О постановке задачи
Выдержка из книги “Стиль, разработка, эффективность, отладка и испытание программ”. Приятно еще раз прочитать о важности к тому, как подходить к разработке программного обеспечения, о важности предварительных переговоров с заказчиков. Также важно начинать программирование в момент, когда, проще говоря, все друг друга поняли и зафиксировали договоренности в виде полной спецификации, которая также будет и основой для полной документации разрабатываемого программного обеспечения.
1. Описание задачи
Нет ничего хуже, чем неполное или неправильное определение требований к программному обеспечению. Если заказчики не могут определить свои запросы или если программист не может понять, чего хочет заказчик, то при разработке проекта можно ожидать серьезных затруднений.
Один из путей уточнения описания требований заказчика - это проведение регулярных просмотров для координации установленных требоавний и действительных намерений заказчика. В результате этих проверок могут быть обнаружены несоответствия, которые при отсутствии таких проверок выявились бы значительно позже. Следует отметить важность полноты и непротиворечивости предварительного проекта. Лучше проявить прагматизм в начале проектирования, чем потом вносить изменения.
2. Постановка задачи
Задача может быть определена хорошо или плохо. Для плохо сформулированной задачи нельзя составить четкого проекта программы. Увы, большинство задач определены плохо. Но если удастся четко определить задачу до этапа программирования, то можно сэкономить время и избежать лишней работы.
Если в проекте программы имеются пробелы, это обнаружится или во время программирования, или после передачи “завершенной” программы пользователю. После чего вносятся изменения в программу до соответствия проекту.
Задачи, подлежащие программированию, обычно ставятся не теми, кто будет программировать. Имеются две причины, по которым программист приступает к работе без полного понимания задачи. Во-первых, заказчик, ставящий задачу, может не иметь четкого представления о ней. Во-вторых, программист может не понять, чего хочет заказчик. Когда программист и заказчик - не одно лицо, первый вынужден работать с представлением второго о данной задаче. Если словами нельзя описать, что делает программа, то и запрограммировать ее нельзя. При отсутствии полного понимания образуется пустота, которую нужно заполнить. И часто бывает, что программист вынужден заполнять эту пустоту, основываясь на собственном видении того, что хочет заказчик. Часто это видение не совпадает.
Заказчик должен подготовить описание задачи. Это необходимо даже в том случае, если программист является одновременно и поставщиком задачи. Такое описание заставит заказчика серьезно обдумать задачу и четко определить ее постановку. Далее должно состояться обсуждение задачи программистом и заказчиком. Если задача достаточно сложна, то обсуждение лучше провести до того, как заказчик попытается описать задачу. Обсуждение часто помогает заказчику разобраться в своем представлении задачи.
Далее программист должен переписать спецификации задачи. Необходимо сжатое, но полное описание задачи. Объем может варьироваться от нескольких предложений до целой книги, в случае большой системы. Это описание является основой для большого количества документации.
Затем программист и заказчик должны вместе тщательно изучить написанные спецификации задачи, чтобы быть уверенным в правильном понимании. Необходимо удостовериться, что заказчик получит ровно то, что описано в спецификациях. А более поздние изменения приводят к удорожанию проекта и задерживают его завершение. Любая небрежность, допущенная на стадии определения задачи, вызовет впоследствии осложнения.
После того как задача определена, лучше всего заморозить спецификации и в дальнейшем не вносить в них каких-либо изменений или дополнений. Любой пересмотр откладывается на более позднее время. В том случае, если изменений вносятся после начала программирования, следует увеличить расходы и выделить дополнительное время на проектирование. Более того, эти дополнительные расходы должны быть достаточно высоки. Это один из способов контролировать изменения и предусматривать дополнительное время на их внесение. Многие проекты невозможно планировать из-за постоянно изменяющихся спецификаций. Заказчики должны дорого платить за все изменения. Это заставит их более тщательно составлять спецификации.