С концепцией единства проектирования согласны и Милс, и Уитт, и Лингер, с ней согласны также Йенсен и Тонис[19]. Мой опыт говорит, что автором проекта больших систем является обычно один человек. Этот человек определяет направление работ.
Как говорится, о вкусах спорить не приходится. Система диспетчеризации воздушных перевозок доводилась до рабочего состояния в течение 10 лет (совершенно завершена эта работа не будет никогда), за этот период времени заказчик провел немало разных ревизий. Одна ревизия, которую проводила группа независимых экспертов по программному обеспечению, констатировала, что проект управляющей (системной) программы выполнен «архаичными методами и неправильно». Несмотря на это, после завершения работ программа прекрасно работала. (Но скольким толкам дал пищу этот отзыв!)
Некоторые руководители разработок программного обеспечения толкают своих программистов на постоянное использование новейших, самых «привлекательных» методов. Они пытаются привычные вещи делать новыми способами или находить новые работы. Этих программистов снабжают инструментарием, специально проектировавшимся с расчетом на творческое использование. Мы должны называть такие работы не разработками программного обеспечения, а научными исследованиями.
С другой стороны, находятся такие руководители, которые уже закончили проект и теперь хотят, чтобы были написаны программы размером в 400 000 строк или около того. А после того как программы будут написаны, их надо будет отправить пользователям и заняться их сопровождением. Этим руководителям не нужна ни привлекательность, ни изобретательская деятельность. Им требуется надежность, ясность, воспроизводимость. Им нужны простые, незатейливые программы.
Проектирование — это все же искусство и что-то еще, что мы еще недостаточно понимаем. Стравинский называл искусство «творчеством, требующим скачка воображения». Может быть, и существуют проекты, которые не являются произведениями искусства, а возникают в результате простого следования образцам — проекты мостов, зданий, одежды и т. д. — но нужно ли нам называть их проектами?
Мы обнаруживаем то, что не работает, и исправляем это место. Когда мы первый раз выполнили мультипроцессорную обработку в системе диспетчеризации воздушных перевозок, то обнаружили, что процедура блокировки (дающая гарантию того, что ни второй, ни третий, ни четвертый центральные процессоры не смогут работать с той записью, которая обрабатывается в данный момент, и не нарушат достоверность данных) работала слишком уж хорошо. Нашим центральным процессорам приходилось лишь лениво дожидаться, когда будет снята блокировка. На втором проходе мы укоротили все процедуры, выполнявшиеся в режиме «блокировки».
При проектировании возникает много компромиссных решений, одно за счет другого — например увеличение занимаемой памяти и за счет этого повышение скорости выполнения программы. Так же как авиаконструктор постоянно жертвует ради увеличения веса и скоростью, и экономичностью двигателя, так и проектировщик программного обеспечения должен принимать во внимание все 12 свойств программ во всех их взаимоотношениях и еще множество других характеристик, которые связаны и с программой, и с теми функциями, которые ею автоматизируются. Что произойдет с остальной частью системы? Что изменится в радиолокаторе? В окружении? Не поглотят ли наш банк другие, более крупные банки? Или его просто вытеснят из данной сферы деятельности?
Мы уже видели, что в работе над созданием программы для приложений типа V гораздо меньше требуется усилий, чтобы написать, чем для того, чтобы понять поставленную задачу и свои возможности, сформулировать требования, понять их и объяснить проектировщикам и кодировщикам. Для понимания требований обычно нужны опытные, профессионально подготовленные специалисты, которые либо ранее занимались автоматизацией этой же области, либо имеют достаточную квалификацию, чтобы воспринимать информацию от тех, кто выполняет работу в настоящее время.
19