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