Блочное моделирование и его графическое представление

Введение

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

В конце 50-х Дуглас Т. Росс впервые использовал понятие “SA-блок”, которое легло в основу того, что позже было названо структурным анализом (Structured Analysis, SA) в отчете

по созданию алгоритмического языка АРТ в Массачусетском технологическом институте

(МТИ). SA блок был использован Дуглас Т. Россом в 1967 году в отчете “AED-подход к системам автоматизированного проектирования”, отмеченном премией.

1960 г - начало разработки того, что теперь называется “иерархическая декомпозиция сверху вниз”.

1969 г - основание компании SofTech.

1972 г - в ходе коммерческого проекта идеи и опыт были обобщены в методологию проектирования.

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

(Architecture Method) и примененному в работах по проекту в ВВС США при разработке систем автоматизированного производства.

1974 г - методология была названа SADT (Structural Analysis and Design Technique)

“Структурный анализ и проектирование ”.

Программа Integrated Computer-Aided Manufacturing (ICAM) предназначенная для интегрированной компьютеризации производства (США конец 70-х) выявила потребность в более совершенных способах обмена информацией и методах анализа производственных систем для всех специалистов, занимающихся проблемой. В рамках программы ICAM для удовлетворения этих потребностей была разработана методология IDEF (I CAM Def inition). Наиболее популярными стали следующие части методологии:

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

IDEF1 (IDEF1X)- используется для создания информационных моделей, представляющих структуру информации, необходимую для поддержки функций систем. Многие CASE инструменты, используемые при разработке современных систем управления базами данных (СУБД), позволяют автоматически генерировать программный код из IDEF1X диаграмм.

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

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

обладающий следующими свойствами:

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

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

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

проектированием процессов

- язык прошел многолетнюю проверку и подтвердил свою работоспособность

- язык легок и прост в изучении

- язык поддерживается рядом программных продуктов

 

 

Концепция IDEF0

 

 

Методология IDEF0 основывается на следующих концептуальных положениях

Модель

Модель дает полное и точное и адекватное описание системы и имеет конкретное назначение. Это назначение называется целью модели:

М моделирует систему С, если М отвечает на вопросы относительно С с точностью Т.

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

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

Если модель отвечает не на все вопросы, или ее ответы не точны, считается, что модель

не достигла поставленной цели.

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

Управление

 

 

Входы

Функция

Выходы

 

Механизмы

 

 

 

Лаконичность и точность

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

Передача информации

Средства IDEF0 позволяют легко передавать информацию от одного участника построения модели к другому. Это обеспечивается:

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

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

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

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

так и входящих в нее элементов.

Строгость и формализм

Разработка модели IDEF0 ведется с использование строгих формальных правил,

определяемым как самим стандартом, так и синтаксисом графического языка.

Итеративное моделирование

Разработка модели IDEF0 ведется пошагово, с обсуждением каждой части модели и

ее утверждением.

Принцип декомпозиции

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

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

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

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

 

 

ИСПОЛЬЗУЮТСЯ: АВТОР: Автор

ПРОЕКТ: имя Проекта

ДАТА: 05 дек 1996

ПЕРЕСМОТР: 14 дек 1996

РАБОЧАЯ ВЕРСИЯ

ЭСКИЗ РЕКОМЕНДОВАНО

ЧИТАТЕЛЬ ДАТА

Диаграмма самого верхнего уровня

ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10

ПУБЛИКАЦИЯ

иерархии – А-0, описывает наиболее общее представление моделируемой системы. Она является родителем для Диаграммы А0.

 

 

A0

 

УЗЕЛ:

A-0

НАЗВАНИЕ: НОМЕР:

 

ИСПОЛЬЗУЮТСЯ: АВТОР: Автор

ПРОЕКТ: имя Проекта

 

ДАТА: 05 дек 1996

ПЕРЕСМОТР: 14 дек 1996

 

РАБОЧАЯ ВЕРСИЯ ЭСКИЗ РЕКОМЕНДОВАНО

 

ЧИТАТЕЛЬ ДАТА

Диаграмма А0 является декомпозицией

ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10

C1

 

I1

 

 

2

 

I2

ПУБЛИКАЦИЯ

 

A3

(Диаграммой - потомком) для А-0. Дает более детальное представление функции в Блоке 0.

 

Декомпозированный Блок 3, является родительским для Диаграммы А3.

 

 

 

M1 M2

 

УЗЕЛ:

A0

 

НАЗВАНИЕ: НОМЕР:

 

ИСПОЛЬЗУЮТСЯ: АВТОР: Автор

ПРОЕКТ: имя Проекта

 

ДАТА: 05 дек 1996

ПЕРЕСМОТР: 14 дек 1996

 

РАБОЧАЯ ВЕРСИЯ ЭСКИЗ РЕКОМЕНДОВАНО

 

ЧИТАТЕЛЬ ДАТА

Диаграмма А3 является декомпозицией

ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10

C1 C2

 

I1

A31

 

 

ПУБЛИКАЦИЯ

Блока 3 Диаграммы А0 и иллюстрирует внутреннее содержание Блока на родительской Диаграмме.

Декомпозированный на Диаграмме А3

Блок 1 является родительским для Диаграммы

А31.

 

 

M1

 

УЗЕЛ:

A3

 

НАЗВАНИЕ: НОМЕР:

 

 

 

Основные определения IDEF0

FEO Диаграмма (For Exposition Only). Графическая диаграмма, используемая для уточнения содержания IDEF0 диаграммы. В отличие от IDEF0 диаграммы, при создании FEO диаграмм не требуется соблюдать правила синтаксиса IDEF0 диаграмм.

ICOM Код (ICOM Code). Код, который устанавливает однозначное соответствие между граничными дугами диаграммы-потомка с дугами родительского блока. Сокращение от Input

(Вход), Control (Управление), Output (Выход), Mechanism (Механизм).

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

Блок (Box). Прямоугольник, содержащий имя и номер. Используется для представления функции на графической диаграмме.

Блок-потомок (Child Box). Блок на диаграмме декомпозиции (диаграмме-потомке)

родительского блока.

Блок-родитель или родительский Блок (Parent Box). Блок, который детализируется диаграммой-потомком.

Ветвь (Branch). Ответвление или слияние двух или более сегментов дуг в одной точке.

Внутренняя Дуга (Internal Arrow). Дуга, в отличие от гр аничной дуги начинающаяся и заканчивающаяся на диаграмме (входная дуга, дуга управления или выходная дуга).

Выходная Дуга (Output Arrow). Класс дуг, отражающих в IDEF0 модели выход, т.е. те данные и объекты, которые получены в результате выполнения функции. Выходные дуги присоединяются с правой стороны IDEF0 Блока.

Глоссарий (Glossary). Список определений ключевых слов, фраз, сокращений и терминов, используемых в IDEF0 модели.

Граничная Дуга (Boundary Arrow). Дуга, источником или приемником которой, в отличие от внутренней дуги, является ICOM или граничная область диаграммы.

Декомпозиция (Decomposition). Разбиение моделируемой функции на подфункции в целях детализации ее представления.

Дерево Узлов (Node Tree). Графическое представление в виде дерева отношений родитель-потомок между узлами IDEF0 модели. Имеет то же значение и содержание, что и индекс узла.

Детализированное Выражение Ссылки (Detail Reference Expression – DRE). Ссылка

(например, номер узла, c-номер, номер страницы), которая записывается рядом с нижним правым углом IDEF0 Блока. Она показывает, что этот блок является декомпозированным и указывает номер диаграммы декомпозиции.

Диаграмма (Diagram). Базовый элемент IDEF0 модели, представляющий детализирующий Блок.

Диаграмма A-0 (A-0 Diagram). Особый случай контекстной IDEF0 диаграммы с одним блоком, содержащим функцию верхнего уровня, подлежащую моделированию. Содержит также определение входов, управления, выходов и механизмов данной функции. Содержит описание цели моделирования и точки зрения.

Диаграмма-потомок (Child Diagram). Диаграмма, детализирующая (уточняющая)

содержание родительского блока.

Диаграмма-родитель или родительская Диаграмма (Parent Diagram). Диаграмма,

которая содержит родительский блок.

Дуга (Arrow). Направленная линия (дуга), состоящая из одного или нескольких сегментов, которые моделируют передачу данных или объектов из источника (начало дуги) к

 

 

 

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

управления, и дуга механизма (включает также дугу запроса). См. сегмент дуги, граничную дугу,

внутреннюю дугу.

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

Дуга Запроса (Call Arrow). Тип дуги механизма. Дуги этого типа дают возможность разделять диаграммы между моделями. Позволяет ссылаться на диаграммы, созданные в данной или других моделях.

Дуга Механизма (Mechanism Arrow). Класс дуг, описывающих в IDEF0 модели механизм – объекты, посредством которых выполняется функция. Этот класс дуг включает специальный случай – дуга запроса. Дуги механизма присоединяются к нижней стороне IDEF0

Блока.

Заголовок (Title). Глагол или глагольный оборот, именующий функцию. Заголовок диаграммы-потомка соответствует имени функции родительского блока.

Зигзаг (Squiggle). Небольшая ломанная линия, которая может использоваться для связывания замечания (метки) с сегментом дуги.

Имя Блока (Box Name). Глагол или глагольный оборот, помещенный внутри IDEF0

блока для именования моделируемой функции.

Имя Функции (Function Name). См. Имя Блока.

Индекс Узла (Node Index). Список, содержащий в схематичном виде узлы IDEF0

модели. Имеет то же назначение и содержание, что и дерево узлов.

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

Контекст (Context). Непосредственно окружение, в котором определенные на диаграмме функции выполняются.

Контекстная Диаграмма (Context Diagram). Диаграмма, представляющая контекст модели. Контекстные диаграммы нумеруются А-n (где n больше или равно 0). Диаграмма А-0

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

Метка Дуги (Arrow Label). Имя существительное или производное от имени существительного. Используется для определения дуги или сегмента дуги.

Номер Блока (Box Number). Номер (от 0 до 6), помещаемый в правом нижнем углу внутри IDEF0 блока, для идентификации блока на диаграмме.

Номер Узла (Node Number). Код, закрепляемый за блоком, с целью определения его положения в иерархии модели. Может использоваться как детализированное выражение ссылки.

Номер Узла Диаграммы (Diagram Node Number). Часть ссылки узла диаграммы,

которая соответствует номеру узла родительского Блока.

Примечание к Модели (Model Note). Текстовый комментарий, который является частью IDEF0 диаграммы. Используется, как правило, для записи факта, который не может быть изображен графически.

Разветвление или развилка (Fork). Переход, в котором сегмент IDEF0 дуги (идущий

от источника) разделяется на два или более сегмента.

Сегмент Дуги (Arrow Segment). Часть дуги, не содержащая ответвлений и присоединений других дуг ни в одной из точек, кроме точек источника и приемника.

Семантика (Semantics). Смысловое значение синтаксических элементов языка.

 

 

Синтаксис (Syntax). Структурные компоненты или свойства языка, а также правила,

которые определяют отношения между ними.

Слияние (Join). Точка соединения, в которой сегмент дуги (идущий от источника) сливается с одним или несколькими сегментами других дуг, формируя один (общий) сегмент дуги.

Слияние/Разветвление (Bundling /Unbundling). Объединение различных дуг в одну, имеющую более общее значение (слияние) или разделение дуги на несколько дуг, каждая из которых имеет самостоятельное значение (разветвление).

С-номер (C-Number). Хронологический номер, который может использоваться для уникальной идентификации диаграммы и для отслеживания истории. Может использоваться как детализированное выражение ссылки, чтобы определить специфическую версию диаграммы.

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

Текст (Text). Полный комментарий в виде текста, относящийся к IDEF0 диаграмме.

Точка зрения (Viewpoint). Краткая формулировка, отражающая точку зрения,

выбранную при построении модели.

Туннельная Дуга (Tunneled Arrow). Дуга (со специальным условным знаком), для которой не выполняются правила ее соответствия определенным дугам на ее родительских диаграммах и диаграммах-потомках.

Узел (Node). Родительский блок для блоков-потомков. См. также индекс узла, дерево узлов, номер узла, ссылка узла, номер узла диаграммы.

Управляющая Дуга (Control Arrow). Класс дуг, описывающих управление в IDEF0 модели, т.е. условия, необходимые для выполнения функции. Данные или объекты, моделируемые как управляющие, могут преобразовываться функцией. В результате, на выходе могут появляться новые данные или объекты. Дуги управления присоединяются к верхней стороне IDEF0 Блока.

Функция (Function). Действие, процесс или преобразование (моделируемое IDEF0 блоком), которое выражается глаголом или глагольным оборотом. Функция описывает то, что должно быть выполнено.

Цель (Purpose). Краткая формулировка цели создания модели.

 

Коды ICOM

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

(Вход), Control (Управление), Output (Выход), Mechanism (Механизм).

При построении диаграммы следующего уровня, дуги, касающиеся декомпозируемого блока, переносятся на диаграмму потомок в виде ICOM кодов I1..., C1..., O1..., M1... Таким образом, после завершения работы на диаграммой ее внутренние дуги стыкуются с внешними, содержание которых может быть описана на более высоком уровне иерархии.

Подготовка

На самом раннем этапе моделирования перед началом разработки модели необходимо определить ее направленность: контекст, точку зрения и цель.

Контекст определяет объект модели как часть целого. Он очерчивает границы модели с

ее внешним окружением посредством описания внешних интерфейсов1.

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

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

Резюме

· Во время обобщения дуги нередко объединяются, а их метки уточняются.

· Построение диаграммы А-0 завершает начальный этап моделирования.

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

 

Сбор информации

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

· чтение документов

 

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

можно в удобном темпе, вопросы для экспертов можно формулировать, делая ссылки на конкретные документы.

Недостатки: необходимость поддерживать библиотеку документов, не описаны текущие нюансы и недокументированные аспекты.

· наблюдение за выполняемыми операциями

Преимущества: получение информации из первых рук, возникают вопросы,

которые никогда не появились бы при чтении документов и общении с экспертом.

Недостатки: слишком долгое наблюдение приводи к избыточному привыканию

к состоянию дел, возможна потеря объективности при описании объекта моделирования.

· анкетирование

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

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

· использование собственных знаний

Преимущества: аналитик является источником информации, знания проверены

на практике и разносторонни.

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

· составление описания

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

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

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

· для сбора фактов

· для определения проблем

· совещания для принятия решений

· диалоги автор—читатель

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

Для всех типов опроса используется подход, имеющий три этапа:

· подготовка,

· проведение опроса,

· завершение.

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

· выбор необходимого собеседника;

· предварительную договоренность о встрече;

· согласованную программу встречи;

· изучение сопутствующей информации;

· согласование действий с группой проектирования и аналитиками.

 

Установив цель встречи, и договорившись о встрече, ограничьте ее продолжительность в

пределах часа или менее. Если тематика обширна, разбейте беседу на несколько встреч.

Установите программу беседы и определите круг вопросов, обратив внимание на те, от ответов

на которые зависит продолжение моделирования.

При опросе главная цель - правильно организовать и поддерживать поток информации

от эксперта к аналитику.

Начиная разговор, следует:

· представиться,

· сформулировать цель встречи,

· оговорить возможность ведения записей,

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

В ходе опроса, контролируя ситуацию, необходимо отслеживать что:

· вы получили достаточно информации;

· вы получаете большой объем ненужной информации;

· обилие информации вас подавляет;

· эксперт начинает уставать;

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

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

 

Что необходимо помнить при опросе

Собирая информацию:

· определите, является ли информация фактом, или мнением;

· постарайтесь уточнить, какое место занимает эксперт в компании;

· старайтесь спрашивать о числах и количествах - это повышает достоверность ответов;

· уточняйте источники и назначение данных (объектов),

· их формат,

· сроки (условия) хранения,

· предполагаемое использование и требуемые изменения.

Управляя потоком информации (непрерывность и достоверность):

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

· никогда не перебивайте, подсказывая ответ или задавая другой вопрос;

· не задавайте наводящих вопросов, и вопросов, на которые можно дать однозначный ответ

(Да/Нет) - это не дает эксперту возможность делиться знаниями;

· старайтесь не задавать контрольных вопросов - это прерывает поток информации;

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

 

Создание диаграмм

 

Бланк диаграммы

В поле ИСПОЛЬЗУЕТСЯ: (USED AT) указывается список диаграмм, отличных от контекста, которые каким-либо образом используют диаграмму на данном листе.

В поле АВТОР: (AUTHOR) заносится имя и фамилия автора диаграммы. В поле

ПРОЕКТ: (PROJECT) вносится название проекта, в рамках которого разрабатывалась

 

 

 

диаграмма. Поле ДАТА: (DATE) содержит дату создания, а в поле ПЕРЕСМОТР: (REV)

заносится дата последней ревизии построенной диаграммы.

Поле ЗАМЕЧАНИЯ: (NOTES) позволяет отслеживать замечания, вносимые при рецензировании построенной диаграммы. По мере появления замечаний на листе, их номера последовательно вычеркиваются.

Классификация по статусу (помечается в квадратике слева от поля) позволяет распределить диаграммы по уровням:

· РАБОЧАЯ ВЕРСИЯ (WORKING) – диаграммы, не законченные автором.

· ЭСКИЗ (DRAFT) – диаграммы, прошедшие обсуждение среди рецензентов, но пока не одобренные комитетом технического контроля.

· РЕКОМЕНДОВАНО (RECOMMENDED) – диаграммы, в которые не предполагается вносить изменения – прошли этап рецензирования и одобрены комитетом технического

контроля.

· ПУБЛИКАЦИЯ (PUBLICATION) – материалы, рекомендованные для окончательной печати

и рассылки.

В поле ЧИТАТЕЛЬ ДАТА (READER DATE) рецензент (читатель) должен указать свою фамилию и дату рецензирования диаграммы.

В поле КОНТЕКСТ: (CONTEXT) определяется контекст рассмотрения диаграммы на данном листе. Схема контекста является по сути уменьшенным изображением предыдущего по отношению к текущей диаграмме (верхнего) уровня без дуг. Блок, декомпозиция которого рассматривается на текущем листе, имеет серую заливку.

ИСПОЛЬЗУЮТСЯ:	АВТОР: ДАТА: 28 мар 1997 ПРОЕКТ: ПЕРЕСМОТР   ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9		РАБОЧАЯ ВЕРСИЯ	ЧИТАТЕЛЬ ДАТА	КОНТЕКСТ
	ЭСКИЗ
	РЕКОМЕНДОВ
	ПУБЛИКАЦИ
УЗЕЛ: A0	НАЗВАНИЕ:	НОМЕР
	Стр.:

Имя функции декомпозированного блока автоматически записывается в поле НАЗВАНИЕ: (TITLE). В поле УЗЕЛ: (NODE) заносится код декомпозированного Блока. В поле НОМЕР: (NUMBER) заносится С-номер и номер страницы.

Поле НОМЕР: содержит номер, с помощью которого можно ссылаться на данный лист.

С-номер состоит из букв авторских инициалов и порядкового номера, присваиваемого автором.

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

 

Декомпозиция функционального блока

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

(определенном блоком и его дугами):

· Функциональный блок, цель и точка зрения для диаграмм потомков уже определены на диаграмме А-0 и пояснены в сопроводительных материалах;

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

Декомпозиция функционального блока состоит из следующих шагов:

1) выбрать блок для декомпозиции на диаграмме;

2) рассмотреть объект, определенный этим блоком (список входящих в него объектов и функций);

 

3) создать новую диаграмму;

4) выявить недостатки новой диаграммы;

5) построить альтернативную декомпозицию функционального блока;

6) корректировать новую диаграмму;

7) корректировать связанные с ней диаграммы.

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

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

· доминирование;

· функциональную сложность блока;

· понятность.

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

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

на диаграмме не должно быть больше 6.

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

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

 

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

Основная функция аналитика — зафиксировать в виде документа описание системы в виде нескольких диаграмм. Совокупность нескольких диаграмм и поясняющих материалов это

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

с их представлением.

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

Полученные в результате диаграммы (IDEF0, FEO, текстовые, глоссария) объединяются

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

 

Подготовка папок

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

Папки - это основное средство общения между участниками проекта.

Задача, которую решают: асинхронное и альтернативное рецензирование рабочих материалов.

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

Диаграммы помещаются сразу за титульным листом в порядке декомпозиции. Пояснительные материалы - сразу за диаграммами, которые они поясняют. Лист глоссария, поясняющий терминологию модели помещается сразу после диаграмм.

 

 

Папки с ответами

 

 

Автор

Читатели

 

Папки с комментариями

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

На титульном листе могут присутствовать следующие области:

· Область для идентификации проекта (как на диаграмме: нижняя и верхняя области)

· Область, описывающая содержание папки.

· Область, где перечислены те (фамилии), кому папка (и ее копии) направляется.

· Область для замечаний по папке в целом (например, нужна помощь по такому то вопросу).

· Область, куда автор помещает специальные инструкции для библиотекаря.

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

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

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

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

 

Комментирование работ

Папки, полученные библиотекарем, регистрируются. Записываются дата рассылки папки

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

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

Все это необходимо для контроля своевременной обратной связи с читателями.

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

 

Ответы на комментарии

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

После передачи папок с авторскими ответами на комментарии читателей папки остаются

у своих владельцев (авторские у автора, читательские у читателя).

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

 

 

Совершенствование моделей

После нескольких циклов автор-читатель, аудитория приходит к единому мнению

(консенсусу) по поводу содержания модели. Это происходит в результате того, что каждому участнику проекта дается возможность высказаться и его высказывания находят отражение в модели.

После того, когда автор видит, что набор диаграмм проработан достаточно хорошо

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

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