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