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