Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование бизнес-процесса страхования гражданской ответственности.

Содержание:

Введение

Информационные системы разрабатывают логически сложную и трудоемкую работу, требующую высокой квалификации участвующих экспертов. Необходимость контролировать процесс разработки программного обеспечения для прогнозирования и обеспечения стоимости разработки, времени и качества результатов привела к концу 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

Рис. 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.

Рис.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.

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

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

Продление

договора

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

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

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

да

нет

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

ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. – М.: Изд-во стандартов, 1990. ↑
Калянов Г.Н. Case-технологии. Современные методы и средства проектирования ИС. [Текст] / Г.Н. Калянов – М.: СИНТЕГ, 2006. – 316 с. ↑
Марка Д.А. Методология структурного анализа и проектирования. [Текст] / Д.А. Марка, К. МакГоуэн – М.: МетаТехнология, 2005. – 240 с. ↑
Верников Г.В. Описание стандартов IDEF. [Электронный ресурс]/ Г.В. Верников (Режим доступа: www.vernikov.ru. Дата просмотра: 10.01.2018г.) ↑
Верников Г.В. Описание стандартов IDEF. [Электронный ресурс]/ Г.В. Верников (Режим доступа: www.vernikov.ru. Дата просмотра: 10.01.2018г.) ↑
Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст] / В.Е. Туманов, С.В. Маклаков – М.: Диалог-МИФИ, 2007. - 333 с. ↑
Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст] / В.Е. Туманов, С.В. Маклаков – М.: Диалог-МИФИ, 2007. - 333 с. ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
ГОСТ Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования» ↑
Рубцов С.В. SADT: процесс моделирования. [Электронный ресурс]/ С.В. Рубцов (Режим доступа: http://www.interface.ru. Дата просмотра: 10.01.2018г.) ↑
Туманов В.Е. Проектирование реляционных хранилищ данных. [Текст] / В.Е. Туманов, С.В. Маклаков – М.: Диалог-МИФИ, 2007. - 333 с. ↑
Калянов Г.Н. Case-технологии. Современные методы и средства проектирования ИС. [Текст] / Г.Н. Калянов – М.: СИНТЕГ, 2006. – 316 с. ↑
Верников Г.В. Основные методологии обследования организаций. [Электронный ресурс]/ Г.В. Верников (Режим доступа: http://www.cfin.ru. Дата просмотра: 10.01.2018г.) ↑
Марка Д.А. Методология структурного анализа и проектирования. [Текст] / Д.А. Марка, К. МакГоуэн – М.: МетаТехнология, 2005. – 240 с. ↑
Рубцов С.В. SADT: процесс моделирования. [Электронный ресурс]/ С.В. Рубцов (Режим доступа: http://www.interface.ru. Дата просмотра: 10.01.2018г.) ↑
Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 10.01.2018г.) ↑
ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» ↑
Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑
Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑
Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑
Разу М.Л. Управление проектом. Основы проектного управления. [Текст] / М.Л.Разу – М.: КНОРУС, 2006. – 768 с. ↑
Грей К.Ф., Ларсон Э.У. Управление проектами: практическое руководство. [Текст] / К.Ф. Грей, Э.У. Ларсон . М.: КНОРУС, 2005. – 528 с. ↑
Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 10.01.2018г.) ↑
Пантелеева Т. Сетевое планирование. [Электронный ресурс]/ Т.Пантелеева (Режим доступа: http://www.inventech.ru. Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. Моделирование работы центра страхования. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://www.iteam.ru. Дата просмотра: 10.01.2018г.) ↑
Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Свечников А.А. BPWin - Rational Rose - Oracle Designer. Сравнительная оценка. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://sancase.narod.ru . Дата просмотра: 10.01.2018г.) ↑
Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑
Свечников А.А. Моделирование работы центра страхования. [Электронный ресурс] / А.А.Свечников (Режим доступа: http://www.iteam.ru. Дата просмотра: 10.01.2018г.) ↑
Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑
Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. [Текст] / С.В. Маклаков – М.: ДИАЛОГМИФИ, 2004. - 327 c. ↑
Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑
Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑
Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. [Текст] / С.В. Маклаков – М.: ДИАЛОГМИФИ, 2004. - 327 c. ↑
Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑
Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров – М.: Финансы и статистика, 2005. – 456 c. ↑
Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑
Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие./ [Текст] / А.М. Вендров – М.: Финансы и статистика, 2006. – 310 c. ↑