На текущий момент я являюсь ведущим аналитиком продукта в новой предметной области (новой для меня и для компании, в которой я работаю). С чего аналитику начать изучение предметной области, да еще так, чтобы оставить какие-то полезные материалы для проекта?
Один из классических подходов – создание модели основных сущностей предметной области.
Перед нами встал вопрос, как удобнее и нагляднее описать логические связи основных сущностей системы.
Основываясь на прошлом опыте и исходя из таких факторов как сроки и объем проекта, было принято решение использовать ER-диаграмму. Данный подход позволил решить сразу несколько задач: и описать логическую модель основных сущностей (как некая альтернатива диаграмме классов UML), и подготовить основу для создания БД нашего продукта. Немаловажным фактором стал и выбор подходящего инструмента для моделирования.
В своем докладе хочу рассказать про плюсы и минусы такого подхода. Хочу поделиться про то, какими критериями пользовалась при выборе инструментария. А также хочу донести основную мысль, что достойную и полезную для разработчиков логическую ER-модель может сделать любой аналитик, хорошо изучивший предметную область. Не обязательно заканчивать курсы по Базам данным (хотя это будет только плюсом☺). Главное знать маленькие «хитрости» и понимать, для чего все это нужно.
Также вместе с вами попробуем нарисовать небольшую ER-модель, чтобы закрепить услышанное на практике.
Доклад будет интересен:
*начинающим аналитикам (понять, зачем и как можно описывать логическую модель проектируемой системы);
*опытным аналитикам (увидеть реальный опыт реальных проектов и подход к проектированию модели сущность-связь для эффективного обмена информацией с разработчиками).
