5ebd9f04

Обязательства по выполнению


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


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

В рамках этих практик системные требования, отнесенные к ПО, называются «установленными требованиями».

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

Эта политика обычно состоит из следующих положений: 

1. Установленные требования должны быть документированы. 

2. Установленные требования рассматриваются:

  • производственными менеджерами,

  • другими задействованными группами.

    • Примеры групп, задействованных в проекте: 

  • группа системного тестирования, 

  • разработки ПО (включая все подгруппы, например, проектирования ПО), 

  • системного проектирования, 

  • обеспечения качества ПО, 

  • управления конфигурацией ПО, 

  • управления документацией.

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






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

    Обязательство 2 Проект следует документированной организационной политике по планированию проектов разработки ПО.

    Эта политика обычно состоит из следующих положений:

    1. Планирование проекта разработки должно выполняться на основе системных требований, отнесенных к ПО. См. описание Операции №2 группы ключевых процессов «Управление требованиями».

    2. Обязательства по проекту обсуждаются:

  • менеджером проекта,

  •     производственным менеджером проекта,

  •     другими производственными менеджерами.

    • 3. Участие других инженерных групп в операциях разработки обсуждается с этими группами и документируется. Примеры других инженерных групп: системного проектирования, проектирования аппаратного обеспечения, системного тестирования.

    4. Задействованные группы рассматривают следующие аспекты проекта:

  • оценки объема ПО,

  • оценки объема работ и затрат,

  • графики выполнения работ,

  • другие обязательства.

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

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

    6. Полученный документ плана разработки ПО является управляемым и контролируемым. Термин «план разработки ПО» используется в этом тексте для обозначения общего плана по управлению проектом разработки. Термин «разработка» не исключает сопровождения ПО или проектов поддержки и должен правильно интерпретироваться в контексте каждого проекта.

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

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




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

    Эта политика обычно состоит из следующих положений:

    1. Отслеживание хода проекта должно выполняться на основе документированного плана разработки ПО.

    2. Менеджер проекта должен постоянно информироваться о состоянии проекта разработки и возникающих проблемах.

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

    4. Изменения производственных обязательств вносятся при участии задействованных групп и согласуются с ними.

    Примеры задействованных групп:

  • группа разработки ПО (включая все подгруппы, например, проектирования ПО, оценки составляющих проекта, системного проектирования),

  • системного тестирования,

  • обеспечения качества ПО,

  • управления конфигурацией ПО,

  • управления контрактами,

  • управления документацией.

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




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

    Эта политика обычно состоит из следующих положений:

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

    2. Управление субподрядом основывается на заключенных договорах.

    3. Изменения обязательств по субподряду принимаются при участии и согласии как генерального подрядчика, так и субподрядчика.

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

    1. Менеджер по субподряду должен обладать знаниями и опытом в разработке ПО или иметь в своем распоряжении подчиненных, обладающих такими знаниями и опытом.

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

    Технический объем передаваемых на субподряд работ определяется группами системного проектирования и разработки ПО.

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

    3. В сферу ответственности менеджера по субподряду входит следующее:

  • выбор субподрядчика,

  • управление субподрядом,

  • организация поддержки поставленных субподрядных продуктов.




    • Обязательство 1 Проект следует документированной организационной политике по обеспечению качества ПО.

    Эта политика обычно состоит из следующих положений.

    1. Группа обеспечения качества контролирует работу по всем проектам разработки в организации.

    2. Группа обеспечения качества имеет канал отчетности перед высшим руководством, который независим от:

  • менеджера проекта,

  • группы разработки ПО,

  • других групп, связанных с разработкой ПО.

    • Примеры групп, связанных с разработкой ПО:

  • группа управления конфигурацией ПО,

  • группа управления документацией.

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

    Независимость должна: обеспечивать сотрудникам группы обеспечения качества организационную свободу, позволяющую им быть «глазами и ушами» высшего руководства проекта; исключить вынесение оценки работы сотрудников группы обеспечения качества со стороны руководства проверяемого проекта; обеспечить уверенность высшего руководства в объективности получаемых отчетов о производственном процессе и качестве продуктов проекта разработки ПО.

    3. Высшее руководство регулярно проверяет деятельность группы обеспечения качества и ее результаты.




    Обязательство 1 Проект следует документированной организационной политике управления конфигурацией ПО (Software Configuration Management, SCM).

    Эта политика обычно состоит из следующих положений:

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

    2. Управление конфигурацией ПО реализуется в течение всего жизненного цикла проекта.

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

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

    В этих практиках содержание данного репозитария называется «библиотекой базовых линий конфигурации».

    Инструменты и процедуры доступа к этому репозитарию называются «системой управления библиотекой конфигураций».

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

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

    5. Регулярно проводится аудит базовых линий и работ по управлению конфигурацией ПО.




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

    Эта политика обычно состоит из следующих указаний:

    1. Создается группа, в сферу ответственности которой входят работы, связанные с ППО, и их координация с проектами.

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

    3. Производственные процессы проектов получаются путем соответствующей адаптации стандартного производственного процесса организации к конкретному проекту.

    Практики, связанные с адаптацией СППО, содержатся в описании Операции №1 группы ключевых процессов «Интегрированное управление разработкой ПО».

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

    Обязательство 2 Высшее руководство поддерживает действия организации по разработке и усовершенствованию производственного процесса.

    Высшее руководство:

    1. Подтверждает перед сотрудниками и менеджерами организации свои обязательства по разработке и усовершенствованию производственного процесса.

    2. Устанавливает долгосрочные планы и принимает обязательства по обеспечению этих работ необходимыми финансами, персоналом и другими ресурсами.

    3. Устанавливает стратегии управления и реализации действий по разработке и усовершенствованию производственного процесса.

    Обязательство 3 Высшее руководство осуществляет надзор за действиями организации по разработке и усовершенствованию производственного процесса.

    Высшее руководство:

    1. Обеспечивает соответствие СППО бизнес-целям и стратегиям организации.

    2. Дает рекомендации по определению приоритетов при разработке и усовершенствовании производственного процесса.

    3. Участвует в составлении планов разработки и усовершенствования производственного процесса.

  • Высшее руководство согласует требования к производственному процессу и связанные с ним вопросы с сотрудниками и менеджерами высших уровней.

  • Высшее руководство согласует с руководителями организации обеспечение поддержки и участия менеджеров и сотрудников в работах по координации производственного процесса.




    • Обязательство 1 Организация следует документированной политике разработки и сопровождения СППО и связанных с ним основных средств.

    Основные средства ППО:

  • стандартный производственный процесс организации,

  • инструкции и критерии для адаптации СППО к конкретному проекту,

  • утвержденные описания жизненных циклов ПО,

  • база данных ППО,

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

    • Эта политика обычно состоит из следующих положений:

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

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

    2. Производственный процесс проекта является адаптированной версией СППО.

    Практики, связанные с адаптацией СППО, содержатся в описании Операции №1 группы ключевых процессов «Интегрированное управление разработкой ПО».

    3. Осуществляется поддержка основных средств ППО. 4. Информация, собранная из различных проектов, организуется и используется для усовершенствования СППО.

    Примеры собираемой информации:

  • измерения, проводимые для оценки процессов и продуктов,

  • накопленный опыт,

  • другая документация, имеющая отношение к производственным процессам.




    • Обязательство 1 Организация следует документированной политике предоставления необходимого обучения.

    Эта политика обычно состоит из следующих положений:

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

    2. Должны быть определены и утверждены механизмы передачи навыков и знаний. Примеры утвержденных механизмов обучения:

  • проведение семинаров,

  • машинное обучение,

  • самообучение под руководством преподавателя,

  • формализованные программы наставничества,

  • обучающие видеофильмы.

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

    4. Учебные курсы или разрабатываются внутри организации, или предоставляются из внешних источников, если это необходимо.

    Примеры внешних источников обучения:

  • обучение, проводимое заказчиком,

  • коммерческие учебные курсы,

  • академические программы,

  • профессиональные конференции,

  • семинары.




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

    Практики, касающиеся СППО и связанных с ним основных средств, содержатся в группе ключевых процессов «Определение производственного процесса организации».

    Эта политика обычно состоит из следующих положений:

    1. Производственный процесс каждого проекта разрабатывается путем адаптации СППО.

    2. Все отклонения от производственного процесса проекта от СППО должны быть документированы и утверждены.

    3. Операции по разработке ПО в каждом проекте выполняются в соответствии с его производственным процессом.

    4. В каждом проекте собираются данные соответствующих измерений, которые затем сохраняются в базе данных ППО.

    Практики, связанные с базой данных ППО, содержатся в описании Операции №5 группы ключевых процессов «Определение производственного процесса организации».




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

    Эта политика обычно состоит из следующих положений:

    1. Операции разработки ПО выполняются в соответствии с производственным процессом проекта.

    Практики, связанные с производственными процессами проектов, содержатся в описании Операций №1 и 2 группы ключевых процессов «Интегрированное управление разработкой ПО».

    2. Для создания и сопровождения программных продуктов используются соответствующие методы и инструменты.

    3. Планы, задачи и продукты разработки должны отслеживаться до системных требований, отнесенных к ПО. В рамках этих практик системные требования, отнесенные к ПО, называются «установленными требованиями».

    Практики, связанные с системными требованиями, отнесенными к ПО, содержатся в группе ключевых процессов «Управление требованиями».




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

    Эта политика обычно состоит из следующих положений:

    1. Системные требования к проекту и цели проектного уровня определяются и рассматриваются всеми задействованными группами.

    Примеры групп, задействованных в проекте:

  • группа разработки ПО,

  • оценки составляющих проекта,

  • системного тестирования,

  • обеспечения качества ПО,

  • управления конфигурацией ПО,

  • управления договорами,

  • управления документацией.

    • 2. Инженерные группы должны координировать свои планы и работы.

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

    В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.




    Обязательство 1 Проект следует документированной организационной политике проведения экспертных оценок.

    Эта политика обычно состоит из следующих положений:

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

    2. Для каждого проекта определяются промежуточные программные продукты, подвергаемые экспертной оценке.

    Практики, связанные с выявлением программных продуктов, подвергаемых экспертной оценке, содержатся в описании Операции №1 группы ключевых процессов «Интегрированное управление разработкой ПО» и Операции №2 группы ключевых процессов «Определение производственного процесса организации».

    Примеры промежуточных программных продуктов:

  • системное ПО и вспомогательные программы,

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

  • программные (например, код) и непрограммные промежуточные продукты (например, документы),

  • описания процессов.

    • 3. Экспертные оценки проводятся под руководством ведущих экспертов, опытных в их проведении.

    4. Экспертные оценки фокусируются не на разработчике, а на проверяемом промежуточном программном продукте.

    5. Результаты экспертных оценок не должны использоваться руководством для оценки работы сотрудников.



    Содержание раздела