Файл: Проектирование реализации операций бизнес-процесса «Управление персоналом» (Создание контекстной диаграммы).pdf

Введение

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

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

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

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

1. Анализ бизнес-процессов предприятия

1.1 Создание контекстной диаграммы

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

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

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

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

Рисунок 1. Функциональный блок

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

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

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

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

1.2 Диаграммы декомпозиции

Любой блок может быть декомпозирован на составляющие блоки. Функциональную декомпозицию можно определить как моделирование “снаружи вовнутрь”

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

Рисунок 3. Диаграмма декомпозиции 1 уровня

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

Рисунок 4. Декомпозиция второго уровня работы “Работа с фирмами работодателями”

Рисунок 5. Декомпозиция второго уровня работы «Работа с соискателями»

2. Проектирование ИС

2.1 Подходы к проектированию ИС

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

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

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

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

Во второй половине 80х годов появилось методология объектно-ориентированного программирования

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

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

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

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

2.2 Унифицированный язык моделирования UML

В настоящее время унифицированный язык моделирования UML [5] является визуальным языком моделирования, который позволяет системным архитекторам представить свое видение системы в стандартной и легкой для понимания форме. Кроме того, UML представляет эффективный механизм совместного использования проектных решений и взаимодействия разработчиков друг с другом.

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

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

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

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

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

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

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

Авторами UML являются Гради Буч (Grady Booch), Джеймс Румбах (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Известные как «три товарища», в 80-х – начале 90-х годов они работали в разных организациях и независимо друг от друга продумывали методологии объектно-ориентированного анализа и проектирования, которые имели явные преимущества перед всеми остальными известными методами. В середине 90-х годов они стали заимствовать идеи друг у друга и поэтому решили объединить свои усилия.

В 1994 году Румбаха пригласили в компанию Rational Software Corporation, где в это же время уже работал Буч. Через год к ним присоединился Якобсон.

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML может оказаться полезен для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.[6]

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться

Язык UML предназначен для решения следующих задач:

1. Предоставить пользователю легко воспринимаемый язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения.
2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей системы в ООАП (объектно-ориентированный анализ и проектирование)конкретной предметной области.
3. Ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования.
4. Поощрять развитие рынка объектных инструментальных средств.
5. Способность совершенствоваться.
6. Интегрировать в себя новейшие и наилучшие достижения практики