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

Автор книги: Джозеф Фокс

сообщить о нарушении

Текущая страница: 6 (всего у книги 21 страниц)

Таблица 4.7. Какое программное обеспечение может самостоятельно работать в различных местах

Инструментальные	Диагностические программы	Диагностические программы Элементы калькуляции	Диагностические программы
Системные	ОС	Операционные системы	ОС
Прикладные	В целях тестирования программы калькуляции	Нет	В целях тестирования программы калькуляции

Инструментальное программное обеспечение

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

Наиболее известными представителями этой части программного обеспечения являются программы трансляторов с языков программирования, которые помогают программистам писать машинные команды. Инструментальными программами являются трансляторы с языков Фортран, Кобол, Джовиал, Бейсик, АПЛ и Паскаль. Они облегчают процесс создания новых рабочих программ.

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

Таблица 4.8. Некоторые инструментальные программы

Текстовые редакторы	PSL/PSA
Форматирование документации	Реляционные СУБД
Архивные системы	Проверка непротиворечивости
Работа с дисками и лентами	CARA/CLARA
Модели	SADT IA
Графические пакеты	Транслятор
Построители структурных блок-схем	Кросс-транслятор
	Предтранслятор
Проектный анализатор APLGOL	Программа-библиотекарь
Система планирования и руководства разработками PERT	Статические анализаторы
	Символическое выполнение
Редактор связей	Интерпретация
Библиотекарь	Генератор тестовых последовательностей
Библиотекарь	Сбор статистики

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

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

Так же как и все другие программы, инструментальное программное обеспечение может содержать ошибки. Этот не очень очевидный факт вынуждает нас для придания людям уверенности в высоком качестве наших инструментальных средств, для содержания их в рабочем порядке, каталогизации, обеспечения помощи производственным программистам в обучении, для их использования, а также для исправления в случае, если они не дают верных результатов, организовывать специальные группы инструментального сопровождения. Такие группы сопровождения, состоящие из системных программистов, представляют большую ценность. (Кому хочется работать с неисправными инструментами?) Затраты на их создание оправдываются увеличением производительности труда другой части программистов, участвующих в разработке. О необходимости таких групп часто забывают, и статьи в бюджете на них не отводят.

Кроме «обычных» средств разработки мы можем упомянуть некоторые дополнительные вспомогательные области:

Разработка тестового программного обеспечения

имитаторы; моделирующие программы; генераторы.

Обслуживающее тестовое программное обеспечение

диагностика; тесты; помощь при техническом обслуживании.

Обучение с помощью программного обеспечения

помощь в изучении; программированные инструкции; программы-тренажеры.

Стоимость инструментального программного обеспечения

Инструментальное обеспечение может стоить сотни миллионов долларов. Военно-морской флот США принял решение использовать на борту всех кораблей только две различные вычислительные машины, работающие в разных диапазонах производительности. Ремонт и поставка запасных частей в море настолько сильно влияют на систему в целом, что размещение на всех кораблях одинаковых машин значительно облегчает расчеты перевозок и снабжения.

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

В середине 1979 г. в ВМФ США подсчитали, что на создание инструментального программного обеспечения для этих машин было затрачено около 300 млн. долларов. Такая сумма не является чем-то необычным. Чтобы сопровождение машин происходило хорошо, должно быть создано огромное число различных программных инструментальных средств.

ВМФ США предпринял смелое и успешное начинание, отвергнув создание целой системы нового инструментального обеспечения, когда при заказе новой самолетной бортовой машины потребовал, чтобы ее система команд совпадала с системой команд одной из судовых ЭВМ. Многие считали, что такие действия будут тормозить развитие вычислительной техники, но работы завершились успешно, налогоплательщикам сэкономлены многие миллионы долларов.

Масштаб, сложность, ясность

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

Масштаб

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	1 день	1825 дней
	1 листок бумаги	Большой склад документов
	1 ч.	1460 дней
	1 ч.	182 дня
	½ дня	182 дня
	1/2 дня	182 дня
	1 день	182 дня
	1 день	182 дня
	2 дня	36 500 дней
	2	5000
	1 день	365 дней
	3 дня	3650 дней
	1 день	3650 дней
	1 день	3650 дней
	3 дня	1825 дней
	1 день	555 дней
	5 листов	500 000 листов
	1000 долларов	300 000 000 долларов

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

			[7]7   Заметим, что получить какие-либо согласующиеся данные путем простого деления данных из одной колонки на данные из другой невозможно. К вопросу о производительности труда мы обратимся в гл.6. [Закрыть]
	209	23.00	6000 +
	30	1.25	1000 +
	103	1.48	5000 +
	120	1.87	3500 +
	23	0.55	1300 +

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

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

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

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

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

Рис. 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]8
  Frederick P. Broocks, Jr. Mythical Man-Month (Reading, Mass; Addison – Wesley, 1975). Есть русский перевод, см. примечание на стр.5.


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

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

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

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

Очень долго у людей были сложности с мостами. За одно только десятилетие с 1870 по 1880 г. только в одних Соединенных Штатах разрушалось в среднем до 40 мостов в год. Граждане переходили через мост с риском для жизни. «Социология» того периода очень напоминает положение, сложившееся в настоящее время:

Катастрофы на крупных мостах случались гораздо чаще, чем на железной дороге. Многие мосты местного значения строились окружными властями, которые соединяли в себе техническое невежество и неумение решать экономические проблемы. Подрядчики и торговцы заключали самые дешевые контракты, что фактически вело к исключению других, возможно более хороших вариантов. Безответственные исполнители продавали все, что только было можно; при первой же возможности быстро наводили мост и тут же поспешно исчезали. Самые авторитетные фирмы были поставлены конкуренцией в весьма опасное положение[9]9
  Gies j. Bridges and Men. New York: Grosset & Dunlap, Inc, 1963.


[Закрыть].

Рис. 4.20. Взаимосвязанные функции (Мартин Дж. «Организация баз данных в вычислительных системах». Пер. с англ. – М… Мир, 1980) Печатается с любезного разрешения издательства Прентис Холл.

Как сильно все сказанное о том времени напоминает ситуацию, возникшую в программировании сегодня! А ведь семидесятые годы прошлого столетия не были первыми годами бедствий. Веками мосты разрушались из-за воздействия гармонических колебаний. Чего стоили только проходы через мосты солдат, марширующих в ногу. В 40-х гг. XX в. возникла проблема ветра. В 1940 г. упал мост через Такомский залив. В 1970-х гг. мост Бронкс Уайтстоун, «укрепленный» после Такомской катастрофы, начал раскачиваться так сильно, что люди бросали свои автомобили и в панике прыгали с пролетов моста.

Проблемы возникали не только с подвесными мостами. В 1944 г. двухфермовый мост через Миссисипи в Честере, шт. Иллинойс, был сброшен ветром со своих ненадежных опор. В 1905 г., когда был разрушен мост на кронштейнах через реку Св. Лаврентия в канадской провинции Квебек, было убито 87 рабочих. Физическая природа таких строений была тогда недостаточно понятна людям.

Новые явления приносят нам новые сложности. Моторы компании «Локхид Электра» (Lockheed Electra) разрушаются из-за дефектов проектирования. Самолеты DC-10 не летают!

Во второй половине семидесятых годов в здании Джона Хэнкока в Бостоне уже не было стеклянных окон. Были заменены 10 тыс. 400-фунтовых стекол.

Люди до сих пор не справились со сложностями, возникшими вместе с открытием ядерной энергии. Убытки от катастрофы, происшедшей на Острове третьей мили, продолжают расти и уже достигли 4 млрд. долларов!

Ясность

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

Работа вычислительной машины по типу I (коммерческие расчеты) совершенно ясна. Задачи по обработке данных в большинстве случаев уже полностью решены. Все, что нам надо сделать, это разобраться в используемых процедурах и запрограммировать их. На противоположной стороне шкалы находятся задачи по управлению процессами типа V.

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

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

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

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

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

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

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

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


[Закрыть], если мы правильно его разработаем и будем правильно управлять им. Если мы документируем его и разделим на отдельные модули. В этом случае мы и вправду сможем приспособиться к любым неожиданностям. Если же мы ничего этого не сделаем, то в итоге получим всего лишь грубый бетонный блок, а не гибкую систему!

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

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

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

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

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

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

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

Продукция	Структура рынка
Размах производства	Разделение труда
Заводы, их расположение	Заказчики
Организация	Налоговое законодательство
Ведущие специалисты	Законы охраны собственности
Число заводов	Обмен продукцией между заводами
Сети	Аппаратура
Процедуры	Следовательно, прикладные программы
Необходимые данные	Следовательно, база данных

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

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

Резюме

Масштаб, сложность и ясность нужно принимать во внимание и планировать с самого начала работ. Построение системы в миллион команд – это такой же триумф, как и постройка моста, часто стоимости этих объектов тоже сравнимы. Однако программное обеспечение невидимо. Никто не видит его; только некоторые посвященные могут его оценить. В некотором смысле такое положение не очень-то радует. Когда создается что-нибудь достаточно сложное, хотелось бы, чтобы плоды труда были видны. Даже сама работа программы это как бы «верхняя часть айсберга». Нет никакого способа показать огромную сложность и достигнутые результаты. Только в процессе изучения и создания можно оценить сложность и масштаб подобных работ.

Программное обеспечение проекта и программное обеспечение как продукция

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

1. Пакеты программного обеспечения	Программное обеспечение, которое может использоваться на любой вычислительной машине, например транслятор с Кобола
2. Системы с программным обеспечением различных компонент	Получающиеся в результате системы, например системы обработки слов отличаются друг от друга именно своим программным обеспечением
3. Аппаратные комплексы с минимальными программными включениями	Продукция с минимумом программного обеспечения, например копировальная установка, использующая ЭВМ для управления операциями

Продукция и проекты

В разработке обеспечения как продукции есть два пункта (см. также табл. 4.12), отличающих ее от разработки программного обеспечения проектов: