Текст книги "Модель зрелости процессов разработки программного обеспечения"
Автор книги: Сьюзен Гарсия
Соавторы: Марк Паулк,Чарльз Вебер,Мэри Хриссис,Билл Куртис,Мерилин Буш
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 15 (всего у книги 16 страниц)
5. Документация подвергается экспертной оценке. См. группу ключевых процессов «Экспертные оценки».
6. Документация должна быть управляемой и контролируемой.
7. Окончательная документация рассматривается и утверждается заказчиком, конечными пользователями, и при необходимости, специалистами по поддержке ПО.
Операция 9. Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта.
Примеры собираемых и анализируемых данных:
описание дефекта,
категория дефекта,
серьезность дефекта,
модули, содержащие дефект,
модули, подверженные влиянию дефекта,
операция, в которой проявился дефект,
экспертная оценка или тестовые сценарии, выявившие дефект,
описание сценария, при выполнении которого был выявлен дефект,
ожидаемые и фактические результаты, выявляющие дефект.
Операция 10. Поддержка согласованности всех промежуточных программных продуктов, включая планы разработки ПО, описания процессов, установленные требования, требования к ПО, архитектуру ПО, планы и процедуры тестирования.
1. Промежуточные программные продукты документируются, а к созданной документации имеется постоянный доступ.
2. Требования к ПО, архитектура ПО, программный код и тестовые сценарии отслеживаются от источника их происхождения до продуктов последующих операций разработки ПО.
3. Документация, отслеживающая установленные требования до требований к ПО, архитектуры, кода и тестовых сценариев, должна быть управляемой и контролируемой.
4. По мере роста понимания разрабатываемого продукта предлагаются, анализируются и внедряются изменения промежуточных программных продуктов, планов, описания процессов и операций.
Влияние изменений на ход проекта определяется до того, как эти изменения будут реализованы.
При необходимости изменения установленных требований, эти изменения утверждаются и реализуются до начала изменения каких-либо связанных с этим промежуточных программных продуктов.
Изменения всех программных продуктов, планов, описания процессов и операций должны координироваться.
Задействованные группы информируются об изменениях и участвуют в их обсуждении.
Примеры групп, задействованных в проекте:
группа разработки ПО,
оценки составляющих проекта,
системного тестирования,
обеспечения качества ПО,
управления конфигурацией ПО,
управления договорами,
управления документацией.
Изменения отслеживаются до своей реализации.
Измерения и анализ
Измерение 1. Выполнение измерений и использование их результатов для определения функциональных возможностей и качества программных продуктов.
Примеры измерений:
количество, типы и серьезность дефектов, выявленных в программных продуктах, отслеживаемые интегрально и по стадиям;
установленные требования, сведенные по категориям (например, безопасность, конфигурация системы, производительность, надежность) и отслеживаемые до требований к ПО и системных тестовых сценариев.
Измерение 2. Выполнение измерений и использование их результатов для определения статуса операций по инженерии разработки программного продукта.
Примеры измерений:
статус каждого установленного требования в течение всего проекта;
отчеты о проблемах по их серьезности и длительности времени, в течение которого проблемы остаются нерешенными; определение статуса изменений установленных требований;
трудоемкость анализа каждого предлагаемого изменения и их совокупности; количество изменений, внесенных в базовые линии, по их категориям (например, интерфейс, безопасность, конфигурация системы, производительность, практичность);
объем внесенных изменений и затраты на их реализацию и тестирование, включая начальную оценку и фактические показатели объема и затрат.
Проверка внедрения
Проверка 1. Регулярная проверка высшим руководством выполнения мероприятий по инженерии разработки программного продукта.
Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 2. Регулярные и событийные проверки мероприятий по инженерии разработки программного продукта со стороны менеджера проекта.
Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 3. Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов, связанных с инженерией разработки программного продукта, и выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО».
Минимальное содержание этих проверок и/или аудитов:
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. Данный план является базовой линией для:
календарного графика проекта,
договорных и технических аспектов проекта,
распределения обязанностей между инженерными группами.
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. Управление межгрупповыми проблемами.
9.7. Экспертные оценки
Группа ключевых процессов для уровня 3: определенный уровень
Цель группы ключевых процессов «Экспертные оценки» заключается в эффективном устранении дефектов в промежуточных программных продуктах на ранних стадиях разработки. Важным следствием этой практики является улучшение понимания промежуточных программных продуктов и дефектов, которые могут быть предотвращены.
Экспертные оценки включают в себя систематическое изучение промежуточных программных продуктов, проводимое экспертами-разработчиками в целях выявления дефектов и областей, в которые следует внести изменения. Конкретные продукты, подлежащие экспертной оценке, определяются в документе производственного процесса проекта, а их оценка планируется в составе мероприятий по планированию проекта разработки, как это описано в группе ключевых процессов «Интегрированное управление разработкой ПО».
Эта группа ключевых процессов охватывает практики, связанные с выполнением экспертных оценок. Практики, определяющие конкретные промежуточные продукты, подлежащие экспертной оценке, содержатся в группах ключевых процессов, которые описывают разработку и сопровождение каждого промежуточного программного продукта.
Цели
Цель 1. Планирование работ по проведению экспертных оценок.
Цель 2. Выявление и устранение дефектов в промежуточных программных продуктах.
Обязательства по выполнению
Обязательство 1. Проект следует документированной организационной политике проведения экспертных оценок.
Эта политика обычно состоит из следующих положений:
1. Организация определяет стандартный набор промежуточных программных продуктов, подвергаемых экспертной оценке.
2. Для каждого проекта определяются промежуточные программные продукты, подвергаемые экспертной оценке.
Практики, связанные с выявлением программных продуктов, подвергаемых экспертной оценке, содержатся в описании Операции № 1 группы ключевых процессов «Интегрированное управление разработкой ПО» и Операции № 2 группы ключевых процессов «Определение производственного процесса организации».
Примеры промежуточных программных продуктов:
системное ПО и вспомогательные программы,
промежуточные программные продукты, как предназначенные для поставки заказчику, так и внутреннего пользования,
программные (например, код) и непрограммные промежуточные продукты (например, документы),
описания процессов.
3. Экспертные оценки проводятся под руководством ведущих экспертов, опытных в их проведении.
4. Экспертные оценки фокусируются не на разработчике, а на проверяемом промежуточном программном продукте.
5. Результаты экспертных оценок не должны использоваться руководством для оценки работы сотрудников.
