Цель презентации

Дать представление об особенностях

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

1 Введение
Введение
2 Классическая
Классическая аналитическая
аналитическая стадия
стадия
3 Особенности
Особенности небольших
небольших задач
задач
4 Рекомендации
Рекомендации
Место аналитической стадии в ЖЦ ИС

?
Требования

Анализ Проектирование
Идея

Разработка

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

Развертывание и
ввод в
Детальные эксплуатацию
требования

3
Обобщенный контекст информационной системы

Автоматизируемые
Участвует в выполнении
процессы

Пользователь

е
т ьзу
т
ю

ол
ру
зи

сп
и

И
ат
м
то
Регламентируют

Ав
выполнение
Программные Функционируют на
средства

с
с т вуют
дей
Нормативно- В за имо
Аппаратно-
методические Регламентируют
программная
документы использование
платформа
Смежные
программные
средства
4
Классическая схема проведения аналитической стадии
Участники аналитической стадии проекта

6
Входные данные аналитической стадии проекта

Исходными данными для аналитической стадии проекта являются:

 Ожидания и потребности Заказчика в виде запроса (RFP)

 Особенности предметной области и деятельности Заказчика, включая:

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

 Сведения об инфраструктуре Заказчика

7
Классическая схема проведения аналитической стадии

Исследование Выявление Формулирование

автоматизируемой потребностей предложений по Создание документа
деятельности Заказчика и автоматизации требований
(AS IS) Пользователей (TO BE)

Выявление и
Определение
анализ
потребностей
требований
Идея Требования
Классическая схема проведения аналитической стадии
• Цели и задачи системы
Определение • Глоссарий терминов и определений (согласованный с заказчиком)
потребностей • Высокоуровневые процессы (описание деятельности)
• Контекст ИС

Исследование • Модели AS IS (организационная, функциональная, информационная,

автоматизируемой IT и пр.)
деятельности • Представление текущей автоматизируемой деятельности в виде
(AS IS) бизнес-процессов

Выявление
потребностей • Упорядоченные и структурированные потребности Заказчика и
Заказчика и Пользователей
Пользователей

• Наложение потребностей на текущую деятельность

Формулирование
• Представление деятельности Заказчика в виде совокупности бизнес-
предложений по
процессов, измененых с учетом предполагаемой автоматизации
автоматизации
• Сценарии использования системы
(TO BE)

Создание документа • Детальные требования, задокументированные в документе

требований требований
Этап «Определение потребностей»

На этапе «Определение потребностей» аналитик должен:

• определить цели, которые Заказчик желает достичь внедрением системы

• определить масштаб системы, детализация которого должна быть достаточна

для оценки трудоемкости реализации проекта

Результаты этапа «Определение потребностей» служат исходной информацией

для оценки трудоемкости создания системы

При реализации сложных систем (либо в условиях повышенных рисков) точно

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

10
Определение границ проекта
Изучить исходную
информацию, определить Существующие проблемы
цели и задачи проекта
RFP, нормативные Уточнить
документы Цели и задачи проекта

Ключевые потребности

Определить границы
проекта

Границы проекта
Оценить текущую
автоматизацию
Автоматизируемые
бизнес-процессы Потребности в интеграции

Выделить группы ключевых

пользователей Требования к программной и
технической платформам
Группы ключевых
Пользователей

11
Цели, задачи и функции

12
Контекст ИС

• диаграмма контекста
• описание контекста системы
• бизнес-требования к ИС

Взаимодействие между
пользователями и системой Информационная
система
Группа Смежная система 1
бизнес-
функций Внутреннее
Группа пользователей 1 (подсистема) взаимодействие
(Роль 1) 1

Взаимодействие со
смежными системами

Группа
бизнес-
функций Смежная система 2
Группа пользователей 2 (подсистема)
(Роль 2) 2

Группа
бизнес-
функций
(подсистема) Смежная система n
n
Группа пользователей n
(Роль n)

13
Этап «Выявление и анализ требований»

На этапе «Выявление и анализ требований» аналитик должен:

• изучить текущую деятельность Заказчика (включая инфраструктуру) – AS IS

• выявить, проанализировать и структурировать ожидания / потребности

Заказчика

• наложить потребности на текущую деятельность и в результате анализа

получить представление деятельности TO BE (с учетом автоматизации)

• сформулировать и документировать требования к Системе и входящим в ее

состав программным компонентам

14
 Этап «Выявление и анализ требований»

ВЫЯВЛЕНИЕ АНАЛИЗ СПЕЦИФИКАЦИЯ ПРОВЕРКА

Текущая

AS IS
деятельность
(AS IS)
Документ
Потребности, требований
желания
заказчика
TO BE

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

Уточнение
Переработка

Повторная оценка
15
Работы этапа анализа автоматизируемой области

16
Определение потребностей пользователей

Пользовательские требования определяют бизнес-логику создаваемой

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

Представитель Заказчика Команда Исполнителя

17
 Модель TO BE

Заказ
1..* включает4 1 Клиент
Позиция заказа Номер 3 делает
Имя
Количество Дата заказа
Адрес
Дата оплаты * 1 Оплатить()
Сумма()
*
входит в4 *
работает с4
ФизЛицо
1 0..1

Товар Сотрудник
Название Имя формирует отчет4 ЮрЛицо
Цена Принять() Лимит кредита
Проверить оплату() 0..1 *
Выполнить()

18
Пользовательские требования

• На основе анализа процессов TO BE можно определить пользовательские

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

• Пользовательские требования формулируются в терминах

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

• Пользовательские требования могут формализоваться в виде

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

19
Детализация требований

Детализация требований в общем случае может быть разделена на:

• определение сценариев (процессов) функционирования

системы;
• описание детальных требований.

20
Сценарии использования системы (прецеденты)

• Сценарии функционирования системы определяются на основе

анализа пользовательских требований и детально описывают
поведение системы в тех или иных случаях
• Сценарии характеризуются Пользователями и потоками выполнения
• Выявление и описание сценариев позволяет выявить все
особенности работы системы, которые невозможно
идентифицировать на уровне пользовательских требований

21
Выявление детальных требований

Прецедент

Основной поток 1
Детальное
Альтернативные потоки функциональное
требование
Исключительные потоки 3 Объявление функции

Входные данные

Логика выполнения
4
Модель данных
2 Результат выполнения

Исключительные ситуации и
Сущности их обработка

Атрибуты сущностей

22
Трассировка детальных функциональных требований

Трассировка требований
Детальные требования наиболее часто трассируются:
• с другими детальными требованиями Потребности
• с прецедентами, на основе анализа которых они были клиента
выявлены

Трассировки требований документируются в виде матрицы

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

Use case (UC)

Requirement
(RE) UC1 UC2 UC3 UC4

Основные
RE1 √
рабочие
RE2 √ продукты
RE3 √
RE4 √
RE5 √ √
RE6 √

23
 Результат аналитической стадии проекта

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

 Требования уровня бизнеса:

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

 Требования уровня Пользователей:

• модель автоматизируемой предметной области AS IS
• упорядоченные и структурированные потребности Пользователей
• модель предметной области в условиях автоматизации TO BE
• сценарии использования системы

 Детальные требования к проектируемым программным компонентам

24
Формулировка детальных функциональных требований

Номер Описание требования Приоритет Сложность Связанные

требова-ния реализации требования
(Критично/ (Низкая/ Средняя/
Важно/ Высокая)
Желательно)
RE.4.1 Система должна автоматизировать подпроцесс «Отчет курьера по BR.4.1
заказам с сопроводительной документацией» Критично Высокая
RE.4.1.1 Система должна обеспечивать возможность выбора заказа. UC 4.1.1
Критично Высокая BR.4.1
RE.4.1.1.1 Система должна обеспечивать возможность открытия формы заказа UC 4.1.1
путем считывания сканером штрих-кода, напечатанного на Критично Высокая BR.4.1
сопроводительном документе заказа.

25
Итак,

Давайте попробуем еще раз озвучить состав задач и работ аналитика

 Взаимодействие аналитика

Спонсор
проекта Менеджеры
Поток
Бизнес- информации
проекта
требования

Пользовательские
требования
Функциональные и
Аналитик нефункциональные
требования
Представители Разработчики
пользователей
Ожидания и
ограничения

Прочие
участники

Тестировщики
28
 Особенности небольших задач

1. Тяжело спрятать риски

2. Система сильно завязана на уже существующую структуру бизнеса и
архитектурных решений
3. Сложно организовать передачу знаний от аналитика к разработчикам и
аналитикам
4. Необходимость оптимизации технологии работы в команде под
конкретные условия проекта
5. Бизнес четко понимает задачу
Риски

1. Не уложиться в бюджет
2. Не попасть в ожидания
3. На попасть в оценки
4. Слишком конкретные вопросы