Лабораторная работа №1

по дисциплине

«Разработка КИСП»

Тема: «Изучение экспертной интегрирующей

системы RUP»

15

(вариант)

 

Отчет по лабораторной работе

(вид документа)

 

Бумага писчая (A4)

(вид носителя)

 

12

(количество листов)

 

 

Проверил:

___________________

«___»_________2007 г.

 

 

 

Выполнил:

студент группы :

__________________

«___»_________2007 г.

 

 

 

 

 

 

 

 

 

 

1.    Цель лабораторной работы.

Лабораторная работа “Изучение экспертной интегрированной системы RUP” преследует цели ознакомления студентов с принципами построения современных систем управления проектированием (на примере RUP 2003), получения навыков работы с интегрированными продуктами и изучение конкретных процессов автоматизации проектирования.

2.    Общий порядок работы с программным продуктом RUP и принципы его построения.

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

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

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

Продукт Rational Unified Process входит в состав Rational Suite всех комплектаций.

В поставку входит:

·         Интерактивная версия базы знаний в формате HTML.

·         Комплект документов, описывающих процесс

База знаний содержит описания архитектуры процесса и его составляющих (стадий разработки и потоков работ), технологии работы, правил создания различных артефактов: моделей, отчетов, планов и т.д. и порядка использования средств инструментальной поддержки. Интерактивная версия содержит настраиваемые шаблоны, которые позволяют использовать информацию, порожденную в процессе работы над проектом, для создания отчетных документов с использованием Microsoft Word, Microsoft Project и Microsoft FrontPage. Для работы с интерактивной версией Rational Unified Process на  компьютере должен быть установлен Netscape Navigator или Microsoft Internet Explorer. В процессе разработки программного обеспечения также могут потребоваться различного рода инструментальные средства, связанные с RUP, которые предоставляются как фирмой Rational, так и другими продавцами: инструменты моделирования (Rational Rose), инструменты управления требованиями (Rational Requisite Pro), инструменты документирования (Rational SoDa), средства программирования (Rational Apex/Ada, Rational Apex/C++ (Java ready)), инструментальные средства поддержки руководителя проекта (MS Project), инструменты управления задачами (Rational ClearQuest), инструменты управления конфигурацией (ClearCase) и различные средства тестирования (Rational SQA Suite, Rational TestMate, Rational Visual Test).

Интерактивность Rational Unified Process поддерживается множеством гипертекстовых ссылок и интерактивных изображений.

Стандартное окно интерактивной среды Rational Unified Process представлено на рисунке 1:

Рис.  1 Стандартное окно интерактивной среды Rational Unified Process

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

-        Окно просмотра древовидной структуры базы знаний. Расположено в левой части. После нажатия на некоторую ссылку в списке в основном окне отображается соответствующий раздел.

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

Рис.  2 Ссылочная строка в верхней части основного экрана

-        В верхней части окна просмотра древовидной структуры базы знаний расположена инструментальная панель (см. рисунок 3).

Рис.  3 Инструментальная панель окна дерева базы знаний

Верхние две кнопки предназначены для упрощения работы с деревьями базы знаний. Первая кнопка «Where Am I» показывает расположение в дереве страницы (разворачивая его при необходимости), открытой в основном окне. Вторая кнопка «Tree Sets» показывает или скрывает остальные деревья базы знаний на дополнительных вкладках, что удобно, если Вы хотите работать с каким-то одним деревом.

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

-        В шапке окна Rational Unified Process расположена ссылочная инструментальная панель, содержащая кнопки «Glossary» и «Index» (см. рисунок 4).

Рис.  4 Фрагмент ссылочной инструментальной панели в шапке окна

При нажатии кнопки «Glossary» открывается окно, содержащее словарь определений терминов, используемых в базе знаний. Посредством кнопки «Index» осуществляется открытие окна алфавитного указателя всех страниц базы знаний.

3.    Назначение программного продукта RUP.

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

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

—    По содержанию действий участников групп разработки (по основным потокам работ);

—    Во времени (по стадиям жизненного цикла разрабатываемой системы).

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

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

Описание процесса выполняется с двух различных точек зрения:

—    Техническая точка зрения фокусируется на артефактах и представлениях, связанных c разрабатываемым изделием;

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

Рис.  5 Общая архитектура процесса проектирования в двух измерениях.

Динамическая структура RUP состоит из четырех фаз: Начало (Inception), Проектирование (Elaboration), Построение (Construction) и Внедрение (Transition). Фазы могут подразделяться на итерации. Переход с фазы на фазу возможен только после выполнения задач фазы и представляет собой контрольную точку (milestone) процесса.

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

- Бизнес-моделирование (Business modeling);

- Определение требований (Requirements);

- Анализ и Проектирование (Analysis and Design);

- Реализация (Implementation);

- Тестирование (Test);

- Развертывание (Deployment).

И три вспомогательные:

- Управление проектом (Project management);

- Управление конфигурациями (Change management);

- Управление средой проекта (Environment).

4.    Детальное описание разделов RUP.

4.1.         Детальное описание этапа «Построение» (phase: Construction).

В фазе «Построение» (Construction) основными задачами становится быстрая и экономичная разработка кода системы. Во время этой фазы происходит реализация большей части функциональности продукта. К концу фазы система должна быть готова к передаче заказчику для бета-тестирования и/или приемо-сдаточных испытаний.

На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.

Пример хода работ на той фазе представлен на рисунке 6.

 

 

Рис.  6 Пример хода работ на фазе  "Построение" (Construction).

 

Более подробная диаграмма примера хода работ на фазе «Построение» в нотации UML из базы знаний RUP приведена на рисунке 7:

Рис.  7 Диаграмма примера хода работ на фазе «Построение» в нотации UML из базы знаний RUP.

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

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

Итак, основные цели этапа «Построение»:

-        Минимизация цены разработки путем оптимизации ресурсов и избегания ненужных переработок и «отходов производства».

-        Достижение необходимого уровня качества настолько быстро, насколько возможно.

-        Разработка рабочих версий (альфа, бета и других тестовых релизов) настолько быстро, насколько возможно.

-        Завершение анализа, проектирования, разработки и тестирования всей необходимой функциональности.

-        Итерационная и последовательная разработка завершенного продукта, готового к внедрению у конечного пользователя.

-        Решение о готовности программного обеспечения, рабочих мест и пользователей к началу внедрения продукта.

-        Достижение некоторого уровня параллелизма в работе программистов.

4.2.         Детальное описание роли «Менеджер управления изменениями» (Change Control Manager).

Менеджер управления изменениями (Change Control Manager) организует процесс внесения в проект затребованных изменений. В его задачи входит разработка регламента внесения изменений, рассмотрение полученных требований, проверка на возможные повторения, а также контроль выполнения работ по изменениям.

Диаграмма, отображающая деятельность менеджера управления изменениями представлена на рисунке 8:

Рис.  8 Диаграмма деятельности менеджера управления изменениями.

 

4.3.         Детальное описание роли «Бизнес-дизайнер» (Business Designer).

Бизнес-дизайнер принимает участие в разработке модели бизнес-системы.

Диаграмма, отображающая деятельность бизнес-дизайнера представлена на рисунке 9:

Рис.  9 Диаграмма деятельности бизнес-дизайнера

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

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

Business Use Case (бизнес-прецедент) определяет множество экземпляров бизнес-прецедентов, в котором каждый экземпляр представляет собой последовательность выполняемых бизнес-действий, которые приводят к наблюдаемому конкретным бизнес-актером результату.

Business Use Case Realization (реализация бизнес-прецедентов) описывает, как исполнители, бизнес-сущности и бизнес-события кооперируются для выполнения конкретного бизнес-прецедента.

Business Entities (бизнес-сущности) представляют абстракцию некоторой важной постоянной информации в бизнес-системе.

Business Event (бизнес-событие) описывает значимое явление в пространстве и времени, важное для бизнес-системы. Бизнес-события используются для оповещения между бизнес-процессами и обычно связаны с бизнес-сущностями.

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

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

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

Ниже перечислены основные моменты деятельности бизнес-дизайнеров:

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

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

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

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

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

-        Бизнес-дизайнеры отвечают за детализацию бизнес-событий и используют их для разъединения пространства и времени внутри бизнес-процессов.

4.4.         Детальное описание роли «Технический писатель» (Technical writer).

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

Диаграмма, отображающая деятельность технического писателя, представлена на рисунке 10

 

Рис.  10 Диаграмма деятельности технического писателя

 

К человеку, исполняющему обязанности технического писателя предъявляются следующие требования:

-        Опыт технического документирования;

-        Некоторые знания в предметной области, которая будет документироваться;

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

4.5.         Детальное описание потока работ «Закрытие проекта» (Workflow: Close-Out Project).

На рисунке 11 представлена детализация потока работ по подготовке руководителем проекта к его завершению:

Рис.  11 Детализация потока работ по подготовке руководителем проекта к его завершению

 

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

5.    Основные термины RUP.

На основе проделанной выше работы можно выделить основные термины RUP:

Ø  Workflow - последовательность выполняемых бизнес-действий, которые приводят к наблюдаемому конкретным бизнес-актером результату.

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

Ø  Activity – единица труда, которая может быть совершена ролью при необходимости.

Ø  Artifact – порция информации, которая: 1) производится, модифицируется и используется процессом, 2) определяет область ответственности и 3) является объектом контроля версий.

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

 

6.    Выводы.

IBM Rational Unified Process позволяет компании-разработчику настраивать весь процесс разработки ПС. В отличие от большинства современных методологий или требований к процессу разработки, ориентированных на строго определенный уровень формализации процесса (как правило, либо очень высокий, либо напротив, очень низкий), RUP позволяет получить именно тот уровень формализации, который необходим в проекте.

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

7.    Список литературы.

 

1. Л. Новиков «Введение в Rational Unified Process» [Электронный источник]: серия текстовых файлов RUP_txt1.pdf - RUP_txt14.pdf.
2. С. Трофимов «Унифицированный процесс разработки от Rational Software – RUP» [Электронный источник]: интернет-ресурс http://www.interface.ru/home.asp?catId=710 .
3. «Rational Unified Process. Методология и технология». – CM Consult [Электронный источник]: интернет-ресурс http://www.interface.ru/home.asp?catId=710 .