интересно
Предыдущая | Содержание | Следующая

Проблемы стандартизации и сертификации информационных услуг и продуктов для экономических приложений

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

Наиболее подробно процессы верификации программ представлены в стандарте DO 178 В - 1995 - Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения, который использован ниже при изложении основных принципов верификации.

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

Назначение верификации ПС состоит в том, чтобы обнаружить, зарегистрировать и устранить дефекты и ошибки, которые могли быть внесены во время разработки или модификации программ. Основное назначение верификации ПС - проверить, что (рис. 1):

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

требования высокого уровня правильно переработаны в архитектуру ПС и в требования к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня;

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

• архитектура ПС и требования к компонентам низкого уровня корректно переработаны в удовлетворяющий им исходный текст программ;

• исполняемый объектный код удовлетворяет требованиям к исходному тексту программ. Кроме того, верификации на соответствие спецификации требований для конкретного проекта комплекса программ подлежат требования к технологическому обеспечению ЖЦ ПС, а также требования к эксплуатационной и технологической документации.

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

верификации ПС рекомендуется такая последовательность основных процедур:

проверка корректности и непротиворечивости исходных требований высокого уровня (контракта) и демонстрация прослеживаемости к ним;

анализ прослеживаемости и анализ покрытия исходных требований и структуры, которые должны показать, что каждое требование к ПС является трассируемым к реализующему его объектному коду, а выполненные просмотры, анализы и сгенерированные тестовые наборы проверяют эти требования;

если код, который выполнялся в процессе тестирования, не идентичен объектному коду ПС, то это несоответствие должно быть указано и обосновано;

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

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

Просмотр может включать инспекцию выходных результатов указанных процессов. Цель анализа – детально исследовать функциональность, эффективность, прослеживаемость и надежность компонентов ПС, а также их связи с другими компонентами системы и оборудованием ИС [1, 2]. Цель просмотров и анализов требований высокого уровня – обнаружить, зарегистрировать и устранить

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

полностью определены функции информационной системы, которые должно выполнять ПС, и требования по функциональности, эффективности и безопасности системы удовлетворены в исходных требованиях высокого уровня к ПС, правильно определены производные требования и обоснована их необходимость;

каждое требование высокого уровня является точным, однозначным и достаточно детализированным и требования не конфликтуют друг с другом;

не существует никаких конфликтов между требованиями высокого уровня и возможностями аппаратных и программных средств объектного вычислителя, особенно такими, как время реакции системы и аппаратура ввода/вывода;

каждое требование высокого уровня может быть проверено и верифицировано;

процесс разработки требований к ПС полностью соответствует стандартам на создание требований и обоснованы любые отклонения от стандартов;

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

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

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

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

Интерпретация процессов верификации в стандартах в области обеспечения ЖЦ программных средств может быть различной. Хотя основные функции верификации – обеспечение реализации требований к ПС и их компонентам на всех уровнях структуры комплекса программ – сохраняются, акценты на критерии и порядок выполнения верификации несколько различаются. Вариант основных регламентированных задач верификации программных средств по-иному отражен в разделе 6.4 стандарта ISO 12207:1995 – Процессы жизненного цикла программных средств (ГОСТ Р ИСО/МЭК–1999), сокращенное содержание которого представлено ниже. Процессы верификации в стандарте включают в свой состав следующие задачи и критерии:

1) верификация договора по критериям:

требования непротиворечивы и покрывают все потребности пользователя;

предусмотрены адекватные процедуры для регулирования изменений требований договора;

предусмотрены процедуры для сотрудничества между участниками-сторонами проекта, включая право собственности, гарантию, авторское право и конфиденциальность;

предусмотрены критерии и процедуры приемки результатов разработки на соответствие требованиям договора;

2) верификация требований к информационной системе по критериям:

требования системы непротиворечивы, выполнимы и проверяемы;

требования системы распределены между компонентами аппаратных, программных средств и ручными операциями полностью и в соответствии с критериями проекта;

требования к программному средству последовательны, выполнимы, тестируемы и точно отражают требования системы;

3) верификация процесса проектирования по критериям:

процессы, выбранные для проекта, адекватны, реализуемы, выполняются, как запланировано, и соответствуют договору;

стандарты, процедуры и область функционирования адекватны для проектных процедур;

проект укомплектован ресурсами и персонал обучен, как требуется по договору;

4) верификация проекта по критериям:

проект корректен и не противоречит исходным требованиям договора и системы;

проект полностью исходит из требований к системе;

проект правильно реализует безопасность, защищенность и другие критические требования;

5) верификация программ по критериям:

текст программ удовлетворяет проекту и требованиям системы, тестируем, корректен и соответствует стандартам программирования;

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

программа корректно обеспечивает безопасность, защищенность и другие критические требования;

6) верификация интеграции компонентов по критериям:

компоненты и элементы каждого компонента программного средства полностью и правильно интегрированы в комплекс программ;

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

7) верификация документации по критериям:

документация адекватна, полна и непротиворечива;

подготовка документации выполнена своевременно;

управление документами следует плановым процедурам.

Тестирование программ, основанное на требованиях, в процессе разработки должно охватить функционирование ПС во всей доступной области варьирования исходных данных и режимов применения. При этом номенклатура и диапазоны варьирования тестов ограничены либо допустимой длительностью подготовки и исполнения тестов, либо вычислительными ресурсами, доступными для использования с целью контроля и тестирования в режиме нормальной эксплуатации. Это отражается на выборе методов тестирования и последовательности анализа компонентов ПС, объеме применяемых тестов и глубине тестирования [3 – 5].

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

В стандартах выделяются три уровня тестирования сверху – вниз:

тестирование интеграции программных компонентов с аппаратурой ИС, верифицирующее корректность функционирования ПС в среде объектной ЭВМ;

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

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

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

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

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

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

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

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

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

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

Развитие методов и средств аккумуляции знаний о развитии экономической системы и использование искусственного интеллекта при выработке управленческих решений