18. Принципы построения модели idef0
IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы.
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ.
При формулировании области моделирования необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").
Цель моделирования. Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
• Почему этот процесс должен быть смоделирован?
• Что должна показывать модель?
• Что может получить читатель?
Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: "Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений", "Идентифицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций информационной системы"...
Точка зрения. Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель, важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only).
IDEF0 - модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.
Yandex.RTB R-A-252273-3
- Разработка и стандартизация программных систем
- 1. Три типа жизненных циклов программных систем.
- Водопадная (каскадная, последовательная) модель
- Итерационная модель
- Спиральная модель
- 3. Стандарт iso серии 9000 при разработке программных систем.
- Iso 9000 — серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.
- 4. Стандарты Единой системы программной документации (еспд)
- Классификация:
- 5. Стандарты рф (гост р) на документирование пс
- 6. Организация группы проекта при разработке программных систем.
- 7. Три способа определения требований к программной системе.
- 8. Спецификация требований к программной системе.
- 9. Методы контроля спецификации требований.
- 10. Спецификация качества программных систем.
- 11. Функциональная спецификация программных систем.
- 12. Архитектура программных систем
- 13. Основные классы архитектур программных систем.
- 14. Основные модели при разработке программных систем.
- (См. Вопрос 1!)
- 15. Принципы объектно-ориентированного анализа и проектирования пс
- 16. Принципы компонентной архитектуры информационных систем.
- 17. Стандарты семейства idef
- 18. Принципы построения модели idef0
- 19. Принципы разработки моделей as-is и то-ве
- 20. Диаграммы в стандарте idef0
- 21. Понятие работы в стандарте idef0
- 22. Описание взаимодействия работ в стандарте idef0
- 23. Типы связей работ в стандарте idef0
- 24. Стандарт idef1x
- 26. Диаграммы потоков данных.
- 27. Архитектурные виды программной системы.
- 28. Фазы, итерации и циклы разработки программных систем - руп.
- 29. Рабочие процессы создания программных систем - руп.
- 30. Основные артефакты при разработке программных систем.
- 31. Концепция языка uml
- 32. Язык uml как система визуализации, специфицирования, конструирования, документирования
- 33. Понятия модели и системы в языке uml
- 34. Принципы моделирования системной архитектуры в языке uml.
- 35. Принципы представления системы в языке uml.
- 36. Понятие сущностей в языке uml
- 37. Структурные сущности предметной области.
- 38. Отношения в языке uml
- 39. Диаграммы в языке uml
- 40. Правила языка uml.
- 41. Общие механизмы языка uml
- 42. Прецедент как спецификация поведения программных систем.
- 43. Организация прецедентов в языке uml.
- 44. Приемы анализа прецедентов в языке uml
- 45. Диаграммы прецедентов.
- 46. Моделирование требований к системе с помощью диаграмм прецедентов.
- 47. Критерии сравнения инструментальных систем разработки программных систем.
- 48. Технико-экономические показатели разработки программных средств
- 49. Сертификация программных средств
- 50. R-технология программирования