90377

Повышение эффективности труда сотрудников службы технической поддержки ООО «Аналитические технологии»

Дипломная

Менеджмент, консалтинг и предпринимательство

Технико-экономическая характеристика предметной области и предприятия Характеристика предприятия Краткая характеристика подразделения или видов его деятельности Экономическая сущность комплекса задач Обоснование необходимости и цели использования вычислительной техники для решения комплекса задач...

Русский

2015-06-04

1.5 MB

0 чел.

PAGE  14

Оглавление

[1] Введение

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

[2.1] 1.1 Технико-экономическая характеристика предметной области и предприятия

[2.1.1] 1.1.1 Характеристика предприятия

[2.1.2] 1.1.2 Краткая характеристика подразделения  или видов его деятельности

[2.2] 1.2. Экономическая сущность комплекса задач

[2.3] 1.3. Обоснование необходимости и цели использования вычислительной техники для решения комплекса задач

[2.4] 1.4 Постановка задачи

[2.4.1] 1.4.1 Цели и назначение автоматизированного варианта решения задачи

[2.4.2] 1.4.2 Общая характеристика организации решения подзадач на ЭВМ

[2.4.3] 1.4.3 Формализация расчётов подзадач

[2.5] 1.5 Анализ существующих разработок для автоматизации комплекса задач

[2.6] 1.6 Обоснование проектных решений

[2.6.1] 1.6.1 Обоснование проектных решений по техническому обеспечению (ТО)

[2.6.2] 1.6.2. Обоснование проектных решений по информационному обеспечению (ИО)

[2.6.3] 1.6.3 Обоснование проектных решений по программному обеспечению (ПО)

[2.6.4] 1.6.4 Обоснование проектных решений по технологическому обеспечению

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

[3.1] 2.1 Информационное обеспечение ИС

[3.1.1] 2.1.1 Информационная модель и ее описание

[3.1.2] 2.1.2 Используемые классификаторы и системы кодирования

[3.1.3] 2.1.3 Характеристика первичных документов с нормативно-справочной и входной оперативной информацией

[3.1.4] 2.1.4 Характеристика базы данных

[3.1.4.1] 2.1.4.1. Характеристика инфологической модели БД

[3.1.4.2] 2.1.4.2. Характеристика даталогической модели БД

[3.1.5] 2.1.5 Характеристика результатной информации

[3.1.5.1] 2.1.5.1 Характеристика таблиц с результатной информацией

[3.1.5.2] 2.1.5.2 Характеристика результатных документов

[3.2] 2.2 Программное обеспечение задачи ИС

[3.2.1] 2.2.1 Общие положения

[3.2.2] 2.2.2 Структурная схема пакета

[3.2.3] 2.2.3 Описание программных модулей

[3.3] 2.3 Технологическое обеспечение ИС

[3.3.1] 2.3.1 Организация технологии сбора, передачи, обработки и выдачи информации

[3.3.2] 2.3.2 Схема технологического процесса сбора, передачи, обработки и выдачи информации

[4]

[5] 3. Обоснование экономической эффективности проекта

[6] Заключение

[7]
Литература


Введение

ООО «Аналитические технологии» – это профессиональный поставщик программных продуктов и решений в области анализа данных. Компания специализируется на разработке систем для глубокого анализа данных, охватывающих вопросы сбора, консолидации, очистки данных, построения моделей и визуализации. Юридический адрес: Россия, 390046, г. Рязань, ул. Введенская 115, оф. 447.

ООО «Аналитические технологии» создано 22 ноября 1995 года в Рязани и первоначально занималась созданием заказного программного обеспечения []. Начиная с 1999 года, компания сконцентрировала все свои ресурсы на разработке программных систем, предназначенных для анализа данных. Было выполнено множество проектов в этой области с российскими и зарубежными компаниями, пока со временем все эти разработки не трансформировались в аналитическую платформу Deductor.

Deductor – флагманский продукт ООО «Аналитические технологии», концентрирующей многолетний опыт компании и вобравший в себя самые удачные архитектурные идеи и современный математический аппарат. Deductor является платформой на базе, которой создаются законченные аналитические решения [, c. 601]. Платформа ориентирована на применение экспертами в различных предметных областях, позволяет обрабатывать любую структурированную табличную информацию. Это доступная по цене и простая в использовании система с прекрасными аналитическими возможностями.

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

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

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

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

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

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

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

Предметом исследования является процесс учета электронных ключей. Объектом исследования является ООО «Аналитические технологии».


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

1.1 Технико-экономическая характеристика предметной области и предприятия

1.1.1 Характеристика предприятия

ООО «Аналитические технологии» – небольшая по численности компания: всего 30 сотрудников. Организационная структура, существующая на данный момент, в общем виде, представлена на рис. 1.

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

В области интеллектуального анализа данных ООО «Аналитические технологии» занимается следующими видами деятельности:

  1.  Разработкой и технической поддержкой аналитической платформы Deductor.
  2.  Консалтингом.
  3.  Обучением.
  4.  Исследованием.
  5.  Маркетингом.

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

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

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

Deductor предоставляет аналитикам инструментальные средства, необходимые для решения самых разнообразных аналитических задач: корпоративная отчетность, прогнозирование, сегментация, поиск закономерностей – эти и другие задачи, где применяются такие методики анализа, как OLAP, Knowledge Discovery in Databases (KDD) и Data Mining. Deductor является платформой для создания систем поддержки принятия решений.

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

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

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

Техническая поддержка – платная услуга для клиентов. Для некоторых компаний поставляются специальные версии аналитической платформы Deductor. В ходе эксплуатации могут возникать различные ошибки при работе программы. В такой ситуации клиенты, пользующиеся указанной услугой, имеют право обратиться за помощью к квалифицированным специалистам ООО «Аналитические технологии». Результат технической поддержки клиентов – это их удовлетворенные потребности в исправлении и доработки функционала аналитической платформы.

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

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

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

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

Для решения широкого спектра задач, связанных с интеллектуальным анализом данных, на конкурентоспособном уровне проводится исследовательская деятельность, заключающаяся как работой с научной литературой, так и проведением собственных экспериментов. Результаты этой деятельность – новые знания в области применения алгоритмов Data Mining для решения экономических и бизнес-задач. Обучением и исследовательской деятельностью главным образом занимается группа «Образование».

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

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

Этой деятельностью главным образом занимается группа «Маркетинг».

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

1.1.2 Краткая характеристика подразделения  или видов его деятельности

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

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

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

Рис.  – Организационная структура групп

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

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

Таблица

Должности сотрудников

Группа

Должности

Разработка

Инженер-программист

Образование

Инженер-программист

Аналитик

Консалтинг

Аналитик

Маркетинг

Маркетолог

Например, сотрудники группы «Маркетинг» могут занимать только должность маркетолога, когда как сотрудники группы «Образование» могут занимать должность как аналитика, так и инженера-программиста.

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

1.2. Экономическая сущность комплекса задач

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

  1.  Номер ключа.
  2.  Название и адрес организации.
  3.  Версия Deductor: Professional или Enterprice x.x.x.
  4.  Дата приобретения.
  5.  Номер лицензионного договора.

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

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

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

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

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

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

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

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

  1.  Номер ключа.
  2.  Тип ключа: сетевой или локальный.
  3.  Версия аналитической платформы Deductor: Professional или Enterprise.
  4.  Количество запусков Deductor.
  5.  Максимальное количество одновременно запущенных Deductor Studio.
  6.  Максимальное количество одновременно запущенных Deductor Viewer.
  7.  Разрешение запуска Deductor Server.
  8.  Количество разных ЭВМ, на которых может быть одновременно запущен Deductor Studio.
  9.  Количество разных ЭВМ, на которых может быть одновременно запущен Deductor Viewer.

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

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

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

Информационная система предназначения для решения следующего ряда задач:

  1.  Ведение учета поступивших и проданных электронных ключей.
  2.  Формирование информационных отчетов для нужд технической поддержки.
  3.  Перепрошивка электронных ключей.
  4.  Накопление информации о лицензионных ключах для последующего анализа средствами аналитической платформы Deductor.

Рассмотрим каждую задачу подробнее.

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

  1.  Обращение на обновление.
  2.  Обращение об обнаружении возможной ошибки.
  3.  Обращение на перепрошивку ключа.
  4.  Обращение за технической информацией по установки или обслуживанию аналитической платформы.

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

Один час работы одного сотрудника приносит компании доход от 160 до 1000 рублей. В среднем в день поступает от 2 до 3 обращений. На сбор необходимой информации для анализа обращения и локализации ошибки уходит от 20 минут до одного часа. Например, клиент может написать, что при редактировании аналитического сценария появилась некоторая ошибка и указать самую позднюю сборку платформы. Однако перед этим он использовал более раннюю версию, что являлось ключевым момент в появлении ошибки. Так как важная информация не была сообщена вовремя, было затрачено много времени на поиск ошибки там, где её нет. С использование системы можно сократить время сбора общей информации о ключах и организации до 5 минут. Решая эту задачу, использование информационной системы в месяц может принести доход от 3200 до 73 300 рублей.

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

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

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

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

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

Осуществляют деятельность фирмы Сотрудники ООО «Аналитические технологии». На выходе находятся выданный электронный ключ и выполненный проект.

Деятельность всей компании можно разложить на следующие составляющие (диаграмма BG-0):

  1.  Заключение договоров.
  2.  Оприходование и выдача лицензионного ключа.
  3.  Разработка, консалтинг и обучение.
  4.  Техническая поддержка клиентов.

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

  1.  Лицензионный договор (полное название: договор на предоставление права пользования программным продуктом).
  2.  Договор на обучение (полное название: договор на оказание информационно-консультационных услуг).
  3.  Договор консалтинга (полное название: договор на оказание информационно-консультационных услуг).
  4.  Договор на годовую техническую поддержку.
  5.  Партнерский договор.

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

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

Таблица

Соответствие заключенного договора и статуса организации

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

Статус организации

Лицензионный договор

Клиент

Договор на обучение

Клиент

Договор консалтинга

Клиент

Договор на годовую техническую поддержку

Клиент

Партнерский договор

Партнер

Электронные ключи, которые поступают в ООО «Аналитические технологии» сперва оприходываются. Затем, в соответствии с лицензионным или партнерским договором, клиенту или партеру выдается лицензионный ключ. Каждый ключ прошивается под определенные версии аналитической платформы Deductor. После прошивки он передается клиенту или партнеру согласно соответствующему договору.

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

Техническая поддержка предоставляется только клиентам заключившим договор о предоставлении этой услуги. Все её этапы осуществляются сотрудниками ООО «Аналитические технологии».

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

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

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

Все рабочие места сотрудников ООО «Аналитические технологии» обеспечены вычислительной техникой. Внедрение клиент-серверной информационной системы будет обладать рядом преимуществ.

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

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

Цель использования – это практическая реализация возможностей внедряемой информационной системы.

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

1.4.1 Цели и назначение автоматизированного варианта решения задачи

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

Назначение информационной системы.

  1.  Ведение учета прихода, выдачи, прошивки, комплектации электронных ключей.

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

  1.  Ведение учета имеющихся электронный ключей у клиентов и партнеров.

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

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

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

  1.  Создание печатных отчетов и экспорт данных в Excel-файл.

К разрабатываемой системе предъявляются следующие требования:

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

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

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

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

Задачами автоматизации для достижения поставленной цели являются:

  1.  Ведение учета поступивших и проданных электронных ключей.
  2.  Предоставление отчета о наличии у клиентов договоров о технической поддержке с указанием сроков представления соответствующей услуги.
  3.  Предоставление отчета о прошивках электронного ключа.
  4.  Предоставление отчета об используемых клиентом версиях.
  5.  Генерация хэш-кода для прошивки ключа с добавлением соответствующих данных в базу данных информационной системы.

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

  1.  Проектирование базы данных для клиент-серверной информационной системы.
  2.  Создание хранимых процедур и триггеров для работы с базой данных.
  3.  Проектирование клиентской части:
    1.  Написание классов, отвечающих за обращения к базе данных.
    2.  Написание классов, сохраняющих настройки пользователей ИС.
    3.  Написание классов, отвечающих за создание отчетов ИС.
    4.  Написание классов, осуществляющих генерацию хэш-кода для прошивки электронного ключа.
    5.  Проектирование визуальной части приложения.
  4.  Написание документации к информационной системе.
  5.  Тестирование и доработка информационной системы.
  6.  Ввод информационной системы эксплуатацию:
    1.  Перенос базы данных на сервер.
    2.  Заполнение базы имеющимися данными.
    3.  Установка клиентского приложения на рабочие места.
    4.  Краткий инструктаж сотрудников по работе в информационной системе.

1.4.2 Общая характеристика организации решения подзадач на ЭВМ

Информационная система имеет клиент-серверную архитектуру.

Серверная часть будет представлять собой базу данных под управлением СУБД Microsoft SQL Server.

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

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

  •  Счет прихода электронных ключей.
  •  Договоры на предоставление права пользования программным обеспечением.
  •  Договоры на оказание технической поддержки.
  •  Партнерские договоры.
  •  Ответы технической поддержки клиентам.

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

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

Режим работы информационный системы – диалоговый.

1.4.3 Формализация расчётов подзадач

Каждая i-ая прошивка j-ого электронного ключа должна удовлетворять следующему условию:

,

где Pi – множество приложений i-ой прошивки, kp – количество приложений p, lj - максимальное количество лицензий, которое поддерживает ключ.

Расчет общего количества сетевых лицензий j-ой прошивки:

,

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

Расчет даты окончания действия i-ого договора технической поддержки происходит по следующей формуле:

[дата окончания]i = [дата заключения]i + [срок предоставления]i.

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

Расчет значения маски ключа keymask для генерации хэш-кода прошивки.

,

где P – множество номеров программ, используемых в прошивке.

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

Решение «1С:ITIL Управление информационными технологиями предприятия СТАНДАРТ» — это система для службы Service Desk (службы технической поддержки), простая в настройке и использовании. Она предназначена для ИТ-подразделений организаций и сервисных компаний.

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

Основные функциональные возможности:

  •  Управление службой поддержки:
    •  Регистрация обращения пользователя. Специалисты службы «Service Desk» регистрируют запросы, приходящие от пользователей, разрешают максимально возможное число инцидентов на первой линии поддержки, назначают исполнителей на инцидент в случае невозможности решить его на этом этапе.
    •  Настройка бизнес-процесса обработки обращения пользователя. Маршрут задачи описывает бизнес-процесс, который выполняется сотрудниками службы «Service Desk» в процессе работы над обращением пользователя.
    •  Учет трудозатрат исполнителей на обработку обращения. Исполнитель в процессе работы над задачей, поставленной пользователем, указывает в списке затраченное на ее выполнение время.
    •  Уведомления пользователя. Пользователь может получать уведомления об изменениях, внесенных в задачу другими участниками.
    •  Удобный список заявок. В системе есть настроенные списки задач. Кроме возможности быстрого отбора каждый из них имеет гибкий фильтр, который позволяет отфильтровать список задач по различным критериям, вывести поля задачи в списке.
    •  База знаний. Встроенная база знаний позволяет накапливать информацию об инцидентах и увеличивать количество инцидентов, разрешенных на первой линии «Service Desk».
    •  Дополнительные свойства обращения пользователя. Сотруднику службы «Service Desk» может потребоваться реквизит обращения, который не предусмотрен системой. В этом случае он может создать собственные свойства.
  •  Управление уровнем сервиса:
    •  Сервисы. ИТ-подразделение или организация оказывает услуги клиенту. Услуги объединены в удобном виде в каталоге сервисов.
    •  Соглашение об уровне оказания сервиса. Между поставщиком ИТ-сервиса и клиентом может быть заключено соглашение, определяющее ключевые задачи предоставления сервиса и обязанности сторон.
    •  Отчеты. Контроль исполнения обязательств, зафиксированных в соглашении об уровне сервиса.
  •  Управление активами:
    •  Классификатор моделей активов. Администратор может создавать модели активов с произвольным набором атрибутов и использовать эти модели при построении каталога активов. Активы включают в себя все, что задействовано в предоставлении сервисов.
    •  Количественный учет в разрезе рабочих мест, материально ответственных лиц и организаций. Активы закреплены за определенным рабочим местом и материально ответственным лицом.
    •  Суммовой учет активов в разрезе статей затрат, анализ совокупной стоимости владения активами. Учитывается стоимость активов, их обслуживания. Стоимость относится на определенную статью затрат с возможностью последующей оценки.
    •  Поштучный учет активов в разрезе серийных номеров. Каждый актив имеет уникальный серийный номер.
    •  Учет ремонтов и обслуживания. В процессе эксплуатации активы изнашиваются и требуют ремонта и обслуживания. Существуют параметры выработки актива, они определяют необходимость обслуживания.
    •  Дополнительные свойства моделей актива и рабочих мест. Пользователь может самостоятельно создать нужные ему свойства актива, модели актива или рабочего места и указать их значения.

Несмотря на наличие широких функциональных возможностей, решение «1С:ITIL Управление информационными технологиями предприятия СТАНДАРТ» имеет ряд недостатков:

  1.  Это решение платное. Одно рабочее место стоит 9 600 рублей. Для нужд технической поддержки ООО «Аналитические технологии» необходимо не менее 10 рабочих мест. Следовательно затраты на закупку решения составят 96 000 рублей.
  2.  Осуществление прошивки ключей средствами рассматриваемого решения не предусмотрено, а доработка в конфигураторе «1С: Предприятия» невозможно из-за несовместимости необходимых библиотек.

Информационная система IPI.MANAGER (ООО ««АйПиАй Тех») предлагает свое решение для службы технической поддержки. Однако данный программный продукт не может решить задачи перепрошивок ключей и их учета.

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

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

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

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

Серверное ТО.

Техническое обеспечение сервера должно позволять бесперебойно функционировать базе данных, разработанной в СУБД MS SQL Server 2005. Минимальные требования приведены в таблице 3 [].

Таблица

Минимальные требования к серверному ТО

ТО

Параметры

Процессор

Тактовая частота не менее 500 МГц (рекомендуется 1 ГГц и более)

Оперативная память

512 МБ (рекомендуется 1 ГБ и более)

Жесткий диск

Не менее 1 ГБ свободного места

Дисплей

Монитор VGA или большего разрешения

Клавиатура

1 шт

Мышь

1 шт

Требования к техническому обеспечению клиентской машины приведены в таблице 4.

Таблица

Минимальные требования к техническому обеспечению клиентской ЭВМ

ТО

Параметры

Процессор

Тактовая частота не менее 500 МГц (рекомендуется 1 ГГц и более)

Оперативная память

512 МБ и более

Жесткий диск

50 МБ свободного места

Дисплей

Монитор VGA или большего разрешения

Клавиатура

1 шт

Мышь

1 шт

Серверная и клиентские ЭВМ должны находится в одной вычислительной сети, с пропускной способностью канала не менее 3Мб/с. Для печати отчетов необходим хотя бы один принтер.

В компании в наличии имеется 40 ЭВМ, из них 3 компьютера являются серверами. Все машины объединены в единую внутреннюю локальную сеть, подключенную к глобальной сети Интернет.

Типичные основные характеристики ЭВМ компании представлены в таблице 5.

Таблица

Типичные основные характеристики ЭВМ

ТО

Параметры

Процессор, тактовая частота

3.00ГГц

ОЗУ, объем

2 ГБ

Жесткий диск, объем

500 ГБ

Дисплей

19"; 1280x1024 пикс

Клавиатура

1шт

Мышь

1шт

Все компьютеры сотрудников оснащены LCD-монитором, клавиатурой, мышью. У компании в наличие имеется 3 веб-камеры, 15 наушников с микрофонами, 2 микрофона, 2 принтера.

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

1.6.2. Обоснование проектных решений по информационному обеспечению (ИО)

Информационное обеспечение ИС можно определить как совокупность единой системы классификации, унифицированной системы документации и информационной базы [, c. 105].

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

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

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

Рассмотрим внемашинное ИО.

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

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

Электронный ключ может быть локальным, либо сетевым.

Пользователи подразделяются на физические и юридические лица.

Рассмотрим входные документы.

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

  1.  Номер счета (положительное число).
    1.  Дата выставления счета.
      1.  Перечень приобретенных ключей и их стоимость.
      2.  Информация о поставщике: название, юридический и физический адреса, контактный телефон и прочее.

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

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

  1.  Договор на предоставления права пользования программным продуктом.
  2.  Расписка о получении электронного ключа.
  3.  Партнерский договор.

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

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

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

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

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

Результирующую информацию (различные отчеты для нужд технической поддержки) можно отдельно сохранить в файле формата «.xls».

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

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

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

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

На рабочих компьютерах сотрудников ООО «Аналитические технологии» установлена операционная система Windows XP, на двух серверах Ubuntu, на одном – Windows Server 2003.

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

  •  Borland Delphi 5;
  •  Microsoft Visual Studio 2005;
  •  Microsoft SQL Server 2005;
  •  Oracle;
  •  Microsoft Office 2003;
  •  Firebird.

Для обеспечения хранения документов и контроля их изменений и версий используется Borland StarTeam. В некоторых консалтинговых проектах используются такие программные продукты, как BP-Win и ER-Win.

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

Для обучения по договорам предоставления информационно-консультационных услуг имеется система дистанционного обучения Competentum. ООО «Аналитические технологии» в сети Интернет имеет свой сайт, расположенных по адресу http://www.basegroup.ru/.

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

Чтобы минимизировать затраты на создание информационной системы выгодно использовать имеющееся ПО.

Так как большинство сотрудников работает на ЭВМ с операционной системой Windows XP, то информационная система должна работать именно под управлением этой ОС.

В качестве СУБД оптимальным решением является Microsoft SQL Server 2005. Она позволяет реализовывать клиент-серверные приложения и уже есть в наличии в ООО «Аналитические технологии». Перечислим достоинства этой СУБД, которые необходимы для реализации информационной системы:

  •  Встроена поддержка .NET Framework.
  •  Поддержка язык Transact-SQL.
  •  Возможность ведения различных пользователей и групп пользователей.
  •  Возможность разграничения прав доступа.
  •  Удобные средства проектирования.
  •  Поддержка клиент-серверных баз данных.

Для разработки клиентской части платформа Microsoft Visual Studio 2005, которая имеется в ООО «Аналитические технологии». Перечислим основные достоинства:

  •  Наличие интеграции с Microsoft SQL Server 2005.
    •  Наличие встроенного мощного языка C#.
    •  Удобные средства проектирования Windows-приложений.

Имеющиеся в наличии библиотеки, необходимые для прошивки ключа совместимы с языков C#. Поскольку указанные лицензии на указанные программные продукты имеются в наличии в ООО «Аналитические технологии», данный выбор позволит сократить затраты на реализацию информационной системы.

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

Рассмотрим различные варианты приобретения информационной системы.

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

Покупка такого решения, как «1С:ITIL Управление информационными технологиями предприятия СТАНДАРТ», может обойтись в 96 000 рублей. Однако его необходимо доработать и адаптировать под нужды ООО «Аналитические технологии». Если следовать этого варианту, то далее должны быть проделаны следующие шаги:

  1.  Изучение решения для его доработки. На первом этапе надо ознакомится с кодом и идеями, положенными в основу решения. Это может занять от недели до месяца.
  2.  Дообработка решения. Правка справочников, отчет и прочих объектов конфигурации для адаптации решения. На этот этап необходимо затратить от трех до четырех недель.
  3.  Написание отдельного приложения, которое бы прошивало ключи и добавляло в базу данных необходимую информацию (одна неделя).
  4.  Тестирование и исправление замеченных недостатков (одна неделя).
  5.  Введение в эксплуатацию.

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

Рассмотрим вариант собственной разработки.

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

  •  Microsoft Visual Studio 2005;
  •  Microsoft SQL Server 2005.

Помимо этого имеются совместимые с языком C#.Net библиотеки для прошивки электронных ключей.

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

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

В сравнении с покупкой и доработкой существующего решения, в данном случае как минимум экономится 96 000 рублей.

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

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

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

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


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

2.1 Информационное обеспечение ИС

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

Как показывает современная практика, реинжиниринг бизнес-процессов является одним из «традиционных» подходов для решения проблемы повышения экономической эффективности предприятия [, c 221].

Диаграмма бизнес-процессов «Как должно быть» приведена в приложении 2. Опишем выбранную стратегию автоматизации комплекса задач и обоснуем осуществленный выбор.

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

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

Процесс «Рассмотрение обращения» претерпевает также изменения. Если, согласно диаграмме «Как есть», он состоял из трех этапов:

  1.  Анализ типа обращения.
  2.  Уточнение используемой версии.
  3.  Уточнение информации о ранее использовавшихся версиях,

то теперь он состоит всего из двух:

  1.  Анализ обращения.
  2.  Получение и анализ отчетов о версиях и перепрошивках.

Такой реинжиниринг процесса значительно сокращает время рассмотрения обращения и выделения из него ценной информации об ошибке. Это единственный процесс, который претерпевает столь радикальное изменение. Согласно литературному источнику [, с. 201], такому кардинальному реинжинирингу должно подвергаться не более 20% всех процессов. В данном случае указанное значение не превышено.

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

Бизнес-процесс «Заключение договоров» подвергается улучшению. Добавляется новый этап – «Получение отчетов о лицензионных ключах». Эти отчеты могут быть использованы маркетологами как входную информацию для заключения договоров. В частности отчет может помочь подобрать оптимальную комплектацию аналитической платформы Deductor. В результате клиента можно будет вывести на более «дорогой» договор, что несомненно принесет больший доход компании.

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

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

Таблица

Описание классификаторов

Наименование кодируемого множества объектов

Значность кода

Система кодирования

Система классификации

Вид классификатора

Номер счета

4

Порядковая

Отсутствует

Системный

Серийный номер ключа

5

Порядковая

Отсутствует

Локальный

Номер договора о годовой технической поддержке

4

Порядковая

Отсутствует

Локальный

Заводской идентификатор ключа

15

Комбинированная

Отсутствует

Системный

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

Серийный номер ключа – это порядковый пятизначный код присваиваемый внутри ООО «Аналитические технологии».

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

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

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

Макет входного документа «Счет» представлен в приложении 8.В нем содержится следующая информация:

  •  Номер счета.
  •  Дата выставления счета.
  •  Название поставщика.
  •  Перечень покупаемых ключей.
  •  Цена ключей.
  •  Общая стоимость.

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

  •  Дата подписания договора.
  •  Наименование клиента.
  •  Срок действия договора.
  •  Условия предоставления услуг технической поддержки.

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

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

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

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

Макеты экранных форм приведены в приложении 12.

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

2.1.4.1. Характеристика инфологической модели БД

Диаграмма ER-модели данных в нотации IDEF1X представлена в приложении 3.

Большинство сущностей связаны связью один ко многим (или к 0). Это означает, что необязательно каждая запись из главной таблицы будет ссылаться на дочернюю [, c. 170]. Это обусловлено жизненными причинами. Когда электронный ключ только поступил, он ещё не имеет ни прошивки и, тем более, не включен не в одну лицензию.

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

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

Так как электронный ключ может только один раз быть поставлен, соответственно приход его осуществляется только один раз. Поэтому тип связи между сущностями «Электронный ключ» и «приход ключа» – «один-к-одному».

Счет прихода должен содержать не менее одного электронного ключа (счет с нулевым количеством ключа бессмыслен). Этот факт обуславливает связь «один-ко-многим-или-одному».

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

Пользователем может быть или юридическое, или физическое лицо. Поэтому связи между сущностями «Пользователь» - «Юридическое лицо» - «один-к-одному-или-к-нулю», «Пользователь» - «Физическое лицо» - «один-к-одному-или-к-нулю».

2.1.4.2. Характеристика даталогической модели БД

На основе ER-модели построим даталогическую модель (таблица 7).

Таблица

Даталогическая модель

Сущность

Идентификатор таблицы

Атрибут

Идентификатор поля

Тип поля

1

2

3

4

5

Электронный ключ

keys

Идентификатор

key_id

int

Заводской идентификатор

factory_key_id

nchar(15)

Идентификатор модели (FK)

key_model_id

smallint

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

int

Пользователь

users

Идентификатор пользователя

user_id

int

Идентификатор статуса (FK)

status_id

tinyint

Является юрид. лицом

is_artificial_person

bit

FTP-логин

ftp_login

varchar(20)

FTP-пароль

ftp_password

varchar(10)

Контактная информация

contact_inf

text

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

int

Юридическое лицо

artificial_person

Идентификатор пользователя (FK)

user_id

int

Наименование организации

name

varchar(100)

Таблица 7 (продолжение)

1

2

3

4

5

Физическое лицо

natural_person

Идентификатор пользователя (FK)

user_id

Int

Фамилия

second_name

varchar(50)

Имя

first_name

varchar(25)

Отчество

middle_name

varchar(25)

Паспортные данные

passport

text

Статус

status

Идентификатор статуса

status_id

Int

Наименование

status_name

varchar(20)

Для физических лиц

is_for_natural_person

Bit

Для юридических лиц

is_for_artificial_person

bit

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

Int

Стандартный комплект

standard_kit

Идентификатор комплекта

kit_id

smallint

Наименование

kit_name

varchar(50)

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

smallint


Таблица 7 (продолжение)

1

2

3

4

5

Приложение

application

Идентификатор приложения

application_id

tinyint

Наименование приложения

application_name

varchar(50)

Актуальность

is_actual

bit

Порядковый номер

application_number

tinyint

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

tinyint

Счет для прихода

bill

Идентификатор счета

bill_id

int

Номер счета (AK)

bill_number

int

Дата предоставления (AK)

bill_date

date

Идентификатор пользователя (FK)

user_id

int

Запись помечена на удаление

is_deleted

bit

Запись была обновлена (AK)

is_updated

int

Приход ключа

key_receipt

Идентификатор прихода

key_receipt_id

int

Заводской идентификатор (AK, FK)

factory_key_id

nchar(15)

Идентификатор счета (FK)

bill_id

int

Запись помечена на удаление

is_deleted

bit

Запись была обновлена (AK)

is_updated

int

Таблица 7 (продолжение)

1

2

3

4

5

Модель ключа

key_model

Идентификатор модели

model_id

smallint

Название ключа

model_name

varchar(50)

Идентификатор типа ключа (FK)

key_type_id

tinyint

Максимальное количество сетевых лицензий

max_net_count

tinyint

Актуальность

is_actual

bit

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

smallint

key_type

Идентификатор типа ключа

key_type_id

tinyint

Наименование

key_type_name

varchar(25)

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

tinyint


Таблица 7 (продолжение)

1

2

3

4

5

Договор о технической поддержке

support_contract

Идентификатор договора ТП

support_contract_id

int

Номер договора ТП (AK)

support_contract_number

int

Дата заключения (AK)

support_contract_date

date

Срок предоставления, мес

support_contract_period

tinyint

Пользователь (FK)

user_id

int

Запись помечена на удаление

is_deleted

bit

Запись была обновлена (AK)

is_updated

int

Версия приложения

build

Идентификатор версии

build_id

smallint

Сборка

build_name

varchar(7)

Дата сборки

build_date

date

Идентификатор приложения (FK)

application_id

tinyint

Комментарий

build_text

text

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

smallint


Таблица 7 (продолжение)

1

2

3

4

5

Использование версий

build_using

Идентификатор

build_using_id

int

Идентификатор версии (AK FK)

build_id

smallint

Идентификатор пользователя (AK FK)

user_id

int

Дата получения

build_using_date

date

Запись помечена на удаление

is_deleted

bit

Запись была обновлена (AK)

is_updated

int

Прошивка

firmware_download

Идентификатор прошивки

firmware_download_id

int

Дата прошивки (AK)

fd_date

date

Заводской идентификатор (AK, FK)

factory_key_id

nchar(15)

Номер программы

prog_number

word

Счетчик GP

counter_gp

word

Маска ключа

key_mask

binary

Серийный номер

serial_number

word

Запись помечена на удаление

is_deleted

bit

Запись была обновлена (AK)

is_updated

int


Таблица 7 (продолжение)

1

2

3

4

5

Приложения прошивки

fd_application

Идентификатор

fd_application_id

int

Идентификатор прошивки (AK, FK)

firmware_download_id

int

Идентификатор приложения (AK, FK)

application_id

tinyint

Наличие локальной лицензии

is_local

bit

Количество сетевых лицензий

net_count

tinyint

Запись помечена на удаление

is_deleted

bit

Запись была обновлена (AK)

is_updated

int

Состав комплекта

composition_of_kit

Идентификатор

composition_od_kit_id

smallint

Идентификатор приложения (AK FK)

application_id

tinyint

Идентификатор комплекта (AK FK)

kit_id

smallint

Описание

description

text

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

smallint


Таблица 7 (окончание)

1

2

3

4

5

Лицензия

licence

Идентификатор

licence_id

int

Идентификатор пользователя (AK FK)

user_id

int

Заводской идентификатор (AK FK)

factory_key_id

nchar(15)

Дата выдачи

licence_date

date

Запись помечена на удаление

is_deleted

bit

Запись была обновлена

is_updated

int

Для всех сущностей, имеющих составные ключи, в соответствующих таблицах создано поле «Идентификатор», при этом были указаны все возможные альтернативные ключи (AK). Это было сделано с целью минимизации объема базы данных. Первичные ключи таблиц выделены жирным шрифтом. Внешние ключи имеют метку «FK».

Для сущности «Пользователь» атрибут «тип» был заменен на «Является юрид. лицом» логического типа. Если значение равно «истина», то пользователь – юридическое лицо, иначе – физическое лицо. Атрибут логического типа будет занимать гораздо меньше памяти ЭВМ, чем хранение строкового. При этом вероятность появления нового типа пользователя крайне мала.

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

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

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

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

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

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

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

Таблица

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

Представление (Справочник или журнал)

Псевдоним поля

Имя поля

Таблица

Юридические лица (справочник «Пользователи»)

ID

user_id

artificial_person

Наименование

name

artificial_person

Статус

status_name

status

Поставщик

is_supplier

artificial_person

Логин FTP

ftp_login

users

Пароль FTP

ftp_password

users

Контактная информация

contact_inf

users

Таблица 8 (окончание)

Представление (Справочник или журнал)

Псевдоним поля

Имя поля

Таблица

Счета (Журнал)

ID

bill_id

bill

Номер

bill_number

bill

Дата

bill_date

bill

Поставщик

name

artificial_person

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

2.1.5.2 Характеристика результатных документов

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

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

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

  •  Серийный номер ключа.
  •  Название организации-владельца ключа.
  •  Контактная информации организации-владельца ключа (e-mail, телефон, адрес).
  •  Дата выта выдачи.
  •  Номер лицензионного договора.

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

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

  •  Номер ключа.
  •  Дата прошивки.
  •  Договор-основание (обычно лицензионный договор).
  •  Комплектация ключа согласно прошивки.
  •  Версия аналитической платформы.

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

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

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

  •  Номер лицензионного ключа.
  •  Дата обновления версии.
  •  Версия.

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

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

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

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

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

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

Макеты отчетов приведены в приложении 11.

2.2 Программное обеспечение задачи ИС

2.2.1 Общие положения

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

«Главное меню» предоставляет доступ к семи основным пунктам меню:

  •  Файл.
    •  Справочники.
    •  Документы.
    •  Журналы.
    •  Отчеты.
    •  Сервис.
    •  Справка.

До входа в информационную систему доступны только пункты главного меню «Файл» и «Справка».

Меню «Файл» раскрывает следующие пункты подменю:

  •  Настройки подключения.
    •  Войти/Сменить пользователя.
      •  Выход.

Пункт «Настройки подключение» вызывает диалоговое окно настройки пути к информационной базе (указание адреса сервера и имени базы данных).

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

Пункт «Выход» закрывает клиентского приложение.

Меню «Справочники» раскрывает следующие пункты подменю:

  •  Электронные ключи.
    •  Модели ключей.
      •  Приложения.
      •  Комплекты.
      •  Пользователи.
      •  Сборки.
      •  Статусы.

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

Пункт «Документы» раскрывает следующие пункты подменю:

  •  Договора ТП.
    •  Счета.

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

Пункт «Журналы» раскрывает следующие пункты подменю:

  •  Прошивки.
    •  Обновления.
      •  Приход ключей.

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

Пункт «Отчеты» раскрывает следующие пункты подменю:

  •  Отчет об обновлениях.
    •  Отчет о наличии ключей.
      •  Отчет о наличии действующих договоров ТП.
      •  Отчет о прошивках.

Пункты этого подменю обеспечивают доступ к диалоговым экранным формам настройки параметров отчетов.

Пункт «Сервис» раскрывает следующие пункты подменю:

  •  Прошить ключ.
    •  Выполнить сценарий Deductor.

Пункт «Справка» раскрывает следующие пункты подменю:

  •  Помощь.
    •  О программе.

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

2.2.2 Структурная схема пакета

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

  1.  Модули подключения к базе данных.
    1.  Модули экранных форм.
    2.  Модули добавления, редактирования и удаления записей.
    3.  Модули транзакций.
    4.  Модули генерации отчетов.

Схема взаимодействия модулей в общем виде (в качестве направленного графа) представлена на рисунке 3.

Рис.  – Схема взаимодействия модулей

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

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

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

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

Диаграмма классов, сгенерированная средствами Microsoft Visual Studio 2005 представлена в приложении 9.

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

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

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

Большая часть транзакций реализованная программно [, c. 119]. Типичная транзакция редактирования записи состоит из следующих элементов:

  1.  Считывание записи.
  2.  Вывод её в специальной экранной форме.
  3.  При событии DialogResult.OK выполнение одной или нескольких хранимых процедур редактирования записей.
  4.  При отсутствии ошибок фиксация транзакции, иначе откат всех изменений.

DialogResult.OK – событие возникающее, когда пользователь заканчивает работу с диалоговым окном для сохранения внесенных им изменений (например, нажатием на кнопку «OK»).

Уровень изоляции транзакций – сериализуемый (Serializable). Это означает, что когда одна транзакция уже считала запись и с ней работает, другая транзакция не может считывать и изменять эти данные [, c. 1122]. При этом решаются следующие проблемы:

  1.  «Грязное» чтение (dirty reads) [, c. 1117]. Такая ситуация возникает , когда один пользователь уже начал транзакцию, изменяющую данных, другой пользователь получает частично измененные данные, не являющиеся корректными.
  2.  Неповторяемое чтение (non-repeatable reads) [, c. 1119]. Такая ситуация возникает, когда один пользователь начинает транзакцию, изменяющую данные, а в это время другой пользователь начинает и завершает другую. Теперь первый пользователь получает другой набор данных во время выполнения других шагов транзакции.
  3.  Чтение фантом (phantom reads) или чтение призрачных строк [, c. 1120]. Данная ситуация возникает, когда один пользователь начинает транзакцию, выбирающую данные из некоторой таблицы. В это же время второй пользователь начинает и заканчивает транзакцию, изменяющую набор данных в таблице (например, были удалены или изменены некоторые записи). При этом у первого пользователя остаются «фантомные» строки, которых теперь нет (или которые были изменены).

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

Рассмотри блок-схемы основных процедур информационной системы. Рассмотрим блок схему процедуры входа пользователя в информационную систему (рис. 4). Обратим внимание, что рассматриваемая процедура проверят, были ли ранее сохранены логин и пароль. Они записаны в бинарном файле в зашифрованном виде. После расшифровки логин и пароль выводятся на форму (вместо пароля выводятся символы «звёздочка»). Пользователь в этой форме может ввести другие идентификационные данные и по окончанию ввода нажать кнопку «OK» (или клавишу «Enter»). Если пользователь решил сохранить логин и пароль, то они шифруются симметричным алгоритмом Rijndael с 16-байтовым ключом []. Для этого используются стандартная библиотека System.Security.Cryptography платформы Framework.Net [, c. 716]. Учет пользователей ведется стандартными средствами Microsoft SQL Server 2005 [, с. 144].

Рис.  – Блок-схема процедуры входа пользователя в ИС

Блок-схема процедуры добавления новой записи (на примере справочника «Модели ключей») представлена на рисунке 4.

Рис.  – Блок-схема добавления записи в справочник «Модели ключа»

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

2.3 Технологическое обеспечение ИС

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

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

  •  счет на покупку ключей (приложение 8);
  •  договор на предоставление права пользования программным продуктом (приложение 6);
  •  договор технической поддержки;
  •  расписка о получении ключа (приложение 7);
  •  партнерский договор.

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

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

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

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

Партнерский договор заключается компаниями-партнерами ООО «Аналитические технологии». В качестве входной информации для ИС используется наименование организации-партнера, перечень передаваемых ключей, список и количество предоставляемых программ.

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

2.3.2 Схема технологического процесса сбора, передачи, обработки и выдачи информации

Схема технологического процесса сбора, передачи, обработки и выдачи информации для наиболее типичных операций выполнена согласно требованиям ГОСТ 19.701-90 [] приведена в приложении 5.

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

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


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

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

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

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

  1.  Получение задания на разработку.
  2.  Подбор и изучение литературы.
  3.  Исследование бизнес-процессов и построение моделей “Как есть” и “Как должно быть”.
  4.  Разработка инфологической модели данных.
  5.  Разработка таблиц баз данных.
  6.  Создание диаграммы базы данных.
  7.  Создание необходимых представлений.
  8.  Разработка хранимых процедур.
  9.  Разработка пользовательского интерфейса.
  10.  Разработка системы авторизации пользователей.
  11.  Разработка алгоритмов программы.
  12.  Отладка программы на ЭВМ.
  13.  Оформление пояснительной записки.
  14.  Создание презентации.
  15.  Cоздание демонстрационной версии программы.

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

T1 = 3 чел. · дн.; U1 = 2 чел.

T2 = 3 чел. · дн.; U2 = 1чел.

T3 = 8 чел. · дн.; U3 = 1 чел.

T4 = 1 чел. · дн.; U4 = 1 чел.

T5 = 2 чел. · дн.; U5 = 1 чел.

T6 = 1 чел. · дн.; U6 = 1 чел.

T7 = 3 чел. · дн.; U7 = 1 чел.

T8 = 7 чел. · дн.; U7 = 1 чел.

T9 = 5 чел. · дн.; U8 = 1 чел.

T10 = 1 чел. · дн.; U9 = 1 чел.

T11 = 8 чел. · дн.; U5 = 1 чел.

T12 = 15 чел. · дн.; U6 = 1 чел.

T13 = 21 чел. · дн.; U7 = 1 чел.

T14 = 3 чел. · дн.; U8 = 1 чел.

T15 = 2 чел. · дн.; U9 = 1 чел.

Продолжительность каждой работы ti определяется по формуле:

Тогда общая продолжительность работ T составит:

 дня.

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

Таблица

Трудоемкости работ

№ этапа

Вид работ

Длительность,

дни

Исполнитель

1

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

1,25

1,75

Руководитель проекта, Дипломник

2

Подбор и изучение литературы

3

Дипломник

3

Исследование бизнес-процессов и построение моделей “Как есть” и “Как должно быть”

8

Дипломник

4

Разработка инфологической модели данных

1

Дипломник

5

Разработка таблиц баз данных

2

Дипломник

6

Создание диаграммы базы данных

1

Дипломник

7

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

3

Дипломник

8

Разработка хранимых процедур

7

Дипломник

9

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

5

Дипломник

10

Разработка системы авторизации пользователей

1

Дипломник

11

Разработка алгоритмов программы

8

Дипломник

12

Отладка программы на ЭВМ

15

Дипломник

13

Оформление пояснительной записки

21

Дипломник

14

Создание презентации

3

Дипломник

15

Создание демонстрационной версии программы

2

Дипломник

Рисунок  – Диаграмма Ганта выполнения работ

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

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

Материальные затраты формируются исходя из цен их приобретения.

При разработке данного проекта к этой статье относят материалы, используемые при проектировании. Перечень материалов, цена, стоимость без учета НДС приведены в таблице 10. Общие материальные затраты составятЗм = = 683,25 руб.

Таблица  

Материальные затраты

Наименование материала

Количество, шт.

Цена за единицу руб.

Сумма с НДС, руб.

Цена без НДС, руб.

СD-диск

2

10

20

16,95

Бумага

1

120

130

101,70

Ручка

1

50

50

39

Переплет

2

80

160

135,6

Черный картридж для принтера

1

500

500

390

ИТОГО:

683,25руб.

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

Эта статья складывается из затрат на заработную плату исполнителей (руководитель работы и дипломник). Руководитель и дипломник работают по шестидневной рабочей неделе, их оклады составляют: дипломник (стипендия в месяц) – 4600 руб., руководитель работы (рукодство дипломным проектиро-ванием – 10 часов) – 1000 руб. Таким образом, дневная заработная плата дипломника составляет 176,92 руб., руководителя работы – 800,00 руб. Тогда общие затраты на заработную плату составят:

Данные по заработной плате приведены в таблице 11.

Таблица

Данные по заработной плате

№ этапа

Наименование этапа

Исполнитель

Дневная ставка, руб.

Коли-чество дней.

Сумма, руб.

1

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

Руководитель проекта и дипломник

800,00

176,92

1,25

1,75

1000,00

309,61

2

Подбор литературы

Дипломник

176,92

3

530,76

3

Исследование бизнес – процессов и построение моделей “Как есть” и “Как должно быть”

Дипломник

176,92

8

1415,36

4

Разработка инфологической модели данных

Дипломник

176,92

1

176,92

5

Разработка таблиц баз данных

Дипломник

176,92

2

353,84

6

Создание диаграммы базы данных

Дипломник

176,92

1

176,92

7

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

Дипломник

176,92

3

530,76

8

Разработка хранимых процедур

Дипломник

176,92

7

1238,44

9

Разработка интерфейса

Дипломник

176,92

5

884,6

Таблица 11 (окончание)

№ этапа

Наименование этапа

Исполнитель

Дневная ставка, руб.

Коли-чество дней.

Сумма, руб.

10

Разработка системы авторизации пользователей

Дипломник

176,92

1

176,92

11

Разработка алгоритмов программы

Дипломник

176,92

8

1415,36

12

Отладка программы на ЭВМ

Дипломник

176,92

15

2653,8

13

Оформление пояснительной записки

Дипломник

176,92

21

3715,32

14

Создание презентации

Дипломник

176,92

3

530,76

15

Создание демонстрационной версии программы

Дипломник

176,92

2

353,84

ИТОГО:

15463,46

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

Единый социальный налог (ЕСН) составляет 34 % от заработной платы, а именно:

В том числе:

  •  В пенсионный фонд РФ (26%) = 4020,5 руб.
  •  В фонд социального страхования РФ (2,9%) = 448,44 руб.
  •  В фонд обязательного медицинского страхования (5,1%) = 788,64 руб.
  1.  Амортизация основных фондов. Сюда входит сумма амортизацион-ных отчислений на полное восстановление основных фондов.

В данном проекте это затраты на амортизацию и эксплуатацию ЭВМ. Они определяются на основе стоимости одного машинного часа и времени эксплуатации ЭВМ, учитывая ее реальную стоимость, стоимость одного машинного часа и стоимость электроэнергии. Стоимость одного машинного часа ЭВМ рассчитывается по формуле:

где СМВ - стоимость машинного времени;

КМЧ =12∙24∙8=2688 – количество машинных часов в году при шестидневной рабочей неделе и восьмичасовом рабочем дне;

ТЭЛ =3,19 руб. за 1 кВт/ч - тариф за электроэнергию;

МПОТ =0,35 кВт - потребляемая ЭВМ мощность.

Стоимость машинного времени СМВ=Ao, 

где Ао-амортизационные отчисления. В компании используется линейный способ начисления амортизации. Срок полезного исопльзования ЭВМ – 3 года. Амортизационные отчисления рассчитаем по формуле:

где S – срок полезного использования (лет), СЭВМ – первоначальная стоимость стоимость ЭВМ (21 000 рублей). Тогда:

 

Затраты на машинное время определяются с учетом машинного часа и общего времени использования ЭВМ:

где NМЧ - количество часов рабочего времени, затраченных на отладку программы. Для данного проекта NМЧ определяется с учетом количества дней отладки программы (42 дня) и количества часов работы ЭВМ в день (6 часов), то есть общее количество времени составило:

Итого суммарная стоимость по статьям 1-4 составила:

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

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

Таким образом, сметная стоимость СП =36845,54 руб. Полная смета затрат приведена в таблице 12.

Таблица

Смета затрат

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

Затраты, руб.

Материальные затраты

683,25

Основная заработная плата

15463,46

Отчисления на социальные нужды

5257,58

Амортизационные отчисления

7000

Накладные расходы

2222.83

ИТОГО:

36845,54

Один час работы одного сотрудника приносит компании доход от 160 до 1000 рублей. В среднем в день поступает от 2 до 3 обращений. На сбор необходимой информации для анализа одного обращения от 20 минут до одного часа. Например, клиент может написать, что при редактировании аналитического сценария появилась некоторая ошибка и указать самую позднюю сборку платформы. Однако перед этим он использовал более раннюю версию, что являлось ключевым момент в появлении ошибки. Так как важная информация не была сообщена вовремя, было затрачено много времени на поиск ошибки там, где её нет. С использование системы можно сократить время сбора общей информации о ключах и организации до 5 минут, что в месяц может принести дополнительных доход от 3 200 до 73 300 рублей, за счет участия сотрудников в освободившееся время в более дорогостоящих проектах.

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

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


Заключение

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

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

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

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


Литература

  1.  ГОСТ 19.701 – 90 (ИСО 5807 – 85) Схемы алгоритмов, программ, данных и систем. – М.: Государственный стандарт союза ССР, 1990. – 22с.
  2.  Р 50.1.028-2001. Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования. М.: ИПК Изд-во стандартов, 2001. – 50 с.
  3.  Абдикеев Н.М. Реинжиниринг бизнес-процессов: учебник. – 2-е изд., испр. – М.: Эксмо, 2007. – 592 с.
  4.  Албахари, Дж. С# 3.0 Справочник: Пер. с анг. – 3-е изд. – СПб.: БХВ-Петербург, 2009. – 944 с.: ил.
  5.  Михеев Р.Н. MS SQL Server 2005 для администраторов. – СПб.: БХВ-Петербург, 2007. – 544 с.: ил.
  6.  Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2008 – 1232 с.: ил. – Парал. тит. англ.
  7.  Паклин Н.Б., Орешков В.И. Бизнес-аналитика: от данных к знаниям (+CD): Учеб. Пособие. 2-е изд., перераб. и доп. – СПб.: Питер, 2010. – 704 с.: ил.
  8.  Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», 2003 – 512 c.
  9.  Хомоненко А. Д. Базы данных : учеб. для вузов / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев ; ред. А. Д. Хомоненко. – 6-е изд. - СПб. : Корона-Век, 2010. – 736 с. : ил.
  10.  An Approach to Security Using Rijndael Algorithm / International Journal of Computer Applications (0975 – 8887) Volume 8 – No.5, – 2010. – p.31-35.
  11.  Белых А.А., Харитонов В.А. Интерпретация эффективности сложных систем с позиций рыночных отношений. Научный журнал КубГАУ, №59(05), – 2010.
  12.  Молоткова Н.В., Фетисова.О.В. Теоретико-методические аспекты реализации реинжиниринга бизнес-процессов предприятия в современных социально-экономических условиях / Вопросы современной науки и практики Университет имени В.И.Вернадского, выпуск N7-9(30), – 2010, – с. 217-222.
  13.  РАБОТА С БАЗАМИ ДАННЫХ НА ЯЗЫКЕ C#. ТЕХНОЛОГИЯ АDO .NET: учебное пособие / сост. О. Н. Евсеева, А. Б. Шамшев. –Ульяновск: УлГТУ, 2009. – 170 с.
  14.  Microsoft SQL Server 2005: System Requirements. http://www.microsoft.com/sqlserver/2005/en/us/system-requirements.aspx
  15.  Фирма BaseGroup Labs. http://www.basegroup.ru/company/about/
  16.  Фирма 1С. http://v8.1c.ru/solutions/product.jsp?prod_id=137


 

А также другие работы, которые могут Вас заинтересовать

62256. Самостоятельная работа на уроках русского языка как средство активизации познавательного интереса 34.33 KB
  В этом смысле особое значение приобретает проблема внедрения эффективных приемов самостоятельной работы в учебно-воспитательный процесс. Значит учителям необходимо учить детей самостоятельной работе.
62257. Самым лучшим уроком жизни бывает армия 20.01 KB
  Армия Что на самом деле дает этот важный урок в нашей жизни Вопрос на самом деле очень интересен и важен но в то же время кажущимся бесполезным для всех тех героев которые отслужили и вернулись домой. Армия Отнимает она на первый взгляд кажется больше чем дает. При всем моем огромном желании возможностях и начальных способностях я не умею воевать Задавим количеством А если Китай Что же на самом деле дает Армия Ты вглядываешься на жизнь совсем с другой стороны учишься жить в большом непростом коллективе когда каждый сам за...
62259. Счет победителей. Невыученные уроки войн, проигранных Россией 442.6 KB
  Прекратилась ли после этого информационная психологическая война Запада против России Сошла ли на нет русофобия Не прекратилась и не сошла. Вовторых восприятие России Западом как Чужого повидимому сохранится до тех пор пока Россия и Запад будут существовать в их нынешнем виде. Втретьих Запад в долгосрочной перспективе будет стремиться к максимальному ослаблению вплоть до раздробления России об этом откровенно говорили и говорят многие на Западе включая друга Билла Клинтона в октябре 1995 г. до такой степени при которой...