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

3.1.8 Сопровождение автоматизированной системы

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

3.2 Первичная стандартизация процессов жизненного цикла программных средств

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

3.2.1 Основные процессы первоначального стандарта

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

3.2.2 Вспомогательные процессы первоначального стандарта

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

3.2.3 Организационные процессы первоначального стандарта

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

3.3 Глобальная унифицированная стандартизация процессов жизненного цикла информационных систем

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

3.3.1 Процессы соглашения

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

3.3.2 Процессы организационного обеспечения проекта

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

3.3.3 Процессы проекта

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

3.3.4 Технические процессы

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

3.3.5 Процессы реализации программных средств

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

3.3.6 Процессы поддержки программных средств

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

3.3.7 Процессы повторного применения программных средств

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

3.3.8 Современное развитие унифицированной стандартизации

Следующая крупная международная редакция ISO/IEC/IEEE 12207:2017 еще сильнее гармонизировала процессы программного обеспечения с ISO/IEC/IEEE 15288. В ней использовались четыре основные группы: процессы соглашения, процессы организационного обеспечения проекта, процессы технического управления и технические процессы. В апреле 2026 года опубликован ISO/IEC/IEEE 12207:2026. Он устанавливает общую систему процессов полного жизненного цикла программных систем, продуктов и услуг, включая формирование замысла, разработку, эксплуатацию, поддержку и прекращение применения. Стандарт допускает одновременное, итерационное, рекурсивное и инкрементное выполнение процессов и не предписывает одну обязательную модель жизненного цикла. На системном уровне в России действует ГОСТ Р 57193—2025, разработанный с учетом ISO/IEC/IEEE 15288:2023 и заменивший ГОСТ Р 57193—2016. Он распространяется на процессы жизненного цикла систем и применяется к системам, создаваемым человеком. Смысл глобальной унификации заключается не в установлении одинаковой последовательности стадий для всех проектов. Унификация создает общий набор процессов, целей, результатов и терминов. Конкретная организация адаптирует их к каскадной, итерационной, спиральной, инкрементной или иной модели.

3.4 Понятие требования к информационной системе и программному обеспечению

Требование представляет собой документированное положение о потребности, возможности, свойстве, функции, характеристике или ограничении, которым должна соответствовать система, программный продукт, процесс или услуга. Требования являются связующим звеном между проблемой заказчика и техническим решением. Они объясняют, зачем создается система, что она должна делать, в каких условиях работать и каким критериям соответствовать. Требование не следует смешивать с пожеланием, идеей или проектным решением. Пожелание может быть неопределенным: «необходимо улучшить обслуживание клиентов». Требование должно уточнять, какой результат ожидается. Проектное решение указывает, каким способом требование будет реализовано. Например, положение «пользователь должен получать уведомление о подтверждении заказа» является функциональным требованием. Решение «уведомление отправляется через брокер сообщений» относится к архитектуре реализации. При формировании требований необходимо различать проблемную область и область решения. Проблемная область описывает деятельность, потребности и ограничения организации. Область решения охватывает программные и технические способы реализации. Преждевременное смешение этих областей приводит к тому, что пользователи формулируют не потребность, а привычный способ ее удовлетворения. Например, пользователь может потребовать «добавить кнопку экспорта в электронную таблицу». Его реальная потребность может заключаться в регулярном получении аналитического отчета. Возможно, автоматическая отправка отчета будет более подходящим решением. Инженерия требований представляет собой систематическую деятельность по выявлению, анализу, согласованию, документированию, проверке, валидации и управлению требованиями. Международный стандарт ISO/IEC/IEEE 29148:2018 регулирует процессы инженерии требований для систем и программных продуктов. Он определяет процессы, информационные результаты, их содержание и рекомендации по оформлению документации требований. Стандарт применяется совместно с процессами ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207. Инженерия требований включает несколько взаимосвязанных видов деятельности. Сначала выявляются заинтересованные стороны и их потребности. Затем требования анализируются, устраняются противоречия и определяется приоритет. После этого требования документируются, проверяются, согласовываются и утверждаются. На протяжении жизненного цикла изменения требований регистрируются и контролируются. Требования образуют иерархию. На верхнем уровне находятся цели организации и бизнес-требования. Далее формулируются требования заинтересованных сторон и пользователей. Они преобразуются в системные требования. Системные требования распределяются между подсистемами, программным обеспечением, оборудованием и организационными процедурами. Затем формируются детальные требования к отдельным компонентам. Например, бизнес-цель может заключаться в сокращении времени обработки заявки клиента. Пользовательское требование устанавливает возможность подачи заявки через личный кабинет. Системное требование определяет состав операций, взаимодействие с внешними системами и требования к времени обработки. Программное требование описывает конкретную функцию проверки заявки. Разделение уровней необходимо для обеспечения прослеживаемости. Разработчик должен понимать, какой потребностью обусловлено конкретное программное требование. Заказчик должен видеть, каким системным решением удовлетворяется его потребность.

3.5 Пользовательские требования

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