Основные принципы стратегии «Чистой комнаты»

Стратегия «Чистой комнаты» (Cleanroom Software Engineering) – это инкрементальный процесс разработки программного обеспечения, включающий в себя формальные методы математической верификации и статистического тестирования, направленный на минимизацию количества дефектов в программном продукте. Процесс разработки Cleanroom обладает следующими особенностями:

1. Основное отличие стратегии "Чистой комнаты" от более традиционных стратегий разработки ПО (RUP, Scrum, Agile, XP) заключается в том, что основная доля времени разработки уделяется проектированию, а не тестированию;

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

3. За счёт регулярной верификации вместо тестирования стоимость разработки уменьшается, как и количество потраченного времени;

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

5. Результирующая система является полностью верифицируемой;

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

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

2. Формирование спецификаций. На данном этапе разрабатывается спецификация каждого инкремента (компонента) системы в несколько шагов:

1. Чёрный ящик. Используется для обобщения отдельного компонента системы и демонстрирует, какие входные воздействия могут повлиять на компонент, правила их преобразования, а также выходную реакцию компонента;

2. Ящик состояний. Используется для описания поведения, возможных состояний компонента, в зависимости от входных воздействий;

3. Прозрачный ящик. Используется для описания логики работы компонента (вплоть до конструкций на языке программирования). На данном шаге спецификация компонента может быть верифицирована математически;

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

4. Верификация архитектуры. На данном этапе происходит верификация всех запрограммированных конструкций. Благодаря использованию структурированного подхода, верификация функций сравнительно с модульным тестированием выполняется намного быстрее:

1. Для последовательных участков кода достаточно проверки одного условия;

2. Для блоков if – else – 2 условия;

3. Для циклов – 3 условия;

5. Кодирование и формальная инспекция кода. На данном этапе вся логика должна быть реализована, а каждая строка кода – верифицирована и, если формальная инспекция дала добро, начинается этап тестирования;

6. Статистическое тестирование системы. На данном этапе вместо традиционного подбора тестовых наборов для покрытия всего кода, готовятся тесты, описывающие поведение системы, а также рассчитывается статистическое распределение тестов, которые теоретически должны сработать корректно;

7. Сертификация системы. На данном этапе происходит сертификация продукта, включающая в себя 5 компонентов, формирующих конечную оценку:

1. Варианты использования;

2. Варианты профилей;

3. Тестовые наборы;

4. Результаты тестирования;

5. Надёжность. Данный критерий, в отличие от предыдущих, не был получен на предыдущих этапах, и включает в себя 3 модели:

• Sampling Model. Сертификация нескольких случайных вариантов использования;

• Component Model. Сертификация каждого компонента;

• Certification Model. Сертификация всей системы;

Достоинства модели Cleanroom:

1. Благодаря командной ориентации модели, компоненты системы могут разрабатываться параллельно, что повышает производительность;

2. Постоянные командные встречи, обзоры, статистические испытания и верификации дают лучшее качество кода, чем тестирование и отладка;

3. Качество продукта под конец разработки будет сертифицировано;

Недостатки:

1. Из-за широкого использования математики и статистики, требуются специалисты в данных областях;

2. Так как кодирование занимает наименьшее количество времени, то разработчики должны быть профессиональными программистами;