День 1809. #Оффтоп
Самая Сложная Часть Создания ПО — не Кодирование, а ТЗ. Начало
Глядя на новости о разработках в области искусственного интеллекта, многие боятся того, что мы, как разработчики ПО, вскоре можем остаться без работы, и нас заменит ИИ. Они полагают, что бизнес будет напрямую просить ИИ создать то, что, по их мнению, им нужно. Стоит ли этого бояться?

Программирование может оказаться непростой задачей, но разобраться в коде, в принципе, не так сложно. Как только вы освоите синтаксис, логику и методы, написание кода станет довольно простым процессом в большинстве случаев. Настоящие проблемы обычно связаны с тем, что должно делать ПО. Самое сложное в создании ПО — создание требований, а требования к ПО по-прежнему определяются людьми.

Это не баг, это фича… нет, погодите, это баг
Я как-то работал над созданием ПО, которое настраивало индивидуальные условия для продуктов на сайтах электронной торговли. Существовало размытое описание логики, которая зависела от типа товара и штата США, где находился заказчик в силу требований закона.

В какой-то момент мне показалось, что я нашел баг. Пользователь выбирает один тип продукта, что создаёт соответствующие условия, но далее в рабочем процессе он может изменить тип продукта. Это нарушало условия, под которыми стояла подпись клиента. Я спросил клиента, надо ли убрать возможность менять тип продукта или при смене переопределять условия? Ответ был уверенным: "Этого никогда не произойдёт".

Это был старший руководитель, не было повода ему не доверять. Несколько месяцев спустя, перед релизом ПО, тестировщик обнаружил дефект, и его поручил мне. Угадайте, что это было, кого в этом обвинили и кого попросили это исправить? Исправить ошибку было легко, а последствия были незначительными, но это лишь в этот раз. Проблемы больше, их сложнее исправить, и они обходятся дороже, чем дальше в процессе разработки вы продвигаетесь. Но источник проблем обычно один и тот же: требования были неясными, непоследовательными или неправильными.

ИИ сейчас: шахматы против беспилотных автомобилей
Концепция ИИ существует уже довольно давно. Он был применён в шахматах ещё в 80-х годах. К концу 90-х ИИ превзошёл возможности человека выигрывать в шахматы. Это тоже неудивительно, ведь параметры шахмат КОНЕЧНЫ. При каждом ходе существует конечное число возможных ходов. ИИ может рассчитывать последствия каждого хода, чтобы выбрать наиболее подходящий, приводящий в итоге к победе.

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

В сфере технологий есть понятие для выражения доступности сервиса в виде количества девяток. Стандартом сейчас является 5 девяток, т.е. доступность 99,999% времени. Проблема в том, что достичь уровня доступности в 99% легко, но каждая следующая девятка даётся сложнее в геометрической прогрессии.

Причина, по которой так сложно достичь приемлемого уровня безопасности беспилотных авто в том, что вождение автомобиля предполагает значительно больше переменных, чем шахматы, и эти переменные НЕ КОНЕЧНЫ. Первые 95% или 99% могут быть предсказуемыми и легко поддающимися учёту. Но дальше существует очень много крайних случаев, которые могут иметь некоторые общие черты, но каждый из которых уникален: другие машины, управляемые людьми, перекрытия дорог, аварии, погодные явления. Невероятно сложно заставить модель ИИ учитывать и распознавать эти аномалии, и, что более важно, правильно реагировать, не попадая в аварию.

Окончание следует…

Источник: https://stackoverflow.blog/2023/12/29/the-hardest-part-of-building-software-is-not-coding-its-requirements/
Автор оригинала: Jared Toporek (консультант в разработке ПО, создатель приложения Keenforms)