Содержание
Основные понятия
Эта модель взята из реального проекта (его название не будет упоминаться). Она была создана по той причине, что из-за множества процессов из RUP и процессов компании возникала путаница в следующих вопросах:
- какие именно результаты нужно получить на выходе,
- кто отвечает за артефакт,
- какая группа должна нести за него ответственность,
- какие средства нужно использовать,
- каковы отношения между артефактами и элементами модели,
- используется ли данный RUP-артефакт в этом проекте,
- на какой итерации данный артефакт создаётся,
- каков уровень детализации,
- как следует связать артефакты существующего процесса с RUP-артефактам,
- и т. д.
Внимание!
Эта информация относится к проекту, в котором методологияRUP применялась к большинствупроцессов, но не ко всем, поскольку были дополнительные процессы, а процесс «Анализ и проектирование» был приспособлен к конкретному проекту. Это не окончательная модельRUP.Рассматривайте её лишь как идею модели, которая может быть создана для вашего проекта.
Введение
На первой итерации менеджер процессов вместе с руководителем проекта и другими сотрудниками потратил немало времени, чтобы определить, какие артефакты должны быть созданы и на каких итерациях. Обсуждался уровень детализации для каждого артефакта и членов группы. Это было необходимо для составления начального описания процесса разработки проекта, а также для того, чтобы руководитель проекта мог разработать план итераций проекта и оценить сроки выполнения.
Проблема
Первая наша проблема заключалась в том, что пока шло планирование, остальные сотрудники не могли приступить к работе над артефактами, но эта проблема не связана с рассматриваемым здесь решением, она характерна лишь для некоторых проектов. Это требует отдельного обсуждения.
После того, как мы тщательно распланировали создание артефактов и объяснили их руководителю проекта, мы опубликовали их в описании процесса разработки. Сразу выяснилось, что многие неверно понимают такие термины как «Use Case» (прецедент). Некоторые думали, что это маленькая овальная схема в Rose, другие полагали, что это документ Word, который содержит только текст, третьи — и то, и другое, а некоторые считали, что это модель всех прецедентов.То же самое было со многими артефактами, типами артефактов и элементами модели.
Были и другие проблемы, например, некоторые не понимали набор инструментов, где должен находиться тот или иной артефакт, где его следует искать и т. д.
Была также неразбериха в том, кто должен отвечать за артефакты, за их создание, за соблюдение сроков и т. д. К кому обращаться, если что-то понадобится исправить или улучшить и т. п.
Существовала также серьёзная проблема с жаргонными названиями артефактов, которые придумывались несмотря на то, что артефакты в RUP уже имеют названия.
Решение
Решение исходит из того факта, что поскольку программное обеспечение должно содержать модели и соответствующие концепции, то же самое должен содержать и процесс разработки.
Поначалу многие менеджеры с административным уклоном, например, руководитель проекта, менеджер по программированию, представители пользователей и т. д. не могли читать UML(Unified Modeling Language) и даже не хотели разбираться в модели. Но вскоре после того, как им объяснили некоторые самые простые понятия моделирования классов, они поняли значения терминов, разобрались в модели и смогли отвечать за свои части модели.
Скоро легко стали находиться забытые артефакты, решаться конфликты по поводу того, что за один артефакт отвечают разные группы. В результате мы смогли итеративно обновлять описание процесса разработки, публиковать отношения между артефактами и распределение ответственности — кто за какой артефакт отвечает, и всё это с использованием описанных ниже пакетов, моделей классов и диаграмм операций.
Использование
- С помощью цвета мы указывали, какие артефакты из RUP обязательно будут использоваться, какие, возможно, будут использоваться, а какие определённо не будут использоваться.
Зелёный = используется,
оранжевый = возможно,
красный = нет,
белый = решает другая группа.
- Цвет пакета указывал также на его происхождение — RUP или собственный.
- Чтобы обозначить <<артефакт>>, <<группу>>, <<операцию>> и т. д., использовалась система обозначений классов со стереотипами.
- Поля атрибутов класса использовались для указания инструмента, в котором должен находиться артефакт, например, в ClearCase, Rose, Word, ReqPro, ClearQuest, Excel и т. п.
- Поле атрибута класса также использовалось для обозначения ответственного за артефакт (владельца артефакта), ответственного за его создание и т. д.
- Ключ указывал на обозначение цветом, способ чтения UML и т. п.
- У нас был ключ для обозначения типа артефакта — RUP-артефакт, не-RUP-артефакт или смешанный.
- Мы опубликовали эту модель с помощью Rose на нашем Web-сайте в качестве составной части описания процесса разработки.
Выводы
Все сочли эту модель очень полезной, поэтому мы собираемся усовершенствовать RUP, предложив эту модель как альтернативную форму документирования описания процесса разработки. Если для большинства других процессов разрабатываются свои модели, то почему бы и для управления проектом не разработать отдельную модель?
Очевидно, при наличии стандартной модели RUP, конкретный проект можно гораздо быстрее подогнать под стандарт RUP. Для малых проектов модель, вероятно, вообще не нужна. Решение этого вопроса также зависит от того, насколько хорошо проектная группа знакома с RUP.
Источник: Interface Ltd.
