Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Управление заявками на техническое обслуживание» с помощью UML (Предлагаемые мероприятия по улучшению технологии решения задачи)

Содержание:

ВВЕДЕНИЕ

Актуальность работы. В настоящее время в России, как и во всем цивилизованном мире, наблюдается тенденция насыщения предоставляемыми услугами практически всего рынка, поэтому компаниям на рынке предоставления услуг приходится осуществлять свою деятельность в условиях жесткой конкуренции. Это приводит к пониманию исключительной роли совершенствования коммерческой деятельности компаний, которые нацелены на максимизацию выручки от предоставления услуг. Услуга, оказанная компанией, должна быть оптимальным образом выполнена: то есть, с учетом всех предпочтений и пожеланий заказчиков, и с получением наибольшей выгоды. Поэтому главная задача любого хозяйствующего субъекта – идеальным образом совместить желания заказчиков и собственные возможности. Именно поэтому система предоставления услуг является центральной в организации коммерческой деятельности в предприятии.

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

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

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

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

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

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

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

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Описание предметной области. Постановка задачи

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

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

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

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

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

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

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

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

1.2. Предлагаемые мероприятия по улучшению технологии решения задачи

В работе рассматривается задача по обработке заявок клиента на проведение технического обслуживания^[2]. Технология решения этой задачи предполагает, что внешний пользователь передаёт свою заявку, которая уточняется, фиксируется и классифицируется менеджером и передаётся на исполнение ответственному сотруднику службы технического обслуживания. Показателем данного процесса будет «Скорость обработки заявки» – среднее время, прошедшее от получения заявления до получения задачи исполнителем. Сейчас это время составляет 40 минут.

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

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

2. ПРОЕКТНАЯ ЧАСТЬ

2.1 Выбор средства для моделирования предметной области решаемой задачи

Для решения этой задачи могут быть использованы различные модели и технологии системного проектирования. Технология проектирования экономической информационной системы – это совокупность методологии и средств проектирования информационной системы, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта информационной системы)^[3].

Существует три вида технологий проектирования:

Технология оригинального проектирования (ТОП) основана на принципе создания уникального проектного решения для сложной экономической системы. ТОП поддерживает 3 группы методов, которые сложились в результате проектирования большого количества систем:

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

Технология типового проектирования (ТТП), основным принципом которой является разбиение существующей системы на типовые модули (задачи, подразделения, системы), которые позволяют их компоновать в проекты для всей системы путем настройки типовых проектных решений и разработки оригинальных недостающих модулей. В зависимости от объекта типизации выделяют 3 типа методов ТТП:

метод элементного проектирования;
метод подсистемного проектирования;
метод системного проектирования.

Технология автоматизированного проектирования (АП).

RAD (Rapid Application Development –– Быстрая разработка приложений) – подход к разработке приложений, предусматривающий широкое использование готовых компонентов и/или приложений и пакетов. RAD – это комплекс специальных инструментальных средств быстрой разработки прикладных информационных систем, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений^[4].

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

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

В настоящее время применяются на практике:

- СУБД, поддерживающие реляционную модель данных 1971 года с некоторыми расширениями;

- Иерархическая "каскадная" схема структурного проектирования БД при подходе "сверху-вниз";

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

- Утилиты динамического администрирования БД.

В России для моделирования и анализа бизнес-процессов достаточно широко используются следующие средства моделирования^[6]: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer.

Сравним функционал этих систем по пяти показателям:

устойчивое положение продукта на рынке (Показатель 1);
распространенность продукта (Показатель 2);
доступность поддержки поставщика (Показатель 3);
доступность обучения (Показатель 4);
доступность материалов по продукту (Показатель 5).

Применим метод вариантных сравнений и оценим каждый параметр по 5-балльной системе, результаты представлены в таблице 1.

Таблица 1. Результат системного сравнения средств проектирования

№ п/п	Наименование средства проектирования	Показатели					Полученная сумма баллов
№ п/п	Наименование средства проектирования	1	2	3	4	5	Полученная сумма баллов
1	Rational Rose	5	5	4	5	5	24
2	Oracle Designer	5	4	4	4	4	21
3	AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin)	5	5	4	5	5	24
4	ARIS	5	4	4	4	4	21
5	Power Designer	4	3	4	5	4	20

Анализ данных, представленных в таблице 1, позволил в качестве средства проектирования выбрать унифицированный язык моделирования UML. В качестве средства разработки и анализа бизнес-процессов используется программный пакет Rational Rose, который позволяет анализировать требования к бизнес-системе, с помощью различных видов диаграмм, моделировать состояния, генерировать код.

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

- анализ бизнеса;

- анализ стратегии развития бизнеса;

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

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

- выбор стратегии автоматизации:

- определение архитектуры;

- формирование бизнес-плана.

Различают следующие виды стратегий автоматизации:

- полная;

- по направлениям;

- по участкам;

- хаотичная.

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

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

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

Таким образом, в качестве стратегии автоматизации выбран проект автоматизации по участкам.

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

- покупка готового программного продукта;

- покупка и доработка программного продукта под цели рассматриваемой организации;

- взять в аренду, существующую программную систему;

- самостоятельная разработка.

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

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

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Моделирование предметной области включает в себя разработку в программной среде Rational Rose следующих схем предметной области управления заявками на техническое обслуживание:

диаграмма вариантов использования (диаграмма прецедентов)
диаграмма последовательности
диаграмма состояний
диаграмма деятельности
диаграмма классов

Диаграмма вариантов использования (диаграмма прецедентов) для рассматриваемой предметной области представлена на рис.1. Эта диаграмма в UML отражает отношения между акторами и прецедентами и позволяет описать систему на концептуальном уровне^[7].

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

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

Основными прецендентами в системе являются (рис.1):

- сделать заявку;

- уточнить заявку;

- оплатить услуги;

- планировать работу;

- фиксировать выполнение;

- фиксировать заявку;

- консультировать;

- выполнить работы;

- формировать счет.

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

Рисунок 2. Диаграмма последовательности управления заявками на техническое обслуживание

В соответствии с диаграммой последовательности (рис.3), выполняются следующие преценденты.

Клиент делает заявку на сайте предприятия (активность 1).
Менеджер получает заявку на сайте предприятия (активность 2).
Менеджер уточняет заявку у Клиента. (активность 3).
Менеджер фиксирует заявку (активность 4).
Менеджер включает заявку в план работ (активность 5).
Специалист технического обслуживания получает план работ (активность 6).
Специалист технического обслуживания выполняет ремонт и консультации (активность 7).
Специалист технического обслуживания формирует счет (активность 8).
Специалист технического обслуживания фиксирует выполнение работ (активность 9).
Клиент выполняет оплату счета за предоставленные услуги технического обслуживания (активность 10).

После получения оплаты объект заявка перестает свое существование.

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

Рисунок 3. Диаграмма состояний при управлении заявками на техническое обслуживание

Начало работы системы управления заявками на техническое обслуживание вызывает «Ожидание заявки» (рис.3). При отсутствии заявок система перейдет в конечное состояние.

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

После фиксирования заявки система переходит в состояние «Ожидание включения в план работ». После наступления события «Работа в плане» система находится в состоянии «Проверка типа обслуживания».

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

В случае определения типа «Технические работы» выполняется состояние «Обработка заявки на техническое обслуживания». Наступление события «Работа выполнена» переводит в состояние «Ожидание окончания работ», а после выполнения события «Работа закончена» переводится в состояние «Ожидание счета».

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

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

Рисунок 4. Диаграмма деятельности при управлении заявками на техническое обслуживание

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

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

Дальнейшие действие «Контроль оплаты» выполняет Менеджер, которое характеризуется состоянием «Квитанция получена». Процесс управления завершается действием на сайте «Фиксация выполнения».

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

Описания основных атрибутов и методов классов представлены в таблицах 2–3.

Рисунок 5. Диаграмма классов для управления заявками на техническое обслуживание

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

№ п/п	Класс	Атрибуты	Тип	Назначение
1	Должность	Наименование	Символьное	Для обозначения должности сотрудника предприятия
2	Сотрудник	Фамилия	Символьное	Фамилия сотрудника
3	Сотрудник	Имя	Символьное	Имя сотрудника
4	Сотрудник	Дата рождения	Символьное	Дата рождения сотрудника
5	Счет	№ счета	Целое	Номер выписанного счета специалистом технического обслуживания
6	Счет	Сумма	Целое	Сумма, выставленная для оплаты клиенту
7	Счет	дата	Дата/время	Дата формирования счета клиенту
8	Клиенты	Фамилия	Символьное	Фамилия клиента
9	Клиенты	Имя	Символьное	Имя Клиента
10	Клиенты	№ договора	Целое	№ договора о предоставлении услуг
11	Клиенты	Адрес	Символьное	Адрес нахождения клиента
12	Заявка	Номер	Целое	Номер заявки в системе
13	Заявка	Описание	Символьное	Описание технической неисправности
14	Заявка	Дата/время	Дата/время	Дата /время формирования заявки
15	Заявка	флаг фиксирования	Логическое	Флаг фиксирования заявки в системе
16	Заявка	флаг выполнения	Логическое	Флаг фиксирования выполнения заявки в системе
17	План работы	Дата	Дата/время	Текущая дата выполнения заявки
18	План работы	Номер заявки	Целое	Номер заявки в системе
19	План работы	время	Дата/время	Время на которое спланировано выполнение заявки
20	План работы	Сотрудник	Символьное	Сотрудник службы технического обслуживания, который будет выполнять заявку
21	План работы	Примечание	Символьное	Примечание к выполнению заявки
22	План работы	№ пункта	Целое	№ пункта плана работы сотрудника

Таблица 2 (Продолжение). Основные атрибуты классов для управления заявками на техническое обслуживание

№ п/п	Класс	Атрибуты	Тип	Назначение
23	Выполнение	№ заявки	Целое	Номер заявки в системе управления
24	Выполнение	Дата/время	Дата /время	Дата /время выполнения заявки
25	Выполнение	Примечание	Символьное	Примечание к выполнению заявки
26	Квитанция	№	Целое	№ квитанции об оплате
27	Квитанция	Дата	Дата/время	Дата совершения транзакции
28	Квитанция	Сумма	Целое	Сумма, оплаченная по квитанции
29	Квитанция	№ заявки	Целое	№ заявки, согласно которой осуществлялся платеж
30	Квитанция	клиент	Символьное	Клиент совершивший оплату
31	Вид заявки	тип	Перечисляемый	Перечисляемый тип заявки может принимать значение «Консультация», «Техническое обслуживание»

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

№ п/п	Класс	Метод	Назначение
1	Должность	AddDolgnost	Добавить должность сотрудника
2	Должность	Remove()	Модифицировать должность
3	Должность	Delete()	Удалить должность
4	Сотрудник	AddSotrudnyk	Добавить сотрудника
5	Сотрудник	RemoveSotrudnyk	Удалить сотрудника
6	Сотрудник	GetSotrudnyk	Выдать информацию о сотруднике
7	Сотрудник	GetAllSotrudnyk	Выдать информацию о всех сотрудниках
8	Счет	add()	Создать счет
9	Счет	modify()	Модифицировать счет
10	Счет	delete()	Удалить счет
11	Клиент	add()	Создать клиента
12	Клиент	modify()	Модифицировать сведения о клиентах

Таблица 3 (Продолжение). Основные методы классов для управления заявками на техническое обслуживание

№ п/п	Класс	Метод	Назначение
13	Клиент	delete()	Удалить сведения о клиентах
14	Заявка	delete()	Удалить заявку
15	Заявка	add()	Создать заявку
16	План работы	add()	Создать пункт плана работ
17	План работы	modify()	Модифицировать пункт плана работ
18	План работы	delete()	Удалить пункт плана
19	Выполнение	add()	Создать выполнение
20	Выполнение	modify()	Модифицировать сведения о выполнении

Основные зависимости классов, которые были идентифицированы в результате моделирования представлены в таблице 4.

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

№ п/п	Класс	Класс	Тип	Назначение
1	Должность	Сотрудник	M:1	1 сотрудник может занимать несколько должностей
2	Клиент	Заявка	1:М	1 клиент может создавать несколько заявок
3	Заявка	Вид	1:2	Заявки могут быть двух типов
4	План работ	Заявка	1:М	В плане работ могут быть M заявок
5	Выполнение	Счет	1:1	Выполнению работ соответствует один счет
6	Выполнение	Квитанция	1:1	Выполнению работ соответствует одна квитанция
7	План работ	Выполнение	1:1	Пункту лана работ соответствует 1 «выполнение»

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

ЗАКЛЮЧЕНИЕ

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

В соответствии с заданием на курсовое проектирование и достижением цели работы, были решены основные частные задачи курсовой работы:

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

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

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

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

При моделировании процессов в рассматриваемой предметной области были построены следующие диаграммы:

диаграмма вариантов использования (диаграмма прецедентов)
диаграмма последовательности
диаграмма состояний
диаграмма деятельности
диаграмма классов

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

СПИСОК ЛИТЕРАТУРЫ

Бертяков А. Автоматизация документооборота. Финансы и статистика, 2010. – 265 с.
Вендров А. / CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 2005.
Грэйди Буч, Джеймс Рамбо, Айвар Джекобсон / Язык UML. Руководство пользователя: Пер. с англ. Слинкин А. А. – 2-ое изд., стер. – М.: ДМК «Пресс»; СПБ.: Питер, 2006 – 432 с.: ил.
Демин, Ю.М. Информационные системы. Документационный менеджмент / Ю.М. Демин. - М.: Бератор, 2009. – 156с.
Емельянова Н.З. Основы построения автоматизированных информационных систем. / Н.З Емельянов, Т.Л. Партыка, И.И. Попов. – М.: Инфра – М, 2010. – 365 с.
Емельянова Н.З. Основы построения автоматизированных информационных систем. / Н.З Емельянов, Т.Л. Партыка, И.И. Попов. – М.: Инфра – М, 2010. – 365 с.
Ивашко А.Г., Григорьев М.В., Коломиец И.И. Проектирование информационных систем: Учебно-методическое пособие. Тюмень: Издательство Тюменского государственного университета, 2007. – 328с.
Лешек А. Анализ требований и проектирования систем. Разработка информационных систем с использованием UML/А.Лешек. – М.: Вильямс,2002. – 405 с.
Маклафлин, Б. Объектно-ориентированный анализ и проектирование / Б. Маклафлин. - СПб.: Питер, 2013. - 608 c.
Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. - СПб.: БХВ-Петербург, 2009. - 528 c.
Просветов Г. И. Управление в сфере услуг: задачи решения. Учебно-практическое пособие. - М.: Издательство «Альфа-пресс», 2009. -184с.
Технологии организации, хранения и обработки данных: Е. А. Левчук — СПб.: «Вышэйшая школа», 2005 г.- 240 с.
Титоренко Г.А. Информационные системы в экономике: учебник. 2-е изд., перераб. и доп. М.: ЮНИТИДАНА, 2008. 463 с.
Фатрелл Р., Шафер Д. Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. М.: «Вильямс», 2003. – 1128 с.

1. Просветов Г. И. Управление в сфере услуг: задачи решения. Учебно-практическое пособие. - М.: Издательство «Альфа-пресс», 2009. -184с.
↑
Вендров А. / CASE-технологии. Современные методы и средства проектирования информационных систем . – М .: Финансы и статистика, 2005 ↑
1. Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. - СПб.: БХВ-Петербург, 2009. - 528 c.
↑
1. Маклафлин, Б. Объектно-ориентированный анализ и проектирование / Б. Маклафлин. - СПб.: Питер, 2013. - 608 c.
↑
Фатрелл Р., Шафер Д. Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. М.: «Вильямс», 2003. – 1128 с. ↑
1. Лешек А. Анализ требований и проектирования систем. Разработка информационных систем с использованием UML/А.Лешек. – М.: Вильямс,2002. – 405 с.
↑
1. Грэйди Буч, Джеймс Рамбо, Айвар Джекобсон / Язык UML. Руководство пользователя: Пер. с англ. Слинкин А. А. – 2-ое изд., стер. – М.: ДМК «Пресс»; СПБ.: Питер, 2006 – 432 с.: ил.
↑
Фатрелл Р., Шафер Д. Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. М.: «Вильямс», 2003. – 1128 с. ↑