Каков наилучший способ моделирования интерактивного графического интерфейса пользователя (с использованием сценариев использования или других подходов)?
Моя компания разрабатывает богатый графический интерфейс пользователя из подробного документа спецификации, написанного как более 100 вариантов использования (UC). Эти подробные UC движут развитием. Они написаны в виде таблиц с актером и столбцами описания. Мы (я и другие) исказили настоящий стиль прозы UC, чтобы поддержать интерактивный характер нашего приложения.
Мы также используем спецификацию для генерации (вручную) тестовой спецификации, поэтому детали (для меня) кажутся важными. Эта тестовая спецификация используется при проверке для получения подтверждения.
Примечание. В нашем продукте намного больше компонентов, чем просто графический интерфейс. Команда GUI состоит из 6-10 человек, проект в целом около 60 человек.
До недавнего времени я создавал "раскадровочный" документ, детализирующий каждую панель и ее взаимодействия по отношению к спецификации. Раньше также была архитектура с графическим интерфейсом, а также проекты для основных подкомпонентов. Ой! Это привело к очень медленным временам разработки, плохой базе кода (ха!) И плохо мотивированной команде.
Приложение представляет собой скорее IDE, позволяя пользователям создавать свои собственные тест-кейсы (для тестирования мобильных телефонов) с использованием drag'n'drop, идиома блок-схемы. Это очень сложный, зрелый (7+ лет) и предлагает много функций. Затем выполняются контрольные примеры и анализируются результаты. Будучи таким бесплатным инструментом (пользователь может пройти почти бесконечное количество путей через инструмент), он, похоже, делает бессмысленную последовательность последовательных вариантов использования. Мы используем "O" для обозначения необязательного, "R" для обозначения повторяемого, вложения и многих других "расширений". UC в основном плохо подходят для разработки взаимодействий IDE. Представьте, что это приложение предлагает пустую рабочую поверхность (например, текстовый процессор или электронную таблицу), где пользователи могут делать что угодно в любом порядке: это привело к раздутию UC.
В настоящее время существует желание упростить спецификацию от 100+ UC до фундаментальных UC: "Разработка тестового примера", "Выполнение тестового примера", "Анализ результатов" (или что-то подобное).
Хотя я понимаю, что наши UC не являются "настоящими" UC (ориентируясь на ценность для бизнеса), моя задача, как руководителя команды по GUI, так и разработчика, заключается в том, что без подробной информации мои ребята не будут знать, что именно разрабатывать. Три UC просто кажутся слишком абстрактными.
Мы придерживаемся формы Унифицированного Процесса, со спецификацией, сделанной заранее. Возможно, нам следует перейти к более гибкому процессу, когда разработчики сами проектируют взаимодействие.
2 ответа
Какой-нибудь инструмент IDE/GUI, основанный на drag'n drop, был бы хорош? С возможностью записи взаимодействий и размещения описательного текста на анимации. Вместо IDE дизайна UC вы позволяете IDE делать UC. С IDE/GUI в определенном состоянии вы можете позволить всплывающему окну показывать, что происходит, записывая UC или какой-либо текст в этом всплывающем окне, вызывая каждый раз, когда конкретное состояние обусловлено пользователем или разработчиком. Всплывающее окно может быть связано с большим количеством всплывающих окон в зависимости от того, что происходит в реальном мире. Как те текстовые приключения, спрашивающие "что ты хочешь делать сейчас?". И всплывающие события UC kan запускают события, чтобы изменить IDE/GUI или изменить другие состояния в соответствии с комплектами тестов, сделанными из спецификаций.
Тестовый набор отображает входы на выходы. Взаимодействия с IDE/GUI выбирают входы и выходы, изменяя состояние прототипа уровня данных программы. Теоретически вы можете выполнять все функции с помощью входных / выходных таблиц (некоторые бесконечно большие) вместо алгоритмов. Практически, когда таблица достаточно велика, пусть один программист использует ее как набор тестов для создания алгоритма и обмена таблицей. Таблица теперь используется в качестве тестового набора сообщений об ошибках.
Позвольте инструменту IDE/GUI сгенерировать код для конечной управляемой событиями среды IDE/GUI, взаимодействующей с событиями с кодом, данными и пользовательскими уровнями, или, что еще лучше, вы позволите ему отражать все на одном уровне, чтобы избавиться от бесконечной реструктуризации.
Это были просто идеи
В OpenLaszlo рекомендуется четыре этапа проектирования: 1.Wire-frame. 2.Storyboards. 3.Animations. 4. Инженерные прототипы.
Это очень интересно... http://www.openlaszlo.org/lps4.7/docs/developers/images/design_sec3_ill.jpg