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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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