Файл: каскадная, поэтапная модель с промежуточным контролем, спиральная, инкрементная».pdf
Добавлен: 16.02.2024
Просмотров: 61
Скачиваний: 0
СОДЕРЖАНИЕ
1. ПОНЯТИЕ ПРОГРАММНОЙ СИСТЕМЫ. АРХИТЕКТУРА И МЕТОДОЛОГИЯ ПРЕКТИРОВАНИЯ ПРОГРАММНОЙ СИСТЕМЫ
1.1. Понятие программной системы
1.2. Архитектура программной системы
1.3. Структурное программирование
1.4. Методы структурного проектирования
1.5. Технология модульного программирования
2. ЖИЗНЕННЫЕ ЦИКЛЫ ПРОГРАММНЫХ СИСТЕМ
Модели различаются способом взаимосвязи этапов жизненного цикла, но каждый из этих этапов в том или ином виде присутствует в каждой модели.
Стратегия. На этом этапе разработчики должны понять требования заказчика, определить задачи и цели проекта, уточнить этапы работ. Далее разрабатывается документация, включающая стоимость работ, график выполнения работ, ожидаемую прибыль и т.п. Ошибки в требованиях к программному продукту недопустимы, т.к. они могут повлечь за собой потери времени и средств, иногда ощутимые, а порой и вовсе привести к провалу проекта. Заключительным шагом определения стратегии является совместное заказчика и поставщика решение об условиях выполнения работ и обязанностях сторон.
Анализ. Подробно исследуются бизнес-процессы, определенные на этапе выбора стратегии, и информация, необходимая для их выполнения. Собранная информация формализуется и уточняется, Информация должна быть полной и исчерпывающей, не должна содержать дублирующей информации, или быть бесполезной или противоречивой.
Проектирование. Проектировщики на основе входных данных анализа формируют модель данных, на основе которой создается техническая спецификация или несколько спецификаций отдельных модулей системы. Все спецификации должны быть предельно точными. Разрабатывается план тестирования системы.
Реализация. На данном этапе разработчики, опираясь на техническую спецификацию, начинают писать код будущей системы. К работе подключаются тестировщики.
Тестирование. Как правило, работа над проектом и тестирование его отдельных частей происходит параллельно. Это целесообразно, т.к. тестирование сложных проектов требует большого количества времени. Исправление возникающих ошибок также занимает много времени, поэтому не имеет смысла начинать тестирование после окончания этапа реализации проекта, это может привести к затягиванию процесса и подорожанию проекта.
Внедрение. Программная система вводится в эксплуатацию, как правило, постепенно. На этом этапе также проводится обучение пользователей.
Эксплуатация и техническая поддержка. Во время эксплуатации готового продукта могут возникать невыявленные в процессе тестирования ошибки. Техническая поддержка призвана устранять такие ошибки, также на данной стадии происходит техническая поддержка пользователей по эксплуатации системы.
2.3. Каскадная модель
Классическим жизненным циклом считается каскадная модель (Waterfall model, «водопад»), предложенная Уинстоном Ройсом в 1970 г. Особенностью модели, отраженной в названии, является поэтапная разработка с переходом на нижнюю ступень только после завершения всех работ на предыдущей ступени.
Разработка начинается с момента заключения договора с заказчиком (этап подготовки, или определения требований), далее следуют этапы планирования, анализ требований, проектирование, кодирование, тестирование и эксплуатация [7] (рис. 6).
Рисунок 6 – Каскадная модель ЖЦ ПС
В каскадной модели переход с одного этапа ЖЦ на другой возможно только после полного и корректного завершения предыдущего этапа. Каждая стадия проходит четкую детализацию, после чего формируется комплект проектной документации.
Идеальным вариантом применения данной модели в разработке ПС было бы строго последовательное выполнение каждого этапа проекта всего один раз, с максимально точным определением требований к каждому этапу проекта и всей программной системы в целом. На практике не всегда удается достичь идеала. Неточность, допущенная при определении требования или его интерпретации, может привести к возврату на уже завершенный этап проекта, что неизменно влечет за собой изменение графика работ и дополнительные финансовые затраты, а иногда и к изменению первоначальной формы проекта.
Преимущества каскадной модели:
- каждый шаг разработки планируется на этапе согласования договора, для каждой стадии выпускается свой набор документов;
- четкая последовательность выполнения стадий работ позволяет поставщику планировать сроки завершения всех работ, а заказчику контролировать сроки и стоимость проекта;
- на начальном этапе четко определяются затраты времени и средств.
Недостатки каскадной модели:
- тестирование начинается на завершающем этапе разработки, исправление выявленной ошибки влечет за собой дополнительные финансовые расходы;
- если в процессе проектирования возникает необходимость изменения требований к проекту, нередко следует переделка всей проделанной работы;
- готовый продукт доступен заказчику только в конце разработки и только тогда он может убедиться в соответствие продукта (или наоборот) своим ожиданиям и дать критическую оценку.
Вероятно¸ именно поэтому каскадную модель считают наиболее подходящей для разработки ПС в крупных отраслях, например, в экономической, медицинской или промышленной, где уже сформирована обширная база документации, которую можно использовать при формировании требований к новому проекту. Применение данной модели при создании проектов ПС в бизнес-проектах неэффективным.
2.3.1. Макетирование
Случается так, что заказчик, знает, что хочет получить, но не знает, как подробно сформулировать требования к будущему продукту. В этом случае прибегают к помощи макетирования, основная цель которого прояснить все нюансы и неопределенности.
В процессе макетирования создается модель будущего продукта. Макет модели может быть бумажным или на основе ПК (реализуют человеко-машинный диалог), работающий макеты (выполняет часть требуемых функций) или существующая программа (характеристики которой в будущем будут улучшены) [7].
Этапы макетирования отражены на рисунке 7 – Последовательность действий при макетировании.
Рисунок 7 – Последовательность действий при макетировании
2.4. Каскадная модель с промежуточным контролем
Каскадная модель с промежуточным контролем («водоворот», или итерационная модель) является модификацией предыдущей модели. Промежуточный контроль осуществляется с помощью циклов обратной связи между этапами. Этапы, как и в модели «водопад» расположены последовательно, но каждый следующий этап имеет связь с предыдущими (рис.8).
Рис 8 – Каскадная модель с промежуточным контролем
Такая модель жизненного цикла ПС реализует возможность внесения изменений на предыдущем этапе, если уже был начат следующий. Промежуточный контроль осуществляется путем исправления ошибок на каждом из этапов непосредственно в момент выявления проблемы.
Преимуществом каскадной модели с промежуточным контролем благодаря промежуточным корректировкам является снижение риска получения некачественного продукта и повышение надежности системы. Промежуточные корректировки обеспечивают возможность вернуться на один или несколько уровней назад до внесения изменений. Однако здесь проявляются и недостатки: время жизни каждого из этапов равно периоду разработки, само время, отведенное на разработку, может быть увеличено, следом возрастают и затраты на реализацию проекта, а согласование результатов происходит после внедрения, что может повлечь за собой моральное устаревание системы и низкую востребованность.
2.5. Инкрементная модель
Инкрементная модель (Incremental model, «increment» в переводе с англ. — приращение) представляет собой процесс частичной реализации всей системы с итерационным наращиванием функционала, т.е. постепенным добавлением нового. У данной модели ЖЦ есть и другое определение. Когда говорят о структуре жизненного цикла, то модель называют итеративной (iterative). Инкрементальной же модель ЖЦ называют, имея в виду процесс наращивания функциональности продукта.
Инкрементный подход в моделировании предложил Б. Боэм как усовершенствование каскадной модели. При данном подходе разработка ведется от версии к версии и ориентир делается на некоторую законченность каждой промежуточной версии: каждая версия должна быть рабочей. Первая версия системы реализует часть требований, в следующей версии добавляют дополнительные требования, так реализуется принцип инкремента, и так до тех пор, пока не будут реализованы все задачи. Для каждой промежуточной версии на этапах жизненного цикла выполняются необходимые процессы, такие, как анализ требований и создание новой архитектуры.
Первый инкремент реализует базовую версию продукта, включающую основные требования. Следующий инкремент включает в себя некоторую модификацию базового продукта, содержащую дополнительные характеристики и функциональность (рис. 9). Каждый инкремент проектируется независимо от другого, и по мере готовности может быть передан заказчику и внедрен в эксплуатацию. Благодаря этому реализуется одно из преимуществ разработки проекта на основе инкрементной модели жизненного цикла.
Рисунок 9 – Инкрементная модель ЖЦ ПС
Преимущества инкрементной модели:
- заказчику не обязательно сразу вкладывать большие средства и оплачивать разработку всей программной системы;
- каждая промежуточная версия является законченным продуктом;
- после ввода в эксплуатацию уже первой версии продукта можно получить отзыв от пользователей и внести изменения в техническое задание, что снижает риск создать невостребованный продукт;
- в ходе выполнения проекта существует возможность поддерживать постоянный прогресс;
- если при разработке архитектуры была допущена ошибка, то ее исправление обойдется дешевле, чем при использовании модели «водопад».
Недостатки инкрементной модели:
- требует повышенного внимания при планировании проектирования;
- устранение проблемы в одной версии продукта может повлечь за собой исправления во всех последующих версиях;
- может возникнуть ситуация с откладыванием решения трудной проблемы на неопределенный срок.
Инкрементную модель, как правило, применяют при разработке сложных и комплексных систем и в тех случаях, когда необходимо реализовать часть возможностей системы за счет промежуточной версии или когда необходимо получить обратную связь от пользователей за счет быстрого ввода продукта в эксплуатацию.
2.6. Спиральная модель
Спиральная модель (Spiral model) – классический пример применения эволюционной стратегии конструирования. Модель, предложенную Барри Боэмом, начали использовать с 1988 года. В спиральной модели сохранены лучшие свойства классического жизненного цикла и добавлен новый элемент – анализ рисков, которому уделяется большое внимание.
Боэм сформулировал десять наиболее распространённых рисков, среди них: дефицит специалистов, нереалистичные сроки и бюджет, разработка неправильного пользовательского интерфейса, недостаточная производительность получаемой системы и др. [12].
Спиральная модель представлена в виде четырех процессов, каждый из которых является отдельным этапом разработки:
- планирование – определение целей;
- анализ рисков;
- разработка и тестирование;
- планирование следующей итерации.
В спиральной модели жизненный путь продукта начинается на этапе планирования и раскручивается витками по спирали. В каждом витке (цикле) новая стадия разработки основывается на предыдущей стадии, а сам процесс разработки усложняется. На выходе из каждого последующего витка получается все более полная версия ПС (рис. 10).
Рисунок 10 – Спиральная модель ЖЦ ПС
Преимущества спиральной модели:
- разделение проекта на части;
- гибкое проектирование;
- большое внимание уделяется проработке рисков на каждом витке разработки;
- обратная связь при взаимодействии с пользователями позволяет лучше анализировать риски, а также оценивать уже готовые результаты.
Недостатки спиральной модели:
- значительная длительность разработки, а вместе с тем и дороговизна
проекта;
- ответная реакция заказчика на созданную версию может спровоцировать новый цикл на начальном этапе разработки, при этом возрастает риск застрять на данном этапе, совершенствуя первую версию до бесконечности, и не продвинуться к окончанию работы над проектом.
Модель спирального процесса разработки является наиболее распространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework).
Эта модель часто используется в больших, сложных и долгосрочных проектах, при разработке серии программных систем и там, где высоки риски.