PPT, PDF1,109 views

Sep reqm-lec3

Документ посвящен управлению требованиями и изменениям в программной инженерии, охватывая проблемы поздних изменений требований и предложенные практические рекомендации. Он описывает процесс контроля изменений, включая анализ влияния, трассировку требований и автоматизацию управления ими. Также представлены шаблоны и инструменты для эффективного управления изменениями в проекте.

Career◦

Управление требованиями и изменениями
Проблема поздних изменений требований.
Процесс контроля изменений.
Практические рекомендации

TEKAMA
Software Engineering Professional Program © 2007. 3-1

ВСЕ ТЕЧЕТ ...
 меняется понимание заказчика того, что нужно
 меняются условия в окружающей ПО системе
 меняются условия в окружении бизнеса
 обнаруживаются ошибки в требованиях

TEKAMA
Software Engineering Professional Program © 2007. 3-2

TEKAMA
Software Engineering Professional Program © 2007. 3-3

День 3. Управление изменениями
требований
День 1. Требования. Спецификация требований.
День 2. Качество требований.
День 3. Управление изменениями требований
 Цена изменений
 Процесс изменений требований
 Анализ влияния
 Трассировка требований
 Автоматизация управления требованиями
Экзамен
TEKAMA
Software Engineering Professional Program © 2007. 3-4

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

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

TEKAMA
Software Engineering Professional Program © 2007. 3-5

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

80
Относительная стоимость

60

40

20

Требования Проект Кодирование Тестирование Использование
Фазы разработки [Карл Видгерс]
TEKAMA
Software Engineering Professional Program © 2007. 3-6

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

Процесс контроля изменений.
Анализ влияния.
Совет по управлению изменениями

TEKAMA
Software Engineering Professional Program © 2007. 3-7

Течение нужно направлять!
При изменении требований к ПО необходимо:
 оценить их необходимость и последствия;
 проверить согласованность с другими;
 утвердить и после утверждения:
 включить в проектную документацию
 довести до всех участников проекта

TEKAMA
Software Engineering Professional Program © 2007. 3-8

TEKAMA
Software Engineering Professional Program © 2007. 3-9

Процесс контроля изменений
Принципы процесса контроля за изменениями:
 Этот процесс должен быть известен
 Через этот процесс проходят ВСЕ изменения
 Все запросы на изменения фиксируются
 Наличие запроса не означает его исполнение
 Каждый запрос анализируется и оценивается
 Утвержденные изменения доводятся до всех
 Неутвержденные изменения не исполняются

TEKAMA
Software Engineering Professional Program © 2007. 3-10

Пример шаблона описания процесса
контроля изменений
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.

TEKAMA
Software Engineering Professional Program © 2007. 3-11

TEKAMA
Software Engineering Professional Program © 2007. 3-12

Возможные роли участников проекта при
управлении изменениями
 Председатель совета по управлению изменениями
 Совет по управлению изменениями
 Тот, кто оценивает изменения
 Тот, кто вносит изменения
 Тот, кто инициирует изменения
 Получатель запроса
 Тот, кто проверяет изменения

TEKAMA
Software Engineering Professional Program © 2007. 3-13

Описание процесса контроля изменений
Описание процесса контроля включает:
 определение области действия
 категоризацию изменений
 назначение ролей исполнителям
 подготовку шаблонов документов
 выбор состояний запроса на изменение

TEKAMA
Software Engineering Professional Program © 2007. 3-14

TEKAMA
Software Engineering Professional Program © 2007. 3-15

Вопросы?

TEKAMA
Software Engineering Professional Program © 2007. 3-16

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

TEKAMA
Software Engineering Professional Program © 2007. 3-17

Запрос на изменение
Основные атрибуты: Дополнительные атрибуты:
 Автор  Идентификатор
 Дата  Краткое название
 Описание  Объект изменения
 Тип запроса
 Важность изменения
 Дата обновления
 Источник запроса
 Контактная информация
TEKAMA
Software Engineering Professional Program © 2007. 3-18

TEKAMA
Software Engineering Professional Program © 2007. 3-19

Атрибуты запроса после его обработки
После оценки у запроса возникают новые атрибуты:
 Результат анализа
 Резолюция
 Приоритет
 Ответственный
 Состояние

TEKAMA
Software Engineering Professional Program © 2007. 3-20

Анализ влияния
Анализ влияния изменения включает оценку:
 технической осуществимости
 соответствия бизнес целям
 масштаба влияния
 цены выполнения изменения
 последствий отклонения

TEKAMA
Software Engineering Professional Program © 2007. 3-21

TEKAMA
Software Engineering Professional Program © 2007. 3-22

Контрольные вопросы Анализа влияния
 Конфликтует ли изменение с базовыми требованиями?
 Какие бизнес последствия или риски его отклонения?
 Повлияет оно на производительность, другие свойства ПО?
 Выполнимо оно в существующих условиях проекта?
 Нужно ли что приобретать или заказывать дополнительно?
 Есть ли нужные специалисты для его выполнения?
 Как изменение повлияет на график проекта?
 Как будет проверяться внесенное изменение?
 Сколько уже сделанных затрат будет потеряно?

TEKAMA
Software Engineering Professional Program © 2007. 3-23

Оценка затрат (пример 1)
Z013. Адрес Email. Увеличить размер адреса до 50 символов
Тип элемента Название элементов Трудоемкость

Формы 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
TEKAMA
Software Engineering Professional Program © 2007. 3-24

TEKAMA
Software Engineering Professional Program © 2007. 3-25

Оценка затрат (пример 2)
Z013. Адрес Email. Увеличить размер адреса до 50 символов

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

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

…

Итого 113,5

TEKAMA
Software Engineering Professional Program © 2007. 3-26

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

Невыполнение анализа влияния, не
отменяет объем работ по реализации изменения

Просто в этом случае объем работ может стать
сюрпризом.
А сюрпризы в разработке редко бывают
приятными.

TEKAMA
Software Engineering Professional Program © 2007. 3-27

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

Разработчик

TEKAMA
Software Engineering Professional Program © 2007. 3-28

TEKAMA
Software Engineering Professional Program © 2007. 3-29

Основные задачи Совета
 организовать анализ влияния изменения
 оценить преимущества изменения
 оценить последствия изменения
 принять решение
Запрос на
изменение
CCB

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

TEKAMA
Software Engineering Professional Program © 2007. 3-30

TEKAMA
Software Engineering Professional Program © 2007. 3-31

Вопросы?

TEKAMA
Software Engineering Professional Program © 2007. 3-32

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

Иерархия требований.
Матрица трассировки.
Процедура трассировки

TEKAMA
Software Engineering Professional Program © 2007. 3-33

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

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

Требования

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

TEKAMA
Software Engineering Professional Program © 2007. 3-34

TEKAMA
Software Engineering Professional Program © 2007. 3-35

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

Выбрать адрес Email клиента
Отправить Email с Вставить текст расчета в Email
расчетом заказа Отправить Email
Просмотреть ответные Email
Разослать рекламу
клиентам Подготовить лист рассылки
TEKAMA
Software Engineering Professional Program © 2007. 3-36

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

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

TEKAMA
Software Engineering Professional Program © 2007. 3-37

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

 Потребность заказчика (U)
 Функциональное требование (F)
 Свойство (P)
 Ограничение (C)
 Тест (T)
 Документ (D)
 Диаграмма (M)
 Программный элемент (идентификатор)

TEKAMA
Software Engineering Professional Program © 2007. 3-38

Пример идентификации требований
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 ..............................

TEKAMA
Software Engineering Professional Program © 2007. 3-39

Типы связей при трассировке
Источник Цель
Системное требование Требование к ПО
Вариант использования Функциональное требование
Функциональное требование Функциональное требование

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

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

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

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

TEKAMA
Software Engineering Professional Program © 2007. 3-40

Матрица трассировки (пример 1)
Показывает связь между требованиями
и рабочими продуктами
Функциональное требование Потребность Продукт

F1.1 Выбрать вид продукции U1 ord.prod.choose()
ord.prod.corr()
order()
F1.2 Ввести параметры продукции U1 order()
......... ......... .........

F2.1 Выбрать адрес Email клиента U2 email.choose()
F2.3 Отправить Email U2 email.send()
........... ......... ............

TEKAMA
Software Engineering Professional Program © 2007. 3-41

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

Функциональное
Программные элементы
требование
FC_001 FC_013 FC_022 RP_01

F1.1 ↵
F1.2 ↵
F1.3
F1.4
F1.5 ↵ ↵
F1.6

TEKAMA
Software Engineering Professional Program © 2007. 3-42

Процедура трассировки
Для определения процедуры трассировки нужно:
 выбрать набор трассируемых связей
 выбрать тип матрицы трассировки
 определить часть продукта для трассировки (важность,
сложность, рискованность)
 определить способ идентификации элементов
 определить роли участников процесса
 подобрать инструмент для записи информации
 найти способ контроля актуальность информации

TEKAMA
Software Engineering Professional Program © 2007. 3-43

Мотивация трассировки
 точный расчет трудозатрат
 качество внесения изменений
 отслеживание реализации потребностей
 поиск мест изменений при адаптации продукта
 выявление связанных требований и компонент
 снижение риска ухода разработчика
 более качественное тестирование

TEKAMA
Software Engineering Professional Program © 2007. 3-44

TEKAMA
Software Engineering Professional Program © 2007. 3-45

Вопросы?

TEKAMA
Software Engineering Professional Program © 2007. 3-46

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

TEKAMA
Software Engineering Professional Program © 2007. 3-47

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

 синхронизировать изменения в разных
документах;
 распространять информацию об изменениях;
 определять состояние требований;
 распределять требования по версиям продукта.
TEKAMA
Software Engineering Professional Program © 2007. 3-48

Возможности автоматизации
Инструментальные средства управления требованиями:
 хранят и показывают базовые и текущие версии требований;
 гибко настраивают атрибуты требований и запросов на
изменение и наборы состояний требований и изменений;
 управляют доступом к информации;
 генерируют уведомления об изменении состояния информации
 формируют статистические отчеты;
 импортируют и экспортируют требования в разных форматах;
 облегчают трассировку требований;
 связывают требования с элементами ПО создаваемых с
помощью других средствах разработки

TEKAMA
Software Engineering Professional Program © 2007. 3-49

TEKAMA
Software Engineering Professional Program © 2007. 3-50

Инструментальные средства
Active! Focus Xapware Technologies, www.x
apware.com
CaliberRM Borland, www.borland.com
C.A.R.E. SOPHIST Group, www.sophist.de
DOORS Telelogic, www.telelogic.com
RequisitePro 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]
TEKAMA
Software Engineering Professional Program © 2007. 3-51

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

TEKAMA
Software Engineering Professional Program © 2007. 3-52

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

TEKAMA
Software Engineering Professional Program © 2007. 3-53

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

TEKAMA
Software Engineering Professional Program © 2007. 3-54

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

Идеал – это сверкающий ориентир,
который своим блеском порой
мешает видеть дорогу

Виктор Кротов, философ и писатель

TEKAMA
Software Engineering Professional Program © 2007. 3-55

Практические рекомендации
 Выявлять требования до программирования в
максимально возможном объеме
 Фиксировать все требования, запросы на
изменение, результаты анализ влияния
 Чувствовать границу между «что нужно сделать» и
«как это сделать»
 Упор делать не на процессы, процедуры и
стандарты, а на принципы и результаты.

TEKAMA
Software Engineering Professional Program © 2007. 3-56

Образцы документов для управления
требованиями
 Процесс управления требованиями
 Процесс управления изменениями
 Процедура проверки статуса требований
 Процедура трассируемости требований
 Устав совета по управлению изменениями
 Список и шаблон анализа последствий изменений
в требованиях

http://www.processimpact.com/goodies.shtml
TEKAMA
Software Engineering Professional Program © 2007. 3-57

Вопросы?

TEKAMA
Software Engineering Professional Program © 2007. 3-58

День 3. Обзор
 Цена изменений
 Процесс изменений требований
 Анализ влияния
 Трассировка требований
 Автоматизация управления требованиями

TEKAMA
Software Engineering Professional Program © 2007. 3-59

Основные источники
 К. Вигерс. Разработка требований к
программному обеспечению./ Пер. с англ.
2004.
 Д. Леффингуэлл, Д. Уидриг. Принципы работы
с требованиями к программному обеспечению.
Унифицированный поход / Пер. с англ. - М.:
2002
 SWEBOK. Guide to the Software Engineering
Body of Knowledge (Область знаний
программной инженерии)
 IEEE Std 830-1998, IEEE Recommended
Practice for Software Requirements
Specifications, 1998.
TEKAMA
Software Engineering Professional Program © 2007. 3-60

TEKAMA
Software Engineering Professional Program © 2007. 3-61

Экзамен

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

ЭКЗАМЕН

TEKAMA
Software Engineering Professional Program © 2007. 3-62

Sep reqm-lec3

1.
Управление требованиями иизменениями Проблема поздних изменений требований. Процесс контроля изменений. Практические рекомендации TEKAMA Software Engineering Professional Program © 2007. 3-1
2.
ВСЕ ТЕЧЕТ ... меняется понимание заказчика того, что нужно  меняются условия в окружающей ПО системе  меняются условия в окружении бизнеса  обнаруживаются ошибки в требованиях TEKAMA Software Engineering Professional Program © 2007. 3-2
4.
День 3. Управлениеизменениями требований День 1. Требования. Спецификация требований. День 2. Качество требований. День 3. Управление изменениями требований  Цена изменений  Процесс изменений требований  Анализ влияния  Трассировка требований  Автоматизация управления требованиями Экзамен TEKAMA Software Engineering Professional Program © 2007. 3-4
5.
Последствия поздних изменений При позднем изменении требований теряется уже выполненная работа и увеличивается объем предстоящей работы TEKAMA Software Engineering Professional Program © 2007. 3-5
6.
Цена изменения требований 100 исправления ошибок в требованиях 80 Относительная стоимость 60 40 20 Требования Проект Кодирование Тестирование Использование Фазы разработки [Карл Видгерс] TEKAMA Software Engineering Professional Program © 2007. 3-6
7.
Контроль изменений требований Процесс контроля изменений. Анализ влияния. Совет по управлению изменениями TEKAMA Software Engineering Professional Program © 2007. 3-7
8.
Течение нужно направлять! Приизменении требований к ПО необходимо:  оценить их необходимость и последствия;  проверить согласованность с другими;  утвердить и после утверждения:  включить в проектную документацию  довести до всех участников проекта TEKAMA Software Engineering Professional Program © 2007. 3-8
10.
Процесс контроля изменений Принципыпроцесса контроля за изменениями:  Этот процесс должен быть известен  Через этот процесс проходят ВСЕ изменения  Все запросы на изменения фиксируются  Наличие запроса не означает его исполнение  Каждый запрос анализируется и оценивается  Утвержденные изменения доводятся до всех  Неутвержденные изменения не исполняются TEKAMA Software Engineering Professional Program © 2007. 3-10
11.
Пример шаблона описанияпроцесса контроля изменений 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. TEKAMA Software Engineering Professional Program © 2007. 3-11
13.
Возможные роли участниковпроекта при управлении изменениями  Председатель совета по управлению изменениями  Совет по управлению изменениями  Тот, кто оценивает изменения  Тот, кто вносит изменения  Тот, кто инициирует изменения  Получатель запроса  Тот, кто проверяет изменения TEKAMA Software Engineering Professional Program © 2007. 3-13
14.
Описание процесса контроляизменений Описание процесса контроля включает:  определение области действия  категоризацию изменений  назначение ролей исполнителям  подготовку шаблонов документов  выбор состояний запроса на изменение TEKAMA Software Engineering Professional Program © 2007. 3-14
17.
Анализ влияния Запрос на изменение. Анализ затрат. Совет по управлению изменениями TEKAMA Software Engineering Professional Program © 2007. 3-17
18.
Запрос на изменение Основныеатрибуты: Дополнительные атрибуты:  Автор  Идентификатор  Дата  Краткое название  Описание  Объект изменения  Тип запроса  Важность изменения  Дата обновления  Источник запроса  Контактная информация TEKAMA Software Engineering Professional Program © 2007. 3-18
20.
Атрибуты запроса послеего обработки После оценки у запроса возникают новые атрибуты:  Результат анализа  Резолюция  Приоритет  Ответственный  Состояние TEKAMA Software Engineering Professional Program © 2007. 3-20
21.
Анализ влияния Анализ влиянияизменения включает оценку:  технической осуществимости  соответствия бизнес целям  масштаба влияния  цены выполнения изменения  последствий отклонения TEKAMA Software Engineering Professional Program © 2007. 3-21
23.
Контрольные вопросы Анализавлияния  Конфликтует ли изменение с базовыми требованиями?  Какие бизнес последствия или риски его отклонения?  Повлияет оно на производительность, другие свойства ПО?  Выполнимо оно в существующих условиях проекта?  Нужно ли что приобретать или заказывать дополнительно?  Есть ли нужные специалисты для его выполнения?  Как изменение повлияет на график проекта?  Как будет проверяться внесенное изменение?  Сколько уже сделанных затрат будет потеряно? TEKAMA Software Engineering Professional Program © 2007. 3-23
24.
Оценка затрат (пример1) Z013. Адрес Email. Увеличить размер адреса до 50 символов Тип элемента Название элементов Трудоемкость Формы 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 TEKAMA Software Engineering Professional Program © 2007. 3-24
26.
Оценка затрат (пример2) Z013. Адрес Email. Увеличить размер адреса до 50 символов Изменение Формы Отчеты Процедуры … Итого Z013.Адрес Email 2 1 4,6 … Итого 113,5 TEKAMA Software Engineering Professional Program © 2007. 3-26
27.
Отказ от анализавлияния Невыполнение анализа влияния, не отменяет объем работ по реализации изменения Просто в этом случае объем работ может стать сюрпризом. А сюрпризы в разработке редко бывают приятными. TEKAMA Software Engineering Professional Program © 2007. 3-27
30.
Основные задачи Совета организовать анализ влияния изменения  оценить преимущества изменения  оценить последствия изменения  принять решение Запрос на изменение CCB Сроки Затраты Качество Объем TEKAMA Software Engineering Professional Program © 2007. 3-30
33.
Трассировка требований Иерархия требований. Матрица трассировки. Процедура трассировки TEKAMA Software Engineering Professional Program © 2007. 3-33
34.
Направления трассировки Потребности заказчика Требования Рабочие продукты TEKAMA Software Engineering Professional Program © 2007. 3-34
36.
Иерархия требований (пример) Выбрать вид продукции Рассчитать заказ Ввести параметры продукции Выбрать материалы Выбрать работы Ускорить Задать скидки обслуживание Указать сроки клиента Создать шаблон расчета Использовать шаблон расчета Удалить шаблон расчета .............................. Выбрать адрес Email клиента Отправить Email с Вставить текст расчета в Email расчетом заказа Отправить Email Просмотреть ответные Email Разослать рекламу клиентам Подготовить лист рассылки TEKAMA Software Engineering Professional Program © 2007. 3-36
37.
Связь с рабочимипродуктами Выбрать вид продукции Форма «Расчет заказа» Форма «Вид продукции» Тест формы «Вид продукции» Тест формы «Расчет заказа» Руководство «Расчет заказа» Модель «Расчет заказа» Ввести параметры продукции TEKAMA Software Engineering Professional Program © 2007. 3-37
38.
Идентификация требований и рабочихпродуктов (пример)  Потребность заказчика (U)  Функциональное требование (F)  Свойство (P)  Ограничение (C)  Тест (T)  Документ (D)  Диаграмма (M)  Программный элемент (идентификатор) TEKAMA Software Engineering Professional Program © 2007. 3-38
39.
Пример идентификации требований 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 .............................. TEKAMA Software Engineering Professional Program © 2007. 3-39
40.
Типы связей притрассировке Источник Цель Системное требование Требование к ПО Вариант использования Функциональное требование Функциональное требование Функциональное требование Функциональное требование Вариант использования Функциональное требование Элемент архитектуры Функциональное требование Элемент дизайна Элемент дизайна Элемент кода Бизнес правило Функциональное требование TEKAMA Software Engineering Professional Program © 2007. 3-40
41.
Матрица трассировки (пример1) Показывает связь между требованиями и рабочими продуктами Функциональное требование Потребность Продукт F1.1 Выбрать вид продукции U1 ord.prod.choose() ord.prod.corr() order() F1.2 Ввести параметры продукции U1 order() ......... ......... ......... F2.1 Выбрать адрес Email клиента U2 email.choose() F2.3 Отправить Email U2 email.send() ........... ......... ............ TEKAMA Software Engineering Professional Program © 2007. 3-41
42.
Матрица трассировки (пример2) Функциональное Программные элементы требование FC_001 FC_013 FC_022 RP_01 F1.1 ↵ F1.2 ↵ F1.3 F1.4 F1.5 ↵ ↵ F1.6 TEKAMA Software Engineering Professional Program © 2007. 3-42
43.
Процедура трассировки Для определенияпроцедуры трассировки нужно:  выбрать набор трассируемых связей  выбрать тип матрицы трассировки  определить часть продукта для трассировки (важность, сложность, рискованность)  определить способ идентификации элементов  определить роли участников процесса  подобрать инструмент для записи информации  найти способ контроля актуальность информации TEKAMA Software Engineering Professional Program © 2007. 3-43
44.
Мотивация трассировки  точныйрасчет трудозатрат  качество внесения изменений  отслеживание реализации потребностей  поиск мест изменений при адаптации продукта  выявление связанных требований и компонент  снижение риска ухода разработчика  более качественное тестирование TEKAMA Software Engineering Professional Program © 2007. 3-44
48.
Проблемы контроля изменений Придокументальном подходе к работе с требованиями и изменениями есть трудности:  синхронизировать изменения в разных документах;  распространять информацию об изменениях;  определять состояние требований;  распределять требования по версиям продукта. TEKAMA Software Engineering Professional Program © 2007. 3-48
49.
Возможности автоматизации Инструментальные средствауправления требованиями:  хранят и показывают базовые и текущие версии требований;  гибко настраивают атрибуты требований и запросов на изменение и наборы состояний требований и изменений;  управляют доступом к информации;  генерируют уведомления об изменении состояния информации  формируют статистические отчеты;  импортируют и экспортируют требования в разных форматах;  облегчают трассировку требований;  связывают требования с элементами ПО создаваемых с помощью других средствах разработки TEKAMA Software Engineering Professional Program © 2007. 3-49
51.
Инструментальные средства Active! Focus Xapware Technologies, www.x apware.com CaliberRM Borland, www.borland.com C.A.R.E. SOPHIST Group, www.sophist.de DOORS Telelogic, www.telelogic.com RequisitePro 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] TEKAMA Software Engineering Professional Program © 2007. 3-51
55.
Идеал и реальность Идеал – это сверкающий ориентир, который своим блеском порой мешает видеть дорогу Виктор Кротов, философ и писатель TEKAMA Software Engineering Professional Program © 2007. 3-55
56.
Практические рекомендации  Выявлятьтребования до программирования в максимально возможном объеме  Фиксировать все требования, запросы на изменение, результаты анализ влияния  Чувствовать границу между «что нужно сделать» и «как это сделать»  Упор делать не на процессы, процедуры и стандарты, а на принципы и результаты. TEKAMA Software Engineering Professional Program © 2007. 3-56
57.
Образцы документов дляуправления требованиями  Процесс управления требованиями  Процесс управления изменениями  Процедура проверки статуса требований  Процедура трассируемости требований  Устав совета по управлению изменениями  Список и шаблон анализа последствий изменений в требованиях http://www.processimpact.com/goodies.shtml TEKAMA Software Engineering Professional Program © 2007. 3-57
59.
День 3. Обзор Цена изменений  Процесс изменений требований  Анализ влияния  Трассировка требований  Автоматизация управления требованиями TEKAMA Software Engineering Professional Program © 2007. 3-59
60.
Основные источники  К.Вигерс. Разработка требований к программному обеспечению./ Пер. с англ. 2004.  Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный поход / Пер. с англ. - М.: 2002  SWEBOK. Guide to the Software Engineering Body of Knowledge (Область знаний программной инженерии)  IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, 1998. TEKAMA Software Engineering Professional Program © 2007. 3-60

Editor's Notes

#3 Трудно себе представить ПО, созданное для решения реальных задач, которое не меняется в процессе жизненного цикла. Желания (&quot;аппетиты&quot;) заказчиков растут во время использования ПО. Меняются бизнес процессы заказчика, адаптируясь к внешним условиям. Меняются сами эти условия в форме законов, стандартов, рыночных условий В ходе реализации требований обнаруживаются ошибки в самих требованиях к ПО. Разработчики - любезные люди и им часто трудно отказать симпатичному «юзеру» и не сделать программу более удобной. Сильно увеличивает поток изменений следование принципам &quot;Клиент всегда прав&quot; и &quot;Чего изволите...&quot;.
#4 ЛОВУШКА . Часто неправильно толкуется принцип &quot;изменяемости&quot; требований. Что является поводом отказа от выявления требований до начала программирования (&quot;все равно они будут изменяться&quot;). Принцип &quot;изменяемости&quot; не отменяет принцип &quot;выявления ” требований до начала программирования, отказ от которого лишает разработку целенаправленности. Верным признаком отсутствия ясно сформулированных требований является включение некоторой функциональности в продукт, затем ее исключение, а затем снова включение (&quot;тасование&quot;).
#6 Подготовленная в процессе определения требований и утвержденная СТПО представляет базовую версии требований ( baseline ). Все ее изменения считаются незапланированными. Чем слабее базовая версия, тем больше будет расти объем проекта. Люди не любят говорить или слышать слова &quot;Нет!&quot;. Поэтому, в ходе разработки легко собрать большой пакет изменений. Их принятие приводит в долговременной перспективе к срыву сроков, снижению качества продукта. Создается ощущение, что проект никогда не будет завершен. При этом, размываются обязательства, возникают споры, стресс у разработчиков и неудовлетворенность того же клиента. Основные методы борьбы с этим - более полное и точное выявление базовых требований и включение предлагаемых изменений в версию продукта для следующего проекта. В работе с изменениями важнейшим качеством разработчиков является умение отказать клиенту. Лучшей формой отказа является фраза &quot;Конечно да, но не сейчас...&quot;. В идеале все требования собираются и &quot;замораживаются&quot; до начала разработки (модель разработки типа &quot;водопад&quot;). Но на практике так не бывает, и изменения происходят. Но если в какой-то момент требования не &quot;заморозить&quot;, то результата не будет вовсе. Здесь нужно искать золотую середину!
#9 В процессе формирования требований и приступая к разработке необходимо позаботиться об управлении изменениями в предположении, что потребуется: оценка влияния изменения на бизнес и проект, согласование с другими требованиями, взвешенное одобрение, включение изменения в СТПО и доведение изменения до сведения участников проекта Каждое изменение имеет цену. Любое изменение требований влияет как на бизнес, так и на проект. Влияние на бизнес обычно положительное (преимущества, удобства), а влияние на проект - отрицательное (сроки, стоимость). В частном случае она может быть отрицательной если предлагаемое изменения сокращает срок или стоимость разработки. Оценить влияние изменений может только человек (developer sapiens!). Новые изменения могут вступать в противоречие с ранее утвержденными требованиями. В этом случае потребуется разрешать конфликты.
#10 Одобрение изменения должно осуществляться ответственным лицом (лучше всего коллегиальным органом), в обязанности которого входит разрешение конфликтов требований, а также проверка проектной оценки изменения и соотнесение оценки его влияния на бизнес с бизнес целями проекта. СТПО всегда должна представлять актуальное представление о продукте. Ценность не актуальной СТПО быстро снижается и команда начинает работать, как будто вообще нет никакой спецификации («Зря на нее потратились!»). Если вносить изменения сразу в код, описание продукта становиться не точным, а изменяемый код - более уязвимым (&quot;хрупким&quot;). Так, спецификация становиться дезинформацией, процесс тестирования не полным, становится возможным дублирование кода. Итог - снижение эффективности работы команды. ЛОВУШКА . Наивно полагать, что проект будет успешным, если в продукт постоянно включается все больше функциональности, а проект ограничен сроками, кадрами, бюджетом и требованиями к качеству.
#11 Изменения происходят под управлением определенного процесса протекающего в соответствии с принципами, указанными на слайде. Заказчикам процесс контроля за изменениями не нравиться. Однако, правильно организованный процесс контроля является не препятствием, а средством фильтрации и накопления полезной информации и обеспечивает внесение наиболее ценных изменений, откладывая менее ценные &quot;на потом&quot;. Процесс контроля позволяет руководителю проекта принимать правильные проектные решения, взвешивая коммерческую (бизнес) ценность продукта и затраты, и делает разработку более управляемой. ЛОВУШКА . Часто заказчик обращается с просьбой об изменении к высшему руководству компании разработчика или непосредственно к программисту, минуя руководителя, отвечающего за проект (&quot;Он, слишком часто говорит: Нет!&quot;). Это прямой путь к потере контроля над проектом.
#12 Полезно включить следующие четыре компонента во все процедуры и описания процесса : входной критерий — условия , которые должны быть удовлетворены до выполнения процесса или процедуры ; различные задачи , задействованные в процессе или процедуре , участник проекта , отвечающий за выполнение каждой задачи , и другие лица , принимающие участие в выполнении задачи ; последовательные действия для подтверждения того , что задачи были выполнены правильно ; выходной критерий — условия , указывающие , когда процесс или процедура считаются успешно завершенными . 1. Введение Во введении описывается назначение процесса и определяются организационные границы , в которых он применяется . Если этот процесс затрагивает только изменения в определенных продуктах , их следует определить здесь . Также укажите , существуют ли какие - то специальные виды изменений , которые не подлежат контролю , например изменения в промежуточных или служебных продуктах , созданных в ходе проекта . В разделе 1.3 определите все термины , необходимые для понимания остальной информации . 2. Роли и ответственности Перечислите членов команды — по ролям , не по именам , которые участвуют в процессе контроля изменений , и опишите их обязанности , в табл . далее приведены некоторые типичные роли ; адаптируйте их в соответствии с конкретной ситуацией . Каждый человек может выполнять несколько ролей . Например , председатель совета по управлению изменениями также может получать подаваемые запросы на изменения . В небольших проектах несколько , а возможно , и все роли выполняются одним человеком . 3. Состояние запроса на изменение Запрос на изменение проходит через определенные стадии на протяжении жизненного цикла , причем на каждой стадии он имеет различные статусы . Вы можете представить эти изменения состояния , используя диаграмму перехода состояний , как показано на рис . 19-2. Обновляйте состояние запроса , только когда удовлетворяются определенные критерии . 4. Входной критерий Основным входным критерием для процесса контроля изменений является действительный запрос на изменение , полученный по утвержденным каналам . Все потенциальные инициаторы запросов должны знать , как подавать запросы на изменение , независимо от того , отправляют они его , заполняя бумажную форму или Web -форму , отправляя сообщение по электронной почте или используя средство контроля изменений . Назначьте каждому запросу на изменение уникальный идентификатор и направьте их всех к единой точке контакта — получателю запроса .
#13 5. Задачи Следующий шаг — это оценка запроса на предмет технической выполнимости , затрат и соответствия бизнес - требованиям проекта и ограничениям ресурсов . Председатель совета по управлению изменениями может назначить сотрудника для оценки влияния изменения , анализа риска , анализа опасности и др . Анализ позволяет убедиться , что вероятные последствия изменения ясны . Тот , кому поручена оценка , и члены совета по управлению изменениями должны также рассмотреть коммерческие и технические последствия отклонения изменения . Затем уполномоченные члены совета по управлению изменениями решают , утвердить или отклонить запрошенное изменение . Совет по управлению изменениями присваивает каждому одобренному изменению уровень приоритета , или назначает дату реализации , или назначает это изменение определенной сборке или номеру версии . Далее совет по управлению изменениями оповещает о решении , обновляя состояние запроса или уведомляя всех членов команды , которые занимаются модификацией . После этого необходимо обновить : документацию требований , описание дизайна и моделей , компоненты пользовательского интерфейса , код , документацию тестирования , экраны справки и руководства для пользователей . Тот , кто вносит изменения , делает это установленным путем . 6. Проверка Изменения требования , как правило , проверяют с помощью экспертной оценки , чтобы убедиться , что измененные требования , варианты использования и модели соответствующим образом отражают все аспекты изменения . Информация о трассируемости поможет вам найти все части системы , которые это изменение затрагивает и которые , как следствие , необходимо проверить . Поручите нескольким членам команды проверить изменения с помощью тестирования или экспертизы . После этих процедур тот , кто занимается проверкой , устанавливает обновленные продукты , сделав их доступными остальным членам команды , и переопределяет базовую версию , в которой учтены изменения . 7. Выходной критерий Все перечисленные далее выходные критерии должны быть удовлетворены , чтобы должным образом завершить процесс управления изменениями : 1 состояние запроса : Rejected (Отклонено ), Closed (Закрыто ) или Canceled (Отменено ); 1 все изменения записаны в соответствующих разделах ; 1 инициатор запроса , председатель совета по управлению изменениями , менеджер проекта и другие значимые участники проекта оповещены о деталях изменения и текущем состоянии запроса на изменение ; I матрица связей требований обновлена . ( В главе 20 о трассируемости требований рассказано более подробно .) 8. Отчет о состоянии управления изменения Определите графики и отчеты , которые вы будет использовать при обобщении содержимого базы данных контроля изменений . Обычно на этих графиках показано количество запросов на изменение в каждой категории состояния как функция времени . Опишите процедуры создания графиков и отчетов . Менеджер проекта использует эти отчеты при контроле состояния проекта . Приложение . Элементы данных , сохраненные для каждого запроса В табл . 19-2 перечислены некоторые элементы данных , которые можно сохранить для каждого запросе на изменение . После определения своего собственного списка , укажите , какие элементы следует сохранять обязательно , а какие нет . Также укажите , устанавливается ли значение для каждого элемента автоматически средством контроля изменений или вручную одним из участников процесса управления изменениями .
#14 Председатель совета , по управлению измене ниями Возглавляет совет по управлению изменениями ; как правило обладает правом принятия окончательного решения , если совет не приходит к согласию ; выбирает тех , кто оценивает и вносит изменения для каждого запроса на изменение Совет по управлению изменениями Группа , принимающее решение утвердить или отклонить каждое предложенное изменение для определенного прооекта Тот , кто оценивает изменение Человек , которого председатель совета просит проанализировать влияние предложенного изменения ; это может быть сотрудник технического отдела , клиент , маркетолог или сотрудник , занимающийся всем этим понемногу Тот , кто вносит изменение Отвечает за внесение изменений в продукт , когда запрос на изменение утвержден Тот , кто инициирует запрос Некто , подающий новый запрос на изменение Получатель запроса Лицо , которому передаются новые запросы на изменение Тот , кто проверяет изменение Человек , определяющий , корректно ли выполнено изменение
#15 Процесс контроля изменений желательно описать, утвердить и донести до каждого разработчика. Описание процесса контроля включает: Определение области действия. Процесс контроля не обязательно должен быть всеобъемлющим. Он может касаться некоторой части продукта, отдельного проекта, подразделения или всей организации. Он может также распространяться на определенные этапы жизненного цикла ПО. Категории изменений. Процесс контроля могут проходить абсолютно все изменения, изменения после утверждения базовой версии требований, только изменения предлагаемые пользователями. Определить категорию изменений можно исключением (например, &quot;кроме служебных программ&quot;). Роли исполнителей. Для того, чтобы процесс работал, необходимо определить персонально, кто в нем участвует и в какой роли. Примеры ролей: Ответственный за процесс, Регистратор запросов, Оценивающий влияние, Вносящий изменения и т.п.
#16 Шаблоны документов. Поскольку процесс контроля изменений является чисто человеческой деятельностью, то полезно определить форму и содержание документов его сопровождающих. К таким документам относятся: «Запрос на изменение», «Отчет об анализе влияния» и т.п. Состояние запроса. «Запрос на изменение» является основным обязательным документом, сопровождающим процесс контроля. В своем жизненном цикле он может иметь следующий набор состояний: «Получен», «Оценен», «Отклонен», «Одобрен», «Внесен в требования».
#19 Основным инструментом в процессе контроля за изменениями является документ, обычно называемый &quot;Запрос на изменение&quot; ( change request ). Основной минимальный набор атрибутов запроса на изменение следующий: Автор - кто инициировал запрос (запрос не может быть анонимным) Дата - когда запрос подан (это важно при разборках типа «почему не выполнен») Описание - описание сути предлагаемого изменения. Требования к описанию сути изменения такие же, как и для отдельного требования. В качестве дополнительных атрибутов запрос на изменение может иметь: Идентификатор или номер (для точных формальных ссылок). Краткое название изменения (для содержательных ссылок). Объект изменения – идентификатор требования, продукта или его части.
#20 Тип запроса : «добавление», «исправление», «исключение требования» (для анализа проекта) Важность изменения с точки зрения автора (для определения приоритетов) Дата обновления , если исходный запрос в процессе анализа был скорректирован Источник – категория и имя автора (клиент, маркетолог, разработчик ...) Контактная информация автора (для больших проектов).
#21 После прохождения процедуры анализа влияния и рассмотрения у запроса возникают другие атрибуты: Результат анализа влияния изменения на бизнес и проект Резолюция – решение ответственного органа (лица) по данному запросу Приоритет реализации запроса Ответственный за внесение изменения в СТПО и его доведение до исполнителей Состояние запроса по результатам рассмотрения Значения дополнительным атрибутам присваивается лицом, исполняющим роль Регистратора запросов. В процессе контроля изменений в команде проекта эта роль может выполняться любым членом команды разработчиков (но обязательно одним), который координирует обработку изменений. Для обработки запросов хорошо использовать базу данных, которая облегчает его заполнение, прохождение и распространение.
#22 Каждый запрос должен проходить экспертизу, обычно называемую Анализом влияния , в целях выяснения возможных последствий принятия или непринятия предлагаемого изменения. При этом нужно учитывать что: - проверка технической осуществимости может потребовать проведение экспериментов; - изменение может не соответствовать бизнес целям, а иметь новую для него ценность. - масштаб влияния изменения включает не только изменение отдельного программного элемент, но и СТПО, моделей, тестов, документации и т.п.; - стоимость выполнения изменения может включать изменение сроков проекта, стоимость приобретения дополнительного оборудования или ПО, привлечения дополнительных ресурсов и т.п.; - отклонение запроса на изменение может оказать негативное влияние на бизнес;
#23 В общем случае, влияние изменения на проект может иметь и положительное влияние («отрицательную» стоимость), если его принятие сокращает сроки разработки, снижает потребность проекта в ресурсах (люди, оборудование, ПО). В процессе Анализа влияния выявляются компоненты, которые нужно создать или изменить и оцениваются затраты на это. Одно изменение может вызвать лавину переделок, включение новых функций может снизить производительность и т.п. Для анализа последствий принятия изменений полезно использовать список контрольных вопросов. На следующем слайде приведен пример контрольного списка вопросов для анализа влияния изменений.
#24 Список контрольных вопросов нужно адаптировать к условиям разработки с учетом особенностей разрабатываемого ПО и используемых технологий.
#25 Простые на первый взгляд изменения часто оказываются более сложными. При этом, чем выше уровень изменяемых требований, тем масштабней влияние изменения. ЛОВУШКА1 . Часто в затраты включают только время на кодирование, забывая о тестировании, документировании и управлении проектом. Список рабочих продуктов для модификации или разработки нужно готовить в виде документа с указанием трудоемкость реализации каждого элемента. Результаты оценки влияния отдельного изменения можно представить в виде таблицы (см. слайд). Список элементов может оказаться не полным или не точным, но его наличие все равно лучше, чем отсутствие, так как он объективизирует масштаб изменений. ЛОВУШКА2 . Разработчики - в основном оптимисты и часто не могут сделать реалистичные расчеты затрат. Всегда хочется показать свою &quot;крутизну&quot;: &quot;это пара пустяков!&quot;. Возможно, это в меньшей степени относится к работе на повременной основе (без явного определения проекта).
#26 В этой связи для оценки трудоемкости лучше использовать некоторые «нормативы», основанные на опыте конкретной организации, команды проекта или отдельного разработчика. Используя списки рабочих продуктов с оценкой трудозатрат можно сравнивать реальные затраты с запланированными и вырабатывать соответствующие «нормативы». Такая информация создает почву для более адекватного планирования в будущем.
#27 Если одновременно анализируется влияние нескольких изменений, то сводные результаты оценки трудозатрат на выполнение нескольких изменений можно представить в виде другой таблицы с колонками: “ Изменение” - код и название предлагаемого изменения; “ Формы” - трудозатраты на разработку или модификацию экранных форм; “ Отчеты” - трудозатраты на разработку или модификацию отчетов; “ Процедуры” трудозатраты на разработку или модификацию процедур или классов и т.п. тестировании, документировании и управлении проектом.
#28 Анализа влияния изменения может потребовать от несколько часов до нескольких дней. Альтернативой Анализу влияния являются несколько минут размышлений и резолюции типа &quot;Нет проблем&quot;, &quot;И так все ясно&quot;, &quot;Думаю, это не займет много времени&quot;. Правильные расчеты являются основой управления ожиданиями заказчиков, а неправильные расчеты ведут к потере его доверия. Долго ожидая быстро обещанных результатов, он может вообще отказаться от изменений и, соответственно, их оплаты.
#29 В качестве организационного инструмента Управления изменениями предлагается использовать &quot;Совет по управлению изменениями&quot; (Change Control Board, CCB). Совет представляет собой орган, который уполномочен принимать решения об утверждении предлагаемых изменений. В его же функции входит утверждение на начальном этапе проекта базовой версии спецификаций требований. Состав, структура и полномочия Совета определяются принятым в проекте процессом контроля изменений. Функции Совета может выполнять одно лицо (например, руководитель проекта) или комитет, возглавляемый председателем, в который могут входить менеджеры, аналитики, представители заказчика, а так же различные категории разработчиков. Совет действует в интересах заказчика и руководителя проекта и создает основу для пересмотра обязательств сторон в условиях изменения требований. Даже если обязательства формально не пересматриваются, Совета обеспечивает объективные свидетельства о ходе проекта, которые в случае разбирательств могут объяснить причину неудачи.
#30 Основным артефактом при работе Совета является «Запрос на изменения». После одобрения запроса ему назначается приоритет, он вносится в спецификацию требований, если нужно, корректируется план, и соответствующая информация доводится до исполнителей. Даже если проект реализует один человек, контроль изменений остается полезным. В этом случае говорят о не о совете, а о &quot;Точке управления изменениями&quot; (есть даже такой термин Change Control Рoint, CCP), которая присутствует в творческом процессе разработчика. При этом в упрощенном виде сохраняются все процедуры и артефакты процесса контроля (запрос на изменение, результаты анализа влияния и т.п.). ЛОВУШКА. Чем меньше коллегиальность принятия решений об изменениях требований, тем выше риски неудачи проекта.
#31 Успех проекта по разработке ПО определяет баланс четырех основных переменных: «Время», «Затраты», «Качество» и «Объем» работ. Если значения этих переменных выбраны правильно, то проект считается успешным («качественно и в срок имеющимися ресурсами реализован запланированный объем работ»). Проблема изменений состоит в том, что все переменные проекта исходно зафиксированы, и изменения требований в ходе проекта увеличивает объем работ и нарушает исходно установленный баланс. В задачи Совета входит организация анализа влияния изменений, и принятие решения о судьбе изменения путем «взвешивания» всех преимуществ изменения (экономия средств, увеличение дохода, удовлетворение клиента, конкурентные преимущества ...) и отрицательных последствий для проекта (затраты на разработку, задержка поставки). По результатам анализа влияния Совет должен принять сбалансированное решение, результатом которого может стать осознанное увеличение сроков или затрат, снижение качества продукта или уменьшение функциональности.
#32 Заказчик может остаться недовольным как в случае отказа от предлагаемого им изменения, так и в случае его принятия, при условии, что поставка продукта задержится или, что он, например, будет меньше тестироваться. Находить сбалансированные решения по предлагаемым изменениям с учетом интересов всех заинтересованных сторон и является основной целью «Совета по управлению изменениями».
#35 Реализация изменение требования может потребовать изменения других требований и элементов ПО (рабочих продуктов). Как при анализе влияния выяснить, каких? Для этого нужно иметь информацию о том, с какими другими требованиями или рабочими продуктами (компонентами дизайна, модулями исходного кода, вариантами тестирования, файлами с документацией) связано данное требование. Такая информация о связях, зафиксированная в явном виде называется трассировкой требований. Она помогает отслеживать связи требований в направлениях от источника к реализации и наоборот. На слайде показаны возможные варианты трассировки. Потребности заказчика отслеживаются в требованиях, чтобы можно было определить, какие требования затрагиваются при изменении потребностей. Такие связи обеспечивают уверенность в том, что спецификация требований отражает все потребности заказчика и что каждое требование обосновано.
#36 По мере разработки ПО трассировка позволяет отслеживать связи между отдельными требованиями и рабочими продуктами, чтобы можно было определить, какие элементы затрагиваются при изменении потребностей. Такие связи обеспечивают уверенность в том, что каждое требование реализуется определенным набором рабочих продуктов и, что среди последних нет таких, которые не соответствуют ни одному из заданных требований.
#37 Трассировка представляет потребности и требования в виде ориентированного ацикличного графа, по которому можно прослеживать связи потребностей и требований (сверху вниз и снизу вверх). Трассировка имеет дело с функциональными требованиями и обычно не затрагивает характеристики качества ПО и ограничения, если им не соответствуют определенные функциональные требования. Для выполнения трассировки: - требования дробятся на мелкие фрагменты (одна функция - одно требование). - требования и элементы конфигурации уникально идентифицируются, чтобы на них можно было ссылаться. - для каждого требования (элемента конфигурации) указывается источник.
#38 Трассировка требований к рабочим продуктам определяет связь между требованиями и реализующими их элементами ПО. Наличие трассировки позволяет проверить полноту реализации требований и наличие рабочих продуктов не соответствующих никаким требованиям (&quot;код-сироту&quot;). Часто наличие таких элементов ПО говорит о том, что некоторое требование просто не зафиксировано. Трассировка требований к рабочим продуктам помогает контролировать продвижение проекта, снижает риск неполноты реализации требований и помогает выполнять анализ влияния изменения требований. Нефункциональные требования (производительность и другие свойства) не всегда прослеживаются до элементов продукта. Производительность часто связана с архитектурой, оборудованием, структурой БД. Перемещаемость часто связана с выбором языка, ограничениями на использование библиотек. Но некоторые нефункциональные требования активизируют создание производных функциональных требований.
#39 Уникальная идентификация требований является необходимым условием трассировки. Наиболее простой способ идентификации требований и рабочих продуктов учитывает наличие нескольких уровней требований и категорий рабочих продуктов. При таком подходе для каждой категории требований и рабочих продуктов вводится краткое обозначение, которое используется в идентификаторе в качестве индекса. В пределах одной категории требования нумеруются последовательно. Номер, присвоенный однажды некоторому требованию, не используется при удалении этого требования. Для упоминания рабочих продуктов вместо последовательного номера можно использовать обозначения соответствующих диаграмм (DFD, SADT, ER D ), тестов, документов. На программные элементы обычно ссылаются по их именам.
#40 Если требования имеют явно выраженную иерархическую структуру, то последовательные номера требований более низкого уровня также индексируются номерами требований более высокого уровня.
#41 В зависимости от создаваемых в ходе проекта типов рабочих продуктов трассировка может отражать различные типы связей. В общем случае эти связи могут быть &quot;многие ко многим&quot;. При разработке ПО могут создаваться различные категории требований и рабочих продуктов. Но не обязательно все связи определять явно. В каждом проекте можно ограничить набор отслеживаемых связей, определив какие связи следует фиксировать явно (например, только функциональные требования и рабочие продукты).
#42 Обычно информация о трассировке фиксируется в документе «Матрица трассировки» (варианты названия: «Матрица отслеживания», «Таблица трассировки»). Пример такого документа с простейшей структуры показан на слайде. Такой документ создается после утверждения базового варианта требований. При этом в ней заполняются первые две колонки. По завершении разработки каждого элемента ПО конфигурации (не по мере планирования!) информация о нем заносится в третью колонку. Это позволяет фиксировать связи требований с рабочими продуктами и, дополнительно, отслеживать продвижение проекта.
#43 Трассировку можно представить в виде матрицы, определяющий связи между требованиями и рабочими продуктами (&quot;Функциональные требования - программные элементы&quot;, &quot;Функциональные требования-Варианты тестирования&quot; ...). Если программных элементов значительно больше чем требований, то эту матрицу можно развернуть на 90 градусов.
#44 Трассировка требует хорошей организации работ и дисциплины. При этом, нужно учитывать, что регулярно обновлять информацию трассировки не сложно, восстанавливать по мере продвижения к завершению проекта очень сложно. Поэтому, трассировку нужно либо делать регулярно, либо не делать вовсе. Разработчик держит информацию о связях в голове и может обойтись без документирования трассировки. Но эта информация также нужна руководителю проекта. Решение состоит в том, что за трассировку должны отвечать другие лица (менеджер проекта, руководитель группы, аналитик) запрашивая информацию у разработчиков, которые, могут препятствовать ее предоставлению, если им не объяснить всю ценность такой информации. Для выполнения трассировки необходимо явно определить соответствующую проектную процедуру (см. слайд).
#45 Трассировка дает долгосрочные выгоды. Она увеличивает затраты на управление, но эти затраты по сути являются инвестициями, которые возвратятся на в процессе сопровождения и развития системы. Трассировка обеспечивает ряд преимуществ при выполнении других работ: Анализ влияния - позволяет выполнить более точный расчет трудозатрат Контроль проекта - отслеживает реализацию потребностей и требований Разработка - выявляет места внесения изменений при адаптации продукта Сопровождение - повышает качество внесения изменений на этапе использования ПО Проектирование - выявляет пакеты связанных требований и элементов ПО Управление рисками - наличие трассировки снижает риск ухода разработчика
#46 Тестирование - позволяет более целенаправленно вести тестирование Демонстрация - облегчение демонстрации реализации исходных требований Применять трассировку или нет, тратить ли драгоценное время? - вопрос сопоставления преимуществ и затрат. Для принятия правильного решения, вспомните сколько ошибок в проектах было сделано из-за отсутствия информации о связях. Правильный путь - попробовать трассировать 10-20 требованиях для сложной части ПО и затем постепенно расширять масштаб.
#49 При использовании документального способа хранения требований на бумаге или в файлах: - трудно синхронизировать изменение различных представлений требований и рабочих продуктов. - трудно доводить информацию при изменении этих документов многим участникам проекта, особенно при их географическом удалении; - трудно отслеживать состояние требований; - трудно распределять требования по версиям продукта. При переносе требования в следующий выпуск, приходится перемещать его из одной спецификации в другую. Альтернативой документального хранения требований и изменений является использование специализированных инструментальных средств на базе данных.
#50 Для управления изменениями требований существуют специальные инструментальные средства, которые автоматизируют многие процессы работы с требованиями (см. слайд). Инструменты позволяют более гибко управлять требованиями и их изменениями, делают процесс контроля более прозрачным и простым. Они облегчают скучную и рутинную работу по трассировки требований. Инструменты позволяют достоверно измерять активность изменений и анализировать ход проекта, а не на основе субъективных впечатлений и неясных воспоминаний, зависящих скорее от уровня оптимизма и пессимизма разработчиков и заказчиков. По активности изменений можно оценивать работу аналитика (качество требований) и постепенно совершенствовать процесс определения требований. Высокая частота изменений в течение длительного времени - верный признак приближения провала проекта. ЛОВУШКА . Инструменты обеспечивают удобную работу с отдельными требованиями и изменениями, облегчают их модификацию, но ограничивают возможности контроля качества спецификации в целом (завершенность, непротиворечивость). Просматривая фрагмент требования через экран весь контекст приходится держать в памяти.
#51 Нужно понимать, что использование инструментов не решает всех проблем работы с требованиями. Они не помогут определить потенциальных пользователей или выявить нужные требования. Они не заменят интеллект экспертов и лиц, принимающих решения, при управлении изменениями. Они не могут полностью автоматизировать трассировку, так как информация о связях находится в памяти исполнителей. Использовать инструменты можно, когда у вас уже есть рабочая методика, но ей не хватает эффективности. Нельзя надеяться, что инструмент восполнит недостаток трудолюбия, дисциплины, опыта или понимания.
#52 На рынке ПО предлагается много инструментальных средств, поддерживающих управление требованиями и контроль изменений. ЛОВУШКА. Не пытайтесь быстро, на скорую руку разработать собственное средство управления требованиями, сравнимое по мощности с коммерческими продуктами. Это может показаться легко, но такая разработка может сильно отвлечь ресурсы команды от основной разработки, и не приведет к созданию хорошего инструмента, особенно в условиях недостатка необходимых теоретических знаний и опыта ручного управления изменениями. [Карл Вигерс] Однако, если вы создали и сопровождаете производственную систему своего предприятия, то в нее без значительных затрат можно встроить простую систему сбора и обработки заявок на изменения системы от пользователей, которая может значительно повысить управляемость изменений.
#56 Книги, руководства, стандарты всегда рисуют некоторую идеальную картину работы, которую в реальных условиях воспроизвести практически невозможно. Ее не следует отвергать из-за недостижимости, а нужно использовать в качестве ориентира для выбора первых шагов в ее направлении. Современная программная инженерия - мастерская с большим набором инструментов (принципы, методы, средства), которые не обязательно использовать все для решения конкретной задачи. Однако, нужно знать, что в мастерской имеется, чтобы подобрать для решения текущей задачи оптимальный набор инструментов. Не пытайтесь внедрять все методы сразу. Кроме того, инструменты нужно затачивать и делать профилактику, это означает что выбранные принципы, методы и средства нужно регулярно применять и совершенствовать.
#57 Подводя итоги, хочется сформулировать несколько основных принципов работы, связанных с требованиями к ПО: Выявлять требования до программирования в максимально возможном объеме. Разработка без требований похожа на путешествие по незнакомой местности без карты. С точки зрения руководства и заказчика программист «ныряет в кротовую нору с множеством выходов, и в каком и когда он вылезет никто не знает» (&quot;Тоннельный эффект&quot;). Фиксировать все требования, запросы на изменение, результаты анализ влияния. В разработке ПО всегда есть много заинтересованных лиц (минимум 2), с которыми нужно обсуждать требования и изменения. Делать это в устной форме опрометчиво, из-за ненадежности нашей памяти и сильных различий в уровне подготовки Чувствовать границу между «что нужно сделать» и «как это сделать» Предпринимая любые шаги в разработке, на любом ее этапе сначала нужно понять «что нужно сделать», чтобы была свобода поиска и правильного выбора того «как это делать». «Что нужно сделать» задает границу между требованиями и решениями. Программист должен максимально себя защищать, выстраивая границу между тем, что он должен сделать, и своей работой. Не важно идут требования от заказчика. своего аналитика или руководителя. Это повысит качество ПО, позволит точнее спланировать работу и снизит ответственность за реализацию неудачно поставленной задачи. Упор делать не на процессы, процедуры и стандарты, а на принципы и результаты.
#58 Образцы документов для управления требованиями Процесс управления требованиями . Описывает действия работающей над проектом команды , связанные с изменениями требований , различными версиями документации по требованиям , учетом и отчетностью статусов требований и накоплением информации по трассированию . Здесь должны быть указаны списки атрибутов для каждого требования — приоритет , ожидаемая стабильность и планируемый номер выпуска , а также действия , необходимые для одобрения спецификации и основной версии требований . Пример описания процесса управления требованиями вы можете найти в приложении J «CMM Implementation Guide» (Caputo, 1998). Процесс управления изменениями . Реально действующий процесс управления изменениями способен уменьшить хаос , вызываемый бесконечными , бесконтрольными изменениями требований . Процесс управления изменениями определяет пути предложения , передачи , оценки и разрешения нового требования или его модификации . Инструментальное средство выявления проблем облегчает контроль за изменениями , но помните , что инструмент — не замена процессу . В главе 19 детально описан процесс управления изменениями . Процедура проверки статуса требований . Подразумевает проверку статуса каждого функционального требования и отчетность по нему . Вам придется использовать базу данных или коммерческое средство управления требованиями , чтобы контролировать статус большого числа требований в огромной системе . Эта процедура также описывает отчеты , которые вы сможете генерировать для просмотра статуса собранных требований в любое время . Больше об учете статуса требований вы можете прочитать в главе 18. Устав совета по управлению изменениями . В совет по управлению изменениями (change control board, CCB) входят наиболее заинтересованные в проекте лица , которые решают , какие изменения в требованиях принять , какие отвергнуть и в какую версию продукта следует внести каждое предложенное изменение . Как вы знаете из главы 19, устав совета по управлению изменениями описывает структуру , функции и рабочие процедуры совета . Процедура трассируемости требований . Матрица трассируемо - сти требований содержит список всех функциональных требований , конструктивных элементов и модулей кода , связанных с каждым требованием , и варианты тестирования , подтверждающие его корректную реализацию . Матрица трассируемости должна также определять требование исходной системы , вариант использования , бизнес - правило или другой источник , из которого проистекает каждое функциональное требование . Список и шаблон анализа последствий изменений в требованиях . Оценка стоимости и другого влияния предлагаемого изменения в требованиях — ключевой шаг в определении того , принимать ли его . Анализ последствий помогает совету по управлению изменениями принимать информированные решения . Как показано в главе 19, список последствий помогает вам рассмотреть задачи , побочные эффекты и риски , которые могут возникнуть при реализации каждого изменения в требованиях . Рабочая таблица предлагает простой способ оценки трудовых затрат для каждого задания . Пример шаблона для результатов анализа последствий также показан в главе 19.
#61 Это, конечно, не единственные источники информации. На сегодня существует масса литературы по этой развивающейся области Программной инженерии. Некоторые ссылки на нее приведены ниже: Астелс Девид, Миллер Гранвилл, Новак Мирослав. Практическое руководство по экстремальному программированию, Пер. с англ. - М.: Издательский дом &quot;Вильямс&quot;, 2002. - 320 с.: Бек Кент. Экстремальное программирование. – СПб.: Питер, 2002. – 224 с.: Брукс Фредерик. Мифический человеко-месяц. - Пер. с англ. – СПб.: Символ-Плюс, 2005 Коберн Алистер. Современные методы описания функциональных требований к системам / Пер. с англ. - М.: Издательство &quot;Лори&quot;, 2002. - 263 с.: Купер Алан. Психбольница в руках пациентов. - Пер. с англ. – СПб.: Символ-Плюс, 2004 Соммервил Иан. Инженерия программного обеспечения, 6-е издание. - Пер. с англ. - М.: Издательский дом &quot;Вильямс&quot;, 2002. - 624 с.:
#62 Шмуллер Джозеф. Освой самостоятельно UML за 24 часа, 2-е издание / Пер. с англ. - М.: Издательский дом &quot;Вильямс&quot;, 2002. - 352 с.: IEEE Std 1233-1998, IEEE Guide for Developing System Requirements Specifications, 1998. IEEE Std 1362-1998, IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document, IEEE, 1998. IEEE/EIA 12207.0-1996//ISO/ IEC12207:1995, Industry Implementation of Int. Std.

Sep reqm-lec3

More Related Content

What's hot

Viewers also liked

Similar to Sep reqm-lec3

More from Natalia Zhelnova

Sep reqm-lec3

Editor's Notes