Положение о планировании - Профессионал управления

APLANA
SOFTWARE
117485,Россия, Москва, ул. Профсоюзная,84/32, под.6, этаж 7.
Тел.: (095) 748-13-45/748-13-46. Факс: (095) 333-6412 , E-mail: info@aplana.com
Группа компаний АйТи
СОГЛАСОВАНО
УТВЕРЖДАЮ
__________
__________
"___"___________2002г.
"___"___________2002г.
Положение о планировании
при выполнении проектов разработки
прикладного программного обеспечения
дата введения:
основание для введения:
дата отмены:
основание для отмены:
заменено на:
2002
Положение о планировании
УТВЕРЖДЕНО
Положение о планировании
при выполнении проектов разработки
прикладного программного обеспечения
Листов 1
© АПЛАНА Софтвер
Положение о планировании
АННОТАЦИЯ
Настоящий документ является частью организационного обеспечения выполнения проектов разработки прикладного программного обеспечения. В документе представлены процедуры и правила организации планирования в процессе разработки прикладного программного обеспечения. Утвержденное положение обязательно для выполнения всеми участниками проектов разработки
программного обеспечения.
© АПЛАНА Софтвер
2
Положение о планировании
Оглавление
ВВЕДЕНИЕ ....................................................................................................... 5
1.1. ЦЕЛЬ ДОКУМЕНТА............................................................................................. 5
1.2. СФЕРА ПРИМЕНЕНИЯ ........................................................................................ 5
1.3. НОРМАТИВНАЯ ОСНОВА ................................................................................... 5
1.4. СВЕДЕНИЯ О ДОКУМЕНТЕ ................................................................................. 5
1.5. ПРОЦЕДУРА СОПРОВОЖДЕНИЯ ПОЛОЖЕНИЯ ................................................... 6
1.6. ТЕРМИНЫ, СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ ....................................................... 6
2.
ОСНОВНЫЕ ПОЛОЖЕНИЯ ........................................................................ 9
2.1. ЦЕЛИ ПЛАНИРОВАНИЯ ...................................................................................... 9
2.2. ПОЛИТИКА В ОБЛАСТИ ПЛАНИРОВАНИЯ ПРОЕКТОВ ......................................... 9
2.3. ОБЕСПЕЧЕНИЕ ПРОЦЕССОВ ПЛАНИРОВАНИЯ.................................................. 11
2.3.1. Обеспечение ресурсами ......................................................................... 11
2.3.2. Распределение ответственности ....................................................... 13
2.3.3. Обучение ................................................................................................. 17
2.3.4. Документирование и публикация ......................................................... 17
2.3.5. Контроль версий .................................................................................... 18
2.4. УЧАСТНИКИ ПЛАНИРОВАНИЯ ......................................................................... 18
2.5. ДЕЙСТВИЯ ПО ПЛАНИРОВАНИЮ ..................................................................... 19
2.5.1. Этапы планирования ............................................................................. 19
2.5.2. Контроль изменений плана ................................................................... 25
2.6. ИЗМЕРЕНИЯ ..................................................................................................... 25
2.6.1. Измерения в процессе планирования .................................................... 25
2.6.2. Измерение объемов программного обеспечения ................................. 26
2.6.3. Измерение рисков ................................................................................... 27
2.7. ВЕРИФИКАЦИЯ ................................................................................................ 27
2.7.1. Контроль со стороны руководства .................................................... 27
2.7.2. Контроль со стороны руководителя проекта ................................... 29
2.7.3. Контроль со стороны ГКК ................................................................... 30
2.8. СОВЕРШЕНСТВОВАНИЕ ОРГАНИЗАЦИОННОЙ СИСТЕМЫ................................. 30
3.
СТАНДАРТЫ ПЛАНИРОВАНИЯ ............................................................. 31
3.1. СОСТАВНЫЕ ЧАСТИ ПЛАНА ПРОЕКТА ............................................................. 31
3.1.1. Паспорт проекта .................................................................................. 31
3.1.2. План график............................................................................................ 32
3.1.3. План рисков............................................................................................. 32
3.2. СТАНДАРТИЗАЦИЯ РОЛЕЙ ПРОЕКТА ............................................................... 34
3.2.1. Состав рабочей группы ......................................................................... 34
3.2.2. Основные функции ключевых ролей ..................................................... 36
3.2.3. Масштабирование рабочей группы ..................................................... 36
3.2.4. Формирование рабочей группы и период действия рабочей группы 38
3.2.5. Управление в рабочей группе ................................................................ 38
3.2.6. Выделение ресурсов на проекты .......................................................... 38
3.3. СТАНДАРТИЗАЦИЯ МОДЕЛЕЙ ЖИЗНЕННОГО ЦИКЛА ....................................... 39
3.4. ШАБЛОНЫ ДЛЯ РАЗРАБОТКИ ПЛАНОВ ............................................................ 40
3.5. ПРАВИЛА ФОРМИРОВАНИЯ ПЛАНОВ ............................................................... 40
1.
© АПЛАНА Софтвер
3
Положение о планировании
СТАНДАРТИЗАЦИЯ МЕТРИК ОБЪЕМОВ ПРОДУКТА .......................................... 40
СТАНДАРТИЗАЦИЯ ПАРАМЕТРОВ ПРОИЗВОДИТЕЛЬНОСТИ ............................. 41
ПОКАЗАТЕЛИ КАЧЕСТВА ПЛАНОВ ГРАФИКОВ ................................................. 41
БАЗЫ ДАННЫХ ПРОЕКТОВ ............................................................................... 42
4.
ДОКУМЕНТИРОВАННЫЕ ПРОЦЕДУРЫ ............................................. 44
4.1. ПЛАНИРОВАНИЕ PRESALE .............................................................................. 44
4.2. ПРЕДВАРИТЕЛЬНОЕ ПЛАНИРОВАНИЕ .............................................................. 45
4.3. ПРОИЗВОДСТВЕННОЕ ПЛАНИРОВАНИЕ ........................................................... 47
4.4. РАБОЧЕЕ ПЛАНИРОВАНИЕ ............................................................................... 49
3.6.
3.7.
3.8.
3.9.
© АПЛАНА Софтвер
4
Положение о планировании
1.
Введение
1.1. Цель документа
Целью «Положения о планировании при выполнении проектов разработки
прикладного программного обеспечения» (далее – Положение) является регламентация процедур подготовки и сопровождения плана при разработке и сопровождении создаваемого в прикладного программного обеспечения и документации к нему с целью обеспечения необходимого уровня качества проводимых
работ.
1.2. Сфера применения
Положение предназначено для использования в области разработки прикладного программного обеспечения и документации.
Положение является частью документационного обеспечения основной
деятельности - разработки заказного программного обеспечения.
Утвержденное Положение имеет статус внутреннего стандарта и обязательно для исполнения в проектах разработки прикладного программного обеспечения.
1.3. Нормативная основа
В качестве базовых стандартов при разработке данного Положения использовались следующие документы:
1.
ment Plans»
IEEE Std 1058-1998 «IEEE Standard for Software Project Manage-
2.
Key Practices of the Capability Maturity Model
/CMU/SEI-93-TR-025 ESC-TR-93-178.
SM
, Version 1.1
1.4. Сведения о документе
Номер версии:
хх.хх.
Дата выпуска:
хх.хх.2002 г.
Дата утверждения:
хх.хх.2002 г.
© АПЛАНА Софтвер
5
Положение о планировании
1.5. Процедура сопровождения Положения
Настоящее Положение разрабатывается в Группе Методологии Разработки
программного обеспечения, согласуется на Техническом совете и утверждается
Директором.
Сопровождение, версионный контроль и доведение Положения до всех
сотрудников осуществляет Группа Методологии Разработки. Номер версии
присваивается в процессе ввода Положения в действие. Группа Методологии
Разработки осуществляет сбор предложений и замечаний, которые формируются в ходе выполнения проектов разработки программного обеспечения. При исправлении ошибок или несоответствий Положению присваивается следующий
по порядку вспомогательный номер версии (после разделительной точки); при
изменении и вводе в действие новых элементов организации или технологии
работ, новой версии Положения присваивается следующий по порядку основной номер. При вводе в действие новой версии Положение публикуется на Web
портале компании, сотрудники уведомляются о выпуске новой версии по электронной почте.
1.6.
Термины, сокращения и определения
Сокращение,
термин
Расшифровка сокращения или термина
Категория на
глийском языке
Активность
Ограниченная во времени деятельность в проекте,
предусматривающая выполнение определенного
ряда действий.
Activity
Аналитик
Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за
формирование требований и управление ими в ходе
проекта
Analyst
Веха
Событие в ходе выполнения проекта, являющееся
значимым, однозначным и определяющим
Milestone
ГКК
Группа Контроля Качества
Quality
Group
ГМР
Группа Методологии Разработки
Engineering
Group
Документатор
Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за разработку пользовательской документации к программному продукту
User
Writer
Задача
Ограниченная во времени деятельность в проекте,
имеющая предусловие для начала и постусловие
для завершения. Задача состоит из определенного
ряда активностей.
Task
Заказчик
Организация, в интересах которой разрабатывается
Customer
© АПЛАНА Софтвер
ан-
Assurance
Process
Documentation
6
Положение о планировании
Сокращение,
термин
Расшифровка сокращения или термина
Категория на
глийском языке
ан-
программный продукт, имеющая полномочия
утверждать требования к программному продукту и
принимать результат разработок. В качестве заказчика может выступать сторонняя фирма, департамент компании, руководитель комплексного проекта, группа маркетинга и пр. В контексте настоящего Положения под Заказчиком понимаются ответственные сотрудники, имеющие полномочия согласовывать и утверждать технические и организационные документы проекта от имени Заказчика.
Запрос на ТКП
Запрос заказчика или службы маркетинга на ТКП
Request for proposal
Интегратор
Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за
управление конфигурациями рабочих продуктов
проекта
Integrator
Ключевая роль
Роль, на которую возлагается ответственность достижения одной из целей проекта. Ключевая роль
присваивается сотруднику на протяжении всего
жизненного цикла проекта
Key role
Конструктор
Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за разработку технического проекта
Designer
по
Должность сотрудника, отвечающего за организацию и координацию работ по подготовке проектов
вплоть до момента передачи проекта в производство
Sales Manager
Менеджер проекта
Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за организацию и координацию работ участников проекта
Project Manager
Паспорт проекта
Документ, содержащий идентификационные сведения и характеристические данные проекта; входит
в качестве составной части в план проекта
Project passport
План проекта
Набор связанных документов, содержащих организационные решения и показатели проекта
Project plan
План рисков
План действий по компенсации последствий события риска; планы рисков входят в качестве составной части в план проекта
Risk plan
План-график
Распределение по временной шкале, последовательности действий, событий и использования ресурсов в проекте; план-график входит в качестве
составной части в план проекта
Schedule
Менеджер
продаже
© АПЛАНА Софтвер
7
Положение о планировании
Сокращение,
термин
Расшифровка сокращения или термина
Категория на
глийском языке
ПО
Программное Обеспечение
Software
Продукт
Программное обеспечение, разработанное в качестве результата проекта
Product
Проект
Ограниченная во времени деятельность, направленная на разработку уникального продукта
Project
Разработчик
Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за кодирование и отладку программного обеспечения
Developer
Ролевая группа
Структурная единица рабочей группы проекта,
подчиненная ключевой роли
Role group
Роль
Множество обязанностей, которое возлагается на
сотрудника в рамках проекта. Один сотрудник может совмещать несколько ролей в проекте. Одну
роль в проекте могут выполнять несколько специалистов. В последнем случае группа специалистов,
выполняющая одну роль, должна быть структурирована с выделением ведущего члена рабочей
группы, ответственного за организацию работ по
данному направлению.
Role
Список рисков
Документ, содержащий ранжированный перечень
рисковых событий и их показателей; входит в качестве составной части в план проекта
Risk list
Стадия
Ограниченная во времени деятельность в проекте,
имеющая целью производство версий предопределенных результирующих продуктов проекта. Стадия состоит из нескольких этапов и завершается
вехой, контролируемой заказчиком.
Stage
Тестировщик
Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за тестирование разрабатываемого программного продукта
Tester
Технические
предложения
Документ, содержащий описание общих требований, характеристик и потребительских свойств
предлагаемого к разработке программного продукта
Vision
Технический
проект
Набор связанных документов с описанием технических решений, положенных в основу разработки,
архитектуры разрабатываемой программной системы и методики разработки.
Design
ТКП
Технико-Коммерческое предложение
Proposal
© АПЛАНА Софтвер
ан-
8
Положение о планировании
Сокращение,
термин
Расшифровка сокращения или термина
Категория на
глийском языке
, Центр
Центр Заказных Разработок Программного Обеспечения
Software Development
Center
Этап
Ограниченная во времени деятельность в проекте,
имеющая целью производство предопределенных
промежуточных продуктов проекта в соответствии
с процессами жизненного цикла. Этап состоит из
ряда задач и завершается вехой, контролируемой
руководством проекта.
Phase
2.
ан-
Основные положения
2.1. Цели планирования
Исходными целями планирования являются:
1)
Обеспечение разработки планов проектов с требуемой для практики точностью.
2)
Распределение ответственности между исполнителями.
3)
Достижение согласования между участниками проекта, руководством Центра и Заказчиком относительно действий сторон, ограничений, рисков
и распределения ответственности при выполнении проекта.
4)
Документирование плана проекта.
Обеспечивающими задачами процесса планирования являются:
1)
Создание единой информационной базы для контроля хода выполнения проектов, планирования ресурсов и управленческих решений руководства.
2)
Создание информационной базы для проведения оценок по объему и трудоемкости разрабатываемого программного обеспечения с приемлемой
для практики точностью путем документирования оценок объема ПО.
2.2. Политика в области планирования проектов
В данном разделе приведены принципы, которые положены в основу планирования проектов разработки программного обеспечения.
1.
Координация работ по разработке и сопровождению плана проекта возлагается на одного члена рабочей группы – Менеджера проекта, на протяжении всего жизненного цикла проекта. Менеджер проекта персонально отвечает за наличие и качество плана.
© АПЛАНА Софтвер
9
Положение о планировании
2.
точников:
План проекта должен разрабатываться на основе следующих ис-
a.
Требований к разрабатываемому программному продукту;
b.
Модели выбранного жизненного цикла разработки;
c.
Оценок объема программного продукта в выбранной метрике;
d.
Выбранных технологий.
e.
Эталонных данных по производительности разработки программного обеспечения данного вида.
3.
План проекта программного обеспечения должен быть согласован
со всеми ключевыми членами рабочей группы.
4.
План проекта программного обеспечения на уровне стадий должен быть доведен до сведения Заказчика и согласован с Заказчиком по его требованию.
5.
План проекта должен включать список рисков, распределение
рисков и планы компенсации для рисков, превышающих уровень, утвержденный для данного проекта.
6.
План разработки должен быть утвержден Руководством.
7.
В случае изменений требований план должен быть приведен в соответствие с произведенными изменениями. После изменения новая версия
плана должна пройти согласование и утверждение в порядке, принятом при разработке общего плана.
8.
Утвержденный план проекта является основанием для организации работ по проекту.
9.
В ходе работ по техническому проектированию план проекта
должен детализироваться до уровня активностей. Если детализация плана проекта не влечет изменений параметров основных этапов проекта, изменения плана должны быть согласованы только с членами рабочей группы - непосредственными исполнителями работ.
10.
План проекта должен находиться под контролем изменений.
11.
Группа контроля качества проводит проверки фактического выполнения процедур планирования. Документированные результаты проверок
предоставляются в рабочую группу проекта и руководству для принятия решений.
© АПЛАНА Софтвер
10
Положение о планировании
2.3. Обеспечение процессов планирования
2.3.1.
Обеспечение ресурсами
Рабочая группа
2.3.1.1.
Рабочая группа проекта разработки программного обеспечения должна
быть полностью укомплектована стандартными ключевыми проектными ролями (см. раздел 3.2 Стандартизация ролей проекта):
1.
Менеджер проекта;
2.
Аналитик;
3.
Конструктор;
4.
Разработчик;
5.
Тестировщик;
6.
Документатор;
7.
Интегратор.
Для небольших проектов в соответствии с правилами масштабирования
рабочей группы, несколько ролей могут выполняться одним специалистом в соответствии с правилами совмещения ролей (п.3.2.3) .
Методологии разработки ПО
2.3.1.2.
Все тематические направления разработки программного обеспечения в
должны быть обеспечены соответствующими методологиями разработки. Необходимыми составляющими методологии разработки являются:
1.
Модель жизненного цикла, документированная в виде описания
процесса. Шаблон плана, выводимый из модели жизненного цикла.
2.
Документарная модель, соответствующая модели жизненного
цикла. Регламент проектного документооборота. Шаблоны документов.
3.
Ролевая структура рабочей группы проекта. Распределение обязанностей ролей по всем процессам жизненного цикла. Квалификационные требования.
4.
Технологическое обеспечение всех процессов жизненного цикла.
Методическая и техническая поддержка.
5.
Инструментальное обеспечение всех процессов жизненного цик-
ла.
© АПЛАНА Софтвер
11
Положение о планировании
6.
Метрики измерения объемов продуктов разработки.
7.
Эталонные данные производительности.
2.3.1.3.
Модели жизненного цикла
Для обеспечения возможности учета фактографических данных по результатам исполнения проектов, сбора статистической информации и улучшения
методологии разработки программного обеспечения создание планов должно
выполняться строго на основе стандартизированных моделей жизненного цикла
ПО (п.3.3).
Модели жизненного цикла ПО разрабатываются и сопровождаются в ГМР.
Библиотека моделей жизненного цикла ПО создается для всех методологий,
адаптированных для применения. Утверждение моделей жизненного цикла в
качестве стандартных для использования в производит Технический совет Центра.
Выбор модели жизненного цикла осуществляется руководителем проекта
по рекомендациям ГМР.
2.3.1.4.
Оценки объема разрабатываемого продукта
Планирование должно производиться на основе оценок объема разрабатываемого продукта. Оценка объемов разрабатываемого продукта производится в
метриках, которые включены в выбранную методологию разработки. Оценка
объемов выполняется Конструктором на основе разработанных требований к
продукту и накопленных в ГМР статистических данных по выполненным ранее
проектам по данной методологии. Полученные оценки объема продукта согласовываются с руководителем проекта и документируются.
2.3.1.5.
Данные производительности
Планирование должно выполняться на основе накопленных данных по
производительности разработки программного обеспечения (п. 3.7). Сбор данных по производительности ведется в ГМР на основе статистического анализа
результатов проектов, выполненных по данной методологии.
Технический совет утверждает эталонные показатели производительности, которые используются при планировании новых проектов.
Данные производительности являются одним из основных показателей деятельности, на основе которых Технический совет разрабатывает техническую
политику. Ответственным за организацию разработки технической политики
является Технический директор.
© АПЛАНА Софтвер
12
Положение о планировании
Инструментальные средства и инфраструктура
2.3.1.6.
Составление планов-графиков работ осуществляется с использованием
средства MS Project 2000. MS Project 2000 должен быть установлен на рабочих
местах всех менеджеров по продажам, менеджеров проектов, руководства, сотрудников ГМР и ГКК.
Разработанные и готовящиеся планы должны находиться в единых базах
данных Центра под управлением MS SQL Server.
Паспорт проекта разрабатывается с помощью Rational Clear Quest.
План рисков разрабатывается c использованием MS Excel.
Техническую поддержку инструментальных средств и баз данных осуществляет служба сопровождения.
2.3.2.
Распределение ответственности
Менеджер проекта
2.3.2.1.
Менеджер проекта является ключевой ролью в составе рабочей группы.
Менеджер проекта имеет следующие обязанности в процессе планирования:
1.
проекта.
Разработка плана проекта и/или координация разработки плана
2.
Планирование ресурсов для выполнения проекта.
3.
Формирование рабочей группы проекта.
4.
Согласование плана проекта с ключевыми членами рабочей груп-
пы.
5.
Согласование плана проекта у Заказчика по его требованию или
по распоряжению руководства.
6.
Согласование плана проекта с руководством комплексного проекта, если разработка программного обеспечения является подпроектом комплексного проекта компании.
7.
Утверждение плана проекта у руководства.
8.
Поддержание плана проекта в актуальном состоянии в ходе выполнения проекта, контроль версий плана проекта.
9.
Вынос на уровень руководства проблем и рисков, связанных с
выполнением плана, которые не могут быть разрешены внутри проекта. Отчет
© АПЛАНА Софтвер
13
Положение о планировании
(рапорт) о проблемах и рисках, выносимых на уровень руководства, должен
быть документирован.
10.
Контроль за публикацией материалов проекта.
Аналитик
2.3.2.2.
Аналитик является ключевой ролью в составе рабочей группы.
Аналитик имеет право согласовывать план проекта перед утверждением
Руководством.
В обязанности Аналитика входит:
1.
Анализ плана проекта на соответствие сформированным требованиям к продукту.
2.
Планирование и уточнение плана проекта в области управления
требованиями.
3.
Согласование плана проекта.
4.
Вынос на уровень менеджера проекта проблем и рисков, связанных с несоответствием плана требованиям и выполнением плана. Отчет (рапорт) о проблемах и рисках должен быть документирован.
Тестировщик
2.3.2.3.
Тестировщик является ключевой ролью в составе рабочей группы.
Тестировщик имеет право согласовывать план проекта перед утверждением Руководством.
В обязанности Тестировщика входит:
1.
Планирование и уточнение плана проекта в области тестирования.
2.
Согласование плана проекта.
3.
Вынос на уровень менеджера проекта проблем и рисков, связанных с несоответствием плана проекта - плану тестирования и выполнением плана. Отчет (рапорт) о проблемах и рисках должен быть документирован.
4.
Учет заявленных проблем внутри проекта.
2.3.2.4.
Конструктор
Конструктор является ключевой ролью в составе рабочей группы.
© АПЛАНА Софтвер
14
Положение о планировании
Конструктор имеет право согласовывать план проекта перед утверждением Руководством.
В обязанности Конструктора входит:
1.
Планирование и уточнение плана проекта в области разработки
Технического проекта.
2.
Согласование плана проекта.
3.
Вынос на уровень менеджера проекта проблем и рисков, связанных с выполнением плана. Отчет (рапорт) о проблемах и рисках должен быть
документирован.
Разработчик
2.3.2.5.
Разработчик является ключевой ролью в составе рабочей группы.
Разработчик имеет право согласовывать план проекта перед их утверждением Руководством.
В обязанности Разработчика входит:
1.
Планирование и уточнение плана проекта в области разработки.
2.
Согласование плана проекта.
3.
Вынос на уровень менеджера проекта проблем и рисков, связанных с выполнением плана. Отчет (рапорт) о проблемах и рисках должен быть
документирован.
Документатор
2.3.2.6.
Документатор является ключевой ролью в составе рабочей группы.
Документатор имеет право согласования плана проекта перед его утверждением Руководством.
Документатор проекта имеет следующие обязанности в процессе планирования:
1.
Планирование и уточнение плана проекта в области разработки
документации, обучения пользователей.
2.
Согласование плана проекта.
© АПЛАНА Софтвер
15
Положение о планировании
3.
Вынос на уровень менеджера проекта проблем и рисков, связанных с выполнением плана. Отчет (рапорт) о проблемах и рисках должен быть
документирован.
Интегратор
2.3.2.7.
Интегратор является ключевой ролью в составе рабочей группы.
Интегратор имеет право согласования плана проекта перед его утверждением Руководством.
Интегратор проекта имеет следующие обязанности в процессе планирования:
1.
Планирование и уточнение плана проекта в области сборки продукта, контроля версий и внедрения у Заказчика.
2.
Согласование плана проекта.
3.
Вынос на уровень менеджера проекта проблем и рисков, связанных с выполнением плана. Отчет (рапорт) о проблемах и рисках должен быть
документирован.
Группа Методологии Разработки
2.3.2.8.
Группа Методологии разработки проводит анализ и статистическую обработку выполненных проектов, накапливает базу знаний по выполненным проектам.
По запросу Менеджера по продаже и Менеджера проекта Группа Методологии Разработки предоставляет:
1.
Оценки объема программного обеспечения;
2.
Модель жизненного цикла для проекта, шаблон плана проекта;
3.
Данные по эталонной производительности.
Группа Методологии Разработки разрабатывает черновик Предварительного плана, оказывает руководителю проекта методическую помощь при разработке плана – графика работ и плана рисков.
2.3.2.9.
Группа Контроля Качества
Группа контроля качества проводит анализ выполнения стандартов, положений и документированных процедур в области планирования в соответствии
© АПЛАНА Софтвер
16
Положение о планировании
с собственным планом на календарной основе и при прохождении проектных
вех уровня стадий.
Отчеты о результатах проверок в документированном виде представляются ключевым членам рабочей группы и Руководству.
Группа Контроля Качества не имеет властных полномочий, не имеет права
согласовывать или утверждать проектные документы. Решения по замечаниям
Группы Контроля Качества принимается в рабочей группе проекта и на уровне
руководства.
2.3.3.
Обучение
Специалисты, которые в соответствии с должностными инструкциями могут занимать в проекте роль менеджера проекта проходят специальное обучение
по темам:
 Процедуры и методики планирования
 Методы управления рисками
 Использование инструментального средства MS Project 2000
2.3.4.
Документирование и публикация
План проекта должен быть документирован. Действующая версия плана
должна быть оформлена и утверждена в соответствии с порядком утверждения
официальных внутренних документов. Электронная копия утвержденного плана
публикуется в следующем порядке:
1.
Копия паспорта проекта публикуется на Web узле. Доступ к опубликованному паспорту проекта должен быть открыт для всех сотрудников,
Службам Компании, ведущим контроль и аудит проектов, ответственным представителем заказчика, внешним группам и партнерам, ведущим совместные с
работы.
2.
План-график работ в формате MS Project 2000 публикуется на
Web узле Project Central . Доступ к информации по плану графику должен быть
открыт для членов рабочей группы, руководству, Службам Компании, ведущим
контроль и аудит проектов. Доступ к информации о стадиях и этапах должен
быть открыт ответственным представителям заказчика.
3.
План рисков помещается в базу данных конфигурационного
управления. Доступ на чтение должен быть открыт для членов рабочей группы,
руководства.
© АПЛАНА Софтвер
17
Положение о планировании
2.3.5.
Контроль версий
Предыдущие версии плана проекта и плана рисков должны находиться
под контролем изменений и храниться в базе данных конфигурационного
управления.
Версии паспорта проекта контролируются Rational Clear Quest.
2.4. Участники планирования
Для описания процесса планирования выделяются следующие ключевые
роли, должности и группы:
1.
Менеджер проекта – несет ответственность за непосредственную разработку плана проекта.
2.
Ключевые члены рабочей группы – несут ответственность за корректность и исполнимость плана в части своих направлений.
3.
ГКК – группа контроля качества – несет ответственность за своевременность опубликования для ключевых членов рабочей группы проекта и
руководства Центра информации об отклонениях от принятых стандартов, неполном выполнении положений и документированных процедур в области планирования.
4.
ГМР – группа методологии разработки. Группа несет ответственность за предоставление точных и корректных данных для планирования проектов. Группа несет ответственность за поддержку и совершенствование процессов планирования в проектах разработки программного обеспечения.
5.
Заказчик – организация, имеющая полномочия согласовывать
план разработки ПО и контролировать в соответствии с ним выполнение обязательств по разработке программного продукта.
6.
Директор по производству – несет ответственность за выполнение плановых объемов производства программного обеспечения. Директор по
производству запускает проекты разработки программного обеспечения в производство и прекращает исполнение проектов.
7.
Технический директор – несет ответственность за обеспечение
проектов инфрастуктурой разработки, инструментальными средствами. Технический директор организует исследования и освоение новых технологических
платформ, инструментальных средств и областей программирования с целью
повышения производительности работ и расширения услуг.
8.
Директор по методологии – несет ответственность за методологическое обеспечение производства программного обеспечения в Центре. Директор по методологии координирует работу по организационному развитию
Центра в соответствии со стандартами качества и обеспечивает ее исполнение.
© АПЛАНА Софтвер
18
Положение о планировании
9.
Менеджер ресурсов – несет ответственность за обеспечение проектов разработки программного обеспечения специалистами необходимой квалификации. Менеджер ресурсов является административным руководителем
сотрудников. На менеджере ресурсов лежит ответственность за проведение кадровой работы в центре.
2.5. Действия по планированию
2.5.1.
Этапы планирования
2.5.1.1.
Планирование работ по Presale
Каждый менеджер по продаже создает и в дальнейшем поддерживает в актуальном состоянии план работ по Presale.
Цель создания плана работ по Presale – согласование с руководством состава и объемов работ по Presale, согласование задач с исполнителями работ,
координация и контроль выполнения работ.
Задания плана работ по Presale на самом верхнем уровне группируются по
предполагаемым будущим проектам. Раздел плана, соответствующий определенному проекту, разрабатывается на основании полученного от потенциального заказчика запроса на ТКП (Request For Proposal – RFP).
План работ по Presale детализируется до уровня заданий исполнителям.
Исполнители заданий заполняются из общего ресурсного пула.
План работ по Presale разрабатывается и сопровождается менеджером по
продаже. Состав и объем работ, включаемых в план, согласуется с Коммерческим директором. Выделение сотрудников для исполнения заданий плана согласуется с Директором по производству.
План работ по Presale включает только план-график, разрабатываемый в
MS Project, который помещается в базу MS SQL планов проектов, а также публикуется на MS Project Central.
План работ по Presale не помещается под версионный контроль. До конца
первого рабочего дня очередной рабочей недели Менеджер по продаже обеспечивает актуальность данных своего плана по состоянию работ на конец предыдущей рабочей недели.
Разделы плана работ по Presale, соответствующие предполагаемым проектам, Presale-работы по которым прекращены и, как предполагается, уже не будут возобновлены в будущем, могут удаляться не ранее, чем по истечении трех
месяцев с момента прекращения работ.
© АПЛАНА Софтвер
19
Положение о планировании
Предварительное планирование
2.5.1.2.
Предварительное планирование проекта выполняется в рамках работ по
Presale.
Цель предварительного планирования – оценка параметров проекта для
принятия решения о целесообразности заключения контракта, согласования с
заказчиком ограничений проекта и подготовки контракта.
Предварительное планирование включает:
1.
Создание и заполнение паспорта проекта.
2.
Разработку предварительного плана-графика работ по проекту.
3.
Составление списка рисков проекта.
Паспорт проекта создается менеджером по продаже в Rational Clear Quest
(действие «Submit») на основании полученного от заказчика запроса на ТКП.
При этом заполняется только раздел «Общая информация». Факт создания паспорта проекта свидетельствует о готовности соответствующего раздела плана
работ по Presale для согласования с Коммерческим директором (по составу и
объемам работ).
Коммерческий директор открывает Presale, переводя паспорт проекта в состояние «Creating Workgroup» (действие «Start Presale»). Директор по производству назначает исполнителей и подтверждает открытие Presale, переводя паспорт проекта в состояние «Developing Proposal» (действие «Confirm Presale»).
При этом заполняется раздел «Рабочая группа».
После завершения работ по подготовке ТКП менеджер по продаже переводит паспорт проекта в состояние «Discussing Proposal» (действие «Commit
Proposal»). При этом заполняется раздел «Информация из ТКП». К этому моменту должны быть подготовлены варианты предварительного плана-графика и
списка рисков проекта.
После согласования ТКП с заказчиком менеджер по продаже переводит
паспорт проекта в состояние «Approved» (действие «Approve Proposal»). В состоянии проекта «Approved» работы по Presale включают подготовку и заключение договора.
Дальнейшие действия с паспортом проекта описаны в разделе 2.5.1.3
(Производственное планирование).
Предварительный план-график разрабатывается менеджером по продаже в
MS Project и сохраняется в базе MS SQL, предназначенной для предварительных планов-графиков, в процессе выполнения работ по подготовке ТКП. В
дальнейшем он включается в состав ТКП, а после согласования ТКП с заказчиком используется при определении событий в тексте договора.
© АПЛАНА Софтвер
20
Положение о планировании
Безрисковая версия предварительного плана-графика разрабатывается на
основе:
1.
Описаний технических решений, которые предполагается включить в ТКП.
2.
Оценок объемов продуктов, подготовленных на основе статистики по аналогичным техническим решениям в метрике требований.
3.
Выбранной модели жизненного цикла.
4.
Эталонных параметров производительности.
Предварительный план-график по уровню детализации находится на
уровне стадий и этапов выбранного жизненного цикла разработки. В качестве
ресурсов в предварительном плане-графике используются названия проектных
ролей из ресурсного пула.
Окончательная версия предварительного плана-графика формируется путем включения в безрисковую версию резервов времени, определяемых в соответствии с предварительным списком рисков.
Версия предварительного плана-графика, включенная в согласованную с
заказчиком версию ТКП и используемая в дальнейшем при составлении договора, должна быть также согласована с руководством. Как составная часть ТКП
или (в дальнейшем) как составная часть договора, эта версия предварительного
плана-графика помещается в базу конфигурационного управления.
Список рисков проекта составляется аналитиком в виде файла MS Excel в
процессе выполнения работ по подготовке ТКП на основании результатов предварительного обследования (предварительных требований). Список рисков используется при определении необходимых резервов для включения в предварительный план-график проекта и при разработке в дальнейшем плана рисков
проекта.
Список рисков включает:
1.
Краткие описания (наименования) событий рисков.
2.
Ссылки на вехи предварительного плана-графика проекта, вплоть
до которых действуют соответствующие риски.
3.
Оценки последствий событий рисков.
4.
Оценки вероятностей событий рисков.
Список рисков, как составная часть будущего плана рисков проекта, помещается в базу конфигурационного управления.
© АПЛАНА Софтвер
21
Положение о планировании
Производственное планирование
2.5.1.3.
Производственное планирование проекта выполняется непосредственно
после принятия руководством решения о запуске проекта в производство, в
рамках работ по проекту.
Цель производственного планирования проекта – согласование среди
ключевых членов рабочей группы параметров проекта, поставленных задач,
распределения ответственности; утверждение плана у руководства, согласование параметров плана с заказчиком по его требованию; организация производства проекта на основе утвержденного плана.
Производственное планирование включает:
1.
Уточнение данных паспорта проекта.
2.
Разработку производственного плана-графика работ по проекту.
3.
Разработку плана рисков проекта.
Директор по производству запускает производство по проекту, переводя
паспорт проекта, ведущийся в Rational Clear Quest, из состояния «Approved» в
состояние «In Work» (действие «Start»). Как правило, это действие выполняется
после подписания договора. При этом вносятся новые данные в поле «Менеджер проекта», а также в раздел «Рабочая группа». В дальнейшем данные поля
редактируются только Директором по производству, остальные поля Паспорта
редактируются менеджером проекта.
Непосредственно после запуска производства менеджер проекта помещает
в базу MS SQL, предназначенную для рабочих планов-графиков, один из стандартных шаблонов, подготовленных для разработки в MS Project производственного плана-графика. Название помещенного в базу файла должно соответствовать идентификатору из паспорта проекта.
Разрабатываемый производственный план-график детализирует предварительный план-график до уровня конкретных заданий. Он также включает работы по производственному и рабочему планированию проекта. Работы по производственному планированию выполняются менеджером проекта и членами рабочей группы по его заданию. В качестве названия ресурсов могут указываться
проектные роли из ресурсного пула, но по работам, связанным с производственным планированием, должны быть указаны конкретные исполнители.
Производственный план-график разрабатывается на основе:
1.
Предварительного плана-графика проекта.
2.
Описаний технических решений, включенных в согласованную с
заказчиком версию ТКП.
© АПЛАНА Софтвер
22
Положение о планировании
3.
Технического задания, если оно существует к моменту разработки
производственного плана-графика.
4.
Технического проекта, если он существует к моменту разработки
производственного плана-графика.
5.
Списка рисков проекта.
6.
Оценок объемов продуктов, подготовленных на основе статистики по аналогичным техническим решениям в выбранной метрике.
7.
Выбранной модели жизненного цикла.
8.
Эталонных параметров производительности.
Разработанный производственный план-график проходит согласование в
рабочей группе, а затем утверждается распоряжением Директора по производству «Об открытии проекта». Распоряжение об открытии проекта:
1.
Назначает менеджера проекта.
2.
Определяет частичный или полный состав рабочей группы.
3.
Определяет сроки проекта.
4.
Определяет бюджет проекта.
5.
Фиксирует версии производственного плана проекта и плана рис-
ков.
Версия производственного плана-графика, согласованная в рабочей группе
и утвержденная распоряжением об открытии проекта, помещается в базу конфигурационного управления. В дальнейшем эта версия используется как «baseline» при разработке рабочего плана-графика.
Если требуется изменение производственного плана-графика, то очередная его версия также должна пройти согласование в рабочей группе, а затем –
утверждение Директором по производству.
План рисков проекта разрабатывается одновременно с производственным
планом-графиком. При разработке плана рисков:
1.
Уточняется список рисков, разработанный при предварительном
планировании.
2.
рисков.
Разрабатываются планы компенсации для наиболее критичных
Список рисков используется при уточнении параметров необходимого резервирования при разработке производственного плана. Планы компенсации
© АПЛАНА Софтвер
23
Положение о планировании
рисков вводятся в действие при возникновении соответствующих событий рисков.
Документы, составляющие план рисков, помещаются в базу конфигурационного управления, причем их версии однозначно связываются с утвержденной
версией производственного плана-графика.
Рабочее планирование
2.5.1.4.
Рабочее планирование выполняется в рамках работ по проекту на всем его
протяжении, начиная с момента вступления в силу распоряжения об открытии
проекта.
Цель рабочего планирования – подготовка информации для выдачи заданий исполнителям, координации и контроля выполнения работ.
Рабочее планирование включает:
1.
Детализацию производственного плана-графика до рабочего.
2.
Корректировку рабочего плана-графика по ходу выполнения проектных работ в рамках производственного плана.
Рабочий план-график разрабатывается и сопровождается менеджером проекта.
Детализация производственного плана-графика производится с использованием информации о ресурсах, предоставляемых Ресурс менеджером. В рабочем плане-графике не учитываются поправки на риск. В базе данных проектов
рабочий план-график разрабатывается подключением производственного планаграфика к общему ресурсному пулу с последующей конкретизацией в отношении ресурсов и сохраняется в базе данных под тем же именем.
На протяжении проекта рабочий план-график постоянно корректируется
менеджером проекта в соответствии с фактическим исполнением задач и событий проекта.
Рабочий план-график должен поддерживаться в актуальном состоянии на
протяжении всего времени выполнения проекта. По завершении проекта рабочий план-график с включенными фактическими данными об исполнении передается в Группу Методологии Разработки для после проектного (postmortem)
анализа и сбора данных для статистической обработки.
Рабочий план-график не находится под версионным контролем или контролем изменений как самостоятельный документ. При возникновении рисковых или проблемных событий, в результате которых было принято решение изменить план проекта, должна быть выпущена новая версия производственного
плана в установленном порядке. Рабочий план-график проекта должен быть
приведен в соответствие с новой версией производственного плана. Предыду© АПЛАНА Софтвер
24
Положение о планировании
щий (незавершенный) вариант рабочего плана-графика фиксируется и передается в Группу Методологии Разработки для последующего анализа.
Контроль проекта и сопровождение рабочего плана-графика проекта регламентируются Положением о контроле выполнения проекта.
2.5.2.
Контроль изменений плана
Версия предварительного плана проекта непосредственно связана с
утвержденным контрактом. В случае изменения контракта, подписания дополнительных соглашений или протоколов к контракту выпускается новая версия
предварительного плана, если принимаемые изменения затрагивают плановые
параметры.
Версия производственного плана непосредственно связана с версией предварительного плана. При выпуске новой версии предварительного плана должна
быть выпущена новая версия производственного плана. Если производственный
план разрабатывался на основе готового технического задания или технического проекта, то выпуск новой версии этих документов должен повлечь за собой
выпуск новой версии производственного плана.
Рабочее планирование производится в рамках действующей версии производственного плана. При выпуске новой версии производственного плана,
предыдущий (незавершенный) вариант рабочего плана-графика фиксируется и
передается в Группу Методологии Разработки для последующего анализа. В
рамках одной версии производственного плана рабочий план-график является
динамически изменяемым документом, который должен поддерживаться в актуальном состоянии в соответствии со статусом проекта без промежуточного
версионного контроля.
Новые версии документов помещаются под контроль изменений с описанием причин и содержания изменений.
Обновленные документы публикуются для информации членов рабочей
группы и руководства. О выпуске новых версий документов посылаются извещения ключевым членам рабочей группы и руководству.
2.6. Измерения
2.6.1.
Измерения в процессе планирования
Измерения используются для определения статуса работ по созданию планов.
Статус работ по созданию плана проекта определяется на основе следующих вех (milestones):
© АПЛАНА Софтвер
25
Положение о планировании
 Предварительный план:
o
Завершение разработки предварительного плана;
o
Согласование предварительного плана в компании;
o
Утверждение предварительного плана заказчиком.
 Производственный план:
o
Завершение оценки объема программного продукта;
o
Завершение оценки рисков проекта;
o
Завершение разработки Производственного плана;
o
Согласование Производственного плана в рабочей группе;
o
Утверждение Производственного плана руководством.
 Рабочий план:
o
Завершение разработки Рабочего плана;
o
Согласование Рабочего плана с исполнителями.
2.6.2.
Измерение объемов программного обеспечения
2.6.2.1.
Выбор метрик для оценки объемов ПО
Метрики для оценок объемов программного обеспечения непосредственно
связаны с применяемыми методологиями разработки. Методологии разработки
подготавливаются и внедряются ГМР.
При открытии проекта разработки в ГМР производится выбор методологии, которая будет использоваться при выполнении проекта. Выбор методологии предопределяет использование соответствующей метрики.
ГМР осуществляет подготовку и внедрение метрик исключительно на основе возможности освоения заявленной точности.
2.6.2.2.
Эталонные параметры производительности
Эталонные параметры производительности формируются в ГМР на основе
фактических данных по завершенным проектам, выполненным по данной методологии.
ГМР планирует и организует выполнение пилотных проектов с целью
освоения новых методологий и получения начальной фактографической информации по производительности.
© АПЛАНА Софтвер
26
Положение о планировании
Как правило, не принимаются к производству проекты, требующие применения новых не апробированных методологий.
2.6.3.
Измерение рисков
Вероятность рисковых событий
2.6.3.1.
Вероятность рисковых событий оценивается в процентах. Поскольку
оценка вероятности производится экспертным путем, расчет производится выбором из дискретного ряда значений.
Последствия рисковых событий
2.6.3.2.
Последствия рисковых событий должны оцениваться в размере ущерба в
денежном выражении. Для обеспечения независимости оценок ущерба от размеров проекта оценка производится в независимых единицах (процентах) относительно стоимости всего проекта в целом. Поскольку оценка производится
экспертным путем, расчет производится выбором из дискретного ряда значений.
2.7. Верификация
Верификация процессов управления планированием выполняется на нескольких уровнях для обеспечения гарантии исполнения всех необходимых
действий.
2.7.1.
Контроль со стороны руководства
Директор по производству
2.7.1.1.
Директор по производству контролирует:
1.
Инициацию и завершение производственных проектов.
2.
Наличие предварительных, производственных и рабочих планов
по всем проектам.
3.
Статус и актуальность планов.
4.
Наличие решений по проблемам внутри проекта и сформированных планов управления рисками.
5.
Своевременность выноса на уровень руководства проблем и рисков, которые не могут быть решены внутри проекта.
6.
проектах.
Отчеты ГКК по проверке исполнения процессов планирования в
© АПЛАНА Софтвер
27
Положение о планировании
Технический директор
2.7.1.2.
Технический директор контролирует:
1.
ботки.
Обоснованность выбора технических решений в проектах разра-
2.
ботки ПО.
Эффективность применения информационных технологий разра-
3.
ботки.
Обеспеченность выполнения проектов инфраструктурой разра-
4.
ствами.
Обеспеченность выполнения проектов инструментальными сред-
5.
Режим и график использования стендового оборудования для выполнения проектов.
6.
Подготовленность персонала для использования требуемых инструментальных средств разработки.
7.
Выполнение пилотных проектов по освоению новых инструментальных средств и технологий разработки.
8.
Деятельность Технического совета по анализу и освоению новых
инструментальных средств и технологий по тематическим направлениям.
9.
Отчеты ГКК по обеспечению проектов.
10.
Уровень производительности труда рабочих групп.
Директор по методологии разработки
2.7.1.3.
Директор по методологии разработки контролирует:
1.
Исполнение процедур выполнения производственных проектов в
соответствии с утвержденными стандартами.
2.
Обеспеченность основных тематических направлений методологиями разработки.
3.
Подготовленность персонала для использования требуемых методологий разработки.
4.
Выполнение пилотных проектов по освоению новых методологий.
5.
Разработку и внедрение стандартов, и методологий разработки,
совершенствования организационной системы.
© АПЛАНА Софтвер
28
Положение о планировании
6.
Работы по сертификации организации.
7.
Деятельность ГМР и ГКК.
8.
Отчеты ГКК по качеству.
9.
Подготовку исходных фактографических данных для маркетинга.
Менеджер ресурсов
2.7.1.4.
Менеджер ресурсов контролирует:
1.
Обеспеченность людскими ресурсами проектов разработки ПО.
2.
Разрешение конфликта ресурсов между проектами.
3.
Качество, уровень квалификации, ресурсов.
4.
Учет информации по ресурсам.
5.
Деятельность по планированию и подбору персонала.
Директор
2.7.1.5.
Директор на периодической основе – один раз в неделю - проводит проверку проектов. Проверке подлежит:
1.
Текущий статус проектов.
2.
Текущий статус рисков проектов.
3.
го уровня.
Наличие решений по проблемам и рискам проектов вне проектно-
4.
Итоговые отчеты ГКК.
2.7.2.
Контроль со стороны руководителя проекта
Руководитель проекта контролирует:
1.
Актуальность планов.
2.
Исполнимость планов.
3.
Учет в плане всех требований ключевых членов рабочей группы.
4.
Состав и статус решаемых с заказчиком вопросов связанных с
планированием проекта
© АПЛАНА Софтвер
29
Положение о планировании
5.
Выполнение решений принятых по рискам и проблемам.
6.
Отчеты ГКК по проекту.
2.7.3.
Контроль со стороны ГКК
Группа контроля качества проводит проверки документов и процедур планирования и выпускает документированные отчеты по результатам проверок.
ГКК не является согласующей инстанцией при выпуске проектных документов.
В задачу ГКК входит информирование рабочей группы проекта и руководства
о несоответствиях, которые оказывают влияние на качество выпускаемых продуктов. Решения о целесообразности исправления выявленных недостатков возлагается на рабочую группу проекта и руководство.
Группа контроля качества проверяет:
1.
Обоснованность Предварительного плана: соответствие предварительного плана проекта техническим предложениям, выбранной методологии,
оценкам производительности.
2.
Соответствие Производственного плана – Предварительному плану, контракту, Техническому заданию, методологии разработки, оценкам производительности.
3.
Соответствие Рабочего плана – Производственному плану.
4.
Наличие Паспорта проекта в составе плана проекта.
5.
Наличие списка рисков.
6.
Наличие плана рисков для наиболее значимых событий риска.
7.
Документирование, адресацию и разрешение выявленных про-
8.
Контроль выполнения процедур планирования.
блем.
2.8. Совершенствование организационной системы
В организации действует на постоянной основе процесс совершенствования организационной системы. Процесс разбивается на последовательность
проектов. Результатом проектов – итоговыми вехами (milestone) является достижение очередного уровня СММ по факту с подтверждением внутреннего
аудита.
Распределение ответственности в проектах совершенствования организационной системы:
© АПЛАНА Софтвер
30
Положение о планировании
1.
Руководитель проектов – Директор по Методологии.
2.
Разработчик – ГМР.
3.
Тестировщик – ГКК.
3.
Стандарты планирования
3.1. Составные части плана проекта
В состав обязательных частей плана входят: паспорт проекта, план-график
работ и план рисков.
3.1.1.
Паспорт проекта
Паспорт проекта заполняется в Rational Clear Quest с использованием
формы «Project».
При инициации проекта на фазе Presale паспорт проекта создается (пункт
меню «Actions/New Project») и заполняется менеджером по продаже. С момента
запуска проекта в производство его паспорт сопровождает менеджер проекта.
Rational Clear Quest фиксирует историю изменений паспорта проекта.
Паспорт проекта является основным документом, требующимся при регистрации проекта.
При инициации проекта на фазе Presale для проекта указывается:
1.
Идентификатор проекта.
2.
Название проекта.
3.
Заказчик.
4.
Цель проекта.
5.
Тип проекта.
6.
Финансирование проекта (источник).
7.
Стоимость (примерная оценка).
К моменту открытия проекта в паспорте также должны быть заполнены:
8.
Задачи проекта
9.
Общий состав работ
10.
Приоритет проекта
© АПЛАНА Софтвер
31
Положение о планировании
11.
Ограничения проекта
12.
Состав ключевых членов рабочей группы
Остальные поля паспорта заполняются в ходе проекта. После завершения
проекта полностью заполненный паспорт проекта передается в ГМР для архивирования.
3.1.2.
План график
План график проекта составляется с использованием MS Project 2000.
План график разрабатывается на основе шаблона плана, соответствующего выбранной методологии проекта.
Предварительный план-график составляется на основе описания технических решений, включаемых в ТКП, предварительного выбора модели жизненного цикла, оценок производительности в метрике технических требований по
аналогичным проектам с учетом рисков проекта.
Производственный план-график составляется на основе анализа требований, выбора методологии разработки, оценок производительности в метрике,
соответствующей выбранной методологии проекта и оценок объема программного продукта с учетом рисков проекта.
Рабочий план-график составляется на основе согласованного Производственного плана детализацией плана до уровней активностей без учета рисков.
3.1.3.
План рисков
План рисков составляется на основе стандарта: P1540, D10.0 Draft Standard for Software Life Cycle Processes--Risk Management
Состав плана рисков
3.1.3.1.
План рисков разрабатывается на основе шаблона плана рисков, который
готовится в ГМР. План рисков включает в себя:
1.
рисков
Список рисков, упорядоченный в порядке убывания экспозиции
2.
Распределение суммарной экспозиции рисков во времени (характеристическая кривая рисков).
3.
Риск проекта в целом.
4.
План компенсации для наиболее серьезных рисков. Уровень рисков, для которых должен быть разработан план компенсации, устанавливается
на основе приоритета проекта.
© АПЛАНА Софтвер
32
Положение о планировании
Список рисков
3.1.3.2.
Список рисков должен включать следующие необходимые поля:
1.
Краткое описание условия возникновения (наименование) рискового события.
2.
Ссылка на веху (milestone) в плане-графике работ, с которым связано возникновение рискового события. Если указанная веха в плане успешно
пройдена, значит, рисковое событие не состоялось.
3.
Ожидаемая дата возникновения рискового события (дата вехи).
4.
Вероятность рискового события.
5.
Оценка уровня последствий рискового события.
6.
Экспозиция рискового события - произведение вероятности на
уровень последствий (в дальнейшем используется термин «уровень риска»)
Характеристическая кривая рисков
3.1.3.3.
Характеристическая кривая рисков представляет собой график зависимости суммы уровней всех рисков, которые могут произойти на временном промежутке от текущего момента до конца проекта. Кривая рисков – убывающая
зависимость от риска проекта в целом, в начале проекта, до нулевого значения в
конце проекта.
Форма характеристической кривой рисков является исходной информацией для выбора или изменения методологии ведения проекта.
Риск проекта в целом
3.1.3.4.
Риск проекта в целом является суммой уровней всех рисков проекта.
Планы компенсации рисков
3.1.3.5.
Планы компенсации рисков должны быть составлены для проектов:
-
с низким приоритетом – для всех рисков с уровнем выше 0.5
-
со средним приоритетом – для всех рисков с уровнем выше 0.3
-
с высоким приоритетом – для всех рисков с уровнем выше 0.1
Планы компенсации рисков представляет собой план мероприятий, разработанный с целью уменьшения ущерба от события риска. План компенсации
рисков вводится в действие решением рабочей группы проекта или решением
руководства.
© АПЛАНА Софтвер
33
Положение о планировании
Решение о вводе в действие плана компенсации должно быть документировано. Извещения о вводе плана компенсации в действие должны быть
разосланы всем членам рабочей группы, соисполнителям, в ГКК, ГМР и руководству.
Решение о вводе плана компенсации в действие является основанием для
изменения проектных документов, находящихся под контролем изменений.
Параметры рисков
3.1.3.6.
3.1.3.6.1.
Вероятность рисков
В плане рисков используются следующие значения вероятности рисковых
событий:
1.
«Очень высокая»
-
80%
2.
«Высокая»
-
60%
3.
«Средняя»
-
40%
4.
«Низкая»
-
20%
3.1.3.6.2.
Последствия рисков
В плане рисков используются следующие значения последствий рисковых
событий:
1.
«Очень высокая»
-
100%
2.
«Высокая»
-
70%
3.
«Средняя»
-
40%
4.
«Низкая»
-
10%
Последствия рисковых событий измеряется в процентах, как отношение
ущерба к стоимости проекта. Значение последствия - 100%, означает, полную
неудачу проекта.
3.2. Стандартизация ролей проекта
3.2.1.
Состав рабочей группы
Стандартизация ролей проекта осуществляется на основе анализа целей
проектов разработки программного обеспечения.
В проекте разработки программного обеспечения могут быть выделены
следующие цели, которые в совокупности определяют успех проекта:
© АПЛАНА Софтвер
34
Положение о планировании
1.
Обеспечение соответствия свойств разрабатываемого продукта
бизнес задачам Заказчика при сдаче результирующего продукта;
2.
Компании;
Обеспечение соответствия результатов проекта бизнес задачам и
3.
Обеспечение соответствия уровня технических решений задачам
проекта и технической политике и Компании;
4.
Обеспечение требуемой производительности реализации продук-
5.
Обеспечение выявления и разрешения проблем;
та;
6.
Обеспечение требуемой эффективности применения продукта
пользователями;
7.
Обеспечение требуемой эффективности внедрения и сопровождения продукта у Заказчика.
Рабочая группа проекта разработки программного обеспечения должна
быть полностью укомплектована следующими ключевыми проектными ролями
в соответствии с целями проекта:
№
Цель
1.
Обеспечение соответствия свойств разрабаты- Аналитик
ваемого продукта бизнес задачам Заказчика.
2.
Обеспечение соответствия результатов проекта Менеджер проекта
бизнес задачам и Компании.
3.
Обеспечение соответствия уровня технических Конструктор
решений задачам проекта и технической политике и Компании
4.
Обеспечение требуемой производительности Разработчик
реализации продукта
5.
Обеспечение контроля разрешения техниче- Тестировщик
ских проблем
6.
Обеспечение требуемой эффективности приме- Документатор
нения продукта пользователями
7.
Обеспечение требуемой эффективности внед- Интегратор
рения и сопровождения продукта у Заказчика
© АПЛАНА Софтвер
Роль
35
Положение о планировании
3.2.2. Основные функции ключевых ролей
В соответствии со своими целями роли имеют следующие функции:
№
Роль
Основные функции
1
Аналитик
Обследование автоматизируемых процессов у заказчика;
Разработка и управление требованиями к продукту;
Взаимодействие с бизнес представителями заказчика.
2
Менеджер
проекта
Разработка планов;
Координация проекта;
Организация решения проблем;
Взаимодействие с менеджментом заказчика.
3
Конструктор
Выбор платформ реализации и разработки;
Разработка проектных решений;
Разработка архитектуры;
Авторский надзор за концептуальной и архитектурной целостностью.
4
Разработчик
Разработка программ;
Отладка.
5
Тестировщик
Разработка плана тестирования;
Тестирование;
Контроль фиксации ошибок и проблем;
Организация испытаний и опытной эксплуатации;
Взаимодействие с пользователями опытной версии продукта.
6
Документатор
Разработка документации, справочных и обучающих систем;
Обучение пользователей;
Взаимодействие с пользователями.
7
Интегратор
Конфигурационное управление;
Сборка дистрибутивов;
Развертывание продукта на объектах внедрения;
Взаимодействие с техническим персоналом заказчика.
3.2.3. Масштабирование рабочей группы
Для небольших проектов несколько ролей может выполняться одним специалистом. В интересах обеспечения качества не допускается совмещение ролей, имеющих запланированные противоречия в поставленных целях, которые
требуют организации взвешенных компромиссных решений. При планировании
структуры рабочей группы проекта следует руководствоваться следующей матрицей совместимости:
© АПЛАНА Софтвер
36
Разработчик
Тестировщик
Документатор
Интегратор
Н
Конструктор
Аналитик
Менеджер
проекта
Аналитик
Положение о планировании
В
Н
Р
Р
В
В
Н
Н
Н
Н
Р
Н
Р
Р
Н
В
В
Р
В
Менеджер проекта
Н
Конструктор
В
В
Разработчик
Н
Н
Р
Тестировщик
Р
Н
Н
Н
Документатор
Р
Н
Р
В
Р
Интегратор
В
Н
Р
В
В
Р
Р
Условные обозначения:
Р
Рекомендуется;
В
Возможно;
Н
Не допускается.
Для крупных проектов рабочая группа должна быть структурирована.
Структурирование рабочей группы в зависимости от типа проекта может быть
выполнено двумя путями.
Первый способ – структурирование проекта в целом, когда в проекте выделяются самостоятельные подпроекты. В этом случае для каждого подпроекта
создается своя рабочая группа по общим правилам, причем рабочая группа подпроекта функционирует на правах подряда, а в роли заказчика выступает рабочая группа главного проекта. Взаимодействие рабочих групп главного и подчиненного проекта регламентируется Положением об управлении самостоятельными рабочими группами.
Второй способ – включение в одну роль нескольких специалистов. В этом
случае назначается руководитель ролевой группы, за которым закрепляется
ключевая роль в проекте. Для идентификации ключевой роли в проекте в названии роли добавляется определение «Главный», например «Главный конструктор». Роли, не являющимися ключевыми, могут быть в зависимости от потребностей проекта включаться в проект на требуемый период времени.
© АПЛАНА Софтвер
37
Положение о планировании
3.2.4.
группы
Формирование рабочей группы и период действия рабочей
Рабочая группа проекта в полном составе ключевых членов создается при
открытии проекта разработки программного обеспечения. На предпроектной
фазе (Presale) в работах участвуют: Менеджер по продаже, Аналитик, Конструктор и Менеджер проекта.
Подбор ключевых членов рабочей группы осуществляет руководитель
проекта. Координирует и контролирует работу по выделению специалистов для
участия в проектах Менеджер ресурсов. Решение об открытии проекта и назначении рабочей группы утверждается Директором по производству.
Ключевые роли рабочей группы должны быть заполнены на все время
действия проекта от его начала до завершения. Смена специалистов на ключевых ролях проекта допускается только в исключительных ситуациях (увольнение, болезнь и пр.). Специалисты на не ключевые роли могут привлекаться в
проект на ограниченное время по мере необходимости.
3.2.5.
Управление в рабочей группе
Ключевые роли рабочей группы несут коллективную неразделяемую ответственность за результаты проекта.
Ключевые роли рабочей группы обладают равными правами при принятии
решений по проекту. Решения считаются принятыми, если сформировано единое мнение по решаемому вопросу среди ключевых ролей рабочей группы.
При отсутствии согласия решение принимает менеджер проекта, при этом
ключевые члены рабочей группы не согласные с данным решением обязаны:
1)
принять данное решение к исполнению;
2)
документально оформить обоснование своих возражений;
3)
передать документ с обоснованием на рассмотрение в рабочую
группу проекта и руководству.
Факты разногласий в рабочей группе являются проблемой, выходящей за
рамки проекта, и должны быть рассмотрены руководством в приоритетном порядке.
Специалисты, выполняющие не ключевые роли в проекте, несут ответственность перед руководителем ролевой группы.
3.2.6.
Выделение ресурсов на проекты
Полный список сотрудников с информацией об их специализации, квалификации, опыте, занятости в проектах ведет Менеджер ресурсов.
© АПЛАНА Софтвер
38
Положение о планировании
Менеджер ресурсов производит учет рабочего времени сотрудников, координирует и контролирует выделение сотрудников для участия в проектах, отслеживает экономическую эффективность использования людских ресурсов в
производстве и обеспеченность потребности проектов в сотрудниках требуемой
специализации и квалификации.
Менеджер ресурсов ведет учет индивидуальной производительности в
проектах разработки программного обеспечения. Данные индивидуальной производительности используются для уточнения результирующего плана графика
работ.
Для обеспечения возможности сбора информации по производительности
процессов разработки ПО, статистического анализа и организации планирования на основе метрик планируемых объемов программного обеспечения при
планировании проектов должны использоваться стандартизированные роли
проектов разработки ПО.
С целью возможности адаптации произвольной методологии в процесс
разработки, стандартизованы должны быть только ключевые роли.
3.3. Стандартизация моделей жизненного цикла
Модели жизненного цикла разработки программного обеспечения разрабатываются в ГМР как составная часть методологии разработки. Модели жизненного цикла создаются для всех тематических направлений на основе стандарта 1074-1997 IEEE Standard for Developing Software Life Cycle Processes.
Модели жизненного цикла включают в себя модель процессов разработки,
в которой для каждого процесса определены:
файлов),
входная информация (перечень документов и типов программных
выходная информация (перечень документов и типов программных файлов),
-
исполняющие проектные роли,
-
инструментальные средства,
-
метрики объемов работ,
-
методические рекомендации исполнителям,
-
пред- и пост- условия процесса.
© АПЛАНА Софтвер
39
Положение о планировании
3.4. Шаблоны для разработки планов
Шаблоны для разработки планов подготавливаются в ГМР. Для каждой
методологии, освоенной в Центре, должен существовать соответствующий
шаблон плана.
Шаблоны планов графиков работ разрабатываются на основе моделей
жизненного цикла в MS Project 2000. При этом наименование задач шаблона
плана совпадает с наименованием процессов, а структура задач соответствует
структуре процессов.
Поскольку однозначного соответствия между моделью процессов и планом, может не существовать для итеративных моделей, для каждого конкретного проекта должна быть при необходимости выполнена адаптация шаблона плана под условия конкретного проекта.
3.5. Правила формирования планов
Идентификатор плана должен совпадать с идентификатором проекта в
паспорте проекта. Наименование суммарных задач плана, соответствующие
стадиям и этапам из шаблона плана, являются стандартными и не могут быть
изменены. По наименованиям суммарных задач, совпадающих с наименованием
процессов, будут формироваться выборки из базы данных проектов для получения статистических данных в ГМР.
Разработка планов состоит в детализации задач шаблона в соответствии с
формулировками требований. Подготовка Рабочего плана состоит в детализации задач Производственного плана до уровня отдельных заданий разработчикам (активностей).
Разработка Предварительного плана и Производственного плана осуществляется на основе ресурсного пула проектных ролей. Разработка рабочего
плана производится на основе ресурсного пула сотрудников.
Трудоемкость для Предварительного и Производственного планов рассчитывается с учетом рисков проекта. То есть расчетные величины трудоемкости
по эталонной производительности увеличиваются на величину уровня риска
(умножаются на 1+R, где R – суммарная экспозиция рисков).
Рабочий план разрабатывается без учета рисков. Реально произошедшие
события риска отражаются в Рабочем плане по факту возникновения при выполнении проекта (например, включением новых задач и изменением длительности).
3.6. Стандартизация метрик объемов продукта
Метрики объемов программного продукта подготавливаются в ГМР на основе стандарта: 1045-1992 IEEE Standard for Software Productivity Metrics
© АПЛАНА Софтвер
40
Положение о планировании
Общей для всех методологий метрикой объемов является метрика требований. Метрика требований формируется на основе ведения общей базы данных
требований к ПО по всем проектам с фиксацией фактических объемов и производительности реализации требований по выполненным проектам.
Метрика требований используется для разработки предварительных планов.
В числе метрик могут быть использованы: Function Points, Feature Points,
SLOC, Количество классов, Количество модулей, Количество таблиц баз данных и др.
Выбор метрик осуществляется в ГМР на основе анализа статистической
точности использования конкретной метрики на данном этапе и трудоемкости
ее использования. Использование более сложных и более точных метрик осуществляется только при наличии практической потребности в увеличении точности расчетов после практического освоения и набора статистики по более
простым метрикам.
3.7. Стандартизация параметров производительности
Расчет параметров производительности выполняется в ГМР на основе статистического анализа параметров выполненных проектов. Область применения
метрики ограничена используемой методологией. Величина разброса (дисперсии) значений производительности в данной метрике является показателем качества метрики.
ГМР формирует предложения по выбору эталонных параметров производительности, которые будут использоваться для планирования новых проектов.
Эталонные параметры производительности утверждаются Техническим
директором Центра.
Расчет трудоемкости проекта на основе эталонных параметров производительности для малых и средних проектов может выполняться прямым способом.
Для больших проектов расчет должен выполняться с использованием методик
IFPUG, COCOMO и др. с помощью средств SPR KnowledgePLAN, CoStar и др.
3.8. Показатели качества планов графиков
При разработке планов следует руководствоваться следующими показателями качества планов:
 Каждая суммарная задача уровня стадий и этапов должна иметь в своем
составе итоговую веху. Определение вех должно быть однозначным и контролируемым.
 Для каждой вехи в плане-графике должен быть исполнитель – ответственный за выполнение всей задачи в целом.
© АПЛАНА Софтвер
41
Положение о планировании
 Каждая задача должна иметь присвоенный приоритет. По умолчанию MS
Project 2000 устанавливает для всех задач средний приоритет (500 из 1000). При
разработке планов менеджер проекта должен проверить и откорректировать
правильность установки приоритетов.
 Каждая задача должна иметь корректный тип. По умолчанию для новых
задач устанавливается тип «Fixed units» и «Effort driven». При разработке планов тип задач должен быть просмотрен и откорректирован. В частности для задач, связанных с согласованием документов с внешними контрагентами должен
быть выбран тип «Fixed duration», «Non effort driven».
 Ресурсы плана не должны быть перегружены. Выравнивание ресурсов
должно быть выполнено вручную или автоматически с опцией «Priority, Standard».
 Связи между задачами не должны пересекать границы суммарных задач.
Необходимость пересечения границ в Предварительном и Производственном
плане, вообще говоря, указывает на неадекватность модели жизненного цикла.
В Рабочем плане формирование связей, пересекающих границы суммарных задач, допускается с целью оптимизации плана.
 Задачи должны иметь корректный «Constraint type». По умолчанию все
новые задачи имеют тип «As soon as possible». Установление иного типа задач
должно быть обусловлено ограничениями проекта и сопровождаться комментарием.
 Все планы должны разрабатываться с использованием стандартного календаря.
3.9. Базы данных проектов
Для ведения проектов создаются три базы данных на сервере разработки
Центра:
1.
База Presale.
2.
Рабочая база.
3.
Архивная база.
База Presale служит для разработки и хранения Предварительных планов.
Пользователями базы данных являются менеджеры по продаже, аналитики, менеджеры проектов, ГМР, ГКК, руководство Центра. Выделение Предварительных планов в отдельную базу данных обусловлено тем, что информация базы
используется на предпроектной фазе, пользователями базы являются в первую
очередь менеджеры по продажам, и не все Предварительные планы перейдут в
производство.
© АПЛАНА Софтвер
42
Положение о планировании
Рабочая база является основной базой выполнения проектов. Пользователями данной базы являются менеджеры проектов, ГМР, ГКК. База данных интегрируется со средством мониторинга проектов – Project Central.
Архивная база данных служит для архивного хранения выполненных проектов. Пользователями базы данных являются сотрудники ГМР. Информация из
базы данных служит для анализа выполненных проектов, сбора статистических
данных.
© АПЛАНА Софтвер
43
Положение о планировании
4. Документированные процедуры
4.1.
№
Планирование Presale
Действие
Исполнители
Входные
документы
Результирующие
документы
Требования
Исполнителем указанных задач определяется
менеджер
по продаже
1.
Подготовка
переговорам
заказчиком
к Менеджер по прос даже
Внесенные
в план работ по Presale задачи
по ведению
переговоров
2.
Разработка пла- Менеджер по про- Запрос
на
на работ по Pre- даже
ТКП
(Resale
quest
for
Proposal),
полученный
в результате
переговоров
менеджера
по продажам
с заказчиком
Раздел
плана работ по Presale,
посвященный
предполагаемому
будущему
проекту.
Внесенный
в
Clear
Quest паспорт проекта.
3.
Открытие
sale
Pre- Коммерческий ди- Запрос
на
ректор
ТКП,
паспорт проекта, план работ по Presale.
Паспорт
проекта (в
состоянии
«Creating
Workgroup
»)
4.
Выделение со- Директор по про- План работ
трудников
на изводству
по Presale,
работы по Preпаспорт
sale
проекта.
Паспорт
проекта (в
состоянии
«Developing
Proposal»)
© АПЛАНА Софтвер
44
Положение о планировании
4.2.
№
Предварительное планирование
Входные
документы
Результирующие
документы
1.
Разработка без- Менеджер по про- Предваририскового вари- даже
тельные
анта предваритребования,
тельного планаполученные
графика проекта
в результате
предварительного обследования
и
анализа.
Описание
технических
решений,
которые
предполагается включить в ТКП.
Безрисковый вариант предварительного планаграфика
проекта в
базе ProjectPresale
2.
Разработка
Аналитик
списка
рисков
проекта
Список
рисков
проекта
базе КУ
3.
Действие
Исполнители
Предварительные
требования,
безрисковый
вариант
предварительного
планаграфика
проекта
Рисковая
кор- Менеджер по про- Безрисковый
рекция предва- даже
вариант
рительного плапредварина-графика протельного
екта
планаграфика
проекта.
Список рисков проекта.
© АПЛАНА Софтвер
Требования
в
Вариант
предварительного
планаграфика
проекта в
базе ProjectPresale,
учитывающий риски.
45
Положение о планировании
№
Действие
Входные
документы
Результирующие
документы
4.
Учет заложен- Менеджер по про- Предвариных в предвари- даже
тельный
тельный
план
план-график
трудозатрат при
проекта.
определении
стоимости работ
Раздел
ТКП, посвященный
коммерческим условиям.
5.
Включение
Менеджер по про- Предварипредварительно- даже
тельный
го
планаплан-график
графика проекта
проекта.
в состав ТКП
Остальные
подготовленные части
ТКП.
Паспорт
проекта.
Вариант
ТКП
для
представления заказчику.
Паспорт
проекта (в
состоянии
«Discussing
Proposal»).
6.
Утверждение
Коммерческий дипредварительно- ректор, Директор
го
плана- по производству.
графика проекта
(в составе ТКП)
руководством
Вариант
ТКП
для
представления заказчику.
Утвержденный
руководством вариант ТКП.
7.
Согласование
Менеджер по про- Утвержденпредварительно- даже
ный
рукого
планаводством
графика проекта
вариант
(в составе ТКП)
ТКП. Пасс заказчиком
порт проекта.
Замечания
заказчика
по
ТКП.
Согласованная
с
заказчиком
версия
ТКП, размещенная в
базе
КУ.
Паспорт
проекта (в
состоянии
«Approved»
).
© АПЛАНА Софтвер
Исполнители
Требования
46
Положение о планировании
№
Действие
Исполнители
Входные
документы
Результирующие
документы
8.
Включение
Менеджер по про- ПредвариВариант
предварительно- даже
тельный
текста дого
планаплан-график говора.
графика проекта
проекта из
в договор
согласованной с заказчиком версии ТКП.
9.
Утверждение
Менеджер по про- Вариант
Заключенпредварительно- даже
текста дого- ный догого
планавора.
вор.
графика проекта
(в составе договора при его заключении)
4.3.
№
Требования
Производственное планирование
Действие
Исполнители
Входные
документы
Результирующие
документы
1.
Запуск проекта в Директор по про- Паспорт
производство
изводству
проекта.
Паспорт
проекта (в
состоянии
«In Work»).
2.
Разработка про- Менеджер проекта, Шаблон
изводственного
члены РГ проекта
планаплана-графика
графика.
Предварительный
планграфик.
Производственный
планграфик
в
базе проектов.
© АПЛАНА Софтвер
Требования
47
Положение о планировании
№
Действие
Входные
документы
Результирующие
документы
3.
Уточнение спис- Менеджер проекта, Список риска рисков проек- члены РГ проекта
ков проекта.
та
Производственный
план-график
проекта.
Уточненный список
рисков
проекта.
4.
Разработка пла- Менеджер проекта, Уточненный План рисна компенсации члены РГ проекта
список рис- ков в базе
рисков проекта
ков проекта. КУ.
Производственный
план-график
проекта.
5.
Рисковая
кор- Менеджер проекта
рекция
производственного
плана-графика
проекта
Производственный
план-график
проекта.
План рисков
в базе КУ.
Производственный
планграфик
проекта
готовый
для утверждения.
6.
Утверждение
Директор по про- Производисходных пара- изводству.
ственный
метров проекта.
план-график
проекта готовый
для
утверждения.
Распоряжение об
открытии
проекта.
Версия
производственного
планаграфика
проекта в
базе КУ.
© АПЛАНА Софтвер
Исполнители
Требования
48
Положение о планировании
4.4.
Рабочее планирование
№
Действие
1.
Детализация
Производственного плана
2.
Введение в план Менеджер проекта,
трудоемкости
Конструктор
заданий разработчикам
3.
Формирование
Менеджер проекта
запроса на ресурсы исполнителей
4.
Выделение
полнителей
проект
© АПЛАНА Софтвер
Исполнители
Входные
документы
Результирующие
документы
Требования
Менеджер проекта, ТЗ, ПроизКонструктор
водственный
план, Технический
проект
Детализированный
План
до
уровня заданий исполнителям
Детализация плана
проходит
поэтапно в
соответствии
с
этапами
разработки
технического проекта
Детализированный
План
до
уровня заданий исполнителям,
Трудоемкость
Детализированный
план с введенными
трудоемкостями.
Используются имеющиеся
данные по
трудоемкости, разработанные
на
этапе
создания
Производственного
плана
Детализированный план
с введенными трудоемкостями
Список
требуемых
ресурсов
исполнителей
ис- Менеджер проекта, Список трена Менеджер ресурсов буемых ресурсов исполнителей
Согласованный
список
требуемых
ресурсов
исполнителей
49
Положение о планировании
№
Действие
Исполнители
Входные
документы
Результирующие
документы
5.
Подключение
Менеджер проекта
плана к ресурсному пулу и
назначение ресурсов
Детализиро- Рабочий
ванный план план прос введенны- екта
ми трудоемкостями
6.
Согласование
Менеджер проекта
через
Central
распределения
заданий с исполнителями
Рабочий
Рабочий
план проек- план прота
екта
(согласованный с исполнителями)
© АПЛАНА Софтвер
Требования
Рабочий
план
сохраняется в
базе данных
с
BaseLine
заданий
исполнителям
50
Положение о планировании
Лист изменений
Версия
Дата
© АПЛАНА Софтвер
Авторы
Содержание изменения
51