Страница:
только из интерфейсов и, возможно, каких-нибудь искусственных данных или
небольших контрольных примеров. Например, в систему может входить программа
сортировки, которая еще не закончена. Связанные с ней компоненты можно
тестировать с помощью фиктивной программы, которая просто читает и проверяет
формат входных данных и возвращает набор правильно отформатированных
бессмысленных, но упорядоченных данных.
Другой вид - мини-файл. Распространенным видом системной ошибки
является неправильное восприятие форматов ленточных и дисковых файлов.
Поэтому стоит создать несколько маленьких файлов, содержащих лишь несколько
типовых записей и все описания, указатели и т.п.
Предельный случай мини-файла - фиктивный файл, который фактически не
существует. Язык управляющих заданий OS/360 имеет такое средство, и оно
очень полезно для отладки компонентов.
Другой вид окружения - вспомогательные программы. Генераторы данных для
тестирования, печать специального анализа, анализаторы таблиц перекрестных
ссылок - все это примеры специальных приспособлений, которые может
потребоваться создать.13
Контролируйте изменения. Жесткий контроль во время тестирования
является впечатляющим методом отладки аппаратуры, с успехом применимым к
системам программирования.
Прежде всего, кто-то должен быть ответственным. Он, и только он должен
разрешать изменения в компонентах и замену одной версии другой.
Далее, как обсуждалось выше, система должна иметь контролируемые
экземпляры: один экземпляр с последними версиями, находящийся под замком и
используемый для тестирования компонентов; один тестируемый экземпляр с
установленными исправлениями; рабочие экземпляры каждого сотрудника для
внесения исправлений и дополнений в свои компоненты.
В технических моделях System/360 среди обычных желтых проводов можно
было иногда видеть фиолетовые провода. При обнаружении дефекта делались две
вещи. Быстро придумывалось исправление и устанавливалось в системе, чтобы
продолжить отладку. Это изменение делалось фиолетовыми проводами, так что
оно торчало как бельмо на глазу. Изменение регистрировалось в журнале. Тем
временем готовился официальный документ о внесении исправлений, который
запускался в жернова автоматизированного проектирования. В итоге это
выливалось в измененные чертежи и списки проводов и новую заднюю панель, в
которой изменения были сделаны на печатной плате или желтыми проводами.
Теперь физическая модель и документация соответствовали друг другу, и
фиолетовый провод исчезал.
Программированию тоже требуется технология фиолетовых проводов, и очень
требуется жесткий контроль и глубокое уважение к документу, который в
конечном счете, окажется продуктом. Неотъемлемыми составляющими такой
технологии являются регистрация всех изменений в журнале и заметное отличие
в исходном коде между заплатками на скорую руку и продуманными и
документированными исправлениями.
Добавляйте компоненты по одному. Этот рецепт также очевиден, но им
часто пренебрегают из-за оптимизма и лени. Чтобы следовать ему, требуются
фиктивные программы и разное окружение, а это отнимает время. И в конце
концов, вся эта работа может оказаться лишней! Может быть, ошибок и нет!
Нет! Противьтесь соблазну! Это то, в чем заключается систематичное
тестирование системы. Нужно предполагать, что ошибок будет много, и
планировать упорядоченную процедуру избавления от них.
Учтите, что нужно иметь полный набор контрольных примеров для проверки
частично собранных систем после добавления каждого компонента. Прежние
примеры, успешно выполненные на последней частичной сборке, нужно
перезапустить на новой, чтобы проверить, не ухудшилась ли система.
Квантуйте изменения. По мере созревания системы время от времени
начинают появляться разработчики компонентов, принося свежие версии своих
изделий - более быстрые, меньшие по размеру, более полные или
предположительно содержащие меньше ошибок. Замена работающего компонента
новой версией требует такой же систематической процедуры тестирования, как и
добавление нового компонента, хотя и требует меньше времени, поскольку
обычно уже имеются более полные и эффективные контрольные примеры.
Каждая команда, создающая новый компонент, использует новейшую версию
интегрированной системы в качестве среды для отладки своего компонента.
Проделанная работа будет отброшена назад, если эта среда изменится. Конечно,
она должна измениться. Но внесение изменений нужно производить квантами.
Тогда у каждого пользователя будут промежутки продуктивной стабильности,
прерываемые пакетным обновлением среды тестирования. Это оказывается
значительно менее разрушительным, чем постоянные волнения и дрожь.
Леман и Белади дают свидетельства в пользу того, что квант изменений
должен быть либо очень большим и редким, либо очень маленьким и частым.14
Последняя стратегия, согласно их модели, больше подвержена неустойчивости.
Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.
Квантовые изменения хорошо вписываются в технологию фиолетовых
проводов. Быстрая заплатка держится до следующей регулярной версии
компонента, которая должна содержать исправление в отлаженном и
документированном виде.
Никто не любит приносящего дурные вести.
СОФОКА
Как оказывается, что проект запаздывает на год?
... Сначала запаздывает на один день.
Когда слышишь о катастрофическом отставании проекта от графика, то
представляется ряд обрушившихся на него больших бедствий. Однако обычно
причиной катастрофы служат не смерчи, а термиты: отставание от графика
происходит незаметно, но неумолимо. На самом деле, с крупными бедствиями
справиться легче: используются крупные силы, коренная реорганизация,
изобретаются новые подходы. Вся команда поднимается на борьбу.
Отставание, растущее понемногу изо дня в день, труднее распознать,
труднее предотвратить, труднее исправить. Вчера не удалось провести
совещание из-за болезни ключевого работника. Сегодня выключены все машины,
потому что молния ударила в силовой трансформатор. Завтра не удастся начать
тестирование процедур работы с дисками, поскольку поставка с завода первого
диска задерживается на неделю. Снегопад, работа в суде присяжных, семейные
проблемы, экстренные встречи с клиентами, проверки руководством - список
бесконечен. Каждое событие задерживает какую-нибудь работу на полдня или
день. И растет отставание от графика, каждый раз еще на один день.
Вехи или помехи?
Как управлять большим проектом по жесткому графику? Прежде всего, надо
иметь график. У каждого из событий, называемых вехами, должна быть дата.
Выбор дат - уже обсуждавшаяся задача оценки, и он решающим образом зависит
от опыта.
Для выбора всех вех есть только одно пригодное правило. Вехами должны
служить конкретные особые события, которые можно идентифицировать с полной
определенностью. В качестве отрицательных примеров отметим, что написание
программы "закончено на 90 процентов" в течение половины всего времени
кодирования. Отладка "закончена на 99 процентов" почти всегда. "Планирование
завершено" - событие, которое можно объявить почти произвольно.1
Напротив, вехи должны быть 100-процентными событиями. "Спецификации
подписаны архитекторами и разработчиками", "исходный код готов на 100
процентов, отперфорирован и загружен в библиотеку на диске", "отлаженная
версия прошла все контрольные примеры". Такие конкретные вехи разграничивают
расплывчатые этапы планирования, кодирования и отладки.
Наличие четко очерченных границ и недвусмысленность важнее, чем
возможность легкой проверки начальником. Едва ли человек станет лгать о
прохождении вехи, если она очерчена столь ясно, что от не может себя
обманывать. А вот если веха расплывчата, начальник часто воспринимает доклад
иначе, чем тот, кто ему докладывает. Дополняя Софокла, скажем, что никто не
любит и сам приносить дурные вести, поэтому они смягчаются без злого
намерения ввести в заблуждение.
Два интересных исследования поведения правительственных подрядчиков по
проведению оценок в крупномасштабных исследовательских проектах показали:
1. Оценки продолжительности работы, тщательно проведенные и
пересматриваемые каждые две недели перед началом работы, не сильно меняются
по мере приближения начала работы, какими бы неверными они ни оказались в
конечном итоге.
2. После начала работы завышенные изначально оценки постоянно
уменьшаются по мере продвижения.
3. Заниженные оценки существенно не меняются, пока до запланированного
срока окончания работ не остается около трех недель.
Четко различимые вехи в действительности создают удобство команде,
которая должна рассчитывать, что менеджер их хорошо определит. С неясно
видимой вехой жизнь становится труднее. Это уже не веха, а мельничный
камень, перетирающий боевой дух, поскольку она вводит в заблуждение
относительно потерь времени, пока они не станут непоправимыми. А хроническое
отставание от графика угнетающе действует на моральное состояние.
"Другая часть тоже опаздывает"
Отставание от графика на один день - ну и что? Кого волнует отставание
на один день? Позже нагоним. Другая часть, в которую входит наша, тоже
отстает на один день.
Менеджер бейсбола считает энергию важным талантом, как для выдающихся
игроков, так и для выдающихся команд. Это способность бегать быстрее, чем
необходимо, передвигаться скорее, чем необходимо, стараться сильнее, чем
необходимо. Энергия важна и для выдающихся команд программистов. Она
обеспечивает упругость, резервную мощность, позволяющие команде справиться с
повседневными неприятностями, предвосхищать мелкие беды и уберегаться от
них. Рассчитанная реакция, размеренные усилия охлаждают энергию. Как мы
видели, нужно приходить в возбуждение из-за отставания на один день, ибо они
являются составляющими катастрофы.
Но не все отставания на один день одинаково катастрофичны. Поэтому
необходимо рассчитывать реакцию, хотя это и ослабляет энергию. Как отличить
отставания, которые существенны? Ничем нельзя заменить диаграммы ПЕРТ или
метод критического пути. Такая сеть показывает, кто находится в ожидании
каких событий. Она показывает, кто находится на критическом пути, на котором
любое отставание влечет перенос даты окончания. Она также показывает, какое
предельное отставание возможно для некоторой работы, прежде чем оно приведет
на критический путь.
Технология ПЕРТ, строго говоря, есть разработка графика работ с
критическим путями, когда для каждого события производятся три оценки,
соответствующие разным вероятностям уложиться в установленные сроки. Я не
думаю, что такое уточнение стоит затрачиваемых усилий, но для краткости
всякую сеть с критическим путями буду называть диаграммой ПЕРТ.
Подготовка диаграмм ПЕРТ есть самая ценная часть ее применения.
Определение топологии сети, указание зависимостей в ней и оценивание путей
заставляют выполнить большой объем очень конкретного планирования на самых
ранних стадиях проекта. Первая диаграмма всегда ужасна, и для создания
второй приходится проявить много изобретательности.
Во время выполнения проекта диаграмма ПЕРТ дает ответ на деморализующие
извинения типа "другая часть тоже запаздывает". Она показывает, когда
необходимо развить энергию, чтобы увести свою часть работы с критического
пути, и подсказывает способы наверстать потерянное время в других частях.
Под ковром
Когда менеджер низового звена видит, что его маленькая команда
отстает, он не склонен бежать к начальнику со своим горем. Возможно, команда
сумеет наверстать время, либо он сможет что-нибудь придумать или
реорганизовать для решения проблемы. Зачем же беспокоить этим начальника? До
поры до времени это допустимо. Для того и существуют менеджеры низового
звена, чтобы решать такие проблемы. А у начальника достаточно других забот,
требующих его вмешательства, чтобы искать новые. Так вся эта грязь
заметается под ковер.
Но каждому начальнику нужны два вида данных: информация о срывах плана,
которая требует вмешательства, и картина состояния дел, чтобы быть в курсе.3
С этой целью он должен знать положение дел во всех своих командах. Получить
правдивую картину нелегко.
В этом месте интересы менеджера низового звена и начальника вступают в
противоречие. Менеджер низового звена боится, что если он доложит начальнику
о возникшей у него проблеме, тот возьмется за нее сам. Его вмешательство
отнимет у менеджера его функции, уменьшит его власть и нарушит другие его
планы. Поэтому, пока менеджер считает, что может сам решить проблему, он не
докладывает о ней начальнику.
У начальника есть два способа заглянуть под коврик. Использовать нужно
оба. Первый - уменьшить конфликт ролей и стимулировать открытие информации.
Второй - сдернуть коврик.
Уменьшение конфликта ролей. В первую очередь начальник должен провести
различие между данными и действиях и данными о состоянии дел. Он должен
приучить себя не вмешиваться в проблемы, которые могут решить его менеджеры,
и никогда не вмешиваться в проблемы непосредственно во время изучения
состояния дел. Я знал одного начальника, который неизменно снимал трубку и
начинал давать указания, не дочитав до конца первый абзац отчета о состоянии
дел. При таких действиях вам обеспечено утаивание полных данных.
Напротив, если менеджер знает, что его начальник воспримет отчет без
паники или вмешательства, он будет давать честные оценки.
Весь этот процесс идет успешно, если начальник подчеркивает, что
совещания, заслушивания и конференции носят характер изучения состояния дел,
а не принятия мер по проблемам, и ведет себя соответствующим образом.
Очевидно, можно созвать совещание по принятию мер по результатам
заслушивания о состоянии дел, если возникает ощущение, что проблема вышла
из-под контроля. Но тогда по крайней мере все знают, что происходит, и
начальник дважды подумает, прежде чем взять управление на себя.
Сдергивание коврика. Тем не менее необходимо иметь способ узнать
истинное положение дел независимо от наличия стремления к сотрудничеству.
Основой такого изучения служит диаграмма ПЕРТ с часто расположенными вехами.
В большом проекте можно потребовать еженедельного изучения какой-либо части
ее, рассматривая всю диаграмму раз в месяц или около того.
Главным документом является отчет с указанием вех и степени их
фактического выполнения. (На рисунке 14.1 показан фрагмент такого отчета.)
Он может показывать отставание по некоторым позициям и служить в качестве
повестки дня совещания. Всем известны выносимые на него вопросы, и
соответствующие менеджеры готовы доложить о причинах отставания,
предполагаемых сроках завершения, принимаемых мерах, а также требуется ли
помощь от начальника или других групп, и если да, то какая.
В. Высоцкий из Bell Telephone Laboratories добавляет следующее
наблюдение:
Для меня оказалось удобным иметь в отчете о состоянии дел две даты -
"плановую" и "оцениваемую". Плановые даты принадлежат менеджеру проекта и
представляют собой последовательный план работы для проекта в целом, a
priori являющийся приемлемым. Оцениваемые даты принадлежат менеджерам
низшего звена, в переделах компетенции которых находятся рассматриваемые
участки, и представляют их мнения о сроке фактического наступления события
при имеющихся у них ресурсах и получении входных данных (или обязательствах
об их поставке). Менеджер проекта должен осторожно относиться к оцениваемым
датам и стремиться к получению точных, неискаженных оценок, а не
утешительно-оптимистичных или перестраховочно- консервативных данных. Если
эта позиция утвердится в умах, то менеджер
Рис. 14.1
проекта действительно сможет предвидеть, что он попадет в беду, если не
предпримет каких-нибудь мер.4
Создание диаграммы ПЕРТ является обязанностью начальника и подотчетных
ему менеджеров. Внесение в нее изменений, пересмотр и подготовка отчетности
должны осуществляться небольшой (от одного до трех человек) группой, как бы
продолжающей начальника. Такая группа планирования и контроля неоценима при
работе над большим проектом. Она не обладает иными полномочиями, кроме как
требовать от менеджеров низового звена предоставления сведений об установке
или изменении вех и их достижении. Поскольку группа планирования и контроля
осуществляет всю бумажную часть работы, нагрузка на менеджеров низового
звена ограничивается самым важным - принятием решений.
У нас была умелая, энергичная и дипломатичная группа планирования и
контроля, возглавлявшаяся А. М. Пьетрасанта (A. M. Pietrasanta), проявившим
значительные изобретательные способности для разработки эффективных, но
ненавязчивых методов контроля. В результате его группа пользовалась широким
уважением и хорошим отношением. Это немалое достижение для группы, которая
по природе своей должна вызывать раздражение.
Выделение небольшого числа подготовленных работников в группу
планирования и контроля приносит большую отдачу. Для успешного завершения
проекта это значительно лучше, чем если бы они непосредственно занимались
разработкой программных продуктов, так как группа планирования и контроля
стоит на страже того, чтобы неощутимые задержки стали видимыми, и
сигнализирует о критических положениях. Это система раннего обнаружения
потери года, происходящей день за днем.
Чего мы не понимаем, тем не владеем.
ГЕТЕ
О, дайте мне выступить комментатором,
Скользящим по поверхности и будоражащим умы.
КРАББ
омпьютерная программа - это послание человека машине. Строго
выстроенный синтаксис и тщательные определения нацелены на то, чтобы
бездумной машине стали понятны намерения человека.
Но у написанной программы есть обратная сторона: она должна быть в
состоянии рассказать о себе пользователю-человеку. Это требуется даже для
программы, написанной исключительно для собственных нужд, поскольку память
может изменить автору-пользователю, и ему потребуется освежить детали своего
труда.
Насколько же более необходима документация для программы общего
пользования, пользователь которой отдален от автора во времени, и в
пространстве! Для программного продукта сторона, обращенная к пользователю,
столь же важна, как и сторона, обращенная к машине.
Многие из нас бранили далекого безымянного автора за скудно
документированную программу. И многие поэтому пытались на всю жизнь привить
молодым программистам уважение к документации, преодолевающее лень и пресс
графика работ. В целом нам это не удалось. Я думаю, мы использовали неверные
методы.
Томас Дж. Уотсон Старший* (Thomas J. Watson, Sr.) рассказал мне историю
своего первого опыта в качестве продавца кассовых аппаратов в северной части
штата Нью-Йорк. Исполненный энтузиазма, он отправился в путь в своем
фургоне, нагруженном кассовыми аппаратами. Он прилежно объехал свой участок,
но ничего не продал. Обескураженный, он сообщил об этом своему хозяину.
Послушав некоторое время, управляющий сказал: "Помоги мне загрузить
несколько касс в фургон, запрягай лошадь, и поедем снова." Так они и
сделали, и обходя покупателей одного за другим, старик показывал, как
продавать кассовые аппараты. Судя по всему, урок пошел впрок.
Несколько лет я старательно читал группам инженеров-программистов
лекции о необходимости и желательности хорошей документации, увещевая их все
с большим пылом и красноречием. Это не подействовало. Я предположил, что они
поняли, как правильно составлять документацию, но не делали этого по
недостатку рвения. Тогда я попробовал погрузить в повозку несколько кассовых
аппаратов, т.е. показать им, как делается эта работа. Это имело значительно
больший успех. Поэтому оставшаяся часть этого повествования посвящена не
столько поучениям, сколько объяснению того, как делать хорошую документацию.
Какая документация требуется?
Необходимы различные уровни документации: для пользователя,
обращающегося к программе от случая к случаю, для пользователя, который
существенно зависит от программы в своей работе, и для пользователя, который
должен адаптировать программу к изменившемуся окружению или задачам.
Чтобы использовать программу. Каждому пользователю требуется словесное
описание программы. По большей части документация страдает отсутствие общего
обзора. Описаны деревья, прокомментированы кора и листья, но план леса *
Томас Дж. Уотсон Старший - основатель компании IBM (примеч. перев.)
отсутствует. Чтобы написать полезное текстовое описание, взгляните издалека,
а затем медленно приближайтесь:
1. Назначение. Что является главной функцией программы и причиной ее
написания?
2. Среда. На каких машинах, аппаратных конфигурациях и конфигурациях
операционной системы будет она работать?
3. Область определения и область значений. Каковы допустимые значения
входных данных? Какие правильные значения выходных результатов могут
появиться?
4. Реализованные функции и использованные алгоритмы. Что конкретно
может делать программа?
5. Форматы ввода-вывода, точные и полные.
6. Инструкция по работе, в том числе описание вывода на консоль и
устройство вывода при нормальном и аварийном завершении.
7. Опции. Какой выбор предоставляется пользователю в отношении функций?
Каким образом нужно его задавать?
8. Время работы. Сколько времени занимает решение задачи заданного
размера на заданной конфигурации?
9. Точность и проверка. Какова ожидаемая точность результатов? Какие
имеются средства проверки точности?
Часто все эти данные можно изложить на трех или четырех страницах. При
этом нужно уделить особое внимание полноте и точности. Большую часть этого
документа нужно вчерне написать до разработки программы, поскольку в нем
воплощены основные плановые решения.
Чтобы доверять программе. Описание того, как использовать программу,
нужно дополнить описанием того, как убедиться в ее работоспособности. Это
означает наличие контрольных примеров.
Каждый экземпляр поставляемой программы должен содержать несколько
небольших контрольных примеров, которые можно постоянно использовать, чтобы
уверить пользователя в том, что он может доверять программе, и она правильно
загружена в машину.
Кроме того, нужны более тщательные тесты, которые обычно выполняются
только после модификации программы. Они относятся к трем участкам области
входных данных:
1. Основные параметры, проверяющие главные функции программы на обычно
встречаемых данных.
2. Примеры на грани допустимого, проверяющие границы области входных
данных и убеждающие, что работают наибольшие значения, наименьшие значения и
все допустимые исключения.
3. Примеры за границей допустимого, проверяющие границы с обратной
стороны и убеждающие, что недопустимые значения вызывают правильные
диагностические сообщения.
Чтобы модифицировать программу. Для адаптации или исправления программы
требуется значительно больше данных. Разумеется, требуются все детали, а они
содержатся в хорошо прокомментированном листинге. У пользователя,
модифицирующего программу или редко ее использующего, возникает острая
необходимость в ясном отчетливом обзоре, на этот раз внутренней структуры. В
такой обзор входят:
1. Блок-схема или граф подпрограммной организации. Подробнее об этом
см. ниже.
2. Полные описания используемых алгоритмов или ссылки на такие описания
в литературе.
3. Разъяснение структуры всех используемых файлов.
4. Обзор организации прохождения данных - последовательности, в которой
данные или программы загружаются с ленты или диска и описание того, что
делается на каждом ходе.
5. Обсуждение модификаций, предполагаемых исходным проектом, сущность и
расположение добавочных блоков и выходов и дискурсивное обсуждение мыслей
автора программы относительно изменений, которые могут оказаться
желательными, и как их можно провести. Полезно также изложить его замечания
о скрытых ловушках.
Бич блок-схем
Блок-схема чаще всего является лишней частью программной документации.
Для многих программ блок-схемы вообще не нужны. Редкие программы требуют
блок- схемы более чем на одну страничку.
Блок-схемы показывают структуру принятия программой решений, что
является лишь одной стороной структуры программы. Когда блок-схема
размещается на одной странице, структура решений выглядит довольно
элегантно, но наглядность сразу утрачивается, когда есть несколько страниц,
связанных пронумерованными входами и выходами.
Одностраничная блок-схема для значительной по размеру программы
становится, в сущности, диаграммой структуры программы и этапов или шагов. В
небольших контрольных примеров. Например, в систему может входить программа
сортировки, которая еще не закончена. Связанные с ней компоненты можно
тестировать с помощью фиктивной программы, которая просто читает и проверяет
формат входных данных и возвращает набор правильно отформатированных
бессмысленных, но упорядоченных данных.
Другой вид - мини-файл. Распространенным видом системной ошибки
является неправильное восприятие форматов ленточных и дисковых файлов.
Поэтому стоит создать несколько маленьких файлов, содержащих лишь несколько
типовых записей и все описания, указатели и т.п.
Предельный случай мини-файла - фиктивный файл, который фактически не
существует. Язык управляющих заданий OS/360 имеет такое средство, и оно
очень полезно для отладки компонентов.
Другой вид окружения - вспомогательные программы. Генераторы данных для
тестирования, печать специального анализа, анализаторы таблиц перекрестных
ссылок - все это примеры специальных приспособлений, которые может
потребоваться создать.13
Контролируйте изменения. Жесткий контроль во время тестирования
является впечатляющим методом отладки аппаратуры, с успехом применимым к
системам программирования.
Прежде всего, кто-то должен быть ответственным. Он, и только он должен
разрешать изменения в компонентах и замену одной версии другой.
Далее, как обсуждалось выше, система должна иметь контролируемые
экземпляры: один экземпляр с последними версиями, находящийся под замком и
используемый для тестирования компонентов; один тестируемый экземпляр с
установленными исправлениями; рабочие экземпляры каждого сотрудника для
внесения исправлений и дополнений в свои компоненты.
В технических моделях System/360 среди обычных желтых проводов можно
было иногда видеть фиолетовые провода. При обнаружении дефекта делались две
вещи. Быстро придумывалось исправление и устанавливалось в системе, чтобы
продолжить отладку. Это изменение делалось фиолетовыми проводами, так что
оно торчало как бельмо на глазу. Изменение регистрировалось в журнале. Тем
временем готовился официальный документ о внесении исправлений, который
запускался в жернова автоматизированного проектирования. В итоге это
выливалось в измененные чертежи и списки проводов и новую заднюю панель, в
которой изменения были сделаны на печатной плате или желтыми проводами.
Теперь физическая модель и документация соответствовали друг другу, и
фиолетовый провод исчезал.
Программированию тоже требуется технология фиолетовых проводов, и очень
требуется жесткий контроль и глубокое уважение к документу, который в
конечном счете, окажется продуктом. Неотъемлемыми составляющими такой
технологии являются регистрация всех изменений в журнале и заметное отличие
в исходном коде между заплатками на скорую руку и продуманными и
документированными исправлениями.
Добавляйте компоненты по одному. Этот рецепт также очевиден, но им
часто пренебрегают из-за оптимизма и лени. Чтобы следовать ему, требуются
фиктивные программы и разное окружение, а это отнимает время. И в конце
концов, вся эта работа может оказаться лишней! Может быть, ошибок и нет!
Нет! Противьтесь соблазну! Это то, в чем заключается систематичное
тестирование системы. Нужно предполагать, что ошибок будет много, и
планировать упорядоченную процедуру избавления от них.
Учтите, что нужно иметь полный набор контрольных примеров для проверки
частично собранных систем после добавления каждого компонента. Прежние
примеры, успешно выполненные на последней частичной сборке, нужно
перезапустить на новой, чтобы проверить, не ухудшилась ли система.
Квантуйте изменения. По мере созревания системы время от времени
начинают появляться разработчики компонентов, принося свежие версии своих
изделий - более быстрые, меньшие по размеру, более полные или
предположительно содержащие меньше ошибок. Замена работающего компонента
новой версией требует такой же систематической процедуры тестирования, как и
добавление нового компонента, хотя и требует меньше времени, поскольку
обычно уже имеются более полные и эффективные контрольные примеры.
Каждая команда, создающая новый компонент, использует новейшую версию
интегрированной системы в качестве среды для отладки своего компонента.
Проделанная работа будет отброшена назад, если эта среда изменится. Конечно,
она должна измениться. Но внесение изменений нужно производить квантами.
Тогда у каждого пользователя будут промежутки продуктивной стабильности,
прерываемые пакетным обновлением среды тестирования. Это оказывается
значительно менее разрушительным, чем постоянные волнения и дрожь.
Леман и Белади дают свидетельства в пользу того, что квант изменений
должен быть либо очень большим и редким, либо очень маленьким и частым.14
Последняя стратегия, согласно их модели, больше подвержена неустойчивости.
Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.
Квантовые изменения хорошо вписываются в технологию фиолетовых
проводов. Быстрая заплатка держится до следующей регулярной версии
компонента, которая должна содержать исправление в отлаженном и
документированном виде.
Никто не любит приносящего дурные вести.
СОФОКА
Как оказывается, что проект запаздывает на год?
... Сначала запаздывает на один день.
Когда слышишь о катастрофическом отставании проекта от графика, то
представляется ряд обрушившихся на него больших бедствий. Однако обычно
причиной катастрофы служат не смерчи, а термиты: отставание от графика
происходит незаметно, но неумолимо. На самом деле, с крупными бедствиями
справиться легче: используются крупные силы, коренная реорганизация,
изобретаются новые подходы. Вся команда поднимается на борьбу.
Отставание, растущее понемногу изо дня в день, труднее распознать,
труднее предотвратить, труднее исправить. Вчера не удалось провести
совещание из-за болезни ключевого работника. Сегодня выключены все машины,
потому что молния ударила в силовой трансформатор. Завтра не удастся начать
тестирование процедур работы с дисками, поскольку поставка с завода первого
диска задерживается на неделю. Снегопад, работа в суде присяжных, семейные
проблемы, экстренные встречи с клиентами, проверки руководством - список
бесконечен. Каждое событие задерживает какую-нибудь работу на полдня или
день. И растет отставание от графика, каждый раз еще на один день.
Вехи или помехи?
Как управлять большим проектом по жесткому графику? Прежде всего, надо
иметь график. У каждого из событий, называемых вехами, должна быть дата.
Выбор дат - уже обсуждавшаяся задача оценки, и он решающим образом зависит
от опыта.
Для выбора всех вех есть только одно пригодное правило. Вехами должны
служить конкретные особые события, которые можно идентифицировать с полной
определенностью. В качестве отрицательных примеров отметим, что написание
программы "закончено на 90 процентов" в течение половины всего времени
кодирования. Отладка "закончена на 99 процентов" почти всегда. "Планирование
завершено" - событие, которое можно объявить почти произвольно.1
Напротив, вехи должны быть 100-процентными событиями. "Спецификации
подписаны архитекторами и разработчиками", "исходный код готов на 100
процентов, отперфорирован и загружен в библиотеку на диске", "отлаженная
версия прошла все контрольные примеры". Такие конкретные вехи разграничивают
расплывчатые этапы планирования, кодирования и отладки.
Наличие четко очерченных границ и недвусмысленность важнее, чем
возможность легкой проверки начальником. Едва ли человек станет лгать о
прохождении вехи, если она очерчена столь ясно, что от не может себя
обманывать. А вот если веха расплывчата, начальник часто воспринимает доклад
иначе, чем тот, кто ему докладывает. Дополняя Софокла, скажем, что никто не
любит и сам приносить дурные вести, поэтому они смягчаются без злого
намерения ввести в заблуждение.
Два интересных исследования поведения правительственных подрядчиков по
проведению оценок в крупномасштабных исследовательских проектах показали:
1. Оценки продолжительности работы, тщательно проведенные и
пересматриваемые каждые две недели перед началом работы, не сильно меняются
по мере приближения начала работы, какими бы неверными они ни оказались в
конечном итоге.
2. После начала работы завышенные изначально оценки постоянно
уменьшаются по мере продвижения.
3. Заниженные оценки существенно не меняются, пока до запланированного
срока окончания работ не остается около трех недель.
Четко различимые вехи в действительности создают удобство команде,
которая должна рассчитывать, что менеджер их хорошо определит. С неясно
видимой вехой жизнь становится труднее. Это уже не веха, а мельничный
камень, перетирающий боевой дух, поскольку она вводит в заблуждение
относительно потерь времени, пока они не станут непоправимыми. А хроническое
отставание от графика угнетающе действует на моральное состояние.
"Другая часть тоже опаздывает"
Отставание от графика на один день - ну и что? Кого волнует отставание
на один день? Позже нагоним. Другая часть, в которую входит наша, тоже
отстает на один день.
Менеджер бейсбола считает энергию важным талантом, как для выдающихся
игроков, так и для выдающихся команд. Это способность бегать быстрее, чем
необходимо, передвигаться скорее, чем необходимо, стараться сильнее, чем
необходимо. Энергия важна и для выдающихся команд программистов. Она
обеспечивает упругость, резервную мощность, позволяющие команде справиться с
повседневными неприятностями, предвосхищать мелкие беды и уберегаться от
них. Рассчитанная реакция, размеренные усилия охлаждают энергию. Как мы
видели, нужно приходить в возбуждение из-за отставания на один день, ибо они
являются составляющими катастрофы.
Но не все отставания на один день одинаково катастрофичны. Поэтому
необходимо рассчитывать реакцию, хотя это и ослабляет энергию. Как отличить
отставания, которые существенны? Ничем нельзя заменить диаграммы ПЕРТ или
метод критического пути. Такая сеть показывает, кто находится в ожидании
каких событий. Она показывает, кто находится на критическом пути, на котором
любое отставание влечет перенос даты окончания. Она также показывает, какое
предельное отставание возможно для некоторой работы, прежде чем оно приведет
на критический путь.
Технология ПЕРТ, строго говоря, есть разработка графика работ с
критическим путями, когда для каждого события производятся три оценки,
соответствующие разным вероятностям уложиться в установленные сроки. Я не
думаю, что такое уточнение стоит затрачиваемых усилий, но для краткости
всякую сеть с критическим путями буду называть диаграммой ПЕРТ.
Подготовка диаграмм ПЕРТ есть самая ценная часть ее применения.
Определение топологии сети, указание зависимостей в ней и оценивание путей
заставляют выполнить большой объем очень конкретного планирования на самых
ранних стадиях проекта. Первая диаграмма всегда ужасна, и для создания
второй приходится проявить много изобретательности.
Во время выполнения проекта диаграмма ПЕРТ дает ответ на деморализующие
извинения типа "другая часть тоже запаздывает". Она показывает, когда
необходимо развить энергию, чтобы увести свою часть работы с критического
пути, и подсказывает способы наверстать потерянное время в других частях.
Под ковром
Когда менеджер низового звена видит, что его маленькая команда
отстает, он не склонен бежать к начальнику со своим горем. Возможно, команда
сумеет наверстать время, либо он сможет что-нибудь придумать или
реорганизовать для решения проблемы. Зачем же беспокоить этим начальника? До
поры до времени это допустимо. Для того и существуют менеджеры низового
звена, чтобы решать такие проблемы. А у начальника достаточно других забот,
требующих его вмешательства, чтобы искать новые. Так вся эта грязь
заметается под ковер.
Но каждому начальнику нужны два вида данных: информация о срывах плана,
которая требует вмешательства, и картина состояния дел, чтобы быть в курсе.3
С этой целью он должен знать положение дел во всех своих командах. Получить
правдивую картину нелегко.
В этом месте интересы менеджера низового звена и начальника вступают в
противоречие. Менеджер низового звена боится, что если он доложит начальнику
о возникшей у него проблеме, тот возьмется за нее сам. Его вмешательство
отнимет у менеджера его функции, уменьшит его власть и нарушит другие его
планы. Поэтому, пока менеджер считает, что может сам решить проблему, он не
докладывает о ней начальнику.
У начальника есть два способа заглянуть под коврик. Использовать нужно
оба. Первый - уменьшить конфликт ролей и стимулировать открытие информации.
Второй - сдернуть коврик.
Уменьшение конфликта ролей. В первую очередь начальник должен провести
различие между данными и действиях и данными о состоянии дел. Он должен
приучить себя не вмешиваться в проблемы, которые могут решить его менеджеры,
и никогда не вмешиваться в проблемы непосредственно во время изучения
состояния дел. Я знал одного начальника, который неизменно снимал трубку и
начинал давать указания, не дочитав до конца первый абзац отчета о состоянии
дел. При таких действиях вам обеспечено утаивание полных данных.
Напротив, если менеджер знает, что его начальник воспримет отчет без
паники или вмешательства, он будет давать честные оценки.
Весь этот процесс идет успешно, если начальник подчеркивает, что
совещания, заслушивания и конференции носят характер изучения состояния дел,
а не принятия мер по проблемам, и ведет себя соответствующим образом.
Очевидно, можно созвать совещание по принятию мер по результатам
заслушивания о состоянии дел, если возникает ощущение, что проблема вышла
из-под контроля. Но тогда по крайней мере все знают, что происходит, и
начальник дважды подумает, прежде чем взять управление на себя.
Сдергивание коврика. Тем не менее необходимо иметь способ узнать
истинное положение дел независимо от наличия стремления к сотрудничеству.
Основой такого изучения служит диаграмма ПЕРТ с часто расположенными вехами.
В большом проекте можно потребовать еженедельного изучения какой-либо части
ее, рассматривая всю диаграмму раз в месяц или около того.
Главным документом является отчет с указанием вех и степени их
фактического выполнения. (На рисунке 14.1 показан фрагмент такого отчета.)
Он может показывать отставание по некоторым позициям и служить в качестве
повестки дня совещания. Всем известны выносимые на него вопросы, и
соответствующие менеджеры готовы доложить о причинах отставания,
предполагаемых сроках завершения, принимаемых мерах, а также требуется ли
помощь от начальника или других групп, и если да, то какая.
В. Высоцкий из Bell Telephone Laboratories добавляет следующее
наблюдение:
Для меня оказалось удобным иметь в отчете о состоянии дел две даты -
"плановую" и "оцениваемую". Плановые даты принадлежат менеджеру проекта и
представляют собой последовательный план работы для проекта в целом, a
priori являющийся приемлемым. Оцениваемые даты принадлежат менеджерам
низшего звена, в переделах компетенции которых находятся рассматриваемые
участки, и представляют их мнения о сроке фактического наступления события
при имеющихся у них ресурсах и получении входных данных (или обязательствах
об их поставке). Менеджер проекта должен осторожно относиться к оцениваемым
датам и стремиться к получению точных, неискаженных оценок, а не
утешительно-оптимистичных или перестраховочно- консервативных данных. Если
эта позиция утвердится в умах, то менеджер
Рис. 14.1
проекта действительно сможет предвидеть, что он попадет в беду, если не
предпримет каких-нибудь мер.4
Создание диаграммы ПЕРТ является обязанностью начальника и подотчетных
ему менеджеров. Внесение в нее изменений, пересмотр и подготовка отчетности
должны осуществляться небольшой (от одного до трех человек) группой, как бы
продолжающей начальника. Такая группа планирования и контроля неоценима при
работе над большим проектом. Она не обладает иными полномочиями, кроме как
требовать от менеджеров низового звена предоставления сведений об установке
или изменении вех и их достижении. Поскольку группа планирования и контроля
осуществляет всю бумажную часть работы, нагрузка на менеджеров низового
звена ограничивается самым важным - принятием решений.
У нас была умелая, энергичная и дипломатичная группа планирования и
контроля, возглавлявшаяся А. М. Пьетрасанта (A. M. Pietrasanta), проявившим
значительные изобретательные способности для разработки эффективных, но
ненавязчивых методов контроля. В результате его группа пользовалась широким
уважением и хорошим отношением. Это немалое достижение для группы, которая
по природе своей должна вызывать раздражение.
Выделение небольшого числа подготовленных работников в группу
планирования и контроля приносит большую отдачу. Для успешного завершения
проекта это значительно лучше, чем если бы они непосредственно занимались
разработкой программных продуктов, так как группа планирования и контроля
стоит на страже того, чтобы неощутимые задержки стали видимыми, и
сигнализирует о критических положениях. Это система раннего обнаружения
потери года, происходящей день за днем.
Чего мы не понимаем, тем не владеем.
ГЕТЕ
О, дайте мне выступить комментатором,
Скользящим по поверхности и будоражащим умы.
КРАББ
омпьютерная программа - это послание человека машине. Строго
выстроенный синтаксис и тщательные определения нацелены на то, чтобы
бездумной машине стали понятны намерения человека.
Но у написанной программы есть обратная сторона: она должна быть в
состоянии рассказать о себе пользователю-человеку. Это требуется даже для
программы, написанной исключительно для собственных нужд, поскольку память
может изменить автору-пользователю, и ему потребуется освежить детали своего
труда.
Насколько же более необходима документация для программы общего
пользования, пользователь которой отдален от автора во времени, и в
пространстве! Для программного продукта сторона, обращенная к пользователю,
столь же важна, как и сторона, обращенная к машине.
Многие из нас бранили далекого безымянного автора за скудно
документированную программу. И многие поэтому пытались на всю жизнь привить
молодым программистам уважение к документации, преодолевающее лень и пресс
графика работ. В целом нам это не удалось. Я думаю, мы использовали неверные
методы.
Томас Дж. Уотсон Старший* (Thomas J. Watson, Sr.) рассказал мне историю
своего первого опыта в качестве продавца кассовых аппаратов в северной части
штата Нью-Йорк. Исполненный энтузиазма, он отправился в путь в своем
фургоне, нагруженном кассовыми аппаратами. Он прилежно объехал свой участок,
но ничего не продал. Обескураженный, он сообщил об этом своему хозяину.
Послушав некоторое время, управляющий сказал: "Помоги мне загрузить
несколько касс в фургон, запрягай лошадь, и поедем снова." Так они и
сделали, и обходя покупателей одного за другим, старик показывал, как
продавать кассовые аппараты. Судя по всему, урок пошел впрок.
Несколько лет я старательно читал группам инженеров-программистов
лекции о необходимости и желательности хорошей документации, увещевая их все
с большим пылом и красноречием. Это не подействовало. Я предположил, что они
поняли, как правильно составлять документацию, но не делали этого по
недостатку рвения. Тогда я попробовал погрузить в повозку несколько кассовых
аппаратов, т.е. показать им, как делается эта работа. Это имело значительно
больший успех. Поэтому оставшаяся часть этого повествования посвящена не
столько поучениям, сколько объяснению того, как делать хорошую документацию.
Какая документация требуется?
Необходимы различные уровни документации: для пользователя,
обращающегося к программе от случая к случаю, для пользователя, который
существенно зависит от программы в своей работе, и для пользователя, который
должен адаптировать программу к изменившемуся окружению или задачам.
Чтобы использовать программу. Каждому пользователю требуется словесное
описание программы. По большей части документация страдает отсутствие общего
обзора. Описаны деревья, прокомментированы кора и листья, но план леса *
Томас Дж. Уотсон Старший - основатель компании IBM (примеч. перев.)
отсутствует. Чтобы написать полезное текстовое описание, взгляните издалека,
а затем медленно приближайтесь:
1. Назначение. Что является главной функцией программы и причиной ее
написания?
2. Среда. На каких машинах, аппаратных конфигурациях и конфигурациях
операционной системы будет она работать?
3. Область определения и область значений. Каковы допустимые значения
входных данных? Какие правильные значения выходных результатов могут
появиться?
4. Реализованные функции и использованные алгоритмы. Что конкретно
может делать программа?
5. Форматы ввода-вывода, точные и полные.
6. Инструкция по работе, в том числе описание вывода на консоль и
устройство вывода при нормальном и аварийном завершении.
7. Опции. Какой выбор предоставляется пользователю в отношении функций?
Каким образом нужно его задавать?
8. Время работы. Сколько времени занимает решение задачи заданного
размера на заданной конфигурации?
9. Точность и проверка. Какова ожидаемая точность результатов? Какие
имеются средства проверки точности?
Часто все эти данные можно изложить на трех или четырех страницах. При
этом нужно уделить особое внимание полноте и точности. Большую часть этого
документа нужно вчерне написать до разработки программы, поскольку в нем
воплощены основные плановые решения.
Чтобы доверять программе. Описание того, как использовать программу,
нужно дополнить описанием того, как убедиться в ее работоспособности. Это
означает наличие контрольных примеров.
Каждый экземпляр поставляемой программы должен содержать несколько
небольших контрольных примеров, которые можно постоянно использовать, чтобы
уверить пользователя в том, что он может доверять программе, и она правильно
загружена в машину.
Кроме того, нужны более тщательные тесты, которые обычно выполняются
только после модификации программы. Они относятся к трем участкам области
входных данных:
1. Основные параметры, проверяющие главные функции программы на обычно
встречаемых данных.
2. Примеры на грани допустимого, проверяющие границы области входных
данных и убеждающие, что работают наибольшие значения, наименьшие значения и
все допустимые исключения.
3. Примеры за границей допустимого, проверяющие границы с обратной
стороны и убеждающие, что недопустимые значения вызывают правильные
диагностические сообщения.
Чтобы модифицировать программу. Для адаптации или исправления программы
требуется значительно больше данных. Разумеется, требуются все детали, а они
содержатся в хорошо прокомментированном листинге. У пользователя,
модифицирующего программу или редко ее использующего, возникает острая
необходимость в ясном отчетливом обзоре, на этот раз внутренней структуры. В
такой обзор входят:
1. Блок-схема или граф подпрограммной организации. Подробнее об этом
см. ниже.
2. Полные описания используемых алгоритмов или ссылки на такие описания
в литературе.
3. Разъяснение структуры всех используемых файлов.
4. Обзор организации прохождения данных - последовательности, в которой
данные или программы загружаются с ленты или диска и описание того, что
делается на каждом ходе.
5. Обсуждение модификаций, предполагаемых исходным проектом, сущность и
расположение добавочных блоков и выходов и дискурсивное обсуждение мыслей
автора программы относительно изменений, которые могут оказаться
желательными, и как их можно провести. Полезно также изложить его замечания
о скрытых ловушках.
Бич блок-схем
Блок-схема чаще всего является лишней частью программной документации.
Для многих программ блок-схемы вообще не нужны. Редкие программы требуют
блок- схемы более чем на одну страничку.
Блок-схемы показывают структуру принятия программой решений, что
является лишь одной стороной структуры программы. Когда блок-схема
размещается на одной странице, структура решений выглядит довольно
элегантно, но наглядность сразу утрачивается, когда есть несколько страниц,
связанных пронумерованными входами и выходами.
Одностраничная блок-схема для значительной по размеру программы
становится, в сущности, диаграммой структуры программы и этапов или шагов. В