Начнем с того, что DO-178C не навязывает какой-либо конкретный жизненный цикл или методологию. В нем говорится о целях и действиях, которые могут быть выполнены для достижения этих целей. Более того, цели являются довольно общими, например: «Требования высокого уровня разработаны».
Может показаться, что DO-178C оставляет много места для анархии жизненного цикла с такими общими определениями отдельных целей. Однако полный набор из нескольких десятков взаимосвязанных целей резко сокращает пространство для маневра при выборе жизненного цикла. Каскадная или V-образная модель жизненного цикла представляется самым простым и логичным способом достигнуть всех целей одновременно. Тем не менее самый простой способ – не всегда самый подходящий.
Цели разбиты на 10 групп, представленных в таблицах А1 – А10 в приложении к стандарту. Каждая группа соответствует определенному аспекту жизненного цикла. Кроме того, таблица определяет строгость процесса в отношении уровня программного обеспечения:
По логике вещей, чем выше уровень, тем больше целей нужно достичь. Однако посмотрите на распределение этих целей. Количество целей проверки превышает количество целей разработки в несколько раз. Более того, цели развития одинаковы для программного обеспечения уровня A, уровня B и уровня C. Таким образом, DO-178C считает, что надежность программного обеспечения основывается на тщательности проверки. Этот вывод может быть даже усилен: вы не можете ничего сказать о надежности вашего бортового программного обеспечения, критически важного для безопасности, пока проверка не будет завершена!
Неудивительно, что каскадная и V-образная модель могут стать дорогостоящими, если ошибка распространяется на весь жизненный цикл, прежде чем она будет обнаружена на поздних этапах проверки. Это не редкость, когда дополнительные итерации всего цикла добавляются в конце временной шкалы продукта, чтобы исправить проблемы с самого начала истории. Все это приводит к неприятным срокам, деморализованной и изнуренной команде проекта, рассерженным клиентам и бешеному топ-менеджменту.
Очевидный совет для руководителей проектов заключается в том, чтобы проводить как можно больше проверок как можно раньше. Бинго! Эта концепция является одной из выдающихся черт Agile.
Я не хочу подливать масла в огонь священной войны тяжеловесов против Agile. Я хочу подчеркнуть, что Agile не является эквивалентом анархии. Относитесь к требованиям, дизайну и другим необходимым результатам как к ценной части вашего продукта, а не как к раздражающей или исчерпывающей документации. При такой точке зрения Agile-методы идеально подходят: Разбейте свою модель жизненного цикла на более мелкие итерации и проверку на входе.
Конечно, вы должны быть очень осторожны при внедрении Agile в свой проект, критичный для безопасности. Адаптировать дух Agile-практики к среде DO-178C – непростая задача. Я приведу практический пример такой адаптации в моем следующем посте.