Владимир Липаев - Очерки истории отечественной программной инженерии в 1940-е – 80-е годы

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

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

На практике в процессе ЖЦ исходные требования поэтапно уточняются, модифицируются, расширяются и детализируются по согласованию между заказчиком и разработчиком. Базой таких уточнений являются неформализованные представления и знания специалистов-заказчиков и разработчиков, а также результаты промежуточных этапов проектирования. Однако установить не корректность таких эталонов еще труднее, чем обнаружить дефекты в программах, так как принципиально отсутствуют формализованные данные, которые можно использовать как исходные. В процессе декомпозиции и верификации исходной требований, возможно появление ошибок в спецификациях на группы программ и на отдельные модули. Это способствует расширению спектра возможных дефектов и вызывает необходимость создания гаммы методов и средств тестирования для выявления некорректностей в спецификациях на компоненты разных уровней.

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

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