78434

Настройка RUP для использования в рамках УМК «Введение в унифицированный процесс разработки ПО» посредством IBM Rational Method Composer

Дипломная

Информатика, кибернетика и программирование

Цель работы – создание базы знаний по процессу разработки программного обеспечения, который используется в рамках курса «Введение в УП». Методы исследования – теоретический (изучение возможностей RMC), экспериментальный (применение их на практике).

Украинкский

2015-09-20

3.6 MB

0 чел.

Настройка RUP для использования в рамках УМК «Введение в унифицированный процесс разработки ПО» посредством IBM Rational Method Composer

Дипломная работа


Реферат

Дипломная работа 52 с., 52 рис., 13 источников, 2 прил.

 RATIONAL UNIFIED PROCESS, IBM RATIONAL METHOD COMPOSER, RUP, RMC, УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ПО.

 Объект исследования – IBM Rational Method Composer 7.0, унифицированный процесс разработки ПО.

Цель работы – создание базы знаний по процессу разработки программного обеспечения, который используется в рамках курса «Введение в УП».

Методы исследования – теоретический (изучение возможностей RMC), экспериментальный (применение их на практике).

Результат работы - проанализирован и детализирован унифицированный процесс разработки ПО. Создан web-сайт с базой знаний о процессе разработки.

Область применения - сайт предназначен для использования студентами и преподавателями в рамках учебного процесса по курсу «Введение в унифицированный процесс разработки программного обеспечения».


Содержание

Введение

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

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

Во-первых,  испытывают одни и те же сложности и трудности при использовании теоретического материала по унифицированному процессу на практике;

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

Возникла идея создать Учебно-Методический Комплекс «Введение в УП», который автоматизировал бы проведение занятий по предмету и выступал бы хранилищем информации об унифицированном процессе. УМК будет состоять из двух логических частей: технической составляющей и информационной составляющей.

В рамках  написания данной дипломной работы основной задачей было создание схемы стандартного унифицированного процесса, используемого студентами при разработке, и его справочное наполнение. Если перефразировать эту задачу в терминах используемого инструментария, то создание схемы процесса означает настройку стандартного унифицированного процесса от Rational в соответствии с потребностями курса «Введение в унифицированный процесс разработки ПО»; а задача информационного наполнения состоит в организации базы знаний процессов, которую можно было бы создавать, дополнять и публиковать. Для реализации этих требований был выбран IBM Rational Method Composer 7.0.

IBM RMC 7.0 - это инструмент настройки и публикации Web-сайтов на основе RUP. RMC предназначен для того, чтобы внести изменения в RUP, подогнав его под нужды конкретного проекта (в данном случае - курса "Введение в УП").

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

Информационная составляющая, созданная с помощью RMC, позволяет:

Преподавателю обеспечивать студентов справочной информацией (руководствами, примерами исполнения, стандартным видом артефактов)

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

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

Таким образом, УМК одновременно снижает нагрузку на преподавателя и увеличивает эффективность обучения студентов в рамках курса «Введение в УП разработки ПО».

Функционально, задача построения информационной подсистемы УМК разбивается на следующие подзадачи:

1. Анализ предметной области.

2. Знакомство с инструментарием: Rational Method Composer.

3. Составление общей схемы унифицированного процесса.

4. Наполнение УМК справочной и методической информацией. 


  1.  Характеристики унифицированного процесса

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

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

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

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

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

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

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

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

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


  1.  MDA подход к разработке ПО

Под аббревиатурой MDA (Model Driven Architecture) скрывается достаточно новый подход к разработке современных информационных систем. Название этого подхода говорит само за себя - создание приложений базируется на разработке модели приложения.  Причем как понятие приложения, так и понятие модели трактуются в самом широком смысле.

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

Очевидны преимущества, которые дает такой подход:

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

Очевиден и ряд недостатков:

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

Подход MDA возник не на пустом месте. Само его появление и возможность реализации обусловило наличие ряда стандартов и технологий, на практике доказавших свою полезность. Концептуальной основой появления MDA стали спецификации «Архитектура управления объектами» (Object Management Architecture, OMA), «Брокер запросов к объектам» (Object Request Broker, ORB), «Общая архитектура брокера запросов к объектам» (Common Object Request Broker Architecture, CORBA). Перевести замысел в практическую плоскость позволили технологии объектно-ориентированного программирования (ООП), стандарт «Общая метамодель хранилища данных»(Common Warehouse Metamodel,  CWM), языки «Унифицированный язык моделирования» (Unified Modeling Language, UML), «Расширяемый язык гипертекста» (Extensible Markup Language, XML), «Средство мета-объекта» (Meta-Object Facility, MOF). Работами по созданию новой архитектуры программирования занялся консорциум OMG (Object Management Group).

 Object Management Group (OMG) – это консорциум, созданный для развития стандартов распределённых объектно-ориентированных систем. Основной целью являлось создание общей переносимой и ресурсонезависимой объектной модели, которая работала бы для всех типов сред разработки и для всех видов платформ. Был основан в 1989 году 11 компаниями, в их числе: Hewlett-Packard, IBM, Sun Microsystems, Apple Computer, American Airlines и Data General. Сегодня с OMG сотрудничает около 800 организаций — крупнейших производителей программного обеспечения. Сейчас основной целью концерна является моделирование (программ, систем и бизнес-процессов) и создание стандартов в области моделирования. [9, перевод]

По мнению создателей, подход MDA является новым витком эволюции технологий программирования, так как описывает процесс разработки в целом. Можно возразить, что процесс разработки программного обеспечения описан и стандартизован вдоль и поперек: в нашей стране существует ряд ГОСТов, другие страны также имеют соответствующие стандарты. Но новизна MDA заключается в том, что описание процесса разработки в ней выполнено с использованием современных средств представления и позволяет автоматизировать создание приложений. И весьма вероятно, что через некоторое время подход MDA станет общим промышленным стандартом в разработке программного обеспечения.

  1.   Основные понятия

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

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

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

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

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

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

Вычислительно-независимая модель - модель, скрывающая любые детали реализации и процессов системы; описывает только требования к системе и ее окружению.

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

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

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

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

  1.   Принципы разработки приложений на основе моделей

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

  1.  Типы моделей

Рассмотрим типы моделей, используемых в архитектуре MDA.

Вычислительно-независимая модель (Computation Independent Model, CIM) описывает общие требования к системе, словарь используемых понятий и условия функционирования (окружение). Модель не должна содержать никаких сведений технического характера, описаний структуры и функционала системы. CIM максимально общая и независимая от реализации системы модель. Спецификация MDA подчеркивает, что CIM должна быть построена так, чтобы ее можно было преобразовать в платформенно-независимую модель. Поэтому CIM рекомендуется выполнять с использованием унифицированного языка моделирования UML.

Платформенно-независимая модель (Platform Independent Model, PIM) описывает состав, структуру, функционал системы. Модель может содержать сколь угодно подробные сведения, но они не должны касаться вопросов реализации системы на конкретных платформах. Модель PIM создается на основе CIM. Для создания модели используется унифицированный язык моделирования UML.

Платформенно-зависимая модель (Platform Specific Model, PSM) описывает состав, структуру, функционал системы применительно к вопросам ее реализации на конкретной платформе. В зависимости от назначения модель может быть более или менее детализированной. Модель создается на основе двух моделей. Модель PIM служит основой модели PSM. Модель платформы используется для доработки PSM в соответствии с требованиями платформы.

Модель платформы описывает технические характеристики, интерфейсы, функции платформы. Зачастую модель платформы представлена в виде технических описаний и руководств. Модель платформы используется при преобразовании модели PIM в модель PSM. Для целей MDA описание модели платформы должно быть представлено на унифицированном языке моделирования UML.

  1.  Уровни модели

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

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

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

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

  1.  Этапы разработки

Процесс разработки разбивается на три этапа. На первом этапе разрабатывается вычислительно-независимая модель (CIM). Часто модель, создаваемую на этом этапе, также называют доменной или бизнес-моделью. Цель данного этапа разработка общих требований к системе, создание общего словаря понятий, описание окружения, в котором система будет функционировать. Сущности, описываемые в модели CIM этого этапа, должны тщательно анализироваться и отрабатываться. Право на включение в модель должны иметь только те элементы, которые будут использованы и развиты на последующих этапах разработки. Для создания модели CIM на данном этапе можно использовать любые средства. Однако для совместимости с последующими этапами весьма желательно иметь описание модели на языке UML. Следует учитывать, что модель CIM первого этапа представляет собой скорее общую концепцию системы и не является насущно необходимой для процесса разработки приложения. При создании небольших программных систем этот этап можно опустить, однако при работе со сложными проектами он становится почти обязательным. К примеру, разработка текстового технического задания, казалось бы, никак не помогает собственно процессу программирования, зато, существенно способствует пониманию задачи в целом и позволяет избежать грубых ошибок проектирования в дальнейшем. На втором этапе разрабатывается платформенно-независимая модель (PIM). Она может разрабатываться с нуля в случае отсутствия модели первого этапа или основываться на CIM. Преобразование CIM в PIM осуществляется на основе описания на зыке UML, созданного на первом этапе. Здесь в него добавляются элементы, описывающие бизнес-логику, общую структуру системы, состав и взаимодействие подсистем, распределение функционала по элементам, общее описание и требования к пользовательскому интерфейсу. Модель PIM этого этапа обязательно включается во все автоматизированные среды разработки приложений на основе MDA. (см. рис. 1)

рис. 1  Схема преобразования моделей.

На третьем этапе создаются платформенно-зависимые модели (PSM). Их число соответствует числу программных платформ, на которых будет функционировать приложение. Кроме этого, возможны случаи, когда приложение (или его составные части) должны работать на нескольких платформах одновременно. Модель PSM создается путем преобразования модели PIM с учетом требований модели платформы. Процесс преобразования описывается ниже. На этапе создания модели PSM разработка приложения согласно архитектуре MDA заканчивается. Считается, что правильно построенная PSM содержит техническую информацию, достаточную для генерации исходного кода (там, где это возможно) и необходимых ресурсов приложения. Здесь эстафетную палочку должна подхватить среда разработки, реализующая MDA. Однако архитектура MDA описывает еще один вариант прохождения третьего этапа, который называется прямым преобразованием в код. Спецификация MDA для этого случая сообщает, что могут существовать инструментарии, напрямую преобразующие модель PIM в исполняемый код приложения. Модель PSM при этом может создаваться как контрольное описание, позволяющее проверить результат прямого преобразования. [10]

Таким образом, основная цель MDA — минимизация затрат, связанных с привязкой к конкретным системным платформам и программным инфраструктурам, путём уменьшения зависимости ИС от технологий реализации. Для этого вводятся вышестоящие уровни описаний программной системы и предметной области, на основе которых в идеале решается или облегчается задача генерации программного кода, настроек, параметров и т.п. для различных платформ. Это позволяет, при необходимости, применяя незначительные затраты, сгенерировать модифицированную ИС для функционирования на совершенно другой платформе и с использованием отличных технологий. [11]

Подход MDA применим не только в рамках классических программных приложений, но и, при наличии соответствующего инструментария, для построения специфических приложений. Именно таким инструментарием является Rational Method Composer, позволяющий генерировать web-сайты с информацией о процессе разработки на основе модели этого процесса.


  1.  Основные концепции RMC 

 IBM RMC - это инструмент настройки и публикации Web-сайтов на основе RUP. RMC предназначен для того, чтобы внести изменения в RUP, подогнав его под нужды конкретного проекта (в данном случае - курса "Введение в УП").

  1.   Содержание Методик и Процессов

Фундаментальным принципом RMC является разделение Содержания Методик (Method content), которое может быть повторно используемо, от конкретных Процессов разработки, в которых оно используется. Содержание Методик описывает, что должно быть создано, необходимые навыки и приводит пошаговое объяснение, как достигаются конкретные цели разработки. Это описание методик не зависит от описания жизненного цикла разработки. На основе Содержания Методик создаются Процессы в виде последовательностей действий, которые адаптируются к типам конкретных проектов. Таким образом, жизненный цикл (Процесс) отображает изменения работы выполняемой в рамках различных дисциплин (Методики). (см. рис. 2)

рис. 2 Разделение содержания Методик и Процесса

Для создания Методик в RMC используется стандартизированный подход. В метамодели выделяется набор Ролей (Roles), представляющих совокупность связанных навыков, знаний и ответственностей команды разработчиков. Эти Роли ответственны за определенные типы Рабочих Продуктов (Work Product), например тестировщики за план тестирования, а менеджеры проектов за проектный план. Для создания или изменения Рабочих Продуктов Ролям присваиваются Задачи (Tasks), которые на входе и выходе имеют специфичные типы Рабочих Продуктов.

Ключевые элементы RMC можно разбить на Содержание Методик и Процесса. Содержание Методик в основном описывается через Рабочие Продукты, Задачи, Роли и Руководства. Руководства (Guidance), такие как Чек-Листы (check-list), Примеры (example) или Планы Действий (roadmap) могут также быть созданы для предоставления дополнительной информации о Процессе. Элементы RMC, используемые для описания Процессов, это Активности (activity), которые могут быть вложены друг в друга для представления декомпозиции Работ (Пример вложенностей Активностей: Инициализация проекта\Создание проектной среды\ Создание Outlook папок). Также могут быть определены связи Активностей между собой для определения потока работ (workflow). Активности в свою очередь содержат Дескрипторы (descriptor), которые ссылаются на Содержание Методик. Активности используются для создания Процессов, которых в RMC два типа: Процесс Разработки (delivery process) и Процесс Ключевой Области разработки(capability pattern). (см. рис 3)

рис. 3  Ключевые элементы IBM RMC

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

  1.   Дескрипторы

Ключевой концепцией разделения Методик (базы знаний процессов) и Процесса разработки является Дескриптор (Descriptor). Дескриптор является Элементом Процесса, который представляет использование элемента Содержания Методик в Процессе. Дескриптор представляет вхождение одного конкретного элемента Методик, такого как Роль, Задача или Рабочий Продукт в Активности. Дескрипторы являются прокси-подобными представлениями этих элементов внутри декомпозиции работ. Кроме установления ссылки на элементы Методик они позволяют переопределять структуру связей с другими элементами Методик путем определения собственной структуры ссылок Дескриптора.

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

  1.   Элементы RMC

 Библиотека Методик

 Библиотека Методик (Method library) является контейнером, содержащим в себе Подключаемые Методики (Method plug-in) и определения Конфигураций Методик (Method configuration). Все элементы Методик сохраняются в Библиотеке Методик.

 Подключаемая Методика

 Подключаемая Методика (Method Plug-In) является контейнером содержания методик и процессов. Подключаемые Методики, Содержания Методик и Пакеты Содержаний (Content Package) позволяют организовать ваши Методики с уровнем детализации, подходящим для создания и повторного использования.

 Пакет Содержаний

 Пакет Содержаний (Content Package) состоит из элементов Методик, таких как Роли, Задачи, Рабочие Продукты и Руководства.

 Конфигурация Методик (Method configuration)

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

Процесс Разработки (Delivery process)

 Процесс Разработки представляет собой полный и интегрированный подход к выполнению определенного вида проектов. Он представляет модель полного жизненного цикла проекта, который детализируется путем выстраивания последовательности ссылок на Содержание Методик в структуре декомпозиции (breakdown structure). [3]


  1.  Анализ унифицированного процесса в рамках курса «Введение в унифицированный процесс разработки ПО».

  1.   Общая структура процесса

Процессом называется частично упорядоченное множество шагов, направленных на достижение некоторой цели. [2]

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

Для обеспечения этой цели, было решено структурировать всю информацию о процессе по фазам разработки:

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

Начало (Inception) - определение бизнес-целей проекта.

Построение (Elaboration) - разработка плана и архитектуры проекта.

Реализация (Construction) - постепенное создание системы.

Внедрение (Transition) - поставка системы конечным пользователям.

Фазы начала и исследования охватывают проектные стадии жизненного цикла процесса разработки; фазы построения и внедрения относятся к производству. [2]

Внутри каждой фазы происходит несколько итераций.

Итерация (Iteration) представляет полный цикл разработки, от выработки требований во время анализа до реализации и тестирования. Конечным результатом является выпуск готового продукта.[2]

В рамках данной дипломной работы было установлено, что в общем случае фазы «Начало», «Построение» и «Реализация» состоят из двух итераций, а фаза «Реализация» - из трёх. Каждая итерация занимает 2 недели. Отчасти такое разделение обуславливается типом задач, которые предлагаются студенческим командам для решения, отчасти длиной стандартного учебного семестра.

  1.   Фаза Начало
    1.  Первая итерация

В фазе Начало принимают участие в основном только Менеджер проекта, Архитектор и Системный Аналитик. Во второй итерации фазы Начало к ним присоединяются Спецификатор ВИ и Аналитик ВИ (см. рис.  4), но объём их работы невелик.

рис. 4  Распределение ролей по итерациям фазы Начало

На первой итерации фазы Начало происходят следующие действия:

Системный аналитик выполняет следующие задачи (см. рис 5):

рис. 5  Задачи системного аналитика на первой итерации фазы Начало.

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

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

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

Менеджер проекта выполняет следующие задачи (см. рис 6):

рис. 6  Задачи менеджера на первой итерации фазы Начало.

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

Затем менеджер начинает выявлять риски, с которыми может столкнуться проект. Основным исполнителем этого артефакта является менеджер, но фактически его создаёт и архитектор (в разделе «Технические риски»). Менеджер отвечает за всевозможные организационные риски и за компиляцию всех идентифицированных рисков в один документ.

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

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

Архитектор на первой итерации первой фазы начинает формировать широкое, но неглубокое описание системы. В результате выполнения задач «Анализировать архитектуру» и «Проектировать архитектуру» он получает первые наброски моделей проектирования, реализации и развёртывания. (см. рис 7)

рис. 7 Задачи архитектора на первой итерации фазы Начало.

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

  1.  Вторая  итерация

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

рис. 8  Задачи менеджера на второй итерации фазы Начало.

Цель всех действий менеджера на данной фазе – принять решение, заниматься ли разработкой этого проекта вообще, и если да, то на каких условиях.

Основной деятельностью системного аналитика является создание и развитие модели вариантов использования, для чего он выполняет задачу «Структурировать модель ВИ». (см. рис 9)

Рис. 9  Задачи системного аналитика на второй итерации фазы Начало 

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

Архитектор продолжает развитие созданных ранее моделей (проектирования, реализации, развёртывания). Обязательной задачей является упорядочивание вариантов использования по приоритетам. Эта задача выполняется совместно с аналитиком (который представляет интересы заказчика) и её цель – определить среди всех вариантов использования архитектурно значимые, т.е. те, реализация которых должна обязательно войти в архитектуру системы. (см. рис 10)

Не обязательным, но очень желательным и полезным (прежде всего, для команды разработчиков) является создание базового уровня архитектуры – это одно из возможных решений реализации архитектурно-значимых вариантов использования. БУА может быть очень концептуальным, но уже сам факт его создания означает, что задача, поставленная перед командой разработчиков, имеет как минимум одно решение.

рис. 10  Задачи системного аналитика на второй итерации фазы Начало 

Плюс к разработке БУА архитектор может разработать ещё один вид прототипа системы - не эволюционный (коим является базовый уровень архитектуры), а т.н. «выбрасываемый», который служит только одной цели и «выбрасывается» сразу после того, как результаты были получены. На данном этапе имеет смысл построения исследовательского и поведенческого прототипов. Исследовательский прототип создаётся для того, чтобы проверить самые основные допущения проекта касательно функциональности, технологии, или и того, и другого. Поведенческий же может не реализовывать никакой функциональности, а только давать представление о поведении системы. Поведенческие прототипы очень эффективны при анализе и проектировании сетевых приложений, особенно тех, в которых используются транзакции, где больше всего используются окна диалога с системой.

Таким образом, построение небольшого прототипа при минимуме затрат может принести проекту существенную пользу.

Цель всех действий архитектора на данной фазе – определить, как будет реализовываться будущая система.

Спецификатор вариантов использования начинает работу по описанию ВИ. (см. рис. 11)

рис. 11  Задачи спецификатора вариантов использования на второй итерации фазы Начало 

К концу первой фазы разработки должно быть описано порядка 10% от общего числа ВИ системы.

Анализатор ВИ анализирует описанные спецификатором ВИ. (см. рис 12)

рис. 12  Задачи анализатора вариантов использования на второй итерации фазы Начало 

К концу первой фазы разработки должно быть проанализировано порядка 5% от общего числа ВИ системы.

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

Вот краткий список всех артефактов, созданных в результате прохождения командой фазы Начало (см. рис. 13):

рис. 13  Список  артефактов, полученных в результате фазы Начало.

  1.   Фаза Проектирование
    1.  Первая итерация

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

рис. 14  Список  членов команды, участвующих в деятельности на фазе Разработка.

Менеджер продолжает составлять планы и контролировать весь процесс. Задача менеджера – «вести наступление» на риски, т.е. делать всё для того, чтобы снижать вероятность возникновения новых рисков, снижать вероятность возникновения уже определённых рисков и минимизировать вероятный ущерб от наступления уже определённых. (см. рис 15)

рис. 15  Задачи менеджера на первой итерации фазы Проектирование. 

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

рис. 16  Задачи системного аналитика на первой итерации фазы Проектирование.

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

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

Продолжает разрабатывать модели проектирования, реализации и развёртывания.

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

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

рис. 17 Задачи архитектора на первой итерации фазы Проектирование.

Спецификатор ВИ продолжает описывать архитектурно значимые варианты использования. (см. рис 18)

рис. 18 Задачи спецификатора вариантов использования на первой итерации фазы Проектирование 

Аналитик ВИ продолжает анализировать варианты использования, но параллельно с этим он начинает проектировать проанализированные ВИ. (см. рис 19)

рис. 19 Задачи анализатора вариантов использования на первой итерации фазы Проектирование.

Инженер по тестированию начинает разработку плана тестирования, модели тестирования и разработку тестов для уже созданного программного кода. Он же отвечает за принятие решения по полученным результатам тестирования. (см. рис 20)

рис. 20 Задачи анализатора вариантов использования на первой итерации фазы Проектирование. 

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

рис. 21 Задачи разработчика ПО на первой итерации фазы Проектирование 

Системный интегратор начинает интегрировать все получаемые результаты в одну сборку (см. рис 22):

рис. 22 Задачи системного интегратора на первой итерации фазы Проектирование

Тестер целостности и системный тестер проводят тестирование. Результаты тестирования затем передаются инженеру по тестированию. (см рис 23, 24)

рис. 23 Задачи тестера целостности на первой итерации фазы Проектирование.

рис. 24 Задачи системного тестера на первой итерации фазы Проектирование.

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

  1.  Вторая итерация

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

рис. 25 Задачи менеджера на второй итерации фазы Проектирование 

Аналитик продолжает разрабатывать модель вариантов использования. К концу фазы Проектирование модель вариантов использования должна быть закончена как минимум на 80%. (см. рис 26)

рис. 26 Задачи системного аналитика на второй итерации фазы Проектирование.

Спецификатор ВИ продолжает описывать варианты использования. К концу фазы проектирование должно быть описано 40-80% от всех ВИ будущей системы. (см. рис 27)

рис. 27 Задачи спецификатора вариантов использования на второй итерации фазы Проектирование 

Анализатор ВИ продолжает анализировать и проектировать ВИ. К концу фазы проектирование должно быть проанализировано 20-40% и спроектировано около 10% от всех вариантов использования будущей системы. (см. рис 28)

рис. 28 Задачи анализатора вариантов использования на второй итерации фазы Проектирование 

Архитектор продолжает проектировать и реализовывать базовый уровень архитектуры.(см. рис 28)

рис. 29 Задачи архитектора на второй итерации фазы Проектирование 

Разработчик делает все те же действия, что и на первой итерации фазы, но уже в большем объёме. (см. рис 30)

рис. 30 Задачи разработчика на второй итерации фазы Проектирование

Инженер по тестированию продолжает разработку модели тестирования, разработку тестовых сценариев и оценивание результатов тестирования. (см. рис 31)

рис. 31  Задачи архитектора на второй итерации фазы Проектирование 

Системный интегратор интегрирует различные подсистемы в одну сборку. (рис. 32)

рис. 32 Задачи системного архитектора на второй итерации фазы Проектирование 

Тестер целостности и системный тестер проводят тестирование. (см. рис 33, 34)

рис. 33  Задачи тестера целостности на второй итерации фазы Проектирование.

рис. 34 Задачи системного тестера на второй итерации фазы Проектирование.

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

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

Вторая же итерация должна обеспечить широту рассмотрения проблемы (так называемый архитектурный охват). [12]. Главное на второй итерации - это обеспечить архитектурную основу для разрабатываемого приложения. Архитектурная основа означает, что принятые на этом этапе решения в дальнейшем будут выступать в роли фундамента системы. В принципе в архитектуру могут быть внесены изменения, но при этом желательно избежать коренной переработки архитектуры, если только такая работа не связана с решением критических проблем. [12].

Вот список артефактов, разработанных командой к концу фазы Проектирование (см. рис 35):

рис. 35 Список артефактов, разработанных в результате фазы Проектирование

  1.   Фаза Реализация
    1.  Типовая итерация

На фазе реализации работает абсолютно вся команда, по сравнению с фазой Проектирование добавляется дизайнер пользовательского интерфейса. (см. рис 36)

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

Менеджер продолжает составлять планы и контролировать список рисков. Очень важно, чтобы менеджер обновлял список рисков каждую итерацию, т.к. созданный в начале проекта и затем замороженный список рисков несёт в себе мало пользы - может наступить такая непредвиденная ситуация, которую нельзя было даже предположить в начале проекта. (см. рис 37)

рис. 37 Задачи системного тестера на фазе Реализации. 

Системный аналитик заканчивает структурировать модель вариантов использования, если он ещё не сделал этого при окончании фазы Проектирования. (см. рис 35)

рис. 38 Задачи системного аналитика на фазе Реализации. 

Спецификатор вариантов использования продолжает специфицировать ВИ – подробные спецификации вариантов использования нужны уже не столько для проектирования и реализации, сколько для тестирования, написания руководств пользователя и, в перспективе, сдачи проекта заказчику. (см. рис 39)

рис. 39  Задачи спецификатора вариантов использования на фазе Реализации

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

рис. 40  Задачи дизайнера пользовательского интерфейса на фазе Реализации 

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

рис. 41  Задачи архитектора на фазе Реализации 

Анализатор вариантов использования продолжает анализировать и проектировать ВИ, но сейчас его деятельность по проектированию является обязательной, а по анализу – нет, потому что модель анализа не обязательно должна поддерживаться на всём протяжении проекта, во многих случаях хватает только модели анализа базовой архитектуры. (см. рис 42)

рис. 42 Задачи анализатора вариантов использования на фазе Реализации

Разработчик продолжает свою обычную деятельность по реализации системы. Так как основная цель фазы Построение это создание готового программного продукта, то естественно, что именно программирование это самое трудоёмкая и времязатратная деятельность. (см. рис 43)

рис. 43 Задачи разработчика программного обеспечения на фазе Реализации.

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

рис. 44 Задачи инженера по тестированию на фазе Реализации.

Системный интегратор интегрирует систему. Интегрирование задача непрерывная, но в рамках любого проекта команде необходимо определиться, насколько часто будут производиться выпуски, и составить план интегрирования. Если в рамках фазы Проектирование  этот план достаточно условен, интеграция не цель, то на фазе Реализация он играет очень важную роль, более того, иногда логика интеграции может доминировать над приоритетами вариантов использования. [12]. (см. рис 45)

рис. 45 Задачи системного интегратора на фазе Реализации.

Тестер целостности и системный тестер регулярно проводят тестирование. (см. рис 46, 47)

рис. 46 Задачи тестера целостности на фазе Реализация.

рис. 47 Задачи системного тестера на фазе Реализация

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

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

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

Вот список артефактов, реализованных на фазе Построение. (см. рис. 48)

рис. 48 Список артефактов, полученных на фазе Реализация

  1.   Фаза Внедрение
    1.  Типовая итерация

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

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

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


Заключение

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

 Изучены возможности IBM RMC  для настройки RUP под конкретный процесс и для публикации web-сайта процесса.

 Разработана и реализована с помощью IBM RMC полная модель процесса разработки ПО, предназначенная для целей УМК.

 Созданная модель наполнена справочной и методической информацией в соответствии с потребностями курса «Унифицированный процесс разработки ПО».


Список использованных источников и литературы

  1.  Кратчен Ф., Кролл П. Rational Unified Process - это легко. Руководство по RUP для практиков – М.: Кудиц-Образ, 2004 – 432с.
  2.  Буч Г. Язык UML. Руководство пользователя – М.: ДМК, 2006 – 496с.
  3.  Моделирование процессов разработки ПО и создание сайтов процессов с помощью Rational Method Composer [Электронный ресурс]: Режим доступа - http://www.ibm.com/developerworks/ru/library/rmc-model/, свободный.
  4.  Скотт К. Унифицированный процесс. Основные концепции – М.: Вильямс, 2002 – 160с.
  5.  Унифицированный процесс разработки от Rational Software [Электронный ресурс]: Режим доступа - http://www.caseclub.ru/articles/rup2.html, свободный.
  6.  IBM Rational Unified ProcessWikipedia [Электронный ресурс]: Режим доступа - http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process, свободный.
  7.  IBM replacing Rational Process Workbench [Электронный ресурс]: Режим доступа - http://www.infoworld.com/article/05/10/19/HNrupwork_1.html, свободный.
  8.  John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 18.
  9.  Object Management Group - Wikipedia[Электронный ресурс]: Режим доступа -  http://en.wikipedia.org/wiki/Object_Management_Group, свободный.
  10.  Архитектура, управляемая моделью [Электронный ресурс]: Режим доступа -  http://www.citcity.ru/11353/, свободный
  11.  Журнал «Мир ПК»: Разработка на основе моделей – Тарасов С. [Электронный ресурс]: Режим доступа - http://www.osp.ru/pcworld/2007/06/4301640, свободный.
  12.  Змеев О.А. Введение в Унифицированный Процесс – в печати.
  13.  Гради Буч, Дж. Рамбо, А. Якобсон. Унифицированный процесс разработки программного обеспечения – СПб.: Питер, 2002 г – 496 с.


Приложение А. Руководство программиста

  1.  Создание Библиотеки Методик

Для создания с нуля Процесса Разработки первым шагом необходимо создать Библиотеку Методик. Для этого выбираем в меню File\New\Method Library и заполняем название библиотеки и путь, по которому она будет храниться.

Рис. 49 Создание Библиотеки Методик

  1.  Создание Подключаемых Методик

В результате предыдущего действия у нас создалась пустая Библиотека Методик, в которой теперь нужно создать Подключаемую Методику. В меню выбираем File\New\Method Plug-in. Выбираем имя и сохраняем Методику.

  1.  Создание Пакета Содержаний

В контекстном меню листа Content Packages в Представлении библиотеки, открывающемуся по щелчку правой кнопкой мыши, выбираем New\Content Package. Именуем и сохраняем Пакет Содержаний. В результате выполненных шагов у нас сформировалась структура для создания и редактирования содержания Методик.

Рис. 50 Создание Пакета Содержаний

  1.  Создание элементов Методик
    1.  Создание Ролей. Для создания Роли выбираем лист Roles и в контекстном меню, открывающемся по щелчку правой кнопкой мыши выбираем New\Role. В открывшемся редакторе (Content Editor) для каждой Роли заполняем поля значениями и сохраняем роль.
    2.  Создание Рабочих Продуктов. Для создания Рабочего Продукта выбираем лист Work Products и в контекстном меню, открывающемся по щелчку правой кнопкой мыши, выбираем New и в зависимости от типа создаваемого продукта либо Artifact либо Deliverable либо Outcome. В открывшемся редакторе (Content Editor) заполняем для каждого Рабочего Продукта поля значениями и сохраняем Рабочий Продукт.
    3.  Создание Задач. Для создания Задачи выбираем лист Tasks и в контекстном меню, открывающемся по щелчку правой кнопкой мыши, выбираем New\Task. В открывшемся редакторе (Content Editor) заполняем для каждой Задачи поля значениями и сохраняем Задачу. Для того чтобы указать, кто выполняет Задачу надо перейти на закладку Roles и выбрать Роль ответственную за выполнение Задачи (Primary performer), которая может быть только одна и Роли участвующие в выполнении Задачи (Additional performers). Для указания Рабочих Продуктов надо перейти на вкладку Work Products и выбрать Рабочие Продукты, которые являются основной входной информацией (Mandatory inputs), дополнительной входной информацией (Optional inputs) и информацией на выходе из Задачи (Outputs).
  2.  Создание Конфигурации Методик

Выбираем лист Configurations в дереве Представления Библиотеки Методик. Выбираем New\Method Configuration в контекстном меню, появляющемся по щелчку правой кнопкой мыши. Вводим имя Конфигурации Упрощенная методология в поле Name и переходим в редакторе на вкладку Plug-in and Package Selection. Выбираем все элементы нашей Подключаемой Методики для использования в созданной Конфигурации.

Рис. 51 Создание Конфигурации Методик

  1.  Создание Процесса Разработки

Выбираем лист Delivery Processes в дереве Представления Библиотеки Методик. Выбираем New\ Delivery Process в контекстном меню. Вводим имя Процесса и выбираем созданную конфигурацию как Default Configuration в появившемся диалоге New Process Component. В появившемся диалоговом окне Switch Configuration выбираем Yes. Сохраняем наш Процесс и переходим к его редактированию.

  1.  Редактирование Процесса Разработки.

Для начала в Представлении Конфигураций находим Упрощенный процесс и дважды кликаем по нему для начала редактирования. Переходим на закладку Work Breakdown Structure.

  1.  Создадим фазы Процесса. Для этого в редакторе выберем Упрощенный процесс и в контекстном меню выберем New Child\Phase. Создаём фазу Начало и две её итерации.
    1.  Теперь добавим к фазам Дескрипторы Задач, определенных в нашей Методике. Для этого в Представлении Конфигурации Методик откроем лист Disciplines\Uncategorized Tasks\ и перенесем дескрипторы (drug and drop) на нужную итерацию фазы Начало в редакторе.
    2.  Для переопределения свойств нужно выделить Дескриптор в окне редактора и изменить его свойства в окне Properties (Для активации окна нужно выбрать Window \ Show View \ Other \ Properties).
  2.  Публикация сайта процесса

Для публикации сайта, необходимо добавить в определение Конфигурации представление, которое будет отображаться на сайте.

Для начала создадим произвольную категорию (Custom category). В Представлении Библиотеки выделяем лист Custom Categories и в контекстном меню выбираем New\Custom Category. Называем новую категорию. Переходим на вкладку Assign и добавляем в поле Content Elements созданный нами процесс разработки. Теперь в контекстном меню категории Представление методологии выбираем меню New\Custom Category, называем новую категорию Роли, переходим на вкладку Assign и добавляем в поле Content Elements Роли: все роли, которые мы хотим опубликовать. Аналогичным образом создаем категории Задачи и Рабочие продукты.

Для того чтобы созданное нами представление отображалось по умолчанию, нажимаем на кнопку Make default, сохраняем изменения. Выбираем в меню Configuration\Publish, в первом окне нажимаем Next, указываем название сайта и путь где будет размещен набор html-страниц на диске, нажимаем Finish.

Для корректной работы опубликованного сайта на клиентской машине необходимо установить Java Runtime Environment (JRE)


Приложение Б. Руководство пользователя

Сгенерированный RMC сайт состоит из двух логических частей: дерева процесса и панели содержимого процесса.

Дерево процесса, созданное по умолчанию, является  доступным пользователю только на просмотр. Для того чтобы изменить в нём что-нибудь, нужно сначала сохранить это дерево как своё. Для этого нужно нажать SaveAs на кнопке над деревом процесса. В созданном дереве можно: добавлять новые элементы, переименовывать имеющиеся и перегруппировывать любые элементы по любым категориям. Для того чтобы добавить новый элемент, нужно нажать на кнопку Add New Node. Для перегруппирования можно либо перетащить элемент в другую категорию (drag-and-drop), либо нажать на кнопку Add From Default и добавить элемент из списка.

В панели содержимого (рис. 13) процесс описывается с точки зрения: Work Breakdown Structure, Team Allocation, Work Product Usage. Во вкладке Work Breakdown Structure отображается, какие задачи запланированы на каждой из фаз. Team Allocation показывает, участники с какими ролями принимают участие на каждой из фаз. Work Product Usage показывает, какие рабочие продукты создаются на каком этапе разработки.

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

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

Рис. 52 Диаграмма для системного аналитика и его ролей и артефактов.


 

А также другие работы, которые могут Вас заинтересовать

66030. Антикризисная политика ЕС 254.54 KB
  Особенности кризиса для стран ЕС Охватив своим масштабам большинство стран мира экономический кризис немного по-разному повлиял на различные мировые капиталистические центры. Одна из очевидных особенностей стран ЕС связанная с экономическим кризисом ...
66031. Российская модель бюджетного федерализма 15.31 KB
  Основы бюджетного федерализма. Особенностью российского бюджетного федерализма является наличие значительного разрыва в уровне бюджетной обеспеченности субъектов Федерации. Модели бюджетного федерализма Существует несколько приоритетных моделей построения...
66034. Разработка и оптимизация конструкции регулирующего клапана (РК) DN125 для системы САОЗ ВД энергоблока АЭС с ВВЭР-1000 малой серии 7.73 MB
  Цель работы: обеспечение безопасности работы реакторных установок В-320 и В-338 при речах 1 контура, компенсируемых работой САОЗ ВД на основе подхода управляемого снижения давления 1 контура с регулированием расхода впрыска борного расхода...
66035. Глобализация финансов 17.21 KB
  В глобализации финансов часто усматривают причину роста спекуляций и отвлечения со спекулятивными целями капитала от производства и создания новых рабочих мест. Процесс финансовой глобализации сконцентрирован прежде всего в трех основных центрах мировой экономики...
66036. Бюджетный дефицит. Виды и меры по его ликвидации в России 52 KB
  Виды дефицита бюджета В тех случаях когда имеющиеся у бюджета доходы недостаточны для осуществления расходов говорят о возникновении бюджетного дефицита.Бюджетный дефицит не обязательно свидетельствует о каком-то чрезвычайном положении в экономике страны.
66038. НАЛОГОВЫЕ СИСТЕМЫ ЗАРУБЕЖНЫХ СТРАН 18.27 KB
  Отличительная черта налоговой системы Франции высокая доля взносов в фонды социального назначения ФСН. Эластичность налоговой системы заключается в том что ежегодно в соответствии с изменениями политической и экономической конъюктуры законодательно уточняются ставки налогов.