Автор работы: Пользователь скрыл имя, 17 Мая 2015 в 22:02, курсовая работа
На базе разработанной информационной системы обеспечивается решение следующих задач:
Расширение сферы безбумажного делопроизводства и документооборота внутри организации;
Управление прайс-листами и услугами организации;
Организация рекламных кампаний
Подготовка и заключение договоров со сторонними организациями;
Оформление приема, перевода и увольнения работников;
Разграничение прав доступа;
ВВЕДЕНИЕ 11.
1 СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ 13.
1.1 Описание предметной област 13.
1.4 Определение логической структуры АИС 14.
1.4.1 Логическое проектирование 14.
1.4.2 Логическая модель АИС 15.
1.4.3 Нормализация 21.
1.5 Разработка информационно-логической структуры системы 22.
1.5.1 Краткое описание методологии UML 22.
1.5.2 Диаграмма вариантов использования 23.
1.5.3 Диаграмма классов 28.
1.5.4 Диаграмма состояний 32.
1.5.5 Диаграмма деятельности 35.
2 КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ 37.
2.1 Физическая модель базы данных 37.
2.2 Выбор и обоснование программных средств разработки 41.
2.3 Выбор технических средств и ресурсный анализ 42.
2.3.1 Расчет необходимого объема памяти 42.
2.3.2 Расчет времени реакции системы 43.
2.3.3 Требования к комплексу технических средств 44.
2.4 Разработка программного обеспечения 45.
2.4.1 Структура программной системы 45.
2.4.1.1 Диаграмма компонентов 46.
2.4.1.2 Диаграмма развертывания 47.
2.4.1.3 Описание модулей системы 48.
2.4.3 Разработка интерфейса системы 50.
3 ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ АИС УПРАВЛЕНИЯ УСЛУГ ПРЕДПРИЯТИЯ И ЕГО ПЕРСОНАЛА 55.
3.1 Планирование и организация процесса разработки 55.
3.2 Технико-экономическое обоснование автоматизированной информационной системы (АИС) 62.
3.2.1 Расчет затрат на разработку автоматизированной информационной системы (АИС) 63.
3.2.2 Расчет-прогноз минимальной цены разработки автоматизированной информационной системы (АИС) 65.
3.2.3 Оценка безубыточности и расчет целесообразного объема продаж 67.
3.2.4 Расчет единовременных затрат на внедрение 69.
3.2.5 Расчет текущих затрат на функционирование АИС 71.
3.2.6 Расчет экономических результатов от внедрения 72.
3.2.7 Методы расчета экономической эффективности инвестиционных (капитальных) затрат 73.
4 БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ 77.
4.1 Обеспечение безопасности объекта автоматизации 79.
4.1.1 Информационная безопасность в СУБД SQL Server 2008 80.
4.1.3 Оценка надежности разработанной АИС 83.
4.2 Оценка напряженности трудового процесса пользователя АИС 85.
4.2.1 Нагрузки интеллектуального характера 85.
4.2.1.1 Содержание работы 85.
4.2.1.2 Восприятие сигналов (информации) и их оценка 86.
4.2.1.3 Распределение функций по степени сложности задания 87.
4.2.1.4 Характер выполняемой работы 88.
4.2.2 Сенсорные нагрузки 88.
4.2.2.1 Длительность сосредоточенного наблюдения (в % от времени смены)…… 88.
4.2.2.2 Плотность сигналов (световых, звуковых) и сообщений в среднем за
1 час работы 89.
4.2.2.3 Размер объекта различения при длительности сосредоточенного
внимания (% от времени смены) 89.
4.2.2.4 Наблюдение за экраном видеотерминала (ч в смену) 89.
4.2.2.5 Нагрузка на слуховой анализатор 90.
4.2.2.6 Нагрузка на голосовой аппарат (суммарное количество часов наговариваемых в неделю) 90.
4.2.3 Эмоциональные нагрузки 90.
4.2.3.1 Степень ответственности за результат собственной деятельности. Значимость ошибки 90.
4.2.3.2 Степень риска для собственной жизни. 91.
4.2.3.3 Ответственность за безопасность других лиц 91.
4.2.3.4 Количество конфликтных производственных ситуаций за смену 91.
4.2.4 Монотонность нагрузок 92.
4.2.4.1 Продолжительность выполнения простых производственных заданий или повторяющихся операций. 92.
4.2.4.2 Время активных действий (в % к продолжительности смены)…… 92.
4.2.4.3 Монотонность производственной обстановки (время пассивного
наблюдения за ходом техпроцесса, в % от времени смены) 92.
4.2.5 Режим работы 93.
4.2.5.1 Фактическая продолжительность рабочего дня 93.
4.2.5.2 Сменность работы 93.
4.2.5.3 Наличие регламентированных перерывов и их продолжительность
(без учета обеденного перерыва) 93.
4.2.5.4Общая оценка напряженности трудового процесса 93.
ЗАКЛЮЧЕНИЕ 97.
СПИСОК СОКРАЩЕНИЙ 99.
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ 100.
СОДЕРЖАНИЕ
4.2.3.3 Ответственность за безопасность других лиц 91.
4.2.3.4 Количество конфликтных производственных ситуаций за смену 91.
4.2.4 Монотонность нагрузок 92.
4.2.4.1 Продолжительность выполнения
простых производственных
4.2.4.2 Время активных действий (в % к продолжительности смены)…… 92.
4.2.4.3 Монотонность
производственной обстановки (время пассивного
наблюдения за ходом техпроцесса, в % от
времени смены) 92.
4.2.5 Режим работы 93.
4.2.5.1 Фактическая продолжительность рабочего дня 93.
4.2.5.2 Сменность работы 93.
4.2.5.3 Наличие
регламентированных перерывов и их продолжительность
(без учета обеденного перерыва) 93.
4.2.5.4Общая оценка напряженности трудового процесса 93.
ЗАКЛЮЧЕНИЕ 97.
СПИСОК СОКРАЩЕНИЙ 99.
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ 100.
ВВЕДЕНИЕ
Информационные системы являются социальными системами, целью разработки которых является предоставление заказчику продуктивной системы. Разработке программного обеспечения предшествует системное планирование, в ходе которого определяется, какие продукты будут наиболее эффективными для организации.
Для системы, разрабатываемой «с нуля», необходимо создать концептуальные конструкции (модели) для конечного решения, которые бы удовлетворяли специфические потребности организации. После их создания функциональные возможности программного пакета настраиваются в соответствии с концептуальными конструкциями .
Также, существует небольшая вероятность, с которой организация могла бы найти программный пакет для автоматизации ее ключевых бизнес-процессов. Ключевым бизнес-процессом, в рамках текущей разработки для ООО КДЛ «Наука» выступает операционная деятельность организации.
ООО Клинико-диагностическая лаборатория - ориентирована на оказание услуг по лабораторной диагностике различных заболеваний в самых актуальных областях медицины, а именно в области онкологии, гинекологии, заболеваний, передающихся половым путем, урологии, эндокринологии, иммунологии, женского и мужского бесплодия, патологии беременности.
Среди многих задач, связанных с работой КДЛ, одной из наиболее важных является задача управления услуг предприятия и его персонала. Для реализации данной задачи необходимо автоматизировать данный процесс.
На базе разработанной информационной системы обеспечивается решение следующих задач:
Расширение сферы безбумажного делопроизводства и документооборота внутри организации;
Управление прайс-листами и услугами организации;
Организация рекламных кампаний
Подготовка и заключение договоров со сторонними организациями;
Оформление приема, перевода и увольнения работников;
Разграничение прав доступа;
1 СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ
1.1 Описание предметной области.
Создаваемая система будет способна решать задачи связанные с управлением услуг предприятия и его персоналом.
Функции, реализуемые системой:
Функционал программного комплекса охватывает деятельность двух отделов: отдела нормативно справочной информации: и отдела кадров. Модуль отдела нормативно справочной информации позволяет работать с юридическими лицами, заключая договора на основе которых формируется прайс лист по оказываемым услугам, вести перечень филиалов а также проводить рекламные акции. Модуль отдела кадров позволяет хранить ученые данные сотрудников, время их работы и занимаемые должности.
Сотрудники, ведущие учет в организации, должны осуществлять контроль вводимых данных в системе для дальнейшего использования и ведения процесса управленческой деятельности.
Сотрудники имеют возможность формирования прайс листов, изменения данных по сторонним организациям, редактирования вида услуг, заключения договоров, осуществление приема и увольнения работников.
Эта информация, является важной для сотрудников, осуществляющих учет в организации, и должна исправно вестись и храниться в базе данных.
Разработанная информационная система должна обеспечивать ведение следующих справочных данных:
Также система должна реализовывать необходимый для работы набор функций:
1.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