Варианты использования и Сценарии использования ПО как основа для проектирования ПИ
Sergey Makarov
Поскольку понимание потребностей пользователей (User Centered Design
philosophy) позволяет разрабатывать более удобные, востребованные и
эффективные программные продукты (а следовательно, ведёт к всеобщему
счастью и удовлетворённости =), необходимо найти инструменты,
позволяющие эффективно извлекать и обрабатывать информацию о
требованиях пользователей.
В свете вышесказанного предлагаю обсудить такие методологии, как
Варианты использования и Сценарии использования (Use case and Usage
scenarios).
Вышеназванные методологии отлично зарекомендовали себя (Karl E.
Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на
собственном опыте.
Предупреждение!
Для того, чтобы достичь валидности вариантов и сценариев использования
необходимо проводить регулярные уточняющие сессии с представителями
пользователей продукта.
Сценарии использования являются оптимальным инструментом для
извлечения и обработки уточняющей информации о требованиях, но их
использование как единственного инструмента для извлечения
пользовательских требований неприемлемо. Важно понимать, что
обсуждаемые методологии являются средством моделирования, которое, в
свою очередь, должно быть основано на реальных фактах.
На сегодняшний день я вижу два взаимодополняющих (но не
альтернативных) способа формализации вариантов использования:
1. используя семантику UML, и
2. в текстовом виде.
Первый способ позволяет кратко описать систему или частный вариант
использования на концептуальном уровне.
Второй способ позволяет произвести низкоуровневое описание, и, что
самое главное, более понятен неподготовленным представителям
пользователей, и заказчику продукта.
Оба способа имеют преимущества и недостатки и обладают способностью
синергетически дополнять друг друга.
Мои комментарии с точки зрения проектировщика
Сам факт описания алгоритма взаимодействия пользователей с системой
расширяет сознание, происходит эффект "влезания в шкуру пользователя",
я увидел целую уйму возможностей усовершенствовать интерфейс.
Увеличился уровень "целостности" документации, появилось приятное
ощущение порядка, когда ты знаешь почему такая-то фича обязательно
должна быть именно в этом месте и какой акцент следует ей придать.
Будьте готовы к тому, что в ходе формализации текстового описания
возникнут сложности с разметкой, таблицами, формулировками и
терминологией, у меня на их преодоление ушёл примерно день.
Мои впечатления с точки зрения руководителя проекта
Всплыли забытые экраны (wireframes), которые необходимо описать (а это
позволило оптимальнее спланировать ход реализации проекта и избежать
лишних итераций).
Использование данных методологий требует временных и ресурсных затрат,
но в итоге окупается сторицей:
- качество продукта повышается в разы;
- уровень удовлетворённости заказчика также заметно возрастает;
- проект становится более прогнозируемым и управляемым (случается
гораздо меньше "потерь" функциональности и элементов интерфейса);
- появляется дополнительная аргументация, которая может потребоваться
в ходе проведения презентаций wireframes, дизайна UI и продукта в
целом.
Буду рад увидеть комментарии, поделится опытом и поучаствовать в
обсуждении =)
Hienadz Drahun
Мне нравится ваш подход. Совмещая методики, описанные Карлом Вигерсом
с методиками User-Centered Design можно получить куда более
качественные результаты, чем при использовании каждой из методик по
отдельности.
Кстати, как вам подход Usage-Centered Design Ларри Константайна (aka
Activity-Centered Design)? Мне он кажется более адаптированым к
использованию совместно с методиками разработки програмного
обеспечения, чем User-Centered Design.
Павел Коноплицкий
статья очень понравилась. Со ссылкой на вас я буду использовать её при
подготовке своего выступления на Минской миниконференции о юзабилити.
Что касается самой статьи, то могу дополнить её самими шаблонами
проектной документации от разных UX компаний и сообществ
http://www.amazedev.com/pmoshablony-dokumentov/
Marina Fedorova
Hienadz Drahun
> Коллеги, а есть ли какая литература на русском по данному вопросу? Можете
> порекомендовать что-либо?
>
Мария, для начала ищите следующие книги. Вышли они лет 5 назад,
поэтому в продаже уже нет.
1) Разработка требований к программному обеспечению
Карл Вигерс, , Москва: "Русская редакция", 2004
http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=142
(Русская пдф-версия плохого качества. Там же можно найти много статей-
книг по данной тематике)
2) Разработка программного обеспечения
Лари Константайн, Люси Локвуд. СПб.: <<Питер>>, 2004
Sergey Makarov
С подходом Ларри Константайна ещё не знаком.
У меня есть только одна его книга "Разработка программного
обеспечения", есть что-то кроме этого на русском?
Попробовал поискать 15 минут, но пока безрезультатно =) Но себе в
задачи уже добавил подробно ознакомится с его подходом, спасибо за
подсказку!
Sergey Makarov
Ваш блог у меня в закладках с момента его первого посещения.
Особенно нравится ваша статья "Успешный проект - проект,
ориентированный на пользователя", жаль, не побывал SocialExperience
2008 и не послушал, в ближайшее время посмотрю видеозапись.
По поводу шаблонов:
поскольку уровень знаний и практических навыков непрерывно растёт (дай
Бог, чтобы так и продолжалось=), думаю, что можно сделать вторую
версию статьи (дополненную), к которой и добавить ссылки на шаблоны
документации. Безусловно, они там будут очень кстати.
Sergey Makarov
Есть ещё книга Алистера Коберна, "Современные методы описания
функциональных требований к системам".
Если нужно, могу отправить на почту все три книги, на русском,
обращайтесь =)
On 27 фев, 08:56, Marina Fedorova <fedoro...@gmail.com> wrote:
> Коллеги, а есть ли какая литература на русском по данному вопросу? Можете
> порекомендовать что-либо?
>
> 26 февраля 2009 г. 19:59 пользователь Павел Коноплицкий
> <amaze...@gmail.com>написал:
Sergey Makarov
вопрос к участникам: что бы вы хотели видеть в этой статье?
На сегодняшний день я планирую следующий состав:
- общий обзор методологии в разрезе UCD;
- расширенные и дополненные выводы, основанные на практическом опыте,
как с точки зрения проектировщика, так и сточки зрения руководителя
проектов;
- указание большей части источников: книг и статей;
- шаблоны описания сценариев использования, как собственные, так и те,
что ещё найдутся (сейчас уже есть шаблоны, предоставленные Карлом
Вигерсом).
Возможно, ещё что-то посоветует Евгений Кулаков, редактор Юзабилити
Бюллетеня.
Denis Beskov
> альтернативных) способа формализации вариантов использования:
> 1. используя семантику UML, и
> 2. в текстовом виде.
> Первый способ позволяет кратко описать систему или частный вариант
> использования на концептуальном уровне.
Вы имеете в виду Activity Diagram или Use Case Diagram?
Что такое <<частный вариант использования>>? Какие ещё бывают?
Что такое <<концептуальный уровень>> -- не раскрывая последовательности
взаимодействий или основной поток без расширений?
> Второй способ позволяет произвести низкоуровневое описание, и, что
> самое главное, более понятен неподготовленным представителям
> пользователей, и заказчику продукта.
Нельзя сказать, чтобы use case в своей полноценной, текстовой форме,
был намного понятнее, чем его же Activity Diagram. Для простых случаев
диаграммы более наглядны и легче воспринимаются, чем расширения use
case.
> Оба способа имеют преимущества и недостатки и обладают способностью
> синергетически дополнять друг друга.
Если под 1-м способом имеются в виду Use Case Diagram, то такая
диаграмма обычно ничем не полезнее перечня в виде простой таблицы из 2-
х столбцов -- 1) Агент (Actor); 2) Способ применения (Use Case).
Если под 1-м способом имеются в виду Activity Diagram, то делать для
реального проекта из, скажем, 30
use case и тексты и диаграммы (которые для любого нетривиального
способа применения становятся довольно запутанными) достаточно
накладно и бессмысленно, можно обойтись диаграммами только для
наиболее сложных или архитектурно значимых способов применения.
> Будьте готовы к тому, что в ходе формализации текстового описания
> возникнут сложности с разметкой, таблицами, формулировками и
> терминологией, у меня на их преодоление ушёл примерно день.
Расскажите пожалуйста, какого рода сложности возникли, о чём идёт
речь?
> Использование данных методологий требует временных и ресурсных затрат,
В отличие от какого подхода? Как альтернатива чему?
Sergey Makarov
> Вы имеете в виду Activity Diagram или Use Case Diagram?
Я имел ввиду Use Case Diagram, но думаю, что Activity Diagram также
будет полезна (иногда незаменима) для описания вариантов
использования, обладающих большим количеством расширений, или для
описания системы в целом. Спасибо, что уточнили.
> Что такое <<частный вариант использования>>? Какие ещё бывают?
Словом "частный" я уточняю уровень абстракции.
> Что такое <<концептуальный уровень>> -- не раскрывая последовательности
> взаимодействий или основной поток без расширений?
Оба варианта описывают систему или вариант использования на
концептуальном уровне.
> Нельзя сказать, чтобы use case в своей полноценной, текстовой форме,
> был намного понятнее, чем его же Activity Diagram. Для простых случаев
> диаграммы более наглядны и легче воспринимаются, чем расширения use
> case.
> Если под 1-м способом имеются в виду Use Case Diagram, то такая
> диаграмма обычно ничем не полезнее перечня в виде простой таблицы из 2-
> х столбцов -- 1) Агент (Actor); 2) Способ применения (Use Case).
Денис - это различные инструменты, применяемые для описания системы на
различных уровнях абстракции. (Было бы нелепо производить
самостоятельно сравнение увеличительной лупы и микроскопа?)
Хорошо, что обратили внимание, действительно, здесь не может быть
однозначного ответа, многое зависит от контекста.
> Если под 1-м способом имеются в виду Activity Diagram, то делать для
> реального проекта из, скажем, 30
> use case и тексты и диаграммы (которые для любого нетривиального
> способа применения становятся довольно запутанными) достаточно
> накладно и бессмысленно, можно обойтись диаграммами только для
> наиболее сложных или архитектурно значимых способов применения.
Я тоже так считаю.
> > Будьте готовы к тому, что в ходе формализации текстового описания
> > возникнут сложности с разметкой, таблицами, формулировками и
> > терминологией, у меня на их преодоление ушёл примерно день.
> Расскажите пожалуйста, какого рода сложности возникли, о чём идёт
> речь?
Ну это как раз сложности, обусловленные перечисленными вами
обстоятельствами:
> >...тексты и диаграммы (которые для любого нетривиального
> > способа применения становятся довольно запутанными)...
> > Использование данных методологий требует временных и ресурсных затрат,
> В отличие от какого подхода? Как альтернатива чему?
В первую очередь как альтернатива неиспользованию.
P.S.
Буду очень признателен, если вы вкратце опишете альтернативные
методологии, которые можно противопоставить обсуждаемым.
Hienadz Drahun
> У меня есть только одна его книга "Разработка программного
> обеспечения", есть что-то кроме этого на русском?
>
Ещё есть "Человеческий фактор в программировании", Москва: Символ,
2004 - но это сборник статей с общей направленностью скорее в сторону
Peopleware, чем в бизнес анализ.
Denis Beskov
> Словом "частный" я уточняю уровень абстракции.
Какие уровни абстракции вы выделяете?
> > Что такое <<концептуальный уровень>> -- не раскрывая последовательности
> > взаимодействий или основной поток без расширений?
> Оба варианта описывают систему или вариант использования на
> концептуальном уровне.
Что такое <<концептуальный уровень>>? Какие ещё бывают?
> > Если под 1-м способом имеются в виду Use Case Diagram, то такая
> > диаграмма обычно ничем не полезнее перечня в виде простой таблицы из 2-
> > х столбцов -- 1) Агент (Actor); 2) Способ применения (Use Case).
> Денис - это различные инструменты, применяемые для описания системы на
> различных уровнях абстракции. (Было бы нелепо производить
> самостоятельно сравнение увеличительной лупы и микроскопа?)
Мой тезис: Use Case Diagram -- самая бестолковая из всего комплекта
UML,
и в общем случае лучше использовать таблицу из списка Агентов и
Способов применения.
Сами по себе <<плящущие человечки>> ничего не объясняют.
> > > Использование данных методологий требует временных и ресурсных затрат,
> > В отличие от какого подхода? Как альтернатива чему?
> В первую очередь как альтернатива неиспользованию.
> Буду очень признателен, если вы вкратце опишете альтернативные
> методологии, которые можно противопоставить обсуждаемым.
Это не методологии, а методы, техники.
1) Простые (неструктурированные) требования -- Для представления
пользовательских требований можно обойтись перечислением
функциональных требований безо всякой структуры (кроме группировки по
подсистемам) -- <<Система должна X>>, <<Система должна Y>> -- именно так
люди долгое время работали по IEEE SRS, ГОСТ 24/34.
2) User Story -- техника группировки функциональных требований в
<<пользовательские истории>> из Agile.
3) FDD (Feature Driven Development) -- подход к разработке, основанный
на ключевых функциональных свойствах, которые группируют
функциональные требования, например, <<Отсылка оповещений>>.
4) Scenario -- техника описания пользовательских требований из UCD.
Также рекомендую заглянуть в форум по Use Case: http://www.uml2.ru/forum/index.php?board=34.0
Hienadz Drahun
> UML,
> и в общем случае лучше использовать таблицу из списка Агентов и
> Способов применения.
Не согласен. Если мы рисуем всего одну такую диаграмму для всей
системы, то может быть полезным.
Если же рисовать несколько мелких диаграммок ( один актер - пара
сценариев использования), то в самом деле не имеет никакого смысла.
Sergey Makarov
Sergey Makarov
обрабатывать информацию о
требованиях пользователей - это и есть UCD. К тому-же прошу не
забывать про тематику группы в целом =)
А форум хороший, я в своё время там нашёл недостающие странички
вышеупомянутой книги Вигерса.
Denis Beskov
On 2 мар, 22:25, Sergey Makarov <vela...@gmail.com> wrote:
> Денис, речь идёт об инструментах, позволяющих эффективно извлекать и
> обрабатывать информацию о
> требованиях пользователей - это и есть UCD. К тому-же прошу не
> забывать про тематику группы в целом =)
Ок, я процитирую вас:
> В свете вышесказанного предлагаю обсудить такие методологии, как
> Варианты использования и Сценарии использования (Use case and Usage
> scenarios).
Это не методологии извлечения и обработки требований пользователей
-- это форматы их ПРЕДСТАВЛЕНИЯ.
Также как и User Story, (Unstructured) Functional Requirement,
Feature, Scenario.
При чём тут тематика группы? О чём спросили -- о том и отвечаю.
Sergey Makarov
UX!
> Какие уровни абстракции вы выделяете?
В контексте требований я выделяю следующие уровни абстракции:
- уровень бизнес-требований (business requirements);
- уровень требований пользователей (user requirements);
- уровень функциональных требований (functional requirements).
Use case diagram позволяет представить варианты использования на
уровне бизнес-требований.
User stories, Usage scenarios являются детализированным методом
представления требований пользователей, и включает моделирование
взаимодействия Актёра (Actors) с системой. Этот метод подходит для
выявления и оценки низкоуровневых функциональных требований, что, в
свою очередь, является базисом для разработки UI.
Вот две диаграммы для наглядности:
http://picasaweb.google.com/velarix/Development#5308733407990720626 -
Карл Вигерс, "Разработка требований к программному обеспечению";
http://picasaweb.google.com/velarix/Development#5308767588317968978 -
предложена GEAO (Global Enterprise Architecture Organization).
> Что такое <<концептуальный уровень>>? Какие ещё бывают?
Под термином "концептуальный уровень" - я подразумеваю описание
требований при наивысшем уровне абстракции, на уровне бизнес-целей, в
рамках которых должны разрабатываться пользовательские и
функционалльные требования и продукт в целом. Поясню на примере:
конкретный пункт (шаг) сценария взаимодействия, например -
"Пользователь подтверждает воспроизведение видеозаписи" является
низкоуровневым требованием, а требования "Повысить показатели уровня
лояльности потребителей", или "Сократить издержки на консультирование
пользователей на $X за Y месяцев" являются требованиями наивысшего,
бизнес-уровня.
Теперь несколько слов относительно приведённых вами альтернативных
методов.
> 1) Простые (неструктурированные) требования -- Для представления
> пользовательских требований можно обойтись перечислением
> функциональных требований безо всякой структуры (кроме группировки по
> подсистемам) -- <<Система должна X>>, <<Система должна Y>> -- именно так
> люди долгое время работали по IEEE SRS, ГОСТ 24/34.
Действительно, я с вами согласен, лучше всё записывать, в том числе
результаты применения User stories, Usage scenarios, коими и являются
"простые требования". Всё, что вы предлагаете, это пропустить этап
выявления и обработки информации о пользовательских требованиях и
просто записать их в виде "простого неструктурированного) списка". Это
явно не является "альтернативным методом".
Ваша ссылка на то, что "именно так люди долгое время работали по IEEE
SRS, ГОСТ..." лишь подтверждает неприемлемость самостоятельного
использования такого "метода описания требований", поскольку мы как
раз обсуждаем методы, которые позволят создавать продукты, не такие
"как всегда". Которые будут УДОБНЫ для пользователей, которые позволят
с лёгкостью решать ВСЕ их задачи (или по крайней мере их большую
часть) в рамках бизнес-целей, а не только те, что вы смогли
перечислить в "простом (неструктурированном) списке".
Обсуждаемая проблема заключается в том, что БОЛЬШАЯ часть существующих
систем не отвечают требованиям пользователей, как на уровне
функциональности, так и на уровне UI. То, что вы в таком контексте
предлагаете "Простые (неструктурированные) требования" как
альтернативу Use case и User stories, только подтверждает тот факт,
что вы так и не осознали цели нашего обсуждения.
> 2) User Story -- техника группировки функциональных требований в
> <<пользовательские истории>> из Agile.
User Story - это общее описание обсуждаемого Use Case, их неотъемлемая
часть. Соответственно, данная техника по определению не может быть
альтернативой обсуждаемым методам. Карл Вигерс (и далеко не только
он), в книге "Разработка требований к программному обеспечению",
называет User Story "рабочими версиями или краткими описаниями Use
Case".
> 3) FDD (Feature Driven Development) -- подход к разработке, основанный на ключевых функциональных свойствах, которые группируют функциональные требования, например, <<Отсылка оповещений>>.
Каковы отличия простых (неструктурированных) списков (за исключением
метода группировки) от подхода FDD?
Каковы преимущества подхода FDD перед обсуждаемыми методами с точки
зрения эффективности выявления и обработки информации о требованиях
пользователей? Мне вообще не понятно, чем вы руководствовались, когда
поставили FDD в один ряд c User Story.
> 4) Scenario -- техника описания пользовательских требований из UCD.
В чём отличие Scenario от User Story или Usage scenarios?
> Мой тезис: Use Case Diagram -- самая бестолковая из всего комплекта
UML, и в общем случае лучше использовать таблицу из списка Агентов и
Способов применения. Сами по себе <<плящущие человечки>> ничего не
объясняют.
По моему мнению, Use Case Diagram - это наиболее эффективный способ
КРАТКОГО описания системы с точки зрения вариантов использования, хотя
бы потому, что диаграмма занимает меньше места.
Вот что на этот счёт пишет Вигерс: "Диаграммы вариантов использования
(use-case diagrams,) позволяют получить отличное визуальное
представление о требованиях пользователей".
> Это не методологии извлечения и обработки требований пользователей
> -- это форматы их ПРЕДСТАВЛЕНИЯ.
> Также как и User Story, (Unstructured) Functional Requirement, Feature, Scenario.
Не соглашусь, и аргументирую цитатой Вигерса:
"В течение многих лет аналитики извлекали информацию о требованиях
пользователей из сценариев использования (McGraw и Harbisont,1997).
Сценарием (scenario) называется описание одного варианта использования
системы. Ivar Jacobson с коллегами (1992), Larry Constantine и Lucy
Lockwood (1999), Alistair Cockburn (2001) и многие другие
преобразовали этот подход в МЕТОДИКУ (обратите внимание), где для
сбора информации и моделирования требований применяются варианты
использования."
> При чём тут тематика группы? О чём спросили -- о том и отвечаю.
Тема обсуждения была озвучена в самом начале:
>> необходимо найти инструменты, позволяющие эффективно извлекать и обрабатывать информацию о требованиях пользователей.
Вся соль в том, что задача всего сообщества UХ, моя задача и задача
этого обсуждения заключается в том, чтобы сосредоточится на
пользователях, найти способы выявить и использовать информацию об их
потребностях, и, в конечном итоге, делать по настоящему удобные и
эффективные продукты, как с точки зрения бизнеса, так и с точки зрения
пользователей. Вы же смещаете фокус с пользователей на терминологию.
Именно это я имею ввиду.
Zaur Giyasov
А теперь я, с позволения, прокомментирую.
> Поскольку понимание потребностей пользователей (User Centered Design
> philosophy) позволяет разрабатывать более удобные, востребованные и
> эффективные программные продукты (а следовательно, ведёт к всеобщему
> счастью и удовлетворённости =) .....
Если в основу проектирования интерфейсов закладывать только требования
пользователей, то это будет далеко не гибкая система, которая будет
ограничена требованиями этих же пользователей, хотя при этом она
создана для решения задач в определенной среде.
Для проектирования интерфейса и системы в целом нам необходимо (а в
отдельных случаях это первостепенно, как мне кажется) вооружится
описанием предметной области. Зная тонкости, особенности и частные
случаи, можно из описания того, что нам придется ворочать (стог сена
или макароны), спроектировать соответствующий инструмент (трактор или
вилку). Правда, если макарон будет много то без трактора никак )))
А далее мы будем выдвигать пользовательские требования к "удобству"
использования того или иного инструмента.
Таким образом, как мне кажется, мы приходим к тому, что описание
предметной области дает нам описание системы на концептуальном, высшем
уровне абстракции системы, из которого можно выделить некоторые
функциональные группы или особенности системы. А далее - имея эти
функциональные особенности, собирать требования пользователей к ним.
То есть я веду к тому, что у тебя, Сергей, были выдвинуты
требования.... а к чему?.... откуда?... Предметная область может
состоять из двух-трех основных деталей, а может быть и достаточно
обширна, что в свою очередь может наложить некоторые технологические
рамки, особенно имея ограниченные бюджет и сроки.
> необходимо найти инструменты,
> позволяющие эффективно извлекать и обрабатывать информацию о
> требованиях пользователей.
Под инструментами извлечения я понимаю проведение опросов,
анкетирование, интервью, фокус-группы (обсуждавшиеся в соседней
ветке), предварительное тестирование интерфейса.
А под инструментами обработки - активная мозговая деятельность )))
которая может заключаться в применении к собранным данным факторного,
кластерного и собирательного (только что придумал про собирательный -
не вспоминайте матстат ))) анализа.
А вот уже у инструментами описания, представления и формализации
собранной информации служат затрагиваемые тобой Варианты использования
и Сценарии использования.
> В свете вышесказанного предлагаю обсудить такие методологии, как
> Варианты использования и Сценарии использования (Use case and Usage
> scenarios).
>
> Вышеназванные методологии отлично зарекомендовали себя (Karl E.
> Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на
> собственном опыте.
>
> Предупреждение!
> Для того, чтобы достичь валидности вариантов и сценариев использования
> необходимо проводить регулярные уточняющие сессии с представителями
> пользователей продукта.
> Сценарии использования являются оптимальным инструментом для
> извлечения и обработки уточняющей информации о требованиях, но их
> использование как единственного инструмента для извлечения
> пользовательских требований неприемлемо.
Опять - как с помощью сенариев использвания мы ИЗВЛЕЧЕМ требования? Мы
их детально опишем - да, но извлечь... нет.
А вот твоя фраза
"Важно понимать, что обсуждаемые методологии являются средством
моделирования, которое, в свою очередь, должно быть основано на
реальных фактах."
Это, как мне кажется, верно - здесь ты сам себя исправляешь.
> На сегодняшний день я вижу два взаимодополняющих (но не
> альтернативных) способа формализации вариантов использования:
> 1. используя семантику UML, и
> 2. в текстовом виде.
> Первый способ позволяет кратко описать систему или частный вариант
> использования на концептуальном уровне.
Ну как же на концептуальном, когда в UML диаграммах присутствуют такие
элементы как "обращение к базе данных" и т.д. и т.п. ?
Концептуальный уровень позволяет понять систему целиком, представить
счастливых пользователей, оперировать общими понятиями, а с помощью
UML мы можем описать конкретные действия пользователей.
> Второй способ позволяет произвести низкоуровневое описание, и, что
> самое главное, более понятен неподготовленным представителям
> пользователей, и заказчику продукта.
А вот тут можно удариться в удобство представления данных - когда
заказчику показываешь "Пользователь делает - Система отвечает" и этого
добра у нас примерно на 5-10 листов (как минимум) то ей Богу, читать
это сложно. Текстовый вариант удобен для остлеживания "правильности"
процесса разработки.
> Оба способа имеют преимущества и недостатки и обладают способностью
> синергетически дополнять друг друга
Вот она мысль :) Их целесообразно объединять. Имея перед собой UML
диаграммы, которые показывают действия, составить текстовый вариант
вариантов использования (сорри за тафтологию).
Здесь, кстати, возможно наткнуться на способ абстрактного мышления
отдельного проектироващика. Кому-то, возможно, проще нарисовать, а
кому и написать сначала. Но иметь эти две вещи в процессе сбора и
формализации требований к системе нужно хотя бы для того, чтобы
представить пользователю, заказчику, программисту и т.д. наиболее
удобный для него вариант представления.
Все таки эти подходы к визуализации требований мы рассматриваем не
сами по себе, а в контексте управления неким проектом - а тут, как все
знают, факторов мильён, и один из основных - человеческий.
Sergey Makarov
Видно, что ты старался...
On 3 мар, 08:34, Zaur Giyasov <zaur.giya...@gmail.com> wrote:
> Сергей, отличная работа!
Это про что?
> А теперь я, с позволения, прокомментирую.
>
> > Поскольку понимание потребностей пользователей (User Centered Design
> > philosophy) позволяет разрабатывать более удобные, востребованные и
> > эффективные программные продукты (а следовательно, ведёт к всеобщему
> > счастью и удовлетворённости =) .....
> Если в основу проектирования интерфейсов закладывать только требования
> пользователей, то это будет далеко не гибкая система, которая будет
> ограничена требованиями этих же пользователей, хотя при этом она
> создана для решения задач в определенной среде.
Где я сказал "только"? Естественно, я подразумевал выявление,
формализацию и использование бизнес-требований, различных
нефункциональных требований, также как разработку Wireframes, или
календарного графика работ.
> Для проектирования интерфейса и системы в целом нам необходимо (а в
> отдельных случаях это первостепенно, как мне кажется) вооружится
> описанием предметной области. Зная тонкости, особенности и частные
> случаи, можно из описания того, что нам придется ворочать (стог сена
> или макароны), спроектировать соответствующий инструмент (трактор или
> вилку). Правда, если макарон будет много то без трактора никак )))
Опять таки, я разве сказал что нам не следует проводить исследование и
формализацию (в том числе с помощью нотации UML) бизнес-процессов или
конъюнктуры рынка? Естественно, понадобится проведение большой работы
по сбору и анализу информации, составление достаточного большого
перечня документации.
Об этом я писал здесь: http://upa.org.ru/UsabilityBulletin-30.aspx?EntryID=818.
Речь идёт только о методах, позволяющих более эффективно извлечь и
обработать информацию о пользовательских требованиях.
> А далее мы будем выдвигать пользовательские требования к "удобству"
> использования того или иного инструмента.
> Таким образом, как мне кажется, мы приходим к тому, что описание
> предметной области дает нам описание системы на концептуальном, высшем
> уровне абстракции системы, из которого можно выделить некоторые
> функциональные группы или особенности системы. А далее - имея эти
> функциональные особенности, собирать требования пользователей к ним.
> То есть я веду к тому, что у тебя, Сергей, были выдвинуты
> требования.... а к чему?.... откуда?...
а к чему?
Требования к продукту.
откуда?
Что значит "откуда"?
Если речь об источниках сбора пользовательских требований, то тут и
интервью, и фокус группы, и приглашение в проектную команду
"сторонников продукта". Заур, обрати внимание на формулировки:
"источники требований" и "источники информации о требованиях", "методы
извлечения требований" и методы "извлечения информации о требованиях".
Если речь идёт об основаниях для принятия решений о том, следует ли
включать какое-либо пользовательское требование в спецификацию
требований, то таким основанием, на мой взгляд, должны быть бизнес-
цели создания продукта, проектные ограничения (ограничения сроков,
доступные ресурсы).
Предметная область может
> состоять из двух-трех основных деталей, а может быть и достаточно
> обширна, что в свою очередь может наложить некоторые технологические
> рамки, особенно имея ограниченные бюджет и сроки.
>
> > необходимо найти инструменты,
> > позволяющие эффективно извлекать и обрабатывать информацию о
> > требованиях пользователей.
>
> Под инструментами извлечения я понимаю проведение опросов,
> анкетирование, интервью, фокус-группы (обсуждавшиеся в соседней
> ветке), предварительное тестирование интерфейса.
> А под инструментами обработки - активная мозговая деятельность )))
> которая может заключаться в применении к собранным данным факторного,
> кластерного и собирательного (только что придумал про собирательный -
> не вспоминайте матстат ))) анализа.
Как я уже писал выше, думаю, что нужно разделять "методы извлечения
требований" (семинары, фокус-группы и пр.) и "методы извлечения и
обработки информации о требованиях" (методы моделирования и
представления информации).
"В течение многих лет аналитики извлекали информацию о требованиях
пользователей из сценариев использования (McGraw и Harbisont,
1997)" (Wiegers 2004).
> А вот уже у инструментами описания, представления и формализации
> собранной информации служат затрагиваемые тобой Варианты использования
> и Сценарии использования.
Абсолютно согласен, добавлю только, что обсуждаемые методы являются
инструментами обработки, эффективной конвертации абстрактных
пользовательских историй (User stories) в спецификации функциональных
требований, другими словами методом преобразования требований в
представлении пользователей в форму, полезную разработчикам.
>
> > В свете вышесказанного предлагаю обсудить такие методологии, как
> > Варианты использования и Сценарии использования (Use case and Usage
> > scenarios).
>
> > Вышеназванные методологии отлично зарекомендовали себя (Karl E.
> > Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на
> > собственном опыте.
>
> > Предупреждение!
> > Для того, чтобы достичь валидности вариантов и сценариев использования
> > необходимо проводить регулярные уточняющие сессии с представителями
> > пользователей продукта.
> > Сценарии использования являются оптимальным инструментом для
> > извлечения и обработки уточняющей информации о требованиях, но их
> > использование как единственного инструмента для извлечения
> > пользовательских требований неприемлемо.
>
> Опять - как с помощью сенариев использвания мы ИЗВЛЕЧЕМ требования? Мы
> их детально опишем - да, но извлечь... нет.
Да, мы извлечём и обработаем информацию о требованиях, но не сами
требования, именно по этой причине я сделал "Предупреждение!" с
восклицательным знаком. =))
Прочитай, пожалуйста, ещё раз, этот абзац:
> > Сценарии использования являются оптимальным инструментом для
> > извлечения и обработки уточняющей информации о требованиях, но их
> > использование как единственного инструмента для извлечения
> > пользовательских требований неприемлемо.
> А вот твоя фраза
> "Важно понимать, что обсуждаемые методологии являются средством
> моделирования, которое, в свою очередь, должно быть основано на
> реальных фактах."
>
> Это, как мне кажется, верно - здесь ты сам себя исправляешь.
Заур, вот здесь как раз ты себя исправляешь =))
> > На сегодняшний день я вижу два взаимодополняющих (но не
> > альтернативных) способа формализации вариантов использования:
> > 1. используя семантику UML, и
> > 2. в текстовом виде.
> > Первый способ позволяет кратко описать систему или частный вариант
> > использования на концептуальном уровне.
>
> Ну как же на концептуальном, когда в UML диаграммах присутствуют такие
> элементы как "обращение к базе данных" и т.д. и т.п. ?
> Концептуальный уровень позволяет понять систему целиком, представить
> счастливых пользователей, оперировать общими понятиями, а с помощью
> UML мы можем описать конкретные действия пользователей.
В каких конкретно UML диаграммах присутствуют такие элементы как
"обращение к базе данных?
Что ты подразумеваешь под элементами, часть семантики UML?
Смею обратить твоё внимание на то, что мы обсуждаем именно Use Case
Diagram (диаграмму прецедентов) и ознакомиться с ней поближе. Хотя бы
прочитать определение и посмотреть несколько примеров.
> > Второй способ позволяет произвести низкоуровневое описание, и, что
> > самое главное, более понятен неподготовленным представителям
> > пользователей, и заказчику продукта.
> А вот тут можно удариться в удобство представления данных - когда
> заказчику показываешь "Пользователь делает - Система отвечает" и этого
> добра у нас примерно на 5-10 листов (как минимум) то ей Богу, читать
> это сложно. Текстовый вариант удобен для остлеживания "правильности"
> процесса разработки.
Заказчику не нужна документация. Покажите заказчику эффективную
систему, и этого будет довольно.
> > Оба способа имеют преимущества и недостатки и обладают способностью
> > синергетически дополнять друг друга
>
> Вот она мысль :) Их целесообразно объединять. Имея перед собой UML
> диаграммы, которые показывают действия, составить текстовый вариант
> вариантов использования (сорри за тафтологию).
Ах, вот она мысль! =)))
Кроме UML-диаграмм, для эффективного и полного составления Usage
scenarios стоит также иметь перед собой пользовательские истории (User
stories), сформулированные на основании полевых исследований (тех
самых интервью, семинаров и фокус групп).
Sergey Makarov
> Здесь, кстати, возможно наткнуться на способ абстрактного мышления
> отдельного проектироващика. Кому-то, возможно, проще нарисовать, а
> кому и написать сначала. Но иметь эти две вещи в процессе сбора и
> формализации требований к системе нужно хотя бы для того, чтобы
> представить пользователю, заказчику, программисту и т.д. наиболее
> удобный для него вариант представления.
> Все таки эти подходы к визуализации требований мы рассматриваем не
> сами по себе, а в контексте управления неким проектом - а тут, как все
> знают, факторов мильён, и один из основных - человеческий.
Факторов может быть и много, но с ними гораздо проще совладать, если
каждый член проектной команды будет выполнять определённые задачи и
нести конкретную ответственность.
Программист не реализует Варианты использования (Use case), поэтому
составление спецификации функциональных требований на основании
системных требований, пользовательских требований, бизнес-правил и
другой информации является задачей аналитика, обладающего должными
навыками и способностями.
Evgeniya Zhadyaeva
"Опять - как с помощью сенариев использвания мы ИЗВЛЕЧЕМ требования?
Мы
их детально опишем - да, но извлечь... нет. "
Вообще сценарии использования давно и эффективно используют для
извлечения требований.
Примеры можно найти в статьях зарубежных авторов.
Иногда, они являются самым верным средством, для того, чтобы поймать
требования контекста.
Речь идет о так называемых, "as is" сценариях ( не в формате use
case).
Эти сценарии описывают, документируют способ взаимодействия с
продуктом или его близкими аналогами.
Они являются результатом изучения пользователей, контекста их жизни,
целей и прочего.
Например, рассмотрим кусок вероятного сценария использования:
"Мария обычно совмещает просмотр телевизора и приготовление еды.
Она включает его, переключает на одну из передач и начинает готовку.
Через некоторое время начинается сериал, и она переключает канал,
чтобы не пропустить серию."
Отсюда, можно выявить следующие пользовательские требования,
обусловленные контекстом использования продукта:
Вероятно, что управление пультом будет неудобно Марии, так как ее руки
могут быть в муке, тесте, быть мокрыми и т.п.
Если мы предложим как решение - управление голосом, то должны учесть,
что на кухне может быть довольно шумно из-за миксера, комбайна или
шума воды. Отсюда технологическое требование (или вопрос): позволит ли
технологическое решение вычленять "из шума" голос человека?
Denis Beskov
On 3 мар, 07:12, Sergey Makarov <vela...@gmail.com> wrote:
> Денис, ещё раз напомню, что целью нашего обсуждения является улучшение
> UX!
Да что вы говорите!
Т.е. по результатам нашего обсуждения UX должен быть улучшен? Чей?
Где?
Я под такой темой не подписывался, печати не ставил, позвольте мне
обсуждать то,
что мне интересно и с теми целями, которые мне близки.
> В контексте требований я выделяю следующие уровни абстракции:
> - уровень бизнес-требований (business requirements);
> - уровень требований пользователей (user requirements);
> - уровень функциональных требований (functional requirements).
Можно было просто сослаться на Вигерса :)
> Use case diagram позволяет представить варианты использования на
> уровне бизнес-требований.
Я так и не понял. Из вашего примера ниже:
Бизнес-требование -- <<Повысить показатели уровня лояльности
потребителей>>.
Допустим, use case, который как-то, прямо или опосредованно (через
промежуточные уровни требований),
участвует в его реализации, звучит как <<Просмотреть видео-файл>>.
В каком смысле ДИАГРАММА с последним use case НАХОДИТСЯ на уровне
бизнес-требований?
> User stories, Usage scenarios являются детализированным методом
> представления требований пользователей, и включает моделирование
> взаимодействия Актёра (Actors) с системой. Этот метод подходит для
> выявления и оценки низкоуровневых функциональных требований, что, в
> свою очередь, является базисом для разработки UI.
Абсолютно согласен!
Это методы ВЫЯВЛЕНИЯ функциональных требований
и одновременно методы ПРЕДСТАВЛЕНИЯ пользовательских требований.
Т.е. мы проводим интервью, изучаем работу существующей системы --
таким образом,
собираем информацию о возможных пользовательских требованиях, а затем,
в ходе их описания
в форматах UC, US, S -- выявляем функциональные.
> Вот две диаграммы для наглядности:http://picasaweb.google.com/velarix/Development#5308733407990720626-
> Карл Вигерс, "Разработка требований к программному обеспечению";http://picasaweb.google.com/velarix/Development#5308767588317968978-
> предложена GEAO (Global Enterprise Architecture Organization).
Я хорошо знаком с источниками обеих этих картинок)
Только связи с Архитектурой Предприятия тут не вижу.
Вроде речь шла о UX Продуктов и Систем, при чём EA?
> > Что такое <<концептуальный уровень>>? Какие ещё бывают?
> Под термином "концептуальный уровень" - я подразумеваю описание
> требований при наивысшем уровне абстракции, на уровне бизнес-целей.
Т.е. <<концептуальный>> -- он же уровень бизнес-требований?
> Действительно, я с вами согласен, лучше всё записывать, в том числе
> результаты применения User stories, Usage scenarios, коими и являются
> "простые требования". Всё, что вы предлагаете, это пропустить этап
> выявления и обработки информации о пользовательских требованиях и
> просто записать их в виде "простого неструктурированного) списка". Это
> явно не является "альтернативным методом".
Я ничего не предлагаю! Вы сами попросили уточнить, а какие
действительно
альтернативы имеются, я их описываю.
Для чего нужны идеальные модели?
Чтобы иметь возможность оценивать нашу.
Так же и здесь -- традиционные методы надо знать, чтобы понимать,
при каком приросте результативности относительно <<новые>> методы
имеет смысл применять.
> Ваша ссылка на то, что "именно так люди долгое время работали по IEEE
> SRS, ГОСТ..." лишь подтверждает неприемлемость самостоятельного
> использования такого "метода описания требований", поскольку мы как
> раз обсуждаем методы, которые позволят создавать продукты, не такие
> "как всегда".
Кто мы? Впервые слышу о подобной постановке обсуждения.
Это в рамках данной темы или группы?
> Которые будут УДОБНЫ для пользователей, которые позволят
> с лёгкостью решать ВСЕ их задачи (или по крайней мере их большую
> часть) в рамках бизнес-целей, а не только те, что вы смогли
> перечислить в "простом (неструктурированном) списке".
Да вы утопист )
> Обсуждаемая проблема заключается в том, что БОЛЬШАЯ часть существующих
> систем не отвечают требованиям пользователей, как на уровне
> функциональности, так и на уровне UI.
Где обсуждаемая проблема???? Где и кто её ставил?
Я наверное что-то пропустил, дайте плс ссылку, о чём речь.
> То, что вы в таком контексте
> предлагаете "Простые (неструктурированные) требования" как
> альтернативу Use case и User stories, только подтверждает тот факт,
> что вы так и не осознали цели нашего обсуждения.
О целях в любой совместной деятельности принято договариваться,
а не навязывать, причём через 20 реплик после начала дискуссии.
Shared Vision, все дела.
> User Story - это общее описание обсуждаемого Use Case, их неотъемлемая
> часть. Соответственно, данная техника по определению не может быть
> альтернативой обсуждаемым методам. Карл Вигерс (и далеко не только
> он), в книге "Разработка требований к программному обеспечению",
> называет User Story "рабочими версиями или краткими описаниями Use
> Case".
Поскольку можно остановиться на Casual Use Case, который эквивалентен
User Story ,
не превращая его в Fully Dressed Use Case -- то в этом смысле User
Story -- альтернатива.
Есть куча XP-шников, которые ничего больше User Story никогда не
видели и не писали.
> > 4) Scenario -- техника описания пользовательских требований из UCD.
> В чём отличие Scenario от User Story или Usage scenarios?
В акцентах, как у семейства близких методов.
Usage scenario -- это структурированная последовательность шагов.
User scenario -- нет.
> По моему мнению, Use Case Diagram - это наиболее эффективный способ
> КРАТКОГО описания системы с точки зрения вариантов использования, хотя
> бы потому, что диаграмма занимает меньше места.
Таблица из 30 строк c перечнем Use Case может войти читабельно на А4
(по крайней мере, у меня так получается). Диаграмма с 30 овалами --
вряд ли.
О чём вы?
> Вот что на этот счёт пишет Вигерс: "Диаграммы вариантов использования
> (use-case diagrams,) позволяют получить отличное визуальное
> представление о требованиях пользователей".
Тогда почему в книге Вигерса в примере документа Use Case
он даёт их перечень в виде таблицы, а не диаграммы, ваши мысли? :)
> Не соглашусь, и аргументирую цитатой Вигерса:
> "В течение многих лет аналитики извлекали информацию о требованиях
> пользователей из сценариев использования (McGraw и Harbisont,1997).
> Сценарием (scenario) называется описание одного варианта использования
> системы. Ivar Jacobson с коллегами (1992), Larry Constantine и Lucy
> Lockwood (1999), Alistair Cockburn (2001) и многие другие
> преобразовали этот подход в МЕТОДИКУ (обратите внимание), где для
> сбора информации и моделирования требований применяются варианты
> использования."
Ок, принято!
Sergey Makarov
On 4 мар, 23:32, Denis Beskov <denis.bes...@gmail.com> wrote:
> On 3 мар, 07:12, Sergey Makarov <vela...@gmail.com> wrote:
>
> > Денис, ещё раз напомню, что целью нашего обсуждения является улучшение
> > UX!
>
> Да что вы говорите!
> Т.е. по результатам нашего обсуждения UX должен быть улучшен? Чей?
> Где?
UX пользователей ИТ-продуктов, на процесс разработки которых имеют
непосредственное влияние участники настоящего обсуждения =)
Не буду отвечать на вопрос "где", предполагаю, что он риторический)
> Я под такой темой не подписывался, печати не ставил, позвольте мне
> обсуждать то, что мне интересно и с теми целями, которые мне близки.
Каковы же цели, которые вам близки?
> > В контексте требований я выделяю следующие уровни абстракции:
> > - уровень бизнес-требований (business requirements);
> > - уровень требований пользователей (user requirements);
> > - уровень функциональных требований (functional requirements).
>
> Можно было просто сослаться на Вигерса :)
Вигерс здесь не причём, вы можете выделить другие уровни абстракции?
> Да вы утопист )
Денис, ваши заявления пессимистичны, причём безосновательно.
Хотя, я бы предпочёл рискнуть стать утопистом, к счастью, этого даже
не требуется, поскольку я опираюсь на реальные факты. Думаю, что из
миллионов изобретений и технологий не осталось даже десятка тех,
которые не стали удобнее и эффективнее за последнее 20 лет, возможно,
за исключением попросту не используемых (чего не сказать про ИТ).
Замечу, 20 лет - это масштаб человеческой жизни (поэтому никак не
возьму в толк, что здесь утопического).
В свете вышесказанного, считаю, что стремление сделать мир удобнее
опирается на фундаментальные, естественные тенденции. Люди всегда
будут любить то, что позволяет им быстрее, проще и комфортнее
достигать своих целей, не правда ли?
Sergey Makarov
и обрабатывать информацию о
требованиях пользователей"? Ммм?