Министерство образования и науки Российской Федерации
Федеральное агентство по образованию
Южный Федеральный Университет
Государственное Образовательное учреждение
Высшего профессионального образования
Курсовая работа
на тему: «Анализ предметной области отдела заказов малого предприятия»
по курсу «Пр.АСОИиУ 2»
2008 год
Оглавление
Введение
Основная часть
Модели
Модель данных
Модель системы в нотации UML 2.0
Иерархическая структура работ
Вывод
Список литературы
Введение
В данной работе необходимо будет разобраться с предметной областью, выявить проблемы, предоставить обзор решения данных проблем, создать модели данных и другие модели системы, решающей данные проблемы в предметной области. Также необходимо создать проект иерархической структуры работ.
Основная часть
Муниципальное предприятие города Армавира «Озеленитель» создано на базе тепличного комплекса в феврале 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
На диаграмме представлены основные пользователи системы. Сущность «Клиент» является расширением сущности «Посетитель». Данным сущностям доступны такие варианты использования как: «Просмотреть информацию», «Отправить вопрос». У сущности «Клиент» есть дополнительный вариант использования: «Работать с заказом», расширяемый рядом других вариантов использования.
У менеджера фирмы имеется два варианта использования: «Управлять» и «Ответить на вопрос». Сущность «Администратор», несет на себе только функции по администрированию данной системы.
Клиент фирмы, работая с заказом, вносит в него изменения. Затем данные изменения должны быть согласованы с менеджером предприятия. Общедоступные варианты использования «Просмотреть информацию» и «Отправить вопрос», показывают возможность ознакомления с информацией о предприятии и его услугах сущностям «Посетитель» и «Клиент».
Иерархическая структура работ
В данной работе необходимо построить план работ по подготовке и защиты на степень Бакалавра.
Примерный план работ приведен в таблице.
Таблица 1
| Название этапа | Срок |
| 1. Тема работы. | 6 |
| 1.1. Выбор темы | 2 |
| 1.2. Согласование темы с начальством (зав каф) | 2 |
| 1.3. Утверждение темы | 2 |
| 2. Определиться со списком существующих систем, решающих подобные задачи, определить их функционал. | 6 |
| 2.1. Выбрать 3 аналога | 1 |
| 2.2. Произвести их анализ | 2 |
| 2.3. Составить сводную таблицу | 3 |
| 3. Разобраться с требованиями к системе. | 18 |
| 3.1. Произвести системный анализ предметной области | 7 |
| 3.2. Бизнес-требование к системе | 3 |
| 3.3. Функциональные требования к системе | 5 |
| 3.4. Системные требования к системе | 3 |
| 4. Начать разработку моделей по UML 2.0. | 22 |
| 4.1. Уточнить модели, на основании реально функционирующей системы. | 5 |
| 4.2. Согласовать работы по моделям с руководителем проекта. | 2 |
| 4.3. Внести коррективы в имеющиеся модели на основании согласований со всеми заинтересованными лицами. | 5 |
| 4.4. Продолжить работу над моделями (увеличить уровень декомпозиции, дополнять модели, делая их более полными) | 10 |
| 5. Разработка приложения на основании полученной ранее информации. | 18 |
| 5.1. Создание ИС | 10 |
| 5.2. Внедрение ИС на предприятие | 8 |
| 6. Отчет по выполняемой работе | 27 |
| 6.1. Написание основных глав пояснительной записки | 8 |
| 6.2. Написание БЖ и ТЭО | 5 |
| 6.3. Согласование отчета с руководителем | 3 |
| 6.4. Доработка отчета | 7 |
| 6.5. Рецензирование | 3 |
| 6.6. Сдача пояснительной записки Рогозову | 1 |
| 7. Сдача на госкомиссии | 31 |
| 7.1. Подготовка к госам | 10 |
| 7.2. Сдача госов | 3 |
| 7.3. Подготовка к бакалавру | 15 |
| 7.4. Сдача бакалавра | 3 |
Теперь нам необходимо, используя CASE средство Microsoft Office Project 2003, создать проект в данном средстве.
Рисунок 4
На рисунке 4 представлены задачи, занесенные в проект, установлены их сроки. На рисунке 5 представлена диаграмма последовательности с обозначенными ресурсами. Система автоматически определяет дату начала и окончания каждой задачи. Необходимо только выставить дату начала и длительность рабочей недели.
Рисунок 5
Я выбрал пятидневную рабочую неделю и дату начало проекта – 04.02.2008. Окончание проекта намечено на 17.06.2008, что является приемлемым значением, для даты окончания проекта. Данная дата соответствует реальным срокам сдачи бакалаврской работы.
Следовательно, можно сделать предположение, что наш проект является выполнимым, так как выделены все основные этапы, им установлены реальные сроки выполнения, и дата окончания проекта является действительной.
Вывод
В процессе проделанной работы, я получил практический опыт по организации плана работ над проектом. Ознакомился с CASE средством которое помогает создать план работ по проекту, распределенный во времени. Ознакомился с методами управления временем по методологии PMI.
Проводя анализ предметной области, а также предлагая подход к решению проблем предметной области, я ознакомился с основными методами по созданию моделей в нотации UML и методологии IDEF1x. Получил практический опыт по созданию данных моделей, увидел и разобрался с нюансами и проблемами, возникающим в ходе создания моделей.
В ходе выполнения данной курсовой работы были получены результаты, которые можно использовать для написания бакалаврской работы. Построенный план работ дает нам представления о сроках подготовке к сдаче бакалаврской работы и сдаче промежуточных этапов.
Список литературы
1. Википедия. - Март 2008 r.. - http://ru.wikipedia.org/wiki/Заглавная_страница.
2. Верников Геннадий «Основы методологии IDEF1X»// Корпоративный менеджмент. - Апрель 2008 r.. - http://www.cfin.ru/vernikov/idef/idef1x.shtml.
3. Леоненков «UML 2.0». - Санкт-Петербург : БХВ-Петербург, 2007.