Kitabı oxu: «Проектирование архитектуры информационных систем»

Редактор Марина Андреевна Старосельская

© Арсентий Александрович Красильников, 2026

© Евгений Александрович Лубышев, 2026

© Георгий Иванович Журавлев, 2026

ISBN 978-5-0071-2540-6

Создано в интеллектуальной издательской системе Ridero

Предисловие

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

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

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

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

Отдельное внимание уделяется современной организации проектной деятельности. Рассматриваются гибкие подходы, Lean, Scrum, Kanban, DevOps и связанные с ним практики, а также автоматизация процессов разработки, интеграции, тестирования, поставки и эксплуатации. Показано значение управления версиями, непрерывной интеграции и поставки, инфраструктуры как кода, контейнеризации, оркестрации, наблюдаемости и управления инцидентами. Наряду с этим рассматриваются DevSecOps, GitOps, DataOps, MLOps, AIOps, Platform Engineering и другие направления, отражающие современное развитие инженерных практик. Вопрос выбора технологического стека связывается с архитектурой, требованиями, ограничениями и условиями эксплуатации, а не сводится к подбору отдельных популярных инструментов.

В книге также подробно рассматриваются технологии и методы непосредственного проектирования информационного и программного обеспечения. Раскрываются возможности CASE-средств, прототипного проектирования и RAD-технологий, объектно-ориентированного подхода и языка UML. Анализируются диаграммы вариантов использования, классов, состояний, компонентов, последовательности и другие средства моделирования, позволяющие описывать структуру и поведение проектируемой системы. Паттерны проектирования рассматриваются как обобщенные способы решения повторяющихся проектных задач и как средство формирования общего профессионального языка при обсуждении программной архитектуры.

Особое место занимают структурные методы анализа и проектирования. SADT и IDEF0 используются для функционального представления системы и последовательной декомпозиции ее деятельности; модели AS-IS и TO-BE позволяют перейти от исследования существующего состояния к проектированию целевого; реинжиниринг бизнес-процессов рассматривается как средство не только автоматизации, но и содержательного преобразования деятельности. IDEF3 применяется для описания последовательностей и сценариев процессов, DFD — для моделирования движения и преобразования информации, а IDEF1X и основы реляционного моделирования — для формирования согласованной структуры данных. Рассмотрение этих методов завершается их совместным применением на комплексных примерах, что позволяет показать взаимосвязь функциональных, процессных, информационных и программных представлений системы.

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

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

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

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

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

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

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

1. Введение в проектирование архитектуры информационной системы

Информационная система является одним из ключевых элементов современной организации, предприятия, государственного учреждения, образовательной структуры, медицинской организации, банка, торговой компании или цифровой платформы. Практически любая деятельность, связанная с накоплением, обработкой, передачей, хранением и использованием информации, в настоящее время осуществляется с применением информационных систем. При этом информационная система представляет собой не только совокупность компьютерных программ. Она включает данные, программное обеспечение, технические средства, пользователей, организационные процедуры, правила работы, средства связи и механизмы управления. В широком смысле информационная система представляет собой организованную совокупность взаимосвязанных элементов, предназначенных для сбора, регистрации, хранения, обработки, поиска, передачи, анализа и представления информации, необходимой для выполнения определенных функций и достижения поставленных целей. Информационная система существует не сама по себе, а в рамках некоторой предметной области. Такой предметной областью может быть банковская деятельность, электронная торговля, управление университетом, медицинское обслуживание, промышленное производство, транспортная логистика, государственное управление, бухгалтерский учет, управление персоналом или любая другая деятельность, в которой требуется систематическая работа с информацией. В российском законодательстве информационная система определяется как совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств. Такое определение подчеркивает три базовых компонента: информацию, информационные технологии и технические средства. Однако с точки зрения проектирования реальных информационных систем этого определения недостаточно, поскольку необходимо учитывать пользователей, бизнес-процессы, организационную структуру, нормативные ограничения, регламенты доступа, способы эксплуатации и сопровождения системы. Например, информационная система университета может включать базу данных студентов, преподавателей, учебных планов, дисциплин и оценок; программные модули для формирования расписания, учета успеваемости и регистрации на учебные курсы; серверы, сетевое оборудование и пользовательские компьютеры; личные кабинеты студентов и преподавателей; правила внесения и изменения данных; процедуры зачисления, перевода и отчисления обучающихся; механизмы защиты персональных данных; средства интеграции с бухгалтерскими, библиотечными и государственными системами. Если рассматривать только программный код, невозможно получить полное представление о такой системе. Основным назначением информационной системы является информационная поддержка деятельности. Это означает, что система должна предоставлять пользователям достоверную, актуальную и необходимую информацию в нужное время и в удобной форме. Кроме того, информационная система может автоматизировать операции, контролировать выполнение процессов, поддерживать принятие решений, обеспечивать взаимодействие между подразделениями, формировать отчетность, прогнозировать события и управлять ресурсами. В структуре информационной системы обычно выделяются несколько взаимосвязанных видов обеспечения. Информационное обеспечение включает данные, документы, классификаторы, справочники, модели данных, правила кодирования и способы организации информационных потоков. Программное обеспечение включает программы, сервисы, приложения, операционные системы, системы управления базами данных и вспомогательные программные средства. Техническое обеспечение представляет собой серверы, рабочие станции, устройства хранения данных, сетевое оборудование, периферийные устройства и телекоммуникационные средства. Организационное обеспечение включает структуру управления системой, распределение обязанностей, регламенты работы, процедуры эксплуатации и сопровождения. Правовое обеспечение охватывает нормативные акты, договоры, требования к защите информации, персональных данных и интеллектуальной собственности. Лингвистическое обеспечение связано с языками взаимодействия, терминологией, классификаторами и способами представления информации. Методическое обеспечение включает инструкции, методики, правила выполнения операций и рекомендации по использованию системы. Следовательно, информационная система является социотехнической системой, поскольку объединяет технические компоненты и деятельность людей. Даже самая совершенная программа не сможет эффективно выполнять свои функции, если не определены роли пользователей, правила внесения данных, ответственность за их достоверность, порядок обработки ошибок и процедуры принятия решений.

1.1 Понятие архитектуры информационной системы

Для понимания принципов проектирования информационных систем необходимо раскрыть понятие архитектуры. В общем смысле архитектура определяет фундаментальную организацию системы, ее основные элементы, связи между ними, принципы взаимодействия и правила дальнейшего развития. Архитектура показывает не только то, из каких частей состоит система, но и то, почему эти части выделены именно таким образом, какие функции они выполняют, как взаимодействуют и какие ограничения должны соблюдаться. Архитектура информационной системы представляет собой совокупность фундаментальных решений относительно структуры системы, ее компонентов, данных, функций, интерфейсов, технологий, способов взаимодействия, развертывания, эксплуатации и развития. Архитектура связывает потребности организации с конкретными техническими и программными решениями. Архитектуру нельзя сводить к одной схеме. Она включает множество взаимосвязанных аспектов. С одной стороны, необходимо описать функции системы и процессы, которые она поддерживает. С другой стороны, требуется определить структуру данных, программные компоненты, техническую инфраструктуру, механизмы интеграции и способы обеспечения безопасности. По этой причине архитектура информационной системы обычно представляется в виде набора моделей и архитектурных представлений. Архитектура отвечает на ряд принципиальных вопросов. Необходимо определить, какие задачи решает система, какие группы пользователей с ней взаимодействуют, какие данные она обрабатывает, из каких подсистем и компонентов состоит, какие интерфейсы используются, каким образом осуществляется взаимодействие между компонентами, где размещаются программные модули и данные, какие технологии применяются, как обеспечиваются производительность, надежность, масштабируемость, безопасность и сопровождаемость. Например, при проектировании информационной системы интернет-магазина требуется определить, будут ли каталог товаров, корзина, оформление заказов, платежи, управление складом и доставка реализованы в одном приложении или в виде отдельных сервисов. Необходимо решить, будет ли использоваться единая база данных или несколько специализированных хранилищ, каким образом система будет взаимодействовать с платежными организациями, службами доставки и учетной системой предприятия, как будет выполняться масштабирование в периоды высокой нагрузки и каким образом будут защищаться персональные и платежные данные пользователей. Архитектурное решение представляет собой выбор, оказывающий существенное влияние на структуру системы, ее свойства и развитие. К архитектурным решениям относятся выбор архитектурного стиля, способ разбиения системы на компоненты, выбор централизованного или распределенного хранения данных, определение способов взаимодействия между подсистемами, выбор технологий интеграции, механизмов безопасности и стратегии развертывания. Некоторые решения легко изменить на поздних этапах разработки, а другие требуют значительных затрат. Например, изменение цвета кнопки в интерфейсе обычно не является архитектурным решением. Переход от централизованной базы данных к распределенному хранению данных, напротив, затрагивает множество компонентов, влияет на целостность данных, транзакции, безопасность и сопровождение, поэтому относится к архитектурным решениям. Проектирование архитектуры информационной системы представляет собой процесс формирования и обоснования архитектурных решений. Этот процесс начинается с изучения целей организации, предметной области, требований заинтересованных сторон и ограничений проекта. Затем определяются основные функции, данные, подсистемы, интерфейсы, технологии и способы развертывания. Полученная архитектура анализируется с точки зрения соответствия функциональным требованиям и требуемым характеристикам качества. Архитектура должна учитывать не только текущие задачи, но и возможное развитие системы. Если архитектура рассчитана исключительно на существующую нагрузку и не допускает расширения, система может быстро перестать соответствовать потребностям организации. Поэтому при проектировании необходимо оценивать перспективы увеличения числа пользователей, объема данных, количества функций, числа интеграций и уровня требований к безопасности. Архитектура выполняет несколько функций. Организационная функция заключается в разделении сложной системы на понятные части. Коммуникационная функция состоит в создании общего представления о системе для заказчиков, аналитиков, разработчиков, администраторов и руководителей. Техническая функция связана с выбором способов реализации требований. Управленческая функция позволяет оценивать трудоемкость, риски, ресурсы и последовательность разработки. Эволюционная функция определяет направления изменения и развития системы. Качественная архитектура должна обеспечивать достижение требуемых характеристик системы. К таким характеристикам относятся производительность, масштабируемость, надежность, доступность, безопасность, удобство сопровождения, модифицируемость, тестируемость, совместимость, переносимость и удобство использования. Эти характеристики часто называют атрибутами качества. Например, для банковской информационной системы особенно важны безопасность, целостность данных, доступность и возможность аудита операций. Для видеоплатформы критическое значение имеют масштабируемость, производительность и устойчивость к высоким нагрузкам. Для небольшой внутренней системы учета может быть важнее простота разработки и сопровождения. Следовательно, не существует одной архитектуры, одинаково подходящей для всех систем. Архитектурные решения выбираются с учетом целей, масштаба, рисков и ограничений конкретного проекта.

1.1.1 Заинтересованные стороны и архитектурно значимые требования

Архитектура формируется не изолированно, а с учетом интересов различных участников, которых называют заинтересованными сторонами. К ним относятся заказчики, пользователи, владельцы бизнес-процессов, разработчики, архитекторы, системные администраторы, специалисты по информационной безопасности, тестировщики, руководители организации, контролирующие органы и внешние партнеры. У каждой группы имеются собственные интересы. Руководство заинтересовано в снижении затрат, повышении эффективности и управляемости. Пользователи ожидают удобства, понятности и быстрого выполнения операций. Разработчики заинтересованы в четкой структуре, тестируемости и возможности внесения изменений. Администраторы требуют наблюдаемости, надежности и простоты развертывания. Специалисты по безопасности обращают внимание на контроль доступа, аудит, защиту каналов связи и данных. Архитектура должна учитывать эти интересы и находить компромиссы между ними. Требования, оказывающие существенное влияние на архитектуру, называются архитектурно значимыми требованиями. Они могут быть функциональными и нефункциональными. Функциональные требования определяют, что должна делать система. Нефункциональные требования определяют, каким образом и с какими характеристиками система должна выполнять свои функции. Например, требование «система должна позволять пользователю оформить заказ» является функциональным. Требование «95% операций оформления заказа должны завершаться не более чем за две секунды» относится к производительности. Требование «система должна выдерживать не менее десяти тысяч одновременных пользователей» относится к масштабируемости. Требование «система должна сохранять работоспособность при отказе одного сервера» связано с надежностью и доступностью. Требование «доступ к медицинским данным должен предоставляться только уполномоченным сотрудникам» относится к безопасности. Архитектор должен выявить такие требования на ранних этапах, поскольку именно они определяют структуру будущей системы. Если требование к высокой доступности обнаруживается только после создания приложения, может потребоваться серьезная переработка механизмов хранения данных, развертывания и обработки отказов.