Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Проектирование CRM-системы ОАО "Орбита-Сервис"

Проектирование CRM-системы ОАО "Орбита-Сервис"

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 28.11.2012
Размер файла 1,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

1.7 Цель, назначение и задачи информационной подсистемы

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

1.8 Организационная структура ОАО "Орбита-Сервис"

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

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

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

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

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

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

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

Инженерный цех осуществляет ремонт и обслуживание.

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

Рекламный отдел занимается рекламой.

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

2.1 Основы технологий создания ПО

2.1.1 Визуальное моделирование

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

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

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

сложности проектируемой системы;

необходимой полноты ее описания;

знаний и навыков участников проекта;

времени, отведенного на проектирование.

Визуальное моделирование оказало большое влияние на развитие ТС ПО вообще и CASE-средств в частности. Понятие CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение этого понятия, ограниченное только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО.

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

2.1.2 Методы структурного анализа и проектирования ПО

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

Функциональную структуру системы;

Последовательность выполняемых действий;

Передачу информации между функциональными процессами;

Отношения между данными.

Наиболее распространенными моделями первых трех групп являются:

функциональная модель SADT (Structured Analysis and Design Technique);

модель IDEF3;

DFD (Data Flow Diagrams) - диаграммы потоков данных.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандартов этого семейства - IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г. Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:

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

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

соответствие подхода к описанию процессов стандартам ISO 9000.

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

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.

Диаграммы потоков данных (Data Flow Diagrams - DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

Наиболее распространенным средством моделирования данных (предметной области) является модель "сущность-связь" (Entity-Relationship Model - ERМ). Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели "сущность-связь" используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).

2.2 Методы анализа и проектирования ПО

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

Все современные ТС ПО реализуют ту или иную методику анализа и проектирования ПО. Одна из типичных методик ООАП реализована в технологии RUP. Согласно этой методике, объектно-ориентированный анализ включает два вида деятельности: архитектурный анализ и анализ вариантов использования. Архитектурный анализ выполняется архитектором системы и включает в себя:

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

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

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

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

Анализ вариантов использования выполняется проектировщиками и включает в себя:

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

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

­ определение атрибутов и ассоциаций классов.

В потоках событий варианта использования выявляются классы трех типов:

Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

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

Управляющие классы (Control) - обеспечивают координацию поведения объектов в системе. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.

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

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

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

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

Объектно-ориентированное проектирование включает два вида деятельности:

­ проектирование архитектуры системы;

­ проектирование элементов системы.

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

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

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

­ формирование архитектурных уровней;

­ проектирование конфигурации системы.

Проектирование элементов системы включает в себя:

­ проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами);

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

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

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

Рассмотрим предлагаемую нами функциональную модель выбранной предметной области. Контекстная диаграмма типа IDEF0 представлена на рисунке 3.

Рисунок 3 - Контекстная диаграмма

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

Декомпозиция первого уровня представлена на рисунке 4.

Рисунок 4 - Декомпозиция первого уровня

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

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

Рисунок 5 - Диаграмма потоков данных

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

Рисунок 6 - Результат декомпозиции первого уровня

2.5 Инфологическая модель предметной области

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

ER-диаграмма, построенная с помощью пакета MS SQL Enterparise Manager 7.2 представлена на рисунке 7.

Рисунок 7 - Инфологическая модель базы данных

2.6 Даталогическое проектирование базы данных

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

Рисунок 8 - Даталогическая модель базы данных

2.7 Разработка математической модели обслуживания заявок автоматизированной подсистемы на основе систем массового обслуживания

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

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

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

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

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

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

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

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

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

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

На рисунке 9 изображена структура СМО.

Рисунок 9 - Структура СМО

Классификация СМО и их основные элементы

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

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

По времени пребывания требований в очереди до начала обслуживания системы делятся на три группы:

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

­ с отказами (нулевое ожидание или явные потери). "Отказанная" заявка вновь поступает в систему, чтобы её обслужили (вызов абонента через АТС);

­ смешанного типа (ограниченное ожидание). Есть ограничение на длину очереди. Ограничение на время пребывания заявки в СМО.

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

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

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

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

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

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

(1)

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

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

Простейший поток обладает такими важными свойствами:

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

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

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

(2)

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

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

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

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

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

(3)

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

, (4)

где - среднее время обслуживания одного требования одним обслуживающим устройством.

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

(5)

где a - коэффициент загрузки;

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

v - интенсивность обслуживания одного требования одним обслуживающим устройством.

Из (1) и (2) получаем, что

(6)

Учитывая, что - интенсивность поступления требований в систему

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

Для СМО с ожиданием количество обслуживаемых устройств n должно быть строго больше коэффициента загрузки (требование установившегося или стационарного режима работы СМО): .

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

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

Эффективность работы СМО характеризуется:

1) Группой показателей эффективности использования СМО:

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

­ относительная пропускная способность - отношение АПС к среднему числу заявок, поступивших за единицу времени (Q);

­ средняя продолжительность периода занятости СМО (Те);

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

2) Показателями качества обслуживания заявок:

­ среднее время ожидания заявки в очереди (T line);

­ среднее время пребывания заявки в СМО (T sys);

­ вероятность отказа заявки в обслуживании без ожидания;

­ вероятность немедленного приёма заявки;

­ среднее число заявок в очереди (N line);

­ среднее число заявок, находящихся в СМО (N sys).

3) Показателями эффективности функционирования пары "СМО - потребитель", (например, когда доход от СМО и затраты на её обслуживание измеряются в одних и тех же единицах, и отражает специфику работы СМО).

Обслуживание с ожиданием

СМО с ожиданием распространены наиболее широко. Их можно разбить на 2 большие группы - разомкнутые и замкнутые. Эти системы определяют так же, как системы с ограниченным входящим потоком.

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

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

Мы рассмотрим здесь классическую задачу теории массового обслуживания в тех условиях, в каких она была рассмотрена и решена К. Эрлангом на n одинаковых приборов поступает простейший поток требований интенсивности . Если в момент поступления имеется хотя бы один свободный прибор, оно немедленно начинает обслуживаться. Если же все приборы заняты, то вновь прибывшее требование становится в очередь за всеми теми требованиями, которые поступили раньше и ещё не начали обслуживаться. Освободившийся прибор немедленно приступает к обслуживанию очередного требования, если только имеется очередь. Каждое требование обслуживается только одним прибором, и каждый прибор обслуживает в каждый момент времени не более одного требования. Длительность обслуживания представляет собой случайную величину с одним и тем же распределением вероятностей F (x). Предполагается, что при x0.

(7)

где - постоянная.

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

Например, вызов абонента, имеющего только один телефонный номер, через АТС. Здесь поток заявок является случайным, если абонент занят, очередная поступающая заявка получает отказ в обслуживании; АТС - это одноканальная СМО (канал обслуживания - линия связи с телефонным номером абонента) с отказами. Работа пейджинговой компании. Многоканальная СМО, число каналов - количество дежурных операторов, СМО с ограниченной очередью (ограничение на длину очереди - память накопителя вызовов).

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

Разработанный программный продукт состоит из трех основных модулей представленных на рисунке 10.

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

Рисунок 10 - Модульная структура программы

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

2.9 Описание алгоритма работы программного модуля

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

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

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

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

Продолжение рисунка 11 - Алгоритм работы программы

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

Продолжение рисунка 11 - Алгоритм работы программы

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

Рисунок 11 - Алгоритм работы программы

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

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

3 Реализация

3.1 Выбор программного средства разработки

3.1.1 Borland Delphi

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

Для реализации поставленных перед подсистемой задач выбрано средство разработки приложение Borland Delphi 7, а также СУБД, поддерживающая архитектуру "клиент-сервер" Microsoft SQL Server 2000. Рассмотрим данные средства более подробнее:

Borland Delphi 7:

Delphi 7 - является наиболее полным решением для разработки корпоративных приложений от проектирования до развертывания по архитектуре, управляемой моделью (MDA), которое позволяет интегрировать моделирование, разработку и развертывание приложений и систем электронного бизнеса для платформы Windows. Delphi 7 содержит развитые библиотеки и инструменты для создания приложений электронного бизнеса и веб-сервисов, полностью интегрирует соответствующие технологии и качественно повышает производительность разработчиков, предоставляя все необходимое для исследования вопросов перехода на Microsoft.net. При помощи включенного в комплект поставки Kylix 3 для Delphi разработчики могут переносить свои приложения на Linux, повышая отдачу своих инвестиций и расширяя спектр платформ, на которых доступны их приложения. Интегрируя ведущие приложения разработки в единый и легкий в использовании пакет [8]. Delphi 7 сокращает жизненный цикл разработки приложений и ускоряет вывод создаваемых с его помощью продуктов на рынок ПО.

Delphi 7 обладает возможностями проектирования и развертывания корпоративных приложений. Это позволяет разработчикам быстрее воспользоваться преимуществами разработки корпоративных приложений от концепции до коммерческой версии при помощи новой системы проектирования UML и технологии Model Driven Architecture (MDA).

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

Включённая в состав Delphi 7 технология проектирования и моделирования приложений UML позволяет эффективно проектировать свои приложения при помощи средств визуального моделирования и реорганизации кода (refactoring) [9]. Возможности Delphi 7 по интеграции, реинжинирингу и мгновенной визуализации позволяют создавать высококачественные проекты и тексты программ, применяя готовые шаблоны проектирования и создавая более крупные модели.

Kylix 3 в составе Delphi 7 является первой высокопроизводительной визуальной интегрированной средой разработки (IDE), предназначенной для быстрого создания приложений баз данных, программ с графическим пользовательским интерфейсом (GUI), Internet-приложений и WEB-сервисов для операционной системы Linux.

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

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

3.1.2 MS SQL Server

Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server.

Microsoft SQL Server также поддерживает Open Database Connectivity (ODBC) - интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server [15]. Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000.

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

SQL Server поддерживает избыточное дублирование данных по трем сценариям:

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

История изменений - все изменения базы данных непрерывно передаются пользователям.

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

3.2 Описание прикладной программы

3.2.1 Назначение программы

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

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

Программа работает с СУБД MS SQL Server 2000, перед запуском программы необходимо убедиться, что запущен MS SQL Server, в противном случае программа выдаст предупреждение о том, что необходимо включить MS SQL Server. Выбранная СУБД позволяет работать нескольким приложениям одновременно. В ОАО Орбита Сервис к базе данных будет подключено одновременно до 18 клиентов с разными правами доступа.

3.2.2 Системные и программные требования

Для корректной работы данной программы на стороне клиента необходимо наличие компьютера с архитектурой совместимой с I386 и операционной системой Windows XP, Windows 2000, Windows Vista. Из специального программного обеспечения на рабочую станцию необходимо установить СУБД MS SQL SERVER 2000.

Минимальные системные требования для аппаратного обеспечения:

­ оперативная память 128Мб;

­ процессор с тактовой частотой 800 MHz;

­ свободное место на жестком диске 20Мб;

­ видеосистема SVGA 800Ч600;

­ клавиатура;

­ мышь;

­ CD привод для чтения оптических дисков;

­ PC совместимый принтер.

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

­ оперативная память 256Мб;

­ процессор с тактовой частотой 1000 MHz;

­ свободное место на жестком диске 5Гб;

­ видеосистема SVGA 1024Ч768;

­ клавиатура;

­ мышь;

­ CD привод для чтения оптических дисков;

­ PC совместимый принтер.

Размер файлов отчетов со временем будет увеличиваться, поэтому рекомендуется свободного места на жестком диске не меньше 5ГБ.

Для корректной работы сервера СУБД необходимо наличие компьютера с архитектурой совместимой с I386 и операционной системой Windows XP, Windows 2000, Windows Vista, с установленным MS SQL SERVER 2000.

Минимальные системные требования для аппаратного обеспечения:

­ оперативная память 512Мб;

­ процессор с тактовой частотой 1000 MHz;

­ свободное место на жестком диске 5Гб;

­ видеосистема SVGA 800Ч600;

­ клавиатура;

­ мышь;

­ CD привод для чтения оптических дисков.

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

­ оперативная память 1024Мб;

­ процессор с тактовой частотой 2000 MHz;

­ свободное место на жестком диске 20Гб;

­ видеосистема SVGA 800Ч600;

­ клавиатура;

­ мышь;

­ CD привод для чтения оптических дисков.

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

3.2.3 Описание интерфейса и возможностей программы

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

Рисунок 12 - Главное окно программы

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

­ справочник инженеров;

­ поиск;

­ печать;

­ экспорт в excel;

­ добавление, изменение, удаление записи;

­ фильтр по значениям ячеек;

­ функция быстрый поиск по номеру заказа;

­ фильтр по дате;

­ настройка интерфейса.

Окно "Поиск" показано на рисунке 13. В нем мы можем производить поиск, как по какому-то отдельному критерию, так и сразу по нескольким.

Рисунок 13 - Окно "Поиск"

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

Окно редактирования данных показано на рисунке 14.

Рисунок 14 - Редактирование данных

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

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

­ принято в ремонт

­ тестовый прогон

­ ожидание детали

­ отремонтирован

­ выдан клиенту

По умолчание при добавлении новой записи статус телефона установлен в значение "принято в ремонт".

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

Рисунок 15 - "Справочник инженеры"

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

На Рисунке 16 показано добавление нового инженера.

Рисунок 16 - Добавление нового инженера в справочник

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

Рисунок 17 - Настройка интерфейса системы

Разработанная система позволяет распечатать квитанции для клиента. Например, печать наряда-заказа и квитанции показана на рисунках 18 и 19. Квитанцию клиент забирает себе, и предъявляет её при получении отремонтированного телефона, в случае утери квитанции мы всегда сможет идентифицировать клиента по ФИО или другим данным.

В квитанции распечатываются основные данные, такие как:

­ модель;

­ серийный номер;

­ IMEI;

­ серийный номер батареи;

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

­ неисправность со слов клиента;

­ стоимость ремонта;

­ замечания, внешний вид;

­ дата приёма;

­ инженер.

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

­ ФИО клиента;

­ адрес;

­ контактный телефон;

­ модель телефона сданного в ремонт;

­ серийный номер;

­ IMEI;

­ серийный номер батареи;

­ комплектность;

­ неисправность со слов клиента;

­ стоимость ремонта;

­ замечания, внешний вид;

­ дата приёма;

­ дата выдачи;

­ инженер.

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

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

Рисунок 18 - Предпросмотр наряд-заказа перед печатью

Рисунок 19 - Предпросмотр квитанции перед печатью

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

Рисунок 20 - Экспорт данных в xls формат

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

Рисунок 21 - Система оповещения

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

3.2.4 Резервное копирование

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

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

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

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

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

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены