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

Масштаб

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

В полном одиночестве за двадцать минут я могу написать программу из 100 команд, которая будет вычислять мои ежемесячные выплаты процентов по ссуде. Это будет разработка программы. За 20 минут.

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

В обоих случаях я буду выступать в роли разработчика программ. Но усилия мои будут весьма различными. А быть руководителем группы, ответственным за все эти миллионы команд, это абсолютно другой вид деятельности.

Есть «программирование в малом» и «программирование в большом». 100 команд — это просто программа, миллион команд — это уже программное обеспечение.

Давайте поищем (вокруг себя) аналогии, которые помогут нам понять наши технологические проблемы. Строителем моста может быть человек, который строит полутораметровое сооружение из тонких досок над узким ручейком на заднем дворе, или человек, создающий подвесной мост через реку или залив. Нельзя сравнивать такие мосты, они находятся на разных концах масштабной шкалы. Но и тот и другой — мост!

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

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

Создается «рабочий план». Тщательно детализируются и документируются все сведения о том, что, когда и кем должно выполняться, какая между всем этим есть взаимосвязь. Определяется параллельность работ (какие работы могут выполняться параллельно друг другу).

Все это надо распланировать и понять заранее. Только после этого можно приступать к найму строителей, выписывать ордера на материалы, инструменты и доставлять оборудование.

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

Проходят годы. Мост становится реальностью, чудом, воплощенным в жизнь. Его могут видеть миллионы людей, видеть уже построенным, пользоваться им. Это триумф (см. рис. 4.17).

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

Урок, который можно извлечь из табл. 4.9, очевиден — для строительства моста стоимостью в 300 млн. долларов нужен тщательно разработавшей «фундамент». Все это с полной уверенностью можно отнести и к программному обеспечению стоимостью в 100 млн. долларов, состоящему из программ размером от 500 тыс. до 2 млн. строк текста.

Эффект больших масштабов проявляется во всех отраслях. Дональд Дуглас, один из пионеров авиации, говорил, что «когда вес документов достигнет веса самолета, самолет начнет летать» (См. рис. 4.18.)

Джеймс Мартин утверждает, что «документы для „Боинга-747“ весили больше, чем сам самолет». То же самое можно сказать и о большом программном обеспечении. Здесь может возникнуть вопрос, много ли в настоящее время имеется систем из программ в миллион строк, много ли их будет появляться в будущем. Некоторые я перечислил в табл. 4.10, но дело в том, что их с каждым днем становится все больше.

Таблица 4.9. Эффект влияния роста размеров на рост усилий

Таблица 4.10. Большие программные проекты

Появление больших систем программного обеспечения обусловлено снижением стоимости аппаратуры вместе с одновременным увеличением его мощности. Список систем не ограничивается приведенными в таблице, этот список все пополняется. Я знаю множество программ для министерства обороны, в которых затраты на программистскую часть превысили 50 млн. долларов. Этого уровня достигает и промышленность. В этот диапазон попадают большие системы связи фирм ATT, RCA, W.U., Satellite Business Systems. Операционные системы, сделанные для крупнейших промышленников, имеют даже большие размеры и стоят дороже.

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

Одной из программ, стоившей гораздо больше 100 млн. долларов, была система наземного контроля космических кораблей типа Аполлон, созданная хьюстонским Центром пилотируемых полетов. Я был в Хьюстоне в 1970 г. сразу же после вступления на пост главного управляющего федеральным системным центром с целью проинспектировать работу 700 человек, подчинявшихся лично мне.

Они показали мне, как они управляют ходом разработки программы в миллион строк. Я был просто потрясен! «Это сущая бюрократия», — думал я, когда мне показывали планы, руководства, формы, тесты и еще множество всевозможных документов.

Вскоре после этого я посетил еще некоторые подчиненные системы. Там не было такой большой системы управления разработками — и разработки были неуправляемыми. Самым правильным был подход, применявшийся в Хьюстоне, — для управления разработкой действительно большой системы более 50 % средств нужно направлять на планирование, проверку, составление графиков, руководство и управление. Это и есть та инфраструктура, которую мы видим в других отраслях. Позже мне показали график, изображенный на рис. 4.19. Он и сейчас соответствует действительности.

Наверное, самый понятный пример эффекта, проистекающего от возрастающего масштаба работ, был мною обнаружен при изучении одного интересного и удивительного факта, когда в 1968 г. я прибыл в отделение федеральных систем для того, чтобы стать помощником его президента Боба Эванса. Около десяти человек из Хьюстонской космической группы были направлены в Лондон, в один из банков. Для чего это было нужно? Специалисты по космосу помогали Лондонскому банку налаживать обработку данных?

Или, может быть, некоторые из членов Хьюстонской группы были специалистами по банковскому делу? Вовсе нет. Причиной их командировки в Лондон был тот факт, что самыми крупными заморскими партнерами фирмы IBM являются банки. А европейские, японские и другие иностранные банки в противоположность банкам США не столь сильно скованы рамками всевозможных законов и границами государств. Для связи с тысячами своих отделений они пользуются системами, стоящими более 100 млн. долларов.

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

Оглавление книги