Андрей Орлов - Записки автоматизатора. Профессиональная исповедь

В соответствии с российскими (и, кстати, американскими) стандартами составление технического задания (ТЗ) возлагается на разработчика. Это естественно, так как обычно клиент сам не знает, чего хочет, что можно реализовать и как.

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

Посмотрим на примерах, к чему это приводит.

Невинная фраза из ТЗ «Все количество распределяется по всем покупателям поровну с округлением до 1 шт. Погрешность округления относится на последнего покупателя» приводит к очень интересным результатам.

Итак, на 100 покупателей поступило 40 штук. Поровну означает 40/100 = 0,4 штуки. С округлением до одной штуки получается 0, то есть все 40 штук получит последний покупатель.

Еще веселее, если на 100 покупателей поступило 60 штук. Тогда все покупатели, кроме последнего, получат по одной штуке, а последний… – 39 (минус тридцать девять) штук.

Программа соответствует ТЗ.

Вообще ошибки округления – это бич современных систем учета, особенно в России, где правила бухгалтерского учета про них просто не упоминают, якобы у нас все всегда точно. Как следствие, в России их никаким способом нельзя обрабатывать правильно. У меня сформировалось стойкая убежденность, что наши налоговые органы вполне умышленно никогда не отвечают на такие вопросы и не дают необходимых разъяснений: так удобнее сделать нарушителем любого, кто отчитывается перед налоговиками. Следующий пример из приказа МНС я могу воспринимать только как издевательство:

«По коду строки 100 указано 5 месяцев, в течение которых транспортное средство было зарегистрировано на организацию в 2003 году, следовательно, коэффициент, который следует указать по коду строки 110, составит 5/12 = (5: 12)».

Ясно? 5/12 равно 5:12, так МНС приказал. А уж сколько знаков после запятой оставить – это ваша проблема: сколько ни укажите, будете не правы.

Значит, тем более все вопросы, связанные с округлениями, надо подробно описать в техническом задании и по возможности разъяснить руководству (с примерами на конкретных цифрах).

Про программиста, написавшего программу для банка, добавлявшую все ошибки округления на его банковский счет и ставшего миллионером (на время, пока его не посадили), я читал еще в начале семидесятых (книжка называлась «Кибернетическая смесь»). Теперь обязательно пытаюсь рассказать эту историю боссам, а потом уже показываю, как после получения груза на сто тысяч долларов тысяча долларов растворяется в системе.

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

Про полтинники.Я уже писал, как в компании, продававшей периодическую печать, киоскеры, работавшие в метро, взмолились, чтобы мы округляли розничные цены на газеты до полтинника. Руководство нас на это благословило, и я программисту ровно так задание и сформулировал: «В поле PriceMetro поместить значение из поля PriceRetail, округленное до 0,5».

Звонит программист:

– А каким способом округлять?

– Обычным.

– Андрей, я не знаю обычного способа округлять до 0,5. Пожалуйста, опиши.

– Ты издеваешься?

– Нет, я серьезно.

– Хорошо.

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

ДРОБН:= А – ЦЕЛОЕ (А)

ЕСЛИ ДРОБН < 0,25 ТО ДРОБН:= 0

ИНАЧЕ ЕСЛИ ДРОБН < 0,75 ТО ДРОБН:= 0,5

ИНАЧЕ ДРОБН:= 1

ОКРУГЛ05 (А) = ДРОБН + ЦЕЛОЕ (А)

Дело в том, что не существует никакого «общего» способа округления до полтинников. Его нужно было записать в задании явно. Что я и сделал самым понятным для программиста способом.

Про дополнительное оборудование(история, рассказанная Александром Ройзнером за 15 лет до предыдущей). Мы пытались формализовать действия, которые во время поездки должен совершать машинист локомотива, чтобы в дальнейшем правильность этих действий оценивала автоматизированная система. По этому поводу с начальником одного из локомотивных депо произошел следующий диалог: