ГОСТ Р 57101-2016 Системная и программная инженерия. Процессы жизненного цикла. Управление проектом

ГОСТ Р 57101-2016/ISO/IEC/IEEE 16326:2009

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системная и программная инженерия

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА

Управление проектом

Systems and software engineering. Life cycle processes. Project management

ОКС 35.080

Дата введения 2017-09-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 сентября 2016 г. N 1191-ст

4 Настоящий стандарт идентичен международному стандарту ISO/IEC/IEEE 16326:2009* "Системная и программная инженерия. Процессы жизненного цикла. Управление проектом" (ISO/IEC/IEEE 16326:2009 "Systems and software engineering - Life cycle processes - Project management", IDT)

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. Международная организация по стандартизации (ИСО) и Институт инженеров по электротехнике и радиоэлектронике (ИИЭР) не несут ответственности за идентификацию подобных патентных прав

7 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

ISO/IEC/IEEE 16326 был подготовлен подкомитетом 7 "Системная и программная инженерия" Совместного технического комитета ИСО/МЭК СТК 1 "Информационные технологии" в сотрудничестве с Комитетом по стандартам системной и программной инженерии Компьютерного общества IEEE в соответствии с соглашением о партнерском сотрудничестве между ИСО и ИИЭР.

Этот выпуск ISO/IEC/IEEE 16326 отменяет и заменяет предыдущий технический отчет ISO/IEC TR 16326:1999, который был пересмотрен и согласован с содержанием IEEE 1058:1998.

Настоящий стандарт содержит нормативные требования для планов управления проектом, охватывающих проекты программных средств и систем. Настоящий стандарт также содержит детальные положения и рекомендации относительно применения ряда процессов проекта, которые свойственны жизненным циклам программных средств и систем согласно ИСО/МЭК 12207:2008 (IEEE 12207:2008) "Системная и программная инженерия. Процессы жизненного цикла программных средств" [15] и ИСО/МЭК 15288:2008 (IEEE 15288:2008) "Системная и программная инженерия. Процессы жизненного цикла систем" [16]. Положения и рекомендации предназначены для помощи в подготовке нормативного содержания планов управления проектом.

_______________

Заменен на ISO/IEC TR 15288:2015.

Настоящий стандарт - это результат гармонизации технического отчета ISO/IEC TR 16326:1999 и IEEE 1058:1998.

1 Область применения

1.1 Цель

Настоящий стандарт предназначен для помощи руководителям проектов в управлении для успешного ведения проектов, касающихся программных средств и систем. Настоящий стандарт определяет необходимое содержание плана управления проектом (ПУПРП). Этот стандарт также формулирует цели и содержание результатов процессов проекта согласно ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008) и добавляет детальные положения для управления проектами, в которых используются эти процессы.

1.2 Область распространения

Настоящий стандарт предназначен для тех, кто использует или планирует использовать ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008) в проектах, имеющих дело с программными средствами и системами независимо от области применения проекта, продукции, методологии, масштаба или сложности. Область применения настоящего стандарта охватывает полные жизненные циклы программных средств или систем, и стандарт предназначен для всех, кто играет роль в управлении проектом, особенно:

- ответственных за установление и непрерывное улучшение процессов жизненного цикла программных средств по ИСО/МЭК 12207:2008 (IEEE 12207:2008) и процессов жизненного цикла систем по ИСО/МЭК 15288:2008 (IEEE 15288:2008);

- ответственных за выполнение любого процесса жизненного цикла программных средств по ИСО/МЭК 12207:2008 (IEEE 12207:2008) или любого процесса жизненного цикла системы по ИСО/МЭК 15288:2008 (IEEE 15288:2008), выполняемого на проектном уровне;

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

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

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

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

1.3 Ограничения

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

2 Соответствие

Настоящий стандарт обеспечивает нормативное определение содержания плана управления проектом (ПУПРП) и дает представление о выполнении процессов проекта по ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008). Пользователи настоящего стандарта могут потребовать соответствия содержанию нормативной документации или условиям процессов, или полного соответствия (т.е. и тому, и другому).

2.1 Соответствие содержанию нормативной документации

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

2.2 Соответствие процессам

Требование соответствия условиям процессов настоящего стандарта эквивалентно требованию соответствия процессам проекта по ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008), изложенным в разделе 6 настоящего стандарта.

2.3 Полное соответствие

Требование полного соответствия настоящему стандарту эквивалентно требованию соответствия содержательным требованиям ПУПРП, процитированным в разделе 5, и процессам проекта по ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008) согласно разделу 6 настоящего стандарта.

3 Обозначения и сокращения

В настоящем стандарте используются следующие обозначения и сокращения:

4 Приложения настоящего стандарта

Настоящий стандарт определяет необходимое содержание ПУПРП так, чтобы, будучи выполненным успешно, достигались цели и желаемые результаты, задаваемые в процессах проекта по ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008).

Процессы проекта по ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008) содержат стандартные действия и задачи для использования любой стороной, которая должна выполнить проект, имеющий дело с программными продуктами или системами. Настоящий стандарт предоставляет дополнительное детальное руководство (см. раздел 5) для того, чтобы помочь руководителям этих проектов при разработке ПУПРП для какого-либо специального проекта.

ANSI/PMI 99-001:2004 [1] предоставляет важную информацию об управлении проектами, а ИСО 10006:2003 [2] дает представление о применении управления качеством в проектах. Руководители проектов, имеющие дело с программными продуктами или системами, могут найти полезным для управления успешного завершения проектов содержание руководства РМВОК® [1] и ИСО 10006:2003 [2] наряду с руководством, представленным в настоящем стандарте.

_______________

РМВОК® - зарегистрированная торговая марка Института управления проектами. Эта информация дана для удобства пользованием этим стандартом и не сопровождает ИСО/МЭК или ИИЭР этой продукцией. Могут использоваться подобные продукты, если они, как можно видеть, приводят к тем же результатам.

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

5 Элементы плана управления проектом

Этот раздел определяет каждый из элементов ПУПРП, как показано на рисунке 1.

Рисунок 1 - Структура и содержание плана управления проектом

Рисунок 1, лист 2

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

Детальные описания каждого раздела и подраздела представлены в разделах 6 и 8 ПУПРП. Дополнительные планы часто обязаны удовлетворять требованиям к продукции и договорным срокам. Дополнительные планы определены в разделе 9 ПУПРП (см. рисунок 1).

Руководителям проектов следует разрабатывать содержание планов, определенных ниже, таким образом, чтобы они достигали целей и желательных результатов по ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008), процитированных в разделе 5 настоящего стандарта. Если необходимо применять и использовать программные продукты и услуги в более общем контексте систем, в которых они существуют, руководителям проектов, разрабатывая эти планы, если это возможно, следует стремиться согласовывать желаемые проектные результаты с выходными результатами, определенными в ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008).

ПУПРП непрерывно обновляется в течение жизни проекта. История регистрации изменений сопровождает изменения ПУПРП-документа.

Каждая версия ПУПРП, основанного на настоящем стандарте, должна содержать вступительную часть, которая включает:

- титульный лист, который должен содержать название проекта, дату выпуска, уникальный идентификатор (номер проекта, номер версии базовой линии) и идентификацию издающей организации;

- страницу для подписей, которая должна содержать подписи лиц, ответственных за рассмотрение, согласование и утверждение ПУПРП;

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

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

- оглавление;

- перечень рисунков, которые содержатся в ПУПРП;

- перечень таблиц, которые содержатся в ПУПРП.

5.1 Обзор проекта (раздел 1 ПУПРП)

5.1.1 Краткое описание проекта (подраздел 1.1 ПУПРП)

5.1.1.1 Замысел, область применения и цели (пункт 1.1.1 ПУПРП)

Этот пункт ПУПРП должен формулировать замысел, область применения и цели проекта и продукции. Утверждение области применения должно быть совместимым с подобными положениями в проектном соглашении и другими соответствующими документами уровня системы или бизнес-уровня.

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

В этом пункте ПУПРП должна быть предоставлена ссылка на официально утвержденные требования к продукции.

5.1.1.2 Предположения и ограничения (пункт 1.1.2 ПУПРП)

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

5.1.1.3 Поставки проекта (пункт 1.1.3 ПУПРП)

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

5.1.1.4 Краткое описание графиков и бюджета (пункт 1.1.4 ПУПРП)

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

5.1.2 Развитие плана (подраздел 1.2 ПУПРП)

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

5.2 Ссылки (раздел 2 ПУПРП)

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

5.3 Определения (раздел 3 ПУПРП)

Этот раздел ПУПРП должен содержать определения (или ссылки на документы, содержащие определения), все термины и сокращения, требуемые для адекватного понимания ПУПРП.

5.4 Контекст проекта (раздел 4 ПУПРП)

5.4.1 Модель процесса (подраздел 4.1 ПУПРП)

Этот подраздел ПУПРП должен сослаться на процесс управления моделью жизненного цикла или определить отношения между главными рабочими действиями и поддерживающими процессами проекта. Определение отношений осуществляется путем рассмотрения потоков информации и рабочих продуктов между действиями и функциями, графиков производства рабочих продуктов, планируемых анализов, основных выполняемых этапов, базовых линий, поставок проекта и необходимых согласований, которые реализуются в проекте. Кроме того, должны быть указаны технические стандарты, политики и процедуры, обеспечивающие разработку и/или модификацию рабочих продуктов. Модель процесса для проекта должна включать действия по инициированию и завершению проекта. Для описания модели процесса используется комбинация графических и текстовых нотаций. Любое приспосабливание стандартной модели процесса организации для проекта должно быть указано в этом подразделе.

5.4.2 План по улучшению процесса (подраздел 4.2 ПУПРП)

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

5.4.3 План инфраструктуры (подраздел 4.3 ПУПРП)

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

5.4.4 Методы, инструментарии и методики (подраздел 4.4 ПУПРП)

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

5.4.5 План приемки продукции (подраздел 4.5 ПУПРП)

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

5.4.6 Организация проекта (подраздел 4.6 ПУПРП)

Этот подраздел ПУПРП должен определить взаимодействия с организационными объектами (сущностями), внешними к проекту, описать внутреннюю организационную структуру проекта и определить роли и ответственности в проекте.

5.4.6.1 Внешние взаимодействия (пункт 4.6.1 ПУПРП)

Этот пункт ПУПРП должен описать организационные границы между проектом и внешними объектами (сущностями). Сюда следует включать (но не ограничиваясь этим) следующее: головную организацию, приобретающие организации, субподрядчиков и другие организационные объекты (сущности), которые взаимодействуют с проектом.

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

5.4.6.2 Внутренние взаимодействия (пункт 4.6.2 ПУПРП)

Этот пункт ПУПРП должен описать внутреннюю структуру проектной организации, чтобы предусмотреть взаимодействия между единицами команды разработчиков программных средств. Кроме того, в этом пункте должны быть определены организационные взаимодействия между проектными и организационными объектами (сущностями), которые обеспечивают процессы поддержки, такие как управление конфигурацией, обеспечение качества, верификация и валидация. Чтобы изобразить действующие полномочия, ответственности и связь в пределах проекта, следует использовать графические устройства, такие как организационные структуры или диаграммы.

5.4.6.3 Полномочия и ответственности (пункт 4.6.3 ПУПРП)

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

5.5 Планирование проекта (раздел 5 ПУПРП)

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

5.5.1 Инициирование проекта (подраздел 5.1 ПУПРП)

Этот подраздел ПУПРП должен определить детали для оценки области применения проекта, необходимого укомплектования персоналом, план приобретения ресурсов для поддержки штата проекта и план относительно подготовки кадров проекта. В зависимости от масштаба и области применения проекта, эти планы могут существовать как отдельные или могут быть включены в другие планы.

5.5.1.1 План оценки (пункт 5.1.1 ПУПРП)

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

5.5.1.2 План по кадрам (пункт 5.1.2 ПУПРП)

Этот пункт ПУПРП должен определить штатную численность с требуемым уровнем навыка, проектными этапами (фазами), в которых необходимы соответствующий персонал и навыки, а также продолжительность потребности в кадрах. Этот пункт должен определить источники кадров, например с помощью внутренней передачи, нового найма или контракта. Если наряду с проектной командой должен быть принят персонал от других компаний или заказчика, в этом пункте необходимо рассмотреть детали такого оказания услуг. Для изображения планов по кадрам могут использоваться диаграмма Ганта по ресурсам и гистограммы ресурсов, крупноформатные и иные таблицы, показывающие представления уровней навыков, проектных этапов (фаз) и распределений по проекту уровней навыков и проектных этапов (фаз).

5.5.1.3 План приобретения ресурсов (пункт 5.1.3 ПУПРП)

Этот пункт ПУПРП в дополнение к кадрам должен определить план приобретения и высвобождения ресурсов для успешного завершения проекта. План приобретения ресурсов должен состоять из описания процесса приобретения и высвобождения ресурсов, включая назначение ответственности за все аспекты приобретения ресурсов. В план следует включать (но не ограничиваться этим) планы по приобретению и высвобождению оборудования, компьютерных аппаратных и программных средств, обучению, контрактам по обслуживанию, транспортировке, основным средствам, административным и вспомогательным услугам. В плане следует определить время на проектных графиках, когда будут востребованы различные действия по приобретению и высвобождению ресурсов. Должны быть определены ограничения на приобретение необходимых ресурсов (при наличии таковых). Этот пункт может быть расширен дополнительными подпунктами вида 5.1.3 для приспособления планов приобретения относительно различных типов приобретаемых ресурсов.

5.5.1.4 План обучения персонала проекта (пункт 5.1.4 ПУПРП)

Этот пункт ПУПРП должен определить обучение, необходимое для гарантии того, что персонал обладает навыками в объеме, достаточном для успешного осуществления проекта. График обучения должен включать типы востребованного обучения, количество персонала для обучения, входные и выходные критерии для обучения и методы обучения, например лекции, консультации, наставничество или компьютерное обучение. Как необходимое, в учебный план следует включать обучение и техническим, и организаторским навыкам. Если в состав проектной команды должны быть приняты специалисты из других компаний или заказчика, этот пункт должен определять предусмотренное для них обучение.

5.5.2 Рабочие планы проекта (подраздел 5.2 ПУПРП)

Этот подраздел ПУПРП должен определить рабочие действия, графики выполнения, ресурсы, бюджет и детали снабжения по проекту.

5.5.2.1 Рабочие действия (пункт 5.2.1 ПУПРП)

Этот пункт ПУПРП должен определить различные рабочие действия, которые будут выполняться в проекте. Следует использовать структурное разбиение работ для изображения рабочих действий и отношений между ними. Рабочие действия должны анализироваться до уровня, который раскрывает все проектные факторы риска и обеспечивает корректные оценки требований к ресурсам и продолжительности выполнения каждого рабочего действия. Чтобы задать для каждого рабочего действия критичные факторы, такие, как необходимые ресурсы, оцененная продолжительность, производимые рабочие продукты, критерии приемки для рабочих продуктов, рабочие действия предшественников и преемников, следует использовать рабочие программные пакеты. В структурном разбиении работы уровень разбиения для различных рабочих действий может быть разным в зависимости от факторов, таких, как качество требований, знания о работе и новизна используемых технологий.

5.5.2.2 Распределение графиков (пункт 5.2.2 ПУПРП)

Этот пункт ПУПРП должен обеспечить отношения планирования между рабочими действиями способом, который изображает упорядочение во времени и иллюстрирует возможности ведения параллельных рабочих действий. Любые ограничения на планирование специфических рабочих действий, вызванные факторами, внешними к проекту, должны быть обозначены в графике выполнения рабочих действий. В график следует включать достаточно частые контрольные точки, в которых могут быть оценены достижения по объективным показателям, область применения и качество произведенных к этому времени рабочих продуктов. Методики для отображения распределения графиков по проекту могут включать диаграммы с контрольными точками, перечни действий, диаграммы Ганта, сетевые графики, критические сетевые пути, метод PERT.

5.5.2.3 Распределение ресурсов (пункт 5.2.3 ПУПРП)

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

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

5.5.2.4 Распределение бюджета (пункт 5.2.4 ПУПРП)

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

5.5.2.5 План снабжения (пункт 5.2.5 ПУПРП)

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

5.6 Оценка и контроль проекта (раздел 6 ПУПРП)

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

5.6.1 План управления требованиями (подраздел 6.1 ПУПРП)

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

5.6.2 План контроля за изменениями в области применения (подраздел 6.2 ПУПРП)

В этом подразделе ПУПРП должно быть описано, как выявить действия, не относящиеся к области применения проекта, и определить конкретные выбираемые действия, если они востребованы. Технический отчет ИСО/МЭК 19759:2005 [12], (см. 3.А.5.В.1, раздел 8), содержит детали относительно определения области применения проекта.

_______________

Заменен на ISO/IEC TR 19759:2015.

5.6.3 План управления графиками (подраздел 6.3 ПУПРП)

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

5.6.4 План управления бюджетом (подраздел 6.4 ПУПРП)

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

5.6.5 План гарантии качества (подраздел 6.5 ПУПРП)

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

5.6.6 Планы управления субподрядчиками (подраздел 6.6 ПУПРП)

Этот подраздел ПУПРП должен содержать планы относительно отбора и управления любыми субподрядчиками, которые могут сотрудничать по рабочим продуктам проекта. Должны быть определены критерии выбора субподрядчиков. Используя приспособленную версию настоящего стандарта, необходимо разработать план управления относительно каждого субконтракта. В приспособленные планы следует включать разделы, необходимые для гарантий успешного завершения каждого субконтракта. В частности, в каждый план субподрядчика должны быть включены: управление требованиями; контроль за техническим продвижением; управление графиками выполнения и бюджетом; критерии приемки продукции; гарантии качества; процессы измерений и управления рисками. Для необходимых гарантий успешного завершения субконтракта следует добавлять дополнительные темы. Должны иметь место ссылки на официальный субконтракт и главные разделы контракта подрядчика/субподрядчика.

5.6.7 План закрытия проекта (подраздел 6.7 ПУПРП)

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

5.7 Поставка продукции (раздел 7 ПУПРП)

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

5.8 Планы по поддерживающим процессам (раздел 8 ПУПРП)

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

5.8.1 Контроль за проектом и рабочей средой (подраздел 8.1 ПУПРП)

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

5.8.2 Управление решениями (подраздел 8.2 ПУПРП)

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

5.8.3 Управление рисками (подраздел 8.3 ПУПРП)

Этот подраздел ПУПРП должен определить план управления рисками для идентификации, анализа и распределения по приоритетам проектных факторов риска. Этот подраздел должен описать процедуры для планирования непредвиденных обстоятельств и используемых методов прослеживания различных факторов риска с оценкой изменений в уровнях факторов риска и реакций на эти изменения. План управления рисками должен также определить планы относительно анализа начальных факторов риска, их непрерывной идентификации, анализа и реакции на риски в течение жизненного цикла проекта. В этом плане следует описать рабочие действия по управлению рисками, процедуры и сроки их реализации, документацию и отчет о требованиях, организациях и персонале, ответственном за выполнение определенных действий и процедур, для доведения до различных приобретающих сторон, поставщиков и организаций субподрядчиков информации о рисках и их статусе. Факторы риска, которые следует рассматривать, относятся к рискам: в отношении приобретающей стороны и поставщика; договорным и технологическим рискам; возникающим из-за масштабов (размеров) и сложности продукции; в разработке и рабочей среде для достижения целей проекта; при наборе персонала и в уровнях навыков; при увольнениях персонала; при соблюдении сроков и бюджета; в принятии продукции приобретающей стороной.

Примечание - ИСО/МЭК 16085:2006 (IEEE 16085:2006) [9] содержит положения по управлению рисками и планам по управлению рисками.

5.8.4 Управление конфигурацией (подраздел 8.4 ПУПРП)

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

Примечание - IEEE 828:2005 [5] и ИСО 10007:2003 [7] содержат положения для управления конфигурацией.

5.8.5 Управление информацией (подраздел 8.5 ПУПРП)

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

5.8.5.1 Документация (пункт 8.5.1 ПУПРП)

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

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

Примечание - ИСО/МЭК 15289:2006 [8] содержит положения по документации.

_______________

Заменен на ISO/IEC/IEEE 15289:2011.

5.8.5.2 Связь и реклама (пункт 8.5.2 ПУПРП)

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

5.8.6 Гарантии качества (подраздел 8.6 ПУПРП)

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

Примечания

1. ИСО 9001:2000 [10] содержит требования к менеджменту качества.

_______________

Заменен на ИСО 9001:2015.

2. ИСО/МЭК 90003:2004 (IEEE 90003:2009) [11] содержит руководство по применению к программным средствам требований из ИСО 9001:2000.

_______________

Заменен на ИСО/МЭК 90003:2014.

5.8.7 Измерения (подраздел 8.7 ПУПРП)

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

Примечание - Спецификации информационной модели измерений по ИСО/МЭК 15939:2007 (IEEE 15939:2007) включают частоту сбора данных, источники данных и т.д.

5.8.8 Ревизии и аудиты (подраздел 8.8 ПУПРП)

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

5.8.9 Верификация и валидация (подраздел 8.9 ПУПРП)

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

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

Примечание - IEEE 1012:1998 [13] содержит положения по обеспечению, верификации и валидации программных средств.

5.9 Дополнительные планы (раздел 9 ПУПРП)

Этот раздел ПУПРП должен содержать дополнительные планы, необходимые для удовлетворения требований к продукции и договорным срокам выполнения проекта. Дополнительные планы относительно специального проекта могут включать планы относительно выполнения требований по обеспечению безопасности, обеспечению частной жизни, защищенности для продукции специальных основных средств или оборудования, планы по инсталляции, обучению пользователей, комплексированию, конверсии данных, передаче системы, сопровождению или поддержке продукции. Для проектов, имеющих дело с программными средствами или системами, дополнительные требования обычно документируются в два дополнительных плана, созданных на более низком уровне абстракции, чем ПУПРП. Дополнительные планы - это план управления системной инженерией (SEMP) и план разработки программных средств (SDP).

5.10 Заключительные положения

ПУПРП может включать приложения и индексирование, если это приемлемо для помощи в использовании ПУПРП.

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

Индексирование. Индексы к ключевым терминам и сокращениям, используемым в теле ПУПРП, являются дополнительными. Индексирование рекомендуется для улучшения удобства и простоты использования ПУПРП.

6 Процессы проекта

Этот раздел исследует семь процессов проекта согласно ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008), представляя детальное рассмотрение и рекомендации по применению в управлении проектами, имеющими дело с программными средствами или системами. Рассмотрение и рекомендации предназначены для помощи руководителям проектов в составлении нормативного содержания ПУПРП для специального проекта, как это показано в разделе 5 настоящего стандарта.

Нормативные части процесса проекта из ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008) представлены в таблице, где они рассмотрены с последующими рекомендациями. Рекомендации, данные для проектов программных систем, относятся к проектам программных средств. Любые рекомендации, данные для программных продуктов, излагаются ниже соответствующих рекомендаций для программных систем.

Нормативный текст для описания процессов проекта из соответствующих частей ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008), процитированных в настоящем стандарте, в некоторых случаях различается. В одних случаях это происходит из-за того, что области применения стандартов различны. Например, контекст процесса жизненного цикла ИСО/МЭК 12207:2008 (IEEE 12207:2008) сосредоточен на программных средствах и услугах, в то время как описание процесса жизненного цикла в ИСО/МЭК 15288:2008 (IEEE 15288:2008) фокусируется на более широком рассмотрении различного рода систем. В других случаях различия могут произойти из-за определенной цели или выходных результатов в ИСО/МЭК 15288:2008 (IEEE 15288:2008), предполагающих, что данный раздел, заявленный в ИСО/МЭК 12207:2008 (IEEE 12207:2008), должно быть, включен для фиксации подобного раздела в ИСО/МЭК 15288:2008 (IEEE 15288:2008). Однако в целях настоящего стандарта различия несущественны. Каждая часть процесса в настоящем стандарте разработана с учетом общей цели и выходных результатов из ИСО/МЭК 12207:2008 (IEEE 12207:2008) и ИСО/МЭК 15288:2008 (IEEE 15288:2008).

Существует несколько предписывающих методологий управления проектами, которые поддерживают процессы жизненного цикла в области системной и программной инженерии, используемых и в государственном, и в частном секторе. Руководство РМВОК® [1] содержит исчерпывающий набор родовых процессов управления проектами. Руководство OGC PRINCE2® [17] дает представление об управлении проектами правительственных информационных систем. Методология создания программного обеспечения RUP® [18] была подключена к РМВОК® [19] и итеративно применяет управление проектами и процессами разработки программных средств. (Каждое повторение происходит на любой из фаз RUP, а именно в фазах начала, разработки, конструирования, передачи. Повторение не может происходить более чем на одной фазе, и итерация охватывает шесть основных и три поддерживающие дисциплины RUP). Постадийная методология GATES [20] поддерживает управление проектами при прохождении стадий, управляя процессами через экспертизу, ревизии, согласование и завершение базовых линий проекта, артефакты и обозначенные рабочие продукты (или поставки по проекту) для гарантий готовности перехода к следующей фазе, стадии, процессу, действию или задаче. Идентифицированные процессы, действия и задачи для любого данного проекта могут потребовать итеративных действий на пути к достижению целей проекта. Например, процессы, действия и задачи могут быть основаны на модели жизненного цикла программных средств и использоваться в одно и то же время; они могут быть взаимозависимыми или скоординированными в организованном ряду структурного разбиения работ (WBS) по всему жизненному циклу проекта.

Руководителю проекта следует довести применимые проектные планы, поставки и графики выполнения до соответствующих заинтересованных сторон организации. Руководителю проекта необходимо учитывать их обязательства, чтобы поддержать процессы организации. В подразделе 6.2 ИСО/МЭК 12207:2008 (IEEE 12207:2008) и подразделе 6.2 ИСО/МЭК 15288:2008 (IEEE 15288:2008) дается представление о проекте организации, реализующем следующие процессы:

- управления моделью жизненного цикла;

- управления инфраструктурой;

- управления портфелем;

- управления человеческими ресурсами;

- управления качеством.

6.1 Процесс планирования проекта

Руководство:

a) Ответственность за подготовку и согласование планов следует определить и задокументировать.

b) Руководителю проекта следует гарантировать, что все проектные требования выявляются, документируются, анализируются и управляются. При планировании проекта следует предусмотреть следующие действия:

1) привлечение всех заинтересованных сторон к определению требований проекта;

2) управление изменениями в области применения и требованиях по всему жизненному циклу проекта. Все изменения в области применения и требованиях следует тщательно оценивать по воздействию на стоимость, сроки выполнения, риски, текущие области применения и качество;

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

4) определение того, кто ответственен за соглашения с заинтересованными сторонами по проектным требованиям;

5) установление и поддержание прослеживаемости между требованиями к системе и программным средствам, между требованиями к программным средствам и проектом, а также между требованиями к программным средствам и тестами.

c) Критические усилия по системной инженерии следует проводить с необходимыми ресурсами и навыками по программной инженерии.

d) Критические усилия по программной инженерии следует проводить с необходимыми ресурсами и навыками по системной инженерии.

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

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

Примечание - См. приложение А ИСО/МЭК 12207:2008 (IEEE 12207:2008) и/или ИСО/МЭК 15288:2008 (IEEE 15288:2008) по процессу приспосабливания.

g) При разработке проектной области применения следует учитывать итеративность процесса соглашения, используемого по всему жизненному циклу проекта. Начальная область применения обычно основана на установленных или выявляемых требованиях заказчика/пользователя, но риски, изменения в требованиях заинтересованных сторон, окружающей среде, проектном бюджете и сроках, проектирование развития заставляют непрерывно переоценивать и вновь подтверждать соглашения и обязательства и, как требуется, вносить соответствующие изменения в область применения проекта. Руководителю проекта следует также определить выполнимость запланированных процессов проекта, чтобы персонал, материалы, основные средства, среда системной и программной инженерии и технология, требуемая для выполнения и управления проектом, были доступными, адекватными и приемлемыми, а определенные сроки для завершения проекта были достижимыми и экономичными. Результаты этого анализа выполнимости могут вызвать необходимость уточнений положений о начальной области применения проекта. Для извлечения пользы могут оказаться востребованными многократные итерации между областью применения, внутренними планами и процессами проекта.

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

i) ИСО/МЭК 10006:2003 [2] предоставляет руководящие принципы руководителям для обеспечения надлежащего качества их проектов, продукции и услуг.

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

k) В процессе планирования следует установить критерии завершения для всех проектных задач. Подход, как поддержано руководством РМВОК® [1], помогает определить, были ли проект, действие или задача завершены успешно.

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

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

n) В проекте следует определить один главный график выполнения работ, и все зависимые графики следует интегрировать и согласовать с главным графиком. Структурное разбиение работ (WBS) следует применять к оценкам эффективности проектного продвижения и обеспечивать наглядность в процессах и продуктах. Руководство РМВОК® [1] настоятельно рекомендует порядок структурного разбиения работ, потому что это организует и определяет полную область применения проекта. Структурное разбиение работ следует проводить таким образом, чтобы проект был управляемым на соответствующем уровне последовательной степени детализации с учетом масштабов, сложности, критичности и рисков проекта.

o) В проектные оценки, используемые при планировании, следует включать:

1) затраты, связанные с выполнением процесса;

2) непериодические затраты для создания продукции;

3) возвращающиеся затраты, ежегодные, требуемые организацией в результате завершения проекта;

4) инфраструктуру;

5) потребности в ресурсах, включая соответствующее управление и контроль;

6) навыки и уровень опыта персонала, назначенного на проект;

7) гарантии и контроль качества;

8) управление рисками;

9) условия среды программной инженерии;

10) выполняемую работу в каждом процессе и/или действии;

11) управление конфигурацией;

12) технические критерии качества работы (например, время ответа, пропускная способность, использование памяти, полоса пропускания).

р) Руководителям проектов следует использовать существующую организационную инфраструктуру всякий раз, когда это применимо. Если существующая инфраструктура не соответствует или является недостаточной для поддержки проекта, тогда следует обоснованно использовать адаптацию или дополнения к существующей инфраструктуре. Для устранения дефицита в инфраструктуре может потребоваться заключение субподрядного договора.

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

r) Планы следует обновлять и согласовывать с положениями раздела 5 настоящего стандарта.

s) Руководителю проекта следует гарантировать, что план управления проектом и все планы, на которые он ссылается, помещены под управление конфигурацией проекта.

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

u) Всякий раз, когда поддержка процессов выполняется организациями вне прямого организационного контроля со стороны руководителя проекта, важно понять существование двух множеств отношений между: 1) руководителем проекта и другими руководителями, поддерживающими управление процессом; 2) поддерживаемым и поддерживающим организационными управлениями. Руководителю проекта следует признать этот факт, рассматривая аспекты планирования, выполнения, контроля и отчетности при реализации специальной технической и управленческой отчетности, организации потоков информации и разрешении споров. Синхронизация планов может оказаться более сложной с учетом соглашений и задач по субконтрактам. В этом случае может помочь наличие одного генерального плана.

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

w) Если в проекте от одной или более организаций участвуют несколько команд, руководителю проекта следует объединить эти команды, обеспечивая, чтобы каждая команда, используя свое отдельное видение, ориентировалась на общие цели в проекте.

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

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

z) При планировании проекта используются различные методы оценки стоимости, включая стоимостные модели применительно к системе и программным средствам. Методы оценки стоимости основаны на предполагаемом размере конечного и/или рабочего продукта. Таким образом, важно точно оценить размер продукта.

aa) При планировании проекта следует включать планирование непредвиденных обстоятельств для управленческих и технических проблем.

ab) Руководителю проекта следует начинать проект соразмерно с полномочиями по расходам (или дополнительным расходам) бюджета.

Руководство для программных средств:

a) ИСО/МЭК 25030:2007 [14] рекомендует уделить внимание определению и документированию требований к качеству, основанных на характеристиках качества согласно ИСО/МЭК 9126-1:2001 [3], например, когда программные средства должны быть встроены в высокоуровневую систему, когда функции должны быть распределены между программными и аппаратными средствами или между программными средствами и внешне взаимодействующими системами или программными средствами.

_______________

Заменен на ИСО/МЭК 25010:2011.

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

c) Следует определять сложность программных средств и системы и разрабатывать показатели эффективности с приобретающей стороной.

d) Планы по системе, программным и аппаратным средствам следует интегрировать и управлять ими согласованно.

e) Для обеспечения программными ресурсами руководителю следует определить:

1) требования для сопровождения, распределения обновлений, модернизаций и затрат на предоставляемые услуги;

2) права собственности, например гарантии, интеллектуальные права, патенты, лицензии и авторские права.

6.2 Процесс оценки и контроля проекта

Руководство:

a) Для оценки и успешной реализации ограничений взаимодействия следует сформировать рабочие группы по управлению взаимодействием (ICWGs). Эти рабочие группы следует составлять из представителей от каждой организации, имеющей отношение к взаимодействию. Рабочие группы по управлению взаимодействием проводят совещания по рассмотрению взаимодействия программных средств и систем, исследуют варианты и заключают соглашения о лучшем подходе для реализации взаимодействия. Рекомендации рабочей группы, требующие проектных изменений, следует предоставлять любому формальному процессу управления конфигурацией, реализующему проект (например, в совет по управлению конфигурацией), для согласования до реализации. Следует определить и управлять взаимодействиями как неотъемлемой частью спецификации программных средств и документов по описанию взаимодействия.

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

c) Руководителю проекта следует быть ответственным за то, чтобы проектные задачи включали:

1) оценку результатов анализа проектных продуктов, действий и задач;

2) соответствие планам управления, философии, методологии и технологиям проекта;

3) документирование планов и обязательств;

4) удовлетворение требований;

5) готовность для продвижения к следующему процессу, действию или задаче.

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

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

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

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

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

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

j) Следует требовать документирования существенных проблем, деловых вопросов и решений, вытекающих из анализов и оценок. Деловые вопросы и существенные проблемы следует прослеживать до их закрытия. А выявленные проблемы необходимо вводить в систему корректирующих действий проекта.

k) Руководителям проектов следует предпринимать всеохватывающее управление взаимозависимостями между процессами проекта.

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

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

n) Позднее добавление персонала к проекту программных средств делает проект отстающим во времени.

_______________

Brooks, Frederick P. The Mythical Man Month: Essays on Software Engineering (1975, 2nd ed. 1995).

o) Чтобы гарантировать соответствие или регулирование целей (стоимость, время и выполнение), базовая линия требований к программным средствам регулярно рассматривается по всему проекту во взаимодействии с заинтересованными сторонами.

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

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

6.3 Процесс управления решениями

Руководство:

a) В стратегию принятия решений следует включать определение лиц, принимающих решения, их полномочий, категорий решения и установление приоритетов. Категории решения могут включать:

1) параметры реализации для требований функциональных возможностей продукта;

2) определенные процессы, применимые к проекту, чтобы избежать чрезмерной спецификации процесса управления решениями;

3) точки входа и выхода для стадий жизненного цикла;

4) пороги стоимости для альтернатив, в которых формальные компромиссные исследования должны поддерживать решение;

5) разработанные или купленные решения по компонентам продукта или системы, которая будет поставлена;

6) проблемы, затрагивающие бизнес-цели организации;

7) категории риска, для которого требуются формальные планы смягчения.

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

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

d) В стратегии принятия решений следует определить роли и ответственность различных заинтересованных сторон, зависящих от предстоящих решений. Примеры включают:

1) у полного плана стоимости проекта, как результата перспективного проектирования, может быть заинтересованная сторона от функциональной финансовой области с ролью согласования, но следует включать эту заинтересованную сторону как аналитика относительно реализации этой функциональности;

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

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

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

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

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

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

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

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

6.4 Процесс управления рисками

Руководство:

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

Примечание - ИСО/МЭК 16085:2006 (IEEE 16085:2006) [9] определяет процесс для управления рисками в жизненном цикле. Управление рисками - основная дисциплина для того, чтобы принять эффективные решения и отчитаться по результатам в пределах организаций. Цель управления рисками состоит в том, чтобы определить потенциальные организаторские и технические проблемы прежде, чем они приведут к ущербам, и так, чтобы могли быть превентивно предприняты противодействия, которые уменьшают или устраняют вероятность и/или возможные воздействия от этих возможных проблем. Это критический инструмент для того, чтобы непрерывно определять выполнимость планов проекта, улучшить поиск и определение потенциальных проблем, которые могут затронуть действия, качество и рабочие продукты в жизненном цикле, а также для того, чтобы улучшить активное управление проектами.

6.5 Процесс управления конфигурацией

Руководство:

Примечание - Стандарты IEEE 828:2005 [5], ANSI/GEIA 649A [6] и ИСО 10007:2003 "Системы менеджмента качества. Руководящие принципы для управления конфигурацией" [7] содержат положения по управлению конфигурацией.

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

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

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

Руководство для программных средств:

а) Процесс управления конфигурацией для программных средств, представленный в 7.2.2 ИСО/МЭК 12207, является специализацией из процесса управления конфигурацией из группы процессов проекта и обеспечивает дополнительные детали для использования руководителем проекта в управлении конфигурацией для программных средств.

6.6 Процесс управления информацией

Руководство:

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

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

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

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

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

Заключение проекта [стадии] отмечается анализом основной поставки и проектной работы, чтобы: а) определить, следует ли проект продолжать, переводя его в следующую стадию, и b) правильно ли обнаруживаются и исправляются ошибки по критериям "эффективность-стоимость" (согласно Руководству РМВОК®) [1]).

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

6.7 Процесс измерения

Руководство:

Примечание - ИСО/МЭК 15939:2007 (IEEE 15939:2007) [4] содержит положения по измерениям. Измерение поддерживает управление и усовершенствование процессов и продуктов. Измерение - это первичный инструмент для управления системой и действиями в жизненном цикле программных средств, оценивая выполнимость проектных планов и контролируя приверженность проектных действий этим планам. Измерение системы и программных средств - также основная дисциплина в оценке качества продукции и возможностей организационных процессов. Стандарт ИСО/МЭК 15939:2007 (IEEE 15939:2007) определяет действия и задачи, которые необходимы, чтобы успешно идентифицировать, определить, выбрать, использовать и улучшить измерение в пределах полной проектной или организационной структуры. Стандарт также обеспечивает определения для терминов по измерениям, обычно используемых в пределах отраслей промышленности, программных средств и систем.

Библиография

[1] ANSI/PMI 99-001-2004, A Guide to the Project Management Body of Knowledge, Third Edition - PMBOK® Guide, Project Management Institute (PMI) Standards Committee, 2004

[2] ISO 10006:2003, Quality management systems - Guidelines for quality management in projects

[3] ISO/IEC 9126-1:2001, Software engineering - Product quality - Part 1: Quality model

_______________

Заменен на ISO/IEC 25010:2011.

[4] ISO/IEC 15939:2007 (IEEE Std 15939-2007), Systems and software engineering - Measurement process

[5] IEEE Std 828-2005, Standard for Configuration Management Plans

[6] ANSI/GEIA 649A, National Consensus Standard for Configuration Management, 1 April 2004

[7] ISO 10007:2003, Quality management systems - Guidelines for configuration management

[8] ISO/IEC 15289:2006, Systems and software engineering - Content of systems and software life cycle process information products (Documentation)

_______________

Заменен на ISO/IEC/IEEE 15289:2015.

[9] ISO/IEC 16085:2006 (IEEE Std 16085-2006), Systems and software engineering - Life cycle processes - Risk management

[10] ISO 9001:2000, Quality management systems - Requirements

_______________

Заменен на ISO 9001:2015.

[11] ISO/IEC 90003:2004 (IEEE Std 90003-2009), Software engineering - Guidelines for the application of ISO 9001:2000 to computer software

_______________

Заменен на ISO/IEC 90003:2014.

[12] ISO/IEC TR 19759:2005, Software Engineering - Guide to the Software Engineering Body of Knowledge (SWEBOK)

_______________

Заменен на ISO/IEC TR 19759:2015.

[13] IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation, 9 March 1998

[14] ISO/IEC 25030:2007, Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements

[15] ISO/IEC 12207:2008 (IEEE Std 12207-2008), Systems and software engineering - Software life cycle processes

[16] ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering - System life cycle processes

_______________

Заменен на ISO/IEC/IEEE 15288:2015.

[17] OGC:2005, Managing Successful Projects with PRINCE2®, Office of Government Commerce (UK)

[18] Krutchen P.:2000, The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley

[19] Charbonneau S.:2004, Software Project Management - A Mapping between RUP and the PMBOK, Xelaration Software Corp. /library/4721.html

[20] Cooper R.G.:2004 Principles of the Stage-Gate Method, PDMA Handbook for New Product Development, John Wiley & Sons Inc.

Электронный текст документа

и сверен по:

, 2018