оценки предполагаемого объема промежуточных программных продуктов (или объема их изменений),
объема работ и затрат по проекту.
2. Составление графика разработки базируется на прежнем опыте:
по возможности следует использовать подобные проекты.
3. В графике разработки указываются даты этапов и критических зависимостей, а также другие ограничения.
4. Продолжительность работ и временные рамки этапов в графике разработки должны выбираться таким образом, чтобы обеспечить достаточную точность оценки хода проекта.
5. Предположения, выдвинутые при создании графика, должны документироваться.
6. График разработки документируется, проверяется и согласуется.
Операция 13 Выявление, оценка и документирование рисков по проекту разработки, связанных с затратами, графиком и техническими аспектами проекта.
1. Анализ и определение значительности рисков на основании их потенциального влияния на проект. 2. Определение страховочных действий, связанных с рисками.
Примеры страховочных действий:
внесение в график резерва по времени;
создание альтернативных планов укомплектования персоналом;
создание альтернативных планов по использованию дополнительного аппаратного обеспечения.
Операция 14 Подготовка планов по использованию в проекте специализированных средств и вспомогательного инструментария.
1. Выполнение оценочного расчета потребностей в специализированных средствах и вспомогательном инструментарии на основании оценок объема промежуточных программных продуктов и других характеристик.
Примеры специализированных средств и вспомогательного инструментария разработки:
хост-компьютеры и периферийное оборудование для разработки ПО,
компьютеры и периферийное оборудование для тестирования ПО,
целевая операционная среда,
другое вспомогательное ПО.
2. Распределение обязанностей и обсуждение соглашений по приобретению или разработке этих средств и инструментов.
3. Планы рассматриваются всеми задействованными группами.
Операция 15 Документирование данных по планированию разработки.
1. Документируемая информация включает в себя сами оценки и дополнительные сведения, необходимые для воспроизведения оценочных расчетов и определения их обоснованности.
2. Записи данных по плану разработки ПО должны быть управляемыми и контролируемыми.
Измерения и анализ
Проверка внедрения
8.3. Отслеживание хода проекта и контроль над ним
Цели
Обязательства по выполнению
Необходимые предпосылки
Выполняемые операции
Измерения и анализ
Проверка внедрения
8.4. Управление производственным субподрядом
Цели
объема работ и затрат по проекту.
2. Составление графика разработки базируется на прежнем опыте:
по возможности следует использовать подобные проекты.
3. В графике разработки указываются даты этапов и критических зависимостей, а также другие ограничения.
4. Продолжительность работ и временные рамки этапов в графике разработки должны выбираться таким образом, чтобы обеспечить достаточную точность оценки хода проекта.
5. Предположения, выдвинутые при создании графика, должны документироваться.
6. График разработки документируется, проверяется и согласуется.
Операция 13 Выявление, оценка и документирование рисков по проекту разработки, связанных с затратами, графиком и техническими аспектами проекта.
1. Анализ и определение значительности рисков на основании их потенциального влияния на проект. 2. Определение страховочных действий, связанных с рисками.
Примеры страховочных действий:
внесение в график резерва по времени;
создание альтернативных планов укомплектования персоналом;
создание альтернативных планов по использованию дополнительного аппаратного обеспечения.
Операция 14 Подготовка планов по использованию в проекте специализированных средств и вспомогательного инструментария.
1. Выполнение оценочного расчета потребностей в специализированных средствах и вспомогательном инструментарии на основании оценок объема промежуточных программных продуктов и других характеристик.
Примеры специализированных средств и вспомогательного инструментария разработки:
хост-компьютеры и периферийное оборудование для разработки ПО,
компьютеры и периферийное оборудование для тестирования ПО,
целевая операционная среда,
другое вспомогательное ПО.
2. Распределение обязанностей и обсуждение соглашений по приобретению или разработке этих средств и инструментов.
3. Планы рассматриваются всеми задействованными группами.
Операция 15 Документирование данных по планированию разработки.
1. Документируемая информация включает в себя сами оценки и дополнительные сведения, необходимые для воспроизведения оценочных расчетов и определения их обоснованности.
2. Записи данных по плану разработки ПО должны быть управляемыми и контролируемыми.
Измерения и анализ
Измерение 1 Выполнение измерений и использование их результатов для определения состояния работ по планированию проекта разработки.
Примеры измерений:
определение степени выполнения этапов работ по планированию разработки в сравнении с планом;
определение объема выполненных работ по планированию разработки и использованных при этом ресурсов.
Примеры измерений:
определение степени выполнения этапов работ по планированию разработки в сравнении с планом;
определение объема выполненных работ по планированию разработки и использованных при этом ресурсов.
Проверка внедрения
Проверка 1 Регулярная проверка высшим руководством выполнения работ по планированию разработки.
Регулярные проверки проводятся высшим руководством для получения своевременной информации о производственном процессе и его понимания на соответствующем уровне абстракции. Промежутки времени между проверками должны соответствовать потребностям организации и могут быть длительными, если в организации имеется работающая система оповещения об исключительных ситуациях.
1. Проверка технических, финансовых, кадровых аспектов и выполнения графика работ.
2. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
3. Изучение рисков проекта разработки.
4. Поручение и проверка задач, а также отслеживание их выполнения.
5. Подготовка итогового отчета по результатам каждой проверки и распространение его среди задействованных групп и сотрудников.
Проверка 2 Регулярные и событийные проверки работ по планированию проекта разработки со стороны менеджера проекта.
1. В проверках принимают участие представители задействованных групп.
2. Сравнение статуса и текущих результатов работ по планированию проекта разработки с техническим заданием по проекту и установленными требованиями.
3. Рассмотрение зависимостей между группами.
4. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
5. Рассмотрение рисков проекта разработки.
6. Поручение и проверка действий, а также отслеживание их выполнения.
7. Подготовка итогового отчета по результатам каждой проверки и распространение его среди задействованных групп и сотрудников.
Проверка 3 Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов, связанных с планированием проекта, и выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО». Минимальное содержание проверок и/или аудитов:
1. Мероприятия по оценочному расчету и планированию проекта разработки.
2. Мероприятия по обсуждению и принятию обязательств по проекту.
3. Мероприятия по подготовке плана разработки ПО.
4. Стандарты, используемые при подготовке плана разработки ПО.
5. Содержание плана разработки ПО.
Регулярные проверки проводятся высшим руководством для получения своевременной информации о производственном процессе и его понимания на соответствующем уровне абстракции. Промежутки времени между проверками должны соответствовать потребностям организации и могут быть длительными, если в организации имеется работающая система оповещения об исключительных ситуациях.
1. Проверка технических, финансовых, кадровых аспектов и выполнения графика работ.
2. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
3. Изучение рисков проекта разработки.
4. Поручение и проверка задач, а также отслеживание их выполнения.
5. Подготовка итогового отчета по результатам каждой проверки и распространение его среди задействованных групп и сотрудников.
Проверка 2 Регулярные и событийные проверки работ по планированию проекта разработки со стороны менеджера проекта.
1. В проверках принимают участие представители задействованных групп.
2. Сравнение статуса и текущих результатов работ по планированию проекта разработки с техническим заданием по проекту и установленными требованиями.
3. Рассмотрение зависимостей между группами.
4. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
5. Рассмотрение рисков проекта разработки.
6. Поручение и проверка действий, а также отслеживание их выполнения.
7. Подготовка итогового отчета по результатам каждой проверки и распространение его среди задействованных групп и сотрудников.
Проверка 3 Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов, связанных с планированием проекта, и выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО». Минимальное содержание проверок и/или аудитов:
1. Мероприятия по оценочному расчету и планированию проекта разработки.
2. Мероприятия по обсуждению и принятию обязательств по проекту.
3. Мероприятия по подготовке плана разработки ПО.
4. Стандарты, используемые при подготовке плана разработки ПО.
5. Содержание плана разработки ПО.
8.3. Отслеживание хода проекта и контроль над ним
Группа ключевых процессов для уровня 2: повторяемый уровень.
Цель группы ключевых процессов «Отслеживание хода проекта и контроль над ним» заключается в том, чтобы обеспечить адекватный обзор фактического выполнения проекта, позволяя руководству предпринимать эффективные меры при значительном отклонении хода проекта от планов разработки.
Данная группа ключевых процессов включает в себя отслеживание и сравнение результатов разработки с документированными оценками, обязательствами и планами, а также корректировку этих планов на основании фактических результатов.
Отслеживание работ по проекту, распространение информации об их состоянии и пересмотр планов происходит на основе документированного плана проекта разработки (т. е. плана разработки ПО, описанного в группе ключевых процессов «Планирование проекта»). Производство работ контролируется руководством. Ход проекта оценивается путем сравнения фактических показателей объема ПО, вложенных усилий, финансовых затрат и выполнения графика с плановыми значениями при завершении определенных промежуточных программных продуктов или на определенных этапах. При обнаружении несоответствия планам проекта предпринимаются корректирующие действия. Эти действия могут включать в себя пересмотр плана разработки ПО с целью отражения в нем фактических результатов и перепланирования оставшейся работы либо принятие мер по повышению производительности.
Цель группы ключевых процессов «Отслеживание хода проекта и контроль над ним» заключается в том, чтобы обеспечить адекватный обзор фактического выполнения проекта, позволяя руководству предпринимать эффективные меры при значительном отклонении хода проекта от планов разработки.
Данная группа ключевых процессов включает в себя отслеживание и сравнение результатов разработки с документированными оценками, обязательствами и планами, а также корректировку этих планов на основании фактических результатов.
Отслеживание работ по проекту, распространение информации об их состоянии и пересмотр планов происходит на основе документированного плана проекта разработки (т. е. плана разработки ПО, описанного в группе ключевых процессов «Планирование проекта»). Производство работ контролируется руководством. Ход проекта оценивается путем сравнения фактических показателей объема ПО, вложенных усилий, финансовых затрат и выполнения графика с плановыми значениями при завершении определенных промежуточных программных продуктов или на определенных этапах. При обнаружении несоответствия планам проекта предпринимаются корректирующие действия. Эти действия могут включать в себя пересмотр плана разработки ПО с целью отражения в нем фактических результатов и перепланирования оставшейся работы либо принятие мер по повышению производительности.
Цели
Цель 1 Сравнение фактических результатов и показателей с запланированными.
Цель 2 В случае значительного отклонения фактических результатов и показателей от запланированных — применение корректирующих действий и контроль над их выполнением.
Цель 3 Согласование изменений производственных обязательств с задействованными группами и сотрудниками.
Цель 2 В случае значительного отклонения фактических результатов и показателей от запланированных — применение корректирующих действий и контроль над их выполнением.
Цель 3 Согласование изменений производственных обязательств с задействованными группами и сотрудниками.
Обязательства по выполнению
Обязательство 1 Должен быть назначен производственный менеджер проекта, ответственный за работы по проекту и их результаты. Обязательство 2 Проект следует документированной организационной политике управления проектом разработки ПО.
Эта политика обычно состоит из следующих положений:
1. Отслеживание хода проекта должно выполняться на основе документированного плана разработки ПО.
2. Менеджер проекта должен постоянно информироваться о состоянии проекта разработки и возникающих проблемах.
3. В случае отклонений от плана должны предприниматься корректирующие действия, направленные либо на повышение производительности, либо на коррекцию планов.
4. Изменения производственных обязательств вносятся при участии задействованных групп и согласуются с ними.
Примеры задействованных групп:
группа разработки ПО (включая все подгруппы, например, проектирования ПО, оценки составляющих проекта, системного проектирования),
системного тестирования,
обеспечения качества ПО,
управления конфигурацией ПО,
управления контрактами,
управления документацией.
5. Высшее руководство рассматривает все изменения обязательств и новые обязательства по проекту, которые принимаются группами и отдельными лицами, не входящими в организацию.
Эта политика обычно состоит из следующих положений:
1. Отслеживание хода проекта должно выполняться на основе документированного плана разработки ПО.
2. Менеджер проекта должен постоянно информироваться о состоянии проекта разработки и возникающих проблемах.
3. В случае отклонений от плана должны предприниматься корректирующие действия, направленные либо на повышение производительности, либо на коррекцию планов.
4. Изменения производственных обязательств вносятся при участии задействованных групп и согласуются с ними.
Примеры задействованных групп:
группа разработки ПО (включая все подгруппы, например, проектирования ПО, оценки составляющих проекта, системного проектирования),
системного тестирования,
обеспечения качества ПО,
управления конфигурацией ПО,
управления контрактами,
управления документацией.
5. Высшее руководство рассматривает все изменения обязательств и новые обязательства по проекту, которые принимаются группами и отдельными лицами, не входящими в организацию.
Необходимые предпосылки
Предпосылка 1 План разработки ПО должен быть документирован и утвержден.
Практики, связанные с планом разработки ПО, содержатся в описании Операций № 6 и № 7 группы ключевых процессов «Планирование проекта».
Предпосылка 2 Менеджер проекта назначает конкретных сотрудников, ответственных за промежуточные программные продукты и производственные операции.
Распределяемые сферы ответственности охватывают следующие аспекты:
1. Разрабатываемые промежуточные программные продукты или предоставляемые услуги.
2. Объемы работ и затрат, необходимые для выполнения производственных операций.
3. График выполнения производственных операций.
4. Бюджет производственных операций.
Предпосылка 3 Процесс отслеживания хода проекта должен быть обеспечен соответствующими ресурсами и финансированием.
1. На производственных менеджеров и ведущих специалистов возлагаются конкретные обязанности по отслеживанию хода проекта.
2. Отслеживание хода проекта обеспечивается вспомогательными инструментальными средствами.
Примеры вспомогательных инструментальных средств:
электронные таблицы,
программы производственного и календарного планирования проекта.
Предпосылка 4 Производственные менеджеры должны пройти обучение управлению техническими и кадровыми аспектами проекта разработки.
Примеры тем учебных занятий: управление техническими аспектами проектов; отслеживание и контроль объема, трудоемкости, затрат и графика разработки; управление персоналом.
Предпосылка 5 Линейные менеджеры должны получить ориентацию в технических аспектах проекта разработки.
Примеры ориентирования:
инженерные стандарты и процедуры проекта разработки;
предметная область проекта.
Практики, связанные с планом разработки ПО, содержатся в описании Операций № 6 и № 7 группы ключевых процессов «Планирование проекта».
Предпосылка 2 Менеджер проекта назначает конкретных сотрудников, ответственных за промежуточные программные продукты и производственные операции.
Распределяемые сферы ответственности охватывают следующие аспекты:
1. Разрабатываемые промежуточные программные продукты или предоставляемые услуги.
2. Объемы работ и затрат, необходимые для выполнения производственных операций.
3. График выполнения производственных операций.
4. Бюджет производственных операций.
Предпосылка 3 Процесс отслеживания хода проекта должен быть обеспечен соответствующими ресурсами и финансированием.
1. На производственных менеджеров и ведущих специалистов возлагаются конкретные обязанности по отслеживанию хода проекта.
2. Отслеживание хода проекта обеспечивается вспомогательными инструментальными средствами.
Примеры вспомогательных инструментальных средств:
электронные таблицы,
программы производственного и календарного планирования проекта.
Предпосылка 4 Производственные менеджеры должны пройти обучение управлению техническими и кадровыми аспектами проекта разработки.
Примеры тем учебных занятий: управление техническими аспектами проектов; отслеживание и контроль объема, трудоемкости, затрат и графика разработки; управление персоналом.
Предпосылка 5 Линейные менеджеры должны получить ориентацию в технических аспектах проекта разработки.
Примеры ориентирования:
инженерные стандарты и процедуры проекта разработки;
предметная область проекта.
Выполняемые операции
Операция 1 Отслеживание выполнения производственных операций и передача информации о состоянии проекта производится на основе документированного плана разработки ПО.
Практики, связанные с содержанием плана разработки ПО, содержатся в описании Операции № 7 группы ключевых процессов «Планирование проекта».
К плану разработки ПО выдвигаются следующие требования:
1. Этот план должен обновляться по ходу проекта, отражая его результаты и, в частности, завершение этапов.
2. К плану разработки ПО получают постоянный доступ:
группа разработки ПО (включая все подгруппы, например, проектирования ПО),
производственные менеджеры,
менеджер проекта,
высшее руководство,
другие задействованные группы.
Операция 2 Пересмотр плана разработки ПО в соответствии с документированной процедурой.
Практики, связанные с созданием плана разработки ПО, содержатся в описании Операции № 6 группы ключевых процессов «Планирование проекта».
Эта процедура обычно определяет следующее:
1. Пересмотр плана разработки ПО выполняется при необходимости включения в него уточнений и изменений, в частности при значительных изменениях планов. Во всех изменениях плана должны быть отражены внутренние зависимости между установленными системными требованиями, проектными ограничениями, ресурсами, затратами и графиком выполнения проекта.
2. Обновление плана разработки ПО выполняется с целью учета в нем всех новых обязательств по проекту и изменений прежних обязательств.
3. План разработки ПО должен проходить проверку после каждого исправления.
4. Документ плана разработки ПО должен быть управляемым и контролируемым. «Управляемый и контролируемый» означает, что в любой момент времени (прошлый или настоящий) известна версия используемого промежуточного продукта (т. е. реализован контроль версий), а внесение изменений происходит управляемым образом (т. е. реализовано управление изменениями).
Если желательно реализовать еще большую степень контроля, промежуточный продукт может быть помещен в условия полномасштабного управления конфигурацией, как это описано в группе ключевых процессов «Управление конфигурацией ПО».
Операция 3 Обязательства по проекту и их изменения, принятые группами и отдельными лицами, не входящими в состав организации, рассматриваются высшим руководством в соответствии с документированной процедурой.
Операция 4 Информация об утвержденных изменениях обязательств, влияющих на проект, распространяется между разработчиками и группами, связанными с разработкой ПО.
Примеры групп, связанных с разработкой ПО:
группа обеспечения качества ПО,
управления конфигурацией ПО,
управления документацией.
Операция 5 Отслеживание объема промежуточных программных продуктов (или объема их изменений) и применение корректирующих действий в случае необходимости.
Практики, связанные с оценочным расчетом объема, содержатся в описании Операции № 9 группы ключевых процессов «Планирование проекта».
1. Отслеживается объем всех основных промежуточных программных продуктов (или объем их изменений).
2. Фактический объем кода (сгенерированного, полностью протестированного и переданного заказчику) сравнивается с оценками, содержащимися в плане разработки ПО.
3. Фактический объем переданной заказчику документации сравнивается с оценками, содержащимися в плане разработки ПО.
4. Регулярно производится уточнение, отслеживание и корректировка общего планируемого объема промежуточных программных продуктов (оценочный расчет с учетом фактических значений).
5. Изменения оценок объема промежуточных программных продуктов, влияющие на производственные обязательства, обсуждаются с задействованными группами и документируются.
Операция 6 Отслеживание объема работ и затрат по проекту, при необходимости — применение корректирующих действий.
Практики, связанные с оценочным расчетом затрат, содержатся в описании Операции № 10 группы ключевых процессов «Планирование проекта».
1. Фактические показатели трудозатрат и финансовых расходов сравниваются с оценками, содержащимися в плане разработки ПО, в целях выявления перерасхода или неполного использования ресурсов.
2. Себестоимость разработки отслеживается и сравнивается с оценками, содержащимися в плане разработки ПО.
3. Трудозатраты и укомплектование персоналом сравниваются с оценками, содержащимися в плане разработки ПО.
4. Изменения в штате сотрудников и в других производственных расходах, влияющие на производственные обязательства, обсуждаются с участием задействованных групп и документируются.
Операция 7 Отслеживание использования критических компьютерных ресурсов в проекте, при необходимости — применение корректирующих действий.
Практики, связанные с оценочным расчетом использования компьютерных ресурсов, содержатся в описании Операции № 11 группы ключевых процессов «Планирование проекта».
1. Фактические и планируемые показатели использования критических компьютерных ресурсов отслеживаются и сравниваются с оценками для всех основных компонентов ПО в соответствии с планом разработки.
2. Изменения оценок использования критических компьютерных ресурсов, влияющие на производственные обязательства, обсуждаются с участием задействованных групп и документируются.
Операция 8 Отслеживание календарного графика проектных работ, при необходимости — применение корректирующих действий.
Практики, связанные с составлением календарного графика, содержатся в описании Операции № 12 группы ключевых процессов «Планирование проекта».
1. Степень фактического выполнения проектных работ, этапов и других обязательств сравнивается с планом разработки ПО.
2. Оценивается влияние позднего и досрочного завершения проектных работ, этапов и других обязательств на будущие работы и этапы.
3. Изменения календарного графика разработки, влияющие на производственные обязательства, обсуждаются с участием задействованных групп и документируются.
Операция 9 Отслеживание технических операций по проекту разработки, при необходимости — применение корректирующих действий.
1. Разработчики регулярно докладывают своему линейному менеджеру о техническом состоянии разработки.
2. Содержимое успешных сборок продукта сравнивается с планом разработки ПО.
3. Отчет о проблемах, выявленных в промежуточных программных продуктах, документируется и направляется по назначению. 4. Отчеты о проблемах отслеживаются до разрешения вопросов.
Операция 10 Отслеживание рисков разработки, связанных с затратами, ресурсами, графиком и техническими аспектами проекта.
Практики, связанные с выявлением рисков, содержатся в описании Операции № 13 группы ключевых процессов «Планирование проекта».
1. Приоритеты и действия по снижению рисков уточняются по мере поступления дополнительной информации.
2. Менеджер проекта регулярно проверяет области с высокой степенью риска.
Операция 11 Документирование фактических данных измерений и данных по изменению плана проекта.
Практики, связанные с документированием данных по проекту, содержатся в описании Операции № 15 группы ключевых процессов «Планирование проекта».
1. Записи включают в себя оценочные данные и дополнительные сведения, необходимые для воспроизведения оценочных расчетов и проверки их обоснованности.
2. Данные по изменениям в плане проекта разработки должны быть управляемыми и контролируемыми.
3. Данные по планированию и изменениям в плане проекта разработки, а также фактические данные измерений архивируются в целях их использования в текущем и будущих проектах.
Операция 12 Группа разработки ПО регулярно проводит внутренние проверки в целях отслеживания хода технических работ, планов, производительности и проблем и их сравнения с планом разработки ПО.
В этих проверках принимают участие:
1. Линейные менеджеры и подчиненные им ведущие специалисты.
2. Производственный менеджер проекта, линейные и другие производственные менеджеры по мере необходимости.
Операция 13 Проведение на определенных этапах проекта формальных проверок достигнутых результатов в соответствии с документированной процедурой.
1. Проведение этих проверок планируется на какие-либо значимые моменты календарного графика проекта, такие как начало или завершение определенных стадий разработки.
2. Проверки проводятся при участии заказчика, конечных пользователей и задействованных групп организации по мере необходимости.
В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.
3. В проверках используются материалы, рассмотренные и утвержденные производственными менеджерами с соответствующей сферой ответственности.
4. В проверках рассматриваются производственные обязательства, планы и состояние работ по проекту.
5. Результатом этих проверок является выявление существенных проблем, определение действий и решений, а также их документирование.
6. В ходе проверок изучаются риски проекта разработки.
7. В случае необходимости, по результатам проверок уточняется план разработки ПО.
Практики, связанные с содержанием плана разработки ПО, содержатся в описании Операции № 7 группы ключевых процессов «Планирование проекта».
К плану разработки ПО выдвигаются следующие требования:
1. Этот план должен обновляться по ходу проекта, отражая его результаты и, в частности, завершение этапов.
2. К плану разработки ПО получают постоянный доступ:
группа разработки ПО (включая все подгруппы, например, проектирования ПО),
производственные менеджеры,
менеджер проекта,
высшее руководство,
другие задействованные группы.
Операция 2 Пересмотр плана разработки ПО в соответствии с документированной процедурой.
Практики, связанные с созданием плана разработки ПО, содержатся в описании Операции № 6 группы ключевых процессов «Планирование проекта».
Эта процедура обычно определяет следующее:
1. Пересмотр плана разработки ПО выполняется при необходимости включения в него уточнений и изменений, в частности при значительных изменениях планов. Во всех изменениях плана должны быть отражены внутренние зависимости между установленными системными требованиями, проектными ограничениями, ресурсами, затратами и графиком выполнения проекта.
2. Обновление плана разработки ПО выполняется с целью учета в нем всех новых обязательств по проекту и изменений прежних обязательств.
3. План разработки ПО должен проходить проверку после каждого исправления.
4. Документ плана разработки ПО должен быть управляемым и контролируемым. «Управляемый и контролируемый» означает, что в любой момент времени (прошлый или настоящий) известна версия используемого промежуточного продукта (т. е. реализован контроль версий), а внесение изменений происходит управляемым образом (т. е. реализовано управление изменениями).
Если желательно реализовать еще большую степень контроля, промежуточный продукт может быть помещен в условия полномасштабного управления конфигурацией, как это описано в группе ключевых процессов «Управление конфигурацией ПО».
Операция 3 Обязательства по проекту и их изменения, принятые группами и отдельными лицами, не входящими в состав организации, рассматриваются высшим руководством в соответствии с документированной процедурой.
Операция 4 Информация об утвержденных изменениях обязательств, влияющих на проект, распространяется между разработчиками и группами, связанными с разработкой ПО.
Примеры групп, связанных с разработкой ПО:
группа обеспечения качества ПО,
управления конфигурацией ПО,
управления документацией.
Операция 5 Отслеживание объема промежуточных программных продуктов (или объема их изменений) и применение корректирующих действий в случае необходимости.
Практики, связанные с оценочным расчетом объема, содержатся в описании Операции № 9 группы ключевых процессов «Планирование проекта».
1. Отслеживается объем всех основных промежуточных программных продуктов (или объем их изменений).
2. Фактический объем кода (сгенерированного, полностью протестированного и переданного заказчику) сравнивается с оценками, содержащимися в плане разработки ПО.
3. Фактический объем переданной заказчику документации сравнивается с оценками, содержащимися в плане разработки ПО.
4. Регулярно производится уточнение, отслеживание и корректировка общего планируемого объема промежуточных программных продуктов (оценочный расчет с учетом фактических значений).
5. Изменения оценок объема промежуточных программных продуктов, влияющие на производственные обязательства, обсуждаются с задействованными группами и документируются.
Операция 6 Отслеживание объема работ и затрат по проекту, при необходимости — применение корректирующих действий.
Практики, связанные с оценочным расчетом затрат, содержатся в описании Операции № 10 группы ключевых процессов «Планирование проекта».
1. Фактические показатели трудозатрат и финансовых расходов сравниваются с оценками, содержащимися в плане разработки ПО, в целях выявления перерасхода или неполного использования ресурсов.
2. Себестоимость разработки отслеживается и сравнивается с оценками, содержащимися в плане разработки ПО.
3. Трудозатраты и укомплектование персоналом сравниваются с оценками, содержащимися в плане разработки ПО.
4. Изменения в штате сотрудников и в других производственных расходах, влияющие на производственные обязательства, обсуждаются с участием задействованных групп и документируются.
Операция 7 Отслеживание использования критических компьютерных ресурсов в проекте, при необходимости — применение корректирующих действий.
Практики, связанные с оценочным расчетом использования компьютерных ресурсов, содержатся в описании Операции № 11 группы ключевых процессов «Планирование проекта».
1. Фактические и планируемые показатели использования критических компьютерных ресурсов отслеживаются и сравниваются с оценками для всех основных компонентов ПО в соответствии с планом разработки.
2. Изменения оценок использования критических компьютерных ресурсов, влияющие на производственные обязательства, обсуждаются с участием задействованных групп и документируются.
Операция 8 Отслеживание календарного графика проектных работ, при необходимости — применение корректирующих действий.
Практики, связанные с составлением календарного графика, содержатся в описании Операции № 12 группы ключевых процессов «Планирование проекта».
1. Степень фактического выполнения проектных работ, этапов и других обязательств сравнивается с планом разработки ПО.
2. Оценивается влияние позднего и досрочного завершения проектных работ, этапов и других обязательств на будущие работы и этапы.
3. Изменения календарного графика разработки, влияющие на производственные обязательства, обсуждаются с участием задействованных групп и документируются.
Операция 9 Отслеживание технических операций по проекту разработки, при необходимости — применение корректирующих действий.
1. Разработчики регулярно докладывают своему линейному менеджеру о техническом состоянии разработки.
2. Содержимое успешных сборок продукта сравнивается с планом разработки ПО.
3. Отчет о проблемах, выявленных в промежуточных программных продуктах, документируется и направляется по назначению. 4. Отчеты о проблемах отслеживаются до разрешения вопросов.
Операция 10 Отслеживание рисков разработки, связанных с затратами, ресурсами, графиком и техническими аспектами проекта.
Практики, связанные с выявлением рисков, содержатся в описании Операции № 13 группы ключевых процессов «Планирование проекта».
1. Приоритеты и действия по снижению рисков уточняются по мере поступления дополнительной информации.
2. Менеджер проекта регулярно проверяет области с высокой степенью риска.
Операция 11 Документирование фактических данных измерений и данных по изменению плана проекта.
Практики, связанные с документированием данных по проекту, содержатся в описании Операции № 15 группы ключевых процессов «Планирование проекта».
1. Записи включают в себя оценочные данные и дополнительные сведения, необходимые для воспроизведения оценочных расчетов и проверки их обоснованности.
2. Данные по изменениям в плане проекта разработки должны быть управляемыми и контролируемыми.
3. Данные по планированию и изменениям в плане проекта разработки, а также фактические данные измерений архивируются в целях их использования в текущем и будущих проектах.
Операция 12 Группа разработки ПО регулярно проводит внутренние проверки в целях отслеживания хода технических работ, планов, производительности и проблем и их сравнения с планом разработки ПО.
В этих проверках принимают участие:
1. Линейные менеджеры и подчиненные им ведущие специалисты.
2. Производственный менеджер проекта, линейные и другие производственные менеджеры по мере необходимости.
Операция 13 Проведение на определенных этапах проекта формальных проверок достигнутых результатов в соответствии с документированной процедурой.
1. Проведение этих проверок планируется на какие-либо значимые моменты календарного графика проекта, такие как начало или завершение определенных стадий разработки.
2. Проверки проводятся при участии заказчика, конечных пользователей и задействованных групп организации по мере необходимости.
В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.
3. В проверках используются материалы, рассмотренные и утвержденные производственными менеджерами с соответствующей сферой ответственности.
4. В проверках рассматриваются производственные обязательства, планы и состояние работ по проекту.
5. Результатом этих проверок является выявление существенных проблем, определение действий и решений, а также их документирование.
6. В ходе проверок изучаются риски проекта разработки.
7. В случае необходимости, по результатам проверок уточняется план разработки ПО.
Измерения и анализ
Измерение 1 Выполнение измерений и использование их результатов для определения состояния работ по отслеживанию хода проекта и контролю над ним.
Примеры измерений: определение объема трудозатрат и других ресурсов, вложенных в выполнение работ по отслеживанию хода проекта и контролю над ним; определение статуса изменений плана разработки
ПО, включающих в себя изменения следующих оценок — объема промежуточных программных продуктов, затрат на разработку, критических компьютерных ресурсов и показателей календарного графика.
Примеры измерений: определение объема трудозатрат и других ресурсов, вложенных в выполнение работ по отслеживанию хода проекта и контролю над ним; определение статуса изменений плана разработки
ПО, включающих в себя изменения следующих оценок — объема промежуточных программных продуктов, затрат на разработку, критических компьютерных ресурсов и показателей календарного графика.
Проверка внедрения
Проверка 1 Регулярная проверка высшим руководством выполнения работ по отслеживанию хода проекта и контролю над ним.
Регулярные проверки проводятся высшим руководством для получения своевременной информации о производственном процессе и его понимания на соответствующем уровне абстракции. Промежутки времени между проверками должны соответствовать потребностям организации и могут быть длительными, если в организации имеется работающая система оповещения об исключительных ситуациях.
1. Проверка технических, финансовых, кадровых аспектов и выполнения графика.
2. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
3. Изучение рисков проекта разработки.
4. Поручение и проверка действий, а также отслеживание их выполнения.
5. Подготовка итогового отчета по результатам каждой проверки и его распространение среди задействованных групп.
Проверка 2 Регулярные и событийные проверки менеджером проекта работ по отслеживанию хода проекта и контролю над ним.
1. В проверках принимают участие представители задействованных групп.
2. Технические, финансовые, кадровые аспекты и показатели календарного графика сравниваются с планом разработки ПО.
3. Проверка использования критических компьютерных ресурсов. В отчет включается сравнение текущих оценок и фактического использования этих ресурсов с начальными оценками.
4. Обсуждение зависимостей между группами.
5. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
6. Изучение рисков проекта разработки.
7. Поручение и проверка задач, а также отслеживание их выполнения.
8. Подготовка итогового отчета по результатам каждой проверки и его распространение среди задействованных групп.
Проверка 3 Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов, связанных с отслеживанием хода проекта и контролем над ним, а также выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО».
Минимальное содержание проверок и/или аудитов:
1. Мероприятия по пересмотру и изменению обязательств.
2. Мероприятия по изменению плана разработки ПО.
3. Содержание измененного плана разработки ПО.
4. Мероприятия по отслеживанию затрат по проекту, календарного графика, технических и архитектурных ограничений, функциональных возможностей и производительности.
5. Мероприятия по проведению плановых технических и административных проверок.
Регулярные проверки проводятся высшим руководством для получения своевременной информации о производственном процессе и его понимания на соответствующем уровне абстракции. Промежутки времени между проверками должны соответствовать потребностям организации и могут быть длительными, если в организации имеется работающая система оповещения об исключительных ситуациях.
1. Проверка технических, финансовых, кадровых аспектов и выполнения графика.
2. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
3. Изучение рисков проекта разработки.
4. Поручение и проверка действий, а также отслеживание их выполнения.
5. Подготовка итогового отчета по результатам каждой проверки и его распространение среди задействованных групп.
Проверка 2 Регулярные и событийные проверки менеджером проекта работ по отслеживанию хода проекта и контролю над ним.
1. В проверках принимают участие представители задействованных групп.
2. Технические, финансовые, кадровые аспекты и показатели календарного графика сравниваются с планом разработки ПО.
3. Проверка использования критических компьютерных ресурсов. В отчет включается сравнение текущих оценок и фактического использования этих ресурсов с начальными оценками.
4. Обсуждение зависимостей между группами.
5. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.
6. Изучение рисков проекта разработки.
7. Поручение и проверка задач, а также отслеживание их выполнения.
8. Подготовка итогового отчета по результатам каждой проверки и его распространение среди задействованных групп.
Проверка 3 Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов, связанных с отслеживанием хода проекта и контролем над ним, а также выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО».
Минимальное содержание проверок и/или аудитов:
1. Мероприятия по пересмотру и изменению обязательств.
2. Мероприятия по изменению плана разработки ПО.
3. Содержание измененного плана разработки ПО.
4. Мероприятия по отслеживанию затрат по проекту, календарного графика, технических и архитектурных ограничений, функциональных возможностей и производительности.
5. Мероприятия по проведению плановых технических и административных проверок.
8.4. Управление производственным субподрядом
Группа ключевых процессов для уровня 2: повторяемый уровень.
Цель группы ключевых процессов «Управление производственным субподрядом» заключается в выборе квалифицированных производственных субподрядчиков и эффективном управлении ими.
Управление производственным субподрядом включает в себя выбор субподрядчика, принятие взаимных обязательств с ним, отслеживание и проверку производительности и результатов его работы. Эти практики охватывают управление как субподрядом, связанным с разработкой исключительно программного продукта, так и управление программной частью субподряда, который включает в себя ПО, аппаратное обеспечение и, возможно, другие системные компоненты.
Выбор субподрядчика основывается на его способности выполнить определенную работу. Решение о передаче на субподряд части работы генерального подрядчика принимается под влиянием многих факторов. Субподрядчики могут выбираться на основании стратегических деловых альянсов, а также по техническим соображениям. В практиках данной группы ключевых процессов рассматривается традиционное обеспечение поставок, связанное с заключением субподряда с другой организацией на определенную часть работы.
При передаче работ на субподряд заключается документированное соглашение (договор) по техническим и нетехническим (например, датам поставки) требованиям, которое используется в качестве основы для управления субподрядом. Поручаемая субподрядчику работа и рабочие планы документируются. Стандарты, которым будет следовать субподрядчик, должны быть совместимы со стандартами генерального подрядчика.
Связанные с субподрядом работы по планированию разработки, отслеживанию хода проекта и контролю над ним выполняются субподрядчиком. Генеральный подрядчик должен гарантировать выполнение этих работ на должном уровне, а поставленные субподрядчиком программные продукты будут удовлетворять своим критериям приемки. Генеральный подрядчик и субподрядчик должны совместно решать вопросы по управлению разрабатываемыми продуктами и интерфейсами процессов.
Цель группы ключевых процессов «Управление производственным субподрядом» заключается в выборе квалифицированных производственных субподрядчиков и эффективном управлении ими.
Управление производственным субподрядом включает в себя выбор субподрядчика, принятие взаимных обязательств с ним, отслеживание и проверку производительности и результатов его работы. Эти практики охватывают управление как субподрядом, связанным с разработкой исключительно программного продукта, так и управление программной частью субподряда, который включает в себя ПО, аппаратное обеспечение и, возможно, другие системные компоненты.
Выбор субподрядчика основывается на его способности выполнить определенную работу. Решение о передаче на субподряд части работы генерального подрядчика принимается под влиянием многих факторов. Субподрядчики могут выбираться на основании стратегических деловых альянсов, а также по техническим соображениям. В практиках данной группы ключевых процессов рассматривается традиционное обеспечение поставок, связанное с заключением субподряда с другой организацией на определенную часть работы.
При передаче работ на субподряд заключается документированное соглашение (договор) по техническим и нетехническим (например, датам поставки) требованиям, которое используется в качестве основы для управления субподрядом. Поручаемая субподрядчику работа и рабочие планы документируются. Стандарты, которым будет следовать субподрядчик, должны быть совместимы со стандартами генерального подрядчика.
Связанные с субподрядом работы по планированию разработки, отслеживанию хода проекта и контролю над ним выполняются субподрядчиком. Генеральный подрядчик должен гарантировать выполнение этих работ на должном уровне, а поставленные субподрядчиком программные продукты будут удовлетворять своим критериям приемки. Генеральный подрядчик и субподрядчик должны совместно решать вопросы по управлению разрабатываемыми продуктами и интерфейсами процессов.
Цели
Цель 1 Выбор генеральным подрядчиком квалифицированных субподрядчиков.
Цель 2 Заключение соглашения о взаимных обязательствах между генеральным подрядчиком и субподрядчиком.
Цель 2 Заключение соглашения о взаимных обязательствах между генеральным подрядчиком и субподрядчиком.