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

Вот какие составляющие разработки ПО определили ученые за после#

дние 25 лет:

определение проблемы;

выработка требований;

создание плана конструирования;

разработка архитектуры ПО, или высокоуровневое проектирование;

детальное проектирование;

кодирование и отладка;

ГЛАВА 1 Добро пожаловать в мир конструирования ПО!

3

блочное тестирование;

интеграционное тестирование;

интеграция;

тестирование системы;

корректирующее сопровождение.

Если вы работали над неформальными проектами, то можете подумать, что этот

список весьма бюрократичен. Если вы работали над слишком формальными про#

ектами, вы это знаете!

Алгоритм предоставляет вам сами команды. Эвристика
сообщает вам, как обнаружить команды самостоятельно или по крайней мере где
их искать.

Самая сложная часть программиро#
вания — концептуализация проблемы, и многие ошибки программирования яв#
ляются концептуальными.

Инкрементное проектирование, конструирование и
тестирование — одни из самых эффективных концепций разработки ПО.
При инкрементной разработке вы сначала создаете самую простую версию систе#
мы, которую можно было бы запустить. Она может не принимать реальных дан#
ных, может не выполнять над ними реальных действий, может не генерировать
реальные результаты — она должна быть просто скелетом, достаточно крепким,
ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО
15
чтобы поддерживать реальную систему по мере ее разработки. Она может вызы#
вать поддельные классы для каждой из определенных вами основных функций. Такая
система похожа на песчинку, с которой начинается образование жемчужины.
Создав скелет, вы начинаете понемногу наращивать плоть. Каждый из фиктивных
классов вы заменяете реальным. Вместо того чтобы имитировать ввод данных, вы
пишете код, на самом деле принимающий реальные данные. А вместо имитации
вывода данных — код, на самом деле выводящий данные. Вы продолжаете добав#
лять нужные фрагменты, пока не получаете полностью рабочую систему.

Это печально, потому что, если

комбинировании см. раздел 5.3.

вы станете использовать только одну методологию, вы уви#

дите весь мир в терминах этой методологии. В некоторых случаях это сделает

недоступными для вас другие методы, лучше подходящие для решения текущей

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

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

Этот феномен известен как синдром WISCA или WIMP: «Why Isn’t Sam Coding
Anything? (Почему Сэм не пишет код?)» или «Why Isn’t Mary Programming (Почему
Мэри не программирует)?»

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

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

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