Журнал "Компьютерра" №713

Вмешательство фасилитатора в процесс тестирования должно быть очень аккуратным. С одной стороны, зачастую требуется направить действия пользователя в нужное русло, чтобы получить необходимую информацию (например, если тестируется какой-то конкретный диалог, а пользователь норовит придумать решение поставленной перед ним задачи без использования этого диалога), с другой, участник тестирования должен обладать достаточной свободой в своих действиях, чтобы ситуация была реалистичной - поэтому явных указаний о том, что делать, не выдается.

После завершения праведных трудов пользователя остается подробная запись всех его действий, уже снабженная пометками и готовая для анализа - она пересматривается, определенные моменты снабжаются дополнительными комментариями и т.д. На "выходе" работы аналитика получается толстый письменный отчет, который можно снабдить видеоприложением - например, вырезав выражение лиц участников, когда те сталкивались с трудностями при совершении какого-то действия - дабы заказчик в буквальном смысле слова посмотрел своим проблемам в лицо. (Пример такого отчета мы надеемся выложить на том же многострадальном inside.computerra.ru.)

"По окончании тестирования участники обычно бывают довольны, - рассказывает Татьяна. - Им приятно чувствовать себе экспертами; обычно люди просят, чтобы мы приглашали их и в следующий раз".

Юрий Романов и Михаил Ваннах не раз писали на страницах "КТ" о квантовых свойствах человеческого сознания: в результате измерения его состояние может измениться. Кажется, юзабилити-специалисты об этом прекрасно осведомлены…

ГОЛУБЯТНЯ: Поход в горы

Автор: Сергей Голубицкий

Отправляем в турсун-заде железные мотивы и сосредотачиваемся на мягком материале, ибо скопилось его непристойное множество. Дабы не мусолить разношерстые софтины по отдельности, решил объединить сегодня несколько программ тематически - разыграем сценку "Поход в горы". Вернее, тут и разыгрывать нечего: всю прошлую неделю ежедневно оказывался в ситуации, когда приходилось быстро решать хоть и основополагающие, но элементарные задачи - дефрагментировать диск перед созданием имиджа, получить дистанционный доступ к компьютерам родственников, протестировать стремную программу в виртуальной машине…

О программах, способных выполнять с той или иной долей блеска описанные ситуации, я рассказывал в "Голубятнях" тыщу раз, выделяя то одно, то другое достоинство фаворита дня. Оказалось, однако, что в "фаворитизме дня" кроется жуткая трагедия, способная в критичный момент довести до отчаяния. Поясню ситуацию: одно дело - вальяжно и расслабленно тестировать на досуге ту или иную программулину, совсем другое - в авральном порядке быстро и четко выбрать оптимальный вариант, способный эффективно решить проблему. И здесь оказывается, что все эти "фавориты дня" в экстренной ситуации - тот самый "поход в горы" - начинают трещать по швам: либо не справляются с поставленной конкретной задачей, либо неподъемной своей учебной курвой загоняют в тупик, доводя до сенильного не по годам тремора.

Всю неделю ловил себя на мысли, что приходится отправлять былых "фаворитов дня" в мусорную корзину и браться за поиск новых кандидатов, предоставляющих надежное, быстрое, простое и эффективное решение. Обращаю внимание читателей, что речь идет не о традиционных для "Голубятен" acid tests - кислотных тестах, при которых с софта сгоняется семь потов, а именно о "походе в горы" - проверке функциональной эффективности программ в ситуациях, когда не ставится задача побить мировой рекорд, а всего лишь - надежно, быстро и просто решить банальную задачу. Согласитесь, странно наблюдать, как победители кислотных тестов потешно простоволосятся в, казалось бы, гораздо более приземленных ситуациях.

ОК, скидываем обороты культур-повидлианской насыщенности (упаси господи, у неподготовленных читателей голова сползет набекрень!) и переходим к топорному тексту в лоб. Ситуация первая: виртуальная машина.

После установки чистой Висты на новом ноутбуке постоянно ощущаю шаткость ситуации, обусловленную незнакомым поведением операционной системы. Скажем, прислала мне студентка письмо с ответами на контрольные задания, которые запихала в вордовский документ. Уж сколько я просил-молил пользоваться в электронной переписке чистым текстом, на худой конец - хэтэмээлью, но только не DOC’ами: все впустую! Любовь отечественных "малопродвинутых пользователей" к офисным программам кукожит воображение: с какого-то непонятного будуна вордовские документы мнятся чуть ли не синонимом самого компьютера. Чего только не запихивают конченые ламеры (это те, кому неохота учиться, - в отличие от нас, ламеров не конченых, пребывающих в постоянном наращивании IT-бицепса) в свои DOC’и: и картиночки всякие, и шматки хэтэмээли, выскобленные из веб-браузера через copy-paste, и, прости господи, пытаются втыкать туда даже флэш-клипы и авишки!

Прислала, короче, мне студентка письмо, запустил я приложенный к нему вордовский документ, а паршивец полез чего-то менять в normal.dot. Голова у меня от зашкаленной занятости и без того идет кругом - ну я и кликнул на ОК, не вдаваясь в подробности появившегося на экране сообщения. В результате документ в Ворде не открылся, но это не беда в сравнении с тем, что последовало. А последовал… полный кондец приложению MS Word 2003, который вообще перестал загружаться!

Я, конечно, понимаю, что можно чего-то там освежить в памяти, почитать мануал, добраться до этого покоцанного normal.dot, чего-нибудь там подправить либо заменить на заведомо действующий, только… только нет у меня времени на все эти дурацкие камлания! Нет и баста. Мне гораздо проще и быстрее восстановить образ TrueImage, которые создаю в последнее время чуть ли не через день.

Подлянка с засланным вордовским казачком наглядно продемонстрировала зыбкость почвы, на которой приходится обживаться с новой ОС. В любом случае о лихих тестированиях, кои позволял себе под Windows XP, мечтать не приходится. По крайней мере до окончательного обустройства в Висте и, желательно, появления сервис-пака, повышающего устойчивость системы к непредвиденным сбоям, вызванным нештатными ситуациями или кривым софтом.

Изначально я планировал заниматься тестированием на добром старичке Asus W2, однако 17-дюймовый ноутбук каким-то незаметным, хотя и естественным образом перекочевал на письменный столик Света Моих Очей, где теперь служит площадкой для проведения ежедневных турниров в Stronghold 2, Call of Duty 4 и Heroes 5. Поэтому единственным выходом из ситуации стала установка виртуальной машины на Vaio - для всех случаев софтотестирования и левых экспериментов (нехилый такой переходец получился к "топорному тексту в лоб" - главное, короткий).

В свое время тестировал и рекомендовал в "Голубятнях" WMWare и MS Virtual PC. Оказалось, однако, что для похода в горы обе виртуальных машины напрочь не пригодны. Почему? Потому что - гиганты. Потому что функциональность этих виртуальных машин на несколько порядков превосходит все мыслимые и немыслимые запросы одинокого пользователя. Ну зачем мне, скажите на милость, функции репликации и деплоймента стандартного софта на сотни машин корпоративной сети? Правильно, незачем!

Чтобы прийти к такому, казалось бы, очевидному выводу, пришлось сперва установить (по старой памяти!) WMWare, подспудно побрюзжав в адрес откусанного полгигабайта дискового пространства, а затем утонуть с ушами в мануалах, пытаясь на скорую руку отыскать быстрые решения простеньких задач. Срыл WMWare, поставил Virtual PC - программа, конечно, полегче объемом, но по сути - все та же мечта сисадмина в корпоративном бегемоте. Только мы, домашние ламеры, тут при чем?

В общем, выдаю позитив: innotek VirtualBox [1] - грациозная бесплатная сказка весом 17 мегабайт и функциональностью, перекрывающей все мыслимые запросы домашнего пользователя. Установка - две минуты, ознакомление с интерфейсом и основной функциональностью программы - пять минут, установка гостевой Windows XP - десять минут, запуск - все! - можно работать. Это уже потом я добрался до сравнительных тестов, которые показали: быстродействие гостевых ОС в VirtualBox в разы превосходит именитые виртуальные машины. Хотя чего же тут удивляться, учитывая микроскопические размеры бесплатной альтернативы?

Вердикт: в категории виртуальных машин VirtualBox - тот самый настоящий неприхотливый пацан, на которого только и можно положиться в горах.

Ситуация вторая: дистанционный доступ к компьютерам родственников. В "Голубятнях", навскидку по памяти, я описывал как минимум семь программ, обеспечивающих нужную функциональность: WinVNC, TridiaVNC, Radmin, NetOP Remote Control, Remote Office Manager, TWD Remote-Anything, Remotely Anywhere. Всеми, помнится, восхищался, особенно продуктом французской TWD - с его уникальными фичами - персонализированным слэйвом (slave) и Directory Server, позволяющим обходить любые прокси и корпоративные файрволлы.

Опять же, по старой памяти, начал с TWD Remote-Anything. Условия работы были жесткие - за стеной с выражением нетерпеливого ожидания на лице сидел Свет Моих Очей, недоумевающий - когда же, наконец, папа поможет отразить атаку вероломных рыцарей. А папе просто надоело каждые две минуты бегать к ноутбуку сына, и он решил установить по-быстренькому программу дистанционного доступа. Вот только с TWD по-быстренькому не вышло: я завяз в этой французской гадине на полтора часа! Сын давно махнул рукой и продолжил виртуальные сражения в одиночку, а я все продолжал конфигурировать Directory Server, внешнее имя компьютера, его внутреннее имя, открывать порты на маршрутизаторе, налаживать службу динамического DNS и прочий пакет маразма, который годится для чего угодно, но только не для "похода в горы" - когда нужно просто, быстро и надежно.

Срыл, вспомнил с тоской обо всех остальных ранее тестированных альтернативах, предвкушая повторение напрягов, да и рискнул попробовать хорошо известную, но в руки как-то не попадавшуюся Symantec PCAnywhere [2]. И попал в самое яблочко! Легкая, неприхотливая, интуитивно понятная, устанавливается за минуту, запускается без сбоев - еще через минуту. Вот вам пожалуйста - еще один кандидат на "поход в горы". Если вы в цейтноте, нет времени возиться со сложными настройками, учитываться мануалом, то PCAnywhere - однозначный выбор.

Ситуация третья: дефрагментация. Как-то писал недавно, что давно перестал озабочиваться этим эзотерическим процессом, поскольку утратил чувство логики объединения фрагментов файлов в одном месте на физическом диске. То есть сердцем понимаю - дефрагментировать надо, но вот умом - не схватываю. Теперь же захотелось все-таки перед созданием образа True Image довести раздел С до совершенства, чтобы не стыдно потом было восстанавливать. Дефрагментаторов я тоже перепробовал в жизни с десяток, но ни к одному так и не прикипел. Признаюсь, идеального пацана для "похода в горы" нашел совершенно случайно - по наводке уж не помню какого бакунианского блога: UltimateDefrag [3].

Привлек в дефрагментаторе неортодоксальный подход к процедуре - вместо традиционной и как раз вызывающей у меня нарекания опции Fragmented Files Only, программа предлагала целый ряд непривычных, а главное - осмысленных альтернатив: перемещение на выгодные участки диска (поближе к MFT и к быстрым внешним трекам) определенных директорий и файлов (например, Windows, Program Files и т. п.) с учетом различных критериев: последние обращения (Recency), частота изменений (Volatility), интенсивное использование (например, какой-то игры). Вкупе с архивацией редко используемых файлов и папок UltimateDefrag позволяет производить 35 вариантов дефрагментации диска, и самое главное - в доходчивом мануале даются четкие и прямые рекомендации, для каких типов компьютеров и пользователей какие способы дефрагментации предпочтительны.

В общем, установил, дефрагментнул, создал идеальный образ диска - доволен!

ТЕХНОЛОГИИ: Все, что вы хотели спросить о сертификации бортового программного обеспечения, но боялись узнать

Автор: Титов,Анатолий

Рынок ПО сегодня затоварен. Даже самый притязательный потребитель не уйдет из магазина с пустыми руками. Но все ли продукты можно считать достаточно надежными для использования в областях, связанных с безопасностью жизни? Поставим вопрос шире: каким должно быть программное обеспечение или что необходимо сделать, чтобы его можно было использовать в критических областях? Давно замечено, что от культуры производителя зависит качество выпускаемого им продукта. То есть ответ лучше всего искать там, где производители лоб в лоб сталкиваются с задачами обеспечения надежности и безопасности своих продуктов. Авиационная индустрия является одной из таких областей.

ОБ АВТОРЕ

Анатолий Титов - профессиональный разработчик ПО, семнадцать лет работающий в аэрокосмической индустрии. Участвовал во многих проектах, в том числе был ведущим разработчиком технологии TCL/MC3 - кроссплатформного стандарта векторных электронных карт, сертифицированного для использования в бортовых летно-информационных системах. Также принимал участие в работе над REDSHIFT 3 и 4.

Авиаиженеры постоянно занимаются проблемами обеспечения безопасности, поэтому свой опыт они успешно переносят и на ПО. Компании, производящие авиационное ПО, имеют богатую историю проектирования больших критических систем, и репутация их программных продуктов очень высока. Примером использования ПО в авиации можно назвать устанавливаемые практически на все современные самолеты электронные летно-информационные системы (Electronic Flight Information System, EFIS). На дисплеях этих систем ПО отображает информацию (крен, курс, тангаж, скорость, высоту, скольжение и пр.), которую раньше предоставляли механические приборы, а также многое другое, включая полетные и погодные карты. О требованиях, предъявляемых к ПО в авиации, и рассказывает эта статья.

Какой же подход у авиационной индустрии к надежности ПО? Надежность любой программы должна быть доказана, иначе она не может считаться ни надежной, ни безопасной. Поскольку доказать правильность выполнения программы на практике в общем случае невозможно, авиаторы ограничиваются сертификацией согласно установленному стандарту. Без этого ни один прибор, ни одна система не могут быть смонтированы на летательном аппарате. В США сертификаты выдает FAA (Federal Aviation Administration), в Канаде - Transport Canada, в Европе - JAA (Joint Aviation Authorities). Все эти организации главным стандартом для сертификации бортового авиационного ПО полагают RTCA DO-178B (или его европейский аналог EUROCAE ED-12B). Этот стандарт начал разрабатываться в начале 80-х годов, первая редакция появилась в 1982 году, актуальная версия была выпущена десять лет спустя. Специальный стандарт для сертификации бортового ПО понадобился потому, что подход к сертификации ПО существенно отличается от подхода к сертификации любого агрегата самолета, поскольку методы проверки надежности оборудования неприменимы для ПО. Например, мы можем, взяв на тестирование крыло самолета, приложить к нему нагрузку. На тысячный раз под воздействием нагрузки крыло сломается, и мы сумеем определить параметры безопасности нагрузки и интенсивности ее применения, при которых крыло остается недеформированным. С программами такое не проходит. Поэтому для сертификации ПО предлагается другой подход: необходимо определить жизненный цикл ПО, входящие в него процессы, установить их цели, виды деятельности, условия переходов между ними, доказать сертификационной власти, что все они соответствуют стандарту и что авиаторы следуют им на всем протяжении жизненного цикла ПО. Стандарт DO-178B и содержит всю эту информацию.

С чего начинается сертификация? Сертификация начинается с классификации рассматриваемого ПО с точки зрения безопасности. Классификация напрямую связана с тяжестью состояния отказа, которое ПО может вызывать. Состояние отказа определяется как воздействие на летательный аппарат (ЛА) или на лиц, находящихся на его борту, привносящее существенный вред в операционные условия и окружение ЛА. Установлены следующие категории состояний отказа:

• A. Катастрофическое - состояние, не совместимое с безопасным полетом и посадкой.

• B. Опасное - состояние, при котором функциональные способности ЛА или способности экипажа справляться с неблагоприятными условиями управления достигают нижних пределов безопасности. Экипаж не может выполнять свои задачи аккуратно и полностью.

• C. Существенное - состояние, при котором функциональные способности ЛА или способности экипажа справляться с неблагоприятными условиями управления снижены до существенных пределов. Имеет место существенное увеличение нагрузки на экипаж или ухудшение эффективности работы экипажа.

• D. Несущественное - состояние, не приводящее к значительным потерям безопасности управления ЛА.

• E. Не влияющее - состояние, никак не влияющие на способности управления ЛА.

Исходя из этой классификации и сертифицируются программные продукты (очевидно, что для программ, сбой которых приводит только к состоянию Е, сертификация не требуется, а программы, способные привести к катастрофе, проверяются гораздо тщательнее остальных). Чем выше уровень ПО (от D до A), тем более жесткие требования предъявляются к нему, к детальности и объему необходимой документации, и, как следствие, требуется больше ресурсов для процесса сертификации. Определение уровня сертификации выясняется во время консультаций с сертификационной властью, которая руководствуется двумя базовыми принципами:

• Уровень ПО зависит от уровня других программных компонентов, использующихся в системе, а также аппаратного обеспечения, на которое предполагается установить это ПО.

• Если аномальное поведение ПО может приводить к различным категориям состояния отказа, то уровень ПО выбирается в соответствии с самым серьезным состоянием отказа.

Что понимается под жизненным циклом? Ключевым понятием DO-178B является понятие жизненного цикла программы. Стандарт определяет жизненный цикл ПО как период времени, который начинается с решения о производстве или модификации программного продукта и заканчивается тогда, когда продукт перестает поддерживаться (причем под продуктом здесь понимается не только сама программа, но и связанные с нею документация и данные). Жизненный цикл состоит из набора процессов, являющихся необходимыми и достаточными для производства и поддержки программного продукта. DO-178B жестко не устанавливает каких либо моделей жизненного цикла, поэтому любые модели, будь то каскадные, итерационные или какие-либо другие, могут быть использованы, но он требует, чтобы они были описаны или чтобы были указаны источники их описаний, а также показано, что жизненный цикл следует этим моделям. Все, что производится в течение жизненного цикла для планирования, управления, объяснения, определения, контроля, доказательства проведения определенных действий, - относится к артефактам ЖЦ ПО, и без этих артефактов сертификация невозможна.

Для всех процессов жизненного цикла стандарт определяет их цели в соответствии с уровнями ПО. Процесс содержит в себе один или несколько видов деятельности, каждое из которых представляет собой набор действий для решения конкретной задачи или группы тесно связанных задач. Конкретный проект может определять один или несколько жизненных циклов и выбирать виды деятельности для каждого процесса, их последовательность и решаемые задачи. DO-178B не задает жесткой структуры жизненного цикла, но рекомендует включать в него процесс планирования, процесс разработки, а также четыре процесса, которые относятся к интегральным: процесс обеспечения качества, процесс управления конфигурацией, процесс верификации, процесс сертификационного взаимодействия (интегральные процессы остаются актуальными в течение всего жизненного цикла, причем особый интерес представляет не относящийся напрямую к программированию процесс сертификационного взаимодействия: в нем поддерживается связь между компанией-разработчиком и организацией, ведающей выдачей сертификатов).

Процесс планирования устанавливает виды деятельности и координирует взаимодействие между процессом разработки и интегральными процессами. Кроме того, при планировании разрабатываются планы для всех процессов жизненного цикла, а также разрабатываются или выбираются три стандарта ПО: стандарты требований, дизайна и кода.

Для перехода от одного процесса к другому или повторения процесса должны быть определены критерии перехода, которые являются минимально достаточными условиями перехода к процессу. Только когда все эти условия будут удовлетворены, возможна инициализация нового процесса. Некоторые критерии перехода между процессами зависят от уровня, на которое претендует ПО.

В чем особенности процесса разработки ПО стандарта DO-178B? Разработка ПО состоит, в свою очередь, из четырех процессов: процесса создания требований, процесса дизайна, процесса кодирования и процесса интеграции. Целью процесса создания требований является разработка высокоуровневых требований, которые непосредственно исходят из требований системы и включают функциональные и операционные требования к ПО, критерии производительности, точности, правильности, безопасности, а также интерфейсы, протоколы и другое. Базируясь на высокоуровневых требованиях, процесс дизайна вырабатывает низкоуровневые требования и архитектуру ПО. Низкоуровневые требования - это требования, из которых исходный код может быть создан напрямую, без дополнительной информации. Результатом работы процесса дизайна являются описания: алгоритмов, структур данных, компонентов ПО, низкоуровневых интерфейсов, механизмов управления ресурсами и др. На основе этой информации в процессе кодирования разрабатывается исходный код, из которого в процессе интеграции создается выполняемый объектный код. Последовательность процессов, входящих в процесс разработки, не является строгой, поскольку не все процессы могут быть задействованы. Например, при сертификации уже разработанного ПО могут быть использованы только процессы создания требований и интеграции. Если необходимо добавить к уже разработанному ПО дополнительную функцию, которая не нарушает общей структуры и может быть закодирована непосредственно из требований, тогда последовательность процессов будет выглядеть как создание требований, кодирование, интеграция. Если используются методы разработки прототипов, тогда процессы создания требований, кодирования и интеграции могут повторяться многократно, до тех пор, пока не определится наилучший прототип, после чего будут иметь место процесс дизайна и финальные процессы кодирования и интеграции.

Есть ли ограничения по выбору языка программирования? Стандарт не дает каких бы то ни было рекомендаций по выбору языка программирования, но выбор высокоуровневого языка предпочтителен. Высокоуровневые языки считаются более надежными, поскольку код у них прозрачнее, в нем легче прослеживается связь с требованиями дизайна, он детерминирован, устойчив, и на нем можно реализовывать синтаксически сложные конструкции. До недавнего времени для бортового ПО использовался только язык Ada, сейчас более популярны С и С++. Существует бортовое ПО, написанное на языке Java.

Достаточно ли одного тести-рования для выявления всех ошибок, которые могут быть допущены в течение всего жизненного цикла? DO-178B утверждает, что этого недостаточно. Согласно стандарту, за нахождение ошибок и информирование о них отвечает процесс верификации ПО. Этот процесс кроме тестирования должен использовать такие методы верификации, как ревизия и анализ. Под ревизией понимается инспекция выходной информации исследуемого процесса в соответствии с контрольным перечнем. Анализ детально экзаменует функциональность, производительность, источники требований, полноту тестирования, безопасность компонента ПО, а также его взаимоотношения с другими компонентами бортового ПО. Анализ может выявить противоречия и несоответствия в спецификации, требованиях, дизайне и коде. Одним из инструментов анализа могут быть так называемые формальные методы, под которыми понимаются описательные нотации или аналитические методы, используемые для конструирования, разработки и оценки математических моделей поведения системы. Всего стандарт выделяет шесть типов ревизий и анализов: высокоуровневых требований, низкоуровневых требований, архитектуры, исходного кода, результатов интегральных процессов и тестирующих примеров. За тестирование в процессе верификации ПО отвечает процесс тестирования ПО, состоящий из тестов на соответствие установленным требованиям и анализа тестового покрытия, который, в свою очередь, состоит из анализа покрытия тестов и анализа структурного покрытия. Первый проверяет, что у каждого требования есть свой тестирующий пример; целью второго анализа является выявление структур кода, не охваченного тестирующими примерами. Если при анализе структурного покрытия будет выявлен не протестированный код, то решений может быть два: создание тестов, покрывающих этот код, или удаление кода как "мертвого". Конечно, в некоторых языках программирования есть конструкции, которые довольно трудно проверить. Эти особенности языка должны быть описаны в документации. Кроме нормальных тестов, использующих правильные входные данные, стандарт требует проводить тесты на устойчивость. Эти тесты включают установку неправильных начальных значений для переменных, инициализацию данных в ненормальных условиях, сбойную модель входной информации, нарушение временной синхронизации и др.

Какие документы требуются для успешной сертификации? Для сертификации ПО согласно DO-178B должен быть представлен не только исходный и выполняемый объектный код, сопровождающийся подробной документацией. Вот минимальный набор документов, который должен быть представлен сертификационной власти: план программных аспектов сертификации (ППАС), требования ПО, описание дизайна, индекс конфигурации ПО, резюме произведенного ПО. ППАС служит главным средством, используемым сертификационной властью для определения соответствия кандидата на получение сертификации на заявленный уровень ПО. План должен содержать: описание функций и назначения программных и аппаратных средств, обзор ПО, обоснование уровня ПО и методы обеспечения безопасности, описание жизненного цикла, описание всех артефактов. Резюме произведенного ПО - это основной инструмент показа соответствия программного продукта с ППАС и содержащий характеристики ПО, его идентификацию, историю изменений и отчет о соответствии с DO-178B. Производство большого количества детальных документов преследует еще одну важную цель: возможно, что в процессе создания этих документов выявятся проблемы и ошибки в ПО, а также появятся идеи по его модернизации и улучшению.

Сертификация - это дорого? Да. Сертификация ПО согласно стандарту DO-178B - довольно дорогая процедура. Она приводит к увеличению стоимости разработки ПО на 50–200% и напрямую зависит от уровня ПО, на который нацелена сертификация. Стоимость сертифицированного ПО при покупке, для установки на своем оборудовании или использование его как части своего ПО может отличаться в разы от стоимости несертифицированного ПО. Любое, даже самое незначительное изменение ПО, приводит к потере сертификационного доверия к нему сертификационной властью, и это ПО должно быть повторно сертифицировано. Поэтому любое изменение такого ПО обходится очень дорого.

Дает ли программное обеспечение, прошедшее сертификацию, стопроцентную гарантию безопасности? Конечно, нет. Невозможно утверждать со стопроцентной гарантией, что и после прохождения сертификации ПО удовлетворяет всем требованиям безопасности. Но сертификация - это именно тот путь, который напрямую ведет ПО в направлении надежности и безопасности, и эти показатели для такого ПО очень высоки. Достоинства ПО, прошедшего сертификацию, таковы:

• Высокая надежность и безопасность.

• Высокое качество, поддающееся проверке.

• Непротиворечивость.

• Возможность повторного использования.

• Низкая стоимость технического обслуживания.

• Быстрая интеграция с аппаратными средствами.

• Переносимость на другие платформы.

Предполагаются ли изменения в стандарте? Несмотря на всю эволюцию ПО, DO-178В остается основным стандартом сертификации ПО для бортовых систем. Происходит это потому, что DO-178В не содержит требований, касающихся структуры организации ПО, его операционных способностей и возможностей; в нем также отсутствуют ссылки на какие-либо конкретные национальные или международные стандарты. Этот стандарт используется не только в авиации. Например, он успешно применяется в медицине. Существуют планы его использования в атомной промышленности и робототехнике. Начиная с 2005 года ведется разработка нового стандарта сертификации бортового оборудования под названием DO-178С, который предполагается опубликовать в 2008 году. Главное отличие нового стандарта от текущего в том, что в нем будет сделан акцент на объектно-ориентированные технологии, на более широкое использование формальных методов верификации ПО, на моделирование бортовых систем с помощью ПО, будет большая согласованность между процессами жизненного цикла ПО, а также улучшится кооперация DO-178 с другими документами RTCA. Есть большая вероятность, что новая версия стандарта станет основным документом для любых критических систем, где используются программные продукты и где безопасность людей является доминирующим критерием.

FAA утверждает, что, в принципе, можно и не сертифицировать программное или аппаратное обеспечение согласно установленным ею стандартам, а можно предложить какой-либо другой стандарт и провести сертификацию согласно этому стандарту. Но тогда придется доказать сертификационной власти, что новый стандарт лучше с точки зрения надежности и обеспечения безопасности, нежели тот, который он пытается заменить.

Сертификация текста

Перед вами, пожалуй, самый многострадальный текст этого года, переживший жесточайшую авторскую и редакторскую правку. Началось все со статьи Анатолия Титова с поэтичным названием "Сертификация программного обеспечения в авиации. Вопросы по сертификации бортового программного обеспечения согласно стандарту RTCA DO-178B". Из текста было понятно, что автор прекрасно разбирается в предмете, но, по грубым прикидкам, в оригинальном виде эта статья заняла бы полос двадцать, не меньше. Причем большая часть полос состояла бы из пассажей вида "эти требования, в зависимости от их строгости, классифицируются на две категории: контрольную категорию 1 (КК1) и контрольную категорию 2 (КК2), причем КК2 представляет собой подмножество КК1". У нас не было никаких сомнений, что дочитавший статью до конца поймет, наконец, как и зачем сертифицируется программное обеспечение для самолетов, однако в том, что таких счастливчиков окажется относительно немного, сомнений тоже не возникало - тема довольно сложная, и особых скидок на читателей еженедельных журналов автор не делал. По нашей просьбе текст был значительно сокращен (более чем в четыре раза!) и упрощен; кроме того, автор изменил внутреннюю структуру текста - по большому счету, это был даже не правленный, а заново написанный материал на ту же тему. Но даже в таком виде он казался слишком сложным для периодического издания. Мы попытались смягчить самые формально описанные фрагменты, пока наконец не поняли, что чрезмерное упрощение статьи только умаляет сложность задачи, которая стоит перед программистами, работающими на авиаиндустрию. Другими словами, НОСР (не очень сообразительный редактор) вовремя перестал выкидывать из АТ (авторского текста) НК (непонятные куски) и МА (многочисленные аббревиатуры). К слову, во время жизненного цикла статьи автор проявлял поистине ангельское терпение, потому что НОСР отвечал на АП (авторские письма) нерегулярно, чем заметно усложнил процесс сертификации текста. ВГ

СОФТЕРРА: Софтерринки

Автор: Илья Шпаньков

Citius, altius, fortius

ОС Windows, Linux, Mac OS X

Адрес www.mozilla.com/en-US/firefox/3.0b1

Версия 3 beta 1

Размер 8,4 Мбайт

Интерфейс многоязычный (русский поддерживается)

Цена бесплатно

Лицензия MPL/GPL/LGPL

Первая бета третьей версии популярного свободного браузера Mozilla порадовала очередными новшествами. Прежде всего отметим полностью переработанную систему закладок: теперь записи о них сохраняются во встроенной базе данных, что, по задумке авторов, делает браузер удобнее и стабильнее. Можно присваивать закладам теги, автоматически отслеживать ваши любимые страницы (Smart Places), выполнять поиск по закладкам и истории. Кроме того, появились средства оповещения о неблагонадежных веб-сайтах и блокирования доступа к ним. Добавилась интеграция с антивирусными программами и система "родительского контроля", позволяющая предотвратить загрузку файлов из Сети. Многие пользователи отмечают ускорение загрузки страниц.

Долговой калькулятор

ОС Windows

Адрес www.mega-soft.ru/prg1252.html

Версия 1.04

Размер 36 Кбайт

Интерфейс русский

Цена бесплатно

Лицензия проприетарная (freeware)