Информационная система обслуживания клиентов центра занятости населения

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

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

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

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

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

Информационные объекты. Функциональная модель позволяет идентифицировать все информационные объекты, которыми оперирует предприятие в своей деятельности. В отличие от информационных моделей (DataFlowDiagrams, IDEF1X) функциональная модель IDEF0 отражает, как именно используются информационные объекты в рамках деловых процессов.

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

Далее изображена контекстная диаграмма (Рис. 2.4) разрабатываемой модели.

Рис. 2.4 - Контекстная диаграмма

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

Заявления работодателей;

Заявления соискателей;

Анкетные данные соискателей;

Данные работодателей.

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

Должностные инструкции сотрудников центра занятости;

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

Распоряжения начальства.

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

Списки кандидатов;

Контракты;

Обработанные резюме.

Ресурсами и механизмами были приняты:

Психолог;

Рекрутер;

Аналитик;

Начальник подразделения;

Эксперт.

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

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

В какой последовательности выполняются эти процедуры;

Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес процесса;

Какие входящие документы/ информацию использует каждая процедура процесса;

Какие исходящие документы/информацию генерирует процедура процесса;

Какая документация/условия регламентирует выполнение процедуры;

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

На диаграмме изображены основные функции, выполняемые центром занятости (Рис.2.5):

Рис. 2.5 - Декомпозиция контекстной диаграммы

Поиск персонала состоит из следующих этапов:

Учет кадров и их движение (Рис.2.6);

Принятие и утверждение предложения клиентом, подписание контракта;

Рис. 2.6 - Учет кадров и их движение

Сбор информации о заказе:

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

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

Разработка первичного предложения:

- постановка задачи,

- оценка ресурсов,

- определение консультантов, которые будут участвовать в проекте,

- выбор метода решения поставленной задачи,

- обозначение этапов работы,

- определение графика выполнения проекта,

- проектирование системы контроля выполнения плана,

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

Исследование сферы профессиональной среды, в которой работают потенциальные кандидаты.

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

- Описание критериев успешности профессиональной деятельности.

- Описание психологической составляющей успешности.

- Общие особенности.

- Основные операции и действия, которые необходимо совершать сотруднику.

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

- Режим труда и отдыха.

- Характер психофизиологического состояния (монотонность/ напряженность, утомление и т.д.).

- Объем и характер перерабатываемой информации.

- Возможность общения.

- Возможность принятия решений, и пр.

Первичная проверка квалификации кандидатов (Рис.2.7):

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

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

- Беседа со специалистами.

- Сбор информации и квалификационных вопросов для проведения интервью с кандидатами.

информационный система центр занятость

Рис. 2.7 - Первичная проверка квалификации кандидатов

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

- Сбор информации о возможных кандидатах и первичная проверка их квалификации

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

- Рассмотрение первичного списка кандидатов с клиентом

Подписание контракта

Итоговая встреча клиента с кандидатом

- Уточнение условий работы отобранного кандидата;

- Уточнение дня выхода кандидата на работу;

- Оформление необходимой документации и согласование сроков оплаты, периода гарантии.

Построение информационной модели центра занятости «какнадо».

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

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

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

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

Рис. 2.8 - Структурная модель согласования целей работодателя и соискателя

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

Определим формальное задание глобальной цели k-го лица, ищущего работу в виде набора:

(2.1)

где , - i-й компонент глобальной цели лица, ищущего работу.

Определим формальное задание глобальной цели p-го работодателя в виде набора:

(2.2)

где , - j-й компонент глобальной цели работодателя.

В виде компонентов глобальной цели примем:

Вид работы;

Величина заработной платы;

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

Наличие ведомственного жилья;

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

Соответствие кандидата уровню требования работодателя и прочее.

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

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

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

Согласно рисунку 2.9, решение о приеме на работу во многом зависит от того, насколько совпадают цели кандидата и работодателя. Степень совпадения целей кандидата и работодателя следует определять, применяя такие операции теории нечеткой логики, как степень включения, определение степени нечеткого равенства, определение степени нечеткой эквиваленсии[13]

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

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

, (2.3)

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

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

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

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

Соискатель при составлении заявки устанавливает соответствие между элементами множеств , и элементами множества , причем элементы riимеют вербальное определение, например, R = {предприятие с тяжелыми условиями труда, предприятие с низким уровнем зарплаты, предприятие с хорошим соцпакетом, предприятие с высоким уровнем требований и т.д.}.

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

Каждого i-го соискателя можно формально определить вектором конструктивных параметров:

, (2.4)

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

Таким образом, особенность подбора кандидатур на конкретную вакансию в структурном виде можно изобразить схемой, показанной на рис. 2.9.

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

Рис. 2.9 - Структурная схема подбора персонала

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

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

2.4 Модель подбора персонала

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

q=(X,Y,Q) (2.5)

где Q- график соответствия, подлежащий идентификации.

На концептуальном уровне формализацию системы подбора персонала можно представить следующим образом (рис. 2.10).

Рис. 2.10 - Система подбора персонала

В системе подбора персонала X- множество управляющих параметров, F-возмущающие воздействия, Z-множество состояний системы, Y- набор выходных параметров, получаемый по следующей формуле:

Y=W(Z,X) (2.7)

где W - правило преобразования.

Модель системы подбора персонала может быть представлена в виде функции выходов:

, так что (2.8)

где F - график соответствия f.

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

Подбор кандидатуры моделируется в виде всюду определенного соответствия или отображения q=(X,Y,Г), Г: X>Y, где X-область отправления отображения, представляющая собой набор хранящихся в базе данных заявок, Y- получаемое решение, Г - закон, в соответствии с которым осуществляется отображение, причем под символом может пониматься любая математическая операция, совокупность операций или любой из операторов.

Отображение может быть нечетким, заданным тройкой множеств , в которой -нечеткое множество, заданное в произвольном базовом множестве XЧY. Четкое соответствие Г=(X,Y,F) является носителем нечеткого соответствия , а график F является носителем нечеткого графика.

Таким образом, в модели поиска персонала, изображенной на рис. 2.5, первичная проверка квалификации кандидатов, изображенная на рис. 2.7, будет осуществляться ИС центра занятости автоматически, в результате чего существенно снизится нагрузка на рекрутеров, и на этап интервьюирования будут попадать уже тщательно отобранные кандидатуры. При этом влияние человеческого фактора будет снижено, а присутствие этапа интервьюирования (рис. 2.11) позволит оценить достоверность заполнения заявки соискателем.

Рис. 2.11 - Интервью с кандидатами в центре занятости, психологическое тестирование, ролевая игра

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

3. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ЦЕНТРА ЗАНЯТОСТИ

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

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы (рис. 3.1):

системы на основе архитектуры файл-сервер;

системы на основе архитектуры клиент-сервер;

системы на основе многоуровневой архитектуры;

системы на основе интернет/интранет-технологий.

Рис. 3.1 - Деление информационных систем по способу организации

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

Таблица 3.1 - Типовые функциональные компоненты информационной системы

3.2 Архитектура файл-сервер

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

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

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

3.3 Архитектура клиент-сервер

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

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере (рис. 3.2).

Рис. 3.2 - Классический вариант клиент-серверной информационной системы

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

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

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

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

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

3.4 Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней (рис. 3.3)

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

- средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

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

Рис. 3.3 - Классический вариант многоуровневой информационной системы

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистами узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейс, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле,передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все болееочевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако прикладные серверы можно строить на базе Microsoft Windows NT с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.

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

3.5 Интернет/интранет-технологии

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

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

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

Проектирование структуры ИС

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

Выделение вариантов использования и пользователей ИС;

Проектирование модульной структуры ИС;

Проектирование схемы развертывания ИС.

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

Варианты использования ИС

Определим пользователей и варианты использования информационной системы центра занятости. Cэтой целью применим диаграммы вариантов использования (UseCase)нотации UML2.0 (рис. 3.4).

Рис. 3.4 - Варианты использования ИС центра занятости

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

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

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

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

3.6 Модульная структура ИС

Исходя из вариантов использования ИС центра занятости, спроектируем далее модульную структуру проектируемого приложения. Для определения модульной структуры воспользуемся диаграммой компонентов нотации UML 2.0 (рис. 3.5).

Рис. 3.5 - Модульная структура ИС

Информационная система центра занятости состоит из трех компонентов:

Интерфейс. Реализация взаимодействия пользователей с информационной системой. Содержит в себе следующие модули:

Ввод/вывод - организация ввода и вывода информации при работе с ИС;

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

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

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

БД. Реализация хранилища данных, в котором содержится информация о клиентах.

Схема развертывания ИС

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

Рис. 3.6 - Схема развертывания ИС

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

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

3.7 Разработка структуры БД

Как уже говорилось ранее, в информационной системе вся информация хранится в единой БД. Для моделирования логической структуры базы данных была применена методология IDEF1x. Согласно данной методологии, [14],процесс построения информационной модели состоит из следующих шагов:

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

задание первичных и альтернативных ключей;

определение атрибутов сущностей;

приведение модели к требуемому уровню нормальной формы;

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

задание триггеров, процедур и ограничений;

генерация базы данных.

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

Логическая структура базы показана на рис. 3.7.

Рис. 3.7 - Логическая структура БД

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

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

ФИО - фамилия, имя, отчество соискателя (первичный ключ);

Пол - пол соискателя;

Дата рождения соискателя;

Паспортные данные - серия и номер паспорта, кем и когда выдан (первичный ключ);

Адрес - домашний или контактный адрес соискателя;

Телефон - контактный телефон;

Стаж - стаж работы соискателя;

Воинский учет - данные о службе в армии;

Фото - фотография соискателя;

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

Резюме - атрибут, хранящий резюме соискателя;

Заметки - заметки по кандидатуре соискателя, сделанные рекрутером;

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

ФИО - фамилия, имя, отчество соискателя (внешний ключ);

Паспортные данные - серия и номер паспорта, кем и когда выдан (внешний ключ);

Должность - должность, занимаемая в прошлом соискателем;

Место работы - прошлое место работы согласно должности;

Дата приема на работу;

Дата увольнения;

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

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

ID работодателя - уникальный идентификационный номер (первичный ключ);

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

Тип - тип работодателя: организация, частное лицо и т.д.;

Юридический адрес;

Физический адрес;

Контактный телефон;

ИНН;

Номер свидетельства;

Заметки - замечания, сделанные рекрутером.

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

Наименование - предлагаемая должность (первичный ключ);

ID вакансии - уникальный идентификационный номер (первичный ключ);

Описание - описание предложения;

Заработная плата;

График работы;

Требования - требования к соискателю;

ФИО - фамилия, имя, отчество соискателя (внешний ключ);

Паспортные данные - серия и номер паспорта, кем и когда выдан (внешний ключ);

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

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

Рис. 3.8 - Физическая модель БД

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

ID должности - уникальный номер должности (первичный ключ);

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

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

4. РЕАЛИЗАЦИЯ ПРОЕКТА