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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-07