Введение: Актуальность, цели и задачи исследования
В условиях нарастающей цифровой трансформации и глобальной конкуренции, разработка информационных систем, способных обеспечить эффективное взаимодействие территориально распределенных и сетевых пользователей, становится ключевым фактором экономического успеха. Актуальность настоящего исследования продиктована необходимостью поиска и систематизации современных методологий, архитектурных решений и стандартов, которые позволяют создавать масштабируемые, безопасные и высокопроизводительные веб-ориентированные ИС. Отход от устаревших каскадных моделей и переход к гибким, итеративным подходам, интегрированным с актуальными требованиями стандартизации (ГОСТ, ISO), формирует основу для успешного проектирования в 2025 году.
Цель работы: Разработать методологическую и проектную основу для создания современной Информационной Системы, предназначенной для сетевых пользователей, обеспечив ее соответствие актуальным стандартам и технологическим трендам.
Объектом исследования выступает процесс проектирования Информационной Системы.
Предметом исследования являются методологии, архитектурные паттерны, стандарты документирования и технологические решения, применяемые на этапах жизненного цикла ИС, ориентированной на сетевое взаимодействие.
Теоретические основы проектирования ИС и их жизненный цикл
Жизненный цикл (ЖЦ) ИС представляет собой фундаментальную концепцию в программной инженерии, определяющую совокупность стадий, которые система проходит от зарождения идеи до вывода из эксплуатации. Понимание структуры и классификации ИС является краеугольным камнем для выбора правильной методологии проектирования. Классический ЖЦ, включающий планирование, анализ требований (системный анализ), проектирование (логическое и физическое), реализацию, внедрение и эксплуатацию, служит необходимой базой, на которой строятся все современные гибкие модели.
Классификация и структура Информационных Систем
Информационные системы могут быть классифицированы по различным признакам, но для сетевых пользователей ключевое значение имеет классификация по масштабу и степени автоматизации.
По масштабу ИС подразделяются на три основных типа, что напрямую влияет на выбор архитектуры:
| Класс ИС | Описание и область применения | Требования к архитектуре |
|---|---|---|
| Однопользовательские (Настольные) | Работают на автономном ПК, не предполагают сетевого взаимодействия. Используются для личных или узконаправленных задач. | Локальное хранение данных, монолитное приложение. |
| Групповые (Офисные) | Ориентированы на коллективное использование данных членами рабочей группы (5-20 человек). Строятся на базе Локальной Вычислительной Сети (ЛВС) с использованием SQL-серверов. | Архитектура «файл-сервер» или «клиент-сервер» (двухзвенная). |
| Корпоративные (КИС) | Поддерживают работу крупных компаний, часто территориально разнесенных. Требуют высокой отказоустойчивости, масштабируемости и интеграции. | Многоуровневая (многозвенная) архитектура, SOA, Микросервисы. |
По степени автоматизации ИС делятся на:
- Ручные: Операции выполняются человеком без современных технических средств.
- Автоматические: Все операции выполняются техническими средствами (например, станки с ЧПУ) без участия человека.
- Автоматизированные (АИС): Совместное участие человека и технических средств, где машина выполняет рутинные и расчетные задачи, а человек принимает ключевые решения. Большинство современных ИС, включая веб-ориентированные системы для сетевых пользователей, относятся именно к АИС.
Системный анализ как основа предпроектной стадии
Системный анализ является критически важной предпроектной стадией, которая определяет успех всего проекта. Его цель — не просто собрать пожелания заказчика, а сформулировать действительную потребность в новой ИС, проанализировать существующие бизнес-процессы и, самое главное, определить экономическую обоснованность проектирования. На этой стадии проводится глубокое исследование предметной области, выявление узких мест в текущей системе (если она существует) и формализация требований.
Ключевые результаты системного анализа:
- Определение границ системы: Четкое понимание того, что войдет в ИС, а что останется за ее пределами.
- Анализ рисков: Идентификация потенциальных технологических, ресурсных и организационных рисков.
- Разработка Технического Задания (ТЗ): Конечным и наиболее важным результатом системного анализа является разработка ТЗ. Этот документ отражает все технические условия, функциональные и нефункциональные требования к ИС, а также ограничения на ресурсы, сроки и стоимость проектирования.
ТЗ служит юридическим и техническим основанием для дальнейшей разработки, а его структура и содержание должны строго соответствовать национальным стандартам (в РФ — ГОСТ 34.602-2020). Отсутствие формализованного ТЗ, даже при использовании гибких методологий, многократно увеличивает вероятность расхождения ожиданий заказчика и конечного результата.
Актуальные методологии разработки и приоритизации в 2025 году
Выбор методологии определяет не только порядок выполнения работ, но и философию управления проектом. Классические методологии, такие как RUP (Rational Unified Process), основанные на спиральной модели, остаются актуальными для крупных, высокорисковых проектов с четко заданными требованиями. Однако для веб-ориентированных ИС, требующих быстрой адаптации к меняющимся потребностям сетевых пользователей, доминирующей силой являются гибкие (Agile) подходы.
Трансформация Agile: Scrum 3.0 и роль ИИ
Agile-методологии, в частности Scrum, продолжают эволюционировать, адаптируясь к вызовам 2025 года. Наблюдается тренд, который можно назвать Scrum 3.0, характеризующийся активной интеграцией искусственного интеллекта (ИИ) в процесс управления проектом. ИИ перестает быть просто инструментом и становится «ассистентом» Scrum-мастера и команды.
Роль ИИ в современном Scrum:
- Прогнозирование и оценка (Story Points): ИИ анализирует исторические данные прошлых спринтов (скорость, отклонения, сложность задач), предоставляя более точные прогнозы по срокам выполнения и более объективные оценки трудоемкости (Story Points), минимизируя субъективизм человеческой оценки.
- Динамическая корректировка бэклога: Инструменты ИИ могут автоматически анализировать обратную связь от пользователей, рыночные тренды и технические зависимости, предлагая оптимальные перестановки в бэклоге продукта, что обеспечивает его динамическую корректировку.
- Автоматизация рутинного управления: ИИ берет на себя рутинные задачи Scrum-мастера, такие как планирование встреч, отслеживание хода спринта, выявление и ранжирование потенциальных «блокеров» и проблем до того, как они станут критическими.
Гибкие методологии в 2025 году также активно трансформируются в гибридные модели, где Agile используется для разработки минимально жизнеспособного продукта (MVP) и итеративных улучшений, а каскадный подход (Waterfall) сохраняется для строго регламентированных этапов (например, сертификация, регуляторная документация). Эти гибриды, в свою очередь, интегрируются в сквозные DevOps-цепочки (Development, Security, Operations), что позволяет добиться непрерывной поставки ценности.
Количественная приоритизация требований в гибких проектах
В условиях быстро меняющегося бэклога и ограниченных ресурсов, критически важной задачей становится объективная приоритизация требований. Традиционный качественный метод MoSCoW позволяет разделить требования на категории. Однако для точного ранжирования внутри категории, особенно в крупных масштабируемых проектах, необходимы количественные метрики.
Для приоритизации в рамках Scaled Agile Framework (SAFe) активно используется модель WSJF (Weighted Shortest Job First) — «Сначала Более Ценная и Короткая Работа». Этот метод позволяет максимизировать экономический эффект, выполняя работы с самой высокой стоимостью задержки и наименьшей длительностью. Использование WSJF позволяет команде всегда концентрироваться на задачах, которые приносят наибольший финансовый или стратегический вклад.
Формула расчета приоритета WSJF:
WSJF = Стоимость Задержки (СЗ) / Размер Работы (РР)
Где Стоимость Задержки (СЗ) рассчитывается как сумма трех ключевых параметров:
СЗ = Ценность для пользователей/бизнеса + Критичность по времени + Снижение рисков/Открытие возможностей
А Размер Работы (РР) заменяет Оценку длительности/трудоемкости.
| Компонент WSJF | Описание |
|---|---|
| Ценность для бизнеса | Какую финансовую или стратегическую выгоду принесет завершение данной функции. |
| Критичность по времени | Как быстро утрачивается ценность, если работа не будет выполнена немедленно (например, соблюдение регуляторных сроков). |
| Снижение рисков/Возможности | Насколько выполнение задачи снизит технические риски или откроет новые рыночные возможности. |
| Оценка длительности (Размер Работы) | Оценка трудоемкости выполнения задачи (используются условные единицы, например, Story Points). |
Чем выше итоговое значение WSJF, тем выше приоритет задачи в бэклоге. Этот подход гарантирует, что команда всегда работает над тем, что приносит максимальную ценность в кратчайшие сроки.
Формализация требований и моделирование (Системный анализ)
Качество проектирования ИС напрямую зависит от того, насколько точно и полно были сформулированы требования. Требования делятся на функциональные и нефункциональные, и обе категории должны быть формализованы с использованием общепринятых нотаций и стандартов.
Функциональные и нефункциональные требования (ФТ и НФТ)
Функциональные требования (ФТ) описывают, что система должна делать. Это конкретные функции, действия и операции, которые система выполняет для пользователя или для себя. Примеры: «Система должна позволять сетевому пользователю регистрироваться через MFA», «Система должна генерировать ежемесячный отчет о транзакциях».
Нефункциональные требования (НФТ) описывают, как система выполняет свои функции, то есть ее качественные атрибуты. Для сетевых ИС НФТ часто являются более критичными, чем ФТ, так как определяют масштабируемость и устойчивость к нагрузкам.
Для формальной классификации и оценки НФТ в академической работе необходимо опираться на международные стандарты, в частности, на ISO/IEC 25000 (SQuaRE), а точнее на ISO/IEC 25010, который определяет 8 основных характеристик качества ПО. Почему нефункциональные требования так важны? Потому что именно они определяют, выдержит ли система реальную нагрузку и насколько она будет защищена от внешних угроз.
| Характеристика (ISO/IEC 25010) | Описание (Пример для сетевой ИС) |
|---|---|
| Надежность | Способность системы поддерживать заданный уровень производительности в определенных условиях. Включает Возобновляемость и Устойчивость к сбоям. Пример: Доступность системы 99.9% рабочего времени. |
| Исполнительная эффективность | Реакция системы на объемы ресурсов, время отклика и пропускную способность. Пример: Обработка не менее 1000 запросов в секунду при пиковой нагрузке. |
| Безопасность | Защита информации и данных. Включает Конфиденциальность, Целостность. Пример: Использование 256-битного шифрования для всех передаваемых данных. |
| Масштабируемость | Способность системы эффективно адаптироваться к росту нагрузки или объема данных. |
В курсовой работе необходимо не просто перечислить НФТ, но и указать конкретные измеримые метрики (например, с использованием критерия SMART), что соответствует строгим требованиям технической документации.
Интегрированный подход к моделированию
Моделирование является методом визуализации и формализации требований, предотвращающим ошибки на ранних этапах. Эффективный системный анализ использует комбинированный подход, сочетая несколько нотаций:
- UML (Unified Modeling Language): Унифицированный язык моделирования является стандартом для объектно-ориентированного проектирования. Он незаменим для описания логики системы, поведения пользователей (диаграммы вариантов использования), структуры классов и взаимодействия компонентов (диаграммы последовательности).
- DFD (Data Flow Diagrams): Диаграммы потоков данных используются для описания движения информации в системе и ее трансформации, что важно для анализа данных в бизнес-процессах.
- IDEF0 (Integration Definition for Function Modeling): Нотация функционального моделирования, хотя и считается классической, сохраняет актуальность в российских проектах, где требуется детальная функциональная декомпозиция системы «сверху-вниз» и соблюдение отечественных стандартов. IDEF0 позволяет построить иерархию функций и их взаимосвязей с входными/выходными данными, механизмами и управляющими воздействиями.
Интегрированный подход позволяет сначала провести высокоуровневую функциональную декомпозицию (IDEF0), затем описать логику работы системы и взаимодействие объектов (UML) и, наконец, проанализировать информационные потоки (DFD), обеспечивая полноту системного анализа.
Архитектурные паттерны для масштабируемых сетевых ИС
Для сетевых пользователей критически важна способность ИС обрабатывать большое количество одновременных запросов и легко масштабироваться. Современные веб-ориентированные системы почти полностью отошли от классических монолитов, отдав предпочтение сервис-ориентированным подходам.
Микросервисная архитектура и паттерн «База данных на сервис»
Сервис-ориентированная архитектура (SOA) стала предшественником Микросервисной архитектуры. SOA строится на крупных, слабо связанных сервисах, часто использующих общую централизованную базу данных. Микросервисы пошли дальше. Микросервисная архитектура — это метод разработки, при котором приложение строится как набор небольших, независимых, автономно развертываемых сервисов, каждый из которых отвечает за одну бизнес-функцию.
Преимущества микросервисов:
- Независимое развертывание: Каждый сервис может обновляться и развертываться независимо, минимизируя риск сбоя всей системы.
- Технологическое разнообразие (Полиглотность): Разные сервисы могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.
- Масштабируемость: Можно масштабировать только тот сервис, который находится под нагрузкой, экономя ресурсы.
Ключевым архитектурным паттерном, обеспечивающим автономность микросервисов, является «База данных на сервис» (Database Per Service).
| Паттерн | Описание | Роль в ИС |
|---|---|---|
| База данных на сервис | Каждый микросервис владеет своей собственной (логически разделенной) базой данных. Доступ к данным другого сервиса возможен только через его API. | Обеспечивает полную изоляцию данных, устраняя сильные зависимости между сервисами. Позволяет использовать полиглот-персистентность (например, сервис управления пользователями использует NoSQL, а сервис учета транзакций — SQL). |
Использование этого паттерна критически важно для создания действительно масштабируемой и надежной сетевой ИС, так как устраняет единую точку отказа и «бутылочное горлышко» в виде централизованной СУБД.
Мультиагентные Системы (МАС) в корпоративной оркестрации
Для решения сложных, распределенных задач и автоматизации сложных бизнес-процессов в рамках крупных корпоративных ИС (КИС) все чаще применяются Мультиагентные Системы (МАС). МАС — это совокупность автономных, взаимодействующих между собой ИИ-агентов, каждый из которых обладает определенными знаниями и способностью к принятию решений. Они совместно решают задачи, которые были бы слишком сложны для одного централизованного сервиса.
Применение МАС в сетевых ИС:
- Оркестрация DevOps: Агенты могут автономно управлять сложными цепочками развертывания, мониторинга и самовосстановления микросервисов.
- Автоматизация поддержки клиентов: Распределенные агенты могут обрабатывать запросы пользователей, маршрутизировать их, анализировать историю и предоставлять решения, действуя как единый, но распределенный, интеллектуальный помощник.
- Оптимизация ресурсов: В КИС агенты могут динамически перераспределять вычислительные ресурсы между подсистемами в зависимости от текущей нагрузки и приоритетов.
МАС позволяют добавить в архитектуру ИС адаптивность, самоорганизацию и повышенную отказоустойчивость, что является перспективным направлением для веб-ориентированных систем в 2025 году. Какова же практическая ценность этих систем для конечного пользователя?
Стандартизация, Документация и Практическая реализация
Академический проект по ИС не может считаться завершенным без надлежащего оформления технической документации. В Российской Федерации это требует строгого соблюдения государственных стандартов (ГОСТ).
Требования к Техническому заданию согласно ГОСТ
Несмотря на активное использование гибких методологий, которые часто избегают избыточной документации, формальное Техническое задание (ТЗ) остается обязательным элементом для курсовых и дипломных работ, а также для государственных контрактов.
Ключевые стандарты документации:
- ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
Данный стандарт введен взамен ГОСТ 34.602-89 и является основным документом, регламентирующим структуру и содержание ТЗ. ТЗ должно содержать разделы, детально описывающие назначение системы, требования к функциям, виды обеспечения (программное, информационное, техническое) и требования к безопасности.
- ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем».
Этот стандарт определяет полный перечень документов, которые должны разрабатываться на разных стадиях ЖЦ ИС (например, Пояснительная записка, Программа и методика испытаний, Описание базы данных).
Международный стандарт ГОСТ Р ИСО/МЭК 12207—2010 (адаптация ISO/IEC 12207) регламентирует общую структуру процессов жизненного цикла программных средств, дополняя отечественные ГОСТы в части управления проектом и качеством.
Этапы практической реализации и прототипирования
Практическая часть курсовой работы (прототипирование) является логическим продолжением теоретического проектирования.
Основные этапы реализации:
- Разработка логической и физической модели данных: На основе требований создается схема базы данных (БД). Для сетевой ИС чаще всего используется реляционная СУБД (например, PostgreSQL, MySQL) для критических данных и, возможно, NoSQL-хранилища для неструктурированных данных (полиглот-персистентность).
- Кодирование (Разработка компонентов): В веб-ориентированных ИС используется архитектура «клиент-сервер». Серверная часть (backend) реализует бизнес-логику и API (например, на Python/Django или Java/Spring), а клиентская часть (frontend) — пользовательский интерфейс (например, на React или Vue.js).
- Интеграция и тестирование: Компоненты ИС объединяются, и проводится модульное, интеграционное и системное тестирование.
- Опытная эксплуатация: Прототип ИС развертывается, и проводится ограниченное тестирование с участием сетевых пользователей для выявления скрытых ошибок и проверки соответствия нефункциональным требованиям (например, времени отклика).
Результатом практической части должно стать не только описание кода, но и демонстрация того, как выбранные архитектурные паттерны (например, реализация API для обмена данными между клиентской и серверной частью) обеспечивают масштабируемость и соответствие требованиям.
Обеспечение Информационной Безопасности в сетевой ИС
В сетевых ИС, где данные передаются через открытые каналы связи и хранятся централизованно, информационная безопасность (ИБ) является не просто требованием, а обязательным условием функционирования. Внедрение ИБ должно быть интегрировано с самого начала проектирования, а не добавлено в конце.
Актуальные меры защиты учетных записей
В 2025 году недостаточно просто требовать «сложный пароль». Современные атаки на учетные записи делают обязательным внедрение продвинутых мер защиты:
- Многофакторная Аутентификация (MFA/2FA): Это критически важный барьер. Пользователь должен подтверждать свою личность не менее чем двумя независимыми факторами (например, пароль + код из SMS или биометрия). Внедрение MFA должно быть обязательным нефункциональным требованием для всех сетевых ИС.
- Парольные фразы и менеджеры паролей: Акцент смещается от принудительной регулярной смены коротких паролей к использованию длинных парольных фраз (10–12 символов и более), которые сложнее подобрать.
- Принцип наименьших привилегий (Principle of Least Privilege): Сетевые пользователи должны иметь доступ только к тем данным и функциям, которые необходимы им для выполнения своих непосредственных обязанностей, что минимизирует ущерб в случае компрометации учетной записи.
Отраслевые стандарты защиты информации
Для критически важных сетевых систем (например, финансовых, государственных) необходимо ссылаться на национальные стандарты, определяющие базовый состав организационных и технических мер защиты.
ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер».
Хотя этот стандарт напрямую адресован финансовому сектору, его принципы и требования применимы ко всем сетевым ИС, обрабатывающим конфиденциальные данные. Он описывает три уровня защиты (усиленный, стандартный, минимальный) и требует выполнения следующих ключевых мер:
- Защита сетевой инфраструктуры: Сегментация сети, использование межсетевых экранов.
- Управление доступом: Строгий контроль прав, применение MFA, регулярный аудит доступа.
- Защита от вредоносного кода: Применение антивирусных систем и средств обнаружения вторжений.
Включение ссылки на ГОСТ Р 57580.1-2017 в курсовую работу демонстрирует глубокое понимание не только технических, но и регуляторных требований к современным сетевым ИС.
Заключение
Проектирование современной Информационной Системы для сетевых пользователей в 2025 году требует синтеза передовых методологий, актуальных архитектурных решений и строгого следования стандартам. Проведенный анализ подтверждает, что успех проекта ИС критически зависит от качества предпроектной стадии, формализованной в соответствии с ГОСТ 34.602-2020.
При этом, для обеспечения скорости разработки и адаптивности, целесообразно использовать гибкие подходы, трансформированные с учетом ИИ-инструментов (Scrum 3.0), и опираться на количественную приоритизацию (WSJF). В архитектурном плане, масштабируемость и отказоустойчивость достигаются за счет Микросервисной архитектуры с применением паттерна «База данных на сервис» и, в сложных корпоративных системах, за счет интеграции Мультиагентных Систем для оркестрации.
Практическая значимость разработанного мастер-плана заключается в том, что он предоставляет студенту не шаблонное, а методологически корректное и технологически передовое руководство, позволяющее создать прототип ИС, который не только соответствует функциональным требованиям, но и отвечает высоким стандартам ISO/IEC 25010 в части надежности и производительности, а также требованиям ГОСТ Р 57580.1-2017 в части информационной безопасности, включая обязательное использование Многофакторной Аутентификации. Все эти факторы необходимо учитывать, если мы хотим, чтобы наша система оставалась конкурентоспособной в долгосрочной перспективе.
Список использованной литературы
- Смирнов И.Н. и др. Основные СУБД. – М.: Наука, 1999. – 320 с.
- Смирнова Г.Н. и др. Проектирование экономических информационных систем: Учебник / Под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2002. – 512 с.
- Григорьев П.Н. Работа с Access 2000. – СПб.: Корона, 2004. – 180 с.
- Маклаков С.В. BPwin и Erwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ–МИФИ, 2004.
- Хомоненко А.Д. и др. Базы данных: Учебник для вузов / Под ред. проф. А.Д. Хомоненко. – СПб.: КОРОНА принт, 2004. – 736 с.
- Пенова И.П. MS Access для начинающих. – Москва: Вильямс, 2008. – 213 с.
- Шабунин А.Н., Макаров А.А. О проектировании информационной системы инспекционно-досмотрового комплекса // Cyberleninka.ru. 2014.
- СОВРЕМЕННЫЕ МЕТОДИКИ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ // urfu.ru. 2015.
- Тарасьев А. А., Спиричева Н. Р. Сравнительный анализ методологий проектирования на примере разработки системы документооборота больницы // Fundamental-research.ru. 2017.
- О стандартах документации // Docplace.ru. 2017.
- Ермаков А.С. ПЕРСПЕКТИВНОЕ РАЗВИТИЕ МЕТОДОЛОГИИ DEVOPS // cyberleninka.ru. 2020.
- ГОСТ Р 59215-2020 Информационные технологии. Методы и средства обеспечения безопасности. Информационная безопасность во взаимоотношениях с поставщиками // docs.cntd.ru. 2020.
- Паттерны микросервисов: полный и структурированный список для разработчиков // vk.com. 2021.
- ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ И ЗАЩИТА ИНФОРМАЦИИ В СОВРЕМЕННОМ ОБЩЕСТВЕ // w-science.com : [сайт]. 2022.
- Проектирование информационных систем // kchgu.ru. 2024.
- В чем разница между сервис-ориентированной архитектурой и микросервисами? // timeweb.cloud. 2024.
- ТОП-10 методологий разработки ПО в 2025: Agile, DevOps и другие тренды // fortech.dev. 2025.
- Функциональные и нефункциональные требования к ПО: что важно знать // skillfactory.ru. 2025.
- Микросервисная архитектура: чем она хороша и кому нужна // cloud.ru. 2025.
- Информационная безопасность (тренды) // tadviser.ru. 2025.
- Жизненный цикл информационной системы // kgau.ru : [сайт]. URL: [дата обращения 24.10.2025].
- АНАЛИЗ ТРЕБОВАНИЙ К ИНФОРМАЦИОННЫМ СИСТЕМАМ // ivan-shamaev.ru : [сайт]. URL: [дата обращения 24.10.2025].
- Перечень стандартов в области информационных технологий и защиты информации // xn--80aaiduub8a.xn--p1acf : [сайт]. URL: [дата обращения 24.10.2025].
- SOA и микросервисы: разница между архитектурными стилями // amazon.com : [сайт]. URL: [дата обращения 24.10.2025].