Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Улучшение процесса разработки ПО для IT компании

310 views

Published on

Доклад Николая Киреева на Analyst Days-7. 13-14 октября 2017. Минск
www.analystdays.com

Published in: Education
  • Be the first to comment

  • Be the first to like this

Улучшение процесса разработки ПО для IT компании

  1. 1. Практикум UML Моделирование функциональности бизнеса и ПО на основе модифицированной структуры уровней требований Николай Киреев info@webmax.by Студия информационных технологий WebMax.BY
  2. 2. Уровни требований К. Вигерса Уровни требований [К. Вигерс «Разработка требований к ПО», 2004, с.8, рис. 1-1]
  3. 3. О чём «молчат» уровни К. Вигерса • Не поддерживают чёткого разделения Бизнес - Система • Не предусматривает моделирования функциональности бизнес- субъектов, не являющихся пользователями программной системы • Предусматривает моделирование функций программной системы только на уровне пользовательских требований • Не вводит иерархии функциональных требований, исключая таким образом их детализацию.
  4. 4. Фреймворк Дж. Захмана Люди/организации достигают поставленных целей, исполняя возложенные на них функциональные обязанности, в определённом месте, в определённое время и оперируя конкретными данными Почему? Кто? Что? Когда? Где? Как?
  5. 5. Контекст – Бизнес – Система
  6. 6. Модифицированные уровни функциональных требований и их моделирование Что даёт модификация уровней: 1. Чёткое разделение моделей бизнеса и системы. 2. Делает возможным представлять субъекты-участники бизнес- процесса, не являющиеся пользователями системы. 3. Возможность более детального представления функций программной системы. 4. Отделяет функции бизнес-логики от GUI
  7. 7. Представление функционала. Как? Если говорим о ФУНКЦИЯХ, подразумеваем СУБЪЕКТОВ, говорим о СУБЪЕТАХ, имеем ввиду их ФУНКЦИИ Уровень Контекста (Отрасль) Внешние по отношению к бизнес-системе субъекты (должностные лица) достигают общие цели (цели отрасли), исполняя свои функциональные (должностные) обязанности, результатом которых станут законы, правила и ограничения для бизнеса. Их необходимо учитывать при разработке архитектуры бизнеса. Уровень Бизнеса (Предприятие) Участники бизнеса (должностные лица и/или штатные единицы, в UML это Business Actors) достигают поставленных целей (Business Goals), исполняя возложенные на них функциональные обязанности (в UML-моделях это Business Use Cases). Уровень Системы Пользователи программной системы (Actors) достигают целей (Software Goals), инициируя функциональные сервисы системы (User Requirement, в UML-моделях это базовые Use Cases). Законы, стандарты, нормы правила, ограни- чения Бизнес Система
  8. 8. Структура представления Use Case View (шаблон RUP) Business Use Case Model Use Case Model Модели Бизнеса Модели Системы
  9. 9. Business Use Case Model (уровень Бизнеса)
  10. 10. Структура Use Case Model (уровень Системы) Общая UC-модель системы Модели общей функциональности для групп пользователей Детальная модель функционала инициируемого отдельным актёром Раздельно для физ.лиц и системБазовые сервисы, актёры и границы системы Только для актёров физ.лиц
  11. 11. Пример. Общая Use Case диаграмма Диаграмма прецедентов [Д. Арлоу, А. Нейштадт «UML-2 и унифицированный процесс», 2007, с.98, рис. 4.6]
  12. 12. Пример. Общая Use Case диаграмма
  13. 13. Пример. Общая Use Case диаграмма
  14. 14. Пример. Модель общих (для группы) функций
  15. 15. Пример. Модель общих (для группы) функций
  16. 16. Пример. Детализация функций актёров- физ.лиц
  17. 17. Пример. Детализация функций актёров- физ.лиц
  18. 18. Принцип MDA или разработка моделированием Модель MDA [Арлоу Д., Нейштадт И. „UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование“, 2е издание, 2007, с.28]
  19. 19. Заключение. Что дают модифицированные уровни? ЧТО ДАЮТ МОДИФИЦИРОВАННЫЕ УРОВНИ ТРЕБОВАНИЙ? • ЧЁТКОЕ РАЗДЕЛЕНИЕ МОДЕЛЕЙ БИЗНЕСА И СИСТЕМЫ • ПОНЯТНУЮ ИЕРАРХИЮ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ • ВОЗМОЖНОСТЬ КАК ОБЩЕГО ПРЕДСТАВЛЕНИЯ ФУНКЦИНАЛЬНОСТИ СИСТЕМЫ, ТАК ЕЁ ДЕТАЛИЗАЦИИ ДО УРОВНЯ ФУНКЦИЙ БИЗНЕС-ЛОГИКИ • ВОЗМОЖНОСТЬ СОЗДАВАТЬ БОЛЕЕ «ЧИТАБЕЛЬНЫЕ» USE-CASE ДИАГРАММЫ
  20. 20. Спасибо за внимание! Николай Киреев info@webmax.by www.webmax.by

×