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

Разработка по принципу «Чистой комнаты» - это процесс разработки программного обеспечения, направленный на производство программного продукта с сертифицируемым уровнем надежности. Данный подход фокусируется на предотвращении дефектов, а не на их устранении. Также, это интеграция моделирования, формальной верификации, статистического анализа. Верификация выполняется с использованием математических критериев корректности. Статистический анализ используется для анализа тестового покрытия. Преимущества: 1) Ни одной ошибки, 2) Короткий цикл разработки, 3) Длиннее жизнь продукта. Основные принципы: 1) Маленькие команды (Независимые команды для разработки спецификаций, разработки и сертификации), 2) Инкрементная разработка с статистическим контролем качества (Эффективность оценивается на каждом шаге инкрементной разработки с использованием числа ошибок на KLOC, скоростью увеличения MTTF или числом последовательно выполненных безошибочных тестов), 3) Разработка базируется на математических принципах (Для составления спецификации и разработки используется принцип «ящика», Формальная верификация используется для подтверждения корректности реализации спецификации, Корректность проверяется путем рецензирования), 4) Тестирование базируется на статистических принципах (Тестовые наборы случайным образом генерируются на основе модели использования). Виды команд: 1) Specification team (Разрабатывает спецификации), 2) 2) Development team (Разрабатывает и верифицирует продукт, Продукт не компилируется и не выполняется в процессе верификации) 3) Certification team (Разрабатывает множество статистических тестов, Оценивает надежность продукта). Стратегия “Чистой комнаты”: 1) Increment planning (Планирование строится вокруг инкрементной стратегии), 2) Requirements gathering (Сбор и улучшение требований осуществляется классическими методами), 3) Box structure specification («Ящик» - это изоляция поведения и данных на каждом уровне разработки), 4) Формальный дизайн (Спецификация (черный ящик) итерационно улучшается до уровня архитектурного дизайна (устойчивый ящик) и дизайна уровня системы или компонента (чистый ящик)), 5) Верификация корректности (Используются математические подходы к подтверждению корректности спецификации и кода), 6) Генерация кода, инспекции («Ящик» спецификации транслируется в код на языке программирования, инспекции подтверждают соответствие кода и «ящика», синтаксическую корректность кода и т.п.), 7) Статистическое планирование тестов (Тестовые наборы генерируются в автоматическом режиме, случайно, на основе распределения вероятностей шаблонов использования продукта).

7. Основные принципы подхода непрерывной интеграции

Непрерывная интеграция – это методология разработки, ежедневная интеграция результатов, автоматическая проверка билдов. Риски, которые минимизируют НИ: 1) Исправление бага позже стоит дороже, 2) Низкий уровень когерентности в команде, 3) Ухудшение качества кодовой базы, 4) Низкий уровень видения проекта, 5) Низкий уровень анализа развертываемости продукта. Основные принципы: 1) Когда билдить? (При каждом check-in, При каждом изменении зависимости), 2) Как билдить? (Использовать один скрипт построения, Скрипт должен запускаться из командной строки и не зависеть от IDE, Для CI должен быть использован выделенный сервер, Сервер автоматически должен фиксировать все check-in, Сервер предоставляет немедленный фидбэк).