Разработка автоматизированной системы управления рисками

С организационной  точки зрения архитектура АСУ  содержит три основных уровня: уровень  представления данных, уровень бизнес-логики и уровень хранения данных.

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

АСУР должна быть совместимой и взаимодействовать  с другими системами предприятия-инвестора (система бухучета, отдела кадров и  т.д.), обмен информацией должен происходить  автоматически по локальной сети.

Для АСУР определены следующие режимы функционирования: 
- Нормальный режим функционирования; 
- Аварийный режим функционирования.

Основным режимом функционирования АСУР является нормальный режим. 

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

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

В случае перехода системы в предаварийный  режим необходимо: 
- завершить работу всех приложений, с сохранением данных; 
- выключить рабочие станции операторов; 
- выключить все периферийные устройства; 
- выполнить резервное копирование БД.

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

АСУР должна предоставлять инструменты диагностирования основных процессов системы, трассировки и мониторинга процесса выполнения программы.

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

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

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

 

Требования  к функциям.

1. Подсистема идентификации риска должна обеспечивать анализ введенных данных о рисковом событии (классификация, систематизация), составление реестра рисков. Подсистема должна предоставлять пользователю удобный и понятный интерфейс для ввода данных.
2. Подсистема Оценки риска должна обеспечивать расчет оценки вероятности риска, оценки стоимости ущерба, расчет значимости риска, сравнение с уровнями толерантности, выделение существенных и несущественных рисков, расчет экономических показателей, определение  сопутствующих рисков.
3. Подсистема назначения действий, направленных на выявление и устранение причин и последствий рисковых событий должна обеспечивать определение мероприятий для минимизации риска (предложение пользователю списка типовых мероприятий из справочника типовых мероприятий, внесение в справочник нетиповых мероприятий, введенных пользователем), их стоимости, предполагаемого эффекта, сроков исполнения, ответственных лиц.
4. Подсистема сбора данных о фактически понесенных потерях, вызванных влиянием операционного риска должна обеспечивать сбор данных о фактических потерях от реализации рискового события, о виновных, о возмещении ущерба, о влиянии рискового события на другие сферы деятельности.
5. База данных должна содержать информацию обо всех рисковых событиях, мероприятиях, контрольных процедурах,  о виновных, о владельцах рисков, об ответственных, справочник типовых рисков, справочник типовых мероприятий, справочник типовых контрольных процедур, классифицировать и систематизировать данные, информация об экспертах и экспертных оценках, о количественных параметрах рисков). База данных должна обеспечивать периодическое резервное копирование и сохранение данных на дополнительных носителях информации.
6. Подсистема контроля исполнения мероприятий должна контролировать исполнение мероприятий по минимизации риска посредством напоминаний, отметок об исполнении/неисполнении, запросом отчетов.
7. Подсистема аналитики должна содержать мастер отчетов для генерации отчетных форм по желанию пользователя, позволять визуализацию рисковых событий, ущерба, эффективности мероприятий, контрольных процедур, производить мониторинг рисковых событий.  Подсистема аналитики должна быть построена на основе современных OLAP-технологий, позволяющих строить многомерные аналитические отчеты произвольного вида, включая графическое и текстовое представление данных.
8. Подсистема интеллектуального анализа данных должна осуществлять анализ данных из базы данных при поддержке экспертной информации, предоставлять пользователю информацию о наиболее распространенных рисках, наиболее эффективных мероприятиях, о сопутствующих рисках, о периодических рисках, об уровне контроля рисков(низкий, средний, высокий), организационные и операционные масштабы(все предприятие, бизнес-единицы, бюджетные единицы), уровень рассмотрения и принятия решений и т.д.
9. Подсистема подготовки опросных листов для экспертов должна обеспечивать выбор экспертов, выбор вопросов, рассылку опросных листов, определение сроков опроса.

 

Требования  к видам обеспечения.

Требования  к математическому обеспечению.

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

Требования к информационному обеспечению.

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

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

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

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

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

Технические средства, обеспечивающие хранение информации, должны использовать современные технологии, позволяющие обеспечить повышенную надежность хранения данных и оперативную замену оборудования (распределенная избыточная запись/считывание данных; зеркалирование; независимые дисковые массивы; кластеризация). 

В состав системы должна входить специализированная подсистема резервного копирования и восстановления данных.

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

 

Состав, содержание и организация работ  по созданию АСУ.

1. Исследование и обоснование создания АС.
1. Обследование (сбор и анализ данных) автоматизированного объекта, включая сбор сведений о зарубежных и отечественных аналогах.
2. Разработка и оформление требований к системе.
2. Техническое задание.

2.1       Разработка технического задания на АС в целом и, при необходимости, частных ТЗ на подсистемы.

3. Технический проект.
1. Разработка окончательных решений по общесистемным вопросам, в том числе по структурам АС (функциональной, организационной); процедурам (задачам), реализуемым системой; процессу функционирования системы и, при необходимости, выдача частных технических заданий на разработку видов обеспечения АС или видов обеспечения подсистемы АС.
2. Разработка решений по организационному обеспечению, включая разработку плана мероприятий по подготовке к внедрению АС.
3. Разработка решений по техническому обеспечению.
4. Разработка или выбор алгоритмов автоматизируемой деятельности.
5. Разработка решений по информационному обеспечению.
6. Разработка решений по программному обеспечению.
7. Разработка проектно-сметной строительной документации.
8. Согласование решений по связям видов обеспечения между собой и разработка общесистемной документации на АС в целом.
9. Составление заказной документации на поставляемые компоненты и комплексы средств автоматизации или технических заданий на их разработку.
4. Рабочая документация.
1. Разработка рабочей документации по информационному обеспечению.
2. Разработка рабочей документации по организационному обеспечению.
3. Разработка или адаптация программ и программной документации.
5. Ввод в действие.
1. Подготовка организации к вводу АС в действие, обучение персонала пользователя. 
2. Комплектация АС* поставляемыми комплексами средств автоматизации, техническими средствами, программными средствами и др.
3. Пуско-наладочные работы.
4. Проведение опытной эксплуатации АС.
5. Проведение приемочных испытаний (государственных, межведомственных или ведомственных).
6. Приемка АС в промышленную эксплуатацию (внедрение АС)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4 База данных АСУР

 

4.1 Понятие о данных и БД

 

Восприятие реального мира можно  соотнести с последовательностью  разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое  описание называют данными.

Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного  языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить  утверждение "Стоимость авиабилета 128". Здесь "128" – данное, а "Стоимость  авиабилета" – его семантика.

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

Жесткая зависимость между данными  и использующими их программами  создает серьезные проблемы в  ведении данных и делает использования  их менее гибкими.

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

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