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

СОДЕРЖАНИЕ

4.2.3.3 Ответственность за безопасность других лиц 91.

4.2.3.4 Количество конфликтных производственных ситуаций за смену 91.

4.2.4 Монотонность нагрузок 92.

4.2.4.1 Продолжительность выполнения  простых производственных заданий  или повторяющихся операций. 92.

4.2.4.2 Время активных действий (в % к продолжительности смены)…… 92.

4.2.4.3 Монотонность производственной обстановки (время пассивного  
наблюдения за ходом техпроцесса, в % от времени смены) 92.

4.2.5 Режим  работы 93.

4.2.5.1 Фактическая продолжительность рабочего дня 93.

4.2.5.2 Сменность работы 93.

4.2.5.3  Наличие регламентированных перерывов и их продолжительность 
(без учета обеденного перерыва) 93.

4.2.5.4Общая оценка напряженности трудового процесса 93.

ЗАКЛЮЧЕНИЕ 97.

СПИСОК СОКРАЩЕНИЙ 99.

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ 100.

 

ВВЕДЕНИЕ

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

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

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

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

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

На базе разработанной информационной системы обеспечивается решение следующих задач:

Расширение сферы безбумажного делопроизводства и документооборота внутри организации;

Управление прайс-листами и услугами организации;

Организация рекламных кампаний

Подготовка и заключение договоров со сторонними организациями;

Оформление приема, перевода и увольнения работников;

Разграничение прав доступа;

 

1 СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание предметной  области.

Создаваемая система будет способна решать задачи связанные с управлением услуг предприятия и его персоналом.

Функции, реализуемые системой:

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

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

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

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

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

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

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

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

1. Ведение документооборота;
2. Управление прайс листами и договорами;
3. Формирование и хранение данных о сторонних организациях и учетных данных сотрудников;
4. Внесение и изменение услуг организации;
5. Обеспечение безопасности данных, хранящихся в базе данных;
6. Функция системы разграничения доступа.

1.4 Определение  логической структуры АИС

1.4.1 Логическое  проектирование

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

В процессе проектирования системы разработана логическая модель данных с использованием CASE-средства проектирования баз данных - ErWin 7.2, предназначенное для моделирования и создания баз данных на основе диаграмм «сущность - связь».

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

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

На этапе логического проектирования для каждого атрибута определяется примерный тип данных (строковый, числовой, BLOB и др.).

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

Моделирование предметной области выполнено с использованием средства визуального моделирования объектно-ориентированных систем - Rational Rose 7.0, работа которого основана на универсальном языке моделирования UML (Universal Modeling Language).

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

Моделирование в Ration Rose проводится как спуск от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде диаграмм вариантов использования. В рамках Rational Rose этот этап минуется «User Case Viewer», и служит для проведения итерационного цикла общей постановки задачи.

После завершения формирования принципов использования системы тает этап разработки ее логической структуры, именуемый «Logical Viewer».

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

Кроме того, для описания логики системы применяются на данном этапе граммы состояний, диаграммы сценариев и другие элементы языка UML.

1.4.2 Логическая  модель АИС

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

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

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

диаграмма сущность-связь (Entity Relationship Diagram, ERD);

модель данных, основанная на ключах (Key Based model, KB);

полная атрибутивная модель (Fully Attributed model, FA).

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

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

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

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

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

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

Описание сущностей системы, связей и их ключевых и не ключевых атрибутов приведено в логической модели АИС управления услуг предприятия и его персонала на рисунке 1.1 - .

.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.4.3 Нормализация

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

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

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

Отношения находятся в третьей нормальной форме, т.к. они находятся Ер второй и первой нормальной форме. И при этом любой из атрибутов таблицы зависит только от первичного ключа (Primary key, РК) (иначе говоря, один факт хранится в одном месте), отсутствуют транзитивные зависимости не ключевых атрибутов от ключевых (А → В и В → С, где А - набор ключевых атрибутов (ключ), В и С - различные множества не ключевых атрибутов).

При решении данной задачи третья нормальная форма является достаточной. Для доказательства того, что отношения находятся в третьей нормальной форме рассмотрим отношения «Филиалы», «Договор», «Организация».

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

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

В отношении «Филиалы» ключом является атрибут <id_Филиала>. Не ключевыми атрибутами являются: <id_Организации>, <Сокращенное_название>, <Полное_название>, <Почтовый_адрес>, <Город>, <Телефон>, <Электронная_почта>, <Комментарий>. В Данном отношении отсутствуют транзитивные зависимости не ключевых атрибутов от ключевых, таким образом, отношение находится в третьей нормальной форме.

1.5 Разработка информационно-логической структуры системы

1.5.1 Краткое  описание методологии UML

Разработка унифицированного языка объектно-ориентированного моделирования Unified Modeling Language (UML) обуславливалась требованиями, предъявляемыми к языку моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода, сильные стороны известных методов, и давал бы четкую модель системы, отражающую все ее значимые стороны, и обеспечивал наилучшую поддержку моделирования.

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

• ОМТ-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем;
• Booch лучше всего подходил для стадий дизайна и разработки;
• OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе.

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

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

UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

В терминах языка UML определены следующие виды диаграмм:

• диаграмма вариантов использования (use case diagram);
• диаграмма классов (class diagram);
• диаграммы поведения (behavior diagrams);

• диаграмма состояний (statechart diagram);
• диаграмма деятельности (activity diagram);

• диаграммы взаимодействия (interaction diagrams);

• диаграмма последовательности (sequence diagram);
• диаграмма кооперации (collaboration diagram);

• диаграммы реализации (implementation diagrams);

• диаграмма компонентов (component diagram);
• диаграмма развертывания (deployment diagram).

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

1.5.2 Диаграмма вариантов использования.

Для управления процессом разработки АИС и определения функциональных требований к системе построена диаграмма вариантов использования (use case diagram), которая определяет общие границы и контекст моделируемой предметной области.

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

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

Данная система состоит из следующих актантов:

• администратор
• сотрудник отдела кадров
• сотрудник отдела нормативно справочной информации

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

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

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

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

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

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

Диаграмма вариантов использования для АИС управления услуг предприятия и его персонала показана на рисунке 1.2

 

 

 

Для основных вариантов использования составлены сценарии их использования (текстовое описание).

Рассмотрим сценарий для варианта использования «Войти в систему». Вариант использования: Войти в систему.

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

Актант: Пользователь.

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

1. Система отображает диалоговое окно для ввода имени пользователя и пароля.
2. Пользователь вводит имя пользователя и пароль и подтверждает вход в систему.

А1: Пользователь отклоняет вход и нажимает кнопку «Отмена».

4. Система проверяет введенные пользователем имя и пароль.
5. Система осуществляет настройку и вывод главного рабочего окна программы, при этом вариант использования выполнен успешно.

А2: Введено неправильное имя или пароль пользователя.

Альтернативы:

А 1: Пользователь отклоняет вход нажатием кнопки «Отмена».

А 1.1. Система закрывает окно для ввода имени пользователя и пароля и завершает работу программы.

А2: Введено неправильное имя или пароль пользователя.

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

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

Актант: Администратор.

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

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

1.5.3 Диаграмма классов

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

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

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

Для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) существует три специальных графических примитива:

• управляющий класс (control class) —класс отвечающий за координацию действий других классов.

Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Управляющий класс изображен в форме прямоугольника класса со стереотипом ««control»»;

• класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы.

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

• граничный класс (boundary class) – класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актантами, но является составной частью системы Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом ««boundary»»;

Диаграммы классов для АИС управления услуг предприятия и его персонала показаны на рисунках 1.3 -1.4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.5.4 Диаграмма состояний

Диаграмма состояний (statechart diagram) изображает все возможные состояния, в которых может находиться конкретный объект разработанной АИС, а также изменения состояния объекта, которые происходят в результате влияния некоторых событий на этот объект.

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

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

entry - указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);

exit - указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);

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

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

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

Диаграмма состояний для АИС управления услуг предприятия и его персонала показаны на рисунке 1.5

 

 

 

 

 

 

 

1.5.5 Диаграмма деятельности

Диаграмма деятельности (activity diagram) представляет собой специальный тип диаграммы состояний, описанной выше, в которой представлены состояния действия и транзакции, имеющие место по завершении операций.

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

Диаграмма деятельности разделяется на «дорожки» (swimlanes), в каждой из которых размещены элементы, принадлежащие одной подсистеме разработанной АИС.

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

Диаграмма деятельности для АИС управления услуг предприятия и его персонала показана на рисунке 1.6. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Физическая модель базы данных

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