Проектирование информационных систем: Комплексный подход к разработке курсовой работы, учитывающий современные методологии, тренды и критерии эффективности

В условиях стремительной цифровизации всех сфер жизни и бизнеса, проектирование информационных систем (ИС) приобретает не просто актуальность, но и статус критически важного компонента успешного развития любой организации. Современные компании, от малого бизнеса до глобальных корпораций, зависят от эффективности и надежности своих информационных систем, которые служат основой для принятия решений, автоматизации процессов и взаимодействия с клиентами. По данным исследований, глобальный рынок реляционных баз данных, являющихся фундаментом большинства ИС, в 2023 году оценивался в 62,76 млрд долларов США, с прогнозом роста до 146,64 млрд долларов США к 2031 году, что наглядно демонстрирует масштаб и динамику развития этой отрасли.

Настоящая курсовая работа нацелена на формирование подробного плана-структуры, который послужит студентам технических и экономических вузов, специализирующимся в области информационных технологий, системного анализа, программной инженерии или прикладной информатики, надежным фундаментом для углубленного исследования и написания академического текста по проектированию информационных систем. Цель работы — дать всестороннее представление об основных этапах, методологиях и современных трендах в проектировании ИС, а также акцентировать внимание на вопросах безопасности, масштабируемости и интеграции, которые зачастую недооцениваются, хотя именно они определяют долгосрочную жизнеспособность и конкурентоспособность решения.

В рамках этой работы мы ответим на ключевые исследовательские вопросы:

• Каковы основные этапы и методологии проектирования информационных систем в современных условиях?
• Как осуществляется сбор, анализ и документирование функциональных и нефункциональных требований к информационной системе?
• Какие модели и нотации (например, UML, DFD) используются для проектирования архитектуры и компонентов информационной системы?
• Каковы подходы к проектированию пользовательского интерфейса и базы данных для обеспечения эффективности и удобства использования ИС?
• Какие существуют методы оценки эффективности и качества спроектированных информационных систем?
• Какие современные тренды (например, облачные технологии, микросервисы, ИИ) влияют на процесс проектирования информационных систем?
• Как учитывать вопросы безопасности, масштабируемости и интеграции при проектировании информационных систем для конкретных бизнес-процессов?

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

Глава 1. Теоретические основы проектирования информационных систем

1.1. Понятие и сущность информационных систем

В современном мире, пронизанном цифровыми технологиями, трудно переоценить роль информационных систем. Что же представляет собой информационная система? По своей сути, информационная система (ИС) — это организованная совокупность технических средств, программного обеспечения, персонала, методов и процедур, предназначенная для сбора, хранения, обработки, поиска и выдачи информации, необходимой для достижения определенных целей управления или выполнения бизнес-процессов. Иными словами, это сложный механизм, который позволяет преобразовывать данные в знания, поддерживающие принятие решений.

Центральным звеном в создании такой системы является проектирование ИС. Этот процесс — не просто техническая задача, а комплексная деятельность, охватывающая создание схемы базы данных и определение необходимых ограничений целостности для различных моделей данных (реляционных, хранилищ данных, NoSQL), а также разработку общей архитектуры и функциональности системы. Проектирование — это мост между абстрактной идеей и её конкретной реализацией, где каждая деталь имеет значение, поскольку от неё зависит успешность всего предприятия.

Жизненный цикл ИС — это последовательность этапов, через которые проходит информационная система от момента своего зарождения до вывода из эксплуатации. Классический жизненный цикл включает в себя:

1. Анализ требований: Определение того, что система должна делать.
2. Проектирование: Разработка архитектуры, баз данных, пользовательского интерфейса и других компонентов.
3. Реализация (кодирование): Создание программного кода.
4. Тестирование: Проверка соответствия системы требованиям.
5. Внедрение: Установка системы в рабочую среду.
6. Эксплуатация и сопровождение: Поддержка работоспособности, внесение изменений и улучшений.

Каждый этап является критически важным, и ошибки, допущенные на ранних стадиях, могут привести к значительным затратам и проблемам в будущем, вплоть до полного краха проекта, поэтому их тщательная проработка необходима.

Классификация информационных систем многообразна и позволяет лучше понять их сущность и назначение:

Критерий классификации	Типы информационных систем	Описание
По назначению	Управляющие ИС	Предназначены для автоматизации функций управления предприятием, например, ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), SCM (Supply Chain Management).
	Информационно-справочные ИС	Предоставляют доступ к большим объемам структурированной информации, например, электронные библиотеки, базы знаний.
	ИС обработки данных	Ориентированы на выполнение рутинных операций с большим объемом данных, например, бухгалтерские системы, системы начисления заработной платы.
	Экспертные системы	ИС, использующие знания экспертов для решения задач в определенной предметной области, например, медицинские диагностические системы.
По масштабу	Персональные ИС	Используются одним пользователем для личных или профессиональных задач (например, личные органайзеры).
	Групповые ИС	Ориентированы на работу небольшой группы пользователей или отдела (например, системы документооборота отдела).
	Корпоративные ИС	Обслуживают потребности всей организации или крупного предприятия (например, ERP-системы).
	Глобальные ИС	Распределенные системы, охватывающие множество организаций или пользователей по всему миру (например, интернет-банкинг, международные платежные системы).
По архитектуре	Централизованные ИС	Все компоненты (данные, логика, интерфейс) расположены на одном сервере.
	Распределенные ИС	Компоненты системы распределены между несколькими серверами или узлами сети, например, клиент-серверные, многозвенные архитектуры, микросервисные.
	Облачные ИС	Системы, развернутые и работающие на облачных платформах (IaaS, PaaS, SaaS), предоставляющие высокую гибкость и масштабируемость.

Такая классификация помогает не только ориентироваться в многообразии существующих систем, но и обоснованно выбирать архитектурные решения на этапе проектирования, исходя из конкретных задач и требований к ИС, что является фундаментом для успешной реализации проекта.

1.2. Основные концепции и принципы проектирования ИС

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

Одной из центральных концепций является системный подход, который рассматривает ИС как единое целое, состоящее из взаимосвязанных и взаимодействующих элементов. Это означает, что при проектировании нельзя фокусироваться только на одной части системы, игнорируя её влияние на другие компоненты и на систему в целом. Например, оптимизация базы данных может быть бесполезной, если пользовательский интерфейс сложен и неудобен; ведь в итоге это приведёт к снижению общей производительности и удовлетворённости пользователей.

Ключевые принципы проектирования ИС включают:

• Принцип целостности: Все компоненты системы должны быть согласованы и работать как единый организм, обеспечивая непротиворечивость данных и логики.
• Принцип модульности: Система должна быть разбита на независимые, легко заменяемые и тестируемые модули. Это упрощает разработку, отладку и сопровождение.
• Принцип иерархичности: Организация компонентов системы в иерархическую структуру, от общего к частному, что позволяет управлять сложностью.
• Принцип абстрагирования: Фокусировка на существенных деталях и игнорирование несущественных на определенном уровне рассмотрения. Это позволяет проектировщикам работать с различными уровнями детализации.
• Принцип стандартизации: Использование общепринятых стандартов, нотаций и методов, что обеспечивает совместимость, повторное использование и облегчает взаимодействие между разработчиками.
• Принцип адаптивности (гибкости): Способность системы к изменению и адаптации к новым требованиям без существенных переделок.
• Принцип безопасности: Включение механизмов защиты данных и доступа на всех этапах проектирования.

Роль системного анализа в проектировании ИС является центральной. Системный анализ — это методология, направленная на изучение сложных систем, выявление их структуры, функций, связей и поведения для достижения определенных целей. В контексте проектирования ИС системный анализ выполняет несколько ключевых функций:

• Определение границ системы: Четкое обозначение того, что входит в систему, а что остаётся за её пределами.
• Формулирование целей и задач: Уточнение того, что система должна достигать и какие проблемы решать.
• Выявление требований: Сбор и систематизация функциональных и нефункциональных требований от всех заинтересованных сторон.
• Моделирование: Создание различных моделей (функциональных, структурных, поведенческих) для визуализации и анализа системы.
• Оценка альтернатив: Анализ различных вариантов проектирования и выбор наиболее оптимального с точки зрения затрат, рисков и эффективности.
• Управление сложностью: Разбиение большой и сложной задачи на более мелкие, управляемые части.

Без глубокого системного анализа проектирование ИС рискует стать хаотичным процессом, который приведет к созданию неэффективной, дорогой в обслуживании и не удовлетворяющей потребностям пользователей системы. Таким образом, системный анализ выступает в роли своего рода компаса, указывающего путь к успешной реализации проекта, что в конечном итоге экономит ресурсы и время разработчиков.

1.3. Критерии качества и эффективности информационных систем

Когда речь заходит о проектировании информационных систем, недостаточно просто создать функциональный продукт. Ключевое значение приобретают его качество и эффективность, которые определяют успешность внедрения и дальнейшей эксплуатации. Эти показатели не являются абстрактными; они могут и должны быть измерены, чтобы убедиться, что система действительно служит своим целям.

Основные критерии качества и эффективности ИС включают:

1. Надежность: Способность системы выполнять свои функции без сбоев в течение заданного периода времени и в определенных условиях. Количественно может быть оценена как среднее время между отказами (MTBF) или доступность (процент времени, в течение которого система работоспособна).
2. Производительность: Способность системы выполнять операции в определенный временной интервал. Измеряется через время отклика, пропускную способность (количество транзакций в секунду) или загрузку ресурсов.
3. Удобство использования (Usability): Легкость, с которой пользователи могут взаимодействовать с системой для выполнения своих задач. Оценивается через время обучения, количество ошибок, субъективную удовлетворенность пользователей.
4. Безопасность: Способность системы защищать информацию от несанкционированного доступа, изменения или уничтожения. Измеряется количеством инцидентов безопасности, временем на обнаружение и устранение уязвимостей.
5. Масштабируемость: Способность информационной системы адаптироваться к резкому изменению показателей задач и повышению требований, например, увеличению объемов данных или числа пользователей, без структурных изменений и с наращиваемостью производительности. Количественно масштабируемость может быть оценена как отношение прироста производительности системы к приросту используемых ресурсов; чем ближе это отношение к единице, тем лучше. Например, если при двукратном увеличении аппаратных ресурсов производительность возросла в 1,8 раза, то коэффициент масштабируемости составит 0,9.
6. Интеграция: Способность различных компьютерных систем или программ «общаться» между собой и обмениваться информацией для создания единого информационного поля. Оценивается сложностью и стоимостью подключения новых систем, а также степенью автоматизации обмена данными.
7. Сопровождаемость: Легкость внесения изменений, исправлений и улучшений в систему. Измеряется временем, необходимым для реализации новой функциональности или исправления ошибки.
8. Экономическая эффективность: Соотношение затрат на разработку и эксплуатацию системы к полученной от неё выгоде.

Особое внимание следует уделить влиянию качества пользовательского интерфейса (GUI) и пользовательского опыта (UX) на бизнес-показатели. Исследования показывают, что плохой UX может приводить к потере от 25% до 40% пользователей на каждом этапе перехода между экранами. Напротив, хорошо спроектированный пользовательский интерфейс способен значительно улучшить ключевые метрики:

• Увеличение производительности труда: В корпоративных приложениях улучшение GUI/UX может повысить производительность труда сотрудников на 15-35%. Удобный интерфейс минимизирует время на выполнение рутинных операций и снижает когнитивную нагрузку.
• Рост конверсии: Для веб-сайтов и мобильных приложений качественный UX-дизайн может увеличить коэффициент конверсии до 200%, а в некоторых случаях — до 400%. Интуитивно понятный путь пользователя от знакомства с продуктом до совершения целевого действия напрямую влияет на продажи и привлечение клиентов.
• Сокращение расходов на поддержку клиентов: Эффективный UX-дизайн может снизить количество обращений в службу поддержки до 33%. Когда интерфейс понятен, пользователи реже сталкиваются с проблемами и вопросами, что разгружает саппорт и экономит средства компании.
• Укрепление лояльности и репутации: Удовлетворенные пользователи чаще возвращаются к продукту, рекомендуют его другим, что напрямую влияет на репутацию бренда и долгосрочную ценность клиента. Игнорирование качества UI/UX, напротив, приводит к снижению лояльности, негативным отзывам и падению репутации, что влечёт за собой серьёзные финансовые и репутационные потери.

Таким образом, критерии качества и эффективности — это не просто теоретические показатели, а мощные инструменты для оценки реальной ценности проектируемой информационной системы, напрямую влияющие на её успех на рынке и внутри организации.

Глава 2. Методологии и этапы проектирования информационных систем

2.1. Структурный подход к проектированию ИС

Исторически, одним из первых и наиболее фундаментальных подходов к разработке сложных программных систем стал структурный подход. Его появление было обусловлено необходимостью управлять все возрастающей сложностью проектов и систематизировать процесс разработки. Сущность структурного подхода заключается в декомпозиции (разбиении) информационной системы на автоматизируемые функции. Этот принцип известен как «разделяй и властвуй»: вместо того чтобы пытаться решить одну большую и сложную проблему целиком, её разбивают на множество меньших, более управляемых и независимых задач, что значительно облегчает процесс разработки.

Система при этом разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подразделяемые на задачи и конкретные процедуры. Такая иерархическая структура позволяет постепенно углубляться в детали, сохраняя при этом общее представление о системе.

Ключевые принципы структурного подхода:

• «Разделяй и властвуй»: Разделение сложной системы на более простые, легко управляемые компоненты. Это позволяет командам работать параллельно над разными частями, снижая общую сложность.
• Иерархическое упорядочивание: Организация составных частей проблемы в иерархические древовидные структуры. Например, главная функция системы может быть разбита на несколько подфункций, каждая из которых, в свою очередь, детализируется.
• Абстрагирование: Выделение существенных аспектов системы и игнорирование второстепенных на определенном уровне детализации. Это помогает сосредоточиться на главном и избежать перегрузки информацией.
• Формализация: Применение строгого методического подхода к решению проблем, используя стандартизированные нотации и диаграммы. Формализация обеспечивает однозначность понимания и снижает риск ошибок.

На стадии проектирования ИС модели структурного подхода активно используются для визуализации. Они расширяются диаграммами, отражающими структуру программного обеспечения, его архитектуру, структурные схемы программ и диаграммы экранных форм. Это позволяет заранее увидеть, как будет выглядеть и работать система.

Одним из наиболее известных и широко применяемых примеров методологии, разработанной на основе структурного подхода, является SADT (Structured Analysis and Design Technique), а её часть — IDEF0 (Icam DEFinition). IDEF0-диаграммы используются для моделирования бизнес-процессов и функциональной декомпозиции, показывая, какие функции выполняются в системе, какие данные они используют и производят, а также какие управляющие воздействия и исполнители участвуют в процессе.

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

Несмотря на появление более новых методологий, структурный подход остается актуальным для начального анализа и верхнеуровневого проектирования, особенно в проектах, где доминирует четкая функциональная иерархия и требуется строгое следование плану.

2.2. Объектно-ориентированный подход к проектированию ИС

В отличие от структурного подхода, который фокусируется на функциях и потоках данных, объектно-ориентированный подход (ООП) предлагает принципиально иной взгляд на проектирование информационных систем. Его появление в 1980-х годах стало ответом на возрастающую сложность систем и необходимость создания более гибкого, повторно используемого и легко модифицируемого программного обеспечения.

Концептуальной основой объектно-ориентированного подхода является объектная модель. Он использует объектную декомпозицию, описывая статическую структуру системы в терминах объектов и связей между ними, а поведение системы — в терминах обмена сообщениями между объектами.

Основные элементы объектной модели:

1. Абстрагирование: Выделение существенных характеристик объекта и игнорирование второстепенных. Позволяет создавать упрощенные, но функционально полные представления реальных сущностей.
2. Инкапсуляция: Сокрытие внутренней реализации объекта от внешнего мира. Объекты взаимодействуют друг с другом через четко определенные интерфейсы, что предотвращает несанкционированный доступ к данным и упрощает модификацию. Объект определяется как осязаемая реальность (tangible entity) — предмет или явление, имеющие четко определяемое поведение, обладающее состоянием (данными), поведением (методами) и индивидуальностью.
3. Модульность: Разделение системы на дискретные, независимые и повторно используемые компоненты (модули). В ООП модулями являются классы и объекты.
4. Иерархия: Упорядочение классов и объектов в иерархические структуры, чаще всего через наследование или агрегацию.

Структура и поведение схожих объектов определяют общий для них класс. Например, класс «Клиент» может описывать общие свойства (имя, адрес) и поведение (сделать заказ, просмотреть историю покупок) для всех конкретных клиентов.
Наследование — это мощный механизм, позволяющий строить новые классы (потомки) на основе существующих (предков), наследуя их данные и методы, и добавляя или переопределяя их функциональность. Например, класс «VIP-Клиент» может наследовать все от «Клиента», но добавлять новые методы для работы с эксклюзивными предложениями.

Основное преимущество объектно-ориентированного подхода состоит в упрощении проектирования ИС при наличии типовых проектных решений по отдельным компонентам, а также легкости модификации. Это объясняется несколькими факторами:

• Повышение модульности и повторного использования кода: Инкапсуляция и наследование позволяют создавать компоненты, которые можно многократно использовать в разных частях системы или в других проектах, сокращая необходимость повторного написания кода и уменьшая количество ошибок.
• Упрощение внесения изменений: Благодаря инкапсуляции, изменения внутри объекта не влияют на другие части системы, если не меняется его внешний интерфейс. Это делает систему более устойчивой к изменениям и упрощает её сопровождение.
• Улучшение наглядности и удобства сопровождения: Объектная модель более естественно отражает реальный мир, что делает систему более понятной для разработчиков и облегчает её документирование и сопровождение.
• Повышение безопасности: Инкапсуляция защищает данные объекта от прямого доступа извне, что способствует повышению информационной безопасности.
• Эффективное управление сложностью проекта: Возможность абстрагирования и декомпозиции на объекты позволяет справляться с высокосложными проектами, разбивая их на более управляемые единицы.

Таким образом, ООП не просто объединяет данные и программы в объекты; он создает надежную основу для проектирования и разработки программных систем, способных адаптироваться к изменяющимся требованиям и оставаться управляемыми на протяжении всего жизненного цикла.

2.3. Современные гибкие методологии (Agile, DevOps) и их влияние на проектирование

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

Agile-методологии (Scrum, Kanban, Extreme Programming и др.) — это не жесткий набор правил, а философия разработки, основанная на четырех ключевых ценностях, изложенных в Манифесте Agile:

1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

Влияние Agile на проектирование ИС проявляется в следующем:

• Итеративный и инкрементальный подход: Проектирование перестает быть одноразовым этапом и становится непрерывным процессом, распределенным по коротким итерациям (спринтам). На каждой итерации команда создает небольшой, но полностью функционирующий прирост продукта.
• Фокус на ценности для пользователя: Требования к системе определяются и уточняются постоянно, с тесным взаимодействием с заказчиком. Вместо долгого и детального проектирования всей системы сразу, Agile-команды фокусируются на проектировании только той функциональности, которая будет реализована в ближайшей итерации.
• Адаптивность к изменениям: Проектирование в Agile предполагает готовность к изменению требований даже на поздних стадиях, что является его ключевым преимуществом перед жесткими водопадными моделями. Проектная документация становится «живой» и постоянно обновляется.
• Кросс-функциональные команды: Проектирование становится общей ответственностью всей команды, включая аналитиков, разработчиков, тестировщиков и даже представителей заказчика. Это обеспечивает более глубокое понимание требований и эффективное решение проблем.

DevOps — это не столько методология, сколько культура и набор практик, направленных на автоматизацию и интеграцию процессов между командами разработки (Dev) и эксплуатации (Ops). Цель DevOps — сократить жизненный цикл разработки систем и обеспечить непрерывную поставку высококачественного программного обеспечения.

Влияние DevOps на проектирование ИС:

• «Инфраструктура как код» (Infrastructure as Code, IaC): Проектирование инфраструктуры (серверов, сетей, баз данных) становится частью процесса разработки. Окружения для развертывания описываются в коде, что позволяет автоматизировать их создание, управление и масштабирование. Это минимизирует риски ошибок и обеспечивает согласованность сред.
• Непрерывная интеграция и непрерывная доставка (CI/CD): Проектирование должно учитывать возможность автоматической сборки, тестирования и развертывания кода. Архитектура системы проектируется таким образом, чтобы изменения в одной части не нарушали работу других, что способствует частым и небольшим релизам.
• Мониторинг и обратная связь: На этапе проектирования закладываются механизмы сбора метрик и мониторинга производительности системы в реальном времени. Это позволяет быстро выявлять проблемы в эксплуатации и оперативно вносить коррективы в дизайн системы.
• Микросервисная архитектура: DevOps способствует развитию микросервисной архитектуры, где система разбивается на небольшие, автономные сервисы. Проектирование таких систем требует особого внимания к взаимодействию между сервисами, их масштабируемости и устойчивости к сбоям.

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

2.4. Этапы проектирования ИС: от анализа до внедрения

Проектирование информационной системы — это комплексный, многоэтапный процесс, который начинается задолго до написания первой строчки кода и продолжается вплоть до полного запуска системы в эксплуатацию. Каждый этап имеет свои цели, задачи и методологии, а их последовательное и качественное выполнение является залогом успешной реализации проекта и минимизации рисков.

Давайте последовательно рассмотрим основные стадии проектирования ИС:

Этап проектирования ИС	Основная цель	Ключевые задачи	Важность для проекта
1. Анализ требований	Определение того, что система должна делать для удовлетворения потребностей пользователей и бизнеса.	Сбор, классификация, анализ и документирование функциональных и нефункциональных требований. Определение границ системы, заинтересованных сторон и бизнес-целей.	Формирует основу для всего проекта. Ошибки на этом этапе приводят к созданию системы, не соответствующей ожиданиям, что может вызвать необходимость дорогостоящих переделок или даже полный провал проекта. Качественный анализ снижает риски и обеспечивает релевантность решения.
2. Концептуальное проектирование (архитектурный дизайн)	Разработка высокоуровневой архитектуры системы, определение основных компонентов и их взаимодействия.	Выбор архитектурного стиля (например, монолит, микросервисы), определение основных модулей, внешних интерфейсов, технологий и платформ. Создание общей схемы системы.	Определяет масштабируемость, производительность, надежность и сопровождаемость системы. Правильный выбор архитектуры позволяет избежать тупиковых решений и заложить прочный фундамент для будущего развития ИС.
3. Логическое проектирование (детальный дизайн)	Детализация архитектуры и разработка логической структуры каждого компонента.	Проектирование баз данных (ER-диаграммы, нормализация), детальное описание функциональных модулей, алгоритмов, пользовательского интерфейса (UI/UX), API. Создание спецификаций для каждого компонента.	Преобразует высокоуровневые идеи в конкретные, реализуемые планы. Детальное проектирование минимизирует неоднозначности для разработчиков, ускоряет процесс кодирования и снижает вероятность ошибок. На этом этапе закладывается основа для тестирования и интеграции.
4. Физическое проектирование	Определение физической реализации системы, включая выбор конкретных технологий и аппаратного обеспечения.	Выбор СУБД, операционных систем, языков программирования, сетевого оборудования. Определение физической структуры данных (индексы, таблицы), конфигурации серверов, стратегии развертывания.	Превращает абстрактные модели в конкретные технические решения. Оптимизация на этом уровне влияет на производительность, безопасность и стоимость эксплуатации системы. Здесь определяются все параметры, необходимые для развертывания и запуска ИС в реальной среде.
5. Реализация (кодирование)	Написание программного кода в соответствии с разработанными спецификациями.	Разработка модулей, функций, интерфейсов, интеграционных механизмов. Модульное тестирование каждого компонента.	На этом этапе создается сам продукт. Качественное кодирование, основанное на детальном проекте, обеспечивает стабильность и корректность работы системы.
6. Тестирование	Проверка соответствия реализованной системы требованиям и выявление дефектов.	Функциональное, интеграционное, системное, нагрузочное, приемочное тестирование. Исправление ошибок и дефектов.	Гарантирует, что система работает так, как было задумано, и соответствует ожиданиям пользователей. Обнаружение ошибок на ранних стадиях тестирования значительно дешевле, чем их исправление после внедрения.
7. Внедрение	Развертывание системы в рабочей среде и подготовка пользователей к её использованию.	Установка ПО, миграция данных, обучение пользователей, создание эксплуатационной документации.	Осуществляет переход системы из стадии разработки в стадию эксплуатации. Успешное внедрение требует не только технических, но и организационных усилий, чтобы обеспечить плавный переход и принятие системы пользователями.
8. Эксплуатация и сопровождение	Поддержание работоспособности системы, внесение изменений и улучшений, поддержка пользователей.	Мониторинг производительности, устранение сбоев, обновление ПО, добавление новой функциональности, управление изменениями.	Долговременное обеспечение ценности ИС. Сопровождение позволяет системе оставаться актуальной и эффективной на протяжении всего её жизненного цикла, адаптируясь к меняющимся потребностям бизнеса и технологическому прогрессу. Игнорирование этого этапа приводит к устареванию и неэффективности системы, что, в свою очередь, влечёт за собой потерю конкурентных преимуществ.

Каждый из этих этапов тесно связан с предыдущим и последующим, образуя единую цепочку. Обоснование значимости каждого этапа для успешной реализации проекта и минимизации рисков заключается в том, что пропуск или некачественное выполнение любой из стадий может привести к серьезным проблемам: от несоответствия системы требованиям до полного провала проекта и значительных финансовых потерь. Системное и последовательное прохождение всех этапов, с учетом гибкости и адаптивности современных методологий, является ключом к созданию эффективной и устойчивой информационной системы.

Глава 3. Сбор, анализ и моделирование требований к информационной системе

3.1. Классификация и сбор требований к ИС

Сердцем любого успешного проекта по созданию информационной системы является глубокое понимание того, что именно эта система должна делать и как она должна функционировать. Это понимание формируется на этапе сбора и анализа требований — процессе, который зачастую является самым сложным, но при этом самым критичным. Неточные или неполные требования могут привести к созданию продукта, который не будет востребован, независимо от его технического совершенства.

Требование к программному обеспечению — это условие, которому оно должно удовлетворять, или свойство, которым оно должно обладать, чтобы удовлетворить потребность пользователя, а также требования контракта, спецификации или стандарта. Все требования, указанные в спецификации, делятся на функциональные и нефункциональные.

Функциональные требования (ФТ) описывают задачи, которые приложение или его компоненты должны выполнять, то есть «что» система должна делать, без учета ограничений, связанных с её реализацией. Они определяют поведение системы в процессе обработки инфор��ации и включают вычисления, пользовательское взаимодействие, преобразование данных, выполнение бизнес-логики. Каждая функция обычно включает три этапа: ввод данных, их обработка и вывод результата.

Примеры функциональных требований:

• Пользователь должен иметь возможность авторизоваться в системе, используя логин и пароль.
• Система должна позволять проверять баланс счета и переводить средства между счетами в банковском приложении.
• Интернет-магазин должен предоставлять функции добавления, удаления и замены товаров в корзине.
• Система должна автоматически формировать ежемесячные отчеты по продажам.
• Система должна обрабатывать данные о клиентах, включая их ввод, хранение и извлечение по запросу.

Нефункциональные требования (НФТ), напротив, устанавливают критерии качества и производительности программы, то есть «каким образом» система это сделает. Они не определяют поведение системы, но описывают её атрибуты или атрибуты системного окружения. Важность нефункциональных требований заключается в обеспечении общей производительности, удобства использования и устойчивости системы, влияя на удовлетворенность пользователей и эффективность системы.

Примеры нефункциональных требований:

• Масштабируемость: Система должна поддерживать до 10 000 одновременных пользователей без снижения производительности.
• Производительность: Время отклика системы на запрос пользователя не должно превышать 2 секунд.
• Безопасность: Система должна соответствовать стандарту ISO/IEC 27001 и использовать двухфакторную аутентификацию.
• Надежность: Время простоя системы не должно превышать 0,01% в год (99,99% доступности).
• Удобство использования: Интерфейс системы должен быть интуитивно понятным и требовать не более 1 часа обучения для нового пользователя.
• Совместимость: Система должна быть совместима с браузерами Chrome, Firefox, Edge последних трех версий.
• Восстанавливаемость: В случае сбоя данные должны быть восстановлены в течение 30 минут с потерей не более 15 минут информации.

Эффективный сбор требований требует применения разнообразных методов выявления:

• Собеседование: Прямое общение с заинтересованными сторонами для выяснения их потребностей и ожиданий.
• Анкетирование: Сбор информации от большого числа пользователей через опросники.
• Проведение совещаний: Организованные встречи для обсуждения и согласования требований.
• Сессии по выявлению требований (мозговой штурм): Групповая работа для генерации идей и выявления скрытых требований.
• Раскадровка (storyboard): Визуализация последовательности действий пользователя в системе, помогает лучше понять пользовательский опыт.
• Создание и демонстрация работающих прототипов: Быстрое создание упрощенных версий системы для получения обратной связи.
• Ролевые игры: Симуляция взаимодействия пользователей с системой для выявления скрытых потребностей и проблем.

Работа с требованиями в ходе проекта — это непрерывный процесс, который делится на этапы:

1. Определение типов требований и групп участников проекта: Выявление всех стейкхолдеров (заказчики, пользователи, менеджеры, разработчики) и их ролей.
2. Первичный сбор требований: Использование вышеупомянутых методов для накопления исходной информации.
3. Классификация и занесение в базу данных требований: Систематизация собранных данных, их структурирование и хранение (например, в Jira, Confluence, специализированных системах управления требованиями).
4. Использование этой базы для управления проектом: Требования становятся основой для планирования, разработки, тестирования и контроля всего проекта.

Тщательный подход к сбору и классификации требований закладывает фундамент для всей последующей разработки, обеспечивая создание действительно ценной и полезной информационной системы.

3.2. Анализ и документирование требований

После того как требования собраны, начинается фаза их анализа и документирования. Это критически важный этап, который преобразует набор разрозненных пожеланий и ожиданий в структурированный, понятный и согласованный набор спецификаций, служащих основой для проектирования и разработки.

Процесс анализа требований включает:

• Классификацию: Разделение требований на функциональные и нефункциональные, а также по другим критериям (например, по приоритету, по модулю системы, по стейкхолдерам).
• Приоритизацию: Определение значимости каждого требования для бизнеса и пользователя. Используются различные методы, например, MoSCoW (Must have, Should have, Could have, Won’t have) или ранжирование по бизнес-ценности.
• Выявление конфликтов и неоднозначностей: Устранение противоречий между требованиями разных стейкхолдеров или нечетких формулировок, которые могут привести к неправильной интерпретации.
• Детализацию: Разработка высокоуровневых требований до достаточного уровня детализации, чтобы разработчики могли их реализовать.
• Проверку на выполнимость: Оценка реалистичности требований с учетом доступных ресурсов, бюджета и технологий.

Документирование требований — это процесс формального описания всех согласованных требований. Документация служит основным источником истины для всех участников проекта и предотвращает недопонимание. Для этого используются различные стандарты, такие как IEEE 830 (Рекомендуемая практика по разработке спецификаций требований к ПО) или ГОСТ 19/34.

Основным артефактом является Спецификация требований к программному обеспечению (SRS — Software Requirements Specification), которая обычно включает:

• Введение (цели, область применения, определения).
• Общее описание (перспективы продукта, функции, пользователи, ограничения).
• Конкретные требования (функциональные, нефункциональные, требования к внешним интерфейсам).
• Приложения (глоссарий, диаграммы).

Занесение требований в базу данных требований (например, в такие инструменты как Jira, Confluence, Trello, Azure DevOps, IBM DOORS, Jama Connect) позволяет эффективно управлять ими на протяжении всего жизненного цикла проекта. Эта база обеспечивает:

• Централизованное хранение: Все требования доступны в одном месте.
• Трассируемость: Возможность отслеживать, как требования преобразуются в элементы дизайна, код, тестовые сценарии и обратно.
• Управление изменениями: Контроль за изменениями требований и их влиянием на проект.
• Совместную работу: Облегчение взаимодействия между командами.

Игнорирование нефункциональных требований (НФТ) на этапе анализа и документирования может привести к крайне серьезным негативным последствиям. Как правило, ФТ определяют «что» делает система, а НФТ — «насколько хорошо» она это делает. Если система не может делать это «достаточно хорошо», то её функциональность теряет смысл.

Потенциальные последствия игнорирования НФТ:

• Сбои в работе, замедление системы и её недоступность: Отсутствие требований к производительности или надежности приводит к тому, что система не выдерживает нагрузок, «падает» или работает слишком медленно, делая её непригодной для использования.
• Проблемы с безопасностью, включая утечки данных и уязвимость к атакам: Недостаточное внимание к безопасности может привести к критическим уязвимостям, что чревато потерей конфиденциальных данных, репутационным ущербом и финансовыми потерями.
• Трудности с интеграцией со смежными системами: Если не заложены требования к совместимости и API, система становится «островом», неспособным обмениваться данными с другими корпоративными или внешними сервисами, что снижает её ценность.
• Потеря прибыли, клиентов и репутации компании: Неудовлетворительный пользовательский опыт (из-за отсутствия требований к UI/UX), низкая производительность или проблемы с безопасностью отпугивают клиентов, снижают доходы и наносят непоправимый вред имиджу компании.
• Претензии со стороны регуляторов и крупные штрафы: В отраслях, регулируемых строгими стандартами (финансы, здравоохранение), несоблюдение требований к безопасности, конфиденциальности или целостности данных может повлечь за собой огромные штрафы и юридические последствия. Например, игнорирование GDPR или HIPAA может стоить миллионы.

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

3.3. Моделирование функциональных и архитектурных требований с использованием UML

После того как требования к информационной системе собраны, классифицированы и задокументированы, следующим шагом становится их визуализация и детализация с помощью специализированных языков моделирования. Среди них доминирующую позицию занимает UML (Unified Modeling Language) — унифицированный язык визуального моделирования, который предоставляет мощные инструменты для графического представления и описания различных аспектов системы.

UML не является методом разработки, а скорее языком, который позволяет командам общаться на одном языке, понимать структуру и поведение системы до её фактической реализации. Важно, что UML обеспечивает поддержку всех этапов жизненного цикла информационной системы (ИС):

• Стадия анализа требований: Используются диаграммы бизнес-прецедентов и диаграммы видов деятельности для описания бизнес-активности и высокоуровневых функциональных требований.
• Этап концептуального и логического моделирования: Применяются диаграммы классов, последовательностей и состояний для предварительного проектирования, описания бизнес-объектов и их взаимодействия.
• Этап физической реализации системы: Разрабатываются диаграммы компонентов и развертывания, которые показывают, как система будет физически структурирована и развернута.

Основные типы UML-диаграмм, используемые в проектировании информационных систем:

1. Диаграммы прецедентов (Use Case Diagrams): Обобщенная модель функционирования системы в окружающей среде. Они описывают набор функциональности, доступной акторам (внешним для системы сущностям, таким как пользователи, другие системы). Показывают «что» система должна делать с точки зрения пользователя.
   • Пример: Для банковской системы акторами могут быть «Клиент» и «Банкомат», а прецедентами — «Снять наличные», «Проверить баланс», «Перевести средства».
2. Диаграммы видов деятельности (Activity Diagrams): Модель бизнес-процесса или поведения системы в рамках прецедента. Используются для визуализации потока управления, последовательности действий и параллельных процессов.
   • Пример: Пошаговое описание процесса оформления заказа в интернет-магазине, включая выбор товара, добавление в корзину, ввод адреса, оплату и подтверждение.
3. Диаграммы взаимодействия (Interaction Diagrams): Моделируют процесс обмена сообщениями между объектами, показывая, как объекты взаимодействуют для выполнения определенного действия. Представляются в виде:
   • Диаграмм последовательностей (Sequence Diagrams): Акцентируют внимание на временной последовательности сообщений.
   • Кооперативных диаграмм (Collaboration Diagrams): Акцентируют внимание на структурных связях между объектами.
   • Пример: Последовательность сообщений при авторизации пользователя: пользователь вводит данные → система проверяет данные → отправляет запрос в БД → БД возвращает результат → система авторизует или отклоняет.
4. Диаграммы состояний (Statechart Diagrams): Модель динамического поведения системы и её компонентов при переходе из одного состояния в другое в ответ на внешние или внутренние события.
   • Пример: Состояния заказа в интернет-магазине: «Новый» → «В обработке» → «Оплачен» → «Отгружен» → «Доставлен».
5. Диаграммы классов (Class Diagrams): Моделируют статическую структуру данных и взаимосвязи между классами. Предназначены для проектирования объектов информационной системы, их атрибутов и методов. Являются основой для проектирования баз данных и объектно-ориентированного кода.
   • Пример: Классы «Клиент», «Заказ», «Товар» с их атрибутами и связями («Клиент делает Заказ», «Заказ содержит Товар»).
6. Диаграммы компонентов (Component Diagrams): Модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС. Показывают, как компоненты (например, модули, сервисы) связаны друг с другом.
   • Пример: Диаграмма, показывающая связь между веб-приложением, API-сервисом, базой данных и внешним платежным шлюзом.
7. Диаграммы развертывания (Deployment Diagrams): Показывают, из каких аппаратных и программных узлов состоит система в данный момент и как эти узлы связаны между собой. Используются на этапе физической реализации системы для планирования развертывания.
   • Пример: Диаграмма, иллюстрирующая размещение веб-сервера, сервера приложений и сервера базы данных на разных физических или виртуальных машинах.

Использование UML позволяет создать всеобъемлющее и непротиворечивое представление о системе, облегчает коммуникацию между участниками проекта и значительно снижает риски на всех этапах жизненного цикла ИС.

3.4. Моделирование потоков данных с помощью DFD

Наряду с унифицированным языком моделирования UML, существует другая мощная методология для графического представления систем — DFD (Data Flow Diagrams), или диаграммы потоков данных. Это методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных является одним из основных инструментов структурного анализа и проектирования информационных систем.

DFD-нотация предназначена для моделирования информационных систем с точки зрения хранения, обработки и передачи данных. Она позволяет визуализировать, как информация перемещается по системе и трансформируется различными процессами.

Компоненты DFD-диаграмм включают:

1. Внешняя сущность (External Entity): Объекты или системы, находящиеся за пределами процесса, которые поставляют или получают информацию. Это могут быть пользователи, другие информационные системы, внешние организации. На DFD они представлены прямоугольниками.
2. Процесс (Process): Активность, которая приводит к преобразованию данных. Процесс принимает входные данные, обрабатывает их и выдает выходные данные. Обозначается кругом или прямоугольником со скругленными углами.
3. Хранилище данных (Data Store): Место, где данные хранятся в системе. Это могут быть базы данных, таблицы, файлы, архивы. Обозначается двумя параллельными горизонтальными линиями или открытым прямоугольником.
4. Поток данных (Data Flow): Связь, показывающая, куда и какая информация передается между сущностями, процессами и хранилищами. Обозначается стрелкой с указанием направления и типа данных.

Для описания диаграмм DFD используются две основные нотации — Йордана (Yourdon) и Гейна-Сарсон (Gane-Sarson). Они отличаются синтаксисом символов (например, формой процессов и хранилищ данных), но имеют одинаковую суть и набор элементов.

Модель DFD является иерархической: каждый процесс на верхнем уровне может быть декомпозирован на структурные составляющие, отношения между которыми могут быть показаны на отдельной, более детализированной диаграмме. Это позволяет создавать многоуровневые модели, начиная с высокоуровневого обзора и постепенно углубляясь в детали.

Центральным элементом иерархии DFD является контекстная диаграмма DFD. Это диаграмма, показывающая разрабатываемую автоматизированную информационную систему в окружающей среде. Её основное назначение — ограничить рамки системы, показав, какие внешние сущности взаимодействуют с системой и какие основные потоки данных существуют между ними. Контекстная диаграмма представляет всю систему как один процесс.

Актуальность DFD в современном бизнес-анализе и интеграции систем остается высокой, несмотря на широкое распространение объектно-ориентированных подходов и UML. Диаграммы потоков данных особенно ценны при:

• Разработке ИС: Для понимания и моделирования информационных потоков внутри системы.
• Интеграции систем: Для визуализации обмена данными между различными системами, что критически важно при создании единого информационного поля.
• Миграции данных и функционала: Помогают определить, как данные будут перемещаться и трансформироваться при переходе на новую систему.
• Управлении данными и построении аналитических хранилищ: DFD позволяют четко описать, откуда приходят данные, как они обрабатываются и где хранятся.

Например, в системе управления заказами контекстная DFD могла бы показать, что «Клиент» и «Поставщик» являются внешними сущностями, взаимодействующими с «Системой управления заказами», обмениваясь такими потоками данных, как «Заказ», «Подтверждение заказа», «Счет», «Информация о товаре». Затем процесс «Система управления заказами» может быть декомпозирован на более детальные процессы, такие как «Обработка заказа», «Управление складом» и «Бухгалтерия», каждый со своими потоками данных и хранилищами.

Использование DFD позволяет бизнес-аналитикам и проектировщикам эффективно визуализировать и анализироват�� движение данных, выявлять узкие места и оптимизировать информационные процессы в системе, что в конечном итоге способствует созданию более эффективных и надёжных решений.

Глава 4. Проектирование ключевых компонентов информационной системы

4.1. Проектирование пользовательского интерфейса (UI/UX)

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

Пользовательский интерфейс — это не только визуальное оформление. Это совокупность информационной модели проблемной области, средств и способов взаимодействия пользователя с информационной моделью, а также компонентов, обеспечивающих формирование информационной модели в процессе работы программной системы. UI — это то, что видит и с чем взаимодействует пользователь (кнопки, меню, формы). UX — это общий опыт взаимодействия, ощущения и эмоции, которые пользователь получает при работе с системой.

Основные принципы создания пользовательских интерфейсов, обеспечивающие его высокое качество:

1. Естественность: Интерфейс должен быть интуитивно понятным, имитировать реальный мир и привычные действия.
2. Гибкость: Система должна адаптироваться к разным стилям работы пользователей, предлагая настройки и возможности персонализации.
3. Дружелюбность: Интерфейс должен быть прост в освоении, прощать ошибки и предоставлять понятную обратную связь.
4. Согласованность: Единообразие элементов управления, навигации и терминологии по всей системе.
5. Простота: Достигается продуманными лаконичными названиями команд, грамотно сформулированными системными сообщениями и логичным размещением элементов на экране. Минимум отвлекающих факторов, максимум функциональности.
6. Эстетическая привлекательность: Визуально приятный и современный дизайн способствует позитивному восприятию и доверию к продукту.

Влияние качества UI/UX на бизнес-показатели и удовлетворенность клиентов колоссально, и его нельзя недооценивать:

• Повышение производительности труда: В корпоративных приложениях улучшение GUI/UX может увеличить продуктивность сотрудников на 15-35%. Удобный интерфейс сокращает время на выполнение задач, уменьшает количество ошибок и снижает уровень стресса.
• Рост конверсии: Хорошо спроектированный пользовательский интерфейс способен увеличить коэффициент конверсии веб-сайта до 200%, а лучший UX-дизайн — до 400%. Интуитивно понятный путь пользователя от знакомства с продуктом до покупки или выполнения целевого действия напрямую влияет на прибыль.
• Сокращение расходов на поддержку клиентов: Эффективный UX-дизайн может сократить количество обращений в службу поддержки до 33%. Если пользователи легко находят нужную информацию и функционал, они реже нуждаются в помощи, что экономит ресурсы компании.
• Снижение оттока пользователей: Плохой UX может приводить к потере от 25% до 40% пользователей на каждом этапе перехода между экранами. Напротив, положительный пользовательский опыт способствует удержанию клиентов и формированию лояльной аудитории.
• Укрепление репутации и бренда: Продукт с отличным UI/UX вызывает доверие, получает положительные отзывы и рекомендации, что напрямую влияет на репутацию компании на рынке.

Проектирование интерфейса — это итеративный процесс, включающий:

1. Анализ привычек целевой аудитории: Понимание того, кто будет использовать продукт, их задач, потребностей и ограничений.
2. Формулирование и проверка гипотез: Создание предположений о том, как пользователи будут взаимодействовать с системой, и их тестирование.
3. Продумывание внешнего вида: Разработка макетов, цветовых схем, типографики и общей стилистики.
4. Проектирование пользовательского опыта: Создание карт пользовательских сценариев, CJM (Customer Journey Map), вайрфреймов.
5. Создание и тестирование прототипов: Разработка интерактивных моделей интерфейса для проверки гипотез и получения обратной связи.

Экономическая выгода прототипирования огромна. Создание прототипов информационных систем позволяет значительно сэкономить время и деньги компании. Обнаружение и исправление ошибок на ранних стадиях проекта обходится существенно дешевле, чем на поздних. Например, при использовании 3D-печати для прототипирования срок изготовления тестового образца может быть сокращен с 2-3 недель до 1-3 дней. В разработке ПО прототипирование позволяет:

• Сократить сроки разработки: Выгоднее протестировать несколько простых прототипов, чем долго разрабатывать продукт, а затем переделывать его.
• Снизить стоимость: Раннее выявление проблем предотвращает дорогостоящие исправления после запуска.
• Улучшить коммуникацию: Наглядный прототип позволяет заказчикам и команде лучше понять будущий продукт и избежать расхождений в ожиданиях.
• Минимизировать риски: Прототипы помогают выявить неверные предположения о потребностях пользователей до того, как будет потрачено много ресурсов на реализацию.

Таким образом, инвестиции в качественное UI/UX проектирование и прототипирование окупаются многократно, обеспечивая успех продукта и удовлетворенность его пользователей. Как иначе можно гарантировать, что система будет не просто работать, но и приносить реальную пользу?

4.2. Проектирование баз данных

Без прочной и хорошо спроектированной базы данных (БД) невозможно представить современную информационную систему. База данных является хранилищем всей информации, с которой работает система, и её проектирование — это один из наиболее ответственных и фундаментальных этапов в создании ИС. Ошибки на этом этапе могут привести к серьезным проблемам с производительностью, целостностью данных и масштабируемостью системы.

Проектирование баз данных обычно проходит в три основных этапа:

1. Концептуальное (инфологическое) проектирование:
   • На этом этапе определяются данные, которые необходимо хранить, и связи между ними, независимо от конкретной СУБД (системы управления базами данных) или модели данных.
   • Основная задача — создать высокоуровневую модель предметной области, понятную как специалистам, так и бизнес-пользователям.
   • Ключевым инструментом являются ER-диаграммы (модели «сущность-связь»). Они визуально изображают сущности (объекты реального мира, о которых необходимо хранить информацию, например, «Клиент», «Товар», «Заказ»), их атрибуты (характеристики сущностей, например, «имя клиента», «цена товара») и связи между сущностями (например, «Клиент делает Заказ», «Заказ содержит Товары»).
   • Пример: На ER-диаграмме «Клиент» и «Заказ» будут сущностями, соединенными связью «размещает», где один клиент может разместить много заказов (связь «один-ко-многим»).
2. Логическое (даталогическое) проектирование:
   • Концептуальная модель преобразуется в логическую структуру, совместимую с выбранной моделью данных (чаще всего реляционной) и потенциально с конкретной СУБД.
   • Основная задача — устранение избыточности данных, обеспечение их целостности и повышение эффективности хранения. Для этого проводится нормализация данных.
   • Нормализация — это процесс организации полей и таблиц реляционной базы данных таким образом, чтобы минимизировать избыточность данных и избежать аномалий вставки, обновления и удаления. Она достигается путем приведения таблиц к нормальным формам (1НФ, 2НФ, 3НФ, БКНФ и т.д.).
   • Например, если в таблице «Заказы» хранится информация о клиентах (имя, адрес), то при логическом проектировании эти данные будут вынесены в отдельную таблицу «Клиенты», а в таблице «Заказы» останется только ссылка на клиента (например, id_{клиента}).
3. Физическое проектирование:
   • На этом этапе определяется реальная структура хранения данных на диске и выбираются конкретные механизмы реализации в рамках выбранной СУБД.
   • Выбирается конкретная СУБД (например, MySQL, PostgreSQL, Oracle, Microsoft SQL Server). Выбор зависит от требований к производительности, масштабируемости, безопасности, лицензионным затратам и квалификации команды.
   • Разрабатывается схема БД с учетом физических аспектов: задаются параметры таблиц, типы данных для столбцов, определяются первичные и внешние ключи, создаются индексы для ускорения поиска и фильтрации данных.
   • Учитываются требования к производительности (оптимизация запросов, денормализация для ускорения чтения) и безопасности (права доступа пользователей, шифрование).
   • Пример: Для таблицы Заказы может быть создан индекс по полю ДатаЗаказа для ускорения поиска заказов за определенный период.

Реляционная модель является наиболее часто используемой моделью для большинства проектов баз данных, и её доминирование на рынке подтверждается статистикой:

• В 2021 году на долю Oracle, MySQL и Microsoft SQL Server, основанных на реляционной модели, приходилось более 62% общего числа пользователей СУБД.
• Глобальный размер рынка реляционных баз данных в 2023 году оценивался в 62,76 млрд долларов США, с прогнозом роста до 146,64 млрд долларов США к 2031 году. Это подчеркивает её устойчивую актуальность и востребованность.

Реляционные базы данных обладают такими преимуществами, как строгая структура, обеспечение целостности данных, гибкость в запросах благодаря SQL и широкая поддержка со стороны инструментов и сообщества.

Качественное проектирование базы данных — это инвестиция в будущее системы. Оно обеспечивает не только эффективное хранение и доступ к данным, но и закладывает основу для масштабируемости, безопасности и надежности всей информационной системы.

Глава 5. Актуальные аспекты проектирования ИС: безопасность, масштабируемость и интеграция

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

5.1. Обеспечение информационной безопасности на этапе проектирования

Информационная безопасность (ИБ) — это не дополнение к системе, а её неотъемлемая часть, которую необходимо закладывать на самых ранних этапах проектирования. Игнорирование ИБ на этом этапе приводит к появлению уязвимостей, которые могут быть чрезвычайно дороги и сложны в устранении в уже работающей системе.

Проектирование ИБ-системы — это формирование комплекса мер, направленных на обеспечение безопасности данных и предотвращение несанкционированного доступа или распространения. Это процесс, который охватывает не только технические решения, но и организационные, правовые и кадровые аспекты.

Этапы проектирования систем информационной безопасности включают:

1. Анализ актуального состояния ИС: Оценка текущей инфраструктуры, используемых технологий, существующих данных и бизнес-процессов.
2. Выявление уязвимостей: Поиск потенциальных слабых мест в системе, которые могут быть использованы злоумышленниками.
3. Оценка существующих мер защиты: Анализ уже внедренных механизмов безопасности и их эффективности.
4. Определение требований к безопасности: Формулировка конкретных целей и задач ИБ, исходя из бизнес-рисков, угроз и требований регуляторов.
5. Разработка архитектуры системы защиты: Проектирование комплексного решения, включающего аппаратные, программные и организационные средства.

Информационная безопасность на любом уровне предполагает реализацию трех фундаментальных составляющих, известных как триада ЦРУ (CIA Triad):

• Конфиденциальность информации: Обеспечение того, что данные доступны только авторизованным лицам. Недоступность её третьим лицам.
• Целостность информации: Гарантия того, что данные не были изменены или уничтожены несанкционированным образом. Отсутствие искажений или подмены.
• Доступность информации: Обеспечение постоянной возможности для авторизованных пользователей иметь доступ к нужным данным и ресурсам системы.

Нормативные требования играют ключевую роль в проектировании ИБ. Проектирование систем ИБ должно учитывать:

• Требования нормативных правовых актов: Например, Федеральные законы № 152-ФЗ «О персональных данных» в России, GDPR в Европе.
• Требования регуляторов: Для России это, например, ФСТЭК РФ (Федеральная служба по техническому и экспортному контролю) и ФСБ РФ (Федеральная служба безопасности). Для финансового сектора действуют особые требования Центробанка.
• Внутренние политики компании: Корпоративные стандарты и правила по обращению с информацией.

Порядок проектирования ИБ-систем часто соответствует требованиям стандартов, таких как ГОСТ Р 59793—2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания», который устанавливает общие положения по созданию систем ИБ.

При разработке архитектуры системы информационной безопасности необходимо предусмотреть способы защиты, которые минимизируют риски наиболее массовых проблем, таких как:

• Вирусы и спам: Установка и настройка антивирусного ПО на рабочих станциях и серверах, использование программ фильтрации электронной почты.
• Несанкционированный доступ: Внедрение сетевых экранов (файрволов) для контроля входящего и исходящего трафика, систем аутентификации и авторизации, систем обнаружения вторжений (IDS/IPS).
• Утечки данных: Применение систем предотвращения утечек данных (DLP), шифрование конфиденциальной информации.

Комплексный подход к ИБ на этапе проектирования позволяет создать не просто функциональную, но и устойчивую, защищенную информационную систему, минимизирующую риски для бизнеса и пользователей.

5.2. Проектирование масштабируемых информационных систем

В современном мире, характеризующемся экспоненциальным ростом объемов данных и количества пользователей, способность информационной системы эффективно адаптироваться к изменяющимся нагрузкам является одним из ключевых требований. Масштабирование информационных систем — это процесс увеличения пропускной способности ИС для обработки растущих объемов данных, запросов или пользователей, позволяющий системе сохранять стабильность и производительность при росте нагрузки. Это не просто добавление ресурсов, а продуманная стратегия, закладываемая на этапе проектирования.

Масштабируемость — это способность системы адаптироваться к резкому изменению показателей задач и повышению требований, например, увеличению объемов данных или числа пользователей, без структурных изменений и с наращиваемостью производительности.
Количественно масштабируемость может быть оценена как отношение прироста производительности системы к приросту используемых ресурсов, при этом чем ближе это отношение к единице, тем лучше. Например, если при двукратном увеличении аппаратных ресурсов производительность возросла в 1,8 раза, то коэффициент масштабируемости составит 1.8/2 = 0.9.

Существует три ключевых подхода к масштабированию, которые должны быть учтены на этапе проектирования:

1. Вертикальное масштабирование (Scale-Up):
   • Сущность: Увеличение ресурсов одного узла системы. Это означает добавление большего количества оперативной памяти, более мощного процессора, увеличение объема хранилища на существующем сервере.
   • Преимущества: Простота в реализации, не требует значительных изменений в архитектуре приложения.
   • Недостатки: Ограничено возможностями физического оборудования (есть предел того, сколько памяти или процессоров можно установить в один сервер). Создает единую точку отказа.
   • Применение: Часто используется для монолитных приложений, где разделение на компоненты затруднено.
2. Горизонтальное масштабирование (Scale-Out):
   • Сущность: Добавление новых узлов (серверов, экземпляров приложения) в систему для распределения нагрузки. Вместо одного мощного сервера используется несколько менее мощных.
   • Преимущества: Обеспечивает практически неограниченное расширение ресурсов, повышает отказоустойчивость (при выходе из строя одного узла, другие продолжают работать).
   • Недостатки: Требует дополнительной настройки архитектуры для распределения нагрузки (балансировщики нагрузки, распределенные базы данных) и управления состоянием между узлами. Сложность в синхронизации данных.
   • Применение: Идеально подходит для микросервисных архитектур и систем, разработанных с учетом распределенной природы.
3. Куб масштабирования приложений (Cube Scaling):
   • Сущность: Более комплексный подход, который совмещает вертикальное и горизонтальное масштабирование, а также учитывает сетевую архитектуру, контейнеризацию (Docker, Kubernetes) и другие современные технологии. Он включает три измерения:
     • X-ось (клонирование): Горизонтальное масштабирование путем запуска множества идентичных экземпляров приложения.
     • Y-ось (функциональная декомпозиция): Разделение системы на независимые сервисы (микросервисы).
     • Z-ось (шардинг данных): Разделение данных на независимые сегменты (шарды), которые могут быть обработаны параллельно.
   • Преимущества: Максимальная гибкость, высокая отказоустойчивость, способность обрабатывать экстремальные нагрузки.
   • Недостатки: Высокая сложность архитектуры и управления.

Масштабируемость зависит от:

• Аппаратуры: Производительность серверов, скорость сети, характеристики дисковых подсистем.
• Особенностей операционной системы и приложений: Эффективность кода, использование асинхронных операций, управление памятью.
• Способов физического размещения данных: Выбор подходящей СУБД, стратегия шардирования, репликация.
• Подключения сервера к сети: Пропускная способность канала, наличие балансировщиков нагрузки.

Влияние архитектуры на стратегию масштабирования:

• Монолитные приложения (где вся функциональность собрана в одном большом блоке) чаще масштабируются вертикально, так как их сложно декомпозировать для горизонтального распределения.
• Микросервисные приложения (состоящие из множества независимых, слабо связанных сервисов) гораздо лучше поддаются горизонтальному масштабированию, поскольку каждый сервис может быть масштабирован независимо.

Таким образом, проектирование масштабируемых ИС требует не только выбора правильной стратегии масштабирования, но и архитектурных решений, которые изначально предусматривают возможность роста и развития системы без фундаментальных переделок, что является залогом долгосрочного успеха проекта.

5.3. Принципы и методы интеграции информационных систем

В современном корпоративном ландшафте редкая информационная система существует в полной изоляции. Напротив, большинство организаций используют множество различных систем (ERP, CRM, BI, специализированные отраслевые решения), которые должны эффективно взаимодействовать друг с другом. Здесь на первый план выходит интеграция информационных систем.

Главная цель интеграции — создать единое информационное поле, где данные и функции различных систем доступны и могут быть использованы другими системами. Это позволяет избежать дублирования информации, повысить её актуальность, автоматизировать сквозные бизнес-процессы и улучшить общую оперативность компании.

Общие принципы, учитываемые в процессе интеграции систем:

• Гибкость: Интеграционное решение должно быть способно адаптироваться к изменяющимся требованиям бизнеса и технологическим изменениям.
• Масштабируемость: Способность интеграционной платформы или решения расти и обрабатывать все большие объемы данных и количество взаимодействий.
• Безопасность: Защита данных и каналов обмена информацией от несанкционированного доступа, перехвата или изменения.
• Управляемость: Возможность контролировать и отслеживать обмен данными между системами, мониторить работу интеграционных процессов.
• Модульность: Разработка интеграционных компонентов как независимых модулей, которые могут быть повторно использованы или заменены.
• Стабильность: Надежная работа интеграционного решения без сбоев и потери данных.

Типы интеграции по характеру взаимодействия:

1. Точечная (Point-to-Point) интеграция:
   • Сущность: Прямое соединение двух систем для обмена данными. Каждая пара систем имеет собственное уникальное соединение.
   • Преимущества: Простота реализации для небольшого количества систем.
   • Недостатки: При увеличении числа систем количество связей растет экспоненциально (по формуле n * (n-1) / 2), что приводит к «спагетти-архитектуре», сложной в управлении и сопровождении.
   • Применение: Для интеграции двух-трех систем, когда другие подходы избыточны.
2. Интеграция через шину (Enterprise Service Bus, ESB):
   • Сущность: Использование централизованного посредника (шины) для обмена сообщениями между системами. Системы взаимодействуют не напрямую, а через ESB, которая преобразует данные, маршрутизирует сообщения и управляет их потоками.
   • Преимущества: Уменьшает количество прямых связей, обеспечивает централизованное управление интеграцией, стандартизацию протоколов, возможность трансформации данных.
   • Недостатки: ESB может стать единой точкой отказа и бутылочным горлышком, требует специализированных навыков для настройки и поддержки.
   • Применение: Для интеграции среднего и большого количества систем в корпоративной среде.
3. Оркестровка процессов:
   • Сущность: Управление сложными, многошаговыми бизнес-процессами, которые охватывают несколько систем. Оркестратор координирует вызовы различных сервисов и систем в определенной последовательности.
   • Преимущества: Позволяет автоматизировать и контролировать сквозные бизнес-процессы, обеспечивает видимость и управляемость.
   • Недостатки: Высокая сложность реализации, требует четкого определения бизнес-процессов.
   • Применение: Для автоматизации комплексных процессов, таких как оформление заказа, онбординг клиента.
4. Событийно-ориентированная интеграция (Event-Driven Architecture, EDA):
   • Сущность: Системы обмениваются информацией путем публикации и подписки на события. Когда в одной системе происходит значимое событие (например, «заказ создан»), она публикует это событие в шину событий (message broker), а другие системы, заинтересованные в этом событии, подписываются на него и реагируют.
   • Преимущества: Высокая масштабируемость и отказоустойчивость, слабая связанность систем, асинхронное взаимодействие.
   • Недостатки: Сложность в отслеживании потоков данных и отладке, требует продуманной обработки идемпотентности (повторное выполнение операции не приводит к изменению результата).
   • Применение: Для распределенных систем, микросервисов, высоконагруженных систем, требующих реактивности.

Интеграция может связывать ИС с внешними источниками данных или сервисами, например, через внешние API (Application Programming Interface). Это позволяет системе взаимодействовать с платежными шлюзами, сервисами доставки, социальными сетями или другими сторонними приложениями.

Одним из ключевых факторов успешной интеграции является правильное управление данными, включающее определение единых стандартов для их хранения, передачи и обработки между системами. Это подразумевает создание общего глоссария терминов, согласование форматов данных, использование ETL-процессов (Extract, Transform, Load) для преобразования данных.

Таким образом, продуманное проектирование интеграционных решений является фундаментом для создания гибкой, масштабируемой и эффективной информационной экосистемы, способной поддерживать динамичные потребности современного бизнеса.

Заключение

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

Мы убедились, что успешное проектирование ИС невозможно без четкого понимания её сущности и жизненного цикла, а также без опоры на основные концепции системного анализа. Детальное рассмотрение структурного и объектно-ориентированного подходов, а также современных гибких методологий Agile и DevOps, подчеркнуло эволюцию инженерной мысли и адаптивность к меняющимся условиям. Особое внимание было уделено поэтапному процессу проектирования — от анализа требований до внедрения, с обоснованием значимости каждого шага для минимизации рисков и обеспечения успешной реализации проекта.

Глубокий анализ методов сбора, классификации и документирования требований, а также применение языков моделирования UML и DFD, показал, как абстрактные пожелания трансформируются в конкретные технические спецификации. Акцент на негативных последствиях игнорирования нефункциональных требований наглядно продемонстрировал их критическую важность для устойчивости и эффективности системы.

Наконец, детальное рассмотрение проектирования пользовательского интерфейса и баз данных, подкрепленное убедительными статистическими данными о влиянии UI/UX на бизнес-показатели и доминирующем положении реляционной модели данных, выявило, насколько эти компоненты определяют успех и долгосрочную ценность ИС. И, что не менее важно, мы подчеркнули роль обеспечения информационной безопасности, проектирования масштабируемых архитектур и принципов интеграции систем как фундаментальных столпов, обеспечивающих адаптивность, устойчивость и защищенность современных информационных решений.

Ключевые выводы проведенного исследования заключаются в следующем:

1. Комплексность: Проектирование ИС — это междисциплинарный процесс, требующий интеграции знаний из области системного анализа, программной инженерии, управления базами данных и бизнес-процессов.
2. Адаптивность: Современные методологии (Agile, DevOps) и архитектурные подходы (микросервисы) направлены на повышение гибкости и способности ИС к быстрой адаптации к меняющимся требованиям.
3. Качество и эффективность: Критерии качества (надежность, производительность, удобство использования) и экономическая эффективность должны быть заложены на этапе проектирования, а не рассматриваться как второстепенные задачи. Особое внимание к UI/UX и нефункциональным требованиям приносит значительные бизнес-выгоды.
4. Безопасность и устойчивость: Информационная безопасность, масштабируемость и эффективная интеграция являются не просто опциями, а обязательными атрибутами любой современной ИС, обеспечивающими её долгосрочную жизнеспособность.

Перспективы дальнейших исследований в области проектирования ИС огромны и тесно связаны с развитием новых технологий. Особый интерес представляют:

• Влияние искусственного интеллекта (ИИ) на проектирование ИС: Как ИИ может быть интегрирован в процесс проектирования для автоматизации анализа требований, генерации кода или оптимизации архитектуры.
• Проектирование систем для облачных вычислений и бессерверных архитектур: Исследование лучших практик и паттернов для создания высокодоступных, масштабируемых и экономически эффективных облачных ИС.
• Проектирование систем для Интернета вещей (IoT): Особенности сбора и обработки данных с большого количества устройств, вопросы безопасности и масштабируемости в IoT-экосистемах.
• Применение Low-code/No-code платформ в проектировании: Анализ того, как эти платформы меняют роли аналитиков и разработчиков, и их влияние на скорость и стоимость создания ИС.

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

Список использованной литературы

1. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем : учебник. Москва : Финансы и статистика, 2002.
2. Леоненков, А. Самоучитель UML. Санкт-Петербург : БХВ-Петербург, 2001.
3. Вендров, А.М. Практикум по проектированию программного обеспечения экономических информационных систем. Москва : Финансы и статистика, 2002.
4. Александров, Д.В., Грачев, И.В., Фадин, Д.Н. Case-технологии. Владимир : Изд-во Владим. гос. ун-та, 2006. 64 с.
5. Александров, Д.В. Системное моделирование бизнеса : учеб. пособие. Владимир : Изд-во Владим. гос. ун-та, 2004. 300 с.
6. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. Москва : Финансы и статистика, 2000. 556 с.
7. Голосов, А.А., Охрименко, П.В. Введение в информационный бизнес. Москва : Финансы и статистика, 2005. 592 с.
8. Костров А.В., Матвеев Д.А. Информационный менеджмент. Оценка эффективности ИС : учебное пособие. Владимир : ВлГУ, 2004. 116 с.
9. Мишенин, А.И. Теория экономических информационных систем. Москва : Финансы и статистика, 2003. 382 с.
10. Симонович, С.В. Специальная информатика. Москва : Инфорком-Пресс, 2000. 346 с.
11. Смирнова, Г.Н., Сорокин, А.А., Тельнов, Ю.Ф. Проектирование экономических информационных систем. Москва : Финансы и статистика, 2003. 512 с.
12. Титоренко, Г.А. Автоматизированные информационные технологии в экономике. Москва : Юнити, 2001. 416 с.
13. Структурный подход к проектированию ИС. URL: https://citforum.ru/consulting/articles/struct_approach/ (дата обращения: 25.10.2025).
14. Объектно-ориентированное проектирование ИС. URL: https://intuit.ru/studies/courses/2302/573/lecture/12059 (дата обращения: 25.10.2025).
15. Глава 16. Этапы проектирования ИС с применением UML. URL: https://intuit.ru/studies/courses/2302/573/lecture/12061 (дата обращения: 25.10.2025).
16. Проектирование интерфейсов: основные принципы, этапы и ошибки при разработке. URL: https://practicum.yandex.ru/blog/proektirovanie-interfeysov/ (дата обращения: 25.10.2025).
17. Проектирование систем информационной безопасности: основные этапы и особенности. URL: https://itaus.ru/articles/proektirovanie-sistem-informacionnoy-bezopasnosti-osnovnye-etapy-i-osobennosti/ (дата обращения: 25.10.2025).
18. Функциональные и нефункциональные требования — что это, как разработать, примеры требований. URL: https://practicum.yandex.ru/blog/functional-and-non-functional-requirements/ (дата обращения: 25.10.2025).
19. Типы интеграции информационных систем: классификация и характеристики. URL: https://decosystems.ru/blog/tipy-integratsii-informatsionnykh-sistem-klassifikatsiya-i-kharakteristiki (дата обращения: 25.10.2025).
20. Просто о сложном: что такое интеграция систем? URL: https://astanahub.com/article/prosto-o-slozhnom-chto-takoe-integraciya-sistem (дата обращения: 25.10.2025).
21. Модели проектирования баз данных. URL: https://www.youtube.com/watch?v=l_8p92s_9dM (дата обращения: 25.10.2025).
22. Масштабирование информационной системы. URL: https://struchkov.digital/scaling/ (дата обращения: 25.10.2025).
23. Значение построения UML диаграмм при моделировании информационных систем. URL: https://naubook.ru/znachenie-postroeniya-uml-diagramm-pri-modelirovanii-informacionnyx-sistem/ (дата обращения: 25.10.2025).
24. Методы и подходы к интеграции систем. URL: https://flexberry.ru/docs/fd_integration-approaches/ (дата обращения: 25.10.2025).
25. DFD: примеры и правила построения диаграмм потоков данных. URL: https://practicum.yandex.ru/blog/dfd-data-flow-diagram/ (дата обращения: 25.10.2025).
26. Основные принципы создания пользовательских интерфейсов (ПИ). URL: https://www.ncrdo.ru/news/osnovnye-principy-sozdaniya-polzovatelskih-interfejsov-pi/ (дата обращения: 25.10.2025).
27. Диаграмма потоков данных (DFD) для чайников: что это такое, как сделать и какой бывает. URL: https://habr.com/ru/companies/kaiten/articles/748118/ (дата обращения: 25.10.2025).
28. Что такое DFD (диаграммы потоков данных). URL: https://kinzyabulatov.ru/chto-takoe-dfd/ (дата обращения: 25.10.2025).
29. Статья. Использование DFD: как описать движение данных в бизнес-процессах. URL: https://infostart.ru/public/1930263/ (дата обращения: 25.10.2025).
30. Лекция 6. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ. URL: https://www.intuit.ru/studies/courses/1069/214/lecture/5533 (дата обращения: 25.10.2025).
31. Применение объектно-ориентированного подхода при проектировании информационной системы. URL: https://intuit.ru/studies/courses/2302/573/lecture/12060 (дата обращения: 25.10.2025).
32. Функциональные и нефункциональные требования (с примерами). URL: https://visuresolutions.com/ru/blog/functional-vs-non-functional-requirements-examples/ (дата обращения: 25.10.2025).
33. Основы моделирования баз данных с помощью Creately. URL: https://creately.com/ru/guides/data-modeling-tutorial/ (дата обращения: 25.10.2025).
34. Проектирование баз данных: основные этапы, методы и модели БД. URL: https://decosystems.ru/blog/proektirovanie-baz-dannykh-osnovnye-etapy-metody-i-modeli-bd (дата обращения: 25.10.2025).
35. Лекция 1. Введение в проектирование баз данных. URL: https://msuniversity.ru/lecture/1/ (дата обращения: 25.10.2025).
36. Проектируем ИБ-систему: нюансы и цели процесса. URL: https://www.anti-malware.ru/analytics/IT_Security_Management/Designing_IS_security_system_nuances_and_goals (дата обращения: 25.10.2025).
37. Интеграция между информационными системами: какая и зачем нужна. URL: https://xsud.ru/articles/integratsiya-mezhdu-informatsionnymi-sistemami-kakaya-i-zachem nuzhna/ (дата обращения: 25.10.2025).
38. Статья. Основы применения UML. Кто и как его использует. URL: https://infostart.ru/public/1090433/ (дата обращения: 25.10.2025).
39. Горячев, В.Ю. Принципы разработки пользовательских интерфейсов. URL: http://intsys.msu.ru/sites/default/files/goryachev-principles_ui_design-2015.pdf (дата обращения: 25.10.2025).
40. Безопасность информационных систем. URL: https://searchinform.ru/blog/bezopasnost-informatsionnyh-sistem/ (дата обращения: 25.10.2025).