ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 05.12.2019
Просмотров: 3905
Скачиваний: 6
РД
IDEF0 - 2000
56
ботчик
создает
модель
на
основе
материала
,
собранного
из
источников
ин
-
формации
.
Разработчик
должен
:
•
собирать
исходные
данные
от
обязательных
источников
информа
-
ции
,
определенных
руководителем
проекта
;
при
недостаточности
собранных
сведений
автор
вправе
использовать
любые
другие
ис
-
точники
информации
с
обязательным
указанием
ссылок
на
них
;
•
обучать
(
при
необходимости
)
основам
IDEF0-
моделирования
руко
-
водителя
проекта
,
экспертов
(
рецензентов
и
читателей
)
и
других
членов
технического
совета
для
обеспечения
правильного
понима
-
ния
ими
моделей
,
создаваемых
авторами
;
•
оформлять
модель
в
виде
IDEF0-
диаграмм
;
•
организовывать
разработку
модели
.
В
период
подготовки
проекта
разработчик
вместе
с
руководителем
проекта
изучает
и
устанавливает
область
действия
модели
.
Затем
он
намечает
план
проекта
,
т
.
е
.
состав
и
последовательность
работ
,
которые
необходимо
выполнить
для
достижения
поставленных
целей
.
Руководитель
проекта
обеспечивает
разработчика
списком
источников
информации
и
списком
экспертов
,
к
которым
разработчик
может
обратиться
.
Разработчик
должен
удостовериться
,
что
со
всеми
участниками
проекта
ус
-
тановлен
необходимый
контакт
.
Исходную
информацию
разработчик
собирает
из
источников
,
установ
-
ленных
руководителем
проекта
.
Природа
этой
информации
во
многом
зави
-
сит
от
стадии
разработки
модели
.
Источниками
информации
могут
служить
люди
и
документы
.
Разработчик
должен
понимать
,
что
каждый
эксперт
-
источник
информации
смотрит
на
информацию
со
своей
точки
зрения
.
Раз
-
работчик
должен
стараться
увидеть
глазами
источника
информации
ее
смысл
и
структуру
.
Синтезируя
эти
точки
зрения
в
процессе
сравнения
и
противо
-
поставления
,
разработчик
создает
образ
изучаемого
объекта
моделирования
.
Второй
функцией
разработчика
является
помощь
в
технике
моделиро
-
вания
всем
,
кому
она
может
понадобиться
.
Эта
помощь
заключается
в
общем
ориентировании
членов
технического
совета
,
источников
информации
и
экс
-
пертов
,
ознакомлении
их
с
навыками
чтения
модели
,
а
также
с
навыками
моделирования
.
Третьей
функцией
является
оформление
модели
в
виде
IDEF0-
диаграмм
.
Для
рецензирования
он
оформляет
папки
с
диаграммами
для
пере
-
дачи
их
в
библиотеку
проекта
.
Разработчик
организует
построение
модели
.
Для
поддержки
принятых
разработчиком
решений
и
регистрации
вклада
каждого
участника
записи
исходной
информации
,
собранной
в
процессе
моделирования
,
сохраняются
РД
IDEF0 - 2000
57
в
течение
определенного
времени
после
завершения
проекта
.
Это
позволяет
разработчику
следить
за
тем
,
чтобы
исследуемая
область
была
охвачена
со
всех
сторон
.
Зная
,
кто
и
в
каких
областях
поставлял
информацию
,
и
как
это
происходило
,
разработчик
может
оценить
степень
соответствия
стадии
моде
-
лирования
исходным
целям
.
11
.2.3
Технический
совет
Это
элемент
организации
процесса
создания
моделей
,
предлагающий
арбитражные
решения
по
моделированию
и
рекомендации
по
установлению
статуса
диаграмм
,
части
и
/
или
модели
в
целом
(
статусы
: "
Рабочий
проект
",
«
Эскиз
», «
Рекомендовано
»
и
Публикация
»).
Технический
совет
проводит
политику
проекта
через
рекомендации
и
замечания
авторам
,
предложения
по
установлению
статуса
руководителю
проекта
и
подготовку
компромиссных
решений
для
разрешения
конфликтов
,
которые
могут
возникнуть
в
процессе
проекта
.
В
техническом
совете
должно
быть
несколько
специалистов
с
высоким
уровнем
компетентности
способных
отстоять
свои
решения
перед
высшим
руководством
объекта
моделирования
.
Технический
совет
формируется
из
экспертов
и
профессионалов
,
зна
-
комых
с
предметной
областью
моделирования
.
Руководитель
проекта
фор
-
мирует
этот
совет
и
является
его
председателем
.
Поскольку
основной
причи
-
ной
,
побуждающей
создавать
модель
,
является
необходимость
повышения
эффективности
объекта
моделирования
,
важно
,
чтобы
в
совете
были
пред
-
ставлены
все
службы
,
имеющие
отношение
к
рассматриваемой
в
проекте
предметной
области
.
Полезно
включать
в
совет
экспертов
из
смежных
облас
-
тей
объекта
моделирования
,
не
входящих
в
исследуемую
область
,
но
связан
-
ных
с
ней
.
Эти
эксперты
помогают
адекватно
оценить
влияние
окружающей
среды
на
объект
моделирования
.
Эксперты
могут
быть
членами
совета
.
Эксперту
обычно
показывают
только
ограниченные
фрагменты
модели
на
промежуточных
стадиях
,
в
то
время
как
совет
должен
принять
решение
по
всей
модели
.
Иногда
в
совет
могут
входить
лица
,
играющие
роль
источников
.
В
силу
очевидной
противо
-
речивости
интересов
нецелесообразно
,
чтобы
в
совет
входили
разработчики
модели
.
11
.2.4
Эксперт
Эксперт
-
выбираемое
руководителем
проекта
лицо
,
обладающее
спе
-
циальными
знаниями
некоторых
аспектов
моделируемой
области
.
Его
опыт
в
предметной
области
,
к
которой
относится
моделируемый
объект
,
позволяет
делать
полезные
критические
замечания
в
процессе
создания
модели
.
Эксперты
призваны
критически
оценивать
создаваемую
по
частям
мо
-
дель
.
Это
осуществляется
в
ходе
нескольких
циклов
изучения
с
использова
-
нием
читательских
папок
(
цикл
автор
/
читатель
).
Папки
обеспечивают
экс
-
РД
IDEF0 - 2000
58
перта
набором
информации
,
предназначенным
для
описания
законченного
фрагмента
моделируемого
объекта
.
С
помощью
папок
эксперту
предоставля
-
ется
информация
в
наглядном
виде
.
В
процессе
рецензирования
ему
может
понадобиться
заполнить
пробелы
или
даже
завершить
изложение
материала
,
представленного
в
папке
.
Хотя
папка
во
многом
основывается
на
интерпре
-
тации
разработчиком
ранее
полученной
информации
,
комментарии
экспер
-
тов
служат
ценным
материалом
для
уточнения
модели
.
В
информационных
папках
перед
экспертом
должны
ставиться
конкретные
,
четко
сформулиро
-
ванные
вопросы
,
связанные
с
моделированием
.
Главной
задачей
эксперта
является
оценка
соответствия
модели
соот
-
ветствующей
предметной
области
.
Экспертная
оценка
является
основным
средством
в
достижении
консенсуса
среди
изучающих
модель
экспертов
.
Одобренная
модель
-
это
модель
,
согласованная
с
экспертами
.
Если
эксперты
согласны
с
тем
,
что
модель
или
ее
часть
адекватно
представляет
рассматри
-
ваемый
объект
,
то
модель
считается
одобренной
.
Если
есть
не
согласившиеся
с
этим
,
то
их
мнение
должно
обязательно
фиксироваться
,
и
модель
считается
неправильной
,
пока
не
доказано
обратное
.
Для
достижения
консенсуса
авто
-
ры
учитывают
комментарии
и
замечания
экспертов
при
пересмотре
той
части
модели
,
к
которой
эти
замечания
относятся
.
Эксперты
подразделяются
на
две
группы
:
•
Эксперты
–
рецензенты
•
Эксперты
–
читатели
.
Эксперт
-
рецензент
-
член
коллектива
разработчиков
,
знающий
предметную
область
моделирования
,
специализирующийся
на
некоторой
конкретной
функции
предприятия
и
ответственный
за
обеспечение
критических
коммен
-
тариев
относительно
разрабатываемой
модели
.
Эксперт
–
рецензент
должен
знать
IDEF0 -
методологию
и
уметь
делать
письменные
структурированные
замечания
в
рассылаемых
папках
.
Он
является
постоянным
и
активным
уча
-
стником
цикла
автор
/
читатель
.
Эксперт
–
читатель
-
член
коллектива
разработчиков
,
профессионально
знающий
предметную
область
моделирования
,
понимающий
IDEF0 -
мето
-
дологию
и
умеющий
читать
IDEF0 -
диаграммы
.
Эксперт
-
читатель
знако
-
мится
с
документацией
(IDEF0 -
папкой
),
не
делая
письменных
комментари
-
ев
.
От
экспертов
-
читателей
авторы
получают
замечания
с
помощью
опроса
.
11
.2.5.
Библиотекарь
библиотекарь
-
лицо
,
ответственное
за
хранение
документации
,
изго
-
товление
копий
,
координацию
обмена
письменной
и
/
или
электронной
ин
-
формацией
(
рассылка
папок
,
получение
рецензий
,
регистрация
и
публикация
диаграмм
и
модели
).
РД
IDEF0 - 2000
59
11
.2.6
Источники
информации
Исходная
информация
для
IDEF0-
модели
поступает
к
разработчику
из
разных
источников
:
от
людей
и
от
документов
.
Люди
,
являющиеся
источни
-
ками
информации
,
обладают
конкретными
знаниями
о
частных
свойствах
объекта
моделирования
,
управлении
или
ходе
бизнес
–
процесса
и
их
участие
в
моделировании
может
быть
ограничено
несколькими
минутами
опроса
.
Однако
именно
эти
источники
обеспечивают
основу
для
моделирования
.
Информация
,
предоставляемая
ими
,
используется
для
создания
модели
,
а
восприятие
этой
информации
обеспечивает
разработчику
понимание
,
необ
-
ходимое
для
построения
точной
модели
.
Руководитель
проекта
подбирает
адекватные
источники
информации
,
исходя
из
направления
проекта
и
потребностей
разработчика
.
По
мере
разви
-
тия
процесса
моделирования
потребности
в
информации
изменяются
,
и
спи
-
сок
источников
информации
руководитель
проекта
пересматривает
.
Соби
-
раемая
разработчиком
информация
должна
как
можно
точнее
фиксироваться
.
Каждый
источник
воспринимает
предметную
область
по
-
своему
,
и
на
разработчике
лежит
ответственность
за
правильный
отбор
информации
.
Осо
-
бенно
это
относится
к
источникам
-
документам
.
Источник
-
документ
отражает
состояние
объекта
моделирования
в
не
-
который
момент
времени
.
Поэтому
документы
являются
важным
источником
информации
для
модели
,
но
для
их
эффективного
использования
необходима
значительная
работа
,
связанная
с
интерпретацией
,
пониманием
и
подтвер
-
ждением
.
Лица
,
выступающие
в
роли
источников
информации
,
могут
оказывать
разработчику
модели
дополнительную
помощь
,
объясняя
,
как
сообщенная
ими
информация
поступает
,
интерпретируется
или
используется
.
Разработ
-
чик
должен
воспользоваться
этой
помощью
для
понимания
того
,
как
воспри
-
ятие
информации
одного
источника
связано
с
восприятием
другого
.
11
.3
Заключительные
замечания
1
.
Функциональная
модель
-
плод
коллективного
труда
всех
участников
процесса
моделирования
.
2.
Создание
моделей
,
адекватно
отражающих
объект
предметную
область
,
возможно
лишь
при
выполнении
обязательных
условий
:
•
IDEF0-
диаграммы
следует
разрабатывать
в
точном
соответствии
с
IDEF0-
методологией
;
•
при
моделировании
должен
быть
организован
итеративный
процесс
рецензирования
каждого
фрагмента
модели
и
модели
в
целом
;
•
начинать
следующий
уровень
декомпозиции
можно
лишь
после
полно
-
го
завершения
работы
над
родительской
диаграммой
,
т
.
е
.
после
при
-
своения
ей
статуса
"
Публикация
" .
РД
IDEF0 - 2000
60
1
2.
Перспективы
развития
методологии
функционального
моделирования
Из
знакомства
с
IDEF0
следует
,
что
эта
методология
представляет
собой
четко
формализованный
подход
к
созданию
функциональных
моделей
-
структурных
схем
изучаемой
системы
.
Схемы
строятся
по
иерархическому
принципу
с
необходимой
степенью
подробности
и
помогают
разобраться
в
том
,
что
происходит
в
изучаемой
системе
,
какие
функции
в
ней
выполняются
и
в
какие
отношения
вступают
между
собой
и
с
окружающей
средой
ее
функциональные
блоки
.
Совокупность
схем
(IDEF0 -
диаграмм
)
образует
модель
системы
.
Эта
модель
носит
качественный
,
описательный
,
деклара
-
тивный
характер
.
Она
принципиально
не
может
ответить
на
вопросы
о
том
,
как
протекают
процессы
в
системе
во
времени
и
в
пространстве
,
каковы
их
характеристики
и
в
какой
мере
удовлетворяются
(
или
не
удовлетворяются
)
требования
,
предъявляемые
к
системе
.
Все
эти
вопросы
с
неизбежностью
возникают
после
того
,
как
достигнут
нижний
уровень
декомпозиции
,
т
.
е
.
обозначены
« ...
функции
нижнего
уровня
,
с
помощью
которых
и
работает
система
»([ 3 ],
стр
.
1
4
1
).
В
этом
случае
рекомендуется
переходить
к
другим
моделям
-
математи
-
ческим
,
имитационным
моделям
,
описывающим
процессы
в
функциональ
-
ных
блоках
IDEF0 -
модели
.
По
терминологии
,
принятой
в
исследовании
операций
,
IDEF0 -
модели
относятся
к
классу
концептуальных
.
Именно
концептуальные
модели
являются
основой
построения
математических
моделей
.
Пытаться
«
нагрузить
»
концептуальную
модель
количественными
соотношениями
не
следует
-
это
разные
уровни
абстракции
.
Видимо
,
этим
объясняется
существование
специальной
методологии
IDEF2,
предназначен
-
ной
для
моделирования
динамических
процессов
в
функциональных
моде
-
лях
.
В
отсутствии
стандарта
,
регламентирующего
применение
методологии
IDEF2,
целесообразно
ставить
вопрос
о
наполнении
IDEF0 -
структур
коли
-
чественным
содержанием
,
т
.
е
.
о
создании
методики
построения
моделей
,
адекватно
описывающих
процессы
в
изучаемой
системе
,
в
т
.
ч
.
и
во
времени
,
в
динамике
Описание
и
количественная
оценка
преобразований
требуют
создания
математических
моделей
,
которые
должны
отображать
(
имитировать
)
физи
-
ческие
,
экономические
,
организационные
,
финансовые
,
логические
и
т
.
п
.
отношения
между
сущностями
,
входящими
в
IDEF0 –
модель
,
разворачи
-
вающиеся
во
времени
.
Исходя
из
общих
соображений
,
связанных
с
возможными
областями
при
-
менения
функционального
моделирования
и
структурного
анализа
предпри
-
ятий
и
организаций
,
можно
указать
несколько
классов
математических
мо
-
делей
,
которые
найдут
применение
в
качестве
средств
описания
процессов
и