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

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

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

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

Балансировка системы

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

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

Рис. 3.2. Пропускная способность системы и МКС как средства оценки производительности вычислительной машины.

На рис. 3.2 наглядно подытоживаются наши рассуждения о производительности.

Глава 4
Таксономия программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.1. Три фазы жизненного цикла программы.

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

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

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

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

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

Рис. 4.2. Синонимы термина «программное обеспечение фазы использования».

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

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

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

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

Рис. 4.3. Жизненный цикл молотка.

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

Рис. 4.4. Жизненный цикл велосипеда.

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

Рис. 4.5. Жизненный цикл административного здания.

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

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

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

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

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

Рис. 4.7. Жизненный цикл программного обеспечения.

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

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

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

Рис 4.8 Жизненный цикл аппаратуры.

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

Рис. 4.9 Одна группа руководит работами на всех стадиях жизненного цикла

Рис. 4.10 Три руководящие группы; один жизненным цикл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Определение требований для системы типа V крайне затруднено, так как до этого таких систем еще не было	С системами типа V работать легче, так как пользователь к этой фазе уже лучше знает, что ему нужно
(Для систем типов I и II работа по определению требований практически одинакова)
2. Проектирование. Большие возможности. Выбираются лучшие варианты. Начинают сверху	Проще, поскольку система существует, многое из того, что спроектировано на верхних уровнях, сделано, и в большей мере определяет то, что надо делать на более низких уровнях. Труднее, если документация плохая. Напоминает археологические раскопки
3. Программирование Такое же	Такое же
4. Компоновка Такая же	Такая же
5. Тестирование Такое же	Такое же
6. Документирование Такое же	Такое же

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

Рис. 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. Различные области применения прикладного программного обеспечения.

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

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

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

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

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

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

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