Рефераты. Автоматизация деятельности кадрового агентства (на примере КА "Фактор") /p>

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

Для представления бизнес-модели можно использовать один из популярных программных продуктов Computer Associates BPwin, версия 4.0

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

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать бизнес с трех ключевых точек зрения:

- функциональности системы (в рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой);

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

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

Для рассмотрения бизнес-процессов блока «Деятельность кадрового агентства» необходимо использовать методологию IDEF0.

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

В диаграмме по ведению деятельности кадрового агентства рассматривается процесс работы сотрудников. Все это отражается в диаграмме IDEF0 «Деятельность кадрового агентства» (Приложение 1).

После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан в Приложении 2. На диаграмме выделены основные этапы работы агента:

- Сбор заявок, анкет и резюме (необходимо собрать все анкеты, заявки и резюме, поступившие по различным каналам);

- Сортировка по должностям (необходимо отсортировать поступившие анкеты по тому, на какую должность претендует соискатель);

- Подшивка в папки (отсортированные анкеты, необходимо подшить в папки);

- Проверка соответствия анкет соискателей и заявки работодателя (необходимо подобрать персонал для каждой представленной вакансии)

- Проведения собеседования (по результатам отбора проводится собеседование с соискателем или работодателем).

1.2 Сбор требований

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

Для этого необходимо собрать все данные по формам и бланкам, которые заполняются сотрудниками КА «Фактор». (Приложение 3 - 6)

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

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

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

- эргономичность пользовательского интерфейса;

- ввод и редактирование различных видов данных;

- надежное хранение большого объема информации;

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

- возможности сравнения, сортировки;

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

Результатом проектирования на данной стадии является разработка технико-экономического обоснования (ТЭО) необходимости создания автоматизированной информационной системы (АИС) для КА «Фактор». (Приложение 7).

1.3 Анализ и моделирование требований

Модели, созданные на этапе определения требований необходимы для того, чтобы:

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

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

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

В данном случае опять целесообразно использовать BPWin и методологию IDEF0 (Приложение 8). Так, будем использовать ее и при декомпозиции процесса подбора персонала для конкретной заявки. (Приложение 9). Для некоторых процессов необходимо использовать диаграммы IDEF3, чтобы отразить альтернативные сценарии развития. Например, при декомпозиции процесса проведения собеседования (Приложение 10)

1.4 Спецификация и аттестация требований

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

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

1. Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать CASE - средства для проверки непротиворечивости моделей.

2. Обзор требований. Требования системно анализируется рецензентами.

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

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

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

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

Результатом данной стадии проектирования должно явится создания технического задания для КА «Фактор». (Приложение 11)

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

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

- методология функционального моделирования работ SADT;

- методология объектно-ориентированного анализа и проектирования на языке UML;

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

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

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

ЗАКЛЮЧЕНИЕ

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

СПИСОК ЛИТЕРАТУРЫ

1. А.М. Вендров CASE-технологии. Современные методы и средства проектирования информационных систем [Электронный документ]

2. Бизнес. Карьера. Успех. Настольная книга руководителя. Ростов-на-Дону, «Альтаир», 2006, с. 32

ПРИЛОЖЕНИЕ 1

ПРИЛОЖЕНИЕ 2

ПРИЛОЖЕНИЕ 3

ПРИЛОЖЕНИЕ 4

ПРИЛОЖЕНИЕ 5

ПРИЛОЖЕНИЕ 6

ПРИЛОЖЕНИЕ 7

ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ НЕОБХОДИМОСТИ СОЗДАНИЯ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ (АИС)

Исходные положения

Автоматизируемый объект - кадровое агентство «Фактор». Организационная структура поликлиники приведена на рисунке 1.

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

Характеристики и технико-экономические данные

В КА «Фактор» практически отсутствуют какие-либо технические средства. Только деятельность сотрудников бухгалтерии автоматизирована. В организации установлена типовая конфигурация 1С:Бухгалтерия. Передача данных из бухгалтерии в налоговую инспекцию производится лично бухгалтером. Передача распоряжений и документов производится при личном контакте.

Обоснование цели создания АИС

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

Внедрение АИС позволит автоматизировать многие процессы в КА «Фактор»: поиск и заполнение анкет и заявок, передачу их в случае необходимости другому сотруднику, формирование и передачу счета в кассу.

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

Обоснование комплексов задач и подсистем

Для обеспечения движения потоков информации в КА «Фактор» планируется создать локальную сеть 100Мбит (витая пара), звездной топологии. АРМ пользователя будет представлять собой ПК (Intel Celeron® CPU 2.00GHz, 512 МБ ОЗУ, 80 Гб). В качестве операционных систем АРМ и серверной ОС будет использоваться Windows XP. Проектирование будет проводиться посредством средств разработки индивидуальной конфигурации на основе 1С:Предприятие.

Перечень организационно-технических мероприятий для создания АИС

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

Обоснование эффективности создания информационной системы

Выводы и предложения

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

ПРИЛОЖЕНИЕ 8

ПРИЛОЖЕНИЕ 9

ПРИЛОЖЕНИЕ 10

ПРИЛОЖЕНИЕ 11

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

на разработку автоматизированной информационной системы

Исполнитель: Пискунов О.А

Утверждаю: ______________ Иванов И.И.

1. ОБЩИЕ СВЕДЕНИЯ

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

Заказчиком системы является Иванов Иван Иванович. Исполнителем выступает практикант Пискунов О.А.

Дата начала работ: 11.11.2007 г.

Дата окончания работ: 11.05.2008 г.

Пискунов О.А. выполняет разработку индивидуальной конфигурации для КА «Фактор» на основе 1С:Предприятие. Результатом работы является специально разработанная конфигурация для сотрудников, реализующий задачи поставленные заказчиком, и комплект документации по использованию АИС.

2. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ АИС

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

Создаются следующие рабочие места:

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

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

4. ТРЕБОВАНИЯ К СИСТЕМЕ

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

АИС должна поддерживать возможность конвертирования различных форм и отчетов в формат MS Excel.

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

В соответствии с организационной структурой предприятия АИС должна иметь 5 АРМ (Intel Celeron® CPU 2.00GHz, 512 МБ ОЗУ, 80 Гб). Должна существовать возможность дальнейшего расширения системы.

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ

1. Разработка индивидуальной конфигурации. Сроки выполнения: 11.11.2007 - 15.12.2007

2. Установка и наладка. Сроки выполнения: 16.12.2007 - 20.12.2007

3. Тестирование и доработка АИС. Сроки выполнения: 21.12.2007- 28.12.2007

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

6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ

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

7. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА К ВВОДУ В ДЕЙСТВИЕ СИСТЕМЫ

Персонал КА «Фактор» должен обладать базовыми знаниями в пользовании компьютерами. Перед началом тестирования системы Исполнитель обязуется обучить персонал организации работе с системой.

Страницы: 1, 2



2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.