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