7.1.2. Корректность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ тестового покрытия включает применение двух методов: анализ покрытия, основанного на требованиях; анализ структурного покрытия.

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

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

В стандарте ISO 9126:1–4 выделяются понятия и атрибуты внутренней и внешней корректности.

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

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