Анализ требований Трассировка на элементы проектирования и тестирования

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

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

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

В таких случаях к общим типам требований необходимо добавить такие типы требований, как сценарии тестирования, диаграммы классов и диаграммы взаимодействия [9] и установить их связь с требованиями более высокого порядка. Подобную задачу можно выполнять только с использованием специальных инструментальных средств. Для примера среда разработки и управления требованиями Rational RequisitePro интегрируется со средством проектирования RationalSoftwareArchitect, что позволяет отслеживать изменение требований на уровне проектирования.

Показатели требований

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

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

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

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

Подход на основе оценки вариантов использования (UCP), является одним из множества методов оценки трудозатрат на основе требований [10]. Основываясь на данном подходе, аналитик может оценивать трудозатраты на описание варианта использования и доводить их до руководителя проекта. Трудозатраты могут быть добавлены в виде атрибута требований.

Количественная оценка вариантов использования была разработана Густавом Карнером (GustavKarner) в 1993 году как способ измерения размера программного обеспечения по количеству, размеру и сложности вариантов использования, данного программного обеспечения.

На рисунке 8 изображен процесс вычисления оценки вариантов использования.

Рисунок 8. Количественная оценка вариантов использования.

Данный процесс начинается с определения весовых коэффициентов действующих лиц, инициирующих вариант использования. Весовой коэффициент зависит от типа действующего лица (Таблица 2). Далее рассчитывается общий вес действующих лиц по формуле UAW = 1*Q1+2*Q2+3*Q3, гдеQ1,Q2,Q3 – количество вариантов использования, инициируемых простым, средним и сложным типом действующих лиц, соответственно.

Таблица 2 - Весовые коэффициенты действующих лиц

Тип	Описание	Весовой коэффициент
Простой	Внешняя система, взаимодействующая через прикладной программный интерфейс.	1
Средний	Внешняя система, взаимодействующая через протоколы, такие как TCP/IP или пользователь, взаимодействующий через интерфейс на основе командной строки.	2
Сложный	Пользователь, взаимодействующий с системой через графический пользовательский интерфейс.	3

Вторым шагом является определение весовых коэффициентов для вариантов использования. Оценка данных коэффициентов приведена в таблице 3. Под транзакциями понимается общее количество потоков событий (основных и альтернативных).

Таблица 3 - Весовые коэффициенты вариантов использования

Тип	Количество транзакций	Весовой коэффициент
Простой	1-3	5
Средний	4-7	10
Сложный	7 и более	15

Далее рассчитывается общее значение весов для всех вариантов использования (UUCW). Для этого необходимо оценить вес каждого варианта использования и сложить полученные результаты. Следующим действием складываем общий вес действующих лиц и общий вес вариантов использования, получая не усредненную количественную оценку вариантов использования UUCP = UAW+UUCW.

Далее рассчитываем влияние внешней среды EF = 1,4 – 0.03*Efactor и технического фактора TCF = 0,6 + 0,01*Tfactor, соответственно.

В приведенных выше формулах Efactor и Tfactorявляются коэффициентами, характеризующими влияние внешней среды и требований к характеристикам качества. Значения данных величин берется из специальной таблица и их можно найти в [10].

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

Трудозатраты = 28*UUCP * TCF * EF

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