hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Процессыm		разработки
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Требования

Проектирование

Реализация

Интеграция/тестирование

Сопровождение

Рис. 22.2. Традиционная каскадная модель

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
541Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

Следуя этой модели, непросто вернуться назад, чтобы внести измене% ния – как лососю нужно потратить массу времени и энергии, чтобы подняться вверх по течению. Но у лосося для этого есть генетическая программа, а у программиста ее нет. Это означает, что данный процесс не будет полезен, если требуется сделать изменения на поздних стади% ях разработки. Требования должны быть зафиксированы до начала проектирования системы, а когда процесс уже пошел, модификации затруднены. Обычно проблемы проектирования обнаруживаются лишь на стадии тестирования системы.

В защиту этой модели нужно сказать, что она проста в управлении, по крайней мере теоретически, и служит основой большинства других мо% делей разработки. Каскадная модель плохо подходит для очень круп% ных проектов; она хороша для проекта длиной в пару недель. В иных моделях это учитывается и предлагается на протяжении проекта ис% пользовать несколько маленьких каскадных моделей.

SSADM и PRINCE

Хотя аббревиатура SSADM может вызвать подозрение, что участвовать в ней могут только совершеннолетние, на самом деле за ней скрывается

Structured Systems Analysis and Design Methodology – методология структурного системного анализа и проектирования. Это структу% рированный и строгий метод на основе каскадного подхода – видимо, наиболее регламентированный из всех вариантов каскадной модели.

Эта модель охватывает анализ и проектирование, но не реализацию и тестирование, и является хорошо определенным открытым стандар% том, широко применяемым в правительственных организациях Вели% кобритании. SSADM состоит из пяти основных ступеней (каждая из которых подразделяется на множество мелких процедур), названия

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								542m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 22. Рецепт программыClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

которых достаточно содержательны, чтобы в данной книге не останав% ливаться на них подробно:

•Технико%экономическое обоснование

•Анализ требований

•Спецификация требований

•Разработка логического проекта

•Физическое проектирование

Модели PRINCE (Projects In a Controlled Environment) и последовав% шая за ней PRINCE2 были разработаны в 1989 и 1996 годах с целью заменить SSADM. Подобно SSADM, эти модели являются тяжеловес% ными и документо%центрическими. Они перечисляют регламентиро% ванные шаги (на этот раз восемь фаз), следуя которым можно изгото% вить продукт, который должен удовлетворить заданным требованиям и стандартам качества.

VNмодель

Эта модель процесса основана на классической каскадной схеме и бы% ла разработана для управления процессами разработки программного обеспечения в правительственных и военных организациях Германии. Она имеет много общего с каскадной моделью (включая способность вызывать критику), но моделирует процесс не в виде каскада, а в виде буквы V, как на рис. 22.3.

Слева мы видим фазы разработки, ведущие к созданию программного продукта: планирование, проектирование и реализацию. Поток в пра% вой части управляет тестированием и одобрением.1 На каждом уровне тестирования происходит сравнение со спецификациями, созданными на соответствующей стадии слева.

Отличие V%модели от каскадной не только в ориентировке диаграммы. Этапы тестирования (в правой ветви) могут начинаться параллельно

Требования

Приемочное тестирование

Разработка архитектуры

Системное тестирование

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

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

Код

Компонентное тестирование

Рис. 22.3. V#модель

1Обратите внимание, что разработка течет в нижнюю сторону, как в водопа% де, а тестирование оказывается восхождением в гору – неплохая модель

разработки программ!

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Процессыm		разработки
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
543Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

с разработкой (левая ветвь) и приобретают равное с ней значение. Это хорошо, поскольку:

•Обычно тестирование сокращают на заключительном этапе опазды% вающего проекта. Это опасно. Этот факт отражается выделением тестирования как краеугольного камня процесса разработки, что помогает повысить качество продукта.

•Тестирование не должно ограничиваться конечным продуктом – необходимо рецензировать и проверять продукт на всех стадиях разработки, от анализа требований до законченной программы. В V%модели это отражено.

•На практике тестирование и исправление ошибок часто занимают больше половины общей длительности проекта. В каскадной моде% ли это не находит точного отражения.

•V%модель может помочь сократить общее время разработки, потому что позволяет осуществлять этапы тестирования как только завер% шится очередная стадия разработки. Такая параллельная работа дает возможность приблизить завершение проекта, потому что не нужно ждать окончания фазы реализации каскадной модели, что% бы начать тестирование.

Создание прототипов

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

Создание прототипов нацелено на то, чтобы обойти это ограничение. Прототипы помогают изучить и оценить реализацию в ходе разработ% ки и уточнить требования к системе (пользователи никогда не знают, что им нужно).

Суть процесса прототипирования заключается в создании нескольких временных прототипов системы. Каждый прототип оценивается, по% казывается клиенту, и отзывы клиента кладутся в основу следующего прототипа. Это продолжается, пока не будет получено достаточно зна% ний для разработки и развертывания реального продукта.

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								544m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 22. Рецепт программыClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

часть составляет разработка. Поэтому цикл прототипирования нужно ограничивать; нельзя повторять его бессчетное число раз.

Прототипы быстро разрабатываются на языках верхнего уровня. Ино% гда их просто рисуют: применение автоматизированных инструментов1 может невероятно ускорить создание прототипов. Прототипы нужны для доказательства правильности концепции, поэтому эффективность, стабильность или полнота функций не являются главными заботами при их разработке. В результате прототипы более эффективны для сис% тем, в которых большое значение имеет интерфейс пользователя.

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

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

Опасности прототипов

Выпуск прототипов в качестве продукта может вызвать серьез% ные проблемы сопровождения.

Одно время я сотрудничал с компанией, в которой существовала политика использования только одной библиотеки GUI для сво% их клиентов, написанных на Java. Но на практике в одних систе% мах эта библиотека использовалась, а в других – нет. Когда обна% руживалась ошибка, программистам сопровождения было очень трудно разобраться в работе клиентского кода. Других библио% тек GUI они не знали, и их исправления часто служили источни% ком новых проблем. Чем чаще это происходило, тем сильнее продукты компании теряли репутацию.

Не пришлось глубоко копать, чтобы выяснить причину проблем: клиентские части, использовавшие не ту библиотеку GUI, кото% рую нужно, были прототипами, лишь «по случайности» ставшие продуктами. Потратив какое%то время на выпуск правильного кода, можно было бы избежать многомесячной работы в буду% щем и сберечь репутацию компании.

1Например, средства быстрой разработки приложений (RAD) с простыми

построителями GUI.