Unified Process

Unified Process (англ. унифицированный процесс) — методология для построения процессов разработки программного обеспечения, позволяющий команде разработки преобразовывать требования заказчика в работоспособный продукт. В зависимости от требований и доступных ресурсов, процесс разработки может быть адаптирован путём включения или исключения определённых проектных активностей. Примером методологии разработки, основанной на Unified Process, является Rational Unified Process (RUP), который содержит ряд активностей, не описанных в более общем фреймворке, но представляющих ценность для определённого типа проектов^[1].

Unified Process активно использует унифицированный язык моделирования (UML). В ядре UML лежит модель, которая позволяет команде разработки в упрощённом виде понять многообразие сложных процессов, необходимых для разработки программного обеспечения. Различные модели, используемые в Unified Process, позволяют визуализировать систему, описать её структуру и поведение, задокументировать принимаемые в процессе разработки решения^[1].

История возникновенияПравить

Истоки фреймворка лежат в работах сотрудника Ericsson Ивара Якобсона, опубликованных в конце 1960-х годов. Якобсон и его коллеги моделировали огромные телекоммуникационные системы с использованием слоёв «блоков» (того, что позднее стало называться «компонентами»): нижние слои служили основанием для подсистем из верхних слоёв. Команда строила нижние блоки путём рассмотрения «дорожных происшествий» (англ. traffic cases), которые могли произойти с пользователями системы. Именно эти «происшествия» стали прообразом сценариев использования (англ. use cases), вошедших позднее в состав UML^[2]. Работы Якобсона также послужили толчком для создания диаграмм, используемых в UML, включая диаграммы деятельности и последовательности.

В 1987 году Якобсон основал собственную компанию Objectory AB и совместно с партнёрами провёл несколько лет, разрабатывая проект и продукт под названием Objectory. В 1995 году Якобсон публикует книгу «Object-Oriented Software Engineering», описывающую процесс разработки, движущей силой которого являются требования клиента, трансформируемые в конечный продукт с помощью сценариев использования. Выход книги совпал с первой публикацией онлайн-версии ядра Unified Process.

В 1995 году компанию Objectory AB поглощает корпорация Rational. С помощью значительно возросшего количества коллег, Якобсон приступает к расширению процесса Objectory, дополняя его инструментами для управления проектами и разработки. Наряду с Гради Бучем и Джеймсом Рамбо, работавшими в Rational ранее, Якобсон становится участником группы «трёх амиго»^[3]^[4], возглавивших работы по созданию процесса, получившего название Rational Objectory Process (ROP), а также распространению Unified Process, ставшего основой для Unified Modelling Language.

В процессе работы над ROP и UML, корпорация Rational продолжала слияния и поглощения компаний, занимающихся созданием инструментов для разработки программного обеспечения. Эти инструменты обеспечили возможность управления требованиями («RequisitePro»), общего тестирования («SQA»), тестирования производительности, управления конфигурациями и управления изменениями. В 1998 году Rational изменяет название продукта на RUP, концептуальным ядром которого остаётся Unified Process.

ХарактеристикиПравить

Unified Process основан на сценариях использования, описывающих одно или несколько действующих лиц, взаимодействующих с системой и получающих результаты, представляющие ценность для участников процесса. Именно сценарии использования являются основной движущей силой, управляющей всем процессом разработки, начиная со сбора и обсуждения требований, и заканчивая анализом, дизайном и имплементацией. Сценарии использования описываются простым и понятным языком, так, чтобы быть понятным стороннему читателю.

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

Третьим фундаментальным принципом Unified Process является использование итеративного и инкрементного подхода. Итерациями называются миниатюрные проекты, которые позволяют запустить более новую версию системы. Результат итерации, изменения, внесённые в систему, называются инкрементом. В частности, итеративный подход позволяет последовательно улучшать архитектуру системы, обрабатывать постоянные изменения требований, гибко подстраивать план всего проекта. Приверженность принципу непрерывной интеграции позволяет выявлять возможные проблемы на ранней стадии. Помимо этого, итеративность помогает минимизировать риски, связанные с техническими ограничениями, архитектурой и изменяющимися требованиями^[5].

Фазы разработкиПравить

Относительный размер фаз разработки для типичного проекта

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

Начальная фаза (англ. Inception) позволяет очертить границы системы, определить предполагаемую архитектуру, выявить критические риски и принять решения относительно старта проекта, в зависимости от предположительных оценок его стоимости, вложенных усилий, расписания и качества продукта. С этой фазой связана важная веха проекта под названием «Цели жизненного цикла».

Фаза подготовки (англ. Elaboration) создана для решения следующих задач: выяснение большинства функциональных требований; преобразование предполагаемой архитектуры в работающий прототип, сфокусированный на архитектуре; устранение критических рисков; принятие окончательного решения о начале проекта и создание достаточно детального плана. Завершает эту фазу веха под названием «Архитектура жизненного цикла».

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

Передача (англ. Transition) полностью функционирующей системы пользователям является завершающей фазой цикла разработки. Вехой для неё считается выпуск продукта^[6].

Разновидности рабочего процессаПравить

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

Каждый процесс представляет собой набор работ, выполняемых различными членами проектной команды. Так, целью процессов по сбору требований является создание модели сценариев использования, позволяющих выявить основные функциональные требования к системе. Процессы анализа и соответствующая модель позволяет разработчикам структурировать функциональные требования; процесс дизайна описывает физическую реализацию сценариев использования, и является абстракцией для следующей модели. Процесс и модель имплементации описывают, как элементы дизайна соотносятся с компонентами программного обеспечения, включающими исходный код, динамические библиотеки и пр. Последняя из моделей, описывающая тестирование, поясняет, какие системные тесты и юнит-тесты и как должна выполнять команда разработки^[7].

Итерации и инкрементыПравить

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

В ходе работы над итерацией команда разработки выполняет следующие шаги:

Устраняет критические риски перед началом работ.
Создаёт план итерации с нужной степенью детализации.
Выполняет планируемые работы.
Производит анализ полученного инкремента.
Обновляет список рисков.
Обновляет план проекта в соответствии с результатами итерации.
Приступает к следующей итерации^[8].

Артефакты, исполнители и активностиПравить

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

Под исполнителем понимается роль, которую отдельный работник может исполнять на проекте. Разница между исполнителем и действующим лицом (из сценариев использования) заключается в том, что последний смотрит на систему «снаружи», в то время как исполнитель — «изнутри». Исполнители создают артефакты, самостоятельно или в группах или командах. Важно помнить, что один и тот же человек может выступать на проекте в нескольких ролях: например, аналитик может также выявлять сценарии использования и описывать их.

Каждая из разновидностей рабочего процесса включает в себя несколько активностей — задач, над которыми работают исполнители с целью получения артефактов^[9].

Реализации Unified ProcessПравить

Unified Process лежит в основе ряда методологий по разработке программного обеспечения, среди которых^[10]:

ПримечанияПравить

↑ ¹ ² Scott, 2001, с. 1.
↑ Frost, Hellstrom, 2006, с. 20.
↑ Frost, Hellstrom, 2006, с. 18.
↑ Scott, 2001, с. 3.
↑ Scott, 2001, с. 3-10.
↑ Scott, 2001, с. 10-13.
↑ Scott, 2001, с. 13-16.
↑ Scott, 2001, с. 16-17.
↑ Scott, 2001, с. 17-18.
↑ History of the Unified Process (неопр.). enterpriseunifiedprocess.com. Дата обращения: 21 декабря 2016. Архивировано 16 декабря 2016 года.

ЛитератураПравить

Jens Frost, Tomas Hellström. Återanvändbara Use Cases inom telekomindustrin (швед.). — 2006. — С. 57.
Kendall Scott. Overview // Unified Process Explained, The. — 1st edition. — Addison-Wesley Professional, 2001. — 208 с. — ISBN 0-201-74204-7.

[_2b4d733985c2b9c4-1] ¹ ² Scott, 2001, с. 1.

[_73f53c3f88221347-2] Frost, Hellstrom, 2006, с. 20.

[_73f53d3f88221512-3] Frost, Hellstrom, 2006, с. 18.

[_2b4d733985c2b9c6-4] Scott, 2001, с. 3.

[_06c546c046d79264-5] Scott, 2001, с. 3-10.

[_5d0d38a8fc7c9f4d-6] Scott, 2001, с. 10-13.

[_77a61fa90bb9a695-7] Scott, 2001, с. 13-16.

[_4c5d62a8f33739ef-8] Scott, 2001, с. 16-17.

[_555203a8f85f64b7-9] Scott, 2001, с. 17-18.

[10] History of the Unified Process (неопр.). enterpriseunifiedprocess.com. Дата обращения: 21 декабря 2016. Архивировано 16 декабря 2016 года.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]