Разработка под управлением UI

Question

Идея разработки пользовательского интерфейса имеет смысл вообще? Большинство наших клиентов любят передавать свои требования в виде экранов. Напр. Я хочу, чтобы экран делал ЭТО и ЭТО. Иногда они даже заходят так далеко, что сами диктуют компоновку экрана (это может быть потому, что клиенты сегодня уже используют программные приложения для большинства своих задач).

Также этот метод сбора требований, как представляется, автоматически передает как данные, так и ассоциированное поведение.

Что вы, ребята, думаете?

Answer 1

На самом деле это имеет смысл в этом отношении. Варианты использования здесь отличаются друг от друга тем, что они не могут использоваться одинаково. Случаи использования будут полезны для извлечения и оформления требований.

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

Типичный цикл будет:

• проект несколько требований и прецедентов, очень ограниченные по масштабам очень сосредоточенным.
• Создайте тестовый протокол, который позволит нам собирать данные по этой функции (удобство использования, простота использования, прием, производительность и т. Д.).
• Создать или расширить приложение, чтобы включить эту функцию
• имеет несколько пользователей протестировать приложение с помощью гибкой адаптации юзабилити-тестировании (см Ruben's Handbook of Usability Testing), где мы бы ограничить тестовые сессии до 15 минут с 15 минут debreifing.
• Извлечь полезные данные из тестирования для инъекции в будущую итерацию.

Этот метод был perticularely полезным, когда пользователи либо не знали точно, что они хотели, либо не могли рассказать нам. Поэтому нам пришлось бы разрабатывать тесты, которые собирали бы объективные данные о полезности программного обеспечения для пользователя и пытались бы соответственно провести следующую итерацию. (многие из наших «клиентов», если я могу их назвать, были сильно инвалидами и не могли говорить, поэтому мы должны были быть творческими).

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

Хотя мы разработали эту технику в основном для особо конкретных случаев, мы провели некоторое тестирование с обычными пользователями в обычном программном обеспечении и получили очень положительные результаты. Идея сходится очень быстро к потребностям usre. Также тот факт, что они участвовали в этом стилевом подходе, также очень положительно повлиял на принятие продукта в целевом сообществе.

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

Таким образом, UIDD (если вы прощаете с плохим аббревиатурой) будет членом семейства TDD подходов к разработке программного обеспечения, где итерации зависят от пользовательских взаимодействий.

---

Additionnal чтение по теме:

http://www.codinghorror.com/blog/archives/001091.html

http://cakebaker.42dh.com/2007/07/07/usability-driven-development/

http://www.springerlink.com/content/l413k76812896gnt/

http://www.agilemodeling.com/essays/agileUsability.htm

http://www.uxbooth.com/blog/how-test-driven-development-increases-overall-usability/

Answer 2

Я думаю, что вы на самом деле говорите здесь прецеденты - см. this article для вступления.

Answer 3

История разработки, основанная на тестировании. Я думаю, что это неплохая идея, если вы серьезно относитесь к ее части автоматизации. Если вы не можете автоматизировать свои тесты, тогда у вас проблемы. Посмотрите на эту статью здесь: http://www.industriallogic.com/papers/storytest.pdf Это не похоже, что ваши клиенты дают вам автоматические тесты пользовательского интерфейса, но я думаю, что это лучший способ пойти.

Answer 4

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

Похоже, что это похоже на разработку с учетом поведения, каркас и истории пользователей.

Answer 5

Какое развитие вы делаете? Когда я разрабатываю веб-приложения (flex или php), я работаю с рисунками (каркасами), поэтому я могу заставить клиента знать поток/внешний вид приложения без написания кода.

Существует нет «правильного пути для развития» для всех, вам просто нужно найти способ, который наилучшим образом подходит для вас. ура!