39493

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

Дипломная

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

Информационные системы являются социальными системами целью разработки которых является предоставление заказчику продуктивной системы. Для системы разрабатываемой с нуля необходимо создать концептуальные конструкции модели для конечного решения которые бы удовлетворяли специфические потребности организации. На базе разработанной информационной системы обеспечивается решение следующих задач: Расширение сферы безбумажного делопроизводства и документооборота внутри организации; Управление прайслистами и услугами организации;...

Русский

2013-10-04

4.86 MB

82 чел.


СОДЕРЖАНИЕ

4.2.3.3 Ответственность за безопасность других лиц {Error calculating value!: Bookmark "_Toc251727488" was not found in this document.}

4.2.3.4 Количество конфликтных производственных ситуаций за смену {Error calculating value!: Bookmark "_Toc251727489" was not found in this document.}

4.2.4 Монотонность нагрузок {Error calculating value!: Bookmark "_Toc251727490" was not found in this document.}

4.2.4.1 Продолжительность выполнения простых производственных заданий или повторяющихся операций. {Error calculating value!: Bookmark "_Toc251727491" was not found in this document.}

4.2.4.2 Время активных действий (в % к продолжительности смены)…… {Error calculating value!: Bookmark "_Toc251727492" was not found in this document.}

4.2.4.3 Монотонность производственной обстановки (время пассивного
наблюдения за ходом техпроцесса, в % от времени смены)
{Error calculating value!: Bookmark "_Toc251727493" was not found in this document.}

4.2.5 Режим работы {Error calculating value!: Bookmark "_Toc251727494" was not found in this document.}

4.2.5.1 Фактическая продолжительность рабочего дня {Error calculating value!: Bookmark "_Toc251727495" was not found in this document.}

4.2.5.2 Сменность работы {Error calculating value!: Bookmark "_Toc251727496" was not found in this document.}

4.2.5.3  Наличие регламентированных перерывов и их продолжительность
(без учета обеденного перерыва)
{Error calculating value!: Bookmark "_Toc251727497" was not found in this document.}

4.2.5.4Общая оценка напряженности трудового процесса {Error calculating value!: Bookmark "_Toc251727478" was not found in this document.}

ЗАКЛЮЧЕНИЕ {Error calculating value!: Bookmark "_Toc251727479" was not found in this document.}

СПИСОК СОКРАЩЕНИЙ {Error calculating value!: Bookmark "_Toc251727480" was not found in this document.}

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ {Error calculating value!: Bookmark "_Toc251727481" was not found in this document.}


ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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: Пользователь отклоняет вход и нажимает кнопку «Отмена».

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

А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 модель, является также «моделью данных проекта», описывающей отдельную часть всей структуры данных, предназначенную для обеспечения конкретного участка автоматизации.

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

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

Физическая модель данных — способ хранения данных в конкретной СУБД. Строится на основе логической модели данных.

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

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

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



2.2 Выбор и обоснование программных средств разработки

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

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

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

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

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

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

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

Таким образом, 3-х уровневая организация архитектуры позволяет осуществить полный функционал системы и реализовать все необходимые требования, предъявляемые к данной АИС.

2.3 Выбор технических средств и ресурсный анализ 

2.3.1 Расчет необходимого объема памяти

Расчет необходимого объема внешней памяти, для функционирования разработанной АИС определяется по формуле (2.1):

VBn = Voc +Vn +VСУБД (2.1),

где VВП - общий объем внешней памяти, Мб;

Voc - объём внешней памяти, необходимый для размещения файлов операционной системы, Мб;

VП - объём внешней памяти, необходимый для хранения программ, Мб;

VСУБД - объём внешней памяти, необходимый для хранения файлов СУБД, Мб.

Для расчета необходимого объема памяти примем, что разработанная АИС функционирует под ОС Microsoft Windows ХР SP3, которая требует Voc = 1765 Мб и использует СУБД Microsoft SQL Server 2008, объем внешней памяти которой составляет VСУБД - 2048Мб.

VП=Vc + Vc.n. (2.2),

где Vc - объем памяти, необходимый для хранения файлов разработанной АИС, Мб.

Vс.п. _ объемом памяти, необходимым для хранения файлов

сопутствующих программ, Мб.

Для хранения файлов системы необходимо 2,4 Мб, а для хранения файлов сопутствующих программ - 238,2 Мб.

Таким образом, общий объем внешней памяти, рассчитанный по формуле (2.1) составляет Van = 4053,6 Мб, что удовлетворяет самым минимальным конфигурациям современных ЭВМ.

Расчет необходимого объема оперативной памяти, для функционирования разработанной АИС определяется по формуле (2.3):

VОЗУ = VОС + VД + VСУБД + VП (2.3),

где VОЗУ - общий объем оперативной памяти, Мб;

Voc - объем оперативной памяти, необходимый для нормальной работы ОС, Мб;

VСУБД - объем оперативной памяти, необходимый для работы программы, Мб;

VД - объем кэша для хранения данных, загружаемых в оперативную память при работе программы, Мб.

ОС Microsoft Windows ХР SP3 требует Voc = 256 Мб оперативной памяти. Используемая СУБД Microsoft SQL Server 2008 требует VСУБД = 1024 Мб. Объем памяти для хранения программ VП - 2,4 Мб. Для определения объема кэша для хранения данных применим оценку сверху VД = 34 Мб.

Таким образом, общий объем оперативной памяти, рассчитанный по формуле (2.3) составляет Vo3y = 1316,4 Мб. В результате оптимальный объем оперативной памяти для работы с программой примем 1,5 Гб.

2.3.2 Расчет времени реакции системы

Для расчета времени реакции системы применяется формула (2.4):

tРЕАКЦИИ = tКОМАНД + tДИСКА + tПЕРЕДАЧИ + tВЫВОДА   (2.4),

где tКОМАНД - время, затрачиваемое процессором на выполнение команд;

tДИСКА - время, затрачиваемое при обращении к жесткому диску для считывания блоков данных;

tПЕРЕДАЧИ - время, затрачиваемое на передачу данных по сети;

tВЫВОДА - время, затрачиваемое на вывод информации на экран монитора.

Для разработанной АИС управления услуг предприятия и его персонала время реакции системы не является критическим параметром, поэтому расчет проводился опытным путем на ПЭВМ IBM PC Pentium IV с общим объемом оперативной памяти 2 Гб. Данные выводились на печать с использованием МФУ HP 2727. Результаты расчетов приведены в таблице 2.1.

Таблица 2.1 - Расчет времени реакции системы

Стадия

Количество записей

Время реакции, с

Формирование прайс-листов

200

15

Поиск данных

60

8

Печать данных

500

60

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

2.3.3 Требования к комплексу технических средств

Комплекс технических средств (КТС) - это некоторое структурное единство компонентов технического обеспечения (ТО), обеспечивающих функционирование разработанной АИС.

Функциональными требования к КТС являются:

хранение БД системы;

реализация математических моделей;

системы поиска данных;

обеспечение наглядности информации;

возможность работы, как в пакетном, так и в диалоговом режиме;

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

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

Согласно проведенным расчетам к ПЭВМ предъявляются следующие технические требования:

процессор класса Pentium с тактовой частотой 2 ГГц и выше;

объем ОЗУ 1,5 ГБ или более;

4 ГБ свободного места на диске и выше;

внешние устройства ввода/вывода (МФУ, принтер, монитор).

2.4 Разработка программного обеспечения

2.4.1 Структура программной системы

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

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

Для визуализации компонентов разработанной системы используются диаграммы компонент. Этап построения диаграмм компонент в Rational Rose именуется «Component View» и состоит из построения общей диаграммы и, при необходимости, детализации отдельных компонентов на вложенных диаграммах.

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

Для представления физической структуры АИС управления услуг предприятия и его персонала разработаны диаграмма компонентов и диаграмма развертывания, рассмотренные ниже.

2.4.1.1 Диаграмма компонентов

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

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

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

Рисунок 2. 2 – Диаграмма компонентов АИС управления услуг предприятия и его персонала

2.4.1.2 Диаграмма развертывания

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

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

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

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

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

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

Данная диаграмма отражает особенности реализации системы и в отличие от диаграмм логического представления является единой для системы в целом. Разработанная диаграмма развертывания для АИС управления услуг предприятия и его персонала содержит графические изображения процессоров, устройств, процессов и связей между ними и представлена на рисунке 2.3.

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

2.4.1.3 Описание модулей системы

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

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

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

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

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

Объект конфигурации является программным модулем, объединяющим в себе данные (свойства) и операции над ними (методы);

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

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

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

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

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

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

В состав АИС управления услуг предприятия и его персонала входит 11 модуля, основные значения которых указаны в таблице 2.2.

Таблица 2.2 – Описание модулей системы

Модуль

Краткое описание

Log4J

Библиотека для ведения логов

JTDS

Драйвера для MsSQL

swing

Библиотека граф элементов

swingX

Дополнительные графические элементы

JCalendar

Графические компоненты для календарей и дат

Hibirnate

Библиотека (Фрэймворк) персистентностей

Spring

Фрэймворк, контейнер для объектов и т.д.

JUnit

Библиотека Unit тестирования

Commons - logging

Системные библиотеки, необходимые для spring и Hibernate

Commons - collection

Системные библиотеки, необходимые для spring и Hibernate

Netbeans - Platform

Фрэймворк и библиотеки для организации графического многооконного интерфейса

2.4.3 Разработка интерфейса системы

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

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

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

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

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

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

Каждый пункт меню определяется тремя характеристиками. Первая определяет то, что будет отображаться в данном пункте меню это либо строка текста, либо картинка. Вторая характеристика определяет тип: разделитель, меню или подменю. Третья характеристика указывает, является ли данный пункт меню разрешенным, запрещенным, недоступным или помеченным. Эта характеристика пункта меню не является обязательной.

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

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

Рисунок 2.4 – Формы модуля работы с учетными данными

Рисунок 2.5 – Формы модуля работы с учетными данными

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

Рисунок 2.6 – Формы модуля расписание

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

Рисунок 2.7 – Формы модуля администратора
3 Экономическое обоснование АИС управления услуг предприятия и его персонала

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

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

единовременные затраты на создание;

единовременные затраты на внедрение;

текущие затраты на функционирование;

экономические результаты от внедрения. По результатам этих расчетов определяется экономическая эффективность разработки АИС.

3.1 Планирование и организация процесса разработки

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

составление перечня работ по разработке АИС;

определение состава и количества исполнителей каждой работы;

установление последовательности и взаимосвязи работ;

определение трудоемкости и продолжительности каждой работы;

составление сетевого графика;

расчет временных параметров сетевого плана продолжительность разработки АИС;

- составление плана-графика выполнения работ.

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

Продолжительность каждой работы Dj определяется по формуле:

где nчисленность исполнителей, чел.

Экспертные оценки и расчетные величины трудоемкости продолжительности сводятся в таблице 3.1.

Таблица 3.1 - Оценка трудоемкости отдельных видов работ

Вид работ

Оценка трудоемкости

Расчетные величины

aj

mj

bj

Dj

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

6

8

10

8,00

8,00

  1.  Выбор комплекса технических средств

2

4

6

4,00

4,00

  1.  Разработка структуры конфигурации

3

5

6

4,83

4,83

  1.  Разработка информационного обеспечения модуля администратор

4

5

8

5,33

5,33

  1.  Разработка информационного обеспечения модуля отдел кадров

4

6

8

6,00

6,00

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

4

6

8

6,00

6,00

  1.  Разработка программного обеспечения интерфейсной части системы

4

6

8

6,00

6,00

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

2

4

6

4,00

4,00

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

3

5

5

4,67

4,67

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

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

3

5

5

4,67

4,67

  1.  Отладка и тестирование подсистем

2

3

4

3,00

3,00

  1.  Отладка и тестирование интеграции системы

3

5

5

4,67

0,51

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

9

12

14

11,83

11,83

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

Таблица 3.2 - Оценка трудоемкости отдельных видов работ

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

какие работы нужно вы-полнить перед данной

исполнители

Трудо-ем-кость работы, чел.-дн.

Продол-житель-ность работы , дн.

должность

Коли-чество

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

_

Начальник отдела

1

8

8

  1.  Выбор комплекса технических средств

1

программист

1

4

4

  1.  Разработка структуры конфигурации

2

программист

1

5

5

  1.  Разработка информационного обеспечения модуля администратор

3

программист

1

5

5

  1.  Разработка информационного обеспечения модуля отдел кадров

3

программист

1

6

6

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

3

программист

1

6

6

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

  1.  Разработка программного обеспечения интерфейсной части системы

4,5,6

программист

1

6

6

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

7

программист

1

4

4

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

7

программист

1

5

5

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

7

программист

1

5

5

  1.  Отладка и тестирование подсистем

8,9,10

программист

1

3

3

  1.  Отладка и тестирование интеграции системы

11

программист

1

5

5

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

12

программист

1

12

12

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

Рисунок 3.1 - Сетевой график процесса разработки системы

Длительность разработки АИС определяется продолжительностью критического пути сетевого графика.

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

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

С этой целью рассчитываются временные параметры событий и работ построенной сети.

Ранний срок свершения i-гo события Tpi — время, необходимое для выполнения всех работ, предшествующих данному событию.

Tpi = t[L(I÷i)макс],

где L(I÷i) — пути, ведущие от исходного события I до данного события i.

t[L(I÷i)макс] — продолжительность максимального из путей от исходного события I до данного события i.

Продолжительность критического пути (Lкр) находится по фомуле:

t(Lкp) = t[L(I÷С)макс],

где Lкp — критический путь;

L(I÷С) — пути, ведущие от исходного события I до конечного события С.

Поздний срок свершения i - г о события Tпi — время свершения события, превышение которого вызовет аналогичную задержку наступления завершающего события.

Tпi = t(Lкp) - t[L(i÷С)макс],

где t[L(I÷С)макс] — продолжительность максимального из путей от данного события i до завершающего С.

Резерв времени i-ro события Ri определяется как разность между поздним и ранним сроком свершения события i, т.е.

Ri = Tпi - Т pi.

Временные параметры работы между i и j событием сетевой модели находятся следующим образом:

ранний срок начала Трнij = Tpi;

поздний срок окончания Tпoij = Tпj;

ранний срок окончания Tpoij = Трнij + tij;

поздний срок начала Тпнij = Tпoij - tij;

полный резерв времени Rпij = Tпoij - Tpoij

свободный резерв времени Rcij = Tpoij - Tpoi - tij

где tij — продолжительность работы ij.

Временные параметры событий и работ представляется в форме таблицы 3.3

Таблица 3.3 – Временные параметры сетевого плана

Коды событий i

Временные параметры

Код работ

ij

Временные параметры работ

tij

Трнij

Tpoij

Тпнij

Tпoij

Rпij

Rcij

Tpi

Tпi

Ri

0

0

0

0

0-1

8

0

8

0

8

0

0

1

8

8

0

1-2

4

8

12

8

12

0

0

2

12

12

0

2-3

5

12

17

12

17

0

0

3

17

17

0

3-4

5

17

22

17

22

0

0

3

17

17

0

3-5

6

17

23

17

23

0

0

3

17

17

0

3-6

6

17

23

17

23

0

0

4

22

22

0

4-7

6

22

28

23

29

1

0

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

5

23

23

0

5-7

6

23

29

23

29

0

0

6

23

23

0

6-7

6

23

29

23

29

0

0

7

29

30

1

7-8

4

29

33

29

33

0

0

7

29

30

1

7-9

5

29

34

29

34

0

0

7

29

30

1

7-10

5

29

34

29

34

0

0

8

33

33

0

8-11

3

33

36

34

37

1

0

9

34

34

0

9-11

3

34

37

34

37

0

0

10

34

34

0

10-11

3

34

37

34

37

0

0

11

37

38

1

11-12

5

37

43

37

42

1

1

12

42

42

0

12-13

12

42

64

42

54

10

10

13

54

54

0

13-14

0

54

54

0

0

0

0

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

План-график выполнения работ представлен в таблице 3.4.

Таблица 3.4. – Линейный график работ.

Код работы

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

Трудоем-кость

чел. –дн.

Продол-житель-ность, дн.

Календарь мес.

1

2

3

4

0-1

Разработка технического задания на разработку АИС

8

8

1-2

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

4

4

2-3

Разработка структуры конфигурации

5

5

3-4

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

5

5

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

4-5

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

6

6

5-6

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

6

6

6-7

Разработка программного обеспечения интерфейсной части системы

6

6

7-8

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

4

4

8-9

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

5

5

9-10

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

5

5

10-11

Отладка и тестирование подсистем

3

3

11-12

Отладка и тестирование интеграции системы

5

5

12-13

Оформление документации

12

12

3.2 Технико-экономическое обоснование автоматизированной информационной системы (АИС).

Задачи и содержание технико-экономического обоснования АИС состоят в следующем:

  1.  доказательство целесообразности создания или развития АИС на ^нове анализа составляющих:
    •  социальная потребность в системе;
    •      технические, математические, информационные и организационные возможности (качественная оценка системы);
    •  экономическая целесообразность разработки АИС
  2.  доказательство целесообразности внедрения АИС на основе расчетов
    •  текущих затрат на функционирование системы;
    •  показателей экономической эффективности инвестиционных затрат;

3.2.1 Расчет затрат на разработку автоматизированной информационной системы (АИС)

Укрупненный расчет затрат на разработку АИС можно выполнить по формуле:

Кп = Фз/п[(1+ßд)(1+ßс)+ ßн +ßпр]+tэвм См-Ч ,

где Ф3/п — фонд основной заработной платы разработчиков и других исполнителей работ, р.;

ßд — коэффициент дополнительной зарплаты, можно принимать 0ДО...ОД5;

ßс — коэффициент отчислений на социальные нужды от основной и дополнительной заработной платы, равен 0,302;

ßн — коэффициент накладных расходов организации, разрабатывающей проект, можно принимать 0,6...0,8;

ßпр — коэффициент прочих расходов, принимать 0,1...0,2;

tЭВм — машинное время, затраченное для отладки программного обеспечения АС, ч.;

См-ч —стоимость машино-часа работы ЭВМ, р.

Укрупненный расчет фонда основной заработной платы исполнителей работ по разработке АС производится по формуле:

Где         — суммарная трудоемкость работ по разработке АИС, чел.ч.(чел.-дн.)

С тарифная ставка часовая (дневная) разработчиков и других исполнителей работ, р.

С = Зп/Дн = 40000 р. в мес./22дн. = 1818р. — тарифная дневная ставка разработчиков.

Тогда фонд основной заработной платы исполнителей работ равен:

Фэ/П = 54 × 1818 = 98172 р.

Время, затраченное на отладку программного обеспечения на ПК t3BM = 88 ч., устанавливается экспертным путем или по фактическим затратам машинного времени.

Себестоимость машино-часа работы KCA определяется по формуле:

где Зп — затраты на заработную плату обслуживающего персонала с учетом всех отчислений, р.;

А — годовая сумма амортизации, р.;

Зэ — затраты на силовую электроэнергию, р.;

Зр — затраты на ремонт и обслуживание оборудования в год, р.;

Змзатраты на материалы в год, р.;

Зн — накладные расходы, р.;

Фд — действительный годовой фонд времени работы КСА, ч. Расчет затрат на заработную плату обслуживающего персонала производится по формуле:

где n — количество работников;

li — месячный оклад работника, р.;

kд — коэффициент, учитывающий дополнительную заработную плату (кд принимается от 1,1 до 1.2);

kс.н — коэффициент, учитывающий отчисления на социальные нужды принимается равным 1,26 (в соответствии с законодательством РФ отчисления на социальные нужды составляют 30,2% от основной и дополнительной заработной платы).

Годовые амортизационные отчисления по КСА считаются по формуле:

где  = 38000 р. — стоимость ПК и прочего оборудования, входящего в КСА, используемого при отладке АИС;

На = 25% — норма амортизации.

Затраты на электроэнергию в год Зэ определяются следующим образом:

Зэ = Wy · Сэ · Тв = 0,5 · 2,69· 2184 = 2937,48 р.,

где Wy = 0,5кВт — установленная мощность;

Сэ = 2,69 р / кВт — стоимость силовой электроэнергии;

Тв = 2184 ч — время, в течение года, когда КСА потребляет электроэнергию.

Зр + Зм = 0,04 · 38000 = 1520 р. - затраты на текущие ремонты и на материалы в год, примем их сумму равной 4 % от стоимости КСА.

Накладные расходы примем равными нулю.

Годовой фонд времени Фд устанавливается, исходя из номинального фонда времени и времени профилактики оборудования и ремонтов:

Фд = S · h · D - Тпр = 8 · 1 · 250 -12 · 8  = 1904 ч, где

S — продолжительность смены, ч;

h — количество смен;

D — число рабочих дней в году, дн.;

Тпр — время ремонтов и профилактики оборудования в год, ч.

Следовательно, себестоимость машино-часа работы КСА равна:

Таким образом, затраты на разработку системы составляют:

Кп = 98172 · [(1,14 · 1,302) + 0,7 + 0,2] + 88 · 302,74 = 260710,66 р.

3.2.2 Расчет-прогноз минимальной цены разработки автоматизированной информационной системы (АИС)

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

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

где  — минимальный уровень рентабельности, (10-20%). Таким образом, минимальная сумма прибыли равна:

= 260710,66 · 0,15 = 39106,6 р. Следовательно, минимальная цена разработки равна:

 =260710,66 + 39106,6 = 299817,26.

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

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

Если АИС разрабатывается для удовлетворения потребностей различных организаций и планируется продажа ее на рынке, то студент-дипломник должен сделать прогноз цен, затрат, спроса и возможностей реализации [15].

С этой целью необходимо:

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

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

— выбрать подход к определению цены продажи;

— определить возможные затраты на рекламу, сопровождение, доработку и т.п.

  1.  Оценка безубыточности и расчет целесообразного объема продаж

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

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

Суммарные затраты на разработку и реализацию проекта:

S (N) = Кп + S1 · N 

Кп - единовременные затраты на разработку АС;

S1 - затраты на рекламу, сопровождение на одну сделку;

Объем продаж в стоимостном выражении можно рассчитать по формуле:

Q(N) = Z · N 

Z - цена продажи.

Известно, что среднерыночная цена аналогичных автоматизированных систем составляет 50000р. Затраты на рекламу, сопровождению на одну сделку составляет 20% от среднерыночной стоимости - 50 000 рублей.

Точка безубыточности ТБ находится из соотношения

Z · NТБ = Кп + Si · NТБ, откуда:

7

Точка безубыточности служит разработчику хорошим ориентиром в оценке риска затрат на разработку. График безубыточности приведен на рисунке 3.2.

 

Рисунок 3.2 - Расчет единовременных затрат на внедрение АИС

Затраты на разработку считаются эффективными, если доходы покроют все затраты на разработку, продажу АИС и будет получена минимально необходимая сумма прибыли Пmin. Поэтому рассчитывается целесообразный объем продаж Nц из соотношения:

Z · Nц ≥ (Кп + S1 · Nц) + Пmin, откуда

,

, 8

Ниже приведены расчеты безубыточности и целесообразного объемов продаж для разных уровней цен:

  1.  Цена продажи Z=40000 р.

, 8

  1.  Цена продажи Z=35000 р.

, 9

  1.  Цена продажи Z=30000 р.

, 10

Разработка АИС целесообразна, поскольку потенциальное число потребителей превышает 10. При цене продажи

использующих систему управления рестораном «Epitome POS» и потенциальное число потребителей превышает 10. При цене продажи 40000 руб. точка безубыточности 10 шт., т.е. при дальнейших продажах появляется прибыль. Минимальная прибыль будет получена при продаже 10 экземпляров АИС.

3.2.4 Расчет единовременных затрат на внедрение

Единовременные затраты на внедрение АИС включают затраты на приобретение проекта АИС или затраты на разработку проекта, если разработка ведется специалистами той же организации (предприятия), где внедряется АИС, капитальные затраты на комплекс технических средств (КТС), а также расходы на установку КТС, его монтаж и наладку. Следует отметить, что при расчете эффективности конкретной АИС Личина капитальных затрат Ki определяется пропорционально доле времени использования средств автоматизации в данной АИС δi. Это объясняется тем, что один и тот же комплекс средств автоматизации может использоваться в работе нескольких АИС. Поэтому единовременные затраты на внедрение i-й системы Ki определяются по формуле:

Ki= Кпи·δi

где Кп — 260710,66  р. — затраты на разработку АИС;

Ки — величина инвестиционных (капитальных) затрат;

δi — коэффициент участия КСА. Величина инвестиционных (капитальных) затрат определяется по формуле:

КИ = ККТС + КМ + КИНВ + КЗД + КОС + КТР + КСОПКВЫС,

Где Кктс — сметная стоимость КТС, р.;

КМ, КИНВ, КЗД — затраты на установку, монтаж и запуск КТС в работу, на производственный инвентарь, на строительство и реконструкцию зданий для размещения КТС, р.;

КОС — сумма оборотных средств, р.;

КТР — транспортно-заготовительные расходы, р.;

КСОП — сметная стоимость системы стандартного обеспечения применения КТС, р.;

КВЫС — сумма высвобожденных средств в результате ввода в действие КСА, р.

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

Коэффициент участия КСА δi.находится по формуле:

где ti — время использования КСА при функционировании данной АИС в течение года, ч.;

Ф — действительный фонд времени работы КСА в год, ч.

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

Таким образом, единовременные затраты на внедрение АИС равны:

К-260710,66 +0 = 260710,66 р.

3.2.5 Расчет текущих затрат на функционирование АИС

Годовые текущие затраты Зтек на функционирование АИС рассчитываются путем определения суммарных затрат, вызываемых решением комплекса задач (процедур) АИС и общесистемных затрат и определяются по формуле:

где Зсист — общесистемные затраты за год, р./год (эти затраты, так же как капитальные, могут учитываться с коэффициентом  если данный КСА используется несколькими системами);

3i — затраты, вызванные решением i-й задачи АС, р./год;

n — число задач, решаемых в течение года.

Затраты 3А могут быть рассчитаны по формуле:

где  — годовые затраты на заработную плату специалистов, решающих данную задачу с учетом всех начислений в условиях АИС, р;

—стоимость работы комплекса средств автоматизации по данной задаче, р./год.

Затраты, связанные с работой КСА по данной задаче  могут быть рассчитаны по формуле:

где = 464 р./ч — себестоимость часа работы (сервера и компьютера);

= 2920 ч — время решения задачи с использованием КСА в год.

Таким образом, годовые текущие затраты Зтек на функционирование АИС равны:

Зтек = 1354880 + 0= 1354880  р./год.

3.2.6 Расчет экономических результатов от внедрения

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

Годовая экономия от внедрения АИС Эг определяется по формуле:

где m — количество статей затрат, по которым может быть получена экономия;

 — экономия по i-й статье затрат, т.р.;

 — затраты на функционирование АИС.

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

На заработной плате (с учетом отчислений на социальные нужды):

Э1 — административно-управленческого персонала;

Э2 — ИТР;

Э3 — производственных рабочих;

На материалах и сырье:

Э4 — на электроэнергии;

От сокращения:

Э5 — брака;

Э6 — непроизводительных расходов

Формулы Расчета годовой экономии на заработной плате

Где - затраты на выполнение работ по существующему (базовому) варианту при ручном способе и в условиях автоматизации, т.р,

- трудоемкость обработки информации ручным способом, ч.;

= 8760 ч - из расчета: 8 ч/дн., 365 дней, 3 человека;

= 2920 ч - из расчета: 8 ч/дн., 365 дней, 1 человека;

— коэффициент, учитывающий дополнительную трудоемкость по обработке информации на вспомогательные операции (принимать  = 2,0.-3,0);

ru - часовая тарифная ставка управленческих работников (171р.);

О - коэффициент, определяющий размер дополнительной заработной платы с учетом отчислений на социальные нужды (0,5...0,6);

R - коэффициент, определяющий характер накладных расходов (0,4..0,7);

Таким образом,

= 8760 · 2 · 171 · (1+0,5+0,4) = 5692248 р.,

=2920 · 2 · 171 · (1+0,5+0,4)= 1897416 р.,

= 5692248 - 1897416 = 3794832 р.,

Годовая экономия от внедрения АИС равна:

=3794832- 1354880 = 2439952

3.2.7 Методы расчета экономической эффективности инвестиционных (капитальных) затрат

Для оценки эффективности затрат на создание АИС можно применять метод расчета чистой дисконтированной стоимости (дохода).

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

Базисом для установления расчетной ставки может быть ставка процента на заемный капитал, по который предприятие должно выплачивать кредитору проценты. Если процентная ставка не учитывает инфляцию, то ее называют номинальной ставкой процента in. Реальная ставка процента ir учитывает уровень инфляции In.

Реальная ставка процента ir рассчитывается по формуле Фишера:

ir = (in-In)/(l+In),

где ir, in, In заданы в десятичных дробях.

Пусть номинальная ставка процента in равна 20 % годовых, а уровень инфляции In равен 9 %. Следовательно, реальная ставка процента ir равна:

ir = (0,20 - 0,09)/(1 + 0,09) = 10 %

Чистая дисконтированная стоимость (доход) — это суммарный эффект за период функционирования инвестиций (капиталовложений) с учетом приведения всех результатов и затрат к начальному году (дисконтирование с помощью расчетной ставки процента). Чистая дисконтированная стоимость (доход или интегральный эффект)  рассчитывается по формуле:

где Т — период функционирования проекта, г.;

Kj — инвестиционные затраты в j-м году, т.р.;

— экономический результат (экономия, прибыль и амортизация) в j-м году, т.р.;

 —коэффициент дисконтирования для года j.

Коэффициент дисконтирования  можно рассчитать по формуле:

Чистая дисконтированная стоимость  равна:

Расчет чистой дисконтированной стоимости представлен в табл. 1.5.

Таблица 1.5 - Расчет чистой дисконтированной стоимости

Год

Инвестиционные затраты т.р.

Дополнительная прибыль и амортизация, т.р.

Ряд платежей и поступлений т.р.

Расчетная процентная ставка,%

Коэффициент дисконтиров.

Текущая дисконтир. Стоимость, т.р.

1

299817,26

0

- 299817,26

1

- 299817,26

2

0

2439952

2439952

0,909

2217916,37

3

0

2439952

2439952

0,826

2015400,35

4

0

2439952

2439952

0,751

1832403,95

Всего

299817,26

7319856

7020038,74

5765903,41

Интегральный эффект  = 5765903,41 руб. > 0 - следовательно, инвестиции в проект считаются эффективными.

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

Формирование интегрального эффекта системы приведен на рисунке 3.4.

Рисунок 3.4 - Формирование интегрального эффекта системы


4
БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ

Безопасность жизнедеятельности является важным аспектом в разработке любой автоматизированной системы.

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

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

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

Одним из аналогов разрабатываемой системы, является программа «ИС Кольпоскопия», использующая базу данных MS Access и как следствие имеет ряд недостатков: скорость работы с базой данных при обработке запросов, трудоемкость при сопровождении и масшатбируемости, громоздкость пакета Microsoft Office.

В АИС учета услуг предприятия и управления персоналом предусматривается наличие автоматизированных рабочих мест (АРМ) для следующих участников процесса управленческой деятельности:

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

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

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

Старший специалист отдела нормативно справочной информации

сотрудники отдела кадров:

руководитель отдела кадров;

менеджер по персоналу;

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

Координация и контроль за выполнением плана маркетинговых мероприятий;

Осуществление планирования;

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

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

Формирование информационных данных;

архивное хранение электронных документов;

одновременная работа пользователей;

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

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

резервное копирование;

справочные функции;

Реализованные функциональные возможности в АИС учета услуг предприятия и управления персоналом соответствуют задачам, описанным в разделе постановки задачи. Таким образом, разработанная АИС является пригодной и позволяет в полной мере автоматизировать работу процесса управленческого учета, а также удовлетворяет требованиям ГОСТ Р ИСО/МЭК 9126-93 «Государственный стандарт на оценку качества программной системы» (Дата последнего переиздания 01.11.2004)

Немаловажную роль играют вопросы обеспечения безопасности хранения информации. В частности, обеспечение целостности данных различными СУБД. Разрабатываемая АИС СУБД. использует СУБД SQL Server 2008 для хранения данных. Рассмотрим средства и методы, обеспечивающие безопасность процесса ведения управленческой деятельности, дадим оценку качества условий труда участников процесса управленческого учета по показателям напряженности трудового процесса.

4.1 Обеспечение безопасности объекта автоматизации

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

несанкционированный доступ к базе данных;

внесение некорректных и заведомо ложных данных;

- возникновение исключительных ситуаций в результате некорректных действий пользователей;

нарушение функционала программы;

распространение и кража информации;

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

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

В соответствии с ГОСТ Р 50.1.053—2005 «Основные термины и определения в области технической защиты информации» под состоянием защищенности информации, при котором обеспечиваются ее конфиденциальность, доступность и целостность понимается информационная безопасность системы.

Обеспечение информационной безопасности разработанной системы, согласно ГОСТ Р 50922-2006 «Защита информации. Основные термины и определения» (Дата последнего переиздания 13.12.2007), предполагает осуществление деятельности по предотвращению утечки защищаемой информации, несанкционированных и непреднамеренных воздействий на защищаемую информацию.

Существует четыре уровня обеспечения информационной безопасности:

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

процедурный (меры безопасности, ориентированные на людей);

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

программно-технический.

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

Программно-технические меры направлены на контроль компьютерного оборудования, программ и хранящихся данных. Согласно ГОСТ Р 50922-2006 «Защита информации. Основные термины и определения» (Дата последнего переиздания 13.12.2007), данные меры обеспечения безопасности предотвращают воздействия на защищаемую информацию ошибок пользователя информацией, сбоя технических и программных средств информационных систем, а также иных нецеленаправленных на изменение информации воздействий, связанных с функционированием технических средств, систем или с деятельностью людей, приводящих к искажению, уничтожению, копированию, блокированию доступа к информации, а также к утрате, уничтожению или сбою функционирования системы.

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

4.1.1 Информационная безопасность в СУБД SQL Server 2008

Одним из методов обеспечения защищенности базы данных разработанной информационной системы, является использование средств СУБД SQL Server 2008, таких как:

авторизация и аутентификация;

шифрование трафика и данных;

изоляция учетных записей от объектов базы данных;

выполнение кода с минимальными привилегиями;

аудит;

сокрытие метаданных.

Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу. Право доступа, согласно ГОСТ Р 50922-2006 «Защита информации. Основные термины и определения» (Дата последнего переиздания 13.12.2007), это совокупность правил доступа к информации, установленных правовыми документами или собственником, владельцем информации.

SQL Server 2008 поддерживает два режима аутентификации: аутентификация с помощью SQL Server и аутентификация с помощью Windows. Последний режим является рекомендуемым, т.к. позволяет реализовать решение, основанное на однократной регистрации пользователя и на едином пароле доступа к различным приложениям, что упрощает работу пользователей, избавляя их от запоминания множества паролей и снижая риск хранения. В результате аутентификации, согласно ГОСТ Р 34.10-94 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма» (Дата последнего переиздания 01.06.1994), вторая сторона убеждается, что субъект действительно тот за кого он себя выдает. Наиболее распространенной является парольная аутентификация. Главное достоинство парольной аутентификации - простота и привычность.

SQL Server 2008 содержит встроенные средства шифрования, цифровой подписи и верификации данных с помощью симметричных ключей (поддерживаются алгоритмы шифрования RC4, RC2, DES, AES) и асимметричных ключей (алгоритм RSA).

Весь трафик между клиентом и сервером по умолчанию шифруется с применением протоколов IP Security (IP SEC) и Secure Sockets Layer (SSL). При необходимости можно определить политику безопасности, полностью запрещающую обмен незашифрованными данными между клиентом и сервером, что снижает риск утечки данных, полученных путем перехвата трафика. СУБД также поддерживает шифрование самих хранимых данных, полностью интегрированное с инфраструктурой управления ключами.

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

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

СУБД SQL Server 2008 реализует принцип минимальных привилегий, позволяет, выполнять хранимые процедуры и функции, определяемые пользователем, с правами другого пользователя. Также. SQL Server 2008 позволяет указать контекст безопасности, в котором будут выполняться те или иные операторы программного модуля, то есть учетной записи, используемой при проверке разрешений на объекты, на которые ссылается процедура или функция.

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

Аудит, согласно ГОСТ Р 50.1.053-2005 «Информационные технологии, основные термины и определения в области технической защиты информации», - проверка реализованных в автоматизированной информационной системе процедур обеспечения безопасности с целью оценки их эффективности и корректности, разработки предложений по их совершенствованию, а также способ выявления некорректных или неавторизованных действий пользователей.

SQL Server 2008 поддерживает несколько способов поддержки аудита. В частности, можно использовать Windows Security EventLog (механизм отслеживания обращений к объектам, применения прав, попыток аутентификации) и SQL Profiler (средство осуществления детального аудита попыток доступа к объектам БД), а также триггеры (механизм отслеживания попытки изменения метаданных пользователями или полного их запрещения).

В SQL Server 2008 системные объекты находятся в скрытой базе mssqlsystemresource, а пользователям доступны представления Catalog Views для обращения к системным таблицам, причем данные из этих представлений фильтруются в зависимости от того, кто делает запрос. Имеется и специальное разрешение VIEW DEFINITION, позволяющее обойти сокрытие метаданных всей базы данных, схемы или конкретного объекта.

4.1.3 Оценка надежности разработанной АИС

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

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

В соответствии с ГОСТ Р 50.1.053-2005 «Информационные технологии, основные термины и определения в области технической защиты информации», обеспечен требуемый уровень защищенности информационных ресурсов автоматизированной информационной системы, которые включают в себя документы и массивы документов, используемые в системе.

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

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

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

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

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

В процессе работы с АИС учета услуг предприятия и управления персоналом, полностью удовлетворяющей требованиям для прохождения аттестации рабочих мест, а также ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению» (Дата последнего переиздания 01.11.2004), пользователь испытывает минимальное напряжение, ввиду создания комфортных условий труда, что приводит к увеличению производительности труда, сокращению усталости и уменьшению утомляемости.

4.2 Оценка напряженности трудового процесса пользователя АИС

Оценка напряженности труда осуществляется в соответствии с «Методикой оценки напряженности трудового процесса» руководства Р 2.2.2006-05 «Гигиеническими критериями оценки условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса». Напряженность трудового процесса оценена в соответствии с рекомендациями данного руководства.

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

4.2.1 Нагрузки интеллектуального характера

4.2.1.1 Содержание работы

В процессе управленческой деятельности, пользователь АИС учета услуг предприятия и управления персоналом решает следующие задачи:

формирование договоров;

составление прайс листов;

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

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

мониторинг введенной информации;

поиск организаций по различным реквизитам;

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

управление учетными данными пользователей;

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

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

Таким образом, решаемый набор задач по указанным выше признакам относится классу 3.1. «сложных задач с выбором по известным алгоритмам». Ранее класс оценки сложности решаемых задач составлял 3.2., т. к. способы решения задачи заранее были не известны.

4.2.1.2 Восприятие сигналов (информации) и их оценка

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

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

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

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

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

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

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

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

4.2.1.4 Характер выполняемой работы

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

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

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

4.2.2 Сенсорные нагрузки

4.2.2.1 Длительность сосредоточенного наблюдения (в % от времени смены)

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

В результате разработки АИС наблюдается снижение длительности сосредоточенного наблюдения за счет отсутствия необходимости работы с бумажными документами и составления графика работ и составляет 30-40 % от времени смены, что соответствует классу 2.

4.2.2.2 Плотность сигналов (световых, звуковых) и сообщений в среднем за 1 час работы

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

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

Таким образом, напряженность трудового процесса по плотности сигналов относится к классу 1.

4.2.2.3 Размер объекта различения при длительности сосредоточенного внимания (% от времени смены)

В качестве основы размеров объекта различения взяты категории зрительных работ из СНиП 23-05—2010 «Естественное и искусственное освещение».

В разработанной АИС наименьший размер объекта различения, в данном случае точки, равен 0,2-0,7 мм. Характер зрительной работы относится к средней точности. Но, поскольку требуется рассматривать лишь такой объект, который несет смысловую информацию, необходимую для выполнения данной работы, наименьшим объектом различения будет являться буквенная информация, размер которой при использовании шрифта Times New Roman 14 pt составляет 1,8-2.5 мм.

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

4.2.2.4 Наблюдение за экраном видеотерминала  в смену) 

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

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

4.2.2.5 Нагрузка на слуховой анализатор

Общий уровень шума от аппаратной части компьютера составляет 28- 40 дБ. Уровень речи превышает шум на 20 -30 дБ, следовательно, нагрузка на слуховой анализатор пользователя по классу напряженности условий труда откосится к классу 2. Разборчивость слов и сигналов при этом составляет 90—70%.

4.2.2.6 Нагрузка на голосовой аппарат (суммарное количество часов наговариваемых в неделю)

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

4.2.3 Эмоциональные нагрузки

4.2.3.1 Степень ответственности за результат собственной деятельности. Значимость ошибки

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

Снижение человеческого фактора позволяет отнести деятельность пользователя системы к классу 1.

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

4.2.3.2 Степень риска для собственной жизни.

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

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

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

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

Конфликтные ситуации в управленческой деятельности пользователя практически сведены к нулю, за счет автоматизации процесса управленческого учета и осуществления его по модели «Человек - Машина».

Разработанная АИС обладает удобным, эргономичным интерфейсом и соответствует требованиям конечного пользователя к функциональности системы, а также ГОСТ Р ИСО\МЭК 9126-93 «Государственный стандарт на оценку качества программной системы» (Дата последнего переиздания 01.11.2004) и не вызывает трудностей при работе участников управленческого учета.

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

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

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

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

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

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

В процессе работы пользователя с АИС, с учетом работы по модели «Человек - Машина», время активных действий составляет 90 % к продолжительности смены и оценивается классом 2.

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

Функция непосредственного наблюдения осуществляются следующими АРМ:

АРМ администратора;

АРМ руководителя отдела нормативно справочной информации;

АРМ руководителя отдела кадров.

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

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

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

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

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

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

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

Таким образом, по данному критерию напряженность труда относится к классу 1.

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

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

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

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

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

Показатели

Класс условий труда

1

2

3.1

3.2

3.3

1. Интеллектуальные нагрузки

1.1

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

+

*

1.2

Восприятие сигналов и их оценка

+

*

1.3

Распределение функции по степени сложности задания

+*

1.4

Характер выполняемой работы

+

*

2. Сенсорные нагрузки

2.1

Длительность сосредоточенного наблюдения

+

*

2.2

Плотность сигналов за 1 час работы

+*

2.3

Число объектов одновременного наблюдения

+

2.4

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

+*

2.5

Работа с оптическими приборами при длительности сосредоточенного наблюдения

+*

2.6

Наблюдение за экраном видеотерминала

+*

2.7

Нагрузка на слуховой анализатор

+*

2.8

Нагрузка на слуховой аппарат

+*

3. Эмоциональные нагрузки

3.1

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

+

*

3.2

Степень риска для собственной жизни

+*

3.3

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

+*

3.4

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

+

*

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

4.1

Число элементов, необходимых для реализации простого задания или многократно повторяющихся операций

+*

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

4.2

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

+*

4.3

Время активных действий

+*

4.4

Монотонность производственной обстановки

+*

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

5.1

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

+*

5.2

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

+*

5.3

Наличие регламентных перерывов и их продолжительность

+*

Количество показателей в каждом классе до внедрения АС(*)

7

8

6

1

Количество показателей в каждом классе после внедрения АС(+)

10

9

4

0

Общая оценка напряженности труда

+*

Примечание: более 6 показателей относятся ко 2 классу, 1 показатель

отнесен ко классу 3.1, поэтому общая оценка напряженности труда участника процесса управленческой деятельности соответствует классу 2.

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

Также, проведя анализ таблицы 1, стало очевидным преимущество и Целесообразность разработанной АИС в результате снижениям напряженности труда по отдельным показателем. Наблюдается переход Указателей из класса напряженности 2 в класс 1 и из класса 3.2 в 3.1.

Разработанная АИС обладает удобным, эргономичным интерфейсом и отвечает требованиям конечного пользователя к функциональности системы и полностью соответствует ГОСТ Р ИСО/МЭК 9126-93 «Государственный стандарт на оценку качества программной системы» (Дата последнего переиздания 01.11.2004). АИС учета услуг предприятия и управления персоналом полностью удовлетворяет всем требованиям, определенным в постановке задачи.


ЗАКЛЮЧЕНИЕ

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

Основными особенностями данной системы являются:

формирование прайс листов и управление услугами предприятия;

эргономичный интерфейс, отвечающего требованиям к функциональности системы;

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

функциональное использование информации, хранящейся в базе данных;

формирование и выдача на экран монитора информации;

обеспечение механизма разграничения прав доступа;

информационная безопасность системы.

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

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

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

В рамках исследования безопасности жизнедеятельности был проанализирован вопрос обеспечения безопасности хранения информации в СУБД MS SQL Server 2008.


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

АИС - автоматизированная информационная система;

КТС - комплекс технических средств;

ТО - техническое обеспечение;

АС - автоматизированная система;

БД - база данных;

СУБД - система управления базами данных;

ОЗУ - оперативное запоминающее устройство;

ОС - операционная система;

ПИ - пользовательский интерфейс;

ФИО - фамилия имя отчество.


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

1. Мацяшек, Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML [Текст]/Л.А. Мацяшек. - М.: Изд-во Вильяме, 2002. - 432 с.

2. Киммел, П. UML. Основы визуального анализа и проектирования UML [Текст]/ П. Киммел. - М.: НТ Пресс, - 2008. - 272 с.

3. Якобсон, А. Унифицированный процесс разработки программного обеспечения [Текст]/ А. Якобсон, Г. Буч, Дж. Рамбо. - М: ДМК Пресс; СПб.: Питер, 2002. - 496 с.

4. Зайцев, СЛ. Проектирование баз данных с ERwin. Вазовые концепции моделирования данных (Часть 1) [Текст]/С.Л. Зайцев. 03.06.2002.

5. Эрик Фримен, Элизабет Фримен при участииКэтти Ськрра и Берта Бейтса. Паттерны проектирования 2012. – 645 с.

6. Виейра, Р. Программирование баз данных Microsoft SQL Server 2005. Базовый курс [Текст]/Р. Виейра, М.: Диалектика, 2007. - 832 с.

7. Официальный сайт. Libra Hospitality. SquirrelOne POS. [Электронный ресурс]. - http://librahospitality.com

8. Герберт Шилдт «Java. Полное руководство» 8-е издание.  2012. – 1102 с

.9. Официальный сайт. Интерактивная документация по СУБД MS SQL Server. [Электронный ресурс]. - http://www.xmarks.com/site/msdn.microsoft.com/ en-us/library/ms950403.aspx

10. Трофимов, С.A. CASE-технологии. Практическая работа в Rational Rose [Текст]/С.А. Трофимов. - Изд. 2-е. - М.: Бином-Пресс, 2002. - 288 с.

11. Коннолли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика [Текст]/ Т. Коннолли, К. Бегг, А. Страчан, CПб.: Питер, 2004. - 496 с.

12. Трофимов Дерябкин, В.П. Преддипломная практика и дипломное проектирование по специальности «Автоматизированные системы обработки иформации и управления». Метод. Указ. / В.П. Дерябкин, А.В. Баландин, К.Е. Климентьев , Самарский Аэрокосмический университет Самара, 2008. -38 с.

13. Суханов, С.В. Оформление выпускной квалификационной работы (специалиста, бакалавра, магистра) [Метод. указания] / С.В, Суханов, Самарский гос. аэрокосм университет Самара, Самара, 2010.-24 с

14. Куренкова, В.П. Технико-экономическое обоснование создания автоматизированных систем и программных продуктов [Метод. указания] / В.П. Куренкова, Самар. гос. аэрокосм университет  - Самара, 2006.-30 с.

15. Вендров, А.М,  проектирование программного обеспечения экономических информационных систем [Текст]/ А.М. Вендров. – Финансы и статистика, - 2005. – 544с.


АИСУиОД ГТЦ «Газпром» предназначена для организации процесса ^правленческой деятельности, анализа данных реализаций удаленных точек гтЦ «Газпром» и получения информационных и статистических данных.

А.2 Краткое описание программы

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

A3 Описание работы с программой

Работа с системой начинается с запуска формы авторизации пользователя и ввода соответствующих данных авторизации для входа в систему. Форма авторизации приведена на рисунке АЛ. После успешной проверки введенных параметров осуществляется вход в систему, в результате йо появляется главное окно программы, приведенное на рисунке А.2. При ^дачной попытке входа система отклоняет введенные данные авторизации "выдает сообщение, приведенное на рисунке A3

Рисунок 1.3 – Физическая модели АИС управления услуг предприятия и его персонала, модуль отдел нормативно справочной информации

Рисунок 1.3 – Физическая модели АИС управления услуг предприятия и его персонала, модуль отдел кадров

Рисунок 1.3 – Физическая модели АИС управления услуг предприятия и его персонала, модуль администратор

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

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

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

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

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

МФУ

TCP/IP

Рисунок 1.3 – Логическая  модели АИС управления услуг предприятия и его персонала, модуль отдел нормативно справочной информации

Science.exe

Клиент

MS SQL Server 2008

Рисунок 1.2– Логическая  модели АИС управления услуг предприятия и его персонала, модуль отдел кадров

Рисунок 1.1 – Логическая  модели АИС управления услуг предприятия и его персонала, модуль администратор


 

А также другие работы, которые могут Вас заинтересовать

42616. ЛОГИЧЕСКИЕ И АРИФМЕТИЧЕСКИЕ ОПЕРАЦИИ 84.5 KB
  Тогда можно утверждать что дождь начался в time1 = h1 60 m1 минут а закончился в time2 = h2 60 m2 минут. Разность между началом и концом дождя составляет timeRes = time2 – time1 24 60 24 60 минут. Выделяем количество часов и минут из timeRes и выводим их на экран.h int h1 h2 m1 m2 time1 time2 timeRes hres mres; void minvoid { h1 = 23; m1 = 50; h2 = 13; m2 = 20; time1 = h1 60 m1; time2 = h2 60 m2; timeRes = time2 time1 24 60 24 60; hres = timeRes 60; mres =...
42617. Получить сумму тех элементов последовательности 49 KB
  Получить b1bn где bi это значение первого по порядку положительного элемента iой строки если таких элементов нет то принять bi =1 2. Присвоим переменной а1 значение равное остатку от деления iтого элемента массива на 5 а переменной а2 значение равное остатку от деления iтого элемента массива на 2. Если значение переменной а1 будет равно нулю т. iый элемент массива нацело поделился на 5 а значит он кратен 5 то прибавим к значению переменной sum1 значение iтого элемента массива.
42618. Системы счисления. Десятичная система счисления 100 KB
  Для задачи Rounder функция min имеет вид: void minvoid { Rounder s; int res = s.round1234567; printf d n res; } Калькулятор зарплаты SlryClcultor Работая в компании за первые 200 часов работник получает зарплату в размере p1 долларов в час каждый месяц. void minvoid { SlryClcultor s; double res = s.clcHours82812140; printf lf n res; } Убежать из прямоугольника EscpeFromRectngle Вы находитесь в точке x y внутри прямоугольника нижний левый угол которого имеет координаты 0 0 а правый верхний w...
42619. ОПРЕДЕЛЕНИЕ ТВЁРДОСТИ МАТЕРИАЛОВ 1.45 MB
  Изучить методы определения твердости материалов устройство и работу твердомеров. Для оценки качества азотированных и цементированных деталей знание твердости является основным. По твердости можно судить о некоторых других механических характеристиках материала – модуле упругости Е пределе пропорциональности ПР пределе текучести y пределе прочности Вударной вязкости и др. Например для конструкционных углеродистых сталей при твердости по Бринеллю НВ 1500 4500 МПа можно определить величину предела прочности В из...
42621. ПРОЕКТНЫЙ АНАЛИЗ 494 KB
  Продолжительность капитальных вложений в создание нового производства (новой технологической линии) составляет 3 года с распределением по годам 50% : 25% : 25%. Необходимые объемы капитальных вложений в здания, сооружения и оборудование соответственно равны: $250,000; $240,000; $1,700,000.
42622. Вивчення елементів середовища СУБД MS Access 69.5 KB
  Створити порожнью базу даних СУБД СУБД MS ccess. Вивчити склад та призначення об’єктів бази даних СУБД MS ccess. Вивчити функції та призначення командних кнопок вікна управління базою даних СУБД MS ccess.
42623. ДОСЛІДЖЕННЯ ПРОГРАМНИХ ОБ'ЄКТІВ НАПЕРЕДВИЗНАЧЕНИХ ТИПІВ ТА ОПЕРАЦІЙ НАД НИМИ 215.5 KB
  Декларація об’єкта включає його ідентифікатор та індикатор типу. Опис програмних обєктів Паскаль: опис константи ::=const ідентифікатор = статичний вираз опис змінної ::= vr ідентифікатор : індикатор типу { базування }01 індикатор типу ::= ідентифікатор індикатор напередвизначеного типу базування ::=bsolute зображення значення вказівного типу bse ідентифікатор Наприклад: const PI = 3.14; опис константи PI vr sum : integer; опис змінної sum опис змінної mult розташованої в тому місті памяті що і sum vr mult: longint bse sum; опис...
42624. ДОСЛІДЖЕННЯ ВИРАЗІВ 139.5 KB
  Таблиця 1 Пріоритет Операції Сі Операції Паскаль Категорія Перший @ ^ Спеціальні операції Другий not Унарні операції Третій nd shl shr Бінарні операції Четвертий or xor Бінарні операції П’ятий = = = Бінарні операції Шостий == = = = ^ Бінарні операції Вирази які мають лише константи та літерали називаються R виразами і можуть розташовуватися лише в правий частині оператора присвоєння. Завдання Написати програми на мовах Паскаль та Сі які складаються з...