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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю [41]. Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба "Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?" способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!

Подсказка 52: Работайте с пользователем, чтобы мыслить категориями пользователя

Добыча полезных требований важна – в это время начинают складываться связи с вашим пользовательским ядром, изучаются их ожидания и надежды на создаваемую вами систему. Более подробно это обсуждается в разделе "Большие надежды".

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

Ивар Джекобсон [Jac94] предложил концепцию "сценариев использования системы" для фиксирования требований. Они позволяют описывать частные случаи использования системы не с точки зрения пользовательского интерфейса, а в более абстрактном виде. К сожалению, книга И. Джекобсона несколько расплывчата в деталях, поэтому в настоящее время не существует единого мнения о том, что же считать "сценарием использования системы". Что это – формальный или неформальный термин, прозаический или структурированный документ (подобный канцелярской форме)? Каким должен быть уровень детализации (помните, что у нас весьма широкая аудитория)?

В своей статье (журнал «Wired», январь 1999, с. 176) продюсер и музыкант Брайан Иноу описал чудо техники – новейший микшерный пульт. Этот пульт заставляет звучать все, что в принципе может звучать. И все же, вместо того, чтобы помочь музыкантам в создании лучших произведений или ускорить (или удешевить) процесс записи, он "путается под ногами", нарушая творческий процесс.

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

Эта среда характеризовалась требованием – усилить существующие навыки работы. Вместо того, чтобы раболепно дублировать то, что уже существует, нужно было обеспечить переход на новую ступень развития.

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

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

При рассмотрении сценариев использования системы стоит отметить их целенаправленную природу. Алистер Кокбэрн опубликовал статью, в которой описывается этот подход, а также шаблоны, используемые (строго или нестрого) при этом в качестве отправной точки ([Сос97а]; имеется Интернет-версия этой статьи [URL 46]). На рисунке 7.1. показан (в сокращении) пример подобного шаблона, на рис. 7.2 представлен пример сценария его использования.

Рис. 7.1. Шаблон сценария использования системы по А. Кокбэрну

A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ

– Цель в контексте

– Область действия

– Уровень

– Предусловия

– Условие успешного завершения

– Условие неудачного завершения

– Первичный действующий субъект

– Условие начала действия

B. ОСНОВНОЙ СЦЕНАРИЙ ПРИ УСПЕШНОМ ЗАВЕРШЕНИИ

C. РАСШИРЕНИЯ

D. ВАРИАНТЫ

E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ

– Приоритет

– Рабочая характеристика

– Частота

– Превосходящий прецедент использования

– Подчиненный прецедент использования

– Канал связи с первичным действующим субъектом

– Вторичные действующие субъекты

– Канал связи со вторичными действующими субъектами

F. РАСПИСАНИЕ

G. ОТКРЫТЫЕ ПРОБЛЕМЫ

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

Рис. 7.2. Пример сценария использования системы

ПРЕЦЕДЕНТ ИСПОЛЬЗОВАНИЯ № 5: ПРИОБРЕТЕНИЕ ТОВАРА

A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ

• Цель в контексте: Покупатель напрямую направляет коммерческий запрос в нашу фирму и ожидает отгрузки товаров и выставления счета за указанные товары.

• Область действия: Фирма

• Уровень: Итоговая информация

• Предусловия: Нам известен покупатель, его адрес, и т. д.

• Условие успешного завершения: Покупатель получает товары, мы получаем оплату.

• Условие неуспешного завершения: Мы не производим отгрузку товаров, покупатель не производит оплату.

• Первичный действующий субъект: Покупатель, любой агент (или компьютер), действующий от имени заказчика

• Условие начала действия: Получение запроса на приобретение товара.

B. ОСНОВНОЙ СЦЕНАРИЙ С УСПЕШНЫМ ЗАВЕРШЕНИЕМ

1. Покупатель обращается в фирму с запросом на приобретение товара.

2. Фирма фиксирует имя покупателя. его адрес, требуемые товары. и т. д.

3. Фирма предоставляет покупателю информацию о товарах, ценах, сроках поставки, и т. д.

4. Покупатель подтверждает заказ.

5. Фирма компонует заказ, отправляет заказ покупателю.

6. Фирма высылает покупателю счет-фактуру.

7. Покупатель оплачивает счет-фактуру.

C. РАСШИРЕНИЯ

3а. Один из пунктов заказа отсутствует у данной фирмы: Заказ переоформляется.

4а. Покупатель производит оплату непосредственно кредитной картой: Прием оплаты кредитной картой (прецедент использования № 44).

7а. Покупатель возвращает товар: Оформление возвращенного товара (прецедент использования № 105).

D. ВАРИАНТЫ

1. Покупатель может осуществить заказ по телефону, факсу, при помощи Интернет-формы (на странице), по другим сетям электронного обмена информацией.

7. Покупатель может оплатить заказ наличными денежным переводом, чеком, или кредитной картой.

E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ

• Приоритет: Высший

• Производительность: 5 минут на оформление заказа, оплата в течение 45 дней

• Частота: 200 заказов в день

• Превосходящий прецедент использования: Управление взаимоотношением с заказчиком (прецедент использования № 2).

• Подчиненные прецеденты использования: Компоновка заказа (прецедент использования № 15)

• Прием оплаты кредитной картой (прецедент использования № 44). Возврат товара покупателем (прецедент использования № 105).

• Канал общения с первичным действующим субъектом: по телефону, факсу или компьютерной сети.

• Вторичные действующие субъекты: компания – оператор платежной системы, банк, экспедиторская фирма.

F. РАСПИСАНИЕ

• Должная дата: Выпуск 1.0

G. ПРОБЛЕМЫ, ЯВЛЯЮЩИЕСЯ ОТКРЫТЫМИ

• Что происходит, если имеется лишь часть заказа?

• Что происходит, если кредитная карта похищена?

Подобного рода организация поддерживает иерархическое структурирование сценариев использования системы – вложение более подробных сценариев в сценарии более высокого уровня. Например, сценарии post debit и post credit дополняют друг друга в сценарии post transaction.

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

Рис. 7.3. Сценарии использования, выраженные UML, понятны даже ребенку!

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

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

Требования не являются архитектурой. Требования – это не конструкция, и не пользовательский интерфейс. Это потребность.

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

Но это не зависело от программистов и не являлось вопросом использования памяти. Если уж быть честным до конца, вина за это лежит на системных аналитиках и проектировщиках. "Проблема 2000 года" возникла по двум основным причинам: нежелание выйти за пределы существующей бизнес-практики и нарушение принципа DRY.

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

Подсказка 53: Абстракции живут дольше, чем подробности

Требует ли от вас фраза "Видеть перспективу", чтобы вы занялись предсказанием будущего? Нет. Это означает создание формулировок типа:

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

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

Вина за неудачи многих проектов возлагается на увеличение области их применения – это также называется раздуванием одной их характеристик, мелким улучшательством или размыванием требований. Это аспект синдрома лягушки из раздела "Суп из камней и сварившиеся лягушки" Что можно сделать для того, чтобы требования не поглотили нас?

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

К сожалению, немногие проекты могут похвастаться активным отслеживанием требований. Это означает, что они не имеют возможности сообщать об изменении в области действия – кто затребовал средство, кто утвердил его, каково общее число утвержденных запросов и т. д.

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

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

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

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

Подсказка 54: Используйте глоссарий проекта

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

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

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

Распространение с помощью сети Интернет также позволит избежать создания толстенных отчетов под названием "Анализ требований", которые никто никогда не прочтет и которые устаревают в тот момент, когда первая капля чернил смачивает лист бумаги.

Если этот материал есть в Сети, то программисты даже могут его прочесть.

• Суп из камней и сварившиеся лягушки

• Довольно приличные программы

• Круги и стрелки

• Все эти сочинения

• Большие надежды

• Можете ли вы использовать программы, которые сами пишете? Можно ли обладать хорошим чутьем на требования, будучи неспособным использовать программы самостоятельно?

• Выберите проблему (не связанную с информатикой), которую вам необходимо решить в данный момент. Сгенерируйте требования для решения, не требующего наличия компьютера.

42. Какие из нижеследующих примеров, по всей вероятности, являются требованиями? Переформулируйте те, которые таковыми не являются, для придания им большей пользы (если это возможно). (Ответ см. в Приложении В.)

1. Время отклика не должно превышать 500 мс.

2. Цвет фона диалогового окна будет серым.

3. Приложение будет организовано в виде нескольких внешних процессов и внутреннего сервера.

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

5. Приложение и данные должны умещаться в пределах 256 Кбайт.

Однажды царь Фригии Гордий завязал узел, который никто не мог развязать. Было предсказано, что тот, кто сможет развязать его, станет властелином всей Азии. И вот пришел Александр Македонский, который разрубил узел своим мечом. Несколько иная интерпретация требований и все – он стал властителем всей Азии.

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

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

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

Конечно же, нет. Разгадка находится в совершенно другом месте. Секрет разгадки головоломки состоит в идентификации реальных (а не воображаемых) ограничений и поиске решения, исходя из этих ограничений, некоторые из которых абсолютны, а другие являются лишь предвзятыми мнениями. Абсолютные ограничения обязаны соблюдаться, какими бы неприятными и нелепыми они ни казались. С другой стороны, некоторые очевидные ограничения в реальности могут таковыми и не являться. Например, существует старый фокус, который обычно демонстрируется в баре: вы берете закупоренную бутылку шампанского и спорите, что можете пить из нее пиво. Фокус заключается в том, что вы переворачиваете бутылку донышком вверх и наливаете немного пива в углубление на донышке. Многие проблемы в программировании можно разрешить подобным оригинальным способом.

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

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

Например, можете ли вы соединить все четыре точки (см. рисунок ниже) тремя прямыми линиями и вернуться в исходную точку, не отрывая карандаша от бумаги и не проводя одной и той же линии дважды [Но178]?

Вы обязаны бросить вызов любым предвзятым мнениям и оценить, являются ли они реальными, раз и навсегда установленными ограничениями.

Неважно, как вы мыслите – в пределах ящика или за его пределами. Проблема заключается в нахождении ящика – распознавании реальных ограничений.

Подсказка 55: Не размышляйте вне ящика – найдите этот ящик

Столкнувшись с серьезной проблемой, представьте все возможные направления, в которых вы можете двигаться. Не отвергайте никакие варианты, какими бы бесполезными или глупыми они ни казались. Теперь просмотрите весь список и объясните, почему нельзя идти по тому или иному пути. Вы уверены в этом? Можете ли это доказать?

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

Между прочим, решение головоломки с четырьмя точками представлено в Приложении В.

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

• Существует ли более простой способ?

• Вы пытаетесь решить главную проблему или отвлекаетесь на второстепенные технические детали?

• Почему это является проблемой?

• Что делает эту проблему столь сложной для решения?

• Стоит ли делать это именно таким образом?

• Стоит ли это делать вообще?

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

Все, что вам нужно, – это знание реальных ограничений, вводящих вас в заблуждение, и мудрость, позволяющая отличить одно от другого.

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

• Когда вы получили проект, которым занимаетесь в настоящее время, то прилагался ли к нему набор ограничений?

Тот, кто колеблется, иногда спасается

(Джеймс Тэрбер, Стекло на поле)

Великим лицедеям присуща одна общая черта: они знают, когда начинать, а когда подождать. Прыгун в воду стоит на трамплине, ожидая подходящего момента для прыжка. Дирижер стоит за пультом с поднятыми руками, пока не почувствует, что пора начинать.

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

Подсказка 56: Прислушайтесь к сомнениям – начинайте тогда, когда полностью готовы

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

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

Каждый испытывает страх перед чистым листом бумаги. Начало нового проекта (или даже новый модуль в существующем проекте) может лишить вас спокойствия. Многие из нас предпочли бы отложить момент связывания себя обязательствами. Но вы же не можете заявить, что вы просто оттягиваете начало работы?

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

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

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

Это звучит несколько цинично, но начало работ по созданию прототипа может быть более политкорректно, нежели примитивное высказывание типа "Я не настроен на начало работы" с последующим запуском игры "пасьянс".

• Обсудите синдром "страха начала работы" с вашими коллегами. Испытывают ли они тот же самый синдром? Принимают ли они его во внимание? Какие приемы они используют для его преодоления? Может ли группа преодолеть сопротивление отдельной личности, или это будет давлен и ем со стороны команды?

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

(Цитата из докладной записки авиакомпании British Airways, опубликованная в журнале "Pilot Magazine", декабрь 1996 г.)

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

Составление спецификации – это большая ответственность.

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

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

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

Проблемный вопрос для вас. Напишите короткую инструкцию по завязыванию бантиком шнурков на ботинках. Попробуйте!

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

Подсказка 57: Некоторые вещи лучше сделать, чем описывать

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

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

Поймите нас правильно, мы не против искусственного генерирования спецификаций. Разумеется, мы признаем, что в ряде случаев необходимы невероятно подробные спецификации – в силу причин, обусловленных контрактом, из-за операционной системы, в которой вы работаете, или природы самого продукта, разработкой которого вы занимаетесь [43]. Просто осознайте, что по мере того как спецификации становятся все более подробными, их доходность начинает убывать, а то и уходит в минус. Кроме того, будьте осторожны при составлении многослойных спецификаций, нижние уровни которых не обеспечены реализацией или прототипами; слишком легко составить спецификацию того, что невозможно построить.

Чем дольше вы будете позволять спецификациям оставаться защитной оболочкой, предохраняющей разработчиков от кошмарного мира составления программ, тем сложнее будет перейти к решению задач, возникающих при составлении программ. Не окажитесь в этой спирали спецификации: в некоторой точке вам придется начать программирование! Если ваша команда будет облачена в теплые, удобные спецификации, разорвите эти оковы. Подумайте о создании прототипов или о разработке с использованием метода "стрельбы трассирующими".

• Стрельба трассирующими

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

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

[Фотографии] с кругами и стрелками и несколькими строками на обратной стороне, объясняющими, кто есть кто, должны были стать свидетельством против нас…

(Арло Гатри, Ресторан Алисы)

Начиная со структурного программирования, через бригады главного программиста, CASE-средства, разработку методом «водопада», спиральную модель, метод Джексона, диаграмму «сущность-связь», облака Буча, метод объектного моделирования, метод Objectory, метод Коуда/Йордона до современного языка UML информатика никогда не страдала от недостатка методов, стремившихся уподобить программирование инженерной дисциплине. Каждый метод имеет своих приверженцев, и каждый из них переживает период популярности. Затем ему на смену приходит следующий. Долгая жизнь была суждена возможно лишь одному из всех этих методов – структурному программированию.

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

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

Подсказка 58: Не будьте рабом формальных методов

Формальные методы имеют ряд серьезных недостатков.

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

• Похоже, что формальные методы поощряют специализацию. Одна группа людей работает над моделью данных, другие занимаются архитектурой, в то время как сборщики требований коллекционируют сценарии использования (или их эквивалент). Мы видели, как это приводило к плохому взаимодействию и трате усилий впустую. Кроме того, существует тенденция впадать в умонастроение типа "мы против них" – проектировщики против программистов. Мы же предпочитаем воспринимать систему, над которой работаем, целиком. Скорее всего, невозможно будет глубоко проникнуть в суть каждого аспекта системы, но вы обязаны знать, как взаимодействуют между собой компоненты, куда помещены данные и каковы требования.

• Мы предпочитаем создавать настраиваемые динамичные системы, используя метаданные, позволяющие изменять характер приложений в ходе их выполнения. Большинство современных формальных методов сочетают модель статического объекта или данных с некоторой разновидностью механизма построения диаграммы событий или процесса. Мы пока не встречали механизма, позволяющего отображать динамизм, ожидаемый от систем. На самом деле большинство формальных методов уводят в сторону, поощряя стремление к заданию статических отношений между объектами, которые на самом деле должны быть связаны между собой динамически.

В своей статье в журнале САСМ [Gla99b], написанной в 1999 г., Роберт Гласе сделал обзор исследований улучшений в производительности и качестве, достигнутых благодаря семи различным технологиям разработки программ (технология 4GL, структурные методики, CASE-средства, формальные методы, методология "чистой комнаты", модели процессов и ООТ). Он сообщает, что первоначальное оживление, связанное со всеми этими методами, было преувеличено. Хотя существуют указания на то, что у некоторых методов есть преимущества, эти преимущества начинают проявляться только после существенного снижения производительности и качества, в период принятия технологии на вооружение и обучения пользователей.

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

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

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

Подсказка 59: Дорогие инструменты не всегда создают лучшие решения

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

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

• Диаграммы сценариев использования являются частью процесса UML при сборе требований (см. "Карьер для добычи требований"). Являются ли они эффективным способом взаимодействия с вашими пользователями? Если нет, то почему вы их используете?

• Как вы можете объяснить пользу, которую приносит формальный метод вашей команде? Чем вы можете ее измерить? В чем состоит улучшение? Можете ли вы провести различие между пользой от инструментального средства и возросшим опытом сотрудников вашей команды?

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

• Годятся ли инструментальные средства, применяемые в крупномасштабных проектах, для малых проектов? Верно ли обратное?

Примечания:

4

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

41

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

42

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

43

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