21 подписчик

Рубрика: рассказ от анонимного программиста

12 минут

2 прочтения

9 августа 2023

Самая сложная часть создания программного обеспечения - это не кодирование, а требования

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

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

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

Это не ошибка, это особенность…нет, подождите, это ошибка

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

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

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

Я наивно спросил клиента: “Должен ли я удалить вводимые данные, которые позволяли пользователю переопределять правильные правила и условия?” Ответ, который я получил, с тех пор запечатлелся в моем мозгу. Его точные слова были произнесены с полной уверенностью:

“Этого никогда не случится”

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

Месяцы спустя, всего за несколько недель до запуска программного обеспечения, тестировщик на стороне клиента обнаружил дефект, и он был назначен мне. Когда я увидел подробности дефекта, я громко рассмеялся.

То беспокойство, которое у меня было по поводу отмены правил и условий по умолчанию, то, что, как мне сказали, никогда не произойдет? Угадайте, что происходило? Угадайте, кого в этом обвинили и кого попросили это исправить?

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

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

Искусственный интеллект применялся в шахматах еще в 1980-х годах. Широко признано, что искусственный интеллект превзошел человеческие способности выигрывать в шахматы. Это также неудивительно, поскольку параметры шахмат конечны (но игра еще не решена).

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

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

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

В технологиях стандартом доступности является пять или даже шесть 9 секунд — веб-сайт или услуга доступны 99,999% (или 99,9999%) времени. Затраты на достижение первых 99% не так уж высоки. Это означает, что ваш веб—сайт или сервис могут быть недоступны более трех дней — 87,6 часов - в году. Однако за каждые 9, которые вы добавляете в конце, стоимость растет в геометрической прогрессии. К тому времени, когда вы достигнете 99,9999%, вы сможете допускать только 31,5 секунды простоя в год. Это требует значительно большего планирования и усилий и, конечно же, обходится дороже. Получить первые 99%, возможно, нелегко, но пропорционально это намного проще и дешевле, чем последняя крошечная доля.

365 X 24 X 60 минут = 525 600 минут в год

доступность 99% -> отключен на 5256 минут, 87,6 часов

доступность 99,9% -> снижение на 526 минут, 8,76 часа

99,99% -> 52 минут, менее 1 часа

99,999% -> 5,2 минуты

99,9999% -> 0,52 минуты, примерно 31,5 секунды

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

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

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

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

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

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

Что еще хуже, требования меняются или игнорируются. Недавно меня попросили помочь команде создать что-то, что могло бы помочь людям получать информацию о проблемах со здоровьем, связанных с COVID-19. Приложение предназначалось для той части земного шара, где не было надежного Wi-Fi. Команда хотела, чтобы я помог создать приложение, которое могло бы проводить опросы с помощью SMS—сообщений по телефону. Поначалу я был рад принять в этом участие.

Как только я начал слышать, как команда описывает, чего, по их мнению, они хотят, я понял, что это будет проблемой. Одно дело, когда розничная компания спрашивает вас по шкале от 1 до 10, какова вероятность того, что вы снова сделаете покупки в их магазине. Совсем другое дело - проводить многоступенчатые опросы с вопросами с множественным выбором о симптомах, которые вы испытываете при возможной инфекции COVID. Я никогда не говорил "нет", но я затронул все возможные точки отказа в этом процессе и хотел, чтобы команда четко определила, как мы будем обрабатывать поступающие ответы на все вопросы. Будут ли числа, разделенные запятыми, сопоставлены с каждым ответом? Что произойдет, если отправленный ответ не соответствует ни одному из приведенных вариантов?

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

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

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

За последнее десятилетие индустрия программного обеспечения перешла от водопадной методологии к гибкой. Waterfall точно определяет, чего вы хотите, еще до написания любого кода, в то время как agile обеспечивает достаточную гибкость, чтобы вы могли вносить коррективы по ходу работы.

Так много программных проектов, использующих waterfall, потерпели неудачу из-за того, что заинтересованные стороны думали, что они знают, чего хотят, и думали, что смогут точно описать это и задокументировать, только для того, чтобы быть очень разочарованными, когда конечный продукт был доставлен. Предполагается, что гибкая разработка программного обеспечения является противоядием от этого процесса.

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

Искусственный интеллект на самом деле мог бы неплохо создавать программное обеспечение, используя процесс waterfall, который также ласково называют death march. Вы знаете, кто ужасен в водопаде? Мы - человеческие существа. И это не из-за той части, где подписанные документы передаются команде программистов, чтобы они могли написать код. Это все, что было до этого. Искусственный интеллект может делать некоторые экстраординарные вещи, но он не может читать ваши мысли или говорить вам, чего вы должны хотеть.

Подписывайтесь на наш telegram: