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