25. Обзоры как средство обеспечения качеством программных средств и ис.

Процедуры и типы проверок в виде обзоров для программных средств отражены в американском стандарте, где рассматриваются 3 вида обзоров, которые называются «формальные технические обзоры» FTO - это технический обзор, сквозной просмотр и внимательное изучение представленных материалов.

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

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

Цель технического обзора – оценка качества и создание информации для управления проектом.

Информация:

1. Обнаружить возможные ошибки в функциях, логики и реализации

2. показать, что характеристика элемента соответствуют установленной сертификации.

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

4. доказать что сделанные изменения осуществлены соответствующим образом и при этом учтены все побочные влияния тих изменений.

5. обеспечить единообразие в разработки разных частей системы документирования и т.д.

6. упростить и улучшить процессы управления проектом системы.

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

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

Особенности проведения формальных технических обзоров:

1. организация встречи и ее проведение определяется установленными правилами.

2. Встреча и проведение обзора протоколируется

3. Для проведения обзора выделяется руководитель и есть правила проведения таких обзоров

4. Для повышения эффективности перед каждым обсуждением составляется список вопросов подлежащих проверке, контролю, испытанию.

Экономическое влияние дефектов, при разработке программного средства для ИС

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

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

Если принять стоимость исправления ошибки, обнаруженной на этапе архитектурного проектирования за единицу – она же будет стоить до тестирования в 5-6 раз больше, если она обнаруживается во время тестирования – в 15 раз больше, а после внедрения в эксплуатацию – стоимость исправления от 50 до 100 единиц.

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

Если не применять средств обнаружения ошибок то все эти ошибки, усиленные, переходят на следующую фазу, а переход на следующую фазу стоимость их обнаружения резко возрастает.

Можно на количественных данных показать, что ведение формальных технических обзоров позволяет снизить стоимость обнаружения ошибок в десятки раз.

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

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

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