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

Работа из раздела: «Банковское, биржевое дело и страхование»

ДИПЛОМ

Тема

ВВЕДЕНИЕ

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

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

Преимущества внедрения информационных систем:

- освобождаются сотрудники компании от рутинных расчетов и действий;

- увеличивается прозрачность работы компании и контроль за ее деятельностью;

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

Предметом автоматизации является подсистему учёта страховых премий.

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

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

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

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

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

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

- обеспечение сохранности информации.

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

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

- сведение к минимуму учета невостребованной информации;

- повышение удобства работы за счет разработанных форм работы с системой;

- возможность получать отчетность в любом разрезе;

- наличие детализированного разграничения прав доступа к системе;

- оперативный анализ и управление ходом выполнения разработанного плана.

Для выполнения дипломного проекта определены следующие задачи:

1. Проведение обследования предметной области.

2. Выявление требований к системе.

3. Проектирование информационной системы.

4. Реализация проекта.

5. Оценка эффективности проекта.

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

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

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

Глава 1 Автоматизация процесса учёта страховых премий для строящегося жилья в страховой компании

§1.1 Анализ объекта автоматизации

Общие сведения о страховой компании, организационная структура

Компания ЗАО «ФАРТ», основанная в 1997 году, уже более 12 лет успешно работает на российском страховом рынке.

В соответствии с лицензией С № 1256 54 от 28.04.2006 г. ЗАО «СК «ФАРТ» имеет право заниматься следующими видами страхования:

- страхование от несчастных случаев;

- страхование средств наземного транспорта;

- страхование средств воздушного транспорта;

- страхование средств водного транспорта;

- страхование грузов;

- страхование имущества юридических и физических лиц;

- страхование предмета залога (заклада);

- комплексное страхование банковских рисков;

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

- страхование гражданской ответственности владельцев средств автотранспорта;

Основные цели Компании:

- получение высокой и стабильной прибыли;

- поступательное и динамичное развитие;

- расширение рынка оказываемых услуг.

Ценности Компании:

1. Сотрудники - это главное достояние нашей Компании. ЗАО «ФАРТ» стремится к постоянному совершенствованию и развитию своего интеллектуального и человеческого капитала.

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

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

4. Постоянное развитие и обучение - это непрерывное движение вперед, создание условий для развития талантов и способностей наших сотрудников, поддержка молодежи.

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

6. Эффективность - это достижение максимальных результатов при условии оптимального использования человеческих, природных и финансовых ресурсов.

7. Новаторство - это поиск, разработка и внедрение наиболее эффективных решений.

8. Научный подход - это глубокий анализ управленческих, технологических, и производственных задач на основе современных знаний и опыта.

9. Преемственность - это интенсивная работа страховщиков и бережное отношение к традициям Компании.

Принципы деятельности Компании:

1. Компания всегда действует в соответствии с существующим законодательством.

2. Компания является ответственным исполнителем всех нормативных актов государственных органов.

3. Компания защищает права своих участников.

4. Компания ценит и уважает своих сотрудников.

5. Компания всегда действует в соответствии с самыми высокими этическими стандартами.

6. Компания нетерпима к коррупции и взяточничеству.

7. Компания использует свои ресурсы с максимальной эффективностью.

8. Компания сотрудничает с общественными организациями.

Структура управления организацией: блочно-целевая.

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

Данную структуру можно также охарактеризовать как функциональную, т.к. система делится на блоки, имеющие четко очерченные задачи[15].

Организационная структура страховой компании построена в соответствии со стандартом предприятия ЗАО «СК «ФАРТ» (Рис.1.1).

Рис.1.1 «Организационная структура ЗАО «СК «ФАРТ»

Более подробно рассмотрим организационную структуру страховой компании ЗАО «СК «ФАРТ», а в частности его отдел по работе с клиентами, для которого разрабатывается данная информационная система.

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

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

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

Задача отдела по работе с клиентами:

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

Функции отдела по работе с клиентами:

- проведение переговоров и заключение договоров с клиентами;

- участие в планировании продаж;

- получение и контроль возврата денежных средств за заключённые договоры;

- составление и подписание актов сверки взаиморасчетов;

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

- своевременное оповещение клиентов об изменении цен;

- оформление и подбор необходимой документации;

- контроль выполнения договоров;

- представление всех видов продукции покупателям;

- обеспечение клиентов необходимыми рекламными материалами;

- выполнение планов продаж;

- формирование и проведение различных мотивационных программ;

- составление, ведение и предоставление необходимых видов отчетов.

В страховой компании ЗАО «СК «ФАРТ»не существует своего ИТ-отдела. У них есть только несколько человек, которые занимаются техническим обслуживанием компьютеров расположенных в данной компании. Поэтому для разработки информационной системы учёта страховых премий для строящегося жилья было решено обратится за разработкой данной системы в компанию ООО «СистемК».

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

Основное направление деятельности компании - разработка программного обеспечения на заказ, полностью отвечающего потребностям Вашего бизнеса, а также разработка web-приложений, позволяющих отслеживать деятельность Вашей компании из любой точки мира и в любое удобное для Вас время, всего лишь при наличии доступа в Интернет.

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

Решения на основе веб-интерфейса предоставляют множество возможностей:

- полноценное управление сетью распределенных филиалов предприятия;

- работа всех офисов продаж с централизованным складом;

- оперативное получение необходимой информации из любой точки мира;

- упрощение и автоматизация бизнес-процессов.

При этом не используется никакого дополнительного программного обеспечения кроме интернет-браузера.

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

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

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

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

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

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

Стоимость страхования инвестиций остается высокой, несмотря на возрастающую конкуренцию на рынке. В среднем она составляет 1-3% от страховой суммы (для сравнения: застраховать риск утраты права собственности при покупке квартиры на вторичном рынке можно всего за 0,1-0,5%). Значительному снижению страховых тарифов препятствует в том числе повышенный спрос на недвижимость. В итоге страховщикам приходится анализировать целый пласт объектов заведомо низкого качества и в некоторых случаях даже смягчать требования к объекту страхования.

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

Для вычисления страховой премии необходимо знать:

1. Категорию застройщика (1категории, 2категория, 3категория, 4категория).

2. Этап строительства. Существует 4 этапа строительства:

- от цокольного до 1/3 этажности дома;

- от 1/3 до 2/3 этажности дома;

- от 2/3 этажности дома до последнего;

- отделочные работы.

3. Срок страхования (на 1 год, от 1 до 1.5, от 1.5 до 2, от 2 до 3 лет);

4. Тарифы на финансовые риски, которые зависят от срока страхования:

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

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

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

- мошенничество - действия контрагента приведших к оформлению права собственности на объект долевого строительства на третьих лиц;

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

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

Пользователь может выбрать несколько финансовых рисков, все или один.

Страховая премия вычисляется по формуле

Ст.Пр. = Ц_кв(р/м2) * Sобщ * (1.ТарифРиска%+..+ N.ТарифРиска%) * (Категория.ПК + Этап.ПК + Срок.ПК )

где ПК - поправочный коэффициент;

Ц кв(р/м²) - Точная стоимость квартиры (р/м²);

Sобщ - Общая площадь квартиры (м²).

Формулировка цели и описание информационной системы

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

Основной целью создания информационной системы учёта страховых премий для строящихся квартир в страховой компании (ЗАО «СК «ФАРТ») является повышение эффективности деятельности ЗАО «СК «ФАРТ» за счет:

- сведения к минимуму негативного влияния человеческого фактора на достоверность расчетов;

- организации автоматизированной обработки расчетных данных;

- формирования отчетной документации;

- организации централизованного долгосрочного хранения данных.

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

- повышению качества информации;

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

- обеспечению сохранности информации;

- возможность получать отчетность в любом разрезе (графики, таблицы, html странички, Word и Excel странички);

- наличию детализированного разграничения прав доступа к системе;

- оперативному анализу и управлению ходом выполнения разработанного плана.

Задачи, решаемые в рамках информационной системы:

1. БД должна содержать информацию о строительных компаниях (категория, адрес, телефон, e-mail), о строящихся объектах (адрес, район, срок сдачи, материал и этажность), а также квартирах (количество комнат, этаж, подъезд, тип, планировка, общая площадь, средняя стоимость квартиры и точная стоимость );

2. Должен осуществляться поиск строящегося объекта по следующим критериям:

- строительная компания;

- адрес;

- район;

- материал;

- срок сдачи;

- этажность.

3. Также поиск квартир по следующим критериям:

- строительная компания;

- адрес;

- тип квартиры;

- планировка;

- цена (руб./м2 ).

4. Должна быть возможность изменять, добавлять и удалять записи;

5. Должна быть возможность сортировать данные в зависимости от таблицы;

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

Пользователи системы

Пользователями системы будут являться:

Отдел по работе с клиентами, в который входят:

- руководитель отдела по работе с клиентами;

- сотрудники отдела по работе с клиентами.

§1.2 Аналитический обзор существующих систем учёта страховых премий для строящегося жилья в страховых компаниях

Существующая система учёта страховых премий

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

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

- увеличение объема предоставляемой регламентированной отчетности;

- обеспечение оперативного сбора и анализа;

- анализ убыточности в различных разрезах и рентабельности существующих каналов продаж.

В связи с этим возрастает потребность в создании или модернизации корпоративных информационных систем. [9]

Каким образом страховые компании решают данную задачу? Многие продолжают работы по развитию систем собственными силами. Некоторые организации прибегают к услугам IT-компаний. Часть компаний приобрела готовые продукты для учета и ведения договоров (таких, как UNICUS Easy, «АКРИФОРМ», «Премьерлайн» РИНТИ, «ИНЭК-Страховщик 5.0»).

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

До разработки системы учёта страховых премий для строящегося жилья компанией ООО «СистемК» в страховой компании автоматизированного учёта страховых премия для строящегося жилья вообще не было. В отделе функционирует КИС для учёта стразовых премий на базе MS Excel. Страховым компаниям необходимо автоматизировать сбор и обработку данных, так как страхование - это довольно сложный и трудоемкий процесс, где учитываются различные факторы, связанные с определенными объектами, которые можно упустить или допустить ошибку при выборе, а это значит, что при подсчете различных страховых премий могут быть неточности или даже грубые ошибки. Это ведет к финансовым потерям компании. Чтобы этого не допустить необходимо внедрение и развитие более современной информационной системы. Так как готовые продукты для учёта страховых премий в основном засчитаны на крупные компании, что соответственно увеличивают их стоимость, то руководством компанией ЗАО «СК «ФАРТ, в целях экономии денежных средств, было принято решение разработать информационную систему удовлетворяющую их требование у компании ООО «СистемК».

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

- отсутствие единой БД;

- дублирование и потеря информации;

- недостоверность данных вследствие потерь и неправильных расчетов.

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

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

- повышение удобства работы за счет разработанных форм работы с системой;

- возможность получать отчетность в любом разрезе.

Наглядно процесс расчета представлен на рис.1.2

Рис.1.2. «Расчет страховой премии для строящегося жилья AS IS»

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

Модель IDEF0 - AS-IS представлена в Приложении 1

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

Обоснование средств моделирования бизнес-процессов

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

- построение модели бизнес-процессов предприятия и анализ этой модели, в том числе стоимостной анализ (ABC);

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

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

- создание сущностей и атрибутов и построение на этой основе модели данных;

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

В последнее время для целей анализа деятельности предприятий все большее распространение получает средство моделирования Rational Rose компании Rational Software. Однако на российском рынке CASE-средств давно присутствуют и успешно используются другие инструменты, реализующие потребности аналитика при описании и анализе деятельности предприятия.

Сравним особенности описания бизнес-процессов, реализованных в программном продукте Rational Rose фирмы Rational Software и продуктах, основанных на методологии IDEF0, наиболее распространенным из которых на российском рынке является BPwin корпорации Computer Associates.

BPwin позволяет создавать модели процессов и поддерживает три стандарта (нотации) моделирования - IDEF0, DFD и IDEF3, каждая из которых позволяет рассмотреть различные стороны деятельности предприятия.

Модель IDEF0 предназначена для описания бизнес-процессов предприятия. Она позволяет наглядно представить бизнес-процессы и легко выявить их недостатки, а также позволяет понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляющими факторами и какие ресурсы для этого необходимы. Методология структурного моделирования предполагает построение модели AS-IS (как есть), анализ и выявление недостатков существующих бизнес-процессов и построение модели TO-BE (как должно быть), то есть модели, которая должна использоваться при построении автоматизированной системы управлением предприятия[28].

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. DFD описывают функции обработки информации, документы, объекты, а также сотрудников или отделы, которые участвуют в обработке информации.

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

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

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

Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения «бизнес-моделей», содержащаяся в дополнительном наборе рекомендаций или методике RUP (Rational Unified Process), которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case (Диаграммы вариантов использования) и Activity (Диаграммы действия) для описания бизнес-процессов. Эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг IDEF0. Синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную и понятную систему и этим диаграммам не дается никакой интерпретации, объясняющей, как их применять при моделировании. Из чего следует, что Rational Rose допускает построение синтаксически корректных Activity-диаграмм, которые могут не иметь смысла ни с точки зрения моделируемого объекта, ни с позиции здравого смысла[26]..

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

Выбирая BPwin, необходимо строго выполнять все соглашения методологии IDEF0, которые станут гарантией получения:

- проверенной в различных предметных областях методологии моделирования и анализа деятельности предприятия;

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

Средства моделирования, основанные на IDEF0, имея описанный по стандарту бизнес-процесс, в качестве отчета выдадут:

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

- заготовки для проектирования организационной структуры предприятия;

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

Кроме того, для построения модели данных Computer Associates предлагает мощный и удобный инструмент - Erwin, который имеет два уровня представления модели - логический и физический. На логическом уровне данные могут быть наглядно представлены и понятны даже неспециалистам. Физический уровень данных - это отображение системного каталога, который зависит от конкретной реализации СУБД.

Основные достоинства продукта BPwin:

- позволяет описывать предметную область комплексно, поддерживая сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ);

- позволяет оптимизировать любые процедуры в компании;

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

- позволяет облегчить сертификацию на соответствие стандартам качества ISO9000;

- позволяет эффективно манипулировать моделями - сливать и расщеплять их.

- имеет широкий набор средств документирования моделей, проектов;

- интегрирован с Erwin (средством моделирования структур данных), Paradigm Plus (для моделирования компонентов ПО).

- Достоинства продукта Erwin:

- поддерживается прямое и обратное проектирование для 20 типов СУБД;

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

- позволяет переносить структуру БД из СУБД одного типа СУБД в другой;

- позволяет документировать структуру БД;

- продукт можно использовать на всех стадиях жизненного цикла баз данных: при проектировании, разработке, тестировании и поддержке;

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

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

Еще одним средством разработки является Delphi 7.0.

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

- создавать интерфейс используя стандартные компоненты;

- передавать управление различным процессам, в зависимости от состояния системы;

- создавать оболочки для БД и сами БД;

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

Разработку программного продукта решено было провести с помощью средств Delphi 7.0, что было обусловлено:

- интегрированная среда разработки приложений позволяет создавать, компилировать, тестировать и редактировать проект или группу проектов в единой среде программирования;

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

- библиотека компонентов содержит множество стандартных компонентов, которые можно использовать при создании приложений.

Хотя система Delphi 7.0 не является СУБД в буквальном смысле этого слова тем не менее, она обладает вполне развитыми возможностями СУБД. Представляемые Delphi 7.0 средства обеспечивают создание и ведение локальных и клиент-серверных БД, а также разработку приложения для работы практически с любыми БД. Назвать систему Delphi обычным СУБД мешает, наверное, только то, что, с одной стороны, у неё нет «своего» формата таблиц (языка описания данных), поэтому она использует формы таблиц других СУБД, например: Paradox, dBase, InterBase (это вряд ли является недостатком, поскольку названные форматы хорошо себя зарекомендовали); с другой стороны, в плане создания приложений различного назначения, в том числе приложений БД, возможности Delphi не уступают возможностям специализированных СУБД, а зачастую и превосходят их.

32 - битовый компилятор Delphi генерирует исполняемые EXE -файлы. При этом существует возможность генерировать либо простые ЕХЕ - файлы, либо сложные приложения, требующие подключения DLL библиотек.

Delphi, как СУБД, полностью ориентирован на реляционную модель данных и имеет встроенный язык запросов к БД SQL.

Вывод: В качестве средства разработки ИС будет использован Delphi7.O, как наиболее оптимальное средство разработки [29].

Обоснование системы управления базой данных

В качестве системы управления базой данных рассматриваются реляционные СУБД Oracle и Microsoft SQL Server, разработанные лидерами мирового рынка программного обеспечения. При принятии решения о выборе СУБД следует рассмотреть следующие особенности:

Поддержка различных платформ

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

Подход Oracle к поддержке различных операционных систем радикально отличается от подхода Microsoft -- СУБД этой фирмы существуют для огромного количества платформ. Хотя поддержка большого количества платформ требует немалых вложений, переход к широкому применению Java, который сейчас происходит в Oracle, позволяет существенно сократить затраты на разработку и поддержку продуктов.

Полная стоимость владения

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

Oracle рассматривает вопрос снижения полной стоимости владения своей СУБД с позиции надежности продукта, в то время как Microsoft -- с позиции цен на отдельные продукты, дополнительные утилиты, сервисы и услуги. Цена на продукты Oracle обычно намного превышает цены на аналогичные продукты Microsoft, особенно с учетом того, что в составе Microsoft SQL Server имеются утилиты и сервисы, которые при выборе Oracle следует приобретать отдельно за дополнительную плату.

Инструменты и утилиты

SQL Server прост в применении, в частности в администрировании. SQL Server Enterprise Manager, входящий в состав всех редакций Microsoft SQL Server (кроме MSDE), представляет собой полнофункциональное и достаточно простое средство для администрирования этой СУБД.

Oracle предоставляет больше возможностей для администрирования посредством Oracle Enterprise Manager. Однако установка этого инструмента сложна, и он входит в состав далеко не всех редакций СУБД Oracle, а некоторые его компоненты можно приобрести только как отдельные продукты[25].

Производительность

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

При выборе СУБД для информационной системы планирования движения денежных средств на производственном предприятии предпочтение было отдано продукту Microsoft SQL Server 2005, потому что:

- SQL Server 2005 имеет лучшее соотношение цены с производительностью, чем Oracle;

- у разработчика имеется опыт создания и администрирования баз данных в SQL Server 2005;

- SQL Server 2005 проще в эксплуатации (установка, использование, администрирование);

- SQL Server 2005 совместим с платформой Delphi7.O.

Обоснование методики проектирования

Разработка и внедрение программного обеспечения будет осуществляться с разбиением на стадии:

1. Предпроектная стадия:

- изучение предметной области;

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

2. Стадия разработки эскиза решений:

- формирование наглядного эскиза решений;

- утверждение эскизного решения у заказчика;

- опытная эксплуатация;

3. Стадия доработки эскизного решения до промышленного образца:

- доработка эскизного решения до промышленного образца;

- внедрение информационной системы;

- обучение пользователей;

4. Стадия сопровождения и развития:

- сопровождение разработанной информационной системы;

- развитие информационной системы.

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

Обоснование средства разработки клиентского приложения

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

- небольшой и ограниченный бюджет на разработку и внедрение системы;

- на начальном этапе нет необходимости в дополнительных модулях;

- у разработчиков имеется опыт разработки на Delphi7.0;

- Delphi7.0 проще в разработке приложений.

Delphi не имеет своего формата таблиц БД, однако несмотря на это, обеспечивает поддержку многих СУБД, как локальных (например, dBase и Paradox), так и промышленных (например, SyBase и InterBase). К средствам Delphi, предназначенным для работы с БД, относятся следующие:

- инструментальные средства (специальные программы и пакеты, обслуживающие БД вне разрабатываемых приложений);

- компоненты, предназначенные для создания приложений, осуществляющих операции с БД.

Инструментальные средства

Для операции с БД система Delphi предлагает следующие инструментальные средства:

1. Borland DataBase Engine (BDE) - процессор баз данных, который представляет собой набор библиотек, предназначенных для организации доступа к БД из приложения Delphi. BDE является центральным звеном, используемым для доступа к данным.

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

2. BDE Administrator - утилита для установки псевдонимов (имен) баз данных, параметров БД и драйверов баз данных на конкретном компьютере.

При работе с БД из приложения, созданного с помощью Delphi, доступ к базе данных производится по ее псевдониму (имени). Параметры БД, определяемые псевдонимом, действуют только для этой
БД; параметры установленные для драйверов БД, действуют для всех БД, использующих драйвер. Кроме того, в утилите BDE A dministrator можно произвести установку таких общих для всех БД параметров, как формат даты и времени, форматы представления числовых значений, используемый языковой драйвер и т.д. Поддерживает информацию о конфигурации БД на конкретном ПК в файле IDAPI32.CFG.

3. DataBase Desktop -средство для создания, изменения и просмотра БД.

Эта утилита ориентирована прежде всего на работу с таблицами локальных СУБД, таких как Paradox или dBase. В ряде случаев может использоваться и для работы с таблицами удаленных СУБД. Например. Из DBD можно с некоторыми ограничениями создавать таблицы БД,работающие под управлением InterBase,ORACLE, и просматривать их содержимое.

4. SQL Explorer - утилита для конфигурирования псевдонимов БД, просмотра структуры БД, таблиц БД, выдачи запросов к БД.

5. SQL Monitor - программа для отслеживания порядка выполнения SQL запросов.

6. SQL Builder - программа визуального конструирования SQL - запросов

7. SQL Links -драйверы для доступа к удаленным промышленным СУБД, например, Microsoft SQL Server или ORACLE (для работы с промышленным сервером InterBase, который поставляется совместно с Delphi и является 'родным' для нее, поэтому устанавливать SQL Links не нужно).

8. Local InterBase Server - локальная версия SQL-сервера Borland InterBase, которая используется при отладке приложений, предназначенных для работы с удаленными БД в архитектуре клиен-сервер[23].

Реинжиниринг бизнес процессов (модель IDEF0 -TO-BE)

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

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

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

- информация о строительных компаниях (категория, адрес, телефон, e-mail), о строящихся объектах (адрес, район, срок сдачи, материал и этажность), а также квартирах (количество комнат, этаж, подъезд, тип, планировка, общая площадь, средняя стоимость квартиры и точная стоимость );

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

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

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

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

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

Эксплуатация Системы будет проходить на отдельном персональном ЭВМ.

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

Рис.1.3. «Расчет страховой премии для строящегося жилья TO BE»

Модель IDEF 0 - To-Be представлена в Приложении 2.

Глава 2 Проектирование и разработка информационной учёта страховых премий для строящихся квартир в страховой компании

§ 2.1. Описание требований к системе

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

Система должна быть выполнена с учетом требований ТЗ, представленного в Приложении 3, соответствовать современному уровню программно-технических средств аналогичных объектов. Здесь представлен общий список требований к системе в целом.

Основными бизнес-требованиями к информационной системе являются:

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

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

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

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

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

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

- удалять информацию из базы могут только администраторы базы;

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

Требования к структуре и функционированию системы

Требования к защите информации от несанкционированного доступа

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

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

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

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

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

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

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

- протоколирование действий персонала по управлению работой системы;

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

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

- антивирусное ПО устанавливается на всех узлах, включая точки доступа в Internet;

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

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

Требования к эргономике и технической эстетике

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

- режим многооконного отображения процесса с возможностью открывать и закрывать окна, изменять их размеры и месторасположение на экране, выбирать активное окно, вызывать всплывающие окна;

- отображение результатов измерений во времени с возможностью их группировки на одном графике (экране), изменение масштаба и положения координат, а также периода времени;

- формирование и отображение рапортов со свободным выбором формы, содержания, времени создания и устройства вывода.

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

Расположение оборудования в помещениях должно обеспечить удобство их обслуживания.

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

Требования по стандартизации и унификации

Единообразный подход к решению однотипных задач должен достигаться:

- унификацией функциональной структуры системы и входящих в неё подсистем в части её элементов (автоматизированных функций) и в части связей между её элементами (информационной связи между функциями);

- единым программно-техническим способом реализации одинаковых функций системы и единым операторским интерфейсом в системе (способами и правилами взаимодействия 'человек-машина');

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

Унификация компонентов информационного обеспечения должна быть направлена:

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

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

Унификация лингвистического и программного обеспечения должна быть направлена:

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

- в части системного программного обеспечения - на максимальное использование стандартных программных средств - пакетов системных и прикладных программ и программных модулей, СУБД, Web-серверов, OPC-серверов, SCADA-систем, а при необходимости - и на разработку новых проблемно-ориентированных пакетов;

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

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

§ 2.2. Проектирование информационной системы

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

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

- представление предметной области в том виде, как она реально существует;

- как ее воспринимает человек (имеется в виду проектировщик базы данных);

- как она может быть описана с помощью символов.

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

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

Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:

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

- обследование предметной области, изучение ее информационной структуры;

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

- моделирование и интеграция всех представлений.

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

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

Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д. [12].

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

Таблица 2.1 Уровни проектирования

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ · сущности · атрибуты · связи	Представление аналитика
ЛОГИЧЕСКИЙ УРОВЕНЬ · записи · элементы данных · связи между записями	Представление программиста
ФИЗИЧЕСКИЙ УРОВЕНЬ · группирование данных · индексы · методы доступа	Представление администратора

На основе разработанных требований к системе учёта страховых премия для строящихся квартир в строительной компании необходимо спроектировать ее. При этом необходимо определить:

1. Технологию системе учёта страховых премия для строящихся квартир.

2. Календарный план-график.

3. Определить бизнес-логику приложения и построить модели процессов.

4. Разработать структуру базы данных.

5. Разработать пользовательские интерфейсы.

Разработать структуру отчетов.

Технология разработки и внедрения ИС учёта страховых премий для строящихся квартир в страховой компании

Предполагается выполнить цикл работ по внедрению и поддержке ИС:

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

- разработка системы учёта страховых премий для строящихся квартир ее автоматизации;

- внедрение автоматизированных процессов расчётов страховых премия для строящихся квартир;

- обучение и консультирование персонала по эксплуатации и поддержке развернутых процессов.

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

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

Описание архитектуры информационной системы

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

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

Схематически архитектура системы представлена на рис.2.1

Рис.2.1 «Архитектура системы»

Описание информационной системы на концептуальном уровне

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

- cтандарт DFD;

- диаграмма прецедентов;

- стандарт IDEF3.

Стандарт DFD

На рис.2.2 представлен корневой уровень модели «Работы с системой для строящегося жилья», реализованной по стандарту DFD.

жилье страховой информационный компания учёт

Рис.2.2 Модель DFD

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

- сотрудники отдела по работе с клиентами;

- законодательство;

- руководящий состав.

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

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

Клиенты- покупают продаваемую продукцию, т.е страховые договоры.

На рис.2.2 представлена «Диаграмма информационных потоков системы учёта страховых премия для строящегося жилья», представлен корневой уровень модели «Учёта страховых премия для строящегося жилья», реализованной по стандарту DFD. Подробная схема по стандарту DFD представлена в Приложении 4.

Диаграмма прецедентов

Диаграмма прецедентов реализуется с помощью средства проектирования Rational Rouse и иллюстрирует работу участников системы с функциями системы.

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

Сотрудники отдела по работе с клиентами производят:

- ввод исходной информации;

- нормализуют исходную информацию;

- формирование отчётных данных.

В свою очередь и руководитель отдела по работе с клиентами:

- составляет отчеты;

- предоставляет их руководству.

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

Рис.2.3 Диаграмма прецедентов

Описание информационной системы на логическом уровне
(UML - модели)

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

Диаграмма модулей системы иллюстрирует ее ключевые функции (рис.2.4 Диаграмма модулей системы):

- авторизация пользователя;

- настройки расчетов страховых премий;

- представление отчетных данных;

- заполнение справочников;

- формирование отчетов.

Рис.2.4 Диаграмма модулей системы

Описание информационной системы на физическом уровне (ER - модель)

Третий уровень проектирования технологический, заключается в определении технологий, используемых для внедрения системы, и окончательный вид системы. [19] На данном этапе формируется логическая и физическая модель ER модель базы данных. С их помощью проектируется структура и сущность организации метаданных, на основе которых будет построена база данных. Логическая ER модель базы данных представлена в приложении 5. Физическая модель учёта страховых премий для строящегося жилья представлена в приложении 6.

§ 2.3. Реализация компонентов информационной системы (реализация приложений)

Проектирование базы данных

В этом разделе рассматривается структура разработки БД. Важно рассмотреть основные проектные решения (выбор модели).

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

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

Описание таблиц

Таблица Company - содержит информацию о строительной компании. Далее приведены поля этой таблицы.

- С_ID - номер строительной компании(ключ);

- K_ID - код таблицы категорий, по данному полю происходит связывание с таблицей Кategor;

- C_Name - название строительной компании;

- С_Phone - телефон строительной компании;

- С_Address - адрес строительной компании;

- С_Kat - Категория строительной компании.

Поле С_Kat - это поле выбора, содержащее все категории строительных компаний, из которого пользователь выбирает одно из наименований. Для формирования списка выбора используется поле K_Name таблицы Kategor, содержащей записи данных о категориях. Связь между двумя таблицами Company и Kategor осуществляется через их поля кода категории K_ID и K_ID соответственно. Использование поля выбора заключается в том, что пользователь выбирает значение в поле С_Kat, содержащем список, который построен на основании значений поля K_Name. После выбора значений поля С_Kat из поля связи K_ID таблицы Kategor автоматически заносится соответствующее значение в поле K_ID таблицы Company.

Таблица Kategor - содержит инормацию о категориях строительных компаний

- K_ID - номер категории(ключ);

- K_ Name - название категории;

- K_ pk - поправочный коэффициент.

Таблица Object - содержит информацию о строящихся объектах

- O_ID - номер объекта(ключ);

- С_ID - код строительной компании;

- D_ID - код района в котором находиться данный объект;

- M_ID - код материала из которого сделан объект;

- O_ Address - адрес объекта ;

- O_ Date - срок сдачи объекта;

- O_ Distr - район объекта(поле выбора, содержащее все районы. Связь между двумя таблицами Object и District осуществляется через их поля D_ID и D_ID соответственно. Для формирования списка выбора используется поле D_Name таблицы District);

- О_ Mat - строительный материала из которого сделан объект(поле выбора, содержащее строительные материалы. Связь между двумя таблицами Object и Material осуществляется через их поля M_ID и M_ID соответственно. Для формирования списка выбора используется поле M_Name таблицы Material);

- O_ Floor - этажность объекта;

- С_ Name - строительная компания, строящая данный объект.

Между таблицами Company и Object устанавливается связь «главный-подчиненный», при которой таблица Company является главной, а таблица Object - подчиненной. Для организации связи в качестве поля связи главной таблицы берется автоинкрементное поле С_ID уникального кода компании, по этому коду построен ключ, значение которого автоматически формируется при добавлении новой записи и в пределах таблицы является уникальным. В подчиненной таблице полем связи (внешним ключом) является целочисленное поле С_ID, по которому построен индекс.

Таблица District - содержит все районы

- D_ID - номер района(ключ);

- D_ Name - специальные сокращения районов;

- District - полное название района.

Таблица Material - содержит все существующие стандартные материалы для строительства объектов

- M_ID - номер материала(ключ);

- M_Name - специальное сокращение материала;

- Material - полное название материала.

Таблица Float - содержит полную информацию о квартирах;

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

- O_ID - код строящегося объекта, в котором находится данная квартира;

- T_ID - код типа квартиры;

- P_ID - код планировки квартиры;

- F_ Col - количество комнат;

- F_ Pod - номер подъезда;

- O_ Floor - этажность объекта(заносится автоматически);

- F_ Floor - этаж на котором находится квартира;

- F_ Type - тип квартиры (поле выбора, содержащее тип квартиры. Связь между двумя таблицами Float и Type осуществляется через их поля T_ID и T_ID соответственно. Для формирования списка выбора используется поле T_Name таблицы Type);

- F_Plan - планировка квартиры (поле выбора, содержащее планировку квартиры. Связь между двумя таблицами Float и Plan осуществляется через их поля P_ID и P_ID соответственно. Для формирования списка выбора используется поле P_Name таблицы Plan);

- O_ Address - адрес строящегося объекта, в котором находится данная квартира(заполняется автоматически);

- F_ S_ obsh - общая площадь квартиры;

- F_ Cost_ Sr - средняя стоимость квартиры в рублях за м²;

- F_ Cost_ Toch - точная стоимость квартиры в рублях за м²;

- F_ StrahPrem - страховая премия в рублях(заполняется после подсчета);

- С_ Name - строительная компания, которая строит данный объект(заносится автоматически).

Между таблицами Float и Object устанавливается связь «главный-подчиненный», при которой таблица Object является главной, а таблица Float подчиненной. Для организации связи в качестве поля связи главной таблицы берется автоинкрементное поле О_ID уникального кода компании, по этому коду построен ключ, значение которого автоматически формируется при добавлении новой записи и в пределах таблицы является уникальным. В подчиненной таблице полем связи (внешним ключом) является целочисленное поле О_ID, по которому построен индекс.

Таблица Type - содержит все существующие стандартные типы квартир.

- T_ID - номер типа(ключ);

- T_ Name - специальные сокращения типов квартир;

- Type - полное название типа квартиры.

Таблица Plan - содержит все существующие стандартные планы квартир.

- P_ID - номер плана(ключ);

- P_Name - специальные сокращения планов квартир;

- Plan - полное название плана

Разработка модуля данных

Модуль данных - это специализированная форма, которая предназначена для размещения используемых в проекте невизуальных компонентов доступа к данным. Используется во время разработки приложения. В общем случае на модуле данных можно разместить любой невизуальный компонент из палитры компонентов. Рекомендуется все типы Ttable, Tquery , TdateBase, используемые в проекте, хранить именно в модуле данных. Доступ к этим компонентам осуществляется путем включения имени файла модуля данных в секции Uses модуля. Одним из главных удобств является приписывание каждому набору данных правил по управлению данными. Такие правила называются бизнес-правилами. Они обычно определяют реакцию системы при добавлении, изменении, удалении данных, при вводе ошибочных значений и реализует блокировку действий, которые могут разрушить ссылочную смысловую целостность БД. Такие бизнес-правила, хранящиеся централизованно на уровне приложения, при использовании одного и того же набора данных в разных формах приложения, позволяют унифицировать поведение набора данных на уровне всего приложения.

Пример модуля данных изображен на рис.2.6

Рис.2.6 пример модуля данных

Разработка SQL-запросов.

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

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

1. Сравнения.

- =(равно);

- > (больше) или < (меньше);

- >= (больше или равно) или <= (меньше или равно);

- <> или !<> (не равно);

- !> (не больше) или !<(не меньше).

2. BETWEEN (проверка на вхождения в диапазон).

3. LIKE (Сравнение по шаблону).

4. IS NULL (Проверка на нулевое значение).

5. IN (проверка на вхождение).

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

Сложный критерий (логическое выражение) состоит из

1. Простых условий.

2. Логических операций:

- AND(логическое и);

- OR(логическое или);

- NOT(логическое не);

3. Круглых скобок.

По каким критериям будет осуществляться поиск зависит от пользователя, значит SQL-запрос должен быть динамическим, т.е. формироваться и изменяться при выполнении приложения.

Сортировка представляет собой упорядочивание записей по возрастанию или убыванию значений полей. Список полей, по которым выполняется сортировка, указывается в операнде ORDER BY. По умолчанию сортировка происходит в порядке возрастания значений полей. Для указания обратного порядка сортировки по какому-либо полю нужно указать после имени этого поля описатель DESC. [8].

В отличие от набора данных Table, средствами языка SQL можно выполнять сортировку для набора данных Query и по неиндексированным полям. Однако по индексированным полям таблицы сортировка выполняется быстрее.

Рассмотрим пример SQL-запроса, который выполняет сортировку для таблицы Company:

procedure TForm1.SortCompClick(Sender: TObject);

var s:string;

begin

DataModule2.QComp.Close;

DataModule2.QComp.SQL.Clear;

case RadioGroup2.ItemIndex of

0: s:='';

1: s:='DESC';

end;

case ComboBox2.ItemIndex of

0: s:=' C_ID ' +s;

1: s:=' C_Name ' +s;

2: s:=' C_Address ' +s;

3: s:=' C_Phone ' +s;

end;

DataModule2.QComp.SQL.Text:='SELECT * FROM Company '+

'ORDER BY ' +s;

DataModule2.QComp.Open;

end;

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

Удаление записей. Для удаление группы записей используется инструкция DELETE имеющая формат

DELETE FROM <Имя таблицы>

[WHERE <Условия отбора>];

В результате выполнения этой инструкции из таблицы, имя которой указано после слова FROM, удаляются все записи, которые удовлетворяют критерию отбора. Если критерий не задан, то из таблицы будут удалены все записи. Какая именно квартира будет удалена зависит от пользователя, значит SQL-запрос должен быть динамический, т.е. формироваться и изменяться при выполнении приложения.

Рассмотрим SQL-запрос на удаление текущей квартиры:

procedure TForm1.DelFloatClick(Sender: TObject);

var kv :integer;

begin

kv:=DataModule2.QFloat.FieldByName('F_ID').AsInteger;

begin

DataModule2.QFloat.RequestLive:=True;

DataModule2.QFloat.Close;

DataModule2.QFloat.SQL.Clear;

DataModule2.QFloat.SQL.Text:= 'DELETE FROM Float1 '+

'WHERE F_ID = '+ IntToStr(kv);

DataModule2.QFloat.ExecSQL;

Расчет страховой премии

Для вычисления страховой премии необходимо знать категорию застройщика (1категории, 2категория, 3категория, 4категория), этап строительства (4 этапа: от цокольного до 1/3 этажности дома, от 1/3 до 2/3 этажности дома, от 2/3 этажности дома до последнего, отделочные работы), срок страхования(на 1 год, от 1 до 1.5, от 1.5 до 2, от 2 до 3 лет) и тарифы на финансовые риски, которые зависят от срока страхования («Порча», «Остановка», «Банкротство», «Мошенничество», «Недооформление», «Форс-мажор»), пользователь может выбрать несколько финансовых рисков, все или один.

Страховая премия вычисляется по формуле:

Ст.Пр. = Ц_кв(р/м2) * Sобщ * (1.ТарифРиска%+..+ N.ТарифРиска%) * (Категория.ПК + Этап.ПК + Срок.ПК ),

где ПК - поправочный коэффициент

Ц_кв(р/м²) - Точная стоимость квартиры (р/м²);

Sобщ - Общая площадь квартиры (м²).

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

Созданы таблицы поправочных коэффициентов и тарифов, рис.2.7

Рис.2.7 Схема таблиц

Таблица Srok - содержит поправочные коэффициенты. На каждый срок страхования свой поправочный коэффициент

- S_ID - номер срока страхования(ключ);

- S_Name - название срока;

- S_pk - поправочный коэффициент срока страхования.

Таблица Risk - содержит тарифы на финансовые риски в %.

- R_ID - номер тарифа(ключ);

- S_ID - номер срока;

- S_Name - наименование срока;

- R_Porcha - тариф на финансовый риск «Порча»;

- R_Ostan - тариф на финансовый риск «Остановка»;

- R_Bankr - тариф на финансовый риск «Банкротство»;

- R_Moshen - тариф на финансовый риск «Мошенничество»;

- R_Nedoofr - тариф на финансовый риск «Недооформление»;

- R_PolnPac - полный пакет.

Между таблицами Risk и Srok устанавливается связь «главный-подчиненный», при которой таблица Srok является главной, а таблица Risk - подчиненной. Для организации связи в качестве поля связи главной таблицы берется автоинкрементное поле S_ID уникального кода срока страхования, по этому коду построен ключ, значение которого автоматически формируется при добавлении новой записи и в пределах таблицы является уникальным. В подчиненной таблице полем связи (внешним ключом) является целочисленное поле S_ID, по которому построен индекс.

Таблица Etap - содержит поправочные коэффициенты каждого этапа стройки:

- E_ID - номер этапа(ключ);

- E_ Name - название этапа;

- E_ pk- поправочный коэффициент.

Таблица Kategor - содержит поправочные коэффициенты категорий компаний

- K_ID - номер категории(ключ);

- K_ Name - название катигории;

- K_ pk - поправочный коэффициент.

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

Рис.2.8 Форма поправочных коэффициентов и тарифов

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

Рис.2.9 подсчет страховой премии

Описание интерфейса

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

Выбор требуемого раздела производится путем выбора соответствующей закладки на главной форме рис.2.10

Рис.2.10 главная формы

Раздел «Компании»

Работа проводится с помощью формы, которая выбирается по нажатию соответствующей кнопки. При нажатии на кнопку «Добавить» открывается форма «Добавить компанию» рис.2.11

Рис.2.11 форма «Добавить компанию»

Необходимо внести данные о компании. Из списка «Категории» выбрать нужную категорию и нажать на кнопку «Добавить». После чего программа выведет следующее сообщение рис.2.12

Рис.2.12 сообщение о результате добавления

Для редактирования данных компании необходимо нажать на кнопку «Изменить», тогда вызовется форма под названием «Изменить ДАННЫЕ О КОМПАНИИ» рис2.13, которую можно также использовать как удобный просмотр данных компании, т.к. вся информация представлена в удобном для чтения виде и при нажатие на главную форму не закрывается, остается на главной формы в неактивном режиме. Форма будет показывать данные текущей компании.

Рис.2.13 форма «Изменить ДАННАЕ О КОМПАНИИ»

При удалении компании, необходимо нажать на кнопку «Удалить».

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

Рис.2.14 Предупреждение о существование объектов

Рис.2.15 подтверждение к удалению

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

Рис.2.16 - Сортировка компаний

Раздел «Объекты».

Главная форма раздела «Объекты» представлена на рис.2.17.

Рис.2.17 - Главная формы, раздел «Объекты»

В данном разделе можно показать все объекты или объекты только определенной компании по желанию пользователя. Компания выбирается пользователем из списка панели «Показать» рис.2.18. При удалении, изменении, или добавлении компаний в базе данных состав списка соответственно изменяется.

Рис.2.18 - Вывод объектов компании Кварсис

Для того чтобы отсортировать данные объекта необходимо выбрать критерии сортировки из списка панели «Сортировать по», и задать направление сортировки рис.2.19

Рис.2.19 - Сортировка таблицы объектов

Для добавления объекта необходимо вызвать форму «Добавить объект». Для этого надо нажать на кнопку «Добавить» рис.2.20

Рис.2.20 - форма «Добавить объект»

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

Для изменения данных объекта необходимо вызвать форму «Изменить ДАННЫЕ ОБЪЕКТА». Для этого надо нажать на кнопку «Изменить» рис.2.21

Рис.2.21- форма «Изменить ДАННЫЕ ОБЪЕКТА»

Для удаление записи объекта нужно нажать на кнопку «Удалить». Перед удалением программа предупреждает о том, что объект будет удален вместе с квартирами, находящимися в данном доме рис.2.22, в случае положительного ответа объект удаляется

Рис.2.22 - предупреждение об удалении объекта

Для поиска объекта, необходимо вызвать форму «Поиск ОБЪЕКТА». Для этого нужно нажать на кнопку «Поик» рис.2.23

Рис.2.23 - форма «Поиск ОБЪЕКТА»

Данная форма позволяет искать объект по различным критериям. Для поиска объекта необходимо напротив нужного критерия поставить галочку и заполнить соответствующие поля: выбрать (для полей «Компания» «Район» или Материал) нужное значения или ввести данные(в поля «Адрес», «Этажность » и «Срок сдачи») . Например рис.2.24

Рис.2.24 - Пример заполнения формы «Поиск ОБЪЕКТА»

После заполнения формы нужно нажать на кнопку «Искать», программа выдаст сообщение с результатом поиска.

Раздел «Квартиры»

Главная форма раздела «Квартиры»представлена на рис.2.25

Рис.2.25 - Главная форма Раздела «Квартиры»

В данном разделе можно показать все квартиры или квартиры только определенной компании определенного объекта по желанию пользователя. Компания и адрес объекта выбираются пользователем из списка панели «Показать». При изменении, удалении или добавлении компаний и принадлежащих им объектов в базу данных, состав списков соответственно изменяется рис.2.26

Рис.2.26 - выбор квартир по компании и дому.

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

Рис.2.27- Сортировка таблицы квартиры

Для добавления квартиры необходимо вызвать форму «Добавить квартиру». Для этого надо нажать на кнопку «Добавить» рис.2.28

Рис.2.28 - Форма «Добавить КВАРТИРУ»

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

Аналогично с предыдущими разделами организовано изменение рис.2.29

Рис.2.29 - Форма «Изменить ДАННЫЕ О КВАРТИРЕ»

Что бы осуществить поиск квартиры, необходимо воспользоваться формой представленной на рис.2.30. В данной форме устанавливаются критерии поиска и после нажатия кнопки «искать» выдаётся результат.

Рис.2.30- Форма «поиск квартиры»

Для того, чтобы посчитать страховую премию необходимо вызвать форму «Страховая премия», которая вызывается с помощью нажатия кнопки «ПРЕМИЯ» рис.2.31

Рис.2.31 - Форма «Страховая премия»

Рассмотрим подсчет премии на конкретном примере:

Шаг 1:

- устанавливается категория застройщика (1категории, 2категория, 3категория, 4категория) (данная информация о категориях строительных компаний содержится в разделе «Компании»);

- выбирается стадия строительства объекта (4 этапа: от цокольного до 1/3 этажности дома, от 1/3 до 2/3 этажности дома, от 2/3 этажности дома до последнего, отделочные работы);

- выбирается срок страхования (на 1 год, от 1 до 1.5, от 1.5 до 2, от 2 до 3 лет)

Шаг 2: устанавливаются финансовые риски (выделяются риски от которых страхуется клиент и нажимается на кнопку «Установить»). На форме видно как посчитались проценты;

Шаг 3) нажимается кнопка «Посчитать», после чего программа выводит стоимость страховки.

При подсчете использовались таблицы раздела «Расчет тарифа» рис.2.32

Рис.2.32 - Форма «Расчет тарифа»

Формирование отчетов

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

Для этого есть подраздел «Отчеты». На данный момент существует два отчета. Это отчёт по объектам и развёрнутый отчёт по объектам на конкретную дату. Развёрнуты отчёт по объектам представлен на рис.2.33

Рис.2.33 - Развёрнутый отчёт по объектам

Глава 3 Обоснование экономической эффективности и внедрение проекта

§ 3.1. Внедрение и эксплуатация информационной системы

Подготовка объекта внедрения

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

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

Программный комплекс предусматривает одновременную работу нескольких клиентских рабочих мест с одной базой данных при наличии локальной сети (с пропускной способностью 100 Mb/s) по протоколу TCP/IP с учетом требований корпоративной вычислительной сети. Приложение распределяется по местам пользователей системы и защищено паролем.

3.1.2.Тестирование системы

В рамках внедрения системы предусмотрен ряд испытаний:

- предварительные испытания;

- опытная эксплуатация;

- приемочные испытания.

С целью определения работоспособности системы и решения вопроса о возможности приемки ее в опытную эксплуатацию были проведены предварительные испытания. В качестве эксперта был выбран пользователь системы - сотрудник отдела по работе с клиентами. [26]

Подготовленные и согласованные тесты на этапе предварительных испытаний обеспечили:

- полную проверку функций и процедур системы;

- необходимую точность вычислений;

- проверку основных временных характеристик функционирования программных средств;

- проверку надежности и устойчивости функционирования программных и технических средств.

В качестве исходной информации для теста был использован фрагмент реальной информации ЗАО СК «Фарт»в объеме, достаточном для обеспечения необходимой достоверности испытаний.

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

- контроль качества выполняемых функций;

- оценка удобства технического обслуживания.

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

Условия эксплуатации системы

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

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

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

Основу информационного обеспечения системы составляют:

- защита данных от разрушения в аварийных и сбойных ситуациях;

- защита данных от несанкционированного доступа.

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

- компьютер с процессором Pentium 233 МГц или более мощный, рекомендуется Pentium III;

- Microsoft Windows 2000 с Service Pack 3 или более поздней версии, или Microsoft Windows XP или операционная система более поздней версии;

- память: ОЗУ 128 Мбайт или как рекомендуется выше;

- 130 Мбайт памяти на жестком диске.

§ 3.2. Экономическая эффективность информационной системы

Расчет экономической эффективности информационной системы планирования бюджета движения денежных средств

Экономическая эффективность - это разность или соотношение стоимостного эффекта от внедрения автоматизированной системы и стоимости самой системы, затрат на ее создание и эксплуатацию за определенный период времени [23]. Обоснование экономической эффективности внедрения информационной системы позволяет:

- выявить необходимость и целесообразность затрат на создание и внедрение информационной системы на конкретном объекте;

- рассчитать срок окупаемости затрат на создание информационной системы и сравнить его с установленными нормативами;

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

- выбрать экономически наиболее эффективные варианты построения информационного обеспечения информационной системы.

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

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

Для оценки экономической эффективности информационной подсистемы «Учет продаж компьютерной техники» использовалась модель COCOMO II (Constructive Cost Model), которая является одной из самых популярных моделей. Это обусловлено сравнительной легкостью применения расчета затрат.

Модель СОСОМО II, опубликованная в 1995 г., состоит из трех подмоделей, каждая из которых применяется при определенных условиях: при сборке приложения из готовых компонентов, на этапе предварительного проектирования и после проектирования архитектуры приложения. Подмодели можно использовать совместно различными способами, наиболее подходящими для технологий, распространяемых на рынке на данный момент и перспективных.

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

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

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

Преимущества использования модели COCOMO II:

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

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

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

Оценка объемов системы

Справочники

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

- строительные компании;

- категории строительной компании;

- строящиеся объекты;

- районы;

- материалы;

- квартиры;

- типы квартир;

- план квартиры;

Строительные компании- содержит информацию о строительной компании. Далее приведены поля этой таблицы (С_ID - номер строительной компании(ключ), K_ID - код таблицы категорий, по данному полю происходит связывание с таблицей Кategor, C_Name - название строительной компании, С_Phone - телефон строительной компании, С_Address - адрес строительной компании, С_Kat - Категория строительной компании).

Категории строительной компании- содержит инормацию о категориях строительных компаний (K_ID - номер категории(ключ), K_Name - название категории, K_pk - поправочный коэффициент).

Строящиеся объекты- содержит информацию о строящихся объектах (O_ID - номер объекта(ключ), С_ID - код строительной компании, D_ID - код района в котором находиться данный объект, M_ID - код материала из которого сделан объект, Address - адрес объекта, O_Date - срок сдачи объекта, O_Distr - район объекта, О_Mat - строительный материала из которого сделан объект, O_Floor - этажность объекта, С_Name - строительная компания, строящая данный объект).

Районы- содержит все районы (D_ID - номер района(ключ), D_Name - специальные сокращения районов, District - полное название района).

Материалы - содержит все существующие стандартные материалы для строительства объектов (M_ID - номер материала(ключ), M_Name - специальное сокращение материала, Material - полное название материала).

Квартиры - содержит полную информацию о квартирах (F_ID - номер квартиры(ключ), O_ID - код строящегося объекта, в котором находится данная квартира, T_ID - код типа квартиры, P_ID - код планировки квартиры, F_Col - количество комнат, F_Pod - номер подъезда, O_Floor - этажность объекта(заносится автоматически), F_Floor - этаж на котором находится квартира, F_Type - тип квартиры, F_Plan - планировка квартиры, O_Address - адрес строящегося объекта, в котором находится данная квартира(заполняется автоматически), F_S_obsh - общая площадь квартиры, F_Cost_Sr - средняя стоимость квартиры в рублях за м2 , F_Cost_Toch - точная стоимость квартиры в рублях за м2, F_StrahPrem - страховая премия в рублях(заполняется после подсчета), С_Name - строительная компания, которая строит данный объект(заносится автоматически).

Типы квартиры- содержит все существующие стандартные типы квартир (T_ID - номер типа(ключ), T_Name - специальные сокращения типов квартир, Type - полное название типа квартиры).

План квартиры- содержит все существующие стандартные планы квартир (P_ID - номер плана(ключ), P_Name - специальные сокращения планов квартир, Plan - полное название плана).

Формы

Для реализации выше перечисленных операции необходимо создать следующие формы

- форма для ввода компаний; уровень низкий;

- форма для ввода объектов; уровень средний;

- форма для ввода квартир ; уровень низкий;

- форма для ввода материала; уровень низкий;

- форма для ввода реквизитов компаний; уровень низкий;

- форма для ввода типов квартир; уровень низкий;

- форма для ввода плана квартир; уровень низкий;

- форма для ввода категории; уровень низкий;

- форма для ввода районов города; уровень низкий;

- форма для ввода этажности объекта; уровень низкий;

- форма для ввода срока сдачи объекта; уровень низкий;

- форма для ввода средней стоимости квартиры; уровень низкий;

- форма для ввода точной стоимости квартиры; уровень средний;

- форма для ввода площади квартиры; уровень сложный;

- форма для ввода поправочных коэффициентов; уровень сложный.

Отчёты

- движения денежных средств - уровень сложности средний;

- развернутый отчёт по объектам страхования- уровень сложности простой.

Операции

- расчёт страховой премии;

- поиск по квартирам;

- добавление компании застройщика;

- добавление объектов;

- добавление квартир;

- удаление компании застройщика;

- удаление объектов;

- удаление квартир;

- транзитные операции.

Запросы

Запросы, которые будут выполняться нашей системой:

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

- запрос на сумму страховой премию по каждой компании;

- запрос на сумму страховой премию по каждой квартире.

3.2.1. Расчет функциональных показателей

Функционально-ориентированные указатели (метрики) косвенно измеряют программный продукт и процесс разработки.

Формула расчета функциональных указателей:

FP = метрика*(0,65+0,01*?F_i)

где метрика - общий вес оценок требований пользователей.

?F_i - сумма оценок четырнадцати специфических факторов.

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

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

- внешние выводы - всех выводов, по которым пользователю поступают результаты, вычисленные приложением.

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

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

- внешние интерфейсные файлы - всех логических файлов, на которые ссылается данное приложение.

Таблица 3.1 Оценка сложности экранов

Характеристики	Кол-во всего	Ранг
		Низкий	Средний	Высокий	Всего
Внешние формы	21	11*3=33	2*4=8	8*6=48	89
Внешние выводы	11	4*4=16	5*5=25	2*7=14	55
Внешние запросы	11	4*3=12	5*4=20	2*6=12	44
Внутренние логические файлы	21	11*5=55	8*7=56	2*10=20	131
Итого	-	-	-	-	319

Далее производится обоснование коэффициентов регулировки сложности. Коэффициент регулировки сложности может принимать следующие значения: 0 - нет влияния, 1 - случайное, 2 - небольшое, 3 - среднее, 4 - важное, 5 - основное.

Распределение коэффициентов регулировки сложности (F_i):

1. Параметр передачи данных - 2

2. Распределенная обработка данных - 4

3. Производительность - 5

4. Распространенность используемой конфигурации - 3.

5. Скорость транзакции-5.

6. Оперативный ввод данных - 4

7. Эффективность работы конечного пользователя - 4.

8. Оперативное обновление - 5

9. Сложность обработки - 4

10. Повторная используемость - 0

11. Легкость инсталляции - 1

12. Легкость эксплуатации - 4.

13. Разнообразие условий размещения - 10

14. Простота изменений - 1

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

F_i_:=42

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

FP = Общее_количество * (0,65 + 0,01 * ? F_i)

Рассчитаем FP

FP= 319*(0,65+0,01*42)=341.33

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

COCOMO II. Модель композиции приложений.

Формула расчета трудозатрат в человеко/месяцах: NOP/PROD

где NOP - количество новых объектных указателей

NOP = OP * (100-% Reuse / 100)

OP - общее количество объектных указателей. Для расчета этого показателя необходимо оценить сложность экранов и отчетов создаваемого продукта с учетом поправочных коэффициентов. Результаты расчета и оценок представлены в таблицах 3.4, 3.5, 3.6.

%Reuse - процент повторно используемых компонентов.

PROD - коэффициент оценки возможностей среды и разработчика.

Таблица 3.2 Оценка сложности экранов

Экран	Количество представлений	Количество таблиц данных	Уровень сложности
форма для ввода компаний	5	1	Простой
форма для ввода объектов	4	3	Простой
форма для ввода квартир	5	1	Простой
форма для ввода материала	3	4	Простой
форма для ввода реквизитов компаний	3	4	Средний
форма для ввода типов квартир	3	9	Сложный
форма для ввода плана квартир	4	1	Простой
форма для ввода категории	3	1	Простой
форма для ввода районов города	1	1	Простой
форма для ввода этажности объекта	1	1	Простой
форма для ввода срока сдачи объекта	1	1	Средний
форма для ввода средней стоимости квартиры	1	1	Средний
форма для ввода точной стоимости квартиры	1	1	Средний
форма для ввода площади квартиры	2	4	Простой
форма для ввода поправочных коэффициентов	5	9	Сложный

Таблица 3.3 Оценка сложности отчетов

Отчет	Количество представлений	Количество таблиц данных	Уровень сложности
движения денежных средств	1	9	Средний
развернутый отчёт по объектам страхования	1	4	Простой

Таблица 3.4 Объектные указатели

	Количество	Вес	Итого
		Простой	Средний	Сложный
Экран	15	9*1 = 5	4*2=8	2*3=6	19
Отчет	2	1*2 = 2	1*5=5		7
Итого					26

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

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

В объектных указателях могут быть использованы некоторые уже существующие функции, количество их составляет 10% от всех объектных указателей (%REUSE = 10%)

NOP = 26*0,90 = 23,4

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

NOP/PROD = 23,4/13 = 1,8чел/мес.

Это означает, что если разработкой приложения будет занят один человек, то это займет 1,8 месяца.

COCOMO II. Модель раннего этапа проектирования

Формула расчета затрат

Затраты = А*Размер^B*Me

где A - масштабный коэффициент

Размер - количество строк кода создаваемого программного продукта

B = 1,01 + 0,01?b_i

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

Me = П EM_i

Оценка масштабных факторов для разрабатываемой ИС представлена в Таблица 3 _ 5

Таблица 3.5 Оценка масштабных факторов

Фактор	Количество	Описание
Предсказуемость	2	У предприятия есть опыт разработки подобных систем.
Гибкость разработки	0	клиент установил только общие цели
Разрешение архитектуры	5	Нет анализа рисков
Связность группы	0	Проблем взаимодействия нет
Зрелость процесса	2	Имеет место некоторое управление процессом
Итого	9

В = 1,01 + 0,01 * 9 = 0,1

M_e - множитель поправки, зависящий от набора формирователей затрат M_i. M_i оцениваются в диапазоне (1,6); 1 - очень низкий, 6 - сверх высокий.

M_e= П Е * M_i,

E - табличный коэффициент.

Таблица 3.6 Расчет значения факторов

Фактор	Количество	Значение
Возможности персонала PERS	2	1.19
Надежность и сложность продукта RCPX	3	1
Возможности повторного использования RUSE	6	1.49
Трудности платформы PDIF	3	1
Опытность персонала PREX	3	1
Средства поддержки FCIL	2	1.3
График SCED	2	1.1

Множитель поправки, который определяется на основе формирователей затрат, равен: M_e= 1,19*1*1,49*1*1*1,3*1,1=2,53

А = 2,5

Размер = FP * 32 = 341,33 * 32 = 10,922 (тыс. строк)

Отсюда, оценка трудозатрат равна:

ЗАТРАТЫ = 2,5 * 10,922^1,1* 2,53+ 0 =87,74 (чел/дней)

Определение эффекта от внедрения ИС

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

Для определения стоимости выполнения процесса модели «AS-IS» оценим время, на выполнение процессов и посчитаем стоимость исполнения процесса (чтобы оценить потери компании, т.к. процесс контроля качества не является основным бизнес-процессом компании). Для этого возьмем почасовую ставку исполнителя, если бы он занимался основными бизнес-процессами. В среднем за месяц возникает 12 проблемы, около 7 требований, 315 инцидентов, 3 достижений.

Таблица 3.7 Смета затрат на выполнение процессов сотрудниками в модели «AS-IS»

Центр затрат	Исполнитель процесса	Часов в месяц	Ставка (руб/час)	Итого (руб)
Преобразование нормативной информации	Менеджер по работе с клиентами	1*10 = 10 ч.	300	3000
Расчёт страховой премии	Менеджер по работе с клиентами	2*50 = 100 ч	300	30000
Составление отчетов	Менеджер по работе с клиентами	1*15=15	300	4500
Итого		125ч..		30750

Аналогично рассчитаем смету затрат на выполнение процессов сотрудниками для модели «TO BE»

Таблица 3.8 Смета затрат на выполнение процессов в модели «TO-BE»

Центр затрат	Исполнитель процесса	Часов в месяц	Ставка (руб/час)	Итого (руб)
Нормализация исходной информации	Менеджер по работе с клиентами	3*5=15	300	4500
Работа с сервисами	Менеджер по работе с клиентами Финансовый директор	3*3=9	300	2700
Расчёт страховой премии	Менеджер по работе с клиентами	3*4=12	300	3600
Составление отчетов	Менеджер по работе с клиентами	1*0,5=0,5	500	250
Итого		36,5		11050

Внедрение системы приведет к ежемесячной экономии на исполнении процессов контроля качества в размере 30750- 11050 = 19700 руб., можно ожидать сокращения затрат на исполнение процессов на 43%. Снижение стоимости бизнес-процесса возможно за счет замены части ручной работы и расчетов на автоматизированные процедуры.

Модель TO BE представлена в Приложении 2.

Расчет показателей эффективности

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

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

Экономические выгоды от работы информационной системы можно классифицировать так:

- сокращение затрат;

- качественные результаты;

- стратегические результаты.

Система Project Expert Holding позволяет моделировать деятельность предприятий различных размеров - от небольшого частного предприятия до холдинговых структур. С ее помощью можно создавать проекты любой сложности - от расчета окупаемости нового оборудования до оценки эффективности диверсификации деятельности предприятия. В нашем случае Project Expert Holding является инструментом оценки эффективности внедрения новой информационной системы [21].

Для расчёта эффективности проекта необходимо:

- ввести финансовые параметры проекта;

- определить ресурсы и сформировать календарный план;

- определить источники финансирования;

- ввести регулярный эффект от проекта на стадии эксплуатации;

- ввести затраты на маркетинг, управление и производство;

- рассчитать показатели эффективности проекта;

- сделать заключение о выгодности проекта.

Ввод финансовых параметров проекта

На рис.3.1 представлена форма для ввода сведений о проекте:

Рис.3.1 Ввод сведений о проекте

В качестве продуктов будут выступать внешние отчеты, договоры, заявки, автоматизированное создание которых и будет приносить эффект в виде снижения затрат. Началом «продаж» будем считать 1.02.2009 - дату полного внедрения ИС (рис.3.2)

Рис.3.2 Ввод сведений о поступлениях (экономическом эффекте)

Далее необходимо учесть влияние налогов. В нашем случае применим только ЕСН (26% с заработной платы персонала, занятого непосредственным созданием ИС). Иные виды налогов при расчете сметы затрат не учитываются, т.к. компания разрабатывает ИС собственными силами (рис.3.3)

Рис.3.3 Ввод сведений о налоге

Ввод ресурсов и формирование календарного плана

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

Рис.3.4 Ввод сведений о ресурсах

На рис.3.5 представлен календарный план проектной части.

Рис.3.5 Календарный план проектной части

Определение источников финансирования

Далее необходимо рассмотреть источник финансирования проекта. Организация-заказчик владеет достаточными собственными средствами для создания новой информационной системы. Потому нет необходимости привлекать заемные средства, которые будут снижать доходность проекта из-за выплачиваемых процентов за кредит. Необходимые средства будут выделены из бюджета компании к моменту начала разработок (01.09.2009г.) в объеме - 20000 руб. На рис.3.6 представлена форма для определения источников финансирования. На рис.3.7 отображена форма для заполнения собственных денежных средств компании.

Рис.3.6 Формирование источников финансирования

Рис.3.7 Собственные средства компании

Формирование поступлений от проекта (эффект)

Рассмотрим пункт «Другие поступления». На основании результатов функционально-стоимостного анализа, имеем: эффект (экономия) от использования аналитической информационной системы составляет 19700руб. в месяц. Зная, что данный положительный эффект будет наблюдаться ежемесячно на протяжении всего периода использования системы после полного внедрения ИС (с 1.01.2009г), введем эту информацию (рис.3.8).

Рис.3.8 Ввод информации о поступлениях от проекта

Ввод затрат на управление и производство

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

Расходы управленческого персонала включены в оплату труда исполнителя проекта, который исполняет обязанности, аналитика, программиста, специалиста по внедрению. Занесем данные о заработной плате исполнителя в план персонала (рис.3.9).

Рис.3.9 Ввод затрат на персонал

Расчёт финансовых отчётов и показателей эффективности

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

Рис.3.10 Ввод ставки дисконтирования

На рис.3.11 представлен отчёт «Прибыли-убытки».

Рис. 3_11 Отчёт о прибылях и убытках

На рис.3.12 представлен отчет «Кэш-фло».

Рис.3.12 Отчёт «Кэш-фло»

На рис.3.13 представлен отчёт «Баланс».

Рис.3.13 Баланс

На рис.3.14 представлены показатели эффективности инвестиций в проект.

Рис.3.14 Показатели эффективности

Заключение о выгодности проекта

Проанализируем полученные показатели эффективности:

1. Период окупаемости (PB) равен 5 мес., следовательно, уже через 6 месяца после внедрения новой ИС предполагается оправдать вложенные средства.

2. Чистый приведенный доход представляет разность между дисконтированными затратами и поступлениями (эффекта) от создания и использования ИС. Следовательно, руководители страховой компании могут рассчитывать на 127 630руб. в случае использования новой ИС в течение 1 года.

4. Индекс прибыльности демонстрирует, что за 1 год эффект (экономия) от использования АИС в 2,32 раза больше вложенных в нее средств.

5. Из ниже приведенного графика (Рис.3.15) видим, что первые 3 месяцев разработки системы компания имеет убытки, связанные с затратами на создание ИС и отсутствием недостаточностью доходов от ее использования. Начиная с 5 месяца вплоть до середины июня 2009г. наблюдается период окупаемости. Система полностью окупится за 6 месяцев. Наличие положительного эффекта объясняет целесообразность создания новой информационной системы.

Рис. 3_15 График окупаемости

Таким образом, можно считать доказанным тот факт, что компании целесообразно создать информационную систему.

ЗАКЛЮЧЕНИЕ

В процессе работы над дипломным проектом было проведено обследование предметной области: проанализированы информационные потребности предприятия, выявлены проблемы, связанные с отсутствием интегрированной информационной системы на предприятии ЗАО «Фарт» и определены требования к информационной системе.

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

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

- построена модель информационной системы «Учёта страховых премий для строящегося жилья в страховой компании» с помощью программного продукта Computer Associates AllFusion Process Modeler BpWin 4.1;

- спроектированы модели данных (логического и физического уровней) с помощью программного продукта Computer Associates AllFusion ErWin Data Modeler ErWin 4.1;

- создана база данных с помощью программного продукта Microsoft SQL Server 2005;

- реализовано клиентское приложение на Delpfi 7.0.

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

После проведения работ по внедрению системы была рассчитана эффективность проекта и составлен бизнес-план.

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

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

1. Башмаков А.И., Башмаков И.А. «Интеллектуальные информационные технологии», М.: Изд-во МГТУ им. Н.Э. Баумана 20005год;

2. Гергенов А.С. «Информационные технологии в управлении», М.: Изд-во МГТУ им. Н.Э. Баумана 20005год;

3. Балдин К.В., Уткин В.Б. «Информационные системы в экономике», М, 2003год;

4. Банк В.Р., Зверев В.С. «Информационные системы в экономике», Экономист, 2005 г.

5. Введение в страхование. Учебное пособие Шахов В.В.

6. Комментарий к страховому законодательству Фогельсон Ю.Б.

7. Российское страхование: системный анализ понятий и методология . Юлдашев Р.Т., Тронин

8. Финансово-экономические методы страхования: Учебник Гвозденко А.А.

9. Бурков В.Н., Заложнев А.Ю., Кулик О.С., Новиков Д.А. Механизмы страхования в социально-экономических системах. М.: ИПУ РАН, 2001. - 109с.

10. Граве К.А., Лунц Л.А. Страхование. - М.: Госюриздат, 1960. - 175 с.

11. Грищенко Н.Б. Основы страховой деятельности: Учебное пособие. Барнаул: Изд-во Алт. ун-та, 2001. - 274 с.

12. Лузин В. П. Информационно-технические основы создания системы управления крупными рисками в страховой компании. - М.: БУКВИЦА, 2000 146 с.

13. Николенко Н.П. Реинжиниринг бизнес-процессов страховой компании. Учебное пособие. - М.: Издательский дом „Страховое ревю“, 2001. - 123 с.

14. Тенденции и перспективы развития страхования в России / Под ред. Астаповича А.З., Котлобовского И.Б. - М.: Диалог МГУ, 1999. - 80 с.

15. Кадыков М.В. «CRM-системы для малого и среднего бизнеса» - СПб, 2007 http://www.monitor-crm.ru/aboutcrm/aboutcrm9/

16. Пашутин С. Управление взаимоотношениями с клиентами // ПВ -№ 10, октябрь2005

17. http://www.promved.ru/articles/article.phtml?id=592&nomer=23

18. Анохин С.И. Технологии построения корпоративной информационной системы (КИС). http://www.talgar.ru/actions/2001/2001k/program.asp

19. Методические рекомендации по оценке эффективности инвестиционных проектов (вторая редакция). Издание официальное. М.: Экономика, 2000.

20. Вендров А. М. CASE - технологии. Современные методы и средства проектирования информационных систем - М.: Финансы и статистика, 1998 176 с.

21. Бугорский В.Н. Экономика и проектирование информационных систем. СПб.: Роза мира, 1998.

22. Альпина Паблишер. Управление проектом. М.: Бук Чембер Интернэшнл, 2001

23. Международный стандарт ИСО 9000-3: 1991 Общее руководство качеством и стандарты по обеспечению качества. Часть 3: Руководящие указания по применению ИСО 9001 при разработке, поставке и обслуживании программного обеспечения.

24. Вендров А. М. CASE -- технологии. Современные методы и средства проектирования. М.: Фин. и Ст. 1998.

25. Международный стандарт ИСО 9001 Системы Качества. Модель для обеспечения качества при проектировании и/или разработке, производстве монтаже и обслуживании.

26. Гофман В.Э., Хомоненко А.Д. Delphi7.-СПб.: БХВ-Санкт-Петербург, 2003.- 1216с.:ил

27. Бобровский С. И. Delphi7.-СПб.: БХВ-Санкт-Петербург, 2004.-736с.: ил

28. Гофман В.Э., Хомоненко А.Д. Работа с базами данных в Delphi7.-СПб.: БХВ-Санкт-Петербург, 2003.- 624с.: ил

29. Каратыгин С.А., Тихонов А.Ф.- Энциклопедия по СУБД Paradox 4.5: В 2т.- М.:Мир, 1994. - 520с.

Приложение

1. Модель IDF0 для учёта страховых премия для строящегося жилья AS IS

2. Модель IDF0 для учёта страховых премия для строящегося жилья TO BE

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

4. Модель DFD работы с системой принятия управленческих решений в страховой компании

5. Логическая ER модель

6. Физическая ER модель