Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

У вас никогда не возникало ощущения, что ваш проект обречен еще до его начала? Иногда так и происходит, если вначале вы не установите некоторые основополагающие правила. В противном случае вы можете объявить проект закрытым и сэкономить спонсору некоторую сумму.

В самом начале проекта вам придется определить требования. Недостаточно лишь выслушать пользователей, необходимо прочесть раздел «Карьер для добычи требований».

Житейская мудрость и управление сдерживающими факторами являются основными темами раздела «Разгадка невероятных головоломок». Неважно, какую операцию вы осуществляете – анализ, составление текста программы или тестирование, проблемы возникают все равно. Чаще они не будут настолько сложными, какими показались вначале.

Даже когда вы подумаете, что решили все проблемы, то все равно будете чувствовать неудобства, начав работать над проектом. Является ли это простым промедлением или чем-то большим? В разделе «Пока вы не готовы» предлагается совет – в какой момент благоразумно прислушаться к предостережению внутреннего голоса.

Слишком раннее начало – это проблема, но слишком долгое ожидание еще хуже. В разделе «Западня со стороны требований» обсуждаются преимущества создания спецификаций по образцу.

В разделе «Круги и стрелки» рассматриваются некоторые ловушки, в которые можно попасть при использовании формальных процессов и методологий. Неважно, насколько хорошо он продуман, и какие «лучшие случаи из практики» в нем использованы, – никакой метод не заменит мышления.

Если вы устраните эти критические аспекты до того, как проект будет запущен, вы лучше справитесь с «аналитическим параличом» и начнете выполнять реальный успешный проект.

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

Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.

Подсказка 51: Не собирайте требования – выискивайте их

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

Простой ответ состоит в том, что требование формулирует необходимость осуществления чего-либо. Грамотно составленное требование выглядит следующим образом:

• Доступ к личному делу сотрудника ограничен группой уполномоченных на то лиц.

• Температура головки блока цилиндров не должна превышать определенного критического значения, зависящего от марки двигателя.

• Редактор выделяет ключевые слова, выбор которых зависит от типа редактируемого файла.

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

Первая формулировка в списке, приведенном выше, вероятно, была составлена пользователями следующим образом: «Доступ к личному делу сотрудника ограничен его руководителями и работниками отдела кадров». Является ли эта формулировка требованием? Возможно, что сегодня и является, но она воплощает бизнес-политику в абсолютной формулировке. Политика же регулярно меняется, поэтому, скорее всего, мы не захотим жестко встраивать ее в наши требования. Мы рекомендуем документировать положения политики отдельно от требований и связывать их посредством гиперссылки. Сделайте требование общей формулировкой и снабдите разработчиков информацией о политике в качестве примера того, что им придется поддерживать в реализации. В конечном счете политика конечна, как и метаданные в приложении.

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