hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								470m
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
Глава 19. СпецификацииClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Составление спецификаций делает вашу информацию:

Лучше защищенной

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

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

Доступной

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

Более точной

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

Типы спецификаций

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

Благодаря этому выход одной спецификации естественно перетекает в содержимое следующей, оставляя документальный след в фарватере быстро развивающегося программного продукта. Пример такого бу% мажного следа приведен на рис. 19.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
471Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Спецификации

Спецификация

всех подсистем

проекта

План

Архитектор/

тестирования

программного

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

Спецификация

блока

подсистем

Спецификация

Функциональная

тестирования

архитектуры

спецификация

Спецификация

проекта

Спецификация

Функциональная

Спецификация

Функциональная

требований

спецификация

проекта

спецификация

Спецификация

тестирования

Спецификация

Функциональная

интерфейса

спецификация

пользователя

Спецификация

проекта

Спецификация

тестирования

План тестирования

Спецификация

тестирования

интеграции компонент

и окончательного продукта

Рис. 19.1. Типичное документальное свидетельство спецификаций

Так как разработка программного обеспечения является итеративным процессом, этот поток информации не направлен в одну сторону (иначе вы попадаете в узкие рамки каскадной методологии – см. «Каскадная модель» на стр. 539). Если вы обнаруживаете, что не хватает какой%то информации, или нужно скорректировать конструкцию программы, в спецификацию должны быть внесены соответствующие изменения. Если изменение и сопровождение документации затруднены, это пло% хо отражается на разработке. Бюрократические процедуры стремятся удушить разработку хороших программ требованием, чтобы вся работа проводилась согласно Спецификации, даже если ей 10 лет и она полно% стью устарела. Хорошие программисты считают свои спецификации таким же податливым материалом, как их код.

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

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

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								472m
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
Глава 19. СпецификацииClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

1.3.5. Интерфейс пользователя должен представлять собой чер# ный прямоугольник с текстом «Без паники», показанным крас# ным шрифтом sans#serif кеглем 13 пунктов.

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

Мы должны рассмотреть:

Функциональные требования

Эти требования детализируют, что должна делать программа. На% пример: Должна обрабатывать изображения в формате BMP и пре# образовывать их в JPEG или GIF.

Требования к производительности

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

Требования к совместимости

Описывают прочие программные, аппаратные и внешние системы, с которыми должен взаимодействовать программный продукт. На% пример: Должен поддерживать связь по HTTP и RS232 с сервером обновления.

Требования к будущим функциям

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

Эти требования делятся на две части. Дискретные требования носят двоичный характер. Взглянув на исходный код, легко проверить, удо%

				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
473Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

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

Заказчик должен одобрить и подписать спецификацию требований; она, в сущности, представляет собой контракт между разработчиком программного обеспечения и его клиентом. Изготовитель обязуется поставить продукт, функциональность которого отвечает специфика% ции, а клиент согласен оплатить его. Без согласованной специфика% ции клиент может отказаться от продукта по своей прихоти, и разра% ботчики потратят впустую массу труда. Увы, это обычная проблема производства программ, с которой я неоднократно встречался, особен% но часто возникающая в тех случаях, когда заказчик не является тех% ническим специалистом и не представляет себе, каким должно быть хорошее программное решение. Когда требуемая программа наконец% то сделана, заказчик осознает, что он просил сделать не то, что ему в действительности нужно: пишите все сначала. Вы вернулись на пер% вую клетку. Такие вещи случаются постоянно, поэтому спецификация требований – ваш страховой полис.

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

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

•Чтобы добиться большей удовлетворенности заказчика – путем оп% ределения того, на что он может рассчитывать.

•Чтобы уменьшить количество ошибок – ограничивая ползучий функ# ционализм, мы препятствуем изменениям в коде, осуществляемым

в последнюю минуту и приводящим к жутким ошибкам.