Опыт восстановления требований для существующих систем на основе IBM RUP

1. Опыт восстановления требований для существующих систем на основе IBM RUP

2. Содержание . Цели Использование RUP Восстановление требований Результаты Взаимодействие с разработчиками Восстановление архитектурного описания Стыковка функционального описания с низкоуровневым архитектурным описанием Выводы 2

3. Много кода, мало информации • Система работает хорошо, правда, непонятно как! • Изменились бизнес-условия – необходимо адаптировать систему • Как улучшить “черный ящик”? НАЛЕВО • Два пути: • Разработка новой системы • Модернизация существующей системы НАПРАВО 3

4. Достоинства и недостатки • Может быть намного более эффективным путь модернизации существующей системы. Но система должна быть документирована! А если документации нет, то необходимо обратное проектирование! 4

5. Цели обратного проектирования системы • Избежать разработки существующих, исправно функционирующих решений “с нуля” и подготовить систему для доработки • Смягчить проблемы человеческого фактора • Снизить трудоемкость сопровождения системы • Выявить требования и повысить качество тестирования системы • Основные вопросы • Какой результат хотим получить? • Как организовать получение результата? 5

6. Пример из реального проекта • Область: Банк с большой сетью филиалов • Система: банковская автоматизированная расчетная система • Технологии: “тонкий клиент”, J2EE, СУБД Oracle • Средства: IBM Rational Application Developer, Microsoft Word, IBM Websphere Application Server • Команда: 5 разработчиков • Объем системы: более 1000 классов Java (без учета вложенных) • Необходимо, чтобы сторонние консультанты провели обратное проектирование системы в течение 3 месяцев 6

7. C чего начинать?RUP поможет Уточнить границы системы Построить модели верхнего уровня абстрагирования • Обязательное условие: трассировка элементов описаний Построить модели архитектурного уровня 7

8. Уточнение границ системы • Итеративность – залог успеха • Чем больше и точнее знаем о системе, тем качественнее результат (модернизации) • “Цена-качество” в разумных пределах (можно часть восстановить, а часть переписать “с нуля”) Подготовить экономическое обоснование Сформировать концепцию Определить сценарии использования и актеров Менеджер проекта Аналитик Оценить риски Распланировать и назначить работы исполнителям 8

9. Результаты обратного проектирования • А что нам надо для успешного обратного проектирования системы в данном конкретном проекте? MDA - Model-DrivenArchitecture (OMG) 9

10. Результаты обратного проектирования MDA - Model-DrivenArchitecture (OMG) Модель сценариев использования Трассировка сценариев использования к их реализациям Модель реализации 10

11. Инструментарий • Был выбран инструментарий: • Для управления требованиями и отслеживания изменений в них - IBM Rational RequisitePro (т.к. в Банке внедрен IBM Rational ClearQuest, используются средства тестирования IBM Rational, документация ведется в Microsoft Word) • Для визуального моделирования – IBM Rational Software Architect (т.к. он интегрируется с IBM Rational Application Developer и IBM Rational RequisitePro) • Для генерации документов – IBM Rational SoDA (т.е. средство интегрируется с IBM Rational RequisitePro и IBM Rational Software Architect ) 11

12. Построение моделей верхнего уровня абстрагирования • Проблема – при недостатке документации сложно перейти от кода в верхнему уровню абстракции • Пользователи хорошо знают бизнес-контекст, но плохо внутренние аспекты взаимодействия системы! • Основные объектные абстракции системы можно получить из БД • Откуда получить сценарии использования? Детализировать сценарии использования Определить сценарии использования и актеров Менеджер проекта Оценить результаты итерации Выполнить анализ БД Аналитик 12

13. Где источник знаний о системе? • Источники знаний: • Разобщенные документы: • Положение о проведении межфилиальных расчетов в Банке (1док.) • Принципы организации документооборота, описывающий старую промышленную систему (1) • Документы с общими требованиями от Бизнеса (12 + 3 дополнения) • Разработчики: У Вас удачный день! Мне все известно про кредиты! Хорошо, я найду для Вас полчаса, чтобы поговорить об операционных днях, но только когда немного освобожусь! Мой конек – маршрутизация документов, но я сейчас в отпуске! А я вообще много знаю и делаю, а нормально объяснить не могу! 13

14. Типы требований и трассировки (CIM) STRQ • STRQ – входные требования (“заказчика”), 772 треб.(17 док.) • TERM – термины и сокращения глоссария, 179 треб. • REF – ссылки на внешние документы, 348 треб. • UC – сценарии использования, 677 треб. (32 док.) • PRD – руководство пользователя , 136 треб. • FEAT – функциональные требования, 1447 треб. • SUPL – дополнительные требования (безопасности, производительности, надежности и т.д.), 65 треб. • HELP – справочники, 43 треб. • CHK – проверки, 150 треб. • Всего трассировок - 4456 TERM REF UC PRD SUPL FEAT HELP CHK 14

15. Ближайшая цель - выявление требований? • Анализ документов • Интервью с разработчиками • Шаблон сценария использования: • Название • Описание • Шаги основного потока • Шаги альтернативных потоков • Специальные требования • Предусловия • Постусловия Модель сценариев использования Спецификация сценария использования Функциональные и дополнительные требования Диаграмма деятельности 15

16. Организация взаимодействия с разработчиками Консультант Разработчик Рук.разработчиков 3 дня 1 час Знакомство с документацией Презентация системы 1 час Формирование и уточнение основной диаграммы сценариев использования Согласование основной диаграммы сценариев использования 2 дня Замечания Есть 3 итерации 40 минут Нет Детализация очередного сценария использования Согласование очередного сценария использования 2-3 дня Замечания 2-3 итерации Есть Уточнение модели сценариев использования Нет 30 минут 16

17. Документ “Положение о проведении межфилиальных расчетов в Банке” • Простой документ Word без какой-либо строгой структуры 17

18. Пример документа с общими требованиями • Имеют строгую структуру, утвержденную в Банке и формат требований строго регламентирован • В каждом документе свои секции с терминами и ссылками 18

19. Проблема дублирования терминов и ссылок в документахс общими требованиями • Входные документы необходимо обработать и отслеживать изменения к ним, но менять сами документы нельзя! • Термины (TERM) и ссылки (REF) в документах могут дублироваться с измененными формулировками или одинаковые формулировки использованы для разных терминов. Необходима аналитическая обработка. • Решение: Легенда: Связи внутри документов Связи между документами TERM REF Документ №1 TERM TERM REF REF TERM REF Документ №2 Артефакты репозитория требований (RequisitePro) Глоссарий проекта Документ №3 19

20. Дополнения к общим требованиям • IBM Rational RequisitePro позволяет отслеживать изменения в требованиях и активизировать все связи от требований, в которые внесены изменения • Проблема: Все входные документы стабильны и не меняются. Изменения в требованиях приходят в дополнениях 20

21. Механизм атрибута “Состояние” • Был введен атрибут “Состояние” со значениями “Актуальное”, “Изменено”, “Удалено”. Стало возможным фильтровать действующие требования • При изменении требования: Состояние = “Актуальное” Артефакты репозитория требований (RequisitePro) Состояние = “Актуальное” Состояние = “Изменено” Обновление списка требований • При удалении требований механизм работает аналогично, только удаленные требования скрываются из списка 21

22. Иерархия требований

23. Трассировка объектов и сценариев использования системы • Отношение с объектами может быть более сложным: отдельные объекты могут соответствовать группам таблиц, полям или их группам полей. Актер 1 Актер 2 Актер 3 Сценарий использования 1 Сценарий использования 2 Сценарий использования 3 Объект 1 Объект 2 Объект 3 Таблица 1 Таблица 2 Таблица 3 • Могут быть сформированы дополнительные интерфейсные и управляющие объекты. 23

24. Построение моделей архитектурного уровня • Получение списка архитектурно значимых классов от разработчиков для построения диаграмм классов • Трассировка сценариев использования в коде и в реальном времени для построения диаграмм последовательностей Выполнить трассировку сценариев использования и ее анализ Выполнить статический анализ кода Менеджер проекта Построить модель реализации Выполнить мэпинг модели реализации на сценарии использования Оценить результаты итерации Архитектор 24

25. Диаграммы архитектурно-значимых классов • Строим диаграммы классов вокруг архитектурно значимых классов 25

26. Граф вызовов функций • Результат трассировки нескольких сценариев использования – граф вызовов методов и функций • Выполняем анализ кода в реальном времени и статический анализ кода Функция 1 Функция 5 Функция 9 Функция 2 Функция 6 Функция 10 Функция 3 Функция 7 Функция 11 Функция 4 Функция 8 Функция 12 • Результат трассировки кода в реальном времени • Результат статического анализа кода 26

27. Идентификация объектов • Идентифицируем управляющие и интерфейсные объекты для обнаруженных функций Функция 1 Функция 5 Функция 9 Объект У2: Класс C Объект У1: Класс C Функция 2 Функция 6 Функция 10 Функция 3 Функция 7 Функция 11 Функция 4 Функция 8 Функция 12 Объект И1: Класс A Объект И2: Класс B 27

28. Коммуникационные диаграммы • Строим наглядные коммуникационные диаграммы • Реальная архитектура может оказаться далекой от идеала Идеал: Реалии: Объект У1 Объект С1 Объект С2 Объект С3 Объект И1 Объект И2 28

29. Диаграммы последовательностей • Диаграммы последовательностей – другой формат представления вызовов функций с привязкой к объектам • Некоторые средства создают их автоматически по результатам трассировки в реальном времени Привязка к шагам сценариев использования 29

30. Анализируем компонентную структуру системы • Идентифицируем классы выявленных объектов 30

31. Стыковка архитектурного описания с функциональным • Обнаружим специфические для сценариев классы и общие классы • Результаты анализа кода позволяют итерационно уточнять модель сценариев использования 31

32. Модель реализации Код Сценарий использования функциональной модели Реализация сценария использования модели реализации Реализация сценариев использования • В реализациях сценариев использования объединяем описание низкоуровневом архитектурном уровне 82 архитектурно-значимых класса на 44 диаграммах (всего на диаграммах – 670 классов из 1026) 32

33. Репозиторий проекта Документы Автоматическая генерация документов IBM Rational SoDA • Требования к системе • Архитектура системы • Руководство пользователя • Репозиторий требований • Репозиторий моделей • Репозиторий тестирования • Репозиторий дефектов 33

34. Заметки или накопленная мудрость • Идеала не существует, но все мы стремимся к нему! (Частые итерации и обратная связь) • Использование визуального моделирования заметно ускорило процесс согласования функционального описания системы • Необходим профессиональный аналитик для сопровождения процесса управления требованиями • Многие не любят менять заведенный порядок, особенно если необходимо делать дополнительную работу в те же самые сроки! • Не существует решения для всех. Каждый раз это большая работа по адаптации к существующему бизнесу 34

35. Спасибо за внимание! СПАСИБО ЗА ВНИМАНИЕ! Ваши Вопросы? Дмитрий А. Лесин (495) 7107580 dlesin@aplana.comwww.aplana.ru

36. Сервер приложений (Websphere Application Server v6.0) СУБД (Oracle 9) Сервер процесса управления версиями и изменениями Базовая архитектура проекта Архитектор, разработчик, тестировщик, менеджер развертывания Разработчик, тестировщик, менеджер развертывания Разработчик, тестировщик, менеджер развертывания Разработчик, тестировщик, менеджер развертывания Менеджер проекта, аналитик NETWORK Внешний ресурс

37. локальные представления Репозиториймоделей Репозиториймоделей Репозиториймоделей Репозиториймоделей Репозиториймоделей Репозиторийтестир. (RFT) Репозиторийтестир. (RFT) Репозиторийтестир. (RFT) Репозиторийтестир. (RFT) Репозиторийтестир. (RFT) Репозиторийтестир. (RTM) Репозиториймоделей Репозиторийтребований Репозиторий дефектов Репозиторийтестир. (RFT) Сервер упр. версиями, конфиг. и изменениями (ClearQuest + ClearCase) Сервер приложений WAS v6.0 Сервер СУБД (Oracle 9) Сервер тестирования Сервер процесса управления требованиями Реализованная архитектура Архитектор, разработчик, тестировщик, менеджер развертывания Разработчик, тестировщик, менеджер развертывания Разработчик, тестировщик, менеджер развертывания Разработчик, тестировщик, менеджер развертывания Менеджер проекта, аналитик NETWORK Внешний ресурс