Роль комитета рецензирования и одобрения

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

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

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

 

Сбор исходной информации

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

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

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

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

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

Как отмечалось в разделе 2, целью моделирования данных является определение единого, согласованного в рамках всего предприятия взгляда на ресурсы данных, что в архитектуре ANSI/SPARC называется концептуальной схемой. Исходные документы, по большей части, представляют либо внешнюю, либо внутреннюю схемы, соответствующие концептуальной схеме, но более ориентированные на практическое использование. Пользовательские отчеты, например, являются представлением данных из внешней схемы и могут служить исходной документацией. Описания файлов и проекты баз данных соответствуют представлениям данных из внутренней схемы и также могут использоваться в качестве исходной документации. Хотя в процессе моделирования структура данных существенно меняется, окончательная модель должна по-прежнему соответствовать внутренней и внешней схеме, на основе которых она построена.

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

 

Авторские соглашения

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

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

1. Авторские соглашения не являются формальными расширениями методологии.
2. Авторские соглашения не должны противоречить методологии.

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

 

Стадия 1 - определение сущностей

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

 

Идентификация сущностей

"Сущность" представляет в контексте IDEFlX-модели множество "предметов", обладающих связанными с ними данными. Здесь "предмет" может быть отдельной физической субстанцией, событием, состоянием, действием, идеей, понятием, точкой, местом и т.д. Элементы представляемого сущностью множества обладают общим набором атрибутов или характеристик. Например, все элементы множества служащих обладают номером служащего, фамилией и другими общими атрибутами. Отдельный элемент множества сущности называется экземпляром сущности. Например, служащий с именем Джерри и номером 789 является экземпляром сущности В СЛУЖАЩИЙ. Сущности всегда именуются общими существительными в единственном числе. Они должны иметь атрибут (ключ), однозначно идентифицирующий каждый из их экземпляров.

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

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

Сущность образуется в результате объединения основных экземпляров сущности, становящихся элементами этой сущности. Это означает, что некоторое количество экземпляров сущности, у которых все характеристики однотипны, представляется в качестве сущности. Такая концепция приведена на рис. 4-2. Каждый экземпляр сущности является элементом сущности, обладающим однотипной определяющей информацией.

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

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

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

Экземпляры сущностей

Рис. 4-2. "Синтезированные" сущности

При построении пула сущностей разработчик присваивает каждой записи свой идентифицирующий номер и записывает ссылку на ее источник. Таким образом поддерживается возможность отслеживания информации. Целостность пула остается ненарушенной, а управление пула - сравнительно легким. Пример пула сущностей показан на рис.4-3.

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

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

Номер	Имя сущности	Номер источника
Е-1	Платежное требование
Е-2	Расходный ордер
Е-3	Приходный ордер
Е-4	Реестр платежных поручений
Е-5	Смета
Е-6	Личная карточка сотрудника
Е-7	Ведомость на выдачу зарплаты
Е-8	Журнал учета больничных листов
Е-9	Сотрудник
Е-10	Квалификация сотрудника
Е-11	Отдел
Е-12	Филиал
Е-13	Журнал дежурного
Е-14	Счет
Е-15	Рабочая карта
Е-16	График мастера
Е-17	Материалы
Е-18	Доступность материалов
Е-19	Оборудование для обработки материалов
Е-20	Требования к материалам

Рис. 4-3. Пул сущностей

 

Определение сущностей

Еще одним результатом стадии 1 является начало работы над глоссарием сущностей. На протяжении этой стадии глоссарий представляет собой просто набор определений сущностей.

Определение сущности включает следующие компоненты:

ИМЯ СУЩНОСТИ

Имя сущности является уникальным именем, с помощью которого сущность будет распознаваться в IDEFlX-модели. Оно должно быть описательным. Хотя допускаются аббревиатуры и акронимы, имя сущности должно быть осмысленным.

ОПРЕДЕЛЕНИЕ СУЩНОСТИ

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

СИНОНИМЫ СУЩНОСТИ

Это список других имен, под которыми сущность может быть известна. Единственным относящимся к этому правилом является то, что определение, связанное с именем сущности, должно в точности применяться к каждому из синонимов в списке.

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

 

⇐ Предыдущая17181920212223242526Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: