WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 || 3 | 4 |

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

-- [ Страница 2 ] --

Очень слабое взаимодействие 10000 инструкций на человека в год Некоторое взаимодействие 5000 « Человеко-месяцы Существенное взаимодействие 1500 « Человеко-год здесь не учитывает поддержку и системное тестирование, только разработку и программирование. При введении поправки с коэффициентом два с целью учета системного тестирования эти цифры близко соответствуют данным Харра.

Данные Харра Джон Харр (John Harr), менеджер по программированию Electronic Switching System, входящей в состав Bell Telephone Laboratories, сообщил о своем собственном опыте и других известных ему данных в докладе на Объединенной конференции по компьютерам весной 1969 года.8 Эти данные приведены на рисунках 8.2, 8.3 и 8.4.

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

Число Число Затра- Чело- Количество Слов / програм- програм- чено веко- слов в человеко мных мистов лет лет программе год блоков Операционная 50 83 4 101 52000 Обслуживающая 36 60 4 81 51000 Компилятор 13 9 2 17 38000 Транслятор 15 13 2 11 25000 (ассемблер) Рис. 8.2 Сводка по четырем важнейшим программным проектам, осуществленным в ESS Производительность разбивается на два класса: для управляющих программ составляет около 600 слов на человека за год, для трансляторов — около 2200.

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

На рисунках 8.3 и 8.4 показаны некоторые интересные данные о фактической скорости программирования и отладки в сравнении с прогнозом.

Данные OS/ Опыт OS/360 подтверждает данные Харра, хотя данные по OS/360 не столь подробны. В группах разработки управляющей программы производительность составила 600-800 отлаженных команд в год на человека. В группах разработки трансляторов производительность достигла 2000-3000 отлаженных команд в год на человека. При этом учитывается планирование, тестирование компонентов, системное тестирование и некоторые затраты на поддержку. Насколько я могу судить, эти данные согласуются с результатами Харра.

Ежемесячная оценка размера программы Фактическая скорость программирования Прогноз скорости программирования март июнь сентябрь декабрь март июнь сентябрь декабрь Рис. 8.3 Предсказанная и фактическая скорость программирования Ежемесячная оценка размера программы Прогноз скорости отладки Фактическая скорость отладки март июнь сентябрь декабрь март июнь сентябрь декабрь Рис. 8.4 Предсказанная и фактическая скорость отладки Данные Арона, Харра и OS/360 дружно подтверждают резкие различия в производительности в зависимости от сложности и трудности самой задачи. В работе оценивания сложности я придерживаюсь той линии, что компиляторы втрое хуже обычных пакетных прикладных программ, а операционные системы втрое хуже компиляторов. Данные Корбато Данные Харра и OS/360 относятся к программированию на языке ассемблера. Есть немного публикаций относительно производительности системного программирования с использованием языков высокого уровня. Корбато (Corbato) из проекта MAC Массачусетского технологического института сообщает о средней производительности 1200 строк отлаженных операторов PL/I на человека в год при разработке операционной системы MULTICS (от 1 до 2 миллионов слов). Это число очень вдохновляет. Как у других проектов, MULTICS включает в себя управляющие программы и языковые трансляторы. Результатом также является системный продукт, отлаженный и документированный. Данные кажутся сравнимыми в отношении видов исполненной работы. А производительность повышается до Тысячи слов Тысячи слов средней величины между управляющими программами и трансляторами в других проектах.

Но Корбато указывает количество строк за год на человека, а не слов! Каждому оператору в его системе соответствует от трех до пяти слов кода, написанного вручную! Из этого можно сделать два важных вывода:

• Производительность, измеренная в элементарных операциях, оказывается постоянной, что кажется разумным, если учитывать, сколько времени нужно думать над оператором, и сколько ошибок может в нем быть. • При использовании подходящего языка высокого уровня производительность можно повысить в пять раз. Глава 9 Два в одном Глава 9 Два в одном Глава 9 Два в одном Автору стоит присмотреться к Ною и... поучиться на примере Kовчега, как в очень маленькое пространство втиснуть очень много.

СИДНЕЙ СМИТ, «ЭДИНБУРГСKОЕ РЕВЮ» Размер программы как стоимость Какова стоимость программы? Если не считать времени выполнения, то помять, занимаемая программой, составляет главные издержки. Это верно даже для собственных разработок, когда пользователь платит автору существенно меньше, чем стоит разработка. Возьмем интерактивную систему IBM APL. Плата за ее использование составляет $400 в месяц. При работе она требует не меньше Кбайт памяти. У машины Model 165 ежемесячная аренда 1 Кбайта памяти стоит около $12. Если пользоваться программой круглосуточно, то месячная плата составит $ за пользование программой и $1920 за память. Если пользоваться системой APL лишь четыре часа в день, то месячная плата составит $400 за пользование программой и $320 за использование памяти.

Нередко можно встретить человека, выражающего ужас по поводу того, что в машине, имеющей 2 Мбайт памяти, под операционную систему может быть отведено 400 Кбайт. Это столь же глупо, как ругать Боинг-747 за то, что он стоит миллионов долларов. Надо же спросить: «А что она делает?» Какую, собственно, простоту в использовании и производительность (посредством эффективного использования системы) получаешь за потраченные деньги? Нельзя ли вложенные в аренду памяти $4800 в месяц израсходовать с большей пользой — на другие аппаратные средства, программистов, прикладные программы?

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

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

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

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

Все же при работе над OS/360 пришлось извлечь несколько горьких уроков, несмотря на то, что все описанные меры были приняты.

Прежде всего, недостаточно установить размер памяти, нужно взвесить размер со всех сторон. Большинство прежних операционных систем размещалось на магнитных лентах, и большое время поиска на ленте не располагало к частой загрузке программных сегментов. OS/360 располагалась на диске, как и ее непосредственные предшественники — операционная система Stretch и дисковая операционная системы 1410-7010. Ее создатели получили свободу легкого обращения к диску.

Первоначально это обернулось катастрофой для производительности.

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

К счастью, вскоре настал день, когда заработала система моделирования технических характеристик OS/360. Первые результаты показали наличие серьезных проблем. Моделирование компиляции с Fortran H на машине Model 65 с барабанами дало результат пять операторов в минуту! Анализ показал, что все модели управляющей программы делали множество обращений к диску. Даже интенсивно используемые модули супервизора часто обращались к диску, и результат по звуку весьма напоминал шелест перелистываемой книги.

Первая мораль ясна: планировать нужно как размер резидентной части, так и общий размер. Помимо планирования этих размеров нужно планировать и количество обращений к диску для обратной записи.

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

Поэтому второй вывод тоже совершенно ясен: при задании размера модуля нужно точно определить, что он должен делать.

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

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

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

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

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

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

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

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

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

Представление — суть программирования За мастерством стоит изобретательность, благодаря которой появляются экономичные и быстрые программы. Почти всегда это является результатом стратегического прорыва, а не тактического умения. Иногда таким стратегическим прорывом является алгоритм, как, например, быстрое преобразование Фурье, предложенное Кули и Тьюки, или замена n2 сравнений на n log n при сортировке.

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

Примеры мощи, которой обладает представление, легко умножить. Я вспоминаю одного молодого человека, занимавшегося созданием усовершенствованного консольного интерпретатора для IBM 650. Ему удалось вместить его в поразительно малое пространство благодаря разработке интерпретатора для интерпретатора и пониманию того, что взаимодействие человека с машиной происходит медленно и редко, а память дорога. Элегантный маленький компилятор с Fortran фирмы Digitek использует особое очень плотное представление кода самого компилятора, благодаря чему не требуется внешней памяти. Время, которое тратится на распаковку кода, десятикратно окупается за счет отсутствия ввода-вывода.

(Упражнения в конце главы 6 книги Брукса и Иверсона «Автоматическая обработка данных»1 включает подборку таких примеров, как и многие упражнения у Кнута.2) Программист, ломающий голову по поводу нехватки памяти, часто поступит лучше всего, оставив в покое свой код, вернувшись назад и хорошенько посмотрев свои данные. Представление — суть программирования.

Глава 10 Документарная гипотеза Глава 10 Документарная гипотеза Глава 10 Документарная гипотеза Гипотеза:

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

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

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

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

Чтобы увидеть, как это должно работать в программном проекте, рассмотрим некоторые документы, полезные и в другом контексте, и посмотрим, можно ли сделать обобщения.

Документы для проекта разработки компьютера Предположим, что разрабатывается компьютер. Какие важнейшие документы должны быть разработаны?

Цели. Здесь описывается, какие потребности нужно удовлетворить, а также задачи, пожелания, ограничения и приоритеты.

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

График.

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

Организационная структура.

Пространственное расположение.

Оценка, прогноз, цены. Они находятся в циклической взаимосвязи, что определяет успех или провал проекта:

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

Если цены ниже установленных, начинается радостная раскрутка спирали успеха.

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

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

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

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

Документы для факультета в университете Несмотря на огромные различия в целях и деятельности, критическое множество для председателя факультета в университете составляет сходное число сходных документов. Почти каждое решение декана, совета кафедры или председателя является спецификацией или изменением следующих документов:

Цели.

Описание курса.

Требования к соискателю степени.

Предложения по исследовательской работе (и планы, при наличии финансирования).

Расписание занятий и назначение преподавателей.

Бюджет.

Помещения.

Назначение руководителей для аспирантов.

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

Документы для программного проекта Во многих программных проектах работа начинается с совещаний, на которых обсуждается структура;

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

Что: цели. Здесь определяется, какие потребности должны быть удовлетворены, а также задачи, пожелания, ограничения и приоритеты.

Что: спецификации продукта. Начинается как предложение, а кончается как руководство и внутренняя документация. Важнейшей частью являются спецификации скорости и памяти.

Когда: график.

По какой цене: бюджет.

Где: расположение помещений.

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

Зачем нужны формальные документы?

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

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

Наконец, документы образуют базу данных менеджера и его контрольный список.

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

Я не разделяю выдвигаемых продавцами видений «всеохватывающей информационной системы для управления», в которой администратор вводит в компьютер запрос с клавиатуры, и на экране вспыхивает нужный ему ответ. Есть много фундаментальных причин, по которым этого не произойдет. Одна причина заключается в том, что только маленькая часть, возможно 20 процентов, рабочего времени администратора занята задачами, которые требуют сведений, отсутствующих в его памяти. А все остальное время — это общение: слушать, отчитываться, обучать, убеждать, советовать, ободрять. Но для той доли, для которой действительно нужны данные, необходимы несколько важных документов, которые удовлетворяют большинство нужд.

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

Сделав это, он определит свой курс более четко и быстро.

Глава 11 Планируйте на выброс Глава 11 Планируйте на выброс Глава 11 Планируйте на выброс В этом мире нет ничего постояннее непостоянства.

СВИФТ Разумно взять метод и испытать его. При неудаче честно признайтесь в этом и попробуйте другой метод. Но главное, делайте что-нибудь.

ФРАНKЛИН Д. РУЗВЕЛЬТ Опытные заводы и масштабирование Инженеры-химики давно поняли, что процесс, успешно осуществляемый в лаборатории, нельзя одним махом перенести в заводские условия. Необходим промежуточный шаг, создание опытного завода, чтобы получить опыт наращивания количеств веществ и функционирования в незащищенных средах. К примеру, лабораторный процесс опреснения воды следует проверить на опытном заводе мощностью 50 тысяч литров в день, прежде чем использовать в городской системе водоснабжения мощностью 10 млн. литров в день.

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

В большинстве проектов первой построенной системой с трудом можно пользоваться.

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

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

Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.

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

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

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

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

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

Мощную поддержку при внесении изменений оказывают операции времени компиляции по включению стандартных объявлений.

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

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

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

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

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

Барьеры являются социологическими, и с ними нужно бдительно и настойчиво бороться. Во-первых, менеджеры сами рассматривают руководителя как «слишком большую ценность», чтобы использовать их для реального программирования. Во вторых, работа менеджера обладает более высоким престижем. Чтобы преодолеть эти сложности, в некоторых лабораториях, например, в Bell Labs, упраздняют все наименования должностей. Каждый профессиональный служащий является «техническим сотрудником». В других, например в IBM, вводят двойную лестницу продвижения (рис. 11.1). Соответствующие ступеньки теоретически равнозначны.

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

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

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

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

Более того, эта структура предназначена для сокращения числа интерфейсов.

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

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

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

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

Бетти Кэмпбелл из Лаборатории ядерной физики МТИ отмечает интересный цикл в жизни отдельной версии программы. Он показан на рисунке 11.2. В начале существует тенденция повторного появления ошибок, найденных и устраненных в предыдущих версиях. Обнаруживаются ошибки в функциях, впервые появившихся в новой версии. Все они исправляются, и в течение нескольких месяцев все идет хорошо. Затем количество обнаруженных ошибок снова начинает расти. По мнению Кэмпбелл, это происходит потому, что пользователи выходят на новый уровень сложности, начиная полностью применять новые возможности версии. Эта интенсивная работа выявляет более скрытые ошибки в новых функциях. Количество ошибок, выявленных за месяц Месяцы, прошедшие после инсталляции Рис. 11.2 Частота обнаружения ошибок как функция возраста версии программы Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50 процентов) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, один назад».

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

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

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

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

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

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

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

Глава 12 Острый инструмент Глава 12 Острый инструмент Глава 12 Острый инструмент Хорошего работника узнают по инструменту.

ПОСЛОВИЦА аже в наше время многие программные проекты, с точки зрения использования Динструментария, работают как механические мастерские. У каждого механика есть свой набор инструментов, собиравшийся в течение всей жизни, который он тщательно запирает и охраняет — наглядное свидетельство личного мастерства.

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

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

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

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

Что это за инструменты, разработку которых менеджер должен обдумывать, планировать и организовывать? Прежде всего, вычислительные средства. Для этого требуются машины, и должна быть принята политика планирования времени. Для этого требуется операционная система, и должна быть установлена политика обслуживания. Для этого требуется язык, и должна быть заложена политика в отношении языка. Затем идут утилиты, средства отладки, генераторы контрольных примеров и текстовый процессор для работы с документацией. Рассмотрим их поочередно. Целевые машины Машинную поддержку полезно разделить на целевые машины и рабочие машины.

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

Каковы типы целевых средств? Если бригада создает новый супервизор или другое программное средство, составляющее сердцевину системы, то ей, конечно, нужна своя машина. Для таких систем потребуются операторы и один или два системных программиста, чтобы машина была в рабочем состоянии.

Если требуется отдельная машина, то она должна быть довольно специфической: не требуется, чтобы она была быстрой, но требуется, по меньшей мере, 1 Мбайт оперативной памяти, 100 Мбайт в активных дисках и терминалы. Достаточно символьных терминалов, но со значительно большей скоростью, чем 15 символов в секунду, характерных для пишущих машинок. Наличие большой памяти значительно способствует продуктивности, позволяя заняться разбиением на оверлеи и минимизацией размера после тестирования функций.

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

Планирование времени. Если целевая машина новая, — например, для нее создается первая операционная система, — то машинного времени мало, и планирование становится большой проблемой. Потребности в рабочем времени целевой машины имеет специфическую кривую роста. При разработке OS/360 у нас были хорошие эмуляторы System/360 и другие машины. По прежнему опыту мы оценили, сколько часов рабочего времени S/360 нам понадобится, и стали получать первые машины с производства. Но месяц за месяцем они оставались без нагрузки. Затем сразу все систем оказались загруженными, и распределение времени стало проблемой.

Использование машин выглядело примерно как на рисунке 12.1. Все одновременно начали отлаживать первые компоненты, и затем все команды постоянно что-то отлаживали.

Модель:

40 часов в месяц Январь Рис. 12.1 Рост использования целевых машин Мы централизовали все свои машины и библиотеки магнитных лент и организовали для их работы профессиональную и опытную группу машинного зала. Для максимизации бывшего в недостатке машинного времени S/360 все отладочные прогоны мы осуществляли в пакетном режиме на подходящих свободных машинах.

Мы добились четырех запусков в день (оборачиваемость составила два с половиной часа), а требовалась четырехчасовая оборачиваемость. Вспомогательная машина 1401 с терминалами использовалась для планирования прогонов, отслеживания тысяч заданий и контроля времени оборачиваемости.

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

Даже если система была на занята, посторонние не могли ею пользоваться.

Это оказалось более удачным способом планирования. Хотя коэффициент использования машины, возможно, несколько упал (а часто и этого не было), производительность поднялась. Для каждого члена команды десять запусков в течение шести часов значительно продуктивнее, чем десять запусков, осуществленных с перерывами в три часа, поскольку постоянная концентрация Количество часов сокращает время обдумывания. После такой гонки команде обычно требовалось один-два дня, чтобы подогнать работу с документами, прежде чем просить о выделении нового блока. Зачастую всего три программиста могут с пользой поделить и распределить между собой выделенный им блок времени. Похоже, что это лучший способ использования целевой машины при отладке новой операционной системы.

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

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

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

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

Этот опыт, однако, сослужил плохую службу при программировании новой машины.

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

Поэтому надежный эмулятор на зрелой машине остается полезным значительно дольше, чем можно было предположить.

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

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

Библиотеки программ и учет. Очень успешным и важным применением вспомогательной машины в программе разработки OS/360 была поддержка библиотек программ. Система, разработанная под руководством У. Р. Кроули (W. R.

Crowley), состояла из двух соединенных вместе машин 7010 и общей дисковой базой данных. На 7010 поддерживался также ассемблер для S/360. В этой библиотеке хранился весь протестированный или находящийся в процессе тестирования код, как исходный, так и ассемблированные загрузочные модули. На практике библиотека была разбита на подбиблиотеки с различными правами доступа.

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

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

Через некоторое время системная версия была готова для более широкого использования. Тогда она перемещалась в подбиблиотеку текущей версии. Этот экземпляр был священным, и доступ к нему разрешался только для исправления разрушительных ошибок. Его можно было использовать для интегрирования и тестирования всех новых версий модулей. Программный каталог на машине отслеживал все версии каждого модуля, его состояние, местонахождение и изменения.

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

По моему мнению, это было одним из лучших решений в программе OS/360. Эта часть технологии управления была независимо разработана для нескольких крупных программных проектов, в том числе в Bell Labs, ICL и Кембриджском университете. Она применима как к программам, так и к документации. Это — неоценимая технология.

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

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

Система документации. Из всех инструментов больше всего труда может сберечь компьютеризированная система редактирования текста, действующая на надежной машине. Наша система, разработанная Дж. У. Франклином (J. W. Franklin), была очень удобна. Я думаю, без нее руководства по OS/360 появились бы значительно позднее и оказались бы более запутанными. Есть люди, которые станут утверждать, что двухметровая полка руководств по OS/360 является следствием недержания речи, и сама ее объемистость являет собой новый тип непостижимости. И доля правды в этом есть.

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

Во-вторых, это гораздо лучше, чем крайняя недостаточность документации, характерная для большинства систем программирования. Я охотно соглашусь, тем не менее, что в некоторых местах текст можно было значительно улучшить, и результатом лучшего описания стал бы меньший объем. Некоторые части (например, «Концепции и средства») сейчас очень хорошо написаны.

Эмулятор производительности. Лучше его иметь. Разработайте его «снаружи внутрь», как описано в следующей главе. Используйте одинаковое проектирование сверху вниз для эмулятора производительности, эмулятора логики и самого продукта. Начните работу с ним как можно раньше. Прислушайтесь к тому, что он вам скажет.

Языки высокого уровня и интерактивное программирование Сегодня два важнейших инструмента системного программирования — это те, которые не использовались при разработке OS/360 почти десятилетие назад. Они до сих пор не очень широко используются, но все указывает на их мощь и применимость. Это: а) языки высокого уровня и б) интерактивное программирование. Я убежден, что только инертность и лень препятствует повсеместному принятию этих инструментов, технические трудности более не являются извинениями.

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

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

Меня эти возможности производительности и отладки ошеломляют. Мне трудно представить себе систему программирования, которую я стал бы создавать на языке ассемблера.

Ну, а как с классическими возражениями против этого инструмента? Их три: я не могу сделать то, что хочу;

результирующая программа слишком велика;

результирующая программа слишком медленна.

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

Что касается скорости, то оптимизирующие компиляторы иногда порождают код, который зачастую выполняется быстрее, чем написанный вручную. Более того, проблемы скорости можно обычно решить, заменив от 1 до 5 процентов скомпилированной программы кодом, написанным вручную, после ее полной отладки. Какой язык высокого уровня следует использовать для системного программирования? Сегодня единственный достойный кандидат — PL/I.6 У него очень полный набор операторов;

он соответствует окружению операционной среды;

имеется целый ряд компиляторов с разными особенностями — интерактивных, быстрых, с улучшенной диагностикой, с высокой степенью оптимизации. Лично я быстрее разрабатываю алгоритмы с помощью APL;

затем я перевожу их в PL/I для соответствия системному окружению.

Интерактивное программирование. Одним из оправданий проекта МТИ MULTICS была его польза для создания систем программирования. MULTICS (и вслед за тем TSS IBM) концептуально отличается от других интерактивных компьютерных систем именно в тех отношениях, которые необходимы для системного программирования:

многоуровневая система разделения доступа и защиты данных и программ, интенсивное управление библиотеками и средства для совместной работы пользователей терминалов. Я убежден, что во многих приложениях интерактивные системы никогда не заменят системы с обработкой пакетных заданий. Но я думаю, что создатели MULTICS привели самые убедительные доводы в ее пользу именно в применении к системному программированию.

Пока есть не много свидетельств действительной плодотворности этих очевидно мощных инструментов. Существует широко распространенное признание того, что отладка является трудной и медленной частью системного программирования, и медленная оборачиваемость — проклятие отладки. Поэтому логика интерактивного программирования кажется неумолимой. Программа Размер Пакетная (П) или Операторов на диалоговая (Д) человека в год Код ESS 800 000 П 500 – Поддержка ESS 7094 120 000 П 2100 – Поддержка ESS 360 32 000 Д Поддержка ESS 360 8 300 П Рис. 12.2 Сравнительная производительность при пакетном и диалоговом программировании Помимо того, есть хорошие отзывы тех, кто разработал таким способом небольшие системы или части систем. Единственные доступные мне данные относительно влияния на программирование больших систем исходят от Джона Харра из Bell Labs.

Они представлены на рисунке 12.2. Эти цифры охватывают написание, ассемблирование и отладку программ. Первая программа является, в основном, управляющей. Остальные три — языковые трансляторы, редакторы и т.п. Данные Харра позволяют предположить, что средства интерактивной работы, по крайней мере, удваивают производительности системного программирования. Эффективное использование большинства интерактивных средств требует, чтобы работа производилась на языке высокого уровня, поскольку телетайп и пишущую машинку нельзя использовать для получения дампа памяти. С использованием языка высокого уровня легко редактировать исходный текст и делать отдельные распечатки. Вместе они действительно составляют пару отточенных инструментов.

Глава 13 Целое и части Глава 13 Целое и части Глава 13 Целое и части Я духов вызывать могу из бездны.

И я могу, и каждый может, Вопрос лишь, явятся ль на зов они?

ШЕKСПИР, KОРОЛЬ ГЕНРИХ IV реди современных кудесников, как и встарь, встречаются хвастуны: «Я могу Списать программы, которые управляют воздушным движением, перехватывают баллистические ракеты, делают переводы по банковским счетам, управляют производственными линиями». На что есть ответ: «И я могу, и каждый может, но будет ли работать то, что ты напишешь?» Как написать программу, которая будет работать? Как протестировать программу? И как объединить набор протестированных программ-компонентов в протестированную и надежную систему? Несколько раз мы уже касались соответствующих приемов, давайте теперь рассмотрим их более систематически.

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

Такую же роль выполняет детализированная трудоемкая работа по разработке архитектуры, подразумеваемая этим подходом. В. А. Высоцкий из проекта Safeguard, выполнявшегося в Bell Telephone Laboratories, говорит так: «Решающая задача — дать определение для продукта. Очень многие неудачи связаны именно с теми аспектами, которые не были вполне специфицированы».1 Тщательное определение функций, тщательная спецификация и старательное избегание всех украшательств функций и полетов технической мысли — все это снижает количество системных ошибок, которые будут обнаружены.

Проверка спецификации. Задолго до написания всякого кода спецификация должна быть передана сторонней группе тестирования для тщательного рассмотрения полноты и ясности. Как считает Высоцкий, сами разработчики сделать это не могут:

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

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

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

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

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

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

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

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

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

Структурное программирование. Другой важный круг идей для разработки, сокращающих число ошибок в программе, исходит то Дейкстры (Dijkstra)3 и построен на теоретической структуре Бёма (Boehm) и Джакопини (Jacopini). В своей основе подход заключается в разработке программ, управляющие структуры которых состоят только из циклов, определяемых такими операторами, как DO WHILE и группами условно выполняемых операторов, ограниченных скобками с использованием операторов условия IF…THEN…ELSE. Бём и Джакопини показывают теоретическую достаточность таких структур. Дейкстра доказывает, что альтернативное неограниченное применение ветвление с помощью GO TO образует структуры, располагающие к появлению логических ошибок.

В основе, несомненно, лежат здравые мысли. При обсуждении сделано много критических замечаний — в частности, большое удобство представляют дополнительные управляющие структуры, такие как n-вариантный переход (так называемый оператор CASE) для различения среди нескольких случаев и аварийный выход (GO TO ABNORMAL END). Кроме того, некоторые догматически избегают всех GO TO, что представляется чрезмерным.

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

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

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

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

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

Главным грехом было смело нажать кнопку START, не разбив предварительно программу на отлаживаемые секции с запланированными остановками.

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

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

Снимки моментального состояния. Машины, для которых были разработаны дампы памяти, имели память размером 2000-4000 слов, или 8-16 Кбайт. Однако размер памяти рос огромными темпами, и делать дамп памяти стало нереальным. Поэтому разработали методы выборочного дампа, выборочной трассировки и вставки в программы команд для моментальных снимков. Вершиной развития этого направления стал TESTRAN в OS/360, позволявший вставлять в программу моментальные снимки без повторной сборки и компиляции.

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

Мультипрограммная система Кодда была разработана, но акцент был сделан на увеличение производительности благодаря эффективному использованию ввода вывода, и интерактивная отладка не была осуществлена. Идеи Стрейчи были улучшены и в 1963 году воплощены Корбато с коллегами в МТИ в экспериментальной системе 7090. Это разработке привела к MULTICS, TSS и другим сегодняшним системам разделения времени.

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

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

Тем не менее интересные экспериментальные данные Голда (Gold) показывают, что во время первого диалога каждого сеанса достигается втрое больший прогресс в интерактивной отладке, чем при последующих диалогах.8 Это убедительно говорит о том, что из-за отсутствия планирования мы не полностью реализуем потенциал диалоговой работы. Пора стряхнуть пыль со старых методов работы в интерактивном режиме.

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

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

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

Контрольные примеры. Что касается разработки фактических процедур отладки и контрольных примеров, особенно удачное изложение предлагает Грюнбергер (Gruenberger),9 есть и более короткие описания в других известных учебниках.10, Системная отладка Неожиданно трудным этапом создания системы программирования оказывается тестирование системы. Я уже обсуждал некоторые причины как его трудности, так и непредсказуемости. Можно не сомневаться в двух вещах: системная отладка займет больше времени, чем предполагается, а ее сложность оправдывает досконально систематичный и плановый подход. Рассмотрим, что включает в себя такой подход. Используйте отлаженные компоненты. Обычный здравый смысл, если не обычная практика, подсказывают, что системную отладку нужно начинать, когда работает каждая составляющая часть.

Далее общепринятая практика следует двумя путями. Первый подход — «свинти и попробуй». Видимо, он основывается на том, что кроме ошибок в компонентах найдутся и ошибки в системе (т.е. в интерфейсах). Чем скорее части будут соединены вместе, тем скорее всплывут системные ошибки. Легко также представить, что, используя компоненты для тестирования друг друга, можно в значительной мере избежать создания окружения для тестирования. И то, и другое, очевидно, является правдой, но, как показывает опыт, не всей правдой:

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

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

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

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

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

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

Предельный случай мини-файла — фиктивный файл, который фактически не существует. Язык управляющих заданий OS/360 имеет такое средство, и оно очень полезно для отладки компонентов.

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

Прежде всего, кто-то должен быть ответственным. Он, и только он должен разрешать изменения в компонентах и замену одной версии другой.

Далее, как обсуждалось выше, система должна иметь контролируемые экземпляры:

один экземпляр с последними версиями, находящийся под замком и используемый для тестирования компонентов;

один тестируемый экземпляр с установленными исправлениями;

рабочие экземпляры каждого сотрудника для внесения исправлений и дополнений в свои компоненты.

В технических моделях System/360 среди обычных желтых проводов можно было иногда видеть фиолетовые провода. При обнаружении дефекта делались две вещи.

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

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

Добавляйте компоненты по одному. Этот рецепт также очевиден, но им часто пренебрегают из-за оптимизма и лени. Чтобы следовать ему, требуются фиктивные программы и разное окружение, а это отнимает время. И в конце концов, вся эта работа может оказаться лишней! Может быть, ошибок и нет!

Нет! Противьтесь соблазну! Это то, в чем заключается систематичное тестирование системы. Нужно предполагать, что ошибок будет много, и планировать упорядоченную процедуру избавления от них.

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

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

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

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

Леман и Белади дают свидетельства в пользу того, что квант изменений должен быть либо очень большим и редким, либо очень маленьким и частым.14 Последняя стратегия, согласно их модели, больше подвержена неустойчивости. Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.

Квантовые изменения хорошо вписываются в технологию фиолетовых проводов.

Быстрая заплатка держится до следующей регулярной версии компонента, которая должна содержать исправление в отлаженном и документированном виде.

Глава 14 Назревание катастрофы Глава 14 Назревание катастрофы Глава 14 Назревание катастрофы Никто не любит приносящего дурные вести.

СОФОKА Kак оказывается, что проект запаздывает на год?

... Сначала запаздывает на один день.

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

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

Вехи или помехи?

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

Для выбора всех вех есть только одно пригодное правило. Вехами должны служить конкретные особые события, которые можно идентифицировать с полной определенностью. В качестве отрицательных примеров отметим, что написание программы «закончено на 90 процентов» в течение половины всего времени кодирования. Отладка «закончена на 99 процентов» почти всегда. «Планирование завершено» — событие, которое можно объявить почти произвольно. Напротив, вехи должны быть 100-процентными событиями. «Спецификации подписаны архитекторами и разработчиками», «исходный код готов на процентов, отперфорирован и загружен в библиотеку на диске», «отлаженная версия прошла все контрольные примеры». Такие конкретные вехи разграничивают расплывчатые этапы планирования, кодирования и отладки.

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

Два интересных исследования поведения правительственных подрядчиков по проведению оценок в крупномасштабных исследовательских проектах показали:

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

2. После начала работы завышенные изначально оценки постоянно уменьшаются по мере продвижения.

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

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

«Другая часть тоже опаздывает» Отставание от графика на один день — ну и что? Кого волнует отставание на один день? Позже нагоним. Другая часть, в которую входит наша, тоже отстает на один день.

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

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

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

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

Подготовка диаграмм ПЕРТ есть самая ценная часть ее применения. Определение топологии сети, указание зависимостей в ней и оценивание путей заставляют выполнить большой объем очень конкретного планирования на самых ранних стадиях проекта. Первая диаграмма всегда ужасна, и для создания второй приходится проявить много изобретательности.

Во время выполнения проекта диаграмма ПЕРТ дает ответ на деморализующие извинения типа «другая часть тоже запаздывает». Она показывает, когда необходимо развить энергию, чтобы увести свою часть работы с критического пути, и подсказывает способы наверстать потерянное время в других частях.

Под ковром Когда менеджер низового звена видит, что его маленькая команда отстает, он не склонен бежать к начальнику со своим горем. Возможно, команда сумеет наверстать время, либо он сможет что-нибудь придумать или реорганизовать для решения проблемы. Зачем же беспокоить этим начальника? До поры до времени это допустимо. Для того и существуют менеджеры низового звена, чтобы решать такие проблемы. А у начальника достаточно других забот, требующих его вмешательства, чтобы искать новые. Так вся эта грязь заметается под ковер.

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

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

У начальника есть два способа заглянуть под коврик. Использовать нужно оба.

Первый — уменьшить конфликт ролей и стимулировать открытие информации.

Второй — сдернуть коврик.

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

Напротив, если менеджер знает, что его начальник воспримет отчет без паники или вмешательства, он будет давать честные оценки.

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

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

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

В. Высоцкий из Bell Telephone Laboratories добавляет следующее наблюдение:

Для меня оказалось удобным иметь в отчете о состоянии дел две даты — «плановую» и «оцениваемую». Плановые даты принадлежат менеджеру проекта и представляют собой последовательный план работы для проекта в целом, a priori являющийся приемлемым. Оцениваемые даты принадлежат менеджерам низшего звена, в переделах компетенции которых находятся рассматриваемые участки, и представляют их мнения о сроке фактического наступления события при имеющихся у них ресурсах и получении входных данных (или обязательствах об их поставке). Менеджер проекта должен осторожно относиться к оцениваемым датам и стремиться к получению точных, неискаженных оценок, а не утешительно-оптимистичных или перестраховочно консервативных данных. Если эта позиция утвердится в умах, то менеджер Рис. 14. проекта действительно сможет предвидеть, что он попадет в беду, если не предпримет каких-нибудь мер. Создание диаграммы ПЕРТ является обязанностью начальника и подотчетных ему менеджеров. Внесение в нее изменений, пересмотр и подготовка отчетности должны осуществляться небольшой (от одного до трех человек) группой, как бы продолжающей начальника. Такая группа планирования и контроля неоценима при работе над большим проектом. Она не обладает иными полномочиями, кроме как требовать от менеджеров низового звена предоставления сведений об установке или изменении вех и их достижении. Поскольку группа планирования и контроля осуществляет всю бумажную часть работы, нагрузка на менеджеров низового звена ограничивается самым важным — принятием решений.

У нас была умелая, энергичная и дипломатичная группа планирования и контроля, возглавлявшаяся А. М. Пьетрасанта (A. M. Pietrasanta), проявившим значительные изобретательные способности для разработки эффективных, но ненавязчивых методов контроля. В результате его группа пользовалась широким уважением и хорошим отношением. Это немалое достижение для группы, которая по природе своей должна вызывать раздражение.

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

Глава 15 Обратная сторона Глава 15 Обратная сторона Глава 15 Обратная сторона Чего мы не понимаем, тем не владеем.

ГЕТЕ О, дайте мне выступить комментатором, Скользящим по поверхности и будоражащим умы.

KРАББ омпьютерная программа — это послание человека машине. Строго выстроенный К синтаксис и тщательные определения нацелены на то, чтобы бездумной машине стали понятны намерения человека.

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

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

Многие из нас бранили далекого безымянного автора за скудно документированную программу. И многие поэтому пытались на всю жизнь привить молодым программистам уважение к документации, преодолевающее лень и пресс графика работ. В целом нам это не удалось. Я думаю, мы использовали неверные методы.

Томас Дж. Уотсон Старший* (Thomas J. Watson, Sr.) рассказал мне историю своего первого опыта в качестве продавца кассовых аппаратов в северной части штата Нью-Йорк. Исполненный энтузиазма, он отправился в путь в своем фургоне, нагруженном кассовыми аппаратами. Он прилежно объехал свой участок, но ничего не продал. Обескураженный, он сообщил об этом своему хозяину. Послушав некоторое время, управляющий сказал: «Помоги мне загрузить несколько касс в фургон, запрягай лошадь, и поедем снова.» Так они и сделали, и обходя покупателей одного за другим, старик показывал, как продавать кассовые аппараты.

Судя по всему, урок пошел впрок.

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

Тогда я попробовал погрузить в повозку несколько кассовых аппаратов, т.е.

показать им, как делается эта работа. Это имело значительно больший успех.

Поэтому оставшаяся часть этого повествования посвящена не столько поучениям, сколько объяснению того, как делать хорошую документацию.

Какая документация требуется?

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

Чтобы использовать программу. Каждому пользователю требуется словесное описание программы. По большей части документация страдает отсутствие общего обзора. Описаны деревья, прокомментированы кора и листья, но план леса * Томас Дж. Уотсон Старший — основатель компании IBM (примеч. перев.) отсутствует. Чтобы написать полезное текстовое описание, взгляните издалека, а затем медленно приближайтесь:

1. Назначение. Что является главной функцией программы и причиной ее написания?

2. Среда. На каких машинах, аппаратных конфигурациях и конфигурациях операционной системы будет она работать?

3. Область определения и область значений. Каковы допустимые значения входных данных? Какие правильные значения выходных результатов могут появиться?

4. Реализованные функции и использованные алгоритмы. Что конкретно может делать программа?

5. Форматы ввода-вывода, точные и полные.

6. Инструкция по работе, в том числе описание вывода на консоль и устройство вывода при нормальном и аварийном завершении.

7. Опции. Какой выбор предоставляется пользователю в отношении функций?

Каким образом нужно его задавать?

8. Время работы. Сколько времени занимает решение задачи заданного размера на заданной конфигурации?

9. Точность и проверка. Какова ожидаемая точность результатов? Какие имеются средства проверки точности?

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

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

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

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

1. Основные параметры, проверяющие главные функции программы на обычно встречаемых данных.

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

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

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

1. Блок-схема или граф подпрограммной организации. Подробнее об этом см.

ниже.

2. Полные описания используемых алгоритмов или ссылки на такие описания в литературе.

3. Разъяснение структуры всех используемых файлов.

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

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

Бич блок-схем Блок-схема чаще всего является лишней частью программной документации. Для многих программ блок-схемы вообще не нужны. Редкие программы требуют блок схемы более чем на одну страничку.

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

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

MAIN PL/I ROUTINES GSP LINKAGE EXTERNAL VARIABLES Node MODE INITIAL MODE0 MODE1 MODE3 MODE STACKER MESSAGE Node DISPLAY INIT2 GPRIM LIGHTS SCALEN IPRIM Node INTERNL BINDING CLASH FORCE TORQUE GRAD Рис. 15.1 Граф структуры программы (пример W. V. Wright) Конечно, такой структурный граф не требует особых усилий по соблюдению стандартов ANSI для блок-схем. Все эти правила относительно вида прямоугольников, соединительных линий, нумерации и т.п. нужны только для понимания подробных блок-схем.

Подробная пошаговая блок-схема является досадным анахронизмом, пригодным только для новичков в алгоритмическом мышлении. Введенные Голдштайном и фон Нейманом1 прямоугольники вместе со своим содержимым служили языком высокого уровня, объединяя непостижимые операторы машинного языка в осмысленные группы. Как давно понял Иверсон,2 в систематическом языке высокого уровня группировка уже проведена, и каждый прямоугольник содержит оператор (рис.

15.2). Поэтому сами прямоугольники являются утомительным и отнимающим место упражнением в черчении и вполне могут быть удалены. Тогда остаются только стрелки. Стрелки, связывающие один оператор с другим, расположенным в следующей строке, излишни, и их можно удалить. Тогда остаются только GO TO, и если придерживаться хорошей практики программирования и использовать блочные структуры для минимизации числа GO TO, таких стрелок окажется немного, но они очень способствуют пониманию. Вполне можно нарисовать их на листинге и вовсе избавиться от блок-схемы.

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

Многие гордятся использованием специальных программ для генерации этого «незаменимого инструмента разработки» на основе уже законченной программы.

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

Апостол Петр сказал о новообращенных язычниках и законе Моисея: «Что же вы [желаете] возложить на выи учеников иго, которого не могли понести ни отцы наши, ни мы?» (Деяния апостолов 15:10). То же сказал бы я о программистах-новичках и устаревшей практике блок-схем.

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

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

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

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

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

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

В качестве важнейшей цели мы должны попытаться предельно уменьшить груз документации — груз, с которым ни мы, ни наши предшественники толком не справились.

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

A PGN4: PROCEDURE OPTIONS (MAIN);

START DECLARE SALESFL FILE RECORD INPUT ENVIRONMENT (F(80) MEDIUM (SYSIPT, 2501));

B DECLARE PRINT4 FILE DEFINE INPUT RECORD AND OUTPUT OUTPUT ENVIRONMENT (F(132) MEDIUM (SYSLST, 1403) CTLASA);

FILES DECLARE 01 SALESCARD, 03 BLANK1 CHARACTER (9), C 03 SALESNUM PICTURE '9999', 03 NAME CHARACTER (25), 03 BLANK2 CHARACTER (7), OPEN FILES 03 CURRENT_SALES PICTURE '9999V99', 03 BLANK3 CHARACTER (29);

From K3, D4 D3 DECLARE 01 SALESLIST, 03 CONTROL CHARACTER (1) INITIAL (' '), D 03 SALESNUM_OUT PICTURE 'ZZZ9', 03 FILLER1 CHARACTER (5) INITIAL (' '), READ A 03 NAME_OUT CHARACTER (25), CARD 03 FILLER2 CHARACTER (5) INITIAL (' '), 03 CURRENT_OUT PICTURE 'Z,ZZZV.99', 03 FILLER3 CHARACTER (5) INITIAL (' '), 03 PERCENT PICTURE 'Z9', E 03 SIGN CHARACTER (1) INITIAL ('%'), 03 FILLER4 CHARACTER (5) INITIAL (' '), LAST Yes 03 COMMISSION PICTURE 'Z,ZZZV.99' A CARD?

03 FILLER5 CHARACTER (63) INITIAL (' ');

No OPEN FILE (SALEFL), FILE (PRINT4);

F Sales less ON ENDFILE(SALEFL) GO TO ENDOFJOB;

then 1000. COMPARE SALES TO A 1000. Sales equal to or greater then 1000. G MOVE SALESMAN, NAME, CURRENT TO OUTPUT H READ_CARD:

SET PERCENT READ FILE (SALEFL) INTO (SALESCARD);

TO IF CURRENT_SALES < 1000.00 THEN GO TO UNDER_QUOTA;

SALESNUM_OUT = SALESNUM;

NAME_OUT = NAME;

CURRENT_OUT = CURRENT_SALES;

J PERCENT = 5;

COMMISSION = CURRENT_SALES *.05;

MULTIPLY WRITE FILE (PRINT4) FROM (SALESLIST);

CURRENT GO TO READ_CARD;

SALES BY K WRITE A LINE D Рис. 15.2 Сравнение блок-схемы и соответствующей программы на PL/I (фрагмент) Второе предложение — в максимальной мере использовать пространство и формат, чтобы улучшить читаемость и показать отношения подчиненности и вложенности.

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

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

Поскольку подход на основе самодокументирования сокращает дополнительную работу, меньше препятствий к его осуществлению.

Некоторые приемы. На рисунке 15.3 показана самодокументирующаяся программа на языке PL/I.3 Числа в кружочках не являются ее частью, а служат метадокументацией для ссылок при обсуждении.

1. Используйте для каждого запуска свое имя задания и ведите журнал, в котором учитывайте предмет проверки, время и полученные результаты. Если имя состоит из мнемоники (здесь QLT) и числового суффикса (здесь 4), то суффикс можно использовать в качестве номера запуска, связывающего запись в журнале и листинг. При этом для разных прогонов требуются свои карты задания, но их можно делать колодами с дублированием постоянных данных.

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

Здесь индекс — две младшие цифры года.

3. Включите текстовое описание в качестве комментариев к PROCEDURE.

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

5. Покажите связь с алгоритмом, описанным в книге: а) изменения;

б) особенности использования;

в) представление данных.

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

7. Поставьте метку в начале инициализации.

8. Поставьте метки перед группами операторов, соответствующие операторам алгоритма, описанного в книге.

9. Используйте отступы для показа структуры и группирования.

10. Вручную поставьте стрелки, показывающие логический порядок операторов.

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

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

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

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

1 //QLT4 JOB...

QLTSRT7: PROCEDURE (V);

/***************************************************************************/ /*A SORT SUBROUTINE FOR 2500 6-BYTE FIELDS, PASSED AS THE VECTOR V. A */ /*SEPARATELY COMPILED, NOT-MAIN PROCEDURE, WHICH MUST USE AUTOMATIC CORE */ /*ALLOCATION. */ /* */ /*THE SORT ALGORITHM FOLLOWS BROOKS AND IVERSON, AUTOMATIC DATA PROCESSING,*/ /*PROGRAM 7.23, P. 350. THAT ALGORITHM IS REVISED AS FOLLOWS: */ /* STEPS 2-12 ARE SIMPLIFIED FOR M=2. */ /* STEP 18 IS EXPANDED TO HANDLE EXPLICIT INDEXING OF THE OUTPUT VECTOR. */ /* THE WHOLE FIELD IS USED AS THE SORT KEY. */ /* MINUS INFINITY IS REPRESENTED BY ZEROS. */ /* PLUS INFINITY IS REPRESENTED BY ONES. */ /* THE STATEMENT NUMBERS IN PROG. 7.23 ARE REFLECTED IN THE STATEMENT */ /* LABELS OF THIS PROGRAM. */ /* AN IF-THEN-ELSE CONSTRUCTION REQUIRES REPETITION OF A FEW LINES. */ /* */ /*TO CHANGE THE DIMENSION OF THE VECTOR TO BE SORTED, ALWAIS CHANGE THE */ /*INITIALIZATION OF T. IF THE SIZE EXCEEDS 4096, CHANGE THE SIZE OF T, TOO.*/ /*A MORE GENERAL VERSION WOULD PARAMETERIZE THE DIMENSION OF V. */ /* */ /*THE PASSED INPUT VECTOR IS REPLACED BY THE REORDERED OUTPUT VECTOR. */ /***************************************************************************/ /* LEGEND (ZERO-ORIGIN INDEXING) */ DECLARE (H, /*INDEX FOR INITIALIZING T */ I, /*INDEX OF ITEM TO BE REPLACED */ J, /*INITIAL INDEX OF BRANCHES FROM NODE I */ K) BINARY FIXED, /*INDEX IN OUTPUT VECTOR */ (MINF, /*MINUS INFINITY */ PINF) BIT (48), /*PLUS INFINITY */ V (*) BIT (*), /*PASSED VECTOR TO BE SORTED AND RETURNED */ T (0:8190) BIT (48);

/*WORKSPACE CONSISTING OF VECTOR TO BE SORTED, FILLED*/ /*OUT WITH INFINITIES, PRECEDED BY LOWER LEVELS */ /*FILLED UP WITH MINUS INFINITIES */ /* NOW INITIALIZATION TO FILL DUMMY LEVELS, TOP LEVEL, AND UNUSED PART OF TOP*/ /* LEVEL AS REQUIRED. */ INIT: MINF= (48) '0'B;

PINF= (48) '1'B;

DO L= 0 TO 4094;

T(L) = MINF;

END;

DO L= 0 TO 2499;

T(L+4095) = V(L);

END;

DO L=6595 TO 8190;

T(L) = PINF;

END;

8 K0: K = -1;

K1: I = 0;

/* <--------+*/ K3: J = 2*I+1;

/*SET J TO SCAN BRANCHES FROM NODE I. <-------+|*/ K7: IF T(J) <= T(J+1) /*PICK SMALLER BRANCH -- > --+||*/ THEN /* |||*/ DO;

9 /* |||*/ K11: T(I) = T(J);

/*REPLACE |||*/ K13: IF T(I) = PINF THEN GO TO K16;

/*IF INFINITY, REPLACEMENT- +8 -+|||*/ /* IS FINISHED ||||*/ K12: I = J /* SET INDEX FOR HIGHER LEVEL ||||*/ END;

/* ||||*/ ELSE /* <-----++||*/ DO;

/* | ||*/ K11A: T(I) = T(J+1);

/* | ||*/ K13A: IF T(I) = PINF THEN GO TO K16;

/* - +8 -+ ||*/ K12A: I = J+1;

/* | ||*/ END;

/* | ||*/ K14: IF 2*I < 8191 THEN GO TO K3;

/*GO BACK IF NOT ON TOP LEVEL -- < -+-+|*/ K15: T(I) = PINF;

/*IF TOP LEVEL, FILL WITH INFINITY | |*/ K16: IF T(0) = PINF THEN RETURN /*TEST END OF SORT <-----+ |*/ K17: IF T(0) = MINF THEN GO TO K1;

/*FLUSH OUT INITIAL DUMMIES - -8 ----|*/ K18: K = K+1;

/*STEP STORAGE INDEX |*/ V(K) = T(0);

GO TO K1;

/*STORE OUTPUT ITEM ---------|*/ END QLTSRT7;

Рис. 15.3 Самодокументирующаяся программа Самым серьезным возражением является увеличение размера исходного текста, который нужно хранить. Поскольку практика все более тяготеет к хранению исходного кода в активных устройствах, это вызывает растущее беспокойство. Лично я пишу более краткие комментарии в программах на APL, которые хранятся на диске, чем в программах на PL/I, которые хранятся на перфокартах.

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

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

А что же блок-схемы и структурные графы? Если используется только структурный граф самого высокого уровня, он вполне может содержаться в отдельном документе, поскольку редко подвергается изменениям. Но конечно, его можно включить в исходный текст программы в качестве комментария, что будет благоразумно.

В какой мере описанные выше приемы применимы для программ на языке ассемблера? Я думаю, что базовый подход документирования применим всюду.

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

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

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

Резюме Создание программного обеспечения всегда включает в себя существенные задачи — моделирование сложных концептуальных структур, составляющих абстрактный программный объект, и второстепенные задачи — создание представлений этих абстрактных объектов с помощью языков программирования и отображение их в машинные языки с учетом ограничений по памяти и скорости. В прошлом рост продуктивности программирования по большей части достигался благодаря устранению искусственных преград, делавших второстепенные задачи чрезмерно трудными, например, жестких аппаратных ограничений, неудобных языков программирования, нехватки машинного времени. Какая часть работы разработчиков программного обеспечения все еще связана со второстепенными, а не с существенными обстоятельствами? Если она занимает менее 9/10 всех затрат, то, даже сведя все второстепенные затраты к нулю, мы не получим роста производительности на порядок величин.

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

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

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

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

• Выявлять и растить выдающихся разработчиков концепций нового поколения.

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

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

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

Но, вглядываясь в предстоящее десятилетие, мы не видим никакой серебряной пули.

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

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

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

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

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

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

Акциденции я рассматриваю в следующем параграфе. Сначала рассмотрим сущность.

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

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

Верно то, что создание программных систем всегда будет трудным. Серебряной пули нет по самой природе вещей.

Рассмотрим неотъемлемые свойства этой несократимой сущности современных программных систем: сложность, согласованность, изменяемость и незримость.

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

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

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

Сложность программ является существенным, а не второстепенным свойством.

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

Многие классические трудности разработки программного обеспечения проистекают их этой сложности сущности и ее нелинейного роста при увеличении размера.

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

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

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

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

У разработчика программного обеспечения нет такой утешительной веры.

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

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

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

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

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

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

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

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

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

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

Несколько графов могут представлять управляющие потоки, потоки данных, схемы зависимостей, временных последовательностей, соотношений пространства имен.

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

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

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

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

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

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

Pages:     | 1 || 3 | 4 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.