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

УДК 004

РАЗРАБОТКА МОДЕЛЕЙ ОПИСАНИЯ ДЕЯТЕЛЬНОСТИ СТРАХОВОЙ КОМПАНИИ

Новикова Татьяна Борисовна¹, Самойлова Светлана Сергеевна², Вахрушев Владислав Игоревич^3
1Магнитогорский государственный технический университет им. Г.И. Носова, кандидат педагогических наук, доцент кафедры БИиИТ
²Магнитогорский государственный технический университет им. Г.И. Носова, студент группы ФИПИб-13
³Магнитогорский государственный технический университет им. Г.И. Носова, студент группы ФИПИб-13

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

Ключевые слова: моделирование процессов деятельности, модель описания деятельности, страховая компания

---

MODELLING THE DESCRIPTION OF ACTIVITIES OF THE INSURANCE COMPANY

Novikova Tatyana Borisovna¹, Samoilova Svetlana Sergeevna², Vakhrushev Vladislav Igorevich^3
1Nosov Magnitogorsk State Technical University, Ph.D., Associate Professor, Department of business Informatics
²Nosov Magnitogorsk State Technical University, student
³Nosov Magnitogorsk State Technical University, student

Abstract
This article presents a simulation of an insurance company by using different methodologies.

---

Библиографическая ссылка на статью:
Новикова Т.Б., Самойлова С.С., Вахрушев В.И. Разработка моделей описания деятельности страховой компании // Современная техника и технологии. 2016. № 11. Ч. 2 [Электронный ресурс]. URL: https://technology.snauka.ru/2016/11/11435 (дата обращения: 24.02.2023).

Содержание:

Введение

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

Объектом проекта курса является методология структурного проектирования для ИС. Тема проекта курса — сеть и SADT-модели.

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

Задача теоретической части проекта курса:

1) получить обзор структурного подхода к проектированию ИС;

2) сравнительный анализ подходов;

3) описание метода функционального моделирования SADT;

4) Изучение методов и методов построения сетевых моделей;

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

Целью практической части проекта курса является моделирование бизнес-процесса страхования гражданской ответственности. Для описания предметных областей бизнес-процесса будут использоваться BPwin и ERwin.

Для решения этой задачи необходимы следующие задачи:

1) Изучить характеристики предметной области;

2) Определить бизнес-процессы, включенные в эту предметную область;

3) Использование инструментов визуального моделирования бизнес-процессов BPwin и ERwin для моделирования процесса страхования вашего клиентского автомобиля;

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

Глава 1. Основы структурного подхода к проектированию ИС

1.1. Применение структурного подхода при разработке ИС

Проблема сложности является основной проблемой, которая должна быть решена при создании больших и сложных систем любого характера, включая ЭИС. Ни один разработчик не может выйти за рамки человеческих возможностей и понять всю систему. Единственный эффективный подход к решению этой проблемы, созданный человечеством в его истории, состоит в том, чтобы построить сложную систему из небольшого числа основных частей, каждая из которых, в свою очередь, построена из небольших частей и т.д. Поскольку мелкие детали могут быть изготовлены из существующего материала. ^[1]

Этот подход известен под разными именами, среди которых такие, как «разделяй и властвуй», иерархическую декомпозицию и тому подобное. Что касается проектирования сложных программных систем, это означает, что необходимо разделить (разложить) на небольшие подсистемы, каждая из которых может развиваться независимо. Это позволяет разрабатывать подсистемы на любом уровне, чтобы иметь в виду информацию только о ней, а не обо всех других частях системы. Правильное разложение является основным способом преодоления трудностей при разработке крупных систем.^[2] Понятие «правильное» в отношении к декомпозиции означает следующее:

• количество связей между отдельными подсистемами должно быть

минимум;

• подключение отдельных частей в каждой подсистеме быть максимальным.

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

• каждая подсистема должна инкапсулировать их содержимое

(чтобы скрыть его от других подсистем);

• каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

Фундаментальное различие между структурным и объектно-ориентированным (ОО) подходом — это метод декомпозиции системы. Подход OO использует декомпозицию объекта, а статическая структура системы описывается в терминах объектов и отношений между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.

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

1. 2. Основные принципы структурного подхода

Вся наиболее распространенная методология структурного подхода основана на целом ряде общих принципов. В качестве двух базовых принципов используется следующее:^[4] 1) принцип «разделяй и властвуй» — принцип решения сложных задач, разбивая их на многие более мелкие независимые задачи, легко понять и принять решение; 2) принцип иерархического упорядочения — принцип организации составных частей проблемы в иерархической древовидной структуре с добавлением новых деталей на каждом уровне. Распределение двух базовых принципов не означает, что другие принципы незначительны, так как игнорирование любого из них может привести к непредсказуемым последствиям (включая отказ всего проекта).^[5]Основными из этих принципов являются:

1) принцип абстрагирования — состоит в распределении существенных аспектов системы и отвлечении от нерелевантности;

2) принцип формализации — это необходимость строгого методического подхода к решению проблем;

3) принцип непротиворечивости — разумные и согласованные элементы;

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

В структурном анализе в основном используются две группы средств, иллюстрирующие функции, выполняемые системой, и отношения между данными. Каждая группа должна соответствовать определенным типам моделей (диаграмм), наиболее распространенными среди которых являются: модель SADT и соответствующие функциональные схемы; Диаграммы потоков данных DFD; ERD-диаграммы «сущность-связь».

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

Модель SADT (IDEF0) наиболее полезна при создании функциональных моделей. Они четко отражают функциональную структуру объекта: действия, отношения между действиями. Таким образом, четко логика и взаимодействие процессов организации. Основным преимуществом этой нотации является возможность получить полную информацию о каждой работе благодаря своей высоко регулируемой структуре. Она может помочь выявить любые недостатки в процессе, в котором она реализуется: дублирование функций, отсутствие механизмов, управляющих процессом, отсутствие контрольных переходов и т.д.^[6]

DFD позволяет анализировать информационное пространство системы и используется для описания управления документами и обработки информации. Поэтому диаграммы DFD используются для дополнения моделей бизнес-процессов, запущенных в IDEF0.^[7]

IDEF3 хорошо адаптирована для сбора данных, необходимых для анализа системы с точки зрения несоответствия / координации процессов во времени.

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

1.3. Сравнительный анализ подходов к проектированию ИС

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

1. Цели проекта;

2. Требования к информации, необходимые для анализа и принятия решений в отношении проекта;^[8]

3. Подход к возможностям, соответствующий требованиям раздела 2;

4. Разработка / внедрение информационной системы.

Сравнение подходов должно содержать ответы на следующие вопросы:

1. Как подход и его обозначения применимы к определенной фазе проектирования ИС.

2.Каков критерий выбора подхода в случае использования более одного подхода (какой подход лучше использовать).

Функциональность подходов может быть правильно сопоставлена ​​только по отношению к конкретным задачам. Каждый из этих подходов имеет свои преимущества и недостатки. В зависимости от задач эти преимущества могут увеличиваться и, наоборот, ослабевать. Следует подчеркнуть, что модель не является самоцелью — это всего лишь инструмент, это понимание того, что вам нужно описать, какие аспекты реальной системы в то же время отражают, что определяет успех проекта по моделированию бизнес процессов.^[9]

Сравнение структурированных, объектно-ориентированных подходов и методологии ARIS показано на рисунке 1.

Рис.1 а) Анализ структурного подхода

Рис. 1 б) Анализ объектно-ориентированного подхода

Рис. 1 в) Анализ   методологии ARIS

Позиционирование подходов, которых вы можете придерживаться в связи с проблемой моделирования бизнес-процессов на этапе анализа и проектирования таковы (таблица 1).

Таблица 1

Позиционирование подходов к видам проектов

Подход Тип проекта	Структурный подход	Объектно-ориентированный подход	Методология ARIS
Типовое проектирование		▼ ∆
Оригинальное проектирование	▼	∆	▼ ∆
Смешанное проектирование	▼	▼ ∆	▼ ∆

▼ — анализ

 ∆ — проектирование

Типовое проектирование — этап анализа — собирать информацию и одобрять ее полноту и адекватность с клиентом для настройки системы, для этого замечательного объектно-ориентированного подхода. Дизайн — исследование настроек системы, то есть реализация бизнес-процессов Заказчика в рамках внедренной системы. Использование структурных обозначений или моделей ARIS является неуместным и избыточным. Примером такого проекта может быть введение «Галактики» или «1С».^[10]

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

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

2. Предпочтения аналитиков и наличие инструментов.

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

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

Анализ сильных и слабых сторон структурированных, объектно-ориентированных подходов и методологии ARIS представляет собой основанную на технологиях ИС-схему с использованием CASE-технологий.

Предлагаемые схемы подходов к проектированию ИС уменьшают сложность процесса создания ИС, значительно повышают эффективность проекта и помогают избежать ненужных, чрезмерных действий из-за оптимального выбора инструментов в зависимости от типа проекта. [12] [14]

Глава 2. Сетевые и SADT-модели

2.1. Метод SADT. Обзор и состав функциональных моделей

 Метод SADT, разработанный Дугласом Росс в 1969 году для моделирования искусственных систем средней сложности. Этот метод был успешно использован в военных, промышленных и коммерческих организациях в Соединенных Штатах для решения широкого круга задач, таких как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка программного обеспечения для систем обороны, управление финансами, закупки, и т. д. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF. Метод SADT реализуется в одном из стандартов этого семейства — IDEFO, который был утвержден в качестве федерального стандарта в США в 1993 году^[11]

Метод SADT представляет собой набор правил и процедур для построения функциональной модели объекта любой предметной области. Функциональная модель SADT отображает функциональную структуру объекта, то есть создает действия и отношения между этими действиями. Основные элементы этого метода основаны на следующих концепциях:^[12]

• графическое представление блочного моделирования. Графические блоки и дуги. SADT-диаграммы отображают функциональный блок, а входы / выходы интерфейсов представлены дугами, соответственно, включенными в устройство и выходящими из него. Взаимодействие блоков друг с другом описывается с помощью интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и как выполняются и управляются функции.

Метод SADT может использоваться для моделирования различных процессов и систем. В существующих системах метод SADT может использоваться для анализа функций, выполняемых системой, и указать механизмы, с помощью которых они работают.^[13]

Состав функциональной модели.

Результатом метода SADT является модель, которая состоит из диаграмм, текстовых фрагментов и глоссария со ссылками друг на друга. Графики — основные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги, соответственно. Соединение провода с блоком определяет тип интерфейса. Управляющая информация, включенная в блок, а входная информация, которая обрабатывается, показана на левой стороне блока и результаты (вывод) показаны с правой стороны. Механизм (человеческая или автоматическая система), который выполняет операцию, представленную дугой, которая является нижней частью блока (рис.4). Одной из наиболее важных особенностей метода SADT является постепенное внедрение все большего количества деталей при создании диаграмм, показывающих модель. На рисунке 2, где показаны четыре диаграммы и их взаимосвязь, показана структура модели SADT. Каждая модель компонента может быть разложена на другую диаграмму. Каждая диаграмма иллюстрирует блок «внутренняя структура» в родительской диаграмме.^[14]

Рис. 2. Функциональный блок и интерфейсные дуги

2. 2. Иерархия диаграмм

 Построение модели SADT начинается с представления всей системы в простейших компонентах формы — одного блока и дуг, представляющих интерфейсы с функциями из системы. Поскольку единственным блоком является вся система в целом, имя, указанное в блоке, является общим. Это верно для интерфейса дуг — они также представляют собой полный набор внешних интерфейсов системы в целом. Затем блок, представляющий систему как единый модуль, подробно описан на другой диаграмме с несколькими блоками, связанными с дугами интерфейса. Эти блоки представляют собой основную подфункцию исходной функции. Это разложение показывает полный набор подфункций, каждый из которых представлен как блок, границы которого определены в дугах интерфейса. Каждая из этих подфункций может быть разложена аналогичным образом, для более детального представления.^[15]

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

Рис.2. Структура SADT-модели. Декомпозиция диаграмм

На рисунке 3 показаны различные опции для функций и дуг соединения с блоками.

Рис. 3а) параллельное выполнение функций

Рис. 3 б) Варианты соединения дуг с блоками

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

Для SADT-диаграмм явно не указывается какая-либо последовательность или время. Обратная связь, итерация, продолжение процесса и перекрытие (во времени) функций могут быть изображены с использованием дуг. Обратная связь может быть в виде комментариев, наблюдений, исправлений и т. д. (Рис. 4а).

Рис. 4 а). Пример обратной связи

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

Рис. 4 б). Пример механизма

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

Чтобы указать положение любых диаграмм или блоков в иерархии, используются числа диаграмм. Например, A21 — это диаграмма, которая детализирует блок 1 на диаграмме A2. Аналогично, A2 детализирует блок 2 на диаграмме, A0, который является самой верхней диаграммой модели. На рисунке 5 показана типичная древовидная диаграмма.

Рис. 5. Иерархия диаграмм

2.3. Типы отношений между функциями

Одним из основных моментов в разработке ICS с помощью методологии SADT является точная согласованность типов отношений между функциями. Различают по меньшей мере семь типов привязки:

• случайная;

• логическая;

• временная;

• процедурная;

• коммуникационная;

• последовательная;

• функциональная.

Ниже каждого типа контекста, кратко обозначенного и проиллюстрированного типичным примером SADT.^[16]

Тип случайной связи: наименее желательно.

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

Рис. 6 а) Случайная связность

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

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

Тип процедурной связности. Элементы, связанные с процедурой, группируются вместе, потому что они выполняются в одном цикле или процессе. Пример процедурной диаграммы показан на рисунке 6 б.

Рис. 6 б) Процедурная связность

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

Рис.6 в) Коммуникационная связность

Тип последовательной связности. Диаграммы, имеющие последовательную связь, вывод одной функции служит для ввода следующей функции. Связь между элементами на диаграмме меньше, чем упомянутые выше связки уровней моделируются как причинно-следственная зависимость (рис. 13).

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

Рис. 6 г) Последовательная связность

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

C = g (B) = g (f (A)) (1)

В таблице 2 ниже представлены все типы отношений, рассмотренные выше. Важно отметить, что уровни 4-6 устанавливают типы соединений, которые разработчики считают важными для получения графиков хорошего качества.^[17]

Рис. 6 д) Функциональная связность

Таблица 2

Описание типов связей

2.3. Планирование сети во время разработки проекта ИС.

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

Самые известные методы планирования и управления — метод критического пути (CPM) и программы планирования и развития лидерства (PERT).

Основные этапы реализации этих методов:

1) определяет конкретные рабочие компоненты проекта, их приоритетные отношения и продолжительность;

2) проект представлен в виде сети, показывающей отношения приоритета между работами, включающими проект;

3) на основе сетевых расчетов, составлен график работы проекта.

Планирование и управление сетью включает в себя 4 этапа:

1) структурное планирование;

2) календарное планирование;

3) оперативное управление.

Структурное планирование начинается с разделения проекта на отдельные операции, определяющие продолжительность, а затем построение сети, представляющей взаимосвязь работы проекта. Это позволяет деталям проанализировать все работы и внести улучшения в структуру проекта до начала его реализации.^[19]

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

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

2.3.1. Основные понятия и определение сетевых моделей

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

Основными элементами сетевой модели являются:

• Работа

• событие

• путь

Задайте некоторый процесс, который приведет к достижению определенного результата, потребляя любые ресурсы и имея длительный срок. Концепция «работа» применяет концепцию процесса, то есть процесс, который требует затрат труда, но не требует много времени. Ожидание изображено пунктирной стрелкой, что указывает на ее длительность (рис.7а).

Рис.7 а)изображение в сетевой модели ожидания

В понятие «работа» также входит понятие «зависимость». Зависимость — это взаимосвязь между двумя или более событиями, которые не требуют инвестиций времени или ресурсов. В сетевой модели зависимость показана как пунктирная стрелка без времени (рис. 7, б).

Рис.7 б) изображение зависимости в сетевой модели

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

Таким образом, начало и конец любой работы описывают пару событий, называемых начальными и конечными событиями. Поэтому для идентификации конкретной операции используйте код (ij), состоящий из начальных (i-ro) и конечного (j-ro) событий, например 2-4; 3-8; 9-10.

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

работа i,j

j

Рис. 7 в) Кодирование работы

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

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

Путь — любая последовательность работает в сети (в конкретном случае этой работы), в которой окончательное событие одного задания совпадает с началом события следующей работой. Следующие типы способов:^[21]

Полный путь — это путь от начального к финальному событию. Критический путь — максимальная длина полного пути. Подкритический путь — это полный путь, наиболее близкий по длительности к критическому пути.

Работа, лежащая на критическом пути, называется критической. Каждый путь характеризуется продолжительностью, которая равна сумме продолжительности его составляющих произведений.^[22]

2.3.2. Временные параметры событий, работ и способов

Tр (i) — самое раннее время I, это время, необходимое для выполнения всей работы до этого события. это наибольшая продолжительность пути до этого события.

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

R (i) — время события события i — период времени, который может задержать возникновение события, не нарушая условий завершения проекта в целом. Начальные и конечные события критических работ имеют нулевые резервные события. Основные параметры событий и действий вычисляются в соответствии с уравнениями 2-17.

Расчет самого раннего времени событий поддерживается от начального события до финала. Для исходного события Тр(i) =0 (2), для остальных событий Тр(i) – max[Тр(k)+t(k,i)] (3).

Поздний срок для завершающего события Тп(i) = Тр(i). (4) Для всех остальных событий Тп(i) = min[Тп(j)-t(i,j)] (5). Резерв времени Ri = Тп(i) – Tр(i) (6).

Трн(i,j) – ранний срок начала работы (i,j);

Тпн(i,j) – поздний срок начала работы (i,j);

Тро(i,j) – ранний срок окончания работы;

Тпо(i,j) – поздний срок окончания работы.

Для критических работ:

Трн(i,j)= Тпн(i,j) (7)

Тро(i,j)= Тпо(i,j) (8)

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

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

Трн(i,j) = Тp(i) (9)

Тро(i,j) = Тp(i)+t(i,j) (10)

Тро(i,j) = Трн(i,j)+t(i,j) (11)

Тпо(i,j) = Тп(i) (12)

Тпн(i,j) = Тп(j) – t(i,j) (13)

Тпн(i,j) = Тпо(i,j)-t(i,j) (14)

Rп(i,j) = Тп(j)-Тр(i)-t(i,j) (15)

Rc(i,j) = Тр(j)-Тр(i)-t(i,j) (16).

Разность между длительностью критического пути и длительностью другого полного пути называется полным запасом времени: R(Lп)=Т(Lкр)-Т(Lп) (17). ^{[23] [24]}

2.3.3. Пример построения сетевого графика

Построить сетевой график выполнения работ по реконструкции завода и определить значение его параметров (раннее и позднее начало событий, начало и конец работы, резервировать время для отдельных событий), чтобы определить критический путь сети.^[25]

Средняя продолжительность выполнения работ Таблица 3

Код работ	1-2	2-3	3-8	1-4	4-6	4-7	6-7	7-8	1-5	5-8	2-4	5-6
Продолжительность (дни)	2	4	4	6	5	4	6	5	14	3	1	0

Определяем ранние сроки наступления j-го события сетевого графика:

Определяем поздние сроки свершения i- го события :

Определим резерв времени i-го события сетевого графика.

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

1) 1-5-6-7-8. Его продолжительность равна:

(дней).

2) 1-5-8. Его продолжительность равна:

(дней).

Таким образом, критический путь — это путь 1-5-6-7-8 и его продолжительность составляет 25 дней.^[26] Список работ, относящихся к критическому пути, представлен в таблице 4.

Таблица 4

Коды работ	Продолжительность работы (дни)
1-5	14
5-6	0
6-7	6
7-8	5

Сетевой график выполнения работ по реконструкции цеха представлен на рисунке 8.

4

4

6

14

5

2

4

5

3

6

0

0

0

4

6

9

3

2

2

8

6

3

6

21

15

0

7

20

20

0

0

1

5

14

14

0

6

14

14

0

8

25

25

Рис.8 Сетевой график

Таким образом, критический путь — это путь 1-5-6-7-8, а его продолжительность составляет 25 дней.

ГЛАВА 3. Моделирование бизнес-процессов в среде BPwin

3.1. Описание предметной области

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

Основными процессами системы являются:

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

2) страховой платеж: заявки на оплату; рассмотрение документов; осмотр транспортных средств, имущества; подготовка акта; принятие закона; выплата страховки.

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

Постановка задачи

Цель:

1. Методы разработки, Case средствами BPwin;

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

Основные функции, требующие автоматизации:

• • • • учетная запись клиентов
      • учёт заключения договоров
      • автоматизировать процесс страховых выплат клиентам

Используемые документы и их описание:

Документы клиента, входящие в документы, удостоверяющие личность клиента и транспортных средств

Заявка на оплату — входящий документ

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

Акт осмотра — является внутренним документом, который подтверждает осмотр транспортного средства

Документ на страховое возмещение — исходящий документ для получения платежей.

3.2. Описание модели AS-IS

3.2.1. Построение диаграмм IDEF0

Методология IDEF0основана на подходе, разработанном Дугласом Т. Россом в начале 70-х годов и называется SADT (Structured Analysis & Design Technique — метод структурного анализа и проектирования). Основной подход и как результат, методология IDEF0 является графическим языком для описания (моделирования) систем.^[29]

Процесс моделирования любой системы в IDEF0 начинается с определения контекста, т. е. самого абстрактного уровня описания всей системы. В контексте было включено определение предмета моделирования, целей и точек зрения на модель.^[30]

На диаграмме контекста A-0 показана система управления процессом, показанная на рисунке 9 а).

Рис.9 а) Контекстная диаграмма

Рис. 9 б) Диаграмма декомпозиции

Рисунок 9 б) диаграмма декомпозиции, которая охватывает следующие процессы:

Консультации. Входящая информация — это вопросы клиента, исходящая информация – это ответы консультанта. Это просто: сотрудник, консультант по использованию законодательных документов и внутренних инструкций, находит ответ на вопрос и сообщает об этом клиенту по телефону.

Рис. 19 в) процесс проведения консультаций

Процесс консультаций проходит в 2 этапа: поиск информации и ответное сообщение^[31]

Информационный поиск проводится в центре следующим образом:

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

Рис. 19 г) Процесс поиска информации

Если клиента удовлетворяет полученная информация, мы можем перейти к следующему процессу — заключению договоров (рис.19 д). Это также происходит в 2 этапа: предварительные интервью и фактическое заключение контракта. Входящая информация — это документы клиента и решение клиента. Решением клиента может быть отказ в страховании — исходящей информации. В случае положительного решения соглашение заключено. Исходящая информация — это страховой полис.^[32]

Рис. 19 д) Процесс заключения договоров

В случае страхового случая клиент получает страховые выплаты (Рис.19 e). Этот процесс происходит в 4 этапа:

— просмотр документов. Входящая информация — это заявка на оплату, страховой полис и документы клиента. Исходящая информация — страховой случай.

— далее инспектором проводится проверка информации по транспортному средству — свидетельство о проверке.

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

— в случае положительного решения, кассир производит платежи клиенту. Исходящая информация – утверждённый акт осмотра.^[33]

Рис.19 е) Страховые выплаты

Прежде чем выплатить страховое возмещение, сотрудники центра рассмотрят документы клиента.^[34] Этот процесс происходит следующим образом (рис. 19 ж):

Рис. 19 ж) Рассмотрение документов

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

Сотрудники центра изучают документы и принимают решение об осмотре транспортных средств или нет.^[35]

3.2.2. Построить диаграммы IDEF3

В отличие от IDEF0, который представляет собой смоделированную систему как набор действий, IDEF3 является методом моделирования действий как последовательности событий, а также участвует в объектах событий.^[36]

Построим схему IDEF3-процесса контракта (рис. 20 a):

Рис. 20 а) Заключение договора

Из рисунка 20 а) видно, что заключение контракта состоит из следующих последовательных процессов: осмотр транспортных средств, заполнение инспекционного свидетельства, вид страхования, получение платежа и выдача полиса. Клиент может выбрать следующие виды страхования: КАСКО Страхование автомобиля от угона и ущерба; ОСАГО — обязательное страхование гражданской ответственности владельцев транспортных средств; ДСАГО — ряд дополнительных программ: страхование водителя и пассажиров от аварии, эвакуация с места аварии, страхование только по риску угона. Клиент может выбрать только один вид страхования.^[37]

Следующая диаграмма IDEF3 (рис.20 б) показывает процесс проверки транспортных средств. Инспектор должен проверить повреждение транспортных средств, проверить всю необходимую документацию и посмотреть результаты медицинского осмотра владельца транспортного средства. Результат проверки может быть либо доказательством оплаты, либо отказом от них.

Рис. 20 б) Осмотр автотранспорта

3.2.3. Анализ цен

Анализ затрат — это соглашение об учетной записи, используемой для сбора затрат, связанных с работой, для определения общей стоимости процесса. Для этого вам нужно будет создать Центры затрат (Cost centers), которые могут быть интерпретированы как статьи расхода. При проведении анализа затрат в BPwin сначала устанавливаются единицы времени и денег, а затем описываются центры затрат и наконец, для каждой операции на диаграмме декомпозиции назначается продолжительность, частота выполнения этой работы в рамках общий процесс (частота) и сумма для каждого МВЗ, т. е. устанавливают стоимость каждой работы по каждой статье потребления. Этот очень упрощенный принцип расчета справедлив, если работа выполняется последовательно.^{[38] [39]}

Возьмём диаграмму «Страховой платеж» и рассчитаем стоимость. Мы предполагаем, что вовлечены в этот процесс: Менеджер, который принимает решение; три инспектора, которые рассматривают документы и проводят проверку транспорта; один кассир, который дает деньги. Ежедневно получаем 40 заявок на страхование. Предположим, что зарплата инспектора — 300 р / сут. 500 р / сут, а кассир — 200 р / сут. Аналогичным образом распределяем диаграммы затрат «Консультации» и «Заключение договора». Создадим следующие центры затрат:

зарплата;

оборудование;

расходные материалы;

стоимость управления.

Результаты анализа затрат приведены в таблице 4:

Стоимостной анализ процесса страхования Таблица 4

Activity Name	Activity Cost (Рубль)	Cost Center	Cost Center Cost (Рубль)
Страхование автогражданской ответственности	5 300,00	зарплата	2 900,00
		оборудование	200,00
		расходные материалы	900,00
		управление	1 300,00
консультации	650,00	зарплата	300,00
		расходные материалы	150,00
		управление	200,00
заключение договоров	1 000,00	зарплата	700,00
		расходные материалы	200,00
		управление	100,00
страховые выплаты	3 000,00	зарплата	1 600,00
		оборудование	200,00
		расходные материалы	400,00
		управление	800,00
рассмотрение документов	350,00	оборудование	50,00
		расходные материалы	100,00
		управление	200,00
осмотр автотранспорта	300,00	зарплата	300,00
принятие решения	750,00	зарплата	500,00
		расходные материалы	50,00
		управление	200,00
выплата страхового возмещения	300,00	зарплата	200,00
		оборудование	50,00
		расходные материалы	50,00

Как видим, на процесс страховых выплат уходит 5300руб. день.

3.2.4. Построение DFD-диаграмм

Для документирования механизмов передачи и обработки информации в системе используются диаграммы потоков данных (Data Flow Diagrams). Диаграмма DFD обычно построена для визуализации текущей активности системы документооборота в вашей организации. Часто диаграммы DFD используются в качестве дополнительной модели бизнес-процессов, запущенных в IDEF0.^[40]

Диаграмма DFD показана на рисунке 21:

Рис.21. DFD-диаграмма «Беседа с клиентом»

На диаграмме показан процесс разговора с клиентом, в котором он принимает решение о заключении договора или нет.^[41]

Внешние ссылки: клиент, законодательство и страховщик. Страховщик получает документы и консультирует клиентов на основании требований законодательства.

3.2.5. Построение диаграммы дерева узлов и диаграмм FEO

Дерево узлов — представление отношений между родительскими и дочерними узлами модели IDEF0 в виде древовидного графика. Узлы диаграмм используют традиционное дерево иерархии, в котором верхний узел (блок) соответствует контекстной диаграмме и декомпозиции нижнего уровня потомства.^[42]

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

Рис. 22 Диаграмма дерева узлов

FEO-диаграмма — диаграмма-иллюстрация отдельных фрагментов модели и иллюстрирует альтернативные точки зрения или для специальных целей, которые явно не поддерживаются синтаксисом IDEFO. FEO-диаграмма позволяет проиллюстрировать различные сценарии, чтобы показать разные точки зрения, чтобы показать отдельные части, которые явно не поддерживаются синтаксисом IDEF0.^[43] FEO-диаграмма, показанная на рисунке 23.

Рис. 23. FEO-диаграмма

3.3. Описание модели TO-BE

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

Рис. 24. Модель TO BE

Таким образом, изменение процесса консультаций сократит время консультаций, улучшит качество обслуживания клиентов и, следовательно, конкурентоспособность фирмы. В результате можно будет опустить ненужные и дорогостоящие процессы и перейти непосредственно к выполнению контракта с клиентом.^[44]

ГЛАВА 4. Построение модели данных в Erwin

ERwin — средство разработки структуры базы данных (БД). ERwin сочетает в себе графический интерфейс Windows, инструменты для рисования редакторов ER-диаграмм для создания логической и физической модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных.^[45]

4.1. Проектирование логической и физической модели данных

В Erwin есть два уровня моделирования: логический и физический.

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

Рис. 25. Логическая модель данных

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

Таблица 5

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

Для каждого объекта мы определяем набор атрибутов.

Сущность «Клиент» содержит следующие атрибуты: «Идентификатор клиента» — первичный ключ; «номер автомобиля», «номер сотрудника» — внешние ключи и атрибуты «имя», «дата рождения», «адрес» и «паспорт», описывающие личные данные клиента.

Сущность «Договор» содержит следующие атрибуты:

номер контракта (первичный ключ);

номер транспортного средства;

Дата страхования

Размер страховки.

Сущность «Транспортное средство» содержит информацию о существующих транспортных средствах клиента и включает в себя следующие атрибуты:

№ машины (первичный ключ);

Цвет;

марки автомобилей;

Год.

Сущность «Полис» включает в себя следующий набор атрибутов:

номер полиса (первичный ключ);

номер договора (внешний ключ);

дата выдачи;

срок окончания.

Сущность «Сотрудник» содержит информацию о сотрудниках и имеет следующие атрибуты:

Номер сотрудника (первичный ключ);

Имя;

Дата рождения;

Паспорт.

Сущность «Взносы» содержит следующие атрибуты:

Номер квитанции (первичный ключ);

Дата платежа;

Сумма;

номер договора (внешний ключ).

Дадим объяснения каждой взаимосвязи между сущностями.

Тип отношения между таблицами «Клиент» и «Договор» — один к одному, т. е. каждый клиент заключает один договор для каждого транспортного средства.

Тип отношения между таблицами «Транспорт» и «Клиент» — один к одному, то есть каждый клиент имеет одну копию страховки транспортных средств по одному контракту.

Тип отношения между таблицами, «Договор» и «Полис» — один к одному, т. е. для каждого договора, клиенту предоставляется один полис.

Тип отношения между таблицами «Сотрудник» и «Клиент» не идентифицируется. Каждый сотрудник может обслуживать несколько клиентов.

Тип отношения между таблицами, «Договор» и «Взносы» — один-ко-многим, поскольку каждый контракт получает от клиента несколько вкладов.

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

Рис. 26. Физическая модель данных

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

4.2. Прямое и обратное проектирование

Процесс создания физической схемы базы данных из логической модели данных называется прямым проектированием. Создайте пустую базу данных «Страхование» в СУБД MS Access. Основной целью базы данных «Страхование» являются функции автоматизации учета клиентов и контрактов. Используя встроенные функции, Erwin создадим базу данных «Страхование». База данных «Страхование» будет включать 6 таблиц. (Рисунок 27)

Рис.27. База данных «Страхование»

Схема данных предметной области представлена на рисунке 28.

Рис. 28. Схема данных

Процесс создания логической модели из физической базы данных называется обратным проектированием. Создадим новую логико-физическую модель в Erwin. Используя меню Tools / Reverse Engineer From, мы можете указать источник обратного проектирования – базу данных. С помощью кнопки Browse выбираем файл, содержащий базу данных.^[46] Результат обратного проектирования показан на рисунке 29.

Рис. 29. Обратное проектирование

Таким образом, мы можем сказать, что ERwin — мощный, но простой в использовании инструмент для проектирования баз данных. Кроме того, программа Erwin совместима с большинством используемых в настоящее время СУБД, что является преимуществом программы.

Заключение

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

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

В нотации IDEF0 мы показали все процессы в системе и отразили отношения между ними. Используя схему IDEF3, была смоделирована последовательность действий при заключении договора страхования и осмотре транспортных средств. Встроенный механизм расчета стоимости позволил нам оценить и проанализировать затраты на процесс страхования. На основе модели мы определили недостатки процесса и предложили усовершенствования модели TO BE. Инструмент Erwin помог нам создать предметную область базы данных.

Таким образом, все задачи, заданные в проекте курса, можно считать завершенными.

Итак, мы видели, что инструменты BPwin и Erwin могут значительно облегчить работу по проектированию и анализу бизнес-процессов.

Список использованных источников

1. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. – М.: Изд-во стандартов, 1990.

2. ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств»

3. ГОСТ Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования»

4. Вендров А.М. CASE — технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c.

5. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c.

6. Грекул, В.И. Проектирование информационных систем: учебное пособие [Текст] / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.: Интернет-Ун-т Информ. технологий, 2005. – 304 с.

7. Грей К.Ф., Ларсон Э.У. Управление проектами: практическое руководство. [Текст] / К.Ф. Грей, Э.У. Ларсон . М.: КНОРУС, 2005. – 528 с.

8. Калянов Г.Н. Case-технологии. Современные методы и средства проектирования ИС. [Текст] / Г.Н. Калянов – М.: СИНТЕГ, 2006. – 316 с.

9. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. [Текст] / С.В. Маклаков – М.: ДИАЛОГМИФИ, 2004. — 327 c.

10. Марка Д.А. Методология структурного анализа и проектирования. [Текст] / Д.А. Марка, К. МакГоуэн – М.: МетаТехнология, 2005. – 240 с.

11. Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с.

12. Титоренко Г.А. Автоматизированные информационные технологии в экономике. [Текст] / Г.А. Титоренко – М.: Компьютер, ЮНИТИ, 2004.– 369c.

13. Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст] / В.Е. Туманов, С.В. Маклаков – М.: Диалог-МИФИ, 2007. — 333 с.

14. Федотова Д.Э. CASE-технологии: Практикум [Текст] / Д.Э. Федотова, Ю.Д. Семенов, К.Н. Чижик– М.: Горячая линия-Телеком, 2005. – 157c.

15. Верников Г.В. Описание стандартов IDEF. [Электронный ресурс]/ Г.В. Верников (Режим доступа: www.vernikov.ru. Дата просмотра: 10.01.2018г.)

16. Верников Г.В. Основные методологии обследования организаций. [Электронный ресурс]/ Г.В. Верников (Режим доступа: http://www.cfin.ru. Дата просмотра: 11.01.2018г.)

17. Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 12.01.2018г.)

18. Рубцов С.В. SADT: процесс моделирования. [Электронный ресурс]/ С.В. Рубцов (Режим доступа: http://www.interface.ru. Дата просмотра: 10.01.2018г.)

19. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 13.01.2018г.)

20. Свечников А.А. Моделирование работы центра страхования. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://www.iteam.ru. Дата просмотра: 10.01.2018г.)

Приложение 1.

Подходы к проектированию ИС

Приложение 2.

Консультация

Удовлетворяют условия?

Продление

договора

Страховые выплаты

Наступил страховой случай?

Заключение договора

да

да

нет

нет

Получение выплат

1. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. – М.: Изд-во стандартов, 1990. ↑

2. Калянов Г.Н. Case-технологии. Современные методы и средства проектирования ИС. [Текст] / Г.Н. Калянов – М.: СИНТЕГ, 2006. – 316 с. ↑

3. Марка Д.А. Методология структурного анализа и проектирования. [Текст] / Д.А. Марка, К. МакГоуэн – М.: МетаТехнология, 2005. – 240 с. ↑

4. Верников Г.В. Описание стандартов IDEF. [Электронный ресурс]/ Г.В. Верников (Режим доступа: www.vernikov.ru. Дата просмотра: 10.01.2018г.) ↑

5. Верников Г.В. Описание стандартов IDEF. [Электронный ресурс]/ Г.В. Верников (Режим доступа: www.vernikov.ru. Дата просмотра: 10.01.2018г.) ↑

6. Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст] / В.Е. Туманов, С.В. Маклаков – М.: Диалог-МИФИ, 2007. — 333 с. ↑

7. Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст] / В.Е. Туманов, С.В. Маклаков – М.: Диалог-МИФИ, 2007. — 333 с. ↑

8. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

9. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

10. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

11. ГОСТ Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования» ↑

12. Рубцов С.В. SADT: процесс моделирования. [Электронный ресурс]/ С.В. Рубцов (Режим доступа: http://www.interface.ru. Дата просмотра: 10.01.2018г.) ↑

13. Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст] / В.Е. Туманов, С.В. Маклаков – М.: Диалог-МИФИ, 2007. — 333 с. ↑

14. Калянов Г.Н. Case-технологии. Современные методы и средства проектирования ИС. [Текст] / Г.Н. Калянов – М.: СИНТЕГ, 2006. – 316 с. ↑

15. Верников Г.В. Основные методологии обследования организаций. [Электронный ресурс]/ Г.В. Верников (Режим доступа: http://www.cfin.ru. Дата просмотра: 10.01.2018г.) ↑

16. Марка Д.А. Методология структурного анализа и проектирования. [Текст] / Д.А. Марка, К. МакГоуэн – М.: МетаТехнология, 2005. – 240 с. ↑

17. Рубцов С.В. SADT: процесс моделирования. [Электронный ресурс]/ С.В. Рубцов (Режим доступа: http://www.interface.ru. Дата просмотра: 10.01.2018г.) ↑

18. Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 10.01.2018г.) ↑

19. ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» ↑

20. Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑

21. Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑

22. Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑

23. Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑

24. Грей К.Ф., Ларсон Э.У. Управление проектами: практическое руководство. [Текст] / К.Ф. Грей, Э.У. Ларсон . М.: КНОРУС, 2005. – 528 с. ↑

25. Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 10.01.2018г.) ↑

26. Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 10.01.2018г.) ↑

27. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

28. Свечников А.А. Моделирование работы центра страхования. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://www.iteam.ru. Дата просмотра: 10.01.2018г.) ↑

29. Вендров А.М. CASE — технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑

30. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

31. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

32. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

33. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

34. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

35. Свечников А.А. BPWin — Rational Rose — Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑

36. Вендров А.М. CASE — технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑

37. Свечников А.А. Моделирование работы центра страхования. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://www.iteam.ru. Дата просмотра: 10.01.2018г.) ↑

38. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑

39. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. [Текст] / С.В. Маклаков – М.: ДИАЛОГМИФИ, 2004. — 327 c. ↑

40. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑

41. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑

42. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. [Текст] / С.В. Маклаков – М.: ДИАЛОГМИФИ, 2004. — 327 c. ↑

43. Вендров А.М. CASE — технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑

44. Вендров А.М. CASE — технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑

45. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑

46. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑

ПЕРЕЧЕНЬ ВОПРОСОВ
ДЛЯ ПОДГОТОВКИ К ЭКЗАМЕНУ

по дисциплине

«Устройство и
функционирование информационной
системы»

для студентов
специальности

230401 «Информационные
системы (по отраслям)»

Перечень
теоретических вопросов

1. Система: понятия
   системы, информационной системы,
   автоматизированной информационной
   системы.

2. Информационные
   системы: характеристика этапов развития
   информационных систем 50-80-х годов,
   особенности, основные функции, цели
   использования для каждого этапа
   развития.

3. Информационные
   системы: характеристика этапов развития
   информационных систем 1980-2000-х годов,
   особенности данных этапов, основные
   функции, цели использования для каждого
   этапа развития.

4. Информационная
   система: понятие, основные свойства.

5. Информационная
   система: понятие, основные задачи.

6. Информационные
   системы управления: уровни управления,
   основные задачи операционного,
   тактического, стратегического уровня
   управления, примеры информационных
   систем для каждого уровня управления.

7. Автоматизация
   производства: понятие автоматизации,
   характеристика элементов автоматизации
   производства (станки с ЧПУ, промышленные
   роботы, автоматизированные складские
   системы, системы контроля качества).

8. Автоматизация:
   цели автоматизации деятельности
   организации, примеры целей автоматизации
   для различных систем.

9. Информационные
   системы: ручные, автоматические и
   автоматизированные информационные
   системы, характеристика систем.

10. Информационные
    системы управления: характеристика и
    назначение типов информационных систем
    управления.

11. Обеспечивающие
    подсистемы информационных систем: виды
    обеспечений информационных систем,
    характеристика функциональной части
    информационной системы, пример
    функциональных подсистем информационной
    системы.

12. Обеспечивающие
    подсистемы информационных систем: виды
    обеспечивающих подсистем, характеристика
    информационного обеспечения.

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

14. Обеспечивающие
    подсистемы информационных систем: виды
    обеспечивающих подсистем, характеристика
    технического обеспечения, централизованное
    и децентрализованное техническое
    обеспечение.

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

16. Обеспечивающие
    подсистемы информационных систем: виды
    обеспечивающих подсистем, характеристика
    математического, лингвистического
    обеспечения информационных систем.

17. Обеспечивающие
    подсистемы информационных систем: виды
    обеспечивающих подсистем, характеристика
    кадрового и эргономического обеспечения
    информационных систем.

18. Информационные
    системы управления: классификация
    информационных систем по функциональному
    признаку, функции производственных
    систем, систем маркетинга, финансовых,
    кадровых и учетных систем, примеры
    информационных систем данных видов.

19. Информационные
    системы управления: классификация
    систем по уровню управления, примеры
    информационных систем управления.

20. Информационные
    системы: классификация систем по способу
    организации, характеристика систем на
    основе файл-серверной архитектуры,
    клиент-серверной архитектуры,
    многоуровневой архитектуры, характеристика
    информационных систем на основе
    архитектуры «толстого» и «тонкого»
    клиента.

21. Информационные
    системы: классификация по признаку
    структурирования задач, примеры систем
    по классификации.

22. Базовые
    типы информационных систем: особенности
    фактографических и документальных
    информационных систем.

23. Базовые типы
    информационных систем: документальные
    и гипертекстовые информационные
    системы.

24. Базовые
    типы информационных систем: экспертные
    системы, системы искусственного
    интеллекта, отличия экспертных систем,
    основные подсистемы экспертных систем.

25. Жизненный цикл
    программного продукта: структура по
    стандарту ISO/IEC
    12207, характеристика и задачи основных
    процессов жизненного цикла.

26. Жизненный цикл
    программного продукта: по стандарту
    ISO/IEC
    12207,
    характеристика вспомогательных
    процессов жизненного цикла.

27. Жизненный цикл
    программного продукта: структура по
    стандарту ISO/IEC
    12207,
    организационные процессы жизненного
    цикла, их характеристика.

28. Модель жизненного
    цикла автоматизированной системы:
    понятие, характеристика каскадной
    модели, этапы, особенности каскадной
    модели.

29. Модель жизненного
    цикла автоматизированной информационной
    системы: характеристика спиральной
    модели, особенности модели.

30. Модель жизненного
    цикла автоматизированных информационных
    систем: модель быстрой разработки
    (RAD-модель),
    характеристика, особенности модели.

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

32. Метод проектирования
    информационных систем: понятие метода
    проектирования, составляющие метода
    проектирования.

33. Технология
    проектирования информационных систем:
    понятие, требования к технологии
    проектирования.

34. Технология
    проектирования автоматизированных
    информационных систем: классификация
    методов проектирования автоматизированных
    информационных систем, структурный и
    объектно-ориентированный подход.

35. Технологии
    проектирования: краткая характеристика
    стандарта проектирования, стандарта
    оформления проектной документации,
    стандарта интерфейса пользователя.

36. Реинжиниринг
    бизнес-процессов: понятие реинжиниринга,
    изменение бизнес-процессов при
    реинжитиринге.

37. CASE-средства:
    понятие, классификация CASE-средств.

38. CASE-средства:
    понятие, преимущества использования
    CASE-средств
    при проектировании.

39. Методология
    функционального моделирования
    информационных систем IDEF0:
    назначение системы, описание основных
    элементов методологии, диаграмма,
    контекстная диаграмма процессов,
    декомпозиция.

40. Методология
    функционального моделирования IDEF0:
    назначение методологии, синтаксис и
    семантика моделей.

41. Методология
    описания бизнес-процессов IDEF3:
    особенности методологии, отличия,
    диаграммы, единица работы, перекресток,
    описание связи процессов.

42. Методология
    описания бизнес-процессов IDEF3:
    особенности методологии, соединения:
    «И-соединения», «ИЛИ-соединения»,
    синхронные и асинхронные соединения,
    примеры использования на диаграмме.

43. Методология
    описания бизнес-процессов IDEF3:
    особенности, уровень использования,
    требования к описанию бизнес-процессов
    в методологии.

44. Структурный анализ
    потоков данных (DFD):
    назначение диаграмм потоков данных,
    основные элементы нотации, применение.

45. Структурный анализ
    потоков данных (DFD):
    назначение и применение диаграммы,
    синтаксис и семантика потоков данных.

46. Оценки качества
    информационной системы: стандарты,
    описывающие процедуры определения
    ГОСТ Р ИСО/МЭК 9126-93, характеристики
    качества: функциональные возможности,
    надежность, практичность, эффективность,
    сопровождаемость, мобильность.

47. Процесс оценивания
    качества информационной системы: этапы
    оценки, установка критериев оценки.

48. Организация труда
    при разработке информационной системы:
    структура разделения работ, составление
    временного графика выполнения работ.
    Трудозатраты, распределение трудозатрат.

49. Оценка ресурсов
    для реализации проекта: оценка объемов
    и сложности программного продукта.

50. Оценка рисков при
    выполнении программного проекта:
    характеристика финансовых, рисков,
    организационных рисков, рисков
    планирования.

Содержание
практического задания

1. На основании
описания предметной области Гостиница,
используя методологию SADT, построить
функциональную модель, описывающую
протекающие в ней основные бизнес –
процессы.

Описание
предметной области Гостиница.

Вам необходимо
автоматизировать деятельность
администратора гостиницы. Основной
задачей информационной системы
Гостинницы является отслеживание
финансовой стороны работы гостиницы.

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

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

Сдача номеров
может выполняться непосредственно при
въезде либо бронироваться заранее.

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

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

Учет финансового
состояния определяется ежемесячно.

2. На
основании описания предметной области
Страховая компания, используя методологию
SADT, построить функциональную модель в
методологии IDEF0,
описывающую протекающие в ней основные
бизнес – процессы. Декомпозицию возможно
выполнить в методологии IDEF3.

Описание предметной области Страховая компания.

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

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

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

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

3. На основании описания предметной области Ломбард, используя методологию sadt, построить функциональную модель в нотации idef0, описывающую протекающие в ней основные бизнес – процессы.

Описание предметной области Ломбард.

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

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

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

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

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

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

Описание предметной области Реализация готовой продукции.

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

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

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

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

При окончании
товара на складе выполняется заказ
товара у поставщиков.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Разработка информационной системы ‘Страхование имущества граждан’

Введение

Наименование системы

Экономическая информационная система страхования имущества граждан.

Шифр темы или шифр (номер) договора: ИК-120

Заказчиком системы является страховая организация «Роскомстрах»

Адрес заказчика: г. Вологда, ул. Мира, 76.

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

Адрес разработчика: г. Череповец, ул. Первомайская, д. 48.

Перечень документов, на основании которых создается система, кем и когда
утверждены эти документы: Договор №89 на разработку ИС «Страхование имущества
граждан», техническое задание. Утвержден компанией-разработчиком и
компанией-заказчиком 27.03.2012.

Начало работы по созданию системы: 27.03.2012

Окончание работы по созданию системы: 27.05.2012

Сведения об источниках и порядке финансирования работ: Работы по
разработке и внедрению информационной системы оплачиваются в соответствие с
договором № 89 от «27» марта 2012 г.

Порядок оформления и предъявления заказчику результатов работ: Порядок
оформления и предъявления Заказчикам результатов работ по созданию системы
должен соответствовать требованиям Комплекса стандартов и руководящих
документов на автоматизированные системы: ГОСТ 34.602-89.

Назначение и цели создания (развития) системы:

Назначение системы: Назначением информационной системы является
автоматизация расчета страховок имущества граждан.

Цели создания системы:

·      повышение оперативности обработки информации;

·      снижение трудоемкости операций по страхованию имущества
граждан;

·        уменьшение числа ошибок при страховании имущества граждан.

Характеристика объектов автоматизации

Сведения об объекте автоматизации

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

Требования к системе

Требования к системе в целом

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

Надежность системы определяется правильностью вывода информации
пользователем.

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

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

Численность персонала АИС должна определяться исходя из потребностей
бизнес-процессов предприятия. Численность пользователей системы определяется
параметрами объекта автоматизации.

Рекомендуемая численность для эксплуатации ИС:

·      Администратор — 1 штатная единица;

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

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

Использовать систему необходимо согласно руководству пользователя.

Перспективы развития, модернизации системы.

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

Вероятностно-временные характеристики, при которых сохраняется целевое
назначение системы:

Минимальный срок эксплуатации:

·      системы в целом — не менее 3 лет;

·        модулей функциональных подсистем — не менее 1 лет;

·        комплекса технических средств — не менее 5 лет (при
проведении соответствующей технической модернизации и развития).

Требования к функциям (задачам), выполняемым системой

Система «Страхование имущества» предназначена для выполнения

следующих функций:

·      содержание информации о страховых услугах;

·        учет застрахованного имущества граждан;

·        расчет стоимости страхования в зависимости от выбранных
критериев объекта страхования;

·        формирование отчетов о застрахованном имуществе;

·        формирование отчетов о застрахованных клиентах.

Все отчеты могут быть экспортированы в MS Office.

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

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

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

·        перечисление всех видов объектов, предоставляемых страховой
компанией, с указанием стоимости каждого из них;

·        сведения обо всех страховщиках страховой компании;

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

Требования к программному обеспечению: ОС Windows NT, наличие пакета MS Office.

Требования к техническому обеспечению: Тип процессора Pentium 4, ОЗУ 256 Мб, Тип монитора SVGA.

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

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

Таблица 1 — Стадии и этапы работ по созданию системы

Стадии	Этапы работ	Сроки выполнения
1. Формирование требований к ИС	1.1. Обследование объекта и обоснование необходимости создания ИС	05.02.12 — 25.02.12
	1.2. Формирование требований пользователя к ИС	25.02.12 — 29.02.12
2. Разработка концепции ИС	2.1. Проведение необходимых научно-исследовательских работ	01.03.12 — 10.03.12
	2.2. Разработка вариантов концепции ИС и выбор варианта концепции ИС, удовлетворяющего требованиям пользователя	10.03.12 — 20.03.12
	2.3. Выбор концепции	20.03.12 — 21.03.12
3. Техническое задание	3.1. Разработка и утверждение технического задания на создание ИС	22.03.12 — 25.03.12
4. Эскизный проект	4.1. Разработка предварительного эскизного проектного решения по системе и ее частям	27.03.12 — 07.04.12
	4.2. Разработка документации на ИС и ее части	07.04.12 — 14.04.12
5. Технический проект	5.1. Разработка проектного решения по системе и ее частям	15.04.12 — 30.04.12
	5.2. Разработка документации на ИС и ее части	01.05.12 — 10.05.12
6. Рабочая документация	6.1. Разработка рабочей документации на систему и ее части	11.05.12 — 20.05.12
7. Ввод в действие	7.1. Подготовка объекта автоматизации к вводу ИС в действие	21.05.12 — 23.05.12
	7.2. Подготовка персонала	23.05.12 — 25.05.12
	7.3. Проведение предварительных испытаний	25.05.12 — 27.05.12
	7.4. Проведение опытной эксплуатации	27.05.12 — 29.05.12
	7.5. Введение в эксплуатацию	01.06.12
8.Сопровождение	8.1. Работы по гарантии	(Да)
	8.2. Послегарантийное обслуживание	(Да)

Перечень организаций, участвующих в работах по созданию системы:

        Организация-заказчик, для которой создается ИС и которая
обеспечивает финансирование, приемку работ и эксплуатацию ИС.

2        Организация-разработчик, которая осуществляет работы по созданию
ИС и ее сопровождению.

Порядок контроля и приемки системы

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

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

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

Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие

1.     Изменения, которые необходимо осуществить в объекте автоматизации.

Дополнительных изменений в объекте автоматизации не требуется.

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

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

Необходимо, в соответствии с проектными решениями, провести обучение
обслуживающего персонала.

Требования к документированию

Документация, разрабатываемая в соответствии с требованиями настоящего
технического задания, должна соответствовать требованиям ГОСТ 34.201-89.

Полный перечень документации включает:

1)     Техническое задание.

2)      Пояснительная записка.

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

1)     ГОСТ 34.602-89;

Составили

Наименование организации, предприятия	Должность исполнителя	Фамилия, имя, отчество	Подпись	Дата
ИМИТ (филиал) СПбГПУ	студент	Саукова Ксения Александровна		27.03.2012

Согласовано

Наименование организации, предприятия	Должность	Фамилия, имя, отчество	Подпись	Дата
ООО «Роскомстрах»	Директор	Беляков Антон Викторович		27.03.2012

1. Общесистемная часть

 

1.1 Общая
характеристика экономического объекта

Главный офис ООО «Роскомстрах» находится в центре города Вологда, на
улице Мира, дом 76. Он был открыт 1 июня 1995 года. Уже в 1997 году компания
насчитывала более 15 точек обслуживания во всех районах города, а в 2000 году
застраховала 100 тысячного клиента.

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

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

Постоянное обучение персонала, внедрение новых методик, инновационные
решения в сфере страхования — всё это положительно характеризует деятельность
ООО «Роскомстрах».

Основные документы, определяющие функционирование ООО «Роскомстрах» в
целом:

1.     устав ООО «Роскомстрах»;

2.       приказ от 01.06.1995 N 1 «Об утверждении положений о порядке
страхования имущества граждан»;

.        внутренний регламент ООО «Роскомстрах»;

.        лицензия на оказание страховых услуг.

В состав ООО «Роскомстрах» входит 30 отделений, 20 точек обслуживания
клиентов, отдел по работе с корпоративными клиентами, который осуществляет
страхование как крупных, так и малых предприятий. Все отделения и точки
обслуживания находятся в подчинении у генерального директора. Но контроль за
оперативной работой и координацией сотрудников возложен на начальника данной
организации.

Организационная структура ООО «Роскомстрах» представлена на рисунке 1.

Рисунок 1 — Организационная структура ООО «Роскомстрах»

Можно выделить следующие основные направления деятельности ООО
«Роскомстрах»:

1.     страхование имущества граждан;

2.       страхование коммерческого имущества;

.        консультирование граждан по вопросам страхования;

.        возмещение ущерба и личное материальное обеспечение граждан;

.        предупреждение страхового случая и минимизация ущерба;

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

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

В соответствии с основными направлениями деятельности можно выделить
основные бизнес-процессы:

1.     проведение бухгалтерского учета;

2.       оказание страховых услуг;

.        оказание консультационных услуг;

.        возмещение ущерба.

1.2
Выделение функциональной подсистемы АЭИС

Для исследования был взят один из отделов ООО «Роскомстрах» — отдел
работы с клиентами.

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

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

В соответствии с этим, отдел работы с клиентами выполняет следующие
функции:

· ведение учета всех клиентов;

·        ведение статистики договоров страхования;

·        ведется учет услуг страховой организации;

·        ведется учет страховщиков;

·        ведение статистики страхования, сравнение с результатами
прошлых лет.

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

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

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

Можно представить функциональную модель бизнес-процессов (Business
Process Modeling). Наиболее широко используемая методология описания
бизнес-процессов — стандарт IDEF0. Модели в нотации IDEF0 предназначены для
высокоуровневого описания бизнеса компании в функциональном аспекте. Данная
модель представлена на рисунке 3-4 (для большей точности была проведена
двухуровневая детализация).

Рисунок 3 — Функциональная модель страхования (1 уровень)

Рисунок 4 — Функциональную модель страхования (2 уровень)

Кроме функциональной модели бизнес-процессов была построена диаграмма
описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow
Diagramming), позволяет отразить последовательность работ, выполняемых по ходу
процесса, и потоки информации, циркулирующие между этими работами. Данная
диаграмма представлена на рисунках 5-6 (для большей точности была проведена
двухуровневая детализация).

Рисунок 5 — Диаграмма описания потоков данных (1 уровень)

Рисунок 6 — Диаграмма описания потоков данных (2 уровень)

1.3
Технико-экономическое обоснование необходимости разработки или реинжиниринга
функциональной подсистемы АЭИС

страхование информация реинжиниринг

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

Недостатки отдела:

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

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

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

Достоинства отдела работы с клиентами:

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

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

1.     Ручная обработка большого количества информации.

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

Можно выделить следующие необходимые ресурсы для реализации выбранной
подсистемы «Страхование имущества граждан»:

.       финансовые;

2.       трудовые;

.        материальные.

Для разработки подсистемы «Страхование имущества граждан» необходимы
денежные средства. Они могут быть выделены как самой организацией, в рамках
проекта автоматизации страховых компаний Вологодской области, так и спонсорами
ООО «Роскомстрах».

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

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

2. Проектная часть

 

2.1
Постановка задачи на разработку функциональной подсистемы

 

.1.1
Организационно-экономическая сущность задачи

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

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

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

Целями данной функциональной подсистемы является:

1.     повышение качества обработки информации.

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

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

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

.        улучшение качества и минимизация временных затрат на проверку
документов и оформление договоров страхования имущества граждан;

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

.        упрощение доступа к информации о страховании имущества граждан;

.        сокращение бумажных архивов.

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

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

2.1.2
Описание исходной (входной) информации

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

а) ФИО гражданина — предпринимателя/наименование юридического лица;

б) ИНН;

в) паспортные данные;

г) место и дата рождения;

д) юридический адрес (место нахождения), телефон;

е) вид деятельности физического лица;

ж) предоставляемые услуги.

2.1.3
Описание результатной (исходной) информации

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

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

2.1.4
Описание алгоритма решения задачи

Основной задачей в системе «Страхование имущества граждан» является
расчет стоимости премии объекта страхования. Для определения расчетных
показателей страховой статистики используются следующие исходные данные:

число объектов страхования;

число страховых событий;

число пострадавших объектов в результате страховых событий;

сумма собранных страховых платежей;

сумма выплаченного страхового возмещения;

страховая сумма для любого объекта страхования;

страховая сумма, приходящаяся на поврежденный объект страховой
совокупности.

Обозначения:

число страховых событий    C      

число объектов страхования N     

число пострадавших объектов       M     

общая сумма страховых выплат     Sв   

общая страховая сумма всех застрахованных объектов     S     

общая страховая сумма, приходящаяся на поврежденные объекты     Sп

общая сумма страховых премий    П    

система страхование информация реинжиниринг

Показатель	Порядок расчёта
1) Показатель убыточности страховой суммы  (показатель измеряется в границах от 0 до 1, рассматривается как мера величины рисковой премии)	Sв/ S
2) Частота страховых событий (показатель определяет сколько страховых событий приходится на один объект страхования).	C/N
3) Опустошительность страхового события или коэффициент кумуляции риска (показатель определяет сколько застрахованных объектов застигает то или иное событие, минимальное значение -1)	M/C
4) Степень ущербности (степень убыточности) (показатель измеряется в границах от 0 до 1)	Sв/ Sп
5) Средняя страховая сумма на один поврежденный объект	Sп/M
6) Средняя страховая сумма на один договор (объект) страхования	S/N
7) Тяжесть риска	Sв/П*100%
Среднее обеспечение по поврежденным объектам	Sв/M
9) Частота ущерба (вероятность) (показатель выражает частоту наступления страхового события)	(C/N)*(M/C)=M/N

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

/( N*С*М*S)

2.1.5
Описание используемой условно-постоянной информации

Для расчета стоимости страхования объекта используется справочник
«Событие страхования». Он включает в себя:

­   код события;

­    название события;

­    стоимость;

­    пр.

2.2
Разработка программного обеспечения подсистемы

 

.2.1 Выбор
языка разработки и технологии проектирования ЭИС

Разработка данного проекта велась в среде программирования Delphi. Delphi
— это среда разработки, в которой в качестве языка программирования
используется объектно-ориентированный язык программирования Delphi. Язык Delphi
— это язык, в основе которого лежит Object Pascal.

Данный язык отвечает всем современным требованиям, применяемым к языкам
программирования высокого уровня.

В качестве технологии проектирования было выбрано индустриальное автоматизированное
проектирование, которое разбивается на два подкласса: автоматизированное
(использование CASE-технологии) и
типовое (параметрически-ориентированное или модельно-ориентированное). Из
данных подклассов был выбран второй, то есть типовое проектирование.

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

2.2.2
Объектно-ориентированная модель подсистемы «Страхование имущества граждан»

Для построения объектно-ориентированной модели было использовано средство
проектирования Rational
Rose, которое является мощным
инструментом анализа и проектирования объектно-ориентированных программных
систем. Он позволяет моделировать системы до написания кода, что позволяет с
самого начала быть уверенным в адекватности их архитектуры.

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

На данной диаграмме представлено три действующих лица: начальник отдела,
страхователь и оператор по заполнению БД (см. рис. 7).

Рисунок 7 — Диаграмма вариантов использования

Далее была построена диаграмма классов (class
diagram). Она служит для отображения структуры совокупности взаимосвязанных
классов объектов. На ней представлено четыре класса: менеджер, начальник,
руководитель, кассир.

Атрибуты каждого класса отображаются под названием класса с определенным
типом значений и действия классов. Кроме этого, на диаграмме классов показаны
отношения ассоциации и зависимости (см. рис.8). После диаграммы классов были
разработаны диаграммы взаимодействия: последовательности и кооперации.
Диаграммы взаимодействия объектов (Interaction diagram)
отображают динамическое взаимодействие объектов в рамках одного прецедента
использования. Диаграммы последовательности организованы по времени, на
кооперативных диаграммах отображается та же информация, но акцентируется
внимание на статическом взаимодействии объектов (см. рис. 9-10).

Рисунок 10 — Диаграмма последовательности

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

На основе диаграмма последовательности была построена диаграмма
кооперации (см. рис. 11).

Рисунок 11 — Диаграмма кооперации

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

Рисунок 12 — Диаграмма состояний

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

Рисунок 13 — Диаграмма компонентов

Таким образом, диаграмма компонентов (Component diagram) отображает физические модули программного кода.

Диаграмма размещения (Deployment diagram)
отображает распределение объектов по узлам вычислительной сети. Диаграмма
размещения содержит графические изображения процессоров, устройств, процессов и
связей между ними. (Рис.14)

Рисунок 14 — Диаграмма размещения

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

2.2.3
Оценка трудоемкости разработки программного обеспечения на основе диаграммы вариантов
использования

Определение весовых показателей действующих лиц

Таблица 2 — Весовые показатели действующих лиц

Действующее лицо	Тип
Менеджер	Сложный
Руководитель	Сложный
Начальник	Сложное
Кассир	Сложный

Таким образом, общий весовой показатель составляет:

А= 4*3=12.

Определение весовых показателей вариантов использования

Таблица 3 — Весовые показатели вариантов использования

Вариант использованияТип
Расчёт стоимости	Простой
Регистрация новых клиентов	Средний
Заключение договоров	Средний
Формирование отчётности	Простой
Формирование статистики	Простой

Таким образом, общий весовой показатель вариантов использования
составляет:

US = 3*5+2*10 = 35;

В результате показатель UCCP
имеет значение:

UCCP = A+US = 35+12=47.

Определение технической сложности проекта

Таблица 4 — Техническая сложность проекта

Показатель	Описание	Вес	Значение	Значение с учетом веса	Распределенная система	2	1	2
Т2	Высокая производительность (пропускная способность)	1	5	5
Т3	Работа конечных пользователей в режиме он-лайн	1	3	3
Т4	Сложная обработка данных	1	2	2
Т5	Повторное использование кода	1	0	0
Т6	Простота установки	0,5	5	2,5
Т7	Простота использования	0,5	5	2,5
Т8	Переносимость	2	5	10
Т9	Простота внесения изменений	1	0	0
Т10	Параллелизм	1	0	0
Т11	Специальные требования к безопасности	1	0	0
Т12	Непосредственный доступ к системе со стороны внешних пользователей	1	0	0
Т13	Специальные требования к обучению пользователей	1	1	1
∑	—	—	—	28

Показатель TCF составляет:

TCF = 0,6 + (0,01*28) = 0,88.

Определение уровня квалификации разработчиков

Таблица 5 — Уровень квалификации разработчиков

Показатель	Описание	Вес	Значение	Значение с учетом веса
F1	Знакомство с технологией	1,5	5	7,5
F2	Опыт разработки приложений	0,5	5	2,5
F3	Опыт использования ООП	1	3	3
F4	Наличие ведущего аналитика	0,5	5	2,5
F5	Мотивация	1	4	4
F6	Стабильность требований	2	3	6
F7	Частичная занятость	-1	0	0
F8	Сложные языки программирования	-1	3	-3
∑	—	—	—	22,5

Значение показателя EF для
подсистемы:

F= 1,4
+ (-0,03*22,5) = 0,725;

В результате показатель UCP
составляет:

USP = UUCP*TCP*EF =
47*0,88*0,725 = 29,986.

Определение трудоемкости проекта

Первоначально необходимо определить количество человеко-часов на одну UCP: нет показателей F1-F6, которые имеют значение меньше трех и ноль показателей F7-F8 имеют значение больше трех. Поскольку общее значение равно
нулю, то следует использовать 20 человеко-часов на одну UCP.

Для подсистемы «Страхование» общее количество человеко-часов равно
20*29,986 = 599,72, что составляет 15 недель при 40-часовой рабочей неделе.

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

Инструкция по
работе

Работа с подсистемой «Страхование имущества граждан» начинается с окна
пароля. (Рис.15).

Рисунок 15 — Окно пароля данной системы

Если введён неправильно пароль, либо вообще не введён, то выскакивает
сообщение об ошибке (Рис.16).

Рисунок 16 — Сообщение об ошибке

При вводе пароля открывается главное окно программы. Оно содержит
следующие вкладки: Клиентская база, договоры, объекты страхования, расчёт
стоимости страхования (Рис.17). В данном окне можно выбрать базу, с которой
необходимо осуществить работу. Так же можно закончить работу, либо сменить
пользователя системы.

Рисунок 16 — Главное окно

При нажатии на кнопку «Клиентская база» появляется окно, в котором можно
вести учёт застрахованных клиентов, быстро находить нужных клиентов, вводить
новых клиентов и формировать отчёты о клиентах (Рис.17).

Рисунок 17 — Клиентская база

При нажатии на кнопку «Договоры» появляется окно со всеми созданными
договорами, так же можно вводить новый договор (Рис.18).

Рисунок 18 — Договор

При нажатии на кнопку «Виды страхования» появляется окно с для ввода
нового клиента и страхового объекта. Так же можно предварительно просмотреть
договор(Рис.19).

Рисунок 19 — Страховой объект

При нажатии на кнопку «Расчёт стоимости страхования» следующее окно
расчёта, где при вводе оцениваемой стоимости, НДС, коэффициента рассчитывается
размер страхового взноса (Рис.20).

Рисунок 20 — Размер страхового взноса

Для просмотра договора необходимо нажать «Предварительный просмотр» (Рис.
21).

Рисунок 21 — Договор

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

Заключение

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

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

Техническое задание было разработано в соответствии с ГОСТ 34.602-89
«Техническое задание. Требования к содержанию и оформлению».

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

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

Список использованных источников и литературы

1.    Архангельский, А.Я. Программирование в Delphi 6/А.Я.Архангельский. — М.: ЗАО
«Издательство БИНОМ», 2001 г. — 1120 с.: ил.

2.    Дунаев В.В. Базы данных. Язык SQL. / В.В. Дунаев. — СПб.: БХВ-Петербург, 2006. — 288
с.: ил.

.      Смирнова Г. Н. Проектирование экономических
информационных систем: Учебник/Г. Н. Смирнова, А .А. Сорокин, Ю. Ф. Тельнов;
Под ред. Ю. Ф. Тельнова. — М.: Финансы и статистика, 2003. — 512 с.: ил.

4.    Фаронов В.В. Delphi. Программирование на языке высокого уровня./ В.В. Фаронов. — СПб.:
Питер, 2008.-640 с.: ил.

5.    Фленов М. Е. Библия Delphi. / М. Е. Фленов — СПб.: БХВ
— Петербург, 2004. — 880 с.: ил.

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

Ручкина В.Н.,
аспирант Донецкого национального университета

IT охватывает новые области науки, техники, бизнеса. Яркий пример — сфера страхового бизнеса. Внедрение и использование современных информационных технологий становится закономерностью. В первую очередь это связано с возрастающим потоком информации, который необходимо накапливать, хранить и обрабатывать. Рост объемов документооборота страховой компании приводит:
— к увеличению числа сотрудников страховой компании;
— к увеличению расходов на ведение страхового бизнеса;
— к отсутствию гибкости в управлении страховой компанией;
— к росту цен на страховые услуги компании и, как следствие, снижению ее конкурентоспособности.

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

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

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

Первым шагом на этапе разработки и проектирования КИС является процесс построения идеальной и реальной моделей бизнеса СК («программирование бизнеса»). Проектирование бизнес-процессов проводится как с помощью классических (SADT) технологий, так и с помощью современных (UML) технологий. Подходы имеют преимущества и недостатки, но позволяют формализовать и упростить понимание деятельности компании и отдельных ее участков.

Классическая методология структурного анализа и проектирования SADT («Structured Analysis& Design Technique») позволяет описать деятельность компании с функционально-структурной точки зрения. Диаграммы, построенные с помощью этого подхода, отражают систему бизнес-процессов компании как набор функций, процедур и задач, выполняемых в компании, и описывают принципы использования потоков данных. Такие диаграммы просты для понимания специалистами различных уровней управления компании.

Методология объектно-ориентированного анализа и проектирования с помощью унифицированного языка моделирования UML («Unified Modeling Language») позволяет отразить динамику процессов компании.

Следующим шагом на этом этапе является выбор средств и систем моделирования бизнеса. Системы CASE («Computer-Assisted Software Engineering») наиболее подходят для этого. Выбор CASE зависит от выбранной методологии моделирования. Технология классического структурного моделирования полностью реализуется с помощью системы BPWin, входящей в комплекс программ Computer Associates AllFusion Modeling 4.1. В системе BPWin создаются модели процессов следующих стандартов (нотаций): IDEF0, DFD и IDEF3.

Модели на основе стандарта IDEF0 необходимы для выявления основных, не дублируемых, не избыточных и эффективных работ и правильно распределенных ресурсов. Диаграммы потоков данных (DFD) описывают функции обработки информации, документы, объекты, а также сотрудники и подразделения. При этом используется набор элементов для источников, приемников и хранилищ данных. Для логики взаимодействия информационных потоков используется IDEF3. С его помощью дают характеристику как отдельной постановке реализации бизнес-процесса, так и полной последовательности действий.

Созданные с применением BPWin диаграммы позволяют точнее сформулировать постановку задачи и наметить этапы ее решения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый шаг на этапе программирования предусматривает выбор и проектирование модели хранения данных. ERWin, входящий в набор Computer Associates AllFusion Modeling 4.1, позволяет спроектировать выбранную модель данных с использованием диаграмм DFD.

На следующем шаге этапа программирования определяется система или язык программирования. Затем создается серверная и клиентская части системы или язык программирования интерфейса. Далее происходит составление запросов и формирования шаблонов для отчетов.

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

Основные этапы внедрения предусматривают установку и наладку компьютерной информационной системы. Далее происходит уточнение первичных документов и форм отчетов. Адаптация системы предполагает доведение ее от уровня As Is до уровня To Be, вплоть до корректировки самих бизнес-процессов.

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

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

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

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

3. Система пользовательского интерфейса. Может помочь пользователям при работе с ЭС, даже если они не знают, как она организована; объясняет пользователю, как получить результат.

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