Выбрать главу

Для всех процессов жизненного цикла стандарт определяет их цели в соответствии с уровнями ПО. Процесс содержит в себе один или несколько видов деятельности, каждое из которых представляет собой набор действий для решения конкретной задачи или группы тесно связанных задач. Конкретный проект может определять один или несколько жизненных циклов и выбирать виды деятельности для каждого процесса, их последовательность и решаемые задачи. DO-178B не задает жесткой структуры жизненного цикла, но рекомендует включать в него процесс планирования, процесс разработки, а также четыре процесса, которые относятся к интегральным: процесс обеспечения качества, процесс управления конфигурацией, процесс верификации, процесс сертификационного взаимодействия (интегральные процессы остаются актуальными в течение всего жизненного цикла, причем особый интерес представляет не относящийся напрямую к программированию процесс сертификационного взаимодействия: в нем поддерживается связь между компанией-разработчиком и организацией, ведающей выдачей сертификатов).

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

Для перехода от одного процесса к другому или повторения процесса должны быть определены критерии перехода, которые являются минимально достаточными условиями перехода к процессу. Только когда все эти условия будут удовлетворены, возможна инициализация нового процесса. Некоторые критерии перехода между процессами зависят от уровня, на которое претендует ПО.

В чем особенности процесса разработки ПО стандарта DO-178B? Разработка ПО состоит, в свою очередь, из четырех процессов: процесса создания требований, процесса дизайна, процесса кодирования и процесса интеграции. Целью процесса создания требований является разработка высокоуровневых требований, которые непосредственно исходят из требований системы и включают функциональные и операционные требования к ПО, критерии производительности, точности, правильности, безопасности, а также интерфейсы, протоколы и другое. Базируясь на высокоуровневых требованиях, процесс дизайна вырабатывает низкоуровневые требования и архитектуру ПО. Низкоуровневые требования - это требования, из которых исходный код может быть создан напрямую, без дополнительной информации. Результатом работы процесса дизайна являются описания: алгоритмов, структур данных, компонентов ПО, низкоуровневых интерфейсов, механизмов управления ресурсами и др. На основе этой информации в процессе кодирования разрабатывается исходный код, из которого в процессе интеграции создается выполняемый объектный код. Последовательность процессов, входящих в процесс разработки, не является строгой, поскольку не все процессы могут быть задействованы. Например, при сертификации уже разработанного ПО могут быть использованы только процессы создания требований и интеграции. Если необходимо добавить к уже разработанному ПО дополнительную функцию, которая не нарушает общей структуры и может быть закодирована непосредственно из требований, тогда последовательность процессов будет выглядеть как создание требований, кодирование, интеграция. Если используются методы разработки прототипов, тогда процессы создания требований, кодирования и интеграции могут повторяться многократно, до тех пор, пока не определится наилучший прототип, после чего будут иметь место процесс дизайна и финальные процессы кодирования и интеграции.