3.1.1 Требования

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

Важность определения предварительных условий

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

Конструирование - последний этап работы, поэтому ко времени начала конструирования успех проекта уже частично предопределен.

Для контроля качества на всех этапах разработки необходимо качественно выполнить планирование, определение требований и проектирование.

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

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

Влияние итеративных подходов на предварительные условия

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

Адекватное внимание к выполнению предварительных условий позволяет снизить затраты независимо от типа используемого подхода.

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

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