Принципы Cleanroom

• Инкрементная разработка на основе статистического контроля качества. На каждой итерации выполняется измерение качества. Полученные метрики сравниваются с предопределенными стандартами с целью определения, является ли процесс разработки контролируемым. Если результаты измерения качества не удовлетворяют принятым стандартам, тестирование в данной итерации прекращается и разработчики возвращаются к этапу проектирования.
• Разработка основывается на математических правилах. Программа есть выражение математической функции. ПО строится по модульному принципу. Различают три категории модулей: модуль типа "черный ящик" (black box), модуль-описатель (state box) и "прозрачный" модуль (clear box). Спецификация требований должна определять такие модули и их функциональность. Проверка программы осуществляется на соответствие именно этой функциональности. Верификация программного кода осуществляется командой разработчиков путем тестирования. Не допускается никакого выполнения программ до завершения тестирования.
• Тестирование на основе методов статистики. Формируется репрезентативная выборка вариантов использования ПО. На основе протоколов их тестирования в соответствии с правилами математической статистики делается научно обоснованный вывод о качестве ПО в целом в терминах надежности и доверия к программному продукту. Инструментом автоматизированного тестирования и оценки надежности ПО в технологии Cleanroom служит среда Cleanroom Certification Assistant, в основе которой лежит идея использования статистических результатов тестирования для подсчета надежности ПО математическими методами. Специальный компонент Statistical Test Generation Facility (STGF) имеет собственный язык описания тестовых данных, позволяющий запрограммировать сценарий тестирования – характер распределения данных, моменты возникновения критических событий и т. д. В результате STGF генерирует код на языке Cи, который после компиляции и запуска подает на вход тестируемой программы тестовые данные. Второй компонент – Cleanroom Certification Model – фиксирует результаты тестирования в виде среднего времени наработки на отказ, которые и используются для вычисления метрик надежности.
• Пошаговая детализация. Cleanroom декларирует пошаговую детализацию проекта, когда полная функциональность системы достигается итерационно. В каждой итерации реализуется определенное подмножество функциональных возможностей, которое тестируется и делается заключение о его качестве (а также прогнозируется качество ПО в целом – см. выше). Такой способ разработки имеет ряд достоинств. И разработчики, и заказчик видят, как система растет и развивается. Возникают хорошие предпосылки для улучшения не только самого продукта, но и процессов его производства, поскольку на каждом этапе разработчики анализируют источники возникновения ошибок и стараются их устранить. На этапе формирования архитектуры будущей системы процедуры тестирования проводятся более тщательно, что позволяет локализовать ошибки на ранних стадиях. Поскольку длительность и другие параметры каждого этапа могут корректироваться в ходе работы над проектом, любые изменения в исходных требованиях удается учесть с минимальными затратами.
• Командная разработка. Cleanroom предполагает, что разработка ведется небольшими группами (от 6 до 8 человек). При этом предусматривается парный контроль, но не исключается индивидуальная разработка. Когда определена архитектура ПО и проработаны интерфейсы между компонентами, программирование компонент может выполняться индивидуально. Результаты отдельного разработчика подвергаются коллективной проверке. Для больших проектов может быть использовано несколько рабочих групп, каждая из которых работает над отдельной подсистемой. Таким образом, после разработки общей архитектуры ПО группы могут работать параллельно.
• Перераспределение времени между этапами жизненного цикла. Поскольку одной из главных целей Cleanroom является предотвращение ошибок, времени на этап проектирования отводится существенно больше по сравнению с другими технологиями. Cleanroom не предполагает увеличения общего времени разработки проекта, но делает акцент на проектировании и верификации. Понимание того, что качество больше достигается за счет проектирования, а не тестирования, должно быть отражено в плане проекта. Тестирование может начинаться позже и занимать меньше времени, чем при применении других технологий.
• Использование имеющихся приемов разработки. Cleanroom не препятствует применению методик и приемов, сложившихся у разработчиков, если они не конфликтуют с принципами Cleanroom. Внедрение технологии Cleanroom может осуществляться последовательно. Пилотный проект позволит приспособить приемы Cleanroom к принятой организации труда. Независимость методологии Cleanroom от конкретного типа аппаратных и программных платформ делает ее пригодной для разработки различного ПО – от распределенных приложений до ассемблерных программ.

Cleanroom и объектно-ориентированный подход

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

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

Преимущества Cleanroom

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

Данная технология минимизирует затраты компании-разработчика на стадии поддержки программного продукта за счет увеличения затрат на стадии разработки. Как правило, такой подход в целом снижает совокупные затраты разработчика на всем сроке жизненного цикла продукта.