Исполнители: кто
Основным понятием процесса является исполнитель. Исполнитель определяет поведение и обязанности отдельных лиц или групп, работающих в одной команде. Поведение выражается через виды деятельности, производимые исполнителями, причем каждый исполнитель соотносится с рядом связанных видов деятельности. В данном контексте "связанных" означает, что все эти действия рекомендуется выполнять одному человеку. Обязанности каждого исполнителя обычно выражаются по отношению к определенным артефактам, создаваемым, изменяемым или управляемым исполнителем. Исполнитель играет одну или несколько ролей и является владельцем множества артефактов. Приведем несколько примеров исполнителей. • Системный аналитик Лицо, действующее как системный аналитик, направляет и координирует процессы определения требований и моделирования прецедентов. Для этого очерчиваются функциональные возможности системы и определяются границы системы. • Разработчик Лицо, действующее как разработчик, определяет обязанности, операции, атрибуты одного или нескольких классов и взаимоотношения между классами. Кроме того, разработчик определяет способы их адаптации к среде реализации. Отметим, что исполнители — это не физические лица; исполнители — это описание обязанностей физических лиц и того, как они должны действовать. С исполнителями связаны конкретные виды деятельности, которые определяют работу, выполняемую исполнителем. Вид деятельности— это часть работы, выполнение которой может потребоваться от сотрудника, играющего некоторую роль, причем результат этой работы является значимым в контексте проекта. Вид деятельности имеет ясную цель, которая выражается, как правило, в создании или обновлении артефактов, таких как модель, класс или план. Каждый вид деятельности соотносится с определенным исполнителем Продолжительность вида деятельности колеблется от нескольких часов до нескольких дней. Как правило, в каждом виде деятельности задействован один исполнитель и затрагивается один-два артефакта. Вид деятельности должен быть таким, чтобы его можно было использовать в качестве элемента планирования и развития. Виды деятельности имеют исходные и результирующие артефакты. Артефакт— это "порция" информации, порождаемая, модифицируемая или используемая процессом. Артефакты— это вещественные продукты проекта: объекты, порождаемые или используемые проектом при работе над окончательным продуктом. Исполнителями видов деятельности артефакты используются как исходная информация и являются результатом или выходом этих видов деятельности. Артефактами могут быть: • модель, такая как модель прецедентов или модель проектирования; • элемент модели (элемент в рамках модели), такой как класс, прецедент или подсистема; • документ, такой как бизнес-план или документ архитектуры программного обеспечения; • исходный код; • исполняемые программы. Артефакты могут быть составляющими других артефактов. Например, модель проектирования содержит множественные классы; план разработки программного обеспечения включает несколько других планов: план кадрового обеспечения, план фаз, план метрик, планы итераций. Как правило, артефакты— это не документы. Самым эффективным и практичным подходом к управлению артефактами проекта является поддержка артефактов в пределах соответствующих инструментальных средств, используемых для создания артефактов и управления ими. При необходимости эти средства позволяют мгновенно создавать нужные документы (снимки процесса). Артефакты, поставляемые заинтересованным сторонам, также нужно рассматривать не на бумаге, а неразрывно с инструментальными средствами. Такой подход гарантирует "свежую" информацию и то, что она будет основываться на действительной проектной работе и ее получение не будет требовать дополнительной работы. Приведем примеры артефактов. • Проектная модель, сохраненная в Rational Rose · План проекта, сохраненный в Microsoft Project • Дефект, сохраненный в ClearQuest • База данных требований проекта в Requisite Pro За артефакты отвечает один исполнитель; Несмотря на то что "владеть" артефактом может только одно лицо, использовать его могут многие люди, которые, при наличии соответствующего разрешения, могут даже модернизировать этот артефакт Технологический процесс— это последовательность видов деятельности, дающих результат с очевидным значением. В терминах языка UML технологический процесс можно выразить как диаграмму последовательностей, диаграмму взаимодействия или диаграмму видов деятельности. Существует множество способов, позволяющих.задать структуру с разбитием большого числа видов деятельности на отдельные технологические процессы. В структуре Rational Unified Process использованы: • основные технологические процессы; • элементы технологических процессов; • планы итераций. В Rational Unified Process существует девять основных технологических процессов, которые представляют собой логическое разбиение всех исполнителей и видов деятельности на группы: области интересов или дисциплины. Основные технологические процессы делятся на шесть основных технических процессов и три основных процесса поддержки. Техническими процессами являются: ■ Процесс моделирования производства; ■ Процесс управления требованиями; ■ Процесс анализа и проектирования; ■ Процесс реализации: ■ Процесс тестирования; ■ Процесс распространения. Тремя основными процессами поддержки являются: ■ Процесс управления проектом; ■ Процесс управления конфигурацией и требованиями; ■ Процесс управления средой. В реальном, полном технологическом процессе проекта указанные девять основных процессов чередуются и повторяются при каждой итерации с различными акцентами и уровнями глубины.
46. Технологический процесс управления проектом.
Управление программным проектом – это искусство балансирования между конкурирующими целями, а также управление риском и преодоление ограничений. Результатом процесса должен быть продукт, удовлетворяющий потребностям заказчиков (тех, кто оплачивает счета) и конечных пользователей. Цель технологического процесса управления требованиями, как он определен в Rational Unified Process, — максимально возможное облегчение поставленной задачи путем обеспечения руководства проектом.Существует три основные цели процесса управления проектом. ■ Создать контур для управления преимущественно программными проектами ■ Обеспечить практическое руководство по вопросам планирования, кадрового обеспечения, реализации проекта и наблюдения за проектом ■ Создать контур для управления риском Следует отметить, что данный технологический процесс, как он определен в Rational Unified Process, не охватывает все аспекты управления проектом. Например, не освещаются следующие вопросы: ■ Управление персоналом: наем, обучение, тренировка ■ Управление ресурсами: определение, распределение ■ Управление контрактами с поставщиками и заказчиками Данный технологический процесс акцептирует внимание лишь на определенных аспектах процесса итеративной разработки. ■ Планирование жизненного цикла итеративного проекта в целом и планирование отдельных итераций ■ Управление риском ■ Наблюдение за прогрессом итеративного проекта и метрики Рассмотрим рис. 7.3, на котором в форме диаграммы видов деятельности представлена одна итерация технологического процесса управления проектом. Каждый вид деятельности, например открытие нового проекта, – это элемент процесса Rational Unified Process. И наоборот, каждый элемент процесса Rational Unified Process состоит из одного или нескольких видов деятельности. Стоит отметить, что некоторые элементы технологического процесса зависят от времени. Элементы технологического процесса 1.Открытие нового проекта ( Целью этого элемента является перевод проекта из стадии зарождения идеи в стадию, на которой уже возможно принятие решений относительно продолжения проекта или отказа от него.) 2. Оценка области действия проекта и риска( включает разработка бизнес-плана,оценка риска, Целью этого элемента является пересмотр определенных возможностей и характеристик проекта) Создание плана разработки программного обеспечения Цель– разработка компонентов и приложений плана разработки программного обеспечения с последующим их формальным пересмотром на предмет выполнимости и приемлемости для заинтересованных сторон. 4. План следующей итерации Цель– создание плана итерации, мелкозернистого плана, направляющего следующую итерацию. После создания данного плана может потребоваться коррекция плана разработки программного обеспечения 5. Наблюдение и контроль над проектом создание графика работ и распределение работ, наблюдение за состоянием проекта, обработка исключительных ситуаций и проблем
|
