<На страницу назад | На страницу вперед>

4.5.1 Разработка схематик процессов
Схематики процессов обеспечивают процессо-центрированное представление процесса. Эти схематики обеспечивают организацию знаний о процессах таким образом, что в центре внимания находятся процессы и их временные, причинно-и логические отношения в рамках контекста определенного сценария.

Построение схематики процессов включает следующие шаги:

  1. Идентифицировать все UOB.
  2. Ассоциировать данные UOB с соответствующим сценарием.
  3. Идентифицировать ограничения предшествования между парами UOB в сценарии и компоновкой исходной схематики.
  4. Добавить переходы для логического описания.
  5. Добавить необходимые ограниченные связи предшествования.
  6. Разработать детальные описания UOB, переходов и связей, по мере необходимости.
  7. Разработать декомпозиции для выбранных UOB.
  8. Добавить реляционные связи для выделения дополнительных отношений, представляющих интерес.

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

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

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

1. Функция
2. Процесс
3. Сценарий

4. Работа
5. Операция
6. Решение

7. Действие
8. Событие
9. Процедура

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

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

Ценным источником возможных UOB также является начальный набор фактов. Идентификация возможных UOB может начаться с поиска именованных процессов (например, процесс приобретения), глаголов в повелительном наклонении (например, ассигновать средства) и отглагольных существительных или герундиев (например, идентификация рабочих требований) в описании специалиста по предметной области. В результате этого анализа можно идентифицировать дополнительные сценарии и возможные UOB. В отличие от сценариев, имеющих обычно более общий характер, UOB более конкретны, имеют определенные временные ограничения. Это значит, что если можно идентифицировать сильные причинно-следственные или временные зависимости, вполне возможно, что была идентифицирована UOB, а не сценарий. Таким образом, фразы типа "Такие события могут потребовать повторное определение заданных задач в ответ на изменения в политике национальной безопасности" могут дать две возможные UOB ("Повторно определить заданные задачи" и "Пересмотреть политику национальной безопасности"), которые имеют причинно-следственное отношение "в ответ на".

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

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

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

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

Форма "Сводная схематика процессов" (рис. 4-5) помогает аналитику скоординировать работу по проверке со специалистами по предметной области и разработать схематику процессов на базе исходных данных. Частью этой формы является текстовое описание или глоссарий по схематике процессов.

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

 
Аналитик:                   Дата:
x
Рабочий вариант Рецензент: Дата:

Где
исполь зуется:

Проект:   Черновой вариант    
      Рекомендуемый вариант    
 
Примечания:              Реценз.:
  Выпущенный вариант    
Номер схематики процессов:
Имя схематики процессов:                             Метка схематики процессов:
Набор UOB:
UOB, на которые сделана ссылка: Сценарии, на которые сделана ссылка: Схематики переходов состояний, на которые сделана ссылка:
Объекты:
Описание:
Ссылка на установку контекста: Описанный элемент:

Тип формы: Сводная схематика процессов

Рис. 4-5
Форма "Сводная схематика процессов"

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

Детальные описания UOB, переходов и связей предшествования разрабатываются на базе данных, получаемых при проведении интервью, и проверяются специалистом по предметной области, знания которого представляет данное описание. Первоначально эти детальные описания могут иметь вид простых статей глоссария. Однако, по ходу выполнения анализа данных детальные описания становятся более четкими и структурированными. Типичная информация, включаемая в детальное описание: участвующие объекты и их роли, представляющие интерес факты, ограничения. Для записи этих детальных описаний на естественном языке используются формы детальных описаний (рис. 4-6 - 4-9).

Документ на детальное описание UOB включает: (1) имя UOB, метку и номер UOB; (2) листинги типов объектов и экземпляров, фактов и ограничений, определяющих характер и структуру данной UOB; (3) текстовое описание данной UOB (рис. 4-6).

 
Аналитик:                   Дата:
x Рабочий вариант Рецензент: Дата:

Где
исполь зуется:

Проект:   Черновой вариант    
      Рекомендуемый вариант    
 
Примечания:              Реценз.:
  Выпущенный вариант    
Номер UOB
Имя UOB:                          Метка UOB:
Объекты:
Факты:
Ограничения:

Описание:
Номер UOB
Имя UOB:                          Метка UOB:
Объекты:
Факты:
Ограничения:

Описание:
Ссылка на установку контекста: Описанный элемент:

Тип формы: Детальное описание UOB

Рис. 4-6
Форма "Детальное описание UOB"

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

  1. Номер UOB (UOB No.): В этой секции содержится номер UOB для ассоциированной UOB. Номер UOB уникально идентифицирует блок UOB, ассоциированный с документом на детальное описание.
  2. Имя UOB (UOB Name): В этой секции содержится имя UOB.
  3. Метка UOB (UOB Label): В этой секции содержится метка UOB (т.е. имя UOB, некоторая часть имени или аббревиатура, отражаемая в блоке UOB).
  4. Объекты (Objects): В этой секции перечисляются имена всех объектов (типы или экземпляры), участвующих в процессе, описываемом данной UOB. Объекты могут быть физическими или концептуальными. Объекты могут создаваться, модифицироваться или уничтожаться при выполнении процесса. Полезно отнести объект к определенной категории: агент, измененный, участвующий, созданный или уничтоженный объект.
      a. Агент (Agent) - если объекты (или объекты данного типа) играют активную причинно-следственную роль в экземплярах данной UOB.
      b. Измененный (Affected) - если объект (или экземпляры данного типа) изменен во время действия экземпляров данной UOB.
      c. Участвующий (Participant) - если с данным объектом не ассоциирована причинность или трансформация в экземплярах данной UOB.
      d. Созданный или Уничтоженный (Created или Destroyed) - если объект (или экземпляры данного типа) создан или уничтожен в экземплярах данной UOB.
  5. Факты (Facts): В этом поле перечисляются факты относительно экземпляров данной UOB.
  6. Ограничения (Constraints): В этом поле перечисляются ограничения на данную UOB, т.е. факты, определяющие, что должно действовать во всех экземплярах данной UOB.
  7. Описание (Description): Это поле содержит статью глоссария (текстовое описание) для данной UOB. Как правило, статья глоссария представляет текстовое изложение информации, уже содержащейся в списках объектов, фактов и ограничений.

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

 
Аналитик:                   Дата:
x Рабочий вариант Рецензент: Дата:

Где
исполь зуется:

Проект:   Черновой вариант    
      Рекомендуемый вариант    
 
Примечания:              Реценз.:
  Выпущенный вариант    
Номер перехода

Тип перехода

Объекты:

Факты:

Ограничения:

Описание:

Номер перехода

Тип перехода

Объекты:

Факты:

Ограничения:

Описание:

Ссылка на установку контекста: Описанный элемент:

Тип формы: Детальное описание переходов

Рис. 4-7
Форма "Детальное описание переходов"

Базовые поля (ядро) в документе на детальное описание переходов:

  1. Номер перехода (Junction No.): Номер перехода, перед которым ставится буква "J" (Junction - переход), уникально идентифицирующий переход в рамках данного описания.
  2. Тип перехода (Junction Type): Асинхронный И (AND), асинхронный ИЛИ (OR), синхронный И (AND), синхронный ИЛИ (OR), ИСКЛЮЧАЮЩЕЕ ИЛИ (XOR).
  3. Объекты (Objects): Все значимые объекты (типы или экземпляры), ассоциированные с данным переходом. Как правило, эти объекты являются агентами и устанавливают ограничения на переходы.
  4. Факты (Facts): Заслуживающие внимания, неограничивающие факты, ассоциированные с данным переходом, в частности, факты, включающие ассоциированные с данным переходом объекты.
  5. Ограничения (Constraints): Спецификация логики принятия решений и любых других ограничений, ассоциированных с данным переходом. В идеале эта спецификация должна быть приведена в логически точной форме на языке детального описания IDEF3. Язык детального описания определяется, обсуждается и иллюстрируется в приложении A.
  6. Описание (Description): Неформальное описание логики принятия решений, при использовании любых других аннотаций или исходной информации.

Особые ограничения, определяемые ограниченными связями предшествования, регистрируются в документе на детальное описание связей предшествования (рис. 4-8). По формату и назначению этот документ подобен детальному описанию UOB.

 
Аналитик:                   Дата:
x Рабочий вариант Рецензент: Дата:

Где
исполь зуется:

Проект:   Черновой вариант    
      Рекомендуемый вариант    
 
Примечания:              Реценз.:
  Выпущенный вариант    
Номер связи
Номер маршрута:                     Источник:
Адресат:
 

Объекты:

Факты:

Ограничения:

Описание:

Ссылка на установку контекста: Описанный элемент:

Тип формы: Детальное описание связей предшествования

Рис. 4-8
Форма "Детальное описание связей предшествования"

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

  1. Номер связи (Link No.): Номер связи, перед которым ставятся буквы "PL" (Precedence Link - связь предшествования), уникально идентифицирующий связь предшествования в рамках данного описания.
  2. Номер маршрута (Path No.): Номер маршрута связи, включающий номер связи и уникальное целое число, разделенные интервалом. Например, для связи предшествования PL1, которая расходится по трем альтернативным маршрутам в соответствии с переходом, используются следующие номера маршрутов связи: PL1.1; PL1.2; PL1.3.
  3. Источник (Source): Имя исходного элемента связи IDEF3 (т.е. UOB или референт) в специфицированном маршруте.
  4. Адресат (Destination): Имя элемента IDEF3 (т.е. UOB или референт), являющегося адресатом связи в специфицированном маршруте.
  5. Объекты (Objects): Все значимые объекты (типы или экземпляры), участвующие в отношении, представляемом данной связью. Как правило, эти объекты представляют составные части источника или адресата отношения, представляемого данной связью.
  6. Факты (Facts): Заслуживающие внимания, неограничивающие факты, включающие объекты, участвующие в отношении, представляемом данной связью.
  7. Ограничения (Constraints): Заслуживающие внимания ограничения, действующие между UOB источника и адресата или между некоторыми составляющими объектами. В частности, это поле содержит ограничения, определяемые общей ограниченной связью предшествования.
  8. Описание (Description): Дескрипторный глоссарий, ассоциированный с данной связью. Здесь размещается любая дескрипторная информация, которая логически не подходит для других полей в данном документе.

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

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

 
Аналитик:                   Дата:
x Рабочий вариант Рецензент: Дата:

Где
исполь зуется:

Проект:   Черновой вариант    
      Рекомендуемый вариант    
 
Примечания:              Реценз.:
  Выпущенный вариант    
Номер связи

Источник:

Адресат:

Объекты:

Факты:

Ограничения:

Описание:

Ссылка на установку контекста: Описанный элемент:

Тип формы: Детальное описание пунктирных связей

Рис. 4-9
Форма "Детальное описание пунктирных связей"

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

  1. Номер связи (Link No.): Номер связи, перед которым ставятся буквы "DL" (Dashed Link - пунктирная связь), уникально идентифицирующий пунктирную связь в рамках данного описания.
  2. Источник (Source): Имя элемента IDEF3 (например, UOB, референт), являющегося источником отношения, представленного связью.
  3. Адресат (Destination): Имя элемента IDEF3 (например, UOB, референт), являющегося адресатом отношения, представленного данной связью.
  4. Объекты (Objects): Все значимые объекты (типы или экземпляры), участвующие в отношении, представленном пунктирной связью. Как правило, эти объекты являются составляющими источника или адресата отношения, представленного пунктирной связью.
  5. Факты (Facts): Заслуживающие внимания, неограничивающие факты, включающие объекты, которые участвуют в отношении, представленном пунктирной связью.
  6. Ограничения (Constraints): Заслуживающие внимания ограничения, действующие между элементами источника и адресата или между составляющими объектами.
  7. Описание (Description): Глоссарий, ассоциированный с пунктирной связью. Здесь размещается любая дескрипторная информация, которая логически не подходит для других полей данного документа.

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

Как и разработка описаний IDEF3, процесс разработки декомпозиций представляет процесс уточнения. Разработка декомпозиций повторяет ту же процедуру, которая используется для разработки первичного описания. Этот цикл уточнения включает следующие работы: (1) анализ работы; (2) сбор дополнительных данных; (3) описание ситуаций в терминах связанных UOB; (4) проверка; (5) возврат на предыдущий шаг процедуры, если в этом есть необходимость.

<На страницу назад | На страницу вперед>