ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 807
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
3.7. Виды моделей ЖЦ ПС и технологии создания
программных систем
3.7.1. Каскадная модель (классический жизненный цикл)
Эта модель обязана своим появлением У. Ройсу (1970 г.) [16]. Мо- дель имеет и другое название – водопад (waterfall). Особенность модели
– переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии, возвра- тов на пройденные стадии не предусматривается (рис. 3.4).
Требования к разрабатываемой ПС, определенные на стадиях фор- мирования и анализа, строго документируются в виде ТЗ и фиксируют- ся на все время разработки проекта. Каждая стадия завершается выпус- ком полного комплекта документации (ТЗ, ЭП, ТП, РП), достаточной для того, чтобы разработка могла быть продолжена другой командой
98 разработчиков. Критерием качества разработки при таком подходе яв- ляется точность выполнения спецификаций ТЗ. Основное внимание разработчиков сосредоточивается на достижении оптимальных значе- ний технических характеристик разрабатываемой ПС – производитель- ности, объема занимаемой памяти и др.
Рис. 3.4. Каскадная модель ЖЦ ПС
Преимущества каскадной модели: на каждой стадии формируется законченный набор проектной доку- ментации, отвечающей критериям полноты и согласованности; выполняемые в логической последовательности стадии работ позво- ляют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении
ПС, для которых в самом начале проекта можно полно и четко сформу- лировать все требования. Такие проекты характерны для организаций государственного управления, министерств и ведомств, например, ми- нистерства обороны и т.п. Пока все это контролируется стандартами и различными комиссиями госприемки, схема работает хорошо. Приме- нить такой подход при создания проектов ПС для коммерческий орга- низаций не эффективно. Именно здесь проявляются его недостатки: выявление и устранение ошибок производится только на стадии тес- тирования, которое может существенно растянуться; реальные проекты часто требуют отклонения от стандартной после- довательности шагов; цикл основан на точной формулировке исходных требований к ПС, реально в начале проекта требования заказчика определены лишь частично; результаты работ доступны заказчику только по завершению проек- та.
3.7.2. Итерационная модель ЖЦ ПС
С ростом коммерческих проектов выяснилось, что не всегда удается детально проработать проект будущей системы, поскольку многие ас-
99 пекты ее функционирования в динамических сферах деятельности
(бизнес) меняются, пока система создается. Потребовалось изменить процесс разработки так, чтобы гарантировать внесение необходимых исправлений после завершения какого-либо этапа разработки. Так поя- вилась итерационная модель ЖЦ ПС, называемая моделью с промежу- точным контролем или моделью с циклическим повторением фаз [6,7,9].
В итерационной модели (рис. 3.5) недостатки проектирования и программирования могут быть устранены позже путем частичного воз- врата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление.
Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5 – 10 раз меньше, а стоимость выявле- ния и устранения ошибки на стадии сопровождения в 20 раз больше
(рис. 3.6). В некоторых публикациях приводятся еще более шокирую- щие результаты, как десятикратное возрастание затрат на устранение ошибок с каждым последующим этапом [25].
Рис. 3.5. Итерационная модель ЖЦ ПС
В такой ситуации огромное значение приобретает этап формули- рования требований, составление спецификаций и создание плана сис- темы. Программные архитекторы несут личную ответственность за все последующие изменения проектных решений. Объем документации исчисляется тысячами страниц, число утверждающих заседаний огром- но. Многие проекты так никогда и не покидают этап планирования, впав в “паралич анализа”. Одним из возможных путей исключения подобных ситуаций является макетирование (прототипирование).
100 3.7.3. Макетирование
Часто заказчик не может сформулировать требования по вводу, об- работке или выводу данных для будущего программного продукта. Раз- работчик может сомневаться в приспособленности продукта к операци- онной системе, в форме диалога с пользователем или эффективности алгоритма. В таких случаях целесообразно использовать макетирование
[22]. Основная цель макетирования – снять неопределенность в требо- ваниях заказчика. Макетирование (прототипирование) – процесс соз- дания модели требуемого продукта.
Рис. 3.6. Стоимость выявления и устранения ошибки на различных этапах ЖЦ ПС
Модель может принимать следующие формы: бумажный макет (рисованная схема человеко-машинного диалога) или макет на основе ПК; работающий макет, реализующий некоторую часть требуемых функций; существующая программа, характеристики которой должны быть улучшены.
Как показано на рис. 3.7, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.
Рис. 3.7. Итерационный процесс макетирования
Последовательность действий при макетировании представлена на рис. 3.8. Макетирование начинается со сбора и уточнения требований к создаваемой программной системе. Разработчик и заказчик совместно определяют цели ПО, устанавливают, какие требования известны, а ка-
101 кие предстоит доопределить. Затем выполняется быстрое проектирова- ние. В нем сосредотачиваются на характеристиках, которые должны быть видимыми пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Итерации продолжаются до тех пор, пока макет не выявит все требования заказчика и даст возможность разра- ботчику понять, что должно быть сделано.
Достоинства макетирования – возможность обеспечения определе- ния полных требований к системе. Недостатки макетирования: заказчик может принять макет за продукт; разработчик может принять макет за продукт. Следует пояснить суть недостатков.
Когда заказчик видит работающую версию ПС, он перестает созна- вать, что в погоне за работающим вариантом ПС оставлены нерешен- ными многие вопросы качества и удобства сопровождения системы.
Когда же заказчику об этом говорит разработчик, то ответом может быть возмущение и требование скорейшего превращения макета в рабо- чий продукт. Это отрицательно сказывается на управлении разработкой
ПС.
Рис. 3.8. Последовательность действий при макетировании
С другой стороны, для быстрого получения работающего макета разработчик часто идет на определенные компромиссы. Например, мо- гут использоваться не самые подходящие языки программирования или операционная система. Для простой демонстрации может применяться неэффективный (простой) алгоритм. Спустя некоторое время разработ- чик забывает о причинах, по которым эти средства не подходят. В ре- зультате далеко не идеальный выбранный вариант интегрируется в сис- тему.
Прежде чем рассматривать другие модели ЖЦ ПС, которые пришли на смену каскадной модели, следует остановиться на стратегиях конст-
102 руирования программных систем. Именно стратегия конструирования
ПС во многом определяет модель ЖЦ ПС.
3.7.4. Стратегии конструирования ПС
Существует три стратегии конструирования программных систем
[22]: однократный проход (каскадная стратегия, рассмотренная выше) – линейная последовательность этапов конструирования; инкрементная стратегия. В начале процесса определяются все поль- зовательские и системные требования, оставшаяся часть конструи- рования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система; эволюционная стратегия. Система также строится в виде последова- тельности версий, но в начале процесса определяются не все требо- вания. Требования уточняются в результате разработки версий.
Характеристики стратегий конструирования ПС в соответствии с требованиями стандарта IEEE/EIA 12207 приведены в табл. 3.1.
Таблица 3.1
Стратегии конструирования
Стратегия кон-
струирования
В начале
процесса
определены
все требова-
ния?
Множест-
во циклов
конструи-
рования?
Промежуточ-
ное ПО рас-
пространяет-
ся?
1.
Однократный про- ход
Да
Нет
Нет
2.
Инкрементная
(запланированное улучшение про- дукта)
Да
Да
Может быть
3.
Эволюционная
Нет
Да
Да
3.7.5. Инкрементная модель
Инкрементная модель является классическим примером инкре- ментной стратегии конструирования. Она объединяет элементы после- довательной водопадной модели с итерационной философией макети- рования (предложена Б.Боэмом как усовершенствование каскадной мо- дели). Каждая линейная последовательность здесь вырабатывает по- ставляемый инкремент ПС. Например, ПС для обработки слов в 1-м инкременте (версии) реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте – бо- лее сложные возможности редактирования и документирования; в 3-м
103 инкременте – проверку орфографии и грамматики; в 4-м инкременте – возможности компоновки страницы.
Первый инкремент приводит к получению базового продукта, реа- лизующего базовые требования (правда, многие вспомогательные тре- бования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность.
По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом ин- кременте работающий продукт.
Схема такой модели ЖЦ ПС приведена на рис. 3.9. Одной из современ- ных реализаций инкрементного подхода является экстремальное про- граммирование (ориентировано на очень малые приращения функцио- нальности) [22].
Рис. 3.9. Инкрементная модель ЖЦ ПС
3.7.6. Спиральная модель ЖЦ ПО
Спиральная модель – классический пример применения эволюцион- ной стратегии конструирования. Модель (автор Б.Боэм, 1988) базирует- ся на лучших свойствах классического жизненного цикла и макетирова- ния, к которым добавляется новый элемент – анализ риска, отсутст- вующий в этих парадигмах. Модель определяет четыре действия, пред- ставляемые четырьмя квадрантами спирали (рис. 3.10):
1. Планирование – определение целей, вариантов и ограничений.
2. Анализ риска – анализ вариантов и распознавание/выбор риска.
3. Конструирование – разработка продукта следующего уровня.
4. Оценивание – оценка заказчиком текущих результатов конструиро- вания.
Интегрирующий аспект спиральной модели очевиден при учете ра- диального измерения спирали. С каждой итерацией по спирали строят- ся все более полные версии ПС. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, используе- мое в квадранте конструирования.
Для дальнейшего определения проблемных и уточненных требова- ний может быть использовано моделирование. Заказчик оценивает ин-
104 женерную (конструкторскую) работу и вносит предложения по моди- фикации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть останов- лен.
В большинстве случаев движение по спирали продолжается, с каж- дым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по раз- работке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Рис. 3.10. Спиральная модель ЖЦ ПО
Эти действия пронумерованы на рис. 3.10 и имеют следующее содержа- ние:
1 – начальный сбор требований и планирование проекта;
2 – та же работа, но на основе рекомендаций заказчика;
3 – анализ риска на основе начальных требований;
4 – анализ риска на основе реакции заказчика;
5 – переход к комплексной системе;
6 – начальный макет системы;
7 – следующий уровень макета;
8 – сконструированная система;
9 – оценивание заказчиком.
Достоинства спиральной модели:
1) наиболее реально (в виде эволюции) отображает разработку про- граммного обеспечения;
2) позволяет явно учитывать риск на каждом витке эволюции разработ- ки;
3) включает шаг системного подхода в итерационную структуру разра- ботки;
105 4) использует моделирование для уменьшения риска и совершенство- вания программного изделия.
Недостатки спиральной модели:
1) сравнительная новизна (отсутствует достаточная статистика эффек- тивности модели);
2) повышенные требования к заказчику;
3) трудности контроля и управления временем разработки.
Модель спирального процесса разработки является наиболее рас- пространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF
(Microsoft Solution Framework). В качестве языка моделирования ис- пользуется язык UML (Unified Modeling Language). Создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточняя характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируется только то, что можно предвидеть, разрабатывается то, что запланирова- но, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы [25].
Однако для этого нужны очень большие средства. Действительно, если раньше можно было создавать и распускать группы специалистов по мере необходимости, то теперь все они должны постоянно участво- вать в проекте: архитекторы, программисты, тестировщики, инструкто- ры и т. д. Более того, усилия различных групп должны быть синхрони- зированы, чтобы своевременно отражать проектные решения и вносить необходимые изменения.
3.7.7. Рациональный унифицированный процесс
Рациональный унифицированный процесс – (Rational Unified Process,
RUP) – одна из лучших методологий разработки программного обеспе- чения. Основываясь на опыте многих успешных программных проектов,
RUP позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки [10]. Предпосылки для разра- ботки RUP зародились в начале 1980-х гг. в Rational Software corporation. В начале 2003 г. Rational приобрела IBM. Одним из основ- ных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).
RUP – одна из спиральных методологий разработки программного обеспечения. Методология поддерживается и развивается компанией
Rational Software. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная и инкрементная разработка программного обеспечения в RUP предпола- гает разделение проекта на несколько проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набо- ром целей, которые должны быть достигнуты в конце итерации. Конеч- ная итерация предполагает, что набор целей итерации должен в точно-
программных систем
3.7.1. Каскадная модель (классический жизненный цикл)
Эта модель обязана своим появлением У. Ройсу (1970 г.) [16]. Мо- дель имеет и другое название – водопад (waterfall). Особенность модели
– переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии, возвра- тов на пройденные стадии не предусматривается (рис. 3.4).
Требования к разрабатываемой ПС, определенные на стадиях фор- мирования и анализа, строго документируются в виде ТЗ и фиксируют- ся на все время разработки проекта. Каждая стадия завершается выпус- ком полного комплекта документации (ТЗ, ЭП, ТП, РП), достаточной для того, чтобы разработка могла быть продолжена другой командой
98 разработчиков. Критерием качества разработки при таком подходе яв- ляется точность выполнения спецификаций ТЗ. Основное внимание разработчиков сосредоточивается на достижении оптимальных значе- ний технических характеристик разрабатываемой ПС – производитель- ности, объема занимаемой памяти и др.
Рис. 3.4. Каскадная модель ЖЦ ПС
Преимущества каскадной модели: на каждой стадии формируется законченный набор проектной доку- ментации, отвечающей критериям полноты и согласованности; выполняемые в логической последовательности стадии работ позво- ляют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении
ПС, для которых в самом начале проекта можно полно и четко сформу- лировать все требования. Такие проекты характерны для организаций государственного управления, министерств и ведомств, например, ми- нистерства обороны и т.п. Пока все это контролируется стандартами и различными комиссиями госприемки, схема работает хорошо. Приме- нить такой подход при создания проектов ПС для коммерческий орга- низаций не эффективно. Именно здесь проявляются его недостатки: выявление и устранение ошибок производится только на стадии тес- тирования, которое может существенно растянуться; реальные проекты часто требуют отклонения от стандартной после- довательности шагов; цикл основан на точной формулировке исходных требований к ПС, реально в начале проекта требования заказчика определены лишь частично; результаты работ доступны заказчику только по завершению проек- та.
3.7.2. Итерационная модель ЖЦ ПС
С ростом коммерческих проектов выяснилось, что не всегда удается детально проработать проект будущей системы, поскольку многие ас-
99 пекты ее функционирования в динамических сферах деятельности
(бизнес) меняются, пока система создается. Потребовалось изменить процесс разработки так, чтобы гарантировать внесение необходимых исправлений после завершения какого-либо этапа разработки. Так поя- вилась итерационная модель ЖЦ ПС, называемая моделью с промежу- точным контролем или моделью с циклическим повторением фаз [6,7,9].
В итерационной модели (рис. 3.5) недостатки проектирования и программирования могут быть устранены позже путем частичного воз- врата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление.
Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5 – 10 раз меньше, а стоимость выявле- ния и устранения ошибки на стадии сопровождения в 20 раз больше
(рис. 3.6). В некоторых публикациях приводятся еще более шокирую- щие результаты, как десятикратное возрастание затрат на устранение ошибок с каждым последующим этапом [25].
Рис. 3.5. Итерационная модель ЖЦ ПС
В такой ситуации огромное значение приобретает этап формули- рования требований, составление спецификаций и создание плана сис- темы. Программные архитекторы несут личную ответственность за все последующие изменения проектных решений. Объем документации исчисляется тысячами страниц, число утверждающих заседаний огром- но. Многие проекты так никогда и не покидают этап планирования, впав в “паралич анализа”. Одним из возможных путей исключения подобных ситуаций является макетирование (прототипирование).
100 3.7.3. Макетирование
Часто заказчик не может сформулировать требования по вводу, об- работке или выводу данных для будущего программного продукта. Раз- работчик может сомневаться в приспособленности продукта к операци- онной системе, в форме диалога с пользователем или эффективности алгоритма. В таких случаях целесообразно использовать макетирование
[22]. Основная цель макетирования – снять неопределенность в требо- ваниях заказчика. Макетирование (прототипирование) – процесс соз- дания модели требуемого продукта.
Рис. 3.6. Стоимость выявления и устранения ошибки на различных этапах ЖЦ ПС
Модель может принимать следующие формы: бумажный макет (рисованная схема человеко-машинного диалога) или макет на основе ПК; работающий макет, реализующий некоторую часть требуемых функций; существующая программа, характеристики которой должны быть улучшены.
Как показано на рис. 3.7, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.
Рис. 3.7. Итерационный процесс макетирования
Последовательность действий при макетировании представлена на рис. 3.8. Макетирование начинается со сбора и уточнения требований к создаваемой программной системе. Разработчик и заказчик совместно определяют цели ПО, устанавливают, какие требования известны, а ка-
101 кие предстоит доопределить. Затем выполняется быстрое проектирова- ние. В нем сосредотачиваются на характеристиках, которые должны быть видимыми пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Итерации продолжаются до тех пор, пока макет не выявит все требования заказчика и даст возможность разра- ботчику понять, что должно быть сделано.
Достоинства макетирования – возможность обеспечения определе- ния полных требований к системе. Недостатки макетирования: заказчик может принять макет за продукт; разработчик может принять макет за продукт. Следует пояснить суть недостатков.
Когда заказчик видит работающую версию ПС, он перестает созна- вать, что в погоне за работающим вариантом ПС оставлены нерешен- ными многие вопросы качества и удобства сопровождения системы.
Когда же заказчику об этом говорит разработчик, то ответом может быть возмущение и требование скорейшего превращения макета в рабо- чий продукт. Это отрицательно сказывается на управлении разработкой
ПС.
Рис. 3.8. Последовательность действий при макетировании
С другой стороны, для быстрого получения работающего макета разработчик часто идет на определенные компромиссы. Например, мо- гут использоваться не самые подходящие языки программирования или операционная система. Для простой демонстрации может применяться неэффективный (простой) алгоритм. Спустя некоторое время разработ- чик забывает о причинах, по которым эти средства не подходят. В ре- зультате далеко не идеальный выбранный вариант интегрируется в сис- тему.
Прежде чем рассматривать другие модели ЖЦ ПС, которые пришли на смену каскадной модели, следует остановиться на стратегиях конст-
102 руирования программных систем. Именно стратегия конструирования
ПС во многом определяет модель ЖЦ ПС.
3.7.4. Стратегии конструирования ПС
Существует три стратегии конструирования программных систем
[22]: однократный проход (каскадная стратегия, рассмотренная выше) – линейная последовательность этапов конструирования; инкрементная стратегия. В начале процесса определяются все поль- зовательские и системные требования, оставшаяся часть конструи- рования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система; эволюционная стратегия. Система также строится в виде последова- тельности версий, но в начале процесса определяются не все требо- вания. Требования уточняются в результате разработки версий.
Характеристики стратегий конструирования ПС в соответствии с требованиями стандарта IEEE/EIA 12207 приведены в табл. 3.1.
Таблица 3.1
Стратегии конструирования
Стратегия кон-
струирования
В начале
процесса
определены
все требова-
ния?
Множест-
во циклов
конструи-
рования?
Промежуточ-
ное ПО рас-
пространяет-
ся?
1.
Однократный про- ход
Да
Нет
Нет
2.
Инкрементная
(запланированное улучшение про- дукта)
Да
Да
Может быть
3.
Эволюционная
Нет
Да
Да
3.7.5. Инкрементная модель
Инкрементная модель является классическим примером инкре- ментной стратегии конструирования. Она объединяет элементы после- довательной водопадной модели с итерационной философией макети- рования (предложена Б.Боэмом как усовершенствование каскадной мо- дели). Каждая линейная последовательность здесь вырабатывает по- ставляемый инкремент ПС. Например, ПС для обработки слов в 1-м инкременте (версии) реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте – бо- лее сложные возможности редактирования и документирования; в 3-м
103 инкременте – проверку орфографии и грамматики; в 4-м инкременте – возможности компоновки страницы.
Первый инкремент приводит к получению базового продукта, реа- лизующего базовые требования (правда, многие вспомогательные тре- бования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность.
По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом ин- кременте работающий продукт.
Схема такой модели ЖЦ ПС приведена на рис. 3.9. Одной из современ- ных реализаций инкрементного подхода является экстремальное про- граммирование (ориентировано на очень малые приращения функцио- нальности) [22].
Рис. 3.9. Инкрементная модель ЖЦ ПС
3.7.6. Спиральная модель ЖЦ ПО
Спиральная модель – классический пример применения эволюцион- ной стратегии конструирования. Модель (автор Б.Боэм, 1988) базирует- ся на лучших свойствах классического жизненного цикла и макетирова- ния, к которым добавляется новый элемент – анализ риска, отсутст- вующий в этих парадигмах. Модель определяет четыре действия, пред- ставляемые четырьмя квадрантами спирали (рис. 3.10):
1. Планирование – определение целей, вариантов и ограничений.
2. Анализ риска – анализ вариантов и распознавание/выбор риска.
3. Конструирование – разработка продукта следующего уровня.
4. Оценивание – оценка заказчиком текущих результатов конструиро- вания.
Интегрирующий аспект спиральной модели очевиден при учете ра- диального измерения спирали. С каждой итерацией по спирали строят- ся все более полные версии ПС. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, используе- мое в квадранте конструирования.
Для дальнейшего определения проблемных и уточненных требова- ний может быть использовано моделирование. Заказчик оценивает ин-
104 женерную (конструкторскую) работу и вносит предложения по моди- фикации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть останов- лен.
В большинстве случаев движение по спирали продолжается, с каж- дым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по раз- работке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Рис. 3.10. Спиральная модель ЖЦ ПО
Эти действия пронумерованы на рис. 3.10 и имеют следующее содержа- ние:
1 – начальный сбор требований и планирование проекта;
2 – та же работа, но на основе рекомендаций заказчика;
3 – анализ риска на основе начальных требований;
4 – анализ риска на основе реакции заказчика;
5 – переход к комплексной системе;
6 – начальный макет системы;
7 – следующий уровень макета;
8 – сконструированная система;
9 – оценивание заказчиком.
Достоинства спиральной модели:
1) наиболее реально (в виде эволюции) отображает разработку про- граммного обеспечения;
2) позволяет явно учитывать риск на каждом витке эволюции разработ- ки;
3) включает шаг системного подхода в итерационную структуру разра- ботки;
105 4) использует моделирование для уменьшения риска и совершенство- вания программного изделия.
Недостатки спиральной модели:
1) сравнительная новизна (отсутствует достаточная статистика эффек- тивности модели);
2) повышенные требования к заказчику;
3) трудности контроля и управления временем разработки.
Модель спирального процесса разработки является наиболее рас- пространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF
(Microsoft Solution Framework). В качестве языка моделирования ис- пользуется язык UML (Unified Modeling Language). Создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточняя характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируется только то, что можно предвидеть, разрабатывается то, что запланирова- но, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы [25].
Однако для этого нужны очень большие средства. Действительно, если раньше можно было создавать и распускать группы специалистов по мере необходимости, то теперь все они должны постоянно участво- вать в проекте: архитекторы, программисты, тестировщики, инструкто- ры и т. д. Более того, усилия различных групп должны быть синхрони- зированы, чтобы своевременно отражать проектные решения и вносить необходимые изменения.
3.7.7. Рациональный унифицированный процесс
Рациональный унифицированный процесс – (Rational Unified Process,
RUP) – одна из лучших методологий разработки программного обеспе- чения. Основываясь на опыте многих успешных программных проектов,
RUP позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки [10]. Предпосылки для разра- ботки RUP зародились в начале 1980-х гг. в Rational Software corporation. В начале 2003 г. Rational приобрела IBM. Одним из основ- ных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).
RUP – одна из спиральных методологий разработки программного обеспечения. Методология поддерживается и развивается компанией
Rational Software. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная и инкрементная разработка программного обеспечения в RUP предпола- гает разделение проекта на несколько проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набо- ром целей, которые должны быть достигнуты в конце итерации. Конеч- ная итерация предполагает, что набор целей итерации должен в точно-