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

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

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

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

Мы не знаем, каким должен быть предел емкости памяти — 2000, или 1000, или 4000. Эти пределы должны определяться руководством конкретных предприятий. Конечно, иногда можно требовать права на исключение. Имеются в виду случаи, когда создатели аппаратуры абсолютно уверены в ясности и стабильности сферы приложения их усилий, а также в своей способности писать безошибочные программы.

Если мы решим, что наша программа не имеет ни одной ошибки и выпустим нашу продукцию в свет, а потом вдруг обнаружим в небольшой программе, всего в 1000 команд, одну-единственную ошибку, мы будем принуждены возвращать себе и вскрывать тысячи микроволновых печей или посылать тысячи техников для замены микросхем в копировальных установках или телевизорах. Стабильность программы крайне важна для всего экономического успеха продукции. Любая ошибка как в определении требований, так и в реализации может оказаться фатальной для всего дела, несмотря на то что речь идет всего лишь о «маленькой» программе!

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

Использование таксономии — некоторые примеры

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

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

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

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

Проект с товарными программами