Добавлен: 15.11.2018
Просмотров: 2187
Скачиваний: 15
Лабораторная работа N1
Описание требований в контексте модели прецедентов
Задание. Описать прецеденты в текстовом формате для тематики курсового проекта. Один прецедент описать в развернутом виде и 1-2 прецедента – в сжатом.
Обосновать выбор прецедентов.
Сведения из теории
В этой работе описываются категории требований в контексте модели FURPS+.
Требования (requirements) — это возможности или условия, которым должна соответствовать система или проект. Основная задача этапа определения требований — найти, обсудить и зафиксировать, что действительно требуется от системы в форме, понятной и клиентам и членам команды разработчиков.
В рамках унифицированного процесса провозглашается ряд идей, к числу которых относится управление требованиями. Это не означает необходимости окончательного определения и стабилизации требований на первой фазе проекта. Наоборот, с учетом постоянно меняющихся требований заказчиков и руководителей проекта предлагается "систематизированный подход к поиску, документированию, организации к отслеживанию изменчивых требований к системе". То есть к формулировке требований нужно относиться очень ответственно. Обратите внимание на слово "изменчивые" в предыдущем предложении. Изменение требований считается главным "двигателем" прогресса. Отметим также слово "поиск". Предполагается, что требования должны постоянно корректироваться в процессе описания прецедентов и специальных семинаров.
На рис. 1 показаны результаты исследования факторов риска для программных проектов. Согласно этим исследованиям, 37% риска связано с требованиями, следовательно, удельный вес проблем с требованиями среди общих проблем программных проектов очень высок. Поэтому очень важно грамотно организовать управление требованиями. В рамках итеративного процесса изменение требований и обратная связь рассматриваются как главные «двигатели» прогресса.
Типы требований
В рамках UP, согласно модели FURPS+, требования делятся на следующие категории.
Рис. 1. Факторы риска для программных проектов
Функциональные требования - свойства, возможности, безопасность.
Удобство - человеческий фактор, справочная система, документация.
Надежность - частота сбоев, возможность восстановления и предсказуемость
Производительность - время отклика, точность, доступность, использование
Возможность поддержки - адаптивность, возможность поддели, соответствие международным стандартам, возможность конфигурирования
Символ "+" в названии FURPS+ означает дополнительные (не определяющие) факторы, к которым относятся следующие.
Реализация - требования к ресурсам, языки и средства, аппаратное обеспечение.
Интерфейс - ограничения, накладываемые необходимостью взаимодействия с внешними системами.
Операции - управление системой и ее параметры.
Юридические вопросы - авторское право и т.п.
Категории FURPS+ полезно использовать при формулировке требований, чтобы не упустить важные аспекты жизнедеятельности системы.
Некоторые из этих требований (удобство, надежность, производительность и возможность поддержки) называются атрибутами качества (quality attributes). Обычно требования делят на две большие категории: функциональные (относящиеся к поведению) и нефункциональные (все остальные).
Функциональные требования исследуются и формулируются в процессе разработки модели прецедентов, которая будет описана в следующей главе, а также в процессе осмысления видения системы. Остальные требования формулируются при более детальном описании прецедентов или в дополнительной спецификации. Требования высокого уровня фиксируются в документе "Видение". Затем они уточняются и конкретизируются в последующих документах. В словаре терминов разъясняются термины, фигурирующие при описании требований. В рамках UP в этом словаре должно содержаться понятие "словарь данных", в котором описываются требования к данным, а именно правила верификации, допустимые значения и т.п. Механизм выяснения требований обеспечивает прототипирование.
Как будет видно дальше, требования к качеству оказывают существенное влияние на архитектуру системы. Например, требования высокой производительности или надежности влияют на выбор программного обеспечения и аппаратных средств, а также на конфигурацию системы. Наиболее важным "лейтмотивом" при разработке программных систем является необходимость адаптивности с целью отслеживания быстро изменяющихся функциональных требований.
Описание прецедентов — повествовательных историй об использовании системы — отличный метод осмысления и формулировки требований.
Задачи и описания
У потребителей и конечных пользователей есть свои задачи (которые в контексте UP называют потребностями), решение которых должна обеспечить компьютерная система. Эти задачи могут варьироваться от регистрации торговых операций до оценивания объемов добычи нефти из перспективных месторождений. Существует несколько способов выделения этих задач или системных требований. Наилучшие из них достаточно просты и доступны, поскольку это облегчает участие конечных пользователей в определении требований к системе. А участие в этом процессе потребителей снижает риск провала проекта.
Прецеденты — это механизм упрощения этапа формулировки требований для всех заинтересованных лиц. По существу это рассказы об использовании системы в процессе решения поставленных задач. Вот пример сжатого формата описания прецедента.
Обработка продажи (process sale). Покупатель подходит к кассе с выбранными товарами. Кассир с помощью POS-системы регистрирует каждый товар. Система отображает информацию о каждом наименовании, товара и вычисляет общую сумму. Покупатель вводит требуемую информацию; система ее верифицирует и регистрирует. Система выполняет инвентаризацию. Покупатель получает товарный чек и покидает магазин с покупками.
Зачастую прецеденты нужно продумывать гораздо детальнее. Но основная идея состоит в исследовании и формулировке функциональных требований путем написания историй "из жизни системы". Эти истории помогают сформулировать различные задачи и представляют собой сценарии использования системы. На первый взгляд, описать прецеденты не сложно, хотя зачастую достаточно трудно определить, что требуется от системы и описать это на нужном уровне детализации.
О прецедентах написано достаточно много. Но все равно существует опасность, что умные творческие люди могут слишком усложнить изначально простую идею. Зачастую начинающие специалисты по описанию прецедентов слишком увлекаются созданием диаграмм прецедентов, описанием их взаимосвязей, составлением пакетов прецедентов, рассмотрением необязательных атрибутов и т.д., а не написанием историй. Сила механизма прецедентов состоит в возможности масштабировать уровень сложности и формальности описания в зависимости от реальных потребностей.
Прецеденты и ощутимый результат
Сначала введем некоторые неформальные определения. Исполнителем (actor) будем называть сущность, обладающую поведением, например, человека (идентифицируемого по роли), компьютерную систему или организацию, например кассира.
Сценарий (scenario)— это специальная последовательность действий или взаимодействий между исполнителями и системой. Его иногда также называют экземпляром прецедента (use case instance). Это один конкретный сценарий использования системы либо один проход прецедента, например, сценарий успешной покупки товаров за наличный расчет, либо сценарий неудачного завершения покупки из-за прерванной транзакции по обработке данных кредитной карточки.
Неформально, прецедент (use case) — это набор взаимосвязанных успешных и неудачных сценариев, описывающий использование системы исполнителем для решения одной из задач. Например, рассмотрим свободный формат прецедента, включающего некоторые альтернативные сценарии.
Возврат товара (Handle Returns)
Основной успешный сценарий. Покупатель подходит к кассе с товарами, подлежащими возврату. Кассир использует POS-систему для регистрации каждого возвращаемого товара...
Альтернативные сценарии. Если в авторизации кредитной карточки отказано, кассир информирует об этом покупателя и предлагает ему другой способ оплаты покупки.
Если идентификатор товара в системе не обнаружен, система уведомляет об этом кассира и предлагает ему вручную ввести идентификационный код (возможно, штрих-код поврежден и его сложно считать).
Если у системы возникают сложности при коммуникации с внешней системой вычисления налога,...
Несколько другое, но подобное определение прецедента приводится в RUP.
Прецедент — это набор сценариев использования, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой для достижения ощутимого для конкретного исполнителя результата.
Фраза "ощутимый результат" несколько туманна, но очень важна, поскольку она указывает на то, что поведение системы должно быть ощутимо для пользователя.
Основное внимание при описании прецедента нужно сконцентрировать на вопросе: "Как использование системы обеспечивает ощутимый для пользователя результат или решает его задачу?", а не на обдумывании системных требований в терминах свойств или функций.
На первый взгляд, требование обеспечения ощутимого результата может показаться неочевидным. Однако в сфере программного обеспечения известно множество неудачных проектов, которые провалились из-за невыполнения реальных задач пользователей. К такому отрицательному результату может при вести подход к описанию системных требований в виде списка свойств и функций системы, поскольку он не заставляет заинтересованных лиц рассматривать требования в более широком контексте достижения некоторого ощутимого результата или некоторой цели. В отличие от этого подхода, в контексте прецедентов свойства и функции системы ориентированы на достижение цели.
В этом состоит основная идея, сформулированная Якобсоном относительно прецедентов: требования должны быть направлены на получение ощутимого результата и достижения целей.
Прецеденты и функциональные требования
Прецеденты, в основном, это функциональные требования, указывающие на то, что должна делать система. В контексте типов требований, определяемых моделью FURPS+, основное внимание уделяется функциональным требованиям. Однако остальные типы требований тоже могут быть связаны с прецедентами. В рамках UP и большинства других современных методов прецеденты являются основным механизмом, рекомендуемым для их определения и исследования. Прецеденты определяют пожелания или соглашения относительно поведения системы.
Итак, прецеденты — это требования (хотя и не все требования). Некоторые считают требованиями только список функций и свойств типа "система должна...". На самом деле это не так. Ключевая идея использования прецедентов как раз и состоит (обычно) в снижении роли списка требований в старом понимании этого слова. Теперь в качестве функциональных требований выступают сами прецеденты.
Описания прецедентов — это текстовые документы, а не диаграммы. Моделирование прецедентов — это процесс написания текста, а не рисования. Однако для иллюстрации имен прецедентов и исполнителей, а также их взаимоотношений в UML определены обозначения для диаграммы прецедентов.
Типы и форматы прецедентов
Прецеденты типа "черный ящик" и системные обязанности
Прецеденты типа "черный ящик" (black-box use cases) — это самый типичный и рекомендуемый тип прецедентов. Они не описывают внутреннюю работу системы, ее компоненты или дизайн. Наоборот, системе вменяются некоторые обязанности (responsibilities). Этот метафорический термин широко применяется в объектно-ориентированном проектировании: программные элементы имеют обязанности и взаимодействуют с другими элементами со своими обязанностями. Определяя обязанности системы через прецеденты типа "черный ящик", можно указать, что должна делать система (функциональные требования), не расписывая, как это делать (не выполняя проектирование). Вообще, термины "анализ" и "проектирование" зачастую сводятся к вопросам "что" и "как". Это важные вопросы в хорошей программкой разработке. В процессе анализа требований нужно избегать принятия решений "как", а описывать лишь внешнее поведение системы как черного ящика. Позднее, на этапе проектирования, создается решение, удовлетворяющее разработанной спецификации.
|
Стиль черного ящика |
Другой стиль |
|
Система регистрирует покупку
|
Система записывает сведения о покупке в базу данных. или, еще хуже Система генерирует оператор SQL INSERT для данной продажи... |
Степень формализации
Прецеденты описываются в различных форматах, в зависимости от потребностей. Помимо типов "черного ящика" и "белого ящика", выделяют несколько степеней формализации описания прецедентов.
• Сжатый — аннотация в виде одного абзаца. Обычно она описывает только главный успешный сценарий. Пример такого описания приведен выше для прецедента Оформление продажи (Process Sale).
• Свободный — неформальный стиль описания. Описание прецедента занимает несколько абзацев и охватывает различные сценарии. Примером такого описания является рассмотренный выше прецедент Возврат товара.
• Развернутый — наиболее подробный стиль описания. При таком подходе детально описываются все шаги и варианты развития сценария, а также предусловия и результаты. Рассмотрим пример развернутого описания прецедента для системы Алтын.
Пример развернутого описания прецедента
Оформление продажи
Развернутые описания прецедентов структурированы и содержат большое количество деталей. Их полезно использовать для углубления понимания целей, задач и требований. Для примера POS-системы Алтын такие описания можно обсуждать на семинарах по определению требований на начальной стадии проекта вместе с системным аналитиком, экспертами предметной области и разработчиками.
Формат usecases.org
Для развернутого описания прецедентов существуют различные шаблоны форматирования. Однако чаще всего используется шаблон, приведенный на Web-узле www.usecases.org. Этот стиль проиллюстрирован в следующем примере.
Этот пример детального описания прецедента относится к рассматриваемой в данной книге системе Алтын и отражает множество типичных элементов и вопросов.
Прецедент П1. Оформление продажи
Основной исполнитель. Кассир.
Заинтересованные лица и их требования
- Кассир. Хочет точно и быстро ввести данные, не допуская ошибок в платеже, поскольку недостача вычитается из его зарплаты.
- Продавец. Хочет получить свои комиссионные от продажи.
- Покупатель. Хочет купить товары и быстро оформить покупку с минимальными усилиями. Хочет получить подтверждение факта покупки для возможного возврата товара.
- Компания. Хочет аккуратно записать транзакцию и удовлетворить интересы покупателя. Хочет удостовериться, что служба авторизации платежей зафиксировала все данные о платеже. Заинтересована в обеспечении устойчивости к сбоям; хочет продолжать регистрировать продажи, даже если серверные компоненты (например, служба удаленной проверки кредитоспособности) недоступны. Хочет автоматически обновлять бухгалтерскую документацию и вести складской учет.