Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Характеристика областей знаний SWEBOK



В ядре знаний SWEBOK определено 10 областей знаний. Среди них выделим базовые области, методы и средства которых соответствуют процессам разработки ПС:

1. Разработка требований;

2. Проектирование;

3. Конструирование;

4. Тестирование;

5. Сопровождение.

Эти области знаний по своим базовым концепциям и методам, определенным в SWEBOK, соответствуют задачам и выполняемым действиям следующих процессов разработки ЖЦ стандарта ISO/IEC - 12207:

1. Разработка требований;

2. Проектирование;

3. Кодирование;

4. Тестирование;

5. Интеграция;

6. Интеграционное тестирование;

7. Эксплуатация;

8. Сопровождение.

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

В табл. 2.3. приведен сопоставительный перечень основных областей SWEBOK, их задач и соответственно задач ЖЦ стандарта. При этом процессы приобретения и поставки из состава основных процессов исключены, поскольку они не относятся к процессам разработки ПО.

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

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

· управление конфигурацией,

· управление инженерией ПО (или управление проектом),

· процесс инженерии ПО (инфраструктура процесса разработки),

· методы и средства инженерии;

· инженерия качества (управление качеством).

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

 

Таблица 2.3. Задачи основных областей SWEBOK и процессов ЖЦ

Область SWEBOK Задачи области SWEBOK Задачи процессов ЖЦ стандарта ISO/IEC 12207
Разработка требований Инженерия требований Выявление требований Анализ требований Спецификация требований Проверка требований Управление требованиями Подготовка заказа Выявление требований Анализ требований к системе Анализ требований к ПО Описание документа
Проектирование ПО Разработка архитектуры ПО Нотация Анализ качества проектирования Использование стратегии и методов проектирования Проектирование: · архитектуры системы · архитектуры ПО · ПО Кодирование ПО Тестирование ПО
Конструирование ПО Снижение сложности Предупреждение отклонений от стиля Структуризация системы для проверок Использование внешних стандартов Конструирование структуры системы Кодирование элементов структуры и ПО Интеграция элементов Применение стандартов программной инженерии
Тестирование ПО Тестирование элементов и системы Тестирование спецификаций, структуры и системы на наборах данных Метрическое измерение тестирования Планирование и оценка качества Тестирование ПО Интеграционное тестирование Квалификационное тестирование Интеграция системы Системное тестирование Установка и приемка ПО
Сопровождение ПО Запуск ПО Нахождение ошибок, планирование исправлений Внесение изменений Инсталляция ПО Анализ проблем и модификация Реализация модификаций Анализ сопровождения Миграция, удаление ПО
Эксплуатация системы Методы обеспечения эксплуатации системы Внедрение процесса Функциональное тестирование Эксплуатация системы Поддержка пользователя

 

В табл. 2.4 приведен перечень областей ядра SWEBOK и соответствующие задачи вспомогательных (организационных и дополнительных) процессов ЖЦ стандарта ISO/IEC 12207.

 

Таблица 2.4. Задачи областей SWEBOK и вспомогательных процессов ЖЦ

Области SWEBOK Задачи областей SWEBOK Задачи процессов стандарта 12207
Управление конфигурацией Процесс управления конфигурацией. Идентификация элементов. Учет статуса, аудит. Контроль конфигурации. Управление версиями. Определение и контроль конфигурации. Учет состояния и оценка конфигурации. Управление реализацией и поставкой версии.
Управление проектом Организационное управление. Планирование проектом. Управления процессами и проектом. Инженерия измерения ПО. Управление риском. Инициация и определение области применения. Планирование. Выполнение и контроль. Анализ управления проектом: · технический анализ; · аудит (ревизия).
Управление качеством Концепция качества ПО. Определение и планирование качеством. Верификация и валидация. Измерение в анализе качества ПО. Внедрение процесса. Обеспечение производства и качества. Процесс верификации и валидации. Анализ и оценивание качества.
Методы и средства инженерии Методы инженерии. Инструменты инженерии. Процесс усовершенствования: · определение процесса; · оценка процесса; - улучшение процесса.
Процесс инженерии ПО Инфраструктура процесса. Определение процесса. Измерение процесса. Анализ проекта. Выполнение изменений. Оценки стоимости и затрат. Создание инфраструктуры. Сопровождение инфраструктуры. Внедрение процесса. Завершение.

Сопоставление концепций, методов и средств областей SWEBOK с задачами процессов ЖЦ позволяет регламентировать поиск, обнаружение ошибок и внесение изменений в требования к системе.

 

Контрольные вопросы и задания

1. Охарактеризуйте понятие модели ЖЦ и назовите основные виды моделей ЖЦ.

2. Опишите каскадную и спиральную модели ЖЦ?

3. Дайте характеристику эволюционной модели ЖЦ.

4. Назовите другие виды моделей ЖЦ.

5. Какие общие черты имеют инкрементная и эволюционная модели?

6. Перечислите основные процессы ЖЦ стандарта.

7. Как построить новую модель ЖЦ на основе стандарта?

8. Перечислите процессы категории организационных процессов ЖЦ стандарта.

9. Назовите задачи и методы тестирования ПС.

10. Назовите основные задачи управления качеством и проектом.

11. Проведите сравнительный анализ модели процессов ЖЦ стандарта 12207 и областей ядра знаний SWEBOK.

12. Определите основные цели областей SWEBOK и процессов ЖЦ.

 

 

Лекция 3: Методы определения требований в программной инженерии

Содержание

· 3.1. Общие подходы к определению требований

o 3.1.1. Классификация требований

o 3.1.2. Анализ и сбор требований

o 3.1.3. Инженерия требований

o 3.1.4. Фиксация требований

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

· 3.2. Объектно-ориентированная инженерия требований

o 3.2.1. Сценарный подход

o 3.2.2. Описание требований прецедентами

· Контрольные вопросы и задания

 

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

Рис. 3.1. Основные разделы разработки требований

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

Основные инструменты инженерии требований - UML и RUP, согласно которым требования определяются и уточняются с помощью вариантов использования use case, которые преобразуются к проектным решениям и к архитектуре системы.

Далее рассмотрим общие, практические и объектно-ориентированные подходы к разработке требований к системе, учитывая приведенные разделы на рис. 3.1.

 

3.1. Общие подходы к определению требований

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

3.1.1. Классификация требований

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

Согласно ряду публикаций формирование требований к ПО рассматривается как некоторая деловая игра, во время которой выявляются интересы заинтересованных в разработке ПО лиц, правила реализации этих интересов в конкретном ПО. При этом высказываются разного рода претензии и ограничения на свойства и способы обеспечения требований для получения конечного результата - программного продукта. Кроме того, нет формализованных методов сбора и описания требований, а также отсутствует общепринятое определение самого понятия - требование. Приведем некоторые из них [3.1-3.3].

Требования - это утверждения о функциях и ограничениях системы.

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

Требования - это спецификация того, что и как должно быть реализовано.

Согласно международному глоссарию по терминологии требования включают описание:

1. условий или возможностей, необходимых пользователю для решения поставленных проблем или достижения целей;

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

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

4. документированное представление условий, возможностей ограничений среды на проектирование системы.

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

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

Требования пользователей (user requirements) основываются на целях и задачах, которые пользователям позволит решать будущая система. К способам представления этого вида требований относятся варианты использования, сценарии, прецеденты, таблицы "событие-отклик" и т.п.

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

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

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

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

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

· конфиденциальность, безопасность и защиту данных;

· отказоустойчивость;

· одновременность доступа к системе пользователей;

· время ожидания ответа при обращении к системе (производительность);

· состав выполняемых функций системы (запуск, скорость реакции и др.);

· стандартные положения к формулировке требований.

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

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

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

К выходному продукту предъявляются нефункциональные требования:

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

· к производительности (пропускная способность, время реакции и др.);

· к надежности выполнения (ошибки, интенсивность отказов и др.);

· к интерфейсным внешним атрибутам, с которыми взаимодействует система.

Процесс описания функциональных и нефункциональных требований, а также требований к характеристикам качества с учетом стандарта ISO/IEC 9126-94 уточняется при разработке архитектуры системы. При спецификации требований важной является проблема стандартизации терминологии для нескольких классов ПрО (например, информационные технологии, системы реального времени и др.). Имея стандартизированный понятийный базис для большинства ПрО, можно достигнуть единого с заказчиком понимания терминов, которые используются при описании концептуальной модели и спецификации требований к системе.

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

С помощью спецификаций системных и нефункциональных требований задаются принципы взаимодействия проектируемой системы с другими средами, платформами и общесистемным обеспечением (БД, СУБД, сеть и др.).

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

3.1.2. Анализ и сбор требований

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

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

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

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

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

· спектра проблем ПрО, при решении которых будут реализованы услуги системы;

· функциональное содержание услуг;

· операционную среду работы системы.

В обсуждении требований на систему принимают участие:

· представители заказчика из нескольких профессиональных групп;

· операторы, обслуживающие систему;

· аналитики и разработчики будущей системы.

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

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

· неочевидные, не одинаково важные, которые брались из устаревших источников и документов заказчика;

· разные типы, которые соответствуют разным уровням детализации проекта и требующие применения методов управления ими;

· постоянно изменяемые, развиваемые и уточняемые;

· с уникальными свойствами или значениями;

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

Разработчики требований должны обладать определенными знаниями в данной предметной области и уметь провести:

· анализ проблем предметной области, потребностей заказчика и пользователей системы,

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

· внесение изменений в отдельные элементы требований.

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

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

Существующие стандарты (ГОСТ 34.601-90 и ГОСТ 34.201-89) на разработку требований к системе и документам фиксируют результаты создания программного, технического, организационного и др. видов обеспечения автоматизированных систем на этапах ЖЦ.

Сбор требований.Источниками сведений для формирования требований могут быть:

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

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

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

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

Методы сбора требований следующие:

· интервью с представителями интересов заказчика системы;

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

· примеры возможных вариантов выполнения функций, ролей ответственных лиц, запускающих эти варианты или взаимодействующих с системой при ее развертывании и функционировании.

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

При определении требований, относящихся к внешним и внутренним характеристикам качества, выбираются методы их достижения на процессах ЖЦ. Внутренние характеристики предназначены для достижения необходимых внешних показателей качества и применяются при оценке промежуточных (рабочих) продуктов ПС на процессах ЖЦ.

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

 

3.1.3. Инженерия требований

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

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

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

Качество и процесс улучшения требований - это процесс проверки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на процессах ЖЦ.

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

Основные задачи управления требованиями это:

· разработка атрибутов требований,

· управление вариантами требований,

· управление рисками, возникающими при неточном определении требований,

· контроль статуса требований, измерение усилий при формировании требований;

· реализация требований на этапах ЖЦ.

Разработка и управление требованиями связана с другими областями знаний (рис. 3.2.): проектирование, интеграция, управление качеством, версиями, рисками и др. Кроме того, приведены основные задачи разработки требований: спецификация и утверждение, формирование проектных решений.


Рис. 3.2. Разработка, управление требованиями и связь с задачами SWEBOK

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

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

 

3.1.4. Фиксация требований

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

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

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

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

 

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 


Поделиться:



Последнее изменение этой страницы: 2019-03-31; Просмотров: 1030; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.1 с.)
Главная | Случайная страница | Обратная связь