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

В данном разделе отражены результаты построения моделей предметной области “как есть” и с учетом использования информационной системы. Для обеспечения возможности построения моделей произведен анализ и выбор соответствующих CASE-средств.

2.1 Введение в проблему

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

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

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

Важным моментом является то, что кроме полученных моделей в процессе моделирования, необходимо оценивать качество самого процесса моделирования. Если моделирование БП представляет собой проект, то качество процесса моделирования оценивается по степени соответствия общепринятым стандартам управления проектами. [5]

Критерии качества моделирования [6]:

соответствие методологии и соглашению в целом. Модель должна соответствовать архитектуре, приведенной в методике;

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

непротиворечивость или взаимоувязанность. Согласованность с другими объектами: документы, события, работники системы и т.д.;

ясность и понятность заказчику. Понятность не только владельцам системы, но и её исполнителям;

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

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

Методика оценки качества моделей БП позволяет:

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

Строить возможные варианты выполнения БП с учетом возможностей для их улучшения.

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

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

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

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

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

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

Сцепление и связность являются двумя взаимозависимыми метриками качества разбиения процесса на части - связанность часто определяет качество ее сцепления с другими функциями.[5]

И только теперь, когда необходимый уровень качества отдельных БП будет достигнут, можно говорить о построении интегрированной модели БП компании, которая и будет положена в основу ТЗ на проектирование системы.

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

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

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

Современные средства позволяют достаточно быстро создавать (внедрять) ИС по готовым требованиям. Но очень часто оказывается, что эти системы не удовлетворяют заказчиков. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС. Проблема формирования требований к ИС остается до настоящего времени одной из наиболее трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ создания ИС, когда эти требования должны быть выявлены и формализованы, в получении конечного результата.

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

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

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

2.2 Подходы к моделированию ИС

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

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

Структурный (функциональный) подход

Сущность подхода

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

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

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

Рис. 2.1 - Модель в нотации IDEF0

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

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

ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).

Выводы по практическому использованию

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

Выводы по диаграммам:

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

Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями. Таким образом, четко прослеживается логика и взаимодействие процессов организации. Главным достоинством нотации является возможность получить полную информацию о каждой работе, благодаря ее жестко регламентированной структуре. С ее помощью можно выявить все недостатки, касающиеся как самого процесса, так и то, с помощью чего он реализуется: дублирование функций, отсутствие механизмов, регламентирующих данный процесс, отсутствие контрольных переходов и т.д.

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

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

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

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

Объектно-ориентированный подход

Сущность подхода

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

Рис. 2.2 - Сравнительный анализ объектно-ориентированной и функционально-ориентированной декомпозиций

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

Язык UML(UnifiedModelingLanguage) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем.[8,9]

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

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

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

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

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

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

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

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

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

Выводы по практическому использованию

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

Методология ARIS

Сущность подхода

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

Рис. 2.3 - Взаимосвязь видов моделей ARIS (здание ARIS)

Методология ARIS включает большое количество методов моделирования, в том числе известных как диаграммы Чена ERM, язык UML (UnifiedModelingLanguage), методики ОМТ (ObjectModelingTechnique), BSC (BalancedScorecard) и т.п.

К преимуществам методологии ARIS разработчики относят следующие:

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

богатство методов, позволяет моделировать широкий спектр систем;

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

Выводы по практическому использованию

1. Часто у аналитиков знакомящихся с методологией ARIS возникает чувство, что ARIS может все, она решает все проблемы. Это ошибочное мнение. Методология ARIS решает совершенно конкретный круг задач. Если потребности сильно отличаются от возможностей ARIS (например, сбор требований), то подойдет более специализированное и дешевое решение. ARIS в значительно большей степени предназначен для целей управленческого консалтинга и последующей поддержки решений. Использование ARIS в рамках проекта автоматизации противоречит целям, положенным в основу этой методологии ее создателем.

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

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

4. В случае принятия решения о качественной необходимости использования методологии необходимо иметь ввиду, что ARIS нельзя отнести к интуитивно понятным, она требует времени на изучение, на осмысленное применение (вопрос хотя бы в том, что методология содержит больше 100 моделей!). Для успешного применения должны быть разработаны внутренние соглашения о моделировании и документировании.

Сравнительный анализ подходов к моделированию ИС

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

1. Целей проекта;

2. Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта;

3. Возможностей подхода с учетом требований п. 2;

4. Особенностей разрабатываемой/внедряемой информационной системы.

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

Таблица 2.1 - Сравнительный анализ нотаций IDEF, UML

В данной работе было принято решение использовать два подхода к моделированию, а именно:

структурный подход к моделированию. Подход дает возможность проведения глубокого анализа бизнес - процессов, выявления узких мест: комплексное применение позволяет выявить все возможные рассогласования и неточности. Применение универсальных графических языков моделирования IDEF0, IDEF3, DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов при моделировании предметной области в контексте «как есть» и «как должно быть»;

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

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

Выбор CASE-средств моделирования

Существует множество средств моделирования автоматизированных систем. За последние десятилетия сформировалось новое направление в программотехнике - CASE (Computer-AidedSoftware/SystemEngineering) на основе методологии структурного системного анализа и проектирования. CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки программного обеспечения (ПО) и сопровождения информационных систем, поддержанную комплексом, взаимосвязанных средств автоматизации [10]. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.

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