Почему качество ПО производства ВПК — «дрова» и что с этим делать?

Критически важным для разработки сложных программных систем является организация и техническое обеспечение верификации, тестирования и испытаний системы и составных частей. Учитывая огромный прогресс в технологиях верификации, а также метрик качества ПО, необходимо внедрение данных методик в процесс разработки программного обеспечения военного назначения.

В настоящее время, основной контроль качества осуществляется на межведомственных испытаниях. Почему результирующее качество чуть менее, чем никакое? Значит методика и процесс не отвечают требованиям. Отбрасывая субъективные факторы (исполнение и т. п.), следует рассмотреть основу для методики. На практике методика формируется как набор проверок требований ТЗ. Т.о., если ТЗ мутное, то и методика мутная, покрывающая от силы 10−20% кодобазы продукта.

А почему ТЗ мутное? Снова отбрасывая субъективные факторы, следует констатировать следующие причины:

1. падение уровня проработки ТЗ (НИР и прочие работы перед ОКР);
2. непрерывно растущая сложность систем;
3. есть мнение, что достаточно полное и непротиворечивое ТЗ на перспективную систему составить невозможно.

Почему сегодняшние подходы работали раньше (25 — 30 лет назад)? Во-первых, представляется что проработка ТЗ была несравненно глубже (НИРы и прочие работы), а во-вторых, сложность систем была в разы и даже порядок ниже.

Сложность зарубежных интегрированных систем

При разработке по 12 207 между техническим заданием и методикой находятся несколько стадий (документов), утверждаемых заказчиком. Эти документы являются полезными и актуальными для современного процесса разработки программного обеспечения, но главное они гораздо более детальнее раскрывают требования исходного ТЗ. Есть отдельные
этапы по верификации и валидации этих документов на предмет соответствия техническому заданию. Методика, созданная в процессе разработки по стандарту 12 207, строится на основе вот этих самых промежуточных документов, т. е. появляется фундамент для полных и подробных проверок.

Что не менее важно, за счет новых стадий появляется больше точек анализа качества, а также за счет технологичности документов, появляется возможность привлечения профильных специалистов по контролю качества ПО (как показывает КИМС, военные не любят и не умеют контролировать качество ПО). Одним словом, повышается прозрачность разработки для заказчика, а не как сейчас (подписал ТЗ, пришел на МВИ — а там такое!).

Что делать с мутностью ТЗ? Во-первых, есть возможность исправить ошибки на промежуточных стадиях. А во-вторых, вот тут на помощь приходят более современные модели жизненного цикла (V-модель, спиральная модель).