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

/

Введение

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

В данном дипломном проекте будет исследоваться деятельность страховой компании ОАО “Росно”. Данная компания является лидером в российской системе страхования с рейтингом А+.

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

В первой главе данного дипломного проекта будет проведен анализ существующей системы технической поддержки и горячей линии, будут отобраны слабые места для их более глубокой автоматизации. В компании ОАО “Росно” внедрена система Сервис Деск HP Open View. Кроме анализа самой системы будет проведен анализ загруженности самих специалистов горячей линии и насколько их действия можно выполнять автоматически.

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

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

1. Аналитическая часть

1.1 Технико-экономическая характеристика предметной области и предприятия. Анализ деятельности ОАО СК «РОСНО»

1.1.1 Характеристика предприятия и его деятельности

Группа компаний РОСНО является одной из крупнейших страховых групп в России. В нее входят универсальная страховая компания федерального уровня ОАО СК «РОСНО» и ее дочерние компании: ОАО «РОСНО-МС», ОАО «Альянс РОСНО Управление Активами», СЗАО «Медэкспресс», НПФ «Альянс» и ОДО «Аllianz Украина».

Контрольным пакетом акций РОСНО владеет Allianz New Europe Holding GMBH (100% -- 1 акция), подразделение ведущего международного страховщика Allianz SE, объединяющее компании в Центральной и Восточной Европе.

Главным принципом деятельности Группы компаний РОСНО является забота о клиентах. Страховые полисы и договоры ГК РОСНО имеют более 17 млн. человек и свыше 50 тыс. предприятий и организаций.

ОАО СК «РОСНО» создано в 1991 г. и является одной из крупнейших российских универсальных страховых компаний. В распоряжении ее клиентов более 130 видов добровольного и обязательного страхования. Региональная сеть РОСНО насчитывает 88 филиалов, объединенных по территориальному признаку в 8 дирекций, и 383 агентства во всех субъектах РФ.

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

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

Уставный капитал -- 5 124 802 тыс. руб. Собственные средства -- 7 405 806 тыс. руб., страховые резервы -- 20 461 284 тыс. руб. (по состоянию на 30.06.2010).

РОСНО имеет качественную облигаторную перестраховочную защиту принимаемых рисков. Партнеры компании по перестрахованию -- Allianz, Hannover Re, SCOR, Munich Re, Swiss Re, крупнейшие российские перестраховочные компании. РОСНО также сотрудничает с брокерскими агентствами корпорации Lloyd's.

РОСНО участвует в деятельности 37 (по состоянию на 23.04.2010) профессиональных и отраслевых объединений, ассоциаций и союзов.

В 2007 году международное рейтинговое агентство Moody's Investors Service присвоило РОСНО рейтинг финансовой устойчивости страховщика по международной шкале на уровне Baа1. Прогноз рейтинга -- «стабильный». Одновременно с этим рейтинговое агентство Moody's Interfax присвоило РОСНО рейтинг Ааа.ru по национальной шкале.

В национальном рейтинге страховых компаний России, проводимом рейтинговым агентством «Эксперт РА», РОСНО с 2001 года присваивается наивысший рейтинг А++ «Исключительно высокий уровень надежности». При определении рейтинга в 2008 году рейтинговое агентство впервые распространило данную оценку на Группу компаний (ОАО СК «РОСНО» и ОАО «РОСНО-МС»).

В 2007 году РОСНО первой среди российских страховых компаний обеспечила соответствие информационной безопасности основных бизнес-процессов международным требованиям. Система управления информационной безопасностью компании прошла сертификационный аудит на соответствие требованиям стандарта ISO/IEC 27001:2005.

РОСНО -- неоднократный лауреат премии «Компания года», в том числе в 2007 году, и внесено в реестр надежных партнеров ТПП РФ. РОСНО -- обладатель Национальной награды в области создания и продвижения брэндов: Золотой БРЭНД ГОДА/EFFIE 2005.

В 2007 году в рамках проекта Международный Листинг Брэндов (Brandlisting.com) брэнд РОСНО был оценен агентством V-RATIO Business Consalting Company в 444,6 млн. долларов США.

РОСНО является победителем ежегодного рейтинга «Народная Марка» за 2003 и 2005 годы в категории «Страховая компания».

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

Компании, входящие в Группу, неоднократно становились лауреатами ежегодной общественной премии в области страхования «Золотая саламандра» (с 2004 по 2010 годы -- 22 награды, из них 15 -- ОАО СК «РОСНО»). Премией в номинации «Информационно открытая компания» СК «РОСНО» награждалась пять раз, а в номинации «Качество страховых услуг» -- дважды.

По результатам, подготовленным рейтинговым центром Института экономических стратегий (ИНЭС), РОСНО три года занимает 1 место в ежегодном рейтинге «50 наиболее стратегичных страховых компаний».

РОСНО -- победитель ежегодной премии журнала «Финанс» в номинациях «За продвижение европейских стандартов в российское страхование» (2006 г.) и «Самая информационно открытая компания» (2010 г.).

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

В 2008 году РОСНО стало победителем в номинации «Лучший страховщик в перестраховании 2007», учредителем которой выступил оргкомитет Ежегодной Всероссийской конференции по перестрахованию.

В 2008 году РОСНО удостоилась звания IT-Лидера в области страхования за выдающийся вклад в развитие информационных технологий в России.

Представители управленческой команды РОСНО не первый год входят в топ-5 страхового сектора в рейтинге «Топ-1000 российских менеджеров» (проект Ассоциации менеджеров России и газеты «Коммерсантъ»).

РОСНО два раза признано «Финансовой жемчужиной России» (ежегодная общественная премия 'Лучшие финансовые услуги населения«/Лучший финансовый ретейл). В 2008 г. -- в номинации «За самый невероятный случай, оплаченный страховщиком». В 2009 г. компания была признана компанией предоставляющей «Самый широкий спектр страховых услуг».

По результатам исследования за 2008 год, организованного журналом Euromoney, СК «РОСНО» признана «Лучшей страховой компанией России».

В 2009 г. согласно результатам исследования компании Online Market Intelligence (OMI) и делового еженедельника «Компания» бренд РОСНО был признан «Любимым брендом россиян» в категории «страхование».

В 2009 г. в рамках проводимого «Эксперт РА» Ежегодного форума топ-менеджеров «Будущее страхового рынка России» РОСНО стало лауреатом в номинации: «За неизменную надежность и открытость» и «Лидер рынка страхования выезжающих за рубеж».

Основные технико-экономические показатели компании представлены в таблице 1.

Таблица 1. Основные технико-экономические показатели компании.

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

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

1) Администрация

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

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

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

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

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

В Структуре Айти Отдела предусмотрены несколько должностей системных администраторов (Сетевой, Почты, Доменный, Сетевой, ). Программист 1с занимается доработкой конфигураций 1с трёх основных компаний холдинга, + обновление ПО 1С. Инженеры ИТ делятся на две категории, одни работаю т в офисе и выполняют функции суппортов (тех поддержка говоря по нашему), другие обслуживают сеть точек продаж, а именно обеспечивают бесперебойную работу 24/7/365. Также в штате ИТ отдела есть Администраторы БД, в его должностные обязанности входит настройка и администрирование работы корпоративных информационных систем.

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

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

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

4) Служба безопасности следит за доступом людей и ТС на территорию Холдинга, как через КПП с шлагбаумом так и через Систему Контроля Управления Доступом (далее сокр.па СКУД). Также в их распоряжении находится система управления наблюдением на всей территории Холдинга, а именно нескольких административными зданиями.

1.1.3 Программная и техническая архитектура ИС предприятия

На рис. №2 и рис. №3 показана Техническая архитектура строения ОАО “РОСНО” в общем виде, и более детально в центральном офисе на Озерковской набережной. Структура представляет собой целый комплекс сервером, свитчей и саршрутизаторов и серверов. Основным брандмауэром (фаерволом) в системе является CheckPoint NGX R65, он выполняет роль фильтрация трафика и анализа контента, также он выполняет функции инициализации и поддержки VPN-туннелей с удаленными офисами, регионами, сторонними организациями и пользователями. Основные сетевые маршрутизаторы и коммутароры используется от производителя CISCO(WS-C3560G-24TS и PIX-515E (FO)) как самые надежные в своем классе. Соединение удаленных точек продаж и офисов с центральным московским офисом реализовано с помощью услуг интернет провайдера комстар посредством VPN соединения точка точка.

Программная архитектура ОАО “РОСНО”изображена на рис № 3. На всех рабочих станциях сотрудников установлена операционная система Microsoft Windows XP (SP3 Rus), также используется Microsoft Office 2003 (базовая), защиту компьютеров от вирусов обеспечивает Symantec, в качестве корпоративной почты используется система Exchange Server 2007 компании MicroSoft. Также в компании используется 2 информационных системы по тематике основной деятельности компании - страхования и ИС по учёту и контролю исполнения заявок по работе ИТ Департамента.

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

Операторы электронного архива занимаются переводом бумажных данных в электронный документ посредством ИС реализованной совместно с программой ABBY.

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

Отдел горячей линии и Департамент системного и сетевого администрирование ведёт учёт всех заявок пользователей и плановых работ в ИС “HP OpenView Service desk”

В рамках карты архитектуры сети и серверов такой большой компании, с 2 центральными офисами в Москве и Одним крупным офисом в Воронеже достаточно сложно описать всю структуру серверов, активного и пассивного сетевого оборудования, поясню лишь что центральный офис на Озеркоской набережной находится в 10 и 40-ов VLAN-е и имеет выход в интернет через CheckPoint NGX R85. Исследуемая нами система регистрации запросов посредством операторов горячей линии также находится в 40 VLAN-е центрального Московского коммутатора

Рисунок 2: Аппаратная архитектура ОАО “РОСНО”

Рисунок 3: Детализация архитектуры сетей ОАО “РОСНО”

Рисунок 4: Программная архитектура ОАО “РОСНО”

1.2 Характеристика комплекса задач, задачи и обоснование необходимости автоматизации

1.2.1 Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов

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

В компании используется более десяти ИС для обслуживания той или иной деятельности компании. Одной из наиболее важной в обслуживании всей сети компании Росно, в том числе и региональных её отделений, является система приёма заявок о проблемах связанной с ИТ. В него входят учёт заявок для инженеров технической поддержки, администрирование ключевых объектов сетевой инфраструктуры(AD, Mail , BackUp, File, Terminal серверов) , поддержка взаимодействия с внешним миром(Телефония, Мобильная телефония, доступ в интернет, межсетевой экран, антивирусная защита), Поддержка и доработка используемых в компании ИС (РКИС, ЭА, и др.). Описанный выше комплекс задач автоматизирован с использованием ИС 'Hp Open View Service Desk'версии 5.1, датированная концом 2007 года.

Основной ИС по работе в компании является РКИС - корпоративная информационная система Росно. Данная ИС была разработана и Внедрена совместно с компанией IBM в 2006 году и находится на поддержке у компании внедренца. В данную ИС вносятся все данные о страховых полисах, осуществляется расчет выплат, анализ убытков и заключение новых договорах страхования: страхования транспорта, страхования Жизни . Для удаленных офисов с которыми поддерживать постоянное подключение к ИС проблематично организован терминальный доступ посредством Citrix Terminal.

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

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

ИС Service Desk HP OpenView является основной системой по учёту заявок на горячую линию. В данной ИС в день регистрируется более 500 заявок и 100 нарядов. Архитектура данной ИС представляет собой кластер из 2 физических серверов и 5 программными сервисами на каждом из них.

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

Рисунок №5 Комплекс задач Поддержи ИТ компании ОАО “РОСНО”

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

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

2) Поддержание в работоспособном состоянии информационных систем компании (описанные выше Электронный архив, РКИС, Ломбарди);

3) Администрирование сетевой инфраструктуры, доступа в интернет, разграничение прав на сетевые ресурсы;

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

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

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

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

1.2.2 Определение места проектируемой задачи в комплексе задач

Из всего комплекса задач по автоматизации работы департамента информационных технологий мною будет исследоваться работа отдела горячей линии. В состав горячей линии входит 6 дневных операторjd, которые обрабатывают заявки в графике 5/2 и один дежурный администратор, работающий в графике 1/3. В обязанности горячей линии входит консультирование пользователей по телефону, регистрации заявок исходя из телефонных звонков и обработка почтового ящика горячей линии, что в свою очередь включает: регистрацию заявок, назначения на правильную группу и конкретного исполнителя, согласование выполнения работ в нужном формате и с нужными отделами.

Входными данными для создания заявки являются:

· Телефонный звонок с описанием проблемы в неформализованном языке.

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

· Сбои в работе сервисов и серверов

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

· Заявка или наряд, оформленная в соответствии с регламентом.

· Информация о закрытии заявки переданная заявителю(так называемая обратная связь);

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

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

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

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

Процесс формирования и выполнения заявки: Пользователь доводит до сведения ИТ отдел о неисправности, каким либо образом связанной по его мнению, с Информационными технологиями. Заявки, относящиеся к юрисдикции ИТ департамента вводятся в ИС 'HP Open View Service Desk' ручным способом, остальные заявки отклоняются.

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

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

Регламент работы задействованных специалистов:

На первом этапе инженер подбирает архитектуру реализации проекта автоматизации и согласовывает её с системным администратором

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

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

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

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

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

Рис. № 7 Документооборот обработки заявки горячей линии ОАО “РОСНО”

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

Необходимые технические средства на этапах обработки заявок, представленных на рисунке №6 представлены в таблице № 2.

Таблица № 2. Технические средства, используемые на этапах обработки заявки

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

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

Таблица №3. Соотношение показателей затрат на обработку и выполнение заявки.

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

1.2.4 Анализ системы обеспечения информационной безопасности и защиты информации

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

В компании реализована своя политика ИБ и ЗИ: На уровне человеческого фактора и программно. Аппаратно ограничений нет

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

Защиты информации с пользовательских компьютеров в компании реализована только Программно. Реализация ограничение на подключение любых периферийных устройств по портам USB, com, ltp, PCI и выполнена средствами Программного продукта ZLOCK и управляется централизовано на сервере. Для того чтобы подключить новый девайс к компьютеру, который автоматически блокирует новые устройства, следует позвонить на сотруднику СБ, назвать номер заявки в рамках которой производится установка нового оборудования

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

Защита информации в серверной регламентируется следующими ограничения доступа:

1) Права доступа по электронному пропуску (proxy- карта)

2) Роспись за получение и сдача ключа у охранника.

3)Разблокировка датчиков открытия двери у у оперативного дежурного СБ

Средства защиты от инсайдерских угроз в компании следующие:

За каждым пользователем закреплён компьютер/ноутбук и монитор, которые имеют идентификационный ПИН код, за который он несет материальную ответственность.

1.3 Анализ существующих разработок и выбор стратегии автоматизации «КАК ДОЛЖНО БЫТЬ»

1.3.1 Анализ существующих разработок для автоматизации задачи

На сегодняшний момент на рынке ПО существует масса всевозможных как зарубежных, так и Российских предложений и продуктов по автоматизации работы ИТ-отделов компаний, включающих в себя как классический help Desk так и Service Desk а также дополнительный функционал, описанный в библиотеке ITIL.

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

Информационные системы также классифицируются:

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

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

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

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

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

В состав обеспечивающих подсистем обычно входят:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Несмотря на разбиение на классы по перечисленным выше признакам, по функциональности, проектируемая мной система относится к CRM классу.

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

Перед выбором любой информационной системы всегда встаёт вопрос о требованиях к системе и целях, которые планируется достигнуть в результате внедрения. На текущий момент в исследуемой мной компании ОАО “РОСНО” уже внедрена ИС класса Service desk и используется более 2 лет, за это время были осознаны некоторые ошибки внедрения и появились некоторые требования по доработке системы. Итак, основными критериями при выборе технологии решения задачи будут следующие условия:

· суммарный бюджет на проект автоматизации не более 70000руб.

· сокращение времени обработки почтового ящика горячей линии

· контроль над обработанными заявками в автоматическом режиме

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

Похожий программный продукт предлагает и компания Microsoft, Help Desk разработанный на базе SharePoint. Данный Програмный продукт позиционируется как дополнительный модуль к системе документооборота Microsoft Office SharePoint Server и представляет собой web-интерфейс для администраторов системы и пользователей. В данном случае недостатком можно считать то, что сама SD система в отличие от предыдущего ПО от HP является дополнительным модулем к основному программному комплексу, ориентированному на автоматизацию работы в другой области.

Еще одним предложением, правда уже Отечественных разработчиков разработчиков (г. Санкт петербург) является IPI Manager. Это комплекс для создания системы заявок, для управления ИС по запросам клиентов. Написана на языке Python, поддерживает множество СУБД (MYSQL, PostgreSQL собственный формат БД ) может интегрироваться с LDAP каталогом, лицензия - GPL. Эта система имеет открытый программный код. Как недостаток тут можно отметить относительно малый опыт данной компании в реализации данного рода продукта, но при знании скриптового языка Python, можно самому дорабатывать данный продукт.

Основные характеристики представленных продуктов представлены в таблице № 4.

Таблица № 4. Сравнительный анализ ИС класса Service Desk.

Исходя из критериев, которые предъявляет компания ОАО “РОСНО” к целям автоматизации нами был куплен и используется на данный момент ИС HP OpenView servisedesk версии 5.2. В рамках выделенного бюджета на решение текущей задачи по регистрации и обработке инцидентов в 70000руб. на 7000 заявителей 50 инженеров и 40 администраторов работающих в системе. не подходит внедрение ни одной из конкурирующих ИС. Кроме того, мы рассмотрели много бесплатных вариантов на платформе Windows и под Linux. В большинстве случаев их интерфейс перегружен. Минус в том, что новые заявки подлежат обязательному многоэтапному согласованию с пользователем, оставившим заявку и руководством отдела, а в некоторых случаях необходимо выполнить более 10-12 действий по переводу заявки в различные статусы и согласованию каждого нового статуса с руководством и пользователем, что влияет на время реакции на выполнение заявки и скорость выполнения работ по заявке. Также, функциональность каждого решения не является гибкой и не всегда соответствует идеологии обработки заявок в отделе. Таким образом, ИС класса helpdesk от компании Kayako (Kayako Support Suite 3.60.04) имеет перегруженный дополнительными возможностями веб-интерфейс и множество неотключаемых модулей SLA, Teamwork, News и т.д., что не входит в перечень требований и доставляет неудобства в работе. После детального анализа 5 программных продуктов данного класса, с учетом ограниченного бюджета и сложностями при внедрении новой информационной системы класса сервис деск в такой большой компании, было решено доработать функционал существующей ИС HP open view Service Desk. Причиной данному выводу стало большая текучка кадров в отделе горячей лини в связи с огромным количеством рутиной работы по регистрации и обработке заявок. Поэтому было принято решение доработать данную ИС в направлении обработки заявок, приходящих на общий ящик горячей линии support@rosno.ru

1.3.2 Выбор и обоснование стратегии автоматизации задачи

Определим стратегические и функциональные свойства ИС.

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

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

1. Анализ существующих процессов учёта деятельности ИТ отдела компании. Заключается в сборе и анализа следующих показателей: количество не выполненных заявок, количество выполненных заявок в день по инженеру, среднее время выполнения заявки.

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

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

4. формирование Технического задания и графика выполнения работ

Выбор стратегии автоматизации:

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

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

Автоматизация по направлениям подразумевает под собой автоматизацию отдельных направлений деятельности компании. В этом случае компания получает полную автоматизацию работы, например, кадровой службы, производства, бухгалтерии или логистики. Такой подход к автоматизации вполне нормален и в дальнейшем интеграция уже автоматизированных направлений в рамках всего предприятия не будет связана с серьезными препятствиями[15]. Хаотичная, она же кусочная стратегия не подходит так как мы автоматизируем целый отдел, при этом используется несколько составляющих ИС, такие как веб сервер, субд, клиент серверное приложение, нельзя автоматизировать только часть из них, эффекта от этого будет ноль. Полная стратегия автоматизации тоже не подходит в нашем случае, так как мы автоматизируем одно из направлений деятельности холдинга. Стратегия автоматизации по участкам лучше всего подходит в данном дипломном проекте, потому что в нашем случае мы автоматизируем деятельность одного отдела, отдела горячей линии, в смену в нем работает 5 человек, которые на 30 процентов времени заняты телефонными звонками а всё остальное время заняты рутинной работой по регистрации и обработке заявок. Автоматизировав данный процеcс, можно будет сократить численность данного отдела не понижая продуктивность его работы.

1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации комплекса задач

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

· Покупка готовой специализированной ИС;

· Разработка ИС своими силами;

· Разработка ИС сторонней фирмой;

· Покупка системы и её доработка;

Таблица №5. Сравнение способов приобретения ИС

Покупка: Так называемую коробочную версию продукта в дипломном проекте рассматривать не буду, так как там нечего проектировать.

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

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

Покупка + доработка была выбрана исходя и критериев описанных в пункте 1.3.1 т.к. на данный момент используемая ИС HP open view внедрена не самым лучшим образом и основной процесс регистрации и обработки заявок недостаточно автоматизирован. Преимуществом данного решения будет возможность параллельной работы в системе без кардинальных изменений во время доработки, также максимальное количество учтённых пожеланий и строгое соответствие ТЗ при доработке функционала. Данный вариант оптимально подходит также потому, что если что-то пойдет не так, то всегда можно остановится, проанализировать и начать итерацию сначала, вместе с тем, основная система будет продолжать функционировать исправно. Также кроме возможности откатиться и начать сначала, в условиях ограниченности бюджета, данный вариант будет единственным верным решением.

1.4 Обоснование проектных решений

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

Информационное обеспечение (ИО) включает в себя:

· систему классификации и кодирования;

· систему унифицированной документации, используемой в ИО;

· информационную базу.

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

· общегосударственные классификаторы,

· отраслевые (ведомственные) классификаторы, используемые в пределах определенной отрасли (ведомства);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Варианты СУБД систем.

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

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

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

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

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

Написание программы сервиса, обрабатывающего почтовый ящик было решено на языке 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. Характеристики сервера БД.

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

· Два процессора позволяют, при использовании 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. Характеристика конфигурации ПК пользователя.

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

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

Для средств организации ЛВС критерием выбора будет тип кабеля и пропускная способность. На данный момент по анализу сетевого трафика программой 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

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.

2.2.2 Характеристика нормативно-справочной, входной и оперативной информации

В данном дипломном проекте используются только входящие файлы и справочники. Входящим файлом является письмо(заявка) на почтовый ящик горячей линии Росно. Письмо представляет из себя неструктурированны текст с описанием неисправности, отправитель по умолчанию становится заявителем, если данного пользователя нет в системе HP open View Service Desk то он добавляется в справочник пользователей в ручную пользователем горячей линии. Письмо содержит в себе текс, который распознается процедурой классификации инцидентов. Также в теле письма может быть описание для какого сотрудника должно быть реализована заявка, эта информация также определяется алгоритмом классификации инцидентов.

Справочником для работы процесса регистрации заявок безусловно является таблица классификации заявок, она содержит базу знаний, по которой в соответствии с регламентом, назначаются, согласовываются и выполняются заявки в компании ОАО 'РОСНО' .

Справочник «Классификация» состоит из следующих полей:

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

2.Код (ключевое поле, уникально идентифицирующее запись);

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

4. Код группы(идентифицирует группу - департамент ИТ (Сетевики/поддержка пользователей, поддержка ИС, почтовые администраторы,Vip обслуживание));

5. Код специалиста (непосредственный исполнитель, каждый день руководителями присылается отчёт о присутствии, исходя их него назначаются исполнители заявок );

6. Согласование., даннео поле имеет логически тип Истина/ложь;

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

2.2.3 Характеристика результатной информации

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

1. «Отчет по согласованным заявкам»

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

· Дата создания заявки

· Пользователь (заявитель)

· Ответственная группа

· Назначенный на заявку сотрудник

· Статус

· Приложенное исходное письмо (тема и тело письма в оригинале)

2. Отчет ”заявки по местоположению заявителя”:

Содержит таблицу со следующими полями:

· Дата создания заявки

· Даты писем по согласованию

· Пользователь (заявитель)

· Месторасположение(город)

· Адрес (улица, дом, корпус, офис)

· Ответственная группа

· Текущий статус переписки и зарегистрирована ли заявка

· Приложенное окончательное письмо (тема и тело письма в оригинале)

Данного рода отчеты имею в информационных поток предприятия служат скорее для получения статистики нежели для оперативного управления и принятия решений, а Информация в этих журналах является скорее уточняющей, нежели обобщающей. В итогах данной ведомостей за месяц можно понять насколько загружена горячая линия по регистрации заявок в ручную, сколько ошибок при регистрации допускает служба и допускает ли. на рисунке №14 представлена скриншот Журнала Созданных заявок в оду итерацию(без согласования) за 1/3/6 часов».

2.3 Программное обеспечение задачи

2.3.1 Общие положения (дерево функций и сценарий диалога)

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

Рисунок 15 Сценарий Диалога работы программы

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

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

Рисунок № 16 Дерево функций

2.3.2 Характеристика базы данных

Базу данных ИС можно представить в виде следующей ER модели -

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

Таблица «registered_letter» что означает обработанное письмо, имеет следующие поля - таблица 12.

Таблица 12. Таблица «registered_letter»

Таблица «Group», имеет следующие поля - таблица 13.

Таблица 13. Таблица «Group»

Таблица называется «IT_worker» и подразумевает список сотрудников ИТ отдела, имеет следующие поля - таблица 14.

Таблица 14. Таблица «IT_worker»

Таблица «History», имеет следующие поля - таблица 15.

Таблица 15. Таблица «History

Таблица называется 'Klassification' и подразумевает набор ключевых слов и по которым будут назначены исполнители заявки - таблица 16.

Таблица 16. Таблица 'Klassification'

2.3.3 Структурная схема пакета (дерево вызова процедур и программ)

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

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

Таблица 17. Таблица модулей разрабатываемого программного продукта.

2.3.4 Описание программных модулей

Для описание работы программы наиболее понятным будет пояснение основного моlудя программы, процедуры Main. Программный код данной процедуры будет приведен в приложении 1.

2.4 Контрольный пример реализации проекта и его описание

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

Разрабатываемая в данном диплом проекте программа запущена на компьютере где находится ИС “HP OpenView Service Desk” в фоновом режиме (сервис) и с периодичностью в 1 минуту проверяет почту горячей линии на вопрос поступления новых писем. При поступлении нового письма программа выкачивает его по протоколу pop3 и удаляет из почтового ящика, вместе с тем она анализирует от кого пришло письмо, с какой темой и детально прорабатывает тело письма. Вся интерактивность работы с данным сервисом реализована с помощью веб интерфейса с использованием веб сервера Apache.

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

Далее у нас появляется меню авторизации пользователей, согласно определенным ранее ролям прав доступа в пункте 2.1.3. Здесь следует ввести логин и пароль, используемый в системе ИС “HP OpenView Service Desk”.

После входа в систему мы можем просмотреть статус работы нашего сервиса в разделе STATUS и синхронизировать таблицы пользователей с основной таблицей ИС “HP OpenView Service Desk”. После нажатия кнопки Syncronize справочники сотрудников и исполнителей из ИС “HP OpenView Service Desk” автоматически обновят недостающие записи в таблицах - справочниках сервиса, обрабатывающего заявки на почте.

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

После нажатия на кнопку “Create” перед нами откроется форма для выбора типа отчета , следует выбрать один из них и нажать кнопку NEXT для переходя к следующему этапу мастера формирования отчета. Данное окно мастера формирования отчета представлено на рисунке № 24

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

После этого на указанный адрес электронной почты приходит письмо, с прикрепленным отчетом, выбранным ранее, см. рисунок № 26

Рисунок № 26 Письмо с вложенным отчетом.

3. Обоснование экономической эффективности

3.1 Выбор и обоснование методики расчета экономической эффективности

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

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

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

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

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

Основными показателями являются временные и трудовые показатели затрат на осуществление операций в ИС.

Для расчета экономической эффективности необходимо сравнить два типа показателей.

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

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

Для трудовых затрат:

- абсолютное снижение трудовых затрат

Т = Т0 - Т1,

где Т0 - трудовые затраты на обработку информации по базовому варианту;

Т1 - трудовые затраты на обработку информации по предлагаемому варианту;

- коэффициент относительного снижения трудовых затрат

КТ =Т / T0 * 100%,

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

YT = T0 / T1

А так же для стоимостных затрат.

- абсолютное снижение стоимостных затрат

С = С0 - С1,

где С0 - стоимостные затраты на обработку информации по базовому варианту; С1 - стоимостные затраты на обработку информации по предлагаемому варианту.

- коэффициент относительного снижения трудовых затрат

Кс =С / С0 * 100%,

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

YС = С0 / С1

А после чего рассчитать срок окупаемости проекта:

Ток = КП /C

3.2 Расчёт показателей экономической эффективности проекта

На основании представленных в п 3.1 формул можно сделать следующие расчеты.

Таблица 24. Сводная таблица показателей эффективности

Попробуем рассчитать плановый и текущий показатели:

Т0 = 22дня*11мес*((800зявок*3мин)/ 6чел) = 96800

Т1 = 22дня*11мес*((100зявок*3мин)/ 6чел)=12100

Теперь рассчитаем абсолютное снижение затрат:

Т = Т0 - Т1 =96800-12100 = 84700минут

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

УТ =Т0 / T1 =96800/12100 = 8

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

На рисунке 27 представлена диаграмма трудоёмкости обработки одного клиента при базовом варианте обработки («как есть») и при внедряемом («как должно быть») в целом.

Рисунок 27 Общая диаграмма трудоемкости.

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

C0 = 12*6*20000рублей = 1440000 рублей в год

C1 = 12*4*20000рублей = 960000 рублей в год

Теперь рассчитаем абсолютное снижение стоимостных затрат:

С = С0 - С1= 1440000 рублей-960000 рублей = 480000рублей за год

На рисунке 28 представлена общая диаграмма, демонстрирующая общие стоимостные расходы на обработку одного клиента при базовом варианте обработки («как есть») и при внедряемом («как должно быть») в целом.

Рисунок 28 Общая диаграмма стоимостных затрат

Далее рассчитаем общий индекс снижения стоимостных затрат.

YС = С0 / С1 = 1440000/960000 = 1,5

Общие затраты на проект составляют:

Стоимость работы программиста в течении 2х месяцев составляет около 70000 тысяч рублей с учётом отработки 40часов в неделю. Затрат на дополнительное техническое оснащение у нас не предусмотрено. Поэтому Кп = 70000руб.

Ток = КП /C = 70000рублей/480000рублей = 0,15 года

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

Заключение

В проекте рассматриваются все этапы внедрения доработки ИС, от аналитической разработки проекта, до внедрения проекта на предприятии.

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

Проект рассматривает задачи оптимизации информационной инфраструктуры на предприятии.

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

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

В проекте решены задачи автоматизации процесса обработки и согласования заявок и нарядов регистрируемой горячей линией страховой компании “РОСНО”, а именно:

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

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

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

Список литературы

1. Электронная библиотека МФПА Microsoft Solutions Framework Модель процессов MSF вер. 3.1

2. ГОСТ Р 51241-2008 - «Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний», Руководящий документ, 2008г.

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

4. «Методология функционального моделирования IDEF0», Руководящий документ, Госстандарт России.;

5. Вендров А.М. «CASE технологии Современные методы и средства проектирования информационных систем» М.: Финансы и статистика, 1998г. - 176 с.: ил.;

6. Гулиян Г.Б., Нестеров И.А. «Основы организации компьютерных сетей. Часть 1.», Московская финансово-промышленная академия. - М., 2007г. - 169 с. ил.;

7. Крис Дж. Дейт «Введение в системы баз данных» - Киев: Вильямс, 2007г. - 1328 с.: ил.;

8. Микрюков В. Ю. «Информация, информатика, компьютер, информационные системы, сети», Москва: Феникс, 2007г. - 448 с.: ил.;

9. Мишенин А. И. «Теория экономических информационных систем», Москва: Финансы и статистика, 2007г. - 240 с.: ил.;

10. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. «Баз данных», Учебник, Корона - Век, 2010г. - 736 с.: ил.;

11. «Memory Limits for Windows Release»

12. http://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx

13. https://msdb.ru/Downloads/WindowsServer2008/Datasheet_Windows_Server_2008.pdf

14. «Сравнение различных выпусков Windows Server 2003»

15. http://www.microsoft.com/Rus/WindowsServer2003/evaluation/features/compareeditions.mspx

16. http://www.openview.ru/s_desk.htm

17. Лекция: Основные понятия технологии проектирования информационных систем (ИС) http://www.intuit.ru

18. Сайт московского исследовательского института системного проектирования http://miisp.ru/index.php?option=content&task=view&id=491

19. http://www.rodnik.ru/product/server/rab_station/server/ Критерии выбора серверной платформы.

20. http://www.interface.ru/fset.asp?Url=/misc/rcrm1.htm Рынок CRM-систем

21. http://www.erpselection.ru/analitiks/koltunova_demands.shtmlТребования к информационной системе и модели жизненного цикла

22. Лекция: Классификаторы в ИС http://www.intuit.ru

23. ГОСТ 19781-90

24. Липаев В.В. / Процессы и стандарты жизненного цикла сложных программных средств / Москва / СИНТЕГ / 2006

25. Методология и технология ЖЦ http://cmcons.com/articles/obshhie_stati_rup/

23. курс Верификация программного обеспечения информация [+]Авторы: С.В. Синицын, Н.Ю. Налютин http://www.intuit.ru

Приложение 1

Описание фаз Автоматизации по стандарту MSF

Таблица № 11 Ответственность участников в фазе разработки.

Таблица № 12 Ответственность участников в фазе стабилизации.

Таблица № 13. Ответственность участников в фазе разработки.

Приложение 2

Программный код основной процедур main и syntax

#!/usr/bin/env python

import poplib

import email

import string

import time

def main():

try:

while True:

try:

print 'Connecting mail server...'

M = poplib.POP3('mango.rosno.ru')

M.user('HPOPSD_mailer')

M.pass_(' HPOPSD_mailer)

numMessages = len(M.list()[1])

for i in range(numMessages):

print '=' * 40

msg = M.retr(i + 1)

str = string.join(msg[1], 'n')

mail = email.message_from_string(str)

print 'From:', mail['From']

print 'Subject:', mail['Subject']

print 'Date:', mail['Date']

mail_str = ''

if mail.is_multipart():

mail_str = mail.get_payload(0).get_payload()

else:

mail_str = mail.get_payload()

# This string contains message text

procedure л

# Delete message from server

M.dele(i + 1)

M.quit()

print '%d new messages received' % numMessages

time.sleep(10)

except KeyboardInterrupt:

raise

except Exception as e:

print 'Error: %s' % str(e)

time.sleep(1)

except KeyboardInterrupt:

print('Terminating signal received. Shutting down')

if __name__ == '__main__':

main()

from doc.text import DocTextReader doc = DocTextReader('parus.doc') root_entry = doc.root_entry word_document = doc.get_entry_by_name('WordDocument') one_table = root_entry.child.left_sibling.left_sibling fc_clx = self.word_document.get_long(0x01a2) one_table.seek(fc_clx) print one_table.read(1) print one_table.tell() # fc_clx + 1 print doc.read()

import xlrd rb = xlrd.open_workbook('d:/final.xls',formatting_info=True) sheet = rb.sheet_by_index(0) for rownum in range(sheet.nrows): row = sheet.row_values(rownum) for c_el in row: print c_el

# -*- coding: UTF-8 -*-

if __name__ == '__build__':

raise Exception

def canonize(source):

stop_symbols = '.,!?:;-nr()'

stop_words = (u'это', u'как', u'так',

u'и', u'в', u'над',

u'к', u'до', u'не',

u'на', u'но', u'за',

u'то', u'с', u'ли',

u'а', u'во', u'от',

u'со', u'для', u'о',

u'же', u'ну', u'вы',

u'бы', u'что', u'кто',

u'он', u'она')

return ( [x for x in [y.strip(stop_symbols) for y in source.lower().split()] if x and (x not in stop_words)] )

def genshingle(source):

import binascii

shingleLen = 10 #длина шингла

out = []

for i in range(len(source)-(shingleLen-1)):

out.append (binascii.crc32(' '.join( [x for x in source[i:i+shingleLen]] ).encode('utf-8')))

return out

def compaire (source1,source2):

same = 0

for i in range(len(source1)):

if source1[i] in source2:

same = same + 1

return float(same*2)/float(len(source1) + len(source2))*100

class doc extends cfb {

public function parse() {

parent::parse();

$wdStreamID = $this->getStreamIdByName('WordDocument');

if ($wdStreamID === false) { return false; }

$wdStream = $this->getStreamById($wdStreamID);

$bytes = $this->getShort(0x000A, $wdStream);

$fComplex = ($bytes & 0x0004) == 0x0004;

$fWhichTblStm = ($bytes & 0x0200) == 0x020;

$fcClx = $this->getLong(0x01A2, $wdStream);

$lcbClx = $this->getLong(0x01A6, $wdStream);

$ccpText = $this->getLong(0x004C, $wdStream);

$ccpFtn = $this->getLong(0x0050, $wdStream);

$ccpHdd = $this->getLong(0x0054, $wdStream);

$ccpMcr = $this->getLong(0x0058, $wdStream);

$ccpAtn = $this->getLong(0x005C, $wdStream);

$ccpEdn = $this->getLong(0x0060, $wdStream);

$ccpTxbx = $this->getLong(0x0064, $wdStream);

$ccpHdrTxbx = $this->getLong(0x0068, $wdStream);

$lastCP = $ccpFtn + $ccpHdd + $ccpMcr + $ccpAtn + $ccpEdn + $ccpTxbx + $ccpHdrTxbx;

$lastCP += ($lastCP != 0) + $ccpText;

$tStreamID = $this->getStreamIdByName(intval($fWhichTblStm).'Table');

if ($tStreamID === false) { return false; }

$tStream = $this->getStreamById($tStreamID);

$clx = substr($tStream, $fcClx, $lcbClx);

$lcbPieceTable = 0;

$pieceTable = '';

$pieceCount = 0;

$from = 0;

while (($i = strpos($clx, chr(0x02), $from)) !== false) {

$lcbPieceTable = $this->getLong($i + 1, $clx);

$pieceTable = substr($clx, $i + 5);

if (strlen($pieceTable) != $lcbPieceTable) {

$from = $i + 1;

continue;

}

break;

}

$cp = array(); $i = 0;

while (($cp[] = $this->getLong($i, $pieceTable)) != $lastCP)

$i += 4;

$pcd = str_split(substr($pieceTable, $i + 4), 8);

$text = '';

for ($i = 0; $i < count($pcd); $i++) {

$fcValue = $this->getLong(2, $pcd[$i]);

$isANSI = ($fcValue & 0x40000000) == 0x40000000;

$fc = $fcValue & 0x3FFFFFFF;

$lcb = $cp[$i + 1] - $cp[$i];

if (!$isANSI)

$lcb *= 2;

else

$fc /= 2;

$part = substr($wdStream, $fc, $lcb);

if (!$isANSI)

$part = $this->unicode_to_utf8($part);

$text .= $part;

}

return $text;

}

}