Амазон
RRRRR - 54.147.212.173
@ Подписаться

Несколько тезисов для умных друзей о построении моделей

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
2013-07-28 19:38:53
Сергей В. Сычёв » Всем

О построении моделей

  • Классификация НЕ обязана корректно описывать часть окружающего мира, она просто "заточена" под конкретный функционал.
  • Большую непротиворечивую классификацию невозможно создать по теореме Геделя о неполноте.
  • Если СЕЙЧАС классификация непротиворечива, то это только потому, что проект ещё мал и данные (в т.ч., типы данных) еще не все учтены.
  • Классификация должна быть НЕ “правильная”, а компактная (маленькая) и не растущая СТРУКТУРНО при увеличении потока требований.
  • При хорошей модели по мере роста проекта добавляются записи в справочники, но не "ветки" в структуру.
  • При добавлении новых требований к объектным структурам, увеличивается число веток. Поэтому они плохи.
  • При добавлении новых требований к функциональным структурам, увеличивается число записей в справочнике.
  • Поэтому функциональные структуры легче продвинуть к идеалу. Их также легче сопровождать.
  • Надо не только учиться “обрабатывать сложные деревья” (модная ВУЗовская тема), но и проектировать модель так, чтобы функциональность росла, а "ветки" нет.  В идеале, вообще обходиться без задачи обработки сложного дерева.
  • В алгоритмах обработки деревьев нет ничего плохого, но люди несовершенны. Очень многие из них “ветвят проект” только потому, что их учили  “обрабатывать деревья”. А задача сделать функциональную, но одновременно компактную модель не ставили вовсе.

Всякую модель полезно проверять на "максимум потока", и, при этом, задавать себе такие вопросы:

  • Когда поток вырастет в 1000 раз, то какая подсистема не выдержит в первую очередь?
  • Нельзя ли вовсе обойтись без этой подсистемы? Как перестроить проект так, чтобы этой подсистемы не было, а функциональность сохранилась?
  • Если удалось перестроить проект так, что удалось обойтись БЕЗ подсистемы по предыдущему пункту (а функциональность сохранить), снова применить прием увеличения максимума потока и снова спросить себя:
    • Когда поток вырастет ещё в 1000 раз, то какая следующая подсистема испортится прежде остальных?
    • Как обойтись без неё? (далее цикл)
  • Если соответствующую подсистему (см.выше) полностью устранить не удалось, но удалось её реализовать иначе (лучше и проще), то попробовать экстраполировать СТРУКТУРУ перестроенной подсистемы на весь проект. Хоть это и нелогично. 

Пояснение: из работы "Идеализация технических систем" [Ю.Саламатов, И.Кондраков] известно, что подсистема, испытывающая максимальные претензии, после ее улучшения “поглощает” соседей (т.е., способна выполнить функции ближайших подсистем) и становится эталоном для системы в целом.

Прошу прощения у всех, кому это не интересно, а Вы случайно прочли :)

Спасибо,

2013-08-10 14:54:11
Редакция » Всем

Уважаемые Коллеги!

Для удобства разные обсуждения одной темы размещены слева на панели:

Обсуждение 1 темы о построении моделей (медицинский центр)
Обсуждение 2 темы о построении моделей (продажа запорной арматуры)

Спасибо,

2013-10-24 19:47:46
Стас Воронин » Сергей В. Сычёв

Уважаемый Сергей Валерьевич!


В связи с Вашими тезисами возникло несколько вопросов:


1. Предположим мы решили собрать картотеку типовых бизнес-проблем и свести их в некий общий каталог. Вероятно, исходно такой каталог состоял бы из двух больших разделов: маркетинга и менеджмента, но как в целом следовало бы все это классифицировать?

  • по типу проблем, например: "проблемы продаж"?
  • по причине/источнику проблем: например, проблемы, связанные с неверной моделью з/п?
  • как-то иначе?

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


2. Верно ли, что в итоге такие проблемы разложились бы по этапам S-кривой, или мы здесь заблуждаемся? 


С уважением,

2013-10-26 23:57:51
Сергей В. Сычёв » Стас Воронин

Уважаемый Стас!

собрать картотеку типовых бизнес-проблем и свести их в некий общий каталог (...)

  • по типу проблем, например: "проблемы продаж"?
  • по причине/источнику проблем: например, проблемы, связанные с неверной моделью з/п?
  • ........................
Существует бесконечное множество вариантов продолжения данного списка. Но приведённый Вами пример носит, всё же, умозрительный характер, а при конкретном исследовании имеются более узкие формулировки и более частные задачи. Так что, перебирать многочисленные варианты для классификации не приходится.
 
Обычно изначально есть определённый массив решённых задач - их накапливаешь и подбираешь аналоги. Когда общее число записей становится большим, то организация картотеки заключается в том, чтобы упрощать извлечение аналогов и их групповую обработку после извлечения, а не в том, чтобы делать "правильной" картину мира. Это и будет функциональным подходом. Группирую так, чтобы затем извлечь максимум аналогов простейшим и удобным способом.

 

Вероятно, исходно такой каталог состоял бы из двух больших разделов: маркетинга и менеджмента


А это - как раз - объектный подход ("правильно" разложить существительные по полкам). Будет громоздко, неудобно и путано. Причём вместо слов "маркетинг" или "менеджмент" могут стоять любые иные существительные, например, "слоны" и "мамонты" или "вилки", "ложки" и "тарелки" и проч. - проблема порождается не темой, а способом организации данных и определённым ошибочным желанием ("хочу максимально полно и непротиворечиво описать действительность").

2. Верно ли, что в итоге такие проблемы разложились бы по этапам S-кривой, или мы здесь заблуждаемся? 

Какие именно проблемы и с какой радости?

Спасибо,


Уважаемые Коллеги!

Если Вам нравится наш Форум, Вы можете поддержать его, отправив любую сумму (тогда выберите опцию "Спасибо за Форум").

Вы также можете поддержать конкретное обсуждение и получить гарантированный ответ от наших специалистов (тогда выберите опцию "Прошу эксперта ответить в этой теме").
Задайте Ваш вопрос здесь.

Большое Спасибо!


Яндекс.Метрика