Единый процесс

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

Унифицированный процесс разработки программного обеспечения или унифицированный процесс представляет собой итеративную и поэтапную структуру процесса разработки программного обеспечения . Наиболее известным и широко документированным усовершенствованием унифицированного процесса является рациональный унифицированный процесс (RUP). Другими примерами являются OpenUP и гибкий унифицированный процесс .

Обзор

Унифицированный процесс — это не просто процесс, а скорее расширяемая структура, которую следует настраивать для конкретных организаций или проектов. Рациональный унифицированный процесс также представляет собой настраиваемую структуру. В результате часто невозможно сказать, была ли усовершенствованная версия процесса получена из UP или из RUP, и поэтому имена, как правило, используются как взаимозаменяемые.

Название «унифицированный процесс» в отличие от «рационального унифицированного процесса» обычно используется для описания общего процесса, включая те элементы, которые являются общими для большинства усовершенствований. Имя унифицированного процесса также используется во избежание потенциальных проблем, связанных с нарушением прав на товарный знак, поскольку Rational Unified Process и RUP являются товарными знаками IBM . Первая книга, описывающая этот процесс, называлась «Унифицированный процесс разработки программного обеспечения» (англ. ISBN   0-201-57169-2 ) и опубликовано в 1999 году Иваром Джейкобсоном , Грэди Бучом и Джеймсом Рамбо . С тех пор различные авторы, не связанные с Rational Software, опубликовали книги и статьи, используя название Unified Process , тогда как авторы, связанные с Rational Software, отдали предпочтение названию Rational Unified Process .

В 2012 году была выпущена дисциплинированная гибкая среда доставки — гибридная структура, которая принимает и расширяет стратегии унифицированного процесса, Scrum , экстремального программирования и других методов.

Унифицированные характеристики процесса

Итеративный и инкрементный

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

Унифицированный процесс — это итеративный и поэтапный процесс разработки. Фазы разработки, построения и перехода разделены на серию итераций с временными рамками . (Начальная фаза также может быть разделена на итерации для большого проекта.) Каждая итерация приводит к созданию приращения , которое представляет собой выпуск системы, содержащий добавленные или улучшенные функциональные возможности по сравнению с предыдущим выпуском.

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

Архитектурно-ориентированный

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

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

Риск-ориентированный

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

Вариант использования

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

Жизненный цикл проекта (фазы единого процесса)

Единый процесс делит проект на четыре этапа:

• Зарождение
• Разработка (веха)
• Строительство (релиз)
• Переход (окончательная производственная версия)

Каждая фаза обычно содержит несколько итераций (названных I1, E1, E2, C1 и т. д. на иллюстрации фазы UP). Точное количество итераций на каждом этапе зависит от масштаба и характера проекта. Иллюстрация фазы UP здесь содержит ровно 1, 2, 4 и 2 итерации в четырех фазах, но это всего лишь пример того, как может выглядеть конкретный проект.

Начальный этап

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

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

Этап разработки

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

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

Конечным результатом этапа разработки является план (включая смету стоимости и графика) этапа строительства. На этом этапе план должен быть точным и заслуживающим доверия, поскольку он должен быть основан на опыте этапа разработки и поскольку на этапе разработки должны быть учтены значительные факторы риска.

Этап строительства

Строительство – самый крупный этап проекта. На этом этапе остальная часть системы строится на фундаменте, заложенном в процессе разработки. Функции системы реализуются в виде серии коротких, ограниченных по времени итераций. Каждая итерация приводит к созданию исполняемой версии программного обеспечения. На этапе построения принято писать полнотекстовые варианты использования, и каждый из них становится началом новой итерации. Диаграммы общего унифицированного языка моделирования (UML), используемые на этом этапе, включают диаграммы действий , диаграммы последовательности , диаграммы сотрудничества , диаграммы перехода состояний и диаграммы обзора взаимодействия . Выполняется итеративная реализация для снижения рисков и упрощения элементов. Последним результатом этапа строительства является программное обеспечение, готовое к развертыванию на переходном этапе.

Переходный этап

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

Уточнения и вариации

Уточнения единого процесса отличаются друг от друга тем, как они классифицируют дисциплины проекта или рабочие процессы . Рациональный унифицированный процесс определяет девять дисциплин: бизнес-моделирование , требования , анализ и проектирование , внедрение , тестирование , развертывание , конфигурацией и управление изменениями , управление проектами и среда . Унифицированный корпоративный процесс расширяет RUP за счет добавления восьми «корпоративных» дисциплин. Гибкие усовершенствования UP, такие как OpenUP/Basic и гибкий унифицированный процесс, упрощают RUP за счет сокращения количества дисциплин.

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

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

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

• Гибкий унифицированный процесс (AUP), облегченный вариант, разработанный Скоттом В. Эмблером.
• Базовый унифицированный процесс (BUP), облегченный вариант, разработанный IBM и предшественник OpenUP.
• Унифицированный процесс предприятия (EUP), расширение рационального унифицированного процесса
• Essential унифицированный процесс (EssUP), облегченный вариант, разработанный Иваром Джейкобсоном.
• Открытый унифицированный процесс (OpenUP), процесс разработки программного обеспечения Eclipse Process Framework.
• Унифицированный процесс Rational (RUP), IBM / Rational Software. процесс разработки
• Унифицированный метод Oracle (OUM), Oracle . процесс разработки и внедрения
• Rational Unified Process-System Engineering (RUP-SE), версия RUP, адаптированная Rational Software for System Engineering.

Ссылки

• Кролл, Пер; Крухтен, Филипп (2003). Rational Unified Process стал проще: практическое руководство по RUP . ISBN   0-321-16609-4 .
• Крухтен, Филипп (2004). Rational Unified Process: Введение (3-е изд.). ISBN   0-321-19770-4 .
• Эмблер, Скотт (2002). Гибкое моделирование: эффективные практики экстремального программирования и унифицированного процесса . Дж. Уайли. ISBN  0-471-20282-7 .
• Скотт, Кендалл (2002). Объяснение единого процесса . ISBN   0-201-74204-7 .
• Бергстрем, Стефан; Раберг, Лотта (2004). Внедрение Rational Unified Process: успех с RUP . ISBN   0-321-20294-5 .
• Эмблер, Скотт ; Константин, Ларри (2002). Единый переходный процесс и этапы производства . Книги КМП. ISBN  1-57820-092-Х .
• Ларман, Крейг (2004). Гибкая и итеративная разработка: Руководство для менеджера . ISBN   0-13-111155-8 .