Этап 4. Критиковать авторское изложение.

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

1. Правилен ли синтаксис построенных диаграмм?

2. Понятно ли изложено, то, что хотел сказать автор?

3. Согласен ли я с тем, что представлено автором?

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

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

 

Проверка диаграммы автором

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

Порядок критической оценки:

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

2. создать альтернативные декомпозиции;

3. корректировка новой диаграммы;

4. корректировка всех связанных с ней диаграмм.

 

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

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

Вопросы о блоках:

 

 

 

· Представляют ли блоки содержательную декомпозицию функции?

· Не выглядит ли диаграмма запутанно?

· Все ли блоки соответствуют точке зрения модели?

· Несут ли блоки достаточный объем новой информации?

· Все ли блоки имеют одинаковый уровень детализации?

· Соразмерна ли сложность всех блоков?

· Отражает ли каждый блок какой-то аспект родительской диаграммы?

Вопросы о связях с родительской диаграммой:

· Все ли внешние дуги имеют ICOM коды?

· Все ли ICOM коды соединяют дуги с одним и тем же значением?

· Дополняют ли названия внешних дуг информацию, сообщаемую диаграммой?

· Не противоречит ли смысл анализируемой диаграммы смыслу родительского блока и его диаграмме?

Вопросы о внутренних дугах

· Не слишком ли много внутренних дуг?

· Нет ли блоков без дуг управления?

· Нет ли блоков без выходных дуг?

· Правильно ли отражают дуги, представляющие ограничения, доминирование блоков?

· Верно ли решение диаграммы?

· Все ли важные обратные связи отражены?

· Все ли ошибочные ситуации учтены?

 

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

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

На хорошей диаграмме блоки должны обладать следующими качествами:

· выполнять строго определенные функции;

· иметь одинаковую сложность;

· иметь одинаковый уровень детализации;

· просто и ясно соединяться с другими блоками диаграммы;

· воздействовать на управление, вход и выходы с определенным смыслом;

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

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

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

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

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

 

Коррек тировка но в о й д иаг р а м м ы

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

 

 

В ходе корректировки необходимо следить за:

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

· выбором названий блоков;

· информативностью дуг;

· делать пояснения.

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

У глагола не обязательно должен быть объект (объекты/данные описаны в виде дуг),

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

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

и данных.

С помощью дополнительных материалов (FEO, глоссарий, текстовые диаграммы)

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

 

Исправле ние взаи мосвязан ных диаграмм

Автор вынужден вносить исправления в другие диаграммы (а не только в текущей) в трех случаях:

· при изменении меток внешних дуг,

· при появлении новых внешних дуг,

· при перераспределении функций (в диаграммы-потомки).

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

IDEF0 — это методология, формирующая стиль мышления, а не просто упражнения в построении диаграмм.

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

 

Процесс рецензирования диаграмм

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

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

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

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

· авторы (создают модели);

· читатели-специалисты (читают и комментируют работу автора);

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

· библиотекарь (организует обмен и хранение материалами).

Цикл автор-читатель включает следующие функции:

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

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

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

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

 

 

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

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

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

· блок уже содержит достаточное количество деталей, чтобы ответить на поставленные вопросы;

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

· необходимо изменить точку зрения, чтобы лучше детализировать блок;

· блок слишком похож на другой блок той же модели;

· блок очень похож на другой блок другой модели;

· блок представляет тривиальную (слишком простую для декомпозиции) функцию.

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

где будет использоваться модель в будущем:

· для разработки ПО,

· для написания руководства,

· для управления технологическим процессом,

· для разработки и внедрения нового процесса и т.д. и т.п.

 

Достаточная детализованность

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

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

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

 

Изменение уровня рассмотрения

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

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

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

 

Изменение точки зрения

Ситуации, которые сигнализируют о возможной замене точки зрения:

· дальнейшую декомпозицию "хорошо понятного" блока трудно проводить без изменения точки зрения модели;

· при декомпозиции блока появляется совершенно новая терминология;

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

 

 

 

Сходные функции

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

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

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

 

Тривиальные функции

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

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

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

поясняя содержание более сложных.

 

Размер моделей

С математической точки зрения, число блоков в модели в зависимости от уровня иерархии растет в геометрической прогрессии (см. Таблица 1).

 

Таблица 1

 

Уровень в модели	Общее число блоков в модели
4 блока на диаграмме	6 блоков на диаграмме
Top

Однако на практике это не так. Обычно модель строится слоями, большинство из которых не являются глубокими. Очень часто, диаграммы 3-го уровня строятся только для того, чтобы убедиться, что полученные на диаграммах 2-го уровня ответы на поставленные вопросы являются полными (цель достигнута).

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

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

 

 

 

Литература

1. Девид Марка, Клемент МакГроуэн. Методология структурного анализа и проектирования:

Пер. с англ.-М.:1993, 240 с., ил.

2. INTEGRATED COMPUTER – AIDED MANUFACTURING (ICAM). ARCHITECTURE PART

II. VOULME IV – FUNCTION MODELLING MANUAL (IDEF0). SoftTech, Inc. 460 Totten Road, Waltham, MA 02154. June 1981. (русская редакция стандарта по методологии IDEF0 подготовлена в 1993 г. и распространяется компанией МетаТехнология).

3. ISO 9000 Introduction and Support Package: Guidelines on the Process Approach to quality management systems. ISO/TC 176/SC 2/N 544R. 17 May, 2001.

4. ISO 9000 Introduction and Support Package: Guidance on the Documentation Requirements of

ISO 9001:2000. ISO/TC 176/SC 2/N 544R. 13 March, 2001.

5. INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0). Draft Federal

Information Processing Standards Publication 183, 1993, December 2

6. Р50.1.028-2001. Методология функционального моделирования. М.: Госстандарт России,

2001.

7. Окулесский В.А. Функциональное моделирование – методологическая основа реализации процессного подхода. М.: НИЦ CALS-технологий «Прикладная логистика», 2001.

8. Менеджмент качества и международные стандарты ИСО 9000 версии 2000 г. Материалы семинара в рамках Программы ИСО для развивающихся стран. Минск, Июль 2001 г. 79 с.

9. Рахлин К.М. МС ИСО серии 9000 версии 2000 г.: сущность и содержание процессного подхода. М.: Стандарты и Качество, №3, 2001.

10. Information Integration For Concurrent Engineering (IICE). IDEF3 Process Description Capture

Method Report. Knowledge Based Systems, Inc., Texas, USA, 1995.

11. Хаммер M., Чампи Д. Реинжиниринг корпорации: Манифест революции в бизнесе. - С.-

Петербург: С.-Петербург. ун-т, 1999.- 332.