Раздел – Информационная безопасность и защита информации.

Вопрос 13 – Предотвращение неисправностей в по ас.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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