Читать онлайн «Мифический человеко-месяц или как создаются программные системы». Страница 19

Рис. 11.1 Двойная служебная лестница IBM

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

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

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

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

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

Два шага вперед, шаг назад

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

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

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

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

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

Бетти Кэмпбелл из Лаборатории ядерной физики МТИ отмечает интересный цикл в жизни отдельной версии программы. Он показан на рисунке 11.2. В начале существует тенденция повторного появления ошибок, найденных и устраненных в предыдущих версиях. Обнаруживаются ошибки в функциях, впервые появившихся в новой версии. Все они исправляются, и в течение нескольких месяцев все идет хорошо. Затем количество обнаруженных ошибок снова начинает расти. По мнению Кэмпбелл, это происходит потому, что пользователи выходят на новый уровень сложности, начиная полностью применять новые возможности версии. Эта интенсивная работа выявляет более скрытые ошибки в новых функциях. [5]

Рис. 11.2 Частота обнаружения ошибок как функция возраста версии программы

Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50 процентов) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, один назад».

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

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

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

Шаг вперед, шаг назад

Леман и Белади изучили историю последовательных выпусков большой операционной системы. [6] Они считают, что общее количество модулей растет линейно с номером версии, но число модулей, затронутых изменениями, растет экспоненциально в зависимости от номера версии. Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Все меньше сил тратится на исправление ошибок исходного проекта и все больше — на ликвидацию последствий предыдущих исправлений. По прошествии времени система становится все менее и менее организованной. Рано или поздно исправление ошибок теряет смысл. На каждый шаг вперед приходится шаг назад. В принципе годная для вечного использования система перестает быть основой развития. Кроме того, меняются машины, конфигурации, требования пользователя, так что фактически система является вечной. Необходим совершенно новый проект, выполняемый с самого начала.

От механической статистической модели Белади и Леман приходят к общему заключению относительно программных систем, которое подкреплено всем опытом человечества. «Лучшая пора вещей — когда они только что появились», — сказал Паскаль. Ч. С. Льюис выразил это более весомо:

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

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

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

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

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

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