Каскадная модель ЖЦ программных систем

Введение

За десятки лет разработки программного обеспечения и программных систем создан ряд типовых схем упорядочивания выполнения работ по проектированию и разработке. Такие схемы получили название жизненного цикла и обобщенны в стандарте ISO / IEC 12207 и основных моделях ЖЦ, применяемых на практике.

Примеры крупномасштабных систем ПО:

· Распределенная банковская система;

· Операционная система;

· Компьютерная игра;

· Система контроля и безопасности полетов…

Особенности разработки – усилия многих людей на протяжении длительного времени.

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

Жизненный цикл ПО. Жизненный цикл программ

Жизненный цикл ПО. Тенденции

Подходы к проектированию ПО

1) Строго последовательное выполнение всех этаповжизненного цикла ПО (модель водопада);

2) Поэтапное создание ПО (пошаговая или инкрементная модель);

3) Спиральная модель;

4) Эволюционная модель ЖЦ.

Водопадная (Каскадная) модель ЖЦ программных систем

· Одной из первых начала применяться каскадная модель, где каждая работа выполняется один раз и в таком порядке

· Однако вспомогательные и организационные процессы (контроль требований, управления качеством и др.), как правило, выполняются вместе с процессами разработки ПО. В данной модели возврат к начальному процессу предполагается после сопровождение и исправление ошибок.

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

Каскадная модель ЖЦ программных систем

Недостатки этой модели следующие:

- Процесс создания ПС не всегда укладывается в такую жесткую форму и последовательность действий.

- Не учитываются изменяемые потребности пользователей, нестабильные условия внешней среды, влияющие на изменения требований к ПС при й разработки.

- Значительный разрыв между временем внесения ошибки (например, на процессе проектирования) и время ее обнаружения (при сопровождении), что приводит к существенной переработки ПС.

При применении каскадной модели возможны следующие факторы риска:

- Требования к ПС недостаточно четко сформулированы, либо не учитывают перспективы развития ОС, условий и т.п.

- Громоздкая система, не допускающая компонентной декомпозиции, может вызвать проблемы по размещению ее в памяти или на платформах, не предусмотренных в требованиях.

- Внесения быстрых изменений в технологии и в требования может ухудшить процесс разработки отдельных частей системы или системы в целом.

- Ограничения на ресурсы (человеческие, программные, технические и др.). В ходе разработки могут сузить отдельные возможности реализации системы.

- Полученный продукт может оказаться непригодным для применения вследствие непонимания разработчиками требований или функций системы или недостаточно проведенного тестирования.

Преимущества реализации системы с помощью каскадной модели следующие:

- Все задачи подсистем и системы реализуются одновременно, благодаря чему нельзя забыть ни одного задания, а это способствует установлению стабильных связей между ними.

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

Инкрементный модель ЖЦ

Эту модель (incremental) еще называют моделью с наращиванием или с приростом. Ее суть заключается в разработке продукта итерациями, и каждая итерация заканчивается выпуском трудоспособного версии. В каждой новой версии добавляются некоторые функциональные возможности. Разработка системы начинается с определения набора всех требований к ПС и деления процесса разработки на итерации. Каждая итерация реализуется последовательно с использованием процессов ЖЦ и фиксации рабочей версии системы, системы, которая постепенно приближается к окончательной версии

Первая промежуточная версия системы, которая создается (выпуск 1), реализует часть требований, в последующую версию (выпуск 2) добавляют дополнительные требования до тех пор, пока не будут окончательно выполнены все требования и решены задачи разработки системы.

Для каждой промежуточной версии на процессах ЖЦ выполняются необходимые процессы, работы и задачи, в частности, анализ требований и создание новой архитектуры, которые могут быть выполнены одновременно.

При применении данной модели необходимо учитывать следующие факторы риска:

- Требования составлены с учетом возможности их изменения при реализации продукта;

- Все возможности системы требуется реализовать сразу;

- Быстрое изменение технологии и требований к системе может привести к нарушению полученной структуры системы;

- Ограничения в ресурсном обеспечении (исполнители, финансы) могут привести к несвоевременному вводу системы в эксплуатацию.

Данную модель ЖЦ целесообразно использовать в случаях, когда:

- Желательно реализовать некоторые возможности системы быстро за счет создания промежуточной версии продукта;

- Система декомпозуеться на отдельные составные части, которые можно реализовывать как отдельные самостоятельные промежуточные или готовые продукты;

- Возможное увеличение финансирования на разработку

Исходя из возможности внесения изменений, как в процесс, так и в промежуточный продукт была создана спиральная модель ЖЦльных частей системы.

Спиральная модель ЖЦ

Внесение изменений ориентировано на удовлетворение потребности пользователей сразу, как только будет установлено, что созданные артефакты или элементы документации не соответствуют действительному положению разработки.

Данная модель ЖЦ допускает анализ продукта на витке разработки, его проверку, оценку правильности и принятия решения о переходе на следующий виток или возврата на предыдущий виток для доработки на нем промежуточного продукта.

Отличие этой модели от каскадной заключается в возможности многократно возвращаться к процессу формулирования требований и к повторной разработки версии системы с любого процесса модели.

Для программного продукта такая модель не очень подходит по нескольким причинам. Во-первых, высказывания требований заказчиком носит субъективный характер, требования могут многократно уточняться в течение разработки ПС и даже после завершения и испытания, и иногда может выясниться, что заказчик «хотел совсем другое». Во-вторых, меняются обстоятельства и условия использования системы, поэтому общепризнанным законом программной инженерии является закон эволюции, который сформулируем так: каждое действующее ПС со временем требует внесения изменений или выводится из эксплуатации.

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

Эволюционной модель

В случае эволюционной модели система последовательно разрабатывается с блоков конструкций. В отличие от инкрементного модели в эволюционной модели требования устанавливаются частично и уточняются в каждом последующем промежуточном блоке структуры системы.

В литературе она часто называется моделью быстрой разработки приложений RAD (Rapid Application Development).

факторы риска данной модели:

- Реализация всех функций системы одновременно может привести к громоздкости;

- Ограниченные людские ресурсы заняты разработкой течение длительного времени.

Преимущества применения данной модели ЖЦ такие:

- Быстрая реализация некоторых функциональных возможностей системы и их апробация;

- Использование промежуточного продукта в следующем прототипе;

- Выделение отдельных функциональных частей для реализации их в виде прототипа;

- Возможность увеличения финансирования системы;

- Обратная связь с заказчиком для уточнения функциональных требований;

- Упрощение внесения изменений в связи с заменой отдельных функции.

Модель развивается в направлении добавления нефункциональных требований к системе, связанных с защитой и безопасностью данных, несанкционированным доступом к ним

Методы проектирования ПО

Нисходящая методология

Сложная задача сводится к набору более простых задач, решение которых приведет к выполнению исходной задачи. При этом образуется иерархическая система последовательных уточнений, которая отображается в модульную структуру, совместимую с императивной парадигмой программирования

Восходящая методология

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

Стандарт ISO / IEC 12207:2002 определяет общую структуру и содержание ЖЦ ПС, начиная с разработки концепции до утилизации системы.

Структурно он состоит из описания многих процессов, взаимосвязей между ними, а также сформулированных действий и задач, выполняемых в этих процессах. Иными словами, стандартный жизненный цикл определяет только схему работ по процессам разработки ПС, а не то, как именно выполнять те или иные процессы.

Жизненный цикл ПО. Этапы разработки программ

Анализ определяет требования пользователей, т.е. что должна делать предлагаемая система

Проектирование определяет как программная система будет выполнять требования (задачи) пользователя

Реализация включает написание программы, создание файлов данных и разработку баз данных

Тестирование – это обнаружение в системе ошибок