Жизненный цикл программного обеспечения
1.3. Спиральная модель
Основная идея спиральной модели (рис. 1.4) заключается в том, что на этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путём создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы, в процессе анализа которых проводится конкретизация деталей проекта. В результате выбирается обоснованный вариант, который действительно удовлетворяет требованиям заказчика.
Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы за счёт частичной реализации функциональности программного продукта. Тем самым активизируется процесс уточнения и дополнения требований со стороны пользователей системы.
1.4. Процессная модель
Стоит различать понятие модели жизненного цикла и жизненный цикл конкретного программного продукта. Конкретный программный проект обычно использует различные модели ЖЦ для различных компонент программного продукта. Некоторые компоненты могут быть заимствованы из предшествующих проектов или приобретены на рынке ПО, другие проходят итерационный спиральный или каскадный ЖЦ. На практике мы имеем дело со множеством параллельно протекающих процессов разработки, каждый из которых может находиться в состоянии, отличном от других (рис. 1.5).
Так, первая компонента разрабатывается по классическому жизненному циклу: требования, проектирование, реализация, интеграция. Вторая компонента - по сокращенному жизненному циклу. Третья относится к разряду приобретаемых или заимствованных компонент и потому проходит интеграционные испытания сразу после определения к ней требований.
Разработка четвертой компоненты явно определяется спиральным ЖЦ, в рамках которого последовательно реализуется два прототипа. На основании интеграционных исследований прототипов каждый раз производится уточнение требований. На третьем витке спирали, наконец, производится полномасштабное проектирование (создание документов описания архитектуры системы) и реализация окончательного варианта программной компоненты.
Применение процессной модели позволяет более точно отразить ход программной разработки, подчеркивая тот факт, что программный комплекс не однороден и содержит части, степень сложности которых сильно различается. Какие-то функции системы реализовались уже не один раз и могут использоваться практически без изменений в новых проектах. Другие требуют проведения исследовательских работ, многократного моделирования, оценки различных вариантов их реализации.
В общем случае следует отличать ЖЦ разработки ПО, который описывает именно процессы разработки, и ЖЦ самого ПО. В жизненном цикле проекта (разработки) присутствуют такие этапы, как формирование и обучение коллектива, закупка оборудования, создание стендов отладки и тестирования. ЖЦ программного продукта определяет, в свою очередь, процессы, связанные с функционированием самой программы, такие как:
- установка/настройка;
- эксплуатация;
- обновление;
- резервное копирование;
- временный останов;
- вывод из обращения.
Таким образом, можно и нужно говорить и о таком понятии, как ЖЦ проекта разработки ПО, который обычно на фазе инициализации включает в себя и подписание контракта с заказчиком, приобретение лицензий на инструментальное ПО, формирование среды информационной поддержки проекта, подбор и обучение персонала и т.п.
1.5. Формальные преобразования
Рассматривая разные подходы к процессу создания программного обеспечения, нельзя не упомянуть о таком, как метод формальных преобразований. Он заключается в автоматическом построении программы на основе ее формального описания, что гарантирует получение кода, который будет абсолютно точно соответствовать исходной спецификации.
Формальные преобразования - это набор методов, позволяющих математически корректно трансформировать исходные спецификации в код целевой программной системы. Т.к. переход от требований к коду происходит математически корректно, то проблема тестирования и доказательства корректности конечной программы по отношению к спецификации исчезает. Но верификация спецификаций по отношению к требованиям к системе остается.
Очевидно, что этот метод требует наличия формальных спецификаций, составление и доказательство корректности которых является нетривиальной задачей. Именно поэтому метод формальных преобразований редко используется для всего программного комплекса. В большинстве случаев он применяется для той части сложной системы и реализации тех алгоритмов, где исходные требования хорошо формализуемы.
Вопросы и задачи для самостоятельного решения
- Что включает в себя понятие ЖЦ разработки?
- Что такое ЖЦ программы?
- Имеет ли преимущества поэтапная модель ЖЦ разработки по сравнению со спиральной? Если да, то какие?
- Чем отличается процессная модель от поэтапной?
- Какие основные этапы разработки программных систем вам известны?