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

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

Операция 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. Для единообразной идентификации критериев конкретной оценки используются контрольные списки.

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

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

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

полнота,

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