Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

Причина возникновения экстремальных методик, сосредоточенных на фазе кодирования, не случайна. Американский специалист по методологиям софтостроения Кэпер Джонс в своей книге[23] приводит весьма удручающие статистические данные, например:

• среди проектов с объёмом кода от 1 до 10 миллиона строк только 13 % завершаются в срок, а около 60 % свёртываются без результата;

• в проектах от 100 тысяч до 1 миллиона строк эти показатели выглядят лучше (примерно 25 % и 45 %), но признать их удовлетворительными никак нельзя;

• в проектах примерно от 100 тысяч строк на кодирование уходит около 20 % всего времени, и эта доля снижается с ростом сложности, тогда как обнаружение и исправление ошибок требует от 35 % времени с тенденцией к увеличению.

В любом софтостроительном процессе, будь то заказной проект или продукт для рынка, всегда можно выделить 4 основные стадии:

• анализ, чтобы понять «что делать»;

• проектирование, чтобы определить и запланировать «как делать»;

• разработка, чтобы собственно сделать;

• стабилизация, чтобы зафиксировать результат предыдущих этапов.

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

Рис. 13.Методология «водопад» в идеальном случае

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

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

Рис. 14.На практике «водопад» зацикливается с увеличением сложности проекта

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

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

Но если проблема зацикливания на требованиях может быть успешно решена выбором подрядчиков, уже имевших опыт в построении систем данного типа, то другая, гораздо более значимая проблема несовпадения взглядов заказчика и подрядчика на казалось бы одни и те же вещи стабильно проявляется с ростом проекта. Даже если принять во внимание, что только 20 % требований специфичны для заказчика, тогда как 80 % исходят непосредственно от предметной области инвариантно среде и контексту, то эти 20 % способны угробить весь проект.

Для снижения рисков такого рода в конце 1980-х годов была предложена спиральная модель софтостроения.

Необходимо отличать спиральнуюмодель от итеративной. Спиральная модель сходится в точку «система готова», итеративная модель в общем случае не сходится, но обеспечивает реализацию всё новых и новых требований.