94 ТЕХНОЛОГИЯ РАЗРАБОТКИ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ IDEF3

ВВЕДЕНИЕ

 

Технология разработки описаний процессов включает в себя методологию описания процессов IDEF3 [1,2], технологический цикл развития описаний процессов [4,5] и инструментальные средства поддержки построения диаграмм процессов [3].

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

Содержание учебного пособия построено на материалах различных зарубежных источников, а также на оригинальных результатах работ по созданию научно-методического обеспечения при выполнении НИОКР и на базе курсов лекций, прочитанных авторами в Рязанской государственной радиотехнической академии [1-6].

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

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

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

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

 


Глава 1.  РАЗРАБОТКА ОПИСАНИЙ IDEF3

1.1. Цикл развития описаний IDEF3

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

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

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

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

1.2. Работы, связанные со сбором описаний IDEF3

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

 

1.2.1. Определение проекта

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

Лишь в редких случаях можно полностью определить цель и контекст заранее. Когда начинается компиляция данных, клиент часто пересматривает свой перечень необходимых сведений или вопросов. Нередко бывает так, что область, в которой аналитик рассчитывает получить определенный ответ, ведет в другие области, которые считались выходящими за рамки исследования. Как правило, цель и контекст развиваются в начальной стадии проекта. Для сбора материала, определяющего цель и контекст описания IDEF3, используется форма «Сводное описание IDEF3» (IDEF3 Description Summary Form), представленная на рис. 1.1.

 

Руководитель проекта:

Дата:

Компания:

Номер проекта:

Номер задачи:

 

Рабочий вариант

Рецензент

Дата

 

Черновой вариант

 

 

 

Рекомендуемый вариант

Выпущенный вариант

 

 

Цель:

Контекст:

Перечень сценариев:

Перечень объектов:

Имя описания:

Тип формы:

Сводное описание

Рис. 1.1. Форма «Сводное описание IDEF3»

1.2.2. Определение цели

Определение цели представляет один из наиболее важных начальных шагов в процессе разработки. Без определения цели единственными критериями окончания являются бюджет и время, выделенные для выполнения работ. Определение цели можно разделить на две части: 1) «Определение потребностей»; 2) определение информационных целей в терминах использования этой дескрипторной информации.

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

  1. Кто будет пользоваться данным описанием после его подготовки?
  2. На какой вопрос (вопросы) клиенту нужен ответ?
  3. Какие спорные вопросы или проблемы стоят за потребностью в описании процесса?
  4. Какие решения стоят за потребностью в описании процесса?

 

1.2.3. Установка контекста

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

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

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

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

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

 

1.3. Организация сбора данных

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

Как правило, персонал, принимающий участие в процессе сбора описаний потоков процессов IDEF3, выполняет следующие роли.

  1. Аналитик: специалист по IDEF3, который должен быть основным разработчиком описания потоков процессов IDEF3.
  2. Клиент: лицо или организация, делающая заявку на разработку описания.
  3. Специалист по предметной области: лицо, являющееся источником знаний по прикладной области, представляющей интерес.
  4. Ответственный за контакт: лицо, обеспечивающее взаимодействие аналитика и специалиста по предметной области.
  5. Руководитель проекта: лицо, в конечном итоге отвечающее за работу, связанную с разработкой описания в целом.
  6. Рецензенты: лица, обладающие знаниями по предметной области и/или методу IDEF3, которые несут ответственность за проверку и утверждение черновых описаний и документов. Рецензенты, имеющие полномочия на критику схематик IDEF3 в письменной форме, называются комментаторами. Остальные рецензенты называются читателями. В качестве рецензентов могут использоваться и члены проектной группы, и специалисты по предметной области.
  7. Библиотекарь: лицо, отвечающее за сопровождение журналов регистрации исходных материалов и файлов документов, изготовление копий, распространение комплектов IDEF3, ведение учета.
  8. Члены проектной группы: весь персонал, участвующий в проекте по разработке описания потоков процессов IDEF3.

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

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

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

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

 

1.4. Сбор и анализ данных

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

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

 

1.4.1. Подготовка к интервью

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

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

  1. Календарное планирование интервью и подготовка необходимой логистики.
  2. Постановка цели (целей) интервью.
  3. Подготовка возможных вопросов.
  4. Ожидание вероятных ответов и тревог интервьюируемого лица и готовность к снятию этих тревог.

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

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

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

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

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

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

  1. Для чего проводится интервью?
  2. Кто разрешил проведение интервью?
  3. У кого еще берут интервью?
  4. Каким образом был сделан выбор интервьюируемого и кем?
  5. Каким образом будет использована полученная информация?
  6. Сохранится ли анонимность интервьюируемого?
  7. Будет ли интервьюируемый указан в сводных данных?
  8. Возможна ли обратная связь и что получит интервьюируемый?
  9. Каким образом интервьюируемый мог бы участвовать в результате данного процесса?
  10. Что интервьюируемый может выиграть от интервью?
  11. Почему точная информация с высоким уровнем детализации важна для успешного проведения интервью и данного проекта?
  12. Каким образом интервьюируемый играет ключевую роль в важном процессе?

 


1.4.2. Интервьюирование специалистов по предметной области

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

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

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

 

Сбор имен объектов

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

 

Сбор имен работ

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

 

Сбор фактов и ограничений, связанных с вхождениями процессов

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

  1. Ограничения, регламентирующие инициацию процесса.
  2. Условия, которые должны действовать в течение процесса.
  3. Условия, являющиеся сигналом о завершении процесса.
  4. Процессы, запускаемые инициацией или завершением данного процесса.
  5. Свойства (атрибуты) вхождения процесса (например, продолжительность, прерываемость).
  6. Объекты, участвующие в качестве агентов, информации, ресурсов, продуктов в данном процессе.
  7. Свойства (атрибуты) объектов (например, свойства, ассоциированные с данным процессом, такие, как частота поступления или частота брака).
  8. Отношения или ассоциации между объектами в одном процессе.
  9. Отношения или ограничения на объекты между процессами (например, совместно используемые ресурсы).
  10. Условия, которые должны быть выполнены по отношению к объектам, участвующим в данном процессе.
  11. Различие между штатными и исключительными ситуациями в данном вхождении процесса.

В совокупности этот набор информации называется фактами.

 

Сбор описаний ситуаций

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

 

1.4.3. Сбор и каталогизация исходного материала

Аналитик должен  просмотреть  информационные артефакты по данному процессу (например, формы, экраны), включенные в описание специалиста по предметной области. Копии этих информационных артефактов должны быть собраны для дальнейшего анализа в степени, определяемой практической целесообразностью. Все данные, собранные по ходу выполнения проекта, должны быть зарегистрированы в «Журнале регистрации исходного материала IDEF3», как показано на рис. 1.2.

Где

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

Аналитик:                    Дата:

x

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант Рекомендуемый вариант

Примечания:

Реценз.: 

Выпущенный вариант

Номер исходного материала

Имя исходного материала

От кого получен

материал

Кто

получил материал

Дата получения

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Журнал регистрации исходного материала

Рис. 1.2. Журнал регистрации исходного материала

 

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

Где

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

Аналитик:                    Дата:

x

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

 

Рекомендуемый вариант

Примечания:               Реценз.: 

Выпущенный вариант

Номер исходного материала

Имя исходного материала:

Поддержка:

Комментарии:

Аннотация:

Номер исходного материала

Имя исходного материала:

Поддержка:

Комментарии:

Аннотация:

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Описание исходного материала

Рис. 1.3.  Форма «Описание исходного материала»

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

  1. Поддержка (Supports): в этом поле документируются номера элементов IDEF3 (например, номера объектных состояний), поддерживаемых данным исходным материалом, что обеспечивает прослеживаемость элементов описания до конкретного исходного материала.
  2. Комментарии (Comments): это поле используется для регистрации конкретных свойств или комментариев, заслуживающих впоследствии ссылки при каталогизации данного элемента.
  3. Аннотация (Abstract): аннотация представляет краткий обзор основных концепций, рассматриваемых в данном исходном материале.

 


Анализ собранных данных

После сбора данных, проведения анализа записей, сделанных во время интервью, исходный материал изучается и регистрируется в «Журнале регистрации исходного материала»; первоначальные данные каталогизируются в листы, называемые пулами. В IDEF3 используется четыре пула: 1) объектный пул; 2) сценарный пул; 3) пул UOB; 4) пул объектных состояний. На рис. 1.4 для примера приводится объектный пул. Для всех остальных пулов IDEF3 используется такое же базовое размещение, какое показано на рис. 1.4.

 

Где

Используется:

Аналитик:                    Дата:

x

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

 

Рекомендуемый вариант

Примечания:               Реценз.: 

Выпущенный вариант

Объект

Номер

Объект

Номер

исх. м.

ID No.

Имя

исх.  м.

ID No.

Имя

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Объектный пул

Рис. 1.4.  Пример объектного пула IDEF3

(Поле, имеющее обозначение «Объект», будет называться «Сценарий», «UOB», или «Объектное состояние», в зависимости от пула. Кроме того, поля «ID No.» должны быть заменены обозначениями «S» (Scenario - сценарий), «UOB» (Unity of Behavior - единица поведения) или «OS» (Object State - объектное состояние) для составления идентифицирующих номеров элементов).

Получение требуемой дополнительной информации

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

  1. Проведение дополнительных (контрольных) интервью для получения ответов на вопросы и/или идентификации дополнительных источников информации.
  2. Использование процесса проверки комплектов.
  3. Организация прямого наблюдения за данным процессом или сценарием.
  4. Пересмотр исходного материала с изменением направленности при проведении анализа.
  5. Проведение упрощенных рабочих семинаров.

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

 

1.5. Разработка схематик IDEF3

Механизм сбора и отображения информации для описания процессов включает два типа схематик IDEF3. Схематика процессов обеспечивает процессо-ориентированное представление сценария. Схематика объектов обеспечивает объектно-ориентированное представление сценария или набора сценариев. Оба типа схематик составляют графические проекции описаний, предоставленных специалистами по предметной области.

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

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

 

1.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, ассоциировать их с соответствующими сценариями и начать процесс построения исходной схематики процессов.

 


Компоновка начальной схематики процессов

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

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

Форма «Сводная схематика процессов» (рис. 1.5) помогает аналитику скоординировать работу по проверке со специалистами по предметной области и разработать схематику процессов на базе исходных данных.

 

Где

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

Аналитик:  Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант Рекомендуемый вариант

Примечания:

Реценз. : 

Выпущенный вариант

Номер схематики  процессов:

Имя схематики процессов:                        Метка схематики процессов:

Набор UOB:

UOB, на которые сделана ссылка:

Сценарии, на которые сделана ссылка:

 

Схематики переходов состояний, на которые сделана ссылка:

 

Объекты:

 

Описание:

 

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

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

Рис. 1.5. Форма «Сводная схематика процессов»

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

Разработка детальных описаний UOB, переходов и связей

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

 

Где

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

Аналитик:       Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

Рекомендуемый вариант

Примечания:

Реценз.: 

Выпущенный вариант

Номер UOB

 

 

Имя UOB:                                       Метка UOB:

Объекты:

Факты:

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

Описание:

Номер UOB

Имя UOB:                                     Метка UOB:

Объекты:

Факты:

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

Описание:

 

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Детальное описание UOB

Рис. 1.6. Форма «Детальное описание UOB»

 

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

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

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

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

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

 

Где

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

Аналитик:                 Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

 

Рекомендуемый вариант

Примечания:

Реценз.: 

Выпущенный вариант

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

 

 

Тип перехода: 

Объекты:

Факты:

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

Описание:

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

Тип перехода:

Объекты:

Факты:

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

Описание:

 

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Детальное описание переходов

Рис. 1.7. Форма «Детальное описание переходов»

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

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

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

 

Где

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

Аналитик:                    Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

Рекомендуемый вариант

Примечания:                Реценз.: 

Выпущенный

вариант

Номер связи

Номер маршрута:       Источник:

Адресат:

Объекты:

Факты:

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

Описание:

 

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Детальное описание связей предшествования

Рис. 1.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): дескрипторный глоссарий, ассоциированный с данной связью. Здесь размещается любая дескрипторная информация, которая логически не подходит для других полей в данном документе.

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

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

 

Где

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

Аналитик:                    Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант Рекомендуемый

вариант

Примечания:                Реценз.: 

Выпущенный

вариант

Номер связи

 

 

Источник:

Адресат:

Объекты:

Факты:

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

Описание:

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

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

 

Рис. 1.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) возврат на предыдущий шаг процедуры, если в этом есть необходимость.

 

1.5.2. Разработка схематик объектов

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

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

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

 

Выбор объектов, представляющих интерес

Первой задачей, выполняемой при построении части описания, представляющей схематику объектов, является принятие решения, определяющего объекты, которые должны быть описаны. В принципе аналитик должен идентифицировать объекты, играющие важную роль в знаниях специалиста по предметной области относительно данной системы. Список объектов, включенных в процесс, может быть большим. Для сравнения можно сказать, что список объектов, представляющих особый интерес, скорее всего должен быть небольшим. Обычно существуют объекты, которые модифицируются описываемым процессом. Поскольку создание схематики объектов обычно следует за разработкой одной или нескольких схематик процессов, основными источниками объектов, представляющих интерес, являются следующие элементы: 1) детальные описания UOB; 2) описания сценариев; 3) информационные модели, требуемые для данного сценария (например, другие модели IDEF); 4) исходные данные, полученные при проведении интервью. Независимо от источника объектов они имеют два общих свойства: 1) подвергаются заметным изменениям в данном процессе; 2) существуют в нескольких состояниях в разных точках данного процесса.

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

Компоновка начальной схематики объектов

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

Где

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

Аналитик:

Дата:

x

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

Рекомендуемый вариант

Примечания:

Реценз.: 

Выпущенный вариант

Номер схематики объектов:

 

Имя схематики объектов:

Тип схематики объектов:

 

Метка схематики объектов:

Набор объектных состояний:

UOB, на которые сделана ссылка:

Сценарии, на которые сделана ссылка:

Схематики переходов состояний, на которые сделана ссылка:

Объекты:

Описание:

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Сводная схематика объектов

Рис. 1.10. Форма «Сводная схематика объектов»


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

  1. Номер схематики объектов (Object Schematic No.): уникальный идентифицирующий номер схематики объектов, перед которым ставятся буквы «TS» (Transition Schematic - схематика переходов состояний) и «OBS» (Object Schematics - схематика объектов).
  2. Тип схематики объектов (Object Schematic Type): тип схематики объектов может быть описан как «Схематика переходов состояний», «Схематика расширенных переходов состояний» или «Схематика объектов». «Схематики переходов состояний» (т.е. «Схематики переходов состояний» и «Схематики расширенных переходов состояний») представляют особые типы «Схематик объектов», контекст которых устанавливается по одному сценарию.
  3. Имя схематики объектов (Object Schematic Name): имя схематики объектов.
  4. Метка схематики объектов (Object Schematic Label): имя схематики объектов, некоторая часть имени или аббревиатура, используемая для удобства при отображении в графическом элементе IDEF3 (например, при отображении в референте).
  5. Набор объектных состояний (Object State Set): набор объектных состояний, составляющих переход состояний, представляемых схематикой объектов, если данная схематика относится к типу «Схематика переходов состояний». Если данная схематика представляет общую схематику объектов, в этом поле перечисляются объектные состояния, включенные в данную схематику объектов.
  6. UOB, на которые делается ссылка (Referenced UOBs): набор UOB, на которые делается ссылка в схематике объектов.
  7. Сценарии, на которые делается ссылка (Referenced Scenarios): набор сценариев, на которые делается ссылка в схематике объектов.
  8. Схематики переходов состояний, на которые делается ссылка (Referenced Transition Schematics): набор схематик переходов состояний, на которые делается ссылка в схематике переходов.
  9. Объекты (Objects): набор объектов, включенных в схематику объектов в целях установки контекста.
  10. Описание (Description): текстовое описание или глоссарий, ассоциированный с данной схематикой объектов. Здесь размещается любая дескрипторная информация, которая логически не подходит для других полей.

 

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

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

 

Разработка детальных описаний объектных состояний, переходов

и связей

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

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

Где

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

Аналитик:                    Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант Рекомендуемый вариант

Примечания:                 Реценз.: 

Выпущенный

вариант

Номер

объектного состоя

ния

 

 

Имя объектного состояния:

Метка:

Переходы из объектных состояний:

Переходы в объектные состояния:

Факты:

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

Условия состояния:

Условия выхода из состояния:

Другие:

Описание:

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Детальное описание объектных состояний

Рис. 1.11. Форма «Детальное описание объектных состояний»

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

  1. Номер объектного состояния (Object State No.): уникальный идентифицирующий номер объектного состояния, перед которым ставятся буквы «OS» (Object State - объектное состояние).
  2. Имя объектного состояния (Object State Name): имя объектного состояния.
  3. Метка (Label): имя схематики объектов, некоторая часть имени или аббревиатура, используемая для удобства при отображении в графическом элементе IDEF3 (например, при отображении в референте).
  4. Переходы из объектных состояний (Transitions from Object State(s)): объектные состояния, из которых переходит данный объект.
  5. Переходы в объектные состояния (Transitions to Object State(s)): объектные состояния, в которые переходит данный объект.
  6. Факты (Facts): факты, действующие для объектов в данном состоянии.
  7. Ограничения (Constraints): ограничения на объекты в данном состоянии. В частности, указывается три типа ограничений:

a)       условия состояния (State Conditions) -  условия, индивидуально необходимые для того, чтобы объект находился в данном состоянии;

b)       условия выхода из состояния (Exit Conditions) - условия, достаточные для выхода объекта из данного состояния;

c)       другие (Other) - дополнительные ограничения, представляющие интерес.

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

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

Где

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

Аналитик:                    Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант Рекомендуемый вариант

Примечания:                Реценз.: 

Выпущенный вариант

Номер связи

Номер маршрута:       Источник:

Адресат:

Объекты:

Факты:

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

Условия перехода состояний:

Условия входа в состояние:

Другие:

Описание:

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Детальное описание связей переходов состояний

Рис. 1.12. Форма «Детальное описание связей переходов состояний»

Поля формы детального описания связей переходов состояний.

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

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

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

c)       другие (Other):  дополнительные ограничения, представляющие интерес.

  1. 8.       Описание (Description): глоссарий, ассоциированный с данной связью переходов состояний. Здесь размещается любая дескрипторная информация, которая логически не подходит для других полей данного документа.

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

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

 

Где

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

Аналитик:                    Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

 

Рекомендуемый вариант

Примечания:               Реценз.: 

Выпущенный вариант

Номер объектного

состояния

Имя объекта:

Метка:

Факты:

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

Описание:

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Детальное описание объектов

 

Рис. 1.13. Форма «Детальное описание объектов»

 

Содержание полей в документе на детальное описание объектов.

  1. Номер объектного состояния (Object State No.): номер объекта, перед которым ставится буква «O» (Object - объект), уникально идентифицирующий объект.
  2. Имя объекта (Object Name):  в этой секции указывается имя объекта.
  3. Метка (Label): в этой секции указывается метка объекта (т.е. имя объекта, некоторая часть имени или аббревиатура).
  4. Факты (Facts): в этом поле указываются факты относительно экземпляров объекта.
  5. Ограничения (Constraints): в этом поле указываются ограничения на данный объект, т.е. факты, определяющие условия, которые должны действовать во всех экземплярах объекта.
  6. Описание (Description): это поле содержит статью глоссария (текстовое описание) для данного объекта. Как правило, статья глоссария представляет текстовое изложение информации, уже включенной в перечни объектов, фактов и ограничений.

 

Документ на детальное описание связей отношений используется для дальнейшей характеристики отношений между объектами и объектными состояниями в данной схематике объектов (кроме отношения «переходит в» (transitions-to)). На рис. 1.14 для примера приводится форма детального описания связей переходов состояний, используемая для этой цели.

 

Где

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

Аналитик:                    Дата:

Рабочий вариант

Рецензент:

Дата:

Проект:

Черновой вариант

 

Рекомендуемый вариант

Примечания:               Реценз:      

Выпущенный вариант

Номер связи

 

 

Имя отношения:

Тип отношения (первого порядка, второго порядка):

Включенные объекты и объектные состояния (т.е. аргументы):

Факты:

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

Описание:

Ссылка на установку контекста:

Описанный элемент:

Тип формы:

Детальное описание связей отношений

 

Рис. 1.14. Форма «Детальное описание связей отношений»