О колбасе :)

Понравился анекдот о колбасе и яйцах :)

Жена посылает мужа-программиста в магазин:
- Дорогой, купи, пожалуйста, палку колбасы, и если будут яйца, то купи десяток.
Через полчаса программист возвращается с десятью палками колбасы.
Жена:
- Что это?! Зачем ты купил столько колбасы?
Программист:
- Ну так яйца-то были...

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

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

Из-за чего получаются такие ошибки? Как они закрадываются в спецификации? Есть несколько ответов на эти вопросы: от банального не доглядели до несогласованности требований. Всем известно, что требования в процессе разработки меняются, и после каждого изменения или дополнения нужно проверять, не получилось ли так, что часть новых требований не согласуется со старыми. Так же есть такие факторы, как взаимонепонимание и "требования по умолчанию". Разработчики, которые не являются специалистами в предметной области разрабатываемого продукта, могут не знать некоторых деталей, а для заказчика (или эксперта, учавствующего в разработке спецификации) данные детали являются делом обыденным, само собой разумеющимся. "Требования по умолчанию" - это опасные требования. Их даже может и не быть в спецификации, потому что это "само собой разумеющиеся" вещи, о них просто забывают. А для разработчиков эти вещи далеко не очевидны, так же как и для обычного человека не очевидно то, что для разработчика ясно как 0 и 1.

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