Основы системного анализа и моделирования

1. Основы системного анализа и моделирования (с акцентами на взаимодействие системного аналитика с архитектором)

Перерва А., Иванова В., Седов Е.,
2009
1

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

Рассказ об основах системного анализа,
разработки и управления требованиями с
акцентами на взаимодействие системного
аналитика с архитектором
2

3. Содержание презентации

Вводная часть
Моделирование
Разработка и Управление
требованиями
3

4. Вводная часть

В системном анализе выделяются 3 области:
• Моделирование
• Разработка требований
Системный анализ
• Управление требованиями
Все эти области тесно
переплетены между
собой
RM
Modeling
Analysis
При работе над каждой из
областей, системный
аналитик проводит
АНАЛИЗ
RD
4

5. Вводная часть

Системный анализ
RM
Обзор использовавшихся при разработке подхода
методологий
Modeling
Analysis
RD
Методология системного анализа – это
способ выполнения системного анализа
В качестве эталонных моделей для создания рассматриваемого подхода к
системному анализу выбраны методология RUP и ICONIX, они же выбраны в
качестве основы для разработки методологии разработки и управления
требованиями в компании.
Это не значит, что все взяты дисциплины и активности указанных
методологий, - так как полновесный RUP излишне сложный для проектов
компании, а ICONIX не всегда оптимален с точки зрения акцента на
разработке, управляемой моделями.
В основу рассматриваемой методологии системного анализа легли:
Методология RUP
Методология ICONIX
Собственный опыт
5

6. Моделирование

6

7. Где мы?

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

8. Моделирование

Обзор моделей
<<communicate>>
Заказ
Адрес доставки
• Модель предметной области (Domain object model)
Размещение заказа
<<communicate>>
Заказчик по телефону
Телефонный заказ
Контроль состояния заказа
Телефонный заказчик
Модель предметной
области
Концептуальная модель
системы
• Концептуальная модель системы (Conceptual model)
Бизнес-модель
• Модель вариантов использования (Use Case model)
• Модель анализа (Analysis model)
Модель вариантов
использования
• Логическая модель (Logical model)
Динамическая модель
анализа
Статическая модель
анализа
Модель развертывания
Компонентная модель
Логическая
модель
• Модель дизайна (Design model)
• Модель реализации (Implementation model)
Используемые диаграммы
• Диаграмма вариантов использования (Use case diagram)
• Диаграмма классов (Class diagram)
• Диаграмма активности (Activity diagram)
Диаграмма устойчивости
Диаграмма
последовательности
• Диаграмма последовательности (Sequence diagram)
• Диаграмма устойчивости (Robustness diagram)
8

9. Моделирование

Системный анализ
Моделирование
RM
Modeling
Analysis
RD
Последовательность разработки моделей
Динамика
Модель вариантов
использования
Диаграмма устойчивости
Диаграмма
последовательности
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
За ка з
Те ле ф о н н ый за ка з
Динамическая модель
анализа
Логическая
модель
Адр е с до с та в ки
Те ле ф о н н ый за ка зч и к
Модель предметной
области
Статика
Модель
дизайна
Статическая модель
анализа
Концептуальная модель
системы
9

10. Моделирование

Используемый пример
Системный анализ
RM
Modeling
Analysis
RD
Корпоративная служба обмена файлами
Система представляет собой сервис обмена файлами в корпоративной сети.
Основная задача – обеспечить гарантированную доставку сообщений (файлов) в
гибридной сетевой среде.
Существенной особенностью системы является обеспечение функций
защищенной/безопасной доставки.
Система обладает развитым Web-интерфейсом.
Система позволяет интегрироваться с существующими сервисами
аутентификации/авторизации, а также предоставляет функции экспорта и выгрузки
файлов из существующей системы документооборота компании.
10

11. Моделирование

Последовательность разработки моделей
Системный анализ
RM
Modeling
Analysis
RD
Динамика
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Заказ
Адрес доставки
Оператор
Телефонный заказ
Телефонный заказчик
Модель предметной
области
Статика
11

12. Моделирование

Польза проектной команде:
Модель дает однозначную
трактовку используемых терминов
и понятий предметной области.
Все говорят на одном языке.
Модель предметной области
Назначение:
Выявление, классификация и
формализация сведений обо всех
аспектах предметной области,
определяющих свойства
разрабатываемой системы
Системный анализ
RM
Modeling
Analysis
RD
0..n
1 Документ
1
1
1..n
1
Файл
Сообщение
Основной интерес:
Незашифрованное сообщение
Ключ шифрования
Незашифрованный файл
зашифрован
зашифрован
- Менеджер продукта
- Менеджер проекта
Зашифрованный файл
Зашифрованное сообщение
- Системный аналитик.
12

13. Моделирование

Последовательность разработки моделей
Системный анализ
RM
Modeling
Analysis
RD
Динамика
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Заказ
Адрес доставки
Оператор
Телефонный заказ
Телефонный заказчик
Модель предметной
области
Статика
Концептуальная модель
системы
13

14. Моделирование

Концептуальная модель
системы
Системный анализ
Польза проектной команде:
RM
Modeling
Analysis
Модель дает единый взгляд
проектной команды на
предварительный состав
системы.
RD
Назначение:
Выявление, классификация
и формализация сведений о
разрабатываемой системе
Основные
атрибуты
Основной интерес:
- Системный аналитик
- Архитектор
14

15. Моделирование

Последовательность разработки моделей
Системный анализ
RM
Modeling
Analysis
RD
Динамика
Модель вариантов
использования
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Заказ
Адрес доставки
Оператор
Телефонный заказ
Телефонный заказчик
Модель предметной
области
Статика
Концептуальная модель
системы
15

16. Моделирование

Польза проектной команде:
Модель вариантов использования
Назначение:
Системный анализ
RM
Modeling
Analysis
Модель дает единый взгляд
проектной команды на поведение
системы.
Описание поведения разрабатываемой
системы (как пользователи взаимодействуют
с системой, и что система делает в ответ на
эти взаимодействия)
Выбрать файл
Выбрать получателя
(f rom Выбрать файл)
(f rom Выбрать полу чателя)
RD
<<include>> <<include>>
Авторизация
(f rom Ау тентификация и Ав торизация)
Описание варианта использования
Создать сообщение
Цель
<<include>>
Отправить сообщение
<<include>>
Основной поток
<<extend>> Зашифровать файл
(f rom Шифров ание)
Пользователь инициирует создание
нового сообщения.
Основной интерес:
- Менеджер продукта
- Менеджер проекта
- Архитектор
- Системный аналитик
Система отображает форму
"Отправить сообщение".
Пользователь вводит текст
сообщения.
Пользователь инициирует отправку
сообщения.
Отправить сообщение
<<include>>
Отправить уведомления
Пользователь
(f rom Ув едомление пользов ателей)
(from Все пользователи)
Получить сообщение
Если пользователь VIP, то система
шифрует сообщение.
<<extend>>
Система отправляет сообщение.
VIP
(from Все пользователи)
Расшифровать файл
(f rom Шифров ание)
16

17. Моделирование

Последовательность разработки моделей
Системный анализ
RM
Modeling
Analysis
RD
Динамика
Модель вариантов
использования
<<communicate>>
Размещение заказа
Диаграмма устойчивости
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Заказ
Адрес доставки
Оператор
Телефонный заказ
Телефонный заказчик
Модель предметной
области
Статика
Концептуальная модель
системы
17

18. Моделирование

Модель анализа – диаграммы
устойчивости
Системный анализ
Польза проектной команде:
Диаграммы устойчивости
обеспечивают более высокое
качество описания вариантов
использования.
RM
Modeling
Analysis
RD
Назначение:
Основной интерес:
Служит связующим звеном между
описанием варианта использования
и аналитическими моделями
Описание варианта использования
Цель
- Системный аналитик
Пользователь Форма "Отправить сообщение"
Отправить сообщение
Проверить права пользователя
(f rom Все пользов атели)
...)
Отправить сообщение
Основной поток
Пользователь инициирует создание
нового сообщения.
Система отображает форму
"Отправить сообщение".
Пользователь вводит текст
сообщения.
Зашифрованное сообщение
VIP
(f rom Все пользов атели)
...)
Пользователь инициирует отправку
сообщения.
Если пользователь VIP, то система
шифрует сообщение.
Система отправляет сообщение.
Создать сообщение
Сообщение
(f rom Создать сообщение)
(f rom Создать сообщение)
Зашифровать сообщение
18

19. Моделирование

Последовательность разработки моделей
Системный анализ
RM
Modeling
Analysis
RD
Динамика
Модель вариантов
использования
Диаграмма
активности
<<communicate>>
Размещение заказа
<<communicate>>
Диаграмма устойчивости
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Заказ
Адрес доставки
Оператор
Телефонный заказ
Телефонный заказчик
Модель предметной
области
Статика
Концептуальная модель
системы
19

20. Моделирование

МоделированиеПольза проектной команде:
Модель анализа – диаграммы
активности
Возможность наглядно видеть
логику, заложенную в описании
варианта использования.
Пользователь
Назначение:
Служит для графического
представления
последовательности и
условий выполнения
активностей варианта
использования
RM
Modeling
Analysis
RD
КСОФ
Запрос на
импорт файла
Отображение диалога
запроса файла из iDoc
Ввод уникального
идентификатора документа
Проверка введенных
параметров
Нет
Параметры соответствуют
интерфейсу iDoc
Да
Запрос на импорт документа в
систему iDoc и обработка ответа
Да
копирование указанного документа и
помещение его во вложение
Основной интерес:
Системный анализ
Регистрация события
"Импорт файла из iDoc"
удалось найти документ
в системе iDoc
Нет
Отобразить сообщение о
невозможности импорта
запрашиваемый документ в
системе iDoc не существует
- Системный аналитик
- Архитектор
файл скопирован во вложение
создаваемого сообщения
20

21. Моделирование

Системный анализ
Моделирование
RM
Modeling
Analysis
Последовательность разработки моделей
RD
Динамика
Модель вариантов
использования
Диаграмма
последовательности
Диаграмма устойчивости
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Заказ
Адрес доставки
Оператор
Телефонный заказ
Телефонный заказчик
Модель предметной
области
Статика
Концептуальная модель
системы
21

22. Моделирование

Польза проектной команде:
Понимание принципов
реализации поведения системы.
Модель анализа – диаграммы
последовательности
Системный анализ
RM
Modeling
Analysis
RD
Назначение:
Служит для графического
представления
взаимодействий между
объектами во времени : Пользователь
Описание варианта использования
: Форма "Отправить сообщение"
: Создать сообщение
: Проверить права
пользователя
: Зашифровать
сообщение
: Отправить сообщение
Создать сообщение
Создать сообщение
Цель
Отправить сообщение
Проверить права
Ок
Основной поток
Зашифровать
Пользователь инициирует создание
нового сообщения.
Система отображает форму
"Отправить сообщение".
Пользователь вводит текст
сообщения.
Пользователь инициирует отправку
сообщения.
Ок
Ок
Отправить сообщение
Отправить
Ок
Если пользователь VIP, то система
шифрует сообщение.
Система отправляет сообщение.
22

23. Моделирование

Системный анализ
Моделирование
RM
Modeling
Analysis
Последовательность разработки моделей
RD
Динамика
Модель вариантов
использования
Диаграмма
последовательности
Диаграмма устойчивости
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Динамическая модель
анализа
Заказ
Адрес доставки
Статическая модель
анализа
Оператор
Телефонный заказ
Телефонный заказчик
Модель предметной
области
Статика
Концептуальная модель
системы
23

24. Моделирование

Польза проектной команде:
Модель анализа – статическая
часть
Назначение:
Системный анализ
RM
Модель обеспечивает более
высокое качество Логической
модели.
Уведомление
Логин пользователя
Список документов
(f rom Отправ ить у в едомление)
(f rom Отправ ить сообщение)
(f rom Выбрать файл)
Modeling
Analysis
RD
Общий взгляд на статическую
модель сущностей системы
Список пользователей системы
Содержимое локального диска
(f rom Выбрать полу чателя)
(f rom Выбрать файл)
Зашифрованное сообщение
Сообщение
(f rom Отправ ить сообщение)
(f rom Создать сообщение)
Основной интерес:
- Системный аналитик
Текстовое описание
(f rom Создать сообщение)
Файл вложения
Список получателей
(f rom Выбрать файл)
(f rom Выбрать полу чателя)
24

25. Моделирование

Системный анализ
МоделированиеПольза проектной команде:
Модель анализа –
динамическая часть
Назначение:
RM
Modeling
Analysis
Модель обеспечивает более
высокое качество Логической
модели.
RD
Выбрать получателей
Отобразить всех пользователей
(f rom Выбрать полу чателя)
(f rom Выбрать полу чателя)
Общий взгляд на
динамическую модель
системы
Создать сообщение
(f rom Создать сообщение)
Ввести текстовое описание
Отобразить список файлов
(f rom Создать сообщение)
(f rom Выбрать файл)
Форма "Отправить сообщение"
(f rom Отправ ить сообщение)
Выбрать файл
Добавить влож ение
(f rom Выбрать файл)
(f rom Выбрать файл)
Основной интерес:
- Системный аналитик
Отправить сообщение
Отправить уведомление
Сформировать уведомление
(f rom Отправ ить сообщение)
(f rom Отправ ить у в едомление)
(f rom Отправ ить у в едомление)
25

26. Моделирование

Системный анализ
Моделирование
RM
Modeling
Analysis
Последовательность разработки моделей
RD
Динамика
Модель вариантов
использования
Диаграмма
последовательности
Диаграмма устойчивости
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Динамическая модель
анализа
Заказ
Адрес доставки
Статическая модель
анализа
Оператор
Телефонный заказ
Логическая
модель
Телефонный заказчик
Модель предметной
области
Статика
Концептуальная модель
системы
26

27. Моделирование

Логическая модель
Системный анализ
Польза проектной команде:
Модель отражает логику
реализации системы.
RM
Modeling
Analysis
RD
Назначение:
Показывает распределение
поведения системы по
классам
Основной интерес:
- Архитектор
27

28. Моделирование

Системный анализ
Моделирование
RM
Modeling
Analysis
RD
Последовательность разработки моделей
Динамика
Модель вариантов
использования
Диаграмма устойчивости
Диаграмма
последовательности
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
За ка з
Те ле ф о н н ый за ка з
Динамическая модель
анализа
Логическая
модель
Адр е с до с та в ки
Те ле ф о н н ый за ка зч и к
Модель предметной
области
Статика
Модель
дизайна
Статическая модель
анализа
Концептуальная модель
системы
28

29. Разработка и управление требованиями

29

30. Где мы?

Управление
требованиями
Системный анализ
RM
Системный анализ
Modeling
RM
Analysis
Modeling
Analysis
RD
RD
Разработка
требований
30

31. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Принципы определения и формулировки требований
RD
В основе принципа определения и формулирования требования лежит
определение требования Institute of Electrical and Electronics Engineers, USA –
мировой ведущей ассоциации профессионалов для развития технологий:
(A) Условие или способность, необходимая пользователю чтобы
решить проблему или достигнуть цели.
(B) Условие или способность, которыми должна обладать система или
компонента системы для удовлетворения контракта, стандарта, спецификации
или другого формально установленного документа.
(C) документированное представление условия или способности,
показанной в определении (A) или (B).
© (IEEE Std 610.12-1990)
Кроме того, при формулировании требования должны соблюдаться
основополагающие характеристики требования:
Требование должно быть тестируемым
Требование должно быть реализуемым
Требование должно быть ясным для понимания
Требование должно быть законченным и полным
31

32. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Организация требований
Использование специальных инструментов для
разработки и управления требованиями
RD
Проектная команда работает с информацией,
а не с документами.
Нет необходимости знать, в каком конкретно
документе искать требование.
Нет необходимости знать структуру документа,
чтобы знать, в каком разделе документа искать
требование.
Нет необходимости вводить понятие связи
документов или разделов документов, – связка
проводится на более детальном уровне, –
уровне требований.
32

33. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Организация требований
RD
Преимущества организации требований
При работе в команде наличие четко закрепленной
и наглядно выраженной структуры требований
определяют УНИФИЦИРОВАННЫЙ взгляд на
концепцию будущей системы.
Все аналитики – единое видение
Разные роли – единое видение
Взаимное уточнение и контроль описаний требований
и их организации (группировки, иерархии,
трассировки)
При работе в команде наличие четко закрепленной
и наглядно выраженной структуры требований
приводят к раннему и полному ВОВЛЕЧЕНИЮ всех
проектных ролей в требования на ранних этапах.
33

34.

Разработка и управление требованиями
Обзор пакетов спецификаций требований
1. Extreme
2. Simple
3. Basic
4. Advanced
5. Gold
6. VIP
Расширение пакетов
спецификаций
34

35. Разработка и управление требованиями

Обзор пакетов спецификаций требований
Риски
max
min
Линия развития
продукта
Проект 1
Пример
Тип пакета
спецификаций для
продукта – Extreme
Тип пакета
спецификаций для
проектов 1, 3 и 4 –
Extreme, для проекта 2 Simple
Время жизни продукта
Проект 2
Проект 3
Проект 4
WBS
аналитических
работ
Extreme
Simple
Basic
Advanced
Gold
VIP
Пакеты спецификаций
35

36.

Разработка и управление требованиями
Пакет Extreme
1. Extreme
2. Simple
3. Basic
4. Advanced
5. Gold
6. VIP
Расширение пакетов
спецификаций
Пакет включает в себя:
- документ "Концепция системы", расширенный разделом "общее описание
функциональности" - общее описание поведения системы в простой не
структурированной форме.
36

37.

Разработка и управление требованиями
Пакет Simple
1. Extreme
2. Simple
3. Basic
4. Advanced
5. Gold
6. VIP
Расширение пакетов
спецификаций
Пакет включает в себя:
• Простой проект требований, в котором выделяются
- функциональные требования;
- нефункциональные требования (ограничения, допущения, перечень
поддерживаемых ОС);
• Модель вариантов использования с кратким описанием
• Спецификацию "Требования к системе"
Управление требованиями минимальное:
- статус требования "предложено-утверждено"
- обсуждение в виде дискуссий.
37

38.

Разработка и управление требованиями
Пакет Basic
1. Extreme
2. Simple
3. Basic
4. Advanced
Расширение пакетов
спецификаций
5. Gold
6. VIP
Базовый пакет спецификаций требований
Пакет включает в себя:
• Модели
- Модель вариантов использования (описание на уровне цели + основной поток);
• Проект требований, интегрированный с моделью, в котором выделяются
- бизнес требования;
- варианты использования;
- функциональные требования;
- нефункциональные требования (ограничения, допущения, перечень поддерживаемых ОС);
• Спецификации
- спецификация "Словарь терминов и понятий";
- спецификация "Обзор вариантов использования";
- спецификация "Требования к системе";
Управление требованиями средней сложности
- статус требования "предложено-одобрено(feasibility)-утверждено"
- обсуждение в виде дискуссий.
38

39.

Разработка и управление требованиями
Основные типы требований
учитываются
Оранжевым цветом выделены
основные результаты разработки
требований
<<STKR>>
Запросы ЗЛ
<<BVISION>>
Концепция создания и развития продукта
учитываются
учитываются
(from Ис точники)
<<UREQ>>
Пользовательские требования
учтены
реализуют
<<UC>>
Варианты использования
учитываются
<<FR>>
Функциональные требования
3 «кита»:
- Варианты
использования;
- Функциональные
требования;
учесть при реализации
учитываются
<<NFR>>
Нефункциональные требования
<<ASSUM>>
Ограничения, допущения
(from Ис точники)
учитываются
учитываются
учитываются
<<TVISION>>
Концепция системы
- Нефункциональные
требования.
39

40. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Типы требований
Основные типы
требований
RD
<<STKR>>
Запросы ЗЛ
учитываются
(from Ис точники)
<<BVISION>>
Концепция создания и развития продукта
учитываются
учтены
учитываются
<<UREQ>>
Пользовательские требования
<<UC>>
Варианты использования
формируют
Модель вариантов
использования
учитываются
<<FR>>
Функциональные требования
учесть при реализации
<<NFR>>
Нефункциональные требования
учитываются
<<TVISION>>
Концепция системы
учитываются
<<TERM>>
Глоссарий
40

41. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Единая среда разработки
RD
Единая среда
разработки
Ва
испо риант
льзо
в ан и
я
Возможность быстрого
перехода от требования в
репозитарии требований к
соответствующему варианту
использования в модели
вариантов использования
Инструмент
моделирования
Требование
типа «UC»
Инструмент для
разработки и
управления
требованиями
Возможность быстрого
перехода от варианта
использования в модели
вариантов использования к
соответствующему требованию
в репозитарии требований
Управление статусом
и атрибутами
требования «UC»,
трассировками.
41

42. Разработка и управление требованиями

Типы требований
Системный анализ
RM
Modeling
Analysis
RD
Требования Бизнесвидение (BVision)
<<communicate>>
Размещение заказа
<<communicate>>
Заказчик по телефону
Контроль состояния заказа
Бизнес-модель
Заказ
Телефонный заказ
Адрес доставки
Телефонный заказчик
Модель предметной
области
42

43. Разработка и управление требованиями

Типы требований
Системный анализ
RM
Modeling
Analysis
RD
Требования
Техническое
видение (TVision)
Разрабатывает
архитектор
Концептуальная модель
системы
Компонентная модель
Модель развертывания
43

44. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Типы требований
Основные типы
требований
RD
<<STKR>>
Запросы ЗЛ
учитываются
(from Ис точники)
<<BVISION>>
Концепция создания и развития продукта
учитываются
учтены
учитываются
<<UREQ>>
Пользовательские требования
<<UC>>
Варианты использования
формируют
учитываются
<<FR>>
Функциональные требования
учесть при реализации
<<NFR>>
Нефункциональные требования
учитываются
<<TVISION>>
Концепция системы
учитываются
<<TERM>>
Глоссарий
44

45. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Типы требований
RD
Нефункциональные
требования
45

46. Разработка и управление требованиями

Системный анализ
RM
Modeling
Analysis
Типы требований
RD
Основные типы
требований
<<STKR>>
Запросы ЗЛ
учитываются
(from Ис точники)
<<BVISION>>
Концепция создания и развития продукта
учитываются
учтены
учитываются
<<UREQ>>
Пользовательские требования
<<UC>>
Варианты использования
формируют
учитываются
<<FR>>
Функциональные требования
учесть при реализации
<<NFR>>
Нефункциональные требования
учитываются
<<TVISION>>
Концепция системы
учитываются
<<TERM>>
Глоссарий
46

47. Разработка и управление требованиями

Атрибуты требований
Системный анализ
RM
Modeling
Analysis
RD
47

48. Разработка и управление требованиями

Атрибуты требований – атрибут «Статус»
Системный анализ
RM
Modeling
Analysis
RD
Диаграмма состояний
требований
В работе
Отклонено
Утверждено
Реализовано
Протестир
овано
48

49. Разработка и управление требованиями

Трассировки требований
Представление трассировок в
виде дерева
Системный анализ
RM
Modeling
Analysis
RD
Тип требования 1
Тип требования 2
Тип требования 3
49

50. Разработка и управление требованиями

Трассировки требований
Системный анализ
RM
Modeling
Analysis
RD
Табличное представление трассировок
Тип требования 1
Тип требования 2
50

51. Разработка и управление требованиями

Цели и задачи ролей проектной команды
со
би
ра
ет
за
Менеджер продуктов (МПР) про
с
ы
про
изво
дит
ана бизнес
лиз
-
снимае
т
Заказчик
Риски
снимает
п
вы
Проводит системный
анализ:
1. выявление требований,
2. моделирование,
3. разработка требований,
4. управление
требованиями
Менеджер программы проектов (МПГП)
выявляет и управляет
Какие задачи решает
системный аналитик?
ЗЛ
н
ол
Системный аналитик (СА)
т
яе
WBS аналит. работ
1..*
*
Артефакт
ти т
уе уе
ир ир
ан ол
пл нтр
ко
Задача:
Снять риски через
выполнение аналитических
работ
Системный архитектор (АРХ)
51
Менеджер проекта (МП)

52. Разработка и управление требованиями

Цели и задачи ролей проектной команды
со
би
ра
ет
за
Менеджер продуктов (МПР) про
с
ы
про
изво
дит
ана бизнес
лиз
-
Задача:
Снять риски, связанные с
архитектурой
Менеджер программы проектов (МПГП)
снимае
т
выявляет и управляет
Какую задачу решает
системный архитектор?
ЗЛ
Заказчик
Риски
снимает
п
вы
н
ол
Системный аналитик (СА)
т
яе
Системный архитектор (АРХ)
WBS аналит. работ
1..*
Артефакт
ти т
уе уе
ир ир
ан ол
пл нтр
ко
*
52
Менеджер проекта (МП)

53. Разработка и управление требованиями

Цели и задачи ролей проектной команды
со
би
ра
ет
за
Менеджер продуктов (МПР) про
с
ы
про
изво
дит
ана бизнес
лиз
-
снимае
т
Заказчик
Риски
снимает
п
вы
Системный аналитик (СА)
н
ол
Системный архитектор (АРХ)
т
яе
WBS аналит. работ
1..*
*
Артефакт
ти т
уе уе
ир ир
ан ол
пл нтр
ко
Задачи:
1. Планирует и контролирует
выполнение
аналитических работ
2. Решает в какой форме
фиксировать результаты
работ
3. Выстраивает
эффективные
коммуникации в команде
Менеджер программы проектов (МПГП)
выявляет и управляет
Какие задачи решает
менеджер проекта?
ЗЛ
Менеджер проекта (МП)
53

54. Презентация окончена

Прошу вас делиться своими впечатлениями :
• что было полезно,
• что нет,
• что информативно,
• что наиболее интересно,
• что совсем не интересно.
по адресу [email protected]
Спасибо.
54

55. Соглашение об использовании материала

Данный файл был скопирован с сайта http://pmway.codeplex.com . Пожалуйста, прочтите правила использования материалов сайта.
Правила использования материалов сайта*
Все материалы сайта* размещены с согласия их правообладателей. Полное или частичное копирование и размещение материалов с
сайта* разрешается при соблюдении следующих условий:
1.
В соглашении об условиях использования материала нет запрета на полное или частичное размещение материала без согласия
правообладателей.
2.
Изменения и правки в содержании материала не допускаются без предварительного согласия правообладателей на эти
изменения.
3.
Правообладатели были уведомлены об использовании материала.
Правообладатели имеют право запретить несанкционированное размещение материала, если это действие сопряжено с риском
компрометации или нанесения вреда репутации правообладателей или сайта*.
4.
Ссылка на сайт* и авторов материала являются обязательными.
При нарушении хотя бы одного из вышеуказанных условий полное или частичное копирование и размещение материалов с сайта* без
согласия правообладателей не допускается.
Если вы хотите получить разрешение на копирование, публикацию, либо иные действия с разрешенным материалом, а также
уведомить правообладателей о публикации материала, пожалуйста, обращайтесь к координатору сайта**.
Все материалы сайта* публикуются под брендом “Путь аналитика”.
Бренд “Путь аналитика” защищен авторским правом и не может использоваться в рекламных целях без разрешения
правообладателей.
По всем возникающим вопросам по использованию материалов сайта* обращайтесь к координатору сайта**.
Примечания
*сайт – это ресурсы:
http://pmway.codeplex.com/
http://www.bestpractices.ru
http://www.bp4you.ru
http://saway4ru.codeplex.com/
http://saway.codeplex.com/
http://sadd4ru.codeplex.com/
http://sadd.codeplex.com/
**координатор сайта: Для отправки сообщения требуется регистрация на сайте*.
Соглашение об использовании материала
Данный файл разрешается использовать, изменять без уведомления правообладателей, если он используется по прямому его
назначению.
При использовании файла в качестве примера, ссылочного материала ссылка на сайт* и авторов материала являются
обязательными.