2. Исследование корректности реализации и верификация ас _______мин.

Понятие корректности или правильности подразумевает соответствие проверяемого объекта некоторому эталонному объекту или совокупности формализованных эталонных характеристик и правил.

(СЛАЙД _7_)

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

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

Спецификация требований программного обеспечения (Software Requirements Specification) — законченное описание поведения системы, которую требуется разработать.

Включает ряд пользовательских сценариев (Use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.

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

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

В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований – “Recommended Practice for Software Requirements Specifications”.

(СЛАЙД _8_)

Стандарт IEEE Std 830-1998 — Recommended Practice for Software Requirements Specifications. По сути — это аналог рекомендаций для написания технического задания по ГОСТ 34.602, но более новый и, соответсвенно, отвечающий всем современным требованиям по составлению ТЗ, основанный на структурно-функциональном подходе к пониманию систем.

Стандарт IEEE 830 является признанным разработчиками как не только формально обязательный, но и практически полезный при разработке спецификаций.

В стандарте определены основные ключевые требования «хорошей спецификации»:

Unambiguous (недвусмысленность) — отсутвие лескических, ситаксических и семантических ошибок Complete (полнота) — должны быть описаны все значимые области требований Verifiable (проверяемость) — должны содержаться только те требования, которые могут быть численно измерены Consistent (целостность) — не должно быть конфликтов требований Modifiable (модифицируемость) —спецификация должна быть легкой в использовании и организации ссылок между требованиями Traceable (трассируемость) — спецификация должна позволять пошагово отслеживать (трассировать) от требований до предыдущих принятых решений, от документов расширяющих спецификацию (проектировка и т.д.) к требованиям текущего состояния спецификации

Usable (возможность применения) — спецификация должна без излишних деталей описывать весь жизненный цикл системы

Также в стандарте IEEE 830 1998 определено прототипирование как метод разработки требований к системе и даны образцы структуры спецификаций.