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

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

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

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

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

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

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

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

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

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

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

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

6

7. Где мы?

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

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

Обзор моделей
• Модель предметной области (Domain object model)
• Концептуальная модель системы (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. Моделирование

Последовательность разработки моделей
9

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

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

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

Последовательность разработки моделей
11

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

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

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

Последовательность разработки моделей
13

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

Польза проектной команде:
Модель дает единый взгляд
Концептуальная модель системы
проектной команды на
предварительный состав
системы.
Назначение:
Уведомление
Выявление, классификация
и формализация сведений о
разрабатываемой системе
1
+Отправитель
1
Сообщение
1
Профиль пользователя
Основные
атрибуты
Дата создания
Дата отправки
Важность
1..*
1
+Получатель
1
Основной интерес:
- Системный аналитик
1
Тестовое сообщения
Тема
1
1
1
Файл
- Архитектор
14

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

Последовательность разработки моделей
15

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

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

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

Последовательность разработки моделей
17

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

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

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

Последовательность разработки моделей
Диаграмма
активности
19

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

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

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

Последовательность разработки моделей
21

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

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

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

Последовательность разработки моделей
23

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

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

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

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

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

Последовательность разработки моделей
26

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

Польза проектной команде:
Модель отражает логику
реализации системы.
Логическая модель
Назначение:
Показывает распределение
поведения системы по
классам
Сообщение
+Отправитель
1
Пользователь
Текстовое описание
Файл вложения
Список получателей
Отправитель
Сервис AZN
Установить список получателей()
Установить файл вложения()
1..*
Получить список пользователей()
Проверить привилегии пользователя()
+Получатель
Форма "Отправить сообщение"
Сообщение
Отобразить список получателей()
Отобразить список файлов()
Отправить()
Система iDoc
Получить список документов()
Получить документ()
Основной интерес:
- Архитектор
Модуль уведомлений
Сформировать уведомление()
Отправить уведомление()
Модуль CryptX13
Зашифровать()
Расшифровать()
Локальный диск
Получить список файлов()
Получить файл()
27

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

Последовательность разработки моделей
28

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

29

30. Где мы?

Управление
требованиями
Разработка
требований
30

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

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

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

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

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

Разработка и управление
Организация требований
требованиями
Преимущества организации требований
При работе в команде наличие четко закрепленной и наглядно выраженной
структуры требований определяют УНИФИЦИРОВАННЫЙ взгляд на концепцию
будущей системы.
Все аналитики – единое видение
Разные роли – единое видение
Взаимное уточнение и контроль описаний требований и их организации
(группировки, иерархии, трассировки)
При работе в команде наличие четко закрепленной и наглядно выраженной
структуры требований приводят к раннему и полному ВОВЛЕЧЕНИЮ всех
проектных ролей в требования на ранних этапах.
Минимальные затраты на согласование требований и на изменение требований
Минимальные затраты на обучение законченным требованиям
Взгляд на требования со всех точек зрения на ранних стадиях
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. Разработка и управление требованиями

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

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

Единая среда разработки
Возможность быстрого
перехода от требования в
репозитарии требований к
соответствующему варианту
использования в модели
вариантов использования
Возможность быстрого
перехода от варианта
использования в модели
вариантов использования к
соответствующему требованию
в репозитарии требований
41

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

Типы требований
Требования Бизнесвидение (BVision)
<<ANSW>>
Результаты интервью
(from Ис точники)
учитываются
<<STSTD>>
Стандарты и ГОСТы
<<SERT>>
Требования сертифицирующ их организаций
(from Ис точники)
(from Ис точники)
учитываются
<<STKR>>
Запросы ЗЛ
(from Ис точники)
учитываются
учитываются
<<BVISION>>
Концепция создания и развития продукта
<<BR>>
Бизнес требования
BRULE
учитываются
+brule
учитываются
<<CHAR>>
Унаследованные системы
учитываются
Бизнес правила
(from Ис точники)
(from Ис точники)
42

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

Типы требований
Требования
Техническое
видение (TVision)
<<CHAR>>
Унаследованные системы
(from Ис точники)
учитываются
<<TVISION>>
Концепция системы
учитываются
<<TECH>>
Результаты анализа технологий
(from Ис точники)
Разрабатывает
архитектор
учитываются
Компонентная модель
<<ASSUM>>
Ограничения, допущения
учитываются
<<STKR>>
Запросы ЗЛ
(from Ис точники)
(from Ис точники)
учитываются
учитываются
Модель развертывания
<<BR>>
Бизнес требования
BRULE
+brule
Бизнес правила
(from Ис точники)
43

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

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

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

Типы требований
Нефункциональные
требования
Требования к техническим
средствам
+hardware
Требования к программным
средствам
+software
Требования к окружению
Требования к
развертыванию системы
Требования к
производительности +performance
Требования к надежности
Требования к
масштабируемости
+deployment
+environment
+reliability
+scalability
<<NFR>>
Нефункциональные требования
NFRType : список значений
+security
Требования к лицензированию
Требования к совместимости
<<ICE>>
Требования к взаимодействию с
внешними системами
<<DOC>>
Требования к документации
<<DATA>>
Требования к данным
Требования к безопасности
Требования к эргономике
<<GUI>>
Требования к пользовательскому
интерфейсу
+ergonomics
+licensing
<<CERT>>
Требования к сертификации
+compatibility
+support
Требования к поддержке
45

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

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

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

Атрибуты требований
[FREQ] Functional Requirement
Статус
Фаза
Итерация
Приоритет
Подсистема
Причина
Ответственный
Необходимо проработать
[UC] Use Case
Статус
Фаза
Подсистема
Причина
Ответственный
Архитектурно-значимый
Детализация
[NFR] Non Functional Requirement
(from NFR)
Статус
Фаза
Приоритет
Причина
Ответственный
47

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

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

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

Трассировки требований
Представление трассировок в
виде дерева
Тип требования 1
Тип требования 2
Тип требования 3
49

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

Трассировки требований
Табличное представление трассировок
Тип требования 1
Тип требования 2
50

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

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

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

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

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

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

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

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

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

Данный файл был скопирован с сайта http://saway4ru.codeplex.ru. Пожалуйста, прочтите соглашение об
использовании.
Соглашение об использовании материала
Данный файл разрешается использовать, изменять без уведомления правообладателей, если он
используется по прямому его назначению.
При использовании файла в качестве примера, ссылочного материала ссылка на сайт* и авторов
материала являются обязательными.
По всем возникающим вопросам по использованию материалов сайта* обращайтесь к координатору
сайта**.
Примечания
*сайт – это ресурсы:
http://www.bestpractices.ru
http://www.bp4you.ru
http://saway4ru.codeplex.com/
http://saway.codeplex.com/
http://sadd4ru.codeplex.com/
http://sadd.codeplex.com/
**координатор сайта:
http://www.codeplex.com/site/users/contact/APererva?OriginalUrl=http%3a%2f%2fwww.codeplex.com
%2fsite%2fusers%2fview%2fAPererva
Для отправки сообщения требуется регистрация на сайте*.
55