sep reqm-lec3

Software Engineering Professional Program © 2007.

T E K A M A

Управление требованиями и изменениями

Проблема поздних изменений требований.

Процесс контроля изменений.

Практические рекомендации

3-1


T E K A M A

ВСЕ ТЕЧЕТ ...

меняется понимание заказчика того, что нужно

меняются условия в окружающей ПО системе

меняются условия в окружении бизнеса

обнаруживаются ошибки в требованиях

3-2


T E K A M A

3-3


T E K A M A

День 3. Управление изменениями требований

День 1. Требования. Спецификация требований.

День 2. Качество требований.

День 3. Управление изменениями требований

Цена изменений

Процесс изменений требований

Анализ влияния

Трассировка требований

Автоматизация управления требованиями

Экзамен

3-4


T E K A M A

Последствия поздних изменений

При позднем изменении требований

теряется уже выполненная работа и

увеличивается объем предстоящей работы

3-5


T E K A M A

Цена изменения требований

Отн

осит

ельн

ая с

тоим

ость

ис

прав

лен

ия о

шиб

ок в

тре

бов

ания

х

20

40

60

80

100

Требования ИспользованиеПроект Кодирование ТестированиеФазы разработки [Карл Видгерс]

3-6

Evgenia Vladimirskaya

Похоже, это "Количество выявляемых ошибок"? Или стоимость исправления ошибок?


T E K A M A

Контроль изменений требований

Процесс контроля изменений.

Анализ влияния.

Совет по управлению изменениями

3-7


T E K A M A

Течение нужно направлять!

При изменении требований к ПО необходимо: оценить их необходимость и последствия;

проверить согласованность с другими;

утвердить и после утверждения:

включить в проектную документацию

довести до всех участников проекта

3-8


T E K A M A

3-9


T E K A M A

Процесс контроля изменений

Принципы процесса контроля за изменениями: Этот процесс должен быть известен

Через этот процесс проходят ВСЕ изменения

Все запросы на изменения фиксируются

Наличие запроса не означает его исполнение

Каждый запрос анализируется и оценивается

Утвержденные изменения доводятся до всех

Неутвержденные изменения не исполняются

3-10


T E K A M A

Пример шаблона описания процесса контроля изменений1. Введение

1.1. Назначение

1.2. Границы

1.3. Определения

2. Роли и ответственности

3. Состояние запроса на изменение

4. Входной критерий

5. Задачи

5.1. Оценка запроса

5.2. Принятие решения

5.3. Внесение изменения

5.4. Уведомление всех задействованных лиц

6. Проверка

6.1. Проверка изменения

6.2. Установка продукта

7. Выходной критерий

8. Отчет о состоянии контроля изменений

Приложение. Элементы данных, сохраненные для каждого запроса

http://www.processimpact.com/goo-dies.shtml.

3-11


T E K A M A

3-12


T E K A M A

Возможные роли участников проекта при управлении изменениями

Председатель совета по управлению изменениями


Тот, кто оценивает изменения

Тот, кто вносит изменения

Тот, кто инициирует изменения

Получатель запроса

Тот, кто проверяет изменения

3-13


T E K A M A

Описание процесса контроля изменений

Описание процесса контроля включает:

определение области действия

категоризацию изменений

назначение ролей исполнителям

подготовку шаблонов документов

выбор состояний запроса на изменение

3-14


T E K A M A

3-15


T E K A M A

Вопросы?

3-16


T E K A M A


Запрос на изменение.

Анализ затрат.


3-17


T E K A M A

Запрос на изменение

Основные атрибуты:

Автор

Дата

Описание

Дополнительные атрибуты:

Идентификатор

Краткое название

Объект изменения

Тип запроса

Важность изменения

Дата обновления

Источник запроса

Контактная информация

3-18


T E K A M A

3-19


T E K A M A

Атрибуты запроса после его обработки

После оценки у запроса возникают новые атрибуты:

Результат анализа

Резолюция

Приоритет

Ответственный

Состояние

3-20


T E K A M A


Анализ влияния изменения включает оценку: технической осуществимости

соответствия бизнес целям

масштаба влияния

цены выполнения изменения

последствий отклонения

3-21


T E K A M A

3-22


T E K A M A

Контрольные вопросы Анализа влияния

Конфликтует ли изменение с базовыми требованиями?

Какие бизнес последствия или риски его отклонения?

Повлияет оно на производительность, другие свойства ПО?

Выполнимо оно в существующих условиях проекта?

Нужно ли что приобретать или заказывать дополнительно?

Есть ли нужные специалисты для его выполнения?

Как изменение повлияет на график проекта?

Как будет проверяться внесенное изменение?

Сколько уже сделанных затрат будет потеряно?

3-23


T E K A M A

Оценка затрат (пример 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 символов

3-24


T E K A M A

3-25


T E K A M A

Оценка затрат (пример 2)

Изменение Формы Отчеты Процедуры … Итого

Z013.Адрес Email 2 1 4,6

…

Итого 113,5

Z013. Адрес Email. Увеличить размер адреса до 50 символов

3-26


T E K A M A

Отказ от анализа влияния

Невыполнение анализа влияния, не

отменяет объем работ по реализации изменения

Просто в этом случае объем работ может стать

сюрпризом.

А сюрпризы в разработке редко бывают

приятными.

3-27


T E K A M A


Разработчик

3-28


T E K A M A

3-29


T E K A M A

Основные задачи Совета

организовать анализ влияния изменения

оценить преимущества изменения

оценить последствия изменения

принять решение

Сроки Затраты Качество Объем

CCB

Запрос наизменение

3-30


T E K A M A

3-31


T E K A M A

Вопросы?

3-32


T E K A M A


Иерархия требований.

Матрица трассировки.

Процедура трассировки

3-33


T E K A M A

Направления трассировки

Потребности заказчика

Требования

Рабочие продукты

3-34


T E K A M A

3-35


T E K A M A

Иерархия требований (пример)

Ускоритьобслуживание

клиента

Рассчитать заказ

Отправить Email с расчетом заказа

Выбрать адрес Email клиентаВставить текст расчета в EmailОтправить EmailПросмотреть ответные Email

Выбрать вид продукцииВвести параметры продукцииВыбрать материалыВыбрать работыЗадать скидкиУказать срокиСоздать шаблон расчетаИспользовать шаблон расчетаУдалить шаблон расчета..............................

Разослать рекламуклиентам Подготовить лист рассылки

3-36


T E K A M A

Связь с рабочими продуктами

Выбрать вид продукцииФорма «Расчет заказа»Форма «Вид продукции»Тест формы «Вид продукции»Тест формы «Расчет заказа»Руководство «Расчет заказа»Модель «Расчет заказа»

Ввести параметры продукции

3-37


T E K A M A

Идентификация требований и рабочих продуктов (пример)

Потребность заказчика (U)

Функциональное требование (F)

Свойство (P)

Ограничение (C)

Тест (T)

Документ (D)

Диаграмма (M)

Программный элемент (идентификатор)

3-38


T E K A M A

Пример идентификации требованийU1 Ускорить обслуживание клиента

F1 Рассчитать заказ

F1.1 Выбрать вид продукции

F1.2 Ввести параметры продукции

F1.3 Выбрать материалы

F1.4 Выбрать работы

F1.n ..............................

F2 Отправить Email с расчетом заказа

F2.1 Выбрать адрес Email клиента

F2.2 Вставить текст расчета в Email

F2.3 Отправить Email

F2.4 Просмотреть ответные Email

F3 Разослать рекламу клиентам

Fm.n ..............................

3-39


T E K A M A

Типы связей при трассировке

Источник ЦельСистемное требование Требование к ПО

Вариант использования Функциональное требование

Функциональное требование Функциональное требование

Функциональное требование Вариант использования

Функциональное требование Элемент архитектуры

Функциональное требование Элемент дизайна

Элемент дизайна Элемент кода

Бизнес правило Функциональное требование

3-40


T E K A M A

Матрица трассировки (пример 1)

Показывает связь между требованиями

и рабочими продуктами Потребность

F1.1 Выбрать вид продукции

F1.2 Ввести параметры продукции.........

F2.1 Выбрать адрес Email клиентаF2.3 Отправить Email...........

U1

U1.........

U2U2.........

ord.prod.choose()ord.prod.corr()order()order().........

email.choose()email.send()............

Функциональное требование Продукт

3-41


T E K A M A

Матрица трассировки (пример 2)

Функциональное требование

Программные элементы

FC_001 FC_013 FC_022 RP_01

F1.1

F1.2

F1.3

F1.4

F1.5

F1.6

3-42


T E K A M A

Процедура трассировки

Для определения процедуры трассировки нужно: выбрать набор трассируемых связей

выбрать тип матрицы трассировки

определить часть продукта для трассировки (важность,

сложность, рискованность)

определить способ идентификации элементов

определить роли участников процесса

подобрать инструмент для записи информации

найти способ контроля актуальность информации

3-43


T E K A M A

Мотивация трассировки

точный расчет трудозатрат

качество внесения изменений

отслеживание реализации потребностей

поиск мест изменений при адаптации продукта

выявление связанных требований и компонент

снижение риска ухода разработчика

более качественное тестирование

3-44


T E K A M A

3-45


T E K A M A

Вопросы?

3-46


T E K A M A


3-47


T E K A M A

Проблемы контроля изменений

При документальном подходе к работе

с требованиями и изменениями есть трудности:

синхронизировать изменения в разных

документах;

распространять информацию об изменениях;

определять состояние требований;

распределять требования по версиям продукта.

3-48


T E K A M A

Возможности автоматизации

Инструментальные средства управления требованиями: хранят и показывают базовые и текущие версии требований;

гибко настраивают атрибуты требований и запросов на

изменение и наборы состояний требований и изменений;

управляют доступом к информации;

генерируют уведомления об изменении состояния информации

формируют статистические отчеты;

импортируют и экспортируют требования в разных форматах;

облегчают трассировку требований;

связывают требования с элементами ПО создаваемых с

помощью других средствах разработки

3-49


T E K A M A

3-50


T E K A M A

Инструментальные средстваActive! Focus Xapware Technologies, www.x

apware.comCaliberRM Borland, www.borland.com

C.A.R.E. SOPHIST Group, www.sophist.deDOORS Telelogic, www.telelogic.comRequisitePro Rational Software, www.rational.com

RMTrak RBC, www2.rbcorp.com

RTM WIC, www.chipware.com

Slate EDS, www.eds.com

Vital Link Compliance Automation,www.complianceautomation.com

[Karl Wiegers, 2003]

3-51


T E K A M A

DOORS: Основное окно

3-52


T E K A M A

DOORS: Журнал изменений

3-53


T E K A M A

DOORS: Анализатор связей

3-54


T E K A M A

Идеал и реальность

Идеал – это сверкающий ориентир,

который своим блеском порой

мешает видеть дорогу

Виктор Кротов, философ и

писатель

3-55


T E K A M A

Практические рекомендации

Выявлять требования до программирования в

максимально возможном объеме

Фиксировать все требования, запросы на

изменение, результаты анализ влияния

Чувствовать границу между «что нужно сделать» и

«как это сделать»

Упор делать не на процессы, процедуры и

стандарты, а на принципы и результаты.

3-56


T E K A M A

Образцы документов для управления требованиями

Процесс управления требованиями

Процесс управления изменениями

Процедура проверки статуса требований

Процедура трассируемости требований

Устав совета по управлению изменениями

Список и шаблон анализа последствий изменений

в требованиях

http://www.processimpact.com/goodies.shtml

3-57


T E K A M A

Вопросы?

3-58


T E K A M A

День 3. Обзор

Цена изменений

Процесс изменений требований




3-59


T E K A M A

Основные источники К. Вигерс. Разработка требований к

программному обеспечению./ Пер. с англ. 2004.

Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный поход / Пер. с англ. - М.: 2002

SWEBOK. Guide to the Software Engineering Body of Knowledge (Область знаний программной инженерии)

IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, 1998.

3-60


T E K A M A

3-61


T E K A M A

Экзамен

SEP-REQM

“Управление требованиями”

ЭКЗАМЕН

3-62

sep reqm-lec3

Career

rational software

f2 email f2

u1 f1 f1

email u2email

email f3 fm

ieee recommendedpractice

u f p c t d

suppl 1t0020