Реверс-инжиниринг требований в проекте по миграции КИС. Алексей Смирнов
•Download as PPT, PDF•
2 likes•724 views
Recommended
Recommended
More Related Content
What's hot
What's hot (9)
Viewers also liked
Viewers also liked (20)
Similar to Реверс-инжиниринг требований в проекте по миграции КИС. Алексей Смирнов
Similar to Реверс-инжиниринг требований в проекте по миграции КИС. Алексей Смирнов (20)
More from Alexander Baikin
More from Alexander Baikin (20)
Реверс-инжиниринг требований в проекте по миграции КИС. Алексей Смирнов
- 1. Реинжиниринг требований в проекте по миграции корпоративной информационной системы Стоит ли аналитику бежать впереди паровоза? Горленко Роман, Жданова Виктория, Русакова Наталья, Сафиулин Олег, Сиксимов Александр, Смирнов Алексей, Столяров Дмитрий, Шахов Алексей
- 2. Миграционный проект Старая Новая система, система, TO BE AS IS (web, Java) (Power Builder) База данных 2
- 3. Работа аналитика в миграционном проекте Исходный код Спецификация 3
- 4. Проблемы Трудоемкий процесс анализа кода Доработки до новых версий старой системы Нет полного представления о системе Нет понимания бизнес-процессов Потеря специфических требований заказчика Неструктурированность массива требований Растущий объем кода новой системы 4
- 5. Решения Трудоемкий процесс анализа кода в модель Перенос связей между модулями Автоматическое сравнение версий Доработки до новых версий старой системы Нет полного представленияанализа старой системы Восстановление классов о системе Нет понимания бизнес-процессов Модель реализации бизнес-процессов в Системе Управление требованиями в модели Потеря специфических требований заказчика Неструктурированность массивавсей информация в модели Структурированное хранение требований Группировка Java-кода по компонентам с помощью модели Растущий объем кода новой системы 5
- 6. Инструмент для создания модели: SPARX Enterprise Architect 6
- 7. Анализ существующей системы и построение модели AS IS Исходная система постоянно дорабатывается. Заказчик хочет, чтобы и мы актуализировали уже сданный функционал. Как делать это эффективно? 7
- 8. От исходников к модели AS IS 8
- 9. Слова проходят, а нужные связи остаются 9
- 10. Модель Системы AS IS 10
- 11. Слова проходят, а нужные связи остаются 11
- 12. Модель Системы AS IS 12
- 13. Модель Системы AS IS 13
- 14. Модель Системы AS IS 14
- 15. Модель Системы AS IS Помогает в процессе анализа кода Упрощает оценку трудоемкости планируемых разработок Использование модели позволяет избегать повторного анализа Частично решает проблему поиска данных Дает понимание бизнеса заказчика и места в нем нашей системы 15
- 16. От Системы AS IS к Системе TO BE 16
- 17. TO BE, or not TO BE… 17
- 18. TO BE, or not TO BE… 18
- 19. ИТОГИ 19
- 20. Основные принципы Выделение взаимосвязанных моделей для структурирования информации по уровням ее детализации и потребителям Широкое применение пакетов для раскладывания элементов моделей и диаграмм Обобщающие диаграммы облегчают навигацию между пакетами Диаграммы отслеживания (traceability) визуализируют связи между элементами модели различных уровней (слоев) моделей На диаграмме должна быть только однородная информация, что позволяет не смешивать различные «срезы» данных 20
- 21. Что же все это дало проекту? Экономия времени в случае необходимости повторного анализа функций Системы AS IS, благодаря сохранению и последующему уточнению всей информации, полученной в ходе первичного анализа Облегчение коммуникации внутри команды (и потенциально с заказчиком), т.к. существует единое место хранения информации о Системе TO BE и доступны ее «срезы» с различным уровнем детализации Сформированный массив знаний позволил существенно снизить расходы на реализацию нового функционала, отсутствовавшего в Системе AS IS …и все это благодаря первоначальным усилиям аналитиков проекта! 21
- 22. Чем быстрее Вы начнете, тем больший эффект это принесет проекту Для построения модели безусловно потребуются дополнительные трудозатраты на ее проектирование, постановку процессов и обучение команды, но впоследствии использование собранной информации, благодаря ее понятности и доступности, принесет уменьшение непроизводительного расхода времени. Даже если проект заявляется как чисто миграционный, то все равно не следует «расслабляться». Рано или поздно с большой вероятностью может понадобится понимание Системы в целом и видение ее под различными углами. Не бывает «неважной» или «ненужной» информации – все данные, полученные в ходе анализа должны быть зафиксированы. Со временем часть информации может быть отфильтрована и/или заархивирована. 22
- 23. Чем быстрее Вы начнете, тем больший эффект это принесет проекту
- 25. Так, стоит ли «бежать впереди паровоза»?.. А как считаете ВЫ?
- 26. Летний All you need is … Аналитический Фестиваль г. Иваново 23-24 июня 2012 conf.uml2.ru
Editor's Notes
- Представление. Докладчики. Соавторы. Идея доклада в подзаголовке - Стоит ли бежать впереди паровоза? Как это сделать, чтобы паровоз не задавил. Про паровоз проект: Перенос функционала на новую платформу. Заказчик – крупная общероссийская компания. Мигрируемая система обеспечивает сопровождение контрактов, Автоматизарует жизненно важные процессы заказчика, к ней предъявляются требования по надежности. Система обменивается данными с другими системами заказчика (бух, учетные, статистика…)
- Суть нашего проекта. AS IS – написана силами заказчика, разрабатывается 15 лет, двухзвенка, РВ около 3 млн строк. Особенность – постоянные доработки в процессе эксплуатации. Проект – повторение функциональности старой системы. БД остается той же, используется совместно. В проекте участвуют несколько вендоров. Перевод функционала – порциями, в рамках этапа порция функций старой системы дается каждому вендору. Паровозик – наш проект по миграции.
- «Почти IDEF » диаграмма процесса работы аналитика в начале проекта. Аналитик получал функцию для анализа, лез в код, выдавал спецификацию с Use Cases , требованиями к интерфейсу и взаимодействию с БД. По спецификации реализовывалась система TO BE и проектировались Test Cases . Особенность работы аналитика: единственный источник требований – код системы, контактные лица заказчика – разработчики старой системы. Проект рассматривался как чистое портирование кода. Стейкхолдеры заказчика не осознавали сложность проекта. Отказаться от роли аналитика нельзя: автоматический перенос кода невозможен в связи с разницей в технологиях.
- Проблемы: 1 - Код старой системы запутан, с большим количеством связей, анализировать его крайне тяжело. Другой аналитик – работа заново. 2 - существующая система постоянно развивается, нам приходится постоянно «догонять» ее. Дефицит времени 3 - аналитики работают с конкретными функциями системы, существует риск получить неоптимальную архитектуру, возникают сложности с управлением всем проектом 4 - Для оценок доработок по бизнес-требованиям (а не смотря на заявленный чисто миграционный характер проекта такие требования появились) и и для организации тестирования End-To-End нужно понимание не только отдельных функций системы, но и в целом автоматизируемых бизнес-процессов. 5 - Не смотря на миграцию, новая система имеет ряд отличий от старой, обусловленные как различиями платформ, так и пожеланиями заказчика. Такие отличия всегда согласовывались с заказчиком и фактически имели статус требований. Из-за недостаточной структурированности такие требования иногда терялись 6 - Вся документация хранится в текстовом виде и объем её велик, при этом разная информация хранится в разных местах репозитория. Поиск требует больших трудозатрат. Требованиями, «похороненными» в текстовом документе, сложно управлять. 7 - Новая система росла, и в какой-то момент так разрослась, что возникли проблемы со сборкой и развертыванием системы из-за большого объема кода. Необходимо было решать вопрос группировки его по модулям для частичной загрузки в память кто-то из присутствующих в зале узнал тут и свой проект?
- Наша команда решила применить элементы модельно-ориентированного подхода к разработке, а точнее реверс-инжинирингу требований, , и нам удалось разобраться с нашими проблемами: 1 - Мы загрузили связи между модулями Power Builder старой системе. Т.о., аналитику, не знакомому с функционалом, стало легче разбираться с функционалом старой системы 2 - Благодаря наличию связей между модулями и функциями системы стало возможным быстрое получение информации о влиянии изменений на тот или иной функционал 3 - Мы стали восстанавливать и хранить в модели классы анализа старой системы AS IS . Теперь любой член команды мог быстро получить информацию о системе на любом уровне абстракции. 4 - Потребовалось понимание бизнес-процессов у заказчика 5 - В модель были добавлены требования, связанные с функциями и свойствами (фичами) старой и новой систем 6 - С моделью вся информация о системе хранится в одном месте. Артефакты модели содержат ссылки на текстовую документацию 7 - Модель позволила выполнить группировку пакетов новой системы и разбиение их по компонентам в соответствии с их функциональными связями
- Мы использовали Sparx ЕА. Его можно использовать в 3-х вариантах: 1 – локальный файл (Аксесс) – так было в начале 2 – то же, но в системе упр-я версиями ( SVN) 3 - модель в реляционной серверной СУБД. Размер проекта = > объем моделей AS IS = > выбрали вариант 3.
- Наша работа по созданию модели на самом деле началась с решения достаточно частного вопроса: -------- Миграция системы выполняется поэтапно, итерациями. После завершения первой итерации выяснилась неприятная особенность: исходная система постоянно дорабатывается, и заказчик хочет, чтобы после сдачи итерации мы отслеживали доработки старой системы и поддерживали актуальность сданной части новой системы. -------- Нам был нужен метод, чтобы делать это быстро и эффективно.
- Информации о том, что именно изменилось, нам не дают, только исходные коды новой системы. То есть этом единственным источником изменений требований по-прежнему остается код. Для начала нам нужно было получить модель зависимостей модулей исходной системы. Если бы старая система AS IS была написана на каком-то живом языке, например, на Java , у нас не возникло бы проблем: ЕА, как и многие другие средства моделирования, умеет «втягивать» в себя чужой код и преобразовывать его в модель. Для не очень распространенного Power Script такой вариант не проходил. Поэтому на Перле -------- (так исторически сложилось) был написан набор скриптов для анализа исходников системы AS IS и преобразования их в модель. C крипт работает напрямую с БД модели, минуя клиент ЕА
- В процессе выполнения скрипта: 1. Определяются новые модули, которых еще нет в модели, и добавляются в модель 2. Анализируются исходники всех модулей на предмет упоминания имен других модулей. На базе этого строятся зависимости: если в модуле А упоминается модуль Б, то А зависит от Б. -------- 3. В модель загружаются найденные новые зависимости и удаляются неактуальные. Кстати говоря, скрипт работает напрямую с БД модели, минуя ЕА (богатый опыт реинжениринга позволил нам восстановить и схему данных ЕА ). Таким образом мы получили уже какой-то вариант модели реализации нашей старой системы AS IS . Такая модель со связями уже облегчала анализ новой функциональности.
- Дальше нужно было определять, какие именно модули из списка изменившихся влияют на ту или иную функцию системы. В отдельном пакете были заведены все функции. Были сформированы зависимости пунктов меню (фич) от модулей, которые вызываются непосредственно из каждого пункта меню.
- Теперь, имея построенную модель реализации системы AS IS , мы используем другой скрипт на Перле, который получает на вход список изменившихся модулей (клик), проходит по графу зависимостей модулей друг от друга (прямо в базе ЕА) и выходит на пункты меню. -------- Таким образом мы получаем всю необходимую информацию для оценки трудоемкости доработок новой системы до актуальной версии: для каждой фичи – список изменившихся модулей и «дорожки» по графу зависимостей от фичи к модулю. -------- Затем было принято решение расширить модель еще и на хранимые процедуры и таблицы БД. Построение модели хранимых процедур тоже автоматическое с помощью скрипта, как и для Power Builder'а. Модель таблиц БД импортируется напрямую из базы мигрируемой системы.
- Таким образом, модель реализации системы AS IS у нас теперь включает как модули кода клиента на РВ, так и -------- Таблицы базы и хранимые процедуры. Из таблиц мы смогли восстанавливать классы анализа – и тоже заносить их в модель. -------- Это делается уже не автоматом, а с применением интеллектуального труда аналитика. Когда аналитик в процессе анализа системы выделяет новые сущности, которых нет в модели, он добавляет их в модель. В нашем случае мы восстанавливаем прежде всего классы сущности, т.к. идем от модели данных, т.е. от таблиц нашей системы AS IS . Управляющие и тем более граничные классы нам не так интересны, т.к. мы идем от реализации, и нас интересует концептуальная точка зрения. Переходя к классам анализа, мы имеем уже некоторую абстракцию предметной области – сущности, которые можно спроецировать на бизнес-понятия предметной области. Т.о. у нас есть уже две модели: модель реализации системы AS IS – она платформенно-зависимая, а вот модель анализа этой системы мы получили уже платформенно-независимую. Поскольку БД у нас общая для систем AS IS и нашей новой TO BE , то и классы анализа – сущности системы AS IS также являются классами анализа системы TO BE.
- Сущности предметной области мы добыли, и одна сторона предметной области начала нам проясняться. Теперь нам нужно понять, как эти сущности взаимодействуют между собой. Тогда мы разделили функции системы на те, которые участвуют в workflow по обработке контрактов и прочих сущностей, и прочие вспомогательные функции. Из первых функций мы выделили шаги бизнес-процессов в нашей системе AS IS -------- То есть каждая такая функция системы имеет под собой какой-то шаг большого бизнес-процесса (например, заполнение данных контрагента, проверка условий договора и т.д.) Шаги процессов в системе AS - IS также заносятся в отдельный пакет, шаг реализуется функцией системы
- С нашими моделями система заказчика AS IS стала нам гораздо ближе и понятнее. Но одной старой системой сыт не будешь, нам нужно понимать, что за бизнес стоит над ней. И, имея платформенно-независимую модель анализа, мы смогли перейти к такому пониманию. -------- Из классов анализа мы переходим к бизнес-сущностям заказчика, а от шагов процессов системы – к бизнес-процессам. -------- Процесс перехода к бизнес-модели более творческий, нежели разбор кода. Я бы покривил душой, сказав, что всю необходимую информацию мы получили из кода системы AS IS . Нам конечно пришлось изучать и нормативно-справочную документацию заказчика. Впрочем, наша система As IS тоже содержала много ценной информации о построении бизнес-процессов (там был даже своеобразный конструктор этих бизнес-процессов). В результате анализа нормативки заказчика мы смогли получили так же и бизнес-правила предметной области. -------- В результате мы получили не просто абстрактную модель уровня бизнеса, но модель, привязанную к системе AS IS . Выгода от этого проявилась, когда заказчик, не смотря на декларируемый миграционный характер проекта, начал посылать нам запросы на изменения прямо от бизнеса, сформулированные в бизнес-терминах.
- -------- Так мы построили модель старой системы AS IS , которая (дальше читать по пунктам).
- Итак, после окончания этапа 1 работы с Enterprise Architect мы получили Модель Системы AS IS , которая была интересна аналитикам и части тестировщиков, работа которых заключалась в сравнении поведения Систем AS IS и TO BE. Для остальных членов команды этого было маловато, поэтому основной задачей этапа 2 стало вовлечение в эту работу и представителей других проектных ролей. ------------------------------------------------------------------- Данная работа пошла в двух направлениях, в прямом смысле навстречу друг другу. С одной стороны – аналитики идут по классическому RUP сценарию работы от требований, Feature ( свойств Системы TO BE), модели вариантов использования к…
- … к их реализации в Дизайн-модели Системы TO BE
- С другой стороны - а рхитекторы проекта в Модель реализации стандартными средствами EA экспортировали Java-классы. --------------------------------------- А затем, с помощью модели им удалось “перепаковать” проект так, что он распался на самостоятельные функционально независимые части (компоненты), которые теперь можно было независимо компилировать, поставлять и деплоить.
- Таким образом, мы получаем три уровня моделей: Бизнес-модель (для бизнес-аналитиков) Уровень требований, который распадается на Модель Системы AS IS (она для нас прототип – основной источник требований) и, собственно, Модель требований к Системе TO BE ( на базе которой основана система управления требованиями). Для системных аналитиков. Уровень дизайна, архитектуры (для архитекторов) и реализации (для разработчиков). Дополнительно для целей развертывания и поддержки Модель реализации Системы TO BE может быть дополнена Моделью развертывания и Моделью окружения. Были предусмотрены Диаграммы для управления проектом и Модель тестирования (на рисунке не показаны). Таким образом, в итоге мы получили совокупность взаимосвязанных моделей, достаточно полно описывающих Систему TO BE и проанализированную Систему AS IS с точки зрения различных проектных ролей.
- В процессе работы над моделями мы придерживались принципов, перечисленных на этом слайде. Они только выглядят очевидными, но на самом деле требуют определенной «перестройки» сознания и подходов к работе. Давайте последовательно рассмотри каждый из них. ------------------------------------------------ Каждая проектная роль работает со своей моделью, со своим срезом информации. ------------------------------------------------- Позволило организовать многопользовательскую работу, т.к. пользователи работают в своих пакетах. И сами пакеты являются структурирующими элементами, т.к. несут информацию о структуре Системы. Открывая пакеты. Мы видим структуру фич, т.е. каталог работ. ------------------------------------------------- Обобщающие диаграммы облегчают «путешествия» по моделям сверху-вниз, от общего к частному, от бизнес-требований к их реализации. ------------------------------------------------- Диаграммы отслеживания позволяют понять как рассматриваемый элемент модели связан с элементами более высокого уровня, т.е. дают возможность «ходить по моделям снизу-вверх. ------------------------------------------------ Человеческий мозг не может в равной степени адекватно воспринимать более 5-7 объектов на одном рисунке, поэтому диаграмма не должна быть перегружена элементами различных типов. Хороший стиль, когда на одной диаграмме «встречаются» элементы двух соседних уровней моделей.
- Вопрос аудитории: как вы считаете, что все это дало проекту. -----------------------------------------------
- Уроки, которые мы извлекли в ходе работы над моделями.
- И тогда, когда Ваш проект превратиться из маленького милого хомячка в большого рычащего медведя – Вы будете готовы к этому!
- Уроки, которые мы извлекли в ходе работы над моделями.