Разработка требований к безопасности, доступу, обслуживанию системы

Интегрирование и наследование механизмов обмена данными

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

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

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

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

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

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

· каков график необходимой доступности системы для запросов пользователя (то есть когда система обязательно должна работать);

· допустимы ли вообще и когда допустимы периоды профилактического простоя системы;

· допустимы ли и когда допустимы периоды ограничения доступа к системе;

· какие данные после отказа системы нельзя получить из других источников (часто это ввод новых документов, например накладных, операции со счетами, заказы на телефонные переговоры, информация с автоматизированных датчиков и т.п.);

· если данные можно получить, то каков объем повторно вводимой информации;

· каково допустимое время восстановления системы после сбоя;

· имеется ли график пакетных суточных заданий;

· какие еще приложения, кроме информационной системы, работают на данном оборудовании;

· имеются ли резервные аппаратные средства на случай отказа основных;

· имеется ли запас мощности оборудования, на котором функционирует информационная система;

· какова скорость передачи данных при резервном копировании;

· имеются ли специальные отказоустойчивые носители для хранения резервных копий.

Ответы на эти вопросы позволят более реально оценить ситуацию и уточнить требования заказчика, формализованные аналитиками. Бывает, что заказ работоспособности системы в режиме 24х7 вовсе не является обоснованным и система простаивает, например, 50% времени. Если же требование 24х7 действительно отражает особенности данного бизнеса, то эти вопросы помогут построить соответствующую стратегию защиты данных от сбоев. Качество построенной при проектировании стратегии защиты должно быть проверено тестерами, причем их работа по генерации и проведению тестов, имитирующих отказы оборудования, должна проводиться как на этапе проектирования, так и в течение всего этапа разработки — в целях раннего обнаружения дефектов стратегии защиты данных от сбоев.

Рабочее проектирование – 3 этап. Основные задачи и особенности.