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

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

Ниже на рис. 8 приведена подробная информационная модель рассматриваемого комплекса задач.

Рис. 8. Информационная модель

Область 1 отображает процесс конфигурирования ИС в части ввода пользователей ИС, которые необходимы в рамках задачи для того, чтобы можно было зафиксировать информацию о пользователях (клиентах). Форма «Управление пользователями» предполагает выполнение двух видов операций:

• редактирование справочника объекты;
• редактирование справочника пользователей.

Область 2 отображает то, что из базы ИС в рамках моделируемой задачи используются три справочника и две таблицы. (Под справочником мы понимаем обычную таблицу, которая содержит условно-постоянную информацию).

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

• сначала делается запись (либо производится обновление записи) в справочнике пользователя. Под пользователем понимается ФИО клиента и какие-либо его данные (например паспортные данные).
• затем делается запись, отражающая факт совершения события. В рамках задачи предполагается два варианта его совершения:
  • включилась аварийная кнопка;
  • произошло блокирование.
• в любом случае событие должно поступить какому-либо оператору.
• Оператор дает задание на работы и сообщает о событии клиенту.

Область 4 отображает то, что моделируема ИС предоставляет на выходе:

• клиент получает результатный документ, содержащий параметры совершённого события и проделанной работе.
  • Из справочника «Спр «Клиенты»» используем текстовое наименование клиента;
  • Из справочника «Спр «Событие»» получаем текстовое наименование События.
  • Из таблицы «Т «Работы»» остальные реквизиты.
• клиент может получить выписку о событии и работах.
  • оператор по окончании какого-либо периода получает файл(реестр) событий.

2.2.2. Характеристика нормативно-справочной, входной и оперативной информации

При решении поставленных в дипломном проекте задач используется ряд входных документов:

1) Данные о типе документа;

2) Данные о документах;

3) Данные об отделах;

4) Данные о сотрудниках;

5) Данные о контроле;

6) Данные о поручениях;

7) Данные о исполнении.

Данные типа документа. Содержит данные о типах документах на предприятии. Поступает в бумажном виде. В документе содержатся показатели:

• Номер типа;
• Название типа.

Данные об отделах. Содержит данные об отделах. Поступает в бумажном виде. В документе содержатся показатели:

• Название отдела;
• Руководитель;
• Телефон.

Данные сотрудника. Содержит данные о сотрудниках – составителях и исполнителях документов. Поступает в бумажном виде. В документе содержатся показатели:

• ФИО;
• Дата рождения;
• Телефоны;
• Адрес;
• Должность;
• Отдел.

Данные документа. Содержит данные о документах – корреспонденции, внутренних приказах. Поступает в бумажном виде. В документе содержатся показатели:

• Название документа;
• Содержание;
• Организация, приславшая или кому отсылают;
• Вид документа (входной, выходной);
• Создатель документа;
• Исполнитель (кому направлен);
• Тип документа;
• Руководитель;
• Дата создания.

Данные о контроле документа. Содержит данные о документах – контроле. Поступает в бумажном виде. В документе содержатся показатели:

• Дата контроля;
• Номер документа;
• Номер контроля;
• Выводы.

Данные о исполнении документа. Содержит данные об исполнении документов. Поступает в бумажном виде. В документе содержатся показатели:

• Номер документа;
• Исполнитель;
• Фактическая дата исполнения;
• Отчет об исполнении.

Данные о поручении документа. Содержит данные о поручении документов. Поступает в бумажном виде. В документе содержатся показатели:

• Номер документа;
• Поручитель;
• Кому поручено;
• Поручение;
• Дата поручения;
• Дата исполнения.

2.2.4 Характеристика результатной информации

В данном разделе описан документ поучаемый в результате выполнения всех запросов данной задачи и произошедших событий. Результативным документом (в электронной форме) является “Данные в архив”.

Выходной документ «Данные в архив» содержит следующие данные:

• Фамилия заказчика
• Имя заказчика
• Отчество заказчика
• Пол заказчика
• Фамилия оператора
• Имя оператора
• Отчество оператора
• Пол оператора
• Дата события
• Электронный адрес
• Телефон или факс
• Номер подразделения (отдела)
• Название подразделения.

Данный выходной документ является по сути более уточненным входным документом “Бланк заказа”, но в отличие от него в “ Данные в архив ” уточняется специалист, который зафиксировал событие. Данные в электронном виде хранятся в БД в таблице «Данные» Табл.3.

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

Таблица № 2

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

Таблица № 3

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

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

2.3. Программное обеспечение задачи

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

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

Таблица 4

Набор базовых функциональных возможностей информационных систем

Набор базовых функциональных возможностей информационных систем данного класса представлен в таблице 4.

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

Эти два преимущества основательно изменили системы управления проектами и соответственно возможности организации эффективного управления проектами.

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

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

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

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

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

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