Программное Обеспечение Ibm Rational. Методология И Инструментальные Средства Разработки Программных Систем

Программное обеспечение IBMRational. Методология и инструментальные средства разработки программных систем

Вместо введения

Недавно перебирал старые материалы с прошлых мест работ. Когда-то я готовил брошюру для публикации ее в IBM. Не просто брошюру, а описание средств IBM Rational:немного методологии, немного технологии и много инструментов.

Актуальность брошюры и сейчас достаточно высока, но многих тулов уже давно нет, еще больше добавилось.

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

Так как труд был коллективным, то я упомяну всех, кто участвовал в написании данного документа:

• Алексей Закис
• Наталья Шкляева
• Виктор Ематин
• Дмитрий Лапыгин
• Сергей Шмаков
• и я – Александр Новичков

Содержание

Историческая справка

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

IBM Rational Unified Process

1 Подход к разработке

2 Четко определенный процесс

3 Готовый продукт

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

6 <Дух RUP>

8 RUP и другие подходы к разработке ПО

9 Внедрение RUP

10 Адаптация RUP. IBM Rational Process Workbench

11 База знаний и опыта. IBM Rational Developer Network

Инструментальная поддержка RUP

1 Бизнес-моделирование. IBM Rational Rose

3 Визуальное моделирование и генерация кода. Семейство инструментов IBM Rational XDE

4 Управление требованиями. IBM Rational RequisitePro

5 Разработка. IBM Rational Rapid Developer

6 Автоматизированное тестирование

1 Поиск узких мест в производительности. IBM Rational Quantify

2 Поиск ошибок с распределением памяти. IBM Rational Purify

3 Оценка области охвата кода. IBM Rational PureCoverage

4 Планирование тестирования и отчетность. IBM Rational TestManager

5 Запись и воспроизведение скриптов тестирования. IBM Rational Robot

6 Тестирование надежности. IBM Rational TestFactory

7 Контроль качества. IBM Rational QualityArchitect

7 Автоматизация документирования. IBM Rational SoDA

8 Управление изменениями. IBM Rational ClearQuest

9 Конфигурационное управление. IBM Rational ClearCase

Интеграция методологии и инструментальных средств IBM Rational со средствами разработки сторонних компаний

1 Типовые решения. IBM Rational Suite

1 IBM Rational Suite Team Unified Platform

2 IBM Rational Suite AnalystStudio

3 IBM Rational Suite DevelopmentStudio

4 IBM Rational Suite TestStudio

5 IBM Rational Suite ContentStudio

6 IBM Rational Suite Enterprise

Программное обеспечение IBM Rational

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

Историческая справка

Компания Rational Software была основана Полом Леви (Paul Levy) и Майком Девлином (Mike Devlin) в 1981 г. Их вдохновили перспективы влияния программного обеспечения (ПО) на мировую экономику. С тех пор важность программных систем (ПС) как двигателя мировой экономики и существенного элемента в конкурентной борьбе компаний, услуг и продуктов постоянно растет.

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

Rational Software вывела свой первый продукт на рынок в конце 1984 г. За прошедшие двадцать с небольшим лет она выросла в мощную, высокотехнологичную компанию с 26 тысячами организаций-клиентов, которые используют более 432 тысяч лицензий на ее продукты, и эти цифры постоянно растут.

В 2002 году компания Rational вошла в состав компании IBM.

Ежегодный доход компании – более 500 млн. долл.

В компании работает около 3300 человек в 70 офисах, расположенных по всему миру.

49 компаний из списка “Fortune-50″ и 45 компаний из списка “USA Today e-Business 50″ используют в своей работе продукты Rational Software.

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

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

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

• • превышение сроков исполнения и бюджета программных проектов;

  • низкое качество производимых продуктов;

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

  • отсутствие реальной информации обо всех обнаруженных ошибках и ходе их устранения;

  • невозможность получения развернутых показателей качества программной системы и ее компонентов;

  • отсутствие механизмов управления несколькими проектами и возможностей многократного использования существующих компонентов;

  • выход проекта за рамки бюджета и сроки исполнения;

  • нечеткое определение потребностей пользователей;

  • нечеткое отслеживание изменений требований;

  • трудности сопровождения системы и расширения ее возможностей;

  • невозможность отследить и восстановить картину внесения изменений;

  • обнаружение проектных ошибок лишь на поздних стадиях разработки;

  • неустойчивая работа системы;

  • недостаточная производительность;

  • руководителям служб АСУ сложно управлять группой разработчиков.

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

Между тем, современная индустрия разработки и сопровождения объектно-ориентированных систем имеет проверенные способы решения перечисленных проблем.

Наиболее эффективным из них является внедрение IBM Rational Unified Process(RUP).

IBM Rational Unified Process

IBM Rational Unified Process – это:

• новый подход к разработке ПС, основанный на использовании лучших практических методов, успешно зарекомендовавших себя во многих проектах разработки ПС по всему миру;

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

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

1подход к разработке

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

Основными принципами RUP являются итерационная разработка, управление процессом на основе прецедентов использования и ориентация на архитектуру.

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

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

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

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

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

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

2четко определенный процесс

RUP создавался по методике, используемой при проектировании ПС. В частности, моделирование производилось с помощью Software Process Engineering Metamodel (SPEM) – стандарта моделирования процессов, основанного на UnifiedModeling Language (UML). У процесса есть два измерения:

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

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

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

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

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

• Управление требованиями (Requirements);

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

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

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

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

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

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

• Управление изменениями (Change management);

• Среда (Environment).

В отличие от каскадного подхода (<водопада>), в RUP все дисциплины выполняются практически во всех фазах жизненного цикла ПС. Однако, в зависимости от фазы, меняются текущие цели проекта и соотношение между объемами работ, соответствующих различным дисциплинам.

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

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

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

Фаза Transition жизненного цикла посвящена подготовке разработанного продукта к передаче его заказчику или к тиражированию и распространению (если это <коробочный> продукт).

3готовый продукт

IBM Rational Unified Process представляет собой готовый продукт. Он состоит из нескольких частей.

Это:

• лучшие практические методики, предоставляемые разработчикам;

• веб сайт, содержащий описание процесса и интегрированный со многими инструментальными средствами;

• средства конфигурации, позволяющие настраивать процесс под нужды конкретного проекта;

• средства кастомизации, позволяющие создавать собственные процессы (IBMRational Workbench);

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

Пользователи RUP могут либо выбрать одно из типовых представлений процесса, либо создать свое собственное.

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

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

Для обеспечения инструментальной поддержки всех процессов жизненного цикла разработки и сопровождения ПС RUP рекомендует использование специализированных инструментальных средств IBM Rational:

• управление требованиями – IBM Rational RequisitePro;

• визуальное моделирование и генерация объектного кода – IBM Rational Rose, IBM Rational XDE;

• разработка – IBM Rational RapidDeveloper

• конфигурационное управление – IBM Rational ClearCase;

• управление изменениями – IBM Rational ClearQuest;

• автоматизированное документирование – IBM Rational SoDA;

• автоматизированное тестирование – IBM Rational TeamTest, IBM RationalTestFactory, IBM Rational Robot, IBM Rational PurifyPlus, IBM Rational SiteCheck и IBMRational SiteLoad.

Инструментальные средства IBM Rational интегрированы между собой, и обеспечивают наибольшую отдачу при их совместном использовании. Исходя из этого, IBM Rational объединяет различные инструментальные средства в ролевой набор инструментов – Suites. Каждый из наборов содержит инструментальные средства, направленные на комплексное решение одной из проектных задач:

Ролевой набор

Краткое описание

AnalystStudio

Законченное решение для аналитиков.

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

DevelopmentStudio

Законченное решение для проектировщиков и разработчиков ПС.

Содержит средства проектирования и тестирования для разработчиков. В состав набора может входить Rational Rose RealTime для создания 100% исполняемого кода. Содержит все необходимое для построения управляемого проекта

TestStudio

Законченное решение для тестирования приложений.

Предназначено для тестирования приложений и частично для разработчиков. Не содержит средств проектирования

ContentStudiо

Законченное решение для проектировщиков и разработчиков интернет-приложений

Enterprise

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

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

Примечание: В состав ролевых наборов не входят продукты IBM Rational XDE иIBM Rational RapidDeveloper

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

5

6<дух rup>

IBM Rational Unified Process представляет собой не столько жесткий набор правил, сколько рекомендации по использованию лучших практических методов разработки ПС. Работа с RUP не требует от разработчика создания каких-либо обязательных артефактов или выполнения каких-либо обязательных задач. Но эффективность RUP существенно повышается, если разработчик придерживается определенных принципов, которые составляют <Дух RUP>. В этих фундаментальных принципах сосредоточен опыт тысяч клиентов IBM Rational, приобретенный за 20 лет работы. Понимание этих принципов, несомненно, приведет к более эффективному применению RUP в ваших проектах. Эти принципы таковы:

• начинайте борьбу с главными рисками как можно раньше, и ведите ее непрерывно: иначе они сами пойдут в наступление на вас;

• обеспечьте максимально точное выполнение требований заказчиков;

• сконцентрируйтесь на исполняемой программе;

• будьте готовы к изменениям с самого начала проекта;

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

• стройте систему из компонентов;

• командный принцип работы;

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

Познакомимся с этими принципами поподробнее.

Начинайте бороться с главными рисками как можно раньше и не прекращайте этой борьбы: иначе риски сами пойдут в наступление на вас

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

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

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

7

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

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

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

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

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

Будьте готовы к изменениям с самого начала проекта

Изменения – это очень хорошо для проекта. Вряд ли вы везде и всегда сможете найти оптимальное решение с первой попытки. А изменения дают вам еще один шанс.

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

Закладывайте основу исполнимой архитектуры как можно раньше

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

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

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

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

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

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

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

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

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

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

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

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

8rup и другие подходы к разработке по

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

При разработке ПС для государственных предприятий и в ряде других ситуаций компании-разработчику приходится выполнять формальные требования отечественных и международных стандартов (ГОСТы серий 19 и 34, ГОСТ ИСО/МЭК 12207 и др.). В этом случае можно настроить RUP на достаточно высокий уровень формализации процесса. Более того, при использовании инструментальных средств IBM Rationalнесложно разработать шаблоны документов, которые будут создаваться автоматически с помощью IBM Rational SoDA на основе стандартных моделей и артефактов и соответствовать требованиям ГОСТ.

Использование RUP с достаточно высоким уровнем формализации процесса также может помочь компании-разработчику выполнять требования сертификацииCMM. Поскольку RUP представляет собой хорошо документированный процесс, внедрение RUP поможет вам достигнуть уровней 2 и 3 СММ. В еще большей степениRUP может помочь при внедрении CMMI, поскольку CMMI в большей степени соответствует современному итерационному подходу к разработке ПС.

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

9внедрение rup

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

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

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

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

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

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

• описание порядка разработки и сопровождения ПС;

• шаблоны документов, выпускаемых в процессе разработки;

• указания по разработке артефактов проектов;

• указания по использованию инструментальных средств поддержки.

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

10адаптация rup. ibm rational process workbench

IBM Rational Process Workbench (RPW) – это инструмент настройки и публикации Web-сайтов на основе RUP.

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

RPW является первым инструментом визуального моделирования процессов, использующим UML. Визуальное моделирование процессов повышает уровень абстракции, облегчает понимание и изменение процессов. Взаимосвязанность процессов обеспечена метамоделью RUP. Основные задачи генерации Web-сайта модифицированного RUP выполняются автоматически.

RPW поддерживает три основные задачи моделирования процессов:

• определение процесса,

• описание процесса,

• представление процесса.

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

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

На последнем этапе – этапе представления процесса – RPW генерирует описание процессов, включающее текст и графику в виде Web-сайта, соединяя модели процессов и библиотеку описаний в единое целое.

11база знаний и опыта. ibm rational developer network

IBM Rational Developer Network (RDN) – это портал, доступный для всех потребителей IBM Rational. Портал представляет собой WEB-сайт, содержащий лучшие инициативы Rational и примеры практического использования инструментов и методологии.

Также RDN содержит:

• информационную поддержку пользователей (статьи по инструментальным средствам и методологии IBM Rational);

• обзоры лучших книг по инструментальным средствам и методологии IBM Rational;

• он-лайн курсы по обучению специалистов методологии IBM Rational;

• инструкции по эксплуатации инструментальных средств IBM Rational;

• архивы дополнений и расширений к инструментальным средствам IBM Rational;

• дискуссии по инструментальным средствам и методологии IBM Rational;

• базу знаний, основанную на реальных проектах.

Информация, расположенная на RDN постоянно обновляется и дополняется. Периодически, при апробации новых методов преподавания WEB-курсов, IBM Rationalделает их бесплатными для прохождения.

Для того, чтобы воспользоваться услугами RDN необходимо быть официальным пользователем инструментальных средств IBM Rational.

Инструментальная поддержка RUP

***

Продолжение читайте в блоге Александра Новичкова
http://anovichkov.msk.ru