Тестирование
программного
обеспечения
Введение в тестирование
программного обеспечения
Тестирование ПО 207/18/14
Введение в тестирование ПО
 Жизненный цикл разработки ПО
 Цели и задачи процесса тестирования
 Основные понятия. Полный цикл тестирования. Фазы
тестирования
 Роли участников группы тестирования
 Анализ требований к ПО с точки зрения пригодности
к тестированию
 Составление тестов на основе требований
 Оценка рисков требований, ранжирование тестов
 Изменение требований в процессе разработки
Тестирование ПО 307/18/14
Жизненный цикл разработки ПО
Тестирование ПО 407/18/14
Жизненный цикл разработки ПО
 Жизненный цикл проекта – ключевое
понятие в разработке ПО
 Жизненный цикл – соглашение,
облегчающее планирование проекта и
координацию усилий его участников
 Различные стандарты по-разному
определяют это понятие
Тестирование ПО 507/18/14
Жизненный цикл разработки ПО
 Четыре обобщенные фазы жизненного
цикла
1. концепция (инициация, идентификация, отбор)
2. определение (анализ)
3. выполнение (практическая реализация или
внедрение, производство и развертывание,
проектирование или конструирование, сдача в
эксплуатацию, инсталляция, тестирование и т.п.)
4. закрытие (завершение, включая оценивание
после завершения)
Тестирование ПО 607/18/14
Жизненный цикл разработки ПО
 Определения модели жизненного цикла программной
системы в различных вариантах стандартов ГОСТ:
 Модель жизненного цикла – структура, состоящая из
процессов, работ и задач, включающих в себя разработку,
эксплуатацию и сопровождение программного продукта,
охватывающая жизнь системы от установления требований
к ней до прекращения ее использования [ГОСТ 12207, 1999].
 Жизненный цикл автоматизированной системы (АС) –
совокупность взаимосвязанных процессов создания и
последовательного изменения состояния АС, от
формирования исходных требований к ней до окончания
эксплуатации и утилизации комплекса средств
автоматизации АС [ГОСТ 34, 1990].
Тестирование ПО 707/18/14
Уровни жизненного цикла ПО
 По Скотту Амблеру (Scott W. Ambler) [Ambler,
2005], автору концепций и практик гибкого
моделирования (Agile Modeling) и Enterprise
Unified Process (расширение Rational Unified
Process):
 Жизненный цикл разработки
программного обеспечения – проектная
деятельность по разработке и
развертыванию программных систем
 Жизненный цикл программной системы
– включает разработку, развертывание,
поддержку и сопровождение
 Жизненный цикл информационных
технологий (ИТ) – включает всю
деятельность ИТ-департамента
 Жизненный цикл организации/бизнеса –
охватывает всю деятельность
организации в целом
Тестирование ПО 807/18/14
Модели жизненного цикла ПО
 Каскадная модель: переход на следующий этап означает полное завершение
работ на предыдущем этапе.
 Итеративная и инкрементальная – эволюционная (гибридная, смешанная,
поэтапная модель с промежуточным контролем): разработка ПО ведется
итерациями с циклами обратной связи между этапами. Межэтапные
корректировки позволяют уменьшить трудоемкость процесса разработки по
сравнению с каскадной моделью, но время жизни каждого из этапов
растягивается на весь период разработки.
 Спиральная модель: особое внимание уделяется начальным этапам
разработки: выработке стратегии, анализу и проектированию, где
реализуемость тех или иных технических решений проверяется и
обосновывается посредством создания прототипов (макетирования). Каждый
виток спирали предполагает создание некой версии продукта или какого-либо
его компонента; при этом уточняются характеристики и цели проекта,
определяется его качество и планируются работы следующего витка спирали.
Тестирование ПО 907/18/14
Модели жизненного цикла ПО
Каскадная (водопадная) модель
Тестирование ПО 1007/18/14
Модели жизненного цикла ПО
Каскадная (водопадная) модель
«Основное заблуждение каскадной
модели состоит в
предположениях, что проект
проходит через весь процесс
один раз, архитектура хороша и
проста в использовании, проект
осуществления разумен, а
ошибки в реализации
устраняются по мере
тестирования. Иными словами,
каскадная модель исходит из
того, что все ошибки будут
сосредоточены в реализации, а
потому их устранение происходит
равномерно во время
тестирования компонентов и
системы»
(Ф. Брукс)
 составление плана действий по
разработке системы;
 планирование работ, связанных
с каждым действием;
 отслеживание хода выполнения
действий с контрольными
этапами
Тестирование ПО 1107/18/14
Модели жизненного цикла ПО
Итеративная и инкрементальная модель –
эволюционный подход
Тестирование ПО 1207/18/14
Модели жизненного цикла ПО
Итеративная модель
Тестирование ПО 1307/18/14
Модели жизненного цикла ПО
Итеративная и инкрементальная модель –
эволюционный подход
 разбиение жизненного цикла проекта на
последовательность итераций;
 цель каждой итерации – получение работающей
версии программной системы, включающей
функциональность, определенную интегрированным
содержанием всех предыдущих и текущей итерации
Тестирование ПО 1407/18/14
Модели жизненного цикла ПО
 можно очень рано начать
тестирование
пользователями;
 можно принять стратегию
разработки в соответствии с
бюджетом, полностью
защищающую от
перерасхода времени или
средств (в частности, за счет
сокращения второстепенной
функциональности)
 Эволюционная модель: не только
сборка работающей (с точки зрения
результатов тестирования) версии
системы, но и её развертывание в
реальных операционных условиях с
анализом откликов пользователей для
определения содержания и
планирования следующей итерации.
 “Чистая” инкрементальная модель не
предполагает развертывания
промежуточных сборок (релизов)
системы и все итерации проводятся по
заранее определенному плану
наращивания функциональности, а
пользователи (заказчик) получает только
результат финальной итерации как
полную версию системы.
Итеративная и инкрементальная модель –
эволюционный подход
Тестирование ПО 1507/18/14
Модели жизненного цикла ПО
Спиральная модель
Тестирование ПО 1607/18/14
Модели жизненного цикла ПО
Спиральная модель
 На этапах анализа и проектирования создаются прототипы для
проверки реализуемости технических решений и степени
удовлетворения потребностей заказчика
 Каждый виток спирали соответствует созданию
работоспособного фрагмента или версии системы. Это
позволяет уточнить требования, цели и характеристики проекта,
определить качество разработки, спланировать работы
следующего витка спирали.
Тестирование ПО 1707/18/14
Модели жизненного цикла ПО
Спиральная модель: преимущества
 Модель уделяет специальное внимание раннему анализу возможностей
повторного использования
 Модель предполагает возможность эволюции жизненного цикла, развитие и
изменение программного продукта
 Модель предоставляет механизмы достижения необходимых параметров
качества как составную часть процесса разработки программного продукта.
 Модель уделяет специальное внимание предотвращению ошибок и
отбрасыванию ненужных, необоснованных или неудовлетворительных
альтернатив на ранних этапах проекта
 Модель позволяет контролировать источники проектных работ и
соответствующих затрат
 Модель не проводит различий между разработкой нового продукта и
расширением (или сопровождением) существующего
 Модель позволяет решать интегрированный задачи системной разработки,
охватывающей и программную, и аппаратную составляющие создаваемого
продукта.
Тестирование ПО 1807/18/14
Жизненный цикл разработки ПО
 Методологии разработки ПО
 Практика поэтапного создания продукта: стандарты ГОСТ
(Россия) и ISO (Европа, Россия), CMM (Capability Maturity
Model — распространен в США), регламентирующие данный
процесс
 Rational Unified Process (RUP)
 Enterprise Unified Process (EUP)
 Microsoft Solutions Framework (MSF) версия 3 и версия 4 в
обоих представлениях: MSF for Agile и MSF for CMMI
(анонсированная изначально как “MSF Formal”)
 Agile-практики (eXtreme Programming (XP), Feature Driven
Development (FDD), Dynamic Systems Development Method
(DSDM), SCRUM,...)
Тестирование ПО 1907/18/14
Фазы разработки
программного обеспечения
Осознание проблемы  Идея
Исследование и постановка задачи
 Анализ
Выработка вариантов решения задачи
Выбор варианта решения  Проектирование
Реализация решения
 Программирование
 Тестирование
 Внедрение
 Поддержка
Тестирование ПО 2007/18/14
Бизнес-моделирование
и системный анализ
Проектирование Пилотное внедрение Развертывание
Управление качеством на каждом из этапов
жизненного цикла разработки ПО
• Требования к
качеству ПО
• План
тестирования
• Сценарии
тестирования
• Отчет(ы) о
тестировании
• Метрики
•
Статистические
отчеты
Определение
заинтересованных
лиц;
Определение
критериев качества
Нахождение
решения,
удовлетворяющего
критериям
Проверка,
удовлетворяет ли
решение критериям
качества
Анализ полученных
результатов;
Формирование
базы знаний
 Внутреннее тестированиеВнутреннее тестирование
(участники проекта разработки
ПО)
Проектирование, пилотное
внедрение, развертывание
 Внешнее тестированиеВнешнее тестирование
(пользователи продукта)
Пилотное внедрение,
развертывание
1-20
Тестирование ПО 2107/18/14
Управление конфигурацией
 Прослеживание и контроль сборок и
версий программного продукта
 Версия программного продукта (результат в конце
итерации)
 Сборка программного продукта (регулярная
процедура)
 Доступность «истории» продукта
Тестирование ПО 2207/18/14
Виды тестирования
Тестирование ПО 2307/18/14
Виды тестирования
 Тестирование требований
 Функциональное тестирование
 Тестирование по нефункциональным
требованиям
 отказоустойчивость
 производительность
 переносимость
Тестирование ПО 2407/18/14
Виды тестирования
 Unit-тестирование (модульное тестирование)
– тестирование отдельных модулей
приложения
 Функциональное тестирование – убедиться
в надлежащем функционировании объекта
тестирования
 Тестирование БД – проверка
работоспособности БД при нормальной работе
приложения, в моменты перегрузок и в
многопользовательском режиме
Тестирование ПО 2507/18/14
Категории тестирования
Категории
тестирования
Описание категории Виды тестирования
Текущее
тестирование
Набор тестов, выполняемый
для определения
работоспособности
добавленных новых
возможностей системы.
нагрузочное тестирование;
тестирование бизнес циклов;
Стресс-тестирование
Регрессионное
тестирование
Проверка того, что добавления
к системе не уменьшили ее
возможностей, т.е.
тестирование проводится
согласно требованиям,
которые уже были выполнены
перед добавлением новых
возможностей.
нагрузочное тестирование;
тестирование бизнес циклов;
Стресс-тестирование
Тестирование ПО 2607/18/14
Подкатегории тестирования
Подкатегории
тестирования
Описание вида
тестирования
Подвиды
тестирования
Нагрузочное
тестирование
Тестирования всех или выбранных
функций приложения для определения
поведения приложения под нагрузкой
unit-тестирование (модульное
тестирование);
функциональное
тестирование;
тестирование интерфейса;
тестирование БД
Тестирование
бизнес циклов
Тестирование функций приложения в
последовательности их вызова
пользователем. Например, имитация
всех действия бухгалтера за 1
квартал.
функциональное
тестирование;
тестирование интерфейса;
тестирование БД
Стрессовое
тестирование
Определить рамки стабильной работы
приложения
функциональное
тестирование;
тестирование интерфейса;
тестирование БД
Тестирование ПО 2707/18/14
Артефакты тестирования
 Сводная оценка результатов тестирования
 Двухуровневый план тестирования
 Общий план тестирования
 План тестирования итерации (может быть связан с Планом
обеспечения качества)
 Список идей тестов
 Комплект тестов (Test suite)
 Тестовые сценарии
 Пошаговые инструкции по выполнению теста
 Дефект
 Модель рабочей нагрузки
 Спецификация тестового интерфейса
 Архитектура автоматизации тестов
Тестирование ПО 2807/18/14
Цели и задачи процесса
тестирования
Тестирование ПО 2907/18/14
Определение тестирования
 Тестирование программного обеспечения – это
процесс анализа или эксплуатации программного
обеспечения с целью выявления дефектов
 Процесс анализа программы для определения
расхождений между существующими и требуемыми
условиями (то есть для нахождения ошибок) и для
оценки свойств (характеристик) программы.
Р.Калбертсон, К.Браун, Г.Кобб Быстрое тестирование,
2002
IEEE Std 829 – 1998 IEEE Standard for Software Test
Documentation
1-29
Тестирование ПО 3007/18/14
Два вида тестирования
 Статическое тестирование
 Анализ результатов разработки программного
обеспечения (артефактов)
 Артефакты могут включать любую документацию и код
 Проверка программных кодов, контроль и
проверка программы без запуска на машине
 Динамическое тестирование
 Запуск программного продукта и запуск тестов
1-30
Тестирование ПО 3107/18/14
Цели и задачи процесса
тестирования
 Определения
 Ошибка
 Возникает в результате деятельности людей, связанной с разработкой
программного обеспечения
 Ошибка в требованиях, ошибка в дизайне, ошибка в коде
 Дефект
 Несоответствие поведения программы требованиям или ожидаемому
поведению или несоответствие документации требованиям
 Отказ
 Проявление дефекта в ходе эксплуатации программы
 Аварийный отказ – невозможность продолжать эксплуатацию
программы
 Иногда термины «ошибка» (error, bug) и «дефект» используют
взаимозаменяемо
Тестирование ПО 3207/18/14
Цели и задачи процесса
тестирования
человек
совершает
ошибку
ведущую к
дефекту
обнаруживаемого,
возможно, другим
человеком
проявляемому
в виде
отказа
Тестирование ПО 3307/18/14
Предотвращение и
минимизация
 До выпуска (релиза)
 Переработка
 Повторное проектирование
 Ремонт
 Стоимость анализа
 После выпуска (релиза)
 Идентификация причин –
Рекламации
 Возвраты
 Поддержка
 Гарантийная работа
} Это влияет на
текущий график
} Это влияет на
будущие
графики
Тестирование ПО 3407/18/14
Проблемы менеджмента
качества в разработке ПО
 Комплексность
 Большой объем артефактов, подлежащих контролю
 Большое число возможных состояний
 Соответствие
 Базируется на абстрактной (математической) модели, не
на физических законах
 Влияние человеческого фактора
 Изменчивость
 Последствия изменения неизвестны
 Непредсказуемость
 Невидимость
Тестирование ПО 3507/18/14
Эффективность тестирования
Число ошибок, обнаруженных в ходе
инспекции
Общее число ошибок в продукте до инспекции
Х 100%
Дефекты, обнаруженные тестированием или
инспекцией
Дефекты, имеющиеся во время тестирования или
инспекции
Х 100% =
Обнаруженные дефекты
Обнаруженные дефекты + необнаруженные
дефекты
Х 100%=
(обнаруженные позже)
Джонс (1986)Джонс (1986)
Фаган (1976)Фаган (1976)
Тестирование ПО 3607/18/14
Эффективность тестирования
Число дефектов, обнаруженных до релиза
Число дефектов до релиза + после релиза
Число ошибок фазы
Число ошибок фазы + число дефектов фазы
TDCE =
PCEi =
TDCE – Total Defect Containment
Effectiveness (общая эффективность
устранения дефектов)
PCEi – Phase Containment Effectiveness
(эффективность устранения дефектов фазы)
МоторолаМоторола
Тестирование ПО 3707/18/14
Действия, приводящие к
появлению и устранению дефектов
Фаза разработки Внесение дефекта Устранение
дефекта
Требования Сбор требований и разработка
функциональных спецификаций
Анализ и обзор требований
Высокоуровневый дизайн Работа по дизайну Инспекция высокоуровневого
дизайна
Низкоуровневый дизайн Работа по дизайну Инспекция низкоуровневого
дизайна
Кодирование Кодирование Инспекция кода
Интеграция/сборка Процесс интеграции и
построения сборки
Тестирование построения
сборки
Unit тестирование Плохое исправление дефектов Тестирование
Компонентное тестирование Плохое исправление дефектов Тестирование
Системное тестирование Плохое исправление дефектов Тестирование
1-37
Тестирование ПО 3807/18/14
Роли участников группы
тестирования
Тестирование ПО 3907/18/14
Задачи тестировщика
 Определение миссии тестирования
 Проверка подхода к тестированию
 Проверка стабильности выпуска (build)
 Тестирование и оценка
 Достижение приемлемого результата
миссии
 Совершенствование методов и средств
тестирования
Тестирование ПО 4007/18/14
Участники процесса тестирования
 Менеджер проекта – обеспечение ресурсами, координация
работ
 Разработчик, технический писатель – исправление найденных
ошибок
 Архитектор – обеспечение целостности проекта в процессе
исправления ошибок
 Интегратор – контроль и выпуск версий ПО
 Аналитик – установка приоритетов, связанных с
необходимостью и сложностью исправления найденных
дефектов
 Тестировщик – несет ответственность за процесс тестирования
в целом
Тестирование ПО 4107/18/14
Роли участников группы
тестирования
 Руководитель группы тестирования (Test manager) – представляет
ключевую роль тестировщика в рабочей группе, несет ответственность
за организацию процесса тестирования в проекте, планирование и
контроль действий по тестированию.
 Тестировщик-аналитик (Test analyst) – несет ответственность за
формирование тестовых спецификаций, и анализ итогов тестирования.
 Разработчик тестов (Test developer) – несет ответственность за
разработку автоматизированных тестов, предусмотренных в плане
тестирования, установку и сопровождение инфраструктуры
тестирования, создание стенда для проведения тестирования в
соответствии с планом тестирования.
 Исполнитель тестов (Test operator) - несет ответственность за
фактическое исполнение тестов и документирование выявленных
дефектов.
Тестирование ПО 4207/18/14
Особенности требований к ПО
Тестирование ПО 4307/18/14
Особенности требований к ПО
 Каждое требование должно быть снабжено
уникальным идентификатором
 Требования должны быть представлены с
точки зрения пользователя системы
 Должны быть включены
 Функциональные и
 Нефункциональные требования
 Документ определения требований должен
находиться под управлением
конфигурациями
Тестирование ПО 4407/18/14
Критерии при тестировании
требований
 Полнота
 Непротиворечивость
 Осуществимость
 Проверяемость (возможность
тестирования)
 Однозначность
 Релевантность
Тестирование ПО 4507/18/14
Матрица отслеживаемости требований
ID
требован
ия
ID
функции
ID
компоне
нта в.у.
ID
программн
ого
компонент
а
ID unit
теста
ID
интеграц
ионного
теста
ID
системно
го теста
ID
приемочн
ого теста
RD2.2.4 RS2.2.4.1 D2.2.4.1 CC2.2.4.1 UT2.2.4.1 IT2.2.4 ST2.2.4 AT2.2.4
Тестирование ПО 4607/18/14
Доступность
(отказоустойчивость)
 Частота недоступности системы в пределах временного
интервала, который используется для определения доступности
 Продолжительность недоступности системы
 Доступность по расписанию
 5 х 8 (рабочие дни, рабочие часы)
 7 х 24 (все дни недели, 24 часа)
 365 х 24 (все дни года, 24 часа)
 Доступность пять «9» или 99,999% - стремление индустрии
 Например, производители серверов
 Достигнутый результат – 99,998% для кластеров (10 минут
недоступности в течение года)
 ПК – 97,5% доступности в среднем (219 часов в год)
Тестирование ПО 4707/18/14
Надежность и доступность
 Операционная мера надежности – MTTF (Mean Time
To Failure – среднее время до отказа или наработка
на отказ)
 Измеряется в часах
 Частота отказов
 Среднее время на устранение отказа – MTTR (Mean
Time To Repair)
1
MTTF
Тестирование ПО 4807/18/14
Связь между плотностью
дефектов и значениями MTTF
Дефектов на
KLOC
MTTF
Больше 30 Меньше 2 минут
20-30 4-15 минут
10-20 5-60 минут
5-10 1-4 часа
2-5 4-24 часа
1-2 24-160 часов
Меньше 1 неопределенно
Тестирование ПО 4907/18/14
Производительность
 Число операций в секунду
 MIPS – миллионы инструкций в секунду
 Число транзакций в секунду
 TPC-App для серверов приложений и веб-сервисов
 TPC-C для операций многих пользователей с базой данных
 TPC-E – новый OLTP тест. Эмулирует брокерскую компанию с
клиентами, которые генерируют торговые транзакции. Компания
взаимодействует с финансовыми рынками
 TPC-H для поддержки принятия решений. Набор произвольных
бизнес-запросов и параллельная модификация данных
Тестирование ПО 5007/18/14
Тестирование производительности
 При заданных параметрах системы
 Число серверов
 Процессоры
 Память
 Дисковая подсистема
 Сеть
 При заданном объеме базы данных
 Число записей того или иного сорта, например, число позиций на складе или
число счетов в банковской системе или число полисов в страховой системе
 При меняющемся числе параллельно работающих пользователей
 Например, 1 – 10 – 100 – 1000 – 10000
 Время отклика системы на воздействие
 Он-лайн запросы
 Пакетные запросы (отчеты)
Тестирование ПО 5107/18/14
Переносимость
 Операционные системы
 Windows XP vs Windows Vista
 Windows vs Linux vs Unix (HP-UX, AIX, Solaris)
 AS/400, MVS, VAX
 Сервера приложений
 Web Logic (BEA) vs Web Sphere (IBM) vs Tomcat vs IIS
 Браузеры
 Microsoft IE 6 vs IE7 vs Mozilla vs Opera vs
 Базы данных
 MS SQL vs Oracle vs DB2 + версии
 Среда виртуальных машин
 VM Ware
Тестирование ПО 5207/18/14
Тестирование конфигураций
(системные требования)
 Процессор
 Память
 Диск
 Разрешение монитора
 Видеоплата
 Звуковая карта
 и т.п.
2-52
Тестирование ПО 5307/18/14
Изменение требований к ПО в
процессе разработки
Тестирование ПО 5407/18/14
Управление требованиями
Тестирование ПО 5507/18/14
Анализ влияния изменений
Анализ влияния изменения включает
оценку:
технической осуществимости
соответствия бизнес целям
масштаба влияния
цены выполнения изменения
последствий отклонения
Тестирование ПО 5607/18/14
Оценка затрат (пример 1)
Тип элемента Название элементов Трудоемкость
Формы FC_001, FC_013, FC_022 2
Отчеты RP_01, RP_07 1
Таблицы CLIENT, SUPPL 1
Тесты T002 0.1
Процедуры
Документы CRM-UG1-02 0.5
ИТОГО 4.6
Z013. Адрес Email. Увеличить размер адреса до 50 символов
Тестирование ПО 5707/18/14
Заказчик Разработчик
Маркетолог
Оценка изменений
Спецификация
требований
Запрос на
изменение
Принятое изменение
Новая редакция
Управление изменениями
Тестирование ПО 5807/18/14
Цена изменения требований
Относительнаястоимость
исправленияошибоквтребованиях
20
40
60
80
100
Требования ИспользованиеПроект Кодирование Тестирование
Фазы разработки [Карл Видгерс]

тестирование программного обеспечения

  • 1.
  • 2.
    Тестирование ПО 207/18/14 Введениев тестирование ПО  Жизненный цикл разработки ПО  Цели и задачи процесса тестирования  Основные понятия. Полный цикл тестирования. Фазы тестирования  Роли участников группы тестирования  Анализ требований к ПО с точки зрения пригодности к тестированию  Составление тестов на основе требований  Оценка рисков требований, ранжирование тестов  Изменение требований в процессе разработки
  • 3.
  • 4.
    Тестирование ПО 407/18/14 Жизненныйцикл разработки ПО  Жизненный цикл проекта – ключевое понятие в разработке ПО  Жизненный цикл – соглашение, облегчающее планирование проекта и координацию усилий его участников  Различные стандарты по-разному определяют это понятие
  • 5.
    Тестирование ПО 507/18/14 Жизненныйцикл разработки ПО  Четыре обобщенные фазы жизненного цикла 1. концепция (инициация, идентификация, отбор) 2. определение (анализ) 3. выполнение (практическая реализация или внедрение, производство и развертывание, проектирование или конструирование, сдача в эксплуатацию, инсталляция, тестирование и т.п.) 4. закрытие (завершение, включая оценивание после завершения)
  • 6.
    Тестирование ПО 607/18/14 Жизненныйцикл разработки ПО  Определения модели жизненного цикла программной системы в различных вариантах стандартов ГОСТ:  Модель жизненного цикла – структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999].  Жизненный цикл автоматизированной системы (АС) – совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990].
  • 7.
    Тестирование ПО 707/18/14 Уровнижизненного цикла ПО  По Скотту Амблеру (Scott W. Ambler) [Ambler, 2005], автору концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process):  Жизненный цикл разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем  Жизненный цикл программной системы – включает разработку, развертывание, поддержку и сопровождение  Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента  Жизненный цикл организации/бизнеса – охватывает всю деятельность организации в целом
  • 8.
    Тестирование ПО 807/18/14 Моделижизненного цикла ПО  Каскадная модель: переход на следующий этап означает полное завершение работ на предыдущем этапе.  Итеративная и инкрементальная – эволюционная (гибридная, смешанная, поэтапная модель с промежуточным контролем): разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью, но время жизни каждого из этапов растягивается на весь период разработки.  Спиральная модель: особое внимание уделяется начальным этапам разработки: выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание некой версии продукта или какого-либо его компонента; при этом уточняются характеристики и цели проекта, определяется его качество и планируются работы следующего витка спирали.
  • 9.
    Тестирование ПО 907/18/14 Моделижизненного цикла ПО Каскадная (водопадная) модель
  • 10.
    Тестирование ПО 1007/18/14 Моделижизненного цикла ПО Каскадная (водопадная) модель «Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы» (Ф. Брукс)  составление плана действий по разработке системы;  планирование работ, связанных с каждым действием;  отслеживание хода выполнения действий с контрольными этапами
  • 11.
    Тестирование ПО 1107/18/14 Моделижизненного цикла ПО Итеративная и инкрементальная модель – эволюционный подход
  • 12.
    Тестирование ПО 1207/18/14 Моделижизненного цикла ПО Итеративная модель
  • 13.
    Тестирование ПО 1307/18/14 Моделижизненного цикла ПО Итеративная и инкрементальная модель – эволюционный подход  разбиение жизненного цикла проекта на последовательность итераций;  цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации
  • 14.
    Тестирование ПО 1407/18/14 Моделижизненного цикла ПО  можно очень рано начать тестирование пользователями;  можно принять стратегию разработки в соответствии с бюджетом, полностью защищающую от перерасхода времени или средств (в частности, за счет сокращения второстепенной функциональности)  Эволюционная модель: не только сборка работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации.  “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы. Итеративная и инкрементальная модель – эволюционный подход
  • 15.
    Тестирование ПО 1507/18/14 Моделижизненного цикла ПО Спиральная модель
  • 16.
    Тестирование ПО 1607/18/14 Моделижизненного цикла ПО Спиральная модель  На этапах анализа и проектирования создаются прототипы для проверки реализуемости технических решений и степени удовлетворения потребностей заказчика  Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали.
  • 17.
    Тестирование ПО 1707/18/14 Моделижизненного цикла ПО Спиральная модель: преимущества  Модель уделяет специальное внимание раннему анализу возможностей повторного использования  Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта  Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта.  Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта  Модель позволяет контролировать источники проектных работ и соответствующих затрат  Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего  Модель позволяет решать интегрированный задачи системной разработки, охватывающей и программную, и аппаратную составляющие создаваемого продукта.
  • 18.
    Тестирование ПО 1807/18/14 Жизненныйцикл разработки ПО  Методологии разработки ПО  Практика поэтапного создания продукта: стандарты ГОСТ (Россия) и ISO (Европа, Россия), CMM (Capability Maturity Model — распространен в США), регламентирующие данный процесс  Rational Unified Process (RUP)  Enterprise Unified Process (EUP)  Microsoft Solutions Framework (MSF) версия 3 и версия 4 в обоих представлениях: MSF for Agile и MSF for CMMI (анонсированная изначально как “MSF Formal”)  Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), SCRUM,...)
  • 19.
    Тестирование ПО 1907/18/14 Фазыразработки программного обеспечения Осознание проблемы  Идея Исследование и постановка задачи  Анализ Выработка вариантов решения задачи Выбор варианта решения  Проектирование Реализация решения  Программирование  Тестирование  Внедрение  Поддержка
  • 20.
    Тестирование ПО 2007/18/14 Бизнес-моделирование исистемный анализ Проектирование Пилотное внедрение Развертывание Управление качеством на каждом из этапов жизненного цикла разработки ПО • Требования к качеству ПО • План тестирования • Сценарии тестирования • Отчет(ы) о тестировании • Метрики • Статистические отчеты Определение заинтересованных лиц; Определение критериев качества Нахождение решения, удовлетворяющего критериям Проверка, удовлетворяет ли решение критериям качества Анализ полученных результатов; Формирование базы знаний  Внутреннее тестированиеВнутреннее тестирование (участники проекта разработки ПО) Проектирование, пилотное внедрение, развертывание  Внешнее тестированиеВнешнее тестирование (пользователи продукта) Пилотное внедрение, развертывание 1-20
  • 21.
    Тестирование ПО 2107/18/14 Управлениеконфигурацией  Прослеживание и контроль сборок и версий программного продукта  Версия программного продукта (результат в конце итерации)  Сборка программного продукта (регулярная процедура)  Доступность «истории» продукта
  • 22.
  • 23.
    Тестирование ПО 2307/18/14 Видытестирования  Тестирование требований  Функциональное тестирование  Тестирование по нефункциональным требованиям  отказоустойчивость  производительность  переносимость
  • 24.
    Тестирование ПО 2407/18/14 Видытестирования  Unit-тестирование (модульное тестирование) – тестирование отдельных модулей приложения  Функциональное тестирование – убедиться в надлежащем функционировании объекта тестирования  Тестирование БД – проверка работоспособности БД при нормальной работе приложения, в моменты перегрузок и в многопользовательском режиме
  • 25.
    Тестирование ПО 2507/18/14 Категориитестирования Категории тестирования Описание категории Виды тестирования Текущее тестирование Набор тестов, выполняемый для определения работоспособности добавленных новых возможностей системы. нагрузочное тестирование; тестирование бизнес циклов; Стресс-тестирование Регрессионное тестирование Проверка того, что добавления к системе не уменьшили ее возможностей, т.е. тестирование проводится согласно требованиям, которые уже были выполнены перед добавлением новых возможностей. нагрузочное тестирование; тестирование бизнес циклов; Стресс-тестирование
  • 26.
    Тестирование ПО 2607/18/14 Подкатегориитестирования Подкатегории тестирования Описание вида тестирования Подвиды тестирования Нагрузочное тестирование Тестирования всех или выбранных функций приложения для определения поведения приложения под нагрузкой unit-тестирование (модульное тестирование); функциональное тестирование; тестирование интерфейса; тестирование БД Тестирование бизнес циклов Тестирование функций приложения в последовательности их вызова пользователем. Например, имитация всех действия бухгалтера за 1 квартал. функциональное тестирование; тестирование интерфейса; тестирование БД Стрессовое тестирование Определить рамки стабильной работы приложения функциональное тестирование; тестирование интерфейса; тестирование БД
  • 27.
    Тестирование ПО 2707/18/14 Артефактытестирования  Сводная оценка результатов тестирования  Двухуровневый план тестирования  Общий план тестирования  План тестирования итерации (может быть связан с Планом обеспечения качества)  Список идей тестов  Комплект тестов (Test suite)  Тестовые сценарии  Пошаговые инструкции по выполнению теста  Дефект  Модель рабочей нагрузки  Спецификация тестового интерфейса  Архитектура автоматизации тестов
  • 28.
    Тестирование ПО 2807/18/14 Целии задачи процесса тестирования
  • 29.
    Тестирование ПО 2907/18/14 Определениетестирования  Тестирование программного обеспечения – это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов  Процесс анализа программы для определения расхождений между существующими и требуемыми условиями (то есть для нахождения ошибок) и для оценки свойств (характеристик) программы. Р.Калбертсон, К.Браун, Г.Кобб Быстрое тестирование, 2002 IEEE Std 829 – 1998 IEEE Standard for Software Test Documentation 1-29
  • 30.
    Тестирование ПО 3007/18/14 Двавида тестирования  Статическое тестирование  Анализ результатов разработки программного обеспечения (артефактов)  Артефакты могут включать любую документацию и код  Проверка программных кодов, контроль и проверка программы без запуска на машине  Динамическое тестирование  Запуск программного продукта и запуск тестов 1-30
  • 31.
    Тестирование ПО 3107/18/14 Целии задачи процесса тестирования  Определения  Ошибка  Возникает в результате деятельности людей, связанной с разработкой программного обеспечения  Ошибка в требованиях, ошибка в дизайне, ошибка в коде  Дефект  Несоответствие поведения программы требованиям или ожидаемому поведению или несоответствие документации требованиям  Отказ  Проявление дефекта в ходе эксплуатации программы  Аварийный отказ – невозможность продолжать эксплуатацию программы  Иногда термины «ошибка» (error, bug) и «дефект» используют взаимозаменяемо
  • 32.
    Тестирование ПО 3207/18/14 Целии задачи процесса тестирования человек совершает ошибку ведущую к дефекту обнаруживаемого, возможно, другим человеком проявляемому в виде отказа
  • 33.
    Тестирование ПО 3307/18/14 Предотвращениеи минимизация  До выпуска (релиза)  Переработка  Повторное проектирование  Ремонт  Стоимость анализа  После выпуска (релиза)  Идентификация причин – Рекламации  Возвраты  Поддержка  Гарантийная работа } Это влияет на текущий график } Это влияет на будущие графики
  • 34.
    Тестирование ПО 3407/18/14 Проблемыменеджмента качества в разработке ПО  Комплексность  Большой объем артефактов, подлежащих контролю  Большое число возможных состояний  Соответствие  Базируется на абстрактной (математической) модели, не на физических законах  Влияние человеческого фактора  Изменчивость  Последствия изменения неизвестны  Непредсказуемость  Невидимость
  • 35.
    Тестирование ПО 3507/18/14 Эффективностьтестирования Число ошибок, обнаруженных в ходе инспекции Общее число ошибок в продукте до инспекции Х 100% Дефекты, обнаруженные тестированием или инспекцией Дефекты, имеющиеся во время тестирования или инспекции Х 100% = Обнаруженные дефекты Обнаруженные дефекты + необнаруженные дефекты Х 100%= (обнаруженные позже) Джонс (1986)Джонс (1986) Фаган (1976)Фаган (1976)
  • 36.
    Тестирование ПО 3607/18/14 Эффективностьтестирования Число дефектов, обнаруженных до релиза Число дефектов до релиза + после релиза Число ошибок фазы Число ошибок фазы + число дефектов фазы TDCE = PCEi = TDCE – Total Defect Containment Effectiveness (общая эффективность устранения дефектов) PCEi – Phase Containment Effectiveness (эффективность устранения дефектов фазы) МоторолаМоторола
  • 37.
    Тестирование ПО 3707/18/14 Действия,приводящие к появлению и устранению дефектов Фаза разработки Внесение дефекта Устранение дефекта Требования Сбор требований и разработка функциональных спецификаций Анализ и обзор требований Высокоуровневый дизайн Работа по дизайну Инспекция высокоуровневого дизайна Низкоуровневый дизайн Работа по дизайну Инспекция низкоуровневого дизайна Кодирование Кодирование Инспекция кода Интеграция/сборка Процесс интеграции и построения сборки Тестирование построения сборки Unit тестирование Плохое исправление дефектов Тестирование Компонентное тестирование Плохое исправление дефектов Тестирование Системное тестирование Плохое исправление дефектов Тестирование 1-37
  • 38.
    Тестирование ПО 3807/18/14 Ролиучастников группы тестирования
  • 39.
    Тестирование ПО 3907/18/14 Задачитестировщика  Определение миссии тестирования  Проверка подхода к тестированию  Проверка стабильности выпуска (build)  Тестирование и оценка  Достижение приемлемого результата миссии  Совершенствование методов и средств тестирования
  • 40.
    Тестирование ПО 4007/18/14 Участникипроцесса тестирования  Менеджер проекта – обеспечение ресурсами, координация работ  Разработчик, технический писатель – исправление найденных ошибок  Архитектор – обеспечение целостности проекта в процессе исправления ошибок  Интегратор – контроль и выпуск версий ПО  Аналитик – установка приоритетов, связанных с необходимостью и сложностью исправления найденных дефектов  Тестировщик – несет ответственность за процесс тестирования в целом
  • 41.
    Тестирование ПО 4107/18/14 Ролиучастников группы тестирования  Руководитель группы тестирования (Test manager) – представляет ключевую роль тестировщика в рабочей группе, несет ответственность за организацию процесса тестирования в проекте, планирование и контроль действий по тестированию.  Тестировщик-аналитик (Test analyst) – несет ответственность за формирование тестовых спецификаций, и анализ итогов тестирования.  Разработчик тестов (Test developer) – несет ответственность за разработку автоматизированных тестов, предусмотренных в плане тестирования, установку и сопровождение инфраструктуры тестирования, создание стенда для проведения тестирования в соответствии с планом тестирования.  Исполнитель тестов (Test operator) - несет ответственность за фактическое исполнение тестов и документирование выявленных дефектов.
  • 42.
  • 43.
    Тестирование ПО 4307/18/14 Особенноститребований к ПО  Каждое требование должно быть снабжено уникальным идентификатором  Требования должны быть представлены с точки зрения пользователя системы  Должны быть включены  Функциональные и  Нефункциональные требования  Документ определения требований должен находиться под управлением конфигурациями
  • 44.
    Тестирование ПО 4407/18/14 Критериипри тестировании требований  Полнота  Непротиворечивость  Осуществимость  Проверяемость (возможность тестирования)  Однозначность  Релевантность
  • 45.
    Тестирование ПО 4507/18/14 Матрицаотслеживаемости требований ID требован ия ID функции ID компоне нта в.у. ID программн ого компонент а ID unit теста ID интеграц ионного теста ID системно го теста ID приемочн ого теста RD2.2.4 RS2.2.4.1 D2.2.4.1 CC2.2.4.1 UT2.2.4.1 IT2.2.4 ST2.2.4 AT2.2.4
  • 46.
    Тестирование ПО 4607/18/14 Доступность (отказоустойчивость) Частота недоступности системы в пределах временного интервала, который используется для определения доступности  Продолжительность недоступности системы  Доступность по расписанию  5 х 8 (рабочие дни, рабочие часы)  7 х 24 (все дни недели, 24 часа)  365 х 24 (все дни года, 24 часа)  Доступность пять «9» или 99,999% - стремление индустрии  Например, производители серверов  Достигнутый результат – 99,998% для кластеров (10 минут недоступности в течение года)  ПК – 97,5% доступности в среднем (219 часов в год)
  • 47.
    Тестирование ПО 4707/18/14 Надежностьи доступность  Операционная мера надежности – MTTF (Mean Time To Failure – среднее время до отказа или наработка на отказ)  Измеряется в часах  Частота отказов  Среднее время на устранение отказа – MTTR (Mean Time To Repair) 1 MTTF
  • 48.
    Тестирование ПО 4807/18/14 Связьмежду плотностью дефектов и значениями MTTF Дефектов на KLOC MTTF Больше 30 Меньше 2 минут 20-30 4-15 минут 10-20 5-60 минут 5-10 1-4 часа 2-5 4-24 часа 1-2 24-160 часов Меньше 1 неопределенно
  • 49.
    Тестирование ПО 4907/18/14 Производительность Число операций в секунду  MIPS – миллионы инструкций в секунду  Число транзакций в секунду  TPC-App для серверов приложений и веб-сервисов  TPC-C для операций многих пользователей с базой данных  TPC-E – новый OLTP тест. Эмулирует брокерскую компанию с клиентами, которые генерируют торговые транзакции. Компания взаимодействует с финансовыми рынками  TPC-H для поддержки принятия решений. Набор произвольных бизнес-запросов и параллельная модификация данных
  • 50.
    Тестирование ПО 5007/18/14 Тестированиепроизводительности  При заданных параметрах системы  Число серверов  Процессоры  Память  Дисковая подсистема  Сеть  При заданном объеме базы данных  Число записей того или иного сорта, например, число позиций на складе или число счетов в банковской системе или число полисов в страховой системе  При меняющемся числе параллельно работающих пользователей  Например, 1 – 10 – 100 – 1000 – 10000  Время отклика системы на воздействие  Он-лайн запросы  Пакетные запросы (отчеты)
  • 51.
    Тестирование ПО 5107/18/14 Переносимость Операционные системы  Windows XP vs Windows Vista  Windows vs Linux vs Unix (HP-UX, AIX, Solaris)  AS/400, MVS, VAX  Сервера приложений  Web Logic (BEA) vs Web Sphere (IBM) vs Tomcat vs IIS  Браузеры  Microsoft IE 6 vs IE7 vs Mozilla vs Opera vs  Базы данных  MS SQL vs Oracle vs DB2 + версии  Среда виртуальных машин  VM Ware
  • 52.
    Тестирование ПО 5207/18/14 Тестированиеконфигураций (системные требования)  Процессор  Память  Диск  Разрешение монитора  Видеоплата  Звуковая карта  и т.п. 2-52
  • 53.
    Тестирование ПО 5307/18/14 Изменениетребований к ПО в процессе разработки
  • 54.
  • 55.
    Тестирование ПО 5507/18/14 Анализвлияния изменений Анализ влияния изменения включает оценку: технической осуществимости соответствия бизнес целям масштаба влияния цены выполнения изменения последствий отклонения
  • 56.
    Тестирование ПО 5607/18/14 Оценказатрат (пример 1) Тип элемента Название элементов Трудоемкость Формы FC_001, FC_013, FC_022 2 Отчеты RP_01, RP_07 1 Таблицы CLIENT, SUPPL 1 Тесты T002 0.1 Процедуры Документы CRM-UG1-02 0.5 ИТОГО 4.6 Z013. Адрес Email. Увеличить размер адреса до 50 символов
  • 57.
    Тестирование ПО 5707/18/14 ЗаказчикРазработчик Маркетолог Оценка изменений Спецификация требований Запрос на изменение Принятое изменение Новая редакция Управление изменениями
  • 58.
    Тестирование ПО 5807/18/14 Ценаизменения требований Относительнаястоимость исправленияошибоквтребованиях 20 40 60 80 100 Требования ИспользованиеПроект Кодирование Тестирование Фазы разработки [Карл Видгерс]

Editor's Notes

  • #7 ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД). В последние годы, акцент делается на стандарты ГОСТ, соответствующие международным стандартам. В то же время, 34-я серия является важным дополнительным источником информации для разработки и стандартизации внутрикорпоративных документов и формирования целостного понимания и видения концепций жизненного цикла в области программного обеспечения.
  • #11 В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако, например, неточность какого-либо требования или некорректная его интерпретация, в результате, приводит к тому, что приходится “откатываться” к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно много. Достаточно для чего? Для отказа от каскадной модели жизненного цикла.
  • #20 Обсудить вопрос – в какой момент возникает необходимость управления качеством? Ответ: после 5-10 минутного обсуждения сделать вывод: в любой.
  • #21 Какие артефакты QA создаются на каждом из этапов? Какие процессы идут?
  • #36 Инспекции Фагана широко применяются в индустрии ПО с конца 1970-х годов. Они доказали высокую эффективность. Инспекции проводятся как по отношению к артефактам разработки ПО, так и по отношению к процессу с целью выявления так называемых «системных» ошибок – ошибок процесса. Наличие ошибки процесса приводит к дефекту каждый раз, когда процесс совершается. То есть наличие системной ошибки умножает количество дефектов ПО. Чем выше коэффициент эффективность тестирования, тем лучше совершен процесс. Если эффективность тестирования 100%, то во время эксплуатации дефекты не обнаруживаются.
  • #37 Инспекции Фагана широко применяются в индустрии ПО с конца 1970-х годов. Они доказали высокую эффективность. Инспекции проводятся как по отношению к артефактам разработки ПО, так и по отношению к процессу с целью выявления так называемых «системных» ошибок – ошибок процесса. Наличие ошибки процесса приводит к дефекту каждый раз, когда процесс совершается. То есть наличие системной ошибки умножает количество дефектов ПО. Чем выше коэффициент эффективность тестирования, тем лучше совершен процесс. Если эффективность тестирования 100%, то во время эксплуатации дефекты не обнаруживаются.
  • #41 Менеджер проекта – ключевая роль рабочей группы, несет ответственность за обеспечение ресурсами процесса тестирования, координацию взаимодействия работ по тестированию и исправлению выявленных дефектов и организацию разрешения спорных вопросов по проблемам. Разработчик, Технический писатель – ключевые роли рабочей группы, несут ответственность за исправление выявленных ошибок в рамках выделенных ресурсов. Конструктор – ключевая роль рабочей группы, несет ответственность за контроль целостности проектных решений в процессе исправления разработчиками выявленных дефектов и формирование способов исправления ошибок в сложных или неоднозначных ситуациях. Интегратор – ключевая роль рабочей группы, несет ответственность за контроль и выпуск версий разрабатываемого программного обеспечения в соответствии с согласованными критериями тестирования. Аналитик – ключевая роль рабочей группы, несет ответственность за установку приоритетов, связанных с необходимостью и срочностью исправления выявленных ошибок. Тестировщик – ключевая роль рабочей группы, несет ответственность за процесс тестирования в целом
  • #51 Число параметров, по которым можно производить тестирование, - огромно.
  • #56 Каждый запрос должен проходить экспертизу, обычно называемую Анализом влияния, в целях выяснения возможных последствий принятия или непринятия предлагаемого изменения. При этом нужно учитывать что: - проверка технической осуществимости может потребовать проведение экспериментов; - изменение может не соответствовать бизнес целям, а иметь новую для него ценность. - масштаб влияния изменения включает не только изменение отдельного программного элемент, но и СТПО, моделей, тестов, документации и т.п.; - стоимость выполнения изменения может включать изменение сроков проекта, стоимость приобретения дополнительного оборудования или ПО, привлечения дополнительных ресурсов и т.п.; - отклонение запроса на изменение может оказать негативное влияние на бизнес;
  • #57 Простые на первый взгляд изменения часто оказываются более сложными. При этом, чем выше уровень изменяемых требований, тем масштабней влияние изменения. ЛОВУШКА1. Часто в затраты включают только время на кодирование, забывая о тестировании, документировании и управлении проектом. Список рабочих продуктов для модификации или разработки нужно готовить в виде документа с указанием трудоемкость реализации каждого элемента. Результаты оценки влияния отдельного изменения можно представить в виде таблицы (см. слайд). Список элементов может оказаться не полным или не точным, но его наличие все равно лучше, чем отсутствие, так как он объективизирует масштаб изменений. ЛОВУШКА2. Разработчики - в основном оптимисты и часто не могут сделать реалистичные расчеты затрат. Всегда хочется показать свою "крутизну": "это пара пустяков!". Возможно, это в меньшей степени относится к работе на повременной основе (без явного определения проекта).
  • #58 В качестве организационного инструмента Управления изменениями предлагается использовать "Совет по управлению изменениями" (Change Control Board, CCB). Совет представляет собой орган, который уполномочен принимать решения об утверждении предлагаемых изменений. В его же функции входит утверждение на начальном этапе проекта базовой версии спецификаций требований. Состав, структура и полномочия Совета определяются принятым в проекте процессом контроля изменений. Функции Совета может выполнять одно лицо (например, руководитель проекта) или комитет, возглавляемый председателем, в который могут входить менеджеры, аналитики, представители заказчика, а так же различные категории разработчиков. Совет действует в интересах заказчика и руководителя проекта и создает основу для пересмотра обязательств сторон в условиях изменения требований. Даже если обязательства формально не пересматриваются, Совета обеспечивает объективные свидетельства о ходе проекта, которые в случае разбирательств могут объяснить причину неудачи.