Национальные
информационные ресурсы:
проблемы промышленной эксплуатации.
Г.Р.Громов. Москва,
Наука, 1984
Шкала относительной тяжести ошибок по фазам проекта
В 1975 г. на проходившей в Нью-Йорке Международной конференции по надежности программного обеспечения отмечалось: «Ничто, абсолютно ничто не может более пагубно повлиять на разработку, чем неполное знание или неправильное знание и, как следствие, неадекватная спецификация требований к системе и программному обеспечению» [17, с. 49]. Г. Майерс ссылается на материалы этой конференции, чтобы подчеркнуть, что, «к сожалению, слишком редко на эти процессы обращается достаточное внимание» [17, с. 49].
Характеризуя объективные трудности, которые традиционно мешают уделить «достаточное внимание» этапу формулировки задачи на программирование, В. В. Липаев, например, следующим образом предупреждает своих читателей: «...наиболее специфическим, трудно формализуемым и тесно связанным с функциональным назначением программ является этап системного анализа. На этом этапе формулируются назначение и основные показатели качества создаваемых программ, решаемые задачи практически полностью определяются предметной областью системного анализа. Поэтому здесь трудно обобщать технологические процессы и критерии качества при создании различных типов программ. Ниже этот этап жизненного цикла не рассматривается, и предполагается, что функциональные задачи и алгоритмы их решения в основном определены и формализованы» [20, с. 11].
Г. Майерс, кроме того, приводит ссылки на некоторые справочные работы по системному анализу, в которых предлагаются методы организации «беседы с пользователями, проведение исследований осуществимости и оценки достоинств» проекта и т. д. Упоминаются и первые попытки создания формальных систем для выработки спецификаций (системы типа ADS, TAG, Information Algebra), которые, подчеркивается, «ориентируются на небольшие, специализированные и исключительно хорошо определенные задачи». Кратко обсуждаются также возможности HIPO-диаграмм в качестве одного из вспомогательных средств системного аналитика [17, с. 50].
Таким образом, хотя причины, объективные и субъективные, по которым наиболее сложный этап программирования — постановка задачи и выработка спецификаций па программный продукт — все еще не привлекает заметного внимания науки программирования, могут быть существенно и даже принципиально различными, однако проблема сама по себе от этого, разумеется, не исчезнет. Существующие трудности углубляются, а их экономическое бремя для отрасли в целом становится все более ощутимым.
Под влиянием продолжающегося процесса перемещения общего центра тяжести усилий по разработке прикладных программ с фазы реализации на фазу постановки задачи в 70-х годах была сформирована еще одна профессиональная группа: системные аналитики/программисты (system analyst/programmer) [16]. В задачу специалистов этой группы входило детализировать общие спецификации на проект, которые они получали от системных аналитиков, до уровня спецификаций на отдельные программы, а также участвовать вместе с прикладными программистами в преобразовании таких детальных спецификаций в логическую структуру программ, структуры данных и т. д.
В результате цепочка специалистов, сквозь которую должна безошибочно пройти задача пользователя, до того, как она может быть решена на ЭВМ, приобрела следующий вид:
1. Конечный пользователь — автор исходной задачи, а в ряде случаев и заказчик соответствующего программного продукта.
2. Системный аналитик преобразует цели, назначение, технические характеристики и условия правильности прикладной задачи в общие формальные требования на программный продукт.
3. Системный аналитик/программист преобразует общие формальные требования в детальные спецификации на отдельные программы, участвует в разработке логической структуры и т. д.
4. Прикладной программист преобразует спецификации на программу в логическую структуру программных модулей, а затем и в программный код.
5. Системный программист ведет сопровождение операционной системы, разрабатывает инструментальные средства для поддержки процесса разработки программ, обеспечивает сопряжение с ОС драйверов нестандартных внешних устройств, когда они необходимы для решения прикладной задачи, и т. д.
Каждый из участников этой технологической цепочки (все более уязвимой с точки зрения надежности) выполняет свой этап преобразования исходных условий задачи. Таким образом, до того как начинает работать первый проход машинной трансляции программного кода, типовая прикладная задача обычно проходит не менее трех этапов трансляции «человек—человек».
«Создание программного обеспечения,— отмечает Г. Майерс,— просто совокупность процессов трансляции, т. е. перевода исходной задачи в различные промежуточные решения, пока, наконец, не будет получен подробный набор машинных команд ... Понимание того, что именно ошибки перевода являются причиной ошибок в программе, чрезвычайно важно, так как это — ключ к пониманию проблемы надежности» [17, с. 22].
Можно ли в общем случае, не затрагивая специфики предметной области, оценить относительную тяжесть отдельных «ошибок перевода» в зависимости от звена технологической цепочки, на котором ошибка возникает?
Давно установлено, что тяжесть ошибки (стоимость исправления) быстро возрастает с увеличением интервала времени (технологического времени: число производственных операций между двумя событиями) между появлением погрешности и ее обнаружением.
Вице-президент «Белл лэбс» по компьютерной технологии и системам военного назначения Е. Самнер считает, что на интервале от выработки требований на программы до сдачи программного продукта заказчику стоимость расходов на исправление ошибки возрастает в среднем в 80 раз. «Чем дольше ошибка остается в системе, тем дороже становится ее исправление»,— подчеркивает он [21, р. 14]. В 1983 г. приводились следующие данные о средней стоимости исправления ошибки в зависимости от этапа цикла жизни программы, на котором соответствующая ошибка «всплывала» (по данным исследований фирм «TRW», «GTE Corp.» и «IBM»): на этапе составления спецификаций— 140 долл.; кодирования — 1000 долл.; комплексной отладки — 7000 долл.; сопровождения (у заказчика) — от 14000 до 140000 долл. на каждую ошибку [22].
Итак, тяжесть ошибки растет (много быстрее, чем линейно) в зависимости от интервала времени, на котором она не была обнаружена. Характер процесса трансляции условий исходной задачи в машинный код по звеньям технологической цепи, показанный в табл. 21, полностью определяет для каждого этапа трансляции тот минимальный отрезок технологического времени, на котором ошибка данного этапа не может быть обнаружена (так называемое мертвое время ошибки). Как видно из табл. 21, только прикладной программист принципиально в состоянии обнаружить свою ошибку до того, как по результатам его ошибочных действий будет выполняться работа другим участником проекта (может обнаружить, но может, разумеется, и пропустить ее, не заметив, на следующие этапы). Все остальные участники проекта принципиально не могут обнаружить содержательной ошибки (технические и логические ошибки могут перехватываться) до этапа комплексной отладки, а конечный пользователь — до приемосдаточных испытаний.
Причина такой ситуации понятна: каждый из последующих участников технологического процесса перевода условий исходной задачи не располагает информацией, необходимой для исправления содержательных ошибок, внесенных в условия задачи его предшественником, и, следовательно, «мертвое время» ошибки определяется числом технологических операций, отделяющих каждого исполнителя от первого контакта с работающей программой, когда он только и может, наконец, увидеть, что же он «натворил» (или как его поняли).
После 10—15 лет драматической борьбы программистов-специалистов, способных па бумаге создавать, преобразовывать и передавать один другому сложные информационные конструкции, усилием мысли заставляя их при этом взаимодействовать с реальным миром (во всяком случае так, как они этот мир понимали), стало ясно, что цена крупномасштабной игры в «испорченный телефон» по приведенной выше технологической цепочке становится недопустимо высокой. Так вслед за блок-схемами, модульностью и структурированием в программирование был введен еще один элемент технологической поддержки со стола радиоинженера — макет. Тот самый макет, который веками сопровождал любую сколько-нибудь сложную инженерную разработку, а последние 100 лет не сходит со стола электро- и радиоинженеров.
Назначение макета — отладка принципиальных решений, созданных на данном этапе технологической цепочки. На каждый следующий уровень проекта передается как само решение, так и доказывающий его верность, а также иллюстрирующий основные заложенные в решение принципы действующий макет. При этом «мертвое время» существования принципиальной ошибки почти для всех участников проекта практически выравнивается до интервала: от формулировки решения данного этапа задачи до изготовления иллюстрирующего его макета.
Понятно, что макет не освобождает от лавины неожиданностей (редко приятных) на заключительных этапах проекта (от этапа комплексной отладки и далее), так как остаются проблемы корректности интерфейсов, взаимное влияние модулей и много других традиционных инженерных «радостей», которые, как правило, порождает любая большая система. Однако важно, что пооперационный макет существенно снижает порядок числа ошибок, всплывающих на комплексных испытаниях «большого макета».
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
В 1983 г. Б. Боем из военного сектора фирмы «TRW» опубликовал результаты исследований, согласно которым экономическая тяжесть поиска и устранения ошибки программирования на интервале от выработки требований до сопровождения растет как логарифмическая функция технологического времени, на котором она оставалась необнаруженной. «Большая часть ошибок закладывается в проект ещё до того, как начинается процесс кодирования программ»,— формулирует Боем [23, р. 9] основные итоги статистического анализа большого числа проектов, выполненных ведущими фирмами отрасли.
Онлайн-версия CD-ROM
приложения к книге Г.Р.Громова
"От гиперкниги к гипермозгу: информационные технологии
эпохи Интернета. Эссе, диалоги, очерки."