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

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

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

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

В российской нормативной базе стадии создания автоматизированных систем устанавливает ГОСТ Р 59793—2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания». Требования к техническому заданию на создание автоматизированной системы определяет ГОСТ 34.602—2020. Требования к содержанию основных документов, разрабатываемых при создании автоматизированных систем, устанавливает ГОСТ Р 59795—2021. Процессы жизненного цикла систем рассматриваются в действующем ГОСТ Р 57193—2025, а способы представления и документирования архитектуры — в ГОСТ Р 57100—2025. Последний определяет основные понятия архитектурного описания, архитектурные точки зрения, представления, модели и языки описания архитектуры.

Международный уровень представлен стандартами ISO/IEC/IEEE 12207, посвященными процессам жизненного цикла программного обеспечения, ISO/IEC/IEEE 15288, посвященными процессам жизненного цикла систем, ISO/IEC/IEEE 29148, регулирующими инженерию требований, ISO/IEC/IEEE 42010, посвященными описанию архитектуры, а также серией ISO/IEC 25000, устанавливающей модели и методы определения и оценки качества систем и программных продуктов. Стандарты не должны восприниматься как независимые и конкурирующие документы. Они рассматривают один объект с различных сторон. Стандарт стадий создания отвечает на вопрос, в какой общей последовательности организуется проект. Стандарты процессов жизненного цикла определяют, какие процессы необходимо выполнять. Стандарт инженерии требований устанавливает правила получения, анализа и документирования требований. Стандарт архитектурного описания регулирует представление архитектурных решений. Стандарты качества помогают определить характеристики, которыми должна обладать система.

3.1 Отечественный стандарт жизненного цикла автоматизированных систем

В отечественной практике длительное время основным документом, определявшим стадии создания автоматизированных систем, являлся ГОСТ 34.601—90 «Автоматизированные системы. Стадии создания». Его положения оказали значительное влияние на организацию разработки государственных, производственных, банковских, учетных и управленческих систем. На основе этого стандарта формировались технические задания, проектная документация, программы испытаний и договорные отношения между заказчиками и исполнителями.

В настоящее время национальным стандартом, непосредственно устанавливающим стадии и этапы создания автоматизированных систем, является ГОСТ Р 59793—2021. Он введен в действие 30 апреля 2022 года и распространяется на автоматизированные системы, используемые в управлении, проектировании, исследованиях и других видах деятельности. Стандарт определяет восемь основных стадий: формирование требований к автоматизированной системе, разработку концепции, техническое задание, эскизный проект, технический проект, рабочую документацию, ввод в действие и сопровождение автоматизированной системы.

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

3.1.1 Формирование требований к автоматизированной системе

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

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

3.1.2 Разработка концепции автоматизированной системы

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

3.1.3 Техническое задание

Третья стадия называется «Техническое задание». На ней разрабатывается, согласовывается и утверждается техническое задание на создание автоматизированной системы. Техническое задание является основным документом, устанавливающим назначение системы, цели ее создания, требования, состав работ, порядок контроля и условия приемки. Оно связывает потребности заказчика с деятельностью разработчика. Техническое задание должно быть достаточно полным, чтобы определить границы проекта и ожидаемый результат, но не должно неоправданно ограничивать разработчика деталями, которые могут быть определены на стадии проектирования. Например, в техническом задании необходимо установить требуемую производительность, но не всегда требуется заранее назначать конкретную марку сервера. Действующий ГОСТ 34.602—2020 предусматривает обязательные разделы технического задания: общие сведения; цели и назначение создания системы; характеристику объектов автоматизации; требования к автоматизированной системе; состав и содержание работ; порядок разработки; порядок контроля и приемки; требования к подготовке объекта к вводу системы в действие; требования к документированию и источники разработки. В разделе требований могут фиксироваться требования к структуре и функционированию системы, численности и квалификации персонала, показателям назначения, надежности, безопасности, защите информации, эргономике, эксплуатации, техническому, информационному, программному, организационному и другим видам обеспечения. Техническое задание имеет не только техническое, но и договорное значение. Оно позволяет установить, что должен создать исполнитель и по каким критериям заказчик будет принимать результат. Неопределенные или непроверяемые формулировки в техническом задании становятся причиной конфликтов. Например, требование «система должна работать быстро» невозможно объективно проверить. Корректнее указать: «при штатной нагрузке время формирования карточки клиента не должно превышать двух секунд для 95 процентов запросов». Такое требование содержит условие, измеряемый показатель и допустимое значение.

3.1.4 Эскизный проект

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

3.1.5 Технический проект

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

3.1.6 Рабочая документация

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

3.1.7 Ввод в действие

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