Вчера пришлось знакомиться с проектом плана разработки ПО с одной из компаний, которая хочет внедрять процесс RUP.
Разбирать этот план, я, естественно не буду. Но впечатление сложилось не очень. И я решил нарисовать для них шпаргалку для планирования разработки одной возможности (feature RUP).
По ходу рисования я немножко поменял цель. Получился не шаблон плана, а диаграмма бизнес-процесса разработки возможности.
Учитывались рекомендации итерационности и инкрементности.
Конечно, процесс имеет дополнительные связи с другими частями плана (и процесса) разработки. Я от них абстрагировался.
На основе диаграммы сделан шаблон MSProject.

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

К примеру, 3 сверху (по счету) ветвление точнее соединение -  это что?

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

Вопросы больше наверно со стороны документов и что брать за основу следующего шага.

Ну, я, для затравки, без объяснений выставил.

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

Горизонтальная полоса под действием "Разработка спецификации..." - это Fork UML2 (Разветвление на параллельные потоки).
Параллельно выполняются:
- если есть еще прецеденты - аналитик обрабатывает следующий
- полученная спецификация передаются на анализ (если он будет выполняться) или сразу на проектирование
- технический писатель начинает писать руководство пользователя для прецедента
- тестер начинает писать сценарий тестирования прецедента, и т.д.

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

Вообще, при рисовании все комментарии были документированы в свойстве Description.
В частности, там написано, что "разработка" - это "создание", "изменение" или "удаление".
На верхнем уровне описания (Activity) указано, что при обнаружении ошибки процесс переходит к первому Merge.

Немного непонятно, компания-то чего хочет: ПО разрабатывать или процесс разработки (RUP?) внедрять?
Чего у Вас не хватает, даже с учетом подмены цели, так это цели. В чем цель? Каковы ресурсы для ее достижения? Каковы ограничения при ее достижении?
От этого и пляшите... А то получается какой-то самопальный велосипед... без колес...

Спасибо!

В общем-то о цели шпаргалки я написал: помочь руководителю программного проекта в составлении плана проекта.

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

Т.к. RUP, смею Вас заверить, знаю достаточно хорошо, я и решил сделать такую картинку, глядя на которую руководитель сможет определить (предположим, в MS Project) задачи проекта для каждой возможности и прецедента (действия диаграммы), установить зависимости между задачами (ребра диаграммы) и назначить исполнителей (я сейчас дорисовываю версию диаграммы с потоками - ролями RUP), сегодня выложу.

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

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

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

Извините, процесс разработки плана программного проекта от цели конкретного проекта никак не зависит. От объема, формальности - зависит. А вот от предметной области - практически нет!
(Я имею ввиду объектно-ориентированный проект разработки ПО по RUP (процесс итерационный, инкрементный, базирующийся на use cases).

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

Дорогой друг!

Целиком с вами согласен: не бывает правил без исключений.

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

Аналогично, в Петровском "Морском уставе" было написано: "Здесь правила писаны, а случаев нет!"

И тем не менее, правила, уставы ("технологии") очень помогают в обычных ситуациях, которых большинство!

Использование технологий, шаблонов, "шпаргалок" при разработке ПО существенно сокращает время (о деньгах ни слова!), повышает качество за счет применения проверенных решений, и освобождает голову для решения сложных проблем, которых в нашем деле хватает!

Не хотите использовать проверенные технологии - удачи! Только посложнее жить будет.

А эту "шпаргалку" я рекомендую начинающим руководителя проектов. Не эту версию, я обещаю выставить, наверное, на своем сайте, полное описание.

Водолеюшка вернулся Ну и всех построил

2 Galogen:
Да неее, я не отрицаю шаблонизацию чего-либо, но что-то мне подсказывает (скромн.), что в разработке разных программных продуктов (по крайней мере для разных предметных областей) менеджерами проекта должны использоваться разные (т.е. наилучшим образом подходящие для этих областей) шаблоны. Более того, не все они будут относиться к планам-графикам. А то ведь действительно можно дойти до "управления проектами в MS Project"... :о))

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

Вот вторая версия. Все то же, но добавлены роли исполнителей.

Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).

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

Вот вторая версия. Все то же, но добавлены роли исполнителей.

Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).

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

План не может содержать действий и/или исполнителей и/или трудоемкостей.

Если хотите академическое определение то:

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

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

жЫрный плюсадин !!!
про то, собственно, и речь толкую...