Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Курсовая по сис.анализу

.pdf
Скачиваний:
15
Добавлен:
13.03.2016
Размер:
4.38 Mб
Скачать

Дополнительные сведения.

Примечания.

11

1.3.4.3. Входные и выходные документы

Входными документами для АРМа «Отдел кадров КБФГ» являются личные документы сотрудника, приказы по личному составу, заявления сотрудников, служебные записки и т.д.

АРМ «Отдел кадров КБФГ» позволяет сформировать и распечатать:

Приказ о приеме сотрудника на работу.

Приказ об увольнении сотрудника.

Личную карточку сотрудника.

Отчёты для планово-экономического отдела (4 типа).

Общие отчёты (4 типа).

Списки (10 типов).

Справки (4 типа).

1.3.4.4. Перечень нормативно-справочной информации

Нормативно-справочная информация, используемая в АРМе «Отдел кадров КБФГ» хранится в 14 файлах DBF-формата. Общий объём нормативно-справочной информации достигает 59 Кб.

Перечень нормативно-справочной информации:

Профессии.

Категории работников.

Условия труда.

Тарифная сетка.

Виды отпуска.

Национальность.

Семейное положение.

Образование.

Формы обучения.

Выходные дни для отпуска

Выходные для больничного

Основания увольнения.

Причины увольнения.

Причины выхода на пенсию

1.3.5. Анализ существующего АРМа «Отдел кадров КБФГ»

Существующий в настоящий момент АРМ «Отдел кадров КБФГ» не позволяет вести учёт кадров на фабрике в полной мере отвечающей современным требованиям, ему присущи следующие недостатки:

1.АРМ разработан для работы на одном компьютере. Это является «узким» местом в работе отдела кадров, в случае отказа компьютера работа будет невозможна.

2.Компьютер не подключен к локальной вычислительной сети фабрики.

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

12

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

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

5.База данных не содержит всех необходимых сведений о кадрах. За время эксплуатации АРМа изменились требования к выходным документам, поэтому появилась необходимость в новых данных о сотрудниках.

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

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

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

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

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

11.Сложность администрирования базы данных. Существующий АРМ реализован на СУБД FoxPro v2.5, не имеющей автоматической поддержки целостности базы, контроля ввода, связей между таблицами и других функций и возможностей, которые могут предоставить современные СУБД.

12.Низкий уровень защиты от несанкционированного доступа к информации.

Информация хранится в незащищённом виде.

13.Весь документооборот (входящие и выходящие документы отдела кадров)

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

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

Дальнейшее развитие существующего АРМа «Отдел кадров КБФГ» нецелесообразно. Назрела необходимость в создании принципиально новой системы кадрового учёта интегрированной в единую корпоративную информационную систему Краснокамской бумажной фабрики ГОЗНАК.

13

Глава 2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УЧЁТ КАДРОВ КБФГ»

2.1. Выбор архитектуры информационной системы

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

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

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

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

Между этими двумя крайними позициями существует огромное количество

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

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

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

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

сиспользованием хранимой информации (назовем их сервисом приложений);

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

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

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

14

Рис. 2.1. Одноуровневая архитектура информационной системы.

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

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

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

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

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

15

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

Рис. 2.2. Двухуровневая архитектура информационной системы.

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

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

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

16

Рис. 2.3. Трехуровневая архитектура информационной системы.

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

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

сервера данных;

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

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

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

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

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

17

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

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

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

2.2. Выбор сетевой топологии

Для автоматизации работы отдела кадров и построения локальной вычислительной сети (ЛВС) я предлагаю использовать топологию типа «Звезда» (Рис. 2.4).

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

Повторитель

Рабочая

Рабочая

Рабочая

Рабочая

Рабочая

станция

станция

станция

станция

станция

Рис. 2.4. Топология типа «звезда».

Сеть, построенная по топологии «Звезда», в отличие от других топологий, имеет несколько преимуществ:

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

18

2.При использовании недорогого кабеля типа «витая пара», затраты на построение ЛВС будут небольшие.

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

4.Высокая пропускная способность. Современное сетевое оборудование обеспечивает скорость передачи данных до 100 Мбит/сек.

Вкачестве центрального устройства я предлагаю применить «Коммутатор»

(Switch).

Коммутаторы имеют много отличий от повторителей. Повторители передают все

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

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

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

2.6.2.1. Моделирование данных

Моделирование данных – это процесс описания информационных структур и бизнес правил для определения потребностей информационной системы.

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

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

Модели процессов (диаграммы потоков данных, модели распределения, модели событий/состояний) могут быть созданы при помощи PLATINUM technology BPwin и других инструментов для документирования требований процессов. На разных стадиях разработки используются различные уровни этих моделей (Рис. 2.5.).

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

19

Рис. 2.5. Уровни проектирования базы данных IDEF1X

Примеры преимуществ получаемой модели

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

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

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

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

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

Примеры преимуществ, связанных с процессом создания модели

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

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

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

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

20