Для проведения анализа деятельности организации необходимо построить бизнес-модель. В отечественных компаниях укореняются такие понятия как моделирование бизнес-процессов и реинжиниринг бизнес-процессов.
Бизнес-моделирование – это разработка модели деятельности предприятия с целью решения определенных задач, стоящих перед ее менеджерами.
Для представления бизнес-модели можно использовать один из популярных программных продуктов 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. На диаграмме выделены основные этапы работы агента:
- Сбор заявок, анкет и резюме (необходимо собрать все анкеты, заявки и резюме, поступившие по различным каналам);
- Сортировка по должностям (необходимо отсортировать поступившие анкеты по тому, на какую должность претендует соискатель);
- Подшивка в папки (отсортированные анкеты, необходимо подшить в папки);
- Проверка соответствия анкет соискателей и заявки работодателя (необходимо подобрать персонал для каждой представленной вакансии)
- Проведения собеседования (по результатам отбора проводится собеседование с соискателем или работодателем).
При создании индивидуальной конфигурации, необходимо собрать требования, которые бы помогли создать интерфейс таким образом, чтобы конечному пользователю было просто и понятно ею пользоваться.
Для этого необходимо собрать все данные по формам и бланкам, которые заполняются сотрудниками КА «Фактор». (Приложение 3 – 6)
Данный этап является важным, поскольку именно здесь заказчиком и разработчиком рассматривается первоначальное создание виртуального программного обеспечения исходя из представленных требований. Поэтому требования, которые предоставляет заказчик, должны быть сформулированы правильно, четко и корректно.
Требования к новому программному обеспечению были собраны при помощи рассмотрения некоторых аналогичных решений. Этот метод достаточно интересен тем что, при его использовании был рассмотрен некоторый предыдущий опыт в данной области.
Заказчик представили ряд главных требований, которые должны быть рассмотрены в первую очередь:
- эргономичность пользовательского интерфейса;
- ввод и редактирование различных видов данных;
- надежное хранение большого объема информации;
- вывод конечных результатов в удобном и наглядном для пользователя виде;
- возможности сравнения, сортировки;
- создание форм для печати бланков и результатов.
Результатом проектирования на данной стадии является разработка технико-экономического обоснования (ТЭО) необходимости создания автоматизированной информационной системы (АИС) для КА «Фактор». (Приложение 7).
Модели, созданные на этапе определения требований необходимы для того, чтобы:
- упрощения понимания требований тем, кто читает описывающий их документ (и заказчикам, и разработчикам), - как минимум, за счет более наглядного представления процессов, нежели в текстовом описании;
- модели служат тем исходным материалом, на котором базируется дальнейшее проектирование приложения.
При этом диаграммы выступают как важный иллюстративный материал к требованиям.
В данном случае опять целесообразно использовать BPWin и методологию IDEF0 (Приложение 8). Так, будем использовать ее и при декомпозиции процесса подбора персонала для конкретной заявки. (Приложение 9). Для некоторых процессов необходимо использовать диаграммы IDEF3, чтобы отразить альтернативные сценарии развития. Например, при декомпозиции процесса проведения собеседования (Приложение 10)
Аттестация требований – процесс проверки требований на достоверность, непротиворечивость, полноту и выполнимость. Обзор требований и прототипирование являются основными методами аттестации требований.
Существует ряд методов аттестации требований, которые можно использовать совместно или каждый и отдельности.
1. Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать CASE - средства для проверки непротиворечивости моделей.
2. Обзор требований. Требования системно анализируется рецензентами.
3. Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть.
4. Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или введения ее в эксплуатацию.
Бизнес-моделирование и анализ требований к системе играет важную роль при создании программного обеспечения. Это объясняется тем, что без проведения бизнес-моделирования и анализа требований к информационной системе нет смысла создавать программное обеспечение, так как это может привести к тому, что заказчику будет представлено то программное обеспечение, которое он фактически не заказывал. Поэтому это необходимо учитывать и при разработке программного обеспечения необходимо подходить с особым вниманием и осторожностью, чтобы удовлетворить все требования заказчика.
Результатом данной стадии проектирования должно явится создания технического задания для КА «Фактор». (Приложение 11)
В настоящее время в области разработки и реализации информационных систем существует несколько методологий проектирования:
- методология функционального моделирования работ SADT;
- методология объектно-ориентированного анализа и проектирования на языке UML;
Для проектирования информационной системы была выбрана методология функционального моделирования работ SADT.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.
В данной курсовой работе был проведен процесс анализа предметной области, собраны необходимые требования к разрабатываемой системе, осуществлено бизнес-моделирование процессов, выполнен анализ, моделирование и аттестация требований к информационной системе.
1. А.М. Вендров CASE-технологии. Современные методы и средства проектирования информационных систем [Электронный документ]