Введение
В данной работе необходимо будет разобраться с предметной областью, выявить проблемы, предоставить обзор решения данных проблем, создать модели данных и другие модели системы, решающей данные проблемы в предметной области. Также необходимо создать проект иерархической структуры работ.
Основная часть
Муниципальное предприятие города Армавира «Озеленитель» создано на базе тепличного комплекса в феврале 1993 года. МП г. Армавира «Озеленитель» является членом Ассоциации цветоводов и озеленителей России. Руководит предприятием с 1993 года Заслуженный работник ЖКХ Кубани Сергей Владимирович Костюк.
«Озеленитель» тесно сотрудничает с родственными предприятиями городов и посёлков края – Сочи, Кропоткин, Тихорецка, Краснодара, Успенского, Новокубанска, Туапсе, с предприятиями других краёв и областей – Ростова, Таганрога, Ставрополя, Пятигорска, Нальчика.
Основное направление деятельности «Озеленителя» - производство работ по озеленению города и текущему содержанию городских зеленых насаждений, работы по ландшафтному дизайну. Кроме того, предприятие осуществляет производство более ста наименований цветочной рассады, более ста наименований горшечных растений, выращивание срезочной продукции и изготовление из нее букетов, корзин, венков, композиций, флористические работы.
Основные цеха предприятия - цех зеленого строительства, цех цветоводства. В состав предприятия входит цех по изготовлению малых архитектурных форм из дерева, бетона. Также в состав предприятия входят участок механизации - это 18 единиц техники и 26 человек механизаторов и ремстройучасток, который помимо выполнения ремонтных работ для нужд предприятия освоил производство тротуарной плитки.
Клиенты фирмы звонят на фирму, согласовывают заказ с менеджером. Они передают ему список того, что хотят заказать, менеджер согласно прайсу выставляет счет, а также говорит о том, какие виды продукции не могут быть поставлены, какие сроки предоставления и другие особенности заказа. В результате клиент получает ответ (письмо, факс, что-то другое) в котором менеджер пишет результат запроса, если клиент согласен, то он связывается с менеджером и подтверждает заказ. Менеджер предъявляет требование по оплате заказа, после выполнения этих требований фирма приступает к выполнению заказа.
На данный момент такая процедура сопровождения заказов не является оптимальной. Все операции по сопровождению заявки осуществляются в ручном режиме. С ростом объемов заказов увеличивается общее время на обработку заказов менеджером. Имеющаяся на данный момент процедура обработки и заключения заказов не имеет практически никакой автоматизации.
Менеджер помимо мероприятий по сопровождению заявок выполняет ряд других работ. Соответственно рассеивается внимание, необходим значительный промежуток времени для переключения на работы связанные с заказами. Так как заказы поступают в произвольные моменты времени, менеджеру приходится по нескольку раз переключаться с одной работы на другую, необходимо вспоминать детали каждого заказа, искать записанную ранее информацию по заказу в блокноте или другом источнике. И эти проблемы возникают только на стадии размещения и согласования заказа.
Ряд других проблем связан с формированием ответа. Для составления ответа на заказ уходит много времени. Необходимо найти позицию в прайсе фирмы, определить цену и вставить ее в ответ. После того как данный документ будет отослан заказчику, менеджеру необходимо проследить оплату заказа, а затем отдать команду на исполнение.
Клиенту фирмы очень проблематично отследить объем выполненных работ по своему заказу. Ему необходимо позвонить менеджеру, сказать какой заказ его интересует и хорошо, если у менеджера данная информация под рукой или в голове. В противном случае менеджеру необходимо время для выяснения статуса заказа и объема выполненных по нему работ. Это опять ведет к увеличению нагрузки на менеджера и выбивает его из спокойного ритма работы.
На предприятии также встречается проблема, когда заказ выполнен, а все сроки по его передачи заказчику прошли, по причине неявки заказчика в установленный срок, и товар может попросту испортиться.
Так как это муниципальное предприятие оно производит работы для муниципалитета. И опять-таки с информирование муниципальных руководителей о сроках, объемах работ могут возникать проблемы и накладки.
Данные проблемы мы попытаемся решить с помощью внедрения ИС для отдела заказов на данном предприятии.
Эта ИС является Internet системой, обеспечивающая высокий уровень качества обслуживания клиентов, обеспечивающая автоматический контроль выполнения сроков контракта.
В отличие от применяемых сейчас технологий и методов работы с заказами, наш продукт будет производить все необходимые действия по обеспечению высокого уровня сервиса.
В разрабатываемой ИС предполагается автоматизировать работу менеджера по работе с контрактами и клиентами (их заключение, сопровождение, расторжение), также предоставление новых возможностей клиентам фирмы (отслеживание статуса длительных и сложных заказов, быстрая связь с менеджером проекта, фирмы).
Данная система повысит качество сервиса для клиентов фирмы. Позволит менеджеру оперативно согласовывать заказы/контракты или заключать новые заказы. Пользователь получит возможность быстрого доступа к информации об услугах и товарах фирмы.
Система будет развернута на удаленном Web сервере. Со стороны фирмы в системе будет работать один менеджер, полное управление будет иметь администратор, также предусматривается возможность подключения к системе работников фирмы ответственных за изменение статуса проекта. Также со стороны фирмы заинтересованным лицом может выступать «бухгалтерия». Директору предприятия будет предоставлен доступ к статистике.
Другими непосредственными заинтересованными лицами в использовании данной ИС являются клиенты фирмы.
ИС будет обеспечивать выполнение функций по средствам интернета. Система должна работать круглосуточно. Иметь резервы в случае сбоев. Доступ в специальную часть системы осуществляется после авторизации и аутентификации лица, намеренного войти в защищенную зону.
Критичных данных на сервере хостинг компании храниться не должно. Вся личная информация на сервере БД должна быть доступна только компетентным пользователям. Все операции в системе должны протоколироваться и вестись их «Лог-файл». Должен обеспечиваться должный уровень секретности коммерческой информации, а также личной информации клиентов фирмы. Все значимые данные должны иметь возможность передаваться по защищенным каналам связи или с использованием защитных протоколов передачи данных. Достоверность предоставляемой клиентом фирмы информации проверяет менеджер фирмы.
Применение ИС для решения описанных выше проблем позволит ликвидировать некоторые проблемы, а также сведет к минимуму негативные последствия других проблем на предприятии.
Если затянуть с разработкой внедрением ИС, то невозможно будет увеличивать экономические показатели предприятия более высокими темпами.
Также если решать эти проблемы не в комплексе, а от случая к случаю, по мере жесткой необходимости в их решении, то процесс автоматизации отдела заказов затянется на неопределенный срок. При таком подходе к решению проблем, возможно появление новых проблем связанных с взаимодействием уже работающих (разработанных и запущенных) подсистем (программ), решающих конкретные узкие задачи. В итоге это приведет к переделке уже реализованных механизмов и созданию полноценной ИС.
Модели
Для преставления решения, имеет смысл привести ряд моделей частей системы в нотации UML 2.0, а также модель данных, основанную на методологии IDEF1x.
Для создания моделей в нотации UML 2.0 будет использовано CASE средство Telelogic Tau Modeler 3.1, а для модели данных по методологии IDEF1x – ERwin Data Modeler.
Модель данных
Выделим сущности, для которых необходимо хранить различную информацию.
Рисунок 1
На логической диаграмме представлены выделенные сущности и определены атрибуты данных сущностей. Также проставлены связи между взаимосвязанными сущностями.
Сущность «Клиент» имеет атрибуты id, для присваивания клиенту уникального идентификационного номера. Атрибуты «User», «pass» и «status» необходимы для авторизации и аутентификации пользователя в системе. Сущность «Подробнее» расширяет информацию о сущности «Клиент». В ней обозначены атрибуты для указания дополнительной информации.
Сущность «Заказы» и связанная с ней сущность «Описание» определяют атрибуты необходимые для описания заказов. Атрибут client_id и manag_id необходимы для связывания сущности «Заказы» с сущностями «Клиент» и «Менеджер». Сущность «rights» необходима для назначения прав и областей доступа для менеджера и администрации. Сущность «Администрация» и связанная с ней сущность «Описание» содержит атрибуты для описания администратора системы. Атрибуты«User», «pass» и «status» необходимы для авторизации и аутентификации пользователя в системе.
Сущность «Информация» хранит атрибуты, отвечающие за хранение информации о фирме ее услугах и координатах. Атрибут «visible» определяет видимость информации на сайте. Атрибут «url» назначает адрес для доступа к записи. Атрибут «date» хранит информацию о дате создания или обновления информации.
Сущность «Посетитель», хранит информацию о всех гостях зашедших на сайт. Хранит информацию о присвоенном им уникальном идентификаторе в атрибуте «sid». Также хранится информация о дате и времени посещения, данным гостем с уникальным идентификатором. Также имеется атрибут отвечающий за хранения дополнительной информации о госте.
Сущность «» и связанные с ним сущности «» и «» хранят заданные вопросы пользователей, клиентов и посетителей и имеющиеся на данные вопросы ответов менеджера.
Далее преобразуем полученную логическую модель к физической модели. Полученный результат представлен на рисунке 2.
Рисунок 2
Атрибутам сущностей установлен тип данных, и наложено ограничение по длине поля.
Модель системы в нотации UML 2.0
Диаграмма вариантов использования – описывает функциональное назначение системы в самом общем виде с точки зрения пользователей и заинтересованных лиц.
На рисунке 3 приведена диаграмма вариантов использования разрабатываемой системы. Данная диаграмма является рабочим вариантом. На данной диаграмме имеются служебный записи (комментарии), для дальнейшего развития данной модели.
Рисунок 3
На диаграмме представлены основные пользователи системы. Сущность «Клиент» является расширением сущности «Посетитель». Данным сущностям доступны такие варианты использования как: «Просмотреть информацию», «Отправить вопрос». У сущности «Клиент» есть дополнительный вариант использования: «Работать с заказом», расширяемый рядом других вариантов использования.
У менеджера фирмы имеется два варианта использования: «Управлять» и «Ответить на вопрос». Сущность «Администратор», несет на себе только функции по администрированию данной системы.
Клиент фирмы, работая с заказом, вносит в него изменения. Затем данные изменения должны быть согласованы с менеджером предприятия. Общедоступные варианты использования «Просмотреть информацию» и «Отправить вопрос», показывают возможность ознакомления с информацией о предприятии и его услугах сущностям «Посетитель» и «Клиент».