Системный анализ ИС и бизнес системы - связь, сходства и различия

1. ЛАФ-2013 Системный анализ ИС и бизнес системы - связь, сходства и различия Михаил Кумсков Учебный Центр Люксофт От Бизнес-систем - к информационным системам: переход шаг за шагом

2. ЛАФ-2013 • Системный подход в работе Интернет-аналитика • Техника определения требований к бизнесу • Техника определения требований к ИС • Техника определения требований к бизнесу • Сценарий использования / История пользователя План

3. Аналитики пишут требования к сайту Заказчика

4. ЛАФ-2013 «Что есть система?» - определить «систему координат» Троица: "Система. Окружение системы. Услуги системы» • Сценарии предоставления услуг – поведение системы • Основа для верификации (тестирования) Дизайн системы – реализация процессов «внутренними исполнителями» Системный подход

5. ЛАФ-2013 «Что есть система?» - определить «систему координат» анализа Система. Определить границы системы (что «внутри» а что «вне») Окружение системы. • Актеры – «кто» и «что» взаимодействует с Системой. • Первичныеактеры – пользователи. Вторичные – другие системы. Услуги системы • Услуга обслуживания пользователя – сценарии использования (Use Case) Системный подход

6. ЛАФ-2013 1. Система – определяем границы • – «что внутри», а что «снаружи» 2. Окружение системы– актеры – первичные и вторичные • первичные – пользователи • вторичные – другие системы • Услуги системы– для каждого первичного актера Услуга = Сценарии взаимодействия (основа верификации) Ищем требования – 3 шага

7. ЛАФ-2013 Упражнение Применяем 3 шага: • Система – ИС - границы определены • Ищем: Окружение системы – экторы • Ищем: Услуги системы – • для каждого первичного эктора Техника определения требований

8. ЛАФ-2013 UML диаграмма сценариев использования

9. ЛАФ-2013 • УСЛУГА СИСТЕМЫ – ФОРМА ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ • Метафора: «Услуга – ожерелье» • бусинки – шаги услуги – функции Системы • Понятны заказчику • Понятны разработчику • Понятны тестировщику • Понятны «тех.писателю» УСЛУГА Системы

10. ЛАФ-2013 • Используется в качестве основы для контракта с Заказчиком • Обеспечивает участие заказчиков в процессе разработки с самого начала • Обеспечивает понимание и фиксацию функциональных требований к системе УСЛУГА – ФОРМА ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

11. ЛАФ-2013 • Бизнес (система) – черный ящик! • Формулировка проблемы • Упражнение • Применяем 3 шага: • Система – бизнес система - границы определены • Окружение системы – экторы • Услуги системы – для каждого первичного эктора ТЕХНИКА ОПРЕДЕЛЕНИЯ ТРЕБОВАНИЙК БИЗНЕСУ

12. ЛАФ-2013 • Бизнес (система) – черный ящик! (Колледж – наша бизнес система) • Бизнес услуги = бизнес процессы (БП) • Автоматизируемая работа БП = услуга ИС • Ее исполнитель = пользователь ИС = первичный эктор ИС • Упражнение ОТ ТРЕБОВАНИЙ К БИЗНЕСУ – к ИС

13. ЛАФ-2013 Основной поток. Альтернативные потоки ТЕХНИКА СПЕЦИФИКАЦИИ СЦЕНАРИЯ ИСПОЛЬЗОВАНИЯ

14. ЛАФ-2013 ТЕХНИКА СПЕЦИФИКАЦИИ СЦЕНАРИЯ ИСПОЛЬЗОВАНИЯ

15. ТЕХНИКА СПЕЦИФИКАЦИИ СЦЕНАРИЯ ИСПОЛЬЗОВАНИЯ

16. Детализация шагов «Бизнес-услуги» (процесса) – критерий • Пример • Визуализация на UML – каждый поток – на своей отдельной диаграмме ЭВРИСТИКИ ПРИ ИЗОБРАЖЕНИИ СЛОЖНЫХ БИЗНЕС ПРОЦЕССОВ

17. Открываем черный ящик: • Определяем исполнителей – (список) • Для ИС – подсистемы и классы • Для Бизнеса – сотрудники и ИС • Назначаем“шаги-бусинки” – на исполнителей • Паттерн: “boudary”, “control”, “entity” Проектирование системы

18. Сценарий использования / История пользователя Agile / RUP

19. Agile / RUP Хорошие сценарии использования • Должны: • Приносить значимый результат • Содержать все вариации • Описывать взаимодействие и механизмы, но не политики • Не быть зависимыми от технологий и интерфейсов • Быть достаточно крупными • Инициироваться только одним актером • Включать основные бизнес-исключения и их обработку Ирина Крючкова, Киев, Октябрь 2011

20. Agile / RUP Модель сценариев использования • Имеет четыре компонента: • Границы системы • Актеры • Сценарии использования • Отношения • Представляет собой не только диаграмму! Ирина Крючкова, Киев, Октябрь 2011

21. Agile / RUP • Истории пользователей – • короткое описание функциональности, которая нужна пользователям для достижения их бизнес-целей. • Конкретные нужды конкретного пользователя, выраженные в простой форме. • Одно или два предложения с указанием: • Актера – кто будет использовать историю • Описания истории – высокоуровневый обзор функциональности • Выгоды – бизнес-ценность результатов работы истории Ирина Крючкова, Киев, Октябрь 2011

22. Agile / RUP Шаблон истории пользователя Как <тип пользователя> я хочу <сделать> и тем самым получить <выгоды> Ирина Крючкова, Киев, Октябрь 2011

23. Agile / RUP • Сравнение: Уровень детализации Ирина Крючкова, Киев, Октябрь 2011

24. Agile / RUP • Сравнение: Компетентность и доверие Ирина Крючкова, Киев, Октябрь 2011

25. Планируем – в сценариях использования Либо САМ работаешь – либо другие, НО по твоему ПЛАНУ

26. < Подводим Итоги Знание основ Системного Анализа – подмога в БОЮ за создание «правильного» приложения

27. СИСТЕМА – сначала ВНЕШНЕЕ поведение, а потом – ВНУТРЕННЕЕ проектирование • «История пользователя» – это ЭКЗЕМПЛЯР сценария использования (экземпляр услуги СИСТЕМЫ) «Как наверху - так и внизу»

28. Вопросы?

29. Радость была? Докладчик: Михаил Кумсков E-mail:kumskov@mail.ru mkumskov@luxoft.com СПАСИБО ЗА ВНИМАНИЕ! Skype:kumskov