1.2. Модели жизненного цикла информационных систем
В основе разработки и дальнейшего применения программного обеспечения (ПО) пользователем лежит понятие жизненного цикла (ЖЦ).
ЖЦ ПО – это период «жизни» программной системы, начиная с момента возникновения потребности в ней и заканчивая моментом полного ее выхода из эксплуатации.
ЖЦ ПО представляют в виде последовательности стадий (этапов) и выполняемых на них процессов. Для каждой стадии и процесса определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Модель жизненного цикла – структура, содержащая процессы, действия и задачи, которые реализуются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
В настоящее время известны и используются несколько моделей жизненного цикла. Модель жизненного цикла определяется стратегией конструирования программного обеспечения (ПО). Существуют три стратегии конструирования ПО:
- однократный проход (водопадная стратегия) - линейная этапов конструирования (1.2.1Стратегия однократного прохода реализована в старейшей модели жизненного цикла – каскадной (водопадной) модели);
- инкрементная стратегия. В начале процесса определяются все и системные требования, оставшаяся часть конструирования выполняются в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т.д., пока не будет получена полная система
(1.2.2.Поэтапная модель с промежуточным контролем (рис. 1.2) основана на инкрементной стратегии конструирования. В этой модели разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
1.2.3. Модель быстрой разработки приложений (RAD – Rapid Application Development) – второй пример применения инкрементной стратегии конструирования);
- эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.(1.2.4.Спиральная модель – классический пример применения эволюционной стратегии конструирования.
1.2.5. Компонентно-ориентированная модель)
1.2.1. Классическая модель — каскадная
Каскадная модель (также называют водопадной либо последовательной) жизненного цикла была предложена Уинстон Ройсом в 1970 г. и является старейшей парадигмой процесса разработки программного обеспечения. Модель названа каскадной, чтобы подчеркнуть, что разработка информационной системы рассматривается как последовательное выполнение этапов, причем переход на следующий иерархически нижний этап происходит только после полного завершения работ на текущем этапе. Особенностями является то, что последующий этап не начнется, пока не завершится предыдущий, отсутствие возврата к предыдущим этапам, наличие результата только в конце разработки.
Охарактеризуем содержание основных этапов модели.
Подразумевается, что разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного жизненного цикла.
Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО часто является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяется объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к программному элементу - ПО. Уточняются и детализируются его функции, характеристики и интерфейс. Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта.
Рис.1.1. Классический жизненный цикл разработки ПО\
Рисунок не совсем верный – нижняя линия и стрелки не нужны!!!
Проектирование состоит в создании представлений архитектуры ПО, модульной структуры ПО, алгоритмической структуры ПО, структуры данных, входного и выходного интерфейса (входных и выходных форм данных). Исходные данных для проектирования содержатся в спецификации анализа, т.е. в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
Кодирование состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.
Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений: исправление ошибок, адаптация к изменениям внешней для ПО среды, усовершенствование ПО по требованиям заказчика.
Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе, но не в разработке новой программы.
Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.
Достоинства: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.Полная и согласованная документация на каждом этапе;
Легко определить сроки и затраты на проект.
Недостатки:
- реальные проекты часто требуют отклонения от стандартной последовательности;
- цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);
- результаты проекта доступны заказчику только в конце работы.
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем[3].