Процесс сертификации программ на базе информации об их использовании

Это новый подход к сертификации, который, по утверждению его разработчиков, дает надежные гарантии качества для коммерческих программных пакетов [30].

Методов сертификации качества программного обеспечения становится все больше и больше. Популярные подходы, основанные на процессах, такие как ISO 9000 и SEI-CMM, вынуждают создателей программного обеспечения жестко придерживаться выбранных стандартов и процессов разработки. Такие подходы зачастую требуют участия аудиторов, которые проверяют документацию производителя и то, как он выполняет данное им обещание. Но даже если аудитор по сертификации может убедиться в чистоте намерений производителя, одна эта проверка вовсе не гарантирует, что созданное программное обеспечение будет высокого качества.

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

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

Организации, выполняющие такую сертификацию, называются лабораториями по сертификации программного обеспечения (Software Certification Laboratories — SCL). Их достоинство в том, что они смогут предоставить равные возможности всем производителям, если, конечно, каждый продукт будет тестироваться в равных условиях.

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

Вот и SCL могут потерять свое реноме и лишиться права заниматься сертификацией в случае ошибки [2]. Чтобы несколько снизить этот риск, необходимо использовать точные методы при принятии решений о сертификации — в идеале автоматизированные. К сожалению, даже если SCL использует лучшие методики статистического анализа и динамического тестирования, не всегда можно понять, какому реальному воздействию подвергнется программа в руках пользователей. Таким образом, SCL сталкивается с проблемой точного определения того, как будет вести себя программная система — самое главное, что требуется от уполномоченных по выдаче сертификатов.

Процесс сертификации, о котором идет речь, использует автоматизированные процедуры, что позволяет отказаться от услуг аудиторов. Этот процесс использует ресурсы тестирования конечными пользователями, полагаясь на доказавшие свою состоятельность методы, подобные тем, благодаря которым Linux стала самой популярной и надежной из всех разновидностей Unix [3, 4]. Предлагаемый процесс, полностью основанный на продуктах, как таковых, оценивает качество работы программного обеспечения, а не качество процессов создания кода.

Модель ограниченной гарантии на ПО

Компонентная разработка программ (CBSE — component-based software engineering) предполагает создание программных систем из фрагментов. Достоинства различных стратегий обсуждаются многие годы, но нет никаких признаков того, что компонентная разработка вот-вот станет стандартным подходом к созданию программных систем.

Уверения в надежности компонентов должны исходить не только от их автора. SCL, которые будут проводить собственное тестирование при сертификации программного обеспечения, столкнутся с теми же проблемами, которые стоят сейчас перед его разработчиками: неадекватный уровень тестирования и неверные предположения о том, как именно будет использоваться продукт. Действительно, уровень тестирования, который SCL в состоянии выполнить и не разориться, может оказаться даже ниже того, который провел сам разработчик. Таким образом, было бы ошибкой думать, что SCL могут выдавать сертификаты, основываясь только на результатах собственного тестирования.

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

Сертификация ПО с участием пользователей

Если SCL и разработчики не могут выполнять адекватное тестирование продукта, то кто же может? Для решения этой задачи можно объединить пользователей, только надо сделать так, что пользователям это будет выгодно. После этого встает вопрос, как лучше всего использовать их возможности сделать реальными гарантии на программное обеспечение.

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

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

Производитель программного обеспечения представляет конечный продукт для включения в него резидентного инструментария тестирования, в результате этого создается специальная, «инструментальная» копия. Производитель предоставляет копии SCL, которая передает инструментальную копию предварительно отобранным пользователям, работающим в разных отраслях. Эти тестировщики будут использовать продукт по согласованию с SCL. Предлагаемая Microsoft модель бета-тестирования — прекрасный пример того, как среди всех желающих отобрать только тех, кто действительно сможет предоставить самый большой объем полезной информации.

Заметим, что было бы возможно и потенциально предпочтительно для SCL самой встраивать необходимый инструментальный код, не привлекая для этого производителя. Это можно было бы сделать, если бы специалисты SCL получили доступ к определенным файлам с исходными текстами или к интерфейсам. По сути, независимая организация в первую очередь призвана сделать так, чтобы производитель как можно меньше знал о пользователях, принимающих участие в тестировании, и не мог влиять на результаты процесса сертификации.

Периодически 8СЬ собирает информацию от пользователей и суммирует ее. Это позволяет 8СЬ предоставить разработчику статистические данные о том, как использовался продукт и как он вел себя во время испытаний. При этом 8СЬ может собирать статистику от участников тестирования таким образом, чтобы восстановить личность конкретного пользователя было бы невозможно.

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

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

Если программное обеспечение прекрасно работает в критичных к безопасности применениях и если 8СЬ сумеет собрать достаточно доказательств этого, можно попробовать сертифицировать его для критически важных областей.

Достоинства модели сертификации с участием пользователей

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

В конце концов, объем необходимых данных будет зависеть от того, насколько строгую и полную гарантию хотим получить.

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

Чтобы быстро добиться получения сертификата, недобросовестные разработчики могут попытаться изменить инструментарий таким образом, чтобы добавить фальшивые датчики, которые помешают проведению тестирования. И 8СЬ должна уменьшить этот риск.

 
< Пред   СОДЕРЖАНИЕ     След >