3. Анализ проблемы
Формулировка проблемы
Извлечение требований
Заинтересованные лица
Персоны
Концепция
Сценарный подход
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
6. Business Case*
• Business Case является стандартным
способом КОММУНИКАЦИИ обоснования
начала проекта
• Business Case охватывает финансовые и
другие бизнес-аспекты проекта. Как
положительные, так и отрицательные
Пакет поддержки принятия решения (“Decision
Support Package”) в этом контексте синоним
“Business Case”
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
11. • «Эйнштейн однажды сказал, что правильная
постановка задачи важнее даже, чем ее
решение.
• Для нахождения приемлемого или оптимального
решения задачи важно знать, в чем она состоит. Как
ни просто и прозрачно данное утверждение,
чересчур многие специалисты в науке управления
игнорируют очевидное.
• Миллионы долларов расходуются ежегодно на
поиск элегантных и глубокомысленных ответов на
неверно поставленные вопросы».
• К. Шеннон
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
12. Заказчик
(Область проблемы)
• Анализ проблемы
• Выявление и понимание
потребностей
Исполнитель
(Область решения)
Определение системы
• Управление границами
системы
• Уточнение и улучшение
определения системы.
Специфицирование
Управление изменениями
Лекция №4. «Моделирование
использования. Анализ проблемы» Повторение ( л.1)‹#›
13. • Анализ проблемы
• Выявление и понимание потребностей
• Определение системы
• Управление границами системы
• Уточнение и улучшение определения системы.
Специфицирование
• Управление изменениями
Лекция №4. «Моделирование
использования. Анализ проблемы»
*Дин Леффингуэлл, Дон Уидриг Принципы работы с требованиями к программному
обеспечению. Унифицированный подход
Повторение ( л.1)‹#›
16. • Для избежание проблемы “Да, …, Но ….”
“Да, {Это удовлетворяет требованиям},
но {это не решает мою проблему}.”
• Решаемая проблема - это источник, и она направляет решение
– Анализ проблемы вначале значительно выгоднее, чем потом …
• Результаты анализа будут использованы в дальнейшем
Формулирование проблемы
Основное действующее лицо – заказчик:
“Мне необходимо …”
Формулирование требования
Основное действующее лицо – система:
“Система обеспечивает …”
Разработка требований
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
17. Лекция №4. «Моделирование
использования. Анализ проблемы»
Какая из идентифицированных причин имеет наибольший вклад?
То, что заказчик
называет
проблемой
Разработка требований
‹#›
18. Лекция №4. «Моделирование
использования. Анализ проблемы»
• Kurt Levin - американский социальный
психолог, автор концепции.
• Force Field Diagram (Диаграмма
силового поля) - модель, построенная
на идее, что силы как способствуют,
так и сдерживают изменения.
• Система находится в динамическом
«равновесии» при балансе сил.
• Для проведения изменений,
необходимо чтобы сумма «движущих
сил» (driving forces), была больше
суммы «сдерживающих сил»
(restraining forces)
‹#›
19. Формулировка проблемы
Почему? И Как?
Лекция №4. «Моделирование
использования. Анализ проблемы»
Помогает найти
корень проблемы
‹#›
20. Проблема
(The problem of)
Описание проблемы
Затрагивает
(Affects)
Заинтересованные лица
В результате чего
(The impact of which is)
Влияние проблемы
Успешное решение должно
(A successful solution
would)
Ключевые выгоды решения
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
21. Лекция №4. «Моделирование
использования. Анализ проблемы»
Moore ‘91
Для (заказчик)
У которого (определение возможности или потребности )
(Название
продукта )
(категория продукта)
Который ( описание ключевых преимуществ
использования).
В отличие от (основная альтернатива)
Наш
продукт
(описание дифференциации)
‹#›
27. Определение: индивидуумы или организации,
которые активно вовлечены в проект, или чьи
интересы могут быть затронуты в процессе или
результате выполнения проекта. Они могут также
оказывать влияние на цели и результаты проекта.
Цели проектной команды: должна
идентифицировать Заинтересованные стороны,
определить их требования и ожидания, и до
возможной степени управлять их влиянием на
проект для обеспечения его успешности
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
28. Заинтересованные стороны
Лекция №4. «Моделирование
использования. Анализ проблемы»
Ключевые
польз-ли
Конечные
польз-ли
Владельц
ы БП
СпонсорУправл.
Партнер
РП
Координа
тор
проекта
Управляющий комитет
Исполнитель
Заказчик
Поставщ
ик
Члены
команды
Руков-ли
Групп
‹#›
29. Кто: Менеджер Исполнителя, осознающий куда ввязался, командир-
кандидат в герои (возможно «посмертные»)
Интересы: убедить спонсора на максимально-достаточной бюджет,
уговорить заказчика на постановку более простой задачи и
договориться с ними о максимально приемлемом сроке
Влияние: участвует в управлении проектом совместно с Менеджером
проекта (Заказчик); Организует работы Исполнителя, контролирует
работы Заказчика
Обязательства: отвечает за достижение основных параметров проекта
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
30. Кто: разработчики, тестировщики, консультанты, которых очередной раз
призвали послужить светлому делу Исполнителя
Интересы: реализовать требования Заказчика за счет своих творческих и
других способностей, в соответствии со своим видением
Влияние: обеспечивает успешность функционирования новой системы за
счет корректного выполнения своих обязательств
Обязательства: участие в работе проектной группы,
выполнение задач в соответствии с рабочим
планом; регулярная отчетность о выполнении;
участие в формировании требований,
тестировании, обучении
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
31. Кто: эксперты в различных IT областях
Интересы: работа такая, освоение новых знаний, углубление имеющихся
Влияние: от правильного выбора методик, технологий, инструментария,
оценки сложности продукта, алгоритмов зависит ход проекта
Обязательства: помогает Менеджеру
оценить техническую сложность
проекта, оказывает консультации по
всем тех. вопросам в ходе проекта,
участвует в разработке архитектуры
продукта.
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
32. Кто: представитель руководства заказчика
Интересы: получить запланированный эффект от проекта
Влияние: принимает окончательное решения при спорных ситуациях;
утверждает изменения основных параметров проекта (бюджеты,
сроки), определяет цели и идентифицирует выгоды проекта
Обязательства: участвует в управлении проектом и своевременном
принятии решений,
обеспечивающих успешное завершение
проекта, утверждении подходов к выполнению
проекта и приемке результатов
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
33. Кто: руководитель функционального подразделения, эксперт своей
предметной области, детально понимающий БП предприятия в этой
области и отвечающий за них
Интересы: получить ПРОДУКТ, решающий необходимый круг задач
Влияние: формирует требования к продукту, принимает результаты в своей
функциональной области
Обязательства: координирует работы по своему
бизнес-процессу, формулирует требования
к продукту, участвует в сборе и анализе и
детализации требований, контролирует
реализацию требований в ходе проекта,
участвует в тестировании
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
34. Кто: специалист своей предметной области, детально
понимающий БП предприятия в этой области, будущий
ключевой пользователь продукта (Champion)
Интересы: получить УДОБНЫЙ В ИСПОЛЬЗОВАНИИ продукт,
решающий необходимый круг задач
Влияние: формирует требования к продукту
Обязательства: формулирует требования к
продукту, участвует в сборе и анализе и
детализации требований, контролирует
реализацию требований в ходе проекта,
участвует в тестировании
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
35. Кто: будущий непосредственный пользователь продукта
Интересы: получить УДОБНЫЙ ПРОДУКТ, максимально
упрощающий каждодневную работу
Влияние: обеспечивает успешность функционирования
новой системы за счет корректного использования
продукта
Обязательства: обучается
новому продукту
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
36. Кто: «Могучая кучка»: Спонсор проекта, Управляющий
партнер, Координатор проекта, Менеджер проекта,
другие ЗС, обладающие властью
Интересы: обеспечить нормальный ход проекта
Влияние: принятие, либо утверждение, всех ключевых
проектных решений
Обязательства: инициирование
старта проекта и фиксация
его завершения
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
37. • ЭМПАТИЯ
– Что говорит
– Что думает
– Что чувствует
– Что делает
• ИНТЕРПРЕТАЦИЯ
– Чего хочет
– Что для него важно
• ФОКУС
– В чем состоит
проблема/задача
– Что будет решением
Поиск проблемы
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
39. Разработаны Аланом Купером
Архетип пользователя системы для помощи в принятии решения о
возможностях, функциях и дизайне
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
41. Поиск проблемы
• ЭМПАТИЯ
– Что говорит
– Что думает
– Что чувствует
– Что делает
Лекция №4. «Моделирование
использования. Анализ проблемы»
• ИНТЕРПРЕТАЦИЯ
– Чего хочет
– Что для него важно
• ФОКУС
– В чем состоит
проблема/задача
– Что будет решением
‹#›
42. • синтезируется на основе интервью
реальных людей
• Суммированное описание содержит
– Поведение ,
– Цели,
– Навыки,
– Отношение
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
43. • Основные (primary)
• Второстепенные (satisfy when we can)
• Малозначительные (low-priority)
• Затронутые(Affected)
• Исключающие (Exclusionary)
• Заинтерсованные лица (Stakeholders)
» From Boxes and Arrows
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
45. • Документ уровня всей системы, дающий ответы на
вопросы “Что ” и “Почему” для продукта или приложения
• Содержит информацию о:
– Потребностях пользователей
– Целях и назначении
– Рынке сбыта
– Среде использования
– Возможностях продукта ( Features)
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
47. • Назначение
(Документа)
• Границы
• Определение
• Ссылки на другие
документы
• Обзор
– Purpose
– Scope
– Definitions,
Acronyms
– References
– Overview
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
48. • Описание
возможности
• Описание проблемы
• Позиционирование
продукта
2.1 Business Opportunity
2.2 Problem Statement
2.3 Product Position
Statement
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
49. • Динамика рынка
• Обзор заинтересованных сторон
• Обзор пользователей
• Пользовательская среда
• Профили Заинтересованных лиц
• Профили пользователей
Лекция №4. «Моделирование
использования. Анализ проблемы»
3.1 Market Demographics
3.2 Stakeholder Summary
3.3 User Summary
3.4 User environment
3.5 Stakeholder Profiles
3.6 User Profiles
‹#›
50. • Перспектива продукта
• Обзор возможностей
продукта
• Предположения и
зависимости
• Стоимость и
ценообразование
• 4.1 Product Perspective
• 4.2 Summary of
Capabilities
• 4.3 Assumptions and
Dependencies
• 4.4 Cost and Pricing
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
51. • Возможности
продукта
• Ограничения
• Атрибуты качества
• 5. Product Features
• 5.1 <aFeature>
• 5.2 <another Feature>
• 6. Constraints
• 7. Quality Ranges
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
52. • Приоритеты
• Другие требования к
продукту
• Требования к
документации
• Приложение 1 –
Атрибуты
возможностей
8. Precedence and Priority
9. Other Product Requirements
9.1 Applicable Standards
9.2 System Requirements
9.3 Performance Requirements
9.4 Environmental Requirements
10. Documentation Requirements
10.1 User Manual
10.2 Online Help
10.3 Installation Guides
10.4 Labeling and Packaging
11. Appendix 1 - Feature Attributes
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
54. 1. Concept Statement – внешний документ,
который готовится для целей
демонстрации потребителям и фиксации
их реакций
2. Состав Concept Statement:
1. Неудовлетворенные потребности
потребителей
2. Как работает продукт
3. Фичи продукта
4. Преимущества для потребителя
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
57. Написание Concept Statement для тестирования
Неудовлетворенные
потребности потребителей
Как работает продукт
Возможности продукта
Преимущества для
потребителя
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
62. • Сценарное планирование метод
стратегического планирования,
позволяющий управлять
неопределенностью будущего.
• Эту концепцию в мире бизнеса
популяризировала группа
планировщиков из Shell, которая смогла
“предсказать” нефтяной кризис 1973г.
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
67. • В 1996 году Айвар Джекобсон впервые
сформулировал технику визуального
моделирования для специфицирования сценариев
использования при разработке ПО. Изначально им
использовался несколько терминов usage scenarios
и usage case, но со временем устоялось
использование термина use case.
• Благодаря целой плеяде методистов и в первую
очередь Алистеру Коберну в течение 1990-х
сценарии использования стали ключевой
методологией специфицирования функциональных
требований
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
68. нт (англ. Use Case, а также: вариант
использования, сценарий использования)
— спецификация последовательностей
действий (варианты последовательностей и
ошибочные последовательности), которые
может осуществлять система, подсистема
или класс, взаимодействуя с внешними
акторами (англ. Actors).
http://ru.wikipedia.org/
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
69. Цель: “Разместить заказ”
sc1 sc2 sc6 sc7 ...
S
sc3
(Успех) (Провал )
S
S
F
S
F
S
S
F
F
F
F
Получить
... кредит
... резерв
sc4 sc5
Подцель:
*Коберн Алистер
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
70. • Один основной сценарий
«Ура-сценарий»
• Множество альтернативных
– Типичные варианты
Например: Снятие наличных не с того счета
– Редкие варианты
Например: Снятие более 1–ого млн
– Исключительные варианты (Ошибки)
Например : Ящик с деньгами пуст
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
71. Бизнес сценарий
(Business use case )
Системный сценарий
(System use case )
Использует не техническую
терминологию
Описывает поведение системы на
языке пользователя
Рассматривает систему в качестве
«черного ящика»
Определяет функцию которую система
предоставляет пользователю
По сути представляет собой описание
«Бизнес процесса» по достижении цели
уровня бизнеса/пользователя
По сути представляет собой описание
достижения цели уровня приложения
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
72. • В 2003 году Л. Басс, П.
Клементс, Р. Кацман в
Книге Software
Architecture in Practice
предложили подход
трансформации Атрибутов
качества системы в
Сценарии Атрибутов
Качества
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
76. • Методология объединяет :
– Пользователя системы (актера)
– Дерево целей
– Связанные между собой общей целью функциональных требований к
системе
• В результате грамотного применения позволяет :
– Поместить функциональные требования в простой и понятный для
конечного пользователя текстовый формат
– Сгруппировать все сценарии достижения и не достижения цели
– Сформировать основу для документирования и прослеживания не
функциональных требований к системе не «завязанную» на реализацию
2-76
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
78. Актер(Actor): это кто-то или что-то
взаимодействующее с системой
Сценарий использования(Use case):
Набор экземпляров сценария, где
каждый экземпляр это
последовательность действий,
выполняемых актером и системой,
приводящая к получению актером
наблюдаемого результата(observable
result) или ценности (Value)
Actor
Use Case
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
81. Лекция №4. «Моделирование
использования. Анализ проблемы»
Transmit request
Send back approval
Dispense cash
Ask for Receipt
Printed receipt
Return bank card
Insert Card
Approve card
Enter PIN
Approve PIN
Enter account, amount
Withdraw Cash Bank
Consortium
Bank
Customer
‹#›
82. 1. Идентифицируйте заинтересованных лиц
(stakeholders)
2. Определите цели заинтересованных лиц
(бизнес сценариев) по отношению к
системе
3. Сделайте краткое описание каждого
бизнес сценария
Лекция №4. «Моделирование
использования. Анализ проблемы»
Как правило выполняется на этапе
формирования концепции для крупной системы
или решения
‹#›
83. 1. Определите действующих лиц (actors), а затем сценарии, в
которых они участвуют.
2. Определите внешние события, на которые реагирует система,
а потом свяжите эти события с определенными
действующими лицами и сценариями использования.
3. Определите сценарии использования на основе
существующих функциональных требований.
4. Сделайте краткое описание каждого сценария.
1-й и 2-й шаги могут чередоваться местами
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
84. 1. Определите требования переходного
периода (transition requirements) и свяжите со
сценариями использования и действующими
лицами
2. Определите характеристики качества (Quality
Attributes) и свяжите их свяжите со
сценариями использования и действующими
лицами
На данном шаге необходимо идентифицировать
ограничения и требования, которые
накладывает решение (solution domain)
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
85. 1. Свяжите отношениями зависимости <<depends>>
Бизнес и системные сценарии
2. Свяжите отношениями зависимости системные и
архитектурные сценарии
3. Определите приоритет и очередность разработки
(Road Map) для полученной модели
4. Уберите «висящие» системные сценарии или
найдите для них владельцев
Цель данного шага идентифицировать
пропущенные или «лишние» сценарии
использования
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
87. Полное описание (Fully dressed use case)
Формальный документ основанный на детальном шаблоне
Свободное описание (Casual use case/User story)
Состоит из нескольких абзацев суммирующих сценарий
Краткое описание (Brief)
Состоит из нескольких предложений суммирующих сценарий
Лекция №4. «Моделирование
использования. Анализ проблемы»
‹#›
