кейс — Викисловарь
Морфологические и синтаксические свойства[править]
кейс
Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 1a по классификации А. А. Зализняка).
Корень: -кейс- [Тихонов, 1996].
Произношение[править]
Семантические свойства[править]
Значение[править]
- плоский кожаный ручной чемоданчик для документов, газет, журналов и т. п. с кодовым замком, дипломат ◆ Николай сел за стол, достал из кейса кое-какие бумаги и счета. Ксения Яхонтова, «Смятение Анастасии», 1996–1998 г. (цитата из Национального корпуса русского языка, см. Список литературы) ◆ Между ними стоял тот самый «ядерный чемоданчик», который от множества похожих на него крутых кейсов внешне мало чем отличался (разве только тем, что рядом с ним часто был толстый кофр — пункт мобильной космической связи, из которого торчал край толстой антенны с шариком на конце). В. Н. Баранец, «Генштаб без тайн», 1999 г. (цитата из Национального корпуса русского языка, см. Список литературы) ◆ Людмила нашла чемодан, то есть внушительных размеров кейс, и удивилась его тяжести.
- чемодан для хранения музыкальных инструментов ◆ Отсутствует пример употребления (см. рекомендации).
Синонимы[править]
- дипломат, портфель, чемодан
- футляр
Антонимы[править]
Гиперонимы[править]
- сумка
- контейнер
Гипонимы[править]
- пресс-кейс, атташе-кейс
Родственные слова[править]
| Ближайшее родство | |
Этимология[править]
Происходит от англ. case «коробка, ящик, чемодан», далее от ??
Фразеологизмы и устойчивые сочетания[править]
Перевод[править]
Анаграммы[править]
Библиография[править]
- Новые слова и значения. Словарь-справочник по материалам прессы и литературы 80-х годов / Под ред. Е. А. Левашова. — СПб. : Дмитрий Буланин, 1997.
 | Для улучшения этой статьи желательно:
|
Морфологические и синтаксические свойства[править]
кейс
Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 1a по классификации А. А. Зализняка).
Корень: -кейс-.
Произношение[править]
Семантические свойства[править]
Значение[править]
- проф. конкретная ситуация в бизнесе, используемая для выработки деловых решений в ходе её анализа ◆ Отсутствует пример употребления (см. рекомендации).
Синонимы[править]
Антонимы[править]
Гиперонимы[править]
Гипонимы[править]
Родственные слова[править]
Этимология[править]
Происходит от англ. case «сценарий», далее от ??
Фразеологизмы и устойчивые сочетания[править]
Перевод[править]
Библиография[править]
- Новые слова и значения. Словарь-справочник по материалам прессы и литературы 90-х годов XX века. — СПб. : Дмитрий Буланин, 2014. — ISBN 978-5-86007-637-2.
Что такое кейс и кейс-метод обучения?
Кейс — это строящееся на реальных фактах описание проблемной ситуации, которая требует решения. Ситуация может быть из сферы бизнеса или юриспруденции, медицины или строительства. Объединяет их то, что в каждом случае есть пакет (кейс) заданий, не имеющих точного решения, и требуется в сложившихся условиях предложить определенный вариант действий.
Обычно происхождение термина одни связывают с английским словом case (портфель, небольшой чемодан), другие – с латинским casus (нестандартная, трудноразрешимая ситуация). И те, и другие, как вы видите, в чем-то правы.
Любые бизнес-структуры ежедневно сталкиваются с задачами, не имеющими определенного решения и требующими управленческих решений со стороны менеджмента компании. Каждый такой кейс требует комплексного анализа ситуации, выработки гипотез, предложения эффективных мер по решению поставленной задачи, а также построения финансовой модели решения.
Пример бизнес-кейса может быть таким: компании необходимо разработать стратегию продвижения нового продукта на рынок шоколадных изделий. Для этого необходимо проанализировать отрасль, конкурентов, провести анализ целевой аудитории, доработать продукт, чтобы он удовлетворял потребностям потребителей и обладал конкурентными свойствами, продумать маркетинговую кампанию, составить план работы и оценить риски и финансовые показатели проекта.
Решить кейс – это значит исследовать предложенную ситуацию (кейс), собрать и проанализировать информацию, предложить возможные варианты действий и выбрать из них наиболее предпочтительный вариант.
Предлагать определенное решение в проблемных ситуациях, не имеющих одного «правильного» решения – это ежедневная практика юриста, врача, менеджера, политика, военноначальника… Поэтому важно учиться этому, а не только изучать теорию.
Кейс-метод обучения
Кейс—метод обучения (англ. Case method, кейс-метод,) – техника обучения, использующая описание реальных экономических, социальных и бизнес-ситуаций.
Первую особенность мы уже назвали – кейс не имеет правильного ответа, который нужно найти, используя стандартные формулы и правила.
Во—вторых, информация, с которой приходится работать, принимая решение, зачастую неполна, противоречива и постоянно меняется.
В—третьих,
время на решение кейса, как правило, ограничено.Согласитесь, в жизни не раз приходится сталкиваться с подобным. В бизнесе, например, редко есть возможность выяснить все детали и иметь перед глазами полную картину. Как правило, приходится действовать в условиях неопределенности и нехватки информации, искать нестандартные и креативные решения, быстро выбирать определенное решение из нескольких эффективных, причем, в условиях ограниченного времени, стресса, противоречивой информации.
Кейсы имитируют настоящие ситуации и строятся на реальных фактах. Через разбор реальных ситуаций формируется умение анализировать ситуации и самостоятельно принимать решения в реальной жизни.
Преимущества кейс—метода обучения
По сравнению с традиционными методами обучения кейс-метод имеет ряд неоспоримых преимуществ.
- Традиционные методы ориентированы на изучение чего-либо, а кейс-технологии – на применения имеющихся знаний в конкретной ситуации для решения определенной проблемы. Можно сказать, что кейс метод позволяет соотносить теорию с реальной жизнью и формирует навыки использования теории, методов и принципов, что дает более широкое представление о предмете нежели исключительно академическое образование.
- В кейс-методе акцент при обучении делается не на овладевание готовым знанием, а на его выработку. Не повторить, а найти новое нестандартное решение – это увлекательно и интересно. Обучающиеся оказываются эмоционально вовлечены и поглощены процессом, что приводит к более эффективному усвоению знаний и навыков.
- Кейс-метод позволяет совершенствовать навыки, которые оказываются крайне необходимы в реальной жизни (причем, как в профессиональной, так и в повседневной), развитию которых традиционные методы обучения:
Навыки работы с информацией, аналитические навыки
Умение искать недостающие данные, выделять существенную и несущественную информацию, в сжатые сроки анализировать и перерабатывать большие массивы информации, структурированно и логично мыслить, делать гипотезы и предположения, логично и структурированно оформлять результатыТворческие навыки
Решение кейса требует умения мыслить нестандартно и самостоятельно, быть креативным и уметь предлагать альтернативные варианты решения проблемы, которые нельзя найти логическим путем
«Мягкие навыки» (soft skills)
Организовывать работу команды, улаживать конфликты, грамотно формулировать и отстаивать свое мнение, убеждать, искать компромиссы, презентовать свое решение перед публикой, вести дискуссию, слушать оппонентов, контролировать себя и т.д.
Новый метод с давней историей
В бизнес обучение кейс-метод тоже пришёл из Гарварда – в 1908 году была основана Гарвардская школа бизнеса. Идея строить обучение вокруг обсуждения проблем, связанных с управлением бизнесом, возникла еще у первого декана школы Эдвина Гэя, а первый пробный курс под названием «Искусство ведения бизнеса» был прочитан в 1912 году. Альтернативой учебникам стали интервью с ведущими предпринимателями и топ-менеджерами компаний и написанные на их основе подробные отчеты о том, как они решали ту или иную ситуацию, а также о факторах, влияющих на их деятельность.
Настоящий расцвет кейс-метода наступил в 1919 году, когда деканом Бизнес школы Гарварда стал банкир Уоллес Донэм, который был горячим сторонником его применения. Основной причиной сложностей распространения метода было отсутствие готовых материалов, подобных опубликованным сборникам судебных решений. В 1920-м был издан первый сборник кейсов, после чего вся система обучения менеджменту в Гарвардской школе была переведена на case study Преподаватели Гарвардской школы бизнеса активно способствовали его распространению, публикуя книги, учебные пособия, сборники кейсов и занимаясь обучением преподавателей, еще не использовавших метод. В 50-е годы бизнес кейсы стали активно использоваться и в Западной Европе.
В настоящее время в Гарварде каждый год разрабатывается примерно 350 новых кейсов, рядовой студент за время обучение в престижнейшем университете США разбирает до 700 кейсов. Всем известно, что выпускники Гарварда – одни из наиболее востребованных людей на рынке труда и одни их самых успешных бизнесменов. Наиболее ярким примером является Марк Цукерберк – основатель социальной сети Facebook и самый молодой долларовый миллиардер в мире.
Для России кейс-технологии или кейс-метод обучения – сравнительно новое явление. Распространение они стали получать лишь в 90-ые годы XX-го века на базе нескольких московских вузов. В 2007-м был проведен первый чемпионат России по решению бизнес-кейсов. В 2009-м году популярность чемпионата выросла настолько, что в нем приняли участие 3500 студентов из 15 городов России.
Кейс что это такое для сайта услуг
В сегодняшней статье о том, что это такое — кейс в портфолио (вообще и на сайте услуг в частности), я обращаюсь в первую очередь, конечно же, к моим уважаемым заказчикам. Здравствуйте! Впрочем, копирайтерам, возможно, она тоже будет интересна, ведь это сравнительно новое направление уже наших — веб-райтерских услуг. И делать толковые кейсы из порой (пардон!) невнятного бормотания заказчиков — задача не из легких. Давайте разберемся с этим вопросом. Поехали?
Как выглядит обычно портфолио на сайтах услуг
То, что на подобных веб-ресурсах именуют гордым словом «портфолио», чаще всего бывает представлено в виде свалки. Да, да! Другого слова тут и не подберешь: именно свалка. Почему? Потому что в этот раздел бывает понапихано много изображений без каких-либо пояснений. Встречаются два варианта:
- Либо это красивые и качественные фото, вызывающие чувство «дежа вю» (я это где-то уже видел). И ваше впечатление вас не обманывает.
- Либо это снимки чересчур «любительского» качества и слишком натуралистичные. В кадре могут валяться инструменты, брошенный мусор, а готовые изделия выглядят полуфабрикатами — плохая реклама для компании.
Как показывает мой опыт и короткий аудит страниц выдачи по нескольким коммерческим запросам, чем выше позиции сайта, тем более качественно оформлено их портфолио. И это неудивительно, ведь этот раздел при должном к нему внимании, во-первых, удобен для SEO-оптимизации; во-вторых, улучшает поведенческие характеристики посетителей, что обязательно учитывается при ранжировании.
Как минимум, к каждому изображению необходимо давать пояснения: из какого материала изготовлено изделие, в каких размерах, какова его стоимость. Вот это уже будет интересно посетителю этого раздела, ведь можно выбрать что-то похожее или скомбинировать для себя нечто из нескольких представленных работ. Сухие строки прайса таким образом визуализируются. Потенциальный клиент видит, за что он будет отдавать свои кровные. Согласитесь, уважаемый Зак, такой подход способен принести гораздо большие дивиденты.
Но есть и еще один ключик к душам кошелькам посетителей — это кейсы. Применительно к портфолио кейс — это подробный «разбор полетов», то есть описание представленных изделий не в их готовом, выставочном варианте, но и в процессе работы над ними. Давайте разберемся подробнее с этой интереснейшей фишечкой.
Кейсы в сфере услуг — путь к доверию клиента
Первыми понятием «кейс» в качестве описания процесса решения какой-либо клиентской задачи стали пользоваться тренеры бизнес-школ, инфобизнесмены. «На землю» этот термин спустился не так давно. Ну и зачем какой-нибудь клининговой фирме или компании по изготовлению мебели водить клиентов по своим «неприбранным местам»? И для чего посетителю сайта смотреть на то как пилили для него столешницу, например? Здесь я, конечно, утрирую, но зачем говорить о методах выполнения заказа, многие владельцы бизнеса не понимают до сих пор.
А дело тут в таком «пустячке» как доверие. Глянцевые стоковые картинки наводнили интернет и замылили глаз читателя. Он на них уже не реагирует. А вот историю о том, как вы с честью вышли из трудной ситуации в нестандартном заказе, применив такие вот и сякие решения, заинтересованный читатель прочтет непременно. Недаром кейсы по-другому называют Вижуал Сторителлинг.
Нет, конечно, не любой заказ годится для кейса. Но, я уверена, при желании каждый бизнесмен вспомнит не один случай, когда сложная задача была выполнена нестандартными методами и в срок. Порой достаточно 4—5 ярких кейсов вместо простыней ничего не говорящих фоток. Такое портфолио однозначно будет лучшим продавцом ваших услуг.
Что должно быть в кейсе фирмы услуг
- Красочное изображение готового изделия и несколько снимков тех моментов, которые вызывали затруднения.
- Цель проекта, то есть что хотел получить заказчик.
- Что в его заказе было особенного, над чем пришлось повозиться.
- Какие методы и решения были применены для выполнения поставленной задачи, здесь же можно назвать имена отличившихся исполнителей.
- Перечисление всех материалов, фурнитуры.
- Цена изделия.
- Результаты в цифрах (экономия клиента или выигрыш во времени, в расходе материалов и тому подобное).
- Если часть контента будет представлена в видеоформате, то это будет уже высший пилотаж.
Несмотря на мое — столь сухое перечисление пунктов, описание желательно сделать в виде живого рассказа. Если есть возможность, хорошо добавить gif-анимацию (в тему, конечно).
Объем текстового контента кейса — деталь особо тонкая. Может быть это странно прозвучит в устах копирайтера, но текста должно быть мало. При необходимости каких-то более подробных описаний их лучше прятать во всплывающих окнах. Инфографика, изображения, интерактивные элементы должны править тут бал.
И еще, чуть не забыла. Совсем необязательно возводить себя в ранг супергероев. Покажите, что вы не сразу приняли нужное решение, ведь ошибаться могут все. Будьте проще. Люди охотнее верят таким же, как они сами. Но в результате вы все же сумели выполнить заказ с отменным качеством, с соблюдением сроков, о чем и написал в отзыве довольный клиент. И это будет самым лучшим завершением вашего кейса.
До свидания, уважаемые ЗАКи. Я объяснила вам, что это такое — кейс и, надеюсь, убедила в необходимости срочного их заказа. Тогда не медлите! Вверху справа есть форма для связи. Пишите, объясняйте свою задачу! Отвечаю всем и быстро.
Всего вам доброго. Ваш личный копирайтер GALANT.
А эти статьи вы уже читали? Еще нет? Напрасно… Вам будет интересно:
выжимаем практический опыт / QIWI corporate blog / Habr
У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.Я буду использовать разговорное «юзкейс» вместо неуклюжей кальки «прецедент использования». Надеюсь, уважаемая публика меня за это простит.
Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.
Мои отношения с юзкейсами начались в 1996 году и складывались поначалу не очень хорошо. Я тогда работал на предприятии связи, и у меня был халявный интернет. По дайлапу, через телефонный модем на 9600 бод я бороздил просторы тогдашнего интернета в поисках методики, которая помогла бы мне описать функциональность комплексной информационной системы предприятия.
Дело в том, что автоматизация бизнес-процессов там была реализована на изолированных десктопных приложениях с изолированными же базами данных. Вплоть до того, что учет абонентов-физлиц и расчетов с ними был в одной БД, а учет корпоративных абонентов — в другой. И нигде не было, например, пула свободных телефонных номеров. Стояла задача всё это объединить в единую учетную систему для всех услуг. То, что сейчас называют «биллинг».
Я не знал, как начать формулировать требования к такой большой системе, и стал искать подходящий способ. Наткнулся на спецификацию UML версии 0.9, которая тогда только что вышла. В полном восторге, с горящими глазами, прочитал ее от корки до корки. Мне всё дико понравилось, я понял все схемы UML и как ими пользоваться. Кроме одной: диаграммы Use Case. Было непонятно, что это, зачем она и как ее применять. Ниже объясню, почему так произошло.
Проблему биллинга в конце концов решили — купили у стороннего вендора, потом несколько лет внедряли. Но я к тому времени уже был далеко. Юзкейсы писать тогда так и не научился и, в общем, не ощущал особого дискомфорта.
В 2004 году я пришел работать системным аналитиком в одну из больших аутсорсинговых компаний, где состоялось мое настоящее знакомство с юзкейсами. Стандартом разработки там был Rational Unified Process, все функциональные требования во всех проектах полагалось формулировать только в виде юзкейсов. Это, конечно, радикальный подход, мне он и тогда казался странным, а теперь я точно знаю, что так нельзя. Но тем не менее, прослушав пару тренингов и прочитав Коберна, я разобрался в методике и стал ее применять. С тех пор юзкейсы — мой любимый инструмент анализа и разработки требований.
Что такое юзкейс?
Есть разные определения, они на первый взгляд сильно различаются. Самое невнятное встречается у Коберна, он определяет юзкейс как «соглашение о поведении рассматриваемой системы». Правда, у Коберна была целая книжка чтобы раскрыть и уточнить свое определение.
А вот определение из глоссария UML (перевод мой).
Юзкейс — это описание набора последовательностей действий системы, в том числе вариантов таких последовательностей, в результате которых получается наблюдаемый результат, который обладает некой ценностью для кого-то из участников процесса.
Какое определение я сам стараюсь держать в голове, когда пишу юзкейс? Оно должно мне подсказывать, что я должен сделать, о чем мне надо не забыть написать:
Юзкейс — это текст,
описывающий сценарий
взаимодействия с системой,
приводящий к значимому результату.
Оно короткое, и это хорошо. Но в нем есть несколько неявных умолчаний. О которых я тоже помню, разрабатывая юзкейс. Вот полный вариант:
Юзкейс — это текст,
описывающий сценарий (возможно, не один)
взаимодействия (кого или чего?) с системой,
приводящий (возможно, не приводящий)
к значимому (для кого?) результату.
Такое определение говорит мне, что из описания юзкейса должны быть понятны:
- Результат — пишется в заголовке юзкейса
- Что является рассматриваемой системой
- Участники взаимодействия (действующие лица: люди, внешние системы, кто основной участник?)
- Последовательность действий
- На каждом шаге: Кто? Что делает?
- Что будет если что-то пойдет не так?
Для примера приведу юзкейс из реального проекта. В 2012 году QIWI Кошелёк стал мультивалютным, и курсы конвертации сначала устанавливались на базе курсов ЦБ. Но потом их решили устанавливать по рынку, и проект был посвящен этому переходу. Юзкейс довольно простой. Трейдер выставляет курсы в АБС — автоматизированной банковской системе. Директор казначейства или его заместитель должны их на всякий случай подтвердить. Вдруг трейдер ошибется: рука дрогнет, не ту цифру нажмет. Цена ошибки велика. Если что-то не так, директор заявку отклоняет, и трейдер делает работу заново.
Установка курсов для пользователей QIWI Кошелька
Основной сценарий
- Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки).
- Директор казначейства получает сообщение по электронной почте о необходимости подтвердить заявку.
- Директор просматривает заявку и утверждает ее (см. форму утверждения).
- АБС сохраняет курсы для использования в QIWI Кошельке начиная с момента, указанного в заявке.
- Заинтересованные лица получают по электронной почте сообщение, в котором указаны новые курсы и дата/время их вступления в силу.
Отклонение заявки
- На шаге 3 директор отклоняет заявку.
- Трейдер получает сообщение по электронной почте об отклонении заявки.
Что не нужно в юзкейсе
Коберн не скрывает, что его любимый формат юзкейса — Fully Dressed (как это по-русски, расфуфыренный?). Помимо основного и альтернативных сценариев в него включаются разделы:
- Контекст использования
- Область действия
- Уровень
- Основное действующее лицо
- Участники и интересы
- Предусловие
- Минимальные гарантии
- Триггер
- Расширения
- Список изменений в технологии и данных
По моему опыту — ничего этого не нужно. Всё это только мешает скорее начать читать сценарий и понять суть. Мне ни разу не приходилось писать полностью расфуфыренные юзкейсы. Ближе всего к этому был один проект, который делали два года, и он так и не взлетел.
Разрабатывая юзкейс, вы не должны накладывать преждевременных ограничений на дизайн. Взгляните на юзкейс выше. В нем нет деталей экранных форм и управляющих элементов интерфейса. Пользователь будет выбирать вариант из выпадающего списка, выбором опции или нажатием кнопки? Это сейчас не имеет значения, решения такого уровня следует отложить на потом. Не делайте работу дизайнера, он сделает ее лучше вас.
Вы скажете: ну как же, вот у тебя написано, что директор получает уведомление по электронной почте. А почему не по SMS или каким-то другим способом? Потому что мы с пользователями на тот момент уже согласовали вариант с e-mail-ом. Если бы я написал абстрактно, то у них возникло бы недоумение: как так, разве мы не решили, что это будет e-mail? Что-то изменилось? Описав пользовательский интерфейс чуть более детально, чем полагается по методике, я позаботился о читателе, чтобы он не споткнулся, читая юзкейс.
Вообще, при выборе информации для включения в юзкейс главным критерием должна быть легкость восприятия. Ради нее можно пожертвовать правилами, подробностью, иногда даже точностью. Главное — чтобы юзкейс был понятен с ходу. Если его трудно понять с ходу — это плохой юзкейс.
Что еще отсутствует в приведенном примере? В нем нет ничего о том, как курсы передаются из АБС в процессинговую систему QIWI Кошелька. Потому что это предмет другого взаимодействия и другого юзкейса. Если из-за какого-нибудь сбоя курсы не дойдут до процессинга — это не забота трейдера. Для него результат достигнут: курсы назначены и утверждены.
Не старайтесь запихнуть всё в один юзкейс. Разграничивайте их исходя из целей пользователей.
Условные конструкции
Одно из основных требований Коберна — отсутствие ветвлений в сценарии. Если есть альтернативный вариант развития событий, его полагается описать отдельно. Любую, сколь угодно сложную блок-схему с ветвлениями и циклами можно представить в виде набора линейных участков.
Я не всегда следую этому правилу. Признаюсь, я подправил свой юзкейс перед тем, как выложить его сюда в качестве примера. А в оригинале он выглядел вот так. Отличия начинаются с п.3.
Сценарий установки курсов
- Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки).
- Директор казначейства получает сообщение по электронной почте о необходимости подтвердить заявку.
- Директор просматривает заявку и утверждает либо отклоняет ее (см. форму утверждения).
- Если заявка отклонена, то трейдер получает сообщение по электронной почте об отклонении заявки.
- Если заявка утверждена, то:
a. Курсы сохраняются для использования начиная с момента, указанного в заявке.
b. Заинтересованные лица получают по электронной почте сообщение, в котором указаны новые курсы и дата/время их вступления в силу.
Я считаю, что если в сценарии одно-два ветвления, небольшие и без вложенных условий, то использование условного предложения только улучшит читабельность.
Бизнес-правила
Как сочетать лаконичность юзкейса с множеством деталей, которые обычно нужны, чтобы спроектировать пользовательский интерфейс и разработать код? Для этого я сопровождаю юзкейс списком бизнес-правил, которые должны учитываться при реализации сценариев.
Вот какие бизнес-правила были приложены к юзкейсу из примера.
- Время вступления курсов в силу может быть только 12:00:00, 16:00:00, 20:00:00.
- Трейдеру разрешается отправить заявку на утверждение не позднее, чем за 45 минут до момента вступления курсов в силу.
- Трейдер может удалить заявку, если она еще не направлена на утверждение или отклонена.
- Трейдер может отредактировать не отправленную или отклоненную заявку и повторно отправить ее на утверждение.
- Трейдер может создать и отправить на утверждение одновременно несколько заявок с разными датой и временем вступления в силу.
- Сохранение другой заявки с такой же датой и временем, как у уже существующей, невозможно.
- Директор может утвердить заявку не позднее чем за 40 минут до момента вступления курсов в силу.
- Директор может удалить утвержденную заявку, но не позднее чем 60 минут до момента вступления курсов в силу. Новые курсы, указанные в заявке, в случае ее удаления не вступают в силу.
- При удалении заявки отправляется сообщение заинтересованным лицам об отмене установки новых курсов.
- Необходимо сохранять в журнале информацию о следующих действиях пользователей: отправка заявки на утверждение, утверждение заявки, удаление заявки. Для каждого из них должны сохраняться: дата/время выполнения действия, пользователь, данные заявки: исходные курсы, дата и время вступления в силу.
- Если процессинг QIWI Кошелька не смог загрузить курсы в нужное время по расписанию, то, помимо оповещения специалистов эксплуатации, должно также отправляться сообщение по списку рассылки заинтересованных лиц.
Если присмотреться, то почти каждое из правил может дать начало еще одному альтернативному сценарию, а то и целому юзкейсу. Например: «Директор не успел утвердить заявку». Но если бы я расписал все альтернативы, как положено по Коберну, юзкейс стал бы хуже. В нем было бы труднее разобраться и выделить суть.
Следует всегда внимательно оценивать, какие детали стоит включить в сценарии, а какие — вынести в список бизнес-правил.
Когда систем несколько
Одно из центральных понятий в теме юзкейсов — это «рассматриваемая система» (SuC, System under Consideration, или SuD, System under Development). Согласно классическому подходу, есть система, которую мы разрабатываем, и у нее есть граница. Всё во Вселенной делится на то, что внутри системы, и то, что вне ее. И мы рассматриваем исключительно такие взаимодействия, которые идут через границу системы. Зная, что на входе и на выходе мы можем решить, как оно должно работать внутри.
Этот подход можно назвать «одноклеточным». Мы сосредотачиваемся на том, что происходит в клеточной мембране, и игнорируем до поры до времени всё остальное.
Но в реальности мы живем в многоклеточном организме. У компании много систем, они взаимодействуют между собой и совместно реализуют множество функций бизнеса. Почти в каждом проекте мы должны удовлетворить очередную потребность компании через внесение изменений, по возможности минимальных, в несколько систем.
У Коберна такое предусматривается, там есть вариант «организация — прозрачный ящик». Но у него об этом как-то вскользь. В основном рассказ идет о том, как описать единственную рассматриваемую систему в виде черного ящика.
Я предпочитаю в своих юзкейсах не делать различий между системами, к которым мы ставим требования, и внешними акторами. Каждая из систем, которые мы модифицируем, считается таким же участником взаимодействия, как и все остальные. С точки зрения классической методики так нельзя: система — то что внутри, акторы — то что снаружи.
Зато мой подход позволяет извлечь набор функциональных требований к каждой системе по отдельности. Берем все шаги юзкейсов, в которых участвует данная система. Смотрим, существующая ли это функциональность или новая, или существующая, но с какими-то изменениями. Шаги, в которых нет изменений, выкидываем. То, что остается — передаем команде разработчиков системы для детальной технической проработки. Повторяем для каждой из систем, участвующих в юзкейсах проекта.
Сказуемое без подлежащего
Время от времени в сценариях приходится встречать такие фразы: «данные сохраняются в БД», «пользователю отправляется СМС». Не бывает действий, которые выполняются сами по себе. Их всегда выполняет кто-то или что-то.
Я полностью согласен с рекомендацией Коберна о структуре предложений в сценарии. Каждый шаг юзкейса должен начинаться с подлежащего — кто или что выполняет действие. Затем сказуемое — какое действие. Дальше всё остальное. Сказуемое должно быть в настоящем времени и в действительном залоге. «Пользователь выбирает населенный пункт», «Приложение показывает список товаров».
Пробежав глазами начальные слова шагов, легко собрать список участников. Я предпочитаю не выписывать отдельно список участников в начале юзкейса, это тормозит читателя и мешает ему скорее перейти к чтению сценария.
Неуспешные сценарии
Иногда в проектах забывают предусмотреть случаи, когда что-то происходит не так. К примеру, клиент совершил покупку, а потом захотел ее вернуть. Если об этом не подумали заранее, то приходится срочно допиливать код после запуска. А в тяжелых случаях — выбросить всё и организовать взаимодействие систем в другом порядке.
Техника юзкейсов помогает (хотя и не гарантированно) избегать подобных осложнений. Написав основной сценарий, подумайте: что может пойти не так на каждом из шагов? Что может случиться в другом месте после того, как здесь всё уже закончилось? Каждый найденный вариант отклонений нужно выписать, для начала хотя бы одной фразой. Потом, если потребуется, проработать по шагам.
Если в проекте описаны только основные сценарии юзкейсов, то велик риск, что забыли что-то важное.
Модель предметной области
Юзкейсы должны опираться на модель предметной области, которую все участники проекта понимают одинаково. Вспомним первый шаг нашего примера: «Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки)». В одном пункте употреблено пять понятий. Некоторые из них новые, возникли только в этом проекте.
Самый известный инструмент введения в предметную область — глоссарий. Следует включать в глоссарий только те слова, которые кому-то могут быть непонятны. Если начать объяснять всё, то после первых трех пунктов читателю станет скучно и он закроет глоссарий, не добравшись до важного.
Можно писать краткие статьи, объясняющие новые понятия. Вот пример — выдержка из документации всё того же проекта:
Поддерживаемые валюты
Имеется список поддерживаемых валют. Этот список делится на две части:
- Валюты кошельков — в которых клиенты могут открывать кошельки.
- Остальные («валюты платежей») — в них клиенты не могут открывать кошельки, но в этих валютах могут указываться суммы платежей.
Список поддерживаемых валют может со временем расширяться, валюты платежей становиться валютами кошельков.
Для каждой валюты также известно, котируется ли она к рублю или к доллару США. «Котируется» в данном случае означает «курс задается Казначейством».
(Считаем, что доллар котируется к рублю, но не рубль к доллару, так как курс доллара задается в рублях, а не наоборот).
Еще один классический способ описания модели предметной области — диаграммы «cущность-связь» в формате IDEF1 или статических структурных диаграмм UML.
В одном недавнем проекте я на таких картинках по часу в день, в течение двух недель, излагал команде разработки модель предметной области. В результате у всех разработчиков была единая картина понятий, что нам очень помогло в ходе проекта.
Перечень юзкейсов
Если требования описаны в форме юзкейсов, то их список становится полезным инструментом управления проектом. Например, в списке юзкейсов можно расставлять приоритеты реализации, можно измерять прогресс по количеству реализованных юзкейсов. Перечень юзкейсов может существовать в форме собственно перечня (Use Case Survey) или в виде диаграммы юзкейсов.
Перед вами перечень юзкейсов из другого проекта, он тоже про конвертацию валют. Платежная система обращается в банк чтобы обменять валюту на такую сумму, которой хватит держателям валютных кошельков и получателям платежей.
- Задать прогноз оборотов
- Создать заявки на конвертацию
- Отправить заявки в банк
- Выполнить заявки на конвертацию
- Учесть выполненные заявки
Тот же самый перечень, но в виде диаграммы юзкейсов.
Здесь информации больше: мы видим участников взаимодействия и в каких юзкейсах они участвуют. Вопреки Коберну, в качестве участников показаны системы, к которым мы ставим требования (расчетная система, АБС), а также внешние неизменяемые системы (биржевой терминал, система бухучета) и пользователи.
Теперь я могу вам объяснить, почему юзкейс-диаграмма осталась для меня непонятной при первом знакомстве с UML. Дело в том, что все другие диаграммы UML моделируют систему, они показывают ее нам в разных «ракурсах». А юзкейс-диаграмма иллюстрирует не саму систему, а набор функциональных требований к ней. Юзкейс-диаграмма, следовательно, — модель модели. Не так просто было сразу это понять.
Заключение
Юзкейсы — уже довольно старая методология. За 20 лет появились новые подходы, которые потеснили методику юзкейсов в тех областях, в которых она когда-то была лучшей. Например, юзер стори позволяют более эффективно управлять требованиями в Agile-проектах. Методы дизайна пользовательского опыта помогают разрабатывать продукты, успешные на рынке. На мой взгляд, сегодня в сравнении с более современными методами юзкейсы находятся примерно в том же положении, какое в свое время занимали блок-схемы по сравнению с юзкейсами. Старые добрые блок-схемы — теперь диаграммы Activity в UML — используют до сих пор. Но когда-то они считались универсальным способом проектирования и описания программ, а потом их применение сузилось с появлением методик таких как Use Case, UML, BPMN.
Тем не менее юзкейсы и сейчас остаются хорошим инструментом анализа, особенно для систем, поддерживающих бизнес-процессы. Любой аналитик или проектный менеджер должен знать методику юзкейсов и уметь ее использовать. Об этом, собственно, и мой пост.
Кейс — это… Что такое кейс?
Проверил замки на кейсе, для спокойствия подергал их несколько раз, потом прикрыл кейс своим плащом.
Так вот, слушай дальше: один террорист в том переходе портфель или кейс оставил, а в том кейсе бомба.
Положив на столик свой кейс, он щелкнул замками. – Вернемся, как говорится, к нашим баранам. – Из кейса выпорхнула толстая канцелярская папка, заполненная материалами следствия.
Каждый кейс в оглавлении снабжен указателем компании, отрасли, в которой она работает, даты публикации материала (чтобы легче было определять время, к которому относятся описанные события), а также краткой формулировкой проблемы, которая в данном кейсе рассматривается.
Входит хмырь: «Ну зачем вы, право… Вот, в кейсе 50 кусков». — «Я вас задерживаю». — «Ну да?» — удивился, кейс открыл — он пустой.
Так он, бывало, и стоял на какой-нибудь улице, не двигаясь, вцепившись в кейс и думая о Рейчел, которая была под полутора метра высотой и в чулках, чья шейка была бледна и изящна — шея Модильяни, чьи глаза — не зеркальные отражения друг друга, но слегка наклонены в одну и ту же сторону, темно-карие едва ли не до бездонности, а через какое-то время снова всплывал к поверхности и злился, что переживает из-за пустяков, тогда как информация в кейсе должна быть в офисе уже пятнадцать минут назад; и осознавал, неохотно, что гонки со временем, признание себя винтиком, размах — почти мошенничество — образа плейбоя в Комиссии, который так шел облику британского штабного офицера, и даже внутридепартаментные заговоры и контрзаговоры, что плелись в джазовых подвальчиках в два часа ночи, в пансионах за бренди с содовой, все-таки были увлекательны.
Потому что подумать успел, что мужик тот, на бродягу похожий, который закурить попросил и в лоб мне выстрелил, ограбить меня, кейс мой забрать хотел, потому что тоже плыл на пароме и все подсмотрел, подслушал со стороны, поверив, что в кейсе моем на самом деле сто тысяч… Как поверил про сто тысяч и тот небритый кавказец, который, когда я уже водку в баре выпивал с Арвидом, подсел ко мне и, выдавая себя за чеченца, стал плести, что Масхадов, президент Чечни, с которым он дружит, просто по имени называл, Аслан и Аслан, послал его в Стокгольм, чтобы с Ахмедом Закаевым, представителем Масхадова на Западе, встретиться, который завтра в Стокгольм из Лондона прилетает, и они будут оружие для войны за независимость покупать.
Кавказец предложил сначала триста, потом пятьсот и сразу же, махнув рукой, тысячу процентов, потому что очень срочно нужны деньги, на кейс с которыми он все косился, и мне, чтобы этот жулик–любитель по глупости меня не прирезал, пришлось выйти из бара и показать ему в кейсе бритву фирмы «Gillett» и пакет с нарисованным на нем красным трактором и зеленой надписью Belarus, а в том пакете — трусы фабрики «Комсомолка», верным которой я остался, несмотря на ветры перемен.
Автор: Киселева Ольга, автор и ведущий тренинга Онлайн-интенсив для начинающих тестировщиков. Тест-кейс — это проверка. «Выполни тест-кейс по вводу отрицательных значений» = проведи проверку такую-то и проверь, что результат будет такой-то. Тест-кейс — это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик. Набор тест-кейсов называется тестовым набором (test suite). Стандартные атрибуты тест-кейса
Пример оформления (один ожидаемый результат)Есть внутренний сайт компании компании, которая проводит интернет «Самый_лучший_в_своем_роде» — www.test.ru. Тестовый стенд, на котором проверяются доработки перед выкладкой в PROD (он же production, окружение для пользователей) находится по другому адресу — www.dev_test.ru. На сайте можно заводить карточки обслуживаемых зданий и карточки их жильцов. Карточки создает администратор, на тестовой машине всегда есть пользователь с правами админа, логин / пароль — admin / 1. При входе на тестовый сервер есть дополнительная авторизация, чтобы туда не могли попасть люди «извне», с логином и паролем test / test. Тест-кейс № 1. Создание жильца без ФИО. Шаги
Ожидаемый результат Появляется сообщение об ошибке «Заполните обязательные поля, отмеченные *», карточка не сохраняется. Преимущества и недостатки тест-кейсовПреимущества: тест-кейсы можно доверить выполнять новичку или призванному на помощь коллеге из другого отдела, который ничегошеньки о проекте не знает. Дополнительных вопросов с его стороны будет по минимуму — все и так (должно быть ) понятно! Недостатки (вытекают один из другого):
Последний недостаток перечеркивает достоинства. Тестировщик, который уже год как работает на проекте, поймет и неактуальный кейс, тем более если выполняет их подряд, начиная с первого. А тестировщик, который ничего о проекте не знает и получил пару кейсов из середины тестового набора, не сможет понять, о чем в них идет речь. Чтобы тест-кейсы честно выполняли свою роль, их надо поддерживать, периодически проверять на правильность и дорабатывать… Это отнимает очень много времени и сил. Чтобы упростить этот процесс, могут быть использованы тест-кейсы с одним сценарием выполнения, но несколькими входными параметрами и разными ожидаемыми результатами. Фактически мы получаем мини чек-листы с предварительными шагами. Примеры оформления (несколько ожидаемых результатов)Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле «ФИО» по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).
Несколько вариантов вводимых данныхТест-кейс № 2. Создание жильца, проверка поля «ФИО». Шаги:
Ожидаемый результат
Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё! Результаты для нескольких шагов из кейсаДругой вариант записи тест-кейса с несколькими ожидаемыми результатами — когда результаты пишутся на разные пункты шагов выполнения проверки, то есть на разные этапы сценария. Тест-кейс № 3. Создание жильца с худым полным ФИО. Шаги:
Ожидаемый результат 1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой «Войти» и сообщением «Для входа в систему введите, пожалуйста, свои данные». Несколько проверок после одного сценарияТест-кейс № 4. Создание жильца с самым полным ФИО. Шаги:
Ожидаемый результат Области применения Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию «чек-листы & тест-кейсы». Тест-кейсы нужны:
Тест-кейсы не нужны:
Познакомьтесь со своей системой и потом уже решайте, что подходит именно для нее — творческие чек-листы, формальные тест-кейсы или микс из этих подходов. Стандартные ошибки при оформлении тест-кейсовЧитать теорию — одно, делать на практике — другое. Обычно в теории все понятно, а на практике получаем примерно такой кейс (все совпадения случайны, тест-кейс написан как агрегация различных ошибок): Тест-кейс № 01. Создание жильца. Шаги:
Ожидаемый результат — карточка создана.
Разберем ошибки кейса 01. 1. Абстрактное название 2. Повелительное наклонение 3. PROD 4. Нет ссылки на сайт 5. Слишком детализировано 7. Нет описания проверки Тест-кейс № 02. Создание жильца с корректными ФИО. Шаги:
Ожидаемый результат Уже хорошо, но можно ли еще улучшить этот тест-кейс?
Итак, ошибки кейса 02: 1. Абстрактное название. 2. Нет нужной информации Тест-кейс № 03. Создание жильца с полным ФИО. Шаги:
Ожидаемый результат Определения из книг по тестированиюRon Patton. Software Testing. Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software. Тест-кейсы перечисляют конкретные вещи, которые будут протестированы, и описывают детальные шаги, которые необходимо выполнить для проверки программного обеспечения. Lee Copeland. A Practitioner’s Guide to Software Test Design. The purpose of the test case specification is to specify in detail each test case listed in the test design specification. The test case specification is composed of the following sections:
Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:
Гленфорд Майерс, Искусство тестирования программ Любой тест должен включать две составляющие:
На этом, пожалуй, все PS — Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению! |