СТАТЬЯ

21.05.03

Внедрение RUP в организации

Д. Дж. Де'Вильес, консультант по процессам

Когда организация собирается внедрить новый процесс или инструмент, возникает множество вопросов. Какова оптимальная комбинация процесса и инструментов? Какая стратегия внедрения будет наиболее эффективна? Находит ли этот проект полное одобрение внутри организации? Каковы возможности организации для модернизации? Эти вопросы рассматриваются в данной статье на основании личного опыта внедрения Rational Unified Process® (RUP®) и Rational Suite® в крупных и малых организациях1.

Стратегии внедрения

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

• Стандартная стратегия
• Распределенная стратегия
• Быстрая стратегия
• Осторожная стратегия
• Стратегия, основанная на организационной среде разработки

Все эти стратегии рассматриваются ниже. Определения терминов приводятся в разделе "Терминология RUP".

Стандартная стратегия

При использовании стандартной стратегии, процесс и инструменты сначала внедряются в пилотном проекте, который длится 3-4 месяца и в котором задействовано от 10 до 15 человек. Перед началом проекта создается конфигурация RUP в документе Описание процесса разработки, адаптированном к конкретному проекту, и выбираются проектные инструменты. После завершения пилотного проекта подготавливается документ Организационная среда разработки (Organizational Development Environment, ODE). На этой стадии новый процесс и инструменты оцениваются руководством процесса разработки ПО (Software Engineering Process Authority, SEPA)². Разработанные в ходе пилотного проекта описание процесса разработки и инструкции адаптируются для всей организации, а сотрудники группы пилотного проекта становятся инструкторами для других проектов (см. рис. 1).

Рисунок 1. Стандартная стратегия внедрения

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

Таблица 1. Преимущества и недостатки стандартной стратегии

Распределенная стратегия

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

Рисунок 2. Распределенная стратегия внедрения

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

Таблица 2. Преимущества и недостатки распределенной стратегии

Быстрая стратегия

При использовании быстрой стратегии процесс и инструменты внедряются в проекты без предварительной проверки их эффективности и без опыта работы с ними (см. рис. 3). Результаты выполнения этих проектов должны быть обязательно переданы SEPA, чтобы предотвратить синдром "башни из слоновой кости"⁴. Риск неудачного исхода в этой стратегии существенно выше, поскольку имеющийся запас времени не позволяет организации допускать ошибки, исправлять их и адаптироваться к изменениям.

Рисунок 3. Быстрая стратегия внедрения

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

Таблица 3. Преимущества и недостатки быстрой стратегии

Осторожная стратегия

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

Рисунок 4. Осторожная стратегия внедрения

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

Таблица 4. Преимущества и недостатки осторожной стратегии

Стратегия, основанная на организационной среде разработки

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

Рисунок 5. Стратегия внедрения, основанная на организационной среде разработки

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

Таблица 5. Преимущества и недостатки стратегии, основанной на организационной среде разработки

Пилотный проект

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

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

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

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

Таблица 6. Приоритетные направления и цели фаз жизненного цикла RUP

Обучение и инструктаж

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

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

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

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

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

1. Определение целей и ожиданий.
2. Планирование выполнения работ.
3. Конкретизация RUP. ⁵
4. Обучение проектной группы.
5. Инструктаж проектной группы.
6. Оценка достижений.

Эти операции обсуждаются ниже. Их выполнение может также носить итеративный характер, как это описывается Филиппом Крюхтеном (Philippe Kruchten) .

Рисунок 6. Внедрение RUP в организации

Операция 1: Определение целей и ожиданий

Цель: определение масштаба и целей внедрения нового процесса и инструментов, определение ожиданий основных заинтересованных сторон и группы Rational.

Созданная в этой операции концепция системы⁷ будет использоваться в качестве критерия в операции 6: Оценка достижений. Определение целей происходит на совещании с участием спонсоров и приглашенного технического менеджера Rational (см. раздел "Терминология RUP"), на котором должно быть достигнуто соглашение по следующим вопросам:

• Бизнес-факторы изменений (включая заинтересованные стороны)
• Функциональные границы изменений (организационный или проектный уровень; выбор процесса и инструментов)
• Распределение сфер ответственности (включая проведение организационных изменений)
• Стратегия внедрения (стандартная, распределенная, осторожная и т.д.)
• Приоритет направлений модернизации⁸
• Организация проекта
• Пилотный проект(ы)
• Обязательства обеих сторон
• Потребности в обучении

Операция 2: Планирование выполнения работ

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

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

• Идентификация основных заинтересованных сторон.
• Составление графика установки.
• Составление графика обучения.
• Составление графика инструктажа.

Операция 3: Конкретизация RUP

Цель: создание описания процесса разработки для конкретного проекта или организации.

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

1. Обучение основных заинтересованных лиц. Организация получает четкое представление о RUP. Основные заинтересованные лица проходят курс по основам RUP (два дня). Инженер процесса проходит курс по внедрению RUP (два дня).
2. Оценка организации. Оценка разрабатывающей организации по ее текущему производственному процессу, инструментам, ролям сотрудников, их сферам компетенции, отношению к работе, рынку, техническим тенденциям, проблемам и областям возможного усовершенствования. Эта оценка выполняется инженером (или инженерами) процесса под руководством специалиста Rational по разработке ПО. Объем оценки зависит от выбранной стратегии внедрения и напряженности графика работ. Этот шаг можно инициировать раньше, что может помочь в определении целей и ожиданий (см. выше операцию 1: Определение целей и ожиданий).
3. Создание описания процесса разработки. Адаптированная к проекту (или организации) конфигурация RUP фиксируется в описании процесса разработки. Этот артефакт описывает используемую в проекте (или организации) комбинацию ролей, артефактов, операций и уровня формальности. Он может иметь вид либо документа Word, либо HTML-оболочки, предоставляемой RUP.

Операция 4: Обучение проектной группы

Цель: обучение проектной группы стандартному процессу RUP и его адаптации к проекту или организации, определенной в описании процесса разработки (см. операцию 3: Конкретизация RUP).

Группа проходит двухдневный учебный курс по основам RUP и участвует в совещании перед запуском проекта, на котором представляется описание процесса разработки¹⁰.

Операция 5: Инструктаж проектной группы

Цель: инструктаж группы пилотного проекта относительно использования стандартного процесса RUP и его адаптации в соответствии с описанием процесса разработки.

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

Операция 6: Оценка достижений

Цель: выполнение оценки достижений проектной группы (или организации) во внедрении RUP и определение следующих действий по дальнейшему развертыванию производственного процесса и инструментов.

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

Факторы успеха и неудач

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

Основные причины неудач

1. Попытка слишком резкого внедрения процесса и инструментов. Резкое внедрение изменений воспринимается людьми негативно и может дестабилизировать проект, если сопротивление персонала слишком велико. Сотрудники могут потерять мотивацию, что помешает им эффективно справиться с необходимостью изучить и применить все и сразу. В итоге, как правило, принимается решение исправить положение, чаще всего – путем возврата к исходному решению, вместо того, чтобы переоценить ситуацию и определить оптимальный выход.
2. Недостаточная поддержка со стороны руководства. Известно, что внедрение организационных изменений зависит от всех уровней организации, начиная с ее руководства. Руководство должно иметь четкое представление о пилотном проекте, а успех проекта во многом обусловлен желанием руководства участвовать во внедрении нового процесса и инструментов.
3. Недостаточное участие спонсоров и заинтересованных сторон. Отсутствие представления о ходе выполнения проекта уменьшает мотивацию спонсоров и заинтересованных сторон. Очень важно иметь сторонников изменений на всех уровнях организации, обязательно поддерживая их информированность и участие в проекте. Особенно большое значение этот фактор приобретает при использовании осторожной стратегии внедрения.
4. Нежелание или неспособность к организационным изменениям. Если проект не получает одобрения внутри организации или была выбрана неверная стратегия внедрения, сотрудники теряют мотивацию. Если организационные изменения происходят неуправляемо или политические интересы становятся важнее производственного процесса и инструментария, то успешное завершение проекта крайне маловероятно. Как правило, этот фактор тесно связан с недостаточной поддержкой со стороны руководства, которое негативно влияет на проектную группу.
5. Неясность концепции системы и факторов изменений. Если бизнес-факторы изменений неясны, сотрудников трудно убедить в необходимости действий по внедрению изменений. Чтобы внедрение получило прочный фундамент, люди должны знать, почему организация должна быть изменена (факторы) и к чему ведут эти изменения (концепция системы).

Стратегии успеха

1. Оценка проекта и организации. Оценка организации позволяет определить приоритетные направления модернизации и оптимальную стратегию внедрения. Оценка проекта помогает понять его уникальные характеристики и факторы, выбрать наиболее результативный и эффективный способ реализации производственного процесса.
2. Постепенное внедрение процесса и инструментов. Продвигайтесь небольшими шагами, каждый раз внедряя небольшие усовершенствования, и фиксируйте достижения (быстрые победы) прежде, чем приступить к следующим изменениям. Это поможет проектной группе сохранить уверенность в своих силах и убедит спонсоров в прогрессе проекта. Чтобы определить приоритетные усовершенствования, используйте оценку организации. Следите за тем, чтобы каждое действие было направлено на реализацию концепции конечной системы – движение в случайном направлении ничем не лучше отсутствия движения.
3. Управление и планирование. Наряду с операциями разработки, необходимо проводить управление и планирование операций по формированию среды (формирование среды является одним из процессов RUP). Часто менеджеры проекта не придают значения подготовке среды, считая эти операции вторичными или непроизводительными. Однако в действительности, эти работы так же сложны и необходимы, как анализ требований, проектирование или тестирование. Управление процессом является такой же неотъемлемой частью любого проекта, как и управление самим проектом.
4. Использование инструкторов. Инструктора играют роль катализатора изменений на уровне проекта. Даже после продолжительного обучения, сотрудники склонны, спустя некоторое время, возвращаться к привычным методам работы. Инструктаж особенно важен в первые недели проекта, когда группа еще не привыкла к новому производственному процессу.
5. Распределенное владение процессом. Сотрудники, использующие процесс, являются "реальными экспертами". Их опыт и отзывы о процессе необходимо фиксировать и распространять. Пренебрежение этим советом может привести к синдрому "башни из слоновой кости", т.е., может возникнуть четкое расслоение (а иногда – даже конфронтация) между теоретиками процесса и теми, кто применяет его в действительности.
6. Прагматичность. Не делайте процесс слишком громоздким, иначе проект может увязнуть в излишней документации и формальностях. Используйте для артефактов наиболее подходящую форму; даже грубый набросок на доске может быть артефактом. Для описания процесса разработки не обязательно полностью переписывать процесс, достаточно лишь указать отклонения от стандартного процесса RUP. И, наконец, следует помнить, что не всегда удается все сделать правильно с первого раза, поэтому лучше просто делать это, чем застрять в попытках достигнуть совершенства.
7. Распространение информации. Люди не любят изменений, но их можно переубедить, предоставив доказательства прогресса и установив реалистичные ожидания. Определите ключевых сотрудников (катализаторов изменений) на всех уровнях организации и следите за тем, чтобы они и основные заинтересованные лица были информированы о ходе проекта и участвовали в нем.
8. Обучение сотрудников. Обучение может быть чрезвычайно эффективным инструментом управления организационными изменениями. Обучение инструментарию и методикам проводится с помощью учебных курсов, семинаров, интенсивных занятий¹² или предпроектного выездного обучения¹³ . Чтобы обеспечить эффективное использование инструментария и методик, после обучения следует обязательно провести соответствующий инструктаж.

Заключение

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

План внедрения включает в себя следующие операции:

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

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

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

И в заключение – если люди увидят, что вам нравится ваша работа, они захотят в ней участвовать!

Терминология RUP

Ниже приведены некоторые термины, используемые при внедрении RUP.

Менеджер по работе с клиентом (Account Manager): сотрудник компании Rational, несущий финансовую ответственность за конкретного заказчика Rational Software.
Описание процесса разработки (Development Case): документ или web-страница с описанием адаптации RUP к проекту или организации заказчика.
Инструкции (Guidelines): документы, создаваемые перед началом проекта, в которых фиксируются решения относительно существующих стандартов или стратегий. Инструкции обычно обновляются в ходе проекта на основании опыта проектной группы. Примеры: инструкция по моделированию прецедентов, инструкция по проектированию.
Организационная среда разработки (Organizational Development Environment, ODE): организационные стандарты производственного процесса, инструментов и методик, единообразно используемые во всех проектах.
Пилотный проект (Pilot Project): проект, проверяющий концепцию использования нового процесса и инструментов. Пилотные проекты обычно проводятся организациями до полного развертывания процесса в целях минимизации риска неудачного внедрения.
Инженер процесса (Process Engineer): лицо (или группа), несущее ответственность за конфигурирование RUP путем создания и ведения описания процесса разработки. Инженер процесса работает в тесном сотрудничестве с руководством процесса разработки ПО, но не обязательно входит в его состав.
Руководитель проекта (Project Manager): лицо (или группа), ответственное за планирование, комплектование персоналом и отслеживание реализации проекта. В данном контексте "проект" может быть либо пилотным проектом, либо полномасштабным проектом по установке организационной среды разработки.
Rational Unified Process (RUP): определяемый архитектурой итеративный процесс разработки ПО, разработанный Rational Software. RUP основан на web-технологии и представляет собой описание ролей, артефактов и операций, позволяющее применять оптимальные методики разработки ПО.
Руководство процесса разработки ПО (Software Engineering Process Authority, SEPA):¹⁴ лицо (или группа), владеющее процессом и несущее ответственность за управление им и его поддержку в проектах. В более формальных случаях SEPA (например, отдел кадров) определяет стандарты процесса и проводит проверки проекта.
Специалист по разработке ПО (Software Engineering Specialist): консультант Rational, обладающий опытом в конкретной области разработки ПО. По мере необходимости, определяемой приглашенным техническим менеджером Rational, эти консультанты обычно проводят обучение и инструктажи.
Приглашенный технический менеджер (Technical Engagement Manager, TEM): сотрудник Rational, несущий техническую ответственность за успешное внедрение RUP и Rational Suite в организации заказчика.

От автора

Автор выражает признательность Гарри Полайс (Gary Pollice), Джону Смиту (John Smith), Синди Ван-Ипс (Cindy VanEpps), Эрику Лопес Кардозо (Eric Lopes Cardozo), Катерине Саусвуд (Catherine Southwood) и Марлен Эллин (Marlene Ellin) за их терпение и помощь в работе над этой статьей.

Ссылки

1. Alistair Cockburn, Surviving Object-Oriented Projects: A Manager's Guide. Addison-Wesley, 1997.
2. Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed. Addison- Wesley, 2000.
3. Walker Royce, Software Project Management, A Unified Framework. Addison-Wesley, 1998.

Дополнительная информация

• Публикации по продуктам Rational Software
• Что такое Rational Unified Process
• Эффективная разработка программного обеспечения с использованием технологий и инструментов компании Rational
• Использование RUP для небольших проектов: расширение экстремального программирования
• Концепция циклов сопровождения ПО в методологии RUP компании Rational Software
• Учебные курсы по продуктам Rational Software
• Приобретести продукты Rational Software в электронном магазине ITshop
• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов
  

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

² Если на этой стадии еще не создан формальный орган SEPA, то эту роль может выполнять группа представителей.

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

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

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

⁶

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

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

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

¹⁰ В зависимости от выбранной стратегии внедрения, проектная группа может на этом семинаре фактически создать описание разработки проекта. В этом случае шаг создание описания процесса разработки переносится из операции 3 в операцию 4.

¹¹Подробное описание особенностей процесса и их влияния содержится в книге Уокера Ройса (Walker Royce) Software Project Management, стр.209.

¹² Краткий период интенсивного обучения с последующей оценкой.

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

¹⁴Другое название: группа процесса разработки ПО.

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме

INTERFACE Ltd. Телефон/Факс: +7 (495) 925-0049 Отправить E-Mail http://www.interface.ru

Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 21.05.03