Владимир, а если представить такую ситуацию. Есть процесс "Обеспечения МТР", тогда логично, что на верхнем уровне из него выходит стрелка, которая включает в себя все объекты, связанные с результатом работы этого процесса (сами МТР и различные документы). Пусть эта стрелка называется МТР. В процессе "Обеспечение МТР" есть процесс, результатом которого является, например, Заявка или еще что-то, что уходит в какой-то сервисный процесс для его вызова. На сколько правильно эту Заявку агрегировать вместе с другими объектами деятельности в стрелке МТР на верхнем уровне?
idef0 старый стандарт, времен когда и ООП не было. Он убогий и ненужный в большинстве случаев. Исключения это промышленный линии небольшие. Там надо от станков, например, получить информацию реального времени, а она только через драйвер (то есть функция для программиста). Еще можно применить к монолитным решениям с малой базой. Тогда можно написать ряд функций запросов к монолиту и организовать доступ к ним согласно должностным обязанностями. Но это путь в никуда. Дублирование кода по итогу. А если изображать для наглядности бизнес процесса, то кому это надо изображать? менеджерам идиотам лучше мамонта нарисовать на графике, программисту можно на словах объяснить, быстрее будет. А все сложности деталей работы бизнес процесса на такой диаграмме не покажешь, запутаешь только. Потому idef0 это сотрясание воздуха в 99% случаев. Максимум поток документов изобразить можно между процессами НУ ОЧЕНЬ ВЕРХНЕГО уровня.
Материал нужный для работы, подан, как всегда, ясно, доходчиво. Спасибо!
Спасибо Вам. Было познавательно!
Владимир, а если представить такую ситуацию. Есть процесс "Обеспечения МТР", тогда логично, что на верхнем уровне из него выходит стрелка, которая включает в себя все объекты, связанные с результатом работы этого процесса (сами МТР и различные документы). Пусть эта стрелка называется МТР. В процессе "Обеспечение МТР" есть процесс, результатом которого является, например, Заявка или еще что-то, что уходит в какой-то сервисный процесс для его вызова. На сколько правильно эту Заявку агрегировать вместе с другими объектами деятельности в стрелке МТР на верхнем уровне?
Юрий, можно использовать разные методические подходы. Я предпочитаю агрегировать...
Громкости бы добавить...
Покрутите ручку у колонок ;-)
idef0 старый стандарт, времен когда и ООП не было. Он убогий и ненужный в большинстве случаев. Исключения это промышленный линии небольшие. Там надо от станков, например, получить информацию реального времени, а она только через драйвер (то есть функция для программиста). Еще можно применить к монолитным решениям с малой базой. Тогда можно написать ряд функций запросов к монолиту и организовать доступ к ним согласно должностным обязанностями. Но это путь в никуда. Дублирование кода по итогу. А если изображать для наглядности бизнес процесса, то кому это надо изображать? менеджерам идиотам лучше мамонта нарисовать на графике, программисту можно на словах объяснить, быстрее будет. А все сложности деталей работы бизнес процесса на такой диаграмме не покажешь, запутаешь только. Потому idef0 это сотрясание воздуха в 99% случаев. Максимум поток документов изобразить можно между процессами НУ ОЧЕНЬ ВЕРХНЕГО уровня.
Скажите это моему преподавателю, который сказал, что в курсовой обязательно должна быть idef0
@@lerokforever3535 что тут удивительного, система образования у нас уничтожена ) люди видимость требуют а не суть.