ВІКІСТОРІНКА
Навигация:
Інформатика
Історія
Автоматизація
Адміністрування
Антропологія
Архітектура
Біологія
Будівництво
Бухгалтерія
Військова наука
Виробництво
Географія
Геологія
Господарство
Демографія
Екологія
Економіка
Електроніка
Енергетика
Журналістика
Кінематографія
Комп'ютеризація
Креслення
Кулінарія
Культура
Культура
Лінгвістика
Література
Лексикологія
Логіка
Маркетинг
Математика
Медицина
Менеджмент
Металургія
Метрологія
Мистецтво
Музика
Наукознавство
Освіта
Охорона Праці
Підприємництво
Педагогіка
Поліграфія
Право
Приладобудування
Програмування
Психологія
Радіозв'язок
Релігія
Риторика
Соціологія
Спорт
Стандартизація
Статистика
Технології
Торгівля
Транспорт
Фізіологія
Фізика
Філософія
Фінанси
Фармакологія


Общие понятия о методе управления проектом заказной разработки PJM

Методика Oracle CDM включает стандартный подход к управлению проектами – Project Management Method (PJM).


Цель метода управления проектом Oracle PJM – создание базы для планирования, оценки, контроля и слежения за проектами всех типов в согласованном режиме.

Рис. 2.9. Жизненный цикл управления проектами

 

Oracle PJM также, как и CDM, имеет два измерения (рис. 2.9).

Первое измерение связано с тем, какая работа должна быть выполнена для управления проектом и поддержки проекта. Это измерение определяется процессами в рамках PJM.

Второе измерение связано с тем, когда должны выполняться задачи управления и поддержки в ЖЦ проекта. Это измерение определяется категориями (этапами) ЖЦ.

Все задачи PJM систематизированы в пять процессов, а ЖЦ содержит пять этапов (рис. 2.9).

Процессы метода управления проектами Oracle PJM.

· Контроль и отчетность – включает задачи, обеспечивающие определение масштаба проекта и подхода к проекту, осуществление управления изменениями и контроля за рисками. Этот процесс включает инструкции по внешней отчетности по достигнутому прогрессу и контролю за планом обеспечения качества.

· Управление работами – включает задачи, обеспечивающие определение всех видов работ, осуществление текущего контроля и руководство всеми работами при выполнении проекта. В этот процесс также входит ведение финансового учета проектом.

· Управление ресурсами – этот процесс обеспечивает проект персоналом необходимой квалификации, а также рабочую среду для поддержки проекта.

· Управление качеством – определяет меры, необходимые для реализации качества и обеспечивающие соответствие проекта целям и ожиданиям заказчика на протяжении ЖЦ проекта.

· Управление конфигурацией – включает задачи, обеспечивающие хранение, организацию, слежение и контроль за всеми элементами, создаваемыми при выполнении проекта и вводимые в проект.

Так же как и в CDM, процессы в PJM разбиваются на последовательность задач, которые в процессе разработки проекта выполняют представители управленческих структур организации-разработчика (руководители проектов, управлений, отделов, подразделений и т.п.). Необходимо понять, что задачи CDM – для разработчиков, а задачи PJM – для управленцев.

Для каждой задачи в рамках PJM определяется соответствующая категория (этап) ЖЦ, что однозначно определяет, когда должны выполняться те или иные задачи управления проектом и поддержки.

КатегорииЖЦ PJM определяют второе измерение метода (рис. 2.9).

· Планирование проекта – задачи этой категории включают определение проекта по следующим аспектам: масштаб, качество, время и стоимость. Задачи планирования проекта также определяют соответствующую организацию ресурсов и обязанностей для выполнения проекта.

· Планирование этапа – к этой категории относятся задачи, связанные с корректировкой планов проекта и процедур для определенного этапа СDM.

· Контроль за этапом – задачи этой категории выполняются одновременно с выполнением этапа CDM и они связаны с функциями текущего контроля за проектом, руководства и отчетности в процессе выполнения этапа CDM.

· Окончание этапа – задачи связаны с окончанием и гарантированным завершением этапа CDM.

· Окончание проекта – результатом выполнения задач на этом этапе является удовлетворительное окончание проекта и решение всех нерешенных вопросов до закрытия проекта.

Как следует из рис. 2.9, методы PJM и CDM жестко связаны между собой. Все дело в том, что категории планирование, контроль и окончание этапа, объединенные в одну категорию управление проектом, содержат процессы управления для каждого этапа методики CDM. То есть содержание процессов этих трех категорий изменяется при переходе от одного этапа CDM к другому. А категории планирования и окончания проекта выполняются только один раз в начале и конце проекта и с этапами CDM не связаны.

 

Методология Microsoft Solutions Framework (MSF)

Три модели MSF

Корпорация Microsoft предлагает технологию организации работы команды разработчиков информационных систем уровня предприятия – Microsoft Solutions Framework (MSF). Эта технология содержит комплект моделей, методик и руководств по управлению проектами разработки ИС.

Управление проектами в MSF рассматривается как управление изменениями и рисками. Существует множество причин, приводящих к неудачам: ошибки в прогнозах, постоянно изменяющиеся требования, нечетко поставленные проектные спецификации и т.п. Поэтому очень важно научиться управлять изменениями и рисками, что и обеспечивает MSF, который объединяет наиболее успешный опыт разработчиков Microsoft, опыт заказчиков и партнеров. Он собирается и анализируется с целью выделить повторяющиеся факторы, обеспечивающие успех проекта. Затем эти факторы успеха интегрируются во взаимосвязанные модели, применение которых позволяет получить технологические решения в контексте конкретного бизнеса.

В состав MSF входят три модели: модель команды, модель проектной группы и модель процесса проектирования. Эти модели можно использовать как самостоятельно, так и в различных комбинациях, в зависимости от задач и потребностей, стоящих перед разработчиками.

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

- каждый общается с каждым и каждый делает реальную работу;

- общие для всех членов группы цели и планы;

- каждый понимает как проблемы конечного пользователя, так и проблемы разработчика;

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

Первое утверждение в этом списке – «каждый общается с каждым» - отрицает иерархический способ структурирования проектной группы. Для проектной группы MSF вопрос «кто кому подчинен?» не имеет смысла. Модель команды существенно отличается правилами формирования и составом от традиционных проектных групп. Как правило, в традиционную проектную группу не входят такие традиционные для проекта роли, как конечные пользователи и структуры, выполняющие контроль качества и обучение пользователей. Их отсутствие в составе группы повышает риски, удлиняет сроки проектирования, снижает качество продукта.

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

Недостатком такой модели команды является ограниченный контроль высшего руководства за внутренними взаимоотношениями и процессами в проектной группе.

Целью такой команды является создание качественного продукта, который:

- удовлетворяет ожидания и заказчика и конечных пользователей;

- удовлетворяет проектным ограничениям;

- соответствует реальным потребностям заказчика;

- понятен в использовании конечным пользователям;

- просто внедряется.

Модель проектной группы создана на основе характеристик модели команды, рассмотренных выше. Она определяет основные роли, закрепленные за членами проектной группы (рис. 2.10). В основу модели проектной группы положены следующие идеи.

Рис. 2.10. Модель проектной группы MSF

 

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

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

Рассмотрим более подробно каждую из этих ролей, указанных на рис. 2.10.

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

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

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

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

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

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

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

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

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

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

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

 

Таблица 2

© 2013 wikipage.com.ua - Дякуємо за посилання на wikipage.com.ua | Контакти