Люди, определяющие политику, конечно, видят эту опасность и потому стараются разделить все программное обеспечение на два больших класса — аппаратно-интенсивные программы, которые не должны подвергаться никаким изменениям и, следовательно, не имеют права на ошибку, и программно-интенсивное программное обеспечение, исправление и модификацию которого мы всегда должны предусматривать.
Для обеспечения второго класса необходимо вводить различные стандарты — стандарты на языки программирования, стандарты на процесс разработки, стандарты на тестирование, на документацию и другие. Подробнее о стандартизации речь пойдет позднее. В аппаратно-интенсивных приложениях все эти стандарты не имеют экономического обоснования. Проведение разработки и использование в рамках жестких стандартных ограничений только увеличат стоимость разработки, причем довольно значительно — в 5–10 раз.
Поэтому нам вполне понятно желание разделить эти два класса. Если хорошо осведомленный руководитель видит и представляет себе все предстоящие затраты на разработку, управление разработкой пройдет четко. Но каким образом руководители предприятий составляют руководящие технические материалы для сотен или даже тысяч разработчиков, чтобы добиться обеспечения минимального риска в процессе самой разработки? Вычислительные машины, являющиеся составной частью многих предметов потребления, имеют программы с ошибками, но для их исправления и модификации не создаются никакие планы, не отводятся никакие средства.
Легче всего провести грань между этими столь различными классами программного обеспечения, произвольно установив, что все разработки программ должны вестись с применением методов программно-интенсивных разработок в тех случаях, когда вычислительная машина, на которой будет использоваться данное обеспечение, имеет память размером от 2000 команд и более!
Конечно, это произвольное решение. Существуют примеры достаточно простых программ в 3000 команд, поскольку в них мало условных переходов. Но дело тут в том, что мы пытаемся уберечь ничего не подозревающих создателей аппаратуры от попадания в ловушку взаимосвязи. Замечательные новые кристаллы с интегральными схемами действуют на инженеров как призывные песни сирен. Мощность микропроцессоров так сильно возросла, они стали такими дешевыми. Но столь же возросла и цена ошибки.
Мы не знаем, каким должен быть предел емкости памяти — 2000, или 1000, или 4000. Эти пределы должны определяться руководством конкретных предприятий. Конечно, иногда можно требовать права на исключение. Имеются в виду случаи, когда создатели аппаратуры абсолютно уверены в ясности и стабильности сферы приложения их усилий, а также в своей способности писать безошибочные программы.
Если мы решим, что наша программа не имеет ни одной ошибки и выпустим нашу продукцию в свет, а потом вдруг обнаружим в небольшой программе, всего в 1000 команд, одну-единственную ошибку, мы будем принуждены возвращать себе и вскрывать тысячи микроволновых печей или посылать тысячи техников для замены микросхем в копировальных установках или телевизорах. Стабильность программы крайне важна для всего экономического успеха продукции. Любая ошибка как в определении требований, так и в реализации может оказаться фатальной для всего дела, несмотря на то что речь идет всего лишь о «маленькой» программе!
Человек, ответственный за программное обеспечение, прежде всего, конечно же, захочет выяснить, является ли данное приложение аппаратно-интенсивным. К разработке аппаратно-интенсивного программного обеспечения должны применяться иные, менее строгие стандарты.
Использование таксономии — некоторые примеры
Однажды меня попросили перечислить десять ведущих специалистов Соединенных Штатов по программному обеспечению. Я разделил свой список на три части. В первый список попали люди, действительно знающие, как надо строить, и построившие большие системы программ.
Во второй список я поместил имена тех, кто обладает обширными знаниями в области языков программирования и библиотек программ, т. е. в области инструментального обеспечения. Сюда попали многие деятели из различных университетов страны.
Третий список, однако, относился не к специалистам в области прикладных программ, а к тем, кто занимается построением обеспечения проектов. Прикладная область не представляет собой ничего сложного. Те же, кто разрабатывает программное обеспечение проектов, используют продукцию первых двух групп, соединяют их с прикладной областью и создают окончательную работающую систему. Они в прямом смысле интегрируют программное обеспечение, создавая самые большие, самые быстрые, самые сложные системы. Они построили систему управления воздушным транспортом, спутниками Земли, системы резервирования авиабилетов, военные командные и управляющие системы. Они создавали системные программы, объединяли их с прикладными, основывая свой труд на множестве инструментальных программ. Они руководили разработкой 100 млн. систем.
Наиболее важный вывод, следующий из этой классификации, состоит в том, что для каждой из этих областей необходимы различные таланты и мастерство! Никогда не придет мне в голову назначить специалиста по языкам программирования ответственным за разработку большой системы реального времени; он не компетентен в этой области. И наоборот, нельзя сделать ответственными за создание системы противовоздушной обороны даже высококлассных системных программистов! При выполнении же работ, относящихся к первым двум классам, нельзя использовать специалистов по сложным системам реального времени. Все это совершенно разные работы.
Проект с товарными программами
Система общенациональной связи, предусматривающая также обслуживание, является огромным программным обеспечением проекта, но кроме того, требует создания также еще и многих товарных программ. Система передачи сообщений может соединять конторы клиентов и передавать данные с некоторого устройства (например, копировальной установки) одной конторы на другое устройство, находящееся в другом месте.
Для обеспечения работоспособности такой системы необходимо создать и заставить работать сеть средств передачи информации (микроволновые передатчики, спутники и т. д.), и средства хранения информации, и коммутационные устройства. Обслуживать систему должна небольшая группа людей, которые будут управлять средствами поддержки отдельных узлов сети и регулировать работу системы при возникновении переполнений.
Большая часть сети должна управляться с помощью вычислительных машин. Программы, которые нужно для этого написать и связать между собой, относятся к классу программного обеспечения проектов. Однако очевидно, что средства, предлагаемые пользователям, будут включать также средства радиосвязи. Оператор копировальной установки, включенной в состав сети, может посылать копии своих документов в десятки различных мест. Если имеемся некий постоянный набор клиентов, часто получающих одни и те же копии, оператор может не перечислять их, а адресоваться к группе. Сеть — с помощью соответствующих программ — будет переводить введенный оператором идентификатор группы в фактические адреса. Эта программа — просто автономная программа, продукция, а не часть обеспечения проекта.
Такая продукция:
— должна быть рассчитана на огромное число пользователей; тысячи этих пользователей могут работать в различных областях и отраслях;
— должна быть легкой в использовании, хорошо защищенной от случайных воздействий, хорошо приспособленной к возможным добавкам или исключениям;
— должна быть очень хорошо документирована;
— должна выполнять большое число функций, что поможет ей удовлетворить большое число пользователей;
— должна сопровождаться людьми, которые готовы исправить ее и внести в нее дополнения;
— богатый набор ее функций должен быть перед реализацией тщательно выверен и определен;
