Главная » UML » Конфигурирование и реализация Rational Unified Process

0

В главе описываются стратегия и тактика конфигурирования и реализации Rational Unified Process в принявшей его организации-разработчике.

Введение

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

Конфигурирование Rational Unified Process означает адаптацию процесса к нуждам и ограничениям принявшей его организации. Для этого выполняется некоторая модификация контура процесса, поставляемого корпорацией Rational Software.

Реализация Rational Unified Process в организации-разработчике программного обеспечения означает такое изменение способа работы организации, чтобы она смогла целиком или частично использовать Rational Unified Process, причем успешно.

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

Эффект реализации процесса

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

 

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

Изменение процесса сильнее влияет на организацию и ее сотрудников, чем изменение технологии или замена инструментальных средств. Такие изменения должны тщательно планироваться и координироваться. Организация, принявшая Rational Unified Process, должна определить выгоды и благоприятные возможности, выразить их доступно для заинтересованных сторон, обеспечить должный уровень осведомленности, а затем постепенно перейти от текущего способа ведения дел к новому. Ай-вар Джейкобсон (Ivar Jacobson) определил это как "реструктуризацию процесса разработки программного обеспечения" .

При реализации процесса следует обращать внимание на следующее.

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

•       Инструментальные средства поддержки. Необходимо приобрести новые инстру
ментальные средства, заменить старые, настроить и объединить остальные.

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

•       Описание процесса разработки программного обеспечения.

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

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

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

1 Ivar Jacobson and Sten Jacobson.  Reengineering Your Software Engineering Process. Object Magazine, March-April, 1995.

 

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

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

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

Поэтапная реализация Rational Unified Process

Реализацию нового процесса в организации-разработчике программного обеспечения можно описать в шесть этапов (рис. 17.1)2.

Этап 1. Оценка текущего состояния

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

•       Текущее состояние организации-разработчика программного обеспечения.

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

•       Какие инструментальные средства в настоящее время используются в организации.

2 R.   McFeeley.  IDEAL: A   User’s  Guide for Software Process Improvement.  SEI  Tech.   Rep. CMU/SEI-96-HB-001, 1996.

 

Ш   Какой в настоящее  время используется  процесс  разработки  программного обеспечения и как он описан.

Зачем нужна оценка текущего состояния? Возможны следующие причины.

•       Вы хотите использовать ее для создания плана перехода от текущего состояния
к намеченному.

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

•       Вы хотите объяснить спонсорам причины изменения процесса, инструменталь
ных средств и персонала.

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

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

Рис. 17.2. Классификация систем по базису "техническая сложность/сложность управления"

 

Этап 2. Задание (или пересмотр) целей

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

•       При планировании реализации процесса цели служат важным исходным мате
риалом.

•       Цели, объединенные с результатом этапа 1 (описанием текущего состояния),
используются для убеждения спонсоров и сотрудников организации.

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

Этап 3. Определение рисков

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

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

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

•       Не в каждой итерации производится реализация и тестирование. Для смягче
ния последствий от реализации рисков тестирование следует производить сра
зу же после завершения какой-либо конструкции.

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

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

•       При переходе от итерации к итерации имеет место значительная доработка и
переработка.

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

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

•       Слишком рано начинается привлечение персонала к работе, поэтому в фазе
исследования участвует очень много людей. Это затрудняет понимание испол-

•        

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

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

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

Этап 4. Планирование реализации процесса

Необходимо разработать план реализации процесса и инструментальных средств. План должен описывать принципы успешного перехода от текущего состояния организации к целевом)’.

Даже не пытайтесь все сделать за раз! Наоборот, разбейте реализацию на несколько частей и реализуйте части нового процесса с соответствующей инструментальной поддержкой. Как правило, внимание следует акцентировать на тех областях, где, по вашему мнению, изменения будут наиболее заметны. Если организация-разработчик слаба в тестировании, то можно начать с введения технологического процесса тестирования (как он определен в Rational Unified Process) с инструментальными средствами, позволяющими автоматизировать процесс проведения испытаний. С другой стороны, если слабой стороной организации является сбор требований или управление ими, то начать можно с введения технологического процесса управления требованиями с соответствующей инструментальной поддержкой.

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

•     Необходимость изменений в текущей организации

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

•   Риски

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

Ниже приводятся примеры двух подходов.

•       "Типичного"

•       "Быстрого"

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

 

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

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

Данный подход является оптимальным способом внедрения нового процесса и инструментальных средств.

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

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

Этап 5. Выполнение реализации процесса

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

 

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

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

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

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

Этап 6. Оценка реализации процесса

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

Конфигурирование процесса

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

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

 

2. Процесс, ориентированный на проекты, в котором технологи берут за основу организационный процесс и уточняют его для данного проекта. На этом уровне учитывается размер проекта, повторное использование активов компании, использование исходного цикла ("абсолютно новое предприятие") против эволюционного цикла и т. д. Процесс, ориентированный на проект, описывается в Rational Unified Process как план разработки.

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

•       Дополнения, расширения, модификации или удаления этапов видов деятельности.

•       Введения дополнительных контрольных точек с целью рецензирования видов
деятельности на основе полученного опыта.

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

•       Дополнения,   расширения,   модификации   или  удаления   артефактов,   видов
деятельности или исполнителей.

•       Адаптации шаблонов: введения логотипа компании, колонтитулов, опознава
тельных знаков и обложки.

 

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

•       Радикальные изменения терминологии процесса.

 

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

•       Изменения структуры основных технологических процессов.

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

Резюме

•       При   принятии   Rational   Unified   Process   организация   может   использовать
различные подходы.

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

•       Принятие Rational  Unified  Process  включает,  как правило,  создание плана
разработки, представляющего собой версию процесса, ориентированную на
проект.

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

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

•       Неотъемлемой частью тщательного планирования изменений процесса являет
ся профессиональное образование и инструментальная подготовка.

•        

По теме:

  • Комментарии