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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Защита семантического анализа и актуальности информации

Рассматривая защиту АС в соответствии с подходом, описанным в гл.1, определим еще два уровня: уровень представления и уровень со­держания информации.

На уровне представления информации защиту от угрозы отказа дос­тупа к информации (защиту семантического анализа) можно рассматри­вать как противодействие сопоставлению используемым синтаксическим конструкциям (словам некоторого алфавита, символам и т.п.) определен­ного смыслового содержания. В большей степени эта задача относится к области лингвистики, рассматривающей изменение значения слов с тече­нием времени, переводу с иностранного языка и другим аналогичным на­учным и прикладным областям знаний. В качестве примера нарушения доступности информации можно привести сообщение времен Петра I о том, что переправа войск через реку осуществлялась на самолетах. Ис­тинный смысл сообщения заключается в том, что переправа войск прохо­дила не на летательных аппаратах (иначе сообщение было бы историче­ски неверно), а на небольших плотах. В этом примере защита информа­ции осуществляется использованием факта "самолет-небольшой плот (устар.)". Если потенциальный злоумышленник не знает этот факт, для него не будет доступен смысл сообщения.

Применительно к АС задача защиты от угрозы доступности инфор­мации может рассматриваться как использование для обработки файла данных программ, обеспечивающих воспроизведение данных в том виде, как они были записаны. Рассмотрим, например, файл, содержащий тек­стовую информацию и данные о ее оформлении (выделение курсивом, подчеркивание и т.п.). Если для воспроизведения выбрать более простой редактор, или редактор, не поддерживающий выбранный тип разметки, выделение определенных слов пропадет, а значит, будет утрачена часть информации, которая закладывалась в оформление текста.

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