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

авторы Арсентий Александрович Красильников, Евгений Лубышев, Георгий Журавлев

Оглавление

Предисловие

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

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

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

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

Отдельное внимание уделяется современной организации проектной деятельности. Рассматриваются гибкие подходы, 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% операций оформления заказа должны завершаться не более чем за две секунды» относится к производительности. Требование «система должна выдерживать не менее десяти тысяч одновременных пользователей» относится к масштабируемости. Требование «система должна сохранять работоспособность при отказе одного сервера» связано с надежностью и доступностью. Требование «доступ к медицинским данным должен предоставляться только уполномоченным сотрудникам» относится к безопасности. Архитектор должен выявить такие требования на ранних этапах, поскольку именно они определяют структуру будущей системы. Если требование к высокой доступности обнаруживается только после создания приложения, может потребоваться серьезная переработка механизмов хранения данных, развертывания и обработки отказов.

1.2 Классификация информационных систем

Классификация информационных систем необходима для систематизации их многообразия. Информационные системы могут различаться по назначению, масштабу, уровню управления, степени автоматизации, характеру обработки данных, архитектуре, режиму работы, сфере применения и другим признакам. Одна и та же система может одновременно относиться к нескольким классам. По масштабу применения выделяются персональные, групповые, корпоративные, межорганизационные, государственные и глобальные информационные системы. Персональная информационная система предназначена для поддержки деятельности одного пользователя. Примерами являются персональный планировщик, программа ведения личных финансов, локальная база контактов или индивидуальная система учета документов. Групповая информационная система используется ограниченной группой сотрудников или одним подразделением. Например, система управления задачами отдела, система учета заявок технической поддержки или база документов кафедры. Корпоративная информационная система охватывает деятельность всей организации или значительной ее части. Она объединяет данные и процессы различных подразделений, обеспечивает единое информационное пространство и поддерживает управление ресурсами предприятия. Примерами являются системы класса ERP, комплексные банковские системы, корпоративные медицинские системы и информационные системы крупных университетов. Межорганизационная информационная система обеспечивает взаимодействие нескольких самостоятельных организаций. Например, система электронного документооборота между поставщиками и заказчиками, платформа электронных торгов, система взаимодействия банков и платежных организаций. Государственная информационная система создается для выполнения функций органов государственной власти и предоставления государственных услуг. Такие системы имеют особые требования к безопасности, надежности, совместимости, хранению данных и нормативному регулированию. Глобальная информационная система функционирует в международном масштабе и обслуживает большое число пользователей, организаций и регионов. К этому классу могут относиться международные платежные, поисковые, коммуникационные и облачные платформы. По уровню управления выделяются операционные, управленческие, аналитические и стратегические информационные системы. Операционные информационные системы поддерживают повседневные повторяющиеся операции. Они регистрируют заказы, платежи, перемещения товаров, обращения клиентов, посещения, начисления и другие события. Основной задачей таких систем является точная и своевременная обработка большого количества транзакций. Например, кассовая система магазина регистрирует продажу товаров, рассчитывает стоимость покупки, принимает оплату, уменьшает остатки на складе и формирует чек. Банковская операционная система обрабатывает переводы, платежи, внесение и снятие средств. Управленческие информационные системы предоставляют руководителям информацию для контроля и управления деятельностью. Они формируют отчеты, показатели, сводные таблицы и уведомления об отклонениях. Такие системы используют данные операционного уровня, но представляют их в агрегированном виде. Например, руководитель торговой сети может получать отчеты о продажах по регионам, магазинам, категориям товаров и периодам. Руководитель университета может анализировать контингент студентов, успеваемость, нагрузку преподавателей и выполнение учебных планов. Системы поддержки принятия решений предназначены для анализа сложных ситуаций, сравнения вариантов и оценки последствий решений. Они используют аналитические модели, прогнозирование, оптимизационные методы, статистику и визуализацию данных. Например, логистическая система может выбирать оптимальные маршруты доставки с учетом расстояний, загрузки транспорта, дорожной обстановки и сроков. Кредитная система может оценивать риск выдачи кредита на основе данных о заемщике. Стратегические информационные системы поддерживают долгосрочное планирование и развитие организации. Они позволяют анализировать тенденции, оценивать положение на рынке, прогнозировать изменения и моделировать различные сценарии. По функциональному назначению выделяются бухгалтерские, финансовые, производственные, маркетинговые, логистические, кадровые, медицинские, образовательные, справочно-правовые, геоинформационные и другие системы. Бухгалтерские информационные системы автоматизируют учет хозяйственных операций, формирование проводок, расчет налогов и подготовку отчетности. Финансовые системы поддерживают бюджетирование, управление денежными потоками, анализ доходов и расходов. Производственные системы обеспечивают планирование и контроль производственных процессов, управление оборудованием, материалами и качеством. Логистические системы управляют перевозками, складами, маршрутами и поставками. Кадровые системы хранят сведения о сотрудниках, учитывают рабочее время, поддерживают расчет заработной платы и управление персоналом. По степени автоматизации выделяются ручные, автоматизированные и автоматические системы. В ручной информационной системе операции выполняются человеком без применения специализированных средств автоматизации. Например, учет может вестись в бумажных журналах. В автоматизированной информационной системе часть операций выполняется программными и техническими средствами, а часть решений принимает человек. Большинство современных организационных систем относится именно к автоматизированным, поскольку человек участвует в постановке задач, контроле, подтверждении операций и принятии решений. В автоматической системе операции выполняются без непосредственного участия человека в штатном режиме. Человек осуществляет настройку, наблюдение и вмешивается при возникновении исключительных ситуаций. Примерами могут служить автоматические системы управления технологическими процессами, системы мониторинга оборудования и автоматические торговые алгоритмы. По характеру обработки информации выделяются системы транзакционной обработки, информационно-поисковые, аналитические, экспертные и интеллектуальные системы. Системы обработки транзакций, или TPS, регистрируют и обрабатывают отдельные хозяйственные или операционные события. Для них важны скорость, надежность, целостность и согласованность данных. Информационно-поисковые системы обеспечивают хранение, индексирование и поиск документов или других информационных объектов. Примерами являются библиотечные каталоги, поисковые системы, архивы документов и базы нормативных актов. Аналитические информационные системы предназначены для исследования накопленных данных, выявления закономерностей, построения отчетов и прогнозов. Они могут включать хранилища данных, OLAP-технологии, панели показателей и средства бизнес-аналитики. Экспертные системы используют формализованные знания и правила для решения задач в определенной предметной области. Например, медицинская экспертная система может анализировать симптомы и предлагать возможные диагнозы, однако окончательное решение остается за специалистом. Интеллектуальные информационные системы применяют машинное обучение, обработку естественного языка, компьютерное зрение, рекомендательные алгоритмы и другие методы искусственного интеллекта. По режиму обработки данных системы могут быть пакетными, интерактивными и работающими в реальном времени. Пакетная обработка предполагает накопление данных и их обработку через определенные интервалы времени. Например, расчет заработной платы может выполняться один раз в месяц для всех сотрудников. Интерактивная обработка предполагает непосредственное взаимодействие пользователя с системой. Пользователь вводит данные и получает результат в процессе работы. Обработка в реальном времени требует реакции системы в строго ограниченный промежуток времени. Такие системы применяются в управлении оборудованием, транспорте, медицине, телекоммуникациях и финансовых операциях. Следует различать системы мягкого реального времени и жесткого реального времени. В системе мягкого реального времени задержка нежелательна, но не приводит к катастрофическим последствиям. Например, небольшая задержка видеотрансляции ухудшает качество обслуживания, но обычно не угрожает безопасности. В системе жесткого реального времени нарушение временного ограничения может привести к аварии или потере управления. Примером является система управления медицинским оборудованием или промышленным процессом. По способу организации вычислений выделяются централизованные, децентрализованные и распределенные информационные системы. В централизованной системе основные вычисления и хранение данных выполняются в одном центре. Пользовательские устройства обращаются к центральному серверу или вычислительному комплексу. Преимуществами являются простота управления, единообразие данных и централизованный контроль. Недостатками могут быть зависимость от центрального узла и ограниченная масштабируемость. В децентрализованной системе отдельные подразделения или узлы обладают высокой степенью самостоятельности. Они могут иметь собственные данные и приложения. В распределенной информационной системе компоненты размещаются на нескольких вычислительных узлах, взаимодействующих по сети. Пользователь может воспринимать такую систему как единое целое, хотя обработка выполняется в разных местах. Распределенная архитектура позволяет масштабировать нагрузку и повышать отказоустойчивость, но усложняет взаимодействие, согласование данных, мониторинг и безопасность. По типу пользователей можно выделить внутренние, внешние и смешанные информационные системы. Внутренняя система используется сотрудниками организации. Внешняя система предназначена для клиентов, партнеров или граждан. Смешанная система обслуживает и внутренние, и внешние группы пользователей. Например, банковская система включает внутреннюю часть, которой пользуются сотрудники, и внешние каналы — мобильное приложение, интернет-банк, банкоматы и интерфейсы для партнеров. По степени интеграции информационные системы делятся на изолированные, частично интегрированные и интегрированные. Изолированная система практически не обменивается данными с другими системами. Частично интегрированная система имеет ограниченное число интерфейсов. Интегрированная система включена в широкую информационную среду и взаимодействует с множеством внутренних и внешних приложений. По способу доступа выделяются локальные, сетевые, веб-ориентированные, мобильные и облачные системы. Локальная система устанавливается на отдельном компьютере или работает в локальной сети. Веб-ориентированная система доступна через браузер. Мобильная система использует приложения для смартфонов и планшетов. Облачная система развертывается на облачной инфраструктуре и предоставляется через сеть. Классификация информационных систем имеет практическое значение, поскольку разные классы систем предъявляют различные требования к архитектуре. Для небольшой локальной системы может быть достаточна простая монолитная архитектура. Для глобальной платежной платформы необходима сложная распределенная архитектура с высокой доступностью, масштабируемостью, безопасностью и устойчивостью к отказам.

1.3 Основные виды архитектуры информационной системы

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

1.3.1 Функциональная архитектура

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

1.3.2 Системная архитектура

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

1.3.3 Информационная архитектура

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

1.3.4 Архитектура данных

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

1.3.5 Программная архитектура

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

1.3.6 Взаимосвязь различных видов архитектуры

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

1.4 Монолитная архитектура

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

1.5 Микросервисная архитектура

Микросервисная архитектура представляет собой архитектурный подход, при котором система разделяется на набор небольших автономных сервисов. Каждый сервис реализует определенную бизнес-возможность, имеет четкую ответственность и взаимодействует с другими сервисами через сетевые интерфейсы. Например, интернет-магазин может быть разделен на сервис каталога, сервис заказов, сервис пользователей, сервис платежей, сервис склада, сервис доставки и сервис уведомлений. Каждый микросервис может иметь собственный программный код, собственную базу данных, отдельный цикл разработки и отдельное развертывание. Команда может изменять и выпускать сервис независимо от остальных, если сохраняется совместимость интерфейсов. Ключевой принцип микросервисной архитектуры заключается в разделении по бизнес-возможностям, а не только по техническим слоям. Например, сервис заказов должен включать логику, связанную с заказами, а не представлять собой общий слой доступа к данным для всей системы. Другим важным принципом является автономность сервисов. Сервис должен обладать достаточной самостоятельностью и минимально зависеть от внутренних деталей других сервисов. В микросервисной архитектуре взаимодействие происходит через сеть. Для синхронного взаимодействия могут использоваться HTTP API, REST, gRPC и другие протоколы. Для асинхронного взаимодействия используются очереди сообщений и события. Например, после создания заказа сервис заказов может опубликовать событие «Заказ создан». Сервис склада уменьшит остатки, сервис уведомлений отправит сообщение клиенту, а аналитическая система зарегистрирует событие для отчетности. Преимуществом микросервисов является независимое развертывание. Изменение сервиса уведомлений не требует обязательного развертывания сервиса заказов или каталога. Микросервисы позволяют независимо масштабировать части системы. Если сервис поиска испытывает высокую нагрузку, можно увеличить только число его экземпляров. Разные сервисы могут использовать различные технологии и типы баз данных, если это оправдано задачами. Например, сервис заказов может использовать реляционную базу данных, а сервис рекомендаций — графовое или аналитическое хранилище. Микросервисная архитектура также позволяет распределить ответственность между командами. Каждая команда может владеть определенной группой сервисов и отвечать за их разработку, тестирование и эксплуатацию. Отказ одного сервиса не обязательно приводит к полному отказу системы. Например, при временной недоступности сервиса рекомендаций интернет-магазин может продолжать оформлять заказы без персональных предложений. Однако такая устойчивость возникает только при специально спроектированной обработке отказов. Микросервисная архитектура имеет и существенные недостатки. Основной проблемой является распределенная сложность. Взаимодействие по сети менее надежно, чем вызов функции внутри одного процесса. Запрос может задержаться, потеряться, выполниться несколько раз или завершиться частично. Необходимо учитывать сетевые задержки, тайм-ауты, повторные попытки, балансировку нагрузки, обнаружение сервисов, версионирование API и защиту каналов связи. Сложнее обеспечить целостность данных. В монолите операция может выполняться в рамках одной транзакции базы данных. В микросервисной системе данные распределены между несколькими сервисами, и единая транзакция может быть невозможна или нежелательна. Например, оформление заказа включает резервирование товара, списание средств и создание доставки. Если платеж выполнен, но резервирование товара завершилось ошибкой, система должна корректно обработать частичный результат. Для этого используются распределенные процессы, компенсационные операции и шаблоны типа Saga. Возрастает сложность тестирования. Необходимо проверять отдельные сервисы, их интерфейсы, совместимость версий и совместное поведение системы. Эксплуатация требует развитой инфраструктуры. Необходимы автоматическое развертывание, централизованное журналирование, мониторинг, трассировка запросов, управление конфигурациями, контейнеризация и оркестрация. Большое количество сервисов увеличивает число сетевых соединений, журналов, версий и точек отказа. Без зрелых инженерных процессов микросервисная архитектура может оказаться значительно сложнее монолита. Особенно опасно создавать чрезмерно мелкие сервисы. Если каждое простое действие требует последовательного обращения к множеству сервисов, производительность снижается, а система становится трудноуправляемой. Размер микросервиса определяется не количеством строк кода, а целостностью его бизнес-ответственности и возможностью независимого изменения.

1.6 Сравнение монолитной и микросервисной архитектуры

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

1.7 Архитектурные образцы

Архитектурный образец, или архитектурный паттерн, представляет собой обобщенное повторно применяемое решение типовой проблемы проектирования. Паттерн не является готовой программой или точной схемой. Он описывает общий принцип организации элементов, условия применения, преимущества, ограничения и последствия. Архитектурные образцы формируются на основе опыта создания множества систем. Они позволяют не разрабатывать каждое решение с нуля, а использовать проверенные подходы. Однако паттерн нельзя применять механически. Необходимо учитывать контекст и требования конкретной системы. Одним из наиболее известных является слоистый архитектурный паттерн. Система разделяется на уровни, каждый из которых выполняет определенную ответственность. Например, выделяются слой представления, слой бизнес-логики, слой доступа к данным и слой хранения данных. Слой представления взаимодействует с пользователем. Слой бизнес-логики реализует правила предметной области. Слой доступа к данным выполняет запросы к хранилищу. Такое разделение упрощает понимание и сопровождение системы. Недостатком слоистой архитектуры может быть прохождение каждого запроса через множество уровней и появление излишних зависимостей. Кроме того, при неправильном проектировании слой бизнес-логики может превратиться в набор процедур, тесно связанных с базой данных. Клиент-серверная архитектура разделяет систему на клиентов, запрашивающих услуги, и серверы, предоставляющие их. Клиент отвечает за взаимодействие с пользователем, сервер — за обработку запросов и управление ресурсами. В двухзвенной архитектуре клиент напрямую взаимодействует с сервером базы данных или серверным приложением. В трехзвенной архитектуре между клиентом и базой данных располагается сервер приложений. Многоуровневая архитектура включает дополнительные уровни и сервисы. Архитектура модель–представление–контроллер, или MVC, разделяет приложение на модель, представление и контроллер. Модель хранит состояние и бизнес-логику, представление отображает данные, контроллер обрабатывает действия пользователя и координирует взаимодействие. MVC особенно распространен в веб-разработке. Например, при открытии страницы товара контроллер принимает запрос, обращается к модели, получает данные и передает их представлению для формирования страницы. Сервисно-ориентированная архитектура, или SOA, организует систему как совокупность сервисов, предоставляющих функции через стандартизированные интерфейсы. Сервисы могут использоваться различными приложениями и бизнес-процессами. SOA часто применяется в крупных организациях для интеграции разнородных систем. Например, сервис проверки клиента может использоваться банковской системой, мобильным приложением и системой кредитования. Микросервисная архитектура имеет общие идеи с SOA, но обычно предполагает более мелкие автономные сервисы, независимое развертывание, децентрализованное управление данными и тесную связь сервисов с отдельными бизнес-возможностями. Событийно-ориентированная архитектура строится вокруг событий. Компонент публикует событие о произошедшем факте, а другие компоненты реагируют на него. Отправитель может не знать, какие получатели обработают событие. Например, событие «Платеж подтвержден» может быть обработано сервисом заказов, системой учета, сервисом уведомлений и аналитической платформой. Событийная архитектура снижает прямую связанность компонентов и хорошо подходит для асинхронных процессов. Однако она усложняет отслеживание последовательности операций, обработку ошибок и обеспечение согласованности данных. Архитектура каналов и фильтров представляет обработку данных как последовательность преобразований. Каждый фильтр выполняет отдельную операцию, а каналы передают данные между фильтрами. Такой паттерн применяется в компиляторах, системах обработки изображений, потоковой аналитике и интеграции данных. Например, поток документов может пройти стадии загрузки, проверки формата, извлечения текста, классификации и сохранения. Архитектура репозитория предполагает наличие центрального хранилища, к которому обращаются различные компоненты. Общая база данных является примером репозитория. Преимуществом является единообразие данных. Недостатком — сильная зависимость компонентов от структуры хранилища. Архитектура брокера используется в распределенных системах для организации взаимодействия между компонентами через посредника. Брокер принимает запросы, определяет получателя и передает сообщения. Примерами являются брокеры сообщений и интеграционные шины. Архитектура микрокернела, или архитектура подключаемых модулей, состоит из минимального ядра и расширений. Ядро реализует базовые функции, а дополнительные возможности подключаются как плагины. Такой подход используется в интегрированных средах разработки, браузерах, системах управления контентом и корпоративных платформах. Гексагональная архитектура, также называемая архитектурой портов и адаптеров, отделяет бизнес-логику от внешних технологий. Центральная часть системы содержит правила предметной области. Взаимодействие с базами данных, пользовательским интерфейсом, внешними сервисами и очередями осуществляется через порты и адаптеры. Благодаря этому бизнес-логика меньше зависит от конкретной базы данных или веб-фреймворка. Например, вместо прямого обращения к определенной СУБД бизнес-компонент использует абстрактный интерфейс хранения, а конкретный адаптер реализует этот интерфейс. Чистая архитектура и луковичная архитектура развивают похожие идеи. Основные правила предметной области размещаются в центре, а технические детали находятся на внешних уровнях. Зависимости направлены внутрь, к более стабильной бизнес-логике. Архитектурные паттерны могут комбинироваться. Например, микросервисная система может использовать событийное взаимодействие, а каждый сервис внутри может быть построен по гексагональной или слоистой архитектуре.

1.7.1 Отличие архитектурного паттерна от шаблона проектирования

Архитектурный паттерн необходимо отличать от шаблона проектирования. Архитектурный паттерн определяет крупномасштабную структуру системы или приложения. Шаблон проектирования решает более локальную задачу организации классов и объектов. Например, MVC является архитектурным паттерном, поскольку определяет структуру приложения. Шаблон «Фабрика» определяет способ создания объектов, а шаблон «Наблюдатель» — способ уведомления зависимых объектов об изменениях. Граница между уровнями может быть условной, однако архитектурные паттерны обычно оказывают влияние на всю систему и связаны с фундаментальными решениями.

1.8 Эталонные модели

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

1.9 Эталонные архитектуры

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

1.10 Эталонные варианты архитектур

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

1.11 Соотношение паттерна, эталонной модели и эталонной архитектуры

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

1.12 Архитектурные структуры

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

1.12.1 Архитектурные представления

Архитектурное представление является описанием системы с определенной позиции и для определенных заинтересованных сторон. Оно включает архитектурные элементы, отношения между ними и пояснения. Необходимо различать структуру, представление и точку зрения. Структура существует как организация элементов системы. Представление является ее документированным изображением или описанием. Точка зрения задает правила построения такого представления: какие элементы включать, какие обозначения использовать и какие вопросы решать. Например, структура развертывания существует в системе как реальное размещение программных компонентов. Диаграмма развертывания является архитектурным представлением. Набор правил создания диаграмм развертывания является архитектурной точкой зрения. Разные заинтересованные стороны нуждаются в разных представлениях. Руководителю не требуется детальная схема классов. Ему важны крупные подсистемы, риски и затраты. Разработчику необходимы модули, интерфейсы и зависимости. Администратору требуется схема серверов, сетей и развертывания. Специалисту по безопасности важны границы доверия, потоки конфиденциальных данных и механизмы контроля доступа. Попытка создать одну универсальную диаграмму для всех участников приводит к перегруженному и малополезному документу. Поэтому архитектура описывается набором взаимосвязанных представлений. Одной из известных моделей является модель представлений «4+1». Она включает логическое представление, представление процессов, представление разработки, физическое представление и сценарии. Логическое представление описывает основные функциональные элементы и объекты предметной области. Оно показывает, каким образом система реализует требуемую функциональность. Представление процессов описывает выполняющиеся процессы, потоки, параллелизм, взаимодействие и синхронизацию. Оно важно для анализа производительности и надежности. Представление разработки показывает организацию программного кода, модулей, библиотек и пакетов. Оно ориентировано на разработчиков. Физическое представление описывает развертывание программных элементов на технической инфраструктуре. Оно важно для системных инженеров и администраторов. Сценарии, обозначаемые как «+1», демонстрируют, как элементы различных представлений взаимодействуют при выполнении конкретных пользовательских задач. Например, сценарий оформления заказа связывает пользовательский интерфейс, сервисы, процессы, данные и инфраструктуру. В современной практике также широко используется модель C4. Она предлагает четыре уровня: контекст системы, контейнеры, компоненты и код. Диаграмма контекста показывает систему, пользователей и внешние системы. Диаграмма контейнеров показывает крупные исполняемые приложения и хранилища данных. Диаграмма компонентов раскрывает внутреннее устройство контейнера. Диаграмма кода описывает классы и другие элементы реализации. Модель C4 позволяет постепенно увеличивать детализацию, не перегружая представления.

1.12.2 Требования к архитектурным представлениям

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

1.13 Проектирование архитектуры «сверху вниз»

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

1.14 Проектирование архитектуры «снизу вверх»

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

1.15 Сочетание подходов «сверху вниз» и «снизу вверх»

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

1.16 Этапы проектирования архитектуры информационной системы

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

1.16.1 Архитектурные принципы

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

1.16.2 Компромиссы в архитектуре

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

1.16.3 Архитектурные риски

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

1.16.4 Документирование архитектурных решений

Архитектура должна быть документирована не только в виде схем, но и в виде решений. Для этого могут использоваться записи архитектурных решений, или ADR. Такая запись содержит контекст проблемы, рассматриваемые варианты, принятое решение, обоснование и последствия. Например, может быть зафиксировано решение использовать асинхронный обмен сообщениями между сервисами заказов и уведомлений. В обосновании указывается, что отправка уведомления не должна задерживать оформление заказа. В последствиях отмечается необходимость обработки повторных сообщений и мониторинга очереди. Документирование решений важно, поскольку через некоторое время участники могут забыть причины выбора. Без объяснения новое решение может показаться нелогичным и быть отменено, хотя оно было принято из-за существенных ограничений.

1.16.5 Архитектура как развивающаяся система

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

1.17 Значение архитектуры информационной системы

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

2. Жизненный цикл информационных систем

Жизненный цикл информационной системы представляет собой упорядоченную совокупность состояний, процессов, работ и изменений, через которые проходит информационная система с момента возникновения потребности в ее создании до окончательного прекращения эксплуатации и вывода из использования. Жизненный цикл охватывает не только непосредственную разработку программного обеспечения, но и формирование замысла системы, изучение объекта автоматизации, определение требований, проектирование архитектуры, программную реализацию, испытания, внедрение, эксплуатацию, сопровождение, модернизацию, перенос данных, замену системы и ее окончательное снятие с эксплуатации. Понятие жизненного цикла позволяет рассматривать информационную систему не как однажды созданный и неизменный программный продукт, а как развивающийся объект. После внедрения система продолжает изменяться под воздействием новых требований, изменений законодательства, развития организации, увеличения объемов данных, появления новых технологий, выявления ошибок и изменения ожиданий пользователей. Поэтому жизненный цикл информационной системы обычно значительно продолжительнее периода ее первоначальной разработки. Например, разработка информационной системы университета может занимать два года, однако эксплуатация и сопровождение такой системы могут продолжаться десять или пятнадцать лет. За это время изменяются учебные планы, правила приема, формы отчетности, требования к защите персональных данных, способы взаимодействия со студентами и государственными информационными ресурсами. Следовательно, система должна не только быть создана, но и постоянно поддерживаться в актуальном состоянии. В широком смысле жизненный цикл начинается в тот момент, когда организация осознает наличие проблемы или потребности, которую предполагается решить с помощью информационных технологий. Например, руководство предприятия может установить, что существующий порядок учета складских запасов приводит к ошибкам, задержкам и избыточным закупкам. На этом этапе самой информационной системы еще не существует, но ее жизненный цикл уже начинается, поскольку формируется потребность, анализируются возможные решения и оценивается целесообразность автоматизации. Завершается жизненный цикл не простым прекращением запуска программы, а организованным снятием системы с эксплуатации. При этом необходимо сохранить юридически и организационно значимые данные, перенести информацию в новую систему, закрыть права доступа, прекратить интеграционное взаимодействие, удалить или архивировать конфиденциальные данные, обновить эксплуатационные регламенты и определить дальнейшую судьбу оборудования и программных компонентов. Жизненный цикл информационной системы необходимо отличать от жизненного цикла проекта. Проект имеет определенные цели, сроки, бюджет и момент завершения. Например, проект внедрения системы может завершиться после ее приемки заказчиком. Жизненный цикл самой системы при этом продолжается, поскольку начинается промышленная эксплуатация, сопровождение и последующее развитие. Следует также различать жизненный цикл информационной системы, жизненный цикл программного обеспечения и жизненный цикл программного продукта. Информационная система включает не только программы, но и данные, технические средства, пользователей, организационные процессы, документацию, средства связи и правила эксплуатации. Жизненный цикл программного обеспечения относится преимущественно к программным компонентам. Жизненный цикл программного продукта может дополнительно включать его продвижение, распространение, лицензирование, продажи, поддержку потребителей и прекращение коммерческого распространения. Например, бухгалтерская информационная система предприятия может включать прикладную программу, базу данных, серверное оборудование, рабочие места бухгалтеров, средства резервного копирования, правила разграничения доступа и регламенты подготовки отчетности. Обновление программного компонента является частью жизненного цикла программного обеспечения, но переход организации на новые формы учета и изменение обязанностей сотрудников относятся к жизненному циклу информационной системы в целом. Основными категориями описания жизненного цикла являются стадия, этап, процесс, работа, задача, операция, результат, контрольная точка, итерация, инкремент, версия и выпуск. Стадия жизненного цикла представляет собой относительно крупную часть развития системы, объединенную общей целью и завершающуюся получением значимого результата. Например, стадиями могут быть формирование требований, проектирование, разработка, внедрение и эксплуатация. Этап является более детальной частью стадии. Например, стадия внедрения может включать подготовку объекта автоматизации, обучение персонала, предварительные испытания, опытную эксплуатацию и приемочные испытания. Процесс представляет собой совокупность взаимосвязанных действий, преобразующих определенные входные данные в результаты. Процесс управления требованиями преобразует потребности заинтересованных сторон в согласованные и контролируемые требования к системе. Процесс тестирования преобразует программный продукт, требования и тестовые данные в сведения о качестве и соответствии системы установленным требованиям. Работа объединяет несколько связанных задач, выполняемых для достижения определенного результата. Задача представляет собой конкретное действие или совокупность действий, закрепленных за исполнителем. Операция обычно рассматривается как наиболее детальная единица технологической деятельности. Контрольная точка обозначает момент, в котором оценивается достижение требуемого результата и принимается решение о дальнейшем движении проекта. В контрольной точке может утверждаться техническое задание, архитектура, опытный образец, версия программного продукта или готовность системы к эксплуатации. Итерация представляет собой повторное выполнение определенной последовательности работ с целью получения более полного и качественного результата. Каждая итерация уточняет требования, архитектуру, программные компоненты или другие элементы системы. Инкремент представляет собой функциональное приращение системы, то есть новую часть работоспособного продукта. Например, первым инкрементом системы университета может стать управление контингентом студентов, вторым — формирование расписания, третьим — учет успеваемости. Версия является определенным состоянием системы или программного продукта, имеющим идентифицируемый набор функций и изменений. Выпуск, или релиз, представляет собой версию, официально подготовленную для передачи пользователям или эксплуатации. Жизненный цикл описывается с помощью модели жизненного цикла. Такая модель определяет, как во времени организуются процессы, стадии и работы, в какой последовательности они выполняются, когда проверяются результаты, допускаются ли возвраты к предшествующим этапам, каким образом выпускаются версии системы и как учитываются риски. Необходимо различать модель жизненного цикла и методологию разработки. Модель жизненного цикла задает общую временную и логическую организацию работ. Методология определяет более конкретные принципы, роли, документы, методы и способы управления проектом. Например, каскадная и спиральная модели являются моделями жизненного цикла, а рациональный унифицированный процесс представляет собой более развернутую процессную технологию. Гибкие методы разработки также включают конкретные правила организации командной работы, планирования и обратной связи. Модель жизненного цикла не является описанием всех процессов организации. В пределах одной модели одновременно могут выполняться управление проектом, управление требованиями, проектирование, программирование, тестирование, управление конфигурацией, обеспечение качества, документирование, управление рисками и взаимодействие с заказчиком. Модель показывает общую организацию этих процессов во времени. Международный стандарт ISO/IEC/IEEE 12207:2026 устанавливает общую систему процессов жизненного цикла программных систем, продуктов и услуг. Он охватывает замысел, приобретение, поставку, разработку, эксплуатацию, поддержку и прекращение применения программного обеспечения. При этом стандарт прямо не предписывает единственную модель жизненного цикла: процессы могут выполняться параллельно, итерационно, рекурсивно и инкрементно в зависимости от особенностей проекта. Таким образом, жизненный цикл и модель жизненного цикла не являются тождественными понятиями. Жизненный цикл существует у каждой системы объективно, поскольку она создается, используется, изменяется и в определенный момент прекращает существование. Модель жизненного цикла является способом упорядочения и описания этого развития.

2.1 Содержание жизненного цикла информационной системы

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

2.1.1 Принципы управления жизненным циклом

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

2.2 Каскадная модель жизненного цикла информационной системы

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

2.3 Поэтапная модель жизненного цикла с промежуточным контролем

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

2.4 Стандартизация процессов разработки программ и программной документации

Стандартизация разработки программ и программной документации представляет собой установление и применение согласованных правил, требований, терминов, процессов, видов документов и способов контроля. Ее назначение состоит в том, чтобы сделать деятельность участников проекта понятной, воспроизводимой, управляемой и проверяемой. Без стандартизации разные участники могут по-разному понимать содержание стадий, назначение документов, критерии завершения работ и ответственность сторон. Заказчик может считать систему готовой после реализации функций, разработчик — после завершения программирования, а эксплуатационная организация — только после подготовки инструкций, мониторинга и резервного копирования. Стандарты формируют общий профессиональный язык. Они определяют такие понятия, как процесс, деятельность, задача, требование, верификация, валидация, конфигурация, сопровождение, эксплуатация и прекращение применения. Стандартизация выполняет организационную функцию, поскольку определяет порядок работ и взаимодействия участников. Техническая функция заключается в установлении требований к проектированию, разработке и испытаниям. Информационная функция обеспечивает единообразное представление результатов. Контрольная функция позволяет оценивать полноту и качество работ. Правовая функция проявляется в возможности использовать стандарты и связанные с ними документы при заключении и исполнении договоров. Стандарты жизненного цикла не следует воспринимать как подробную инструкцию по программированию. Они преимущественно определяют, какие процессы должны быть предусмотрены, какие цели они преследуют и какие результаты должны давать. Конкретные языки программирования, средства моделирования, алгоритмы и инструменты выбираются с учетом проекта. Международная стандартизация разделяет процессы жизненного цикла системы и процессы жизненного цикла программного обеспечения. ISO/IEC/IEEE 15288:2023 применяется к полному жизненному циклу систем, включая формирование замысла, разработку, производство, использование, поддержку и снятие с эксплуатации. Он рассматривает систему как целостный объект, включающий программные, технические, организационные и человеческие элементы. ISO/IEC/IEEE 12207:2026 устанавливает систему процессов жизненного цикла программных систем, продуктов и услуг. Он применяется к приобретению, поставке, разработке, эксплуатации, сопровождению и прекращению использования программного обеспечения. Стандарт допускает применение процессов в различных моделях жизненного цикла, включая последовательные, итерационные, инкрементные и гибкие подходы. Это означает, что стандарт процессов и модель жизненного цикла выполняют разные функции. Стандарт определяет состав и назначение процессов, а модель устанавливает их временную организацию. Один и тот же процесс тестирования может использоваться в каскадной, спиральной, инкрементной или гибкой разработке. В каскадной модели основное системное тестирование выполняется после реализации. В итерационной модели тестирование проводится в каждой итерации. В непрерывной разработке автоматические тесты запускаются при каждом изменении программного кода. Сам процесс тестирования сохраняется, но меняется его положение в жизненном цикле. В российской системе стандартизации применяется ГОСТ Р ИСО/МЭК 12207—2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств». Он был создан на основе международной редакции ISO/IEC 12207:2008. Международный стандарт позднее обновлялся, а в 2026 году опубликована новая редакция ISO/IEC/IEEE 12207:2026. Поэтому при практическом применении необходимо различать действующий российский национальный стандарт и актуальную международную редакцию. Важным российским нормативным документом является ГОСТ Р 59793—2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания». Он устанавливает стадии и этапы создания автоматизированных систем. На территории Российской Федерации этот стандарт применяется вместо ГОСТ 34.601—90, который утратил силу с 1 декабря 2023 года. ГОСТ Р 59793—2021 предусматривает движение от формирования требований и разработки концепции к техническому заданию, проектированию, созданию рабочей документации, вводу системы в действие и сопровождению. Конкретный состав стадий и этапов может адаптироваться с учетом особенностей создаваемой системы. Стадия формирования требований к автоматизированной системе включает обследование объекта, обоснование необходимости создания системы, формирование пользовательских требований и оформление результатов. На стадии разработки концепции изучается объект автоматизации, при необходимости проводятся научно-исследовательские работы, формируются варианты концепции, выбирается предпочтительное решение и оцениваются риски проекта. Стадия технического задания завершается разработкой и утверждением документа, который устанавливает назначение, цели, требования, состав работ, порядок контроля и условия приемки системы. На проектных стадиях разрабатываются предварительные и окончательные решения по структуре системы, ее функциям, данным, техническим средствам, программному обеспечению, безопасности и организации эксплуатации. Стадия ввода в действие может включать подготовку объекта, обучение персонала, поставку и монтаж технических средств, загрузку данных, предварительные испытания, опытную эксплуатацию и приемочные испытания. Сопровождение включает работы по гарантийному и послегарантийному обслуживанию, устранению недостатков, поддержанию работоспособности и развитию системы. Отдельное направление стандартизации связано с Единой системой программной документации — ЕСПД. Она устанавливает виды программ и программных документов, стадии разработки, правила оформления, содержание технического задания, описание программы, программу и методику испытаний, эксплуатационные документы и другие результаты разработки. С 30 января 2025 года в России действует ГОСТ 19.101—2024 «Единая система программной документации. Виды программ и программных документов», заменивший ГОСТ 19.101—77. В 2026 году к новой редакции была введена поправка. Стандарт распространяется на программы для средств вычислительной техники и устанавливает виды программ и программных документов. ГОСТ 19.102—77 «Единая система программной документации. Стадии разработки» продолжает действовать и устанавливает стадии разработки программ и программной документации. В нем определены техническое задание, эскизный проект, технический проект, рабочий проект и внедрение. Стандарт допускает исключение или объединение отдельных стадий и этапов по согласованию с заказчиком, то есть даже традиционная нормативная схема предусматривает адаптацию к конкретному проекту. На стадии технического задания обосновывается необходимость разработки, формулируется задача, собираются исходные материалы, определяются требования, критерии качества, сроки, этапы и виды испытаний. Эскизный проект содержит предварительные решения по стр