Файл: Проектирование бизнес-процесса «Обеспечение послепродажного обслуживания».pdf

Оценка производительности производится методом тестирования с помощью эталонных тестов из набора 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

Перечень обозначений типов полей записи базы данных

Таблица № 3

Структура справочника «Данные» в БД

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

2.4. Общие положения (дерево функций и сценарий диалога)

В процессе создания автоматизированной системы на стадиях жизненного цикла, связанных с требованиями, по ГОСТ 34.602-89 разрабатываются следующие модели:

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

Инструментарием для создания моделей требования в данной курсовой работе является Case средство Enterprise Architect(далее EA)^[8].

EA является одним из немногих UML инструментов, который интегрирует этап управления требованиями с другими этапами разработки программного обеспечения, создавая требования непосредственно в модели. Вот некоторые отличительные черты ЕА^[9]:

• Возможность создавать и просматривать требования непосредственно в модели
• Возможность детализировать диаграммы Use CASE непосредственно в модели
• Возможность вводить атрибуты для каждого требования , такие как сложность, тип, статус , а также добавлять свои собственные атрибуты
• Возможность трассировать требования с бизнес-правилами и тестами
• Возможность строить матрицу отношений, позволяющую быстро просмотреть влияние изменений в требованиях
• Возможность создавать в WORD- и HTM- документацию.

Для разработки выше перечисленных моделей в браузере ЕА необходимо создать четыре простые области просмотра (simple view) (рис.9):

• цели системы;
• границы системы;
• функциональные требования к системе;
• нефункциональные требования к системе;

Рисунок 9. Области просмотра модели в браузере EA

Для разработки модели «Цели системы» используется диаграмма классов (class diagram).

Рисунок 10. Модель «Цели системы»

Модель «Цели системы»» используется для отображения бизнес- требований, то есть требований, формулируемых заказчиком разработки системы.

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