Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Denis Beskov

1547
* известны ли вам другие способы описания сценариев?
1а. Свободное текстовое описание, без пунктов.
5. Таблица, где столбцы относятся к разным агентам.
6. Рисованый комикс.

Цитировать
* для приведенных мной в пп. 1 и 2 способах реализации сценариев известны ли какие-нибудь общепринятые правила, нотации и пр. ?
1 — В MSF есть Scenario Template. В Agile есть User Story. В HCI/UCD есть свои Scenario Templates. Прям стандартов не встречал.

1548
В продуктовом магазине есть N касс.

Будет ли эффективно с точки зрения бизнес-показателей компании выделить одну из касс только для покупок объёмом не более 2 товаров?

   1. В каком случае?
   2. Какие бизнес-показатели будут вовлечены в данное изменения?
   3. Какие дополнительные действия необходимо предпринять, чтобы добиться условий из пункта 2?

1549
В общем и целом, не залезая в детали, я бы сказал, что да.

1550
Цитировать
А что делать с применяемым ПО
Какую деятельность вы ведёте? С какой целью? Какие проблемы возникают?

1551
Примеры / Re: Права доступа
« : 19 Октября 2008, 00:31:13 »
Скажите, а как описываются права доступа?
Я не в курсе, поиск не особо помог, шаблоны проектирования еще не знаю (а они, походу, тоже не помогут).
Есть книга по Security Patterns, там есть слово ACL (Access Control List).

1552
Как мы делаем.

Строим модель предметной области.
Пишем Способы Применения, сопровождая их Структурами Данных, Правилами и Ограничениями.
Разрабатываем Модель Навигации, определяя перечень Экранов, необходимых для покрытия этих Способов Применения.
Делаем Макеты экранов, опираясь на Сценарии и Структуры Данных.
Отдаём Макеты на согласование Разработчикам.
Разработчики согласовывают и позже, при реализации показывают реализованное в ходе итерации.
В ходе реализации итерации N мы прототипируем следующие Способы Применения и вносим корректировки в макеты итерации N-1 (функциональность которых уже доступна и тестируется), складируем доработки с обоснованиями в план итерации N+1.

1553
Теперь детально.

Если оставаться инструментом в чужих руках — то такие проблемы будут возникать всегда.

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

Второй уровень — это понимание того, как эти задачи соотносятся друг с другом. Как часто возникает та или иная задача и в какой связи.

Третий уровень — понимание контекста использования, а именно — ЧТО это за люди, которые пытаются выполнять эти задачи, что ими движет, зачем они это делают, в каком случае они будут считать, что система помогает им в выполнении задач, какие другие интерфейсы им нравятся и почему, какие операции являются избыточными и т.д.

Чтобы не возникало постоянных переделок, необходимо фиксировать пользовательские задачи и автоматизировать их, разбирая по итерациям. При попытке внесения изменений требовать обоснование в терминах критериев успеха данного проекта — больше денег, меньше затрат, меньше процент ошибок, больше количество обработанных заявок и т.д — всё измеренное в «на сколько именно»?

1554
Общая рекомендация -- бить по яйцам человека, который даёт инженеру установку "должно быть все красиво".

1555
Присоединиться к вам, что-ли? Ан нет, я всё-таки считаю, что тему надо выбирать и формулировать самому, т.к. убивать 3 года на несвоё не хочется :)

У меня вот вопрос с другой стороны — тематика исследования и моделирования успешности IT-продуктов на какую специализацию тянет?

1556
Я мог поговорить с ГУ-ВШЭ

1557
Если других голосов не будет, то темой станут «Базовые инструменты и методы аналитика».

1559
Мне было бы интересно провести нечто вроде дискуссионного клуба, опираясь на те вопросы, которые я предлагал для семинаров.

1560
Смотрим сюда, изучаем:
http://www.visual-literacy.org/periodic_table/periodic_table.html

И далее можем давать ответы самостоятельно.