Критерий окончания декомпозиции диаграмм и меры по управлению проектом; цикл папки

 

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

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

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

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

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

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

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

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

Методология требует, чтобы каждый, кто делает замечания по папке, представлял бы эти замечания их автору в письменном виде. Автор, письменно, на том же экземпляре документов, отвечает каждому рецензенту. Этот процесс называется “Цикл папки”, и продолжается до тех пор, пока модель не завершена и не рекомендована к опубликованию. Более подробно цикл папки можно представить в виде следующих этапов:

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

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

3.Автор письменно отвечает каждому рецензенту. Он может принять замечание, отметив его знаком “+”, и внеся изменения в свой рабочий экземпляр, которые будут учтены в следующей версии модели. Если у автора есть возражения, он отмечает знаком “Х” соответствующее замечание. Рядом с ним автор должен письменно объяснить причину своего несогласия. После того, как автор ответит на все замечания, папка возвращается к рецензенту.

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

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

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

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

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

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

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

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

· руководитель проекта;

· авторы (разработчики) модели;

· технический совет;

· эксперты в предметной области;

· библиотекарь.

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

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

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

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

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

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

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

Контрольные вопросы

· Какие элементы включает модель SADT?

· Что подразумевается под понятием синтаксиса диаграмм SADT?

· Что включают базовые принципы моделирования в IDEF0?

· Что такое контекст диаграммы?

· Какие задачи и специфические черты характерны для начала моделирования?

· Какие основные объекты имеются в технологии IDEF0?

· Какие средства идентификации SADT диаграмм представлены в технологии IDEF0?

· Каким образом оформляются дополнения к диаграммам и моделям?

· Каков состав проектной группы с точки зрения идеологии IDEF?

· Что такое туннелирование дуг?

· Какие меры по управлению проектом предусмотрены в SADT- методологии и технологии IDEF0?

· Какие рекомендации имеются в методологии для определения момента прекращения декомпозиции диаграмм?

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

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

· Какова основная цель проведения «Цикла папки»?