Доклад Натальи Леоновой на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com

1. Как мы специфицировали проект сКак мы специфицировали проект с
помощьюпомощью UMLUML
Наталья ЛеоноваНаталья Леонова
Т-Системс РУСТ-Системс РУС,, Санкт-Петербург, РоссияСанкт-Петербург, Россия

2. О себе:
• Страший бизнес-аналитик в компании Т-Системс Рус
• Работаю в проекте, находящемся в подразделении
Deutsche Telekom
• Человек, возлюбивший моделирование
• https://ru.linkedin.com/in/leonovanatalia
https://www.facebook.com/natasha.leonova.357

3. Введение
• Почему моделирование
• Инструментарий
• Личный опыт - проект, который «вылечился
моделированием»
• Специфика мультилингвальных проектов

4. Личный опыт
• Новый проект – пример многоязычной команды
• Существует с 2014 года
• Разработан командой в Санкт-Петербурге
• Часть команды - в Германии

5. Что было в самом начале
Модель на стадии создания или привет от
разработчиков

6. Почему именно моделирование
• Новая возможность документирования
• Упрощение задач разработки и анализа
• Наглядность
• Новое знание для аналитиков

7. Как ощущает себя аналитик
Иногда аналитик выглядит примерно так...

8. Новое решение – зачем?
• Потребность облегчить задачу разработке
• Улучшить процесс документирования
• Возможность опробовать новый инструментарий
• Уменьшить проблемы коммуникации

9. ALARM!
И ВОТ МЫ ОПИСЫВАЕМ ПРОЕКТ,И ВОТ МЫ ОПИСЫВАЕМ ПРОЕКТ,
КОТОРЫЙ ДО ЭТОГО ТРОГАЛИ ИКОТОРЫЙ ДО ЭТОГО ТРОГАЛИ И
ДОКУМЕНТИРОВАЛИ ТОЛЬКОДОКУМЕНТИРОВАЛИ ТОЛЬКО
РАЗРАБОТЧИКИРАЗРАБОТЧИКИ

10. К вопросу коммуникации
Многоязычный проект – это 3 иностранных языка, 3Многоязычный проект – это 3 иностранных языка, 3
разные культуры и 3 вида коммуникативных неудач…разные культуры и 3 вида коммуникативных неудач…

11. Как это было (с)

12. Суровая реальность
ЗАКАЗЧИКЗАКАЗЧИК РАЗРАБОТЧИКРАЗРАБОТЧИК АНАЛИТИКАНАЛИТИК

13. Что хотелось сделать лучше
• Упростить создание документации
• Сделать её понятной для всех членов команды
• Визуализировать изменения

14. И немного конкретики...
• Использовали инструментарий Enterprise Architect
• Модели удобнее для всех участникам проекта
• Есть контроль версий и история изменений

15. Что было сделано
• Описали веб-сервисы с помощью моделей
• Добавили комментарии
• Из модели можно генерить документацию

16. Об особенностях
• Модели EA начали использовать не сразу
• Основные используемые диаграммы – диаграммы
классов и use case диаграммы
• Описания и комментарии – на английском языке

17. Как это выглядит

18. Из модели в документ

19. О плюсах
• Модель могут редактировать как аналитики, так и
разработчики
• Модель понятна заказчикам и коллегам с немецкой
стороны
• Структура удобнее для всех
• Баги на документацию исправляются быстрее

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

21. На заметку аналитику
UML – полезное знание для аналитика
Кроме Enterprise Architect существует множество
различных тулов для моделирования и «рисования»
Визуализируй требования! Визуализируй их
полностью!

22. Что почитать
Cертификация - OMG-Certified UML Professional (OCUP)
Foundation – Intermediate – Advanced
Что почитать:
http://www.omg.org/cgi-bin/doc?ad/97-08-11
Х. Гома “UML-проектирование систем реального
времени параллельных и распределенных
приложений”

23. Немного выводов
Модели как универсальный вид документации
Устранение непониманий с заказчиком и немецкой
частью проекта
Быстрое реагирование на проблемы

24. И еще немного выводов
Возможность генерировать артефакты для разработки
Удобство инструментария – очень важная штука
Альтернатива обычным способам документации

25. Вопросы?
Если у Вас есть вопросы или Вы
хотите порисовать диаграммы...

26. Спасибо за внимание!
https://ru.linkedin.com/in/leonovanatalia
https://www.facebook.com/natasha.leonova.357