3.2) Процесс контроля изменений

После регистрации запроса на изменение необходимо принять решение о его дальнейшей судьбе.

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

а) из степени важности запроса для Заказчика и

б) из его стоимости для Разработчика. Стоимость определяется на основании анализа влияния изменения.

3.3) Анализ влияния изменения

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

Анализ результатов изменений затрагивает три аспекта.

1.Определите возможные последствия изменения.

2.Определите все файлы, модели и документы, которые, возможно, придется изменить, если команда включит все запрошенные изменения.

3.Определите задачи, необходимые для реализации изменения, и оцените усилия, необходимые для выполнения этих задач.

3.4) Трассируемость требований

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

Тема11: Проверка требований

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

-извлечение;

-видение;

-классификация;

-спецификация;

-моделирование и прототипирование.

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

1)Верификация и валидация

Понятие проверки можно подразделить на верификацию и валидацию.

Термин "верификация" (verification) в русскоязычной литературе обычно переводят, как "проверка".

Термин "валидация" - как "проверка правильности", "аттестация", "утверждение".

Согласно стандарту IЕЕЕ 1012-1986

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

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

Отличия:

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

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

Т.о. валидация предполагает, что требования изменяются до последнего момента.

Стандарт IEEE 1059-93 "IEEE Guide for Software Verification and Validation Plans” обобщает понятие V&V (Validation and Verification).

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

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

Осуществить верификацию и валидацию АИС и (или) процесса ее создания означет, что:

- АИС (компонента, процесс) соответствует сформулированным требованиям;

-АИС действительно работает.

…действительно.. выполнить верификацию, необходимо:

1) Обеспечить удовлетворение требований свойствам, сформулированным ранее (полнота, трассируемость и др);

2)Убедится в том, что

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

-требования обеспечивают качественную основу для проектирования и сборки ПО.