Бизнес и системный анализ весна 2013 лекция 4

Лекция №4. «Моделирование использования. Анализ проблемы»

‹#›

Часть 1

‹#›

Анализ проблемы

Формулировка проблемы

Извлечение требований

Заинтересованные лица

Персоны

Концепция

Сценарный подход

‹#›

ЖЦ Продукта

Стратегия Продукта

Описание Возмож-ти

Бизнес кейс

Рынок / Сегмент

Бизнес модель

Концепция продукта Заинтересованные

стороны Формулировка

проблемы Возможности

‹#›

Желательность

идеи

Осуществимость идеи

Жизнеспособность идеи

Клиенты

Что они

думают, делают

и чувствуют?

Имеет ли

бизнес-модель

смысл?

Source: Adapted from IDEO (www.IDEO.com)

Имеем ли мы

необходимые

Технологии?

‹#›

Business Case*

• Business Case является стандартным способом КОММУНИКАЦИИ обоснования начала проекта

• Business Case охватывает финансовые и другие бизнес-аспекты проекта. Как положительные, так и отрицательные

Пакет поддержки принятия решения (“Decision Support Package”) в этом контексте синоним “Business Case”

‹#›

Opportunity

Identification

Concept Generation

Concept

Evaluation

Development Launch

Gate Gate Gate Gate Gate

Оценка Идеи

Грубая оценка

Полный кейс

‹#›

Выделение требований (elicitation)

Анализ требований

(analysis)

Описание требований

(specification).

Валидация требований (validation)

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

(Requirements management)

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

(Change management)

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

Лекция №4. «Моделирование использования. Анализ проблемы» Повторение ( л.1) ‹#›

Problem definition

‹#›

• «Эйнштейн однажды сказал, что правильная постановка задачи важнее даже, чем ее решение.

• Для нахождения приемлемого или оптимального решения задачи важно знать, в чем она состоит. Как ни просто и прозрачно данное утверждение, чересчур многие специалисты в науке управления игнорируют очевидное.

• Миллионы долларов расходуются ежегодно на поиск элегантных и глубокомысленных ответов на неверно поставленные вопросы».

• К. Шеннон

‹#›

Заказчик

(Область проблемы)

• Анализ проблемы

• Выявление и понимание потребностей

Исполнитель

(Область решения)

Определение системы

• Управление границами системы

• Уточнение и улучшение определения системы. Специфицирование

Управление изменениями Лекция №4. «Моделирование

использования. Анализ проблемы» Повторение ( л.1) ‹#›

• Анализ проблемы

• Выявление и понимание потребностей

• Определение системы

• Управление границами системы

• Уточнение и улучшение определения системы. Специфицирование

• Управление изменениями

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

Повторение ( л.1) ‹#›

Проблема

Область решения

Область проблемы

Потребности

Возможности

Требования к ПО

Проектирование Тестиров

ание

Документация

Глоссарий

‹#›

• Для избежание проблемы “Да, …, Но ….”

“Да, {Это удовлетворяет требованиям}, но {это не решает мою проблему}.”

• Решаемая проблема - это источник, и она направляет решение

– Анализ проблемы вначале значительно выгоднее, чем потом …

• Результаты анализа будут использованы в дальнейшем

Формулирование проблемы

Основное действующее лицо – заказчик: “Мне необходимо …”

Формулирование требования

Основное действующее лицо – система: “Система обеспечивает …”

Разработка требований

‹#›

Какая из идентифицированных причин имеет наибольший вклад?

То, что заказчик называет проблемой

Разработка требований

‹#›

• Kurt Levin - американский социальный психолог, автор концепции.

• Force Field Diagram (Диаграмма силового поля) - модель, построенная на идее, что силы как способствуют, так и сдерживают изменения.

• Система находится в динамическом «равновесии» при балансе сил.

• Для проведения изменений, необходимо чтобы сумма «движущих сил» (driving forces), была больше суммы «сдерживающих сил» (restraining forces)

‹#›

Формулировка проблемы Почему? И Как?

Помогает найти корень проблемы

‹#›

Проблема

(The problem of)

Описание проблемы

Затрагивает

(Affects)

Заинтересованные лица

В результате чего

(The impact of which is)

Влияние проблемы

Успешное решение должно

(A successful solution

would)

Ключевые выгоды решения

‹#›

Moore ‘91

Для (заказчик)

У которого (определение возможности или потребности )

(Название продукта )

(категория продукта)

Который ( описание ключевых преимуществ использования).

В отличие от (основная альтернатива)

Наш продукт

(описание дифференциации)

‹#›

Лекция №4. «Моделирование

использования. Анализ проблемы» ‹#›

‹#›

Роль Персона

Бизнес требование Потребность

Возмож-сть Вариант использ-ния

Харак-ка качества

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

‹#›

• Анализ Заинтересованных сторон

• Персоны

• Интервьюирование (Interviews)

• Бизнес-моделирование (Business Modeling)

• Семинар (Requirements Workshop)

• Мозговой штурм (Brainstorming & Idea Reduction)

• Прототипирование (Prototypes)

• Контекстная диаграмма, Сценарии использования

• Словарь Данных

• Планирование извлечения требований

• Вопросники (Questionnaires)

• Ролевые игры (Role Playing)

• Анализ спецификаций требований и другой документации заказчика

‹#›

Определение, ключевые ЗС

Stakeholders

‹#›

Определение: индивидуумы или организации, которые активно вовлечены в проект, или чьи интересы могут быть затронуты в процессе или результате выполнения проекта. Они могут также оказывать влияние на цели и результаты проекта.

Цели проектной команды: должна идентифицировать Заинтересованные стороны, определить их требования и ожидания, и до возможной степени управлять их влиянием на проект для обеспечения его успешности

‹#›

Заинтересованные стороны

Ключевые польз-ли

Конечные польз-ли

Владельцы БП

Спонсор Управл. Партнер

Координатор

проекта

Управляющий комитет

Исполнитель

Заказчик

Поставщик

Члены команды

Руков-ли Групп

‹#›

Кто: Менеджер Исполнителя, осознающий куда ввязался, командир-кандидат в герои (возможно «посмертные»)

Интересы: убедить спонсора на максимально-достаточной бюджет, уговорить заказчика на постановку более простой задачи и договориться с ними о максимально приемлемом сроке

Влияние: участвует в управлении проектом совместно с Менеджером проекта (Заказчик); Организует работы Исполнителя, контролирует работы Заказчика

Обязательства: отвечает за достижение основных параметров проекта

‹#›

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

Интересы: реализовать требования Заказчика за счет своих творческих и других способностей, в соответствии со своим видением

Влияние: обеспечивает успешность функционирования новой системы за счет корректного выполнения своих обязательств

Обязательства: участие в работе проектной группы, выполнение задач в соответствии с рабочим планом; регулярная отчетность о выполнении; участие в формировании требований, тестировании, обучении

‹#›

Кто: эксперты в различных IT областях

Интересы: работа такая, освоение новых знаний, углубление имеющихся

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

Обязательства: помогает Менеджеру оценить техническую сложность проекта, оказывает консультации по всем тех. вопросам в ходе проекта, участвует в разработке архитектуры продукта.

‹#›

Кто: представитель руководства заказчика

Интересы: получить запланированный эффект от проекта

Влияние: принимает окончательное решения при спорных ситуациях; утверждает изменения основных параметров проекта (бюджеты, сроки), определяет цели и идентифицирует выгоды проекта

Обязательства: участвует в управлении проектом и своевременном принятии решений, обеспечивающих успешное завершение проекта, утверждении подходов к выполнению проекта и приемке результатов

‹#›

Кто: руководитель функционального подразделения, эксперт своей предметной области, детально понимающий БП предприятия в этой области и отвечающий за них

Интересы: получить ПРОДУКТ, решающий необходимый круг задач

Влияние: формирует требования к продукту, принимает результаты в своей функциональной области

Обязательства: координирует работы по своему бизнес-процессу, формулирует требования к продукту, участвует в сборе и анализе и детализации требований, контролирует реализацию требований в ходе проекта, участвует в тестировании

‹#›

Кто: специалист своей предметной области, детально понимающий БП предприятия в этой области, будущий ключевой пользователь продукта (Champion)

Интересы: получить УДОБНЫЙ В ИСПОЛЬЗОВАНИИ продукт,

решающий необходимый круг задач Влияние: формирует требования к продукту Обязательства: формулирует требования к

продукту, участвует в сборе и анализе и детализации требований, контролирует реализацию требований в ходе проекта, участвует в тестировании

‹#›

Кто: будущий непосредственный пользователь продукта Интересы: получить УДОБНЫЙ ПРОДУКТ, максимально

упрощающий каждодневную работу Влияние: обеспечивает успешность функционирования

новой системы за счет корректного использования продукта

Обязательства: обучается

новому продукту

‹#›

Кто: «Могучая кучка»: Спонсор проекта, Управляющий партнер, Координатор проекта, Менеджер проекта, другие ЗС, обладающие властью

Интересы: обеспечить нормальный ход проекта

Влияние: принятие, либо утверждение, всех ключевых проектных решений

Обязательства: инициирование старта проекта и фиксация его завершения

‹#›

• ЭМПАТИЯ

– Что говорит

– Что думает

– Что чувствует

– Что делает

• ИНТЕРПРЕТАЦИЯ

– Чего хочет

– Что для него важно

• ФОКУС

– В чем состоит проблема/задача

– Что будет решением

Поиск проблемы

‹#›

Лекция №4.

«Моделирование

использования. Анализ

проблемы»

‹#›

Разработаны Аланом Купером

Архетип пользователя системы для помощи в принятии решения о возможностях, функциях и дизайне

‹#›

На что обращать внимание?

‹#›

Поиск проблемы

• ЭМПАТИЯ

– Что говорит

– Что думает

– Что чувствует

– Что делает

• ИНТЕРПРЕТАЦИЯ

– Чего хочет

– Что для него важно

• ФОКУС

– В чем состоит проблема/задача

– Что будет решением

‹#›

• синтезируется на основе интервью реальных людей

• Суммированное описание содержит

– Поведение ,

– Цели,

– Навыки,

– Отношение

‹#›

• Основные (primary)

• Второстепенные (satisfy when we can)

• Малозначительные (low-priority)

• Затронутые(Affected)

• Исключающие (Exclusionary)

• Заинтерсованные лица (Stakeholders) » From Boxes and Arrows

‹#›

• Документ уровня всей системы, дающий ответы на вопросы “Что ” и “Почему” для продукта или приложения

• Содержит информацию о:

– Потребностях пользователей

– Целях и назначении

– Рынке сбыта

– Среде использования

– Возможностях продукта ( Features)

‹#›

Business case

Business drivers

Vision

Stakeholders & Needs

Problem Statement

Features

‹#›

• Назначение (Документа)

• Границы

• Определение

• Ссылки на другие документы

• Обзор

– Purpose

– Scope

– Definitions, Acronyms

– References

– Overview

‹#›

• Описание возможности

• Описание проблемы

• Позиционирование продукта

2.1 Business Opportunity

2.2 Problem Statement

2.3 Product Position Statement

‹#›

• Динамика рынка

• Обзор заинтересованных сторон

• Обзор пользователей

• Пользовательская среда

• Профили Заинтересованных лиц

• Профили пользователей

3.1 Market Demographics

3.2 Stakeholder Summary

3.3 User Summary

3.4 User environment

3.5 Stakeholder Profiles

3.6 User Profiles

‹#›

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

• Обзор возможностей продукта

• Предположения и зависимости

• Стоимость и ценообразование

• 4.1 Product Perspective

• 4.2 Summary of Capabilities

• 4.3 Assumptions and Dependencies

• 4.4 Cost and Pricing

‹#›

• Возможности продукта

• Ограничения

• Атрибуты качества

• 5. Product Features

• 5.1 <aFeature>

• 5.2 <another Feature>

• 6. Constraints

• 7. Quality Ranges

‹#›

• Приоритеты

• Другие требования к продукту

• Требования к документации

• Приложение 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

‹#›

1. Concept Statement – внешний документ, который готовится для целей демонстрации потребителям и фиксации их реакций

2. Состав Concept Statement: 1. Неудовлетворенные потребности

потребителей

2. Как работает продукт

3. Фичи продукта

4. Преимущества для потребителя Лекция №4. «Моделирование

Concept statement

Customer & Stakeholder

Problem

Statement

Solution

Vision

Concept statement Opportunity statement

‹#›

Написание Concept Statement для тестирования Неудовлетворенные потребности потребителей

Как работает продукт

Возможности продукта

Преимущества для потребителя

‹#›

Лекция №4. «Моделирование

Что мешает сделать все правильно ?

‹#›

Неопределенн

ость

Функциональн

подход

Эффект ряби

‹#›

Сложность

Скурпулезность

анализа

Аналитический паралич

‹#›

• Сценарное планирование метод стратегического планирования, позволяющий управлять неопределенностью будущего.

• Эту концепцию в мире бизнеса популяризировала группа планировщиков из Shell, которая смогла “предсказать” нефтяной кризис 1973г.

‹#›

Движущие силы (Driving forces)

Предопределенные элементы

(predetermined elements)

Ключевых неопределенности(key

uncertainties)

‹#›

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

Максимизация положительного

эффекта

Избежание фатальных

‹#›

• В 1996 году Айвар Джекобсон впервые сформулировал технику визуального моделирования для специфицирования сценариев использования при разработке ПО. Изначально им использовался несколько терминов usage scenarios и usage case, но со временем устоялось использование термина use case.

• Благодаря целой плеяде методистов и в первую очередь Алистеру Коберну в течение 1990-х сценарии использования стали ключевой методологией специфицирования функциональных требований

‹#›

нт (англ. Use Case, а также: вариант использования, сценарий использования) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними акторами (англ. Actors).

http://ru.wikipedia.org/

‹#›

Цель: “Разместить заказ”

sc1 sc2 sc6 sc7 ...

(Успех) (Провал )

Получить

... кредит

... резерв

sc4 sc5 Подцель:

*Коберн Алистер

‹#›

• Один основной сценарий «Ура-сценарий»

• Множество альтернативных

– Типичные варианты Например: Снятие наличных не с того счета

– Редкие варианты Например: Снятие более 1–ого млн

– Исключительные варианты (Ошибки) Например : Ящик с деньгами пуст

‹#›

Бизнес сценарий (Business use case )

Системный сценарий (System use case )

Использует не техническую терминологию

Описывает поведение системы на языке пользователя

Рассматривает систему в качестве «черного ящика»

Определяет функцию которую система предоставляет пользователю

По сути представляет собой описание «Бизнес процесса» по достижении цели уровня бизнеса/пользователя

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

‹#›

• В 2003 году Л. Басс, П. Клементс, Р. Кацман в Книге Software Architecture in Practice предложили подход трансформации Атрибутов качества системы в Сценарии Атрибутов Качества

‹#›

Каркас приложен

Бизнес сценарии

Сценарии использования

Архитектурные сценарии

‹#›

Хижина

Дом советов

‹#›

< Главное Скорость

Главное ? -->

‹#›

• Методология объединяет :

– Пользователя системы (актера)

– Дерево целей

– Связанные между собой общей целью функциональных требований к

системе

• В результате грамотного применения позволяет :

– Поместить функциональные требования в простой и понятный для

конечного пользователя текстовый формат

– Сгруппировать все сценарии достижения и не достижения цели

– Сформировать основу для документирования и прослеживания не

функциональных требований к системе не «завязанную» на реализацию

2-76 Лекция №4. «Моделирование

‹#›

Актер(Actor): это кто-то или что-то взаимодействующее с системой

Сценарий использования(Use case):

Набор экземпляров сценария, где каждый экземпляр это последовательность действий, выполняемых актером и системой, приводящая к получению актером наблюдаемого результата(observable result) или ценности (Value)

Use Case

‹#›

Ассоциация коммуникации (Communicates-association): ассоциация между актером и сценарием, указывающая на их взаимодействие

Стрелка : показывает кто начинает взаимодействие

‹#›

Use Case

Actor 2

Consortium

Bank Customer

Deposit Funds

Withdraw Cash

Transfer Funds

Cashier

Maintain ATM

Maintenance

‹#›

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

Customer

‹#›

1. Идентифицируйте заинтересованных лиц (stakeholders)

2. Определите цели заинтересованных лиц (бизнес сценариев) по отношению к системе

3. Сделайте краткое описание каждого бизнес сценария

Как правило выполняется на этапе формирования концепции для крупной системы или решения

‹#›

1. Определите действующих лиц (actors), а затем сценарии, в которых они участвуют.

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

3. Определите сценарии использования на основе существующих функциональных требований.

4. Сделайте краткое описание каждого сценария.

1-й и 2-й шаги могут чередоваться местами

‹#›

1. Определите требования переходного периода (transition requirements) и свяжите со сценариями использования и действующими лицами

2. Определите характеристики качества (Quality Attributes) и свяжите их свяжите со сценариями использования и действующими лицами

На данном шаге необходимо идентифицировать ограничения и требования, которые накладывает решение (solution domain)

‹#›

1. Свяжите отношениями зависимости <<depends>> Бизнес и системные сценарии

2. Свяжите отношениями зависимости системные и архитектурные сценарии

3. Определите приоритет и очередность разработки (Road Map) для полученной модели

4. Уберите «висящие» системные сценарии или найдите для них владельцев

Цель данного шага идентифицировать пропущенные или «лишние» сценарии использования

‹#›

Сортировка и фильтрация

Архитектурные сценарии

Микрооперации

Бизнес контекст

‹#›

Полное описание (Fully dressed use case)

Формальный документ основанный на детальном шаблоне

Свободное описание (Casual use case/User story)

Состоит из нескольких абзацев суммирующих сценарий

Краткое описание (Brief)

Состоит из нескольких предложений суммирующих сценарий

‹#›

Полное описание (Full

dressed )

Введение

Связанные документы

<Сценарий >

Действующее лицо

Предусловие Ход событий

Основной Альтернативный

Экраны

Эскиз Описание элементов

История изменений

‹#›

Выделение требований (elicitation)

Анализ требований

(analysis)

Описание требований

(specification).

Валидация требований (validation)

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

(Requirements management)

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

(Change management)

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

‹#›

Часть 1

‹#›

Безуглый Дмитрий

bdl@system-approach.ru

‹#›

Бизнес и системный анализ весна 2013 лекция 4

Documents

Бизнес и системный анализ весна...

highload весна 2014 лекция 7

highload весна 2014 лекция 2

web весна 2013 лекция 2

java весна 2014 лекция 1

java весна 2014 лекция 2

Бизнес и системный анализ весна...

web весна 2012 лекция 12

java весна 2013 лекция 6

c++ весна 2014 лекция 2

web весна 2013 лекция 4

Бизнес и системный анализ весна...

web весна 2012 лекция 5

frontend весна 2014 лекция 1

Бизнес весна 2014 лекция 6

Бизнес и системный анализ весна...

web весна 2013 лекция 9

Бизнес и системный анализ весна...

Тестирование весна 2013 лекция 4

frontend весна 2014 лекция 3