Проектирование web-сервиса шиномонтажной мастерской
Министерство
образования и науки Российской Федерации
Государственное
образовательное учреждение
высшего
профессионального образования
Югорский
государственный университет
Институт
(НОЦ) систем управления и информационных технологий
Кафедра
"Автоматизированные системы обработки информации и управления"
Курсовой
проект
Проектирование
web-сервиса шиномонтажной мастерской
Группа 1100
Студент: Козуб А.В.
Руководитель: Бурлуцкий В.В.
Ханты-Мансийск
2014 г.
Задание на курсовой проект
. ФИО студента: Козуб Александр Валерьевич
. Тема проекта: Проектирование web-сервиса шиномонтажной мастерской.
. Срок сдачи проекта на нормоконтроль: 05.12.2014
Срок сдачи проекта на проверку законченного проекта: 12.12.2014
. Исходные данные к проекту (организация, отрасль знаний, назначение
проектируемой АСОИУ, основные требования к разработке):
Автоматизируется работа шиномонтажной мастерской в части оказания услуг и
оформления заказа. Веб-сервис должен на основании выбранной услуги клиентом,
сформировать на его основе заявку и сопутствующие учетные и отчетные
документы.сервис должен быть доступен круглосуточно, семь дней в неделю. Доступ
к системе должен быть персонализирован. Защита web-сервиса должна
предусматривать ведение ролевой политики и журналирование действий
пользователей в системе. Необходимо обеспечить стабильную работу с сервисом до
ста пользователей одновременно. С системой должен поставляться необходимый
пакет сопроводительной документации.
. Содержание пояснительной записки по курсовому проекту (перечень
подлежащих разработке вопросов):
пояснительная записка по курсовому проекту включает в свой состав пять
глав:
введение, обследование объекта автоматизации, формирование требований,
эскизный проект, заключение.
Приложение к пояснительной записке включает:
диаграммы IDEF0, DFD, IDEF3, UML, план управления программным проектом,
техническое задание, отчет о проведенном инспектировании.
. Студент-инспектор: Серебряков Никита Андреевич
Аннотация
Объектом проектирования в курсовом проекте является автоматизация
процесса связанных с работой шиномонтажной мастерской.
Предмет проектирования - разработка web-сервиса шиномонтажной мастерской.
Пояснительная записка к курсовому проекту состоит из 6 глав.
В первой главе "Обследование объекта автоматизации" проводится
обзор проекта и делается вывод о целесообразности разработки.
Во второй главе "Анализ и выбор инструментальных средств
разработки" рассматриваются средства проектирования, управления
конфигурациями, разработки (IDE) и средства тестирования.
В третьей главе "Документация проекта" рассматривается
составление документации.
В четвёртой главе "Формирование требований" разрабатывается
техническое задание на создание программного продукта.
В пятой главе "Черновой эскиз" рассматривается графический
пользовательский интерфейс проекта.
В шестой главе "Эскизный проект" разрабатываются
предварительные проектные решения.
Пояснительная записка изложена на 47 страницах, включает 24 рисунка, 6
таблиц и 9 приложений. Список литературных источников содержит 8 наименований.
Содержание
Введение
.
Обследование объекта автоматизации
.1 Описание
объекта
.2 Матрица
проекций
.3 Модель
"AS-IS" по методологии IDEF0
.4 Модель
"AS-IS" по методологии DFD
.5 Модель
"AS-IS" по методологии IDEF3
.6
Предварительная оценка затрат
. Анализ и
выбор инструментальных средств разработки
.1 Средство
функционального моделирования
.2 Средство
объектно-ориентированного моделирования
.3 Выбор
языка программирования
.4 Выбор СУБД
.
Документация проекта
.1 Структура
документов
.2 План
управления конфигурациями
.3 План
управления проектом
.4 План
контроля качества
.
Формирование требований
.1
С-требования
.2
D-требования
. Черновой
эскиз
. Эскизный
проект
.1 Диаграмма
использования
.2 Диаграмма
деятельности для системы в целом
.3 Диаграмма
состояния для одного варианта использования
.4 Диаграммы
последовательности
.5 ER-модель
Заключение
Список
использованных источников
Приложение А
Приложение Б
Приложение В
Приложение Г
Приложение Д
Приложение Е
Приложение Ж
Приложение И
Приложение К
Введение
Управление организацией любого типа, будь то крупное предприятие или
мелкая фирма, связано с переработкой большого потока информации и принятием на
ее основе оперативных и перспективных решений. Поэтому автоматизация
управленческих работ является основным направлением совершенствования
экономики.
Внедрение информационных технологий во все сферы деятельности обусловлено
стремительным развитием науки, качественным скачком возможностей человека,
постоянно растущими объемами информации, сложностью происходящих процессов и
явлений. Не обошла стороной информатизация и сферу услуг.
Предоставление услуг через Интернет - это сложный, хозяйственный комплекс
с многочисленными внешними и внутренними связями. И управление шиномонтажной
мастерской, его информационными потоками, процессом выполнения услуг,
документооборотом и прочими процессами представляет собой сложную систему,
мелкие и крупные задачи которой тесно связаны между собой.
Система управления предоставления услуг должна представлять собой гибкую,
динамичную систему, позволяющую эффективно рассматривать намеченные планы,
оперативно учитывать все изменения и новые тенденции. Большие возможности для
совершенствования управления шиномонтажным сервисом предоставляет использование
вычислительной техники и средств связи. В настоящее время накоплен определённый
опыт разработки и внедрения автоматизированных систем управления различных
сервисов.
Практически все современные виды деятельности человека немыслимы без
использования современных информационных средств, компьютерных технологий.
Объектом автоматизации курсового проекта является работа сотрудников,
обслуживающих клиентов на шиномонтажной мастерской. Одной из основных задач
сотрудников предприятий такого рода является информирование клиентов о
техническом состоянии автомобильных колес, проведение тех или иных обследований
с ними. Сообщение клиенту проблем, способов их решения и суммы за обслуживание.
Целью данного курсового проекта является создание web-сервиса для
шиномонтажной мастерской.
Для достижения поставленной цели сформулированы и решены следующие
задачи:
- анализ информационных потоков, связанных с деятельностью
шиномонтажной мастерской;
- разработка моделей деятельности "как есть";
- разработка информационной модели данных;
- разработка технического задания на разработку web-сервиса.
Разрабатываемая автоматизированная система позволит:
- автоматизировать процесс регистрации, учета, обработки
документов;
- повысить скорость прохождения документа;
- оптимизировать хранение документов;
- сэкономить ресурсы, расходуемые на подготовку новых
документов;
- сократить время на поиск документа;
- повысить комфортность и снизить трудоемкость при работе с
документами для конечного пользователя.
1. Обследование объекта автоматизации
1.1 Описание
объекта
Объектом автоматизации является работа мастерской, занимающаяся
предоставлением услуг физическим и юридическим лицам. В число услуг входит:
шиномонтаж, балансировка, снятие/установка колес, протяжка болтов, чистка
колес, устранение проколов и боковых порезов, устранение грыж, ремонт камер.
Исследование объекта автоматизации приведено в структурно-функциональной
диаграмме с применением методологии IDEF0 приложения А. Исследование объекта
автоматизации во взаимодействии с другими подразделениями приведено в
структурно-функциональной диаграмме с применением методологии DFD приложения Б.
Основная задача сотрудников шиномонтажной мастерской обслуживание клиента
(предложение и оказание услуг).
.2 Матрица
проекций
Для наиболее полного обследования объекта автоматизации была составлена
таблица, включающая в себя перечень бизнес процессов согласно управленческому
циклу.
Таблица 1.2.1 - Бизнес процессы
|
Стадии управления
|
Бизнес-процессы
|
|
Сбор информации
|
1. Предоставление услуг
|
|
Принятие решения
|
2. Принятие решения об услугах
|
|
Реализация решения
|
3. Исполнение услуг
|
|
Учет
|
4. Оформление наряда выполненных работ
|
|
Контроль
|
5. Контроль временем выполнения услуг 6. Контроль
прайс-листа 7. Контроль внутрихозяйственных расчетов
|
|
Отчет
|
8. Составление отчета о клиентах 9. Составление отчета о
материалах 10. Составление отчета о выполненных услугах
|
1.3 Модель
"AS-IS" по методологии IDEF0
Модель "AS-IS" по методологии IDEF0 приведена в приложении А
[1]. Рассмотрим основные блоки данной системы.
Модель можно разбить на пять блоков: предоставление услуг, выполнение
услуг, оформление наряда выполненных работ, контроль услуг и отчетность.
Рассмотрим более подробно каждый из этих блоков.
В блоке предоставление услуг клиент подает заявку на выполнение услуги
(шиномонтаж, балансировка, устранение грыж, ремонт камер и др.). Далее
происходит подсчет стоимости выбранной услуги. На выходе данного блока
формируется заявка, содержащая вышеуказанные данные.
В блоке выполнение услуг происходит непосредственно проведение работ
согласно выбранных услуг. Сотрудник ведет поиск дефектов/неисправностей,
выбирает материал/инструменты для их устранения. При выполнение тех или иных
работ, сотрудник информирует клиента о статусе услуги.
По окончанию всех работ, рассчитывается конечная сумма которую необходимо
оплатить клиенту. Клиент и сотрудник, перед подписанием наряда выполненных
работ, проводят проверку и качество выполненных работ, в результате которого
либо будет сформирован наряд выполненных работ, либо заказ будет отправлен на
доработку в связи с невыполнением той или иной услуги (Рисунок А.5 -
декомпозиция блока "Оформление наряда выполненных работ").
На основании нарядов выполненных работ, директор шиномонтажной мастерской
ведет контроль за временем выполнения услуг, прайс-листа и внутрихозяйственных
расчетов. По необходимости редактирует график работы сотрудников, регулирует
цены в прайс-листе и следит за количеством материала на складе. При каких-либо
изменениях в услуге клиенту будет отправлено смс сообщение.
Все сведения о проделанных работах используются для создания отчетов. В
отчете о материалах имеются сведения о количестве на складе используемых
деталей, о докупке недостающих запчастей. Информацию о проделанной работе за
день можно получить в ежедневном отчете. Данные о клиентах которые когда-либо
пользовались услугами шиномонтажной мастерской находятся в отчете о клиентах.
1.4 Модель
"AS-IS" по методологии DFD
Модель по методологии DFD во многом похожа на модель IDEF0. Модель
приведена в приложении Б [2].
Система работает со следующими внешними сущностями: Клиент, Сотрудники
мастерской, Директор мастерской. Как видно на диаграмме, основные этапы
остались теми же, но добавились хранилища: БД Клиенты (данные о клиенте), БД
Мастеров (данные о сотрудниках), БД Заказ (сведения о заказе), БД Статус заказ
(состояние заказа), БД прайс-лист услуг (перечень услуг и их стоимость), БД
Материалов (материалы необходимые для выполнения работ).
Сначала клиент оставляет информацию о себе на сайте, для формирования
списка услуг, которые могут быть оказаны на шиномонтажной мастерской. Клиент
определяет услуги, после чего производится предварительный расчет стоимости
услуг, используя прайс-лист. По завершению расчетов система оповещает клиента о
стоимости услуг, после чего клиент может как отказаться от услуг, так и согласиться
если его удовлетворяет стоимость услуги (Рисунок Б.3).
Далее сотрудники проводят работы в соответствии с заказом. При
обнаружении дефектов/неисправностей происходит выбор материала/инструментов для
их устранения. При выполнение тех или иных работ сотрудник меняет статус
услуги.
Между блоками "Выполнение услуг" и "Оформление наряда
выполненных работ" существует обратная связь благодаря верификации
проделанной работы и конечного результата, при несоблюдении мастерской своих
обязательств перед клиентом, клиент в праве требовать отправки заказа на
доработку. Если верификация прошла успешно клиент и сотрудник оформляют наряд
выполненных работ (Рисунок Б.5).
При изменениях времени работ мастерской, клиенту отправляется смс
сообщение. В котором указаны разъяснения по какой причине были приняты эти
изменения.
Директор СТО получает различные отчеты с информацией, накопленной в
хранилищах. По результатам отчетов директор мастерской принимает управленческие
решения (Рисунок Б.7).
1.5 Модель
"AS-IS" по методологии IDEF3
Модель по методологии IDEF3 для первого уровня декомпозиции приведена в
приложении В. IDEF3 показывает причинно-следственные связи между ситуациями и
событиями, используя структурный метод выражения знаний о том, как
функционирует система, процесс или предприятие [3].
1.6
Предварительная оценка затрат
Таблица 1.6.1 - Сопоставление функций системы информационным
характеристикам и сложности
|
Функция системы
|
Информационная характеристика
|
Сложность
|
|
Ввод данных о клиенте
|
Внешний ввод
|
Ссылок на файлы - 1 Элементы данных - 5 Сложность низкая
(3)
|
|
Выбор услуг
|
Внешний ввод
|
Ссылок на файлы - 1 Элементы данных - >15 Сложность
средняя (4)
|
|
Подсчет стоимости услуг
|
Внешний запрос
|
Ссылок на файлы - 2 Элементы данных - 7 Сложность средняя
(4)
|
|
Вывод стоимости услуги для клиента
|
Внешний вывод
|
Ссылок на файлы - 1 Элементы данных - 8 Сложность низкая
(4)
|
|
Проведение работ согласно выбранной услуге
|
Внешний запрос
|
Ссылок на файлы - 2 Элементы данных - 7 Сложность средняя
(4)
|
|
Изменение прайс-листа
|
Внешний ввод
|
Ссылок на файлы - 1 Элементы данных - 7 Сложность низкая
(3)
|
|
Выбор материала для устранения дефектов/неисправностей
|
Внешний ввод
|
Ссылок на файлы - 1 Элементы данных - >15 Сложность
средняя (4)
|
|
Обнаружение дефектов/неисправностей
|
Внешний ввод
|
Ссылок на файлы - 2 Элементы данных - 8 Сложность средняя
(4)
|
|
Вычисление конечной суммы за услуги
|
Внешний запрос
|
Ссылок на файлы - 1 Элементы данных - 3 Сложность средняя
(4)
|
|
Верификация выполненной услуги
|
Внешний запрос
|
Ссылок на файлы - 1 Элементы данных - 4 Сложность низкая (3)
|
|
Формирование наряда выполненных работ
|
Внешний запрос
|
Ссылок на файлы - 1 Элементы данных - 4 Сложность низкая
(3)
|
|
Верификация выполненной услуги
|
Внешний запрос
|
Ссылок на файлы - 1 Элементы данных - 4 Сложность низкая
(3)
|
|
Контроль за временем выполнения услуг
|
Внешний запрос
|
Ссылок на файлы - 3 Элементы данных - 12 Сложность средняя
(4)
|
|
Изменение графика работы
|
Внешний ввод
|
Ссылок на файлы - 1 Элементы данных - 12 Сложность низкая
(3)
|
|
Контроль прайс-листа
|
Внешний запрос
|
Ссылок на файлы - 1 Элементы данных - 7 Сложность низкая
(3)
|
|
Изменение прайс-листа
|
Внешний ввод
|
Ссылок на файлы - 1 Элементы данных - 7 Сложность низкая
(3)
|
|
Контроль внутрихозяйственных расчетов
|
Внешний запрос
|
Ссылок на файлы - 2 Элементы данных - 10 Сложность средняя
(4)
|
|
Изменение внутрихозяйственных расчетов
|
Внешний ввод
|
Ссылок на файлы - 1 Элементы данных - 10 Сложность низкая
(3)
|
|
Оповещение клиента
|
Внешний вывод
|
Ссылок на файлы - 1 Элементы данных - 5 Сложность низкая
(4)
|
|
Составление отчета о материалах
|
Внешний вывод
|
Ссылок на файлы - 4 Элементы данных -19 Сложность высокая
(7)
|
|
Составление ежедневного отчета
|
Внешний вывод
|
Ссылок на файлы - 4 Элементы данных -19 Сложность высокая
(7)
|
|
Составление отчета о клиентах
|
Внешний вывод
|
Ссылок на файлы - 3 Элементы данных -12 Сложность средняя
(5)
|
Определение ранга и сложности, используемых внутренних логических и
внешних интерфейсных файлов, описаны в таблице 1.6.2.
Таблица 1.6.2 - Используемые внутренние логические файлы
|
Описание файла
|
Информационная характеристика
|
Сложность
|
|
БД Клиенты
|
Внутренний логический файл
|
Типы данных - 2. Элементы данных - 6 (ID, ФИО, Телефон,
Email, Пароль, Логин). Сложность низкая (7) .
|
|
БД Мастеров
|
Внутренний логический файл
|
Типы данных - 2. Элементы данных - 5 (ID, ФИО, Телефон,
Адрес, Должность). Сложность низкая (7).
|
|
БД Заказ
|
Внутренний логический файл
|
Типы данных - 2. Элементы данных - 4 (ID, ID_Статус_заказа,
Дата, ID_Клиент). Сложность низкая (7).
|
|
БД Статус заказа
|
Внутренний логический файл
|
Типы данных - 2. Элементы данных - 2 (ID, Название)
Сложность низкая (7).
|
|
БД Прайс-лист услуг
|
Внутренний логический файл
|
Типы данных - 3. Элементы данных - 5 (ID, Название_услуги,
Стоимость, Время_выполения, ID_Материалы). Сложность низкая (7).
|
|
БД Материалов
|
Внутренний логический файл
|
Типы данных - 2. Элементы данных - 3 (ID, Название,
Количество). Сложность низкая (7).
|
Для оценки затрат используется методология оценивания функционального
размера, которая заключается в единообразном измерении всех возможностей
приложения. Результатом является число, которое используется для определения
числа строк кода, стоимости и сроков проекта.
Таблица 1.6.3 -Информационные характеристики
|
Имя характеристики
|
Количество
|
|
Низкий
|
Средний
|
Высокий
|
Итого
|
|
Внешние вводы
|
5x3=15
|
3x4=12
|
0x6=0
|
27
|
|
Внешние выводы
|
2x4=8
|
1x5=5
|
2x6=12
|
25
|
|
Внешние запросы
|
4x3=12
|
5x4=20
|
0x6=0
|
32
|
|
Внутренние логические файлы
|
6x7=42
|
0x10=0
|
0x15=0
|
42
|
|
Внешние интерфейсные файлы
|
0x5=10
|
0x7=0
|
0x10=0
|
0
|
|
Общее количество
|
126
|
Для дальнейшего расчета функционального размера необходимо рассмотреть
системные параметры приложения, сведенные в таблицу 1.6.4.
шиномонтажный данные web сервис
Таблица 1.6.4 - Системные параметры приложения
|
№
|
Системный параметр
|
Описание
|
Значение
|
|
1
|
Передача данных
|
Сколько средств связи требуется для передачи или обмена
информацией с приложением или системой?
|
2
|
|
2
|
Распределенная обработка данных
|
Как обрабатываются распределенные данные и функции
обработки?
|
1
|
|
3
|
Производительность
|
Нуждается ли пользователь в фиксации времени ответа или
производительности?
|
1
|
|
4
|
Распространенность используемой конфигурации
|
Насколько распространена текущая аппаратная платформа, на
которой будет выполняться приложение?
|
3
|
|
5
|
Скорость транзакций
|
Как часто выполняются транзакции? (каждый день, каждую
неделю, каждый месяц)
|
3
|
|
6
|
Оперативный ввод данных
|
Какой процент информации надо вводить в режиме онлайн?
|
3
|
|
7
|
Эффективность работы конечного пользователя
|
Приложение проектировалось для обеспечения эффективной
работы конечного пользователя?
|
4
|
|
8
|
Оперативное обновление
|
Как много внутренних файлов обновляется в онлайновой транзакции?
|
3
|
|
9
|
Сложность обработки
|
Выполняет ли приложение интенсивную логическую или
математическую обработку?
|
1
|
|
10
|
Повторная используемость
|
Приложение разрабатывалось для удовлетворения требований
одного или многих пользователей?
|
4
|
|
11
|
Легкость инсталляции
|
Насколько трудны преобразование и инсталляция приложения?
|
2
|
|
12
|
Легкость эксплуатации
|
Насколько эффективны и/или автоматизированы процедуры
запуска, резервирования и восстановления?
|
2
|
|
13
|
Разнообразные условия размещения
|
Была ли спроектирована, разработана и поддержана
возможность инсталляции приложения в разных местах для различных организаций?
|
0
|
|
14
|
Простота изменений
|
Была ли спроектирована, разработана и поддержана в
приложении простота изменений?
|
1
|
Функциональный размер приложения рассчитан в следующей формуле:
, (1)
где 
- коэффициенты сложности, приведенные в таблице 4.
Для разработки приложения был выбран язык программирования Java, для
которого количество строк кода на одну единицу функционального размера равно
53. Следовательно, количество строк кода равно:
(2)
Т.к. рассматриваемый проект относится к распространённому типу (небольшие
программные проекты, над которыми работает небольшая группа разработчиков с
хорошим стажем работы, устанавливаются мягкие требования к проекту), то
коэффициенты для расчета уравнений базовой подмодели COCOMO равны: a=2.4,
b=1.05, c=2.5, d=0.38 [2]. Значит, соответствующие значения показателей равны:
[чел-мес] (3)
[мес] (4)
где E - затраты в человеко-месяцах, D - время разработки.
2. Анализ и выбор инструментальных средств разработки
2.1 Средство
функционального моделирования
Изучение любой системы предполагает создание модели системы, позволяющей
произвести анализ и предсказать ее поведение в определенном диапазоне условий,
решать задачи анализа и синтеза реальной системы. В зависимости от целей и
задач моделирования оно может проводиться на различных уровнях абстракции. В
курсовом проекте в качестве инструмента функционального моделирования был
выбран AllFusion Process Modeler 7 [5].
Возможности программы:
- поддерживает сразу три стандартные нотации - IDEF0 (функциональное
моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование
потоков работ);
- полностью поддерживает методы расчета себестоимости по объему
хозяйственной деятельности (функционально-стоимостной анализ, ABC);
- имеет широкий набор средств документирования моделей,
проектов.
- содержит собственный генератор отчётов;
- лёгок в освоении и применении;
- позволяет облегчить сертификацию на соответствие стандартам качества
ISO9000;
- позволяет эффективно манипулировать моделями;
- низкая стоимость, популярность, большое количество справочной информации
и компетентных специалистов;
2.2 Средство
объектно-ориентированного моделирования
Объектно-ориентированное проектирование - методология проектирования,
соединяющая в себе процесс объектной декомпозиции и приемы представления
логической, физической, а также статической и динамической моделей
проектируемой системы. В курсовой работе использовался язык UML - это
графический язык моделирования общего назначения, предназначенный для
спецификации, визуализации, проектирования и документирования всех артефактов,
создаваемых при разработке программных систем.
Для выбора инструмента объектного моделирования было проведено сравнение
популярных программных средств данной области. Результаты сравнения
представлены в таблице 2.2.1
Таблица 2.2.1 - Результат сравнения программных средств объектного
моделирования
|
Критерий/продукт
|
Microsoft Visio Professional
|
Sparx Enterprise Architect.
|
IBM Rational Rose Enterprise
Edition 7.0
|
IBM Rational Phapsody Modeler 7.5
Free
|
|
Поддержка UML
|
7
|
10
|
8
|
|
Проверка правильности UML диаграмм
|
0
|
0
|
3
|
2
|
|
Генерация исходных кодов по UML диаграмме
|
0
|
7
|
9
|
6
|
|
Поддержка процессов разработки
|
6
|
9
|
8
|
6
|
|
Проектирование БД
|
7
|
8
|
9
|
7
|
|
Поддерживаемые БД
|
9
|
10
|
10
|
5
|
|
Популярность
|
9
|
4
|
7
|
4
|
|
Удобство использования
|
9
|
8
|
9
|
6
|
|
Итого:
|
47
|
56
|
65
|
44
|
Из приведённой таблицы можно сделать вывод, что наилучшим выбором
средства объектного моделирования будет IBM Rational Rose Enterprise Edition
7.0 [6].
2.3 Выбор
языка программирования
Языком программирования web-сервиса был выбран Java.позволяет
разрабатывать высокопроизводительные портативные приложения практически на всех
компьютерных платформах. Доступность приложений в разнородных средах позволяет
компаниям предоставлять более широкий спектр услуг, способствует повышению
производительности, уровня взаимодействия и совместной работы конечных
пользователей и существенному снижению стоимости совместного владения
корпоративными и потребительскими приложениями [7].
Для разработки веб-приложений на языке Java используется свободная
интегрированная среда разработки приложений IDE NetBeans. IDE NetBeans
предельно упрощает создание проектов веб-приложений на основе Java EE с JSF 2.2
JSP. Кроме того, можно создавать и работать с веб-приложениями с помощью других
платформ. Редактор поддерживает автозавершение кода, переходы и реорганизацию
для сопоставления файлов. Кроме того, IDE можно легко настроить для работы с
другими платформами путем установки дополнительных подключаемых модулей,
получив их в центре обновлений после их появления [8].
2.4 Выбор
СУБД
В качестве системы управления базами данных была выбрана Microsoft SQL
Server. MSQL Server является надежной базой данных для любых целей, может
продолжать расширяться по мере наполнения информацией, без заметного уменьшения
быстродействия операций с записями в многопользовательском режиме. Пользователи
могут быть добавлены путем модернизации оборудования.
Обеспечивается максимальная безопасность. Ваши данные защищены от
несанкционированного доступа за счет интеграции сетевой безопасности с сервером
безопасности. Поскольку безопасность на уровне пользователя, пользователи могут
иметь ограниченный доступ к записи данных, тем самым защищая их от модификации
или поиска, указав доступ на уровне пользовательских привилегией. Кроме того, с
данными, хранящимися на отдельном сервере, сервер работает как шлюз, который
ограничивает несанкционированный доступ.
3. Документация проекта
3.1 Структура
документов
Прежде чем приступать к этапу формирования требований к системе,
необходимо определить и систематизировать нормативные документы, определяющие
основные понятия в области автоматизированных систем, устанавливающие термины и
определения, основные положения, общие требования, процессы жизненного цикла,
стадии создания АС.
Основными документами, на основе которых создаются автоматизированные
системы, являются:
- ГОСТ 34.003-90 "Информационная технология. Комплекс
стандартов на автоматизированные системы. Автоматизированные системы. Термины и
определения";
- ГОСТ 24.103-84 "Автоматизированные системы управления.
Основные положения";
- ГОСТ 24.104-85 "Автоматизированные системы управления.
Общие требования";
- ГОСТ Р ИСО/МЭК 12207-99 "Информационная технология.
Процессы жизненного цикла программных средств";
- ГОСТ 24.602-86 "Автоматизированные системы управления.
Состав и содержание работ по стадиям создания";
- ГОСТ 34.601-90 "Автоматизированные системы. Стадии
создания";
- ГОСТ 34.602-89 "Автоматизированные системы. Техническое
задание на создание автоматизированной системы".
Минимальный комплект документации, который необходимо разработать при
разработке любого проекта, включает в свой состав следующие основные документы:
·
план управления
конфигурациями программного обеспечения (Software Configuration Management Plan
- SCMP) в соответствии со стандартом IEEE 828-1990;
·
план контроля
качества программного обеспечения (Software Quality Assurance Plan - SQAP) в
соответствии со стандартом IEEE 730-1989;
·
план управления
программным проектом (Software Project Management Plan - SPMP) в соответствии
со стандартом IEEE 1058.1-1987;
·
техническое задание
(ТЗ) в соответствии со стандартом ГОСТ 34.602-89 (Приложение К);
Диаграмма, отображающая структуру нормативных документов, использованных
при подготовке проекта, представлена на рисунке 3.1.1.
Рисунок 3.1.1 - Структура нормативных документов
3.2 План
управления конфигурациями
Управление документацией программного проекта требует значительных
организационных навыков, поскольку документация крупного проекта представляет
собой сложноорганизованную систему документов с множеством перекрестных связей,
которая подвержена непрерывным изменениям в ходе выполнения проекта. Управление
документацией подразумевает поддержание ее полноты, согласованности и включает
в себя управление конфигурациями. Полнота документации обуславливается перечнем
стандартов, использованных при разработке проекта. Согласованность документации
означает, что набор документов не содержит внутренних противоречий. Обеспечение
непротиворечивости достигается за счет создания целостной документации, т.е.
такой документации, в которой каждая спецификация располагается только в одном
месте. Решение проблемы несогласованности возможно за счет использования
гипертекстовых документов с поддержкой перекрестных ссылок. Поддержка
конфигурации - это координация различных версий и частей документации и
программного кода. Для отслеживания частей проекта необходимо определить их
границы, т.е. ввести элементы конфигурации, под которыми, как правило, понимают
классы, значимые наборы данных, редко - отдельные функции. Существуют
специальные программные средства для управления конфигурацией (например,
Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server,
IBM Rational ClearCase, Subversion и др.) [3].разработал стандарт по
планированию управления конфигурациями - IEEE 828-1990. Результатом его
применения является план управления конфигурациями (SCMP - Software
Configuration Management Plan).
3.3 План
управления проектом
Управление проектом заключается в управлении производством продукта в
рамках отведенных средств и времени. Иными словами, управление проектом - это
достижение баланса между стоимостью, возможностями, качеством и сроками [4].
Важную роль в управлении программным проектом имеет определение рисков,
которые могут произойти в ходе разработки. Для данного проекта были выделены 3
риска.
Управление риском состоит из следующих действий:
- Идентификация риска заключается в фиксации всех факторов
беспокойства и озадаченности, связанных с проектом, а затем в обдумывании
других возможных опасений.
- Планирование устранения.
- Выбор приоритетов.
- Предупреждение рисков - это процесс, в ходе которого степень
рисков снижается или риски полностью устраняются. Имеются два способа
предупреждения рисков. Первый заключается во внесение изменений в требования
проекта, благодаря чему устраняется причина возникновения риска (избежание
риска). Другой способ - разработка неких технологий и архитектуры, решающих
проблему (устранение риска).
Риск №1 - отсутствие навыков программирования на языке Java. Принимая
этот факт, следует признать, что данный фактор серьезно затормозит проект, но
поскольку не все в проекте посвящено программированию, ущерб оценивается числом
7. Стоимость устранения риска высока, поскольку нужно затратить много времени
на обучение с отвлечением от работы.
Риск №2 - отсутствие стабильности в проведении собраний с заказчиком.
Еженедельные собрания являются основой качественной работы сотрудников.
Своевременные встречи позволяют на ранних стадиях выявить недочеты и полностью
сформулировать все требования к системе, что позволит сократить потери, как
времени, так и ресурсов.
Риск №3 - отсутствие базовых знаний работы Java и концепцию работы
веб-приложения в целом. Принимая этот факт, следует признать, что данный фактор
серьезно затормозит проект, так как для правильной работы АС необходимы знания
в выше описанных областях. Для устранения этого риска придётся прибегнуть к
помощи специалистов в данных областях.
3.4 План
контроля качества
В дополнение к ответственности индивидуальных разработчиков и проверкам
работ их коллег, организации определили процесс раздельной систематической и
полной проверки-контроль
качества. В функции контроля качества входят проверки, инспектирование и
тестирование. Контроль качества должен начинаться с запуска каждого проекта.
Лучше всего привлекать контроль качества и для проверки правильности
используемого процесса и актуальности документации [3].
4. Формирование требований
4.1
С-требования
В результате проведенного анализа были выдвинуты требования заказчика,
которые представлены в виде диаграммы use-case UML в приложении Г, а также
описаны ниже.
. Авторизация в системе
. Регистрация пользователей
. Ввод данных о клиенте
. Заявка на выполнение/отказ от услуг
. Выбор услуг
. Подсчет стоимости слуг
. Вывод стоимости услуг
. Проведение работ согласно выбранной услуге
. Выбор материала для устранения дефектов/неисправностей
. Обнаружение дефектов/неисправностей
. Вычисление конечной суммы за услуги
. Верификация выполненной услуги
. Формирование наряда выполненных работ
. Изменение статуса услуги
. Печать отчетов
. Контроль услуг
. Смс-оповещение
. Бэкап БД
. Журналирование
Интерфейс приложения должен быть интеллектуально понятен пользователю.
При входе в систему должна появиться форма авторизации, на которой должны быть
два текстовых поля, предназначенные для ввода в них логина и пароля. После того
как пользователь прошел аутентификацию, он попадает на личную страницу с
возможностью как выбора новой услуги, так и отказа от ранее выбранных.
4.2
D-требования
Разработчикам программного обеспечения нужна база для проектирования и
разработки. Эта база состоит из детальных требований. Их также называют
конкретными требованиями, функциональными спецификациями, требованиями
разработчиками или D-требованиями. D-требования состоят из полного списка
конкретных свойств и функциональности, которую должна иметь программа,
сформулированных в подробностях. D-требования должны быть согласованы с
С-требованиями.
Существуют несколько типов требований:
) функциональные требования - описаны в C-требованиях (См. 4.1
С-требования).
) Нефункциональные требования:
- производительность - программа должна мгновенно реагировать
на действия пользователя.
- надежность и безопасность - программа должна обеспечивать
надежность и секретность хранения и передачи информации.
- обработка ошибок - в случае ошибки программа должна
предложить пользователю отправить отчёт.
- интерфейсные требования - для связи с БД используется SQL
контроллер. SQL выбран как уникальное средство запросов к БД.
- ограничения - программа должна быть написана на Java. Это
позволит создать приложение, удовлетворяющее требованиям заказчика и временным
ограничениям.
) обратные требования:
Программа не должна формировать отчёты по управляющему персоналу.
. Черновой эскиз
Проектирование графического пользовательского интерфейса (ГПИ) в
настоящий момент представляет собой междисциплинарное направление, включающее в
свой состав аспекты дизайна, анализа требований, системного проектирования,
программирования, эргономики, социальной психологии и многие другие вопросы.
Для ГПИ при решении данной задачи нет необходимости подключать какие-то
специализированные графические библиотеки, достаточно средств HTML, CSS и
JavaScript.
На рисунке 5.1 представлен черновой эскиз ГПИ одной из страниц личного кабинета
директора.
Рисунок 5.1 - Печать отчетов, права доступа "Директор"
6. Эскизный проект
6.1 Диаграмма
использования
Диаграмма Use Case отражает все действия, используемые в информационной
системе. Диаграмма вариантов использования приведена в приложении Г.
6.2 Диаграмма
деятельности для системы в целом
Диаграммы деятельности (activity diagram) UML отражают управленческий
аспект реализации варианта использования и включают в свой состав деятельности,
состояния, решения, знаки синхронизации, а также переходы между ними. Диаграмма
деятельности для системы приведена в приложении Д.[1]
6.3 Диаграмма
состояния для одного варианта использования
В языке UML под состоянием понимается абстрактный метакласс, используемый
для моделирования отдельной ситуации, в течение которой имеет место выполнение
некоторого условия. Состояние может быть задано в виде набора конкретных
значений атрибутов класса или объекта, при этом изменение их отдельных значений
будет отражать изменение состояния моделируемого класса или объекта. Диаграмма
состояния для варианта использования "Формирование наряда выполненных
работ" приведена в приложении Ж.
6.4 Диаграммы
последовательности
Диаграммы последовательности (sequence diagram) UML отражают
коммуникационный аспект реализации варианта использования и включают в свой
состав объекты и сообщения между ними. Диаграммы последовательности приведены в
приложении Е.
6.5 ER-модель
Диаграммы классов (class diagram) UML отражают структурный аспект реализации
варианта использования и включают в свой состав классы, объекты, экземпляры, а
также связи между ними. ER-модель диаграммы классов приведена в приложении И.
Заключение
Данная курсовая работа посвящена проектированию web-сервиса шиномонтажной
мастерской на стадии работы с клиентом по приему заказов.
На сегодняшний день снижение времени принятия управленческих решений
является актуальным для руководителей организаций, так как это позволит
наиболее эффективно работать организации.
Клиент получает средство удобного просмотра данных об услуге и
самостоятельное формирование заказа с последующим получением наряда выполненных
работ. Сотрудник мастерской получает заказ в требуемой форме с возможностью
выбора.
Цель курсового проектирования заключается в создании проекта web-сервиса
для шиномонтажной мастерской.
Для достижения поставленной цели сформулированы и решены следующие
задачи:
- Выполнен анализ информационных потоков, связанных с
деятельностью организации.
- Разработаны и описаны модели деятельности "как
есть" в нотации IDEF0 (Приложение А), DFD (Приложение Б) и IDEF3
(Приложение В) которые представлены в функциональном моделировании.
- Разработано ТЗ на шиномонтажную мастерскую (Приложение К).
Данный проект решает такие проблемы как:
- Время и затраты на прием заказа - отпадает необходимость
личных визитов в мастерскую.
- Корректность данных - данные берутся из БД а не заполняются в
ручную, что влияет на работу сотрудников мастерской.
- Полнота данных об услуге - возможность просмотра цен и
полного описания на любою услугу.
Список
использованных источников
1. Новиков
Ф. Моделирование на UML / Ф. Новиков, Д. Иванов. - СПб.: Профессиональная
литература, Наука и Техника, 2010. - 640 с.
2. Перерва
А. Путь аналитика. Практическое руководство IT-специалиста / А. Перерва, В.
Иванова. - СПб.: Питер, 2012 - 304 с.
. Брауде
Э. Технология разработки программного обеспечения / Э. Брауде. - СПб.: Питер,
2004. - 655 с.
. Ройс
У. Управление проектами по созданию программного обеспечения. Унифицированный
подход / У. Ройс. - М.: Издательство "ЛОРИ", 1998. - 431 с.
. AllFusion
Process Modeler 7 (BPwin) - Программные продукты - Каталог ПО - Описания
продуктов: [Электронный ресурс]. Режим доступа: www.bpwin.ru/, свободный. -
Загл. Домашняя страница.
6. IBM
- Rational Rose Enterprise: [Электронный ресурс]. Режим доступа:
#"787396.files/image008.gif">
Рисунок А.1 - Диаграмма IDEF0 (AS-IS) верхнего уровня
Рисунок А.2 - Диаграмма IDEF0 (AS-IS) первого уровня
Рисунок А.3 - Диаграмма IDEF0 (AS-IS) второго уровня "Предоставление
услуг"
Рисунок А.4 - Диаграмма IDEF0 (AS-IS) второго уровня "Выполнение
услуг"
Рисунок А.5 - Диаграмма IDEF0 (AS-IS) второго уровня "Оформление
наряда выполненных работ"
Рисунок А.6 - Диаграмма IDEF0 (AS-IS) второго уровня "Контроль
услуг"
Рисунок А.7 - Диаграмма IDEF0 (AS-IS) второго уровня
"Отчетность"
Приложение Б
Функциональная диаграмма AS-IS модели по методологии DFD.
Рисунок Б.1 - Диаграмма DFD (AS-IS) верхнего уровня
Рисунок Б.2 - Диаграмма DFD (AS-IS) первого уровня
Рисунок Б.3 - Диаграмма DFD (AS-IS) второго уровня "Предоставление
услуг"
Рисунок Б.4 - Диаграмма DFD (AS-IS) второго уровня "Выполнение
услуг"
Рисунок Б.5 - Диаграмма DFD (AS-IS) второго уровня "Оформление
наряда выполненных работ"
Рисунок Б.6 - Диаграмма DFD (AS-IS) второго уровня "Контроль
услуг"
Рисунок Б.7 - Диаграмма DFD (AS-IS) второго уровня "Отчетность"
Приложение В
Функциональная диаграмма AS-IS модели по методологии IDEF3
Рисунок В.1 - Диаграмма IDEF3 (AS-IS) первого уровня
Приложение Г
Диаграмма вариантов использования UML
Рисунок Г.1 - Диаграмма использования Use Case
Приложение Д
Рисунок Д.1 - Диаграмма деятельности UML
Приложение Е
Диаграммы последовательностей UML
Рисунок Е.1 - Диаграмма последовательности для варианта использования
"Авторизация"
Рисунок Е.2 - Диаграмма последовательности для варианта использования
"Формирование наряда выполненных работ"
Рисунок Е.3 - Диаграмма последовательности для варианта использования "Формирование
ежедневного отчета"
Приложение Ж
Диаграмма состояний UML
Рисунок Ж.1 - Диаграмма состояний для варианта использования
"Формирование наряда выполненных работ"
Приложение И
Диаграмма классов UML
Рисунок И.1 - ER-диаграмма
Приложение К
Техническое задание
. Общие сведения
Данное техническое задание описывает создание web-сервиса шиномонтажной
мастерской обеспечивающая выполнение услуг, по принятым заявкам, информирование
клиента о статусе услуге, формирования отчет для управления.
Система создается на основании экспресс-обследования и задания на
курсовой проект.
Сроки проведения работ: Сентябрь 2014 г. - Декабрь 2014 г.
. Назначение и цели создания системы
.1. Назначение системы
) Авторизация клиентов и сотрудников, предоставление им интерфейса
взаимодействия с системой;
) регистрирование и добавление клиентов;
) обслуживание клиентов без непосредственного участия сотрудников;
) информирование клиентов о состоянии услуги;
) изменение статуса услуги сотрудниками;
) формирование отчетов и нарядов выполненных работ;
.2) Цели создания системы
) Повышение эффективности документооборота на шиномонтажной мастерской;
) Использования передовых технологий взаимодействия с пользовательскими
интерфейсами системы;
) возможности ведения истории заказов от клиентов с целью анализа
статистики высокопоставленными лицами мастерской, и облегчение принятие
управленческих решений на основании этих данных,
) сокращения времени поиска сотрудником требуемых форм для
документов (наряд выполненных работ);
) сокращения времени на заполнение документов и минимизации ошибок
при их заполнении;
) систематизации хранения и учета заказов от клиентов;
Характеристика объекта автоматизации
Объектом автоматизации является деятельность отдела по работе с
клиентами.
. Требования к системе
.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию системы
1) система должна функционировать 24 часа в сутки;
) система должна функционировать в режимах, которые определяются
аутентификацией пользователя:
- режим клиента: информирование клиента, внесение своих данных,
выбор услуг;
- режим сотрудника: выбор услуг для работы, изменение статуса
услуги, формирование наряда выполненных работ;
- режим администрации: формирование отчетов о деятельности
учреждения;
- режим администратора: добавление пользователей, возможность
выполнения работ, связанных с другими режимами, управление БД.
) система должна быть расширяемой в контексте создания отчетной документации.
4.1.2 Требования к численности и квалификации персонала системы и режиму
его работы
1) Клиент - базовые знания ПК, умение пользоваться любым
интернет-браузером, знание правил использования системы.
) Администратор - опыт в настройке интерфейсных приложений,
работающих с базой данных; знание руководства пользователя и руководства
системного администратора, опыт работы с CMF, построенных на архитектурном
шаблоне MVC.
4.1.3 Показатели назначения
Должно достигаться изменение следующих показателей:
) количество хранимых записей в таблицах базы данных (до 300
тыс.);
) формат вывода отчетов.
4.2 Требования к функциям (задачам), выполняемым системой
4.2.1 Перечень функций, задач, подлежащих автоматизации
1) подсчет стоимости услуг;
2) формирование и печать наряда выполненных работ;
) изменение прайс-листа/графика работы/внутрихозяйственных
расчетов;
) формирование и печать отчетов;
4.2.2 Требования к форме представления выходной информации
1) выходная информация представляется в виде таблиц представленных в
виде html-тегов;
) таблицы должны иметь возможность экспортироваться в документ
Word, Excel, CSV;
4.2.3 Перечень отказов системы
1) сбои в работе используемой СУБД;
) неисправность в аппаратных средствах;
4.3 Требования к видам обеспечения
4.3.1 Требования к информационному обеспечению системы
1) все данные пользователей организованы в таблицы и хранятся в базе
данных;
4.3.2 Требования к лингвистическому обеспечению
Используется язык программирования Java.
4.3.3 Требования к программному обеспечению
1) информационная система должна функционировать под одной из ниже
перечисленных операционных систем: Windows 2008 Server R2, Linux, FreeBSD,
Unix, Ubuntu, данный выбор обусловлен требованиями к высокий совместимости
системы.
) на персональных компьютерах пользователей должен быть доступ в
Интернет.
4.3.4 Требования к техническому обеспечению
Рабочее место пользователя (Минимальные требования):
- клавиатура, мышь;
- монитор;
- материнская плата;
- жесткий диск;
- процессор AMD/Intel с тактовой частотой не менее 1000 МГц;
- видеокарта с объемом видеопамяти не менее 128 Мб;
- оперативная память не менее 512 Мб;
- сетевая плата.
1. Состав и содержание работ по содержанию системы
1.1. Перечень стадий работ по созданию системы
1) формирование требований к АС;
) разработка концепции АС;
) разработка технического задания;
) создание эскизного проекта.
. Порядок контроля и приемки системы
Промежуточный контроль над ходом проектирования web-сервиса
осуществляется научным руководителем проекта еженедельно на протяжении всего
периода разработки системы.
Прием проекта будет произведен руководителем проектирования.
. Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие
Не обозначены
. Требования к документированию
Перечень подлежащих разработке комплектов и видов документов:
) план управления конфигурациями программного обеспечения;
) план контроля качества программного обеспечения;
) план управления программным проектом;
) спецификация требований к программному обеспечению;
) техническое задание;
) проектная документация программного обеспечения.
. Источники разработки
Документы и информационные материалы, на основании которых
разрабатывалось ТЗ и которые должны быть использованы при создании системы:
) ГОСТ 34.602-89 "Техническое задание на создание АС";
) задание на курсовой проект;
) план управления конфигурациями программного обеспечения;
) план контроля качества программного обеспечения;
) план управления программным проектом;
) спецификация требований к программному обеспечению;
) проектная документация программного обеспечения.