Тестируемость (Возможность Проверки)

⇐ ПредыдущаяСтр 7 из 16Следующая ⇒

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

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

– Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.

– Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).

Треб.1: Система должна препятствовать одновременному доступу большого числа пользователей.

Какое количество здесь имеется в виду под «большим числом» - 10, 100 или 1000?

Ясность (Краткость, Сжатость, Простота, Точность)

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

Треб.1: Иногда пользователь будет вводить Airport Code (Код Аэропорта), который система будет распознавать. Но иногда код можно заменить близлежащим городом, и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города.

Это предложение может быть заменено на более простое:

Треб.1: Система должна идентифицировать аэропорт на основании Airport Code (Кода Аэропорта) или City Name (Названия Города).

Корректность

Если требование содержит факты, эти факты должны быть достоверны:

Треб.1: Цены на аренду машин должны включать все соответствующие налоги (включая налог штата - 6%)

Налог зависит от штата, так что представленная цифра в 6 % - некорректна.

Понятность

Требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо «будет», «обязан» или «может».

Реалистичность (Правдоподобность, Выполнимость)

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

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

Это требование может быть нереальным из-за короткого периода времени разработки.

Независимость

Чтобы понять требование, не нужно знать какое-либо другое требование.

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

Треб.2: Он должен быть отсортирован по ценам.

Слово «Он» во втором предложении относится к предыдущему требованию. И если порядок требований изменить, это требование будет непонятно.

Элементарность

Требование должно содержать отдельный трассируемый элемент (для которого возможно отслеживание связи):

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

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

Необходимость

В требовании нет необходимости, если:

– ни одному заинтересованному лицу требование не нужно;

– удаление требования не повлияет на систему.

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

Треб.1: Все требования, указанные в документе Концепции должны быть реализованы и протестированы.

Независимость от Реализации (Абстрактность)

Требования не должны содержать ненужной информации о дизайне и реализации системы:

Треб.1: Информация должна храниться в текстовом файле.

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

Постоянство

Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные.

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

Треб.1: Дата должна отображаться в формате мм/дд/гггг.

Треб.1: Дата должна отображаться в формате дд/мм/гггг.

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

Треб.1: Для пользователей США дата должна отображаться в формате мм/дд/гггг.

Треб.2: Для пользователей Франции дата должна отображаться в формате дд/мм/гггг.

Немногословность

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

Треб.1: Для удобства ввода даты рейса в системе должен быть доступен календарь.

Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.

Первое требование (относящееся только к дате рейса) является частью второго требования (относящееся к любой дате, вводимой пользователем).

Завершенность

Требование должно быть описано для всех возможных условий.

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

6.1.5.1 Пирамида требований

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

– потребности заинтересованного лица: требование от заинтересованного лица;

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

– сценарий Использования (Use Case): описание поведения системы в терминах последовательности действий;

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

– тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов;

– сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования.

Эти типы требований могут быть представлены в виде пирамиды, как показано на Рисунке 1.1.

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

Например, потребность может быть следующей: «Данные должны быть неизменными». Функциональная особенность этого требования будет: «Система должна использовать реляционную базу данных». На уровне дополнительных требований, требование еще более точное: «Система должна использовать базу данных Oracle 9i».

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

Например, документ Концепция («Vision») содержит высокоуровневые требования (особенности), а низшие уровни пирамиды представляют требования на более детальном уровне. У вышестоящих заинтересованных лиц (таких, как вице-президент) нет времени читать 200 страниц детально описанных требований. Но можно надеяться, что они смогут прочитать 12 страниц Концепции.

Рисунок. Пирамида требований.

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

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

7. Управление требованиями

7.1.1. Процесс управления требованиями

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

– формирование плана управления требованиями;

– сбор требований;

– разработка документа Концепции (Vision);

– создание сценариев использования (Use Cases);

– дополнительная спецификация;

– создание тестовых сценариев (Test Cases) из сценариев использования (Use Cases);

– создание тестовых сценариев (Test Cases) из дополнительной спецификации;

– проектирование системы.

Первый шаг (план управления требованиями) определяет пирамиду требований. На каждом из последующих семи шагов строится один элемент пирамиды. Таблица 1.1. описывает, какие типы требований и какая документация создаются на каждом шаге. Как Вы видите, процесс проходит через пирамиду сверху вниз и слева направо.

Таблица 1.1. Требования и документы, созданные на каждом шаге.

Шаг	Тип требований	Документы
Сбор требований	Потребности заинтересованного лица	Запросы заинтересованного лица
Разработка документа Концепции (Vision)	Функциональные особенности	Концепция
Создание сценариев использования (Use cases)	Сценарии использования, алгоритмы	Спецификация Сценариев Использования
Дополнительная спецификация	Дополнительные требования	Дополнительная спецификация
Создание тестовых сценариев (test cases) из сценариев использования (use cases)	Тестовые сценарии	Тестовые сценарии
Создание тестовых сценариев (test cases) из дополнительной спецификации	Тестовые сценарии	Тестовые сценарии
Проектирование системы	Диаграммы классов, диаграммы взаимодействий	UML-диаграммы

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

7.1.2. Извлечение требований

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

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

– цели;

– знания предметной области;

– заинтересованных лиц;

– операционное окружение;

– организационную среду.

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

В качестве заинтересованного лица можно рассматривать:

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

– поставщиков знаний в систему (эксперты предметной области, авторы документов, которые были использованы для сбора требований, собственники веб-сайтов, ссылки на которые были предоставлены);

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

– обслуживающий персонал, вовлеченный в управление, настройку и сопровождение системы (хостинговая компания, справочная служба).

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

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

– недопонимание между аналитиком и заинтересованными лицами;

– упущение некоторых аспектов, изначально кажущихся второстепенными;

– неоднозначность или некорректность интерпретации информации, полученной от заинтересованных лиц.

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

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

– использование сценариев – моделирование ситуаций для сбора пользовательских требований, определяющих ответы на вопросы «что если» и «как это делается» в отношении бизнес-процессов, реализуемых пользователями;

– создание прототипов – инструмент для постепенного перехода от «бумажных» моделей до пилотных подсистем, реализуемых как самостоятельные проекты или бета-версий продуктов, при этом прототипы могут постепенно трансформироваться в результаты проекта и использоваться для проверки и утверждения требований;

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

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

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

7.1.3. Анализ программных требований

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

Анализ требований включает:

– обнаружение и разрешение конфликтов между требованиями;

– определение границ задачи, решаемой создаваемым программным обеспечением;

– детализация системных требований для установления программных требований.

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

Требования могут классифицироваться по следующим параметрам:

– функциональные и нефункциональные требования;

– внутренние (с другими требованиями) или внешние зависимости;

– требования к процессу или продукту;

– приоритет требований;

– содержание требований в отношении конкретных подсистем создаваемого программного обеспечения;

– изменяемость/стабильность требований.

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

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

Среди факторов, которые влияют на выбор модели, метода и детализации её представления, степени связанности с программным кодом и другими вопросами:

– природа проблемы (проблемной области);

– экспертиза и опыт инженеров;

– требования заказчика к процессу;

– доступность методов и инструментов;

– внутрикорпоративные стандарты и регламенты;

– культура разработки.

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

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

7.1.4. Документирование требований

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

– определение системы;

– системные требования;

– программные требования.

7.1.5. Проверка требований (верификация и аттестация)

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

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

Обзор требований

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

Прототипирование

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

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

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

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

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

Аттестация

Аттестация модели связана с вопросами обеспечения приемлемого качества продукта. Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны пользователей/заказчика. В то же время, проверка и аттестация модели, например, объектно-ориентированного представления бизнес-сущностей и связей между ними может быть проведена с той или иной степенью использования формальных методов. Это – другая сторона утверждения модели.

Приемочные тесты

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

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

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

7.1.6. Измерение программных требований

Для обеспечения качества программных требований полезно иметь методы, определяющие «объем» требований для создаваемого программного продукта. Такая оценка полезна для исследования предполагаемых изменений в требованиях, оценки стоимостных характеристик разработки и поддержки программной системы, опосредовано – оценки продуктивности разработки и эффективности поддержки на этапах реализации требований и внесения изменений и т.п. [7]

⇐ Предыдущая 2 3 4 5 678 9 10 11 Следующая ⇒