Расширенный анализ требований. Иллюстрированные сценарии и прототипы
- Вы действительно хотите, чтобы я поставил свою подпись под этим документом?
- Разумеется, ведь в нем сосредоточено развернутое описание основных требований к автоматизированной информационной системе, которую мы должны для вас создать.
- Хорошо, я подпишу, но это ровным счетом ничего не значит.
- ??
- Ведь это всего лишь бумага, слова… А мне нужна программа, которая реально облегчит жизнь сотрудникам моего предприятия. Подпишу я сейчас документ или не подпишу - не имеет никакого значения. Важно лишь - сможете Вы или нет сделать такую систему, которая действительно принесет пользу. А это выяснится лишь, когда я смогу ее "пощупать".
Такой или примерно такой диалог состоялся у автора с генеральным директором полиграфического предприятия - заказчиком системы комплексной автоматизации его деятельности при подписании эскизного проекта.
И эта ситуация - не нонсенс. Каждый, кто выполнял проекты автоматизации рано или поздно сталкивается с ней. Что же делать - отказываться от выгодного проекта? Или взять на себя риск, что проект не будет принят в эксплуатацию: ведь при таком подходе к документу описания требований наверняка найдется что-то, очевидное для Заказчика, неожиданное для Исполнителя и не вошедшее в ТЗ. Хорошо, если придется переделывать 5% функций. А что, если 30% или 50%?
К счастью, выход существует. И этот выход - создание прототипов. Прототипы позволяют увидеть за сухими строчками документа описания требований фрагменты реальной системы, "поиграть" в эксплуатацию системы до ее создания.
|
|
|
Цели прототипирования
Все то, что говорилось в предыдущей лекции об особенностях восприятия человеком вербальной и невербальной информации по отношению к моделям, в еще большей степени следует отнести и к визуальным прототипам.
Рассмотрим основные цели, требующие применения прототипов [10.1-10.2]:
· прояснить неясные требования к системе;
· выбрать одно из различных концептуальных решений;
· проанализировать осуществимость.
1. Неясные требования. Часто Заказчику бывает трудно сформулировать требования к тому, что он ожидает от системы. В этом случае прототип интерфейса пользователя (User Interface, UI), оперативно созданный по результатам интервью, дает ему возможность увидеть схематичную реализацию того, как Исполнитель увидел соответствующую часть системы. Что интересно - в данном случае полезен любой исход прототипирования: если Исполнитель понял требования хорошо - польза очевидна; если не очень - польза заключается в том, что Заказчик может указать, в чем заключается непонимание, тем самым решив основную задачу - сделать неясное ясным.
|
|
|
2. Разные варианты решения. Любую техническую задачу можно решить различными способами. Это касается как задачи формулировки требований, так и ее реализации в UI.
Рассмотрим пример. Снабженцу поступает входной поток требований на комплектацию заказов материалами. Разные позиции одного и того же требования могут быть закуплены у различных поставщиков. Снабженец должен сопоставить поставщика каждой позиции каждого из требований. Есть как минимум два сценария решения этой задачи.
А) Сценарий последовательной обработки требований.
o А1. Система отображает реестр требований, имеющихся во входной очереди.
o А2. Пользователь выбирает очередное требование.
o А3. Система отображает перечень материалов требования и справочник поставщиков.
o А4. Пользователь сопоставляет каждой из позиций требования поставщика из справочника поставщиков.
o А5. Система придает требованию статус "обработано", высылает по электронной почте автору требования уведомление.
o А6. Продолжать с шага А1, пока очередь не опустеет.
Б) Сценарий группировки по материалам.
o Б1. Система отображает позиции всех требований и справочник поставщиков.
o Б2. Пользователь группирует позиции по типу (так, чтобы однотипные позиции, поставляемые одним и тем же поставщиком, находились рядом).
|
|
|
o Б3. Пользователь выбирает группу позиций и сопоставляет ей поставщика.
o Б4. Система проверяет - не появились ли полностью обработанные требования. При положительном исходе проверки присваивает этим требованиям статус "обработано" и высылает по электронной почте автору требования уведомление.
o Б5. Продолжать с шага Б1, пока очередь не опустеет.
Первый сценарий удобен тем, что позволяет снабженцу работать в разрезе авторов требований, начать с самых критичных по времени требований, контролировать процесс их обработки. Второй сценарий удобен тем, что позволяет одновременно наблюдать на экране строки разных требований, объединяя их в единый заказ.
После реализации прототипов UI по первому и второму сценариям Заказчик, оценив их достоинства и недостатки, смог в диалоге с Разработчиком сформулировать третий, комбинированный сценарий, сочетающий достоинства первых двух.
3. Анализ осуществимости. Часто бывает так, что комбинация функциональных, нефункциональных требований и ограничений такова, что возникает риск невозможности их реализации. Как правило, такой риск связан с требованиями к быстродействию системы при известных ограничениях среды ее реализации. В этом случае создаются прототипы (не обязательно, связанные с UI), реализующие соответствующую часть системы, имитирующие потоки данных, поступающие на ее вход и их обработку.
|
|
|
Классификация прототипов
Вслед за К. Вигерсом [10.2] рассмотрим следующие классификации прототипов:
· горизонтальные и вертикальные;
· одноразовые и эволюционные;
· бумажные и электронные, раскадровки1.
Горизонтальный прототип
Горизонтальный или поведенческий прототип (horizontal prototype, behavioral prototype) моделирует интерфейс пользователя приложения, не затрагивая логику обработки и базу данных.
Если в разработанном интерфейсе используются фрагменты базы данных - они имитируются в программном коде. При этом тексты, отображаемые на экране, должны отражать реальную специфику проблемной области, иначе пользователю будет трудно сосредоточиться. Если при нажатии на элемент управления должны производиться какие-то расчеты или запросы во внешние системы - результаты запросов также имитируются. Желательно реализовать ту часть кода, которая отвечает за перемещение между экранами в процессе исполнения вариантов использования, чтобы пользователь смог понять, как будет действовать система в ответ на его действия.
Горизонтальные прототипы следует использовать для достижения цели прояснения неясных, либо многоальтернативных требований.
Вертикальный прототип
Вертикальный или структурный прототип (vertical prototype, structural prototype) не ограничивается интерфейсом пользователя. Он реализует вертикальный "срез" системы, затрагивая все уровни ее реализации. При создании такого рода прототипов рекомендуется использовать те языки и среды реализации, что и при изготовлении целевой системы (что, вообще говоря, совсем не обязательно для горизонтальных прототипов).
Основные цели применения такого рода прототипов - анализ применимости, проверка архитектурных концепций.
Одноразовый прототип
Одноразовый или исследовательский прототип (throwaway prototype, exploratory prototype) создается, когда нужно быстро промакетировать те или иные аспекты и компоненты системы.
Целям создания исследовательских прототипов служит технология RAD (rapid application development) - быстрая разработка приложений , см. "Выявление требований" .
Одноразовый прототип должен создаваться быстро. При его разработке не следует уделять внимание вопросам повторного использования кода, качества, быстродействия, технологичности и т.п.
В результате получается "сырой" код, который может содержать значительное количество дефектов. Необходимо принять меры к тому, чтобы фрагменты кода, реализующие такого рода прототипы, не стали частью целевой системы.
К. Вигерс приводит следующую схему перехода от одноразового прототипа к детально проработанному UI:
Рис. 10.1.
На рисунке присутствует новое, не раскрытое ранее понятие: "карта диалога", говорят также "схема диалога". Прежде, чем создавать одноразовый прототип, необходимо определиться - какие основные экраны будут присутствовать, какие окна будут открываться, какие правила перехода между ними будут поддерживаться. Информация такого рода хорошо ложится на модель диаграммы состояний, см. "Расширенный анализ требований. Моделирование" ., где разным экранам (окнам) сопоставляются состояния, а активным элементам управления, вызывающим закрытие одних интерфейсных элементов и открытие других - переходы.
Эволюционный прототип
Эволюционный прототип (evolutionary prototype) создается, как первое приближение системы, призванное стать впоследствии самой системой.
Код эволюционного прототипа должен последовательно, в течении одной или более итераций, перерасти в код целевого приложения. Поэтому данный вид прототипов требует всего того, от чего следует отказаться при создании одноразовых прототипов: скрупулезной разработки, применения технологических методов и приемов, тестирования результатов и т.п.
В таблице приведено соотношение между рассмотренными выше 4 видами прототипов [10.2].
| Таблица 10.1. | ||
| Одноразовые | Эволюционные | |
| Горизонтальные | · Прояснение и уточнение примеров использования и функциональных требований · Выявление пропущенных требований · Исследование возможных вариантов интерфейса пользователя | · Реализация базовых вариантов использования · Реализация дополнительных вариантов использования по приоритетам · Реализация и доработка web-сайтов · Адаптация системы к быстро меняющимся требованиям бизнеса |
| Вертикальные | · Демонстрация технической осуществимости | · Реализация и наращивание ключевой клиент-серверной функциональности и уровней коммуникации · Реализация и оптимизация основных алгоритмов · Тестирование и настройка производительности |
Бумажный прототип
Бумажный прототип (paper prototype) - отличная альтернатива рассмотренным выше разновидностям электронных прототипов в случае, когда Разработчик ограничен в ресурсах. Наброски интерфейсов на бумаге, конечно, не заменят интерфейс, созданный в среде разработки. Однако, при всех недостатках, у таких прототипов есть два существенных достоинства.
1. Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и т.п., отвлекаясь от анализа функциональности.
2. Заказчик никогда не скажет, глядя на бумажный интерфейс: "Да вы, я вижу, уже создали систему на 85%! Давайте закончим ее в течении недели".
Раскадровка
Решением промежуточного между электронным и бумажным вариантами прототипов UI класса являются презентации, изготовленные при помощи средств электронного офиса (например, комбинации Microsoft Visio и Microsoft PowerPoint). В этом случае пользователь лишен свободы выбора, предоставляемой ему поведенческим прототипом. Но идею пошаговой смены экранов в процессе реализации сценария варианта использования вполне можно реализовать. Данный вид решения определяется в [10.3], как пассивная раскадровка. Активная раскадровка является дальнейшим развитием понятия пассивной раскадровки, с применением средств анимации и т.п. Третий вид раскадровки, вводимый в [10.3] - интерактивная представляет собой электронный одноразовый горизонтальный прототип.
Дата добавления: 2021-03-18; просмотров: 134; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!