Файл: Проектирование бизнес-процесса «Обеспечение послепродажного обслуживания».pdf
Добавлен: 18.06.2023
Просмотров: 152
Скачиваний: 3
СОДЕРЖАНИЕ
1.1. Выбор комплекса задач автоматизации
1.2. Характеристика существующих бизнес-процессов
1.3. Характеристика документооборота, возникающего при решении задачи
1.4. Обоснование проектных решений по информационному обеспечению
1.5. Обоснование проектных решений по программному обеспечению
2.1. Информационная модель и её описание
2.2. Характеристика нормативно-справочной, входной и оперативной информации
2.3. Характеристика результатной информации
2.4. Общие положения (дерево функций и сценарий диалога)
2.5. Характеристика базы данных
Оценка производительности производится методом тестирования с помощью эталонных тестов из набора AS3AP (ANSI SQL Standard Scalable and Portable). В них контролируется широкий спектр часто встречающихся операций БД и моделируются однопользовательские и многопользовательские среды.
Глава 2. Проектная часть
2.1. Информационная модель и её описание
Информационная система может быть определена с технической точки зрения как набор взаимосвязанных компонентов, которые собирают, обрабатывают, запасают и распределяют информацию, чтобы поддержать принятие решений и управление в организации. В дополнение к поддержке принятия решений, координации и управлению информационные системы могут также помогать менеджерам проводить анализ проблемы, делают видимыми комплексные объекты и создают новые изделия[7].
Информационные системы содержат информацию о значительных людях, местах и объектах внутри организации или в окружающей среде. Информацией мы называем данные, преобразованные в форму, которая является значимой и полезной для людей. Данные, напротив, являются потоками сырых фактов, представляющих результаты, встречающиеся в организациях или физической среде прежде, чем они были организованы и преобразованы в форму, которую люди могут понимать и использовать.
Основу деятельности любой организации составляют ее деловые процессы или бизнес-процессы, которые определяются целями и задачами организации. Каждый бизнес-процесс характеризуется четко определенными во времени началом и концом. Для каждой работы, входящей в бизнес-процесс, определены временные характеристики, определяющие ее место в общей последовательности работ. Описание деятельности организации с помощью бизнес-процессов позволяет определить где, когда и кем выполняется каждая функция, какие данные, информационные или функциональные взаимосвязи для этого нужны и откуда эти данные поступают. Цель этапа информационного моделирования состоит в том, чтобы идентифицировать концептуальные сущности, или объекты, которые составляют подсистему для анализа. Объекты информационной модели представляются через их имена и имена их атрибутов. Здесь устанавливаются связи между информационными объектами и функциональные зависимости. Кроме структурной направленности информационное моделирование связанно с особенностями реализации связей в различных компьютерных технологиях, в зависимости от количества связываемых предметов. Для успешной реализации проекта объект проектирования должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
Информационная модель комплекса задач служит для отображения взаимосвязи входных, промежуточных, а также результатных информационных потоков, функций предметной области и файлов с условно-постоянной информацией.
Ниже на рис. 8 приведена подробная информационная модель рассматриваемого комплекса задач.
Рисунок 8. Информационная модель
Область 1 отображает процесс конфигурирования ИС в части ввода пользователей ИС, которые необходимы в рамках задачи для того, чтобы можно было зафиксировать информацию о пользователях (клиентах). Форма «Управление пользователями» предполагает выполнение двух видов операций:
- редактирование справочника объекты;
- редактирование справочника пользователей.
Область 2 отображает то, что из базы ИС в рамках моделируемой задачи используются три справочника и две таблицы. (Под справочником мы понимаем обычную таблицу, которая содержит условно-постоянную информацию).
Область 3 отображает собственно процесс обработки событий. Проектировщики предполагают, что ввод будет состоять из следующих этапов:
- сначала делается запись (либо производится обновление записи) в справочнике пользователя. Под пользователем понимается ФИО клиента и какие-либо его данные (например паспортные данные).
- затем делается запись, отражающая факт совершения события. В рамках задачи предполагается два варианта его совершения:
- включилась аварийная кнопка;
- произошло блокирование.
- в любом случае событие должно поступить какому-либо оператору.
- Оператор дает задание на работы и сообщает о событии клиенту.
Область 4 отображает то, что моделируема ИС предоставляет на выходе:
- клиент получает результатный документ, содержащий параметры совершённого события и проделанной работе.
- Из справочника «Спр «Клиенты»» используем текстовое наименование клиента;
- Из справочника «Спр «Событие»» получаем текстовое наименование События.
- Из таблицы «Т «Работы»» остальные реквизиты.
- клиент может получить выписку о событии и работах.
- оператор по окончании какого-либо периода получает файл(реестр) событий.
2.2. Характеристика нормативно-справочной, входной и оперативной информации
При решении поставленных в дипломном проекте задач используется ряд входных документов:
1) Данные о типе документа;
2) Данные о документах;
3) Данные об отделах;
4) Данные о сотрудниках;
5) Данные о контроле;
6) Данные о поручениях;
7) Данные о исполнении.
Данные типа документа. Содержит данные о типах документах на предприятии. Поступает в бумажном виде. В документе содержатся показатели:
- Номер типа;
- Название типа.
Данные об отделах. Содержит данные об отделах. Поступает в бумажном виде. В документе содержатся показатели:
- Название отдела;
- Руководитель;
- Телефон.
Данные сотрудника. Содержит данные о сотрудниках – составителях и исполнителях документов. Поступает в бумажном виде. В документе содержатся показатели:
- ФИО;
- Дата рождения;
- Телефоны;
- Адрес;
- Должность;
- Отдел.
Данные документа. Содержит данные о документах – корреспонденции, внутренних приказах. Поступает в бумажном виде. В документе содержатся показатели:
- Название документа;
- Содержание;
- Организация, приславшая или кому отсылают;
- Вид документа (входной, выходной);
- Создатель документа;
- Исполнитель (кому направлен);
- Тип документа;
- Руководитель;
- Дата создания.
Данные о контроле документа. Содержит данные о документах – контроле. Поступает в бумажном виде. В документе содержатся показатели:
- Дата контроля;
- Номер документа;
- Номер контроля;
- Выводы.
Данные о исполнении документа. Содержит данные об исполнении документов. Поступает в бумажном виде. В документе содержатся показатели:
- Номер документа;
- Исполнитель;
- Фактическая дата исполнения;
- Отчет об исполнении.
Данные о поручении документа. Содержит данные о поручении документов. Поступает в бумажном виде. В документе содержатся показатели:
- Номер документа;
- Поручитель;
- Кому поручено;
- Поручение;
- Дата поручения;
- Дата исполнения.
2.3. Характеристика результатной информации
В данном разделе описан документ, поучаемый в результате выполнения всех запросов данной задачи и произошедших событий. Результативным документом (в электронной форме) является “Данные в архив”.
Выходной документ «Данные в архив» содержит следующие данные:
- Фамилия заказчика
- Имя заказчика
- Отчество заказчика
- Пол заказчика
- Фамилия оператора
- Имя оператора
- Отчество оператора
- Пол оператора
- Дата события
- Телефон или факс
- Электронный адрес
- Номер подразделения (отдела)
- Название подразделения.
Данный выходной документ является, по сути, более уточненным входным документом “Бланк заказа”, но в отличие от него в “ Данные в архив ” уточняется специалист, который зафиксировал событие. Данные в электронном виде хранятся в БД в таблице «Данные» Табл.3.
В процессе описания структуры записи файлов для описания типа полей записи используются сокращенные обозначения, приведенные в таблице 2.
Таблица № 2
Перечень обозначений типов полей записи базы данных
Наименование типа поля записи |
Полное название |
Краткое обозначение |
Символьный тип |
Char |
С |
Числовой тип |
Int |
I |
Календарная дата |
Date |
D |
Таблица № 3
Структура справочника «Данные» в БД
№ |
Наименование поля |
Идентификатор |
Тип |
Количество символов |
1 |
ID заказа |
ID |
I |
4 |
2 |
Ф.И.О. клиента |
FIO_K |
C |
25 |
3 |
Пол заказчика |
POL_K |
I |
1 |
4 |
Ф.И.О. разработчика |
FIO_R |
C |
25 |
5 |
Пол разработчика |
POL_R |
I |
1 |
6 |
Дата заказа |
DAT |
D |
10 |
7 |
Электронный адрес |
|
C |
20 |
8 |
Телефон клиента |
TEL |
С |
5 |
9 |
Номер отдела |
NUM_OTD |
I |
3 |
Данный выходной документ формируется всякий раз когда “Бланк событие” одобряется, утверждается и уточняется начальником отдела автоматизации центра информационных технологий. Документ в электронном виде доставляется до получателя (разработчика) при помощи разрабатываемой в данном дипломном проекте программы, более точно при помощи ее администраторской клиентской части с которой работает начальник отдела.
2.4. Общие положения (дерево функций и сценарий диалога)
В процессе создания автоматизированной системы на стадиях жизненного цикла, связанных с требованиями, по ГОСТ 34.602-89 разрабатываются следующие модели:
- цели системы;
- смежные системы;
- границы системы;
- пользователи системы;
- связи системы со смежными системами;
- типовые функциональные требования;
- связи между подсистемами;
- схема функциональной структуры;
- описание автоматизируемых функций;
- нефункциональные требования;
- печатные документы;
Инструментарием для создания моделей требования в данной курсовой работе является Case средство Enterprise Architect(далее EA)[8].
EA является одним из немногих UML инструментов, который интегрирует этап управления требованиями с другими этапами разработки программного обеспечения, создавая требования непосредственно в модели. Вот некоторые отличительные черты ЕА[9]:
- Возможность создавать и просматривать требования непосредственно в модели
- Возможность детализировать диаграммы Use CASE непосредственно в модели
- Возможность вводить атрибуты для каждого требования , такие как сложность, тип, статус , а также добавлять свои собственные атрибуты
- Возможность трассировать требования с бизнес-правилами и тестами
- Возможность строить матрицу отношений, позволяющую быстро просмотреть влияние изменений в требованиях
- Возможность создавать в WORD- и HTM- документацию.
Для разработки выше перечисленных моделей в браузере ЕА необходимо создать четыре простые области просмотра (simple view) (рис.9):
- цели системы;
- границы системы;
- функциональные требования к системе;
- нефункциональные требования к системе;
Рисунок 9. Области просмотра модели в браузере EA
Для разработки модели «Цели системы» используется диаграмма классов (class diagram).
Рисунок 10. Модель «Цели системы»
Модель «Цели системы»» используется для отображения бизнес- требований, то есть требований, формулируемых заказчиком разработки системы.
Целью разработки модели «Пользователи системы» является отображение всех классов пользователей системы, документирования режимов их работы, квалификации и прочих их характеристик, оказывающих влияние на создание и внедрение системы.