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

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

Важные для себя вещи или абстрактные понятия люди всегда обозначали особыми словами.

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

Определение программы

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

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

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

Рабочая программа это программа на машинном языке. Исходная программа может быть написана на языке ассемблера или на языке более высокого уровня (ЯВУ). С помощью программы-транслятора она переводится на машинный язык.

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

Программное обеспечение и программы

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

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

Что делает окрестность окрестностью? Как отличить одну окрестность от другой? Когда небольшой город становится большим городом?

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

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

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

Программное обеспечение — это группа взаимодействующих друг с другом программ.

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

Что же не входит в программное обеспечение?

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

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

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

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

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

Можно писать программу, но не программное обеспечение. И даже с программами трудности значительно возрастают с ростом их размеров.

Фраза «пишет программное обеспечение» не полностью отражает истинные усилия, затрачиваемые на разработку программного обеспечения.

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

Разработка программного обеспечения может быть разбита на шесть этапов:

Определение требований и заданий

Проектирование

Написание команд — программирование

Компоновка

Тестирование

Документирование

Относительно новым термином «программно-аппаратное обеспечение» часто обозначается программное обеспечение или просто программа, которая всегда находится в постоянной памяти, работающей только на чтение (ПЗУ), и выполняется непосредственно оттуда. Хотя тот факт, что запись в память исключается, и создает некоторые трудности проектирования и создания программного обеспечения, однако программно-аппаратное обеспечение не столь уж сильно отличается от программного обеспечения, работающего с обычной памятью, чтобы его нужно было выделять и рассматривать отдельно. Здесь применяются те же правила и практические приемы. Таким образом, мы будем рассматривать программно-аппаратное обеспечение как часть программного обеспечения. Мы еще столкнемся с программами, располагающимися в постоянных запоминающих устройствах.

Обзор программного обеспечения

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

Очень часто разработчики программного обеспечения не успевают выдать надежный продукт точно в назначенный срок или просто выходят из бюджета. Какая-либо помощь этим разработчикам практически не увеличивается, и разумного решения тут вообще не видно. Неудачи на поприще программного обеспечения постигают не только начинающих программистов. Случается, что даже самые крупные, самые солидные, самые технологически передовые организации страдают из-за серьезных препятствий, возникающих перед ними. За несколько недель до намеченной сдачи в эксплуатацию новой системы 138 фирма IBM объявила о годовой отсрочке, вызванной трудностями с программным обеспечением. За год до назначенного ввода в действие усовершенствованной системы связи фирма АТТ объявила о 18-месячной задержке.

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

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

Если мы оглянемся на проделанное нами, то увидим, каких гигантских успехов мы добились. Системы резервирования авиационных билетов работают — и работают прекрасно. Американская система авиалиний к весне 1979 г. обслуживала 13 500 присоединенных терминалов, через которые поступало до 10,6 млн. сообщений в день. Система управления транспортными авиалиниями работает и в США, и за их пределами. Работает спутниковая система. И эти успехи не случайны. На них было затрачено огромное количество ресурсов и усилий, но они работают.

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

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

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

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

Факты о программном обеспечении

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

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

Разработка программного обеспечения проходит следящие шесть этапов: определение требований, проектирование, написание команд, компоновка, тестирование и документирование.

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

Любой процесс может быть выражен несколькими различными «правильными» последовательностями команд.

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

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

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

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

Правильное программное обеспечение не подвержено никаким сбоям. Термин «поддержка» по отношению к программному обеспечению является, следовательно, неправильным.

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

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

Разработка программного обеспечения часто весьма трудоемкий и дорогостоящий процесс.

Программное обеспечение это не цель, а средство.

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

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

Одновременное уменьшение стоимости и увеличение мощности машин расширили область применения ЭВМ сразу на верхнем и нижнем уровнях.

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

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

Программное обеспечение состоит из множества программ различных типов. Программы делают все, что только можно; они бывают маленькими и тривиальными, но бывают также большими и сложными, весьма дорогостоящими. Говорить о программном обеспечении можно только употребляя при этом по крайней мере одно уточняющее слово. О чем мы говорим — о «программном обеспечении проекта» или о «программном обеспечении как продукции»? О «реальном времени» или о «пакете»? А может быть о «диалоге»? Что мы имеем в виду: «помехозащищенность», «помехобезопасность» или просто надежность? О каком программном обеспечении идет речь — о «инструментальном», «системном» или «прикладном»? О «крупномасштабном» или «мелкомасштабном» программном обеспечении? Каждая из этих категорий обладает собственными, характерными только для нее чертами.

Жизнь программы делится на три фазы. Слишком часто разработчики программ фокусируют свое внимание только на фазе разработки, иногда еще и на фазе использования и очень редко на фазе сопровождения или продолжающейся разработки к большему ущербу для последней. Кое-что можно и нужно делать во время разработки для облегчения других фаз. Большинство разработчиков этот аспект игнорируют. Во многих книгах, посвященных разработке и использованию программ, игнорируется тот факт, что эти три фазы существуют отдельно друг от друга, имеют различные цели и часто к тому же проводятся под разным руководством (см. рис. 1.1).

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

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

Особенно важно правильно спланировать загрузку центрального процессора (ЦП) и определить все требования к памяти. Все это заставляет разработчиков при проектировании программ учитывать параметры и характеристики аппаратуры системы. В случае разработки маленьких программ дело обстоит совсем иначе.

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

Любой процесс может быть описан несколькими различными «правильными» последовательностями команд. Сотня программистов смогла бы написать сто различных программ платежной ведомости, каждая из которых будет выполнять то, что от нее требуется. Небольшое количество среди них будет оптимальным. Важные характеристики каждой программы порой конфликтуют друг с другом, подобно тому как при конструировании самолетов размеры вступают в конфликт со скоростью. Прочитав гл.5, вы узнаете, что каждая программа имеет по крайней мере 12 характеристик и некоторые из них, находя воплощение в одной программе, могут вступать с другими в противоречие. Множественность возможных решений является серьезным препятствием для правильного управления процессом разработки программного обеспечения.

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

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

Основным инструментом создания нового программного обеспечения является вычислительная машина и ее программное обеспечение. Разработчики программного обеспечения в своей работе используют ЭВМ и программное обеспечение как основной инструмент для формирования и создания новых программ. Программное обеспечение является при таком использовании «инструментом для изготовления инструментов».

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

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

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

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

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

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

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

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

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

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

Даже сотни лет продолжающегося тестирования — если бы, конечно, это стало возможно — не хватило бы для проверки всех возможных ветвей большой, сложной программы. И несмотря на это, находятся люди, всерьез говорящие о «программном обеспечении, свободном от ошибок»!

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

В начале 1970-х гг. две основные авиакомпании возбудили судебное дело против своих подрядчиков, поскольку созданная ими система стоимостью 40 млн. долларов не только не работала, но и вообще не подавала никаких признаков жизни. Крупный европейский банк направил в суд иск о взыскании 70 млн. долларов, выплаченных за программное обеспечение. Военно-воздушные силы США затратили более 300 млн. долларов на тщетную попытку автоматизировать комплексную систему перевозок и снабжения.

Программное обеспечение — это средство, а не цель. Одна из замечательных технических групп работает в National Security Agency (NSA). Она специализируется в области защиты и разгадывания шифров и привлекает в свои ряды и воспитывает знатоков различных технологических методов.

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

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

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

Хотя глава NSA чувствовал, что им известно, как нужно производить приобретение систем, первым документом, изданным комитетом, был документ под названием «Политика приобретения систем». Лишь затем удалось заняться программным обеспечением!

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

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

Что мы имеем в виду под «третьим порядком»? На первом месте, безусловно, находится желаемый результат. Например, увеличение продажи билетов, происшедшее из-за введения в действие системы предварительного заказа. Результат — это то, к чему мы стремимся, он является целью первостепенной. На втором плане находится система, достигающая данного результата, а программное обеспечение, как часть этой системы, занимает лишь третье место. Важное, это верно. Может быть, самое важное, но все же лишь третье.

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

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

Две роли программного обеспечения

Очевидная роль программного обеспечения — заставить работать аппаратуру! Но давайте заглянем поглубже. Этим роль программного обеспечения не ограничивается. Оно еще должно быть легко модифицируемым.

Никто без серьезных оснований не станет ломать антенну радиолокатора или новый спутник (ценой около 50 млн. долларов). Однако руководители различных систем с легкостью идут на изменения в программном обеспечении! Они должны даже заранее планировать эти изменения. Такая роль была уготована программному обеспечению с самого его возникновения. Изучение истории этого вопроса возвращает нас к понятию запоминаемой программы.

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

Почему проблема программного обеспечения еще не полностью решена?

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

1. Сложность. Внутренняя сложность автоматизируемого процесса, т. е. научная сложность (лунное притяжение и т. д.), или логическая сложность (число ветвей в программе может достичь значения 103000), или и та и другая вместе.

2. Абстрактность. Управление и создание его происходит «вслепую», и, для того чтобы «увидеть», что происходит, требуются весьма сложные приспособления.

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

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

5. Управление взаимодействием с пользователем с помощью программного обеспечения. Создаваемое для такого взаимодействия программное обеспечение должно выполнять следующее:

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

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

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

Разрабатывать программное обеспечение очень и очень трудно. Оно имеет весьма запутанную логическую структуру.