Программное обеспечение и его разработка

Группа работала в Гейтсбурге, очень часто наведываясь в Нью-Йорк. Они выполнили свою работу — 83 тыс. операторов на языке высокого уровня — превосходным образом за 22 месяца, затратив около 300 000 долларов. Ошибок в системе практически не было, она была готова в срок, система была создана и заработала! Вот так-то! Мы сэкономили около 700 000 долларов!

Когда я (я вступил в свою должность в декабре 1969 г.) выдавал Милсу, Бейкеру и другим крупную денежную премию, я обнаружил, что во всей фирме IBM никто не имеет никаких статистических данных по производительности труда! Сколько строк программы считается нормальным написать за один человеко-месяц? Никто этого не знал. Ни у кого даже не было точного определения «строки программы». Все были согласны с тем, что они заслужили премию, но во сколько раз они повысили производительность труда — в 5 раз (как считал я) или всего в 3? В результате мы решили внедрить в Центре федеральных систем систему измерений программ, которой постоянно пользовались в течение более чем 8 лет. Собирались статистики и данные по всем аспектам проектов; база данных содержит ныне колоссальное число данных по 100 проектам. Это единственное в своем роде собрание из всех, с которыми мне приходилось сталкиваться! Мы обратимся к нему позднее в этой же главе.

Мы постановили, что при разработке всех новых проектов надо пользоваться методами структурного программирования. К моему изумлению, реакция опытных программистов была крайне отрицательной! «Что понимает в программировании этот Милс?» «Работа для „Таймс“ это счастливая случайность!» «Все сделал Бейкер». «Милс и Бейкер — это не средние люди». С этим-то я согласен! Но мы настояли на своем, и это было правильное решение. Мы истратили уйму денег и сил на обучение более чем 2600 человек. Две недели занятий с 2600 людьми составляют 100 человеко-лет! Нет никаких сомнений в том, что это было правильное решение

Причиной того, что работа для «Нью-Йорк таймс» была выполнена с такой высокой производительностью, было то, что Милс и Бейкер еще в 1970–71 г. использовали множество самых передовых методов разработки программного обеспечения. Среди них:

структурное программирование,

метод главного программиста,

метод реализации сверху-вниз,

использование библиотекаря,

сквозной контроль,

формальные грамматики.

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

Преимущества структурного программирования

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

Приемлемость структурного программирования

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

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

Хорошее проектирование

Хорошее проектирование приводит к ясному проекту; в таком проекте имеется внутреннее единство. В своей книге «Мифический человеко-месяц» Брукс [18] упоминает европейские соборы, строившиеся по нескольку веков. Наиболее эффектны из них те, в которых видна идея самого первого архитектора. К «плохим» относятся те соборы, в которые каждое столетие вносилось что-нибудь от очередного строителя. Многие языки программирования не прижились потому, что их создатели попытались объединить в них слишком много разноречивых свойств. В связи с этим Брукс упоминает язык PL/1.

18

Brooks F. P. Jr., The Mythical Man-Month (Reading, Mass.; Addison-Wesley, 1975). Русский перёвод см. примечание на стр. 5.

С концепцией единства проектирования согласны и Милс, и Уитт, и Лингер, с ней согласны также Йенсен и Тонис [19] . Мой опыт говорит, что автором проекта больших систем является обычно один человек. Этот человек определяет направление работ.

Как говорится, о вкусах спорить не приходится. Система диспетчеризации воздушных перевозок доводилась до рабочего состояния в течение 10 лет (совершенно завершена эта работа не будет никогда), за этот период времени заказчик провел немало разных ревизий. Одна ревизия, которую проводила группа независимых экспертов по программному обеспечению, констатировала, что проект управляющей (системной) программы выполнен «архаичными методами и неправильно». Несмотря на это, после завершения работ программа прекрасно работала. (Но скольким толкам дал пищу этот отзыв!)

19

Randall W. Jensen and Charles С. Tonies, Software Engineering (Englewood Cliffs, N. J.: Prentice Hall, Inc, 1979).

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

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

Проектирование это…

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

Итеративность

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

Компромиссы

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

Проектирование больших программ типа V — это многогранная деятельность

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