Функциональное моделирование

С1

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.12

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

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

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



2.3.5 С-номер диаграммы

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

Пример. Запись о том, что третий вариант автор с инициалами КВВ заменяет шестым будет записан в виде С-номера в правом нижнем углу диаграммы так: КВВ006 (КВВ003).

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

2.3.6 Правила построения диаграмм

Диаграмма является основным рабочим элементом при создании моделей. Разработчик диаграмм и моделей обычно называется аналитиком, или, в терминологии IDEF0, автором. Каждой IDEF0-диаграмме дается название, которое располагается в центре нижней части ее бланка, а также стандартно идентифицирующая ее информация: автор диаграммы, частью какого проекта является работа, дата создания или последнего пересмотра диаграммы, ее статус (см. рис. 2.13, более подробно поля бланка диаграммы описана в [6]).

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

Контекстные диаграммы должны иметь номер узла вида A-n, где n больше или равен нулю.

Модель должна содержать A-0 контекстную диаграмму, которая содержит только один блок.



Рис. 2.13

Номер блока одиночного блока на A-0 контекстной диаграмме должен быть 0.

Неконтекстная диаграмма должна иметь но не менее трех блоков и не более шести.

Каждый блок на неконтекстной диаграмме должен быть пронумерован внутри в нижнем правом углу в порядке от 1 до 6.

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

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

Блок должен иметь нуль или большее количество входных дуг.

Блок должен иметь нуль или большее количество дуг механизма (не ссылочных).

Блок должен иметь 0 или 1 дугу ссылки.

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

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

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

Рис. 2.14

Рис. 2.15

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

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

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

Рис. 2.16

Рис. 2.17

Рис. 2.18

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

Минимизируйте число петель и поворотов каждой дуги (рис. 2.20).

Рис. 2.19

Рис. 2.20

Обратные связи по управлению рисуйте «вверх и над». Таким образом вы покажете ограничивающие обратные связи при минимальном числе линий и пересечений, а также соберете все дуги управления в верхней правой части диаграммы (рис. 2.21).

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

Рис. 2.21

Рис. 2.22

При соединении большого числа блоков избегайте необязательных пересечений дуг.

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

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

Названия блока и метки дуг не должны состоять исключительно из следующих слов: «Функция», «Действие», «Процесс», «Ввод», «Вывод», «Управляет» или «Механизм». Желательно эти слова не использовать в названиях или метках дуг.

Длинную дугу помечайте дважды.

2.3.7 Дополнительные диаграммы

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

2.3.7.1 Текстовые диаграммы

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

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

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

2.3.7.2 Глоссарии

Глоссарий - набор определений объектов/данных и функций, представленных на диаграмме.

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

2.3.7.3 Поясняющие диаграммы

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

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

2.3.7.4 Указатель диаграмм и узлов

IDEF0-модель, представляет собой согласованный, упорядоченный и легко понимаемый комплект документов, что обеспечивается соответствующей организацией диаграмм в соответствии с порядком нумерации узлов: первым идет узел А-0, вторым - узел А0, третьим - узел А1, четвертым - узел А11 и т.д. Полная IDEF0-модель обычно читается двумя способами:

· обзорное чтение, когда читаются все диаграммы верхнего уровня, прежде чем перейти к диаграммам следующего. Это называется чтением «в ширину»;

· детальное чтение, когда читают отдельную ветвь дерева вплоть до диаграмм самого нижнего уровня. Это называется чтением «в глубину».

Чтобы помочь читателям правильно двигаться по древовидному набору диаграмм, разработаны дополнительные средства, в частности, указатель диаграмм и указатель узлов. Они представляют собой списки узлов или диаграмм (по типу оглавления), определяющих содержание модели. В указателе диаграмм перечисляются все диаграммы модели, с приведенными в отдельной строке названием и номером узла каждой диаграммы. В указателе узлов перечисляются все блоки модели, причем в каждой отдельной строке записываются название и номер узла соответствующего блока. Соответствующая диаграмма имеет узловой номе с буквой «N»: A0N.

2.4 Процесс создания IDEF0-модели

Процесс моделирования в IDEF0 включает в себя:

сбор информации об исследуемом объекте;

документирование полученной информации и представление ее в виде модели;

уточнение модели посредством итеративного рецензирования.

2.4.1 Сбор информации об исследуемом объекте

Сведения об изучаемой системе можно получить разными путями:

чтением документации;

наблюдением за работой системы;

путем опроса с помощью анкет большой группы специалистов;

при беседе с экспертами, обладающими соответствующим опытом и необходимыми сведениями о системе;

использованием того, что уже знает автор;

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

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

2.4.1.1 Анкетирование

Анкетирование является начальным этапом обследования. Анкеты позволяют составить грубое представление о деятельности предприятия, что позволит спланировать первоначальное распределение работ группы аналитиков. Анкеты должны рассылаться руководителям структурных подразделений и содержать графы для фамилии и должности анкетируемого, отдельно излагается просьба приложить шаблоны документов, с которыми работают сотрудники соответствующего подразделения. Список вопросов должен быть ограничен (не более l5-20) с тем, чтобы вся анкета не занимала более двух листов. Можно предложить следующий вариант анкеты [2] (рис. 2.23).

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

Наименование подразделения

ФИО руководителя подразделения, его телефон.

Координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться).

Основные функции подразделения.

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

Какая информация передается в другие подразделения.

Какая информация формируется («рождается») в подразделении.

С какими внешними предприятиями (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается.

Физическое представление информационных потоков и хранилищ (документ, дискета, сеть, журнал, картотека и т.п.).

Документы поступающие от руководства готовящиеся для руководства.

Штатная структура и квалификация кадров.

Техническое оснащение подразделения (компьютеры, сеть, модем и т.п.).

Подпись.

Просьба приложить:

1. Положение о подразделении

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

Рис. 2.23. Вариант анкеты

2.4.1.2 Интервьюирование

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

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

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

выявление проблемы, чтобы помочь установить будущие требования к системе. Этот тип интервью используется для того, чтобы проверить правильность модели «как есть» и сформировать основу для модели «как должно быть»;

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

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

Рекомендуется выделять три этапа при организации опроса:

подготовка к опросу;

проведение опроса;

обработка результатов.



Подготовка

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

Рекомендуются следующие шаги:

выберите нужного собеседника;

договоритесь о встрече;

разработайте предварительную программу встречи;

изучите доступную информацию о предмете разговора;

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

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

Проведение опроса

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

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

Можете ли Вы привести пример?

Когда это произошло?

Если у этого правила исключение?

Можете ли Вы привести какие-нибудь цифры в подтверждение Ваших слов?

Можно предложить несколько общих рекомендаций, касающихся линии поведения аналитика при интервьюировании:

тезис в начале беседы - я ничего (или почти ничего) не знаю о Вашей работе, расскажите как можно подробнее, чем Вы занимаетесь? Даже если вы прекрасно знаете предметную область, не говорите много сами и не учите интервьюируемого;

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

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

не возражайте. Никогда не задавайте наводящих вопросов или вопросов с короткими ответами «да» или «нет». Вы получите от опроса больше, если дадите эксперту возможность говорить то, что он хочет сказать, а не то, что вы хотите услышать;

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

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

В принципе этих и подобных им правил достаточно для выявления в ходе беседы необходимой аналитику информации приблизительно у 90 % интервьюируемых. Что касается остальных 10 %, то их можно типизировать следующим образом [2]:

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

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

«Балласт» - человек, давно работающий на предприятии и непонятно чем занимающийся. На вопросы типа: «Какие функции Вы выполняете?», «С какими документами Вы работаете?» - агрессивно повторяет как попугай: «Я делаю все», «Со всеми документами», «Все документы ко мне приходят и все уходят». Какой-либо информации получить не удается по причине ее отсутствия. Естественно никакого отражения подобной «деятельности» в модели не производится.

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

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

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

Оформление результатов опроса

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

заметок;

перечня функций и данных/объектов;

эскизов диаграмм.

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

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

Титульный лист.

Интервью и последующая запись:

ФИО интевьюэра (автора IDEF-модели);

дата интервью;

продолжительность интервью (начало и окончание);

ФИО интервьюируемого;

его должность и ответственность;

номер телефона;

дополнительные источники информации:

документы;

другие интервью (ФИО, должность, ответственность, адрес, номер телефона);

существенные элементы информации - ключевые пункты, охваченные в интервью;

последующие вопросы или области, не охваченные в интервью;

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

Список функций и данных/объектов

Список основных интервьюируемых (разработанный при подготовке к интервью).

Примечания и эскизы диаграмм.

2.4.2 Построение IDEF0-модели

2.4.2.1 Выбор контекста, точки зрения и цели

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

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

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

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

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

2.4.2.2 Создание контекстной диаграммы

Моделирование начинается с создания диаграммы A-0. Нарисуйте одиночный блок, содержащий название функции, которая охватывает полные возможности (контекст) описываемой системы. Используйте входные, управляющие и выходные дуги для представления данных и объектов системы, реализующих интерфейс с окружающей ее средой. Эта одноблочная диаграмма ограничивает контекст для полной модели и формирует основание для дальнейшей декомпозиции. Запишите цель и точку зрения на A-0 контекстной диаграмме.

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

Если диаграмма A-0 началась на слишком низком уровне детализации, сделайте A-0 блок основанием для нового уровня A0 диаграммы. Продвиньтесь на один уровень к новой A-0-диаграмме, и повторно рассмотрите точку зрения и цель. Повторите этот процесс, пока A-0 не достигнут состояния, при котором будут охвачены все аспекты системы. (Иногда такой более высокий уровень будет значительно шире, чем необходимо с выбранной точки зрения. Если такое случится, то создайте A-1 многоблочную контекстную диаграмму и приведите диаграмму A0 к первоначальному виду.)

2.4.2.3 Создание A0-диаграммы

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

Реальная «вершина» модели - диаграмма A0. Ее структура ясно показывает то, что диаграмма A-0 только наметила показать. Содержание и структура A0 также ограничивают каждый последующий уровень, потому что это законченное описание выбранного объекта. Нижние уровни только раскрывают (но не дополняют) функции A0. Диаграмма A0 вынуждает автора поддерживать выбранный уровень абстракции, держать одинаковую глубину моделирования и относить подробности к более низкому уровню.

2.4.2.4 Создание дочерних диаграмм

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

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

При создании любой IDEF0-диаграммы, должны быть удовлетворены следующие требования:

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

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

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

2.4.2.5 Вспомогательный материал

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

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

2.4.2.6 Выбор блока для декомпозиции

Имея законченную родительскую диаграмму, «укрепите» более высокие уровни, прежде чем переходить к дальнейшей детализации. То есть, имея A0, опишите работу на уровне A1, A2, A3. Декомпозицию A1 в A11, A111 и т.д. следует сделать позже. Это позволит избежать потенциальной работы по переделке уже сделанного на диаграммах высшего уровня.

Выдерживать одинаковую глубину не является строгим правилом. Глубина в любой ситуации зависит от того, обеспечивает ли большая глубина лучшее качество, чем одна диаграмма. Не откладывайте изготовление диаграммы более низкого уровня, например, A111, - сделайте эскиз пока идея еще свежая. Будьте готовы переделать материал более низкого уровня, если это находится в противоречии с более высоким уровнем, например, A1, A2, A3.

Можно дать две рекомендации относительно выбора блока для детализации:

начните с «тяжелой части» - части, которая является наименее знакомой или ясной (понятной);

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

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

2.4.2.7 Создание IDEF0-диаграмм

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

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

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

Начертите эскизно соответствующие дуги

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

Создайте текстовую диаграмму, глоссарий и FEO-диаграммы (если необходимо), чтобы отразить важные аспекты.

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

Генерация функциональных блоков

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

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

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

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

Создание интерфейсных дуг

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

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

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

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

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

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

2.4.2.8 Выбор стратегии декомпозиции

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

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

Декомпозиция в соответствии с функциями, которые выполняют люди или организации. Такая декомпозиция может оказаться полезной стратегией для создания системы описаний, фиксирующей взаимодействие между людьми в процессе их работы. На Западе такие системы часто называют Р3 - первые буквы английских слов people (люди), paper (бумаги), procedures (процедуры). Рекомендуется использовать эту стратегию только в начале работы над моделью системы. В дальнейшем полученная при такой стратегии информация о системе в дальнейшем может быть использована для создания более обоснованной функциональной декомпозиции системы в целом.

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

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

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

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

2.4.2.9 Момент прекращения декомпозиции

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

2.4.2.10 Размер IDEF0-моделей

Посмотрим, как увеличивается размер IDEF0-модели [4]:

Уровень модели	Общее число блоков в модели
	в среднем 4 блок на диаграмме	в среднем 6 блоков на диаграмме
Контекст	1	1
0	5	7
1	21	43
2	85	259
3	341	1555
4	1365	9331

Необходимо заметить, что IDEF0-модели такого размера никогда не создаются по целому ряду причин. Обычно модель строится слоями, большинство из которых не являются глубокими - чаще всего ограничиваются тремя уровнями. Кроме того, не все исходные диаграммы декомпозируются на одинаковую глубину. Часто можно встретить декомпозицию части IDEF0-модели на глубину 5-6 уровней. В этом случае на такую глубину декомпозируется обычно один из блоков диаграммы А0, функции которого очень важны, и их детальное описание дает ключ к пониманию работы всей системы. Но таких функций при создании одной модели насчитывается, как правило, немного, поэтому модели, обладающие такими функциями, имеют обычно форму зонтика с широким тонким куполом и длинной ручкой, на которой происходит детализация.

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

2.4.2.11 Примечания и ссылки

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

Примечания

Имеются два вида примечаний: модельные и читательские.

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

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

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

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

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

Ссылки

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

Примеры

Ссылка	Значение
C2	граничная дуга с ICOM-кодом C2
2I1	вход I1 блока номер 2
2O2 к 3C1	дугу от 2O2 до 3C1
	модельное примечание номер n
| n |	модельное примечание номер n (альтернативное)
	читательское примечание номер n
(n)	читательское примечание номер n (альтернативное)
A42.	смотри читательское примечание номер 3 на диаграмме A42 данной модели
A42.	смотри модельное примечание номер 3 на диаграмме A42 данной модели
A42.3	смотри блок номер 3 на диаграмме A42 данной модели
QA/A21.3C2	смотри дугу управления C2 блока номер 3 на диаграмме A21 модели QA

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

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

MDA / (A21=BT56) .1O2 к 4C3

что означает: смотри в модели «MDA», на диаграмме A21 с C-номером BT56, дугу выхода 2 от блока 1 к управлению 3 блока 4.

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

Например. «A21.3C2 |2| (5) ответ» означает следующее: смотри на диаграмме A21 управление 2 к блоку 3, где автор отвечает на примечание читателя номер 5 (возможно добавленный вторым читателем диаграммы) который прокомментировал авторское модельное примечание номер 2, относительно рассматриваемого управления! В этом примере, «ответ» показывает использование кратких выражений естественного языка в языке ссылок.

2.4.3 Итерактивное рецензирование модели

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

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

В цикле автор-читатель принимают участие специалисты с разными обязанностями:

· авторы создают модели,

· читатели читают и комментируют работу авторов,

· Комитет технического контроля утверждает результаты,

· библиотекарь организует хранение и распространение материалов.

2.4.3.1 Моделирование системы

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

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

Рекомендуется оформлять модель в виде документа в формате «пара страниц» и в порядке «узловых индексов». Формат «пара страниц» означает, что каждая диаграмма и связанный с ней текст расположены в виде пары соседних страниц (рис. 2.24).

Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

Рис. 2.24

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

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

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

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

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

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

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

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

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

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