"В атом мире нет ничего постояннее непостоянства".
(Свифт)
"Общепринято выбрать метод, а затем опробовать его. Если он
неудачен,
оставьте его и испробуйте другой. Но как бы то ни было, не оставляйте попыток".
(Ф. Д, Рузвельт)
Опытные установки и увеличение масштабов
Инженеры-химики давно уже знают, что процесс, который идет в лаборатории, нельзя сразу передавать на завод. Необходим промежуточный шаг, опытная установка, для того чтобы проверить этот процесс в больших масштабах и в условиях, приближенных к реальным. Так, например, лабораторный метод опреснения воды следует сначала проверить на опытной установке мощностью 50 тыс. л воды в день, прежде чем использовать его в городской системе опреснения мощностью 10 млн. л в день.
Создатели систем программирования тоже получали подобные уроки, но, кажется, ничего из них не извлекли. Проект за проектом разрабатывают множество алгоритмов и приступают к созданию программного обеспечения для заказчиков по планам и графикам, предусматривающим поставки первого же готового варианта.
Обычно первая система довольно мало пригодна к использованию. Она может быть слишком медленной, слишком большой, неудобной в использовании или обладать всеми этими качествами одновременно. Нет другого выхода, кроме как начать все сначала, строже подойти к проекту и создать новый вариант, в котором эти недостатки будут ликвидированы. Отказ от старого и создание нового проекта можно осуществить в один этап, можно это делать и по частям. Однако весь опыт создания больших систем говорит, что сделать это придется 2). Каждый раз, когда используются новые концепции или новая техника, приходится создавать систему "на выброс", поскольку даже лучшие методы планирования но настолько хороши, чтобы сразу "те получалось то, что нужно.
Перед руководителем, следовательно, не стоит вопрос о том, надо ли создавать опытную систему, которую придется потом выбросить. Вы должны это сделать. Вопрос в том, нужно ли планировать с самого начала создание варианта па выброс, или же пообещать поставить этот вариант заказчику. Если есть возможность запланировать создание опытной системы, то ответ как нельзя более ясен. Поставка жо заказчику варианта "па выброс" экономит время, но только ценою мук пользователя, треног ч волнений разработчиков во время создания новых проектов и ценой репутации продукта, которую трудно будет исправить даже самым лучшим новым проектом. Следовательно, планируйте неудачу: она вас так или иначе найдет.
Постоянны только изменения
Если вы уже осознали, что придется построить опытную систему, а затем от нее отказаться, и что повторное проектирование с изменением всех идей неизбежно, то полезно теперь без страха взглянуть на сам феномен изменений. Первый шаг заключается в том, чтобы признать факт изменения как образ жизни, а не как тягостное и досадное недоразумение. Косгроув проницательно отмечал, что программист принимает заказы скорее на удовлетворение нужд пользователя, чем на какой-либо реальный осязаемый продукт. И как только реальная потребность пользователя удовлетворена, как только программы оказались написанными, отлаженными и начали использоваться, так мы обнаруживаем, что и нужды пользователя, и его оценка этих нужд приходят в движение 3).
Конечно, все это справедливо и в отношении потребностей, удовлетворяемых самыми разными машинами, будь то новые автомобили или новые вычислительные машины. Но само существование реального объекта сдерживает требования пользователей изменить что-либо и квантует их. А податливость программного продукта и его неосязаемость подставляют его создателей под нескончаемый поток изменений в требованиях.
Конечно, я далек от мысли, что все изменения в целях и требованиях заказчика должны, могут или могли бы быть воплощены в проекте. Следует установить какой-то порог, и чем дальше продвигаются разработки, тем выше он должен быть: в противном случае продукт так п не появится на свет. Тем не менее, некоторые изменения в целях и задачах неизбежны, и лучше быть готовым к ним, чем считать, что их не будет. Неизбежны изменения не только в целях, но н в стратегии и методах разработки. Концепция "работы в корзину" сама по себе является принятием того факта, что, научившись чему-то, мы вносим в проект изменения 4).
Планирование изменений в системе
Пути разработки системы, в которую легко вносить изменения, хорошо известны и широко обсуждаются в литературе - может быть даже шире, чем используются на практике. К ним относится тщательная моду-ляризация, широкое использование подпрограмм, точное и полное описание сопряжении между модулями и исчерпывающая документация. Менее очевидно использование стандартных вызывающих последовательностей и таблично-управляемых методов.
Для уменьшения числа ошибок, вызываемых изменениями, наиболее важным является использование языка высокого уровня и методов самодокументирования. Весьма полезным при внесении изменений в систему является использование операций периода компиляции для введения стандартных описаний.
Квантование изменений крайне важно. Каждый продукт должен иметь- пронумерованные версии, п каждая версия должна иметь свой график и дату замораживания, начиная с которой изменения переходят в следующую версию.
Планирование изменений в организации
Косгроув предлагает рассматривать все планы, вехи, графики как предварительные, что облегчает их изменения. Но это, пожалуй, уж слишком - и так самая общая беда в коллективах программистов сегодня заключается скорее в нехватке административного контроля, чем в его избытке.
Тем не менее Косгроув демонстрирует великолепную проницательность. Он отмечает, что отвращение к созданию проектной документации вызывается не только леностью пли нехваткой времени. Оно порождается нежеланием принимать решения и отстаивать их в тех случаях, когда разработчик прекрасно знает, что они предварительны. "Подготовив документацию проекта, разработчик выставляет себя на всеобщий суд, и потому он должен быть в состоянии отстаивать все им написанное до последнего слова. Если организационная структура хоть в какой-то мере уязвима, не стоит и пытаться ничего документировать до тех пор, пока она не станет полностью обороноспособной".
Создание динамичной структуры организации гораздо труднее, чем проектирование системы, подвергаемой изменениям. Каждому исполнителю нужно отвести такие задачи, которые расширяли бы его возможности, с тем, чтобы весь коллектив был гибкой силой. В большом проекте руководитель должен иметь в своем распоряжении двух-трех лучших программистов в качестве технической кавалерии, готовой поскакать на помощь туда, где решается судьба сражения.
Структуры управления также должны меняться по мере того, как изменяется система. А это означает, что начальник должен уделять как можно больше внимания тому, чтобы его руководители и технические специалисты были взаимозаменяемыми, насколько это позволяют их способности.
Барьеры носят социологический характер, и при их преодолении следует постоянно проявлять бдительность. Во-первых, сами руководители зачастую считают ведущих специалистов "слишком ценными" для того, чтобы использовать их непосредственно в программировании. Во-вторых, работа .в области административного управления имеет более высокий престиж. Чтобы справиться с этой проблемой, на некоторых предприятиях, например в фирме Bell Labs, отказались от каких бы то ни было титулов и званий. Каждый профессинальный служащий является "штатным техническим сотрудником". Другие, например, фирма IBM, имеют двойную лестницу продвижения по службе . Ступени теоретически эквивалентны.
Двойная лестница продвижения по службе в фирме IBM. Легко установить соответствия в заработной плате для каждой ступени. Гораздо трудное придать им соответствующий престиж. Кабинеты должны быть одинакового размера и одинаково обставлены. Секретариат и другие вспомогательные службы должны находиться на одном уровне. Перемещение с технической лестницы на соответствующий уровень административной никогда не должно сопровождаться повышением зарплаты, и оно всегда должно объявляться именно "перемещением", а не "продвижением по службе". Обратное перемещение всегда должно вести за собой повышение зарплаты.
Административных работников следует посылать на курсы, позволяющие им освежить технические знания, а главных технических специалистов следует обучать науке административного управления. Цели проекта, его прогресс и управленческие проблемы должны обсуждаться всеми ведущими специалистами.
Все главные специалисты должны быть профессионально и эмоционально готовы как к руководству группой, так и к тому, чтобы собственными руками написать программу. Это не так-то просто, но дело того стоит.
Сама идея организации коллективов программистов по принципу хирургической бригады является радикальной попыткой решения этой проблемы. Она позво ляет ведущему специалисту избавиться от ощущения, что написание программ роняет его достоинство, и пытается устранить социальные препятствия на его пути к этой творческой работе.
Кроме того, такая организация создается с целью минимизации числа сопряжении. Том самым максимально упрощается введение изменений в систему и относительно облегчается переход всей хирургической бригады к новой программистской задаче в случае необходимости организационных изменений. Проблема гибкой организации решается, таким образом, с далеким прицелом.
Два шага вперед, шаг назад
Программа сдана заказчику, по изменения в нее гродолжают вноситься. Внесение изменений в программу после ее сдачи называется сопровождением программы, однако этот процесс существенно отличается от эксплуатации оборудования.
Эксплуатация оборудования для вычислительной системы сводится к замене плохих элементов, к чистке и смазке и к внесению технических изменений, исправляющих дефекты разработки. (Не все, но большая часть технических изменений исправляет именно дефекты реализации или разработки, а не архитектуры, так что они незаметны для пользователя.)
Сопровождение программы не влечет за собой чистки, смазки или ремонта. Оно сводится в основном к внесению изменений, исправляющих дефекты разработки. Однако гораздо чаще, чем в случае оборудования, такие изменения включают в себя добавление новых функций. Обычно они прекрасно видны пользователю.
Стоимость сопровождения широко используемой программы составляет обычно 40 процентов стоимости ее разработки. Что удивительно, стоимость эта в значительной мере зависит от числа пользователей. Чем больше пользователей, тем больше они найдут ошибок.
Бетти Кэмпбелл из Лаборатории ядерной физики Массачусетского Технологического Института заметила интересный цикл жизни конкретного варианта программы. Первоначально старые ошибки, обнаруженные в предыдущих вариантах и уже устраненные в них, проявляют тенденцию к появлению в новом варианте. Новые функции нового варианта порождают новые ошибки. Эти ошибки вылавливаются, и несколько месяцев все идет хорошо. Но потом число ошибок опять начинает расти. Мисс Кемпбелл находит объяснение этому факту в том, что пользователи выходят на более высокий уровень и начинают полностью использовать все возможности, заложенные в новом варианте. Ценой многих усилии из. этого варианта вылавливаются наиболее топкие ошибки 5).
Количество ошибок как функция времени жизни одного варианта программы.
Основная проблема сопровождения программ заключается в том, что исправление одного дефекта со значительной вероятностью (20-50%) влечет за собой появление другого. Поэтому, образно говоря, весь процесс напоминает два шага вперед и шаг назад.
Почему же дефекты не исправляются более тщательно? Во-первых, даже самый мелкий дефект проявляет себя в какой-то чисто локальной неудаче. В действительности же он зачастую распространяется на всю систему, причем неочевидным образом. Попытка исправить дефект ценой минимальных усилий затрагивает лишь только локальное и очевидное, и, несмотря на существование отличной документации, очень трудно предусмотреть все далеко идущие последствия таких исправлений. Во-вторых, исправлением обычно занимается не тот же самый человек, кто написал программу; зачастую им оказывается начинающий программист или стажер.
Вследствие появления новых ошибок сопровождение программы требует гораздо больше времени на отладку каждого написанного оператора, чем на любой другой этап программирования. Теоретически после каждого исправления нужно опять пропускать весь банк тестов, разработанных для системы, с тем чтобы убедиться, что никаким неявным образом ей не был причинен ущерб. На' практике такая регрессивная отладка должна стремиться к своему теоретическому идеалу, но это очень дорого.
Очевидно, что методы разработки программ, позволяющие устранить или по меньшей мере выявить побочные эффекты, могут оказать существенное влияние на уменьшение стоимости сопровождения, равно как н методы реализации таких разработок с меньшим числом людей, сопряжении и, следовательно, ошибок.
Шаг вперед и шаг назад
Лемап и Бплсди изучали историю последовательности выпуска версий большой операционной системы6). Они обнаружили, что общее число модулей линейно с номером версии, но что число затронутых поправками модулей растет экспоненциально с ростом номера версии. Все исправления проявляют тенденцию к разрушению структуры, увеличению энтропии и неупорядоченности системы. Все меньше и меньше усилий затрачивается на исправление первоначальных недостатков проекта, все больше н больше времени уходит на исправление ошибок, вызванных предыдущими переделками. С течением времени система становится все менее упорядоченной. Рано или поздно переделки перестанут давать какой-либо результат. За каждым шагом вперед будет следовать шаг назад. И хотя в принципе система может использоваться вечно, она устареет н не сможет больше служить основой для движения вперед. К тому же меняются машины, конфигурации, потребности пользователей, так что в действительности система не может жить вечно. Возникает необходимость качественно нового и обоснованного проекта.
И таким образом, на основе статистической механической модели Леман и Биледи пришли к выводу, подтверждаемому опытом всей жизни на земле, который также применим для систем программирования: "Вещи всегда лучше, когда они совсем еще новые",- сказал Паскаль. Это же в более доходчивой форме сформулировал в своей книге 7) С. Лыос.
Создание системных программ - это процесс, уменьшающий энтропию, и, следовательно, он метастабилен. Сопровождение программы - процесс, увеличивающий энтропию, и даже самое умелое осуществление его лишь отодвигает тот срок, когда система безнадежно устареет.