В этой ветке поднимал вопрос http://www.uml2.ru/forum/index.php?topic=972.0
Есть у кого примеры(диаграмки) или регламент работы отдела разработки?
Спасибо

Вот примерно описал процесс. Текстовое описание я взял по адресу: http://www.jvetrau.com/2008/07/01/proektirovanie-v-agile-protsesse-grafik-rabotyi-komand-razrabotki-i-analitiki/

Посмотрите какие я ошибки допустил , что проморгал?
Спасибо

Ох и люблю же я эти activity диаграммы в стиле Золотухиной ... :-).
Но скажем так, коль скоро вопрос стоит про отдел разработки с "нацеленностью на поддержку" ... то
1. Входом должен быть запрос на изменение .. а как он получен -- с подачи собственно разработчиков или по желанию заказчика (в т.ч. индуцированным теми же исполнителями) или от маркетинга - для разработчиков не суть важно. Важно что этот запрос на изменение должен пройти по процессу ... т.е. его должен рассмотреть change control boards (принять в разработку\отклонить. Т.е. оценить сколько стоит внести такое изменение -- есть ли ресурсы, повлияет ли это на архитектуру и т.п.).
2. Далее начинается планирование релиза -- или если по-простому --  нужно будет определить в каком релизе будет имплементирован данный запрос на изменение.
3. После просто описывается процесс выпуска релиза со своими deliverables. При этом стоит обратить внимание что нужно пройти по всему циклу разработки -- от требований, через проектирование ... до тестирования и формальной передачи заказчику. Не забыть про конфигуправление (в терминах SCCM)
4. После передачи -- не забыть проапдейтить инфрмацию в CMDB в рамках конфигурационного управления в терминах ITIL\ITSM. А далее -- чистый ITSM :-) ... вплоть до появления на входе у разработчиков запроса на изменение :-) ... круг замкнулся.

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

Советую перерисовать диаграмму ... и если описывать динамику процесса, то показать одну общую диаграмму в которой будут участвовать CCB (change control boards), отдел разработки, отдел эксплуатации (или заказчик) ... и активности показать в очень general виде ...
Потом детализировать каждый процесс.

Ох и люблю же я эти activity диаграммы в стиле Золотухиной ... :-).

Верно!В стиле Золотухиной :-).
Современем и у тебя Юра будут последователи :-)

OK.
Перерисую.

Сейчас нет времени вникать в суть Д, но по оформлению ДД сделано не верно:
1. Дорожки должны обозначать Роли, в твоем случае это Отделы
2. Если хочешь делить большое Действие на маленькое, то надо использовать композитные Действия:
http://www.jot.fm/issues/issue_2003_07/column3/images/fig7.gif
3. По спецификации входные и выходные данные оформляются в виде объектов, см. Invoice:
http://content.usa.visual-paradigm.com/websiteimages/highlightUML2Support_files/image002.png

Нацеленность на поддержку у нас - такая же, как и на развитие.
Ветку опишу только реактивную, не проактивную.
Если  поддержка - то исключительно исправление ошибок. Реализацию пожеланий выношу в проактивную ветку - её в договоре о поддержке не обещаем. Много тут кто чего желает, обобщая - "канарейку за копейку, чтобы пела. СРОЧНО!!!".

1) Заказчик оформляет заявку на дефект.
2) Инженеры проверяют дефект, и понимают, где дефект: в настройках, которые они сделали (тогда сами виноваты), в ПО, или в руках и голове заказчика (считаю, что писать это слово с большой буквы в середине предложения - показуха). Если в ПО - то 3), если нет - то инженеры устраняют и объясняют сами, на своём уровне, или привлекают менеджера по работе с эти клиентом.
3) Если инженеры нашли пути обхода - то ветка а); если инженеры не нашли пути обхода или ошибка не позволяет внедрить и получить деньги - то б)

1а) Инженеры вводят ошибку - normal или меньше
2а) Тестировщики проверяют ошибку
3а) Если ошибка воспроизводится - то аа), иначе аб)

1аа) Ошибка учитывается
2аа) Ошибка исправляется - рано или поздно, через план и возмущение "чего этот enchancement уже второй год висит? да вся разработка просто бездельники!"

1аб) Тестировщики возвращают ошибку инженерам
2аб) goto 2

1б) Инженеры вводят ошибку - major или выше
2б) Тестировщики проверяют ошибку
3б) Если ошибка воспроизводится и её нельзя обойти - то 1ба), если воспроизводится и её можно обойти - то 1аа), если не воспроизводится - то 1аб)

1ба) Ошибка исправляется сверх плана. По крайней мере один программист вплотную занимается исправлением этой ошибки. Разработчики устают и/или планы, в т.ч. исправление менее важных ошибок, сползают на "пессимистичные" даты.

Упрощённо - так. Хотя бывают разные "исключительные ситуации".