Инструментальная база консалтинга

В настоящее время диcциплина CASE (Computer Aided Software/System Engineering) оформилась в самостоятельное наукоемкое направление в программотехнике. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. CASE –технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения систем ПО.

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

Чем больше деятельности будет внесено в проектирование из кодирования, тем лучше!

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

· бизнес-анализ, для построения моделей AS-IS и TO-BE;

· системный анализ и проектирование.

Большинство CASE-средств основано на парадигме:

м етология – метод – нотация – средство ,

где методология – определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы и их последовательность, а также правила распределения и назначения методов;

метод – это систематическая процедура или техника генерации описаний компонент ПО (например, проектирование потоков и структур данных);

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

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

Многие корпоративные информационные системы зарубежных производителей (SAP R/3, BAAN, ROSS iRenaissance и др.) имеют в своем составе специальные средства, с помощью которых можно обследовать предприятия и построить модель их деятельности, однако существуют стандартизированные, опробованные в течение многих лет методологии и инструментальные средства. Наиболее известной и распространенной является предложенная в 70-х годах прошлого столетия Дугласом Россом (Douglas Ross) методология структурного анализа SADT (Structured Analysis and Design Technique)[15].

В начале 90-х годов в США на основе SADT был принят стандарт моделирования бизнес-процессов IDEFO (http: //www.idef.com), который является независимым от частных организаций стандартом и получил чрезвычайно широкое распространение, он принят в качестве стандарта в нескольких международных организациях, в том числе в НАТО и МВФ.

В середине 2002 года фирма Computer Associates (CA) выпустила новый пакет инструментальных средств, поддерживающих все этапы разработки информационных систем, - AllFusion Modeling Suite 4.1, в который входят пять продуктов:

1) AllFusion Process Modeler 4.1, который фактически является новой версией хорошо известного средства моделирования и анализа бизнес -процессов BPwin. Этот инструмент сохранил в себе всю функциональность старой версии BPwin и приобрел некоторые новые возможности.

2) AllFusion ERwin Data Modeler 4.1 – инструмент создания моделей данных и генерации схем баз данных. Прежнее название – ERwin 4.1.

3) AllFusion Model Manager 4.1 – система организации коллективной работы, хранилище моделей BPwin и ERwin. Старое название – ModelMart 4.1.

4) AllFusion Data Model Validator 4.1 – система поиска и исправления ошибок модели данных. Прежнее название – ERwin Examiner.

5) AllFusion Component Modeler 4.1 – инструмент создания объектных моделей. Старое название – Paradigm Plus 4.1.

Инструмент моделирования AllFusion Process Modeler 4.1 служит для функционального моделирования и построения моделей IDEFO, IDEF3 и DFD.

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

 

 

Control

 

Activity

Input Result

 

 

Mechanism

 

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

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

· Result – материал или информация, которые производятся работой. Основной результат деятельности функции, конечный продукт. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла.

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

· Mechanism (механизм) – все необходимые ресурсы, необходимые для реализации функции. IT – ресурсы, которые выполняют работу (ОС, среда разработки, библиотеки повторно используемых компонент, языки программирования, СУБД, персонал и т.д.)

· Activity (работа) – обозначает поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Все работы должны быть названы и определены. Имя работы должно быть выражено сочетанием отглагольного существительного, обозначающего процесс, например: «Прием, заказа», «Оформление заказа», «Оплата заказа» и т.д. При создании новой функциональной модели создается контекстная диаграмма с единственной работой, изображающей систему в целом.

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

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

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

1) добиваться того, чтобы каждый выделяемый таким образом модуль системы был правильным и не зависел от контекста, в котором он будет использоваться;

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

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

На рис.2.1. показано дерево функций, называемое деревом узлов функциональной модели.

 

 

Рис. 2.1. Пример декомпозиции – дерево узлов функциональной модели

 

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

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

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

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

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

AllFusion Process Modeler 4.1 позволяет создавать модели процессов и поддерживает в одной модели, в дополнение к IDEFO, еще два стандарта (нотации) моделирования – DFD и IDEF3. Каждая из этих трех нотаций позволяет рассмотреть различные стороны деятельности предприятия. Диаграммы IDEFO предназначены для описания бизнес-процессов на предприятии, они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляющим фактором и какие ресурсы для этого необходимы. Нотация IDEFO позволяет выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия.

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

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

В результате обследования предприятия строится функциональная модель существующей организации работы – AS-IS. На основании этой модели достигается консенсус между различными единицами бизнеса по тому, «кто что сделал», и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Внедрение информационной системы, неизбежно приведет к перестройке существующих бизнес-процессов предприятия. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности предприятия могут быть: бесполезные, неуправляемые и дублирующиеся работы (activity), неэффективный документооборот, отсутствие обратных связей по управлению (на проведение работы не оказывает влияния её результат) и входу (объекты или информация используется нерационально) и т.д.

Найденные в модели AS-IS недостатки можно и нужно исправить при создании модели TO-BE – модели новой организации бизнес-процессов. Модель TO-BE нужна для оценки последствий внедрения информационной системы и анализа альтернативных/лучших путей выполнения работы и документирования того, как предприятие будет функционировать в будущем. Как правило, строится несколько моделей TO-BE , из которых по какому-либо критерию (критериям) выбирается наилучшая.

BPwin предоставляет бизнес-аналитику проекта два инструмента для оценки модели – стоимостной анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь) и т.д., в каждой из моделей AS-IS или TO-BE. Следовательно, стоимостной анализ позволяет оценить, каковы будут последствия внедрения информационной системы, действительно ли это приведет к повышению производительности и экономическому эффекту, и к какому именно.

Модели AS-IS и TO-BE позволяют описать начальные и конечные состояние предприятия – до и после внедрения корпоративной информационной системы, оставляя без внимания сам процесс разработки и внедрения. Модель TO-BE – это не модель работы предприятия, а модель (выбора модели) мероприятий по переводу его на новую технологию работы.

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

Модель данных может быть создана вновь или воссоздана из существующей информационной системы с помощью системы проектирования данных AllFusion ERwin Data Modeler 4.1.

Связь функциональной модели AllFusion Process Modeler и модели данных AllFusion ERwin Data Modeler гарантирует завершенность анализа, гарантирует, что есть источник данных (сущность) для всех потребностей данных (работа). Связь объектов способствует согласованности, корректности и завершенности анализа.

Стрелки в функциональной модели AllFusion Process Modeler обозначают некоторую информацию, использующуюся в моделируемой системе. В AllFusion ERwin Data Modeler на логическом уровне модели данных эта информация отображается в виде сущностей(соответствуют таблицам на физическом уровне), состоящих из атрибутовсущностей. Сущности состоят из совокупности отдельных записей – экземпляров сущностей. К модели данных логического уровня предъявляются требования нормализации, которые призваны обеспечить компактность и непротиворечивость хранения данных.

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

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

Для организации коллективной работы над проектом служит средство AllFusion Model Manager 4.1 (ModelMart 4.1) – хранилище моделей, к которому открыт доступ для всех участников проекта. Архитектура ModelMart реализована на архитектуре клиент-сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server, Informix и Oracle. Клиентскими приложениями являются AllFusion ERwin Data Modeler и AllFusion Model Manager. В ModelMart реализован доступ к хранилищу моделей через API, что позволяет постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа.

 

Контрольные вопросы и задания

1. Что такое консалтинг в области информационных технологий?

2. Каковы цели и этапы разработки консалтинговых проектов?

3. В чем отличие моделей деятельности предприятия AS-IS и TO-BE?

4. Какова основная идея методологии SADT?

5. Для чего предназначены диаграммы IDEFO?

6. Что позволяет выявить нотация IDEFO?

7. Поддерживает ли структура данных информационной системы деятельность предприятия?

8. Что позволяет инструментальное средство AllFusion Process Modeler?

9. Какие решения ранних этапов проектирования считаются основными и почему?

10. В каких случаях необходимы предпроектные исследования? Какие вопросы при этом решаются? Что получают в результате таких исследований?

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

12. Составьте примеры декомпозиции – деревья узлов функциональной модели, для таких предметных областей, как ВУЗ, Офис Регистратора, Банкомат (АТМ).

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: