Методика выполнения работы

Лабораторная работа 1

Моделирование бизнес-процессов с использованием методологии SADT

Цель работы: сформировать навыки моделирования бизнес-процессов с использованием методологии IDEF0.

Теоретическая часть

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

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

Наша цель – создать функциональную модель бизнес-процессов данной предметной области.

Напомним, что методология IDEF0 придерживается следующих концепций:

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

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

3. Передача информации. В IDEF0 существует ряд средств, разработанных для улучшения передачи информации:

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

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

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

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

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

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

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

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

- связность интерфейса диаграмм (номера узлов, номера блоков, C-номера);

- связность структуры данных (ICOM-коды и использование туннельных дуг);

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

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

- ограничение на ветвление дуг данных (метки для ограничений потоков данных на ветвях);

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

- требования к меткам дуг данных (правила минимальных меток);

- минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга;

- цель и точка зрения (у каждой модели есть цель и точка зрения).

5. Методология. Пошаговые процедуры обеспечивают моделирование, рецензирование и решение задач интеграции.

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

Создание функциональных моделей и диаграмм по методологии SADT происходит в следующей последовательности:

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

2. Декомпозиция объекта исследования.

3. Моделирование:

3.1. Выбор цели и точки зрения.

3.2. Составление списка данных.

3.3. Составление списка функций.

3.4. Построение и обобщение диаграмм A0(A0 – A-0).

3.5. Декомпозиция ограниченного объекта.

3.6. Итерационный процесс рецензирования.

3.7. Завершение моделирования.

3.8. Документирование.

Начало моделирования с использованием методологии SADT означает создание диаграмм A0 (диаграмма декомпозиции) и А-0 (контекстная диаграмма), которые затем должны быть отрецензированы. Эти две диаграммы полностью рассказывают все об изучаемой предметной области с минимальной степенью детализации.

Прежде чем начать моделирование необходимо к нему подготовиться: собрать информацию и вначале декомпозировать объект исследования (декомпозиция – диаграмма A0 освещает наиболее важные функции и объекты системы), и только затем обобщить эту декомпозицию (диаграмма А-0 трактует систему как черный ящик, дает ей название и определяет наиболее важные входы, управления, выходы и механизмы). При этом надо учесть, что не один из инструментариев, поддерживающих модель IDEF0, в этой части процесса моделирования не поддерживает методологию SADT. Все они предполагают начинать моделирование с контекстной модели. Это противоречие можно разрешить следующим образом: построить первоначальную версию контекстной модели. Затем ее декомпозировать, согласно собранной информации и определений основных функций и данных (построить A0). Затем вернуться к первоначальной версии контекстной модели и внести необходимые изменения.

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

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

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

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

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

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

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

В качестве примера рассмотрим точку зрения начальника отдела продаж, сотрудник которого осуществляет проверку состояния на складе готовой продукции. Цель начальника отдела продаж – организовать своевременную реализацию готовой продукции по договорам и продавать как можно больше продукции со склада, изготовленную по рекомендациям отдела маркетинга (без предварительного договора). Поэтому цель создания бизнес-модели (модели AS-IS): описать процесс реализации готовой продукции со склада.

Теперь можно перейти к определению названия общей функции. Можно идентифицировать ее так: реализация готовой продукции со склада.

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

Учитывая этот принцип классификации данных, отнесем в нашей задаче:

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

К выходным данным: – информация об отпущенном товаре со склада.

К управляющим: – прайс-лист на продукцию предприятия.

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

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

Методика выполнения работы

1. Приступим к графическому изображению контекстной модели в MSVisio. Контекстная диаграмма изображена на рис.1.1.

Рисунок 1.1 – Контекстная диаграмма

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

Пример отчета для модели:

ModelName: Отпуск товара

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

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

Viewpoint: Начальникотделапродаж

Time Frame: (AS-IS)

Status: WORKING

Purpose: Описать процесс реализации готовой продукции со склада

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

AuthorName: Ипатова

   Пример отчета для контекстной диаграммы:

ReportforDiagram: A-0, Реализация готовой продукции со склада

ActivityName: Реализация готовой продукции со склада

ActivityDefinition: Контекстная диаграмма описывает процесс отпуска продукции со склада готовой продукции по договорам заказчиков и в свободной продаже

Activity Status: WORKING

Activity Author: Ипатова

LinkName: Договор

LinkDefinition: Данные в договоре, касающиеся срока выполнения и номенклатуры крепежных изделий

LinkName: Данные о выполнении договора

LinkDefinition: Данные о том, что на склад поступили изделия, изготовленные по договору

LinkName: Данные о товаре в продаже

LinkDefinition: Данные о товаре на складе, предназначенном для свободной продажи

LinkName: Запрос покупателя

LinkDefinition: Запрос о товаре на складе, предназначенном для свободной продажи

LinkName: Данные об оплате

LinkDefinition: Данные о том, что покупатель оплатил товар

LinkName: Данные об отпущенном товаре

LinkDefinition: Отчеты о проданном товаре в свободной продаже, об отпущенном товаре, произведенном по договорам, отметка о выполнении договоров

LinkName: Прайс-лист

LinkDefinition: Цены на товарную продукцию "Метиз-М" на момент продажи

LinkName: Кладовщик

LinkDefinition: Выписывает сопроводительные документы на товар, делает отметку о передаче товара со склада покупателю

LinkName: Сотрудник отдела продаж

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

LinkName: Менеджер по договорам

LinkDefinition: Осуществляет отметку о выполнении заказа и передаче произведенной продукции на склад, осуществляет отметку после отпуска товара со склада при условии выполнения договора в договоре

 

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

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

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

Основные данные можно соотнести с основными функциями следующим образом:

- договор и запрос покупателя – входные данные функции «обработка заказа»;

- данные о выполнении договора и данные о товаре в свободной продаже (данные внешней системы) – входные данные функции «запрос на склад»;

- сведения об оплате – входные данные функции «проверка оплаты»;

- прайс-лист – управляющее данное для функции проверка оплаты;

- данные об отпущенном товаре – выходное данное функции «выдача товара».

Механизмы и основные функции соотнесем таким образом:

- сотрудник отдела продаж – «обработка заказа», «запрос на склад», «проверка оплаты»;

- кладовщик и менеджер по договорам – «выдача товара» (менеджер осуществляет отметку о закрытии договора с покупателем).

Отобразим это на графической модели (рис.1.2).

Рисунок 1.2 – Диаграмма декомпозиции

 

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

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

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

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

Внесем эти изменения на модель. Получим новую контекстную диаграмму A-0 (рис. 1.3) и законченную диаграмму декомпозиции A0 (рис. 2.4).

 

Рисунок 1.3 – Новая контекстная диаграмма

Рисунок 1.4 – Новая диаграмма A0

 

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

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

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

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

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

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

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

4. выписывает требование на товар для получения его на складе;

5. сообщает на склад о подготовке товара на продажу.

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

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

Рисунок 1.5 – Диаграмма декомпозиции

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

Отчеты к диаграмме декомпозиции:

ReportforDiagram: A2, Запроснасклад

ActivityName: Проверка готовности заказа

ActivityDefinition: Проверка производится на основании записей в журнале готовой продукции

Activity Status: WORKING

Activity Author: Ипатова

ActivityName: Подготовка документов на оплату

ActivityDefinition: На основании правил оформления платежных документов готовится платежка

Activity Status: WORKING

Activity Author: Ипатова

ActivityName: Подготовка требования

ActivityDefinition: Требование выписывается с пометкой: отпуск товара только при условии соблюдения условий договора и полной оплаты товара.

Activity Status: WORKING

Activity Author: Ипатова

ActivityName: Сообщение на склад

ActivityDefinition: Сообщение на склад делается по телефону после выписки сопроводительных документов.

Activity Status: WORKING

Activity Author: Ипатова

LinkName: Данные о выполнении договора

LinkDefinition: Данные о том, что на склад поступили изделия, изготовленные по договору

LinkName: Данные о товаре в продаже

LinkDefinition: Данные о товаре на складе, предназначенном для свободной продажи

LinkName: Сотрудник отдела продаж

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

LinkName: Устав Метиз-М

LinkDefinition: Устав предприятия и его дополнения, в которых прописаны правила выполнения бизнес-процессов на предприятии

LinkName: Обработанный запрос

LinkDefinition: Запрос покупателя, прошедший предварительную обработку на соответствие номенклатуры выпускаемого товара

LinkName: Отсутствие товара

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

LinkName: Имеется товар

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

LinkName: Товар в наличии

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

LinkName: Платежка

LinkName: Требование

LinkName: Правила оформления платежей

LinkDefinition: Общие правила оформления платежных документов

LinkName: Правила оформления требований

LinkDefinition: Общие правила оформления требований

LinkName: Правила сообщений

LinkDefinition: Внутрикорпоративные правила передачи такого рода сообщений

LinkName: Правила проверки

LinkDefinition: Внутрикорпоративный стандарт

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

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

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

Рисунок 1.6 – FEO диаграмма для A0

 

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

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