10 Приоритетов RUP

© Лесли Пробаско (Leslee Probasco)
Руководитель разработки ПО
Rational Unified Process
Rational Software Канада

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

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

Я предложил просмотреть то, что Рэнди уже впихнул в свой переполненный тюк. Мы смогли бы увидеть то, чем можно было бы пренебречь, чтобы облегчить груз, и также увидеть, не забыты ли какие-нибудь необходимые вещи. Очень скоро я мог сказать,что он действительно не совсем понимал, что такое "самое необходимое" для прогулки по ненаселенной местности. Я взял чистый лист бумаги и составил список из десяти пунктов¹:

1. Карта
2. Компас
3. Солнечные очки и солнцезащитный крем
4. Запасная одежда
5. Дополнительная еда и питье
6. Фонарь
7. Набор для оказания первой помощи
8. Зажигалка
9. Спички
10. Нож

“Смотри, Рэнди. Вот список, который тебе нужен. Если ты начнешь с этих десяти первоочередных пунктов, тогда другие необходимые вещи для любого похода будут очевидны для тебя”. Я запомнил этот список много лет назад, когда начал ходить по горам, и до сих пор использую его независимо от того, к какому походу готовлюсь и насколько продолжительным он будет. Значимость каждого из этих пунктов возрастает или уменьшается, в зависимости от похода, но начинать с короткого списка, расширяя его по мере необходимости, намного проще, чем начинать с длинного списка и пытаться решить, что не нужно брать.

Применение этого подхода к RUP

Часто, когда я помогаю коллективу, работающему над проектом, разобраться со многими элементами RUP, я слышу такие вопросы: “Как мне разобраться во всех этих вещах и определить, что действительно необходимо для моего проекта?”. “RUP содержит так много информации и предназначен только для больших проектов. Могу ли я использовать его для моего небольшого проекта?”

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

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

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

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

Итак, что должно быть в списке “Десять приоритетов RUP”? Вот мой вариант:

1. Разработать концепцию
2. Выработать план
3. Идентифицировать и смягчать риски
4. Устанавливать и отслеживать проблемы
5. Проанализировать прецеденты
6. Разработать компонентную архитектуру
7. Инкрементно создавать и тестировать продукт
8. Проверять и оценивать результаты
9. Управлять изменениями и контролировать их
10. Обеспечивать поддержку пользователям

Давайте рассмотрим каждый из этих пунктов по отдельности, определим, как они входят в RUP и выясним, почему каждый из них включен в мой “короткий список”.

Наличие ясной концепции – ключ к разработке продукта, который соответствует реальным потребностям ваших заказчиков. Концепция являет собой сущность Requirements Workflow (рабочего потока требований) в RUP: анализ проблемы, понимание потребностей заказчиков, определение системы, отслеживание требований по мере их изменения. Концепция предоставляет высоко - уровневую (иногда контрактную) основу для более подробных технических требований. Таким образом, под концепцией подразумевается четкий, обычно высоко - уровневый, взгляд на проект создания ПО, который может быть ясно сформулирован для любого руководителя или разработчика в процессе выполнения проекта. Концепция содержит самые высокоуровневые требования и конструктивные ограничения, предоставляя читателю понимание принципов разрабатываемой системы. Она также является отправной точкой для процесса утверждения проекта, и поэтому тесно связана с бизнес-прецедентами. И, наконец, поскольку концепция содержит в себе ответы на основные вопросы по проекту, она является средством обоснования будущих решений.

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

• Каковы ключевые термины? (Глоссарий)
• Какую проблему мы пытаемся решить? (Формулировка проблемы)
• Кто является заказчиками? Кто пользователи? Каковы их запросы?
• Каковы свойства продукта?
• Каковы функциональные требования? (Прецеденты)
• Каковы не-функциональные требования?
• Каковы конструктивные ограничения?

“Продукт настолько хорош, насколько хорош план разработки этого продукта”²

В RUP вся информация необходимая для управления проектом собирается в план развития ПО (Software Development Plan (SDP)); SDP может корректировать ряд отдельных пунктов, разработанных в начальной фазе. SDP должен постоянно поддерживаться в актуальном состоянии в процессе выполнения проекта.

SDP определяет график выполнения проекта (включая Project Plan (План Проекта) и Iteration Plan (План Итераций)) и потребности в ресурсах (Ресурсы и Средства), и используется для контроля выполнения графика. Он также управляет планированием для других компонент процесса: Project Organization (Организация Проекта), Requirements Management Plan (План Управления Требованиями), Configuration Management Plan (План Управления Конфигурацией), Problem Resolution Plan (План Решения Проблем), QA Plan (План Контроля Качества), Test Plan (План Тестирования), Test Cases (Тестирование Образцов), Evaluation Plan (План Экспертизы), Product Acceptance Plan (План Приемки Продукта).

В простом проекте формулировки этих планов могут состоять только из одного или двух предложений. Configuration Management Plan, например, может просто потребовать: “В конце каждого дня заархивировать содержимое структуры директорий проекта, скопировать на zip-диск с ярлыком, на котором указать дату и номер версии, и отнести диск в центральное хранилище”.

Формат Software Development Plan не так важен, как та деятельность и соображения, которые вошли в него. Дувайт Эйзенхауер (Dwight D. Eisenhower) говорил: “План ничто, планирование все”. Пункт “Выработать План” совместно с приоритетами 3, 4, 5 и 8 из списка являют собой сущность Project Management Workflow (Потока работ управления проектом) в RUP, который включает зарождение проекта, оценку объема и риска, мониторинг проекта, планирование и оценку каждой итерации и фазы.

3. Идентифицировать и смягчать риски.

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

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

Эти “отпечатки” проекта подчеркивают проблемы, требующие внимания руководства. Хотя время между проверками может меняться, регулярные оценки позволяют менеджерам быть в курсе развития проекта и устранять любые остановки и препятствия, мешающие движению вперед.

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

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

RUP дает Вам методическое, системное средство для разработки, развития и обоснования такой архитектуры. Действия, составляющие Технологию Анализа и Конструирования (Analysis and Design Workflow) включают в себя определение подходящей архитектуры, усовершенствование архитектуры, анализ ее поведения и разработку компонентов системы.

Чтобы говорить и размышлять об архитектуре программного продукта, вы должны сначала создать архитектурное представление, которое описывает важные аспекты этой архитектуры. В RUP это осуществляется в Software Architecture Document (SAD), который представляет множественные виды архитектуры. Каждый вид соотносится с интересами разных участников процесса разработки: конечных пользователей, инженеров, менеджеров, системных инженеров, системных администраторов и т.д. SAD позволяет системным архитекторам и другим членам команды эффективно взаимодействовать для принятия проектных решений, важных с архитектурной точки зрения.

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

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

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

Сущностью Configuration and Change Management Workflow (Технология Управления Изменением и Конфигурацией) в RUP являются управление и контроль объема проекта, поскольку изменения происходят на всем протяжении проектного цикла. Это делается для того, чтобы рассматривать все запросы заинтересованных лиц и удовлетворять их максимально возможно, при условии своевременного выпуска качественного продукта. Как только пользователи получат первый прототип продукта (часто даже раньше), они потребуют изменений. Важно, чтобы эти изменения предлагались и управлялись непротиворечивым образом.

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

В RUP сущностью Deployment Workflow (Поток работ развертывания) является поставка готового продукта наряду с любыми материалами, необходимыми для того, чтобы помочь пользователю изучить, использовать и поддерживать продукт. Как минимум, проект должен быть снабжен User’s Guide (Руководство Пользователя) – это можно осуществить через интерактивную справку – и, возможно, Installation Guide (Руководство по Инсталляции) и Release Notes (Примечания по Версии). В зависимости от сложности продукта, пользователи могут нуждаться в обучающих материалах. И, наконец, Bill of Materials (спецификация поставки) должен ясно информировать, что поставляется вместе с продуктом.

Некоторые из вас, рассматривая мой список приоритетов, могут не согласиться с моим выбором. Вы можете спросить, например, где место в этой картине для “requirements” (требований)? Разве они не существенны? Я расскажу вам, почему я не включил их в мой список. Иногда я спрашиваю у коллектива разработчиков (особенно у коллектива, занимающегося внутренним проектом), “Каковы ваши требования?” то получаю ответ: “У нас действительно нет никаких требований”. Первый раз меня это поразило (т.к. мой предыдущий опыт был связан с разработками в аэрокосмической области). Как могли они не иметь никаких требований? По мере того, как я работал с этими коллективами, я выяснил, что для них “требования” означают ряд пришедших извне инструкций о том, что они должны получить, либо проект не будет принят, и в этом смысле они не имеют никаких требований! Особенно если коллектив связан с исследованием и разработкой, требования к продукту могут меняться на протяжении всего проекта.

Для таких проектов я задаю следующий вопрос: “Хорошо, тогда какова ваша концепция продукта?”. Тогда в их глазах появляется блеск и мы легко проходим по всем вопросам (обозначены маркером) приоритета #1 RUP ("Develop a Vision"), и требования возникают сами собой.

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

Итак, что могут “Десять Приоритетов RUP " изменить в моей жизни? Вот несколько вариантов, как эти рекомендации могут помочь мне в работе с проектами разных размеров.

Прежде всего, если кто - то спрашивает меня, как они могли бы использовать RUP и средства разработки Rational для создания простого продукта с очень маленькой, неопытной командой, которая только знакомится с процессом, я могу поделить мой список “10 Приоритетов” и команда разработчиков не будет завалена всеми деталями RUP и полным инструментарием Rational Suite.

Фактически, эти “десять приоритетов” могут выполняться без какой бы то ни было поддержки автоматизированных инструментальных средств! Записная книжка по проекту, в которой каждому из 10 приоритетов посвящен свой раздел - фактически очень хорошая отправная точка для управления маленьким проектом. (И я нашел, что пояснительные заметки неоценимы для управления, ранжирования и отслеживания запросов на изменения для маленьких проектов!)

Конечно, если размер и сложность проекта растут, эти простые средства применения десяти приоритетов скоро станут неэффективными, и потребность в автоматизированных средствах станет более очевидной. Однако, я все равно рекомендовал бы руководителям команд начинать с “Десяти Приоритетов" и с " Наилучшей практикой" RUP, постепенно добавляя, по мере необходимости, инструментальную поддержку, а не начинать с попыток сразу полностью использовать полный набор инструментальных средств в Rational Suite.

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

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

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

Таким образом - очень рискованно жить без знания "Десяти Приоритетов”. Я призываю Вас использовать их как отправную точку для работы вашего проектного коллектива. Решите, что Вы хотите добавить, изменить, или убрать. После этого решите, что еще является действительно "существенным" для Вашего проекта - независимо от его размера - чтобы поставить продукт вовремя, в пределах бюджета, продукт, который удовлетворяет реальным потребностям ваших заказчиков!

• Другие организации издали подобные списки приоритетов по проектированию ПО.
• IEEE Software Magazine, March/April 1997, "Software's Ten Essentials", автор - Steve McConnell
• В The Software Project Manager's Network есть "16 Critical Software Practices"; доступна на www.spmn.com.
• Software Engineering Institute's (SEI) Capability Maturity Model (CMM) содержит Key Process Areas (KPAs), которые могут рассматриваться, как "приоритеты" (смотри www.sei.cmu.edu).

¹Для полного анализа списка "Десять Приоритетов" см. страницы 35-41 в Mountaineering: The Freedom of the Hills, 6th edition, published by The Mountaineers of Seattle, WA in 1997.

² Johnson Space Center Shuttle Software Group. Цитируется в "They Write the Right Stuff," by Charles Fishman, Fast Company, Issue 6, p. 95, December 1996.

• Эффективная разработка программного обеспечения с использованием технологий и инструментов компании Rational
• Rational Unified Process - методология создания программного обеспечения
• Введение в Rational Unified Process (Серия статей)
• Здесь можно получить ознакомительные версии.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Rational Software
Отправить ссылку на страницу по e-mail