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

Другие разделы, относящиеся к данной теме:

• Ортогональность

• Генераторы исходных текстов

Вопросы для обсуждения

• Если в вашем распоряжении имеется функция-мастер построения графического интерфейса, воспользуйтесь ей для генерирования «скелета» приложения. Внимательно изучите каждую строку сгенерированной программы. Всели в ней вам понятно? Могли бы написать ее сами? Лучше написать ее самому, или же она делает то, что вам не нужно?

Глава 7 Перед тем, как начать проект

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

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

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

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

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

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

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

36 Карьер для добычи требований

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

Антуан де Сент-Экзюпери, Ветер, песок и звезды, 1939

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

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

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

В поисках требований

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

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

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

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

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

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

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