Критически важным для разработки сложных программных систем является организация и техническое обеспечение верификации, тестирования и испытаний системы и составных частей.
Учитывая огромный прогресс в технологиях верификации, а также метрик качества ПО, необходимо внедрение данных методик в процесс разработки программного обеспечения военного назначения.
В настоящее время, основной контроль качества осуществляется на межведомственных испытаниях. Почему результирующее качество чуть менее, чем никакое? Значит методика и процесс не отвечают требованиям. Отбрасывая субъективные факторы (исполнение и т. п.), следует рассмотреть основу для методики. На практике методика формируется как набор проверок требований ТЗ. Т.о., если ТЗ мутное, то и методика мутная, покрывающая от силы 10-20% кодобазы продукта.
А почему ТЗ мутное? Снова отбрасывая субъективные факторы, следует констатировать следующие причины:
- падение уровня проработки ТЗ (НИР и прочие работы перед ОКР);
- непрерывно растущая сложность систем;
- есть мнение, что достаточно полное и непротиворечивое ТЗ на перспективную систему составить невозможно.
Почему сегодняшние подходы работали раньше (25 — 30 лет назад)? Во-первых, представляется что проработка ТЗ была несравненно глубже (НИРы и прочие работы), а во-вторых, сложность систем была в разы и даже порядок ниже.
Как ГОСТ 12207 и современные модели жизненного цикла могут помочь? Для начала, методика в 12207 создается не на основе ТЗ.
При разработке по 12207 между техническим заданием и методикой находятся несколько стадий (документов), утверждаемых заказчиком. Эти документы являются полезными и актуальными для современного процесса разработки программного обеспечения, но главное они гораздо более детальнее раскрывают требования исходного ТЗ. Есть отдельные
этапы по верификации и валидации этих документов на предмет соответствия техническому заданию. Методика, созданная в процессе разработки по стандарту 12207, строится на основе вот этих самых промежуточных документов, т.е. появляется фундамент для полных и подробных проверок.
Что не менее важно, за счет новых стадий появляется больше точек анализа качества, а также за счет технологичности документов, появляется возможность привлечения профильных специалистов по контролю качества ПО (как показывает КИМС, военные не любят и
не умеют контролировать качество ПО). Одним словом, повышается прозрачность разработки для заказчика, а не как сейчас (подписал ТЗ, пришел на МВИ – а там такое!).
Что делать с мутностью ТЗ? Во-первых, есть возможность исправить ошибки на промежуточных стадиях. А во-вторых, вот тут на помощь приходят более современные модели жизненного цикла (V-модель, спиральная модель).
