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

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

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

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

С этого времени мы перешли на микрофиши, что сберегло миллион долларов даже с учетом стоимости устройств для чтения микрофишей в каждом офисе. Мы смогли достичь отличной продолжительности цикла производства микрофишей. Рабочая тетрадь уменьшилась в объеме с 90 дм [3] до 5 дм [3] и, что более важно, обновления выпускались порциями по сотне страниц, стократно уменьшая сложность замены листов.

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

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

Как можно осуществить это сегодня? Сегодняшние системные технологии, я думаю, делают предпочтительнее ведение рабочей тетради в файле прямого доступа с полосками, помечающими измененные части, и датами внесения изменений. Любой пользователь может обратиться к журналу с дисплейного терминала. Сводка изменений, готовящаяся ежедневно, должна храниться в виде стека (LIFO) с установленной точкой доступа. Программист может ежедневно ее читать, но если он пропустил один день, ему придется дольше читать на следующий день. Прочтя об изменениях, он может прерваться и прочесть сам измененный текст.

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

Д. Л. Пранас и Университета Карнеги-Мелона предложил еще более радикальное решение. [1] Он полагает, что производительность программиста выше всего, когда он огражден от подробностей конструкции тех частей системы, над которыми он не работает. Это предполагает, что все интерфейсы полностью и точно заданы. Такой проект определенно хорош, но если полагаться на его идеальное осуществление, это приведет к катастрофе. Хорошая информационная система не только должна выявлять ошибки в интерфейсах, но и способствовать их исправлению.

Организация крупного программного проекта

Если над проектом работает n человек, то существует (n [2] –n)/2 интерфейсов, через которые может происходить обмен данными, и потенциально существует почти 2 n групп, внутри которых должно происходить согласование. Цель организации работы состоит в сокращении необходимого объема обмена информацией и согласования. Поэтому создание правильной организационной структуры является решающим направлением решения проблем информационного обмена, рассматривавшихся выше.