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

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 «Единая система программной документации. Стадии разработки» продолжает действовать и устанавливает стадии разработки программ и программной документации. В нем определены техническое задание, эскизный проект, технический проект, рабочий проект и внедрение. Стандарт допускает исключение или объединение отдельных стадий и этапов по согласованию с заказчиком, то есть даже традиционная нормативная схема предусматривает адаптацию к конкретному проекту. На стадии технического задания обосновывается необходимость разработки, формулируется задача, собираются исходные материалы, определяются требования, критерии качества, сроки, этапы и виды испытаний. Эскизный проект содержит предварительные решения по структуре входных и выходных данных, методам решения задачи и общему алгоритму. Технический проект уточняет данные, алгоритмы, структуру программы, формы представления информации и конфигурацию технических средств. Рабочий проект включает программирование, отладку, разработку программной документации и испытания. Внедрение предусматривает подготовку и передачу программы и документации для эксплуатации, сопровождения или изготовления. Система программной документации может включать техническое задание, спецификацию, текст программы, описание программы, пояснительную записку, программу и методику испытаний, описание применения, руководство пользователя, руководство оператора, руководство программиста, формуляр и другие документы. Назначение технического задания состоит в фиксации целей, назначения, требований, ограничений, стадий разработки и порядка приемки. Спецификация определяет состав программы и документации. Описание программы раскрывает логическую структуру и функционирование. Программа и методика испытаний устанавливает, какие требования проверяются и какими способами. Эксплуатационные документы обеспечивают правильное использование, настройку и обслуживание системы. Международный стандарт ISO/IEC/IEEE 15289:2019 посвящен содержанию информационных объектов жизненного цикла, то есть документации и других зафиксированных результатов процессов. Он определяет назначение и содержание документов, создаваемых в ходе жизненного цикла систем и программного обеспечения. Современное понимание документации шире традиционного текстового документа. Информационным объектом жизненного цикла может быть модель, электронная запись, набор требований, журнал изменений, описание интерфейса, протокол испытаний, схема развертывания, программный код с комментариями или автоматически сформированный отчет. Стандартизация документации обеспечивает полноту, однозначность, согласованность, идентифицируемость, актуальность и прослеживаемость информации. Полнота означает наличие всех необходимых сведений. Однозначность исключает различные толкования. Согласованность требует отсутствия противоречий между документами. Идентифицируемость позволяет определить наименование, версию, автора и статус документа. Актуальность означает соответствие текущему состоянию системы. Прослеживаемость связывает документ с требованиями, решениями и результатами проверки. Большое значение имеет управление версиями документации. Техническое задание, проектная модель и руководство пользователя могут изменяться. Участники должны использовать утвержденные версии, соответствующие текущей конфигурации системы. Например, если тестировщик проверяет систему по устаревшей версии требований, результаты испытаний не будут достоверными. Если пользователь применяет старую инструкцию после изменения интерфейса, возрастает вероятность ошибок. Стандартизация не означает обязательного создания максимального количества документов. Состав документации должен соответствовать размеру, критичности и условиям проекта. Для небольшой внутренней программы может быть достаточно краткого описания требований, инструкции и набора тестов. Для государственной или промышленной системы потребуется значительно более формализованный комплект. Важным принципом является адаптация стандарта, то есть выбор применимых процессов, работ и документов. Адаптация должна быть обоснованной. Нельзя исключать испытания или управление конфигурацией только ради сокращения сроков, если это создает неприемлемые риски. Стандарты не отменяют профессиональное решение. Они создают основу, но конкретная организация определяет роли, инструменты, контрольные точки, степень детализации и способы автоматизации процессов.