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

×


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

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


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

391
А как тогда звучит "using"? "Юсин"?
Abbyy lingvo тоже согласен со мной: [ju:z]
Есть глагол to use в котором s читается звонко, есть существительное use, где s читается глухо. Во фразе use case первое слово — это существительное: https://answers.yahoo.com/question/index?qid=20081206221932AAYRSJb

Рекомендую если уж читать lingvо, то целиком всю статью, а не только первую половину: http://slovari.yandex.ru/use/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/

Произношение:
http://slovari.yandex.ru/use%20case/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/

392
По вашим с Григорием сообщениям я понял что вы поддерживаете мнение davvol по поводу "диаграммы бесполезных действий". Поэтому хотел увидеть выделение общего поведения без использования тех самых "бесполезных действий".
А кто просил или требовал выделения «общего поведения» и на каком основании?


393
Как бы вы выделили общие части основных сценариев юзкейсов, такие как вставка карты, ввод пин-кода, выбор услуги?
А зачем такой вопрос?

NB: use case звучит по английски как юскейс

394
Какую технологию разработки требований применяю я:

1. Предварительные исследования и проблематизация
Выявление заинтересованных лиц
Изучение и описание автоматизируемой деятельности
Изучение системы понятий, существующих в предметной области
Разработка концептуальной модели предметной области
Создание словаря терминов
Исследование и описание проблемных ситуаций
Создание целостной модели проблемы

2. Разработка бизнес-требований
Постановка целей преобразований/автоматизации
Определение перечня процессов и бизнес-функций, которые должны быть автоматизированы/улучшены
Определение целевых показателей процессов
Определение перечня задач пользователей
Определение организационных ограничений

3. Создание концепции приложения/системы
Определение границ системы
Определение ключевых возможностей системы
Определение приоритетов свойств системы

3. Разработка пользовательских требований
Описание ролей пользователей
Разработка сценариев решения задач пользователем
Уточнение предположений о характеристиках пользователей
Разработка требований к качеству в использовании

4. Разработка технических требований к ПО
Разработка реестра функциональных требований
Разработка диаграммы и словаря данных
Разработка требований к внешнему качеству системы
Описание интерфейсов взаимодействия с окружением
Уточнение технических ограничений и предположений


395
Еще вопрос: Так вот эти контекстные сценарии к какому из мной предпочитаемых вариантов подходят?
Можно ли параллельно до какой-то точки пробовать работать с требованиями по AGILE и Вигерсу одновременно?
Требования не возникают из воздуха, они ВЫЯВЛЯЮТСЯ. Анализ контекстных сценариев — это одна из множества техник выявления требований. Эта техника может применяться как в Agile, так и в классическом подходе к работе с требованиями.

Формально в Agile требований нет, есть поводы для разговора —  User Story. User Story как единица функциональности может иметь различный набор приложений, поясняющих её — макеты интерфейсов, тесты, бизнес-правила. Вот только по идеологии Agile создавать такие приложения в отрыве от команды нельзя, они делаются под конкретный коллектив по необходимости.

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

396
Обратите внимание, что ваш контекстный сценарий описывает, как гик нашёл программку и баловался с ней, а не то, как у здорового нормального человека (шучу) возникла потребность и он её решил с помощью вашего архиватора.

Он смог запаковать! Он смог распаковать! ЗАЧЕМ???

Решайте значимые проблемы людей, а не (только) играйтесь с технологиями.

Если девушка Алиса хочет послать реферат на 30 Гб однокурснице, а он не пролазит в почту — вот реальная ситуация, в которой её может спасти архиватор (и не только).

Программы должны решать реальные проблемы людей, иначе весь процесс разработки требований превращается в фантазирование по применению одних технологий, не несущих ценности (например, задействование всех 9 диаграмм UML) для создания других технологий, не несущих ценности.

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

397
Юскейс — это именованная группа сценариев по получению нужного пользователю результата, после которого он может закончить сеанс использования системы.

398
Например, если вы хотите поработать с «требованиями» в формате Agile то можно остановиться на том списке 1-7, который вы написали выше.

Если вы хотите написать требования к ПО в формате IEEE 830, то там много возможных работ.

Если вы хотите написать требования в формате Вигерса, то там тоже много возможных работ.

Вам какой вариант интереснее?

400
Это перечень пользовательских требований в формате неполных пользовательских историй (без очень полезного компонента «зачем»), а не контекстные сценарии.

Вы свалились ещё глубже по процессу.

401
А кто сказал слово «история»?

Context Scenario, Usage Scenario, Use Case и User Story — это 4 разных человека. Я говорил про первый.

402
Значит все же необходимо написать Vision, так как там есть раздел про термины и сокращения?
Термины и сокращения — это типовая часть ЛЮБОГО документа, а не только концепции. Если проект большой, делается в виде отдельного документа — Глоссария. В вашем случае вы можете или ввести определение по тексту и далее его использовать, или использовать более точные формулировки, типа «Создать упакованный ФАЙЛ».

403
Use Cases — это и есть часть пользовательских требований (функциональных).

Для продуктов для домашнего пользования я рекомендую выделять use case'ы из контекстных сценариев.

Разработайте несколько описаний жизненных ситуаций для персонажей и из них станет понятно, какие юскейсы нужны.

404
Ответить на этот вопрос однозначно нельзя. Я рекомендую формулировки способов применения в виде «Сделать <результат>», например, «Написать письмо», «Забронировать билет». В ваших формулировках непонятно как минимум, архив — это файл или виртуальное пространство типа vault? Зачем тестировать архив? Что это за дикие пользователи такие, для которых тестирование архивов является ценным результатом?

Способы применения не появляются из воздуха, лучше их выявлять из контекстных сценариев (или бизнес-процессов). Вы пропустили важные шаги.

405
На типовой диаграмме способов применения приложения показываются все группы сценариев, которые заканчиваются ценным для пользователя результатом, который он может пойти и применять уже за рамками приложения.