Марк Паулк - Модель зрелости процессов разработки программного обеспечения
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. Регулярная проверка высшим руководством выполнения мероприятий по инженерии разработки программного продукта.
Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 2. Регулярные и событийные проверки мероприятий по инженерии разработки программного продукта со стороны менеджера проекта.
Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 3. Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов, связанных с инженерией разработки программного продукта, и выполнение отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО».
Минимальное содержание этих проверок и/или аудитов:
1. Проверка следующих качеств требований к ПО:
полнота,
корректность,
