Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

Для достижения поставленной цели в работе предполагается решение целого комплекса задач:

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

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

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

АНАЛИТИЧЕСКАЯ ЧАСТЬ

Выбор комплекса задач автоматизации

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

Среди основных направлений деятельности компании выделяются:

Проектирование объектов нефтегазовой отрасли;
Изготовление оборудования;
Поставка оборудования КИПиА;
Комплексная автоматизация нефтегазовых производств;
Метрологическое обеспечение;
Строительно-монтажные работы;
Шеф-монтажные и пусконаладочные работы;
Сервисное обслуживание.

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

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

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

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

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

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

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

Особенности работы по проектам связаны с используемыми стандартами разработки и внедрения ПО, наиболее оптимальными в компании считают стандарты регламентированные государственными стандартами ГОСТ 34.601-90, ГОСТ Р ИСО/МЭК 12207-99 [2, 3]. А также используются рекомендации, заключенные в библиотеке, описывающая лучшие из применяемых на практике способы организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. ITIL.

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

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

Характеристика существующих бизнес – процессов

Выделенный процесс разработки программного и аппаратного обеспечения для автоматизированных систем управления может быть описан в рамках нотации IDEF0 [7]. Для выявления проблем организации процесса и ведения документооборота рассматривается существующий принцип организации деятельности компании (рисунок 1).

Рисунок 1. Основной исследуемый бизнес-процесс

Заключенные менеджерами по работе с клиентами договоры поступают на рассмотрение и формирование планов по разработке. При этом необходимо руководствоваться пожеланиями клиентов, которые могут быть поданы в различной форме: как в виде обобщенной текстовой информации, так и в виде результатов опроса сотрудников, которые в дальнейшем будут работать с оборудованием и программным обеспечением [9].

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

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

Рисунок 2. Декомпозиция основного процесса

Основной процесс представлен следующими подпроцессами [10]:

анализ заключенных договоров;
распределение работы;
выполнение заданий по разработке;
мониторинг деятельности.

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

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

Выполнение заданий на разработку АСУ предполагает использование классических стандартов разработки, регламентированных ГОСТ. Описание схемы работы по стадиям на данный момент (рисунок 3).

Процесс разработки включает:

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

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

Рисунок 3. Декомпозиция процесса разработки

Результатом становится проект технического задания, которое согласуется с клиентом, при необходимости вносятся изменения в структуру или содержание технического задания, однако согласно требованиям ГОСТ [1].

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

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

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

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

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

Таким образом, в качестве задания поступают проектные задания, которые становятся основой составления проектов, а результаты работы строятся на базе отчетов по работе над проектами (рисунок 4).

Выполнение проектов предполагает составление календарного плана проекта и работы по нему, которая включает также и мониторинг процесса (рисунок 5).

Выделяются следующие подпроцессы:

организация проектов;
выполнение проектных работ;
анализ работы по проекту.

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

Рисунок 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 отображает процесс управления основными справочниками, которые включают информацию о сотрудниках, а также их специальность и должность. Такая информация необходима при назначении ответственных и исполнителей по задачам, на которые разбиваются проекты. Форма включает возможности по редактированию справочников: должности, специальности и сотрудники.

При этом, в ИС предполагается, что каждый сотрудник имеет конкретную должность строго одну роль, что отображено входящей связью из «Спр* «Должности»» в «Спр* «Сотрудники»».

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

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

сначала создаются или редактируются записи в «Т «Проекты»;
далее при наличии проекта редактируются записи по задачам «Т «Задачи»»;
к каждой задаче проекта в рамках таблицы исполнителя назначаются исполнители «Т «Исполнители»»;
для уже включенных проектов могут создаваться записи о дополнительных согласованиях «Т «Согласования»»;
после выполнения проекта заносятся данные о проведенных испытаниях «Испытания».

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

Из справочника «Спр. «Клиенты»» используем текстовое наименование клиента;
Из таблицы «Т «Проекты»» используем текстовое наименование проекта;
Из таблицы «Т «Испытания»» получаем данные по результатам испытаний;
Из таблицы «Т «Испытания»» получаем ссылку на техническую документацию по проведенным испытаниям.

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

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

Таблица 3

Описание входной информации

Название справочника	Ответственный за ведение	Объем справочника в записях	Частота актуализации	Объем актуализации
Клиенты	Администратор, менеджер по работе с клиентами	50	Раз в месяц	100%
Контакты	Администратор, менеджер по работе с клиентами	96	Раз в квартал	100%
Сотрудники	Администратор, менеджер по работе с кадрами	200	Раз в месяц	80%
Специальнос-ти	Администратор, менеджер по работе с кадрами	20	Раз в год	75%
Должности	Администратор, менеджер по работе с кадрами	50	Раз в год	60%

Реквизиты справочников представлены в таблица 4. Именно с помощью справочников определяются актуальные свойства объектов, а также различные взаимосвязи между ними. Это достигается посредством выделения дополнительных реквизитов.

Таблица 4

Описание справочников (реквизитный состав)

Справочник	Реквизитный состав
Клиенты	Код_клиента Наименование_клиента Адрес_клиента ИНН ОГРН

Справочник

Реквизитный состав

Клиенты

Код_клиента

Наименование_клиента

Адрес_клиента

ИНН

ОГРН

Продолжение таблицы 4

Справочник	Реквизитный состав
Контакты	Код_контакта ФИО email Телефон_контакта Должность Код_клиента
Сотрудники	Код_сотрудника ФИО Код_должности Код_специальности Дата_рождения email Телефон
Специальности	Код_специальности Специальность Описание_специальности
Должности	Код_должности Должность Описание_должности

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

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

Рисунок 11. Отчет по ответственным по проектам

Рисунок 12. Данные по предоставляемым дополнительным образовательным услугам

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

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

Рисунок 13. Дерево функций

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

Рисунок 14. Сценарий диалога

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

Характеристика базы данных

В базе данных автоматизированной системы хранится вся требуемая для работы информация [11, 12], в том числе о клиентах (предприятиях нефтегазовой отрасли) (таблица 5), а также их контактах (контактной информации) (таблица 6).

Таблица 5

Структура таблицы «Клиенты»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код клиента	Код_клиента	Счетчик	11	Ключевое поле
Наименование клиента	Наименование_клиента	Текстовое	255	-
Адрес клиента	Адрес_клиента	Текстовое	255	-
ИНН	ИНН	Текстовое	20	-
ОГРН	ОГРН	Текстовое	20	-

Таблица 6

Структура таблицы «Контакты»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код контакта	Код_контакта	Счетчик	11	Ключевое поле
ФИО	ФИО	Текстовое	55	-
email	email	Текстовое	30	-
Телефон контакта	Телефон_контакта	Текстовое	20	-
Должность	Должность	Текстовое	30	-
Код клиента	Код_клиента	Число	11	Внешний ключ

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

Таблица 7

Структура таблицы «Сотрудники»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код сотрудника	Код_сотрудника	Счетчик	11	Ключевое поле
ФИО	ФИО	Текстовое	255	-
Код должности	Код_должности	Число	11	Внешний ключ
Код специальности	Код_специальности	Число	11	Внешний ключ
Дата рождения	Дата_рождения	Дата и время	-	-
email	email	Текстовое	20	-
Телефон	Телефон	Текстовое	20	-

Таблица 8

Структура таблицы «Специальности»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код специальности	Код_специальности	Счетчик	11	Ключевое поле
Специальность	Специальность	Текстовое	50	-
Описание специальности	Описание_специальности	Текстовое	255	-

Таблица 9

Структура таблицы «Должности»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код должности	Код_должности	Счетчик	11	Ключевое поле
Должность	Должность	Текстовое	50	-
Описание должности	Описание_должности	Текстовое	30	-

С клиентами предприятия заключаются договоры (таблица 10), в соответствии с которыми формируются проекты (таблица 11).

Таблица 10

Структура таблицы «Договоры»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код договора	Код_договора	Счетчик	11	Ключевое поле
Код клиента	Код_клиента	Число	11	Внешний ключ
Дата заключения	Дата_заключения	Дата и время	-	-
Текст договора	Текст_договора	Гиперссылка	-	-

Таблица 11

Структура таблицы «Проекты»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код проекта	Код_проекта	Счетчик	11	Ключевое поле
Наименование проекта	Наименование_проекта	Текстовое	255	-
Календарный план проекта	Календарный_план_проекта	Гиперссылка	-	-
Код договора	Код_договора	Числовой	11	Внешний ключ

По каждому из проектов назначаются задачи (таблица 12), и, соответственно, исполнители каждой из задач (таблица 13). Эти задачи согласовываются с клиентом (таблица 14), по завершении задачи информация вносится в таблицу исполнения (таблица 15).

Таблица 12

Структура таблицы «Задачи»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код задачи	Код_задачи	Счетчик	11	Ключевое поле
Наименование задачи	Наименование_задачи	Текстовое	255	-
Код проекта	Код_проекта	Число	11	Внешний ключ
Ответственный по задаче	Ответственный_по_задаче	Число	11	Внешний ключ

Таблица 13

Структура таблицы «Контингент»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код исполнителя	Код_исполнителя	Счетчик	11	Ключевое поле
Код сотрудника	Код_сотрудника	Число	11	Внешний ключ
Код задачи	Код_задачи	Число	11	Внешний ключ

Таблица 14

Структура таблицы «Согласования»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код согласования	Код_согласования	Счетчик	11	Ключевое поле
Код проекта	Код_проекта	Число	11	Внешний ключ
Дата согласования	Дата_согласования	Дата и время	-	-
Документ согласования	Документ_согласования	Гиперссылка	-	-
Код контакта	Код_контакта	Число	11	Внешний ключ

Таблица 15

Структура таблицы «Исполнение»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код операции	Код_операции	Счетчик	11	Ключевое поле
Наименование операции	Наименование_операции	Текстовое	255	-
Дата исполнения	Дата_исполнения	Дата и время	-	-
Код исполнителя	Код_исполнителя	Число	11	Внешний ключ
Документы	Документы	Гиперссылка	-	-

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

Таблица 16

Структура таблицы «Испытания»

Имя поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код испытаний	Код_испытаний	Счетчик	11	Ключевое поле
Код проекта	Код_проекта	Число	11	Внешний ключ
Итог испытания	Итог_испытания	Текстовое	20	-
Отчет по испытанию	Отчет_по_испытанию	Гиперссылка	-	-
Код контакта	Код_контакта	Число	11	Внешний ключ

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

Рисунок 15. Структура базы данных

Структурная схема пакета (дерево вызова программных модулей)

Для разработки интерфейса приложения в рамках СУБД Microsoft Access были созданы формы и отчеты, а также необходимые запросы для организации работы форм и отчетов.

Основные формы, которые определяют структуру ввода данных в таблицы базы данных, построены в виде простых форм:

специальности;
должности;
сотрудники;
клиенты;
договоры;
проекты.

Для упрощения ввода данных формы сотрудники и договоры дополнены элементами управления в виде поля со списком. Сохранение записей в этих формах проводится после обновления данных в поле списка.

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

форма «Задачи проектов» (главная – проекты, подчиненная – задачи);
форма «Контакты» (главная – клиенты, подчинённая – контакты);
форма «Согласования» (главная – клиенты и договоры, подчиненная – проекты, подчиненная 2 – согласования);
форма «Испытания» (главная – клиенты и договоры, подчиненная – проекты, подчиненная 2 – испытания);
форма «Исполнение» (главная – задачи, подчиненная – исполнители, подчиненная 2 – исполнения).

Примером созданных запросов служит запрос для формирования отчета по ответственным по проектам [15]:

SELECT Проекты.Код_проекта, Проекты.Наименование_проекта, Проекты.Календарный_план_проекта, Задачи.Наименование_задачи, Сотрудники.ФИО

FROM Сотрудники INNER JOIN (Проекты INNER JOIN Задачи ON Проекты.Код_проекта = Задачи.Код_проекта) ON Сотрудники.Код_сотрудника = Задачи.Отвественный_по_задаче;

Главная кнопочная форма организована при помощи элементов управления – вкладок и кнопок. Работа элементов управления на главной форме осуществляется при помощи макросов открытия форм, обновления форм и отчетов.

Описание программных модулей

Обработка данных на формах при помощи полей со списком реализована в виде модулей VBA [8]. Пример такого модуля представлен ниже:

Sub Form_Current()

Dim ParentDocName As String

On Error Resume Next

ParentDocName = Me.Parent.Name

If Err <> 0 Then

GoTo Form_Current_Exit

Else

On Error GoTo Form_Current_Err

Me.Parent![Исполнение подчиненная форма].Requery

End If

Form_Current_Exit:

Exit Sub

Form_Current_Err:

MsgBox Error$

Resume Form_Current_Exit

End Sub

Рисунок 16. Фрагмент блок схемы обработки на форме

Контрольный пример реализации проекта и его описание

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

При открытии приложения автоматически на экране появляется главная форма в тремя основными вкладками (рисунок 17).

Рисунок 17. Главная форма приложения

Для уже существующих договоров с клиентами можно задать новый проект разработки (рисунок 18). Вместе с набором данных присоединяется и документ Microsoft Project, который содержит данные о календарном плане проекта.

Рисунок 18. Ввод данных о проекте

Согласно календарному плану вносятся данные по задачам проекта и ответственные (рисунок 19).

Рисунок 19. Ввод задач проекта

Ввод данных по исполнению задач и выделение прикрепленных исполнителей (рисунок 20).

Рисунок 20. Ввод данных по исполнителям и стадий выполнения задач

Результаты анализа данных по исполнению проектов отражены в отчете «Стадии исполнения задач» (рисунок 21).

Рисунок 21. Стадии исполнения задач по проекту

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ЛИТЕРАТУРЫ

ГОСТ 24.103-84 Автоматизированные системы управления основные положения (http://www.rugost.com/index.php?option=
com_content&view=article&id=75:24103-84&catid=21&Itemid=52).
ГОСТ 34.601-90 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. М.: Стандартинформ, 2009. 5 с.
ГОСТ Р ИСО 21500-2014 «Руководство по проектному менеджменту». – М.: Стандартинформ, 2015.
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.
ИСО/ТО 10006:1997 (R). Менеджмент качества. Руководство качеством при административном управлении проектами.
ISO 15846, ISO 10007. Стандарты по менеджменту конфигурации программных средств.
Арзуманян, М.Ю. Моделирование бизнес-процессов: лабораторный практикум [Текст] / М.Ю. Арзумян, М.А. Деревянко. – СПб.: СПбГУТ, 2014. – 48 с.
Бекаревич, Ю. Самоучитель MS Office Access 2016 [Текст] / Ю. Бекаревич. – СПб.: БХВ-Петербург, 2017. – 408 с.
Гаврилов, А.В. Анализ функциональных возможностей бесплатных CASE-средств проектирования баз данных [Текст] / А.В. Гаврилов // Открытое образование. – 2016. – №4. – C. 39-43.
Кондратьев В. Показываем бизнес-процессы [Текст] /В. Кондратьев, М. Кузнецов. – М.: Навигатор, 2015. – 156 с.
Нестерова, С.А. Базы данных: учебник и практикум для академического бакалавриата [Текст] / С.А. Нестерова. – М.: Юрайт, 2016. – 232 с.
Форта Б. SQL за 10 минут [Текст] / Б. Форта. – СПб.: Вильямс, 2015. – 288 с.
Попова М. Импортозамещающие СУБД: желания и возможности // CNews. Аналитика. Обзор: Рынок ИТ: итоги 2014. [Электронный ресурс]. URL: http://www.cnews.ru/reviews/2014/articles/importozameshchayushchie_subd_zhelaniya_i_vozmozhnosti.
Рейтинг систем управления базами данных (СУБД) 2016 // Tagline. Рейтинги сервисов и технологий [Электронный ресурс]. URL: http://tagline.ru/database-management-systems-rating/.
Пушников А. Ю. Введение в системы управления базами данных [Электронный ресурс].URL: http://www.citforum.ru/database/dblearn/index.shtml