1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы

1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы

^ 1.13Расширенный анализ требований. Иллюстрированные сценарии и макеты
Вы вправду желаете, чтоб я поставил свою подпись под этим документом?

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

- Отлично, я подпишу, но это ровненьким счетом ничего не означает.

- ??

- Ведь это всего только бумага, слова… А мне нужна программка, которая реально облегчит жизнь сотрудникам моего предприятия. Подпишу я на 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы данный момент документ либо не подпишу - не имеет никакого значения. Принципиально только - можете Вы либо нет сделать такую систему, которая вправду принесет пользу. А это выяснится только, когда я смогу ее "пощупать 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы".

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

И эта ситуация - не нонсенс. Каждый, кто делал 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы проекты автоматизации в какой-то момент сталкивается с ней. Что все-таки делать - отрешаться от прибыльного проекта? Либо взять на себя риск, что проект не будет принят в эксплуатацию: ведь при 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы таком подходе к документу описания требований наверное найдется что-то, явное для Заказчика, внезапное для Исполнителя и не вошедшее в ТЗ. Отлично, если придется переделывать 5% функций. А что, если 30% либо 50%?

К счастью, выход существует. И 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы этот выход - создание прототипов. Макеты позволяют узреть за сухими строками документа описания требований куски реальной системы, "поиграть" в эксплуатацию системы до ее сотворения.
^ 1.13.1Цели прототипирования
Все то, что говорилось 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы в предшествующей лекции об особенностях восприятия человеком вербальной и невербальной инфы по отношению к моделям, в еще большей степени следует отнести и к зрительным макетам.

Разглядим главные цели, требующие внедрения прототипов [10.1-10.2]:

  1. Неясные требования. Нередко Заказчику бывает тяжело сконструировать требования к тому, что он ждет от системы. В данном случае макет интерфейса юзера 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы (User Interface, UI), оперативно сделанный по результатам интервью, дает ему возможность узреть схематичную реализацию того, как Исполнитель увидел подобающую часть системы. Что любопытно - в этом случае полезен хоть какой финал прототипирования 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы: если Исполнитель сообразил требования отлично - полезность явна; если не очень - полезность состоит в том, что Заказчик может указать, в чем заключается недопонимание, тем решив основную задачку - сделать неясное ясным.

  2. ^ Различные варианты решения. Всякую 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы техно задачку можно решить разными методами. Это касается как задачки формулировки требований, так и ее реализации в UI.

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

А) Сценарий поочередной обработки требований.

Б) Сценарий группировки по материалам.

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

После реализации прототипов UI по первому и второму сценариям Заказчик, оценив их плюсы и недочеты, сумел в диалоге 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы с Разработчиком сконструировать 3-ий, комбинированный сценарий, сочетающий плюсы первых 2-ух.

  1. ^ Анализ осуществимости. Нередко случается так, что композиция многофункциональных, нефункциональных требований и ограничений такая, что появляется риск невозможности их реализации. Обычно, таковой 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы риск связан с требованиями к быстродействию системы при узнаваемых ограничениях среды ее реализации. В данном случае создаются макеты (не непременно, связанные с UI), реализующие подобающую часть системы, имитирующие потоки данных 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы, поступающие на ее вход и их обработку.
^ 1.13.2Систематизация прототипов
Прямо за К. Вигерсом [10.2] разглядим последующие систематизации прототипов:
^ Горизонтальный макет
Горизонтальный либо поведенческий макет 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы (horizontal prototype, behavioral prototype) моделирует интерфейс юзера приложения, не затрагивая логику обработки и базу данных.

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

Горизонтальные макеты следует использовать для заслуги цели прояснения неясных, или многоальтернативных требований.
^ Вертикальный макет
Вертикальный либо структурный макет (vertical prototype, structural prototype) не ограничивается интерфейсом юзера. Он реализует вертикальный "срез" системы, затрагивая все 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы уровни ее реализации. При разработке такового рода прототипов рекомендуется использовать те языки и среды реализации, что и при изготовлении мотивированной системы (что, вообщем говоря, совершенно не непременно для горизонтальных прототипов 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы).

Главные цели внедрения такового рода прототипов - анализ применимости, проверка строительных концепций.
^ Разовый макет
Разовый либо исследовательский макет (throwaway prototype, exploratory prototype) создается, когда необходимо стремительно промакетировать те либо другие нюансы и составляющие 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы системы.

Целям сотворения исследовательских прототипов служит разработка RAD (rapid application development) - стремительная разработка приложений , см. лекцию 6.

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

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

К. Вигерс приводит последующую схему перехода от разового макета к детально проработанному UI:




прирастить изображение
Рис. 10.1. 

На рисунке находится новое, не раскрытое ранее понятие: "карта диалога", молвят также "схема диалога". До этого, чем создавать 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы горизонтальный макет, нужно обусловиться - какие главные экраны будут находиться, какие окна будут раскрываться, какие правила перехода меж ними будут поддерживаться. Информация такового рода отлично ложится на модель диаграммы состояний, см. лекцию 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы 9., где различным экранам (окнам) сопоставляются состояния, а активным элементам управления, вызывающим закрытие одних интерфейсных частей и открытие других - переходы.
^ Эволюционный макет
Эволюционный макет (evolutionary prototype) создается, как 1-ое приближение системы, призванное стать потом 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы самой системой.

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

В таблице приведено соотношение меж рассмотренными выше 4 видами прототипов [10.2].

Таблица 10.1.




Разовые

Эволюционные

Горизонтальные

  • Прояснение и уточнение примеров использования и 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы многофункциональных требований

  • Выявление пропущенных требований

  • Исследование вероятных вариантов интерфейса юзера

  • Реализация базисных вариантов использования

  • Реализация дополнительных вариантов использования по ценностям

  • Реализация и доработка web-сайтов

  • Адаптация системы к стремительно меняющимся требованиям бизнеса

Вертикальные

  • Демонстрация технической осуществимости

  • Реализация 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы и наращивание главный клиент-серверной функциональности и уровней коммуникации

  • Реализация и оптимизация главных алгоритмов

  • Тестирование и настройка производительности
^ Картонный макет
Картонный макет (paper prototype) - хорошая кандидатура рассмотренным выше разновидностям электрических прототипов в случае 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы, когда Разработчик ограничен в ресурсах. Эскизы интерфейсов на бумаге, естественно, не поменяют интерфейс, сделанный в среде разработки. Но, при всех недочетах, у таких прототипов есть два существенных плюсы.

  1. Заказчик не станет 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы акцентировать внимание на цветовом решении, форме кнопок и т.п., отвлекаясь от анализа функциональности.

  2. Заказчик никогда не произнесет, смотря на картонный интерфейс: "Да вы, я вижу, уже сделали систему на 85%! Давайте закончим ее 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы в течении недели".
Раскадровка
Решением промежного меж электрическим и картонным вариациями прототипов UI класса, является презентации, сделанные с помощью средств электрического кабинета (к примеру, композиции Microsoft Visio и Microsoft PowerPoint). В данном случае юзер 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы лишен свободы выбора, предоставляемой ему поведенческим макетом. Но идею пошаговой смены экранов в процессе реализации сценария варианта использования полностью можно воплотить. Данный вид решения определяется в [10.3], как пассивная раскадровка. Активная 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы раскадровка является предстоящим развитием понятия пассивной раскадровки, с применением средств анимации и т.п. 3-ий вид раскадровки, вводимый в [10.3] - интерактивная представляет собой электрический разовый горизонтальный макет.
^ 1.13.3Иллюстрированные сценарии прецедентов
Иллюстрированные сценарии прецедентов 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы, ИСП [10.4], вместе с образцами позволяют достигнуть наилучшего осознания меж Заказчиком и Разработчиком. Но если макеты адресованы быстрее Заказчику, ежели Разработчику, то с ИСП ситуация обстоит напротив: они содержат дополнительные сведения, помогающие 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы Разработчику лучше осознать специфику проблемной области и, тем, лучше отразить ее в интерфейсе юзера.

Основная мысль ИСП - "разбавить" текст описания сценария варианта использования качествами применимости.

Нюанс применимости - информация, позволяющая расширить описание прецедента описаниями, конкретизирующими те 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы либо другие его особенности и, в итоге, повысить степень комфортности юзера.

Различают [10.4] 3 разновидности качеств применимости: ориентиры, средние значения атрибутов и объемы объектов, средняя интенсивность использования.
Ориентиры
Ориентиры - это описание опциональных многофункциональных способностей 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы системы. Отсутствие таких способностей не приводит к фатальной беде. Присутствие - улучшает применимость, снабжая полезной информацией. Ориентиры следует расценивать не как требования, как пожелания либо советы.

Пример. Описание потока событий ИСП 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы для прецедента "Оформить заказ", расширенного ориентирами (текст в квадратных скобках).

В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из клиентской базы, определяет товарные позиции из справочника и показывает их количество. Система показывает 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы на мониторе наименование позиций, стоимость, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты. Система рассчитывает итоговую сумму. [Менеджер обязан иметь возможность созидать текущее сальдо расчетов с 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы клиентом и данные по последним 10 сделкам со статистикой по дисциплине соблюдения договорных обязательств].
^ Средние значения атрибутов и объемы объектов
Данная информация позволяет оптимальнее выстроить пользовательский интерфейс и оценить на ранешних стадиях 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы проекта "узенькие места" в обработке данных, которые могут воздействовать на производительность системы.

Так, при выборе из 2 способностей лучше подойдет отран управления checkbox, при выборе, ограниченном 2-3 десятками позиций - выпадающий перечень, при обилии, измеряемом 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы тыщами вариантов, потребуются дополнительные средства фильтрации и поиска.

Пример. Описание потока событий ИСП для прецедента "Оформить заказ", расширенного объемами и средними значениями объектов (текст в фигурных скобках).

В процессе выполнения прецедента менеджер по приему заказов 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы выбирает заказчика из клиентской базы {до 10000 клиентов}, определяет товарные позиции из справочника {товары разбиты на 10 категорий, количество позиций в категории не превосходит 500} и показывает их количество {до 100 позиций, средняя закупка - 8 позиций 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы}. Система показывает на мониторе наименование позиций, стоимость, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты {на данный момент есть 3 варианта порядка оплаты}. Система рассчитывает итоговую сумму 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы.
^ Средняя интенсивность использования
Средняя интенсивность использования позволяет выделить сценарии "массового" использования, в каких все должно быть совершенно (быстродействие, удобство использования, минимум действий на выполнение операций). К примеру - интерфейс кассира в гипермаркете. Другая крайность - сценарии, выполняемые 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы от варианта к случаю, не каждый денек и не требующие особенной оперативности (к примеру, расчет зарплаты в месяц). Эти данные позволяют, структурировать подачу инфы, убрать из "основных" интерфейсов изредка применяемые 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы функции и т.п.

Пример. Кусок описания потока событий ИСП для прецедента "Оформить заказ для нового клиента", расширенного объемами и средними значениями объектов (текст в круглых скобках).

В процессе выполнения прецедента 1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы менеджер по приему заказов выбирает заказчика из клиентской базы (в 95% случаев), или вызывается интерфейс регистрации нового клиента (в 5% случаев).


11sportivno-massovaya-rabota-v-maou-licej-5-publichnij-doklad.html
11uchebno-metodicheskoe-i-informacionnoe-obespechenie-disciplini-programma-disciplini-scenarnij-trejding-pravitelstvo.html
11zona-razvitiya-lesnogo-hozyajstva-planirovanii.html