Атрибуты программной системы

1.6. Дополнительные требования

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

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

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

Организация требований по классам

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

Большим преимуществом организации требований по классам, которые будут использованы в проектировании, является поддержка жесткого соответствия между требованиями, проектом и реализацией. Это главное достоинство использования объектно-ориентированного принципа. Кроме этого, классы соответствующие понятиям реального мира, как правило, повторно используются. Для многих программ выгода от использования метода организации требований по классам перевешивает все недостатки.

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

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

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

3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс (обязанности класса в CRC-карточках). Полученный документ создается в форме атрибутов и операций. Каждый известный обязательный объект класса должен быть отдельно указан как требование к классу. Например, «Гостевой пользователь книжного Internet-магазина должен быть клиентом».

События, которые должны обрабатывать объекты класса, должны быть также определены.

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

4. D-требования затем проверяются и сравниваются с С-требованиями.

5. D-требования проверяются заказчиком, и лишь затем публикуются.

Итог этих шагов подводится на рис.5.4.

 

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

 

 

Рис.5.4. Схема D-требований с использованием объектно-ориентированного стиля.

 

Приведем один из способов выбора классов предметной области для классификации требований.

1. Разработать полный набор непересекающихся (ортогональных) вариантов использования.

2. Создать диаграмму последовательности для каждого варианта использования, не забыть, при этом, отождествить все классы и объекты, которые будут взаимодействовать в сценарии диаграммы последовательности.

3. Собрать классы, использовавшиеся и выявленные в диаграммах последовательности.

4. Определить важные дополнительные классы (классы технической инфраструктуры, в том числе аспекты).

5. Распределить подробные (детальные) функциональные требования по этим классам, то есть:

1) указать каждый атрибут как отдельное требование;

2) указать каждый конкретный объект этого класса, который должен существовать;

3) указать каждую функцию, необходимую для объектов в этой классификации;

4) перечислить события, на которые должны реагировать все объекты этого класса.

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

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

 

Метрики для анализа D-требований

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

Приведем список метрик контроля качества, куда включены метрики анализа требований из стандарта IEEE 982.2 – 1988.

Метрики контроля качества детальных требований включают в себя:

1. Метрики того, насколько хорошо написаны требования:

процент однозначных детальных требований;

степень законченности (полнота);

процент неочевидных D-требований (в объектно-ориентированном стиле это измеряется процентом требований, размещенных в неправильном классе);

процент требований, которые:

- не тестируются;

- не прослеживаются;

- не отсортированы по приоритетам;

- не элементарны (можно разбить на части);

- не согласуются с остальными требованиями.

2. Метрики эффективности проверки требований:

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

3. Метрики эффективности процесса анализа требований:

- стоимость каждого D – требования;

- общая (общее затраченное время / число D - требований);

- критическая (стоимость получить еще одно);

- скорость, с которой детальные требования могут быть изменены, либо удалены, либо добавлены.

4. Метрики полноты требований:

• можно оценить после официального завершения сбора D – требований исходя из скорости, с которой требования

- изменяют;

- добавляют.

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

 

Приведем ключевые понятия, введенные в данном разделе:

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

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

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

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

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

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

 

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

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

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

 

Рис. 5.5. Процесс разработки системных требований

 

Анализ осуществимости

 

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

• Отвечает ли система общим и бизнес – целям организации – заказчика и организации разработчика?

• Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости проекта?

• Можно ли объединить систему с другими системами, которые уже эксплуатируются?

• Что произойдет с организацией, если система не будет введена в эксплуатацию?

• Какие текущие проблемы существуют в организации, и как новая система поможет их решить?

• Каким образом система будет способствовать целям бизнеса?

• Требует ли разработка системы технологии, которая до этого не использовалась в организации?

 

5.3.2. Формирование требований

 

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

Модель процесса формирования и анализа требований показана на рис. 5.6.

Процесс формирования требований проходит следующие этапы:

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

2. Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

3. Классификация требований. На этом этапе первичный набор требований преобразуется в логически связанные группы требований.

4. Разрешение противоречий. На этом этапе определяются и разрешаются противоречия всех занятых в процессе формирования требований лиц.

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

6. Проверка требований. Определяется полнота, последовательность и непротиворечивость требований.

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

Существуют разные подходы к формированию требований:

- метод, основанный на множестве опорных точек зрения,

- сценарии,

- методы структурного анализа,

- методы прототипирования.

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

 

 

Рис. 5.6. Процесс определения и анализа требований

 

Опорные точки зрения

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

Точки зрения можно трактовать:

1. Как источник информации о системных данных. В этом случае на основе таких точек строится модель создания и использования данных в системе. Метод SADT использует эту интерпретацию точек зрения.

2. Как структура представлений. Например, на основе различных точек зрения могут разрабатываться модели «сущность - связь», модели конечного автомата и т.д.

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

Вообще говоря, точку зрения можно отождествить с физическим лицом – носителем этой точки зрения.

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

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

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

Сценарии

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

В большинстве случаев сценарий включает:

1. Описание состояния системы в начале сценария.

2. Описание нормального протекания событий.

3. Описание исключительных ситуаций и способов их обработки.

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

5. Описание состояния системы после завершения сценария.

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

Сценарии событий

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

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

На рис. 5.7. показан сценарий события «Начало транзакции», которое инициируется клиентом, вставляющим свою карточку в банкомат.

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

1. Данные, поступающие в систему или исходящие из нее, представлены в эллипсах.

2. Событие представлено в виде прямоугольника с названием события внутри.

3. Управляющая информация показана стрелками в верхней части прямоугольников.

4. Внутрисистемные данные показаны справа от прямоугольников.

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

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

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

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

1. Превышение лимита времени ожидания. Клиент может не успеть ввести PIN–код в отведенное для ввода время. Карточка возвращается.

2. Недопустимая карточка. Карточка не опознается и возвращается.

3. Утраченная карточка. Карточка удерживается банкоматом.

 

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

Рис. 5.7. Диаграмма сценария для события «Начало транзакции»

 

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

 

Варианты использования

Варианты использования (use-case) - это методика формирования требований, основанная на сценариях. Они стали основной нотацией в языке объектного моделирования UML при описании объектных моделей систем. Более того, варианты использования применяются для моделирования предметной области, в анализе пригодности (процесс ICONIX), для выявления и моделирования классов, тестов и т.д.

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

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

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

Язык моделирования UML фактически является стандартом для объектно-ориентированного представления вариантов использования, применяемых при формировании требований.

 

⇐ Предыдущая891011121314151617Следующая ⇒

Поделиться: