Если ваше задание достаточно велико, будет крайне глупо оценивать результаты сотен программистов, основываясь на производительности лучшего из них.
Главный программист
Предположим, мы хотим задать вопрос: в какой момент следует разделить программу на две части и поручить программирование двум программистам? На этот вопрос нет полного всеобъемлющего ответа. Только в идеальном случае можно избежать разделения программы на отдельные части. С той минуты, как вы поделили работу и поручили ее выполнение двум работникам, они должны начать контактировать друг с другом, и тут же возникнут излишняя трата времени, путаница, появятся ошибки.
Очень многое зависит от работы, которую надо выполнить, от программиста, которому она поручена, времени, за которое нужно ее сделать, а также от тех средств, которые можно использовать при написании программ. В проекте системы для газеты «Нью-Йорк таймс» один программист, Т. Бейкер, за 22 мес. создал работающую программную систему, состоящую из 83 тыс. операторов на языке высокого уровня. Этим успехом мы обязаны тому, что в работе был применен метод X. Милса под названием «Группа главного программиста». Бейкер работал так, как работает хирург вовремя операции. Ему помогал библиотекарь, выполняющий все канцелярские дела, включая черную работу по отправке программ на вычислительную машину для проведения трансляции. Инструментальные средства, необходимые Бейкеру, поддерживались в нужном порядке кем-то еще. Один помощник проверял программы Бейкера и давал ему советы.
Ясно, что, поскольку работа выполнялась одним человеком, производительность сильно возросла.
Метод главного программиста прекрасно проявил себя в проекте для «Нью-Йорк таймс» и еще в нескольких проектах после него. Но у этого метода есть один недостаток. Главный программист может проделать такой объем работы, только если он в шесть — десять раз превышает средний объем. Этот метод тем не менее не подходит для больших проектов, программы которых составляют сотни тысяч строк программного текста.
Если объем программ меньше 100 тыс. строк, то метод главного программиста работает хорошо. Не так уж часто нам приходится работать над такими «небольшими» проектами. Ни разу нам не удалось добиться хорошей работы по методу «группы групп».
Из-за того что метод главного программиста был впервые применен в проекте «Нью-Йорк таймс», многие решили, что он является частью структурного программирования. Это не так!
Некоторые утверждали, что работы для «Нью-Йорк таймс» кончились неудачно. Но это не так. Мы (фирма IBM) сэкономили около 700 тыс. долларов, а система работала. Первое время в редакции «Нью-Йорк таймс» было слишком мало людей, которые имели опыт работы с системой. По мере подключения сотрудников газеты к работе в системе начались обычные проблемы перехода, которые всегда возникают при перекладывании ответственности за систему с группы разработчиков на группу сопровождения. Эти нормальные трудности были кое-кем неправильно истолкованы с целью бросить тень на великолепные результаты, полученные благодаря структурному программированию и использованию метода главного программиста.
Мне до сих пор досаждают вопросами вроде того, сколько же надо платить программистам, а я отвергаю эти вопросы с самого начала. Для оценки качества программ, создаваемых разными людьми в единицу времени, нужно учитывать по крайней мере 27 разных параметров. И прежде всего нужно определить, что представляет собой эта самая строка текста. Об этом мы поговорим в гл.6, посвященной производительности и ее оценкам.
Библиотекарь
Сравнительно новым методом, применяемым при разработке программного обеспечения, является использование библиотекаря. В прошлом программисты тратили очень много времени на то, чтобы перебирать колоды перфокарт, подготавливать распечатки программ, и на другие подобные мелочи. Вся эта канцелярщина теперь поручена библиотекарям.
Рис. 5.40 Работа над проектом с помощью библиотеки и библиотекарей.
Но дополнительным преимуществом их привлечения оказалось то, что все программы, написанные программистами, теперь бывают собраны в некотором централизованном доступном хранилище.
Почти неуловимое, но весьма важное изменение произошло в процессе разработки программного обеспечения. Программы стали собственностью организации, в то время как раньше они были собственностью программистов вплоть до тех пор, пока работа над ними не бывала закончена. Редко какой программист показывал своим товарищам все свои неудачные попытки заставить программу работать правильно. Если на это ушло девять пусков, кто об этом будет знать? Такая свобода порождала неопределенность в проведении процесса программирования. Она порождала — или по крайней мере сильно облегчала — поспешные решения, сильно ударяла по всей методологии выполнения работ.
Теперь руководитель работ может просмотреть легко читаемые, структурированные программы, которые вводятся в машину, и увидеть, сколько попыток сделал программист Джонс, чтобы получить работающую программу. Из частного дела программирование превращается в общественное.
«Библиотека» не имеет никакого отношения к библиотекарю. Библиотека — это собрание программ, обычно вспомогательных, которые могут найти применение в любое время.
Некоторые неправильно считают использование библиотекаря частью методики структурного программирования. Это разные понятия и методы.
На рис. 5.40 показаны и автоматический библиотекарь, работающий совместно с программами ведения диалога, и люди, которые были назначены библиотекарями для данного проекта.
Компоновка программ
Сборка большого числа модулей в одну работающую систему программного обеспечения
На этой фазе разработчики получают уже написанные программистом или группой программистов и даже до некоторой степени уже оттестированные программы и соединяют их в единое целое, таким образом, что вычислительная машина сможет выполнить сразу десятки или даже сотни программ, от самого начала до самого конца, получив в конце концов желаемый результат или выполнив желаемый процесс.
Я выбрал слово «компоновка» потому, что оно и в окружающем нас мире означает соединение заранее изготовленных частей в целое изделие. Именно этим мы и занимаемся при создании большой системы программного обеспечения.
Шесть фаз, выделенные нами в разработке программ, таковы:
Определение требований
Проектирование
Написание команд, программирование
Компоновка
Тестирование, или верификация
Документирование
Если нам нужна единственная, выполняемая сама по себе программа, фаза компоновки будет отсутствовать.
Причина, вынуждающая нас выделить компоновку в качестве отдельной фазы разработки программного обеспечения, состоит в том, что для такого рода деятельности в изобилии имеются новые автоматические средства. В прошлом подобная работа выполнялась вручную и, следовательно, очень медленно. В настоящее время в нашем распоряжении оказалось значительное количество программ, автоматически выполняющих компоновку систем программ из сотен подпрограмм.
Эти средства жестко связаны с выбранным ранее языком программирования, а иногда и с операционной системой, но все же стоят особняком от них.
Например, с языком программирования Ада, который, видимо, будет стандартизован министерством обороны, связан большой набор программ сопровождения, составляющих некоторое «окружение», которое могут использовать разработчики программного обеспечения для компоновки длинных цепочек программ [30]. Это окружение носит название APSE (Ada Programming Support Environment — окружение сопровождения программирования на языке Ада), в сам язык встроены специфические конструкции и описатели, позволяющие обращаться к элементам окружения.
