Файл: Учебное пособие.doc

Таблица 3.17

Пример определения функций

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

3.1.3.Совместная разработка приложений (JAD – Joint application design)

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

Сеансы JAD аналогичны сеансам "мозгового штурма", однако не во всем. Сеансы "мозгового штурма" длятся около двух часов, а сеансы JAD – до трех дней. На сеансах "мозгового штурма" происходит быстрое генерирование идей, а на сеансах JAD – высокоуровневые специфические программные модели функций, данных и линий поведения.

Сеанс JAD имеет определенную структуру, на нем придерживаются определенной дисциплины, и он проходит под руководством арбитра. В его основе лежит обмен информацией с использованием документации, фиксированных требований и правил работы. С момента появления методики JAD на сеансах используются CASE-инструменты и другие программные средства, предназначенные для построения диаграмм потока данных (Data flow diagram, DFD), диаграмм взаимосвязей между сущностями (Entity relationship diagrams, ERD), диаграмм смены состояний и других объектно-ориентированных диаграмм.

3.1.3.1.Роли в сеансах JAD

Разработчики

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

Участники

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

Арбитр/консультант

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

Секретарь

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

3.1.3.2.Сеансы JAD

Согласно Вуду (Wood), сеанс JAD– это своеобразная "мастерская", работающая в максимально напряженном режиме, где решения принимаются совместно всеми участниками. При этом участники являются крупными специалистами в рассматриваемом вопросе.

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

3.1.3.3.Результаты проведения сеанса JAD

Результатами проведения сеанса могут быть:

• диаграмма контекста данных;

• диаграмма потока данных первого уровня;

• глобальная модель данных – диаграмма взаимосвязей между сущностями;

• перечень первичных объектов;

• объектная модель высокого уровня;

• обязанности кандидатов и сотрудников для каждого объекта;

• перечень первичных процессов/сценарии выбора;

• другие диаграммы потока данных, диаграммы состояния, деревья альтернатив, таблицы решений;

• требования, предъявляемые к данным для каждого процесса;

• перечень допущений;

• документация по анализу или назначению открытых вопросов.

Результаты сеанса JAD используются в процессе определения требований для организации следующего этапа – создания спецификации SRS.

3.1.3.4.Недостатки метода JAD

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

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

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

3.1.4.Раскадровка

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

Раскадровка имеет следующие преимущества.

Предельно недорога

Дружественна пользователю, неформальна и интерактивна

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

Легко создаваема и модифицируема

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

3.1.4.1.Типы раскадровок

Раскадровки делятся на три типа в зависимости от режима взаимодействия с пользователем: пассивные, активные и интерактивные.

• Пассивные представляют собой историю, рассказываемую пользователю. Они могут состоять из схем, картинок, моментальных копий экрана, презентаций PowerPoint или образцов выходной информации системы. В пассивной раскадровке аналитик играет роль системы и просто проводит пользователя по раскадровке, объясняя следующее: "Когда вы делаете это, происходит вот это".

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

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

Рис. 3.50 Различные виды раскадровок

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

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

3.1.5.Обыгрывание ролей

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

3.1.5.1.Суть метода обыгрывания ролей

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

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

Существует две разновидности метода обыгрывания ролей: сценарный просмотр и CRC-карточки.

3.1.5.2.Сценарный просмотр

Сценарный просмотр – это исполнение роли на бумаге.

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

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

3.1.6.CRC-карточки (Class-Responsibility-Collaboration, класс-обязанность-взаимодействие)

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

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

Ниже предлагается образец проигрывания одного из возможных вариантов использования.

3.1.7.Быстрое прототипирование

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

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

Таблица 3.18

Выгода от прототипа: грубая оценка

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

Существует много способов разбиения прототипов на категории. Например, Дэвис (Davis, 1995) в своей работе выделял следующие прототипы: отбрасываемые, эволюционирующие и операционные; вертикальные и горизонтальные; пользовательские интерфейсы и алгоритмические; и т.д. Каким должен быть прототип в каждом конкретном случае, зависит от того, какую проблему вы пытаетесь решить путем построения прототипа.

Как пример представьте себе приложение для электронной коммерции, в котором компания-производитель одежды желает продавать товары через Интернет, хранить информацию о клиентах и предоставлять клиентам возможность получать свое фото в одежде из каталога. Финансовая оценка для разных уровней прототипирования для программы, продающей одежду, приведена в таблице 4.4. Для каждой из четырех характеристик, рассмотренных в прототипе, сделано несколько оценок: стоимость работы; процент работы, который будет повторно использоваться в самой программе (то есть не будет отброшен); и полная прибыль от прототипа. Под полной прибылью здесь понимается оценка того, что будет получено, если характеристика будет включена в прототип, но код не будет использован в программе. Например, мы подсчитали, что если прототип «примерка одежды» будет построен, это сэкономит минимум 20 000 при разработке. Оценка базируется на нижеследующих факторах.