Ответы_к_госам_final

было известно только, что документ существует), то сейчас этого недостаточно. Требуется уже интегральная оценка.

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

Оси "F" и "D" определяют специфику деятельности организации, регламентируемую положением третьей координаты (R) пространства модели документооборота. При этом модель не зависит от технологии обработки документов, принятой на предприятии – все решает только цель деятельности, будь то государственная организация, торговая компания и промышленная фирма.

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

Инструментальные средства моделирования

CASE-средства

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

CASE-средства позволяют получить описание работы создаваемой системы раньше, чем еѐ построили. Потом с их помощью можно

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

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

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

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

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

Необходимость использования CASE-средств

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

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

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

Общие вопросы:

используемая модель ЖЦ (каскадная или спиральная);

используемые методы (структурные, объектно-

ориентированные).

степень адаптации метода к потребностям организации;

квалификация сотрудников;

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

количественные метрики, используемые в процессе разработки ПО, их использование;

виды документации, выпускаемой в процессе ЖЦ ПО;

проекты, ведущиеся в организации;

средняя продолжительность проекта в человеко-месяцах;

среднее количество специалистов, участвующих в проектах

различных категорий (небольших, средних и крупных);  средний размер проектов различных категорий в терминах

кодовых метрик (например, в строках исходных кодов), способ измерения.

СASE-технологии – методологическая и инструментальная база моделирования

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

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

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

системный анализ и моделирование (практически любая современная крупная программная система разрабатывается с применением CASE-

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

Классификация инструментальных средств

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

 локальные, поддерживающие один-два типа моделей и методов

(Design/IDEF, ProCap, S-Designor, ―CASE. Аналитик‖);

малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin) ;

средние интегрированные средства моделирования, поддерживающие от 4 до 10—15 типов моделей и методов (Rational Rose, Paradigm Plus,

Designer/2000);

крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).

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

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

ERwin. Поддерживает несколько разновидностей методологии информационного моделирования, основанной на ER-диаграммах (сущность

– связь). Интеграция моделей BPwin с моделями ERwin выполняется путем обмена данными через функции экспорта/импорта.

Малые интегрированные системы, так же как и локальные,

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

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

К средним интегрированным средствам можно отнести такие известные продукты, как Rational Rose (Rational Software), Paradigm Plus

(CA/Platinum), Designer/2000 (Oracle).

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

Крупные интегрированные средства моделирования. К этой категории относится инструментальное средство, специально предназначенное для проектирования крупных ИСУП, таких, например, как системы управления предприятием класса ERP.

Это – семейство ARIS (ARIS Toolset, ARIS Easy Design) компании IDS Sheer AG. Принадлежность к категории ERP для средства моделирования означает, что оно предназначено для выполнения комплексного анализа на всех стадиях (требования, спецификации, внедрение) разработки ИСУП класса ERP. Естественно, такое средство может быть использовано при создании любых других ИСУП, а не только ERP.

Обоснование выбора инструментальных средств для моделирования. Общие сведения

Чтобы выбрать инструментарий, способный в полной мере отвечать на поставленные вопросы, необходимо проанализировать существующие CASEсредства.

В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы:

Какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата?

В какой последовательности выполняются эти процедуры?

Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса?

Кто выполняет процедуры процесса?

Какие входящие документы/информацию использует каждая

процедура процесса?

Какие исходящие документы/информацию генерирует процедура процесса?

Какие ресурсы необходимы для выполнения каждой процедуры

процесса?

Какая документация/условия регламентирует выполнение процедуры?

Какие параметры характеризуют выполнение процедур и процесса в целом?

Обзор инструментария

ARIS Toolset

Создаваемые в среде ARIS Toolset (IDS Scheer AG) модели представляют собой документированную совокупность знаний о системе управления на предприятии – организационная структура предприятия, взаимодействия между предприятием и прочими субъектами рынка, состав и структура документов, последовательности шагов процессов, должностные инструкции отделов и их сотрудников. ARIS хранит всю информацию в едином репозитории, что обеспечивает целостность и непротиворечивость процесса моделирования и анализа.

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

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

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

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

BPWin

BPwin, поддерживающее методологии IDEF0 (функциональная модель),

IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей

– того, к чему нужно стремиться (модель TO-BE).

Rational Rose

Корпорация Rational Software выпустила программный продукт Rational Rose [Лит-ра 11] – CASE-средства визуального проектирования информационных систем, позволяющего моделировать как компоненты программного обеспечения, так и бизнес-процессы.

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

Методика построения так называемых «бизнес-моделей», содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Дуги Use Case и Activity диаграмм не имеют смысловых типов, а образно показывают логическую связь. Синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, имеют наборы перечисленных функций, которые дают информацию о происходящих на предприятии процессах. По этой причине пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и

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

Rational Rose основан на стандартах UML, но не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов.

Сравнительная характеристика названных средств

Методологии моделирования

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

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

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

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

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

Правила SADT включают:

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся

имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

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

Состав функциональной модели

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса.

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

Иерархия диаграмм

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

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

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

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

На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.

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

Типы связей между функциями

Различают, по крайней мере, семь типов связывания