3.1.5. Трассировка требований

Одной из главных проблем сбора требований является проблема их изменения. Требования создаются итерационно путем постоянного общения представителей заказчиков с аналитиками и разработчиками будущей системы в целях выявления потребностей. Требования изменяются в зависимости от задач и условий их определения, а также постоянного уточнения на этапе заключения договора на создание системы. На момент заключения договора состав требований, их виды и свойства становятся более полными, т.е. соответствуют взглядам заказчика на создаваемую систему [3.4].

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

Рис. 3.3.  Типы трассируемости требований

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

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

• требования, которые изменяются при их формировании;

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

• связи между различными моделями процесса проектирования системы на ЖЦ программного продукта и принятые решения о необходимости изменения требований в связи с появившимися недостатками в промежуточном продукте;

• информация о согласованных атрибутах требований на разных уровнях рассмотренной схемы трассирования и сохранение ее матрице трассирования;

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

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

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

Процедура трассирования состоит в следующем:

• выбирается элемент (функция, фрагмент или некоторая часть) из матрицы трассирования требований, за которым проводится прослеживание на этапах ЖЦ;

• составляется список вопросов, по которым на каждом этапе проверяются связи при реализации требований в продукте, и если изменяется какое-то звено в цепочке требований (рис. 3.3.), то может модифицироваться процедура разработки этого элемента на последующем этапе ЖЦ;

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

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

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

• ввод более сложных отношений вместо простых связей или специфических отношений;

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

• ведение базы данных объектов трассировки и отношений между ними.

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

Характеристики качества программного обеспечения

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

Качество программного обеспечения (ПО) может быть описано большим количеством разнородных характеристик. Для разных категорий пользователей приоритетными могут быть разные характеристики. Поэтому нужен учет всей совокупности характеристик, важных для всех заинтересованных сторон. Понятие качества программы — многоплановое и может быть выражено некоторой структурированной системой характеристик, которая называется моделью качества.

В 1991 году в качестве стандартной была принята модель качества программного обеспечения, определенная международным стандартом ISO 9126. В ней оценка качества ПО основана на трехуровневом рассмотрении:

1. характеристики

2. подхарактеристики

3. метрики.

Стандарт ISO 9126 определяет 6 характеристик качества ПО:

1. функциональность (functionality),

2. надежность (reliability),

3. практичность или удобство использования (usability),

4. эффективность (efficiency),

5. сопровождаемость (maintainability),

6. переносимость или мобильность (portability).

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

Функциональность определяется следующими подхарактери­стиками:

1. Пригодность к определенной работе(suitability)

2. Точность, правильность (accuracy)

3. Способность к взаимодействию (interoperability)

4. Защищенность (security)

5. Соответствие стандартам и правилам (compliance)

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

Надежность определяется следующими подхарактеристиками:

1. Зрелость, завершенность (обратна к частоте отказов) (maturity)

2. Устойчивость к отказам (fault tolerance)

3. Способность к восстановлению работоспособности при отказах (recoverability)

4. Соответствие стандартам надежности (reliability compliance)

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

Практичность определяется следующими подхарактеристи­ками:

1. Понятность (understandability)

2. Удобство обучения (learnability)

3. Работоспособность (operability)

4. Привлекательность (attractiveness)

5. Соответствие стандартам практичности (usability compliance)

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

Подхарактеристики эффективности:

1. Временные характеристики (time behaviour)

2. Использование ресурсов (resource utilisation)

3. Соответствие стандартам эффективности (efficiency compliance)

Сопровождаемость – это свойство программного продукта быть модифицированным.

Сопровождаемость определяется следующими подхарактери­стиками:

1. Анализируемость (analyzability)

2. Изменяемость, удобство внесения изменений (changeability)

3. Риск возникновения неожиданных эффектов при внесении изменений или стабильность (stability)

4. Тестируемость, удобство проверки (testability)

5. Соответствие стандартам сопровождаемости (maintainability compliance)

Переносимость – способность программного продукта быть переносимым из одной среды в другую.

Переносимость определяется следующими подхарактеристи­ками:

1. Адаптируемость (adaptability)

2. Устанавливаемость, удобство установки (installability)

3. Способность к сосуществованию с другим ПО (coexistence)

4. Удобство замены другого ПО данным (replaceability)

5. Соответствие стандартам переносимости (portability compliance)

Принятые в 2001 году части 2 и 3 стандарта ISO 9126 определяют набор метрик качества ПО. В качестве примера таких метрик приведем следующие:

1. Полнота реализации функций. Используется для измерения пригодности.

2. Корректность реализации функций. Используется для измерения пригодности.

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

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

5. Отношение числа доступных проектных документов к указанному в их списке. Используется для измерения анализируемости.

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