Фазы, итерации и циклы разработки
Фаза (phase) - это промежуток времени между двумя важными опорными точками процесса, в которых должны быть достигнутычетко определенные цели, подготовлены те или иные артефакты и принято решение о том, следует ли переходить к следующей фазе. Рациональный Унифицированный Процесс состоит из следующих четырех фаз:
-Начало (inception) – определение целей проекта. На этой стадии определяются цели системы и устанавливаются рамки проекта. Анализ целей включает выработку критерия успешности, оценку рисков, необходимых ресурсов и составление плана, в котором отражены основные опорные точки. Нередко создается исполняемый прототип, демонстрирующий реалистичность концепции. В конце начальной фазы еще раз подвергается внимательному изучению весь жизненный цикл проекта и принимается решение, стоит ли начинать полномасштабную разработку.
- Исследование (elaboration) – разработка плана и архитектуры проекта. На данном этапе стоит задача проанализировать предметную область, выработать прочные архитектурные основы, составить план проекта и устранить наиболее опасные риски. Архитектурные решения должны приниматься тогда, когда стала ясна структура системы в целом, то есть большая часть требовании уже сформулирована. Для подтверждения правильности выбора архитектуры создается система, демонстрирующая выбранные принципы в действии и реализующая некоторые наиболее важные прецеденты. В конце фазы исследования изучаются детально расписанные пели проекта, его рамки, выбор архитектуры и методы управления основными рисками, а затем принимается решение о том, надо ли приступать к построению.
|
|
|
- Построение (construction) – постепенное создание системы. В фазе построения постепенно и итеративно разрабатывается продукт, готовый к внедрению. На этом этапе описываются оставшиеся требования и критерии приемки, проект "обрастает плотью", завершается разработка и тестирование программного комплекса. В конце фазы построения принимается решение о готовности программ, эксплуатационных площадок и пользователей к внедрению.
-Внедрение (transition) – поставка системы конечным пользователям. В фазе внедрения программное обеспечение передается пользователям. После этого часто возникают требующие дополнительной проработки вопросы по настройке системы, исправлению ошибок, ранее оставшихся незамеченными, и окончательному оформлению ряда функций, реализация которых была отложена. Обычно эта стадия воплощения проекта начинается с выпуска бета-версии системы, которая затем замещается коммерческой версией. В конце фазы внедрения делается заключение о том, достигнуты ли цели проекта и надо ли начинать новый цикл разработки. Подводятся итоги работы над проектом и извлекаются уроки, которые помогут улучшить процесс разработки в ходе работы над новым проектом.
|
|
|
Фазы начала и исследования охватывают проектные стадии жизненного цикла процесса разработки; фазы построения и внедрения относятся к производству. Внутри каждой фазы происходит несколько итераций. Итерация (iteration) представляет полный цикл разработки, от выработки требований во время анализа до реализации и тестирования. Итерация - это завершенный этап, в результате которого выпускается версия (для внутреннего или внешнего использования) исполняемого продукта, реализующая часть запланированных функций. Затем эта версия от итерации к итерации наращивается до получения готовой системы. Во время каждой итерации выполняются особые рабочие процессы, хотя в разных фазах основной упор делается на разных работах.
В начальной фазе главной задачей является выработка требований, в фазе исследования - анализ и проектирование, в фазе построения – реализация, а в фазе внедрения – развертывание.
Конечным результатом является выпуск готового продукта. Все фазы и итерации подразумевают определенные затраты усилий на снижение рисков. В конце каждой фазы находится четко определенная опорная точка, где оценивается, в какой мере достигнуты намеченные цели и не следует ли внести в процесс изменения, прежде чем двигаться дальше.
|
|
|
Прохождение через четыре основные фазы называется циклом разработки. Каждый цикл завершается генерацией версии системы. Первый проход через все четыре фазы называют начальным циклом разработки. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы: начальную, исследования, построения и внедрения. Система, таким образом, эволюционирует, поэтому все циклы, следующие за начальным, называются эволюционными.
Рабочие процессы
Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:
- моделирование процессов - описывается структура и динамика ПО в целом;
- разработка требований - описывается основанный на прецедентах метод постановки требований;
- анализ и проектирование - описываются различные виды архитектуры системы;
- реализация - собственно разработка программ, автономное тестирование и интеграция;
|
|
|
- тестирование - описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок;
- развертывание - охватывает конфигурирование поставляемой системы;
- управление конфигурацией - управление изменениями и поддержание целостности артефактов проекта;
- управление проектом - описывает разные стратегии работы с итеративным процессом;
- анализ среды - рассматриваются вопросы инфраструктуры, необходимой для разработки системы.
Внутри каждого рабочего процесса сосредоточены связанные между собой артефакты и деятельности. Напомним, что артефакт (artifact) - это некоторый документ, отчет или исполняемая программа, которые производятся, а впоследствии преобразуют или потребляются. Термином деятельность (activity) описываются задачи - обдумывание, выполнение, анализ проекта - которые решаются сотрудниками с целью создания или модификации артефактов, а также способы и рекомендации по решению; этих задач. В число таких способов могут входить и инструментальные средства, позволяющие автоматизировать решение части задач.
С некоторыми из рабочих процессов ассоциированы важные связи между артефактами.
Например, модель прецедентов, созданная в ходе выработки требований, конкретизируется в виде проектной модели, являющейся результатом процесса анализа и проектирования, воплощается в модели реализации, которая получена в процессе реализации, и верифицируется моделью тестирования из процесса тестирования.
Артефакты
В начале дадим определение: артефакт (artifact) - это диаграмма, документ, модель, закон и т. д. - нечто, описывающее определенное понятие предметной области. Теперь давайте выясним какие производственные процессы выполняются при разработке программного обеспечения, и какие артефакты при этом разрабатываются.
С каждой деятельностью в Рациональном Унифицированном Процессе связаны артефакты, которые либо подаются на вход, либо получаются на выходе. Артефакты используются как исходные данные для последующей деятельности, содержат справочные сведения о проекте или выступают в роли поставляемых по контракту составляющих.
Модели
Модели - это самый важный вид артефактов в Рациональном Унифицированном Процессе.
Модель (model) - это упрощение реальности; она создается для лучшего понимания разрабатываемой системы. В Рациональном Унифицированном Процессе имеется девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы:
- модель процессов - формализует абстракцию ПО в целом;
- модель предметной области - формализует контекст системы;
- модель прецедентов - формализует функциональные требования к системе;
- аналитическая модель (необязательная) - формализует идею проекта;
- проектная модель - формализует словарь предметной области и области решения;
- модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;
- модель развертывания - формализует топологию аппаратных средств, на которых выполняется система;
- модель реализации - описывает части, из которых собирается физическая система;
- модель тестирования - формализует способы проверки и приемки системы.
Вид - это одна из проекций модели. В Рациональном Унифицированном Процессе существует пять тесно связанных друг с другом видов системной архитектуры:
- вид с точки зрения прецедентов (use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестерами. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры;
- вид с точки зрения проектирования (design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид подчеркивает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям;
- вид с точки зрения процессов (process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы.
- вид с точки зрения реализации (implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой;
- вид с точки зрения развертывания (deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющий физическую систему.
Каждый из перечисленных видов может считаться вполне самостоятельным, так что члены группы проекта, могут сосредоточиться на изучении только тех аспектов архитектуры, которые непосредственно их касаются. Правда, нельзя забывать о том, что эти виды взаимодействуют друг с другом, что неудивительно, так как они представляют разные взгляды на одну систему. Например, узлы вида с точки зрения развертывания содержат компоненты, описанные для вида сточки зрения реализации, а те в свою очередь представляют физическое воплощение классов, интерфейсов, коопераций и активных классов из видов с точки зрения проектирования и процессов.
Другие артефакты
Артефакты в Рациональном Унифицированном Процессе подразделяются на две группы: административные и технические. Технические артефакты, в свою очередь, делятся на четыре большие подгруппы:
- группа требований - описывает, что система должна делать;
- группа проектирования - описывает, как система должна быть построена;
- группа реализации - описывает сборку разработанных программных компонентов;
- группа развертывания - содержит все данные, необходимые для конфигурирования предоставленной системы.
В группу требований включается информация о том, что система должна делать. В составе этих артефактов могут быть модели прецедентов, нефункциональных требований, предметной области и иные формы выражения потребностей пользователя, в том числе макеты, прототипы интерфейсов, юридические ограничения и т. д.
Группа проектирования содержит информацию о том, как система должна быть построена с учетом ограничений по времени и бюджету, наличия унаследованных систем, повторного использования, требований к качеству и т. д. Сюда относятся проектная модель, модель тестирования и иные формы выражения потребностей пользователя, в том числе прототипы и исполняемые архитектуры.
К группе реализации относится вся информация о программных элементах, из которых состоит система, в том числе исходный код на различных языках программирования, конфигурационные файлы, файлы данных, программные компоненты и т.д., а также информация о том, как собирать систему.
Контрольные вопросы
1. Что такое жизненный цикл программного обеспечения?
2. Как осуществляется выбор ЖЦ?
3. В чем состоит цель Рационального Унифицированного Процесса?
4. Как осуществляется определение и контроль конфигурации?
5. Перечислите основные Фазы, итерации и циклы разработки программного продукта.
6. Что представляют собой рабочие процессы?
7. Что такое артефакты?
Список литературы
1. Ашарина И.В. Основы программирования на языках С и С++.-М.: Горячая линия-Телеком, 2009.-207 с.
2. Боровский А.Н. С++ и Borland C++Builder. Самоучитель.-СПб.:Питер, 2009.-256 с.
3. Вендеров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник.-2-е изд., перераб. и доп. – М.:Финансы и статистика, 2011.-544с.:ил.
4. Грэхем И. Объектно-ориентированные методы. Принципы и практика. 3-е издание.:Пер. с англ.-М.:Издательский дом "Вильямс", 2014.-880с.:ил.-Парал.тит.англ.
5. Иванова Г.С., Ничушкина Т.Н., Пугачев Е.К. Объектно-ориентированное программирование: Учебник для вузов.-2-е изд., перераб и доп/ Под ред. Г.С.Ивановой.-М.:Изд-во МГТУ им. Н.Э.Баумана, 2013.-368 с.
6. Крячков А.В. Программирование на С и С++. Практикум [Текст]: учебное пособие для вузов/ А.В. Крячков, И.В. Сухинина и др. – СПб.: Питер, 2010. – 358 с.
7. Пол А. Объектно-ориентированное программирование на С++, 2-е изд./Пер. с англ. - СПб.; "Невский диалект" - "Издательство БИНОМ", 2009 г. - 462 с.
8. Страуструп Б. Язык программирования С++ [Текст]: учебник/ Б. Страуструп. – СПб: Питер, 2012. – 991 с.
9. Фридман А.Л. Основы объектно-ориентированного программирования на языке С++. Изд.2-е перераб. и доп. - М.: Горячая линия - Телеком, 2011. - 232с.
Учебно-методическое пособие
(курс лекций)
Михайлюк Екатерина Андреевна
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Редактор: Иванова Н.И.
Компьютерный набор: Михайлюк Е.А.
Корректор: Иванова Н.И.
Подписано в печать___________ Бумага для множительной техники
Формат _______ Усл. печ. л. ________ Тираж _____ экз. Заказ _____
Отпечатано с авторского оригинала
в отделе оперативной печати СТИ НИТУ «МИСиС»
г. Старый Оскол, м-н Макаренко, 40
Дата добавления: 2019-09-13; просмотров: 194; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!