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