58829

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

Дипломная

Информатика, кибернетика и программирование

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

Русский

2015-01-09

8.14 MB

7 чел.

Аннотация

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


Annotation

The present degree project is devoted to development of the information monitoring system of execution of administrative documents of the enterprises. The analysis of a subject domain and the description of development of functional and information and logical models with application of corresponding CASE-means is made. In an economic part of the project calculation of labor input of performance of work is lead, the estimate of expenses is made and economic efficiency is proved. Also safety issues and ecological compatibility of the project where recommendations on restriction of harmful factors of the acting user are given at work on a personal computer have been mentioned.


Содержание

[1]
Содержание

[2]
Введение

[3]
1 Технико-экономическое обоснование проекта

[4]
2 Анализ процесса контроля исполнения распорядительных документов

[5] 3 Обоснование выбора средств разработки

[6]
4 Разработка структурной и функциональной схемы информационной системы

[6.1] 4.1 Построение контекстной диаграммы

[6.2] 4.2 Декомпозиция моделируемой системы

[6.3]
4.3 Разработка информационной модели

[6.4]
4.4 Определение сущностей

[6.5] 4.5 Определение связей между сущностями

[6.6] 4.6 Определение первичных ключей

[6.7] 4.7 Определение атрибутов сущностей и внешних ключей

[6.8] 4.8 Создание логической модели БД

[6.9] 4.9 Создание физической модели БД

[6.10] 4.10 Прямое проектирование

[7]
5 Разработка и описание алгоритмов и методов функционирования информационной системы

[8] 6 Разработка интерфейса пользователя системы

[9]
7 Разработка руководства пользователя

[10] 8 Тестирование системы

[11] 9 Экономическая часть

[11.1] 9.1  Планирование работы при помощи ленточного графика

[11.2] 9.2 Составление сметы затрат на разработку и определение цены на программную разработку

[11.2.1] 9.2.1 Материальные затраты

[11.2.2] 9.2.2 Затраты на оплату труда

[11.2.3] 9.2.3 Отчисления на социальные нужды

[11.2.4] 9.2.4 Амортизация основных фондов

[11.2.5] 9.2.5 Накладные расходы

[11.3] 9.3 Экономическая эффективность разработки

[12] 10 Безопасность и экологичность проекта

[12.1] 10.1 Выявление опасных факторов, влияющих на оператора ПЭВМ

[12.1.1] 10.1.1 Анализ условий труда на рабочем месте оператора ПЭВМ

[12.1.2] 10.1.2 Воздушная среда в помещениях с ПЭВМ

[12.1.3] 10.1.3 Опасность поражения электрическим током

[12.1.4] 10.1.4 Повышенный уровень шума

[12.1.5] 10.1.5 Неблагоприятные условия зрительной работы

[12.1.6] 10.1.6 Электромагнитное излучение ПЭВМ

[12.1.7] 10.1.7 Организация и оборудование рабочих мест

[12.2] 10.2 Обеспечение пожарной безопасности

[12.2.1] 10.2.1 Оценка пожароопасности объекта

[12.2.2] 10.2.2 Причины возникновения пожаров и мероприятия по их устранению

[12.3] 10.3 Экологичность проекта

[13]
Заключение

[14] Список используемых источников

[15]
Приложение А.

[16] Листинг команд создания основных объектов базы данных

[17] Приложение Б.1.

[18] Текст основной программы MainAskid.prj

[19] Приложение Б.2.

[20] Текст программы MainForm.prj

[21]
Приложение Б.3.

[22] Текст программы EnterCard.prj  «Ввод новой карточки»


Введение

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

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

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

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

В настоящее время ПО находит широкое применение на предприятиях, например, для организации автоматизированного контроля исполнения директивных и других распорядительных документов.

Темой данного дипломного проекта является разработка программного обеспечения контроля исполнения распорядительных документов такого предприятия, как Государственный Рязанский приборный завод (ГРПЗ).


1 Технико-экономическое обоснование проекта

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

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

Контроль исполнения документов направлен на выполнение поручений в установленные сроки.

Эффективность контроля зависит от:

- своевременного доведения до исполнителей требований приказов, указаний, заданий и поручений;

-   своевременного развертывания работ исполнителем;

- своевременного выявления наметившихся отставаний и принятия оперативных мер по их ликвидации;

-   анализа и воздействия на ход исполнения заданий и поручений;

-   обеспечения гласности результатов контроля.

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

- хранение всех требуемых данных;

- ввод новой информации и изменение уже существующей;

- удаление устаревшей или неверной информации;

- вывод на экран требуемых сведений по запросу пользователя и т.д.

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

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

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

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

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

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

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

До разработки данного ПО, работа на ГРПЗ по контролю за исполнением директивных и распорядительных документов, велась не в полном объёме вручную. Данная информация обладала малой актуальностью, т.к. она быстро устаревала. Собственная разработка программного обеспечения позволяет учесть все особенности и потребности функционирования данной системы на предприятии, а также вести его актуальную поддержку.

Автоматизированная система контроля исполнения распорядительных документов предполагает выполнение следующих функций:

- подведение итогов по исполнительности за месяц;

- выдача напоминаний лицам, контролирующим выполнение;

- выдача информации по запросу о состоянии выполнения того или иного документа;

- выдача карточек исполнителю.


2 Анализ процесса контроля исполнения распорядительных документов 

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

Порядок организации автоматизированного контроля исполнения директивных и других распорядительных документов, поставленных на контроль руководством предприятия, устанавливается стандартом предприятия СТП ВИАМ.2.004-01. Стандарт обязателен для всех подразделений предприятия. Процесс контроля исполнения принятых решений осуществляет бюро контроля исполнительской дисциплины.

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

  С целью повышения уровня управляемости предприятием и более  объективной оценки исполнительской дисциплины предусматривают три кода важности работ - КВР:

КВР =1 – для обычных документов,

КВР =2 – для важных документов,

КВР =3 – для особо важных документов, где  ВР – важность работ.

К коду важности 3 относятся особо важные работы по производству изделий и подготовке запуска  новых изделий. К коду важности 2 относятся важные работы по повышению  качества изделий, организации производства. К коду важности 1 относятся обычные работы. Работы,  по которым не присвоены коды важности, также относятся к 1-му коду важности.

Код важности указывается по тем пунктам распорядительных документов, которые ставятся на контроль. Его значение согласовывается при подготовке проекта документа  со всеми должностными лицами, ответственными за контроль этих пунктов. Работы,  по которым не присвоены коды важности, относятся к 1-му коду важности.

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

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

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

Бюро делопроизводства осуществляет структурирование построения документа:

  •  При подготовке проекта документа (плана мероприятий, графика, распоряжения и др.) в подразделении необходимо присваивать этим документам номера из шести цифр, где первыми тремя цифрами обозначается номер подразделения, тремя последующими - порядковый номер по журналу учета документов, разрабатываемых в подразделении.
  •  В зависимости от содержания текст документа может быть разбит на разделы. Разделы должны иметь порядковую нумерацию в пределах всего документа и обозначаться арабскими цифрами.
  •  Раздел может быть разбит на пункты, нумерация которых ведется в пределах каждого раздела и состоит из номеров разделов и пунктов, разделенных точкой.
  •  Пункты при необходимости могут быть разбиты на подпункты, нумерация которых ведется в пределах каждого пункта и состоит из номера раздела, номера пункта и номера подпункта. Пример - “1.2.5” – нумерация подпункта 5, пункта 2, раздела 1.
  •  При отсутствии разделов весь текст документа разбивается на пункты, подпункты, имеющие порядковую нумерацию.
  •  Срок исполнения и исполнитель должны быть назначены для каждого раздела, пункта, подпункта. Назначение нескольких исполнителей по одному разделу, пункту, подпункту допускается только при возможности исполнения работ исполнителями независимо от других подразделений.

После подписания и структурирования документа первый экземпляр поступает на размножение и хранение в Бюро контроля испонительской дисциплины, а второй ставится на контроль в АСКИД.

Все вышеперечисленные этапы постановки документов на контроль отражены на рисунке 2.1.

.

Рисунок 2.1 -  Постановка на контроль

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

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

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

- закрытие карточки контроля на выполнение работ,

- перенос срока исполнения в "Распоряжении на корректировку",

- перенос срока исполнения в «Карточке исполнителю».

Бюро контроля исполнительской дисциплины на основании "Распоряжения на корректировку" проводит изменение сроков исполнения и ставит в известность подразделения-исполнители. Затем выполненные работы снимают с контроля и сдают на хранение. Время хранения контрольных карточек в бюро контроля исполнительской дисциплины 6 месяцев. Карточки контроля уничтожаются путем сжигания.

Процесс непосредственного контроля исполнения документов приведен в соответствии с рисунком 2.2.

Рисунок 2.2 - Контроль исполнения


На основании выполненных работ бюро контроля исполнительской дисциплины готовит следующие выходные документы:

- "Сводка об исполнении документов и мероприятий",  выдается по окончании месяца не позднее 2-го рабочего дня следующего месяца в двух экземплярах, один из которых рассылается подразделениям-исполнителям в течение суток (предварительная сводка); и не позднее 5-го рабочего дня этого же месяца в двух экземплярах (окончательная сводка для подготовки информации на "День качества"  в планово-экономической службе). Второй экземпляр остается в бюро контроля исполнительской дисциплины. Сводку о выполнении подразделениями перечней работ осуществляется с указанием коэффициента исполнительской дисциплины по подразделениям-исполнителям согласно "Методике расчета параметров исполнительской дисциплины". Сводка может быть окончательной или предварительной. Если она формируется по окончании отчетного периода, причем не раньше 4-го числа месяца, следующим за отчетным, то документ будет окончательным (рассчитанные данные будут использоваться для формирования документа "Информация на день качества"). Предварительная сводка может быть выдана в любой момент времени без сохранения в памяти;

- "Карточку исполнителю", которая выдается вместе с "Рассыльным листом" в одном экземпляре. Рассылка подразделениям-исполнителям производится в течение суток.

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

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

- "Ведомость предупреждения", которая выдается 1-го и 15-го числа месяца (в рабочие дни) подразделению или должностному лицу, на которых возложен контроль за исполнением, в одном экземпляре по мере необходимости или по запросу ответственного за контроль;

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

- "Контролируемые работы по документу", который выдается по запросу. Для получения перечня необходимо указать номер, наименование и дату документа, по которому делается запрос. Если работа ранее уже переносилась, то должен выдаваться самый последний срок исполнения;

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

Рисунок 2.3 - Выходные документы

3 Обоснование выбора средств разработки

В данном дипломном проекте необходимо разработать программное обеспечение (ПО) по контролю исполнения распорядительных документов предприятия. Для разработки рассматриваемого ПО выбрана система управления базой данных (СУБД) Oracle 10g. Данная система является единственной СУБД, применяемой на ГРПЗ.

Выбор именно этой СУБД обоснован тем, что она действительно способна обеспечить решение самых разнообразных задач, так как поддерживает:

- любые типы данных – скалярные величины, текст, видео, пространственные координаты, изображения, а также типы данных, определяемые пользователем;

- любые модели обработки данных – реляционную, многомерную, объектно-ориентированную;

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

СУБД Oracle обладает рядом преимуществ:

- Oracle может поддерживать базы данных (БД) больших размеров (от нескольких мегабайтов до сотен гигабайтов);

- к базе данных Oracle может обращаться от одного до сотен пользователей. Вся необходимая блокировка и защита данных выполняются программным обеспечением СУБД;

- Oracle может выполнять резервное копирование во время работы с файлами БД. Это средство позволяет обеспечить круглосуточную эксплуатацию системы;

- Oracle и ее компоненты работают более чем на 100 различных аппаратных платформах и под управлением различных операционных систем (ОС). Если прикладная программа Oracle разработана на одной машине, то будет относительно несложно перенести ее на другую машину и ОС;

- Oracle обеспечивает множество средств защиты, включая управление доступом к БД, определение команд, которые могут быть выполнены, ограничение количества ресурсов, которые могут использоваться отдельными процессами;

- Oracle поддерживает большое число сетевых протоколов, позволяющие осуществлять взаимодействие машин клиента и сервера [6].

В настоящее время существует множество СУБД, работающих на принципах архитектуры "клиент-сервер". Наибольшее распространение получили продукты компаний Oracle, Informix, Sysbase, Ingress. Эти компании предлагают широкий спектр реляционных и объектно-реляционных СУБД для создания баз данных разного уровня: от персональных баз данных до распределенных корпоративных баз данных.

Однако по своим эксплутационным и надежностным характеристикам многие продукты существенно уступают СУБД Оrасlе. Принципы, заложенные в технологию Оrасlе, позволяют создавать системы, различного уровня сложности на высоком уровне надежности.

Корпорация Огас1е предоставляет пользователям не только СУБД, но САSЕ-средства разработки баз данных и приложений, методологию  создания  заказных  систем  СDМ, обеспечивающих автоматизацию работ на всех этапах жизненного цикла информационных систем.

Данная версия СУБД Oracle была выбрана по причине того, что это объектно-реляционная СУБД, выпущенная корпорацией Oracle, т.е. Oracle 10g использует как реляционную, так и объектно-ориентированную архитектуру.

Для разработки информационной системы, описываемой в данном дипломном проекте, использовалась ОС Windows XP.

Выбор данной ОС обусловлен, прежде всего, такими ключевыми характеристиками, как:

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

- надежность. Благодаря полной независимости всех процессов, выполняющихся в среде Windows XP, вероятность сбоя в системе минимальна. Даже если в одном из приложений возникнет ошибка, это не влияет на остальные приложения и на саму систему;

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

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

В качестве языка программирования для разработки программы был выбран Visual FoxPro 6.0.

Visual FoxPro является первым продуктом разработки, предназначенным для создания общекорпоративных приложений типа клиент-сервер. В шестой версии Visual FoxPro новая галерея компонентов и библиотека базовых классов значительно облегчили переход к созданию объектно-ориентированных приложений. Также Visual FoxPro 6.0 отличается тем, что поставляется с множеством  новых инструментов, помимо реализованных в предыдущих версиях [5].

СУБД Oracle 10g, ОС Windows XP и среда программирования FoxPro 6.0 были выбраны в качестве средств разработки, т.к. применяются на предприятии (ГРПЗ), для которого создавалась описываемая в данном дипломном проекте информационная система.


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

4.1 Построение контекстной диаграммы

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

В настоящее время для построения функциональной модели, проведения анализа и реорганизации бизнес - процессов широко используется CASE-средство верхнего уровня BPwin  фирмы PLATINUM Technology, поддерживающее методологии IDEF0 (Integrated Definition), IDEF3 (Work Flow Diagram) и DFD (Data Flow Diagram). Функциональная модель предназначена для описания существующих на предприятии бизнес-процессов (так называемая модель AS-IS). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействие с окружающим миром (контекстная диаграмма), после этого проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях [1].

В данном дипломном проекте осуществляется разработка информационной системы контроля исполнения распорядительных документов, которая будет использоваться на данном предприятии, следовательно, основной блок контекстной диаграммы, которому присваивается имя, охватывающее всю сферу деятельности системы, можно назвать “Контроль исполнения распорядительных документов”. После чего определяем внешние интерфейсы. Входными объектами данной системы являются распорядительные документы, издаваемые на предприятии. К ним относят приказы, указания, протоколы, решения, планы графики и другие, директивные и распорядительные документы генерального директора и технического  директора или лиц, временно выполняющих их обязанности. Порядок организации контроля исполнения распорядительных документов осуществляют сотрудники предприятия с помощью необходимого оборудования, на основании необходимых стандартов и инструкций, применяемых на предприятии, основными из которых являются: СТП ВИАМ.2.004-01 и «Инструкции по подготовке и оформлению приказов и указаний». Выходными объектами системы являются выходные документы.

Блок А0 – «Контроль исполнения распорядительных документов», представленный на рисунке 1, может быть описан более подробно на другой диаграмме, расположенной на один уровень ниже в иерархии. Диаграмма нижнего уровня, или диаграмма-потомок, как бы показывает внутреннее содержание блока – родителя. Процесс создания более детальных диаграмм называется декомпозицией.

Рисунок 4.1 – Контекстная диаграмма

4.2 Декомпозиция моделируемой системы

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

  1.  Поставить документы на контроль;
  2.  Контролировать выполнение;
  3.  Сформировать выходные документы.

Рисунок 4.2 –Диаграмма декомпозиции функционального блока А0

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

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

Каждый из этих этапов может быть описан более подробно на другой диаграмме, расположенной одним уровнем ниже. В свою очередь первый блок диаграммы первого уровня  А1-«Поставить документы на контроль» можно декомпозировать. То есть мы получим IDEF0-диаграмму второго уровня. Пример декомпозиции выполнен в соответствии с рисунком 4.3.

Рисунок 4.3 - Диаграмма декомпозиции функционального блока А1 «Поставить документы на контроль»

Блок А1.1 – «Подготовить порядок документов и правила их оформления». Проект документа готовится ответственным исполнителем не менее чем в двух экземплярах. В нём указывается необходимые адреса рассылки при необходимости размножения.

  •  Проект документа готовится ответственным исполнителем не менее чем в двух экземплярах
  •  Проект документа визируется всеми основными исполнителями. Время рассмотрения для визы всеми основными исполнителями: приказов, распоряжений – не более суток; мероприятий, планов, графиков – не более двух суток.
  •  В проекте следует предусмотреть время на рассылку и постановку документов на контроль. Срок с момента подписания документа до первого срока исполнения должен быть не менее пяти суток. Срок для размножения и рассылки документов исполнителям должен быть не более  3-х суток.
  •  При подготовке документа исполнитель указывает необходимые адреса рассылки при необходимости размножения.
  •  После подписания документа первый экземпляр поступает на размножение и хранение в бюро делопроизводства, а второй экземпляр направляется в бюро автоматизированной системы контроля исполнительской дисциплины (АСКИД). Декомпозиция блока А1.1 -  «Подготовить порядок документов и правила их оформления» выполнена в соответствии с рисунком 4.4.

Рисунок 4.4 - Диаграмма декомпозиции функционального блока А1.1 «Подготовить порядок документов и правила их оформления»

Блок А1.2 – «Утвердить документ для контроля». Этот вопрос решает Генеральный директор, технический директор или лица, временно исполняющие их обязанности.

Блок А1.3 – «Сформировать структуру построения документа». На этом этапе целесообразнее применять методологию DFD, т.к. она специально предназначена для описания документооборота и обработки информации. Дуги управление и механизмы на ней отсутствуют, процессы соединяются стрелками, изображающими поток данных. Ее можно использовать  как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота.

  DFD-диаграмма  содержит:

  •  функции обработки информации (работы);
  •  документы (стрелки) и объекты, которые участвуют в обработке информации;
  •  внешние ссылки, которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
  •  таблицы для хранения документов или объектов (хранилище данных).
    DFD-диаграмма блока «Сформировать структуру построения документа» будет иметь вид, представленный на рисунке 4.5.
Рисунок 4.5 -  Диаграмма потоков данных для функционального блока  «Сформировать структуру построения документа»

На данной диаграмме в качестве внешних данных используется общесистемный классификатор «Документы» и справочник «Календарь».

Структура построения документов, исполнение которых контролируется с помощью АСКИД осуществляется в несколько этапов:

  •   При подготовке проекта документа (плана мероприятий, графика, распоряжения и др.) в подразделении необходимо присваивать этим документам номера из шести цифр, где первыми тремя цифрами обозначается номер подразделения, тремя последующими - порядковый номер по журналу учета документов, разрабатываемых в подразделении.
  •   В зависимости от содержания текст документа может быть разбит на разделы. Разделы должны иметь порядковую нумерацию в пределах всего документа и обозначаться арабскими цифрами.
  •   Раздел может быть разбит на пункты, нумерация которых ведется в пределах каждого раздела и состоит из номеров разделов и пунктов, разделенных точкой.
  •   Пункты при необходимости могут быть разбиты на подпункты, нумерация которых ведется в пределах каждого пункта и состоит из номера раздела, номера пункта и номера подпункта. Пример - “1.2.5” – нумерация подпункта 5, пункта 2, раздела 1.
  •   При отсутствии разделов весь текст документа разбивается на пункты, подпункты, имеющие порядковую нумерацию.
  •   Срок исполнения и исполнитель должны быть назначены для каждого раздела, пункта, подпункта. Назначение нескольких исполнителей по одному разделу, пункту, подпункту допускается только при возможности исполнения работ исполнителями независимо от других подразделений.

Для блока А1.4  «Сформировать карточку исполнителю», DFD-диаграмма будет иметь вид, представленный на рисунке 4.6.

Рисунок 4.6 - Диаграмма потоков данных для функционального блока  «Сформировать карточку исполнителю»

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

Аналогично, DFD-диаграмма блока «Внести необходимую информацию» будет иметь вид, представленный на рисунке 4.7.

Рисунок 4.7 - Диаграмма потоков данных для функционального блока  «Внести необходимую информацию о контролируемых работах »

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

Диаграмма декомпозиции функционального блока «Контролировать выполнение» выполнена в соответствии с рисунком 4.8.

Рисунок 4.8 - Диаграмма декомпозиции функционального блока А2 «Контролировать выполнение»

Функциональный блок А2.2 - «Принять решение о выполнении» можно дополнить диаграммой IDEF3. Она используется для описания логики взаимодействия информационных потоков. Данная диаграмма выполнена в соответствии с рисунком 4.9.

Рисунок 4.9 - IDEF3-диаграмма блока «Принять решение о выполнении»

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

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

-  Одновременно в данном "Распоряжении на корректировку" устанавливаются новые сроки исполнителям всех последующих этапов работ. "Распоряжение на корректировку" оформляется в течение 5 суток до окончания срока работ.

-  Бюро АСКИД на основании "Распоряжения на корректировку" проводит изменение сроков исполнения и ставит в известность подразделения-исполнители.

-  Для повышения эффективности контроля исполнения мероприятий, решений, распоряжений и других директивных и распорядительных документов Генерального директора и технического директора (по вопросам повышения качества изделий), согласованных с директором по качеству, руководителям функциональных служб, начальникам структурных подразделений согласовывать с директором по качеству:

  •  закрытие карточки контроля на выполнение работ,
  •  перенос срока исполнения в "Распоряжении на корректировку",
  •  перенос срока исполнения в «Карточке исполнителю».

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

DFD-диаграмма блока А2.4 «Перенести сроки выполнения» будет иметь вид, представленный на рисунке 4.10.

Рисунок 4.10 - Диаграмма потоков данных для функционального блока  «Перенести сроки выполнения»

На данной  диаграмме в качестве внешних данных используется автоматизированная система «Кадры», справочник «Календарь» и классификатор «Документы». Для указания причины переноса работы используется хранилище «Список причин переноса». В итоге происходит занесение необходимых данных в  хранилища данных «Перенесённые работы».

После чего, руководителем подразделения потребителя, для которого данная работа выполнена, или должностным лицом, на которое возложен контроль за исполнением данной работы осуществляется закрытие карточки исполнителю. На карточке ставится дата выполнения поручения с указанием, какими документами подтверждается выполнение. Закрытые "Карточки исполнителю" передаются в бюро АСКИД. Сроком исполнения работ считается дата поступления "Карточки исполнителю" в бюро АСКИД за вычетом одного рабочего дня после чего работа снимается с контроля.

Диаграмма декомпозиции функционального блока «Закрыть карточку исполнителю» выполнена в соответствии с рисунком 4.11.

Рисунок 4.11 - Диаграмма декомпозиции функционального блока А2.3 «Закрыть карточку исполнителю»

На основании автоматизированного анализа о выполнении контролируемых работ, бюро АСКИД готовит следующие документы:

  •   «Сводку об исполнении документов и мероприятий» с указанием коэффициента исполнительской дисциплины по подразделениям-исполнителям согласно;
  •   «Информацию на "День качества» по итогам работ за истекший период.

Диаграмма декомпозиции функционального блока А3 «Сформировать выходные документы» выполнена в соответствии с рисунком 4.12.

Рисунок 4.12 - Диаграмма декомпозиции функционального блока А3 «Сформировать выходные документы»

На основании автоматизированного анализа о выполнении контролируемых работ, бюро АСКИД готовит следующие документы:

  •   «Сводку об исполнении документов и мероприятий» с указанием коэффициента исполнительской дисциплины по подразделениям-исполнителям;
  •  «Информацию на "День качества» по итогам работ за истекший период.


4.3 Разработка информационной модели

Построение информационной модели производится с помощью CASE-средства CA ERwin Process Modeler 7.3, которое удовлетворяет всем требованиям к системам разработки информационных моделей БД и является эффективным и удобным инструментом для построения моделей данных.

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

ERwin имеет два уровня представления модели – логический и физический.

  •  Логический уровень (точка зрения пользователя). Это абстрактный взгляд на данные. На нем используются данные в таком виде, в каком они известны в реальном мире. Объектам модели (сущностям и атрибутам) даются имена, понятные широкому кругу специалистов. Логическая модель данных является универсальной и никак не связана с особенностями реализации конкретной системы управления базой данных (СУБД).
  •  Физический уровень – определяет представление информации в базе данных (БД). На физическом уровне объекты модели должны обозначаться так, как того требуют ограничения выбранной СУБД. Если в логической модели не имеет принципиального значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о таблицах, колонках, индексах, процедурах и т.п. Такую модель создают специалисты по СУБД [3].


4.4 Определение сущностей

Цель данного этапа – выявление и определение сущностей. Необходимо выявить среди исходных имен существительные, которые могут быть в дальнейшем представлены сущностями.

Сущность представляет собой множество реальных или абстрактных предметов, обладающих общими атрибутами или характеристиками. В ходе процесса определения сущностей возможны следующие ситуации: существительное может являться сущностью или атрибутом; могут появиться «невидимые» ранее сущности. Для отделения сущности от атрибута нужно ответить на вопросы:

  •  Может ли существительное быть описано как сущность?
  •  Обладает ли характерными особенностями?
  •  Существует ли более одного экземпляра?
  •  Может ли быть один экземпляр отделен (идентифицирован) от другого?

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

Рассмотрим DFD-диаграммы блоков. Из хранилищ данных выделим сущности и дадим им имена. Проанализируем DFD – диаграмму блока «Сформировать структуру документа», представленную на рисунке 4.5. Данная DFD – диаграмма содержит в качестве внешних данных общесистемный классификатор «Документы» и справочник «Календарь», а также хранилище данных: «Список категорий важности». Следовательно, в локальной концептуальной модели должна быть представлена сущность, соответствующая этому хранилищу – «Категории важности». Аналогичным образом анализируются все остальные DFD – диаграммы. В результате получим следующие сущности. Результаты по выявлению сущностей представлены в таблице 4.1.

      

    Таблица 4.1 - Выявление сущностей

DFD-диаграмма

Хранилища

Сущности

Внешние данные

Сформировать структуру
документа

Классификатор "Документы"

Документы

Да

Справочник "Календарь"

Календарь

Да

Список категорий важности

Категории важности

Нет

Сформировать карточку
исполнителю

Классификатор "Документы"

Документы

Да

Справочник "Календарь"

Календарь

Да

Автоматизированная система
"Кадры"

Функциональные службы
Картотека руководителей
Подразделения ГРПЗ

Да

Список категорий важности

Категории важности

Нет

Внести необходимую
информацию о
контролируемых работах

Автоматизированная система
"Кадры"

Функциональные службы
Картотека руководителей
Подразделения ГРПЗ

Да 

Список категорий важности

Категории важности

Нет

Список признаков исполнения

Признаки исполнения

Нет

Контролируемые работы

Контролируемые работы

Нет

Перенести сроки
выполнения

Классификатор "Документы"

Документы

Да

Справочник "Календарь"

Календарь

Да

Автоматизированная система
"Кадры"

Функциональные службы
Картотека руководителей
Подразделения ГРПЗ

Да

Список причин переноса

Причины переноса

Нет

Перенесённые работы

Перенесённые работы

Нет

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

- автоматизированная система «Кадры»;

- общесистемный справочник «Календарь»;

- общесистемный классификатор «Документы».

4.5 Определение связей между сущностями

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

Могут быть выражены следующие отношения мощности:

-  Zero, One or Many(Ноль, Один или более);

-  Zero or Many(Ноль или один)-(Z);

-  One or Many(Один или более)-(P);

-  Exactly(Точное значение);

Рассмотрим отношения между сущностями «Признак исполнения», «Категории важности работ» и «Контролируемые работы», полученными из DFD – диаграммы блока А1.5 - «Внести необходимую информацию о контролируемых работах» в соответствии с рисунком 4.13.

Рисунок 4.13 -  ER-диаграмма, показывающая связь между сущностями «Признак исполнения», «Категории важности работ»   и «Контролируемые работы»

 

Рассмотрим отношения между сущностями «Категории важности работ»,  «Причина переноса» и «Перенесённые работы», полученными из DFD – диаграммы блока А2.4 - «Перенести сроки выполнения» (рисунок 4.14).

Рисунок 4.14 -  ER-диаграмма, показывающая связь между сущностями «Причина переноса» и «Перенесённые работы»,

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

Рассмотрим отношение между сущностями «Контролируемые работы» и «Категории важности работ». Одна и та же категория важности работ может быть указана для несколько контролируемых работ, поставленных на контроль, в тоже время, для одной контролируемой работы не может быть указано несколько категорий важности работ, поэтому между данными сущностями будет связь один – ко - многим.

Аналогично между сущностями «Контролируемые работы» и «Признак исполнения». Признак исполнения работы отмечается для одной или нескольких контролируемых работ. Таким образом, отношение будет один ко многим.  Учитывая внешние данные, поступающие из автоматизированной системы «Кадры» (справочник «Подразделения ГРПЗ», классификатор “Функциональные службы, файл «Картотека руководителей»)  и общесистемные справочники (справочник «Календарь», классификатор «Документы»), представим отношения между сущностями в виде таблицы 5.2.

      

       Таблица 4.2 - Определение связей между сущностями

Главная

Сущность

Наименование

Отношения

Дочерняя

сущность

Мощность

Категории важности работ

указываются для

Контролируемые работы

один-ко-многим

Признак исполнения

отмечается в

Контролируемые работы

один-ко-многим

Картотека руководителей

используется

Контролируемые работы

один-ко-многим

Функциональные службы

характеризуют

Подразделения ГРПЗ

один-ко-многим

Подразделения ГРПЗ

содержат

Контролируемые работы

один-ко-многим

Картотека руководителей

используется

Контролируемые работы

один-ко-многим

Справочник «Предупреждающие литеры»

соответствует

Контролируемые работы

один-ко-многим

Причины переноса работ

указываются для

Перенесённые работы

один-ко-многим

Документы

указываются в

Контролируемые работы

один-ко-многим

Контролируемые работы

содержат

Перенесённые работы

один-ко-многим

4.6 Определение первичных ключей

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

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

При определении ключевых атрибутов придерживаются ряда правил:

  •  Запрещается использовать в качестве ключа атрибуты, которые могут принимать более одного значения для одного и того же экземпляра сущности (правило неповторяемости);
  •  Запрещается использовать в качестве ключа атрибуты, которые могут принимать более одного значения для разных экземпляров одной и той же сущности (правило уникальности);
  •  Нельзя использовать атрибуты, обращающиеся в ноль, т.е. не принимающие никакого значения (правило не обращения в ноль)
  •  Сущности с составными ключами не могут быть разбиты на несколько сущностей с более простыми ключами (правило наименьшего ключа).

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

Список всех первичных ключей приведён в таблице 4.3.

          Таблица 4.3 - Список первичных ключей сущностей

Название сущности

Название первичного ключа

Контролируемые работы

Номер карточки

Категории важности работ

Код категории важности

Признак исполнения

Код признака исполнения

Причины переноса работ

Код причины переноса

Перенесённые работы

Номер карточки, Номер записи работы

Справочник «Предупреждающие литеры»

Код литеры

Функциональные службы

Код функциональной службы

Подразделения ГРПЗ

Номер записи PS_POD

Картотека руководителей

Номер записи PS_KRUK

Справочник «Календарь»

Номер записи календаря

Документы

Номер записи OS_DOKKL

4.7 Определение атрибутов сущностей и внешних ключей

Атрибуты – это  характеристики объектов (сущностей). Основное назначение атрибута – это  описание свойств сущностей, а также идентификация экземпляров сущностей.

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

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

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

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

Сущности должны удовлетворять следующим условиям:

  •   первой нормальной форме (сущность находится в 1НФ тогда и только тогда, когда все атрибуты содержат атомарные значения; среди атрибутов не должно встречаться повторяющихся групп, т.е. нескольких значений для каждого атрибута);
  •   второй нормальной форме (сущность находится во 2НФ, если она находится в 1НФ и каждый неключевой атрибут полностью зависит от ПК (не должно быть зависимости от части ключа); 2НФ имеет смысл только для сущностей, имеющих сложный ПК);
  •   третьей нормальной форме (сущность находится в ЗНФ, если она находится во 2НФ и никакой неключевой атрибут не зависит от другого не ключевого атрибута (не должно быть взаимосвязи между не ключевыми атрибутами)) [1].

Каждому выявленному атрибуту следует присвоить осмысленное имя, понятное пользователям. Атрибуты, определенные для каждой сущности, представлены в таблице 4.4.


    
Таблица 4.4 - Атрибуты сущностей модели

Наименование сущности

Атрибут сущности

Контролируемые работы

Номер рассыльного листа

Номер документа

Дата документа

Номер пункта

Краткое содержание

Дата постановки на контроль

Срок исполнения

Дата закрытия

Дата и время корректировки

Табельный номер

Категории важности работ

Наименование категории важности

Дата и время корректировки

Табельный номер

Признак исполнения

Наименование признака исполнения

Дата и время корректировки

Табельный номер

Причины переноса работ

Содержание причины

Дата и время корректировки

Табельный номер

Документы

Наименование документа

Код документа

Подразделения ГРПЗ

Наименование подразделения

Признак аннулированного подразделения

Функциональные службы

Код функциональной службы

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

Картотека руководителей

Код структурного подразделения

Табельный номер

Код должности

Наименование должности

Перенесенные работы

Прежний срок исполнения

Номер документа

Дата документа

Дата и время корректировки

Табельный номер

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

Таблица 4.5 -  Внешние ключи сущностей модели

Наименование сущности

Внешний ключ

Родительская сущность

Контролируемые работы

Код признака исполнения

Признак исполнения

Код категории важности  

Категории важности работ

Номер записи OS_DOKKL

Документы

Номер записи PS_POD

Подразделения ГРПЗ

Номер записи PS_KRUK 

Картотека руководителей

Код литеры

Справочник «Предупреждающие литеры»

Подразделения ГРПЗ

Код функциональной

службы

Функциональные службы

Перенесенные работы

Номер карточки

Контролируемые работы

Код причины переноса работ

Причины переноса работ

4.8 Создание логической модели БД

Фактически, все атрибуты, сущности и отношения уже описаны выше. Поэтому, на данном этапе необходимо лишь разместить их на диаграмме, а также установить, на каком домене определен тот или иной атрибут. Домен это совокупность значений, из которых берутся значения атрибутов. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено несколько атрибутов. В понятие домена входит не только тип данных, но и область значения данных [2].

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

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

        Таблица 4.6 – Базовые сущности

N п/п

Название сущности

1

Контролируемые работы

2

Перенесённые работы

3

Признаки исполнения

4

Категории важности

5

Причины переноса

6

Предупреждающие литеры

Логическая модель будет выполнена в соответствии с рисунком 4.15.

Рисунок 4.15 – Логическая модель базы данных на основе базовых сущностей

     Таблица 4.7 – Внешние сущности

N п/п

Название сущности

1

Документы

2

Календарь

3

Функциональные службы

4

Картотека руководителей

5

Подразделения ГРПЗ

      

    С учётом внешних сущностей логическая модель представлена на рисунке 4.16:




Рисунок 4.16 – Логическая модель базы данных


4.9 Создание физической модели БД

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

В качестве СУБД физической БД в данном дипломном проекте, согласно заданию, выбрана СУБД Oracle 10g. Сама модель данных при переходе на физический уровень остается неизменной, только указываются типы данных и имена атрибутов записываются на английском языке. Доменом называется некоторый пул значений, элементы которого выбираются для присвоения значений одному или более атрибутам. На данном этапе определяются домены для всех атрибутов, присутствующих в модели [3].

Описание доменов на физическом уровне приведено в таблице 4.6.

Таблица 4.6 – Домены 

Домен

Тип

NN

Описание

DATET

DATE

  Дата

NUMBERT_1

NUMBER (1)

  Целые числа, не содержащие Null значений в 1 символ

NUMBERT_3

NUMBER(3)

  Целые числа, не содержащие Null значений в 3 символа

NUMBERT_9

NUMBER(9)

  Целые числа, не содержащие Null значений в 9 символ

VARCHART_100

VARCHAR(100)

 Строка символов длиной 100

VARCHART_2

VARCHAR(2)

 Строка символов длиной 2, не содержащие Null

VARCHART_20

VARCHAR(20)

 Строка символов длиной 20

VARCHART_3

VARCHAR(3)

 Строка символов длиной 3, не содержащие Null

VARCHART_30

VARCHAR(30)

 Строка символов длиной 30

VARCHART_40

VARCHAR(40)

 Строка символов длиной 40

VARCHART_6

VARCHAR(6)

 Строка символов длиной 6, не содержащие Null

Структура базовых таблиц на этом уровне представлена в таблицах 4.7 – 4.12.      Поля таблицы «CF_KVR» представлены в таблице 4.7.

Таблица 4.7 - «Категории важности работ» CF_KVR

PK

FK

Поле

Домен

Тип

NN

Описание

 

K_KVR

NUMBERT_1

NUMBER (1)

Код категория важности

 

 

NAIM_KVR

VARCHART_20

VARCHAR(20)

Наименование категории важности

 

 

TABN

VARCHART_6

VARCHAR(6)

Табельный номер (корректировавшего)

 

 

DAT_KOR

DATET

DATE

Дата  и время корректировки

Контролируемые работы имеют категории важности («Код категории важности» K_KVR в файле «Контролируемые работы»   CF_KWORK). Первоначальное заполнение:

– для обычных работ поле  K_KVR=1 ;

– для важных работ, например, по повышению качества изделий, организации производства K_KVR=2;

– для особо важных работ, например, по производству изделий и подготовке запуска новых изделий K_KVR=3.

Поля таблицы «CF_PRISP» представлены в таблице 4.8.

Таблица 4.8 - «Признак исполнения» CF_PRISP

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

NAIM_PRISP

VARCHART_40

VARCHAR(40)

 Наименование признака исполнения

 

PR_ISP

NUMBERT_1

NUMBER (1)

 Признак исполнения

 

 

DAT_KOR

DATET

DATE

 Дата  и время корректировки

 

 

TABN

VARCHART_6

VARCHAR(6)

 Табельный номер

Контролируемая работа обладает  «Признаком исполнения» PR_ISP (в файле «Контролируемые работы» CF_KWORK). Первоначальное заполнение:

– не поставлена на контроль поле PR_ISP=0

– поставлена на контроль поле PR_ISP=1;

- работа с перенесенным сроком исполнения PR_ISP=2;

– работа выполнена PR_ISP=3.

Поля таблицы «CF_KWORK» представлены в таблице 4.9.

Таблица 4.9 - «Контролируемые работы» CF_KWORK

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

N_DOC

VARCHART_30

VARCHAR(30)

 Номер документа

 

 

N_LIST

NUMBERT_3

NUMBER(3)

 Номер рассыльного листа

 

N_KWORC

NUMBERT_9

NUMBER(9)

 Номер карточки

 

 

DAT_ZAKR

DATET

DATE

 Дата закрытия

 

 

DAT_POST

DATET

DATE

 Дата постановки на контроль

 

 

KR_SOD

VARCHART_100

VARCHAR(100)

 Краткое содержание

 

 

N_PUNKT

VARCHART_6

VARCHAR(6)

 Номер пункта

 

 

DAT_DOC

DATET

DATE

 Дата документа (дата издания)

 

 

DAT_KOR

DATET

DATE

 Дата  и время корректировки 

 

 

TABN

VARCHART_6

VARCHAR(6)

 Табельный номер

 

K_KVR

NUMBERT_1

NUMBER(1)

 Код категории важности

 

PR_ISP

NUMBERT_1

NUMBER(1)

 Признак исполнения

 

ID_PS_KRUK

NUMBERT_9

NUMBER(9)

 Номер записи PS_КRUK

(должностное лицо - исполнитель)

 

ID_OS_DOKKL

NUMBERT_9

NUMBER(9)

 Номер записи OS_DOKKL

 

LIT

NUMBERT_1

NUMBER(1)

 Предупреждающая литера

 

 

SR_ISP

DATET

DATE

 Срок исполнения

 

ID_PS_POD

NUMBERT_9

NUMBER(9)

Номер записи PS_POD (подразделение-исполнитель)

 

Поля таблицы «CF_OLDW» представлены в таблице 4.10.

Таблица 4.10 - "Перенесенные работы" CF_OLDW

PK

FK

Поле

Домен

Тип

NN

Описание

 

ID_CF_OLDW

NUMBERT_9

NUMBER(9)

 Номер записи

N_KWORC

NUMBERT_9

NUMBER(9)

 Номер карточки

 

 

TABN

VARCHART_6

VARCHAR(6)

 Табельный номер (корректировавшего)

 

 

DAT_KOR

DATET

DATE

 Дата  и время корректировки

 

 

DAT_OLDW

DATET

DATE

 Прежний срок исполнения

 

K_PRI_PER

VARCHART_2

VARCHAR(2)

 код причины переноса

Поля таблицы «CF_PRI» представлены в таблице 4.11.

Таблица 4.11 - "Причины переноса работ" CF_PRI

PK

FK

Поле

Домен

Тип

NN

Описание

 

K_PRI_PER

VARCHART_2

VARCHAR(2)

 Код причины переноса работы

 

 

S_PRI_PER

VARCHART_100

VARCHAR(100)

 Содержание причины переноса работы

 

 

DAT_KOR

DATET

DATE

 Дата  и время корректировки

 

 

TABN

VARCHART_6

VARCHAR(6)

 Табельный номер

Поля таблицы «CF_LITER» представлены в таблице 4.12.

Таблица 4.12 - справочник «Предупреждающие литеры» CF_LITER

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

NAIM_LIT

VARCHART_100

VARCHAR(100)

 Наименование литеры

 

LIT

NUMBERT_1

NUMBER(1)

 Литера

 

 

DAT_KOR

DATET

DATE

 Дата  и время корректировки

 

 

TABN

VARCHART_6

VARCHAR(6)

 Табельный номер

 

Структура внешних таблиц на этом уровне представлена в таблицах 4.13 –4.17.

   В качестве внешних данных используется автоматизированная система «Кадры» справочник «Календарь» и общесистемный классификатор «Документы» из которых берётся информация о кодах функциональных служб, кодах подразделений, кодах документов (мероприятий) и кодах должностных лиц, ответственных за исполнение и контроль.

Поля таблицы «PS_POD» представлены в таблице 4.13.

Таблица 4.13 -  «Подразделения ГРПЗ» PS_POD

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

NAIM_LIT

VARCHART_100

VARCHAR(100)

 Наименование литеры

 

LIT

NUMBERT_1

NUMBER(1)

 Литера

 

 

DAT_KOR

DATET

DATE

 Дата  и время корректировки

 

 

TABN

VARCHART_6

VARCHAR(6)

 Табельный номер

Поля таблицы «PS_FS» представлены в таблице 4.14.

Таблица 4.14 - «Функциональные службы» PS_FS

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

NAIM_FS

VARCHART_40

VARCHAR(40)

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

 

 

K_FS

VARCHART_3

VARCHAR(3)

 Код функциональной службы

 

ID_PS_FS

NUMBERT_9

NUMBER(9)

 Номер записи функционального подразделения

     

Поля таблицы «PS_KRUK» представлены в таблице 4.15.

Таблица 4.15 - «Картотека руководителей» PS_KRUK

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

OTCH

VARCHART_20

VARCHAR(20)

 Отчество

 

 

IMUA

VARCHART_20

VARCHAR(20)

 Имя

 

 

FAM

VARCHART_20

VARCHAR(20)

 Фамилия

 

 

TABN

VARCHART_6

VARCHAR(6)

Табельный номер 

 

ID_PS_KRUK

NUMBERT_9

NUMBER(9)

 Номер записи PS_КRUK

 

ID_PS_POD

NUMBERT_9

NUMBER(9)

Номер подразделения подчиненного руководителю

      Поля таблицы «OS_DOKKL» представлены в таблице 4.16.

      Таблица 4.16 -  «Документы»  OS_DOKKL

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

NAIM_DOC

VARCHART_40

VARCHAR(40)

 Наименование документа

 

ID_OS_DOKKL

NUMBERT_9

NUMBER(9)

 Номер записи OS_DOKKL

 

 

K_DOK

NUMBERT_3

NUMBER(3)

 Код документа

 

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

Поля таблицы «OS_KALEND» представлены в таблице 4.17.

Таблица 4.17 - справочник "Календарь" OS_KALEND

PK

FK

Поле

Домен

Тип

NN

Описание

 

 

N_DAY

 

NUMBER(4,0)

 Номер дня

 

ID_OS_KALEND

NUMBERT_9

NUMBER(9,0)

 Номер записи

 

 

N_MES

 

NUMBER(2,0)

 Номер месяца

 

 

GOD

 

NUMBER(4,0)

 Год

 

 

PR_DAY

NUMBERT_1

NUMBER(1,0)

 Признак дня

 

 

DATA

 

DATE

   Дата

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

Значение полю «Табельный номер» TABN  берется из системных параметров парольной защиты (заполняется с использованием PAROL файл "Пароли"), а значение «Дата  и время корректировки» DAT_KOR присваивается с таймера сервера БД.

Базовые таблицы, представлены в таблице 4.18.

         Таблица 4.18  - Базовые таблицы

N п/п

Название таблицы

1

Контролируемые работы – «CF_KWORK»

2

Перенесенные работы – «CF_OLDW»

3

Признак исполнения – «CF_PRISP»

4

Категории важности работ – «CF_KVR»

5

Причины переноса работ – «CF_PRI»

6

Предупреждающие литеры – «CF_LITER»

 

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

      Рисунок 4.17 – Физическая модель базы данных на основе базовых сущностей

  Таблица 4.16  - Внешние таблицы

N п/п

Внешние таблицы

1

Документы – «OS_DOKKL»

2

Календарь – «OS_KALEND»

3

Функциональные службы – «PS_FS»

4

Картотека руководителей – «PS_KRUK»

5

Подразделения ГРПЗ – «PS_POD»

 

С учётом внешних таблиц необходимо сформировать физическую модель базы данных, которая представлена в соответствии с рисунком 4.18:


Рисунок 4.18– Физическая модель базы данных


4.10 Прямое проектирование

По конкретной физической схеме модели ERwin можно генерировать физическую схему (системный каталог) для заданной СУБД.

Процесс генерации физической схемы БД из модели данных называется прямым проектированием (Forward Engineering). При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД.

Процесс генерации логической модели из физической БД называется обратным проектированием. Использование этапов обратного и прямого проектирования позволяет перенести структуру данных с одного сервера на другой.

Процесс генерации системного каталога можно провести двумя способами:

  •  Напрямую из Erwin, используя ODBC драйвер.
  •  С помощью Script-файла, не используя ODBC драйвер: генерация осуществляется из оболочки Oracle 10g, но для такого метода появляется необходимость предварительного редактирования файла вручную. Данный способ используется при отсутствии возможности создания ODBC драйвера.

После проектирования БД на физическом уровне необходимо ее создать. Для этого применялось программное средство Oracle 10g. В Oracle для задания операций доступа к данным используются средства языка структурированных запросов – SQL (Structured Query Language). SQL – это язык, способный реализовывать все операции доступа к данным и их обработки.  

Базу данных можно создать с помощью команды:

CREATE DATABASE  database_name.

После создания физической базы данных создаются ее объекты.

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

CREATE TABLE имя_таблицы (<определение_столбца>

[, <определение_столбца> … ] | [<тип_ограничения> …]);

Рисунок 4.19 – Формат оператора CREATE TABLE

Одним из структурных элементов физической памяти, присутствующим в большинстве реляционных СУБД, является индекс. Индекс – это средство, обеспечивающее быстрый доступ к строкам таблицы на основе значений одного или нескольких столбцов. В SQL индекс создается оператором CREATE INDEX, формат которого представлен на рисунке 4.20.

CREATE [UNIQUE] [ASC | DESC] INDEX имя_индекса 

ON имя_таблицы (имя_столбца [, имя_столбца …]);

Рисунок 4.20 – Формат оператора CREATE INDEX

Представление – это виртуальная таблица, создаваемая на основе запроса. Представление, как и реальная таблица, содержит строки и столбцы данных, но данные, видимые в представлении, на самом деле являются результатами запроса. Представления создаются оператором CREATE VIEW, формат которого показан на рисунке 4.21.

CREATE VIEW имя_представления

    [( столбец_представления [, столбец_представления …])]

AS запрос_SELECT [WITH CHECK OPTION];

Рисунок 4.21 – Формат оператора CREATE VIEW

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

Для создания триггера используется оператор CREATE TRIGGER, формат которого представлен на рисунке 4.22

CREATE TRIGGER имя_триггера FOR

{ имя_таблицы | имя_представления } [ACTIVE | INACTIVE]

{ BEFORE | AFTER } { DELETE | INSERT | UPDATE }

[POSITION номер_приоритета_триггера]

AS тело_триггера [ разделитель ]

Рисунок 4.22 – Формат оператора CREATE TRIGGER

Хранимой процедурой (stored procedure) называется скомпилированная программа произвольной длины на процедурном языке SQL, которая хранится в БД как часть метаданных. Синтаксически хранимые процедуры фактически повторяют синтаксис триггеров, которые были рассмотрены выше.

Хранимые процедуры создаются оператором CREATE PROCEDURE, который представлен на рисунке 4.23.

CREATE PROCEDURE имя_процедуры

    [( параметр тип_данных [, параметр тип_данных …])]

[RETURNS ( параметр тип_данных [, параметр тип_данных …])]

AS тело_процедуры [разделитель]

Рисунок 4.23 – Формат оператора CREATE PROCEDURE

Таблицы представляют собой сегменты БД, которые хранят данные. Каждая таблица состоит из одного или нескольких столбцов, каждому из которых назначается имя и тип данных. Для создания таблицы в Oracle используется команда CREATE TABLE. Для поддержания целостности БД на таблицу накладывается ограничение (constraint). Под ограничением понимается условие, которое должно выполняться при хранении, обновлении и добавлении данных в таблицу БД. Для задания ограничений используется оператор ALTER TABLE.

Листинг команд по созданию БД и  ее основных объектов приведены в Приложении.


5 Разработка и описание алгоритмов и методов функционирования информационной системы

Запуск системы осуществляется двойным щелчком левой кнопки мыши на ярлыке «АСКИД». В данном дипломном проекте разработаны следующие алгоритмы и режимы работы:

- Документы;

- Справочники;

- Контролируемые работы;

- Исполнение документов и мероприятий;

- Выход.

Схема алгоритма выполнена в соответствии с рисунком 5.1

Рисунок 5.1 – Схема алгоритма выбора необходимого режима

Схема алгоритма «Документы» приведена в соответствии с рисунком 5.2.    


Рисунок 5.2 – Схема алгоритма «Документы»


Рисунок 5.3 – Схема алгоритма «Документы»

Рисунок 5.4 – Схема алгоритма «Документы»

Рисунок 5.5 – Схема алгоритма «Справочники»

Рисунок 5.6 – Схема алгоритма «Контролируемые работы»


Алгоритм «Исполнение документов» приведён в соответствии с рисунком 5.7.

Рисунок 5.7 – Схема алгоритма «Исполнение документов»

Алгоритм «Выход» приведён в соответствии с рисунком 5.8.

Рисунок 5.8 – Схема алгоритма «Выход»

6 Разработка интерфейса пользователя системы 

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

При проектировании клиентского приложения необходимо выполнить следующие требования:

  1.  Приложение должно обладать дружественным интерфейсом.
  2.  Приложение должно быть удобно  и понятно любому пользователю.
  3.  Приложение должно позволять легко оперировать данными.

Создание клиентского приложения для описываемой информационной системы осуществлялось с использованием среды программирования Visual FoxPro 6.0.

Язык Visual FoxPro является объектно-ориентированным, визуально программируемым, управляемым по событиям. Объектно-ориентированный язык позволяет создавать приложения шаг за шагом, работая в каждый момент времени с одним из объектов. Объектами являются: заголовок таблицы, заголовок столбца, страница, поле, опции, кнопки, группа кнопок, название опции, листаемый список и т.д.

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

Компонентами Visual FoxPro являются таблицы, формы, запросы, отчеты, программы. Часто компоненты, составляющие пользовательское приложение, объединяют в проект. В Visual FoxPro управление проектами осуществляет диспетчер проектов Project Manager. На него возлагаются две основные функции:

- организация файлов для проекта на основе их типа;

- представление контейнера для сбора компонентов приложения с целью их подготовки для компиляции в приложение (расширение .app) или выполняемый файл (расширение .exe).

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

Созданные экранные формы не требуют генерации программных кодов, они сразу готовы для выполнения. Отдельные объекты могут быть объединены посредством меню. Обычно законченное приложение имеет собственное меню, которое заменяет основное меню Visual FoxPro и содержит команды, предназначенные для выполнения конкретных задач. Данная информация позволяет перейти к созданию структуры меню приложения [5].

Для создания строки меню необходимо выполнить следующие действия:

- открыть окно конструктора Visual FoxPro;

- описать пункты меню;

- отобразить эти пункты на экране;

- определить действия, выполняемые при выборе конкретного пункта меню.

Основное меню приложения должно содержать следующие пункты:

  1.  Контролируемые работы (содержит перечень всех контролируемых работ);
  2.  Справочники (содержит перечень используемых справочников и классификаторов);
  3.  Документы (пункт позволяет формировать выходные документы);
  4.  Выход.

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

Для использования в приложении описанного меню из него необходимо сгенерировать программу на языке Visual FoxPro с помощью команды Menu|Generate.

Рассмотрим последовательность действий при определении наименования пунктов основного меню приложения.

  1.  Открыть проект Askid.
  2.  Перейти на вкладку Other и выбрать группу Menus. Создать новое меню с помощью кнопки New окна проекта.
  3.  Выбрать тип меню Menu для создания меню в виде строки.
  4.  В поле Prompt ввести текст первого пункта меню, для добавления очередного пункта использовать кнопку Insert.
  5.  Определить для каждого пункта его тип с помощью элемента из списка Result:

Command ―  выполнение указанной команды (например, выход из системы осуществляется командой Quit);

Submenu ― раскрытие ниспадающего меню;

Procedure ― вызов указанной процедуры;

Pad Name ― никаких действий не выполняется.

Вид основного меню приложения представлен в соответствии с  рисунком 6.1.

Рисунок 6.1 - Вид основного меню приложения

Просмотреть созданное меню позволяет кнопка Preview (рисунок 6.2).

С помощью кнопки Options предоставляется возможность задать дополнительные характеристики данного пункта меню:

- определение клавиш ускоренного действия;

- блокировка команды меню по условию;

- задание сообщения в строке состояния;

- определение комментария к пункту.

Рисунок 6.2 - Просмотр основного меню приложения

Для сохранения созданного меню предназначена команда File/Save as. Для активизации меню используется команда Menu/Generate (рисунок 6.3).

Рисунок 6.3 - Генерация меню

Последовательность действий при определении наименования пунктов подменю приложения аналогична определению пунктам строки меню. Элементы подменю или группы элементов можно разделить горизонтальными линиями для лучшего их восприятия с помощью указания в поле Prompt символа «\-».

В пункте Справочники основного меню присутствуют следующие подменю:

- виды документов;

- должностные лица;

- структура предприятия;

- категории важности работ;

- признак исполнения.

Окно диалога создания подменю Справочники представлено на рисунке 6.4.

Рисунок 6.4 - Окно диалога создания подменю Справочники

Формы являются мощным и гибким средством представления информации. Экранные формы позволяют объединить поля в группы по определенным признакам, что облегчает восприятие информации.

Visual FoxPro дает возможность использования различных технологий для создания экранных форм. В данном дипломном проекте применяется конструктор форм (Form Designer), в котором разрабатываются собственные формы с заданными свойствами для просмотра, ввода и редактирования данных [7].  

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

Для создания новой формы с помощью конструктора форм необходимо в окне проекта Askid выбрать вкладку Documents, перейти в группу Forms и нажать на кнопку New. Окно конструктора форм показано на рисунке 6.5.

Рисунок 6.5 - Окно конструктора форм

Создавать объекты в форме, определять их свойства, а также свойства самой формы удобно с помощью соответствующих панелей инструментов. Отображаемые на экране панели указываются в опциях меню View/Toolbars.

Панель инструментов Form Controls используется для размещения объектов в форме, панель Form Designer содержит кнопки вызова других панелей и выполняет некоторые дополнительные функции управления формой.

Параметры экранной формы, как и любого другого объекта, определяются настройками окна Properties. На рисунок 6.6 показано окно свойств Properties.

Рисунок 6.6 - Окно свойств Properties объекта Grid

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

Рисунок 6.7 - Свойства объекта Combobox

Объект Grid относится к числу сложных объектов, он характеризуется свойствами, относящимися ко всему объекту в целом. В свою очередь он содержит в себе объекты: столбец сolumn, заголовок столбца header и текст text, каждый из которых обладает своими собственными свойствами. Visual FoxPro предоставляет широкие возможности по визуальному оформлению таблиц формы с помощью соответствующих свойств объекта Grid.

Объект группа кнопок Command Group используется в том случае, если необходимо создать сразу несколько управляющих кнопок. Свойство этого объекта Buttoncount определяет количество кнопок или команд, размещаемых в объекте. В данном случае необходимо наличие двух кнопок (элементов) в объекте Commandgroup1: Ввод и Отказ. Название кнопки определяется значением свойства Caption.

Окно свойств данного объекта для элемента Ввод показано на рисунок 6.8.

Рисунок 6.8 - Окно свойств объекта группа кнопок Commandgroup1 для элемента Command1

     


7 Разработка руководства пользователя

Для того чтобы начать работу с системой, необходимо запустить основную программу.  На экране появляется окно «Автоматизированная система исполнения документов» (рисунок 7.1).

Рисунок 7.1 - Окно «Автоматизированная система исполнения документов»

 При нажатии на кнопку «ОК» осуществляется вход в систему, где представлены необходимые поля (рисунок 7.2).

Рисунок 7.2 - Окно системы

В поле «Справочники» можно просмотреть справочник «Категории важности работ», где каждой категории важности соответствует код. (рисунок 7.3).

Рисунок 7.3 - Просмотр справочника «Категории важности работ»

В поле «Справочники» также можно просмотреть справочник «Причины переноса работ», где у каждой причины переноса свой код. (рисунок 7.4).

Рисунок 7.4 - Справочник «Причины переноса работ»

Для добавления записи необходимо нажать кнопку «Добавить» и ввести текст, например «Жаркое лето». На экране появится информация о том, что запись добавлена (рисунок 7.5).

Рисунок 7.5 - Добавление записи в справочник «Причины переноса работ»

При нажатии на кнопку «ОК» на экране появляется новая запись «Жаркое лето» (рисунок 7.6).

Рисунок 7.6 - Добавленная в справочник «Причины переноса работ» запись

При выборе поля «Контролируемые работы» на экране появляется окно «Критерии поиска карточек», где карточку можно выбрать по исполнителю, по документам, по дате издания документа и по ответственному за контроль. Найдем карточку по ее номеру. Для этого выберем поле «Номер карточки» и введем нужный номер (рисунок 7.7).

Рисунок 7.7 - Окно «Критерии поиска карточек»

На экране появляется окно «Контролируемые работы», в котором выведены все данные о необходимой карточке (рисунок 7.8).

Рисунок 7.8 - Окно «Контролируемые работы»

 

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

Рисунок 7.9 - Окно «Ввод новой карточки»

В этом окне необходимо заполнить соответствующие поля и нажать на кнопку «Ввод». При заполнении полей их можно выбрать из выпадающего списка,  например, поле «Наименование и код документа» (рисунок 7.10).

Рисунок 7.10 - Заполнение полей в окне «Ввод новой карточки»

После заполнения всех остальных полей новая карточка будет введена (рисунок 7.11).

Рисунок 7.11 - Заполненные поля в окне «Ввод новой карточки»

Также карточку можно откорректировать. Для этого в окне «Контролируемые работы» следует нажать на кнопку «Корректировка полей». На экране появляется окно «Корректировка полей», где необходимо заполнить поля и нажать кнопку «Ввод» (рисунок 7.12).

Рисунок 7.12 - Окно «Корректировка полей»

Для закрытия карточки в окне «Контролируемые работы» следует нажать на кнопку «Закрытие карточки». На экране появится соответствующее окно, где необходимо заполнить поля и ввести дату закрытия карточки. Затем нажать на кнопку «Ввод» и карточка будет закрыта (рисунок 7.13).

Рисунок 7.13 - Окно «Закрытие карточки»

При выборе в окне системы поля «Документы» на экране появляется окно «Печать документов» (рисунок 7.14).

Рисунок 7.14 - Окно «Печать документов»

В этом окне можно выбирать необходимые документы. Выберем, например, документ  «Сводка об исполнении документов и мероприятий». На экране появляется соответствующий документ (рисунок 7.15).

Рисунок 7.15 Документ  «Сводка об исполнении документов и мероприятий»

8 Тестирование системы

Для проверки работоспособности и оценки эффективности приложения было проведено тестирование программного обеспечения.

При запуске основной программы на экране появляется окно главной формы (рисунок 8.1).

Рисунок 8.1 - Окно главной формы

 

При нажатии на кнопку «ОК» осуществляется вход в систему, где можно выбрать необходимое поле  из соответствующего меню, представленного на рисунке 8.2

Рисунок 8.2 - Окно системы

В поле «Справочники» можно просмотреть справочник «Категории важности работ», где каждой категории важности соответствует код категории важности. При этом в процессе тестирования выявлена ошибка. В открывшемся окне вместо названия «Категории важности работ» введено название  «Календарь» (рисунок 8.3).

Рисунок - 8.3 Просмотр справочника «Категории важности работ»

При выборе поля «Контролируемые работы» на экране появляется окно «Критерии поиска карточек», где карточку можно выбрать по исполнителю, по документам, по дате издания документа и по ответственному за контроль. Найдем карточку по ее номеру. Для этого выберем поле «Номер карточки» и введем нужный номер (рисунок - 8.4).

Рисунок 8.4 - Окно «Критерии поиска карточек»

На экране появляется окно «Контролируемые работы», в котором выведены все данные о необходимой карточке (рисунок 8.5).

Рисунок 8.5 - Окно «Контролируемые работы»

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

Рисунок 8.6 - Окно «Ввод новой карточки»

В этом окне необходимо заполнить соответствующие поля и нажать на кнопку «Ввод». Новая карточка будет введена (рисунок 8.7).

Рисунок 8.7 - Заполненные поля в окне «Ввод новой карточки»

При выборе поля «Документы» на экране появляется окно «Печать документов» (рисунок 7.1.8).

Рисунок 8.8 - Окно «Печать документов»

В этом окне можно выбирать необходимые документы. Выберем, например, «Карточки по исполнителям». На экране появляется форма карточки (рисунок 8.9).

Рисунок 8.9 - Форма карточки

9 Экономическая часть

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

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

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

9.1  Планирование работы при помощи ленточного графика

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

  При разработке программных средств был выполнен следующий перечень работ:

- разработка задания на проект;

- формирование требований к автоматизированной системе управления (АСУ);

- разработка концепций АСУ;

- разработка технического задания на создание АСУ;

- разработка технического проекта;

- разработка и тестирование программы;

- оформление графического материала;

- оформление отчетной документации.

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

T1 = 2 (чел.-дн.)           U1 = 2 (чел.)

T2 = 4 (чел.-дн.)           U2 = 1 (чел.)

T3 = 4 (чел.-дн.)           U3 = 1 (чел.)

T4 = 6 (чел.-дн.)           U4 = 1 (чел.)

T5 = 12 (чел.-дн.)         U5 = 1 (чел.)

T6 = 35 (чел.-дн.)         U6 = 1 (чел.)

T7 = 4 (чел.-дн.)           U7 = 1 (чел.)

T8 = 4 (чел.-дн.)           U8 = 1 (чел.)

Пункт 1 выполняется дипломником совместно с руководителем проекта, пункты 2-8 дипломником. Таким образом, получим следующие продолжительности работ, в соответствии с их перечнем:

Tn1 = 2/2   (дн.);

Tn2 = 4/1   (дн.);

Tn3 = 4/1   (дн.);

Tn4 = 6/1   (дн.);

Tn5 = 12/1 (дн.);

Tn6 = 35/1 (дн.);

Tn7 = 4/1   (дн.);

Tn8 = 4/1   (дн.);

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

Таблица 9.1 - План проектирования программной продукции

Стадии разработки
проекта

Этапы выполнения 
проекта

Длительность,
дней

Длительность,
%

Исполнитель

Техническое предложение

1.Разработка задания
на проект

1

1,43

Руководитель,
инженер

2.Формирование
требований к АСУ

4

5,71

Инженер

3.Разработка технического
задания на создание АСУ

6

8,57

Инженер

Эскизный проект

4.Разработка
концепций АСУ

4

5,71

Инженер

Технический проект

5.Разработка
технического проекта

12

17,1

Инженер

6.Разработка и
тестирование программы

35

50

Инженер

Рабочая документация

7.Оформление
справочного материала

4

5,71

Инженер

8.Оформление
отчетной документации

4

5,71

Инженер

Итого

70

100

 

Таким образом, общее время работы над данным проектом составляет 70 дней, из них ЭВМ использовалась 55 дней.

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

Рисунок 9.1  Ленточный график работ   

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

9.2 Составление сметы затрат на разработку и определение цены на программную разработку

Целью планирования себестоимости проведения НИР является экономически обоснованное определение величины затрат на её выполнение. В плановую себестоимость НИР включаются все затраты, связанные с её выполнением независимо от источника их финансирования.

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

Сметная стоимость разработки складывается из следующих статей калькуляции:

9.2.1 Материальные затраты

К этой статье относятся материалы, используемые при проектировании. Перечень материалов, цена, стоимость без учета НДС приведены в Таблице 9.2.

Таблица 9.2 - Расходные материалы.

Наименование
материала

Количество

Цена за единицу
без НДС, руб.

Цена за единицу
с НДС, руб.

Сумма, руб.

CD-R диск

1 шт.

18,04

22

22

Ручка

3 шт.

8,2

10

30

Бумага офисная

1 упаковка

123

150

150

Чернила для принтера

1 упаковка

106,6

130

130

ИТОГО:

332

9.2.2 Затраты на оплату труда

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

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

В данном проекте эта статья складывается из затрат на заработную плату исполнителей (руководителя проекта и инженера). Расчет основной заработной платы будет производиться условно, учитывая, что работа выполнялась инженером с окладом 10000 руб., а заработная плата руководителя проекта составляет 15000 руб.:

ЗПосн = Sрп + Sс , где

Sрп – расходы на оплату труда руководителя проекта;

Sс – расходы на оплату труда студента.

Время работы руководителя над дипломным проектом – 2 дня, а инженера – 70 дней. Тогда расходы на оплату труда будут определяться следующим образом:

SРП = 15000*2/21 = 1428,6 руб.

SС =  10000*68/21 = 32380,9 руб.

Таким образом, основная заработная плата составит:

ЗПОСН = 1428,6+ 32380,9  = 33809,5 руб.

Дневная заработная плата рассчитывается исходя из месячной оплаты и известного числа рабочих дней в месяце, принимаемого равным 21 дням. Время работы руководителя над проектом – 2 дня, а инженера – 68 дней. Тогда расходы на оплату труда будут определяться следующим образом:

Таблица 9.3 - Расходы на оплату труда

Оклад,
руб.

Число рабочих
дней (в месяце)

Дневная ставка,
руб.

Трудоемкость,
чел/дн.

Суммарная
зар. плата, руб.

Руководитель
проекта

15000

21

714,3

2

1428,6

Инженер

10000

21

476,2

68

32380,9

Итого

33809,5

9.2.3 Отчисления на социальные нужды

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

Они составляют 30 % от заработной платы.

Осн= 0.3*ЗПосн = 0.3*33809,5= 10142,8 руб.

9.2.4 Амортизация основных фондов

Сюда входят расходы, связанные со стоимостью машинного времени, затраченного на разработку и отладку программы. Она определяется на основе стоимости одного машинного часа и времени эксплуатации ЭВМ, учитывая также реальную стоимость ЭВМ, стоимость лицензии Visual FoxPro и стоимость электроэнергии. Стоимость одного машинного часа ЭВМ рассчитывается по формуле:

Смч = Смв / Кмч + Тэл * Мпотр, где

Кмч = 2016 – количество машинных часов в году (при пятидневной рабочей неделе и 8-часовом рабочем дне с учетом праздников);

Тэл =3,45 руб. за 1кВт/ч – тариф на электроэнергию;

Мпотр = 0.45 кВт – потребляемая ЭВМ мощность;

Смв – стоимость машинного времени, которую определим как:

Смв = Ао + Зэвм, гдеАо– амортизационные отчисления, Зэвм – затраты на эксплуатацию, ремонт, обслуживание ЭВМ (примем условно в размере 50 % от Ао).

Ао рассчитываем по формуле:

Ао= На*Сэвм /100 + На*Спо, где

На – норма амортизации ЭВМ, принятая в соответствии с положением «О единых нормах амортизационных отчислений на полное восстановление основных фондов». Для ЭВМ, используемых при разработке проекта, норма амортизации составляет 16%.

Сэвм – балансовая стоимость ЭВМ (на март 2014 года составляет 12800 рублей).

Спо – балансовая стоимость лицензии на Visual FoxPro (на март 2014 года составляет 10000 рублей).

Тогда,

Ао = На*Сэвм /100 + На*Спо = 0.16*12800 + 0.16*10000 = 3648 руб.

Смв= Ао + Зэвм = 3648 + 0.5∙3648 = 5472 руб.

Смч = Смв / Кмч + Тэл *Мпотр =5472 / 2016 + 3,45*0.45 = 4,3 руб.

Затраты на машинное время определяются с учетом стоимости машинного часа и общего времени использования ЭВМ:

Змв = Смч * Nмч, где

Смч – стоимость одного часа машинного времени;

Nмч – количество часов рабочего времени, когда использовалась ЭВМ.

ЭВМ использовалась 55 дней в среднем по 7 часов в день, то есть общее количество времени составило Nмч= 385 часов. Тогда

Змв = Смч*Nмч = 4,3*385 = 1655,5 руб.

9.2.5 Накладные расходы

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

Примем, что данные расходы составляют 35 % от основной заработной платы, тогда

Нр= 0,35*33809,5= 11833,3 руб.

Смета затрат на разработку данного проекта приведена в Таблице 9.4.

Таблица 9.4 - Смета затрат на разработку проекта

Наименование
статьи

Затраты,
руб.

Доля,
%

1

Материальные
затраты

332

0,6

2

Основная
заработная плата

33809,5

58,5

3

Отчисления на
социальные нужды

10142,8

17,5

4

Амортизационные
отчисления

1655,5

2,9

5

Накладные расходы

11833,3

20,5

ИТОГО:

57773,1

100

Таким образом, сметная стоимость составляет:

Сп= Зм + ЗПосн + Осн + Звм + Нр = 332 + 33809,5 + 10142,5+ 1655,5 + 11833,3= 57773,1руб.

9.3 Экономическая эффективность разработки

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

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

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

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

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

Непосредственно, экономический эффект от внедрения информационной системы очевиден. Рассмотрим такой параметр, как трудоёмкость, по которому можно определить необходимость создания разработки. Вначале, до создания информационной системы, контроль над исполнением распорядительных документов ГРПЗ велся ручным способом и проходил в несколько стадий. После создания и внедрения ПО, трудоемкость значительно уменьшилась.

В ходе сравнения двух вариантов систем удалось определить, что, разработанное программное обеспечение является экономически эффективным по сравнению с ручным вариантом исполнения. А именно на обработку одного распорядительного документа в ручную тратилось порядка 57 минут, а теперь 3 минуты.  Это нашло подтверждение и в графике, показанном на рисунке  9.2.

Рисунок 9.2 - Распределение трудоемкости

За год на предприятии выпускается порядка 2000 приказов, в каждом из которых выставляется по 10 карточек для разных подразделений. На подсчёт коэффициента исполнительности в месяц вручную требуется 5 рабочих дней, а для формирования выходных документов 10 дней. Итого 15 рабочих дней. При учёте,  что в месяце 21 рабочий день, а средняя зарплата инженера 15000 рублей, получаем, что на оплату данных работ в месяц тратится 10715 рублей. Т.е. в год тратится 128572 рубля. Получается наше ПО окупается за 6 месяцев.

Помимо этого, за счёт внедрения данной АСУ, предприятие получает такой показатель, как актуальность информации.

Можно однозначно сказать, что предприятие  сможет повысить эффективность контроля за исполнением распорядительных документов:

- своевременное доведение до исполнителей требований приказов, указаний, заданий и поручений;

- своевременное развертывание работ исполнителем;

- своевременное выявление наметившихся отставаний и принятие оперативных мер по их ликвидации;

- анализа и воздействия на ход исполнения заданий и поручений;

- обеспечение гласности результатов контроля.

10 Безопасность и экологичность проекта

Помещение, где разрабатывается и будет эксплуатироваться данный программный продукт, имеет площадь приблизительно 57 м2. Высота потолка 3,5 метра. В указанном помещении располагается пять рабочих мест, что удовлетворяет требования СанПиН 2.2.2/2.4.1340-03, по которому на одно рабочее место с ПЭВМ должно приходиться не менее 4,5 м2.  

Рабочее место студента оснащено следующим оборудованием: рабочий стол, стул; персональный компьютер в стандартной комплектации (системный блок, дисплей, клавиатура, манипулятор типа «мышь»), а также адаптеры к устройствам периферии. Питание средств вычислительной техники осуществляется от одной из фаз трёхфазной цепи переменного тока (380В/220 В, 50 Гц) с глухозаземлённой нейтралью.

В помещении бетонные стены, паркетный пол и оштукатуренный потолок. Стены в помещении окрашены в светло-зеленый цвет, что также соответствует СанПиН -181-70«Указания по проектированию цветовой отделки интерьеров ипроизводственных зданий промышленных»:цвета стен, потолка, пола гармонируют между собой.

Для устранения возможности засветки экрана дисплея оконные проёмы в помещении должны быть оборудованы регулируемыми устройствами типа жалюзи или занавесей.

10.1 Выявление опасных факторов, влияющих на оператора ПЭВМ

10.1.1 Анализ условий труда на рабочем месте оператора ПЭВМ

При работе с ПЭВМ на пользователя могут воздействовать следующие физические факторы:

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

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

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

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

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

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

10.1.2 Воздушная среда в помещениях с ПЭВМ

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

Работа с ПЭВМ по общим энергозатратам относится к лёгким физическим работам с энергозатратами до 120 ккал/час (категория Iа).

Если работа на ПЭВМ является основной, должны обеспечиваться только оптимальные нормы микроклимата для помещений в соответствии с Таблицей 10.1:

Таблица 10.1 - Оптимальные нормы микроклимата для помещений СанПиН 2.2.4.548-96 «Гигиенические требования к микроклимату производственных помещений»[

Период
года

Категория работ

Температура
воздуха

Температура
поверхностей, С

Относительная
влажность, %

Скорость движения
воздуха, м/с

Холодный

22-24

21-25

40-60

0,1

(20-25)

(19-26)

(15-75)

-0,1

Тёплый

23-25

22-26

40-60

0,1

(21-28)

(20-29)

(15-75)

(0,1-0,2)

Хорошим способом поддержания оптимальных параметров микроклимата является вентиляция и кондиционирование воздуха, согласно СНиП 41-01-2003 «Отопление, вентиляция и кондиционирование», позволяющие производить также очистку воздуха от вредных веществ и создавать небольшое избыточное давление для исключения поступления неочищенного воздуха в помещение с ПЭВМ.

10.1.3 Опасность поражения электрическим током

Вызвана тем, что все оборудование лаборатории питается от одной из фаз трехфазной сети переменного тока (380/220В, 50 Гц). В процессе эксплуатации или проведения профилактических работ человек может коснуться частей, находящихся под напряжением.

ГОСТом 12.1.038-82 * «Предельно допустимые уровни напряжения прикосновения и токов» установлены предельно допустимые уровни напряжения прикосновения и тока, протекающего через тело человека. Меры защиты приведены в ГОСТ 12.1.038-82 * «ССБТ. Электробезопасность. Предельно допустимые уровни напряжений прикосновения и токов»,

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

Так как используется сеть с глухозаземленной нейтралью 220В, то согласно ПУЭ применяется такая защитная мера, как зануление.

ПЭВМ – это устройство бытового назначения и общего применения, поэтому по классификации ГОСТ 12.2.006-87 * место работы относится к помещениям первого класса (без повышенной опасности). Согласно ПУЭ-03 это сухое, беспыльное помещение с нормальной температурой воздуха (до 35С) и с изолирующими полами.

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

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

Электропроводки должны выполняться в соответствии с требованиями ПУЭ-03. Устройство распределительных щитов и пультов питания производится в соответствии с ПУЭ-03. Ограничивается доступ к токоведущим частям в них. Все распределительные щиты и пульты питания должны быть снабжены кнопками аварийного отключения. На входе учебной лаборатории устанавливается устройство защитного отключения (УЗО) с дифференциальным током до 30 мА.

10.1.4 Повышенный уровень шума

Повышенный уровень шума в помещении обусловлен работой системных блоков. В настоящее время нормы допустимого шума на рабочем месте регламентируются СН 2.2.4/2.1.8.562-96 «Шум на рабочих местах, в помещениях жилых, общественных зданий и на территории жилой застройки». При выполнении основной работы на ПЭВМ уровень шума на рабочем месте не должен превышать 50дБА.

Снизить уровень шума в помещениях с ПЭВМ можно использованием для отделки помещений звукопоглощающих материалов с максимальными коэффициентами звукопоглощения в области частот 63-8000 Гц, подтверждёнными специальными акустическими расчётами.

10.1.5 Неблагоприятные условия зрительной работы

Недостаточная освещённость рабочего места приводит к тому, что человек быстро устаёт и работает менее продуктивно. Кроме того, возрастает опасность ошибочных действий и несчастных случаев. Работа на ПЭВМ может осуществляться при наличии естественного и искусственного освещения. Величина коэффициента естественной освещённости должна соответствовать нормативным уровням по СНиП 23.05-95 "Естественное и искусственное освещение". Освещённость на поверхности стола в зоне размещения рабочего документа от системы общего освещения должна быть 300-500 лк.

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

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

В качестве источников света общего освещения следует применять преимущественно люминесцентные лампы мощностью 36-65 Вт типа ЛБ, а в качестве светильников – газоразрядные лампы с высокочастотными пускорегулирующими аппаратами (ВЧ ПРА). Коэффициент запаса для осветительных установок общего освещения должен приниматься равным 1,4. Коэффициент пульсаций не должен превышать 5%.

Яркость светильников общего освещения в зоне углов излучения от 50 до 90 градусов с вертикалью в продольной и поперечной плоскостях должна составлять не более 200 кд/м2, защитный угол светильников – не менее 40 град.

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

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

10.1.6 Электромагнитное излучение ПЭВМ

Современная ПЭВМ является энергонасыщенным аппаратом с потреблением электроэнергии до 350-450 Вт, создаёт вокруг себя поля, такие как электростатическое поле, переменные низкочастотные электрические поля и переменные низкочастотные магнитные поля.

Потенциально возможными вредными факторами могут быть также рентгеновское и ультрафиолетовое излучение ЭЛТ дисплея ПЭВМ; ЭМИ радиочастотного диапазона; электромагнитный фон промышленной частоты 50 Гц. Рентгеновское и ультрафиолетовое излучение экранов мониторов очень незначительны. Излучение радиочастотного диапазона от современных ПЭВМ также существенно ниже предельно допустимых уровней, регламентируемых санитарными нормами.

С учётом стандартов Госсанэпиднадзор России разработал и ввёл в действие СанПиН 2.2.2/2.4.1340-03, нормы по электрическим и магнитным полям.

Существует СанПиН 2.2.412.1.8.055-96 «Электромагнитное излучение радиочастотного диапазона», который устанавливает нормы по электрическим и магнитным полям для частот свыше 400 кГц.

10.1.7 Организация и оборудование рабочих мест

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

Схемы размещения рабочих мест, согласно СанПин 2.2.2/2.4.1340-03 , с персональными компьютерами должны учитывать расстояния между рабочими столами с мониторами: расстояние между боковыми поверхностями мониторов не менее 1,2 м, а расстояние между экраном монитора и тыльной частью другого монитора не менее 2,0 м.

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

Глубина рабочей поверхности стола должна составлять 800 мм (допускаемая не менее 600 мм), ширина — соответственно 1 600 мм и 1 200 мм. Рабочая поверхность стола не должна иметь острых углов и краев, иметь матовую или полуматовую фактору.

Рабочий стол должен иметь пространство для ног высотой не менее 600 мм, шириной — не менее 500 мм, глубиной на уровне колен — не менее 450 мм и на уровне вытянутых ног — не менее 650 мм.

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

Клавиатура должна располагаться на поверхности стола на расстоянии 100-300 мм от края, обращенного к пользователю.

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

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

Конструкция стула должна обеспечивать:

ширину и глубину поверхности сиденья не менее 400 мм;

поверхность сиденья с закругленным передним краем;

регулировку высоты поверхности сиденья в пределах 400-550 мм и углом наклона вперед до 15 градусов и назад до 5 градусов.;

высоту опорной поверхности спинки 300±20 мм, ширину — не менее 380 мм и радиус кривизны горизонтальной плоскости 400 мм;

угол наклона спинки в вертикальной плоскости в пределах 0±30 градусов;

регулировку расстояния спинки от переднего края сидения в пределах 260-400 мм;

стационарные или съемные подлокотники длиной не менее 250 мм и шириной 50-70 мм;

регулировку подлокотников по высоте над сиденьем в пределах 230±30 мм и внутреннего расстояния между подлокотниками в пределах 350-500 мм.;

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

Рабочее место должно быть оборудовано подставкой для ног, имеющей ширину не менее 300 мм, глубину не менее 400 мм, регулировку по высоте в пределах до 150 мм и по углу наклона опорной поверхности подставки до 20 град. Поверхность подставки должна быть рифленой и иметь по переднему краю бортик высотой 10 мм.

10.1.8 Режим труда и отдыха при работе с компьютером

Режим труда и отдыха предусматривает соблюдение определенной длительности непрерывной работы на ПК и перерывов, регламентированных СанПин 2.2.2/2.4.1340-03, с учетом продолжительности рабочей смены, видов и категории трудовой деятельности.

Виды трудовой деятельности на ПК разделяются на 3 группы: группа А — работа по считыванию информации с экрана с предварительным запросом; группа Б — работа по вводу информации; группа В — творческая работа в режиме диалога с ПК .

Если в течение рабочей смены пользователь выполняет разные виды работ, то его деятельность относят к той группе работ, на выполнение которой тратится не менее 50% времени рабочей смены.

Категории тяжести и напряженности работы на ПК определяются уровнем нагрузки за рабочую смену: для группы А — по суммарному числу считываемых знаков; для группы Б — по суммарному числу считываемых или вводимых знаков; для группы В — по суммарному времени непосредственной работы на ПК. В таблице приведены категории тяжести и напряженности работ в зависимости от уровня нагрузки за рабочую смену.

Виды категорий трудовой деятельности с ПК

Категория работы по тяжести и напряженности

Уровень нагрузки за рабочую смену при видах работы на ПК

Группа А

Количество

знаков

Группа Б

Количество знаков

Группа В

Время работы, ч

I

II

III

До 20000

До 40000

До 60000

До 15000

До 30000

До 40000

До 2,0

До 4,0

До 6,0

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

При 8-часовой рабочей смене и работе на ПК регламентированные перерывы следует устанавливать:

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

для второй категории работ — через 2 часа от начала рабочей смены и через 1,5-2,0 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы;

для третьей категории работ — через 1,5- 2,0 часа от начала рабочей смены и через 1,5-2,0 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.

При 12-часовой рабочей смене регламентированные перерывы должны устанавливаться в первые 8 часов работы аналогично перерывам при 8-часовой рабочей смене, а в течение последних 4 часов работы, независимо от категории и вида работ, каждый час продолжительностью 15 минут.

Продолжительность непрерывной работы на ПК без регламентированного перерыва не должна превышать 2 часа.

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

Эффективными являются нерегламентированные перерывы (микропаузы) длительностью 1-3 минуты.

Регламентированные перерывы и микропаузы целесообразно использовать для выполнения комплекса упражнений и гимнастики для глаз, пальцев рук, а также массажа. Комплексы упражнений целесообразно менять через 2-3 недели.

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

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

Не допускаются к работе на ПК женщины со времени установления беременности и в период кормления грудью.

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

Для снятия усталости аккомодационных мышц и их тренировки используются компьютерные программы типа Relax.

Интенсивно работающим целесообразно использовать такие новейшие средства профилактики зрения, как очки ЛПО-тренер и офтальмологические тренажеры ДАК и «Снайпер-ультра».

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

10.2 Обеспечение пожарной безопасности

10.2.1 Оценка пожароопасности объекта

Согласно нормам пожарной безопасности «Определение категорий помещений, зданий и наружных установок по взрывопожарной и пожарной опасности» (НПБ 105-03) помещения по взрывопожарной и пожарной опасности подразделяются на категории А, Б, В1 — В4, Г и Д, а здания  - на категории А, Б, В, Г и Д.

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

Разделение помещений на категории В1 — В4: определение пожароопасной категории помещения осуществляется путем сравнения максимального значения удельной временной пожарной нагрузки (далее по тексту — пожарная нагрузка) на любом из участков с величиной удельной пожарной нагрузки, приведенной в таблице 10.4.

Таблица 10.4 – Удельная пожарная нагрузка

Категория помещения

Удельная пожарная нагрузка g на участке, МДжм-2

В1

Более 2200

В2

1401 — 2200

В3

181 1400

В4

1 180

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

где Gi   количество i-го материала пожарной нагрузки, кг;

   Qpнiнизшая теплота сгорания i-го материала пожарной нагрузки, МДжкг-1.

Удельная пожарная нагрузка g, МДжм-2, определяется из соотношения

g = ,

где S площадь размещения пожарной нагрузки, м2 (но не менее 10 м2).

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

Помещения с ПЭВМ чаще всего относятся к пожароопасным категории В.

В помещении и на рабочем месте оператора присутствуют следующие возгорающиеся предметы: на окне висят шторы, столы изготовлены из дерева, на столах находится большое количество бумаги, пластиковых предметов (клавиатура, манипулятор типа «мышь», части корпуса ПЭВМ и сетевого фильтра).

Рассчитаем удельную пожарную нагрузку для помещения. Комната площадью 57 м2  в которой имеется:

7 деревянных столов;

7 металлических стульев с сиденьями, обтянутыми тканью;

7 компьютеров (каждый из которых состоит из: системного блока, монитора, клавиатуры и мыши);

стены оштукатурены и покрашены краской;

на полу паркет;

деревянная дверь;

деревянные плинтуса;

окно с деревянной рамой.

Затем рассчитываем удельную пожарную нагрузку и определяем категорию помещения по пожаро- и взрывоопасности согласно изложенной методике (НПБ 105-03).

Пожарная нагрузка будет равна:

Удельная пожарная нагрузка составит:

Это значение соответствует категории В4.

10.2.2 Причины возникновения пожаров и мероприятия по их устранению

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

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

Организационно-технические мероприятия должны включать:

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

Мероприятия режимного характера - это запрещение курения в неустановленных местах, производства сварочных и других огнеопасных работ в пожароопасных помещениях и т.д.

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

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

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

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

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

Пожарная безопасность должна обеспечиваться системами предотвращения пожара и противопожарной защиты в соответствии с ГОСТ 12.1.004-91 «Пожарная безопасность. Общие требования».

В качестве пожарных извещателей выбираем 12 тепловых датчиков типа ИП-103М-5АС; в качестве средств пожаротушения – один углекислотный огнетушитель ОУ-5.

Для предотвращения возникновения пожара на рабочем месте необходимо соблюдение правил пожарной безопасности (ППБ-03), кроме того, действует федеральный закон «О пожарной безопасности» № 69-ФЗ (от 21.12.1994г.).

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

10.3 Экологичность проекта

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


Заключение

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

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

Автоматизированная система контроля исполнения распорядительных документов выполнила следующие функции:

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

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

Список используемых источников

  1.  Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. М.: «Диалог МИФИ», 2010. – 255с.
  2.  Создание логических моделей в ERwin: Методические указания к практическим занятиям/ Рязан. гос. радиотехн. университет: Сост. В.Е. Борзых, А.В. Борзых. Рязань, 2010. – 12с.
  3.  Создание физических моделей в ERwin: Методические указания к практическим занятиям/ Рязан. гос. радиотехн. университет: Сост. В.Е. Борзых, А.В. Борзых. Рязань, 2011. – 12с.
  4.  Создание баз данных: Методические указания к теме/ Рязан. гос. радиотехн. акад.: Сост. В.Е. Борзых. Рязань, 2002. – 24с.
  5.  Менахем Базиян, использование Visual FoxPro 6.0. Специальное издание: Пер. с англ. – М.: Издательский дом «Вильямс», 2011.
  6.  Майкл Эбби, Майкл Корн, Oracle 10g: Первое знакомство. Пер. с англ. – М.: Издательский дом «Лори», 2012.
  7.  http://www.codenet.ru/ – Все для программиста.
  8.  http://www.realcoding.net/ – Программирование для всех. Статьи для программиста, учебники, книги, документация, форум.
  9.  http://md-it.ru/ – сайт компании Meijin. КИС Монополия, автоматизированные системы управления бизнесом, управление предприятием.
  10.  Искусственное освещение: Методические указания к дипломному проектированию/ В.Е. Болтнев, Л.Н. Юдаева; Рязан. гос. радиотехн. акад.: Рязань, 2002. – 32с.
  11.  Обеспечение безопасности пользователя при работе с ПЭВМ: Учебное пособие/ Сост. Зайцев Ю.В., Кремнев В.И. – Рязань: РГРТА, 2001. – 68с.
  12.  Безопасность и экологичность проекта: Методические указания для дипломников/ Сост. Зайцев Ю.В. – Рязань: РРТИ, 2006. – 24с.


Аннотация

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


Приложение А.

Листинг команд создания основных объектов базы данных

/***************************************************************************/

/***             Generated 31.03.2014 15:08:24                   ***/

/***************************************************************************/

SET SQL DIALECT 3;

SET NAMES WIN1251;

CONNECT 'localhost:D:\BDTEST_FOR_DIPLOM.gdb' USER 'SYSDBA' PASSWORD 'masterke';

/***************************************************************************/

/***                                Domains                              ***/

/***************************************************************************/

CREATE DOMAIN DATA_TYPE AS

DATE ; 

CREATE DOMAIN NUMBER1_TYPE AS

INTEGER

NOT NULL

CHECK (VALUE >= 1);

CREATE DOMAIN NUMBER3_TYPE AS

INTEGER;

CREATE DOMAIN NUMBER9_TYPE AS

INTEGER

NOT NULL

CHECK (VALUE >= 1);

CREATE DOMAIN VARCHAR6_TYPE AS

VARCHAR(6) ;

CREATE DOMAIN VARCHAR40_TYPE AS

VARCHAR(40) ;;

CREATE DOMAIN VARCHAR100_TYPE AS

VARCHAR(100) ;

/***************************************************************************/

/***                               Generators                            ***/

/***************************************************************************/

CREATE GENERATOR CF_KVR_GEN;

SET GENERATOR CF_KVR_GEN TO 5;

CREATE GENERATOR CF_KWORC_GEN;

SET GENERATOR CF_KWORC_GEN TO 188;

CREATE GENERATOR CF_LITER_GEN;

SET GENERATOR CF_LITER_GEN TO 6;

CREATE GENERATOR CF_OLDW_GEN;

SET GENERATOR CF_OLDW_GEN TO 8;

CREATE GENERATOR DELIVERY_ITEM_GEN;

SET GENERATOR DELIVERY_ITEM_GEN TO 6;

CREATE GENERATOR CF_PRI_GEN;

SET GENERATOR CF_PRI_GEN TO 5;

CREATE GENERATOR CF_PRICP_GEN;

SET GENERATOR CF_PRICP_GEN TO 3;

CREATE GENERATOR OS_DOKKL_GEN;

SET GENERATOR OS_DOKKL_GEN TO 24;

CREATE GENERATOR OS_KALEND;

SET GENERATOR OS_KALEND TO 0;

CREATE GENERATOR PS_FS_GEN;

SET GENERATOR PS_FS_GEN TO 3;

CREATE GENERATOR PS_KRUK_GEN;

SET GENERATOR PS_KRUK_GEN TO 163;

CREATE GENERATOR PS_POD_GEN;

SET GENERATOR PS_POD_GEN TO 31;

/***************************************************************************/

/***                               Exceptions                            ***/

/***************************************************************************/

CREATE EXCEPTION ERWIN_CHILD_DELETE_RESTRICT 'Cannot DELETE Child table because Parent table does not exist.';

CREATE EXCEPTION ERWIN_CHILD_INSERT_RESTRICT 'Cannot INSERT Child table because Parent table does not exist.';

CREATE EXCEPTION ERWIN_CHILD_UPDATE_RESTRICT 'Cannot UPDATE Child table because Parent table does not exist.';

CREATE EXCEPTION ERWIN_PARENT_DELETE_RESTRICT 'Cannot DELETE Parent table because Child table exists.';

CREATE EXCEPTION ERWIN_PARENT_INSERT_RESTRICT 'Cannot INSERT Parent table because Child table exists.';

CREATE EXCEPTION ERWIN_PARENT_UPDATE_RESTRICT 'Cannot UPDATE Parent table because Child table exists.';

SET TERM ^ ;

/***************************************************************************/

/***                                 Tables                              ***/

/***************************************************************************/

CREATE TABLE CF_KVR (

   TABN      VARCHAR6 NOT NULL,

   DAT_KOR   DATE NOT NULL,

   NAIM_KVR  V40 NOT NULL,

   K_KVR     N1 NOT NULL

);

CREATE TABLE CF_KWORC (

   N_KWORK     NUMBER9_TYPE NOT NULL,

   N_LIST      NUMBER3_TYPE,

   N_DOC       VARCHAR40_TYPE,

   DAT_ZAKR    DATE,

   SR_ISP      DATE,

   DAT_POST    DATE,

   KR_SOD      VARCHAR100_TYPE,

   N_PUNKT     VARCHAR6_TYPE,

   DAT_DOC     DATE,

   TAB_N       VARCHAR40_TYPE,

   DAT_KOR     DATE,

   LIT         VARCHAR40_TYPE NOT NULL,

   K_KVR       NUMBER1_TYPE NOT NULL,

   PR_ISP      NUMBER1_TYPE NOT NULL,

   ID_OS_DOKK  NUMBER9_TYPE NOT NULL,

   ID_PS_POD   VARCHAR6_TYPE NOT NULL,

   ID_PS_KRUK  N NUMBER9_TYPE NOT NULL

);

CREATE TABLE CF_LITER (

   TABN      VARCHAR6_TYPE,

   DAT_KOR   DATE,

   NAIM_LIT  VARCHAR100_TYPE,

   LIT       VARCHAR40_TYPE

);

CREATE TABLE CF_OLDW (

   TABN        VARCHAR6_TYPE,

   DAT_KOR     DATE,

   DAT_DOC     DATE,

   N_DOC       VARCHAR40_TYPE,

   DAT_OLDW    DATE,

   ID_CF_OLDW  NUMBER9_TYPE NOT NULL,

   K_PRI_PER   NUMBER9_TYPE NOT NULL,

   N_KWORK     NUMBER9_TYPE NOT NULL

);

CREATE TABLE CF_PRI (

   TABN       VARCHAR6_TYPE,

   DAT_KOR    VARCHAR6_TYPE,

   S_PRI_PER  VARCHAR100_TYPE,

   K_PRI_PER  NUMBER3_TYPE

);

CREATE TABLE CF_PRICP (

   PR_ISP      NUMBER1_TYPE NOT NULL,

   TABN        VARCHAR6_TYPE,

   DAT_KOR     DATE,

   NAIM_PRISP  NUMBER1_TYPE

);

CREATE TABLE OS_DOKKL (

   K_DOC       VARCHAR6_TYPE,

   NAIM_DOC    VARCHAR40_TYPE,

   ID_OS_DOKK  NUMBER9_TYPE NOT NULL

);

CREATE TABLE OS_KALEND (

   N_DAY       NUMBER3_TYPE,

   ID_OS_KALE  NUMBER9_TYPE NOT NULL,

   ID_OS_ORGL  NUMBER9_TYPE,

   PR_DAY      NUMBER1_TYPE,

   DATA        DATE,

   GOD         NUMBER(4),

   N_MES       NUMBER(2)

);

CREATE TABLE PS_FS (

   NAIM_FS   VARCHAR40_TYPE,

   KS_FS     VARCHAR(3),

   ID_PS_ES  NUMBER9_TYPE NOT NULL

);

CREATE TABLE PS_KRUK (

   NAIM_KDOL   VARCHAR40_TYPE,

   K_DOP       VARCHAR40_TYPE,

   OTCH        VARCHAR40_TYPE,

   IMYA        VARCHAR40_TYPE,

   FAM         VARCHAR40_TYPE,

   TABN        VARCHAR6_TYPE,

   KSP         VARCHAR(3),

   ID_PS_KRUK  NUMBER9_TYPE NOT NULL

);

CREATE TABLE PS_POD (

   PRAN       V1,

   NAIM_KSP   VARCHAR100_TYPE,

   KSP        VARCHAR(3),

   ID_PS_POD  VARCHAR40_TYPE NOT NULL,

   KS_FS      VARCHAR(3) NOT NULL

);

/***************************************************************************/

/***                              Primary Keys                           ***/

/***************************************************************************/

ALTER TABLE CF_OLDW ADD CONSTRAINT XPKE_4 PRIMARY KEY (ID_CF_OLDW, N_KWORK);

ALTER TABLE CF_PRICP ADD CONSTRAINT XPKE_2 PRIMARY KEY (PR_ISP);

ALTER TABLE OS_DOKKL ADD CONSTRAINT XPKE_11 PRIMARY KEY (ID_OS_DOKK);

ALTER TABLE OS_KALEND ADD CONSTRAINT XPKE_12 PRIMARY KEY (ID_OS_KALE);

ALTER TABLE PS_KRUK ADD CONSTRAINT XPKPS_KRUK PRIMARY KEY (ID_PS_KRUK);

ALTER TABLE PS_POD ADD CONSTRAINT XPKE_8 PRIMARY KEY (ID_PS_POD);

ALTER TABLE CF_KWORC ADD CONSTRAINT XPKE_12 PRIMARY KEY (N_KWORK);

ALTER TABLE CF_KVR ADD CONSTRAINT XPKPS_KRUK PRIMARY KEY (K_KVR);

ALTER TABLE CF_PRI ADD CONSTRAINT XPKE_8 PRIMARY KEY (K_PRI_PER  );

/***************************************************************************/

/***                              Foreign Keys                           ***/

/***************************************************************************/

ALTER TABLE CF_KWORC ADD CONSTRAINT ISPOLZUYUT FOREIGN KEY (ID_PS_KRUK) REFERENCES PS_KRUK (ID_PS_KRUK);

ALTER TABLE CF_KWORC ADD CONSTRAINT OTMECHAETSYA_V FOREIGN KEY (PR_ISP) REFERENCES CF_PRICP (PR_ISP);

ALTER TABLE CF_KWORC ADD CONSTRAINT UKAZIVAYUTSYA FOREIGN KEY (ID_OS_DOKK) REFERENCES OS_DOKKL (ID_OS_DOKK);

ALTER TABLE CF_KWORC ADD CONSTRAINT VHODIT FOREIGN KEY (ID_PS_POD) REFERENCES PS_POD (ID_PS_POD);


/***************************************************************************/

/***                                Triggers                             ***/

/***************************************************************************/

SET TERM ^ ;

/***************************************************************************/

/****                     Triggers for tables                           ****/

/***************************************************************************/

/* Trigger: TD_CF_KVR */

CREATE TRIGGER TD_CF_KVR FOR CF_KVR

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on CF_KVR */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* CF_KVR указывается для CF_KWORC ON PARENT DELETE CASCADE */

   delete from CF_KWORC

     where

       /*  CF_KWORC.K_KVR = OLD.K_KVR */

       CF_KWORC.K_KVR = OLD.K_KVR;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_CF_KWORC */

CREATE TRIGGER TD_CF_KWORC FOR CF_KWORC

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on CF_KWORC */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* CF_KWORC содержат CF_OLDW ON PARENT DELETE RESTRICT */

   select count(*)

     from CF_OLDW

     where

       /*  CF_OLDW.N_KWORK = OLD.N_KWORK */

       CF_OLDW.N_KWORK = OLD.N_KWORK into numrows;

   IF (numrows > 0) THEN

   BEGIN

     EXCEPTION ERWIN_PARENT_DELETE_RESTRICT;

   END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_CF_LITER */

CREATE TRIGGER TD_CF_LITER FOR CF_LITER

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on CF_LITER */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* CF_LITER соответствует CF_KWORC ON PARENT DELETE CASCADE */

   delete from CF_KWORC

     where

       /*  CF_KWORC.LIT = OLD.LIT */

       CF_KWORC.LIT = OLD.LIT;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_CF_PRI */

CREATE TRIGGER TD_CF_PRI FOR CF_PRI

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on CF_PRI */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* CF_PRI отмечается в CF_OLDW ON PARENT DELETE CASCADE */

   delete from CF_OLDW

     where

       /*  CF_OLDW.K_PRI_PER = OLD.K_PRI_PER */

       CF_OLDW.K_PRI_PER = OLD.K_PRI_PER;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_CF_PRICP */

CREATE TRIGGER TD_CF_PRICP FOR CF_PRICP

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on CF_PRICP */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* CF_PRICP отмечается в CF_KWORC ON PARENT DELETE CASCADE */

   delete from CF_KWORC

     where

       /*  CF_KWORC.PR_ISP = OLD.PR_ISP */

       CF_KWORC.PR_ISP = OLD.PR_ISP;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_OS_DOKKL */

CREATE TRIGGER TD_OS_DOKKL FOR OS_DOKKL

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on OS_DOKKL */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* OS_DOKKL указываются в CF_KWORC ON PARENT DELETE CASCADE */

   delete from CF_KWORC

     where

       /*  CF_KWORC.ID_OS_DOKK = OLD.ID_OS_DOKK */

       CF_KWORC.ID_OS_DOKK = OLD.ID_OS_DOKK;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_PS_FS */

CREATE TRIGGER TD_PS_FS FOR PS_FS

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on PS_FS */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* PS_FS содержат PS_POD ON PARENT DELETE CASCADE */

   delete from PS_POD

     where

       /*  PS_POD.KS_FS = OLD.KS_FS */

       PS_POD.KS_FS = OLD.KS_FS;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_PS_KRUK */

CREATE TRIGGER TD_PS_KRUK FOR PS_KRUK

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on PS_KRUK */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* PS_KRUK используется CF_KWORC ON PARENT DELETE CASCADE */

   delete from CF_KWORC

     where

       /*  CF_KWORC.ID_PS_KRUK = OLD.ID_PS_KRUK */

       CF_KWORC.ID_PS_KRUK = OLD.ID_PS_KRUK;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TD_PS_POD */

CREATE TRIGGER TD_PS_POD FOR PS_POD

ACTIVE AFTER DELETE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* DELETE trigger on PS_POD */

DECLARE VARIABLE numrows INTEGER;

BEGIN

   /* ERwin Builtin Tue May 13 16:08:07 2014 */

   /* PS_POD входит CF_KWORC ON PARENT DELETE CASCADE */

   delete from CF_KWORC

     where

       /*  CF_KWORC.ID_PS_POD = OLD.ID_PS_POD */

       CF_KWORC.ID_PS_POD = OLD.ID_PS_POD;

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_CF_KVR */

CREATE TRIGGER TU_CF_KVR FOR CF_KVR

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on CF_KVR */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* CF_KVR указывается для CF_KWORC ON PARENT UPDATE CASCADE */

 IF

   /* OLD.K_KVR <> NEW.K_KVR */

   (OLD.K_KVR <> NEW.K_KVR) THEN

 BEGIN

   update CF_KWORC

     set

       /*  CF_KWORC.K_KVR = NEW.K_KVR */

       CF_KWORC.K_KVR = NEW.K_KVR

     where

       /*  CF_KWORC.K_KVR = OLD.K_KVR */

       CF_KWORC.K_KVR = OLD.K_KVR;

 END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_CF_KWORC */

CREATE TRIGGER TU_CF_KWORC FOR CF_KWORC

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on CF_KWORC */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* CF_KWORC содержат CF_OLDW ON PARENT UPDATE RESTRICT */

 IF

   /* OLD.N_KWORK <> NEW.N_KWORK */

   (OLD.N_KWORK <> NEW.N_KWORK) THEN

 BEGIN

   select count(*)

     from CF_OLDW

     where

       /*  CF_OLDW.N_KWORK = OLD.N_KWORK */

       CF_OLDW.N_KWORK = OLD.N_KWORK into numrows;

   IF (numrows > 0) THEN

   BEGIN

     EXCEPTION ERWIN_PARENT_UPDATE_RESTRICT;

   END

 END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_CF_LITER */

CREATE TRIGGER TU_CF_LITER FOR CF_LITER

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on CF_LITER */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* CF_LITER соответствует CF_KWORC ON PARENT UPDATE CASCADE */

 IF

   /* OLD.LIT <> NEW.LIT */

   (OLD.LIT <> NEW.LIT) THEN

 BEGIN

   update CF_KWORC

     set

       /*  CF_KWORC.LIT = NEW.LIT */

       CF_KWORC.LIT = NEW.LIT

     where

       /*  CF_KWORC.LIT = OLD.LIT */

       CF_KWORC.LIT = OLD.LIT;

 END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_CF_PRI */

CREATE TRIGGER TU_CF_PRI FOR CF_PRI

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on CF_PRI */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* CF_PRI отмечается в CF_OLDW ON PARENT UPDATE CASCADE */

 IF

   /* OLD.K_PRI_PER <> NEW.K_PRI_PER */

   (OLD.K_PRI_PER <> NEW.K_PRI_PER) THEN

 BEGIN

   update CF_OLDW

     set

       /*  CF_OLDW.K_PRI_PER = NEW.K_PRI_PER */

       CF_OLDW.K_PRI_PER = NEW.K_PRI_PER

     where

       /*  CF_OLDW.K_PRI_PER = OLD.K_PRI_PER */

       CF_OLDW.K_PRI_PER = OLD.K_PRI_PER;

 END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_CF_PRICP */

CREATE TRIGGER TU_CF_PRICP FOR CF_PRICP

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on CF_PRICP */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* CF_PRICP отмечается в CF_KWORC ON PARENT UPDATE CASCADE */

 IF

   /* OLD.PR_ISP <> NEW.PR_ISP */

   (OLD.PR_ISP <> NEW.PR_ISP) THEN

 BEGIN

   update CF_KWORC

     set

       /*  CF_KWORC.PR_ISP = NEW.PR_ISP */

       CF_KWORC.PR_ISP = NEW.PR_ISP

     where

       /*  CF_KWORC.PR_ISP = OLD.PR_ISP */

       CF_KWORC.PR_ISP = OLD.PR_ISP;

  END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_OS_DOKKL */

CREATE TRIGGER TU_OS_DOKKL FOR OS_DOKKL

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on OS_DOKKL */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* OS_DOKKL указываются в CF_KWORC ON PARENT UPDATE CASCADE */

 IF

   /* OLD.ID_OS_DOKK <> NEW.ID_OS_DOKK */

   (OLD.ID_OS_DOKK <> NEW.ID_OS_DOKK) THEN

 BEGIN

   update CF_KWORC

     set

       /*  CF_KWORC.ID_OS_DOKK = NEW.ID_OS_DOKK */

       CF_KWORC.ID_OS_DOKK = NEW.ID_OS_DOKK

     where

       /*  CF_KWORC.ID_OS_DOKK = OLD.ID_OS_DOKK */

       CF_KWORC.ID_OS_DOKK = OLD.ID_OS_DOKK;

 END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_PS_FS */

CREATE TRIGGER TU_PS_FS FOR PS_FS

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on PS_FS */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* PS_FS содержат PS_POD ON PARENT UPDATE CASCADE */

 IF

   /* OLD.KS_FS <> NEW.KS_FS */

   (OLD.KS_FS <> NEW.KS_FS) THEN

 BEGIN

   update PS_POD

     set

       /*  PS_POD.KS_FS = NEW.KS_FS */

       PS_POD.KS_FS = NEW.KS_FS

     where

       /*  PS_POD.KS_FS = OLD.KS_FS */

       PS_POD.KS_FS = OLD.KS_FS;

 END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_PS_KRUK */

CREATE TRIGGER TU_PS_KRUK FOR PS_KRUK

ACTIVE AFTER UPDATE POSITION 0

AS

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* UPDATE trigger on PS_KRUK */

DECLARE VARIABLE numrows INTEGER;

BEGIN

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

 /* PS_KRUK используется CF_KWORC ON PARENT UPDATE CASCADE */

 IF

   /* OLD.ID_PS_KRUK <> NEW.ID_PS_KRUK */

   (OLD.ID_PS_KRUK <> NEW.ID_PS_KRUK) THEN

 BEGIN

   update CF_KWORC

     set

       /*  CF_KWORC.ID_PS_KRUK = NEW.ID_PS_KRUK */

       CF_KWORC.ID_PS_KRUK = NEW.ID_PS_KRUK

     where

       /*  CF_KWORC.ID_PS_KRUK = OLD.ID_PS_KRUK */

       CF_KWORC.ID_PS_KRUK = OLD.ID_PS_KRUK;

 END

 /* ERwin Builtin Tue May 13 16:08:07 2014 */

END

^

/* Trigger: TU_PS_POD */

CREATE TRIGGER TU_PS_POD FOR PS_POD