<На страницу назад | На страницу вперед>
4.5.1 Разработка схематик процессов
Схематики процессов обеспечивают процессо-центрированное представление процесса.
Эти схематики обеспечивают организацию знаний о процессах таким образом,
что в центре внимания находятся процессы и их временные, причинно-и логические
отношения в рамках контекста определенного сценария.
Построение схематики процессов включает следующие шаги:
Идентификация UOB
После завершения начальной работы по сбору данных аналитик должен иметь
списки представляющих интерес объектов, работ, фактов и ограничений. При
использовании этих данных и описаний ситуаций аналитик идентифицирует все
UOB и начинает разрабатывать общую структуру схематик IDEF3.
Исходное основание этой работы определяется при установке контекста проекта, когда аналитик должен идентифицировать представляющие интерес сценарии. Для каждого идентифицированного сценария разрабатывается как минимум одна схематика процессов. Сценарий, используемый в качестве контекста для данной схематики процессов, определяет границы поиска возможных UOB аналитиком.
Идентификация UOB представляет умственную классификационную работу, в которой для идентификации и уточнения возможного набора UOB используется знание парадигмы IDEF3 и фактов, полученных от специалиста по предметной области. Для выполнения этого процесса аналитику следует "настроиться" на то, как люди описывают процессы. При сборе описаний "того, что происходит" в рамках организации или любой сложной системы, должны учитываться понятия на естественном языке. Для описания "того, что происходит в мире" используется каждое из приведенных ниже понятий на повседневном языке:
1. Функция |
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.
Для облегчения сбора логики принятия решений для определенного перехода документ на детальное описание может быть прикреплен к данному переходу в схематике процессов, как показано на рис. 4-7.
Аналитик: Дата: |
x | Рабочий вариант | Рецензент: | Дата: | |
Где |
Проект: | Черновой вариант | |||
Рекомендуемый вариант | |||||
Примечания: Реценз.: |
Выпущенный вариант | ||||
Номер перехода |
Тип перехода Объекты: Факты: Ограничения: Описание: |
||||
Номер перехода |
Тип перехода Объекты: Факты: Ограничения: Описание: |
||||
Ссылка на установку контекста: | Описанный элемент: |
Тип формы: Детальное описание переходов |
Рис. 4-7
Форма "Детальное описание переходов"
Базовые поля (ядро) в документе на детальное описание переходов:
Особые ограничения, определяемые ограниченными связями предшествования, регистрируются в документе на детальное описание связей предшествования (рис. 4-8). По формату и назначению этот документ подобен детальному описанию UOB.
Аналитик: Дата: |
x | Рабочий вариант | Рецензент: | Дата: | |
Где |
Проект: | Черновой вариант | |||
Рекомендуемый вариант | |||||
Примечания: Реценз.: |
Выпущенный вариант | ||||
Номер связи |
Номер маршрута: Источник: |
Адресат: | |||
Объекты: Факты: Ограничения: Описание: |
|||||
Ссылка на установку контекста: | Описанный элемент: |
Тип формы: Детальное описание связей предшествования |
Рис. 4-8
Форма "Детальное описание связей предшествования"
Основное содержание документа на детальное описание связей предшествования:
Объекты, факты и ограничения, уникально ассоциированные с определенной связью, должны быть идентифицированы соответствующим образом.
Особые ограничения, представляемые пунктирными связями, регистрируются в документе на спецификацию пунктирных связей (рис. 4-9).
Аналитик: Дата: |
x | Рабочий вариант | Рецензент: | Дата: | |
Где |
Проект: | Черновой вариант | |||
Рекомендуемый вариант | |||||
Примечания: Реценз.: |
Выпущенный вариант | ||||
Номер связи |
Источник: Адресат: Объекты: Факты: Ограничения: Описание: |
||||
Ссылка на установку контекста: | Описанный элемент: |
Тип формы: Детальное описание пунктирных связей |
Рис. 4-9
Форма "Детальное описание пунктирных связей"
Основное содержание документа на детальное описание пунктирных связей:
Разработка декомпозиций для выбранных единиц поведения
(UOB)
Декомпозиция определенной UOB представляет набор других UOB, обеспечивающий
дополнительные детали процесса, представляемого родительской UOB, с использованием
определенной перспективы. Как правило, UOB на уровне сценариев имеют декомпозиции.
В свою очередь, UOB, входящие в эти декомпозиции, также могут быть декомпозированы.
Обычно разные декомпозиции являются результатом разных точек зрения специалистов
по предметной области на то, что происходит при выполнении определенной
работы. Разные декомпозиции также могут быть результатом абстрагирования
представления процесса с точки зрения некоторого участвующего объекта. Например,
представление в виде декомпозиции можно создать для представления шагов
обработки, требуемых в информационной системе для поддержки организационной
работы. Наконец, декомпозиции могут быть созданы аналитиком для выбранных
UOB с целью упрощения схематики. Декомпозиции представляют схематики, обеспечивающие
более детализированное представление или разные перспективы рассмотрения
определенного процесса с четко определенной точкой зрения. Декомпозиции
часто разрабатываются для сбора альтернативных представлений одного процесса
или для упрощения схематики описаний процессов.
Как и разработка описаний IDEF3, процесс разработки декомпозиций представляет процесс уточнения. Разработка декомпозиций повторяет ту же процедуру, которая используется для разработки первичного описания. Этот цикл уточнения включает следующие работы: (1) анализ работы; (2) сбор дополнительных данных; (3) описание ситуаций в терминах связанных UOB; (4) проверка; (5) возврат на предыдущий шаг процедуры, если в этом есть необходимость.