Общие принципы развития Системы
В соответствии с РД 50-680–88 при выполнении работ должны учитываться и сохраняться все достигнутые ранее основные характеристики функционирования, в том числе следующие принципы:
1) Принцип системности. При декомпозиции должны быть установлены такие связи между структурными элементами системы, которые обеспечивают цельность системы и ее взаимодействие с другими системами.
2) Принцип развития (открытости). Исходя из перспектив развития объекта автоматизации, система должна создаваться с учетом возможности пополнения и обновления функций и состава системы без нарушения ее функционирования.
3) Принцип совместимости. Должны быть реализованы информационные интерфейсы, благодаря которым система может взаимодействовать с другими системами в соответствии с установленными правилами.
4) Принцип стандартизации (унификации). Должны быть рационально применены типовые, унифицированные и стандартизованные элементы, проектные решения, пакеты прикладных программ, комплексы, компоненты.
5) Принцип эффективности. Должно быть достигнуто рациональное соотношение между затратами на создание системы и целевыми эффектами, включая конечные результаты, получаемые в результате автоматизации.
6) Принцип концептуального единства. Система должна разрабатываться в соответствии с утвержденными нормативно-правовыми актами РФ и субъектов РФ, нормативно-методическими и нормативно-техническими документами, регламентирующими порядок создания, разработки и эксплуатации автоматизированных систем.
|
|
|
7) Принцип развития (модифицируемости). Система должна обеспечивать возможность развития, расширения и интеграции с другими системами. Технические решения, используемые на этапах проектирования и реализации Системы должны позволять минимизировать трудозатраты по модернизации, необходимые в связи с принятием новых нормативно-правовых актов, приводящих к изменению технологического процесса.
8) Принцип мобильности. Все виды обеспечения проектируемой Системы должны обладать максимальной независимостью от конкретных типов применяемых технических и программных средств.
9) Принцип децентрализации управления, хранения и обработки информации. Система должна разрабатываться так, чтобы обработка информации в ней проводилась в подсистемах максимально автономно.
10) Принцип относительной независимости подсистем (принцип модульности). Система должна быть реализована как совокупность отдельных максимально независимых функциональных подсистем.
11) Принцип открытости. Система должна быть способна к интеграции в свою среду новых подсистем, расширения функций уже имеющихся, а также обеспечивать возможность интеграции с внешними ИС. В Системе должны применяться общепринятые стандарты на правила передачи (протоколы, интерфейсы) и хранения информации.
|
|
|
12) Принцип многоуровневости. Процесс предоставления государственных, муниципальных и иных услуг имеет многоуровневую организационную структуру. Развитие Системы должно решать проблемы, которые ставятся и (или) решаются на каждом уровне.
13) Принцип санкционированного доступа к информации. Система должна обеспечивать санкционированный доступ к информации. Система должна иметь функции администрирования, которые позволяют устанавливать пользователям права доступа к информации.
Требования к системе
Требования к системе в целом
Требования к структуре и функционированию системы
Функционирование Системы должно осуществляться в многоуровневой архитектуре, в виде взаимодействующего набора подсистем (модулей), совместимых на программно-аппаратном и информационном уровне.
В основу структуры Системы должен быть заложен модульный принцип организации, обеспечивающий возможность встраивания дополнительных подсистем (модулей) и взаимодействия с другими информационными системами
|
|
|
Подрядчик должен разработать и согласовать с Заказчиком архитектуру решения.
Архитектура решения должна быть оформлена в соответствии с документом ДИТ «Шаблон описания архитектуры». Указанный шаблон предоставляется Заказчиком в рабочем порядке на 1-ом этапе.
Каждый модуль СППРиУИР АМиПМ должен быть реализован в трехзвенной архитектуре клиент-сервер, состоящей из компонент трех типов (см. Рисунок 1):
- сервер баз данных;
- серверы приложений, отвечающие за выполнение логики приложений;
- автоматизированные рабочие места (клиентские приложения).
Уровень представления должен быть отделен от уровня данных слоем бизнес-логики.
Рисунок 1 —Архитектура приложения
Использование трехуровневой архитектуры должно обеспечить высокую безопасность и надежность информационной системы.
Архитектура решения должна обеспечивать возможность онлайн обработки сообщений больших объемов и архивный поиск за прошлые даты, получение 3 миллионов сообщений из СМИ и социальных медиа в 24 часа и разделение потока сообщений (очередей) по приоритетам.
В архитектуре решения должна применяться распределённая система управления базами данных, основанная на модели данных BigTable.
|
|
|
Основными преимуществами выделения логики приложения в отдельную составляющую являются возможность ее повторного использования, повышение производительности используемого сервера базы данных, возможность масштабирования Системы. Кроме того, обеспечивается изолированность уровней друг от друга, что позволяет быстро и простыми средствами переконфигурировать Систему при возникновении сбоев или при плановом обслуживании на одном из уровней.
В состав презентационного слоя для веб-приложений не должны входить компоненты, специфичные для конкретной операционной системы (например, ActiveX компоненты).
Компоненты презентационного слоя могут непосредственно взаимодействовать только с компонентами слоя бизнес – логики.
Дата добавления: 2018-06-27; просмотров: 1311; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!