Тема: Требования к архитектуре информационных систем и их компонентам для обеспечения безопасности функционирования

«Требование – это условие или возможность, которой должна соответствовать система».

В IEEE Standard Glossary of Software Engineering Terminology (1990) данное понятие трактуется шире.

Требование – это:

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;

2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;

 

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

• архитектура системы должна быть достаточно гибкой и допускать относительно простое, без коренных структурных изменений, развитие конфигурации используемых средств и наращивание функций и ресурсов ИС в соответствии с расширением сфер и задач ее применения;

(доп.: архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы).

• должны быть обеспечены безопасность функционирования системы при различных видах угроз и надежная защита данных от ошибок проектирования, от разрушения или потери информации, а также авторизация пользователей, управление рабочей загрузкой, резервированием и восстановлением функционирования ИС;
• следует обеспечить комфортный, максимально упрощенный доступ пользователей к управлению и результатам функционирования информационной системы на основе современных графических средств, мнемосхем и наглядных пользовательских интерфейсов;

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

• систему должна сопровождать актуализированная, комплектная документация, обеспечивающая квалифицированную эксплуатацию и возможность развития ИС.

(доп.: ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.,

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

Ø краткое описание процесса;

Ø действующие лица (актеры);

Ø предусловие;

Ø постусловие;

Ø основной сценарий процесса;

Ø альтернативные сценарии (альтернативные сценарии на данном этапе могут быть выявлены не все, данное описание может дополняться в процессе уточнения требований).

 

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

 

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

 

В конце документа следует дать технико-экономическое обоснование разработки ИС. Данный раздел технической документации, при необходимости, может быть выделен в отдельный документ.

Этап обследования объекта автоматизации юридически может быть оформлен отдельным договором или включен в перечень работ по созданию ИС.

 

Следующим этапом создания ИС, является уточнение требований и на основании этого анализа создание документа «Техническое задание».

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

 

Функциональные требования могут быть описаны в технической документации при помощи все тех же диаграмм UML: use case (варианты использования или диаграммы прецедентов), avtivity (сценарии вариантов использования), state machine (диаграмма конечных автоматов).

 

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

 

Диаграмму конечных автоматов в технической документации лучше использовать для основных объектов, изменение состояния которых в Системе необходимо показать заказчику (например, документ – создан, согласован, утвержден).

 

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

 

Помимо функциональных требований в Техническое задание на разработку ИС должны быть включены требования к надежности и безопасности.

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

 

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

 

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

 

Завершающим этапом документирования проекта по созданию ИС может считаться разработка технического проекта и рабочей документации.

 

Высокие темпы роста основных ресурсов аппаратных средств (приблизительно на порядок каждые пять лет) и сохраняющаяся потребность в их увеличении со стороны пользователей привели к необходимости адекватного совершенствования технологий создания программ и баз данных.

 

Одним из важнейших и эффективных путей решения этой проблемы являются концепция и совокупности стандартов открытых систем

(доп.: "Открытая система - это система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы" определение, Жана-Мишеля Корну, подчеркиваемое системный аспект (структуру открытой системы).)

Совокупность стандартов открытых систем начала разрабатывать первая рабочая группа POSIX (Portable Operating System Interface) в IEEE в 1985 г. на основе UNIX-ориентированного комитета по стандартизации /usr/group, ныне UniForum).

 

Идеология открытых систем существенно отразилась на методологических аспектах и ряде направлений развития сложных, критических ИС.

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

Это позволяет обеспечить совместимость компонент различных информационных систем, а также средств передачи данных.

 

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

 

Продуманная и упорядоченная структура ПС и БД непосредственно отражается на достигаемом качестве и безопасности ИС, а также на трудоемкости их разработки.

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

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

 

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

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

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

«Пояснительная записка» или «Общее описание системы» - данные документы во многом пересекаются, поэтому в состав ТРП (технорабочий проект) следует включать только один из них.

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

 

«Описание постановки задач» - данный документ целесообразен, если функциональные требования в Техническом задании были описаны не достаточно детально.

«Описание организации информационной базы» - данный документ обычно включает логическое описание базы данных (БД) Системы. Документ предназначен для разработчиков БД.

Эксплуатационная документация обычно включает «Руководство системного администратора» и «Руководство пользователя».

Если в Системе присутствует несколько основных пользователей, руководство пользователя пишется отдельно для каждого из них.

Перечень технической документации создаваемой для заказчика оформляется в документе

«Ведомость технического проекта».

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

 

 

КОНЕЦ ЛЕКЦИИ 2 (ОТ 13.09.2016 г.)

 

20 сентября 2016г.

БФИС

 

Лекция № 3