Организационная структура коллектива разработчиков

⇐ ПредыдущаяСтр 16 из 26Следующая ⇒

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

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

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

Менеджер проекта.
Разработчик.
Источники информации.
Эксперты в данной предметной области.
Комитет рецензирования и одобрения.

Целью распределения ролей является разграничение ответственности. Все эти роли определяются на последующих страницах.

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

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

Рис. 4-1. Организационная структура коллектива разработчиков

Роль менеджера проекта

Менеджер проекта является лицом, осуществляющим административное управление проектом моделирования. Менеджер проекта выполняет при моделировании четыре основных функции.

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

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

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

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

Роль разработчика модели

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

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

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

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

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

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

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

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

Роль источников информации

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

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

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

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

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

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

Роль эксперта

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

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

Главной задачей эксперта является оценка точности модели. Экспертная оценка является основным средством в достижении консенсуса среди изучающих модель экспертов. Одобренная модель - это модель, согласованная с экспертами. Заметим, что одобренная модель не обязательно является " верной". Если большинство экспертов согласны с тем, что модель адекватно и полностью представляет рассматриваемую сферу, то модель считается одобренной. Если есть несогласившиеся с этим, то их мнение обязательно фиксируется, и модель считается неправильной, пока не доказано обратное. Вот почему участие экспертов так важно для моделирования. Когда разработчик строит первоначальную часть модели, он говорит: " Я просмотрел факты и сделал следующие выводы...". Когда эта часть модели представляется на рассмотрение экспертам, разработчик спрашивает: " Прав ли я? " Для достижения консенсуса комментарии экспертов учитываются при пересмотре той части модели, с которой они не согласны.

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

⇐ Предыдущая 11 12 13 14 151617 18 19 20 Следующая ⇒