L5 requirements
-
Upload
natalia-zhelnova -
Category
Documents
-
view
281 -
download
0
Transcript of L5 requirements
5Software Engineering Professional Program © 2006.
T E K A M A5-1
Планирование и управление требованиями
Планирование и управление требованиями
T E K A M A5-2Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Цели и задачи• Изучить, какие действия требуются для
эффективного управления требованиями– прослеживаемость требований– контроль версий– контроль состояния
• Совершенствование процесса управления требованиями– необходимость в совершенствовании процесса– как, что и почему
T E K A M A5-3Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Вопросы для размышления
• Какие действия относятся к эффективному
управлению требованиями ПО?
• В чем причина необходимости
совершенствования процесса?
– почему мы должны беспокоиться?
– какие основные аргументы за и против?
– как можно делать это эффективно?
T E K A M A5-4Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Принципы и приемы управления требованиями
T E K A M A5-5Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Управление требованиямиЧто необходимо делать, когда требования уже есть
Контроль версий Контроль состояния требования
Управление требованиями
•Определение схемы идентификации версии
•Определение версий спецификации требований
•Определение версий отдельных требований
• Определение состояний требований
• Регистрация состояния требований
Прослеживание требований
• Определение связей с другими требованиями
• Определение связей с другими элементами системы
Управление изменениями
•Предложение изменений
•Анализ влияния
•Принятие решений
•Обновление требований
•Обновление планов
Уже рассмотрено
К. Вигерс
T E K A M A5-6Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Управление требованиямиЧто необходимо делать, когда требования уже есть
Контроль версий Контроль состояния требования
Управление требованиями
•Определение схемы идентификации версии
•Определение версий спецификации требований
•Определение версий отдельных требований
• Определение состояний требований
• Регистрация состояния требований
Прослеживание требований
• Определение связей с другими требованиями
• Определение связей с другими элементами системы
Управление изменениями
•Предложение изменений
•Анализ влияния
•Принятие решений
•Обновление требований
•Обновление планов
Уже рассмотрены
T E K A M A5-7Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Прослеживаемость требований
T E K A M A5-8Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Прослеживаемые связи
• Четыре реальных типа
прослеживаемых связей
– Потребности заказчика с
разработанными требованиям
– Требования с исходными
потребностями заказчика
– Требования с определенными
элементами продукта
– Определенные элементы продукта с соответствующими требованиями
Потребности клиентаПотребности клиента
ТребованияТребования
Нижележащие Нижележащие рабочие рабочие продуктыпродукты
В направлении оттребований
В направлении к требованиям
В направлении оттребований
В направлении к требованиям
T E K A M A5-9Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Зачем прослеживать требования• Проверка продуктов с особыми
требованиями к безопасностиправильное прослеживание подтверждает, что требования были реализованы
• Анализ влияния измененияправильное прослеживание помогает не пропустить изменения в системных элементах
• Обслуживаниеправильное прослеживание помогает делать правильные изменения при обслуживании, повышая тем самым производительность
• Сопровождение проектаправильное прослеживание помогает при сопровождении реализации
• Реинжениринг прослеживаемость помогает лучше выполнить реинжениринг существующих устаревших систем
• Повторное использованиепрослеживаемость помогает при повторном использовании компонентов, определяя пакеты связанных требований, дизайна, кода и тестов
• Снижение рискаправильное прослеживание снижает риски, связанные с уходом из команды существенно важного члена
T E K A M A5-10Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Матрица прослеживания требованийПример 1
Требования пользователя
Элемент дизайна
Функциональное требование
UC-16
Модуль кода
Тестовый сценарий
UC-29
UC-37
Catalog.item.sort Class Catalog Catalog.sort() Sort.7Sort.8
3.4.2 Class Order Order.5
SR 2.1 Class Encrypt Security. 31Security. 32
Security. 33
T E K A M A5-11Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Матрица прослеживания требованийПример 2
Функциональное
требованиеСценарий тестирования
TC – 1 TC – 2 TC – 3 TC – 4
FC – 1
FC – 2
FC – 3
FC – 4
FC – 5
FC – 6
Для больших проектов трудно делать на бумаге, используйте специальные инструменты
T E K A M A5-12Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Процедура прослеживания требований• Выберите отношение связи
• Выберите тип матрицы прослеживания требований
• Определите части продукта, для которых хотите поддерживать информацию прослеживания
• Модифицируйте процедуры разработки и инструкции, чтобы напоминать разработчикам об обновлении связей после реализации требования или утвержденного изменения
• Определите соглашения о маркировке
• Определите лиц, ответственных за обеспечение информацией и координацию/управление этой деятельностью
• Познакомьте команду с принципами и важностью прослеживания требований.
• Разработчики, по мере продвижения разработки, должны постоянно предоставлять соответствующую информацию (небольшими порциями)
• Периодически контролируйте информацию прослеживания
T E K A M A5-13Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Управление версиями требований
• Вам приходилось работать с устаревшими или противоречивыми требованиями?
• Контроль версий документов
– уменьшает путаницу, конфликты и недопонимание при общении
– позволяет эффективно использовать ресурсы проекта
• Механизм контроля версий должен
– создание «базовых» версий
– включать историю исправлений
– позволять только авторизованным лицам вносить изменения
SRS V1.1
T E K A M A5-14Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Атрибуты требований• Выход за рамки текстового описания
– Позволяет представить требование «объектом со свойствами»
– Атрибуты могут определять окружение и контекст
• Возможные атрибуты могут включать– Имя автора
– Дату создания
– Номер версии
– Ответственного за разработку
– Состояние
– Источник требования
– Обоснование
– Выпуск продукта, которому оно принадлежит
Выбирайте наименьшее количество атрибутов, чтобы эффективно управлять проектом
T E K A M A5-15Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Отслеживание состояния требованияСиндром выполнения работы на 90% ...
• В чем состоит проблема, требующая отслеживания
требований?
• Преимущества
– хороший показатель прогресса проекта
– полезен при анализе изменения
– обосновывает некоторые решения, принятые во время
разработки
• Обычно используется метод отслеживания по %
завершения, но работает ли он на самом деле?
T E K A M A5-16Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Возможные состояния требований
Состояние Определение
Предложено
Одобрено
Реализовано
Проверено
Удалено
Отклонено
Требование было запрошено авторизованным источником
Требование было проанализировано, и одобрено для определенной версии. Заинтересованные лица проекта согласились на его реализацию.
Реализующий требование код был написан, протестирован и принят. Это требование можно проследить до дизайна и кода.
Корректная функциональность этого требования было подтверждена последней версией продукта. Требование может быть прослежено до варианта тестирования и может рассматриваться как завершенное
• Когда-то одобренное требование, которое было исключено из базисного документа. Должно содержать обоснование причины этого решения
Это требование было предложено, но в данный момент не планируется его реализация. Должно содержать обоснование причины этого решения
T E K A M A5-17Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Измерение деятельности по управлению• Измерение деятельности по разработке и управлению требует
– изменения в культуре компании
– личной дисциплины
• Отслеживание усилий позволяет
– видеть, выполняет ли команда на самом деле предполагаемые для управления требованиями действия
– снизить во время разработки риск неконтролируемых изменений и пропущенных требований
• При измерении учитывайте следующее:
– предложения по изменению требований
– предложения новых требований
– действия совета по управлению изменениями
– обновления документов требований
– сообщение об изменении требований всем заинтересованным лицам
– отслеживание и отчет о состоянии требований
– сбор информации о прослеживаемости требований
T E K A M A5-18Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Требования и совершенствование процессов
T E K A M A5-19Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Определения процесса• Что представляет собой совершенствование процесса?
– Действие по оценке существующих подходов, распознаванию слабостей и улучшение способа, которым ПО создается, расширяется и сопровождается (Латанзе)
• Что значит точно определенный процесс?
– кодифицирован
– понят
– изучен
– используется
• Преимущества точно определенного процесса
– фиксирует знания
– обучение
– измерение
– непротиворечивость
T E K A M A5-20Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Необходимые условия для совершенствования процесса• Н - Недовольство положением вещей
– происходит в хаотичных организациях
• В – Видение будущего состояния
– мечтатели представляют, как сделать «это» лучше
• П – Первые шаги по направлению к видению
– смельчаки действуют, основываясь на своем видении
• С – Сопротивление изменениям
– Многие люди боятся изменений и сопротивляются им.
Они скорее уйдут, прежде чем изменятся.
T E K A M A5-21Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Необходимые условия длясовершенствования процесса
Если Н * В * П > С
Тогда “Произойдут изменения”Где:
Н - недовольство положением вещейВ – видение будущего состоянияП – первые шаги по направлению к видениюС – сопротивление изменениям
Требует поддержки
менеджмента
T E K A M A5-22Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Основы совершенствования процесса• Совершенствование процесса должно быть
эволюционным, непрерывным и цикличным
• Люди и организации изменяются только при наличии
стимула
• Изменения процесса должны быть ориентированы на
определенную цель и управляемы
• Воспринимайте действия по совершенствованию
процесса как мини-проекты
T E K A M A5-23Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Цикл совершенствования технологических процессов Пример 1
Оцените текущие процессы
Планированиедействий по
совершенствованию
Создание, проба и реализация
новыхпроцессов
Оценка результатов
Насколько хорошо прошли пилотные
испытания и общее внедрение?
Насколько успешно прошел процесс планирования?
Удовлетвояет ли новый процесс требуемым
результатам?
выводы и рекомендации
план действийновые процессы;
результаты пилотных
испытаний
план следующего цикла
совершенствования
Вигерс, англ. издание. стр. 389
T E K A M A5-24Software Engineering Professional Program © 2007.
Планирование и управление требованиямиЦикл совершенствования технологических процессов Подход SEI IDEALSM
Инициирование
Диагностика Создание
Действие
Изучение
Предложите действия набудущие
Проанализируйтеи подтвердите
Пилотное/тестовоерешение
Создайте решение
Разработайтеподход
Установите приоритеты
Разработайте рекомендации
Охарактеризуйте существующее и желаемое состояния
Организуйтеинфраструктуру
Заручитесьподдержкой
Стимул для перемен
Определитеконтекст
Реализуйте решение
Уточните решение
Планируйте действия
T E K A M A5-25Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Ключевые процессы требований
Разработка требований•Процесс разработки требований•Процедура задания приоритетов требований•Шаблон представления/рамок проекта•Шаблон варианта использований•Спецификация требований/контрольный список недостатков варианта использований
Управление требованиями• Процесс управления изменениями• Процесс отслеживания состояния требований• Процедура прослеживаемости требований• Создание совета по управлению изменениями• Шаблон/контрольный список анализа влияния
T E K A M A5-26Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Итак, вы просыпаетесь на следующее утро• Что вы делаете?
– нет… вы не паникуете
– считаете до 10, а затем паникуете ...
• А если серьезно
– оценка• где вы находитесь
• какие ресурсы у вас есть
• какие недостатки вы хотите
исправить
• что является «легко достижимым»
T E K A M A5-27Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Итак, вы просыпаетесь на следующее утро
• Планирование– команда– время– цели
• Процесс– есть ли он у вас– нужен ли он вам– знают ли о нем, и используют ли его люди– можно ли его как-то измерить и повторить
T E K A M A5-28Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Заключение• Связанный с требованиями риск относится ко многим категориям,
но может быть управляемым, как часть постоянного процесса по
управлению рисками
• Действия по управлению требованиями включают контроль за
управление изменениями и версиями, отслеживание состояний и
прослеживание требований
• Прослеживание требований становится чрезвычайно важным в
различных операционных средах проекта и в свете возможных
изменений
• Измерение действий по управлению позволяет лучше отслеживать
ресурсы проекта и снизить связанный с проектом риск
• Совершенствование процесса является фактором желания
организации измениться и адаптироваться
T E K A M A5-29Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Ресурсы• “Practical Approach to Quantifying Risk Evaluation
Results”, Crosstalk Feb 2000– http://www.stsc.hill.af.mil/crosstalk/2000/02/hantos.html
• The Capability Maturity Model: Guidelines for Improving your Process, CMU-SEI, 1995
• Making Process Improvement Work, Neil Potter and Mary Sakrey, 2002
• Factors influencing RM selection tools http://www.incose.org/lib/rmtools.html
• RM tools – comparison – http://www.incose.org/tools/tooltax.html – http://easyweb.easynet.co.uk/%7eiany/other/vendors.htm
T E K A M A5-30Software Engineering Professional Program © 2007.
Планирование и управление требованиями
Вопросы?