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

4 Языки описания требований

11

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

Недостаточный контроль версий

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

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

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

4. Языки описания требований

4.1. Problem Statement Language (PSL)

PSL был частью первого большого проекта по определению требований на формальном языке и их автоматического анализа. Операторы PSL описывают структуру системы, потоки данных, структуры данных, поведение системы и управление проектов. Его синтаксис и семантика базируется на подходе «сущность-связь». Безусловно, язык поддерживает и комментарии на естественном языке. Пример описания на PSL приведен ниже.

PROCESS: process-order

/* authors T.H. Tse and L. Pong */ DESCRIPTION:

this process captures the details of a valid order, calculates the amounts, discount and net-amount, and prepares an invoice; GENERATES: net-invoice;

RECEIVES: valid-order, discount-rate;

SUBPARTS ARE: prepare-gross, compute-discount; PART OF: process-sales;

DERIVES: amount

USING: price, quantity-ordered; DERIVES: total-amount

USING: amount; DERIVES: net-amount

USING: total-amount, discount-rate; PROCEDURE:

1.multiply price and quantity-ordered to obtain amount;

2.update stock record accordingly;

3.add amounts to obtain total-amount;

4.multiply total-amount by discount-rate to obtain net-amount;

5.update customer record accordingly;

6.generate invoice for net-amount;

HAPPENS: 1 TIMES-PER valid-order;

TRIGGERED BY: valid-order-event;

TERMINATION CAUSES: invoice-event;

SECURITY IS: account-clerk-only;

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

4 Языки описания требований

12

4.2. Structured Analysis and Design Technique (SADT)

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

Рис. 1. Пример спецификации на SADT

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

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

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

4.3. EDDA

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

4 Языки описания требований

13

process process-sales (interfaces input I1 = order: orders

control C1 = discount-policy: rules output O1 = net-Invoice: invoices); type

orders = customer-info sequ product-info internal data

product-info: product-array customer-info: customer-records valid-order: orders

bad-order: orders gross-invoice: invoices discount-rate: rates structure

xfork order = validOrder + bad-order subprocesses

process check-order (interfaces input I1 = order: orders

output O1 = checked-order: orders); forward

process determine-discount-rate (interfaces input I1 = customer-info: customer-records control C1 = discount-policy: rules

output O1 = discount-rate: rates); forward

process prepare-gross (interfaces input I1 = product-info: product-array output O1 = gross-invoice: invoices); forward

process compute-discount (interfaces input I1 = discount-rate: rates

I2 = gross-invoice: invoices

output O1 = net-invoice: invoices); forward

begin

process check-order (I1 = order, O1 = checked-order); process determine-discount-rate (I1 = customer-info, C1 = discount-policy, O1 = discount-rate) .

process prepare-gross (I1 = product-info, O1 = gross-invoice);

process compute-discount (I1 = discount-rate, I2 = gross-invoice, O1 = net-invoice);

end

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

У EDDA есть три больших недостатка: (a) она завязана на SADT и не может быть связана с другими методологиями (b) не все из 40 примитивов имеют свой математический эквивалент (а если и имеют, то большое количество новых концепций и нотаций лишь запутывают пользователя) (c) даже если пользователь и знаком с SADT, ему все равно придется выучить полностью новый символический язык.

4.4. Systematic Activity Modelling Method (SAMM)

Язык SAMM представляет из себя комбинацию графики и понятий из теории графов, с той целью, чтобы результат можно было обрабатывать автоматически. Спецификация состоит из дерева контекста (своего рода «оглавление» для диаграмм действий (activity) в иерархической форме). Пример диаграммы действий приведен на рис. 2. Она определяет отношения между действиями и потоками данных. Хотя она и похожа на одну из диаграмм SADT, она не поддерживает контроль и механизмы.

4 Языки описания требований

14

Рис. 2. Пример диаграммы действий на SAMM

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

4.5. Higher Order Software (HOS)

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

4 Языки описания требований

15

Рис. 3. Пример спецификации на HOS

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

4.6. Requirements Statement Language (RSL)

RSL определяет требования к программе в терминах «путей обработки» (processing paths), каждый из которых представляет из себя последовательность шагов, соединяющих прибытие входного сообщения и генерацию соответствующего выходного сообщения. Каждый шаг называется «альфа».

В графической форме это представляется как «сети требований» или попросту R-сети (см. рис. 4). Описание любого «альфа» может заменено несколькими «альфа» более низкого уровня. В отличии от SADT разработчики RSL предпочли вариант, когда окончательная документация появляется только на одном слое вместо иерархии R-сетей.

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

5 Разработка требований к пользовательскому интерфейсу

16

Рис. 4. Пример R-сети

5. Разработка требований к пользовательскому интерфейсу

Определить состав конечных пользователей

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

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

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

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

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

5 Разработка требований к пользовательскому интерфейсу

17

первого прототипа интерфейса пользователя.

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

Создать простой интерфейс пользователя

Прототип должен строиться максимально просто. Задача этого шага — показать целый ряд возможных вариантов до того, как начать углубляться в какой-либо из них. Команда разработчиков должна предоставить пользователю некую «болванку»7 продукта и ничего сверх того. Например, в случае разработки прототипа формата отчета, даже и не следует создавать прототип интерфейса, который этот отчет печатает. Разработчики попросту должны придумать отчет в обычном текстовом процессоре и сказать пользователям: «Вот это вы получите, когда выберете кнопку ‘Печать’».

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

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

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

Для обратной связи по возможности использовать бумагу

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

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

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

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

Исправлять прототип, пока пользователи не будут удовлетворены

Первая версия прототипа редко удовлетворяет ожидания пользователей. Разработчики должны быть готовы к тому, что комментарии пользователей вынудят их вносить изменения в прототип. Они должны объяснить пользователям, что работа над прототипом все время продолжается и что они ждут их замечаний. Если пользователь в тупике или полагает, что программу будет тяжело использовать — это не его вина, это означает, что как раз на этом этапе эту проблему следует исправить.

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

Подготовить полностью расширенный прототип и определить его как основную спецификацию

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

7В оригинале — look and feel.

Список литературы

18

Список литературы

[1]Chrissis, M. B. CMMI: Guidelines for Process Integration and Product Improvement / M. B. Chrissis, M. Konrad, S. Shrum. — Addison Wesley, 2003. — 688 pp.

[2]McConnell, S. Software Project Survival Guide / S. McConnell. — Microsoft Press, 1997. — 304 pp.

[3]Tse, T. H. An examination of requirements specification languages / T. H. Tse, L. Pong // http://www.cs.hku.hk/research/techreps/document/TR-89-09.pdf. — 2005.

[4]Wiegers, K. E. Karl Wiegers describes 10 requirements traps to avoid / K. E. Wiegers // Software Testing & Quality Engineering. — 2000. — January / February.

Список литературы

19

[1], [2], [3], [4]