Разработка системы поддержки принятия решений для повышения эффективности деятельности компании-интегратора

Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление 09.03.03 - Прикладная информатика

(специальность)

Кафедра Экономических и информационных систем

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА (БАКАЛАВРСКАЯ РАБОТА)

Разработка системы поддержки принятия решений для повышения эффективности деятельности компании-интегратора

Разработал

Ю.А. Кочеткова

Самара 2017



Введение

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

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

Компания ООО «Велес-С» работает под маркой «1С:Франчайзинг». Данный статус даёт право компании на оказание услуг в сфере 1С, начиная от подбора ПП и его установки на ОС заказчика и заканчивая обучением и сопровождением заказчика.

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

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

Предметом исследования является бизнес-процесс «Внедрение платформы 1С:Предприятие». Для усовершенствования данного процесса необходимо внедрить СППР, которая сможет вести документооборот, собрать классифицированную информацию о клиенте и его потребностях, более чётко координировать работу двух отделов (отдела внедрения и отдела продаж) и помочь специалисту подобрать решение, которое удовлетворит конкретного клиента.

Цель ВКР - улучшения процесса подбора программного продукта 1С с помощью разработки соответствующей СППР.

Были поставлены следующие задачи ВКР:

1) анализ бизнес-процесса «Внедрение платформы 1С:Предприятие»;

2) обоснование необходимости усовершенствования существующей управленческой практики компании-интегратора;

3) анализ существующих аналогов системы для подбора ПП;

4) выбор средств проектирования и разработки СППР;

5) разработка экранных форм будущей СППР.

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

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

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



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

1.1 Идентификация предметной области

1.1.1 Содержательное описание объекта исследования

Объектом исследования в бакалаврской работе выступила компания ООО «Велес-С», занимающаяся автоматизацией управления и учета на базе программных продуктов «1С». Компания основана в 2007 г.

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

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

Данная фирма-франчайзи предоставляет следующий набор ИТ-услуг:

- подбор и демонстрация программного продукта (ПП);

- поставка ПП;

- внедрение ПП;

- сопровождение ПП;

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

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

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

Компания также занимается разработкой и продажей собственных программных продуктов на платформе «1С:Предприятие 8».

«Велес-С» нанимает только специалистов, имеющих сертификат от фирмы «1С», которые занимаются постоянным совершенствованием своих навыков 1С-программирования.

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

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

Преимуществами фирмы ООО «Велес-С» являются:

- большой каталог предоставляемых программных продуктов 1С;

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

- проведение курсов по обучению «1С», тренингов и семинаров;

- тщательный отбор и обучение работающих специалистов;

- постоянное совершенствование решений в сфере ИТ-услуг;

- индивидуальный подход к каждому клиенту;

- гибкая стоимостная политика и т.д.

1.1.2 Организационная структура

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

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

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

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

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

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

Условные обозначения:

Отдел ИТС - Отдел информационно-технического сопровождения

ПП - программный продукт

Рис. 1.1 - Организационная структура предприятия

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

Секретарь ведёт текущие дела директора и фирмы.

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

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

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

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

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

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

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

Конкурентами фирмы являются другие фирмы-франчайзи, такие как:

1) 1С:Первый БИТ;

2) 1С-РАРУС;

3) РОСИНФО;

4) ПромИнфоКонсалт;

5) Три С;

6) Компания "Байт";

7) СкайТех;

8) и т.д.

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

1.2 Описание бизнес-процесса подбора нужных модулей

Бизнес-процесс - совокупность различных видов деятельности, в рамках которой «на входе» используется один или несколько видов ресурсов, и в результате этой деятельности на «выходе» создаётся продукт, представляющий ценность для потребителя [2].

Бизнес-процесс включает в себя:

- вход;

- выход;

- владельца процесса;

- исполнителя процесса;

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

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

Преимущества процессного подхода:

1) ориентированность на получение результата;

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

3) снижение загруженности руководителя;

4) ориентация на потребителя процесса и др.

На рисунке 1.2 представлена схема бизнес-процесса «Внедрение платформы 1С:Предприятие».

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

Когда поступает заявка, специалист выезжает к заказчику. На месте инженер-программист проверяет соответствие операционной системы (ОС) заказчика техническим требованиям к «1С:Предприятие». Если по каким-либо причинам ОС не проходит проверку, то заказчику отказано в услугах. Если ОС соответствует требованиям, то проводятся более детальные переговоры с заказчиком на предмет его потребностей и предпочтений.

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

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

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



Рис. 1.2 - Бизнес-процесс «Внедрение платформы 1С:Предприятие»



Продолжение рис. 1.2



1.3 Анализ и обоснование необходимости усовершенствования существующей управленческой практики компании-интегратора

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

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

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

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

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

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

Архитектурно СППР состоит из:

- базы данных (БД);

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

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

Задачи, выполняемые системой:

1) учет клиентов (добавление всех клиентов в единую БД системы и их группировка);

2) прикрепление конкретного сотрудника к конкретному заказу;

3) управление продажами ПП (добавление в БД и ведение всех сделок, сохраняя информацию о каждом этапе);

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

5) генерирование возможных решений исходя из установленных критериев;

6) оценка решений и выявление наиболее подходящих;

7) предоставление результатов в удобном для пользователей виде.

Основой интеллектуальной составляющей данной СППР будет являться нечёткая система.

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

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

1.4 Анализ существующих аналогов

Аналогом разрабатываемой СППР может быть сайт по автоподбору программных продуктов

Рис. 1.3 - Дизайн окна сайта по автоподбору продукта

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

По результатам заполненной анкеты на рис. 1.3 сайт выдаёт список возможных ПП для данного предприятия и возможную стоимость установки (рис. 1.4).

Рис. 1.4 - Результирующий список по автоподбору продукта

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

1.5 Выбор средств проектирования и разработки ИС

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

В качестве средства проектирования предметной области был выбран язык Unified Modeling Language. Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем [5].

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

Общие принципы моделирования:

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

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

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

Модели языка UML бывают: статические, описывающие структуру объектов системы, и динамические, описывающие их поведение.

UML включает следующие диаграммы:

1) диаграммы вариантов использования;

2) диаграммы классов;

3) диаграммы состояний;

4) диаграммы деятельностей;

5) диаграммы последовательности;

6) диаграммы кооперации;

7) диаграммы компонентов;

8) диаграммы развёртывания.

1.5.2 Средство разработки

В качестве средства разработки была выбрана среда быстрой разработки программного обеспечения Lazarus. Это - среда быстрой разработки программного обеспечения для компилятора Free Pascal, аналогичная Delphi.

Базой для данной программы является оригинальная кроссплатформенная библиотека визуальных компонентов Lazarus Component Library (LCL). Кроссплатформенное ПО - это ПО, которое может работать на нескольких аппаратных платформах и ОС.

Free Pascal - это бесплатно распространяемый компилятор языка Pascal, работающий под Windows, Linux, Mac OS X, FreeBSD и др. Приложения, разработанные в Lazarus, могут работать на любой ОС.

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

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

1) создание проекта (окно будущего приложения).

2) создание графического интерфейса проекта;

3) написание программного кода;

4) отладка программы.



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

2.1 Разработка архитектуры СППР

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

2.1.1 Диаграмма компонентов

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

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

Рис. 2.1 - Диаграмма компонентов



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

1) БД Пользователей - содержит данные о пользователях, такие как наименование, юридический и почтовый адрес, контактные данные;

2) отчет об установке - содержит информацию о процессе установки ПП, такую как дата и время проведения, состояние работы на текущий момент времени;

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

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

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

6) система управления нормативно-справочной информацией,

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

8) система анализа - отвечает за анализ введённой информации о фирме заказчика и подбор ПП и его модификаций;

9) система формирования отчетности - отвечает за формирование всех типов отчётов касательно состояния выполнения заказов, состояния работ.

2.1.2 Диаграмма развёртывания

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

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

1) Сервер системы формирования отчетностей, предназначенный для хранения и создания отчётов по всем видам работ, проводимым для выполнения заказа;

2) Сервер БД - узел, который обеспечивает работу базы данных о заказчиках и помогает осуществить доступ к ней для сервера формирования отчётности;

3) База данных «Заказчики» содержит в себе всю информацию о заказчиках и их заказах;

4) Сервер приложений осуществляет доступ для ПК пользователей к БД и серверу системы формирования отчётности;

5) ПК пользователей со стереотипом «device» представляет собой возможность пользователей работать с установленным программным продуктом.

Рис. 2.2 - Диаграмма развёртывания



2.2 Функциональное моделирование предметной области

Этап функционального моделирования осуществлён с помощью языка UML. Язык UML- унифицированный язык моделирования, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем. UML осуществляет объектно-ориентированный подход к описанию структуры и поведения системы [9]. UML - это набор графических символов, за которыми стоит определённая семантика, поэтому модель созданная одним разработчиком, может легко быть понята другими разработчиками или программой.

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

2.2.1 Диаграмма вариантов использования

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

В диаграмме вариантов использования описан сценарий взаимодействия между «Сотрудниками» («Инженером-программистом» и «Сотрудником отдела продаж»), «СППР» и «Заказчиком».



Рис. 2.3 - Диаграмма вариантов использования

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

Предусловием варианта использования «Собрать информацию о фирме» является поступление заявки от заказчика на внедрение ПП.

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

Основной поток:

1) Вариант использования начинается, когда от заказчика поступает заявка на внедрение ПП.

2) Инженер-программист выезжает на фирму к заказчику.

3) Специалист проверяет соответствие ОС заказчика техническим требованиям к «1С: Предприятие». Если ОС не соответствует требованиям, то выполняется альтернативный потом событий А1.

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

5) Заказчик заполняет анкету с вопросами, касающимися направленности бизнеса фирмы заказчика и его требований к ПП.

Альтернативный поток А1. ОС не соответствует техническим требованиям.

1) Инженер-программист информирует заказчика о том, что его ОС не соответствует техническим требованиям к «1С: Предприятие».

2) Фирма получает отказ на выполнение своего заказа.

Постусловием варианта использования «Собрать информацию о фирме» является выполнение варианта использования «Ввести информацию о фирме в СППР».

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

Предусловием варианта использования «Ввести информацию о фирме в СППР» является выполнение варианта использования «Собрать информацию о фирме».

Поток событий варианта использования «Ввести информацию о фирме в СППР» выглядит следующим образом:

Основной поток:

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

2) Инженер-программист должен перенести все данные из формы анкеты на экранную форму СППР.

3) Инженер-программист запускает подбор ПП.

Постусловием варианта использования «Ввести информацию о фирме в СППР» является выполнение варианта использования «Подобрать ПП».

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

Предусловием варианта использования «Подобрать ПП» является выполнение вариантов использования «Собрать информацию о фирме» и «Ввести информацию о фирме в СППР».

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

Основной поток:

1) Вариант использования начинается, когда инженер-программист вводит информацию о фирме в СППР.

2) СППР должна на основе информации из анкеты провести подбор ПП, подходящего для конкретного заказчика.

3) СППР выявляет, есть ли уникальные бизнес-процессы в работе фирмы и нужны ли специальные модификации в ПП. Если уникальные бизнес-процессы есть, то выполняется альтернативный поток событий А1.

4) СППР оценивает стоимость будущих работ по внедрению подобранной системы в ОС заказчика.

5) СППР выводит результаты анализа на экран.

6) Инженер-программист изучает полученные данные.

Альтернативный поток А1. Есть уникальные бизнес-процессы.

1) СППР выявляет в чём уникальность бизнес-процессов.

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

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

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

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

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

Основной поток:

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

2) Сотрудник отдела продаж составляет договор между фирмой заказчика и фирмой-франчайзи о предоставлении услуг.

3) Заказчик ознакамливается с договором. Если заказчик не согласен с какими-либо условиями, то выполняется альтернативный поток событий А1.

4) Представитель заказчика подписывает договор вместе с сотрудником отдела продаж.

5) Сотрудник отдела продаж запрашивает у заказчика оплату предоставленных услуг.

6) Заказчик оплачивает услуги по договору.

7) Сотрудник отдела продаж принимает платёж.

Альтернативный поток А1. Заказчик не согласен с условиями договора.

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

2) Заказ отменяется.

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

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

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

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

Основной поток:

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

2) Инженер-программист ознакамливается с результатами подбора программного продукта.

3) Инженер-программист проводит кодирование ПП. Если СППР посоветовала также добавить определённые модификации, то выполняется альтернативный поток событий А1.

4) Затем инженер-программист тестирует готовый ПП. Если тестирование прошло не успешно, то выполняется альтернативный поток событий А2.

Альтернативный поток А1. СППР посоветовала добавить определённые модификации.

1) Инженер-программист узнаёт, какие модификации нужны ПП.

2) Инженер-программист кодирует модификации в ПП.

Альтернативный поток А2. Тестирование ПП прошло не успешно.

1) Инженер-программист изучает отчёт об ошибках во время тестирования.

2) Инженер-программист проводит повторное кодирование и исправление возникших ошибок.

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

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

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

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

Основной поток:

1) Вариант использования начинается после того, как тестирование ПП прошло успешно.

2) Инженер-программист выезжает на фирму к заказчику.

3) Инженер-программист устанавливает ПП на ОС заказчика.

4) Инженер-программист настраивает работу ПП на ПК пользователей. Если перенос данных из старой системы заказчика на новую нужен, то выполняется альтернативный поток событий А1.

Альтернативный поток А1. Нужен перенос старых данных.

1) Инженер-программист получает у заказчика доступ к данным из старой системы.

2) Специалист осуществляет перенос старых данных на новую систему.

Постусловием варианта использования «Провести внедрение ПП» является выполнение варианта использования «Провести обучение пользователей».

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

Предусловием варианта использования «Провести обучение пользователей» является выполнение варианта использования «Провести внедрение ПП».

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

Основной поток:

1) Вариант использования начинается с составления руководства для пользователей.

2) Инженер-программист выезжает на фирму к заказчику.

3) Специалист вручает руководство пользователям.

4) Инженер-программист объясняет пользователям, как работать с новой системой.

Вариант использования «Ввести данные об изменении состояния заказа в СППР» включает в себя постоянный мониторинг заказа со стороны сотрудников и внесение всех изменений в БД СППР.

Поток событий варианта использования «Ввести данные об изменении состояния заказа в СППР» выглядит следующим образом:

Основной поток:

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

2) Сотрудник должен внести всю информацию о текущем состоянии выполнения заказа в специальную экранную форму в СППР.

2.2.2 Диаграмма классов

Диаграмма классов является логической моделью системы. Данная диаграмма представляет статическую структуру модели системы. Она отражает взаимосвязи между отдельными сущностями (объектами) предметной области и описывает их внутреннюю структуру и типы отношений [11].

В классе «Сотрудник» содержится информация обо всех сотрудниках, работающих над бизнес-процессом «Внедрение платформы 1С:Предприятие».

Класс «Фирма заказчика» содержит данные о фирме, предоставленные заказчиком.

В классе «ПП» прописывается информация о программных продуктах, хранящихся на складе.

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

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

Класс «Работа» включает в себя информацию обо всех работах, совершаемых сотрудниками для выполнения поступивших заказов.

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

Класс «Установка ПП» содержит данные об отчёте об установке программного продукта на ОС заказчика.

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

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

Класс « Анкета» описывает все анкеты, которые заполняет заказчик.

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

Одна фирма-заказчик может обратиться в фирму-франчайзи с несколькими заказами, поэтому между классами «Фирма заказчика» и «Заказ» стоит связь «1:n».

Между классами «Сотрудник» и «Работа» стоит кратность «1:n», так как один сотрудник любой должности может заниматься несколькими работами, относящимся к разным заказам.

Для разных заказов при подборе ПП, может быть выбран один и тот же программный продукт, поэтому между классами «ПП» и «Подбор ПП» стоит связь «1:n».

Классы «Подбор ПП», «Установка ПП», «Выезд специалиста» и «Анкетирование» являются потомками для класса предка «Работа», так как они относятся к видам работ, которые делают сотрудники для выполнения поступившего заказа.

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

Анкета состоит из нескольких вопросов, поэтому связь между классами «Анкета» и «Вопрос» имеют кратность «1:n».

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

Класс «Договор» и класс «Заказ» связаны отношением агрегации, так как при завершении заказа сам договор сохраняется в БД.

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



Рис. 2.4 - Диаграмма классов

2.2.3 Диаграммы состояний

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

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



Рис. 2.5 - Диаграмма состояний для системы

Для сотрудника. Выделено три простых состояния, одна начальная точка и одна конечная.

Рис. 2.6 - Диаграмма состояний для сотрудника

Для заказчика. Выделено три простых состояния, одна начальная точка и одна конечная.

Рис. 2.7 - Диаграмма состояний для заказчика

Для заказа. Выделено три простых состояния, одна начальная точка и одна конечная.

Рис. 2.8 - Диаграмма состояний для заказа



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

Рис. 2.9 - Диаграмма состояний для программного продукта

2.2.4 Диаграмма деятельностей

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

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

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



Рис. 2.10 - Диаграмма деятельностей



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

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

2.2.5 Диаграмма последовательности

Диаграмма последовательности помогает рассматривать взаимодействие объектов (классов, компонентов) системы во времени, а также обмен сообщениями между отдельными объектами системы [14].

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

Рис. 2.11 - Диаграмма последовательности

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

2.2.6 Диаграмма кооперации

Диаграммы кооперации отображают поток событий через конкретный сценарий варианта использования и упорядочены по времени. На диаграмме кооперации представлена вся та информация, которая есть и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. В отличие от диаграммы последовательности, на диаграмме кооперации показаны только отношения между объектами, играющими определённые роли во взаимодействии [15].

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



Рис. 2.12 - Диаграмма кооперации

2.3 Инфологическое проектирование БД

Цель этапа инфологического проектирования заключается в формировании описания предметной области и её элементов.

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

Для данной СППР в качестве инфологической модели будет выступать ER-модель. Составляющими данной модели являются: сущность, атрибут и связь.

Сущность - представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками [17].

Атрибут - свойство, которое однозначно идентифицирует каждый экземпляр сущности [18].

Связь - это ассоциация, установленная между несколькими сущностями. В данной ER- модели встречается связь типа один-ко-многим (1:m). Она означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности.

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

Описание сущностей и их атрибутов ИС приведено в табл. 2.1-2.12.

Рис. 2.13 - ER-модель



Таблица 2.1 Описание сущностей

Название объекта	Обозначение объекта	Вид связи	Связанные сущности
Фирма заказчика	Фирма заказчика	1: m 1: m	Подписание договора Заказ
Заказ	Заказ	m: 1 m: 1 m: 1 m: 1 m: 1	Фирма заказчика Анкетирование Выезд специалиста Подбор ПП Установка ПП
Подписание договора	Подписание договора	m: 1 m: 1	Фирма заказчика Анкета
Анкетирование	Анкетирование	1: m m: 1 m: 1	Заказ Анкета Сотрудник
Анкета	Анкета	1: m 1: m	Вопрос Анкетирование
Вопрос	Вопрос	m: 1	Анкета
Выезд специалиста	Выезд специалиста	1: m m: 1	Заказ Сотрудник
Сотрудник	Сотрудник	1: m 1: m 1: m 1: m 1: m	Подписание договора Анкетирование Выезд специалиста Подбор ПП Установка ПП
ПП	ПП	1: m 1: m	Подбор ПП Установка ПП
Подбор ПП	Подбор ПП	1: m m: 1 m: 1	Заказ Сотрудник ПП
Установка ПП	Установка ПП	1: m m: 1 m: 1	Заказ Сотрудник ПП

Таблица 2.2 Описание сущности «Фирма заказчика»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID фирмы заказчика	id фирмы заказчика	Числовой	Первичный ключ
Название фирмы	Название	Текстовый
Контактный номер телефона	Номер телефона	Числовой
Фамилия контактного лица	Фамилия к.л.	Текстовый
Имя контактного лица	Имя к.л.	Текстовый
Отчество контактного лица	Отчество к.л.	Текстовый
Юридический адрес	Юридический адрес	Текстовый

Таблица 2.3 Описание сущности «ПП»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID ПП	id ПП	Числовой	Первичный ключ
Название	Название	Текстовый
Количество на складе	Кол-во на складе	Числовой
Стоимость	Стоимость	Числовой
Отрасль	Отрасль	Текстовый
Функциональная задача	Задача	Текстовый
Подходящая страна работы ПП	Страна работы	Текстовый
Пригодность для крупных проектов	Крупные проекты	Текстовый
Тип предприятия	Тип предприятия	Текстовый

Таблица 2.4 Описание сущности «Заказ»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID заказа	id заказа	Числовой	Первичный ключ
Дата заказа	Дата заказа	Дата
Состояние заказа	Состояние заказа	Текстовый
ID фирмы заказчика	id фирмы заказчика	Числовой	Внешний ключ
ID анкетирования	id анкетирования	Числовой	Внешний ключ
ID выезда специалиста	id выезда специалиста	Числовой	Внешний ключ
ID подбора ПП	id подбора ПП	Числовой	Внешний ключ
ID установки ПП	id установки ПП	Числовой	Внешний ключ

Таблица 2.5 Описание сущности «Подписание договора»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID подписания договора	id подписания	Числовой	Первичный ключ
Номер договора	Номер договора	Числовой
Стоимость услуг	Стоимость услуг	Числовой
Состояние оплаты	Состояние оплаты	Текстовый
Дата подписания договора	Дата подписания	Дата
ID фирмы заказчика	id фирмы заказчика	Числовой	Внешний ключ
ID сотрудника	id сотрудника	Числовой	Внешний ключ



Таблица 2.6 Описание сущности «Вопрос»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID вопроса	id вопроса	Числовой	Первичный ключ
Вопрос	Вопрос	Текстовый
Ответ	Ответ	Перечисление
ID анкеты	id анкеты	Числовой	Внешний ключ

Таблица 2.7 Описание сущности «Анкетирование»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID анкетирования	id анкетирования	Числовой	Первичный ключ
Результат анкетирования	Результат анкетирования	Перечисление
Дата проведения	Дата проведения	Дата
Время проведения	Время проведения	Время
Состояние выполнения	Состояние выполнения	Текстовый
ID анкеты	id анкеты	Числовой	Внешний ключ
ID сотрудника	id сотрудника	Числовой	Внешний ключ

Таблица 2.8 Описание сущности «Анкета»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID анкеты	id анкеты	Числовой	Первичный ключ
Фамилия автора анкеты	Фамилия автора	Текстовый
Имя автора анкеты	Имя автора	Текстовый
Отчество автора анкеты	Отчество автора	Текстовый
Дата обновления	Дата обновления	Дата

Таблица 2.9 Описание сущности «Выезд специалиста»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID выезда специалиста	id выезда специалиста	Числовой	Первичный ключ
Дата проведения	Дата проведения	Дата
Время проведения	Время проведения	Время
Состояние выполнения	Состояние выполнения	Текстовый
Номер бланка	Номер бланка	Числовой
ID сотрудника	id сотрудника	Числовой	Внешний ключ



Таблица 2.9 Описание сущности «Сотрудник»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID сотрудника	id сотрудника	Числовой	Первичный ключ
Фамилия сотрудника	Фамилия	Текстовый
Имя сотрудника	Имя	Текстовый
Отчество сотрудника	Отчество	Текстовый
Должность	Должность	Текстовый
Номер телефона	Номер телефона	Числовой

Таблица 2.11 Описание сущности «Подбор ПП»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID подбора ПП	id подбора ПП	Числовой	Первичный ключ
Дата проведения	Дата проведения	Дата
Время проведения	Время проведения	Время
Состояние выполнения	Состояние выполнения	Текстовый
ID сотрудника	id сотрудника	Числовой	Внешний ключ
ID ПП	id ПП	Числовой	Внешний ключ

Таблица 2.12 Описание сущности «Установка ПП»

Название атрибута	Обозначение атрибута	Тип данных	Примечание
ID установки ПП	id установки	Числовой	Первичный ключ
Дата проведения	Дата проведения	Дата
Время проведения	Время проведения	Время
Состояние выполнения	Состояние выполнения	Текстовый
Номер отчёта	Номер отчёта	Числовой
ID сотрудника	id сотрудника	Числовой	Внешний ключ
ID ПП	id ПП	Числовой	Внешний ключ

2.4 Проектирование базы знаний

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

Типы моделей представления знаний:

- логическая модель;

- продукционная модель;

- нечёткая модель;

- семантическая модель;

- фреймы.

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