Фредерик Брукс Мифический человеко-месяц или как создаются программные системы
Скачать 3.13 Mb.
|
Глава 10 Документарная гипотеза Гипотеза: Среди моря бумаг несколько документов становятся критически важными осями, вокруг которых вращается все управление проектом. Они являются главными личными инструментами менеджера. Технология, правила фирмы и традиции ремесла требуют выполнить некоторое количество канцелярской работы по проекту. Менеджеру-новичку, только что самому бывшему мастеровым, эта работа кажется совершенной помехой и ненужным отвлечением, бумажным валом, грозящим захлестнуть его. По большей части так и есть в действительности. Однако понемногу он начинает понимать, что некоторая небольшая часть этих документов заключает в себе значительную часть его административной работы. Подготовка каждого из них служит главным поводом для сосредоточения мысли и кристаллизации обсуждений, которые без этого длились бы вечно. Ведение этих документов становится механизмом наблюдения и предупреждения. Сам документ становится памяткой, индикатором состояния и базой данных для составления отчетов. Чтобы увидеть, как это должно работать в программном проекте, рассмотрим некоторые документы, полезные и в другом контексте, и посмотрим, можно ли сделать обобщения. Документы для проекта разработки компьютера Предположим, что разрабатывается компьютер. Какие важнейшие документы должны быть разработаны? Цели. Здесь описывается, какие потребности нужно удовлетворить, а также задачи, пожелания, ограничения и приоритеты. Спецификации. Это руководство по компьютеру плюс спецификации технических характеристик. Это один из первых документов, составляемых для нового продукта, и завершается он последним. График. Бюджет. Это не просто ограничение, но один из наиболее полезных менеджеру документов. Наличие бюджета заставляет осуществлять технические решения, которых старались бы избежать, и, что еще важнее, служит выполнению и разъяснению стратегических решений. Организационная структура. Пространственное расположение. Оценка, прогноз, цены. Они находятся в циклической взаимосвязи, что определяет успех или провал проекта: Чтобы сделать прогноз рынка, нужны технические характеристики и установленные цены. Цифры прогноза вместе с заданным проектом числом компонентов определяют оценку стоимости производства и долю расходов на разработку и фиксированных затрат, приходящихся на одно устройство. Эти расходы, в свою очередь, определяют цены. Если цены ниже установленных, начинается радостная раскрутка спирали успеха. Прогноз растет, стоимость одного устройства падает, а цены опускаются еще ниже. Если цены выше установленных, начинается раскрутка спирали катастрофы, и все силы должны быть брошены на то, чтобы сломить ее. Нужно улучшить технические характеристики и разработать новые приложения, чтобы поднять рыночный прогноз. Издержки нужно снизить, чтобы получить более низкие оценки. Напряженность такого цикла часто требует больших усилий маркетолога и инженера. При этом возможны забавные колебания. Я вспоминаю машину, у которой в течение трех лет разработки каждые полгода счетчик команд устраивался то в оперативной памяти, то вне ее. На одном этапе требовались чуть лучшие характеристики, и счетчик делали на транзисторах. На следующем этапе начиналась борьба за снижение стоимости, поэтому счетчик организовывался как адрес в оперативной памяти. В другом проекте лучший известный мне менеджер по инженерным проектам служил гигантским маховиком, гася своей инерцией колебания, исходившие от маркетинга и менеджмента. Документы для факультета в университете Несмотря на огромные различия в целях и деятельности, критическое множество для председателя факультета в университете составляет сходное число сходных документов. Почти каждое решение декана, совета кафедры или председателя является спецификацией или изменением следующих документов: Цели. Описание курса. Требования к соискателю степени. Предложения по исследовательской работе (и планы, при наличии финансирования). Расписание занятий и назначение преподавателей. Бюджет. Помещения. Назначение руководителей для аспирантов. Обратите внимание, что документы очень похожи на те, которые нужны для компьютерного проекта: цели, спецификации продукта, распределение времени, денег, места и людей. Только документы с ценами отсутствуют: этим занимается законодательное собрание. Сходство не случайно — заботами всякой задачи управления являются: что, когда, по какой цене, где и кто. Документы для программного проекта Во многих программных проектах работа начинается с совещаний, на которых обсуждается структура; затем приступают к написанию программ. Однако как бы ни был мал проект, менеджер поступит мудро, если сразу начнет формализовать хотя бы минидокументы, которые послужат его базой данных. И он обнаружит, что ему нужны, по большей части, те же документы, что и другим менеджерам. Что: цели. Здесь определяется, какие потребности должны быть удовлетворены, а также задачи, пожелания, ограничения и приоритеты. Что: спецификации продукта. Начинается как предложение, а кончается как руководство и внутренняя документация. Важнейшей частью являются спецификации скорости и памяти. Когда: график. По какой цене: бюджет. Где: расположение помещений. Кто: организационная структура. Она переплетается со спецификацией интерфейса, как предсказывает закон Конвея: «Организации, проектирующие системы, неизбежно производят системы, являющиеся копиями их организационных структур». [1] Конвей идет дальше и указывает, что организационная структура первоначально отражает проект первой системы, который наверняка был ошибочным. Если проект системы должен допускать внесение изменений, то и организация должна быть готова к переменам. Зачем нужны формальные документы? Во-первых, необходимо записывать принятые решения. Только когда пишешь, становятся видны пропуски и проступают несогласованности. В процессе записывания возникает необходимость принятия сотен мини-решений, и их наличие отличает четкую и ясную политику от расплывчатой. Во-вторых, посредством документов решения сообщаются исполнителям. Менеджеру приходится постоянно удивляться, что политика, которую он считал известной всем, оказывается совершенно неизвестной одному из членов его команды. Поскольку основная его работа состоит в том, чтобы все двигались в одном направлении, его главная ежедневная задача заключается в обмене информацией, а не принятии решений, и документы очень облегчат ему эту нагрузку. Наконец, документы образуют базу данных менеджера и его контрольный список. Периодически изучая их, он видит, в какой точке пути находится, и определяет необходимость смещения акцентов или изменения направления. Я не разделяю выдвигаемых продавцами видений «всеохватывающей информационной системы для управления», в которой администратор вводит в компьютер запрос с клавиатуры, и на экране вспыхивает нужный ему ответ. Есть много фундаментальных причин, по которым этого не произойдет. Одна причина заключается в том, что только маленькая часть, возможно 20 процентов, рабочего времени администратора занята задачами, которые требуют сведений, отсутствующих в его памяти. А все остальное время — это общение: слушать, отчитываться, обучать, убеждать, советовать, ободрять. Но для той доли, для которой действительно нужны данные, необходимы несколько важных документов, которые удовлетворяют большинство нужд. Задача менеджера состоит в том, чтобы разработать план и выполнить его. Но только записанный план является точным и может быть сообщен другим. Такой план состоит из документов, описывающих: что, когда, по какой цене, где и кто. Этот маленький набор важных документов охватывает значительную часть работы менеджера. Если в самом начале понять их всеохватывающую и важную сущность, то они станут для менеджера добрым инструментом, а не раздражающей обузой. Сделав это, он определит свой курс более четко и быстро. Глава 11 Планируйте на выброс В этом мире нет ничего постояннее непостоянства. СВИФТ Разумно взять метод и испытать его. При неудаче честно признайтесь в этом и попробуйте другой метод. Но главное, делайте что-нибудь. ФРАНКЛИН Д. РУЗВЕЛЬТ Опытные заводы и масштабирование Инженеры-химики давно поняли, что процесс, успешно осуществляемый в лаборатории, нельзя одним махом перенести в заводские условия. Необходим промежуточный шаг, создание опытного завода, чтобы получить опыт наращивания количеств веществ и функционирования в незащищенных средах. К примеру, лабораторный процесс опреснения воды следует проверить на опытном заводе мощностью 50 тысяч литров в день, прежде чем использовать в городской системе водоснабжения мощностью 10 млн. литров в день. Разработчики программных систем тоже получили этот урок, но, похоже, до сих пор его не усвоили. В одном проекте за другим разрабатывают ряд алгоритмов и затем начинают создавать поставляемое клиенту программное обеспечение по графику, требующему поставки первой же сборки. В большинстве проектов первой построенной системой с трудом можно пользоваться. Она может быть слишком медленной, слишком большой, неудобной в использовании, а то и все вместе. Не остается другой альтернативы, кроме как, поумнев, начать сначала и построить перепроектированную программу, в которой эти проблемы решены. Браковка и перепроектирование могут делаться для всей системы сразу или по частям. Но весь опыт разработки больших систем показывает, что будет сделано. [2] В тех случаях, когда используются новые системные концепции и новые технологии, приходится создавать систему на выброс, поскольку даже самое лучшее планирование не столь всеведуще, чтобы попасть в цель с первого раза. Поэтому проблема не в том, создавать или нет опытную систему, которую придется выбросить. Вы все равно это сделаете. Вопрос единственно в том, планировать ли заранее разработку системы на выброс или обещать клиентам поставку системы, которую придется выбросить. Если смотреть под этим углом, ответ становится намного проще. Поставка хлама клиенту позволяет выиграть время, но происходит это ценой мучений пользователя, отвлечений разработчиков во время перепроектирования и дурной репутации продукта, которую даже самой удачно перепроектированной программе будет трудно победить. Поэтому планируйте выбросить первую версию — вам все равно придется это сделать. Постоянны только изменения После уяснения того, что опытную систему нужно создавать, а потом выбросить, и что перепроектирование с новыми идеями неизбежно, полезно обратиться лицом к изменению как явлению природы. Первый шаг — признание того, что изменение — это образ жизни, а не постороннее и досадное исключение. Косгроув мудро указал, что программист поставляет удовлетворение потребности пользователя, а не какой-то осязаемый продукт. И в то время как программы создаются, тестируются и используются, меняются как фактические потребности пользователя, так и понимание им своих потребностей. [3] Конечно, это справедливо и в отношении потребностей, удовлетворяемых физическими продуктами, будь то автомобили или компьютеры. Но само существование осязаемого продукта определяет запросы пользователя и их квантование. Податливость и неосязаемость программного продукта побуждают его создателей к бесконечному изменению требований. Я далек от того, чтобы считать, будто все изменения целей и требований клиента можно или необходимо учитывать в проекте. Очевидно, должен быть установленный порог, который должен подниматься все выше и выше по ходу разработки, иначе ни один продукт никогда не будет создан. Тем не менее некоторые изменения в задачах неизбежны, и лучше подготовиться к ним заранее, чем предполагать, что их не возникнет. Неизбежны не только изменения в целях, но также изменения в стратегии разработки и технологии. Концепция «работы на мусорный ящик» есть лишь признание того факта, что по мере приобретения опыта меняется проект. [4] Планируйте внесение изменений в систему Способы проектирования системы с учетом будущих изменений хорошо известны и широко обсуждаются в литературе — возможно, шире обсуждаются, чем применяются. Они включают в себя тщательное разбиение на модули, интенсивное использование подпрограмм, точное и полное определение межмодульных интерфейсов и полную их документацию. Менее очевидно, что при любой возможности необходимо использовать стандартные последовательности вызова и технологии табличного управления. Очень важно использовать языки высокого уровня и технологии самодокументирования, чтобы уменьшить число ошибок, вызываемых изменений. Мощную поддержку при внесении изменений оказывают операции времени компиляции по включению стандартных объявлений. Важным приемом является квантование изменений. Каждый продукт должен иметь нумерованные версии, и каждая версия должна иметь свой график работ и дату фиксации, после которой изменения включаются уже в следующую версию. Планируйте организационную структуру для внесения изменений Косгроув рекомендует ко всем планам, вехам и графикам относиться как к пробам, чтобы облегчить изменения. Здесь он заходит слишком далеко — сегодня группы программистов терпят неудачи обычно из-за слишком слабого, а не слишком сильного административного контроля. Тем не менее он выказывает большую проницательность. Он замечает, что нежелание документировать проект происходит не только от лени или недостатка времени. Оно происходит от нежелания проектировщика связывать себя отстаиванием решений, которые, как он знает, предварительные. «Документируя проект, проектировщик становится объектом критики со всех сторон, и должен защищать все, что написал. Если организационная структура может представлять угрозу, не будет документироваться ничего, кроме того, что нельзя оспорить.» Создавать организационную структуру с учетом внесения в будущем изменений значительно труднее, чем проектировать систему с учетом будущих изменений. Каждый получает задание, расширяющее круг его обязанностей, чтобы сделать технически более гибким все подразделение. В больших проектах менеджеру нужно иметь двух или трех высококлассных программистов в качестве резерва, который можно бросить на самый опасный участок боя. Структуру управления также нужно изменять по мере изменения системы. Это означает, что руководитель должен уделить большое внимание тому, чтобы его менеджеры и технический персонал были настолько взаимозаменяемы, насколько позволяют их способности. Барьеры являются социологическими, и с ними нужно бдительно и настойчиво бороться. Во-первых, менеджеры сами рассматривают руководителя как «слишком большую ценность», чтобы использовать их для реального программирования. Во-вторых, работа менеджера обладает более высоким престижем. Чтобы преодолеть эти сложности, в некоторых лабораториях, например, в Bell Labs, упраздняют все наименования должностей. Каждый профессиональный служащий является «техническим сотрудником». В других, например в IBM, вводят двойную лестницу продвижения (рис. 11.1). Соответствующие ступеньки теоретически равнозначны. Рис. 11.1 Двойная служебная лестница IBM Легко установить соответствующие ступенькам размеры жалования. Значительно труднее дать им соответствующий престиж. Офисы должны иметь одинаковый размер и обстановку. Секретарские и прочие службы должны быть соответствующими. Перевод с технической лестницы в управленческую не должен сопровождаться повышением, и о нем всегда нужно сообщать как о «переводе», а не как о «повышении». Обратный перевод всегда должен сопровождаться прибавкой к жалованью. Менеджеров нужно посылать на курсы технической переподготовки, а старший технический персонал — на курсы обучения управлению. Цели проекта, ход работы и административные проблемы должны доводиться до всех руководящих работников. Если позволяет подготовка, руководящие работники должны быть технически и морально готовы возглавить группы или насладиться разработкой программ собственными руками. Конечно, осуществление всего этого требует много труда, но результат того стоит! Идея организации групп программистов наподобие операционных бригад представляет собой коренное решение этой проблемы. Она заставляет руководящего работника почувствовать, что он не унижает себя, когда пишет программы, и пытается убрать социальные препятствия, мешающие ему испытать радость творчества. Более того, эта структура предназначена для сокращения числа интерфейсов. Благодаря ей систему можно изменять с максимальной легкостью, и становится относительно просто перенаправить всю бригаду на другое задание в случае необходимости организационных изменений. Это действительно долгосрочное решение проблемы гибкой организации. Два шага вперед, шаг назад Программа не перестает изменяться после своей поставки клиенту. Изменения после поставки называются сопровождением программы, но этот процесс в корне отличается от сопровождения аппаратной части. Сопровождение аппаратной части компьютерной системы состоит из трех видов деятельности: замены испорченных деталей, чистки и смазки и осуществления технических изменений для исправления конструктивных дефектов. (Большая часть технических изменений, но не все, устраняет дефекты разработки или реализации, а не архитектуры, и потому незаметна пользователю.) Сопровождение программ не предполагает чистки, смазки или замены испортившихся компонентов. Оно состоит главным образом из изменений, исправляющих конструктивные дефекты. Гораздо чаще, чем для аппаратной части, эти изменения включают в себя дополнительные функции. Обычно они видны пользователю. Общая стоимость сопровождения широко используемой программы обычно составляет 40 и более процентов стоимости ее разработки. Удивительно, что на стоимость сопровождения сильно влияет число пользователей. Чем больше пользователей, тем больше ошибок они находят. Бетти Кэмпбелл из Лаборатории ядерной физики МТИ отмечает интересный цикл в жизни отдельной версии программы. Он показан на рисунке 11.2. В начале существует тенденция повторного появления ошибок, найденных и устраненных в предыдущих версиях. Обнаруживаются ошибки в функциях, впервые появившихся в новой версии. Все они исправляются, и в течение нескольких месяцев все идет хорошо. Затем количество обнаруженных ошибок снова начинает расти. По мнению Кэмпбелл, это происходит потому, что пользователи выходят на новый уровень сложности, начиная полностью применять новые возможности версии. Эта интенсивная работа выявляет более скрытые ошибки в новых функциях. [5] Рис. 11.2 Частота обнаружения ошибок как функция возраста версии программы Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50 процентов) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, один назад». Почему не удается устранить ошибки более аккуратно? Во-первых, даже скрытый дефект проявляет себя как отказ в каком-то одном месте. В действительности же он часто имеет разветвления по всей системе, обычно неочевидные. Всякая попытка исправить его минимальными усилиями приведет к исправлению локального и очевидного, но если только структура не является очень ясной или документация очень хорошей, отдаленные последствия этого исправления останутся незамеченными. Во-вторых, исправляет ошибки обычно не автор программы, и часто это младший программист или стажер. Вследствие внесения новых ошибок сопровождение программы требует значительно больше системной отладки на каждый оператор, чем при любом другом виде программирования. Теоретически, после каждого исправления нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше, чтобы убедиться, что она каким-нибудь непонятным образом не повредилась. На практике такое возвратное тестирование действительно должно приближаться к этому теоретическому идеалу, и оно очень дорого стоит. Очевидно, методы разработки программ, позволяющие исключить или, по крайней мере, выявить побочные эффекты, могут резко снизить стоимость сопровождения, как и методы разработки проектов меньшим числом людей и с меньшим числом интерфейсов — а значит, и с меньшим числом ошибок. Шаг вперед, шаг назад Леман и Белади изучили историю последовательных выпусков большой операционной системы. [6] Они считают, что общее количество модулей растет линейно с номером версии, но число модулей, затронутых изменениями, растет экспоненциально в зависимости от номера версии. Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Все меньше сил тратится на исправление ошибок исходного проекта и все больше — на ликвидацию последствий предыдущих исправлений. По прошествии времени система становится все менее и менее организованной. Рано или поздно исправление ошибок теряет смысл. На каждый шаг вперед приходится шаг назад. В принципе годная для вечного использования система перестает быть основой развития. Кроме того, меняются машины, конфигурации, требования пользователя, так что фактически система является вечной. Необходим совершенно новый проект, выполняемый с самого начала. От механической статистической модели Белади и Леман приходят к общему заключению относительно программных систем, которое подкреплено всем опытом человечества. «Лучшая пора вещей — когда они только что появились», — сказал Паскаль. Ч. С. Льюис выразил это более весомо: Вот ключ к пониманию истории. Высвобождается огромная энергия, возникают цивилизации, создаются прекрасные учреждения, но всякий раз что-то происходит не так. Какая-то роковая ошибка возносит на вершину себялюбивых и жестоких людей, и все скатывается назад, в нищету и руины. Действительно, машина глохнет. Она нормально стартует и проезжает несколько метров, а затем ломается. [7] Системное программирование является процессом, уменьшающим энтропию, а потому ему внутренне присуща метастабильность. Сопровождение программ есть процесс, увеличивающий энтропию, и даже самое умелое его ведение лишь отдаляет впадение системы в безнадежное устаревание. |
Похожие:
 | Удк 378: 303 тестирование как инновационная форма контроля Целью работы является проектирование программного человеко-машинного интерфейса для социально-ориентированной системы поддержки очного... |  | Программа дисциплины Глобальные сети. Путеводители (навигаторы). Глобальные и локальные сетевые технологии. Элементы системной интеграции. Тенденции и... |
| Что мы знаем о числах? ... | | Программа по формированию навыков безопасного поведения на дорогах... Понятия: фаза Луны, синодический месяц, сидерический месяц, восходящий и нисходящий узлы, драконический месяц |
| Последний учебный месяц проходит в напряженном труде контрольные... Но мы находим время и для посещения библиотеки. 24 мая вместе с первоклассниками мы посетили мероприятие "Как создаются книги". Мы... | | Инструкция по настройке Системы видеонаблюдения Программные компоненты системы могут устанавливаться на одном сервере, однако, мы не рекомендуем такую установку во внедрениях более... |
| Перед Вами задания по биологии. На их выполнение отводится 45 минут. Внимательно читайте задания Целью работы является проектирование программного человеко-машинного интерфейса для социально-ориентированной системы поддержки очного... | | Отчет по преддипломной практике На тему: «Проектирование программного... Целью работы является проектирование программного человеко-машинного интерфейса для социально-ориентированной системы поддержки очного... |
| Игорь Куклинов Современная притча в притчах о том, как улучшить свое... Все было плохо. Третий месяц в институте не выдавали зарплату. И без того мизерный оклад, да еще и не платят. Сергей в задумчивости... | | Эмоциональная зрелость — это ослабление непосредственных, импульсивных... Целью работы является проектирование программного человеко-машинного интерфейса для социально-ориентированной системы поддержки очного... |
| Проект «Фразеологизмы или попади в цель» Вводный урок «В гостях у слова» Задумывались ли вы когда-нибудь над тем, почему всё вокруг называется так, а не иначе? Как рождаются слова, когда и кем создаются?... | | Экспериментальная Социальная Сеть www ntl cbm narod ru Математические методы и программные средства формирования социополитической системы |
| Или, что такое эссе и как его написать? Все просто: получено задание от преподавателя как результат окончания очередного полугодия или семестра, как результат окончания... | | Пояснительная записка к дипломному проекту «Совместное моделирование... Лирования, описан инструментарий, базовые идеи и принципы. Осуществлен выбор существующих программных средств и произведена интеграция... |
| Программа по формированию навыков безопасного поведения на дорогах... В «Еврейской Рулетке» автор развенчивает масонскую круговерть в правительстве и парламенте Украины. Правители Украины прямо, как... | | Проекта Программные среды используются человеком как средство обработки исходной информации и анализа результатов. Здесь компьютер выступает... |
