Джозеф Фокс - Программное обеспечение и его разработка

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

При попытке автоматизировать нефтеочистительные заводы фирмы Exxon, расположенные в Эдмонтоне, Канада, и в Антверпене, Бельгия, фирма IBM потеряла более 10 млн. долларов. Выполняли работу две сотни моих хьюстонских сотрудников. Как-то один из разработчиков спросил инженера компании Exxon, каким образом он узнает, когда надо нажать на рычаг. «Очень просто, — ответил тот. — Я опускаю палец в струю и пробую на вкус». Попытайтесь теперь запрограммировать это!

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

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

Программное обеспечение наследует проблемы системы.

При разработке большой системы типа V по мере стабилизации других частей комплекса последнее, что может быть еще модифицировано, — это именно программное обеспечение. Что мы подразумеваем под «стабилизацией»? В больших системах типа V разрабатывается сразу множество различных элементов. Коммуникационные связи/ дисплей/ радиолокатор/ сонар/ телеметрия/ ракета/ спутник/ двигатели/ управление/ еще что-нибудь — что-то из этого списка будет самым новым, самым передовым в мире, может разрабатываться также какой-нибудь необычный способ объединения этих объектов. Эта новинка может преподнести вначале своей эксплуатации любой сюрприз, и нам придется приспосабливаться к реальному положению.

Основная тяжесть адаптации падает на две части нашей системы — на программное обеспечение и обслуживающий персонал. Максимум возможного мы стремимся сделать за счет программ, оставляя нагрузку на людей минимальной. Программное обеспечение действительно будет «гибким» [10] Игра слов, заключающаяся в том, что программное обеспечение по-английски — software — «гибкая или мягкая часть, или аппаратура».— Прим. ред. , если мы правильно его разработаем и будем правильно управлять им. Если мы документируем его и разделим на отдельные модули. В этом случае мы и вправду сможем приспособиться к любым неожиданностям. Если же мы ничего этого не сделаем, то в итоге получим всего лишь грубый бетонный блок, а не гибкую систему!

Долгосрочное планирование и правильное использование фондов в дальнейшем могут сэкономить немалые суммы денег. Мост Джорджа Вашингтона из Нью-Йорка в Нью-Джерси был построен в 1931 г. с одним путепроводом, но все расчеты напряжений были сделаны так, что через 30 лет оказалось возможным добавить еще один уровень с шестирядной дорогой. И действительно, в 1962 г. этот уровень был достроен (см. рис. 4.21).

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

В противоположность предыдущему примеру со строительством второго уровня рассмотрим пример строительства моста-близнеца рядом со старым мостом! Посмотрите, какой мост построен через залив Чезапик. (См. рис. 4.22.)

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

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

При разработке больших систем типа V единственной по-настоящему важной проблемой является отсутствие ясных требований. Руководитель проекта не может понять, что ему делать.

Таблица 4.11 Какие требования могут меняться

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