Унифицированный процесс разработки пс. Унифицированный Процесс разработки ПО компании Rational. Жизненный цикл унифицированного процесса. Цели каждого из этапов

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 - Документация по тестированию программного обеспечения

Согласованность и целостность документации.

Управление документацией требует значительных организационных навыков. Написание хорошей и гибкой документации сродни написанию хорошего и гибкого кода.

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

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

Согласованность означает, что набор документов не содержит внутренних противоречий.Проблема в том, что когда этот набор велик, то довольно сложно избежать появления в нем взаимоисключающих утверждений.

Поддержка конфигурации – это координация различных версий и частей документации и программного кода.

Введение

ациональный унифицированный процесс (Rational Unified Process, RUP) - одна из спиральных методологий разработки программного обеспечения. Методология поддерживается компанией Rational Software, обновление продукта происходит примерно дважды в год. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML).

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

RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта - анализу и моделированию. Таким образом, эта методология направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми.

Процесс предполагает эволюционирование моделей; итерация цикла разработки однозначно соответствует определенной версии модели программного обеспечения. Каждая из итераций (workflow) содержит элементы управления жизненным циклом программного обеспечения: анализ и дизайн (моделирование), реализация, интегрирование, тестирование, внедрение. В этом смысле RUP является реализацией спиральной модели, хотя довольно часто изображается в виде графика-таблицы. Ниже мы приведем основные компоненты процесса.

Для успешного процесса разработки необходимы три составляющие (рис. 1): процесс (process), нотация (notation) и набор утилит (tools). Процесс описывает, что мы делаем, в каком порядке и каким образом; нотация является средством общения; набор утилит помогает автоматизировать процесс и управлять им.

Рис. 1. Треугольник успеха

В RUP представлены все три компонента. Сначала рассмотрим функции нотации, которые производят следующие действия:

Осуществляет «склеивание» процесса в единое целое;

Является языковым средством принятия решений, которые не очевидны из исходного кода;

Предоставляет семантику для отображения важных стратегических и тактических решений;

Предлагает форму, достаточную для того, чтобы размышлять, а потом принимать решения и средства автоматизации процесса для того, чтобы манипулировать формализованными данными.

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

Структура RUP

UP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре основные фазы во времени (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание). К сожалению, в русском языке нет установившейся терминологии, поэтому в дальнейшем мы будем использовать английские термины, сопровождая их переводом на русский язык. На рис. 2 представлено широко распространенное изображение фаз RUP. Целями каждой из данных фаз являются:

Inception понимание, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;

Elaboration понимание, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;

Construction создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);

Transition создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.

Рис. 2. Фазы RUP

Это фазы управления эволюцией продукта - итерациями жизненного цикла. RUP предполагает приближение к конечной цели, но, в отличие от классического стандарта ISO (методология «водопад»), где transition является конечной фазой, каждая из фаз может повторяться несколько раз, отражая изменение требований заказчика продукта.

Методология RUP основана на девяти основных потоках (workflow), являющихся элементами итерации жизненного цикла ПО:

Business modeling (бизнес-анализ) - предполагает анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей;

Requirements (требования) формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases (пользовательских историй) формальное отображение требований пользователя в UML. Результатом являются документы уровня менеджмента;

Analysis and design (анализ и моделирование) - предполагает перевод собранных требований в формализованную программную модель. Результатом является описание системы на фазе реализации (технический проект) - это документы уровня разработчиков системы. Язык формализации - Unified Modelling Language (UML), о котором речь пойдет ниже. В процессе итеративной разработки эволюционировать будет продукт именно этого потока - модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов. Здесь имеется в виду тот факт, что результатом разработки является не модель, а исполняемый код, поэтому заказчик обычно не очень любит платить за моделирование, так как модели не являются продуктом, который ему нужен);

Implementation (реализация, кодирование) - предполагает собственно написание кода. Элементы кода в RUP уже созданы на этапе анализа и дизайна, так как средство реализации UML - Rational Rose - позволяет создавать элементы кода на нескольких языках программирования. Методология - объектно-ориентированное программирование;

Test (тестирование) предполагает тестирование продукта на данной итерации. Стоит специально отметить, что regression testing (возвратное тестирование, тестирование «неухудшения» продукта) в данном случае должно содержать все актуальные тесты от предыдущей итерации и приемосдаточные тесты от предыдущей transition-фазы;

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

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

Preliminary interna это фактически документы, выпускаемые техническим советом для менеджеров предприятия. Основная цель начальных этапов заключение контракта или соглашения о намерениях. Дальнейшие итерации собственно начало работы коллектива разработчиков, который имеет время и ресурсы для построения формальных моделей. UML в данном случае имеет средства, позволяющие отображать модель на элементы кода. Например, дерево объектов отображается непосредственно, вариации зависят от мощности реализации выбранного разработчиками языка программирования, а также от совпадения взглядов Г.Буча и разработчиков данного языка на объектную модель. То же самое относится к методам.

Теперь рассмотрим элементы, касающиеся поддержки продукта, - core supporting workflows:

Configuration management (управление конфигурацией и изменениями) - мощный слой административных действий, направленных на управление версиями продукта, что предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль версий продукта, корпоративные стандарты разработки кода и документации, отслеживание изменений и ошибок (bug tracking); тесно связан с тестированием и поддержкой пользователей (customers support);

Management (управление проектом) - предполагает набор административных действий управления проектом согласно идеологии RUP, используются средства управления проектом (см. ниже список продуктов Rational);

Environment (окружение) предполагает создание и поддержку средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение).

Итеративная разработка;

Управление требованиями;

Использование модульных архитектур;

Визуальное моделирование;

Проверка качества;

Отслеживание изменений.

Практики не являются непосредственно частью процесса RUP, но настоятельно рекомендованы к использованию. Часть практик прямо вытекает из идеологии RUP. Так, итеративная разработка заложена в структуру RUP, поскольку этот процесс является одной из реализаций «спирали». Управление требованиями в RUP появляется на самых ранних стадиях анализа. Теоретически модульная архитектура позволяет повторно использовать код, и система получается более гибкой. В силу того что UML является объектным языком, игнорировать модульность можно, но… несколько затруднительно. Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Кроме того, модели являются средствами коммуникации между разработчиками, но для этого разработчики должны говорить на UML, что предполагает определенный тренинг. Визуальное моделирование часто осуществляется с помощью инструмента Rational Rose, что позволяет получать набор весьма полезных документов для менеджеров, системных администраторов, разработчиков, тестировщики, генерировать элементы кода. Данное средство не является единственной реализацией UML - доступны как коммерческие альтернативы (например, Microsoft Visio), так и бесплатные. Следует отметить, что диалекты UML, реализованные в средствах моделирования, не всегда совпадают: диалект Rational имеет некоторые серьезные различия, описанные как в документации, так и в книгах по UML.

Продукты, поддерживающие RUP

иже перечислены самые известные продукты, поддерживающие Rational Unified Process:

Rational Rose CASE-средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода. Специальная редакция продукта Rational Rose RealTime позволяет на выходе получить исполняемый модуль;

Rational Requisite Pro средство управления требованиями, позволяющее создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения;

Rational ClearQuest продукт для управления изменениями и отслеживания дефектов в проекте (bug tracking), тесно интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой;

Rational SoDA продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы. Возможно также приведение документации к уже существующим стандартам (ISO, CMM);

Rational Purify, Rational Quantify Rational PureCoverage, - средства тестирования и отладки:

Rational Purify весьма мощное средство поиска ошибок на run-time для разработчиков приложений и компонентов, программирующих на C/C++,

Rational Visual Quantify средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО,

Rational Visual PureCoverage - автоматически определяет области кода, которые не подвергаются тестированию;

Rational ClearCase продукт для управления конфигурацией программ (Rational’s Software Configuration Management, SCM), позволяющий производить версионный контроль всех документов проекта. С его помощью можно поддерживать несколько версий проектов одновременно, быстро переключаясь между ними. Rational Requisite Pro поддерживает обновления и отслеживает изменения в требованиях для группы разработчиков;

SQA TeamTest средство автоматизации тестирования;

Rational TestManager система управления тестированием, которая объединяет все связанные с тестированием инструментальные средства, артефакты, сценарии и данные;

Rational Robot инструмент для создания, модификации и автоматического запуска тестов;

SiteLoad, SiteCheck средства тестирования Web-сайтов на производительность и наличие неработающих ссылок;

Rational PerformanceStudio - измерение и предсказание характеристик производительности систем.

Артефакты и роли

еотъемлемую часть RUP составляют артефакты (artefact), прецеденты (precedent) и роли (role). Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты - это последовательности действий, выполняемых системой для получения наблюдаемого результата. Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т.п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт. Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов - начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т.п. Ниже приведен набор артефактов (моделей, документов и т.п.) для каждого из потоков.

Business modeling

Модель бизнес-процессов определение бизнес-требований к разрабатываемой системе;

Модель структуры предприятия - артефакт для разработки функциональной модели системы;

Модели документов, бизнес-сущностей, модели сценариев бизнес-функций, модели состояний бизнес-сущностей - для проектирования пользовательского интерфейса, БД системы; представляют собой описание статического и динамического состояний системы с различных точек зрения;

Модели бизнес-правил артефакт используется для моделирования правил в ПО.

Артефакты-документы используются RequisitePro, SoDA, текстовые процессоры, Microsoft Project:

Оценка организации заказчика, структура бизнеса;

Словарь терминов предметной области;

Набор бизнес-правил;

Коммерческое предложение;

Спецификации бизнес-функций;

План работ на этапе бизнес-моделирования;

Запросы на изменение.

Requirements

Артефакты-модели используется Rational Rose:

Модель функции системы;

Модель сценариев функций системы;

Модель интерфейсов пользователя;

Модель сценариев работы пользователя системы;

Модель выходных форм;

Модель правил системы.

План управления требованиями;

Словарь терминов системы;

Спецификация на программную систему;

Спецификация на функции системы;

Правила системы;

Запросы заинтересованных лиц;

План работ на этапе определения требований к системе;

Запросы на изменение.

Analysis and design

Артефакты-модели используется Rational Rose:

Логическая модель данных;

Физическая модель данных;

Модель спецификаций компонентов системы;

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

Артефакты-документы используются RequisitePro, SoDA, текстовые процессоры, MS Project:

Архитектура программного обеспечения;

Спецификации программных компонентов;

План работ на этапе анализа и проектирования;

Запросы на изменение.

Implementation

Артефакты-модели используется Rational Rose:

Компонентная модель приложения.

Артефакты-код используются Rational Rose, средства программирования, текстовые процессоры:

Элементы генерации кода, полученные в Rational Rose;

Собственно код приложения;

Документация.

Артефакты-документы используются RequisitePro, SoDA, текстовые процессоры, MS Project:

План сборки приложения;

План работ на этапе реализации.

Test

Артефакты-модели используется Rational Rose:

Модель тестовых примеров;

Функциональная модель тестовой программы;

Модель спецификации компонентов тестовой программы;

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

Описание тестовых примеров;

План тестирования;

План работ на этапе тестирования;

Запросы на изменение.

Реализация тестирования Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Deployment

Артефакты-модели используется Rational Rose:

Модель размещения описание размещения компонентов по узлам обработки.

Артефакты-документы используются SoDA, текстовые процессоры, MS Project:

Обучающие материалы;

Документы по инсталляции;

Описание версий системы;

План внедрения.

Следующая статья данного цикла будет посвящена языку Unified Modelling Language (UML).

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

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

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

· Начинайте вести наступление на главные риска раньше и ведите его непрерывно, или они сами пойдут в наступление на вас.

· Обеспечьте выполнение требований заказчиков.

· Сконцентрируйтесь на исполняемой программе.

· Приспосабливайтесь к изменениям с самого начала проекта.

· Рано закладывайте исполняемую архитектуру.

· Стройте систему из компонентов.

· Работайте вместе как одна команда.

· Сделайте качество образом жизни, а не запоздалой идеей.

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

RUP обеспечивает структурированный подход к итеративной разработке , разделяя проект на четыре фазы: Начало, Проектирование, Построение и Внедрение. Каждая фаза сопровождается так называемой вехой, - контрольной точкой процесса, в которой проверяется достижение целей очередной фазы, и принимается решение о переходе (или не переходе) в следующую фазу. Каждая из четырех фаз RUP, таким образом, имеет веху и четко определенный набор целей. Эти цели используются для определения того, какие задачи выполнять и какие артефакты создавать. Каждая фаза концентрируется строго на том, что единственно необходимо для достижения бизнес целей фазы.

Все элементы процесса – роли, задачи, артефакты и связанные с ними концепции, руководства и шаблоны сгруппированы в логические контейнеры, называемые Дисциплинами (Disciplines). В стандартном продукте RUP дисциплин всего девять. К ним относятся: бизнес – моделирование, управление требованиями, управление проектом, управление изменениями и среда.

Каждый рабочий поток процесса: сбор требований, анализ, проектирование, реализация и тестирование определяет набор связанных артефактов и действий. Напомним, что артефактом является документ, отчет, выполняемый элемент и т.п. Артефакт может вырабатываться, обрабатываться или потребляться.

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

Модель - наиболее важная разновидность артефакта. Предусмотрены девять моделей, вместе они покрывают все решения по визуализации, спецификации, конструированию и документированию программных систем:

· бизнес – модель . Определяет абстракцию организации, для которой создается система;

· модель области определения . Фиксирует контекстное окружение системы;

· модель Use Case . Определяет функциональные требования к системе.

· модель анализа . Интерпретирует требования к системе в терминах проектной модели;

· проектная модель . Определяет словарь предметной области проблемы и ее решения;

· модель размещения . Определяет аппаратную топологию, в которой исполняется система;

· модель реализации . Определяет части, которые используются для сборки и реализации физической системы;

· тестовая модель . Определяет тестовые варианты для проверки системы;

· модель процессов . Определяет параллелизм в системе и механизмы синхронизации.

Технические артефакты подразделяются на четыре основных набора:

· набор требований. Описывает, что должна делать система;

· набор проектирования.

Описывает, как должна быть сконструирована система;

· набор реализаций. Описывает сборку разработанных программных компонентов;

· набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.

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

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

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

Набор размещения группирует всю информацию об упаковке, отправке, установке и запуске системы.

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

Показатель Риска = Вероятность (НУ) *Потеря (НУ).

Управление риском включает шесть действий:

1. Идентификация риска – выявление элементов риска в проекте.

2. Анализ риска – оценка вероятности и величины потери по каждому элементу риска.

3. Ранжирование риска - упорядочение элементов риска по степени их влияния.

4. Планирование управления риском – подготовка к работе с каждым элементом риска.

5. Разрешение риска – устранение или разрешение элементов риска.

6. Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий.

Первые три действия относятся к этапу оценивания риска, последние три действия – к этапу контроля риска.

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

Унифицированный процесс – это обобщённый каркас процесса создания ПП, который м.б. специализирован для широкого круга программных систем. Для разработки модели программной системы унифицированный процесс использует унифицированный язык моделирования.

начинайте вести наступлении на главные риски, ведите его непрерывно, иначе риски пойдут в наступления на вас.

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

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

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

закладывайте основу исполняемой архитектуры как можно раньше. Исполняемая архитектура – ключевые варианты использования. Ключевой ВИ это та функциональность системы, без реализации которой ПП не имеет смысла. Ключ. ВИ составляют 7-10% от всех вариантов

стройте систему из компонентов. Приложения на основе компонентов создаются быстрее, более гибкие с точки зрении изменений, относительно низкая стоимость.

работайте как 1 команда

сделайте качество образом жизни, а не запоздалой идеей

6 Жизненный цикл унифицированного процесса. Цели каждого из этапов.

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

Каждый цикл состоит из четырех фаз - анализа и планирования требований, проектирования, построения и внедрения. Каждая фаза, как будет рассмотрено ниже, далее подразделяется на итерации.

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

Что система должна делать в первую очередь для ее основных пользователей?

Как должна выглядеть архитектура системы?

Каков план и во что обойдется разработка продукта?

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

В ходе фазы проектирования детально описываются большинство вариантов использования и разрабатывается архитектура системы.

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

В ходе фазы построения происходит создание продукта - к скелету (архитектуре) добавляются мышцы (законченные программы). На этой фазе базовый уровень архитектуры разрастается до полной развитой системы. Концепции развиваются до продукта, готового к передаче пользователям. В ходе фазы объем требуемых ресурсов вырастает. В конце этой фазы продукт включает в себя все варианты использования, которые руководство и заказчик договорились включить в текущий выпуск. Правда, они могут содержать ошибки. Большинство дефектов будут обнаружены и исправлены в ходе фазы внедрения. Ключевой вопрос окончания фазы: удовлетворяет ли продукт требованиям пользователей настолько, что некоторым заказчикам можно делать предварительную поставку?

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

Rational Unified Process (RUP ) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software . Основываясь на опыте многих успешных программных проектов, Унифицированный процесс позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Одним из основных столпов, на которые опирается RUP , является процесс создания моделей при помощи унифицированного языка моделирования (UML ). Эта статья о применении диаграмм UML в рабочем процессе разработки программных систем по методологии Rational Software .

Ни для кого не секрет, что создание программного обеспечения – это сложный процесс, который, с одной стороны, имеет много общего с творчеством, а с другой, – хотя и высокодоходный, но и высокозатратный бизнес. Жестокая конкуренция на рынке вынуждает разработчиков к поискуболее эффективных методов работы. Путей создания программных систем в еще более короткие сроки, с меньшими затратами и лучшим качеством. Сложность программ постоянно увеличивается. Еще недавно программные продукты могли быть созданы в обозримые сроки одиночками или, например, в IT -отделе автоматизируемого предприятия.

Сейчас же одиночкам, создающим программы «на коленке» остается область небольших утилит и различных модулей расширения «тяжелых» программных продуктов. Будущее за индустриальным подходом к созданию ПО. В 1913 году Генри Форд запустил первый автомобильный конвейер, а в 90-х аналогичный конвейер стал применяться в сфере IT -технологий. Командная разработка требует совсем другого подхода и другой методологии, которая рано или поздно должна была быть создана.

Корпорация Rational Software (http ://www .rational .com ) выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP ), которая представляет собойнабор исчерпывающих рекомендаций для создания практически любых программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно рассказывает когда, кто и что должен делать в проекте, чтобы в результате получить программную систему с установленные сроки, с определенной функциональностью и в рамках отведенного бюджета.

Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему. Систему, которая давала бы «значимый результат» пользователям и выполняла бы именно то, что они от системы ожидают. Поэтому процесс управляется вариантами использования (Use Case ) системы, или иначе –прецедентами.

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

рис. 1 Фазы и потоки работ RUP

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

Вся разработка ПО рассматривается в RUP как процесс создания артефактов. Любой результат работы проекта, будь то исходные тексты, объектные модули, документы, передаваемые пользователю, модели – это подклассы всех артефактов проекта. Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист создает программу, руководитель - проектный план, а аналитик - модели системы. RUP позволяет определить когда, кому и какой артефакт необходимо создать, доработать или использовать.

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

Модели позволяют рассмотреть будущую систему, ее объекты и их взаимодействие еще до вкладывания значительных средств в разработку, позволяют увидеть ее глазами будущих пользователей снаружи и разработчиков изнутри еще до создания первой строки исходного кода. Большинство моделей представляются UML диаграммами, подробнее об UML можно прочитать, например в .

Унифицированный язык моделирования (Unified Modeling Language ) появился в конце 80-х в начале 90-х годов в основном благодаряусилиям «трех друзей» Гради Буча, Джима Рамбо и Ивара Якобсона. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятымии понятными каждому члену проекта графическими элементами.

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

Программная система создается для решения определенных проблем пользователя, а не для опробования новых технологийпрограммистами и получения опыта руководителем проекта. По большому счету, пользователю не важно используете ли вы в процессе разработки объектно-ориентированный подход, UML , RUP или создаете систему по методу XP (экстремального программирования) . Применение тех или иных методик, технологий, создание оптимальной внутренней структуры проекта остается на совести разработчиков, которые принимают решения исходя из предыдущего опыта и собственных предпочтений. Однако пользователь не простит вам игнорирование его требований. Будь программная система хоть десять раз разработана при помощи суперсовременных методов и технологий, если пользователь не получит от нее то, что называется «значимым результатом», ваш программный проект с треском провалится.

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

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

Однажды я проводил семинар по RUP в компании-разработчике программного обеспечения, которая уже десять лет довольно успешно работает на рынке, но не использует в своем рабочем процессе моделирования вовсе, а основывается на прототипах. В зале собралось около двадцати молодых и умудренных опытом программистов, которые внимательно прослушали все, что я им рассказал о RUP и UML . И вот один из них, посмотрев на доску, испещренную примерами диаграмм, заметил: «Это все интересно и, наверное, хорошо подходит для других проектов», – сказал он, «но мы работаем довольно давно без всего этого,раз мы до сих пор обходились без UML , он, наверное, нам это просто не нужен».

Этот вопрос заставил меня задуматься о том, что изменение бизнес-процессов, которое неизбежно должно произойти в компании-разработчике программного обеспечения при внедрении RUP и UML может проходить также тяжело, как внедрение информационной системы на промышленном предприятии.Любое внедрение – это ломка стереотипов. Поскольку квалификация сотрудников в компании-разработчике ПО довольно высока, то и отказаться от своих взглядов таким людям труднее, чем «простым смертным», а возникающие трудности и неприятие можно сравнить с переходом от процедурного к объектно-ориентированному мышлению.

1.Определение требований

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

рис 2. Пример диаграммы Прецедентов

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

Для детализации конкретного прецедента используется диаграмма Активности (Activity Diagram ), пример которой дан на рис 3.

рис. 3 Пример диаграммы Активности

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

Также диаграмма прецедентов может использоваться для создания сценариев тестирования, поскольку все взаимодействие пользователей и системы уже определено.

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

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

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

2.Анализ

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

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

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

Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества (Collaboration ) (рис 4). Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» – отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.

рис 4. Пример диаграммы сотрудничества

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

Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности (Sequence ), показанная на рис 5. Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса. При использовании такого инструмента для создания моделей как Rational Rose , эти два вида диаграмм могут быть созданы друг из друга автоматически (подробнее о Rational Rose можно прочитать, например, в ).

Рис. 5 Пример диаграммы последовательности действий

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

3.Проектирование

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

Для создания модели проектирования используются целый набор UML диаграмм: диаграммы классов (рис. 5), диаграммы кооперации, диаграммы взаимодействия, диаграммы активности.

рис 6. Пример диаграммы классов

Дополнительно в этом рабочем процессе может создаваться модель развертывания, которая реализуется на основе диаграммы развертывания (Deployment Diagram ). Это самый простой тип диаграмм, предназначенный для моделирования распределения устройств в сети. Для отображения используется всего два варианта значков процессор и устройство вместе со связями между ними.

4.Реализация

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

рис. 7 Пример диаграммы компонентов

5.Тестирование

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

6.Заключ ение

Здесь были рассмотрены только основные процессы методологии Rational . RUP довольно обширен, и содержит рекомендации по ведению различныхпрограммных проектов, от создания программ группой разработчиков в несколько человек, до распределенных программных проектов, объединяющих тысячи человек на разных континентах. Однако, несмотря их колоссальную разницу, методы применения моделей, создаваемых при помощи UML будут одни и те же. Диаграммы UML , создаваемые на различных этапах разработки, неотделимы от остальных артефактов программного проекта и часто являются связующим звеном между отдельными процессами RUP .

Решение о применении конкретных диаграмм зависит от поставленного в компании процесса разработки, который, хотя и называется унифицированным, однако не есть нечто застывшее. Компания Rational не только предлагает его улучшать и дорабатывать, но и предоставляет специальные средства внесения изменений в базу данных RUP .

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

Крачтен. Ф. Введениев Rational Unified Process. Изд. 2- е.- М.: Издательский дом "Вильямс", 2002. - 240 с.: ил.

Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения- Спб.: Питер, 2002. - 496 с.: ил.

Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.

Бек. Е. Экстремальное программирование. – Спб.: Питер, 2002. – 224 с.: ил.

ТрофимовС. CASE-технологии: Практическая работа в Rational Rose.
Изд. 2-е.- М.: Бином-Пресс, 2002 г. - 288 с.