Читать онлайн «Программное обеспечение и его разработка». Страница 24

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

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

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

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

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

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

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

1) техническая сложность конкретного приложения.

2) логическая сложность приложения и/или системы программного обеспечения.

Техническая сложность. У меня в распоряжении две программы, по 50 тысяч команд каждая. Одна «делает» платежную ведомость, а другая «делает» вычисления, связанные с безопасностью летящей ракеты. Ракетная программа будет более сложной; в ней требуется решить некоторые сложные уравнения.

Предсказание погоды, уравнения ядерной физики, орбитальные расчеты, гравитационные эффекты, баллистика — все это требует специального математического аппарата, инженерного искусства, а также высокой научной квалификации и знаний. Эти знания нужно использовать во всех фазах разработки программного обеспечения. Получение таких знаний само по себе достаточно трудный процесс, использование же их трудно вдвойне.

Логическая сложность. Существует и другой вид сложности — логическая сложность, причем управляться с логической сложностью даже труднее, чем с математической или технической. Эта сложность проявляется в многообразии различных вариантов, выбор среди которых надо производить на каждом шаге решения. Каким образом можно проследить все возможные или подходящие нам пути, по которым проходит управление при выполнении больших программ? В программах может быть лишь несколько условных переходов, в других же программах их может оказаться огромное множество! Попробуем разобраться, почему же бывает трудно справиться с программой с большим количеством условных переходов.

Сколькими различными способами можно соединить с контактами пять проводков из семижильного жгута? Таких способов 2520.

Сколько различных порядков при ударе можно выстроить для 12 — всего лишь 12 — ребят, игроков бейсбольной команды младшей лиги? Подсчитали? 79 миллионов 833 тысячи 600! Только для 12 ребят!

Одной из самых логически сложных программ является программа диспетчеризации воздушного транспорта, применяемая в США и Великобритании. Она стоила более 100 млн. долларов и используется в 20 диспетчерских центрах США, а также в Лондоне. К настоящему времени мы имеем уже пятилетний опыт ее эксплуатации, система работает вполне удовлетворительно. Великобритания, приобретая систему, выплатила за нее и вычислительную машину IBM 9020, на которой система работает, 10 млн. долларов наперекор жесточайшей политике «Покупать только британское» (Тот факт, что иностранная держава выбрала и использует американскую систему, привел к тому, что Федеральное агентство Соединенных Штатов по авиации отказалось от своих многочисленных нападок на систему и обвинений в ее бесполезности, несовременности и т. д.).

Во время переговоров при заключении контракта на изготовление диспетчерской системы мы специально изучали 600 тысяч строк программы, подготовленной для работы на центральном вычислительном комплексе, и обнаружили в ней большое число условных переходов. Мы насчитали 39 203 таких перехода, т. е. в среднем по одному на каждые 15.3 строк текста В этой программе очень много внимания уделяется принятию различных решений, что связано с запутанной логической структурой управления, предсказания возможных конфликтных ситуаций, а также множества различных вариантов, возникающих при работе с 97 устройствами для ввода данных и запросов к системе, форматной выдаче данных на дисплеи. Сколько же вариантов возникает при выполнении этой программы? Это число равно 39 203! Это просто астрономическое число, оно примерно равно 10^11 801, или десятке, за которой следует 11 800 нулей! Если бы мы могли проверять один вариант программы за одну секунду, то на тестирование всей программы в целом нам пришлось бы затратить несколько тысяч лет. Мы не можем создать специальную тестирующую систему, которая могла бы проверить нам все варианты, возникающие в окружающем нас мире.

Если кто-то начинает говорить о том, что он создал программу, в которой нет ни одной ошибки, значит, либо он говорит об очень маленькой программе, либо вообще не знает, о чем говорит.

Большие системы программного обеспечения логически очень сложны. Они содержат огромное число ветвлений. В своей книге «Мифический человеко-месяц» Брукс [8] утверждает, что системное программное обеспечение в девять раз труднее разрабатывать, чем прикладное обеспечение. Основной причиной этого является логическая сложность.

Если отдельно рассмотреть прикладные программы, они окажутся не такими уж сложными. Однако при первой же попытке объединить некоторое количество прикладных программ в цельную однородную систему мы сразу же столкнемся со сложными проблемами. Рис. 4.20 взят из книги Джеймса Мартина «Организация баз данных».