Оценка финансового состояния и деятельности предприятия
Министерство образования и науки Российской Федерации
Федеральное агентство по образованию
Южный Федеральный Университет
Государственное Образовательное учреждение
Высшего профессионального образования
Курсовая работа
на тему: «Анализ предметной области отдела заказов малого
предприятия»
по курсу «Пр.АСОИиУ 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.
Тема
работы.
|
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
Следовательно,
можно сделать предположение, что наш проект является выполнимым, так как
выделены все основные этапы, им установлены реальные сроки выполнения, и дата
окончания проекта является действительной.
В
процессе проделанной работы, я получил практический опыт по организации плана
работ над проектом. Ознакомился с 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.