Разработка информационной системы: концептуальная и логическая модели

Проектирование информационной системы часто буксует на стыке «как устроено сейчас» и «как должно работать после внедрения». В реальных условиях одна и та же функциональность может быть описана по-разному – от схем процессов до набора требований и ограничений. Из-за этого сложно согласовать ожидания заказчика, договориться о составе данных и выбрать решения, которые поддерживают целевое поведение системы. Поэтому курсовая работа фокусируется на разработке концептуальной и логической моделей как на способе снять неоднозначность и связать бизнес-уровень с проектными артефактами.

Цель работы – выстроить непротиворечивую модель информационной системы от описания предметной области до логической архитектуры и данных. Для достижения этой цели выполняется систематизация методологий проектирования и выбор подходящих CASE-средств; проводится анализ текущих бизнес-процессов в нотации AS-IS с выявлением узких мест; формируется целевое состояние TO-BE и формулируются требования к системе с опорой на модель FURPS+; сравниваются релевантные ИТ-решения для уточнения постановки задач разработки; разрабатывается техническое задание по ГОСТ 34.602-2020. На логическом уровне моделируются сценарии и структура системы через UML, проектируются информационные потоки и логическая модель данных с использованием DFD и ER-диаграмм в IDEF1X, а также фиксируются механизмы защиты, требования к техническому обеспечению и пользовательские регламенты.

Объект исследования – процесс проектирования информационной системы как последовательность переходов от бизнес-описаний к архитектурным и логическим моделям. Предмет исследования – способы представления и согласования требований, поведения и данных: отношения между бизнес-процессами AS-IS/TO-BE, логическими сценариями UML и информационными потоками, а также структура данных в нотации IDEF1X и связанная с ней спецификация требований безопасности и взаимодействия пользователя.

Чтобы связать модели разных уровней, применяются методы, которые «работают» именно на согласование артефактов. Методология проектирования и сравнительный анализ IDEF0, DFD, BPMN и UML нужны для обоснованного выбора нотаций под конкретные задачи моделирования; анализ предметной области и декомпозиция процессов в AS-IS помогают выявить узкие места и причины несогласованности; моделирование TO-BE и формирование требований по FURPS+ используются для перехода от наблюдений к формальным ограничениям системы. При построении логической архитектуры логика поведения фиксируется UML-диаграммами Use Case, Class и Sequence, что делает сценарии проверяемыми и привязывает их к структуре классов. Проектирование информационных потоков через DFD и логической модели данных через ER-диаграмму в IDEF1X позволяет представить обработку информации без потери смысла при переходе на уровень данных. Наконец, разработка регламентов пользователя и требований к защите опирается на анализ того, какие риски и точки взаимодействия возникают при внедрении системы.

Сначала работа закрепляет методическую рамку проектирования: исследователь сравнивает IDEF0, DFD, BPMN и UML как средства описания процессов, потоков и поведения, а затем связывает их с выбранными CASE-инструментами. Такой выбор нужен не «для полноты», а чтобы каждая модель отвечала своей задаче – от описания функций до фиксации сценариев и структуры данных. Параллельно формируется основа для будущих требований: предметная область описывается через текущие бизнес-процессы AS-IS, их декомпозиция выявляет узкие места и места, где информация теряется или передаётся с задержкой.

Далее конструируется целевое состояние TO-BE, в котором отражаются изменения в организации процессов после внедрения системы. На этом этапе требования к системе оформляются по FURPS+, что помогает разделить функциональные ожидания и нефункциональные ограничения: от качества работы и удобства взаимодействия до требований к безопасности. Параллельное сопоставление готовых ИТ-решений и релевантных подходов служит опорой для постановки задач разработки, чтобы выбранные проектные решения не противоречили реальной практике и не требовали избыточных допущений.

Следующим шагом становится формализация результатов в виде технического задания по ГОСТ 34.602-2020. В документе увязываются назначение системы, состав функций, требования к данным и интерфейсам, а также условия разработки и безопасности. Такая связка важна, потому что концептуальная картина поведения системы должна переходить в конкретные требования, которые проверяются на уровне логической модели.

На уровне логики система описывается через UML: сценарии Use Case фиксируют роли и варианты использования, диаграмма Class задаёт структуру данных и сущностей, а Sequence-диаграммы показывают взаимодействие объектов во времени. Информационные потоки уточняются с помощью DFD, а логическая модель данных строится в нотации IDEF1X через ER-диаграмму с сущностями, атрибутами и связями. На завершающем этапе логической проработки формируются механизмы защиты, требования к техническому обеспечению и пользовательские регламенты, включая руководство пользователя, чтобы модель поведения и данных была готова к внедрению и эксплуатации.