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

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

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

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

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

Тип I. Использование для обработки данных.

Тип II. Использование для проведения научных расчетов.

Тип III. Использование для информационных систем.

Тип IV. Использование в диалоговых системах решения задач.

Тип V. Использование для управления процессами.

Таксономия программного обеспечения

За время своей жизни программное обеспечение проходит три фазы:

1. Фазу разработки.

2. Фазу использования.

3. Фазу продолжающейся разработки (часто называемой сопровождением).

Существуют три типа программного обеспечения:

1. Прикладное обеспечение.

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

3. Системное обеспечение.

Три отличительные черты применения программного обеспечения:

1. Масштабность программного обеспечения.

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

3. Ясность программного обеспечения.

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

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

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

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

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

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

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

Теперь мы остановимся на каждом пункте нашей классификационной таблицы и постараемся кратко объяснить, что мы имели в виду под классификацией и чего не имели.

Жизненный цикл программы

Жизнь программ состоит из трех фаз:

1. Разработка.

2. Использование.

3. Продолжающаяся разработка (или сопровождение).

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

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

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

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

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

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

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

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

Некоторые называют эту фазу «операционной» или «эксплуатационной» и говорят об «эксплуатации программного обеспечения». Обычными являются термины «фаза выполнения» или «время выполнения», так же как и термины «рабочая фаза» или «время работы» (рис. 4.2).

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

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

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

Если же речь заходит о велосипеде, мы сталкиваемся с тем, что в жизненном цикле возникает фаза сопровождения, или «регулировки». Из-за износа нам придется тратить усилия на ремонт, чтобы велосипед снова мог ездить (см. рис. 4.4).

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

Мы должны ломать стены, строить новые, переделывать отопительную систему, менять энергосеть и т. д. (см. рис. 4.5).

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

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

Вместо слова «ремонт» стоят слова «внесение изменений». Слово «строительство» также заменяется словом «разработка».

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

Рис. 4.8 показывает принципиальное отличие жизненного цикла аппаратуры от жизненного цикла программного обеспечения.

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

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

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

Другая причина того, что работы по облегчению будущего продолжения разработки зачастую не проводятся, заключается в том, что руководство различными фазами обычно проводится разными людьми. Рис. 4.9 показывает, что иногда руководство всеми тремя фазами находится в одних руках. Но это исключения.

Чаще же действует схема, изображенная на рис. 4.10. Имеются три ведущие группы, по каждой фазе своя. Руководители разработки мало заботятся о затратах на сопровождение и проблемах, возникающих на этой фазе.

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

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

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

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

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

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

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

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

Эти схемы соответствуют одноразовым разработкам, которые встречаются в случае программных обеспечений типов I и II.

Неразрывная связь разработки и продолжающейся разработки

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

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

Имеются ли различия в задачах разработки и продолжающейся разработки? Безусловно, но они не имеют ничего общего с тем, как их многие себе представляют. Мой коллега Энди Ферентино (который привлек мое внимание к рис. 4.13) был свидетелем выступления кандидата на соискание докторской степени по программированию, темой диссертации которого было различие между разработкой и «продолжающейся разработкой» (в терминологии автора «maintenance»). Энди указал на то, что окружение, в котором создается программное обеспечение, должно быть абсолютно одинаковым на обеих фазах. Эти два рода деятельности лишь очень немногим отличаются один от другого. Давайте проследим шаг за шагом.

Разработка программного обеспечения, продлевающая все фазы жизненного цикла

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

Таблица 4.1. Различия между разработкой и продолжающейся разработкой

Это проиллюстрировано на рис. 4.14, где размер букв пропорционален затратам на соответствующие фонды.

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

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

Фаза использования

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

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

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

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

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

Последствия отказов при разных типах использования.

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

Диапазон сложного программного обеспечения простирается от научного центра (годовой) стоимостью 50 млн. долларов, обеспечивающий диалоговую работу 460 ученых, где 90 % всех программ выполняется один-единственный раз, до управляющей системы, в которой программное обеспечение работает по 365 дней в году, по 24 ч. в сутки, не имеет права на малейший отказ и изменяется крайне редко — один раз в год.

Фаза разработки

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

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

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

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

— Компоновка

— Тестирование или верификация

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

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

Фаза продолжающейся разработки

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

Задачи продолжающейся разработки. Продолжающейся разработкой занимается группа сопровождения. Ее задачи таковы:

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

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

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

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

Усилия при продолжающейся разработке затрачиваются на:

1. Исправление программ, чтобы неправильно реализованные функции работали теперь правильно.

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

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

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

Три типа программного обеспечения

Все программное обеспечение может быть разделено на три всеохватывающих типа:

1. Прикладное обеспечение.

2. Системное обеспечение.

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

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

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

2. Системное программное обеспечение. Программы, которые выполняются в фазе использования наряду с прикладными программами. Системное обеспечение управляет ресурсами вычислительной машины, т. е. дисками, оперативной памятью, лентами, центральным процессором. Программное обеспечение, известное под названием операционной системы, также попадает в эту категорию, сюда же попадают и системы управления базами данных (СУБД). И то и другое будет несколько позднее рассмотрено нами в этом же разделе.

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

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

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

Чтобы легче было разрабатывать программное обеспечение, необходимо использовать инструментальное программное обеспечение.

Прикладное программное обеспечение

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

Этот тип обеспечения характерен тем, что: 1) его легче всего разрабатывать и 2) в этой области работает подавляющее большинство разработчиков программного обеспечения.

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

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

Отрасли в которых применяются прикладные программы

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

Системное программное обеспечение

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

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

Системное программное обеспечение служит для следующих целей.

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

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

Операционная система. Операционная система представляет собой большой набор программ. Это наиболее распространенная форма системного программного обеспечения.

Операционные системы применяются теперь почти повсюду. Размеры денежных вложений в создание и модификацию операционных систем просто ошеломляют. Фирма IBM вложила в свою операционную систему около 3 млрд. долларов, а конца расходам еще не видно.

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

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

1. «Управляет» работой аппаратуры.

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

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

в. Она приписывает поступающим заданиям приоритеты. (Это делалось раньше обслуживающим персоналом.)

2. Помогает выполнять функции, необходимые для работы прикладных программ.

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

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

3. Управляет хранением данных и их восстановлением, что совершенно необходимо для функционирования прикладных программ (так называемое Управление Данными)

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

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

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

5. Управляет взаимодействием с пользователем (при помощи терминалов или телевизионных экранов).

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

6. Защищает систему.

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

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

Операционные системы прошли длительный путь развития. В 1966 г. в журнале «IBM System Journal» была опубликована статья Мили под названием «Функциональная структура Операционной системы ОС/360». Мили отметил, что «идея операционных систем восходит по крайней мере к 1953 г., когда состоялась летняя школа по вычислительным машинам и пользовательским системам». Перед операционными системами «тогда, как и сейчас… ставили цель добиться безостановочного выполнения сразу нескольких задач и организовать библиотеку стандартных программ».

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

Автор статьи утверждает, что основной задачей разработки ОС/360 было получение системы «одинаково пригодной как для пакетной обработки, так и для применений в реальном времени». (Эта вторая цель так и не была достигнута.) Были и вторичные цели:

— Повысить скорость решения задач

— Уменьшить время ответа

— Повысить производительность программиста

— Адаптируемость к новым условиям

— Расширяемость

Достижение всех этих целей, за исключением первой, помогает программистам. Что же касается производительности, то «ОС должна обеспечить качественно новый уровень гибкости путем предоставления программистам относительно большого набора входных языков». Ставилась также и цель по достижению независимости от внешних устройств; новая аппаратура подключается автоматически без дополнительных усилий со стороны прикладных программистов! Среди многих других функций, выполняемых ОС/360 для программистов, — связывание частей больших программ, сортировки, работы по вводу/выводу. Для управления хранением и доступом к данным в операционную систему введено восемь различных вариантов программ. Теперь программисту не нужно писать самому подобные программы, в его распоряжении имеется много способов, чтобы указывать, как это должна делать операционная система.

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

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

Второй причиной создания СУБД является стремление к экономии пространства для файлов. Третья причина — это необходимость повысить достоверность информации в файлах, т. е. облегчить проверку отсутствия синхронизационных сбоев. Достоверность повышается благодаря уменьшению общего числа файлов. И наконец, с появлением СУБД облегчается доступ к данным. Многие ошибочно считают эту четвертую причину возникновения СУБД самой главной.

Как работает СУБД. Для понимания принципов работы системы управления базой данных полезно обратиться за иллюстрацией к организации авторемонтного дела. Начиная дело, я привлекаю всего трех механиков, причем каждый работает со своими собственными инструментами. Никаких стандартов пока не существует. Когда число механиков доходит до восьми, мы начинаем сталкиваться с проблемой несовместимости. Прибор, которым механик А1 устанавливает момент зажигания в автомобиле мистера Z, отличается от всех других аналогичных приборов — и, когда этот клиент начинает жаловаться, я проверяю все приборы и обнаруживаю, что все они работают по-разному! Различия между ними вызывают тревогу. Какой же из них «правильный»?

Шаг 1

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

Шаг 2

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

Шаг 3

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

С чем-то подобным мы сталкиваемся и в области программного обеспечения.

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

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

Шаг 1

Мы утвердили стандарты на файлы — размеры, форматы, последовательности — и тем самым облегчили использование данных, подготавливаемых другими программистами.

Шаг 2

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

Это сразу избавило нас от многих неприятностей.

1. Данные хранились в меньшем числе файлов; это экономило место.

2. Стало легче отслеживать текущее состояние элементов данных.

3. Стало возможно изменять размеры данных в файлах (числа с 12 знаками на числа с 14 знаками) без изменения всех индивидуальных прикладных программ.

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

Шаг 3

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

СУБД обычно сопровождается другими программами, которые 1) обеспечивают работу с дисплеями и 2) позволяют формулировать запросы к содержимым файл на простом языке. Такой язык часто называется языком запросов. На шаге 3 создается информационно-поисковая система. Функции, определенные нами на шаге 2, уточняются таким образом, чтобы они могли помочь при поиске данных. Но это лишь некоторая дополнительная выгода, побочный эффект усилий, прилагаемых для облегчения внесения изменений в файлы. Это отнюдь не главная причина, приведшая к появлению СУБД.

В табл. 4.3 сведены воедино все преимущества, даваемые СУБД.

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

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

Таблица 4.3. Преимущества использования системы управления базой данных

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

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

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

Таблица 4.4. Функции системных программ

Отнести конкретную программу к системному или прикладному обеспечению нам помогут два следующих критерия:

1. Откуда возникла данная программа? Была ли она разработана прикладным программистом или отдельной группой, созданной для сопровождения программ, а может быть, ее разработали те же, кто создал и аппаратуру? Кто сопровождает эту программу?

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

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

Разнообразие операционных систем. Некоторую путаницу в вопросы, связанные с операционными системами, вносит и тот факт, что их развитие привело в настоящий момент к появлению специализированных систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Системные программы индивидуального пользования пишутся довольно часто. Иногда такие системные программы могут применяться более чем одним пользователем. Разработанная фирмой IBM для резервирования авиационных билетов операционная система PARS (или АСР) используется более чем двумя десятками авиакомпаний и несколькими банками. Создание системы PARS было обусловлено тем фактом, что система ОС/360 оказалась слишком большой и медленной.

Система диспетчеризации воздушного транспорта, управляющая рейсовым авиационным транспортом, была написана один раз, а используется в 20 авиапортах Соединенных Штатов и в одном из авиапортов Великобритании. ОС/360 не смогла обеспечить необходимую надежность и подходящую схему распределения ресурсов; пришлось FAA (Federal Aviation Agency) (с помощью отделения федеральных систем IBM) писать собственные системные программы.

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

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

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

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

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

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

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

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

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

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

Переход от хорошей пакетной системы к системе реального времени — это переход к новым концепциям.

Преимущества системного программного обеспечения

1. Системное программное обеспечение увеличивает модульность и улучшает защиту информации, значительно упрощая процесс внесения изменений в программы.

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

3. Уменьшая простои, системное обеспечение доводит до максимума использование аппаратуры.

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

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

1. В силу универсальности системных программ снижается скорость их выполнения по сравнению со специализированными системами.

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

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

Таблица 4.5. Эволюция системного программного обеспечения

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

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

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

Они представляют собой набор инструментальных программ, и называть их «операционными» только за то, что они находятся в одном месте со всей системой, ошибочно. В табл. 4.6 перечислено по крайней мере некоторое программное обеспечение, работающее в разных фазах независимо от места работы, а в табл. 4.7 показано, какие программы могут работать автономно в различных местах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Масштаб

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вскоре после этого я посетил еще некоторые подчиненные системы. Там не было такой большой системы управления разработками — и разработки были неуправляемыми. Самым правильным был подход, применявшийся в Хьюстоне, — для управления разработкой действительно большой системы более 50 % средств нужно направлять на планирование, проверку, составление графиков, руководство и управление. Это и есть та инфраструктура, которую мы видим в других отраслях. Позже мне показали график, изображенный на рис. 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! Это просто астрономическое число, оно примерно равно 1011 801, или десятке, за которой следует 11 800 нулей! Если бы мы могли проверять один вариант программы за одну секунду, то на тестирование всей программы в целом нам пришлось бы затратить несколько тысяч лет. Мы не можем создать специальную тестирующую систему, которая могла бы проверить нам все варианты, возникающие в окружающем нас мире.

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

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

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

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

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

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

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

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

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

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

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

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

Ясность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

1) процесс определения требований;

2) широта усилий в смысле разнообразия разрабатываемых функций.

Таблица 4.12. Различия между программным обеспечением проекта и продукцией

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

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

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

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

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

Таблица 4.13 Характеристики программного обеспечения проектов и программного обеспечения как продукции

Требования к проектам и продукции. Выработать требования к системе «Аполлон» гораздо легче, чем к системе управления процессом обработки слов. Дело заключается в том, что ошибки при определении требований исправлять в первом случае значительно легче. Руководство программой Аполлон имело тесный контакт со всеми, кто будет пользоваться программным обеспечением, и вполне способно управлять ими.

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

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

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

Размах работ при разработке проектов и товарных программ.

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

Доведение программы до товарного уровня

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

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

— Пересмотреть существующую документацию, если она действительно существует.

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

— Создать документацию на продукцию.

Создать рекламную литературу, кратко описывающею нашу продукцию.

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

— Пример граничных условий

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

— Сделать рабочую программу ясной. Исследовать программу: убедиться, что в ней нет «никуда не ведущих условных переходов», «тупиков», мертвых концов и т. д.; добавить команды «защиты», необходимые на случай нарушения граничных условий на параметры.

— Модуляризация/расслоение.

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

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

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

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

— Выделить финансовые средства и определить состав группы сопровождения и необходимого для нее оборудования и т. д.

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

— Организовать систему «оповещения об ошибках».

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

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

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

Программная продукция и продукция, различающаяся по программному обеспечению

Часть программного обеспечения может продаваться на рынке исключительно благодаря тому, что оно программное (т. е. может выполняться на вычислительной машине). Другие же программы неотъемлемы от аппаратуры, в комплексе с которой они продаются. На разработку этих различных видов программного обеспечения затрачиваются разные усилия. Примером системы первого типа является программа печати платежной ведомости. Второй тип программного обеспечения можно себе представить на примере программы обработки слов; эта программа в значительно большей степени, чем аппаратура, влияет на качество всей системы в целом, хотя и неотделима от нее.

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

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

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

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

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

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

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

Важнейшим пунктом при этом является правильность программы. Она должна быть правильной, иначе нам придется изъять у пользователей все 500 тысяч телевизоров и исправлять программу. Экономический эффект такой операции будет просто ошеломляющим. С некоторыми потребительскими товарами уже случались такие катастрофы. Что же будет, если наша микросхема будет позволять хранить все больше команд, оставаясь на прежнем уровне стоимости? Конечно же, инженеры попытаются вставить в микропроцессор более крупные программы. И если мы еще можем быть полностью уверены в правильности программы из двухсот команд, то 100 %-ная уверенность в правильности программ из 1000 или 10 000 команд нам недоступна.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такая продукция:

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

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

— должна быть очень хорошо документирована;

— должна выполнять большое число функций, что поможет ей удовлетворить большое число пользователей;

— должна сопровождаться людьми, которые готовы исправить ее и внести в нее дополнения;

— богатый набор ее функций должен быть перед реализацией тщательно выверен и определен;

— соревнование за пользователей начнется для нее после введения в эксплуатацию; конкурентами будут другие сети.

Таблица 4.14. Примеры программ и их соответствие классификации

V — обычно присутствует, * — может быть несколько вариантов, Н — низкий, С — средний, В — высокий, ОВ — очень высокий.

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

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

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

В гл.2 мы уже отмечали, что стоимость больших программ может достигать 90 % общей стоимости проекта.

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

Если от нас требуют разработать основную программу, используемую на одной и только одной вычислительной машине, например программу управления информационной системой для компании XYZ мы будем не вправе делить стоимость программы на число пользователей. К тому же число это равно 1, и вся стоимость накладывается на одного пользователя. Если же нам нужно вставить нашу программу в маленькую вычислительную машину внутри телевизора, мы разделим стоимость программ, написанных для этой машины, на общее число телевизоров, которые будут выпущены в эксплуатацию. Если разработка программ обошлась в 200 тыс. долларов, то после деления на 500 тысяч телевизоров получим удельную стоимость всего 40 центов. Все очень просто! О чем же волноваться? Пока программа правильна, никаких проблем и не существует. В табл. 4.15 представлено все многообразие «тиражей» различных вычислительных машин.

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

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

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

Мы не должны допускать предложений типа «70 % стоимости программного обеспечения приходится на этап продолжающейся разработки». Во многих случаях это правда; во многих — нет. Это слишком общее высказывание. Мы должны добиваться большей точности, использовать уточняющие определения. Люди, не являющиеся специалистами в области вычислительной техники, не только введены в заблуждение относительно вычислительных машин и их программного обеспечения, но также возмущены жаргоном и небрежностью, царящими в нашей отрасли. Если профессионал не настаивает на точности высказываний, является ли он подлинным профессионалом?