Варианты использования и Сценарии использования ПО как основа для проектирования ПИ
Поскольку понимание потребностей пользователей (User Centered Design philosophy) позволяет разрабатывать более удобные, востребованные и эффективные программные продукты (а следовательно, ведёт к всеобщему счастью и удовлетворённости =), необходимо найти инструменты, позволяющие эффективно извлекать и обрабатывать информацию о требованиях пользователей.
В свете вышесказанного предлагаю обсудить такие методологии, как Варианты использования и Сценарии использования (Use case and Usage scenarios). Вышеназванные методологии отлично зарекомендовали себя (Karl E. Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на собственном опыте.
Предупреждение!
Для того, чтобы достичь валидности вариантов и сценариев использования необходимо проводить регулярные уточняющие сессии с представителями пользователей продукта. Сценарии использования являются оптимальным инструментом для извлечения и обработки уточняющей информации о требованиях, но их использование как единственного инструмента для извлечения пользовательских требований неприемлемо. Важно понимать, что обсуждаемые методологии являются средством моделирования, которое, в свою очередь, должно быть основано на реальных фактах.
На сегодняшний день я вижу два взаимодополняющих (но не альтернативных) способа формализации вариантов использования:
1. используя семантику UML, и
2. в текстовом виде.
Первый способ позволяет кратко описать систему или частный вариант использования на концептуальном уровне. Второй способ позволяет произвести низкоуровневое описание, и, что самое главное, более понятен неподготовленным представителям пользователей, и заказчику продукта. Оба способа имеют преимущества и недостатки и обладают способностью синергетически дополнять друг друга.
Мои комментарии с точки зрения проектировщика
Сам факт описания алгоритма взаимодействия пользователей с системой
расширяет сознание, происходит эффект "влезания в шкуру пользователя", я увидел целую уйму возможностей усовершенствовать интерфейс.
Увеличился уровень "целостности" документации, появилось приятное
ощущение порядка, когда ты знаешь почему такая-то фича обязательно
должна быть именно в этом месте и какой акцент следует ей придать.
Будьте готовы к тому, что в ходе формализации текстового описания
возникнут сложности с разметкой, таблицами, формулировками и
терминологией, у меня на их преодоление ушёл примерно день.
Мои впечатления с точки зрения руководителя проекта
Всплыли забытые экраны (wireframes), которые необходимо описать (а это
позволило оптимальнее спланировать ход реализации проекта и избежать
лишних итераций).
Использование данных методологий требует временных и ресурсных затрат, но в итоге окупается сторицей:
- качество продукта повышается в разы;
- уровень удовлетворённости заказчика также заметно возрастает;
- проект становится более прогнозируемым и управляемым (случается
гораздо меньше "потерь" функциональности и элементов интерфейса);
- появляется дополнительная аргументация, которая может потребоваться в ходе проведения презентаций wireframes, дизайна UI и продукта в целом.
Здесь это всё активно обсуждается.
Сейчас пишу статью на эту тему, в связи с чем сотворил такую картину.
В свете вышесказанного предлагаю обсудить такие методологии, как Варианты использования и Сценарии использования (Use case and Usage scenarios). Вышеназванные методологии отлично зарекомендовали себя (Karl E. Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на собственном опыте.
Предупреждение!
Для того, чтобы достичь валидности вариантов и сценариев использования необходимо проводить регулярные уточняющие сессии с представителями пользователей продукта. Сценарии использования являются оптимальным инструментом для извлечения и обработки уточняющей информации о требованиях, но их использование как единственного инструмента для извлечения пользовательских требований неприемлемо. Важно понимать, что обсуждаемые методологии являются средством моделирования, которое, в свою очередь, должно быть основано на реальных фактах.
На сегодняшний день я вижу два взаимодополняющих (но не альтернативных) способа формализации вариантов использования:
1. используя семантику UML, и
2. в текстовом виде.
Первый способ позволяет кратко описать систему или частный вариант использования на концептуальном уровне. Второй способ позволяет произвести низкоуровневое описание, и, что самое главное, более понятен неподготовленным представителям пользователей, и заказчику продукта. Оба способа имеют преимущества и недостатки и обладают способностью синергетически дополнять друг друга.
Мои комментарии с точки зрения проектировщика
Сам факт описания алгоритма взаимодействия пользователей с системой
расширяет сознание, происходит эффект "влезания в шкуру пользователя", я увидел целую уйму возможностей усовершенствовать интерфейс.
Увеличился уровень "целостности" документации, появилось приятное
ощущение порядка, когда ты знаешь почему такая-то фича обязательно
должна быть именно в этом месте и какой акцент следует ей придать.
Будьте готовы к тому, что в ходе формализации текстового описания
возникнут сложности с разметкой, таблицами, формулировками и
терминологией, у меня на их преодоление ушёл примерно день.
Мои впечатления с точки зрения руководителя проекта
Всплыли забытые экраны (wireframes), которые необходимо описать (а это
позволило оптимальнее спланировать ход реализации проекта и избежать
лишних итераций).
Использование данных методологий требует временных и ресурсных затрат, но в итоге окупается сторицей:
- качество продукта повышается в разы;
- уровень удовлетворённости заказчика также заметно возрастает;
- проект становится более прогнозируемым и управляемым (случается
гораздо меньше "потерь" функциональности и элементов интерфейса);
- появляется дополнительная аргументация, которая может потребоваться в ходе проведения презентаций wireframes, дизайна UI и продукта в целом.
Здесь это всё активно обсуждается.
Сейчас пишу статью на эту тему, в связи с чем сотворил такую картину.