Стив Макконнелл

Вы можете выбрать более
последовательный подход (при котором вопросы решаются заблаговременно), если:
требования довольно стабильны;
проект приложения прост и относительно понятен;
группа разработчиков знакома с прикладной областью;
проект не связан с особым риском;
34
ЧАСТЬ I Основы разработки ПО
важна долговременная предсказуемость проекта;
затраты на изменение требований, проекта приложения и кода скорее всего
окажутся высокими.
Более итеративный подход (при котором вопросы решаются по мере работы)
можно предпочесть, если:
требования относительно непонятны или вам кажется, что они могут оказать#
ся нестабильными по другим причинам;
проект приложения сложен, не совсем ясен или и то и другое;
группа разработчиков незнакома с прикладной областью;
проект сопряжен с высоким риском;
долговременная предсказуемость проекта не играет особой роли;
затраты на изменение требований, проекта приложения и кода скорее всего
будут низкими.
Как бы то ни было, итеративные подходы эффективны гораздо чаще, чем после#
довательные.

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

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

Если вы планируете жестко следовать требованиям, на самом деле
вы собираетесь не реагировать на потребности клиента.

Исследования, проведенные в IBM и
других компаниях, показали, что при реализации среднего проекта тре#
бования во время разработки изменяются примерно на 25% (Boehm, 1981;
Jones, 1994; Jones, 2000), на что приходится 70–85% объема повторной работы над
типичным проектом (Leffingwell, 1997; Wiegers, 2003).

Возможно, вы считаете, что «Понтиак Ацтек» — самый великолепный автомобиль
из когда#либо созданных, являетесь членом Общества Верящих в Плоскую Землю
и каждые четыре года совершаете паломничество в Розуэлл, штат Нью#Мексико, на
место приземления инопланетян. Если это так, можете и дальше верить в то, что
требования в ваших проектах меняться не будут. Если же вы уже перестали верить
в Санта#Клауса или хотя бы прекратили признаваться в этом, вы можете кое#что
предпринять, чтобы свести зависимость от изменений требований к минимуму.

Избавившись от необ#

ходимости проводить праздничную церемонию каждый раз, когда оператор язы#

ка C делает то, что было задумано, вы сэкономите время

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

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

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