Требования - Тактическое и оперативное планирование разработки интернет-приложения

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

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

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

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

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

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

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

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

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

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

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

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

Предварительные условия, связанные с определением проблемы

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

Предварительные условия, связанные с выработкой требований

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

Важность явного набора требований обусловлена несколькими причинами.

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

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

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

Адекватное определение требований - одно из важнейших условий успеха проекта.

Стабильность требований

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

Похожие статьи




Требования - Тактическое и оперативное планирование разработки интернет-приложения

Предыдущая | Следующая