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

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

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

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

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

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

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

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

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

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

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

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

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

1 — задание,

2 — продюсер,

3 — технический директор или архитектор,

4 — график работ,

5 — разделение труда,

6 — определение интерфейсов между разными частями.

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