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

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 Содержание жизненного цикла информационной системы

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