Файл: Проектирование реализации операций бизнес-процесса Управление документооборотом (Выбор комплекса задач автоматизации).pdf

Рисунок 5. Декомпозиция процесса работы по проектам(TO-BE)

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

Процесс выполнения проектных работ включает следующие подпроцессы (рисунок 6): назначение исполнителей, выполнение задач, которые определены в рамках календарного плана проекта, согласование с заказчиком, мониторинг исполнения задач. Календарный план проекта предполагает на первых этапах назначение ответственных, которые подбирают исполнителей и фиксируют данные об исполнителях в рамках документации работы по проекту. Отчетная информация по выполненной работе попадает от исполнителей к ответственным по задачам и согласно срокам и поставленным заданиям определяется мера исполнения конкретной задачи.

Рисунок 6. Декомпозиция процесса выполнение проектных работ (TO-BE)

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

Характеристика документооборота, возникающего при решении задачи

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

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

Рисунок 7. Схема документооборота для плана работы по договору

---

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

Рисунок 8. Схема документооборота для плана загрузки специалистов

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

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

Рисунок 9. Схема документооборота для технического задания

Оценочные данные по обработке документов, связанных с разработкой ПО и АО для АСУ представлены в таблица 1.

Таблица 1

Оценочные данные по документообороту при разработке ПО и АО

Наименование документа	Средний объем (стр)	Затраты на обработку (час)	Частота возникновения в год
План работы по договору	20	5	120
План загрузки специалистов	10	5	200
Техническое задание	30	10	300
Техническая и рабочая документация к АСУ	50	20	250
Отчеты о деятельности руководителей подразделений	10	5	24
Отчеты о проделанной работе по договорам клиентов	10	10	240
Акт приемо-сдаточных испытаний	20	10	250

---

Учитывая затраты на разработку и частоту возникновения можно оценить затраты на обработку при средней зарплате разработчика в 40000 руб/мес. (таблица 2)

Таблица 2

Расчетные данные по документообороту при разработке ПО и АО

Наименование документа	Затраты на обработку (час)	Частота возникновения в год	Общие затраты по документу
План работы по договору	5	120	125000
План загрузки специалистов	5	200	208333,3
Техническое задание	10	300	625000
Техническая и рабочая документация к АСУ	20	250	1041667
Отчеты о деятельности руководителей подразделений	5	24	25000
Отчеты о проделанной работе по договорам клиентов	10	240	500000
Акт приемо-сдаточных испытаний	10	250	520833,3
			3045833

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

Обоснование проектных решений по информационному обеспечению

В качестве входных документов могут использоваться унифицированные формы договоров, так как основная часть договоров с клиентами строится по шаблону. При этом для работы с техническим заданием возможно использование классического шаблона согласно ГОСТ [1-4], в рамках которого проводится описание разработки.

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

---

Обоснование проектных решений по программному обеспечению

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

Операционные системы классифицируются по:

• количеству одновременно работающих пользователей: однопользовательские, многопользовательские;
• числу процессов, одновременно выполняемых под управлением системы: однозадачные, многозадачные;
• количеству поддерживаемых процессоров: однопроцессорные, многопроцессорные;
• разрядности кода ОС: 8-разрядные, 16-разрядные, 32-разрядные, 64-разрядные;
• типу интерфейса: командные (текстовые) и объектно-ориентированные (графические);
• типу доступа пользователя к ЭВМ: с пакетной обработкой, с разделением времени, реального времени;
• типу использования ресурсов: сетевые, локальные.

Учитывая аспекты рассматриваемой задачи и специфику системы, которая ориентирована на решение прикладных задач основным фактором для выбора операционной системы является максимальный функционал при минимальных затратах. Так как в компании уже установлена операционная система Windows 7 64 разрядная на большинстве машин и частично Windows 8 также 64 разрядная, то необходимо разрабатывать программное обеспечение совместимое с этими версиями операционной системы Windows от компании Microsoft.

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

• надежности;
• простоты для освоения пользователем;
• наличием инструментов защиты;
• масштабируемости;
• простыми инструментами для разработки;
• минимальными затратами на сопровождение и приобретение.

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

Среди наиболее популярных СУБД можно выделить: PostgreSQL, MSSQL, Oracle Database, MySQL [13, 14]. Все представленные СУБД обладают достаточно разветвленным функционалом, включающих управление данными, инструменты для работы с запросами, технологии защиты данных и другие. Однако все эти СУБД не предполагают наличие инструментов разработки интерфейса в рамках самой системы. В отличие от этих СУБД Microsoft Access или просто Microsoft Access — реляционная система управления базами данных корпорации Microsoft с возможностями разработки интерфейса приложения в рамках своей же платформы. Входит в состав пакета Microsoft Office. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных.

---

Инструменты для разработки и поддержки интерфейса СУБД Microsoft Access включают [8]:

• конструирование таблиц;
• работу с запросами, как при помощи конструктора, так и запись запросов на языке SQL, а также наличие особых перекрестных запросов, запросов с параметром и других;
• работу с формами и элементами управления на форме с использованием встроенного языка VBA (Visual Basic Application);
• создание отчетов в виде печатных документов со сложной структурой.

Разработчиками MS Access предусмотрены несколько методов для разграничения доступа к базам данных и отдельных их объектов.

Кодирование базы данных — является самым простым методом защиты БД. При этом способе защиты выполняется сжатие файла базы данных и его невозможно прочитать при помощи сторонних средств просмотра БД, таких как текстовые редакторы или служебные программы. Второй способ защиты является методом защиты отдельных объектов базы данных. Для этого выполняется скрытие отдельных компонентов (таблиц, форм и так далее) БД в окне открытой базы данных. Использование параметров запуска дает возможность задавать разные настройки, в частности, стартовая форма. Стартовая форма – это обычно стандартная кнопочная форма, которая автоматически появляется на экране при запуске базы данных вместе с заголовком и иконкой базы данных.

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

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

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

Информационная модель и её описание

Разработанная информационная модель может быть отражена на следующей схеме (рисунок 10).

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

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

---