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