Унифицированный процесс – это обобщённый каркас процесса создания ПП, который м.б. специализирован для широкого круга программных систем. Для разработки модели программной системы унифицированный процесс использует унифицированный язык моделирования.
начинайте вести наступлении на главные риски, ведите его непрерывно, иначе риски пойдут в наступления на вас.
обеспечьте выполнение требований заказчика: документируйте требования в виде понятном заказчику, и в ходе проектировании и реализации строго придерживайтесь этих требований
сконцентрируйтесь на выполняемой программе: работающий программный продукт, проходящий тесты лучше, чем всеобъемлющая документация
приспосабливайтесь к изменениям с самого начала проекта: современные приложения достаточно сложны, чтобы мы смогли получить конкретные требования в самом начале разработки. Поэтому необходимо закладывать архитектуру ПП таким образом, чтобы она была восприимчива к изменениям.
закладывайте основу исполняемой архитектуры как можно раньше. Исполняемая архитектура – ключевые варианты использования. Ключевой ВИ это та функциональность системы, без реализации которой ПП не имеет смысла. Ключ. ВИ составляют 7-10% от всех вариантов
стройте систему из компонентов. Приложения на основе компонентов создаются быстрее, более гибкие с точки зрении изменений, относительно низкая стоимость.
работайте как 1 команда
сделайте качество образом жизни, а не запоздалой идеей
Унифицированный процесс циклически повторяется. Эта последовательность повторений Унифицированного процесса представляет собой жизненный цикл системы. Каждый цикл завершается поставкой выпуска продукта заказчикам.
Каждый цикл состоит из четырех фаз - анализа и планирования требований, проектирования, построения и внедрения. Каждая фаза, как будет рассмотрено ниже, далее подразделяется на итерации.
В ходе фазы анализа и планирования требований хорошая идея превращается в концепцию готового продукта и создается бизнесплан разработки этого продукта. В частности, на этой фазе должны быть получены ответы на вопросы:
Что система должна делать в первую очередь для ее основных пользователей?
Как должна выглядеть архитектура системы?
Каков план и во что обойдется разработка продукта?
На этом этапе создается пробный вариант архитектуры. Обычно он представляет собой набросок, содержащий наиболее важные подсистемы. На этой фазе выявляются и расставляются по приоритетности наиболее важные риски, детально планируется фаза проектирования и грубо оценивается весь проект.
В ходе фазы проектирования детально описываются большинство вариантов использования и разрабатывается архитектура системы.
В конце фазы проектирования менеджер проекта занимается планированием действий и подсчетом ресурсов, необходимых для завершения проекта. Ключевым вопросом в этот момент будет следующий: достаточно ли проработаны варианты использования, архитектура и план и взяты ли риски под контроль настолько, чтобы можно было давать контрактные обязательства выполнить всю работу по разработке?
В ходе фазы построения происходит создание продукта - к скелету (архитектуре) добавляются мышцы (законченные программы). На этой фазе базовый уровень архитектуры разрастается до полной развитой системы. Концепции развиваются до продукта, готового к передаче пользователям. В ходе фазы объем требуемых ресурсов вырастает. В конце этой фазы продукт включает в себя все варианты использования, которые руководство и заказчик договорились включить в текущий выпуск. Правда, они могут содержать ошибки. Большинство дефектов будут обнаружены и исправлены в ходе фазы внедрения. Ключевой вопрос окончания фазы: удовлетворяет ли продукт требованиям пользователей настолько, что некоторым заказчикам можно делать предварительную поставку?
Фаза внедрения охватывает период, в ходе которого продукт существует в виде бета-выпуска или бета-версии. Небольшое число квалифицированных пользователей, работая с бета-выпуском продукта, сообщает об обнаруженных дефектах и недостатках. После этого разработчики исправляют обнаруженные ошибки и вносят некоторые из предложенных улучшений в главный выпуск, подготавливаемый для широкого распространения. Фаза внедрения включает в себя такие действия, как производство тиража, тренинг сотрудников заказчика, организацию поддержки по горячей линии и исправление дефектов, обнаруженных после поставки.
В соответствии с ГОСТ 34.601-90 «АС. Стадии создания» устанавливаются следующие стадии создания АИС, которые, в свою очередь, могут подразделяться на этапы:
· формирование требований к АИС;
· разработка концепции АИС;
· техническое задание;
· эскизный проект;
· технический проект;
· рабочая документация;
· ввод в действие.
Каждой стадии соответствует свой набор проектной документации и реализации технических и программных модулей системы. Практика показывает, что процесс создания системы носит итеративный и инкрементный характер. Это же подчеркивают авторы UML, определяя понятие унифицированного процесса разработки программного и информационного обеспечения . Хотя на первой стадии формируется набор требований к АС в целом, на самом деле он всегда в начале неполон и уточняется на последующих стадиях. Приходится делать итерации , то есть повторять отдельные этапы и стадии, либо целиком, либо частично. Кроме того, реальная система многофункциональна и сложна, поэтому обычно ее разбивают на подсистемы и отдельные комплексы задач, выделяя в них подсистемы и задачи первой очереди, второй и т.д. Система создается инкрементно , путем постепенных приращений функциональности с заменой предварительных проектных решений на более проработанные и лучше отвечающие требованиям пользователей. Это снижает финансовые риски и экономит время и расход ресурсов на последних стадиях создания.
При использовании методологии UML для создания программного и информационного обеспечения АИС предлагается построить набор взаимосвязанных моделей, отражающих статические и динамические свойства будущей системы:
· модель вариантов использования;
· модель анализа;
· модель проектирования;
· модель развертывания;
· модель реализации;
· модель тестирования.
Модель вариантов использования включает диаграммы вариантов использования и соответствующие сценарии, описывает функциональные требования к системе и ее поведение при взаимодействии с пользователями.
Модель анализа включает диаграммы обобщенных классов реализации вариантов использования на логическом уровне, соответствующие диаграммы последовательностей и/или диаграммы кооперации и является эскизной проработкой того, как будут реализованы варианты использования на логическом уровне.
Модель проектирования является детальным представлением физической реализации модели анализа и включает диаграммы пакетов (подсистем), детальные диаграммы классов, диаграммы последовательности и/или диаграммы кооперации, диаграммы состояний, диаграммы деятельности различной степени детализации.
Модель развёртывания включает предварительные диаграммы развёртывания, определяющие все конфигурации сетей, на которых может выполняться система. На диаграммах развёртывания указываются узлы сети, типы соединений, распределение активных классов системы по узлам.
Модель реализации описывает, как реализуются в виде компонентов классы проектирования. Соответственно она включает диаграммы компонентов, трассировки (реализации) классов, детальные диаграммы развёртывания, описание архитектуры системы.
Модель тестирования содержит набор тестовых примеров, процедур тестирования и описания тестовых компонент. Она задаёт способы тестирования исполняемых компонентов системы.
Сопоставим процессы построения моделей со стандартизованными стадиями создания АС. Модель вариантов использования строится на стадии формирования требований к АС; модель анализа – на стадии разработки концепции АС. На стадии технического задания и эскизного проектирования строится модель проектирования. Она уточняется на стадии технического проектирования и дополняется моделью развёртывания. На стадии рабочей документации создаются модели реализации и тестирования. Наконец, на стадии ввода в действие модель тестирования уточняется и становится в процессе эксплуатации эталонной, предназначенной для периодических проверок правильности функционирования и диагностики системы.
1.5 Компоненты языка UML
Унифицированный язык моделирования UML (Unified Modeling Language) – это язык визуального моделирования, используемый для спецификации, визуализации, конфигурирования, и документирования сложных систем (в том числе программного обеспечения) по объектно-ориентированной технологии.
При создании АС в методологии UML используются известные по методологиям Гейна/Сарсона и SADT принципы структурного системного анализа :
· нисходящая поэтапная разработка;
· диаграммная техника;
· иерархичность описаний;
· строгая формализация описания проектных решений;
· первоначальная проработка проекта на логическом уровне без деталей технической реализации;
· концептуальное моделирование в терминах предметной области для понимания проекта системы заказчиком;
· технологическая поддержка инструментальными средствами (CASE-системами).
Модель сложной системы на UML может быть исследована для получения оценочных характеристик эффективности протекания процессов в системе.
Модели развёртывания, реализации и тестирования программного и информационного обеспечения АС на UML могут быть использованы как проект приложения с последующей автоматизированной генерацией кода приложения в одной из выбранных сред программирования.
Достаточно полная модель сложной системы должна отражать два аспекта:
-статический (структурный) – состав, структура компонент и их взаимосвязи;
-динамический (поведенческий) – описание логики процессов, протекающих в системе или подлежащих реализации.
Основной способ представления моделей, принятый в UML - диаграммы, снабженные текстовой информацией, включая выражения на встроенном языке ограничений OCL, а также на языках программирования и информационных запросов, используемых для реализации системы.
Основной принцип моделирования: система моделируется как группа дискретных объектов, которые взаимодействуют друг с другом таким образом, чтобы удовлетворить требования пользователя.
В статической модели задается структура, типы объектов и отношения между объектами. В динамической модели определяется поведение объектов во времени (история объектов) и их взаимодействие.
Принципиально UML является языком дискретного моделирования, то есть в него заложена концепция дискретных событий и смены состояния. Непрерывные процессы моделируются приближенно, путем дискретизации.
Модель имеет два аспекта: семантическую информацию (семантику) и визуальное представление (нотацию).
Полный состав представлений моделей на языке UML приведён в таблице 1
Таблица 1 – Представление моделей системы на языке UML.
| МОДЕЛЬ | ДИАГРАММА | КОМПОНЕНТЫ | ||
| Концептуальный уровень Модель вариантов использования (use case model) Логический уровень Модель анализа (analysis model) Модель проектирования (design model) Физический уровень Модель развёртывания (deployment model) | Диаграмма вариантов использования (use case diagram) Диаграмма пакетов анализа (analysis package diagram) Диаграмма пакетов проектирования (design package diagram) Диаграмма классов анализа (analysis class diagram) Диаграмма классов проектирования (design class diagram) Диаграмма состояний (state chart diagram) Диаграмма деятельности (activity diagram) Диаграмма последовательности (sequence diagram) Диаграмма кооперации (collaboration diagram) Диаграмма развертывания (deployment diagram) | Вариант использования (use case) Актант (актер, actor) Ассоциация (связь, отношение, association) Роль (роль в ассоциации, role) Сценарий (scenario) Пакет (package) Пакет (package) Модель (model) Система (system) Подсистема (subsystem) Отношение зависимости (зависимость, dependency relationship) Трассировка (trace) Класс (class) Объект (object) Атрибут (свойство, attribute) Операция (operation) Отношение зависимости (зависимость, dependency relationship) Ассоциация (association) Агрегация (aggregation) Композиция (composition) Обобщение (generalization) Трассировка (trace) Реализация (realization) Состояние (state) Событие (event) Переход (transition) Действие (action) Состояние деятельности (activity state) Событие (event) Переход (transition) Деятельность (activity) Действие (action) Развилка (fork) Слияние (merge) Объект (object) Сообщение (message) Активация (выполнение операции, activation) Линия жизни (lifeline) Плавательная дорожка (swim lane) Объект (object) Роль (роль в кооперации, collaboration role) Сообщение (message) Узел (узел реализации, node) Компонент (component) Объект (object) Зависимость (dependency relationship) | ||
| Модель реализации (implementation model) Модель тестирования (test model) | Диаграмма классов реализации (implementation class diagram) Диаграмма компонентов (component diagram) | Ассоциация (association) Расположение (месторасположение, location) Пакет (package) Система (system) Подсистема (subsystem) Класс (class) Объект (object) Атрибут (свойство, attribute) Метод (method) Отношение зависимости (зависимость, dependency) Ассоциация (association) Агрегация (aggregation) Композиция (composition) Обобщение (generalization) Реализация (realization) Компонент (component) Тестовый компонент (test component) Интерфейс (interface) Зависимость (dependency relationship) Реализация (realization relationship) | ||
Наиболее общей концептуальной моделью системы является диаграмма вариантов использования, она является исходной для построения остальных диаграмм.
Все диаграммы языка являются графами специального вида, содержат вершины (геометрические фигуры), связанные ребрами (дугами). Обычно масштаб изображения и расположение вершин особого значения не имеют, однако, в диаграмме последовательности вводится ось времени и там это существенно.
Связи обозначаются различными линиями на плоскости, внутри фигур пишется текст, около вершин и связей могут изображаться некоторые графические символы. В расширениях UML допускаются пространственные диаграммы.
В языке имеется 4 вида графических конструкций:
· значки (пиктограммы);
· графические символы на плоскости;
· пути (линии);
· строки текста.
1.6 Концептуальный уровень. Модель вариантов использования
В целом процесс объектно-ориентированного проектирования происходит в соответствии с основными принципами структурного системного анализа: нисходящее проектирование с построением иерархии диаграмм, постепенно переводящих нас с уровня на уровень: концептуальный – логический – физический (реализация)
Диаграммой самого верхнего уровня считается предложенная А. Якобсоном в OOSE диаграмма вариантов использования системы в целом. Именно она является исходным концептуальным представлением системы и строится с целью:
· определить общие границы и контекст моделируемой предметной области;
· сформировать общие требования к функциональному поведению и интерфейсу системы;
· подготовить исходную документацию для взаимодействия разработчиков и заказчиков - пользователей системы.
Точка зрения модели: внешний пользователь системы. В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).
Актант (актер, внешняя сущность, actor) - абстрактное описание класса источников/приемников сообщений, которые напрямую взаимодействует с системой, подсистемой или классом. Это-описание роли , которую играет пользователь (человек или другая система, подсистема, класс) во время взаимодействия с системой. По существу, это обобщение имеющих сходство между собой информационных запросов к системе, требующих определенного сервиса (обслуживания).
Актант не обязательно должен отождествляться с конкретным физическим лицом или устройством, хотя это в принципе иногда возможно, если они выполняют только одну роль. Чаще всего – физически – это разные люди и устройства, обращающиеся к системе с целью получения одного и того же сервиса. На самом верхнем уровне, например, актантами могут являться оператор, системный администратор, администратор базы данных, обычный пользователь, какой-либо класс устройств.
Все возможные актанты исчерпывают все возможные пути взаимодействия пользователя с системой (подсистемой, классом). При реализации системы актанты воплощаются в людях и физических объектах. Один человек или физический объект в зависимости от режима взаимодействия может представлять собой несколько актантов (разные роли). Например, один и тот же человек может быть оператором и администратором базы данных, продавцом и покупателем и т.п.
Во многих АС нет никаких других актантов, кроме людей. Однако, актантами могут быть внешняя система, устройство ввода/вывода или таймер (обычно это встречается во встроенных системах реального времени). Среди актантов в варианте использования выделяется главный актант (primary actor), который инициирует работу с системой. Остальные – второстепенные (secondary), они также участвуют в варианте использования, получая результаты и вводя некоторые промежуточные данные.
На логическом и физическом уровнях актанты представляются классами и объектами-экземплярами классов. Возможно построение иерархии актантов с наследованием всех ролей и отношений, атрибутов и операций, которые есть у актанта-предка. Экземпляр актанта-потомка всегда можно использовать в том месте системы, где объявлено использование актанта-предка (принцип подстановки).
Актант может изображаться на диаграммах двумя способами:
3. Символ класса (прямоугольник) с внутренним указанием стереотипа
|
4. Более стандартно: “человек” с надписью (символ человека)
Актант находится вне системы и его внутренняя структура не определяется. Он является источником/приемником сообщений.
Заказчик
Вариант использования (прецедент, use case) – абстрактное описание класса сервиса (сервисных функций), предоставляемого актанту в ответ на его запросы.
Сервис могут предоставлять система в целом, подсистема или класс. Таким образом, вариант использования означает моделирование некоторой части функциональности или поведения системы. Вариант использования имеет имя и означает некоторую последовательность действий, видимых внешнему источнику/приемнику (актанту). Внутренний способ реализации варианта при этом скрывается и на более низких уровнях детализации раскрывается диаграммой кооперации . Как и всякий класс, вариант использования имеет атрибуты и операции, реализация которых раскрывается на физическом уровне.
Вариант использования включает всю последовательность сообщений, которую начинает актант и заканчивает система (подсистема, класс). Поэтому любой экземпляр реализации варианта использования всегда имеет начало во времени и окончание, когда уже никакой актант не посылает сообщений по этому варианту. Сюда же относятся сообщения об ошибках, варианты выполнения функции обслуживания при различных параметрах настройки (альтернативы).
Экземпляр варианта использования – это выполнение варианта использования, которое начинается после первого получения сообщения от экземпляра актанта. В качестве реакции на данное сообщение вариант использования выполняет определенную последовательность действий, например, отправляет сообщение другим экземплярам актанта (а не только тому, кто инициировал). В свою очередь, эти актанты отправляют сообщения данному экземпляру варианта использования, и взаимодействие продолжается до тех пор, пока больше таких сообщений не поступает. Это означает окончание варианта использования.
Связь между актантом и вариантом использования показывается ассоциацией.
На диаграмме вариант использования изображается двумя способами:
1) эллипсом, внутри ставится имя
 |  |
||||||||||
 |
|||||||||||
 |
|||||||||||
 |
|||||||||||
 |
|||||||||||
2) прямоугольником - как и любой класс
Заказчик
 |
|||
Датчик
Между актантами и вариантами использования ассоциация – единственный вид связи. При этом он имеет семантику коммутативной связи , то есть передачи сообщений, поэтому обычно не помечается, так как контекст ясен из обозначений актанта и варианта использования. Но можно ее пометить, а также указать кратность связи:
 |
|||||
 |
|||||
Клиент банка
Кратность (multiplicity) характеризует количество конкретных экземпляров класса, участвующих в данной связи (один клиент может оформить неограниченное число кредитов).
В общем случае ассоциация – это отношение между двумя или несколькими компонентами модели. Так как в большинстве случаев компоненты – это некоторые классы объектов, то экземпляр ассоциации – это просто упорядоченный список ссылок на конкретные экземпляры, возможно, снабженный атрибутами ассоциации (свойствами).
Имя ассоциации, если оно есть, должно быть уникальным. Его формируют по смыслу отношений между классами - участниками ассоциации. Например, «Сотрудник работает_в Отделе», «Менеджер комплектует Компьютер» и т.п.
Ассоциации сами являются классами (класс-ассоциация , association class), у нее есть как свойства класса, так и свойства ассоциации. Экземпляры этого класса - связи, у которых есть не только ссылки на объекты, но и значения атрибутов (свойств).
Участники ассоциации называются ее полюсами . Все полюса – это роли классов, участвующих в связи, они различаются и могут быть перечислены в некотором упорядоченном списке. В большинстве случаев ассоциации бинарны (две роли в ассоциации с определенной семантикой), но могут быть и n -арными . Один и тот же класс может выступать в различных ролях, то есть быть одновременно в двух полюсах ассоциации.
Множественность связи проставляется у полюсов.
Связи могут появляться и исчезать в процессе работы системы, ограничения и соответствующие предикаты могут указываться у полюсов ассоциации.
Иногда связь меняется только у одного из полюсов. Если связь имеет атрибуты, то они могут быть изменены операциями, однако, при этом ссылки на участников связей не меняются.
Ассоциация изображается непрерывной линией, соединяющей границы 2-х классов, если ассоциация n -арная, то рисуется ромб (признак агрегации):
|
|||||||
|
|||||||
 |
|||||||
 |
|||||||
Между собой варианты использования не обмениваются сообщениями и могут находиться только в отношениях (связях) расширения (extend), включения (include) и обобщения (generalization).
В отношении расширения
вариант использования – клиент вносит дополнительную последовательность действий, начиная с некоторой точки основной последовательности, при этом таких “вставок” может быть несколько. Все эти точки называются точками расширения.
Rational Unified Process (RUP) - методология разработки программного обеспечения, созданная компанией Rational Software.
Принципы : Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков. Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)). Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта. Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
RUP использует итеративную модель разработки . В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.
Полный жизненный цикл разработки продукта состоит из четырех фаз , каждая из которых включает в себя одну или несколько итераций: начальная фаза, фаза уточнения, конструирования и внедрения.
Экстремальное программирование (Extreme Programming, XP)
Экстремальное программирование (Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения
12 основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
Короткий цикл обратной связи: (Разработка через тестирование, Игра в планирование, Заказчик всегда рядом, Парное программирование
Непрерывный, а не пакетный процесс: Непрерывная интеграция, Рефакторинг, Частые небольшие релизы
Понимание, разделяемое всеми : Простота, Метафора системы, Коллективное владение кодом или выбранными шаблонами проектирования, Стандарт кодирования
Социальная защищенность программиста: 40-часовая рабочая неделя
Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. «Заказчик» в XP - это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему.
Стандарты документации
Стандарты обеспечивают совместимость между проектами. Стандарты улучшают понимание среди инженеров. Стандарты должны восприниматься инженерами как нечто полезное для них, а не как набор препятствий. Четкие и измеримые цели, требующие дисциплинированного и документированного подхода, обычно являются хорошим мотивом для разработчиков
SVVP - План определяет каким образом и в какой последовательности должны проверяться стадии проекта. Верификация – это процесс проверки правильности сборки приложения. Валидация проверяет тот факт, что собран требуемый продукт.
SQAP - План контроля качества программного обеспечения
SCMP - План управления программным проектом
SRS - Спецификация требований к программному обеспечению
SDD - Проектная документация программного обеспечения
STD - Документация по тестированию программного обеспечения
Согласованность и целостность документации.
Управление документацией требует значительных организационных навыков. Написание хорошей и гибкой документации сродни написанию хорошего и гибкого кода.
Управление документацией подразумевает поддержание ее полноты и согласованности и включает в себя также управление конфигурациями.
Полнота – наличие комплекта документации, охватывающей процесс разработки и сопровождения.
Согласованность означает, что набор документов не содержит внутренних противоречий.Проблема в том, что когда этот набор велик, то довольно сложно избежать появления в нем взаимоисключающих утверждений.
Поддержка конфигурации – это координация различных версий и частей документации и программного кода.
Документирование Тестирование Agile ( , Lean , Scrum , FDD и др.) Cleanroom OpenUP RAD RUP MSF DSDM TDD BDD Конфигурационное управление Управление проектами Управление требованиями Обеспечение качестваUnified Process активно использует унифицированный язык моделирования (UML ). В ядре UML лежит модель, которая позволяет команде разработке в упрощённом виде понять многообразие сложных процессов, необходимых для разработки программного обеспечения. Различные модели, используемые в Unified Process , позволяют визуализировать систему, описать её структуру и поведение, задокументировать принимаемые в процессе разработки решения .
Истоки фреймворка лежат в работах сотрудника Ericsson Ивара Якобсона , опубликованных в конце 1960-х годов. Якобсон и его коллеги моделировали огромные телекоммуникационные системы с использованием слоёв «блоков» (того, что позднее стало называться «компонентами»): нижние слои служили основанием для подсистем из верхних слоёв. Команда строила нижние блоки путём рассмотрения «дорожных происшествий» (англ. traffic cases ), которые могли произойти с пользователями системы. Именно эти «происшествия» стали прообразом сценариев использования (англ. use cases ), вошедших позднее в состав UML . Работы Якобсона также послужили толчком для создания диаграмм, используемых в UML , включая диаграммы деятельности и последовательности .
В 1987 году Якобсон основал собственную компанию Objectory AB и совместно с партнёрами провёл несколько лет, разрабатывая проект и продукт под названием Objectory . В 1995 году Якобсон публикует книгу «Object-Oriented Software Engineering », описывающую процесс разработки, движущей силой которого являются требования клиента, трансформируемые в конечный продукт с помощью сценариев использования. Выход книги совпал с первой публикацией онлайн-версии ядра Unified Process .
В 1995 году компанию Objectory AB поглощает корпорация Rational . С помощью значительно возросшего количества коллег, Якобсон приступает к расширению процесса Objectory , дополняя его инструментами для управления проектами и разработки. Наряду с Гради Бучем и Джеймсом Рамбо , работавшими в Rational ранее, Якобсон становится участником группы «трёх амиго» , возглавивших работы по созданию процесса, получившего название 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 является использование итеративного и инкрементного подхода . Итерациями называются миниатюрные проекты, которые позволяют запустить более новую версию системы. Результат итерации, изменения, внесённые в систему, называются инкрементом. В частности, итеративный подход позволяет последовательно улучшать архитектуру системы, обрабатывать постоянные изменения требований, гибко подстраивать план всего проекта. Приверженность принципу непрерывной интеграции позволяет выявлять возможные проблемы на ранней стадии. Помимо этого, итеративность помогает минимизировать риски, связанные с техническими ограничениями, архитектурой и изменяющимися требованиями .
Относительный размер фаз разработки для типичного проекта
Каждый цикл разработки, согласно Unified Process , состоит из четырёх фаз, представляющих собой промежуток времени между важными вехами проекта, позволяющими руководителям принять важные решения относительно продолжения процесса разработки, объёма работ, бюджета и расписания.
Внутри Unified Process в каждой из фаз разработки выделяются пять разновидностей рабочих процессов: требования, анализ, дизайн, имплементация и тестирование.
Каждый процесс представляет собой набор работ, выполняемых различными членами проектной команды. Так, целью процессов по сбору требований является создание модели сценариев использования, позволяющих выявить основные функциональные требования к системе. Процессы анализа и соответствующая модель позволяет разработчикам структурировать функциональные требования; процесс дизайна описывает физическую реализацию сценариев использования, и является абстракцией для следующей модели. Процесс и модель имплементации описывают, как элементы дизайна соотносятся с компонентами программного обеспечения, включающими исходный код, динамические библиотеки и пр. Последняя из моделей, описывающая тестирование, поясняет, какие системные тесты и юнит-тесты и как должна выполнять команда разработки .
Каждая из фаз, описанных в Unified Process, состоит из итераций , представляющих собой миниатюрные под-проекты ограниченной длительности. Как правило, каждая итерация включает в себя все пять элементов рабочего процесса в той или иной степени. Результатом итерации является инкремент , релиз, содержащий в себе улучшения по сравнению с предыдущей версией продукта.
Унифицированный процесс (UP) − это обобщенный каркас процесса, который может быть специализирован для широкого круга программных систем, различных областей применения, уровней компетенции и размеров проекта.
Унифицированный процесс компонентно ориентирован. Это означает, что создаваемая программная система строится на основе программных компонентов , связанных хорошо определенными интерфейсами.
Специфичные аспекты UP заключаются в трех его характеристиках:
● управляется вариантами использования;
● является архитектурно-ориентированным;
● является итеративным и инкрементным.
Жизненный цикл унифицированного процесса
Жизненный цикл UP разбивается на циклы, каждый из которых завершается поставкой выпуска продукта. Каждый цикл развития состоит из четырех фаз - анализа и планирования требований, проектирования, построения, внедрения. Каждая фаза подразделяется на итерации.
UP включает в себя восемь рабочих процессов: пять основных − определение требований, анализ, проектирование, реализация, тестирование и три вспомогательных (для поддержки основных) − управление конфигурацией и изменением требований, управление проектом, управление средой.
Для определения структуры рабочего процесса сначала необходимо определить, какие типы исполнителей участвуют в процессе. Затем определяются артефакты , которые должны быть созданы в ходе данного рабочего процесса каждым типом исполнителей.
18. XP – процесс.
Экстрема́льное программи́рование (англ. Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
1. Короткий цикл обратной связи (Fine scale feedback)
a. Разработка через тестирование (Test driven development)
b. Игра в планирование (Planning game)
c. Заказчик всегда рядом (Whole team, Onsite customer)
d. Парное программирование (Pair programming)
2. Непрерывный, а не пакетный процесс
a. Непрерывная интеграция (Continuous Integration)
b. Рефакторинг (Design Improvement, Refactor)
c. Частые небольшие релизы (Small Releases)
3. Понимание, разделяемое всеми
a. Простота (Simple design)
b. Общение
c. Уважение
d. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
e. Стандарт кодирования (Coding standard or Coding conventions)
4. Социальная защищенность программиста (Programmer welfare):
a. 40-часовая рабочая неделя (Sustainable pace, Forty hour week)
В XP процесс делится на очень маленькие ступеньки, по сравнению с планируемыми процессами. Это приводит к тому, что первые шаги могут занимать дни или недели вместо месяцев или даже лет для каждой ступени в модели «водопад». Сначала пишутся автоматические тесты, чтобы описать цели разработки. Потом идёт кодирование, которое заканчивается в тот момент, когда все тесты проходят, и программисты не могут придумать новых тестов. Дизайн делается теми же людьми, которые пишут код. (только последняя ступень - соединение дизайна и кода является общим для всех гибких процессов). Незаконченная, но функционирующая система показывается узкому кругу пользователей (чаще всего это сами разработчики). В этот момент начинают писать тесты для следующей наиболее важной части системы.
19. ICONIX – процесс.
ICONIX разработал Дуг Розенберг в компании ICONIX Software .Процесс ICONIX основан на вариантах испльзования, но не характеризуется множеством его недостатков. В этом процессе также применяется язык моделирования UML, но используется только базовая нотация из UML – это 20% языка. В основу процесса ICONIX положены четыре основных этапа разработки ПО на основе вариантов использования:
● моделирование предметной области;
● моделирование прецедентов;
● анализ пригодности требований (проверка на выполнение всех функциональных требований);
● построение диаграмм последовательности.
Основные этапы процесса следующие:
● Анализ требований
● Предварительное проектирование
● Проектирование
● Реализация
Процесс основан на построении минимального количества моделей, которые отражают будущую систему. На этапе анализа создаются модели прецедентов (Use Case), модель пользовательского интерфейса и модель сущностей предметной области. На этапе предварительного проектирования создается диаграмма пригодности (Robustness Diagram). Также дополняется модель прецедентов и модель сущностей предметной области. На этапе детального проектирования создается диаграмма последовательности (SequenceDiagram) и создается диаграмма классов. На этапе реализации создается исходный код. При этом возможно создание диаграммы развертывания и диаграммы компонентов. каждый этап завершается вехой рецензирования, когда созданные диаграммы необходимо обсудить с коллегами.
20. SCRUM – процесс.
Scrum - это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
Главные действующие роли в Scrum: ScrumMaster - тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самогоScrum -а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster );Владелец Продукта (Product Owner ) - человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон; и кросс-функциональная Команда (Scrum Team ), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.
На протяжении каждого спринта создаётся функциональный рост программного обеспечения. Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items ), определенных на протяжении совета по планированию спринта (sprint planning meeting ), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта . Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog ). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements ) во время спринта.
Артефакты
Product backlog - это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story ) или элементами backlog’a (backlog items ). Product backlog открыт для редактирования для всех участников Scrum-процесса.
