Целевая система обеспечения

Итак, "Вася — разработчик программного обеспечения, осуществляющего подготовку трехмерных моделей к печати на 3D принтере. Что является Васиной целевой системой?"

Правильный ответ по учебнику: "Программа, запущенная на исполнение на компьютере разработчика 3D модели".

Вот и противоречие: одновременно выбор софта в качестве целевой системы + упор на то, что ЦС почти всегда есть физический результат (в данном примере — скорее 3Д-модель).

Пытаюсь убрать противоречие так: Вася разраб, он пишет софт, софт будет использоваться где-то кем-то для каких-то принтеров для печати каких-то деталей; скорее всего, Вася сотрудник компании, которая продаст софт компаниям, которые собирают 3д-принтеры, которые их кому-то продают и те покупатели потом на них печатают (вероятно даже, для покупателей их сервиса "печать 3д-деталей"). И вот для Васи все эти потенциальные 3д-детали очень далеко, прям очень, и хоть они и остаются где-то вдали целевыми системами, но для Васи вроде как уже и нет. Его софт могут купить разработчики 4д-принтеров (тогда ЦС станут 4д-модели). А могут купить конкуренты для ознакомления, етс.

Пример с парикмахерской: мы организуем парикмахерскую, так как мы знаем, что она будет выдавать сервис стрижки-укладки-покраски, то наша ЦС есть прическа в целевом контексте (свидание, например). Некорректно, но пусть это будет Целевая Система Обеспечения (то, что будет выдавать сервис по созданию Целевых Систем у клиентов) Мы арендовали/купили/построили помещение под парикмахерскую и наняли команду отремонтировать его под парикмахерскую. Пусть в этой команде
- дизайнер интерьера — он проектирует помещение с назначением парикмахерская, для него ЦС прическа
- прораб / бригадир — он руководит созданием отделки помещения “парикмахерская”, для него ЦС прическа (+ немного уже само помещение)
- маляр-подрядчик, он пришел на один день покрасить стены краской, которую выбрал дизайнер, которую закупил бригадир; маляр может не знать, что помещение для парикмахерской, но это неважно, как раз его ЦС есть покрашенная конкретной краской внутренняя поверхность помещения в срок-бюджет.

Вот тут как раз справедливо сказать “система в глазах смотрящего”.

А Вася из примера в учебнике здесь получается как колеровщик/технолог компании-настройщика колеровочных машин (или в чём там краски смешивают), продающих свой софт/сервис для лакокрасочных производств).

Сергей, мне тоже логика этого кейса не особо понятна была, но мне кажется она может быть в том, что иногда когда делается система обеспечения не для конкретной системы, а для размытого множества систем, то попытки описать целевую систему приведут к большим обобщениям. В этом случае будет лучше остановиться и ограничиться уровнем на котором еще понятно что делается, а не уходить в сплошные абстракции. 

 

Я считаю, что нет правильности - есть полезность. Чем ближе ты находишься к  целевой системе, тем меньше вопросов что это именно она, и тем проще на них удерживать внимание. Системы обеспечения часто находятся очень далеко. Очень сложно (и неполезно) заставить маляра удерживать внимание на прическах, которые будут делаться в парикмахерской. Но удержать его внимание на том, что он красит именно парикмахерскую, а не просто абстрактную стену  - полезно. 

Критерий сильной удаленности систем действительно может быть применен, согласен.

В случае с маляром и парикмахером он точно работает. В случае с разработчиком и принтером.... Ну, возможно. Ладно, как известно, в системном мышлении нет правильных ответов))

Здесь важно упомянуть наличие нашей системы.

У маляра та же целевая система, что и у прочих проектных ролей: причёска.
А наша система для маляра: покрашенная конкретной краской внутренняя поверхность помещения в срок-бюджет.