Каталог решений - Необходимость гуманитарных знаний для программиста. Забавный кейс как повод задуматься

По мере общения с сообществом инфостарта у меня начало закрадываться подозрение, о довольно фрагментарном и слабом гуманитарном образовании IT-шников. Не хочу никого обидеть и тем более вносить сюда элементы какого-либо хвастовства, но очень уж не терпится проверить свою гипотезу или догадку.

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

Собственно у данного кейса есть 3 основные цели:

1. Моя чисто эгоистичная – оценить уровень способности программистов применять гуманитарные знания самого широкого спектра при разработке подходов к решению прикладных задач. Это просто любопытно.
2. Моя еще более эгоистическая – оценить собственные способности через качество решения по данному кейсу.
3. Общечеловеческая – потренировать программистов и проектировщиков информационных систем, обменяться опытом, знаниями и соображениями по методологии проектирования информационных решений.

Ну а теперь сам кейс и пришедшие мне в голову варианты решений:

Итак, Ваша компания намерена принять участие в тендере на разработку ПО для фирмы Х.

Фирма X занимается тем, что отлавливает каких либо животных (кроликов, удавов или, допустим, лошадей) по всему миру при помощи автоматических ловительных терминалов. Терминал уже разработан и имеет устройство в виде ворот и загона. В ворота могут входить самые различные животные, а вот дверь загона для нужного вида животных (остановимся таки на лошадях) должен открывать Ваш софт. В терминале есть 4 контроллера определяющие для вошедшего в ворота животного:

1. Рост
2. Длину
3. Вес
4. Цвет

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

Для КП на тендер нужно выставить цену проекта, срок и подход к решению. Почему так важен подход? Потому что на конкурсе кроме финансистов от заказчика будут присутствовать в качестве независимых экспертов 2-3 очень известных специалиста в области разработки алгоритмов и оценок эффективности систем и они-то и дадут заключение об эффективности Вашего подхода.

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

Ваша задача по кейсу определить именно ту часть предложения в которой будет описан подход к построению информационной компоненты терминала. То есть какова будет структура  и состав базы данных и основной принцип обработки с ее помощью сигналов от контроллера, так чтобы система была по возможности проще (дешевле и быстрее реализуемой) и достаточно точной для определения вероятности. Насколько точна будет Ваша система оценят эксперты на тендере (Вы не знаете заранее кто это будет, поэтому возможности подкупить их нет). Итак Ваша цель – победа в тендере, но очевидно, что претендовать на первенство сразу во всех номинациях требований к  решению у Вас тоже не получится. Давайте опишу основные возможные решения и вы поймете почему:

1. Сверхпросто. Информационная база – максимальные и минимальные значения по всем контролируемым параметрам и набор возможных цветов для лошадей. Алгоритм – сравнение фактических показаний контроллеров с допустимыми на больше меньше и на ИЛИ равно для цвета. Если животное вписывается в параметры и подходит по цвету – оно запускается. Решение очень простое — дешевое, быстрореализуемое, но, очевидно далеко не точное по вероятности определения.
2. Просто. Аналогично сверхпростому, но животное отсекается между минимумами и максимумами по какому-либо критерию в стиле Парето. То есть берется промежуток 20-25% между минимальными и максимальными значениями в центре (которые как известно должны включить примерно 80% существующих в природе лошадей) и берутся только те животные, которые пролезут в данные «ворота», теперь уже меньшего чем у сверхпростого варианта размера.
3. С анализом функции вероятности. Похоже на простой вариант, но вместо критерия Парето используется специальные критерии рассчитанные на основании нормального закона распределения. В информационную базу в этом случае добавляется: среднее по всем количественным показателям и среднеквадратичные отклонения. Усложняется соответственно расчетный алгоритм, так как теперь на основании показаний контроллеров рассчитывается и оценивается вероятность того, что это лошадь. Потом, возможно, вероятности перемножаются (или берется средняя) и сравниваются с неким пороговым уровнем. Этот вариант еще точнее, но дольше и дороже так как необходимо написать больше и более сложного кода, а также требует проведения полноценного статистического исследования популяции лошадей.
4. Моделью статистической взаимосвязи. В данном случае база данных сокращается до одной формулы, в которую нужно подставить рост, длину, вес и цвет (кодированный числом) и которая выдаст вероятность того, что это лошадь. Метод точнее, но опять же снова возможно дольше и возможно дороже, так как помимо исследования популяции необходимо выделить и проанализировать статистические взаимосвязи, протестировать несколько возможных функций вероятности и даже, возможно, потерпеть здесь неудачу, так как устойчивой и пригодной зависимости найдено не будет. Скорее всего эту работу (по разработке статистических методов) нужно будет поручать субподрядчику, так как она требует сильной математической специализации. В общем скорее всего будет очень точно, но не исключен и провал.
5. Распознающей моделью. В данном методе выбирается одна, допустим, нейросетевая модель распознавания (или несколько способов распознавания) в нескольких вариантах, собирается статистический массив данных о лошадях, обучаются и тестируются возможные сети. Затем в терминале моделируется обученная модель распознавания с  лучшими из возможных характеристиками. По сложности программирования сложнее варианта D, по точности, наверное, немного выше. И сроки… Сроки здесь тоже жмут.

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

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

Напомню до начала обсуждения, что это кейс. То есть единственного правильного ответа у задачи нет и подходить таким образом к решению не нужно. Нам нужно по возможности найти лучший ответ. Надеюсь, что получитсяJ