Выполняемые операции

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

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

1. Выявляются пропущенные пункты требований.

2. Выполняется проверка установленных требований на:

выполнимость и возможность реализации в виде программы,

четкость и корректность формулировки,

отсутствие противоречий между требованиями,

возможность тестирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

Установленные требования:

1. являются управляемыми и контролируемыми;

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

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

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

1. Группы разработки ПО участвует в следующих действиях:

подготовка и подача предложения.

представление и обсуждение предложения,

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

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

Примеры проектных обязательств:

технические цели и задачи проекта;

техническое решение системы и разработки;

бюджет, график и ресурсы разработки;

используемые при разработке стандарты и процедуры.

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

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

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

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

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

Примеры жизненных циклов разработки:

«водопад»,

«водопад» с перекрытием,

«спираль»,

серийный выпуск,

единый прототип/«водопад» с перекрытием.

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

Эта процедура обычно определяет следующие действия:

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

стандарты, применяемые заказчиком;

стандарты, используемые в проекте;

утвержденное техническое задание;

установленные требования.

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

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

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

К плану разработки ПО выдвигаются следующие требования:

1. Этот план должен обновляться по ходу проекта, отражая его результаты и, в частности, завершение этапов.

2. К плану разработки ПО получают постоянный доступ:

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

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

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

высшее руководство,

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

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

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

Эта процедура обычно определяет следующее:

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

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

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

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

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

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

Эта процедура обычно определяет следующее:

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

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

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

2. Для составления спецификации субподрядных работ, применяемых стандартов и процедур используются следующие проектные документы:

техническое задание,

системные требования, отнесенные к ПО,

требования к ПО,

план разработки ПО,

стандарты и процедуры разработки.

3. Техническое задание на субподряд:

подготавливается,

проверяется,

согласуется.

Примеры сотрудников, в чьи обязанности входит проверка и согласование технического задания на субподряд:

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

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

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

менеджер по управлению конфигурацией ПО,

менеджер по обеспечению качества ПО,

менеджер субподряда.

исправляется по мере необходимости,

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

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

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

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

Эта процедура обычно определяет следующее:

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

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

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

Операция 2 Группа обеспечения качества выполняет свои работы в соответствии с планом обеспечения качества.

План охватывает следующие вопросы:

1. Сфера ответственности и полномочия группы обеспечения качества.

2. Ресурсы, требующиеся группе обеспечения качества (включая персонал, инструменты и инженерные средства).

3. Календарный план и финансирование работ группы обеспечения качества.

4. Участие группы обеспечения качества в составлении плана разработки ПО, стандартов и процедур проекта.

5. Оценки, выполняемые группой обеспечения качества.

Примеры оцениваемых продуктов и работ:

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

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

Эта процедура обычно определяет следующее:

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

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

3. Документ плана управления конфигурацией ПО должен быть управляемым и контролируемым.

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

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

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

План охватывает следующие вопросы:

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

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

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

Задачи, решаемые данной библиотечной системой:

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

2. Хранение и извлечение отдельных элементов/блоков конфигурации. 3.

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

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

Примером метода оценки продуктивности ППО может служить метод оценки производственного процесса (Software Process Assessment), разработанный институтом SEI.

План действий определяет следующее:

какие данные, полученные в результате проверки, будут приняты во внимание;

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

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

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

Данный план:

1. Использует в качестве исходных данных планы действий по оценке производственного процесса и других инициатив по усовершенствованию организации.

2. Определяет необходимые мероприятия и график их проведения.

3. Определяет группы и сотрудников, ответственных за эти мероприятия.

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

5. Подвергается экспертным оценкам после своего создания или внесения крупных изменений. См. группу ключевых процессов «Экспертные оценки».

6. Проверяется и согласуется производственными менеджерами и руководителями высшего звена.

Операция 3 Мероприятия, проводимые в рамках организации и проектов в целях разработки и усовершенствования производственных процессов, координируются на уровне организации.

Эта координация касается разработки и усовершенствования следующих процессов:

1. Стандартный производственный процесс организации.

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

2. Производственные процессы проекта.

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

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

Эта процедура обычно определяет следующее:

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

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

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

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

Примеры областей разработки ПО:

анализ требований к ПО,

проектирование архитектуры ПО,

составление кода,

тестирование ПО,

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

обеспечение качества ПО.

5. Должны быть описаны внешние интерфейсы между процессом разработки и процессами других задействованных групп.

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

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

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

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

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

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

Примеры источников изменений:

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

результаты адаптации СППО к конкретному проекту,

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

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

проанализированные и интерпретированные данные измерений процесса и продуктов.

7. Планируются, если это необходимо, работы по внесению изменений в производственные процессы текущих проектов.

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

См. группу ключевых процессов «Экспертные оценки».

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

План охватывает следующие вопросы:

1. Набор необходимых навыков и время, к которому они потребуются.

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

3. Содержание необходимого обучения, обучаемый сотрудник и время проведения обучения.

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

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

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

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

изучение конкретных приложений и требований к проекту,

изучение архитектуры программного продукта, разрабатываемого в рамках проекта,

другие виды обучения, более эффективно или рационально проводимые на уровне проекта.

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

Эта процедура обычно определяет следующее:

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

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

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

Эта процедура обычно определяет следующее:

1. Жизненный цикл ПО:

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

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

при необходимости модифицируется в соответствии с принятыми в организации инструкциями и критериями адаптации;

документируется в соответствии с организационными стандартами.

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

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

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

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

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

Отклонения от СППО документируются, после чего они рассматриваются и утверждаются высшим руководством.

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

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

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

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

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

Документируются обоснования выбора конкретного инструмента или метода.

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

Примеры моделей управления конфигурацией:

модели внесения/извлечения данных,

композиционные модели,

транзакционные модели,

модели установки признака изменений.

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

См. группу ключевых процессов «Управление конфигурацией ПО».

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

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

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

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

Примеры методик анализа требований:

функциональная декомпозиция,

объектно-ориентированная декомпозиция,

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

Эти группы выполняют следующие операции:

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

2. Обсуждение критических зависимостей.

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

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

1. Для отслеживания и координации выполнения технических работ представители этих групп проводят следующие мероприятия:

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

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

В состав системных требований и архитектуры входит следующее:

общие системные требования,

системная конфигурация (т. е. аппаратное и программное обеспечение, другие системные компоненты),

распределение и отслеживание требований к этим системным компонентам,

определения интерфейсов между этими системными компонентами.

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

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

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

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

Операция 1 Экспертные оценки проводятся на плановой основе, а планы документируются.

Эти планы определяют:

1. Промежуточные программные продукты, подлежащие экспертной оценке.

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

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

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

Операция 2 Проведение экспертных оценок в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. Экспертные оценки планируются обученными ведущими экспертами и проводятся под их руководством.

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

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

Примеры соответствующей исходной информации:

цели промежуточного программного продукта,

применяемые стандарты,

соответствующие требования к архитектурному модулю,

детальная архитектура модуля программного кода.

3. Участникам экспертной оценки назначаются роли.

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

Вопросы, связанные с несоответствием этим критериям, докладываются соответствующим менеджерам.

5. Для единообразной идентификации критериев конкретной оценки используются контрольные списки.

Контрольные списки адаптируются к конкретному типу промежуточного продукта и экспертной оценки.

Примеры адаптируемых пунктов контрольных списков:

соответствие стандартам и процедурам,

полнота,

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

2. являются основой для создания плана разработки ПО;

3. являются основой для разработки требований к ПО.

Операция 3 Изменения установленных требований рассматриваются и вносятся в проект разработки ПО.

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

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

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

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

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

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

выявляются,

проходят общую оценку,

оцениваются по связанным с ними рискам,

документируются,

планируются,

доводятся до сведения задействованных групп и отдельных сотрудников,

отслеживаются до своего завершения.

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

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

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

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

4. План разработки ПО рассматривается:

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

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

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

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

5. Документ плана разработки ПО должен быть управляемым и контролируемым.

Операция 7 Документирование плана проекта разработки ПО.

В ключевых практиках этот план (или совокупность планов) называется планом разработки ПО.

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

План разработки ПО раскрывает следующие вопросы:

1. Назначение, объем, цели и задачи проекта разработки.

2. Выбор жизненного цикла разработки.

3. Идентификация выбранных процедур, методов и стандартов разработки и сопровождения ПО.

Примеры стандартов и процедур разработки:

планирование разработки ПО,

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

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

проектирование архитектуры ПО,

отслеживание и решение выявленных проблем, измерения при разработке.

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

5. Оценки объема промежуточных программных продуктов и объема их изменений.

6. Оценки объема работ по проекту и затрат на их выполнение.

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

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

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

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

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

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

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

Операция 5 Отслеживание объема промежуточных программных продуктов (или объема их изменений) и применение корректирующих действий в случае необходимости.

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

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

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

3. Фактический объем переданной заказчику документации сравнивается с оценками, содержащимися в плане разработки ПО.

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

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

Операция 6 Отслеживание объема работ и затрат по проекту, при необходимости – применение корректирующих действий.

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

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

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

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

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

В этой процедуре оцениваются следующие факторы:

1. Поданные предложения по планируемому субподряду.

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

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

4. Возможности по разработке ПО и управлению разработкой.

Примером метода оценки возможностей субподрядчика может служить метод SEI для оценки продуктивности процесса разработки (Software Capability Evaluation).

5. Наличие персонала для выполнения работы.

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

7. Доступные ресурсы.

Примеры ресурсов:

производственные помещения,

аппаратное обеспечение,

программное обеспечение,

средства обучения.

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

Документы договора:

1. Условия договора.

2. Техническое задание.

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

3. Требования к разрабатываемым продуктам.

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

5. Перечень продуктов, поставляемых субподрядчиком генеральному подрядчику.

Примеры продуктов:

исходный код,

план разработки ПО,

среда эмуляции,

проектная документация,

план приемочного тестирования.

6. Условия внесения исправлений в продукты.

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

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

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

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

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

6. Аудиты и проверки, проводимые группой обеспечения качества.

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

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

9. Документация, требуемая от группы обеспечения качества.

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

Операция 3 Группа обеспечения качества участвует в подготовке и обсуждении плана разработки ПО, стандартов и процедур проекта.

1. Группа обеспечения качества рассматривает планы, стандарты и процедуры проекта и консультирует участников проекта по следующим вопросам:

соответствие организационной политике,

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

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

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

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

Операция 4 Группа обеспечения качества проверяет производственный процесс разработки ПО на соответствие требованиям.

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

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

Обеспечение совместного использования и передачи элементов/ блоков конфигурации между задействованными группами и между уровнями контроля внутри библиотеки. 4. Помощь в применении производственных стандартов к элементам/блокам конфигурации. 5. Хранение и извлечение архивных версий отдельных элементов/блоков конфигурации. 6. Обеспечение корректного создания продуктов на основе элементов из библиотеки базовых линий. 7. Хранение, обновление и предоставление записей по управлению конфигурацией. 8. Поддержка создания отчетов по управлению конфигурацией. 9. Поддержка структуры и содержимого библиотеки.

Примеры функций поддержки библиотеки:

резервное копирование/восстановление библиотечных файлов,

восстановление библиотечной системы после сбоев.

Операция 4 Идентификация промежуточных программных продуктов, помещаемых в систему управления конфигурацией.

1. Выбор отдельных элементов/блоков конфигурации на основании документированных критериев.

Примеры промежуточных программных продуктов, которые можно определить в качестве элементов/блоков конфигурации:

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

программная система, созданная для проведения тестирования ПО,

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

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

2. Элементам/блокам конфигурации присваиваются уникальные идентификаторы.

3. Определяются характеристики каждого элемента/блока конфигурации.

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

5. Для каждого элемента/блока конфигурации определяется стадия разработки, на которой он помещается в систему управления конфигурацией.

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

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

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

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

Практики, связанные с базой данных ППО, содержатся в описании

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

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

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

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

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

См. группу ключевых процессов «Программа обучения».

Операция 7 Группы, задействованные во внедрении производственных процессов, информируются о мероприятиях по разработке и усовершенствованию процессов, проводимых в рамках организации и проектов.

Примеры способов распространения информации между сотрудниками и их привлечения к участию в мероприятиях:

электронные доски объявлений по производственным процессам,

экспертные комиссии по процессам,

рабочие группы,

совещания по обмену информацией,

обзоры,

группы усовершенствования процессов,

неформальные обсуждения.

9. Описание СППО помещается в систему управления конфигурацией.

См. группу ключевых процессов «Управление конфигурацией ПО».

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

Эти стандарты обычно определяют следующее:

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

Примеры элементов процесса:

элемент оценки ПО,

элемент проектирования архитектуры ПО,

элемент кодирования,

элемент экспертной оценки.

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

2. Описание каждого элемента процесса содержит ответы на следующие вопросы:

необходимые процедуры, практики, методы и технологии;

применяемые стандарты процессов и продуктов;

распределение ответственности за внедрение процесса;

необходимые инструменты и ресурсы;

исходные данные;

создаваемые промежуточные программные продукты;

промежуточные программные продукты, подлежащие экспертной оценке;

критерии готовности и завершения;

собираемые данные о продукте и процессе.

3. Описание отношений между элементами процесса касается следующих вопросов:

очередность,

интерфейсы,

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

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

Примеры жизненных циклов ПО:

«водопад»,

«водопад» с перекрытием,

«спираль»,

серийный выпуск,

единый прототип/»водопад» с перекрытием.

1. Жизненные циклы ПО должны быть совместимы с СППО.

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

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

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

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

Примеры задействованных лиц:

высшее руководство,

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

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

5. Документ плана обучения должен быть управляемым и контролируемым.

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

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

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

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

высшее руководство,

группа обучения,

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

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

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

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

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

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

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

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

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

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

План охватывает следующие вопросы:

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

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

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

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

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

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

Эта процедура обычно определяет следующее:

1. Документирование и систематическое рассмотрение изменений, вызываемых следующими источниками:

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

изменениями, предложенными группой разработки проекта,

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

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

Примеры сотрудников, проверяющих изменения:

члены группы, ответственной за работу над ППО (например, группы инженерии производственного процесса),

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

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

Примеры сотрудников, утверждающих изменения:

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

менеджер проекта.

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

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

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

изучение альтернатив,

имитация,

моделирование,

создание прототипов,

разработка сценариев.

3. Документируются результаты анализа требований и обоснования выбранного варианта.

4. Требования к ПО анализируются на реализуемость, понятность, непротиворечивость, возможность тестирования и полноту (если имеется в виду набор требований).

Проблемы, связанные с требованиями к ПО, выявляются и рассматриваются группой, ответственной за системные требования. Соответствующие изменения вносятся как в установленные требования, так и в требования к ПО.

См. группу ключевых процессов «Управление требованиями».

5. Требования к ПО документируются.

6. Группа, ответственная за системное и приемочное тестирование ПО, анализирует каждое требование к ПО, проверяя возможность его тестирования.

7. Идентифицируются и документируются методы проверки и оценки выполнения каждого требования к ПО. Примеры методов проверки и оценки выполнения: демонстрация, системное тестирование, приемочное тестирование, анализ, инспектирование.

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

См. группу ключевых процессов «Экспертные оценки».

9. Документ требований к ПО рассматривается и утверждается.

Примеры сотрудников, рассматривающих и утверждающих документ требований к ПО:

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

менеджер по системному проектированию,

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

менеджер по тестированию ПО.

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

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

11. Документ требований к ПО помещается в систему управления конфигурацией.

См. группу ключевых процессов «Управление конфигурацией ПО». 12. При любом изменении установленных требований соответствующие изменения вносятся и в требования к ПО. См. группу ключевых процессов «Управление требованиями».

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

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

решение конфликтов проектного уровня и выяснение вопросов, касающихся системных требований и архитектуры;

разработка совместных рекомендаций для решения проблем;

изучение вопросов, касающихся организации процессов и затрагивающих все инженерные группы проекта.

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

1. Данный план является базовой линией для:

календарного графика проекта,

договорных и технических аспектов проекта,

распределения обязанностей между инженерными группами.

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

3. План доступен для членов всех инженерных групп.

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

5. План обновляется по мере выполнения работ, отражая ход проекта и изменения его планов; в частности при завершении основных этапов проекта или значительных изменениях планов.

6. План рассматривается и утверждается всеми инженерными группами и менеджером проекта.

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

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

Эта процедура обычно определяет следующее:

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

что должно быть подготовлено,

кто должен это подготовить,

когда это должно быть подготовлено,

критерии приемки.

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

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

4.

корректность,

правила построения,

возможности поддержки.

Контрольные списки рассматриваются коллегами их автора и потенциальными пользователями.

6. Действия, определенные в ходе экспертной оценки, отслеживаются до своего выполнения.

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

Операция 3 Запись данных о ходе и результатах экспертных оценок.

Примеры данных:

идентификация проверенного промежуточного программного продукта,

объем промежуточного программного продукта,

размер и состав группы экспертов,

время, выделенное каждому эксперту на подготовку к оценке,

продолжительность совещания по экспертной оценке,

типы и количество обнаруженных и устраненных дефектов,

трудоемкость доработки.

8. Календарные графики проекта разработки, включая определение ключевых точек и процедур проверки. 9. Идентификация и оценка рисков по выполнению проекта разработки.

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

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

См. описание Операции №4 группы ключевых процессов «Управление конфигурацией ПО».

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

Эта процедура обычно определяет следующие действия:

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

Примеры оценочного расчета объема ПО:

оценка по функциональным точкам,

по реализованным возможностям,

по количеству строк кода,

по количеству пунктов требований,

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

Примеры видов промежуточных продуктов и операций, для которых выполняются оценки объема:

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

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

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

операции по разработке, проверке и утверждению промежуточных продуктов.

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

3. По возможности, используются данные по результатам прошлых проектов.

4. Предположения по оценкам объема документируются.

5. Оценки объема документируются, проверяются и согласуются.

Примеры групп и отдельных сотрудников, в чьи обязанности входит проверка и согласование оценок объема:

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

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

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

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

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

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

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

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

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

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

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

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

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

Операция 9 Отслеживание технических операций по проекту разработки, при необходимости – применение корректирующих действий.

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

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

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

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

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

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

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

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

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

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

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

Операция 7 Регулярные проверки состояния работ и координационные совещания, проводимые совместно руководителями генерального подрядчика и субподрядчика.

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

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

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

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

2. Отклонения от требований выявляются, документируются и отслеживаются до их устранения. 3. Контролируется выполнение корректирующих действий.

Операция 5 Группа обеспечения качества проводит аудит определенных промежуточных программных продуктов на соответствие требованиям.

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

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

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

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

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

Эта процедура обычно определяет следующее:

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

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

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

4. Документация по вопросам несоответствий должна быть управляемой и контролируемой.

Операция 8 Группа обеспечения качества проводит регулярные обсуждения своих мероприятий и их результатов (по возможности – совместно с представителями заказчика по вопросам обеспечения качества).

Операция 6 Изменения базовых линий контролируются в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

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

2. Внесение в библиотеку базовых линий лишь тех элементов/блоков конфигурации, которые были утверждены комиссией SCCB.

3. Внесение и извлечение элементов/блоков конфигурации выполняется таким способом, который не нарушает корректность и целостность библиотеки базовых линий.

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

Операция 7 Создание продуктов на основе библиотеки базовых линий и контролирование их выпуска в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. Комиссия SCCB санкционирует создание продуктов на основе библиотеки базовых линий.

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

Операция 8 Запись статуса элементов/блоков конфигурации в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

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

2. Ведение текущего статуса и истории (т.е. истории изменений и других действий) для всех элементов/блоков конфигурации.

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

Примеры отчетов:

протоколы совещаний комиссии SCCB,

краткое описание и статус запроса на изменение,

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

См. группу ключевых процессов «Экспертные оценки».

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

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

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

1. Инструкции и критерии адаптации касаются следующих вопросов:

выбор и адаптация жизненного цикла ПО для проекта;

адаптация СППО с учетом жизненного цикла ПО и характеристик проекта;

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

Примеры адаптации:

адаптация процесса к новой линии продуктов или к среде разработки,

настройка процесса для конкретного проекта или класса проектов,

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

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

3. Документы, содержащие инструкции и критерии адаптации, должны быть управляемыми и контролируемыми.

Операция 5 Формирование и сопровождение базы данных производственного процесса организации (ППО).

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

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

3. Финансирование и ресурсы (включая персонал, инструменты и помещения), необходимые для подготовки и проведения обучения.

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

5. График создания и рассмотрения учебных курсов, которые будут разрабатываться группой обучения.

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

7. Описание следующих процедур:

отбор сотрудников для прохождения обучения,

регистрация слушателей и их участие в обучении,

ведение записей по проведенному обучению,

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

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

Эти стандарты содержат следующие требования:

1. Разработка описания для каждого учебного курса.

Примеры вопросов, раскрываемых в описании курса:

предполагаемая аудитория слушателей,

подготовка к участию в обучении,

цели обучения,

продолжительность обучения,

планы занятий,

критерии удовлетворительного прохождения обучения слушателями,

процедуры периодической оценки эффективности обучения,

специальные вопросы, такие как пробное и тестовое чтение курса,

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

2. Проверка материалов учебного курса.

Примеры сотрудников, проверяющих учебные материалы:

эксперты по обучению,

эксперты по предметным областям,

представители слушателей пробных чтений проверяемого курса.

3. Материалы учебного курса должны быть управляемы и контролируемы.

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

Операция 6 Ведение записей по проводимому обучению.

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

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

3. Сведения об успешном прохождении обучения используются при распределении задач между сотрудниками и менеджерами.

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

Производственный процесс проекта обычно содержит следующие указания:

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

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

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

4. Определяются документированные критерии момента необходимости перепланировки проекта.

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

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

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

7. В плане комплектования проекта персоналом определяются потребности проекта в сотрудниках с особыми навыками и знаниями в предметной области.

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

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

Примеры несоответствий и проблем:

различия в уровнях зрелости процессов,

несовместимость процессов,

Архитектура ПО состоит из системной архитектуры и архитектуры программы.

1. Создание и проверка критериев разработки архитектуры ПО.

Примеры критериев разработки архитектуры ПО:

возможность проверки,

соблюдение стандартов для архитектуры ПО,

удобство реализации,

простота,

удобство планирования реализации.

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

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

Примеры стандартов разработки приложений:

стандарты интерфейсов операционной системы,

стандарты пользовательских интерфейсов,

стандарты сетевых интерфейсов.

4. Для проектирования архитектуры ПО используются эффективные методы.

Примеры методов проектирования архитектуры ПО:

создание прототипов,

структурные модели,

повторное использование элементов архитектуры,

объектно-ориентированное проектирование,

системный анализ.

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

Системная архитектура описывает программную структуру верхнего уровня с четко определенными внутренними и внешними интерфейсами.

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

7. На основании системной архитектуры разрабатывается подробная архитектура программного комплекса.

8. Документируется описание архитектуры ПО (т. е. документируется собственно системная архитектура и детальная архитектура программы).

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

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

См.

Соглашение по каждой критической зависимости документируется, проверяется и утверждается как получающей группой, так и группой, ответственной за подготовку объекта критической зависимости.

5. Критические зависимости регулярно отслеживаются и в случае необходимости по отношению к ним применяются корректирующие действия.

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

Оценивается влияние позднего и досрочного выполнения обязательств на будущие работы и этапы.

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

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

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

Примеры межгрупповых проблем:

несовместимые календарные графики,

неадекватное финансирование,

технические риски,

дефекты системной архитектуры и требований,

проблемы системного уровня.

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

Участники этих проверок и совещаний решают следующие задачи:

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

2. Проверка хода технических работ проекта.

3. Проверка того, что группа интерпретирует и реализует технические требования в соответствии с системными требованиями.

4. Проверка выполнения обязательств.

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

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

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

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

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

Эта процедура обычно определяет следующее:

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

2. Для оценок по возможности используются данные по производительности (прошлых и/или текущих проектов). Источники и обоснования этих данных документируются.

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

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

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

расходы на зарплату,

накладные расходы,

командировочные расходы,

расходы на использование машинных ресурсов.

3. Оценки объема работ, потребности в персонале и затрат базируются на прежнем опыте.

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

Рассчитываются фазы операций по времени.

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

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

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

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

Эта процедура обычно определяет следующее:

1. Идентификация критических компьютерных ресурсов.

Примеры критических компьютерных ресурсов:

объем оперативной памяти,

требуемая мощность процессора,

пропускная способность каналов связи.

2.

Отчеты о проблемах отслеживаются до разрешения вопросов.

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

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

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

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

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

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

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

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

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

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

В этих проверках принимают участие:

1. Линейные менеджеры и подчиненные им ведущие специалисты.

2. Производственный менеджер проекта, линейные и другие производственные менеджеры по мере необходимости.

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

1. Проведение этих проверок планируется на какие-либо значимые моменты календарного графика проекта, такие как начало или завершение определенных стадий разработки.

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

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

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

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

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

6. В ходе проверок изучаются риски проекта разработки.

7. В случае необходимости, по результатам проверок уточняется план разработки ПО.

4. Рассматриваются критические зависимости и обязательства между разработчиками субподрядчика и его другими группами.

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

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

6. Рассматриваются несоответствия по договору о субподряде.

7. Рассматриваются проектные риски, связанные с субподрядной работой.

8. Изучаются конфликты и проблемы, которые субподрядчик не может решить самостоятельно.

9. Поручение и проверка корректирующих действий, а также отслеживание их выполнения.

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

Эти проверки:

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

2. Позволяют отслеживать технические операции субподрядчика.

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

4. Контролируют выполнение обязательств.

5. Контролируют своевременность решения технических проблем.

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

Эта процедура обычно определяет следующее:

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

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

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

4. Изучаются риски разработки.

5. По мере необходимости уточняется план субподрядчика по разработке ПО.

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

Эта процедура обычно определяет следующее:

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

краткое описание и статус отчета о проблемах (включая решения проблем),

краткое описание изменений базовых линий,

история изменений элементов/блоков конфигурации,

статус базовой линии конфигурации,

результаты аудитов базовых линий.

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

Эта процедура обычно определяет следующее:

1. Аудит должен быть подготовлен соответствующим образом.

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

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

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

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

6. Группа управления конфигурацией докладывает производственному менеджеру проекта о результатах аудита.

7. Действия, рекомендуемые по результатам аудита, отслеживаются до их завершения.

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

трудоемкости разработки и затрат;

фактические данные по объему ПО, трудоемкости разработки и затратам;

данные о производительности;

измерения качества ПО;

охват и эффективность экспертных оценок;

охват и эффективность тестирования;

меры по повышению надежности ПО;

количество и серьезность недостатков, обнаруженных в требованиях к ПО;

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

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

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

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

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

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

Операция 6 Формирование и сопровождение библиотеки документации по производственным процессам.

Примеры документации по производственным процессам:

описание производственного процесса проекта,

стандарты проекта,

процедуры проекта,

проектные планы разработки ПО,

проектные планы измерений,

учебные материалы по производственному процессу проекта.

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

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

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

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

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

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

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

тестирования ПО,

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

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

различные экономические факторы.

Операция 5 Использование базы данных ППО для планирования и оценочных расчетов для проекта разработки.

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

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

Примеры информации, содержащейся в базе данных ППО:

объем промежуточных программных продуктов,

трудоемкость разработки,

затраты на разработку,

календарный график,

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

технические работы.

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

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

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

записи обоснований достоверности оценочных расчетов проекта.

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

Примеры записываемой проектной информации:

описание задачи,

сделанные предположения,

оценочные расчеты,

пересмотренные оценки,

фактические данные измерений,

информация, необходимая для воспроизведения оценочных расчетов,

определения их обоснованности и выполнения аналогичных расчетов для новой работы.

Операция 6 Управление объемом промежуточных программных продуктов (или объемом их изменений) в соответствии с документированной процедурой.

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

группу ключевых процессов «Экспертные оценки».

10. Документ, описывающий архитектуру ПО, помещается в систему управления конфигурацией.

См. группу ключевых процессов «Управление конфигурацией ПО».

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

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

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

2. Для создания кода используются эффективные методы программирования. Примеры методов программирования: структурированное программирование, повторное использование кода.

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

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

См. группу ключевых процессов «Экспертные оценки».

5. Программный код помещается в систему управления конфигурацией.

См. группу ключевых процессов «Управление конфигурацией ПО».

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

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

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

2. Тестирование ПО осуществляется с помощью эффективных методов.

3. Адекватность тестирования определяется следующими факторами:

уровень выполняемого тестирования,

Примеры уровней тестирования:

модульное тестирование,

интеграционное тестирование,

системное тестирование,

приемочное тестирование.

На оценку критических компьютерных ресурсов влияют следующие оценки:

объем промежуточных программных продуктов,

рабочая нагрузка процессора,

интенсивность потока информации (трафик).

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

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

Эта процедура обычно определяет следующее:

1. График разработки, который зависит от:

оценки предполагаемого объема промежуточных программных продуктов (или объема их изменений),

объема работ и затрат по проекту.

2. Составление графика разработки базируется на прежнем опыте:

по возможности следует использовать подобные проекты.

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

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

5. Предположения, выдвинутые при создании графика, должны документироваться.

6. График разработки документируется, проверяется и согласуется.

Операция 13 Выявление, оценка и документирование рисков по проекту разработки, связанных с затратами, графиком и техническими аспектами проекта.

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

Примеры страховочных действий:

внесение в график резерва по времени;

создание альтернативных планов укомплектования персоналом;

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

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

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

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

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

компьютеры и периферийное оборудование для тестирования ПО,

целевая операционная среда,

другое вспомогательное ПО.

2. Распределение обязанностей и обсуждение соглашений по приобретению или разработке этих средств и инструментов.

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

Операция 15 Документирование данных по планированию разработки.

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

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

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

Группа обеспечения качества со стороны генерального подрядчика выборочно проверяет ход работ и продукты субподрядчика.

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

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

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

Эта процедура обычно определяет следующее:

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

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

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

Операция 12 В ходе процесса поставки программных продуктов, отданных на субподряд, генеральный подрядчик проводит их приемочное тестирование в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

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

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

3. Для любого программного продукта, не прошедшего приемочное тестирование, составляется план корректирующих действий.

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

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

Эта процедура обычно определяет следующее:

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

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

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

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

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

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

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

Оцениваются и документируются риски, связанные со снижением или устранением непредвиденности.

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

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

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

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

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

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

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

Операции №6 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

выбранная стратегия тестирования,

Примеры стратегий тестирования:

функциональная («черный ящик»),

структурная («прозрачный ящик»),

статистическая.

достигаемое тестовое покрытие,

Примеры тестового покрытия:

покрытие операторов,

покрытие путей,

покрытие ветвей,

профиль использования.

4. Для каждого уровня тестирования ПО устанавливаются и используются критерии готовности к тестированию.

Примеры критериев, определяющих готовность к тестированию:

до проведения интеграционного тестирования программные модули должны успешно пройти экспертную оценку и модульное тестирование,

для системного тестирования ПО должно прежде успешно пройти интеграционное тестирование, перед приемочным тестированием проводится проверка тестовой готовности.

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

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

См. группу ключевых процессов «Экспертные оценки».

7. Документы планов, процедур и сценариев тестирования должны быть управляемыми и контролируемыми.

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

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

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

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

Эта процедура обычно определяет следующее:

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

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

Примеры характеристик проекта:

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

объем и сложность системы,

стабильность требований,

хост-среда разработки,

целевая среда системы,

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

доступность ресурсов,

другие специфические ограничения.

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

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

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

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

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

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

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

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

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

Операция 7 Планирование и выполнение системного и приемочного тестирования ПО в целях демонстрации его соответствия требованиям.

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

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

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

Примеры работ по подготовке тестирования:

подготовка тестовой документации,

резервирование ресурсов для проведения тестирования,

разработка тестовых драйверов,

разработка симуляторов.

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

План тестирования раскрывает следующие вопросы:

общий подход к тестированию и проверке;

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

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

критерии приемки.

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

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

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

6. Проблемы, выявленные при тестировании, документируются и отслеживаются до устранения.

Эта процедура обычно определяет следующее:

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

Документируются источники и обоснования оценок.

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

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

2. Планируемые компьютерные ресурсы, системные требования, отнесенные к ПО, сами требования к ПО и/или архитектура ПО корректируются с учетом требований к критическим компьютерным ресурсам.

3. Доступные компьютерные ресурсы распределяются по компонентам ПО.

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

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

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

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

Эта процедура обычно определяет следующее:

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

Календарный график разработки идентифицирует конкретные задачи и этапы, чье завершение можно определить объективно (т. е. возможно бинарное определение в виде «да/нет»).

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

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

7. Результаты тестов документируются и используются для определения, насколько ПО соответствует выдвинутым к нему требованиям. 8. Документы результатов тестирования должны быть управляемыми и контролируемыми.

Операция 8 Документация, используемая при эксплуатации и поддержке ПО, разрабатывается и ведется в соответствии с производственным процессом проекта.

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

Примеры методов и инструментов:

использование текстовых процессоров,

изучение сценариев,

повторное использование документации.

2. Специалисты по созданию документации принимают активное участие в планировании, разработке и ведении документации.

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

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

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

5. Документация подвергается экспертной оценке. См. группу ключевых процессов «Экспертные оценки».

6. Документация должна быть управляемой и контролируемой.

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

Операция 9 Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта.

Примеры собираемых и анализируемых данных:

описание дефекта,

категория дефекта,

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

Критические зависимости могут возникать как внутри группы разработки ПО (т. е. между подгруппами), так и между группой разработки и другими задействованными группами.

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

Примеры принимаемых мер:

анализ и моделирование компромиссных вариантов функций, качества, затрат, графика, персонала и других ресурсов;

определение страховочных действий и, по возможности, внесение резерва времени в график;

оценка влияния предполагаемых действий на все критические зависимости;

распространение информации о принятых решениях между всеми задействованными группами.

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

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

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

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

серьезность дефекта,

модули, содержащие дефект,

модули, подверженные влиянию дефекта,

операция, в которой проявился дефект,

экспертная оценка или тестовые сценарии, выявившие дефект,

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

ожидаемые и фактические результаты, выявляющие дефект.

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

1. Промежуточные программные продукты документируются, а к созданной документации имеется постоянный доступ.

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

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

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

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

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

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

Задействованные группы информируются об изменениях и участвуют в их обсуждении.

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

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

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

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

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

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

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

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

Изменения отслеживаются до своей реализации.

Эта процедура обычно определяет следующее:

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

Примеры вопросов, рассматриваемых в плане управления рисками:

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

методы управления рисками (т. е. выявление, анализ, определение приоритетов, планирование, мониторинг и устранение);

список выявленных рисков (включая оценку, приоритет, статус и планируемые действия);

график управления рисками;

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

измерения.

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

Примеры областей, в которых проводится планирование страховочных действий:

определение вариантов,

оценка влияния вариантов,

техническая осуществимость вариантов,

распределение резервов управления,

критерии принятия решений о реализации вариантов.

3. Для каждого риска разработки, по возможности, определяются альтернативные решения и критерии выбора альтернатив.

4. Первый вариант и основные изменения плана по управлению рисками проходят экспертную оценку.

См. группу ключевых процессов «Экспертные оценки».

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

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

При проведении этих переоценок проверяются и пересматриваются приоритеты рисков и планы по управлению рисками.

Информация, полученная при отслеживании рисков, используется для уточнения оценок рисков и планов по управлению рисками.

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

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

заказчик,

субподрядчики,

конечные пользователи,

группа оценки объема составляющих проекта,

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

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

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

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

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

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

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

Примеры действий:

ужесточение календарного графика,

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

прекращение проекта.

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

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