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

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

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

· достаточная полнота информации для решения задачи;

· исключение избыточности информации;

· достоверность и своевременность информации;

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

· логичность построения документа;

Существует три способа организации информационной базы (ИБ): файловая организация ИБ; интегрированная ИБ, смешанная организация ИБ.

Под файловой организацией ИБ понимается локальное размещение базы на компьютере, доступ к которому других пользователей осуществляется стандартными методами ОС для обмена данными по сети, например в MS Windows это Sharing и Security, что уменьшает скорость обработки данных в локальной базе. Под смешанной организацией ИБ подразумевается распределённая база данных, хранящаяся на нескольких серверах и реплицирующая изменения в каждой из них по расписанию, данная структура ИБ используется в системах класса ERP для работы в одной ИБ территориально удалённым офисам одновременно.

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

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

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

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

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

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

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

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

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

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

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

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

- электронное письмо от сотрудника компании \с описанием неисправности на неформальном языки в сфере ИТ

- регламент работы службы горячей линии

- ежедневное письмо о присутствии Сотрудников IT по всем направлениям.

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

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

- Отчет по согласованным заявках

- Отчет заявок по местоположению заявителя

-Отчет о логике назначения заявителя.

Для решения поставленной задачи задействованы такие классификаторы объектов, как: города, регионы, улица, код описания неисправности

Таблица 6. Описание используемых классификаторов.

Наименование кодируемого множества объектов	Значимость кода	Система кодирования	Система классифи-кации	Вид классифи-катора
Регион	4	Порядковая	Отсутствует	Локальный
Город	4	Порядковая	Отсутствует	Локальный
Улица	4	Порядковая	Отсутствует	Локальный
Код описания неисправности	4	Порядковая	Отсутствует	Локальный

1.4.2 Обоснование проектных решений по программному обеспечению

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

Критериями выбора ПО, установленного на ПК пользователей является максимальная минимизация времени процесса описание заявки/неисправности пользователей и отправки заявки используя корпоративную почту компании. В рамках корпоративного стандарта в компании используется MS outlook 2003. Для запуска этой программы на компьютере пользователя должна быть также установлена ОС , поддерживающая запуск данного приложения. В связи с корпоративным стандартом использования версии ОС MS Windows XP PRO, так как это самая младшая версия ОС, поддерживаемая компанией Microsoft в России (windows 2000 и 9x на данный момент уже не поддерживаются) и имеющая возможность работать в доменной инфраструктуре (версия Windows XP Home не поддерживает работу в домене).Исходя из этих обоснований критерий Win XP Pro sp3 Rus будет использована в качестве пользовательской ОС. Итог: на рабочих станциях пользователей (клиентов) должны быть установлены следующие программные продукты:

· Операционная система Windows XP Pro sp3 Rus

· Почтовый клиент MS outlook 2003

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

Критериями выбора архитектуры реализации проектируемого Программного Комплекса являются:

1. совместимость с существующей инфраструктурой серверов

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

При выборе ОС под данное решение был выбран MS Windows Server 2003, так как данный вид серверных ОС не сильно требователен к ресурсам, а также давно используются в инфраструктуре компании.

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

Таблица 7. Варианты СУБД систем.

Название СУБД Характеристики	Microsoft SQL Server 2005	InterBase 2009	Oracle 11.2.0.1
Встраиваемая аутентификация пользователей	да	да	нет
Мониторинг работы базы данных	да	да	да
Возможность создание временные таблицы	да	да	да
Ведение журнала действий с базами данных и подключение	да	да	да

В качестве СУБД для программы будет использоваться Oracle 11 ver 11.2.0.1. Выбор в пользу компании Oracle сделан не случайно, основная информационная система учёта заявок HP OpenView Service Desk построена на на именно такой базе данных.

Закупка нового сервера не обязательна, так как база данных программного продукта может быть расположена на уже имеющемся сервере «SD». При создании данного сервера компания закладывала около 50% мощности закупаемого сервера на будущую масштабируемость системы, но не смотря на рост базы данных за 3 года загруженность сервера возросла всего на 15% .

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

Рассмотрим основные методы и средства проектирования. В таблице 8 сравниваются между собой основные средства проектирования.

Таблица 8. Основные средства проектирования.

Название Характеристики	Microsoft Visual C++ (MSVC)	Delphi 2010	Python
Совместимость с операционной системой Windows 2000, Windows XP и Windows Vista	да	да	да
Встроенный редактор интерфейса	да	да	да
Совместимость с другими языками программирования	да	нет	да

Написание программы сервиса, обрабатывающего почтовый ящик было решено на языке python. Такой выбор был сделан не случайно: Во первых администратор ИС “HP OpenView ServiceDesk” имеет опыт работы с данным скриптовым языком программирования. Во вторых данный язык действительно не сложен в освоении и среди фрилансеров в интернете легко найти программиста, который при правильно поставленном техническом задании сможет в поставленные сроки выполнить данную разработку, стоимость разработки по на python гораздо ниже, чем разработка на основе таких громоздких продуктов как Borland C++ или Microsoft Visual C++ . В третьих, данный язык очень активно развивается и имеет открытую архитектуру и легко позволяет сделать графический интерфейс в виде HTML странички (web -интерфейс)

1.4.3 Обоснование проектных решений по техническому обеспечению

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

Для функционирования программы (службы) по обработке заявок горячей линии в рамках дорабатываемой ИС HP OpenView ServiceDesk потребуются следующие элементы технического обеспечения:

· ПК-сервер - это основная ЭВМ, на которой уже развернута сама база данных в СУБД а также данный сервер будет являться сервером БД. На нем же будет размещён сервис(служба) которая и будет производить регистрацию и обработку заявок в автоматическом режиме. Характеристики данного сервера представлены в таблице №6

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

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

· ПК-инженера/горячей линии (рабочая станция) - это пользовательский ПК, на котором будет установлена программа клиент, которая будет фиксировать и распределять заявки;

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

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

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

Главными критериями выбора серверной платформы являются специфика решаемых сервером задач и количество автоматизированных рабочих мест, которые объединяются в сеть. После этого остается только выбрать производителя. [16]

Для Сервера СУБД сервера в рамках одного ПК основным критерием выбора будет отказоустойчивость и пропускная способность сетевого интерфейса Исходя из среднего арифметического количества заявок в день, которое составляет 500 заявок и ежеминутным опросом программы базы данных на наличие новой заявки в базе, а также загруженности сетевой инфраструктуры на 30% и загруженности корпоративного сервера баз данных на 25% нет необходимости закупать высокопроизводительный сервер с сетевым адаптером скоростью в 1Gbps, достаточно ограничиться интерфейсом в 100Mbps. Итогом анализа критериев по серверному оборудованию будет использование того же сервера , который использовался в компании ранее. В качестве сервера баз данных (БД) используется сервер, построенный на платформе HP ProLiant DL365 G5, он обладает следующими характеристиками, представленными в таблице № 9.

Таблица 9. Характеристики сервера БД.

Характеристика	Значение
Процессор	Двуядерный Intel® Xeon® X5260 с тактовой частотой 3,3 Гц.
Кол-во процессоров	2
Оперативная память	16 Гб (расширяемая до 64Гб)
Жесткие диски	Тип «SAS» 4 диска 147 Гб и 2 диска 73 Гб
Кол-во жестких дисков	6 (расширяемо до 8)
Питание	Дополнительно резервный блок питания 800Вт с горячей заменой

Рассмотрим данную платформу подробнее:

· Два процессора позволяют, при использовании SQL сервера, эффективно распараллеливать задачи, выполняемые на сервере.

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

· Использование 6 жестких дисков обусловлено следующими соображениями:

Для надежного функционирования операционной системы сервера организован RAID массив из двух жестких дисков каждый по 73 ГБ (такого объема достаточно для работы ОС). Операционная система специально расположена отдельно от файлов БД из соображения безопасности и производительности.

Для надежного хранения данных в формате Structured Query Language (SQL) организован массив жестких дисков большего объема 147Гб. Данного объема достаточно для внедрения нового функционала, на данный момент объем занятого пространства занимает 53Гб, при условии того что в БД храниться записи за 3 года.

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

· Использование дополнительного питания повышает отказоустойчивость системы.

Для ПК-пользователя и ПК-инженера основными критерием выбора оборудования в данном случае являются его технические характеристика, и что не менее важно, соответствие утвержденным корпоративным стандартам. Таким образом, для персональных компьютеров основным критерием выбора является утвержденный список конфигураций ПК.(MB Asus P5 CPU: Core2Duo 2.9Ghz Ram:2 Gb ) Характеристики данной конфигурации описаны в таблице № 10

Таблица №10. Характеристика конфигурации ПК пользователя.

ПАРАМЕТР	ЗНАЧЕНИЕ
Корпус	Minitower IN-WIN "EMR-003", mATX, черно-серебр. (450Вт)
Процессор	Intel "Core 2 Duo E7500" (2.93ГГц, 3МБ, 1066МГц, EM64T) Socket775 (oem)
Кулер для процессора	Socket775 Arctic Cooling "Alpine 7 GT" (ret)
Вентилятор	GlacialTech "SilentBlade II GT9225-EDLA1" d90мм, 1600об./мин. (питание от мат.платы и разъёма питания ATA HDD) (oem)
Материнская плата	Socket775 ASUS "P5G41-M LE/C/SI" (iG41, 2xDDR2, U100, SATA II, PCI-E, D-Sub, DVI, SB, 1Гбит LAN, USB2.0, mATX) (oem)
Модуль оперативной памяти	2ГБ DDR2 SDRAM Kingston "ValueRAM" KVR800D2N6/2G (PC6400, 800МГц, CL6) (ret)
Жесткий диск	320ГБ Seagate "Barracuda 7200.12 ST3320418AS" 7200об./мин., 16МБ (SATA II) (oem)
Привод DVD±RW	24x8x16xDVD/48x32x48xCD Sony Optiarc "AD-7260S", черный (SATA) (oem)
Устройство чтения карт памяти	CF/MD/SM/MMC/SD/MS/MS Pro Sony "MRW620", в 3.5" отсек, черный (USB2.0) (oem)

Для почтового сервера критериями выбора будет отказоустойчивость и высокая скорость работы подсистемы обработки данных. Для него будут использоваться высоко производительные жёсткие диски WD RAPTOR со скоростью вращения шпинделя более 12000 об в мин. И отдельный RAID контроллер, поддерживающий реализацию массива данных Raid 10, который предоставляет и высокую скорость работы и высокую отказоустойчивость подсистемы данных. Конфигурация почтового сервера, функционирующего в компании совпадает с указанными критериями, поэтому оставляем то, что есть. Упрощенная конфигурация почтового сервера описана в таблице № 11

Таблица № 11. Аппаратная конфигурация почтового сервера

Форм-фактор	2U
Код	X5650
Модель	Intel® Xeon®
Количество ядер	6
Количество процессоров (установлено)	2
Тактовая частота	2660 МГц
Intel Smart Cache	12 Mb
Разъем (сокет)	FCLGA1366
Тип памяти	DDR3 1066 МГц
Объём одного HDD	2 Гб
Общий объём	892 Гб
Количество HDD	4 шт
Интерфейс	SAS/SATA
Количество сетевых адаптеров	4 шт
Скорость подключения	1 Гб/с
Тип видеокарты	Дискретная
Оптический привод	DVD±R
USB	4 шт
RJ45 (LAN)	2 шт
Monitor port (VGA)	Есть
Мощность блока питания	570 Вт
Количество блоков питания	2 шт
Возможность горячей замены	Есть

Для средств организации ЛВС критерием выбора будет тип кабеля и пропускная способность. На данный момент по анализу сетевого трафика программой Net Send загруженность сети составляет 36%. Соответственно, свободная пропускная способность составляет 64% от общей пропускной способности СКС. Обрабатываемые службой(сервисом) 500 заявок в день и ежеминутный опрос почтового сервера добавит загруженность сети всего на 3-5%, что никоим образом не повлияет не её пропускную способность и появление коллизий. Из типа кабеля по скоростным параметра предпочтительнее выбрать витую пару вместо устаревшего коаксиала из за ограничения по максимальной пропускной способности коаксиала в 10 Mbps. В соответствии с указанными в пункте 1.1.3 схемами сетевой организации становится ясно, что при использовании свитчей и коммутаторов класса CISCO(WS-C3560G-24TS и PIX-515E (FO)) сеть работает на скорости 100Mbps а на некоторых участках и 1Gbps.

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

2.1 Разработка проекта автоматизации

2.1.1 Этапы Жизненного Цикла проекта автоматизации

Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. Существует несколько моделей и стандартов, в той или иной степени регламентирующих жизненный цикл, большинство из них относятся к заказному ПО (автоматизированным системам АС, и др.) и кроме непосредственно ЖЦ регламентируют также и процессы разработки:[18]

ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [2].

ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий этапов.[3]

Custom Development Method (и, методика Oracle) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Степень адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track), "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы [3]. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (UML), а так же конкретной технологии проектирования и разработки (объектно-ориентированный анализ, object-oriented analysis, OOA, объектно-ориентированное программирование, object-oriented programming, OOP).

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. [8]. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование является самым новым среди рассматриваемых методологий, сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Основными критериями для выбора стандарта ЖЦ будут:

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

разработка в итерационном режиме с возможностью контролировать риски

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

Резюмируя описание стандартов выше итерационными из них являются 4 стандарта: MSF, RUP, COBIT, XP .

Стандарт COBIT мне не подходит, потому что основной целью его использования “является проведения аудита и стратегического планирования ИС и IT инфраструктуры в целом”[18]

Стандарт XP мне тоже не подходит, так как он не содержит полноценных этапов ЖЦ, таких как выработка концепции, планирование, разработка, стабилизация, внедрение.

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

Основные особенности MSF, RUP и XP сведены в таблицу 10. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.

Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP - сопровождение. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации. В таблицк № 12 представлены основные показатели стандартов Жизненного цикла ИС

Таблица 12. Технологии MSF, RUP и XP

Технология	Оптимальная команда	Соответствие стандартам	Допустимые технологии и инструменты	Удобство модификации и сопровождения
Rational Unified Process	10 - 40 чел.	стандарты Rational	UML и продукты Rational	Удобно (RUP)
Microsoft Solutions Framework	3 - 20 чел.	адаптируема	любые	Удобно (MSF+MOF)
XP	2 - 10 чел.	стандарты отсутствуют	любые	Сложно (зависимость от конкретных участников коллектива)

Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.[23]

Наш проект является небольшим, включает в себя 3 человека и этапы разработки и тестирования проводятся в среде разработки Python. Кроме того основным преимуществом MSF является итерационная модель одновременно с уточняющими вехами (аналог каскадной модели). Таким образом, реализация MSF попыталась объединить каскадную и итерационную модель разработки и внедрения ПО[18]

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

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

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

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

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

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

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

Кластер Тестирования формирует Оценка дизайна; требования тестирования; план и календарный график тестирования.. Кластер управление выпуском выполняет функции Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения. К сожалению или к счастью, но в рамках создания и внедрения моего проекта силами сотрудников ИТ департамента, использовать 6 и более человек для фоновой задачи, бюджет которого ограничен лишь премией крайне нецелесообразно. Я объединил задачи кластеров и сформировал из них 3 ответственных лица, они же и есть команда проекта

1)Программист на которого возложены следующие кластеры :

· Управление программой,

· Разработка

· удовлетворение пользователей

2) менеджер проекта, он же внедренец, он же тестировщик, на него возложены следующие кластеры:

· Управление продуктом,

· Тестирование

· управление выпуском .

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

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

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

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

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

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

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

Следующим этапом ЖЦ идёт Фаза стабилизации

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

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

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

Результатами фазы стабилизации являются: Окончательный продукт (golden release), Документация выпуска (release notes), Материалы поддержки решения, Результаты и инструментарий тестирования, Исходный и исполнимый код приложений, Проектная документация. В моём проекте на данном этапе Программистом корректируются ошибки в разрабатываемой им программе, компилируется версия релиз кандидат и после отсутствия критических ошибок по всем веткам функционала программы выпускается окончательная сборка исполняемого кода, параллельно с этим дополняется документация к работе с программой. Руководителем проекта на данном этапе набирает группу тестирования из 2-3 инженеров, которые будут пользоваться этой программой каждый день и тестирует все ветки функционала по разработанным ранее сценариям и формирует дополнения, которые можно будет реализовать в следующей версии.

Следующим этапом будет Фаза внедрения

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

Во время этой фазы по ходу переноса компонент решения из среды тестирования в производственную среду могут продолжаться меры по стабилизации решения. таблица № 13 описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы внедрения. Данная таблица представлена в Приложении №1. Результаты фазы внедрения включают в себя: Информационные системы эксплуатации и поддержки, Процедуры и процессы, Базы знаний, отчеты, журналы протоколов, Массивы данных и программный код, разработанные во время проекта. Отчет о завершении проекта, Показатели удовлетворенности заказчика и потребителей, Описание последующих шагов. На этом этапе Руководитель окончательно внедряет систему в эксплуатацию, устанавливает программный продукт на компьютерах Инженеров ИТ, распечатывает им инструкцию по работе с ней или проводит обучение по её алгоритму работы. Далее Пользователем высылается новый регламент работы ИТ отдела и информацию о новой логике обработки заявок с просьбой в течение недели ответить о замеченных изменениях в обслуживании службой ИТ.

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

· Параллельная стратегия - когда одновременно работают старая (ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время, осуществляется переход на новую систему.

· "Скачок" - это резкий переход от старой системы к новой без дополнительных проверок и с полным отказом от старой системы.

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

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

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

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

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

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

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

1. Задачная модель;

2. каскадная модель (или системная) (70-85 г.г.);

3. спиральная модель (настоящее время).

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

· Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново)

· Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).

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

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

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

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

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

·

Рисунок № 8. Каскадная схема разработки

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

Рис. 9. Реальный процесс разработки ПО по каскадной схеме

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

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

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

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

Рис 10. Спиральная модель ЖЦ ИС

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

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

Сам стандарт MSF даёт некую гарантию минимизации рисков, так как весь ЖЦ проекта разделён на этапы, на каждом этапе есть роли, за которыми закреплены цели, которые должны быть достигнуты и всё же на каждой фазе есть некоторые риски:

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

· Недальновидный анализ сроков проекта и его бюджета

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

· Неправильно подобранный проектный состав исполнителей может повлечь полное отсутствие командной работы

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

На фазе планирования могут возникнуть следующие риски:

· Неправильно или не совсем корректно сформированное архитектура выбираемого решения

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

В фазе разработки возможны следующие риски:

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

Минимизацией данного риска служит более чёткое написание технического задания, понятного программисту

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

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

В фазе тестирования могут возникнуть следующие риски:

· Риски неоконченного тестирования.

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

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

В фазе внедрения могут возникнуть следующие риски:

· Риски неправильного принятия решения о законченности части проекта.

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

Устраняется путем доработки при следующей итерации.

2.1.3 Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации

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

Защита от внутренних угроз. Подразумевает разграничение прав пользователей ИС HP OpenView Service Desk. Подробные права пользователей описаны в таблице № 11

Таблица № 11. Разграничение прав пользователей.

Группы пользователей	Создание заявки	Возможность редактирования своей заявки	Возможность переназначит заявку	Работа с базой знаний
Сетевая группа	Чтение	Есть	Есть	Чтение/создание/удаление
Группа поддержки пользователей	Чтение	Есть	Нет	Чтение/создание/удаление
Горячая линия	Чтение/создание/удаление	Есть	Есть	Чтение

2. Защита от внешних угроз реализуется следующими параметрами:

Во первых все серверные системы в компании ОАО "Росно" не имеют установленных сторонних средств удаленного администрирования, таких как Remote administrator/Dame Ware/Team Viewer. Доступ организован через Remote desktop protocol, на нужный сервер, в том числе и сервер приложений и СУБДгде размещщёна ИС HP open view Service Desk вход осуществялется только по доменной авторизации в соответсвии с уровнем доступа, согласованным по заявке на горячую линию.

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

2.2 Информационное обеспечение задачи

2.2.1 Информационная модель и её описание

Данная информационная модель включает в себя сразу несколько источников. Основной базой данных является база ИС HP OpenView Service Desk. В ней находятся таблицы текущих заявок, справочники Исполнителей (СотрудникИТ) , заявителей - это все сотрудники компании, которые обращаются с проблемами ИТ на горячую линию, в том числе и из регионов. Процесс обращения пользователя на горячую линию реализуется через письмо на горячую линию, что также отражено на Информационной модели. Разработанная в данном дипломном проекте служба(сервис) обрабатывает почту , находя новые заявки и обрабатывая письма, связанные с уже зарегистрированными заявками(например согласование доступа). Данная служба обращается к базе данных HP OpenView Service Desk, в рамках которой созданы специальные таблички для ведения учета и получения статистики, а также добавления справочника ключевых слов. Основной таблицей в этой базе данных является таблица зарегистрированных заявок(Registered Letter). Данная таблица также фиксирует то, что было обработано данной службой и является основной в данном дипломном проекте. Для классификации проблемы по тексту письма, исполнителей заявки (ИТ специалистов) и группы(отдела), к которым принадлежит исполнитель были спроектированы следующие таблицы: It Worker, Klassification, IT_Group.