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

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

2.3.1. ПОСТАНОВКА ЗАДАЧИ

Задача может быть определена хорошо или плохо. Для плохо сформулированной задачи нельзя составить четкого проекта программы. К сожалению, большинство задач, подлежащих программированию, определено плохо ("Напишите программу, выдающую платежную ведомость"). Но если вам удастся четко определить задачу до этапа программирования, вы сэкономите много времени и избегните лишней работы.

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

Задачи, подлежащие программированию, обычно ставятся не теми, кто будет программировать. Имеются две причины, по которым программист приступает к работе без полного понимания задачи. Во-первых, заказчик, ставящий задачу, может не иметь четкого представления о ней; во-вторых, программист может не понять, чего хочет заказчик. Когда программист и постановщик, задачи — не одно лицо, первый вынужден работать с представлен нием второго о данной задаче.

Заказчик должен подготовить описание задачи. Это необходимо даже в том случае, если программист является одновременна и постановщиком задачи. Такое описание заставит заказчика серьезно обдумать задачу и четко определить ее постановку. Да-лее должно состояться обсуждение задачи программистом и заказчиком. Если задача достаточно сложна, то обсуждение лучше провести до того, как заказчик попытается описать задачу. Это поможет ему лучше оценить возможности вычислительной машины, а также программиста. Такое обсуждение часто помогает заказчику разобраться в своем представлении задачи.

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

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

Добивайтесь точности при определении задачи. "~

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