Предпосылка 2. Вспомогательные средства, используемые различными инженерными группами, должны быть совместимы и обеспечивать эффективный обмен информацией и координацию действий.
Примеры вспомогательных инструментальных средств, которые должны быть совместимыми:
текстовые процессоры,
системы управления базами данных,
графические инструменты,
электронные таблицы,
средства для отслеживания проблем,
инструменты управления библиотекой.
Предпосылка 3. Все менеджеры организации должны пройти необходимое обучение принципам коллективной работы.
Примеры тем учебных занятий:
формирование групп;
управление группами;
установление, стимулирование коллективной работы и содействие ей;
групповая динамика.
См. группу ключевых процессов «Программа обучения».
Предпосылка 4. Все ведущие специалисты каждой инженерной группы должны получить ориентацию в процессах, методах и стандартах, используемых в остальных инженерных группах.
См. группу ключевых процессов «Программа обучения».
Предпосылка 5. Члены инженерных групп должны получить ориентацию в принципах коллективной работы.
См. группу ключевых процессов «Программа обучения».
Выполняемые операции
Измерения и анализ
Проверка внедрения
9.7. Экспертные оценки
Цели
Обязательства по выполнению
Необходимые предпосылки
Выполняемые операции
Измерения и анализ
Проверка внедрения
ПРИЛОЖЕНИЕ
ЦЕЛИ КАЖДОЙ ГРУППЫ КЛЮЧЕВЫХ ПРОЦЕССОВ
1. Группы ключевых процессов для уровня 2: повторяемый уровень
Планирование проекта
Отслеживание хода проекта и контроль над ним
Управление производственным субподрядом
Обеспечение качества ПО
Управление конфигурацией ПО
2. Группы ключевых процессов для уровня 3: определенный уровень
Определение производственного процесса организации
Программа обучения
Интегрированное управление разработкой ПО
Инженерия разработки программного продукта
Межгрупповая координация
Экспертные оценки
3. Группы ключевых процессов для уровня 4: управляемый уровень
Управление качеством ПО
4. Группы ключевых процессов для уровня 5: оптимизирующий уровень
Управление технологическими изменениями
Управление изменениями процесса
ССЫЛКИ НА ИСПОЛЬЗУЕМУЮ ЛИТЕРАТУРУ
Примеры вспомогательных инструментальных средств, которые должны быть совместимыми:
текстовые процессоры,
системы управления базами данных,
графические инструменты,
электронные таблицы,
средства для отслеживания проблем,
инструменты управления библиотекой.
Предпосылка 3. Все менеджеры организации должны пройти необходимое обучение принципам коллективной работы.
Примеры тем учебных занятий:
формирование групп;
управление группами;
установление, стимулирование коллективной работы и содействие ей;
групповая динамика.
См. группу ключевых процессов «Программа обучения».
Предпосылка 4. Все ведущие специалисты каждой инженерной группы должны получить ориентацию в процессах, методах и стандартах, используемых в остальных инженерных группах.
См. группу ключевых процессов «Программа обучения».
Предпосылка 5. Члены инженерных групп должны получить ориентацию в принципах коллективной работы.
См. группу ключевых процессов «Программа обучения».
Выполняемые операции
Операция 1. Группа разработки ПО и другие инженерные группы сотрудничают с заказчиком и, при необходимости, конечными пользователями в целях установления системных требований.
Эти группы выполняют следующие операции:
1. Определение критических характеристик в требованиях заказчика и, при необходимости, конечных пользователей.
2. Обсуждение критических зависимостей.
3. Документирование критериев приемки каждого продукта, поставляемого заказчику или конечным пользователям.
Операция 2. Представители разработчиков совместно с представителями других инженерных групп отслеживают и координируют выполнение технических работ и решают технические вопросы.
1. Для отслеживания и координации выполнения технических работ представители этих групп проводят следующие мероприятия:
координация спецификаций, участие в технических обзорах и утверждении системных требований и архитектуры;
Системные требования и архитектура обычно входят в сферу ответственности группы системного проектирования, но предполагается, что в этих работах будут также принимать активное участие представители других инженерных групп.
В состав системных требований и архитектуры входит следующее:
общие системные требования,
системная конфигурация (т. е. аппаратное и программное обеспечение, другие системные компоненты),
распределение и отслеживание требований к этим системным компонентам,
определения интерфейсов между этими системными компонентами.
выполнение технических проверок и анализа на уровне проекта, необходимых для управления и контроля над изменениями системных требований и целей проекта на протяжении всего его жизненного цикла;
отслеживание и проверка операций по проектированию и разработке аппаратного обеспечения, ПО и других системных компонентов;
оценка, разработка соответствующих рекомендаций и отслеживание технических рисков, касающихся нескольких инженерных групп одновременно.
Практики, связанные с управлением рисками, содержатся в описании Операции № 10 группы ключевых процессов «Интегрированное управление разработкой ПО».
2. Представители групп прорабатывают технические вопросы следующим образом:
решение конфликтов проектного уровня и выяснение вопросов, касающихся системных требований и архитектуры;
разработка совместных рекомендаций для решения проблем;
изучение вопросов, касающихся организации процессов и затрагивающих все инженерные группы проекта.
Операция 3. Для обмена информацией о межгрупповых обязательствах, а также для координации и отслеживания выполняемой работы используется документированный план.
1. Данный план является базовой линией для:
календарного графика проекта,
договорных и технических аспектов проекта,
распределения обязанностей между инженерными группами.
2. План используется для координации действий различных инженерных групп.
3. План доступен для членов всех инженерных групп.
4. При обновлении плана учитываются все межгрупповые обязательства и изменения этих обязательств.
5. План обновляется по мере выполнения работ, отражая ход проекта и изменения его планов; в частности при завершении основных этапов проекта или значительных изменениях планов.
6. План рассматривается и утверждается всеми инженерными группами и менеджером проекта.
Операция 4. Критические зависимости между инженерными группами выявляются, обсуждаются и отслеживаются в соответствии с документированной процедурой.
Практики, связанные с управлением критическими зависимостями, содержатся в описании Операции № 9 группы ключевых процессов «Интегрированное управление разработкой ПО».
Эта процедура обычно определяет следующее:
1. Каждая критическая зависимость должна быть явно определена, включая следующее:
что должно быть подготовлено,
кто должен это подготовить,
когда это должно быть подготовлено,
критерии приемки.
2. Критические зависимости обсуждаются группой разработки ПО совместно с другими инженерными группами проекта и организации.
3. Даты потребности и доступности объектов критической зависимости связываются с календарными графиками проекта и процесса разработки.
4. Соглашение по каждой критической зависимости документируется, проверяется и утверждается как получающей группой, так и группой, ответственной за подготовку объекта критической зависимости.
5. Критические зависимости регулярно отслеживаются и в случае необходимости по отношению к ним применяются корректирующие действия.
Статус и даты фактического или ожидаемого выполнения этих обязательств сравниваются с планом, используемым для координации межгрупповых обязательств.
Оценивается влияние позднего и досрочного выполнения обязательств на будущие работы и этапы.
Отчеты о возникших и потенциальных проблемах передаются соответствующим менеджерам.
Операция 5. Представители групп, получающих промежуточные продукты в качестве исходных данных, проверяют их, чтобы убедиться в соответствии этих продуктов своим потребностям.
Операция 6. Межгрупповые проблемы, не решаемые отдельными представителями инженерных групп проекта, рассматриваются в соответствии с документированной процедурой.
Примеры межгрупповых проблем:
несовместимые календарные графики,
неадекватное финансирование,
технические риски,
дефекты системной архитектуры и требований,
проблемы системного уровня.
Операция 7. Представители инженерных групп проекта периодически проводят технические проверки и совещания по обмену информацией.
Участники этих проверок и совещаний решают следующие задачи:
1. Выяснение потребностей и запросов заказчика и, при необходимости, конечных пользователей.
2. Проверка хода технических работ проекта.
3. Проверка того, что группа интерпретирует и реализует технические требования в соответствии с системными требованиями.
4. Проверка выполнения обязательств.
Практики, связанные с проверками, содержатся в группе ключевых процессов «Отслеживание хода проекта и контроль над ним».
5. Обсуждение технических рисков и других технических проблем. Практики, связанные с управлением рисками, содержатся в описании
Операции № 10 группы ключевых процессов «Интегрированное управление разработкой ПО».
Эти группы выполняют следующие операции:
1. Определение критических характеристик в требованиях заказчика и, при необходимости, конечных пользователей.
2. Обсуждение критических зависимостей.
3. Документирование критериев приемки каждого продукта, поставляемого заказчику или конечным пользователям.
Операция 2. Представители разработчиков совместно с представителями других инженерных групп отслеживают и координируют выполнение технических работ и решают технические вопросы.
1. Для отслеживания и координации выполнения технических работ представители этих групп проводят следующие мероприятия:
координация спецификаций, участие в технических обзорах и утверждении системных требований и архитектуры;
Системные требования и архитектура обычно входят в сферу ответственности группы системного проектирования, но предполагается, что в этих работах будут также принимать активное участие представители других инженерных групп.
В состав системных требований и архитектуры входит следующее:
общие системные требования,
системная конфигурация (т. е. аппаратное и программное обеспечение, другие системные компоненты),
распределение и отслеживание требований к этим системным компонентам,
определения интерфейсов между этими системными компонентами.
выполнение технических проверок и анализа на уровне проекта, необходимых для управления и контроля над изменениями системных требований и целей проекта на протяжении всего его жизненного цикла;
отслеживание и проверка операций по проектированию и разработке аппаратного обеспечения, ПО и других системных компонентов;
оценка, разработка соответствующих рекомендаций и отслеживание технических рисков, касающихся нескольких инженерных групп одновременно.
Практики, связанные с управлением рисками, содержатся в описании Операции № 10 группы ключевых процессов «Интегрированное управление разработкой ПО».
2. Представители групп прорабатывают технические вопросы следующим образом:
решение конфликтов проектного уровня и выяснение вопросов, касающихся системных требований и архитектуры;
разработка совместных рекомендаций для решения проблем;
изучение вопросов, касающихся организации процессов и затрагивающих все инженерные группы проекта.
Операция 3. Для обмена информацией о межгрупповых обязательствах, а также для координации и отслеживания выполняемой работы используется документированный план.
1. Данный план является базовой линией для:
календарного графика проекта,
договорных и технических аспектов проекта,
распределения обязанностей между инженерными группами.
2. План используется для координации действий различных инженерных групп.
3. План доступен для членов всех инженерных групп.
4. При обновлении плана учитываются все межгрупповые обязательства и изменения этих обязательств.
5. План обновляется по мере выполнения работ, отражая ход проекта и изменения его планов; в частности при завершении основных этапов проекта или значительных изменениях планов.
6. План рассматривается и утверждается всеми инженерными группами и менеджером проекта.
Операция 4. Критические зависимости между инженерными группами выявляются, обсуждаются и отслеживаются в соответствии с документированной процедурой.
Практики, связанные с управлением критическими зависимостями, содержатся в описании Операции № 9 группы ключевых процессов «Интегрированное управление разработкой ПО».
Эта процедура обычно определяет следующее:
1. Каждая критическая зависимость должна быть явно определена, включая следующее:
что должно быть подготовлено,
кто должен это подготовить,
когда это должно быть подготовлено,
критерии приемки.
2. Критические зависимости обсуждаются группой разработки ПО совместно с другими инженерными группами проекта и организации.
3. Даты потребности и доступности объектов критической зависимости связываются с календарными графиками проекта и процесса разработки.
4. Соглашение по каждой критической зависимости документируется, проверяется и утверждается как получающей группой, так и группой, ответственной за подготовку объекта критической зависимости.
5. Критические зависимости регулярно отслеживаются и в случае необходимости по отношению к ним применяются корректирующие действия.
Статус и даты фактического или ожидаемого выполнения этих обязательств сравниваются с планом, используемым для координации межгрупповых обязательств.
Оценивается влияние позднего и досрочного выполнения обязательств на будущие работы и этапы.
Отчеты о возникших и потенциальных проблемах передаются соответствующим менеджерам.
Операция 5. Представители групп, получающих промежуточные продукты в качестве исходных данных, проверяют их, чтобы убедиться в соответствии этих продуктов своим потребностям.
Операция 6. Межгрупповые проблемы, не решаемые отдельными представителями инженерных групп проекта, рассматриваются в соответствии с документированной процедурой.
Примеры межгрупповых проблем:
несовместимые календарные графики,
неадекватное финансирование,
технические риски,
дефекты системной архитектуры и требований,
проблемы системного уровня.
Операция 7. Представители инженерных групп проекта периодически проводят технические проверки и совещания по обмену информацией.
Участники этих проверок и совещаний решают следующие задачи:
1. Выяснение потребностей и запросов заказчика и, при необходимости, конечных пользователей.
2. Проверка хода технических работ проекта.
3. Проверка того, что группа интерпретирует и реализует технические требования в соответствии с системными требованиями.
4. Проверка выполнения обязательств.
Практики, связанные с проверками, содержатся в группе ключевых процессов «Отслеживание хода проекта и контроль над ним».
5. Обсуждение технических рисков и других технических проблем. Практики, связанные с управлением рисками, содержатся в описании
Операции № 10 группы ключевых процессов «Интегрированное управление разработкой ПО».
Измерения и анализ
Измерение 1. Выполнение измерений и использование их результатов для определения статуса мероприятий по межгрупповой координации.
Примеры фактических измерений:
объем трудозатрат и других ресурсов, израсходованных разработчиками на поддержку других инженерных групп;
объем трудозатрат и других ресурсов, израсходованных другими инженерными группами на поддержку группы разработки ПО;
выполнение конкретных задач и этапов разработчиками в целях поддержки деятельности других инженерных групп;
выполнение конкретных задач и этапов другими инженерными группами в целях поддержки деятельности группы разработки ПО.
Примеры фактических измерений:
объем трудозатрат и других ресурсов, израсходованных разработчиками на поддержку других инженерных групп;
объем трудозатрат и других ресурсов, израсходованных другими инженерными группами на поддержку группы разработки ПО;
выполнение конкретных задач и этапов разработчиками в целях поддержки деятельности других инженерных групп;
выполнение конкретных задач и этапов другими инженерными группами в целях поддержки деятельности группы разработки ПО.
Проверка внедрения
Проверка 1. Регулярная проверка высшим руководством выполнения мероприятий по межгрупповой координации.
Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 2. Регулярные и событийные проверки менеджером проекта мероприятий по межгрупповой координации.
Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 3. Проведение группой обеспечения качества (группой SQA) проверок и/или аудитов работ и промежуточных продуктов по межгрупповой координации и выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО». Сфера ответственности по обеспечению качества для этой группы ключевых процессов может быть представлена функцией SQA, выполняемой всеми инженерными группами проекта.
Минимальное содержание проверок и/или аудитов:
1. Процедура выявления, обсуждения и отслеживания критических зависимостей между инженерными группами проекта.
2. Управление межгрупповыми проблемами.
Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 2. Регулярные и событийные проверки менеджером проекта мероприятий по межгрупповой координации.
Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 3. Проведение группой обеспечения качества (группой SQA) проверок и/или аудитов работ и промежуточных продуктов по межгрупповой координации и выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО». Сфера ответственности по обеспечению качества для этой группы ключевых процессов может быть представлена функцией SQA, выполняемой всеми инженерными группами проекта.
Минимальное содержание проверок и/или аудитов:
1. Процедура выявления, обсуждения и отслеживания критических зависимостей между инженерными группами проекта.
2. Управление межгрупповыми проблемами.
9.7. Экспертные оценки
Группа ключевых процессов для уровня 3: определенный уровень
Цель группы ключевых процессов «Экспертные оценки» заключается в эффективном устранении дефектов в промежуточных программных продуктах на ранних стадиях разработки. Важным следствием этой практики является улучшение понимания промежуточных программных продуктов и дефектов, которые могут быть предотвращены.
Экспертные оценки включают в себя систематическое изучение промежуточных программных продуктов, проводимое экспертами-разработчиками в целях выявления дефектов и областей, в которые следует внести изменения. Конкретные продукты, подлежащие экспертной оценке, определяются в документе производственного процесса проекта, а их оценка планируется в составе мероприятий по планированию проекта разработки, как это описано в группе ключевых процессов «Интегрированное управление разработкой ПО».
Эта группа ключевых процессов охватывает практики, связанные с выполнением экспертных оценок. Практики, определяющие конкретные промежуточные продукты, подлежащие экспертной оценке, содержатся в группах ключевых процессов, которые описывают разработку и сопровождение каждого промежуточного программного продукта.
Цель группы ключевых процессов «Экспертные оценки» заключается в эффективном устранении дефектов в промежуточных программных продуктах на ранних стадиях разработки. Важным следствием этой практики является улучшение понимания промежуточных программных продуктов и дефектов, которые могут быть предотвращены.
Экспертные оценки включают в себя систематическое изучение промежуточных программных продуктов, проводимое экспертами-разработчиками в целях выявления дефектов и областей, в которые следует внести изменения. Конкретные продукты, подлежащие экспертной оценке, определяются в документе производственного процесса проекта, а их оценка планируется в составе мероприятий по планированию проекта разработки, как это описано в группе ключевых процессов «Интегрированное управление разработкой ПО».
Эта группа ключевых процессов охватывает практики, связанные с выполнением экспертных оценок. Практики, определяющие конкретные промежуточные продукты, подлежащие экспертной оценке, содержатся в группах ключевых процессов, которые описывают разработку и сопровождение каждого промежуточного программного продукта.
Цели
Цель 1. Планирование работ по проведению экспертных оценок.
Цель 2. Выявление и устранение дефектов в промежуточных программных продуктах.
Цель 2. Выявление и устранение дефектов в промежуточных программных продуктах.
Обязательства по выполнению
Обязательство 1. Проект следует документированной организационной политике проведения экспертных оценок.
Эта политика обычно состоит из следующих положений:
1. Организация определяет стандартный набор промежуточных программных продуктов, подвергаемых экспертной оценке.
2. Для каждого проекта определяются промежуточные программные продукты, подвергаемые экспертной оценке.
Практики, связанные с выявлением программных продуктов, подвергаемых экспертной оценке, содержатся в описании Операции № 1 группы ключевых процессов «Интегрированное управление разработкой ПО» и Операции № 2 группы ключевых процессов «Определение производственного процесса организации».
Примеры промежуточных программных продуктов:
системное ПО и вспомогательные программы,
промежуточные программные продукты, как предназначенные для поставки заказчику, так и внутреннего пользования,
программные (например, код) и непрограммные промежуточные продукты (например, документы),
описания процессов.
3. Экспертные оценки проводятся под руководством ведущих экспертов, опытных в их проведении.
4. Экспертные оценки фокусируются не на разработчике, а на проверяемом промежуточном программном продукте.
5. Результаты экспертных оценок не должны использоваться руководством для оценки работы сотрудников.
Эта политика обычно состоит из следующих положений:
1. Организация определяет стандартный набор промежуточных программных продуктов, подвергаемых экспертной оценке.
2. Для каждого проекта определяются промежуточные программные продукты, подвергаемые экспертной оценке.
Практики, связанные с выявлением программных продуктов, подвергаемых экспертной оценке, содержатся в описании Операции № 1 группы ключевых процессов «Интегрированное управление разработкой ПО» и Операции № 2 группы ключевых процессов «Определение производственного процесса организации».
Примеры промежуточных программных продуктов:
системное ПО и вспомогательные программы,
промежуточные программные продукты, как предназначенные для поставки заказчику, так и внутреннего пользования,
программные (например, код) и непрограммные промежуточные продукты (например, документы),
описания процессов.
3. Экспертные оценки проводятся под руководством ведущих экспертов, опытных в их проведении.
4. Экспертные оценки фокусируются не на разработчике, а на проверяемом промежуточном программном продукте.
5. Результаты экспертных оценок не должны использоваться руководством для оценки работы сотрудников.
Необходимые предпосылки
Предпосылка 1. Проведение экспертных оценок каждого проверяемого промежуточного программного продукта должно быть обеспечено соответствующими ресурсами и финансированием.
Ресурсы и финансирование предоставляются для выполнения следующих операций:
1. Подготовка и распространение материалов экспертной оценки.
2. Руководство проведением экспертной оценки.
3. Рассмотрение материалов.
4. Участие сотрудников в экспертной оценке и в любых последующих проверках, которые могут потребоваться на основании дефектов, выявленных в ходе экспертной оценки.
5. Отслеживание доработки промежуточного программного продукта, устраняющей дефекты, выявленные в ходе экспертной оценки.
6. Сбор сведений и составление отчетов по результатам экспертных оценок.
Предпосылка 2. Ведущие эксперты должны пройти необходимое обучение руководству экспертными оценками.
Примеры тем учебных занятий:
цели, принципы и методы экспертных оценок;
планирование и организация экспертной оценки;
критерии готовности к экспертной оценке и ее завершения;
проведение экспертной оценки;
отчетность по результатам экспертной оценки;
отслеживание и подтверждение выполнения доработки по результатам экспертной оценки; сбор данных, необходимых для экспертных оценок.
См. группу ключевых процессов «Программа обучения».
Предпосылка 3 Участники экспертных оценок должны пройти необходимое обучение целям, принципам и методам экспертных оценок.
Примеры тем учебных занятий:
типы экспертных оценок (например, проверки требований к ПО, архитектуры ПО, кода и процедур тестирования ПО);
цели, принципы и методы экспертных оценок;
роли экспертов; определение трудоемкости подготовки и проведения экспертных оценок.
См. группу ключевых процессов «Программа обучения».
Ресурсы и финансирование предоставляются для выполнения следующих операций:
1. Подготовка и распространение материалов экспертной оценки.
2. Руководство проведением экспертной оценки.
3. Рассмотрение материалов.
4. Участие сотрудников в экспертной оценке и в любых последующих проверках, которые могут потребоваться на основании дефектов, выявленных в ходе экспертной оценки.
5. Отслеживание доработки промежуточного программного продукта, устраняющей дефекты, выявленные в ходе экспертной оценки.
6. Сбор сведений и составление отчетов по результатам экспертных оценок.
Предпосылка 2. Ведущие эксперты должны пройти необходимое обучение руководству экспертными оценками.
Примеры тем учебных занятий:
цели, принципы и методы экспертных оценок;
планирование и организация экспертной оценки;
критерии готовности к экспертной оценке и ее завершения;
проведение экспертной оценки;
отчетность по результатам экспертной оценки;
отслеживание и подтверждение выполнения доработки по результатам экспертной оценки; сбор данных, необходимых для экспертных оценок.
См. группу ключевых процессов «Программа обучения».
Предпосылка 3 Участники экспертных оценок должны пройти необходимое обучение целям, принципам и методам экспертных оценок.
Примеры тем учебных занятий:
типы экспертных оценок (например, проверки требований к ПО, архитектуры ПО, кода и процедур тестирования ПО);
цели, принципы и методы экспертных оценок;
роли экспертов; определение трудоемкости подготовки и проведения экспертных оценок.
См. группу ключевых процессов «Программа обучения».
Выполняемые операции
Операция 1. Экспертные оценки проводятся на плановой основе, а планы документируются.
Эти планы определяют:
1. Промежуточные программные продукты, подлежащие экспертной оценке.
В перечень выбранных промежуточных программных продуктов входит набор, определенный в стандартном производственном процессе организации.
Практики, связанные со стандартным производственным процессом организации, содержатся в описании Операции № 2 группы ключевых процессов «Определение производственного процесса организации».
2. Календарный график проведения экспертных оценок. Для проведения каждой экспертной оценки, запланированной на ближайшее будущее, определяется обученный ведущий эксперт и остальные эксперты.
Операция 2. Проведение экспертных оценок в соответствии с документированной процедурой.
Эта процедура обычно определяет следующее:
1. Экспертные оценки планируются обученными ведущими экспертами и проводятся под их руководством.
2. Эксперты должны получить предварительные материалы для проведения оценок заранее, чтобы они смогли к ним соответствующе подготовиться.
Предварительные материалы оценок должны включать в себя соответствующую исходную информацию для разработки промежуточного программного продукта, подлежащего проверке.
Примеры соответствующей исходной информации:
цели промежуточного программного продукта,
применяемые стандарты,
соответствующие требования к архитектурному модулю,
детальная архитектура модуля программного кода.
3. Участникам экспертной оценки назначаются роли.
4. Определяются критерии готовности к экспертным оценкам и их завершения, подлежащие строгому соблюдению.
Вопросы, связанные с несоответствием этим критериям, докладываются соответствующим менеджерам.
5. Для единообразной идентификации критериев конкретной оценки используются контрольные списки.
Контрольные списки адаптируются к конкретному типу промежуточного продукта и экспертной оценки.
Примеры адаптируемых пунктов контрольных списков:
соответствие стандартам и процедурам,
полнота,
корректность,
правила построения,
возможности поддержки.
Контрольные списки рассматриваются коллегами их автора и потенциальными пользователями.
6. Действия, определенные в ходе экспертной оценки, отслеживаются до своего выполнения.
7. Успешное завершение экспертных оценок, включая доработку выявленных недостатков, используется в качестве критерия завершения для соответствующей задачи.
Операция 3. Запись данных о ходе и результатах экспертных оценок.
Примеры данных:
идентификация проверенного промежуточного программного продукта,
объем промежуточного программного продукта,
размер и состав группы экспертов,
время, выделенное каждому эксперту на подготовку к оценке,
продолжительность совещания по экспертной оценке,
типы и количество обнаруженных и устраненных дефектов,
трудоемкость доработки.
Эти планы определяют:
1. Промежуточные программные продукты, подлежащие экспертной оценке.
В перечень выбранных промежуточных программных продуктов входит набор, определенный в стандартном производственном процессе организации.
Практики, связанные со стандартным производственным процессом организации, содержатся в описании Операции № 2 группы ключевых процессов «Определение производственного процесса организации».
2. Календарный график проведения экспертных оценок. Для проведения каждой экспертной оценки, запланированной на ближайшее будущее, определяется обученный ведущий эксперт и остальные эксперты.
Операция 2. Проведение экспертных оценок в соответствии с документированной процедурой.
Эта процедура обычно определяет следующее:
1. Экспертные оценки планируются обученными ведущими экспертами и проводятся под их руководством.
2. Эксперты должны получить предварительные материалы для проведения оценок заранее, чтобы они смогли к ним соответствующе подготовиться.
Предварительные материалы оценок должны включать в себя соответствующую исходную информацию для разработки промежуточного программного продукта, подлежащего проверке.
Примеры соответствующей исходной информации:
цели промежуточного программного продукта,
применяемые стандарты,
соответствующие требования к архитектурному модулю,
детальная архитектура модуля программного кода.
3. Участникам экспертной оценки назначаются роли.
4. Определяются критерии готовности к экспертным оценкам и их завершения, подлежащие строгому соблюдению.
Вопросы, связанные с несоответствием этим критериям, докладываются соответствующим менеджерам.
5. Для единообразной идентификации критериев конкретной оценки используются контрольные списки.
Контрольные списки адаптируются к конкретному типу промежуточного продукта и экспертной оценки.
Примеры адаптируемых пунктов контрольных списков:
соответствие стандартам и процедурам,
полнота,
корректность,
правила построения,
возможности поддержки.
Контрольные списки рассматриваются коллегами их автора и потенциальными пользователями.
6. Действия, определенные в ходе экспертной оценки, отслеживаются до своего выполнения.
7. Успешное завершение экспертных оценок, включая доработку выявленных недостатков, используется в качестве критерия завершения для соответствующей задачи.
Операция 3. Запись данных о ходе и результатах экспертных оценок.
Примеры данных:
идентификация проверенного промежуточного программного продукта,
объем промежуточного программного продукта,
размер и состав группы экспертов,
время, выделенное каждому эксперту на подготовку к оценке,
продолжительность совещания по экспертной оценке,
типы и количество обнаруженных и устраненных дефектов,
трудоемкость доработки.
Измерения и анализ
Измерение 1. Выполнение измерений и использование их результатов для определения статуса работ по проведению экспертных оценок.
Примеры измерений:
количество выполненных экспертных оценок в сравнении с планом,
общая трудоемкость выполненных экспертных оценок в сравнении с планом,
количество проверенных промежуточных продуктов в сравнении с планом.
Примеры измерений:
количество выполненных экспертных оценок в сравнении с планом,
общая трудоемкость выполненных экспертных оценок в сравнении с планом,
количество проверенных промежуточных продуктов в сравнении с планом.
Проверка внедрения
Проверка 1. Проведение группой обеспечения качества (SQA) проверок и/или аудитов работ и промежуточных продуктов, связанных с экспертными оценками, и выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО».
Минимальное содержание этих проверок и/или аудитов:
1. Проведение запланированных экспертных оценок.
2. Адекватное обучение ведущих экспертов для выполнения их ролей.
3. Полученное обучение или наличие опыта в выполнении своих ролей у экспертов.
4. Следование процессу подготовки, проведения экспертных оценок и выполнения действий по их результатам.
5. Своевременная подача полных и точных отчетов по результатам экспертных оценок.
См. группу ключевых процессов «Обеспечение качества ПО».
Минимальное содержание этих проверок и/или аудитов:
1. Проведение запланированных экспертных оценок.
2. Адекватное обучение ведущих экспертов для выполнения их ролей.
3. Полученное обучение или наличие опыта в выполнении своих ролей у экспертов.
4. Следование процессу подготовки, проведения экспертных оценок и выполнения действий по их результатам.
5. Своевременная подача полных и точных отчетов по результатам экспертных оценок.
ПРИЛОЖЕНИЕ
ЦЕЛИ КАЖДОЙ ГРУППЫ КЛЮЧЕВЫХ ПРОЦЕССОВ
Ниже перечислены цели всех групп ключевых процессов по уровням зрелости.
1. Группы ключевых процессов для уровня 2: повторяемый уровень
Управление требованиями
Цель 1. Установление контроля над системными требованиями к ПО в целях формирования базовой линии, используемой разработчиками ПО и руководством проекта.
Цель 2. Поддержка согласованности планов разработки, продуктов и операций с системными требованиями, отнесенными к ПО.
Цель 2. Поддержка согласованности планов разработки, продуктов и операций с системными требованиями, отнесенными к ПО.
Планирование проекта
Цель 1. Документирование оценочных расчетов по компонентам проекта для их дальнейшего использования в планировании и отслеживании проекта разработки.
Цель 2. Планирование и документирование работ и обязательств по проекту разработки.
Цель 3. Принятие задействованными в проекте группами и сотрудниками обязательств, связанных с проектом разработки ПО.
Цель 2. Планирование и документирование работ и обязательств по проекту разработки.
Цель 3. Принятие задействованными в проекте группами и сотрудниками обязательств, связанных с проектом разработки ПО.
Отслеживание хода проекта и контроль над ним
Цель 1. Сравнение фактических результатов и показателей с запланированными.
Цель 2. В случае значительного отклонения фактических результатов и показателей от запланированных — применение корректирующих действий и контроль над их выполнением.
Цель 3. Согласование изменений производственных обязательств с задействованными группами и сотрудниками.
Цель 2. В случае значительного отклонения фактических результатов и показателей от запланированных — применение корректирующих действий и контроль над их выполнением.
Цель 3. Согласование изменений производственных обязательств с задействованными группами и сотрудниками.
Управление производственным субподрядом
Цель 1. Выбор генеральным подрядчиком квалифицированных субподрядчиков.
Цель 2. Заключение соглашения о взаимных обязательствах между генеральным подрядчиком и субподрядчиком.
Цель 3. Поддержка постоянного обмена информацией между генеральным подрядчиком и субподрядчиком.
Цель 4. Отслеживание генеральным подрядчиком фактических результатов работы и производительности субподрядчика относительно принятых им обязательств.
Цель 2. Заключение соглашения о взаимных обязательствах между генеральным подрядчиком и субподрядчиком.
Цель 3. Поддержка постоянного обмена информацией между генеральным подрядчиком и субподрядчиком.
Цель 4. Отслеживание генеральным подрядчиком фактических результатов работы и производительности субподрядчика относительно принятых им обязательств.
Обеспечение качества ПО
Цель 1. Планирование работ по обеспечению качества ПО.
Цель 2. Объективная проверка соответствия программных продуктов и технологических операций применяемым стандартам, процедурам и требованиям.
Цель 3. Распространение информации между задействованными в проекте группами и сотрудниками о мероприятиях по обеспечению качества ПО и их результатах.
Цель 4. Передача на рассмотрение высшему руководству вопросов несоответствия, не решаемых на уровне проекта.
Цель 2. Объективная проверка соответствия программных продуктов и технологических операций применяемым стандартам, процедурам и требованиям.
Цель 3. Распространение информации между задействованными в проекте группами и сотрудниками о мероприятиях по обеспечению качества ПО и их результатах.
Цель 4. Передача на рассмотрение высшему руководству вопросов несоответствия, не решаемых на уровне проекта.
Управление конфигурацией ПО
Цель 1. Управление конфигурацией ПО происходит на плановой основе.
Цель 2. Выбранные промежуточные программные продукты определены, управляемы и доступны.
Цель 3. Изменения в определенных промежуточных программных продуктах происходят управляемым образом.
Цель 4. Распространение информации между группами и сотрудниками, задействованными в проекте, о состоянии и содержании базовых линий конфигурации.
Цель 2. Выбранные промежуточные программные продукты определены, управляемы и доступны.
Цель 3. Изменения в определенных промежуточных программных продуктах происходят управляемым образом.
Цель 4. Распространение информации между группами и сотрудниками, задействованными в проекте, о состоянии и содержании базовых линий конфигурации.
2. Группы ключевых процессов для уровня 3: определенный уровень
Координация производственного процесса организации
Цель 1. Координация мероприятий по разработке и усовершенствованию производственного процесса в рамках всей организации.
Цель 2. Выявление преимуществ и недостатков используемых производственных процессов в сравнении со стандартным процессом.
Цель 3. Планирование мероприятий, проводимых на уровне организации в целях разработки и усовершенствования производственного процесса.
Цель 2. Выявление преимуществ и недостатков используемых производственных процессов в сравнении со стандартным процессом.
Цель 3. Планирование мероприятий, проводимых на уровне организации в целях разработки и усовершенствования производственного процесса.
Определение производственного процесса организации
Цель 1. Разработка и сопровождение стандартного производственного процесса организации.
Цель 2. Сбор, изучение и распространение информации, связанной с использованием СППО в проектах разработки ПО.
Цель 2. Сбор, изучение и распространение информации, связанной с использованием СППО в проектах разработки ПО.
Программа обучения
Цель 1. Мероприятия по обучению проводятся на плановой основе.
Цель 2. Обеспечение обучения навыкам и знаниям, необходимым для выполнения руководящих и технических ролей в процессе разработки ПО.
Цель 3. Сотрудники группы разработки ПО и других смежных групп должны пройти обучение, необходимое для выполнения их ролей.
Цель 2. Обеспечение обучения навыкам и знаниям, необходимым для выполнения руководящих и технических ролей в процессе разработки ПО.
Цель 3. Сотрудники группы разработки ПО и других смежных групп должны пройти обучение, необходимое для выполнения их ролей.
Интегрированное управление разработкой ПО
Цель 1. Получение производственного процесса проекта в виде адаптированной версии СППО.
Цель 2. Планирование проекта и управление им в соответствии с его производственным процессом.
Цель 2. Планирование проекта и управление им в соответствии с его производственным процессом.
Инженерия разработки программного продукта
Цель 1. Определение, интеграция и последовательное выполнение задач разработки ПО.
Цель 2. Поддержка взаимной согласованности промежуточных программных продуктов.
Цель 2. Поддержка взаимной согласованности промежуточных программных продуктов.
Межгрупповая координация
Цель 1. Согласование требований заказчика со всеми группами, задействованными в проекте.
Цель 2. Взаимное согласование обязательств между задействованными инженерными группами.
Цель 3. Выявление, отслеживание и разрешение инженерными группами проблем межгруппового взаимодействия.
Цель 2. Взаимное согласование обязательств между задействованными инженерными группами.
Цель 3. Выявление, отслеживание и разрешение инженерными группами проблем межгруппового взаимодействия.
Экспертные оценки
Цель 1. Планирование работ по проведению экспертных оценок.
Цель 2. Выявление и устранение дефектов в промежуточных программных продуктах.
Цель 2. Выявление и устранение дефектов в промежуточных программных продуктах.
3. Группы ключевых процессов для уровня 4: управляемый уровень
Количественное управление процессом
Цель 1. Планирование работ по количественному управлению процессом.
Цель 2. Установление количественного контроля над выполнением производственного процесса проекта.
Цель 3. Количественное выражение продуктивности стандартного производственного процесса организации.
Цель 2. Установление количественного контроля над выполнением производственного процесса проекта.
Цель 3. Количественное выражение продуктивности стандартного производственного процесса организации.
Управление качеством ПО
Цель 1. Планирование работ по управлению качеством ПО.
Цель 2. Определение желаемых количественных показателей качества программного продукта и их приоритетов.
Цель 3. Фактический процесс достижения желаемых показателей качества программных продуктов должен быть количественно определен и управляем.
Цель 2. Определение желаемых количественных показателей качества программного продукта и их приоритетов.
Цель 3. Фактический процесс достижения желаемых показателей качества программных продуктов должен быть количественно определен и управляем.
4. Группы ключевых процессов для уровня 5: оптимизирующий уровень
Предотвращение дефектов
Цель 1. Планирование работ по предотвращению дефектов.
Цель 2. Поиск и выявление общих причин возникновения дефектов.
Цель 3. Определение приоритетов для общих причин возникновения дефектов и их систематическое устранение.
Цель 2. Поиск и выявление общих причин возникновения дефектов.
Цель 3. Определение приоритетов для общих причин возникновения дефектов и их систематическое устранение.
Управление технологическими изменениями
Цель 1. Планирование внедрения технологических изменений.
Цель 2. Оценка новых технологий с целью определения их влияния на качество продукта и продуктивность производственного процесса.
Цель 3. Внедрение подходящих новых технологий в производственный процесс организации.
Цель 2. Оценка новых технологий с целью определения их влияния на качество продукта и продуктивность производственного процесса.
Цель 3. Внедрение подходящих новых технологий в производственный процесс организации.
Управление изменениями процесса
Цель 1. Планирование непрерывного усовершенствования процесса.
Цель 2. Участие в работах по усовершенствованию производственного процесса организации должно носить общекорпоративный характер.
Цель 3. Непрерывное усовершенствование СППО и производственных процессов отдельных проектов.
Цель 2. Участие в работах по усовершенствованию производственного процесса организации должно носить общекорпоративный характер.
Цель 3. Непрерывное усовершенствование СППО и производственных процессов отдельных проектов.
ССЫЛКИ НА ИСПОЛЬЗУЕМУЮ ЛИТЕРАТУРУ
Brooks 87 F.P. Brooks, «No Silver Bullet: Essence and Accidents of Software Engineering», IEEE Computer, Vol. 20, No. 4, April 1987, pp. 10–19.
Crosby 79 P.B. Crosby, Quality is Free, McGraw-Hill, New York, NY, 1979. Curtis 90 B. Curtis, «Managing the Real Leverage in Software
Productivity and Quality,» American Programmer, Vol. 3, No. 7, July 1990, pp. 4–14.
Deming 86 W. Edwards Deming, Out of the Crisis, MIT Center for Advanced Engineering Study, Cambridge, MA, 1986.
DoD 87 Report of the Defense Science Board Task Force on Military Software, Office of the Under Secretary of Defense for Acquisition, Washington, D.C., September 1987.
Fagan 86 M.E. Fagan, «Advances in Software Inspections», IEEE Transactions on Software Engineering, Vol. 12, No. 7, July 1986, pp. 744–751.
Fowler 90 P. Fowler and S. Rifkin, Software Engineering Process Group Guide, Software Engineering Institute, CMU/SEI-90-TR-24, ADA235784, September 1990.
Freedman 90 D.P. Freedman and G.M. Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews, Third Edition, Dorset House, New York, NY, 1990.
Gabor 90 A. Gabor, The Man Who Discovered Quality, Random House, New York, NY, 1990.
GAO-92-48 Embedded Computer Systems: Significant Software Problems on C-17 Must Be Addressed, GAO/IMTEC-92-48, May 1992.
Humphrey 87a W.S. Humphrey, Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/ SEI-87-TR-11, ADA182895, June 1987.
Humphrey 87b W.S. Humphrey and W.L. Sweet, A Method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, CMU/SEI-87-TR-23, ADA187320, September 1987.
Humphrey 88 W.S. Humphrey, «Characterizing the Software Process», IEEE Software, Vol. 5, No. 2, March 1988, pp. 73–79.
Humphrey 89 W.S. Humphrey, Managing the Software Process, AddisonWesley, Reading, MA, 1989.
Humphrey 91a W.S. Humphrey, D.H. Kitson, and J. Gale, «A Comparison of U.S. and Japanese Software Process Maturity», Proceedings of the 13th International Conference on Software Engineering, Austin, TX, 13–17 May 1991, pp. 38–49.
Humphrey 91b W.S. Humphrey, «Process Fitness and Fidelity», Proceedings of the Seventh International Software Process Workshop, 16–18 October 1991.
IEEE-STD-610 ANSI/IEEE Std 610.12-1990, «IEEE Standard Glossary of Software Engineering Terminology», February 1991.
Imai 86 M. Imai, Kaizen: The Key to Japan’s Competitive Success, McGraw-Hill, New York, NY, 1986.
Juran 88 J.M. Juran, Juran on Planning for Quality, Macmillan, New York, NY, 1988.
Juran 89 J.M. Juran, Juran on Leadership for Quality, The Free Press, New York, NY, 1989.
Kitson 92 D.H. Kitson and S. Masters, An Analysis of SEI Software Process Assessment Results: 1987–1991, Software Ingineering Institute, CMU/SEI-92-TR-24, July 1992.
Paulk 91 M.C. Paulk, B. Curtis, M.B. Chrissis, et al, Capability Maturity Model for Software, Software Engineering Institute, CMU/ SEI-91-TR-24, ADA240603, August 1991.
Paulk 93a M.C. Paulk, B. Curtis, M.B. Chrissis, and C.V. Weber, Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24, February 1993. Paulk 93b M.C. Paulk, C.V. Weber, S. Garcia, M.B. Chrissis, and M. Bush,
Key Practices of the Capability Maturity Model, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-25, February 1993.
Radice 85 R.A. Radice, J.T. Harding, P.E. Munnis, and R.W. Phillips, «A Programming Process Study», IBM Systems Journal, Vol. 24, No.2, 1985.
Siegel 90 J.A.L. Siegel, et al., National Software Capacity: Near-Term Study, Software Engineering Institute, CMU/SEI-90-TR-12, ADA226694, May 1990.
Weber 91 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, Key Practices of the Capability Maturity Model, Software Engineering Institute, CMU/SEI-91-TR-25, ADA240604, August 1991.
Crosby 79 P.B. Crosby, Quality is Free, McGraw-Hill, New York, NY, 1979. Curtis 90 B. Curtis, «Managing the Real Leverage in Software
Productivity and Quality,» American Programmer, Vol. 3, No. 7, July 1990, pp. 4–14.
Deming 86 W. Edwards Deming, Out of the Crisis, MIT Center for Advanced Engineering Study, Cambridge, MA, 1986.
DoD 87 Report of the Defense Science Board Task Force on Military Software, Office of the Under Secretary of Defense for Acquisition, Washington, D.C., September 1987.
Fagan 86 M.E. Fagan, «Advances in Software Inspections», IEEE Transactions on Software Engineering, Vol. 12, No. 7, July 1986, pp. 744–751.
Fowler 90 P. Fowler and S. Rifkin, Software Engineering Process Group Guide, Software Engineering Institute, CMU/SEI-90-TR-24, ADA235784, September 1990.
Freedman 90 D.P. Freedman and G.M. Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews, Third Edition, Dorset House, New York, NY, 1990.
Gabor 90 A. Gabor, The Man Who Discovered Quality, Random House, New York, NY, 1990.
GAO-92-48 Embedded Computer Systems: Significant Software Problems on C-17 Must Be Addressed, GAO/IMTEC-92-48, May 1992.
Humphrey 87a W.S. Humphrey, Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/ SEI-87-TR-11, ADA182895, June 1987.
Humphrey 87b W.S. Humphrey and W.L. Sweet, A Method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, CMU/SEI-87-TR-23, ADA187320, September 1987.
Humphrey 88 W.S. Humphrey, «Characterizing the Software Process», IEEE Software, Vol. 5, No. 2, March 1988, pp. 73–79.
Humphrey 89 W.S. Humphrey, Managing the Software Process, AddisonWesley, Reading, MA, 1989.
Humphrey 91a W.S. Humphrey, D.H. Kitson, and J. Gale, «A Comparison of U.S. and Japanese Software Process Maturity», Proceedings of the 13th International Conference on Software Engineering, Austin, TX, 13–17 May 1991, pp. 38–49.
Humphrey 91b W.S. Humphrey, «Process Fitness and Fidelity», Proceedings of the Seventh International Software Process Workshop, 16–18 October 1991.
IEEE-STD-610 ANSI/IEEE Std 610.12-1990, «IEEE Standard Glossary of Software Engineering Terminology», February 1991.
Imai 86 M. Imai, Kaizen: The Key to Japan’s Competitive Success, McGraw-Hill, New York, NY, 1986.
Juran 88 J.M. Juran, Juran on Planning for Quality, Macmillan, New York, NY, 1988.
Juran 89 J.M. Juran, Juran on Leadership for Quality, The Free Press, New York, NY, 1989.
Kitson 92 D.H. Kitson and S. Masters, An Analysis of SEI Software Process Assessment Results: 1987–1991, Software Ingineering Institute, CMU/SEI-92-TR-24, July 1992.
Paulk 91 M.C. Paulk, B. Curtis, M.B. Chrissis, et al, Capability Maturity Model for Software, Software Engineering Institute, CMU/ SEI-91-TR-24, ADA240603, August 1991.
Paulk 93a M.C. Paulk, B. Curtis, M.B. Chrissis, and C.V. Weber, Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24, February 1993. Paulk 93b M.C. Paulk, C.V. Weber, S. Garcia, M.B. Chrissis, and M. Bush,
Key Practices of the Capability Maturity Model, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-25, February 1993.
Radice 85 R.A. Radice, J.T. Harding, P.E. Munnis, and R.W. Phillips, «A Programming Process Study», IBM Systems Journal, Vol. 24, No.2, 1985.
Siegel 90 J.A.L. Siegel, et al., National Software Capacity: Near-Term Study, Software Engineering Institute, CMU/SEI-90-TR-12, ADA226694, May 1990.
Weber 91 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, Key Practices of the Capability Maturity Model, Software Engineering Institute, CMU/SEI-91-TR-25, ADA240604, August 1991.