Читать интересную книгу Программное обеспечение и его разработка - Фокс Джозеф М.

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

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

Замеры времени

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

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

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

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

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

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

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

Рис. 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. Три фазы жизненного цикла программы.

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