1 Менеджмент разработки программных изделий Лекция 10.Проблемы оперирования требованиями. - презентация

1 1 Менеджмент разработки программных изделий Лекция 10.Проблемы оперирования требованиями

2 2 Анализ требований Что такое требования к программному изделию? Два аспекта: Средства программного изделия, в которых нуждается пользователь для решения своих проблем или достижения определенных целей (Что?); Характеристики, которым должна обладать система в целом или ее компонент, чтобы удовлетворять соглашениям, спецификациям, стандартам или другой формально установленной документации (Как?).

3 3 Требования не всегда очевидны и имеют много источников. Требования не всегда легко выразить словами. Существует множество различных типов требований и различных уровней их детализации. Требования чаще всего взаимосвязаны и взаимозависимы, иногда противоречивы. Требования всегда уникальны (требование к фиксируемым требованиям). Набор требований чаще всего является компромиссом. Требования изменяются. Требования зависят от времени. Непрерывность поступления требований (см. лекцию 5) Нужны специальные приемы для работы с требованиями Характеристики требований

4 4 5. Модельные представления уровня конструирования 7. Документные представления 6. Программные представления 3. Типизированные представления требований Глоссарий проекта Т абстр Т экон Т функ Т инт Т эфф Т a (a1,…,an a ), Т b (b1,…,bn b ),Т c (c1,…,cn c ), …,Т z (z1,…,zn z ) 2. Унифицированные представления требований 4. Модельные представления уровня анализа Трассировка требований 1.Исходное представление требований 1. Текстовое описание пожеланий к системе, заданное в свободной форме 2. Элементарные составляющие требований для единообразного использования 3. Элементарные составляющие требований, каждое из которых приписывается к некоторому типу (атрибуты распределяются по уровням иерархии типов) 6. Программные рабочие продукты и их фрагменты 5. Диаграммы классов и др. диаграммы 7. Фрагменты документных рабочих продуктов 4. Образы составляющих как элементы аналитических моделей системы

5 5 Трансформация требований 1.Исходное представление текстовое описание пожеланий к системе, заданное в свободной форме. 3.Типизированное представление элементарные составляющие требований, каждое из которых приписывается к некоторому типу (атрибуты на уровнях иерархии типов). 2.Унифицированные представления элементарные составляющие требований для единообразного использования. 4.Модельные представления уровня анализа образы составляющих как элементы аналитических моделей системы. 5.Модельные представления уровня конструирования диаграммы классов и др. 6.Программные представления программные рабочие продукты и их фрагменты. 7.Документные представления фрагменты документных рабочих продуктов. Глоссарий проекта

6 6 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

7 7 1. Анализ проблем Цель: выявить реальные нужды пользователей, оценка пожеланий с точки зрения их осуществимости в проекте. Результат:ранжированный по степени важности список потребностей пользователей с перечислением следствий того, что данная проблема будет решена

8 8 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

9 9 2. Понимание пользовательских потребностей Требования исходят из многих источников, их количество бывает значительно. Следовательно, необходима типизация требований. Уровни типов. Результат:система типов требований для данного проекта. Глоссарий проекта Т абстр Т экон Т функ Т инт Т эфф Т a (a1,…,an a ), Т b (b1,…,bn b ),Т c (c1,…,cn c ), …,Т z (z1,…,zn z )

10 10 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

11 11 3. Преодоление сложности многофункциональности требований Требования характеризуют изделие с разных сторон многофункциональность Инициаторы работ (stakeholders) те, кто определяют главные требования. Представи- тель заказчика Представи- тель поль- зователя Инвестор Менеджер по продажам Покупатель менеджер проекта, эксперт предметной области, специалист по пользовательскому интерфейсу, архитектор и проектировщики подсистем, тестировщики. … Результат: перечень типизированных требований, описанных текстуально и/или графически, порядок которого соответствует приоритетности требований. Методы преодоления сложности многофункциональности: Интервью Мозговые штурмы Опросы и анкетирование Изучение прототипов Выполняется в течение всего проекта!

12 12 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

13 13 Результат:группа требований, выделенная в процессе оперирования для тех или иных целей. 4. Оперирование с многомерными требованиями одновременное оперирование с разными параметрами отбора требований для анализа Организация хранения и предъявления требований архитектор, проектировщики подсистем и менеджер проекта, разработчик информационной поддержки и библиотекарь Цель: организация помощи при отборе требований Параметры отбора: тип требования, приоритетность, … Тип требования набор атрибутов, атрибут набор значений. Оперирование с требованиями один из основных методов аналитической работы

14 14 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

15 15 5. Определение системы Результат: Точное и согласованное определение системы. Трансформация потребностей и перечня требований в описание для разработки. Общие соглашения: как понимаются требования и их приоритетность, оценка затрат и ресурсных потребностей, рисковые ситуации и стратегия управления рисками. Границы применения будущей системы. Виды рабочих продуктов, правила их построения, проверки и т.д. Внешние рабочие продукты и способы их использования в проекте: применение результатов, использование как прототипов и др. Форма представления определения системы: тексты, схемы, гипертекстовая структура и др. Перед составлением формализованных модельных описаний следует сначала представить их на естественном языке!

16 16 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

17 17 6. Управление областью применимости системы Цель: Выбор наиболее приоритетного для инициаторов работ направления развития проекта в условиях имеющихся в текущий момент ресурсов. Методы: обсуждение атрибутов требований (приоритетность задач, потребность ресурсов, допустимый уровень риска) для выявления реально осуществимых возможностей. Результат:список требований, которые планируется удовлетворить (реализовать) на ближайших этапах, текущей и последующих итераций и для проекта в целом

18 18 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

19 19 7. Детализированное определение системы Цель: Нужно, прежде всего, чтобы инициаторы работ смогли понять, какое изделие им предлагается, и решить, соглашаться с этим предложением или нет. Делается по отношению к функциональности, а также для выработки соглашений о порядке реализации требований, о практичности и надежности системы, о ее производительности, о поддержке и удобствах применения, о порядке тестирования. Варианты детализированного определения для разных пользователей. Результат: определение системы в виде описаний ее возможностей, пригодных для предоставления пользователям очередного резиза.

20 20 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

21 21 8. Использование метафор Цель: метафора как база пользовательского представления системы Для каждого элемента автоматизируемой деятельности в рамках метафоры должны быть найдены образы среди средств системы (функциональная и реализационная полнота) и заданы адекватные формы (интерфейсная полнота). Принципы, способствующие, качеству системы метафор: –Точность отражение в метафоре целей, ресурсов, средств и методов как элементов пользовательской деятельности –Полнота отражение в всех элементов деятельности-прототипа –Единый уровень абстракции в представлении метафоры –Структурность метафоры –Использование существующих метафор –Привычность и естественность метафоры. Она всегда должна быть узнаваема –Учет психологических и эргономических особенностей (комплекс рекомендаций) Результат: дополнительные требования, связанные с реализацией метафор, которые предъявляются к архитектуре, интерфейсу и документации программной системы.

22 22 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

23 23 Программные и документные модели Адекватность предоставляется то, что соответствует пользовательской потребности и его метафоре Полнота автоматизируются все аспекты деятельности Непротиворечивость исключена двусмысленность результатов действий пользователей Расширяемость возможность учета и реализации новых требований Программные и документные модели Адекватность предоставляется то, что соответствует пользовательской потребности и его метафоре Полнота автоматизируются все аспекты деятельности Непротиворечивость исключена двусмысленность результатов действий пользователей Расширяемость возможность учета и реализации новых требований 9. Моделирование требований Моделирование требований сокращение для более точного названия процесса построения моделей прикладной области по динамически изменяемой совокупности требований к программной системе Адекватность, Полнота, Непротиворечивость, Расширяемость свойства моделей Выводятся и дополняются / конкретизируются (технологичность) Требования в унифицированном и типизированном представлениях Модели уровня анализа Модели уровня конструирования Уточненная первичная модель прикладной области Первичная модель прикладной области Программные представления Документные представления Модели уровня конструирования Адекватность представляют архитектуру на данный момент Полнота извлечение всей информации из аналитических моделей + построение архитектуры, допускающей все выбранные модели Непротиворечивость следует из этого свойства аналитических моделей Расширяемость суть итеративного наращивания Модели уровня конструирования Адекватность представляют архитектуру на данный момент Полнота извлечение всей информации из аналитических моделей + построение архитектуры, допускающей все выбранные модели Непротиворечивость следует из этого свойства аналитических моделей Расширяемость суть итеративного наращивания Модели уровня анализа Адекватность согласованность с инициаторами работ Полнота отражение максимально большего числа требований Непротиворечивость отсутствие требований, приводящих к взаимоисключающим ситуациям Расширяемость способность включать новые требования в процессе разработки (текущей и в дальнейшем) Модели уровня анализа Адекватность согласованность с инициаторами работ Полнота отражение максимально большего числа требований Непротиворечивость отсутствие требований, приводящих к взаимоисключающим ситуациям Расширяемость способность включать новые требования в процессе разработки (текущей и в дальнейшем) Обогащение автоматического построения (технологичность) Общие требования к моделям всех уровней Верифицируемость возможность проверки построенной системы моделей Аттестируемость соответствие системы моделей предыдущему уровню Адаптивность способность приспосабливать систему моделей к изменяемому пониманию проекта, реагировать на обнаруженные ошибки, несоответствия и др. Общие требования к моделям всех уровней Верифицируемость возможность проверки построенной системы моделей Аттестируемость соответствие системы моделей предыдущему уровню Адаптивность способность приспосабливать систему моделей к изменяемому пониманию проекта, реагировать на обнаруженные ошибки, несоответствия и др.

24 24 9. Моделирование требований выводятся Адекватность согласованность с инициаторами работ Полнота отражение максимально большего числа требований. Непротиворечивость отсутствие требований, приводящих к взаимоисключающим результатам. Расширяемость способность включать новые требования в процессе разработки Требования в унифицированном и типизированном представлениях Модели уровня анализа Модели уровня конструирования Уточненная первичная модель прикладной области Первичная модель прикладной области (технологичность) Адекватность представляют архитектуру системы на данный момент Полнота извлечение всей информации из аналитических моделей + построение архитектуры, допускающей все выбранные модели Непротиворечивость следует из выводимости из аналитических моделей Расширяемость следует из сути итеративного наращивания Программные представления Документные представления Моделирование требований сокращение для более точного названия процесса построения моделей прикладной области по динамически изменяемой совокупности требований к программной системе

25 25 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

26 Управление изменениями требований Развитие проекта Требования Виды требований: дополнительное отражает ранее не рассмотренный аспект системы; модифицирующее изменяет одно или несколько требований; отменяющее принятие его исключает одно или несколько требований. Различия анализа нового требования в контексте существующих соглашений. Цель такого анализа поддержка целостности системы требований проекта. Принять или отвергнуть требование для данного проекта? Требования

27 27 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

28 Сохранение истории изменений требований Набор требований и их атрибуты меняются весьма произвольно Изменения зависят от изменений в окружении, от используемых методов разработки, от политики компании и заказчика, от успеха или неудачи очередного релиза, от множества других факторов История изменений требований используется для отката проекта к пройденному состоянию для отслеживания аналогичных ситуаций для поддержки управления версиями для будущих учебных целей Для хранения истории нужно обеспечить протоколирование появления данных обратимость изменения данных фиксацию времени каждой модификации данных

29 29 Пример протокола и система типовых запросов к истории Результат:совокупность исторических сведений, которая хранится для данного проекта и используется при организации дальнейших работ ( ):ТР0 поступило, Иванов ( ): ТР1 получено из ТР0,Петров 0633 ТР2 получено из ТР0, Петров 0634:ТР3 получено из ТР0, Петров ( ): ТР1 принято,Петров 0652: ТР2 отклонено,Петров 0653: ТР3 принято, Петров 0634:ТР1У получено из ТР1, Петров 0634:ТР3У получено из ТР3, Петров ( ): М01 расширено ТР1У, ТР3У,Петров 0682: ТР3У отклонено,Петров 0683: ТР3 отклонено,автоматически :М01 восстановлено по 0681,автоматически :М01 расширено ТР1У,Петров Примеры семантически сложных запросов (временной параметр запроса!): выдать набор всех требований, поступивших в течение определенного периода от заданного инициатора работ и касающихся интерфейса; показать требования, приятые к некоторому моменту и связанные с изменением заданного требования; показать ретроспективу изменений заданного представления заданного требования. Задача конкретизации сохранения истории изменений требований для данного проекта: прагматический уровень + оптимизация общей постановки

30 30 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

31 Организация работ с требованиями Требования разделяются на принимаемые и отвергаемые Для отвергаемого требования мотивированное заключение Для принимаемого элементарного составляющего требования определяется, на какой итерации оно может (должно) быть удовлетворено (критерии приоритетность, зависимость …) Простые требования реализуются в момент утверждения Сложные требования откладываются до завершения конструкторских работ данной итерации Из-за откладывания требований корректировка общего плана Учитывается, что ранее принятое требование может оказаться отвергнутым вследствие принятия нового требования Изменения планов всегда согласуются с заказчиком. Результат управления изменениями требований (перманентный):определение целесообразного порядка адаптации проекта к меняющимся условиям эксплуатации разрабатываемого программного изделия

32 32 Управление требованиями Приемы 1 – 12 необходимое, но не достаточное условие Нужна специальная работа, которая адаптирует приемы к конкретным условиям ведения разработки, организует мероприятия, соответствующие приемам, определяет, как и когда активизируются эти мероприятия, встраивает мероприятия в планы развития проекта. В результате определяются процессы управления требованиями проекта