Программное обеспечение и его разработка - [90]
Эта идея о необходимости «версий» была подана мне в 1970 г., когда в комитете Конгресса готовились к публичному слушанию дела о разработке системы диспетчерского контроля за авиаперевозками. Один из экспертов конгресса, изучавший вместе со мной материалы, пришел к выводу, что FAA и IBM будут подвержены критике, поскольку «тот факт, что выпущено семь версий программы, доказывает, что группа не знала, что нужно делать». Я сказал ему, что подготовлюсь к ответу на это обвинение за несколько дней.
Случилось так, что буквально на следующий день после этого я встретился со своей хьюстонской группой и узнал, что у них была «версия 14.7» — т. е. всего, если отвлечься от непонятных обозначений с десятичными дробями, было по крайней мере четырнадцать версий, — и все-таки человек высадился на Луну!
«Зачем так много версий?» — спросил я. Мне привели две причины. Во-первых, сотни операторов управляющих пультов, взаимодействующих с вычислительной машиной, не в состоянии воспринимать изменения в операторских процедурах большими дозами — им надо подавать их по частям. Кроме того, даже сейчас никто не может предвидеть, что захотят в дальнейшем пользователи и что будет необходимо добавить в систему управления.
Все это я передал эксперту Конгресса. Мне показалось, он воспринял смысл всего этого. Но либо он не разговаривал с членом Конгресса, либо конгрессмен не захотел его выслушать, при публичных слушаниях нас подвергли суровой критике за множество исправлений системы, число версий которой показывало, что мы не знали, что делаем!
Что мы имеем — или должны иметь — (с точки зрения программного обеспечения) в первой версии программной системы, состоящей из двух весьма различающихся множеств программ, которые будут выполняться одновременно:
1. Множество системных программ, которые будут составлять график выполнения прикладных программ на машине и управлять внешним окружением.
2. «Начальное множество» прикладных программ, с которыми пользователь может начать работу со своей системой и а) извлекать из нее пользу и б) находить новые и более хорошие способы работы, которые можно будет добавлять в последующие версии или варианты программ. Такой процесс подключения новых функций продолжается в течение всего периода жизни системы.
Почему от такого подхода частенько отказываются? Имеются по крайней мере три причины, которые мешают принять этот эволюционный подход.
Во-первых, он, по-видимому, дороже стоит. Введение в системные программы такой инфраструктуры, которая позволяет им легко воспринимать новые функции прикладных программ, стоит денег, а все преимущества этой инфраструктуры становятся видны только на фазе сопровождения программ, да и тогда они видны только посвященным. Показать эти преимущества нельзя никоим образом, и руководство может только смутно ощущать то, что ему говорят непосредственные технические исполнители. Лишь подлинно мудрый руководитель не побоится затрат на все это. Построение гибкой системы приводит к повышению затрат при разработке; однако общая стоимость жизненного цикла снижается.
Во-вторых, такая инфраструктура программ требует дополнительных затрат машинных ресурсов в фазе использования; необходимы и дополнительная память, и время процессора. Оба этих ресурса часто оказываются дефицитными.
В-третьих, задача проектирования такой инфраструктуры не относится к легким, требующим лишь технических усилий. Для проектирования такой гибкости структуры нужны крайне талантливые люди.
Руководство разработкой программного обеспечения весьма непростое дело. Нужно решать и управлять решением огромного количества мелких, но и важных задач. Ниже следует список, представляющий собой оглавление «Военного стандарта ВМФ США 1679» — разработку программного обеспечения систем вооружения. Все основные пункты мы уже рассмотрели, но и более мелкие могут играть важную роль и сейчас, и в дальнейшем. Этот список прекрасно иллюстрирует трудности задачи разработки:
Общие требования
Руководство разработкой программного обеспечения
Требования к проектированию
Формирование программ
Гарантия качества
Руководство конфигурацией
Управление подрядными работами
Отклонения и отказы от требований
Подробные требования
Требования к производительности программ
Вспомогательная информация для требований о производительности программ
Анализ производительности программ для вычислительных машин
Области применения
Функции
Документация, необходимая для требований по производительности программ
Описание системы вооружения
Функциональное описание
Подробные функциональные требования
Регулируемые параметры
Системные ресурсы
Требования к проектированию программ
Вспомогательная информация для требований к проектированию программ
Анализ проекта программ для вычислительных машин
Документация, необходимая для требований к проектированию программ
Распределение функций
Функциональная схема программы
Распределение ресурсов и резервы
Проектные ограничения
