Предотвращение неисправностей в по ас

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

В настоящее время за рубежом модели жизненного цикла реализуются в виде стандартов. Анализ современных отечественных и зарубежных стандартов позволяет сделать вывод о том, что основными фазами создания ПО являются:

• анализ и спецификация требований;

• проектирование;

• исполнение.

Рассмотрим содержание каждой из фаз, в контексте решения задачи предотвращения неисправностей ПО.

1. Фаза анализа и спецификации требований. Стремление к достижению большей надёжности ПО привлекает особое внимание к самым ранним фазам цикла создания программ. Новейшая и наименее разработанная область обеспечения программной надежности — область спецификаций требований. Анализ всей совокупности требований к системе — технического задания (ТЗ) выполняется на начальной фазе создания программ. ТЗ составляется на основании перечня требований, предъявленных к системе заказчиком (классы решаемых задач, их характеристики и особенности, режим работы АС, сопряжение с внешними объектами, пропускная способность, время ответа и т.п. при заданных ограничениях на стоимость, длительность разработки и др.). Цель создания ТЗ — уточнить и сформулировать задачи, возлагаемые на систему, согласовать требования заказчика и возможности исполнителя, составить техническое задание на ПО. Это делается для того, чтобы удостовериться, что от программ требуются только те системные требования, которые могут быть достигнуты.

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

Успехи в теории программирования и вычислений обеспечили использование формальных методов при разработке ПО. Формальный метод разработки систем состоит из трёх основных компонентов:

• формальной записи спецификаций и описаний проектов;

• методики получения реализации из спецификаций;

• составления правил вывода (или доказательства) того, что реализации отвечают этим спецификациям.

Достоинство формальных методов заключается в том, что системы, разработанные с использованием подобного подхода, имеют принципиально высокое качество. При этом повышение качества достигается двумя путями:

• построением спецификаций в виде ясного, исчерпывающего, недвусмысленного и лёгкого для проверки математического утверждения;

• осуществлением верификации во время разработки ПО.

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

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

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

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

3. Фаза исполнения. Фаза исполнения включает в себя кодирование, интегрирование, а также тестирование и отладку. Примем подход, согласно которому тестирование служит инструментом измерения, но не обеспечения надёжности программ. Поэтому тестирование исключается из дальнейшего рассмотрения.

С каждой из фаз создания ПО связаны специфические ошибки. С фазой анализа и спецификацией требований — системные ошибки, с фазой проектирования — алгоритмические и с фазой кодирования — программные.

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

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

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

Таким образом, на основании анализа фаз создания ПО и допускаемых на них ошибок можно сделать вывод о том, что двумя основными разновидностями ошибок являются:

• неверное специфицирование как всего программного комплекса, так и отдельных его составляющих;

• функциональное несоответствие программы алгоритму.

Предотвращение данных ошибок — путь к обеспечению защиты от сбоев и неисправностей ПО.

Статьи к прочтению:

✯ Возможные неисправности окрасочного аппарата ASpro-2000 и способы их устранения.

Похожие статьи: