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

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

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

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

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

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

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

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

Моя компания, Reliable Software Technologies, в первую очередь намерена проводить сертификацию выпускаемых в массовом порядке программных приложений и компонентов. В ближайшее время мы планируем сертифицировать такие приложения, как Microsoft Word, PowerPoint и Excel. В перспективе мы рассчитываем проводить сертификацию более малых компонентов, которые могли бы встраиваться в самые разные приложения. Процесс сертификации, как мы предполагаем, позволит сделать более массовым повторное использование программ.

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

Я считаю, что компонентная разработка не получила широкого распространения из-за сложившегося недоверия к программным компонентам и незнания того, как проектировать модули для повторного использования. Возможность быстро объединить два компонента - недостаточное основание для роста популярности CBSE. Те, кто выполняет интеграцию компонентов, должны быть уверены в том, что объединены правильные компоненты и сделано это корректно, а также в том, что объединенные компоненты надежны.

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

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

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

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

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

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

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

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

Рис. 1. Базовый процесс сертификации. Разработчик программного обеспечения представляет коммерческую программу-кандидата лаборатории, занимающейся сертификацией программного обеспечения, которая встраивает в продукт резидентный инструментарий тестирования, служащий для получения данных о производительности этого продукта. Результаты тестирования вместе с требованиями конкретного сектора рынка определяют тип и степень полученной сертификации

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

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

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

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

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

Как сказано во врезке «Основные характеристики модели сертификации с участием пользователей», подобный подход обладает рядом преимуществ. Эти преимущества, однако, не могут быть реализованы до тех пор, пока мы точно не знаем, какие данные необходимы для того, чтобы выдать ограниченную гарантию на программное обеспечение. В конце концов, объем необходимых данных будет зависеть от того, насколько строгую и полную гарантию мы хотим получить.

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

Как мы выясним, что инструментарий добавляет достаточное число «датчиков» (то есть фрагментов, которые позволяют собирать информацию о программе и которые отличают инструментальную версию от коммерческой), если эту процедуру выполняет сам разработчик? Как мы убедимся в том, что данный инструментарий добавляет корректные датчики? Ответить на эти вопросы не намного сложнее, чем понять, как мы убеждаемся в качестве других программных инструментальных средств в различных областях, таких как коммерческое ПО для управления полетами. Например, в Федеральном управлении авиации США определена официальная процедура квалификации программных инструментальных средств. Аналогичную схему можно применить для гарантии того, что инструментарий обеспечивает корректную установку датчиков. Более того, SCL будет нести ответственность за то, что пользователь инструментария (в нашем случае - разработчик программного обеспечения) добавил адекватные датчики. Чтобы быстро добиться получения сертификата недобросовестные разработчики могут попытаться изменить инструментарий таким образом, чтобы добавить фальшивые датчики, которые помешают проведению тестирования. И опять-таки, SCL должна уменьшить этот риск.

Похожие подходы

Хотя предлагаемая модель, объединяющая SCL с привлечением к тестированию пользователей, уникальна, тем не менее, она строится на базе ранее разработанных методик. В частности, она во многом похожа на Quality Feedback Agent в Netscape Navigator 4.5 и на PureVision компании Pure Software.

Netscape 4.5 содержит функцию, называемую Quality Feedback Agent, которая отсылает информацию разработчикам Netscape. Агент активируется, когда Communicator идентифицирует какую-нибудь проблему выполнения. Активизировавшись, агент собирает необходимые технические данные и отображает их виде формы, куда пользователь может вписать комментарии. В Netscape используют эти данные для исправления известных ошибок и выявления новых. К сожалению, большинство пользователей отказываются активировать эту функцию.

PureVision компании Pure Software предлагает функции предварительного резидентного тестирования. Этот подход предусматривает, что разработчик создает специальные, «слушающие себя» копии своего продукта, которые передает пользователям [6]. Копии эти посылают разработчику отчет, который включает в себя номер версии, время начала и окончания работы, используемые возможности, объем используемой памяти и идентификаторы пользователей. Если в продукте возникла ошибка, он добавляет к отчету код завершения и данные стека.

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

Software Testing Assurance Corporation - независимое коммерческое предприятие, созданное в 1997 году с амбициозной целью сделаться ведущей организацией, которая сертифицировала бы программное обеспечение на решение проблемы 2000 года. Ее процедура сертификации основана на стандарте всеобщего тестирования кода и предполагает посещение аудиторами, одобренными STAC, офисов компаний, предоставивших свои продукты для такой сертификации. В итоге, однако, подобные правила предоставления гарантий так никогда и не были предложены.

Долгое время компания Microsoft оставалась лидером в использовании бета-тестирования для сбора информации о том, как работают их продукты. Microsoft предоставляет пользователям для тестирования каждый свой программный продукт перед тем, как выпустить его коммерческую версию и предлагает участникам такого тестирования определенную компенсацию. Предварительно отобранные пользователи получают усовершенствованные копии продукта по сниженным ценам в обмен на информацию, касающуюся стабильности продукта, его надежности и удобства. На основе этой информации Microsoft принимает решение о начале производства основной версии. Подобная практика показывает, что пользователи с готовностью принимают участие в тестировании, если в ответ они получают программное обеспечение по сниженным ценам. Кроме того, Майкл Кузумано и Ричард Селби утверждают, что Microsoft собирает детальные пользовательские профайлы с помощью версий своего ПО, специально оснащенных датчиками [7].

Наконец, упомянем Linux - проект разработки разновидности ОС Unix, начатый в 1991 году, который вызвал большой энтузиазм. Сейчас с ним работают почти 8 млн. пользователей. В создании этого продукта принимают участие тысячи добровольцев, причем посвящают этому свое свободное время [4]. Успех Linux часто приводят в качестве доказательства того, что доверия достойны только свободно распространяемые продукты.

Уроки

Какой вывод можно сделать из этого? Ситуация с Microsoft и Linux показывает, что участие пользователей позволяет создать более совершенное программное обеспечение; пример PureVision и Netscape свидетельствуют о том, что производители во что бы то ни стало стремятся получить информацию о тестировании.

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

Спрос на услуги SCL открывает новые возможности в бизнесе тем, кто сможет решиться на риск; вот почему уже существует несколько SCL. Например, KeyLab сертифицирует чистоту Java-программ, но не гарантирует качество программного обеспечения. Поскольку проверить чистоту языка - задача тривиальная, KeyLab берет на себя минимальную ответственность.

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

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

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

Благодарности

Я благодарен всем, кто откликнулся на эту статью. Я также выражаю свою признательность Чаку Хоуэллу, Джону Макманусу, Роджеру Александеру, Долорес Уоллас, Френку Акрману, Лоре Кассаб и Кейт Миллер за их комментарии к первому варианту данной статьи.

Джеффри Воас (jmvoas@rstcorp.com) - сооснователь компании Reliable Software Technologies.

Литература

1. J. Voas, «The Software Quality Certification Triangle,» Crosstalk, Nov. 1998, pp. 12-14
2. J. Voas, «Software Certification Laboratories: To Be or Not to Be Liable?» Crosstalk, Apr. 1998, pp. 21-23
3. B.P. Miller et al., Fuzz Revisited: A Re-Examination of the Reliability of UNIX Utilities and Services, tech. report, Computer Sciences Dept., University of Wisconsin, Madison, Wisc., 1995
4. B.P. Miller, L. Fredriksen, and B. So, «An Empirical Study of the Reliability of Unix Utilities,» Comm. ACM, Dec. 1990, pp. 32-44
 5. C. Pavlopoulou, Residual Coverage Monitoring of Java Programs, master?s thesis, Purdue University, West Lafayette, Ind., 1997
 6. L. Bingley, PureVision: Shedding Light on Black Art Betas, APT Data Services, New York, June 1995, p. 17
 7. M. Cusamano and R. Selby, Microsoft Secrets, Simon & Schuster, New York, 1998

Developing a Usage-Based Software Certification Process, Jeffrey Voas, IEEE Computer, August 2000, pp. 32-37, Reprinted with permission, 2000, Copyright IEEE CS. All rights reserved.

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

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

  • Сертификация выполняется для стабильной версии продукта. Бета-версии в сертификации не участвуют.
  • Производитель ПО не участвует в сертификации. Вместо этого он предоставляет SCL фиксированное количество версий продукта. В эти версии встраиваются резидентные тестовые «датчики» (специальные фрагменты кода, которые позволяют собирать информацию о программе). SCL лицензирует эти версии предварительно отобранным пользователям, работающим в различных областях.
  • SCL определяет методы тестирования и тип собираемой информации об использовании продукта. Эта информация при передаче в SCL должна шифроваться. Из соображений сохранения конфиденциальности, пользователи, принимающие участие в тестировании, должны быть поставлены в известность о том, какого рода информацию собирают тестовые датчики.
  • SCL принимает свое решение о сертификации на основе совокупного опыта работы с продуктом, накопленного пользователями. Такой подход позволяет провести на порядок более тщательное тестирование, чем это по силам самой лаборатории или производителю. Кроме того, решение о сертификации основываются на опыте использования продукта для решения реальных задач, а не на тестировании в гипотетической среде.
  • Пользовательские данные собираются фоновыми процессами с минимальным вмешательством участников тестирования. Пользователи не тратят никаких дополнительных ресурсов для поиска и накопления информации, кроме компьютерных ресурсов, необходимых для ее сбора и хранения. Хотя им не нужно выполнять никаких задач вручную, их версии будут иметь более низкую производительность из-за того, что фоновые циклы обработки предполагают выполнение тестирования. Пользователи, участвующие в этой программе тестирования, получают компенсацию в виде бесплатного ПО или ПО по сниженной цене.
  • Все сгенерированные пользовательские данные поступают только в SCL. Сырая информация не предоставляется производителю. SCL гарантирует конфиденциальность отношений между нею и пользователями. Как только SCL удаляет «сырую» информацию и гарантирует, что на основе обработанной информации выяснить личность пользователя невозможно, она передает данные производителям. Этот процесс позволяет последним улучшить качество следующих версий програм и сосредоточиться на внутреннем тестировании.
  • Гарантия распространяется на определенные секторы рынка и операционные среды. Когда при тестировании накапливается достаточно данных, чтобы подтвердить корректную работу компонентов в конкретном секторе рынка, SCL предоставит гарантии, специфические для данного сектора. Например, гарантия может звучать следующим образом: «Программный продукт X имеет гарантию надежности 99,9% в среде Windows NT». Понятие «достаточное количество данных» - это функция базовых статистических параметров и вида требуемой гарантии. Например, чтобы быть на 99% уверенным в том, что истинная вероятность ошибки составляет менее 0,00001, необходимо провести 460 тыс. тестов.
  • Пользователи дают свое согласие на участие. Те, кто не хочет принимать участие в этом процессе, делать этого не должны.
  • Производители оплачивают SCL ее услуги. Кроме того, SCL принадлежат собранные данные. Поскольку эти данные обладают определенной экономической ценностью, плата, которую SCL возлагает на издателей, должна быть разумной и справедливой. Отметим, однако, что те получают неоценимую по важности информацию о том, как используется их ПО, и широчайшее его тестирование.
  • Не нужны никакие аудиторы. Большинство существующих моделей сертификации требует, чтобы опытные аудиторы посетили офис производителя и проверили выполнение требований к документации и тестовым планам. Наша схема позволяет избежать ошибок, возникающих в работе аудиторов, обусловленных их человеческой природой.
  • В отличие от ISO 9000 и CMM наша сертификация способствует созданию инновационных процессов. Если организация разработчиков может создать продукты, качество которых подтверждается сертификацией и которые соответствуют стандартам этой компании, значит, она создала новые процессы, достойные внимания других разработчиков. Этот открытый подход позволит избежать риска того, что ISO и CMM могут вынудить нас замкнуться на идеях старых процессов.
  • Наш сертификационный процесс создает основу для выполнения ускоренного распределенного тестирования. Для того чтобы гарантировать высокую надежность, как ее определяют Рик Балтер и Джордж Финелли [1], часто требуется именно такое тестирование. Этот процесс может также позволять использовать модели надежности, подобные разработанной Кейт Мюллер и мной модели Squeeze Play, и часто предполагает проведение массового тестирования, чтобы ослабить влияние оценок, полученных в результате недостаточно качественного тестирования [2].
  • Данный процесс позволяет производителям обойтись меньшим числом промежуточных версий. После того, как их продукт получил сертификацию, производителям придется выпускать намного меньше версий, чтобы исправить обнаруженные в предыдущем варианте ошибки.
  • Если программные пакеты могут получить надежную сертификацию для определенных сред при конкретных предварительных условиях, пользователям с эквивалентными средами больше не придется вкладывать большие средства в повторное тестирование лицензированного программного обеспечения.
  • Поскольку данный подход к сертификации автоматизирован, он позволяет повторить и воспроизвести результаты тестирования, т. е. гарантирует, что другие SCL дадут продукту ту же самую гарантию, поскольку получат те же самые исходные данные.
  • Этот процесс заставляет производителей определять явно, каким должно быть корректное поведение их программного обеспечения. Одна только эта возможность способна обеспечить появление программных продуктов более высокого качества.
  • Данная модель может сократить избыточность программного обеспечения, поскольку производители получают беспрецедентную информацию о том, какие функции используются, а какие оказываются ненужными.

Литература

1. R.W. Butler and G.B. Finelli, «The Infeasibility of Experimental Quantification of Life-Critical Software Reliability,» Proc. Conf. Software for Critical Systems, ACM Press, New York, 1991, pp. 66-76

2. J. Voas and K. Miller, «Software Testability: The New Verification,» IEEE Software, May-June 1995, pp. 17-28