Файл: Методология функциональногомоделирования idef0Руководящий документ.pdf
Добавлен: 10.01.2024
Просмотров: 220
Скачиваний: 4
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
цен-
трализованную схему управления (управленческую «вертикаль»). Возмож- ны варианты структур, в которых выходная информация одного из блоков является управляющей для другого. Это отображает децентрализацию
управления («горизонтальные» связи) (см. Приложение 1) .
10.5 Типизация функциональных моделей и IDEF 0– диаграмм.
Эффективность и производительность труда разработчиков функциональ- ных моделей могут быть повышены за счет применения типовых моделей и отдельных диаграмм, ориентированных на применение в конкретных пред- метных областях. Так, например, на основе представлений о жизненном цик- ле продукции (изделия) можно предложить типовую диаграмму уровня А0
для промышленного предприятия, которая может иметь вид, схематически показанный на рис.41.
Рис. 41.
Фрагмент типовой модели промышленного предприятия в формате IDEF0
дан в Приложении 2 .
Сбор данных,
маркетинг
НИОКР, проекти- рование, испыта- ния, подготовка производства
Выпуск и реализация продукции
Сервис, ре- монт, анализ рекламаций
Настройка оргструкту- ры, подготовка кадров,
обновление оборудо- вания и т.д.
Управление
И
нформац ия
Материаль- ный поток
Финансы
РД IDEF0 - 2000 51
Аналогичные типовые модели могут быть разработаны для других видов бизнеса (оказание услуг, транспорт, банковское дело, финансовая деятель- ность и т.д.).
РД IDEF0 - 2000 52
11. Организация процесса функционального моделирова-
ния и управление проектом
11.1 Общие положения
Для эффективного моделирования и получения результатов в соответ- ствии со сроками и сметами управление проектом должно представлять со- бой процесс, в ходе которого координируется работа авторов, экспертов и тех, кто принимает окончательную версию модели системы или ее части.
Это должен быть процесс, в полной мере использующий возможности методологии, основанной на разделении функций участников проекта и ите- ративном характере рецензирования, в ходе которого проверяется коррект- ность диаграмм и/или моделей, а также соответствие их поставленной цели и точке зрения.
IDEF0–модель есть результат скоординированной коллективной рабо- ты, при которой авторы создают первоначальные диаграммы, основанные на собранной информации об объекте моделирования, и передают их другим участникам проекта для рассмотрения и формулирования замечаний. Поря- док, изложенный ниже, требует, чтобы каждый эксперт, у которого есть за- мечания к диаграмме, сделал их письменно и передал автору диаграммы.
Этот цикл продолжается до тех пор, пока диаграммы, а затем и вся модель не будут приняты. Процесс моделирования иллюстрируется рис. 42. Диаграмма отражает тот факт, что этот процесс - итеративная процедура, приводящая к точному описанию системы.
Используется в:
Контекст:
Узел:
Заголовок:
Номер:
Автор:
Проект:
Замечания: 1 2 3 4 5 6 7 8 9 10
Дата:
Версия:
Рабочая версия
Проект
Рекомендовано
Публикация
Читатель
Дата
Время:
Собирать информацию об объекте моделирования
A11
Создать модель в виде
IDEF0-диаграмм
A12
Вести библиотеку пректа
A13
Рецензировать
A14
Обсудить и принять
A15
Опыт и знания экспертов и источники информации
Опубликованная модель
Участники проекта
Источники информации
Авторы
Библиотекарь
Эксперт- рецензент
Технический совет и
Руководитель проекта
Цель проекта и соглашение по ведению проекта
Папки со статусом принятия диаграмм
Папки с комментариями
Напоминания о сроках
Папки с диаграммами модели
Папки с комментариями
Информация об объекте моделирования
Папки для рецензирования
Папки для обсуждения
Результаты рецензирования и обсуждения
Потребность в дополнительной информации
Знания экспертов
-рецензентов
Знания от источников информации
11:51 AM
24/12/99
Моделировать с использованием методологии IDEF0
1
x
РД по
моделированию
РД - стандарт
Прикладная логистика
11:12 AM
24/12/99 11:11 AM
None
24/12/99
A1
Рис.42.
РД IDEF0 - 2000 53
Ценность модели (проекта) определяется ее приемлемостью для экс- пертов.
Эта приемлемость достигается следующими путями:
1) постоянным рецензированием экспертами развивающейся модели,
что обеспечивает необходимый уровень соответствия модели кон- кретной моделируемому объекту (если модель отражает состояние
«как есть») или предполагаемому (состояние «как должно быть») в том понимании, которое соответствует мнению экспертов.
2) периодическим обсуждением диаграмм, частей модели и модели в целом на техническом совете, решение которого (оформленное в виде протокола) позволяет автору продолжить уточняющее модели- рование или закончить его ввиду достаточности детализации и при- емлемости проекта (модели).
Если в процессе моделирования выявляется несогласованность оценок экспертов, то такая несогласованность должна быть преодолена, чтобы полу- чить модель, представляющую объект моделирования или какую-то его часть адекватно.
Методология IDEF0 предусматривает необходимость сохранения запи- сей о всех решениях и альтернативных подходах по мере того, как они воз- никают на протяжении проекта.
Копии диаграмм, разработанные автором, критически (конструктивно)
анализируются компетентными экспертами, которые заносят свои замечания и предложения непосредственно на копиях диаграмм. Авторы отвечают на каждое замечание письменно на тех же копиях.
Предложения принимаются или отвергаются письменно с указанием причин. После внесения изменений и исправлений старые варианты диа- грамм остаются в архиве проекта.
В процессе чтения диаграмм ничто не должно предполагаться в модели по умолчанию, а также не должны делаться выводы, выходящие за пределы действия и утверждения модели. Это побуждает автора к тщательному ком- ментированию и иллюстрированию каждого добавляемого к модели фраг- мента, чтобы при чтении и интерпретации модели ее толкование было одно- значным и соответствующим поставленной цели и установленной точке зре- ния без личного присутствия автора и его дополнительных пояснений.
11.2
Состав участников проекта и структура их взаимодействия
В коллектив, занимающийся проектированием (моделированием),
должны входить следующие участники:
•
Руководитель проекта.
•
Авторы (разработчики) модели.
•
Технический совет
РД IDEF0 - 2000 54
•
Эксперты в предметной области.
•
Библиотекарь.
Дополнительныйспецифическийучастник проекта - "Источники информа-
ции".
При проведении работ с привлечением сторонних организаций может создаваться
Координационный совет
, обеспечивающий взаимодействие всех участников проекта, работающих как в составе проектирующей органи- зации, так и вне ее. Выполняемая функция («роль», которую выполняет уча- стник проекта) не зависит от должности. Один и тот же человек может вы- полнять несколько функций. Однако «роль» каждого участника проекта ин- дивидуальна, должна быть определена и зависит от рассматриваемой части проекта. Структура взаимодействия участников проекта приведена на рис.43.
Руководитель проекта
Palette1
Библиотекарь проекта
Palette2
Авторы
Palette3
Эксперты- рецензенты и
Эксперты- читатели
Palette4
Технический совет
Palette5
Источники информации об объекте моделирования
Palette6
Ďŕďęč ń ěîäĺë˙ěč
Ďŕďęč ń đĺöĺíçč˙ěč
Ďŕďęč ń ěîäĺë˙ěč
Ďŕďęč ń đĺöĺíçč˙ěč
Ďŕďęč ń
ěîäĺë˙ěč
äë
˙
îá
ńóćäĺíč˙
Đĺçóëüňŕňű
îá
ńóćäĺíč˙
Ďđĺäëîćĺíč˙
ďî
ó
ńňŕíîâëĺíčţ
ńňŕňóńŕ ďŕďęč (ěîäĺëč)
Ó
ńňŕíîâëĺííűé
ńňŕňóń
Číôîđěŕöč˙
îá
îáú
ĺęňĺ
ěîäĺëčđîâŕíč˙
Рис.43
Принципы коллективной работы в IDEF0 – методологии гарантируют,
что окончательная версия IDEF0 – модели будет верной, так как модель кор- ректируется по результатам рецензирования частей модели, оформленных в виде папок. Более подробная детализация достигается построением необхо- димого количества диаграмм. По новым частям модели делаются новые за- мечания, вносятся новые изменения. Окончательная модель соответствует представлениям автора и экспертов о системе, смоделированной с данной точки зрения и для данной цели.
Руководитель проекта и разработчики модели (авторы) должны быть
РД IDEF0 - 2000 55
главными исполнителями. Хотя конечной целью разработчика является по- лучение одобрения модели техническим советом, утверждает результаты руководитель проекта. Таким образом, обеспечивается согласованность ин- тересов авторов, рецензентов, совета и руководителя проекта.
11.2.1 Руководитель проекта
Руководитель проекта - лицо, осуществляющее административное управление проектом. Руководитель проекта должен выполнять при модели- ровании следующие основные функции:
•
Выбирать разработчиков модели (авторов). Главным аспектом дан- ной функции является достижение руководителем проекта и разра- ботчиком модели согласия относительно основополагающих пра- вил, в соответствии с которыми выполняется моделирование. Сюда входят использование методологии, степень контроля за разработ- чиком модели со стороны руководителя проекта, область действия и ориентация разрабатываемой модели.
•
Определять обязательные источники информации, на которые раз- работчик модели будет опираться при построении модели. Этими источниками могут быть либо люди, осведомленные о различных аспектах рассматриваемой сферы деятельности, либо документы,
освещающие предметную область моделирования. Эти источники определяются на начальной стадии моделирования, но список их в процессе моделирования должен пересматриваться и уточняться,
поскольку по мере построения модели потребности в информации меняются.
•
Выбирать экспертов, чьи знания будут использованы разработчиком для получения оценки (одобрения) диаграмм и частей модели.. Спи- сок экспертов составляется на начальной стадии проекта и уточня- ется по мере необходимости.
•
Формировать технический совет. Руководитель проекта. – неизби- раемый председатель технического совета. Этот совет под его пред- седательством периодически собирается для обсуждения сущест- венных вопросов, рецензирования и определения статуса модели и ее частей.
•
Присваивать статус рассматриваемой советом части модели.
11.2.2 Разработчики (авторы) модели
Разработчики (авторы) модели - лица, создающие IDEF0 –модели. Разра-
РД IDEF0 - 2000 56
ботчик создает модель на основе материала, собранного из источников ин- формации.
Разработчик должен:
•
собирать исходные данные от обязательных источников информа- ции, определенных руководителем проекта; при недостаточности собранных сведений автор вправе использовать любые другие ис- точники информации с обязательным указанием ссылок на них;
•
обучать (при необходимости) основам IDEF0-моделирования руко- водителя проекта, экспертов (рецензентов и читателей) и других членов технического совета для обеспечения правильного понима- ния ими моделей, создаваемых авторами;
•
оформлять модель в виде IDEF0-диаграмм;
•
организовывать разработку модели.
В период подготовки проекта разработчик вместе с руководителем проекта изучает и устанавливает область действия модели. Затем он намечает план проекта, т.е. состав и последовательность работ, которые необходимо выполнить для достижения поставленных целей.
Руководитель проекта обеспечивает разработчика списком источников информации и списком экспертов, к которым разработчик может обратиться.
Разработчик должен удостовериться, что со всеми участниками проекта ус- тановлен необходимый контакт.
Исходную информацию разработчик собирает из источников, установ- ленных руководителем проекта. Природа этой информации во многом зави- сит от стадии разработки модели. Источниками информации могут служить люди и документы. Разработчик должен понимать, что каждый эксперт- источник информации смотрит на информацию со своей точки зрения. Раз- работчик должен стараться увидеть глазами источника информации ее смысл и структуру. Синтезируя эти точки зрения в процессе сравнения и противо- поставления, разработчик создает образ изучаемого объекта моделирования.
Второй функцией разработчика является помощь в технике моделиро- вания всем, кому она может понадобиться. Эта помощь заключается в общем ориентировании членов технического совета, источников информации и экс- пертов, ознакомлении их с навыками чтения модели, а также с навыками моделирования.
Третьей функцией является оформление модели в виде IDEF0- диаграмм. Для рецензирования он оформляет папки с диаграммами для пере- дачи их в библиотеку проекта.
Разработчик организует построение модели. Для поддержки принятых разработчиком решений и регистрации вклада каждого участника записи исходной информации, собранной в процессе моделирования, сохраняются
РД IDEF0 - 2000 57
в течение определенного времени после завершения проекта. Это позволяет разработчику следить за тем, чтобы исследуемая область была охвачена со всех сторон. Зная, кто и в каких областях поставлял информацию, и как это происходило, разработчик может оценить степень соответствия стадии моде- лирования исходным целям.
11.2.3 Технический совет
Это элемент организации процесса создания моделей, предлагающий арбитражные решения по моделированию и рекомендации по установлению статуса диаграмм, части и/или модели в целом (статусы: "Рабочий проект",
«Эскиз», «Рекомендовано» и Публикация»).
Технический совет проводит политику проекта через рекомендации и замечания авторам, предложения по установлению статуса руководителю проекта и подготовку компромиссных решений для разрешения конфликтов,
которые могут возникнуть в процессе проекта. В техническом совете должно быть несколько специалистов с высоким уровнем компетентности способных отстоять свои решения перед высшим руководством объекта моделирования.
Технический совет формируется из экспертов и профессионалов, зна- комых с предметной областью моделирования. Руководитель проекта фор- мирует этот совет и является его председателем. Поскольку основной причи- ной, побуждающей создавать модель, является необходимость повышения эффективности объекта моделирования, важно, чтобы в совете были пред- ставлены все службы , имеющие отношение к рассматриваемой в проекте предметной области. Полезно включать в совет экспертов из смежных облас- тей объекта моделирования, не входящих в исследуемую область, но связан- ных с ней. Эти эксперты помогают адекватно оценить влияние окружающей среды на объект моделирования.
Эксперты могут быть членами совета. Эксперту обычно показывают только ограниченные фрагменты модели на промежуточных стадиях, в то время как совет должен принять решение по всей модели. Иногда в совет могут входить лица, играющие роль источников. В силу очевидной противо- речивости интересов нецелесообразно, чтобы в совет входили разработчики модели.
11.2.4 Эксперт
Эксперт - выбираемое руководителем проекта лицо, обладающее спе- циальными знаниями некоторых аспектов моделируемой области. Его опыт в предметной области, к которой относится моделируемый объект, позволяет делать полезные критические замечания в процессе создания модели.
Эксперты призваны критически оценивать создаваемую по частям мо- дель. Это осуществляется в ходе нескольких циклов изучения с использова- нием читательских папок (цикл автор/читатель). Папки обеспечивают экс-
трализованную схему управления (управленческую «вертикаль»). Возмож- ны варианты структур, в которых выходная информация одного из блоков является управляющей для другого. Это отображает децентрализацию
управления («горизонтальные» связи) (см. Приложение 1) .
10.5 Типизация функциональных моделей и IDEF 0– диаграмм.
Эффективность и производительность труда разработчиков функциональ- ных моделей могут быть повышены за счет применения типовых моделей и отдельных диаграмм, ориентированных на применение в конкретных пред- метных областях. Так, например, на основе представлений о жизненном цик- ле продукции (изделия) можно предложить типовую диаграмму уровня А0
для промышленного предприятия, которая может иметь вид, схематически показанный на рис.41.
Рис. 41.
Фрагмент типовой модели промышленного предприятия в формате IDEF0
дан в Приложении 2 .
Сбор данных,
маркетинг
НИОКР, проекти- рование, испыта- ния, подготовка производства
Выпуск и реализация продукции
Сервис, ре- монт, анализ рекламаций
Настройка оргструкту- ры, подготовка кадров,
обновление оборудо- вания и т.д.
Управление
И
нформац ия
Материаль- ный поток
Финансы
РД IDEF0 - 2000 51
Аналогичные типовые модели могут быть разработаны для других видов бизнеса (оказание услуг, транспорт, банковское дело, финансовая деятель- ность и т.д.).
РД IDEF0 - 2000 52
11. Организация процесса функционального моделирова-
ния и управление проектом
11.1 Общие положения
Для эффективного моделирования и получения результатов в соответ- ствии со сроками и сметами управление проектом должно представлять со- бой процесс, в ходе которого координируется работа авторов, экспертов и тех, кто принимает окончательную версию модели системы или ее части.
Это должен быть процесс, в полной мере использующий возможности методологии, основанной на разделении функций участников проекта и ите- ративном характере рецензирования, в ходе которого проверяется коррект- ность диаграмм и/или моделей, а также соответствие их поставленной цели и точке зрения.
IDEF0–модель есть результат скоординированной коллективной рабо- ты, при которой авторы создают первоначальные диаграммы, основанные на собранной информации об объекте моделирования, и передают их другим участникам проекта для рассмотрения и формулирования замечаний. Поря- док, изложенный ниже, требует, чтобы каждый эксперт, у которого есть за- мечания к диаграмме, сделал их письменно и передал автору диаграммы.
Этот цикл продолжается до тех пор, пока диаграммы, а затем и вся модель не будут приняты. Процесс моделирования иллюстрируется рис. 42. Диаграмма отражает тот факт, что этот процесс - итеративная процедура, приводящая к точному описанию системы.
Используется в:
Контекст:
Узел:
Заголовок:
Номер:
Автор:
Проект:
Замечания: 1 2 3 4 5 6 7 8 9 10
Дата:
Версия:
Рабочая версия
Проект
Рекомендовано
Публикация
Читатель
Дата
Время:
Собирать информацию об объекте моделирования
A11
Создать модель в виде
IDEF0-диаграмм
A12
Вести библиотеку пректа
A13
Рецензировать
A14
Обсудить и принять
A15
Опыт и знания экспертов и источники информации
Опубликованная модель
Участники проекта
Источники информации
Авторы
Библиотекарь
Эксперт- рецензент
Технический совет и
Руководитель проекта
Цель проекта и соглашение по ведению проекта
Папки со статусом принятия диаграмм
Папки с комментариями
Напоминания о сроках
Папки с диаграммами модели
Папки с комментариями
Информация об объекте моделирования
Папки для рецензирования
Папки для обсуждения
Результаты рецензирования и обсуждения
Потребность в дополнительной информации
Знания экспертов
-рецензентов
Знания от источников информации
11:51 AM
24/12/99
Моделировать с использованием методологии IDEF0
1
x
РД по
моделированию
РД - стандарт
Прикладная логистика
11:12 AM
24/12/99 11:11 AM
None
24/12/99
A1
Рис.42.
РД IDEF0 - 2000 53
Ценность модели (проекта) определяется ее приемлемостью для экс- пертов.
Эта приемлемость достигается следующими путями:
1) постоянным рецензированием экспертами развивающейся модели,
что обеспечивает необходимый уровень соответствия модели кон- кретной моделируемому объекту (если модель отражает состояние
«как есть») или предполагаемому (состояние «как должно быть») в том понимании, которое соответствует мнению экспертов.
2) периодическим обсуждением диаграмм, частей модели и модели в целом на техническом совете, решение которого (оформленное в виде протокола) позволяет автору продолжить уточняющее модели- рование или закончить его ввиду достаточности детализации и при- емлемости проекта (модели).
Если в процессе моделирования выявляется несогласованность оценок экспертов, то такая несогласованность должна быть преодолена, чтобы полу- чить модель, представляющую объект моделирования или какую-то его часть адекватно.
Методология IDEF0 предусматривает необходимость сохранения запи- сей о всех решениях и альтернативных подходах по мере того, как они воз- никают на протяжении проекта.
Копии диаграмм, разработанные автором, критически (конструктивно)
анализируются компетентными экспертами, которые заносят свои замечания и предложения непосредственно на копиях диаграмм. Авторы отвечают на каждое замечание письменно на тех же копиях.
Предложения принимаются или отвергаются письменно с указанием причин. После внесения изменений и исправлений старые варианты диа- грамм остаются в архиве проекта.
В процессе чтения диаграмм ничто не должно предполагаться в модели по умолчанию, а также не должны делаться выводы, выходящие за пределы действия и утверждения модели. Это побуждает автора к тщательному ком- ментированию и иллюстрированию каждого добавляемого к модели фраг- мента, чтобы при чтении и интерпретации модели ее толкование было одно- значным и соответствующим поставленной цели и установленной точке зре- ния без личного присутствия автора и его дополнительных пояснений.
11.2
Состав участников проекта и структура их взаимодействия
В коллектив, занимающийся проектированием (моделированием),
должны входить следующие участники:
•
Руководитель проекта.
•
Авторы (разработчики) модели.
•
Технический совет
РД IDEF0 - 2000 54
•
Эксперты в предметной области.
•
Библиотекарь.
Дополнительныйспецифическийучастник проекта - "Источники информа-
ции".
При проведении работ с привлечением сторонних организаций может создаваться
Координационный совет
, обеспечивающий взаимодействие всех участников проекта, работающих как в составе проектирующей органи- зации, так и вне ее. Выполняемая функция («роль», которую выполняет уча- стник проекта) не зависит от должности. Один и тот же человек может вы- полнять несколько функций. Однако «роль» каждого участника проекта ин- дивидуальна, должна быть определена и зависит от рассматриваемой части проекта. Структура взаимодействия участников проекта приведена на рис.43.
Руководитель проекта
Palette1
Библиотекарь проекта
Palette2
Авторы
Palette3
Эксперты- рецензенты и
Эксперты- читатели
Palette4
Технический совет
Palette5
Источники информации об объекте моделирования
Palette6
Ďŕďęč ń ěîäĺë˙ěč
Ďŕďęč ń đĺöĺíçč˙ěč
Ďŕďęč ń ěîäĺë˙ěč
Ďŕďęč ń đĺöĺíçč˙ěč
Ďŕďęč ń
ěîäĺë˙ěč
äë
˙
îá
ńóćäĺíč˙
Đĺçóëüňŕňű
îá
ńóćäĺíč˙
Ďđĺäëîćĺíč˙
ďî
ó
ńňŕíîâëĺíčţ
ńňŕňóńŕ ďŕďęč (ěîäĺëč)
Ó
ńňŕíîâëĺííűé
ńňŕňóń
Číôîđěŕöč˙
îá
îáú
ĺęňĺ
ěîäĺëčđîâŕíč˙
Рис.43
Принципы коллективной работы в IDEF0 – методологии гарантируют,
что окончательная версия IDEF0 – модели будет верной, так как модель кор- ректируется по результатам рецензирования частей модели, оформленных в виде папок. Более подробная детализация достигается построением необхо- димого количества диаграмм. По новым частям модели делаются новые за- мечания, вносятся новые изменения. Окончательная модель соответствует представлениям автора и экспертов о системе, смоделированной с данной точки зрения и для данной цели.
Руководитель проекта и разработчики модели (авторы) должны быть
РД IDEF0 - 2000 55
главными исполнителями. Хотя конечной целью разработчика является по- лучение одобрения модели техническим советом, утверждает результаты руководитель проекта. Таким образом, обеспечивается согласованность ин- тересов авторов, рецензентов, совета и руководителя проекта.
11.2.1 Руководитель проекта
Руководитель проекта - лицо, осуществляющее административное управление проектом. Руководитель проекта должен выполнять при модели- ровании следующие основные функции:
•
Выбирать разработчиков модели (авторов). Главным аспектом дан- ной функции является достижение руководителем проекта и разра- ботчиком модели согласия относительно основополагающих пра- вил, в соответствии с которыми выполняется моделирование. Сюда входят использование методологии, степень контроля за разработ- чиком модели со стороны руководителя проекта, область действия и ориентация разрабатываемой модели.
•
Определять обязательные источники информации, на которые раз- работчик модели будет опираться при построении модели. Этими источниками могут быть либо люди, осведомленные о различных аспектах рассматриваемой сферы деятельности, либо документы,
освещающие предметную область моделирования. Эти источники определяются на начальной стадии моделирования, но список их в процессе моделирования должен пересматриваться и уточняться,
поскольку по мере построения модели потребности в информации меняются.
•
Выбирать экспертов, чьи знания будут использованы разработчиком для получения оценки (одобрения) диаграмм и частей модели.. Спи- сок экспертов составляется на начальной стадии проекта и уточня- ется по мере необходимости.
•
Формировать технический совет. Руководитель проекта. – неизби- раемый председатель технического совета. Этот совет под его пред- седательством периодически собирается для обсуждения сущест- венных вопросов, рецензирования и определения статуса модели и ее частей.
•
Присваивать статус рассматриваемой советом части модели.
11.2.2 Разработчики (авторы) модели
Разработчики (авторы) модели - лица, создающие IDEF0 –модели. Разра-
РД IDEF0 - 2000 56
ботчик создает модель на основе материала, собранного из источников ин- формации.
Разработчик должен:
•
собирать исходные данные от обязательных источников информа- ции, определенных руководителем проекта; при недостаточности собранных сведений автор вправе использовать любые другие ис- точники информации с обязательным указанием ссылок на них;
•
обучать (при необходимости) основам IDEF0-моделирования руко- водителя проекта, экспертов (рецензентов и читателей) и других членов технического совета для обеспечения правильного понима- ния ими моделей, создаваемых авторами;
•
оформлять модель в виде IDEF0-диаграмм;
•
организовывать разработку модели.
В период подготовки проекта разработчик вместе с руководителем проекта изучает и устанавливает область действия модели. Затем он намечает план проекта, т.е. состав и последовательность работ, которые необходимо выполнить для достижения поставленных целей.
Руководитель проекта обеспечивает разработчика списком источников информации и списком экспертов, к которым разработчик может обратиться.
Разработчик должен удостовериться, что со всеми участниками проекта ус- тановлен необходимый контакт.
Исходную информацию разработчик собирает из источников, установ- ленных руководителем проекта. Природа этой информации во многом зави- сит от стадии разработки модели. Источниками информации могут служить люди и документы. Разработчик должен понимать, что каждый эксперт- источник информации смотрит на информацию со своей точки зрения. Раз- работчик должен стараться увидеть глазами источника информации ее смысл и структуру. Синтезируя эти точки зрения в процессе сравнения и противо- поставления, разработчик создает образ изучаемого объекта моделирования.
Второй функцией разработчика является помощь в технике моделиро- вания всем, кому она может понадобиться. Эта помощь заключается в общем ориентировании членов технического совета, источников информации и экс- пертов, ознакомлении их с навыками чтения модели, а также с навыками моделирования.
Третьей функцией является оформление модели в виде IDEF0- диаграмм. Для рецензирования он оформляет папки с диаграммами для пере- дачи их в библиотеку проекта.
Разработчик организует построение модели. Для поддержки принятых разработчиком решений и регистрации вклада каждого участника записи исходной информации, собранной в процессе моделирования, сохраняются
РД IDEF0 - 2000 57
в течение определенного времени после завершения проекта. Это позволяет разработчику следить за тем, чтобы исследуемая область была охвачена со всех сторон. Зная, кто и в каких областях поставлял информацию, и как это происходило, разработчик может оценить степень соответствия стадии моде- лирования исходным целям.
11.2.3 Технический совет
Это элемент организации процесса создания моделей, предлагающий арбитражные решения по моделированию и рекомендации по установлению статуса диаграмм, части и/или модели в целом (статусы: "Рабочий проект",
«Эскиз», «Рекомендовано» и Публикация»).
Технический совет проводит политику проекта через рекомендации и замечания авторам, предложения по установлению статуса руководителю проекта и подготовку компромиссных решений для разрешения конфликтов,
которые могут возникнуть в процессе проекта. В техническом совете должно быть несколько специалистов с высоким уровнем компетентности способных отстоять свои решения перед высшим руководством объекта моделирования.
Технический совет формируется из экспертов и профессионалов, зна- комых с предметной областью моделирования. Руководитель проекта фор- мирует этот совет и является его председателем. Поскольку основной причи- ной, побуждающей создавать модель, является необходимость повышения эффективности объекта моделирования, важно, чтобы в совете были пред- ставлены все службы , имеющие отношение к рассматриваемой в проекте предметной области. Полезно включать в совет экспертов из смежных облас- тей объекта моделирования, не входящих в исследуемую область, но связан- ных с ней. Эти эксперты помогают адекватно оценить влияние окружающей среды на объект моделирования.
Эксперты могут быть членами совета. Эксперту обычно показывают только ограниченные фрагменты модели на промежуточных стадиях, в то время как совет должен принять решение по всей модели. Иногда в совет могут входить лица, играющие роль источников. В силу очевидной противо- речивости интересов нецелесообразно, чтобы в совет входили разработчики модели.
11.2.4 Эксперт
Эксперт - выбираемое руководителем проекта лицо, обладающее спе- циальными знаниями некоторых аспектов моделируемой области. Его опыт в предметной области, к которой относится моделируемый объект, позволяет делать полезные критические замечания в процессе создания модели.
Эксперты призваны критически оценивать создаваемую по частям мо- дель. Это осуществляется в ходе нескольких циклов изучения с использова- нием читательских папок (цикл автор/читатель). Папки обеспечивают экс-