Архив за Август, 2013

Область применимости юзкейсов

Среда, Август 21st, 2013

“Ни одна модель неверна, по крайней мере в нашем реальном мире, но некоторые модели более полезны, чем другие”

(c) Джордж Бокс.

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

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

1. Проект не по созданию, а по настройке учетной системы.

Предположим, вам понадобился бактрекер. Если вы будете писать движок аналогичный Jira, Redmine или Trackstudio, юзкейсы - это то, что надо для описания функциональных требований. Но если вы собираетесь просто настроить одну из перечисленных систем под свои нужды, то предпочтительней использовать другие нотации. Диаграмму состояний, EPC-диаграмму, восможно IDEF или BPML. Что касается других систем, таких SAP, Sharepoint  и т.п., то в проектах по их настройке под бизнеспроцессы заказчика, так же предпочтительно использовать отличные от юзкейсов нотации.

2. Большое количество различных интерфейсов пользователя для одной и той же функциональности.

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

3. Разрабатываемое ПО содержит много логики.

Нет смысла описывать игромеханику Word of Warcraft через юзкейсы. Это гораздо проще сделать через описание правил. Хотя для описания создания, удаления персонажа и других подобных действий юзкейсы по прежнему эффективны.

А для компилятора командной строки или для утилиты grep юзкейс будет один. А остальные требования - это куча правил.

Но если продукт будет развиваться дальше, то отсутствие юзкейсов может сослужить плохую службу. Skype - сложная технологическое приложение. Разработать его было явно не просто. И похоже в какой то момент разработчики пренебрегли юзкейсами. Как результат, управлять всего то парой сотен аккаунтов не слишком удобно.

4. Взаимодействие между системами.

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

Для описания протоколов взаимодействия неплохо зарекомендовали себя диаграммы последовательности и какой либо вариант  описания XML.

5. Продукт, для которого функциональные требования не слишком важны или их очень мало.

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

Подводя итоги.

Мой тренер по рукопашке говорил: “Нет плохих приемов. Есть неправильное их применение.” Перефразируя его: “Нет плохих нотаций. Нотация должна выбираться в зависимости от проекта.”

PS. Это одна из вводных статей для моего тренинга по разработке юзкейсов. Я переношу материал в статьи, для того, чтобы на самом тренинге больше времени уделить практике.

Примеры вариантов использования (Usecase)

Воскресенье, Август 11th, 2013

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

Рассмотрим часто встречающуюся на практике проблему дублирования данных в операционной базе. Такая ситуация приводит к различным негативным эффектам. Это может быть и многократная отработка одной заявки, неверные данные в сводных отчетах, невозможность выполнения ряда операций и т.д. Как правило, дубликаты нельзя просто удалить, т.к. к дубликатам могут быть привязаны дополнительные объекты, которые необходимо сохранить для дальнейшей обработки.

Примечание. Особенно неприятная ситуация с дубликатами происходит, при слиянии данных из разных систем. Это может быть и создание централизованного хранилища справочников  (Master Data Management) для программных комплексов различного назначения, и слияние локальных баз филиалов в центральную.

Ситуация 1. В бухгалтерской программе один и тот же контрагент введен несколько раз. По контрагенту могут проходить как дебетовые, так и кредитовые финансовые документы. Бардак в базе данных не позволяет эффективно проводить взаиморасчеты. Необходимо сделать так, чтобы в базе остались уникальные контрагенты, с привязанными к ним полным пакетом документов.

Ситуация 2. В бактрекере часто встречаются записи описывающие одну и ту же проблему. Такая ситуация приводит к отвлечению программистов. Кроме того, может сложиться ситуация, при которой одну и ту же ошибку будут править несколько программистов. Необходимо очистить базу от дубликатов, но при этом по возможности сохранить скриншоты и описания.
В качестве примера многократного дублирования записей об ошибке, читатели могут рассмотреть JRA-1330 из открытого источника.

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

Примечание. Далее по тексту объект, который будет помечен как дубликат, будет обозначаться термином «донор». Объект, на который будут перенесены ссылки с донора, будет называться реципиент. Для реципиента широко распространен термин «Золотая запись».

Вариант А. Пометить дефект как дубликат.
Цель: очистка данных для  уменьшении трудозатрат программистов.
Основное Действующее Лицо (ОДЛ): Тестменеджер
Предусловие: выбран дефект-донор

Основной сценарий:
1.  ОДЛ отдает команду «Пометить как дубликат»
2.  SuD предлагает указать реципиента
3.  ОДЛ указывает реципиента
4.  SuD подтверждает, что дефект-реципиент не находится в состоянии «Дубликат»
5.  SuD переводит дефект-донор в состояние «дубликат»
6.  SuD изменяет ссылки с дефекта-донора на дефект-реципиент (переносит аттачи на дефект остающийся активным)
7.  SuD уведомляет ОДЛ об успешном завершении операции
Альтернативный сценарий:
4.а дефект-реципиент находится в состоянии «Дубликат»
4.а.1 SuD уведомляет ОДЛ о невозможности  успешного завершении операции

Такой вариант юзкейса хорошо подходит для использования в системах трекинга задач. Как правило, дублирующие задачи описываются разными терминами и автоматический поиск дубликатов маловероятен.

Примечание. Инженеры Яндекса упоминали об автоматической проверке на дублирование записей, но подробности мне неизвестны.

В корпоративных же системах часто возможен автоматический поиск дубликатов.  Поиск может быть проведен как по уникальным кодам, таким как ИНН, так и с использованием фильтра Байеса. При автоматическом поиске система выдает группы предположительно дублирующихся объектов.

Вариант Б. Сделать неактивными все дублирующиеся объекты, кроме «золотой записи».
Основное Действующее Лицо (ОДЛ): Администратор данных
Предусловие: выбрана группа предположительно дублирующихся объектов

Основной сценарий:
1.  ОДЛ отдает команду на просмотр списка объектов группы
2.  SuD показывает список и предлагает указать реципиента и объекты не являющиеся дубликатами (При автоматическом поиске возможны ложные срабатывания. Так колхозов «Рассвет» в РФ довольно много)
3.  ОДЛ указывает реципиента
4.  ОДЛ указывает объекты, не являющиеся дубликатами
5.  ОДЛ отдает команду «продолжить»
6.  SuD подтверждает, что объект-реципиент не находится в состоянии «Дубликат»
7.  SuD подтверждает, что объект-реципиент в группе единственный
8.  SuD переводит объекты-доноры в состояние «дубликат»
9.  SuD изменяет ссылки с объектов-доноров на объект-реципиент (переносит договора, акты выполненных работ, счета-фактуры и прочие документы на «золотую запись»)
10.  SuD уведомляет ОДЛ об успешном завершении операции

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

Некоторые пояснения по нотации:
•  SuD (system under discusion) –рассматриваемая система. Иногда пишут просто «система», но термин «SuD» более точен.
•  ОДЛ – описание, кто именно является основным действующим лицом, выносится в заголовок. Это позволяет сделать описания юзкейсов устойчивым к изменениям.

PS. Данная статья является одной из цикла вводных статей для моего тренинга “Основы  разработки Use Case’ов“ 

Байка для оруженосца-5. Использование вариантов использования.

Среда, Август 7th, 2013

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

На кухне собралась обычная компания, только Королевы не было. На вопрос об ее отсутствии ответил Чеширский Кот:

- Сейчас она проект толкает. Вообще, у хорошего руководителя проекта основная работа приходится до старта проекта, на старт проекта, перед финишем и после финиша.

- А в середине проекта можно и в отпуск сходить – с завистью заметил Мартовский Заяц.

- Или журналы почитать – добавил Безумный.

- Как Быков в «Стажерах»? - догадался Армигер.

- Как Быков – согласился Чеширский –  Быков, он хороший руководитель. Очень хороший. И хорошо, что он термин «менеджер» не слышал. Но довольно, молодой человек, об этом. Если есть время, его нужно использовать. Чем вы сейчас занимаетесь?

- Требованиями. Ревизией и выбором формата, – отрапортовал Армигер.

- Хорошее дело. И как обычно, есть несколько «но».  – Чеширский помолчал и спросил: – что вас беспокоит, мой друг? И давайте на сегодня ограничимся одним вопросом. Что сейчас вас беспокоит сильнее всего?

- Юзкейсы – понурился Армигер.

- Если беспокоит – не чеши. Лучше маслом помажь, – порекомендовал Заяц.

- Погоди, - вмешался Чеширский, - не путай его. Давайте я выдвину несколько гипотез - и, после того, как Армигер кивнул, продолжил, – вероятно, вас смущает, что их часто рекомендуют, но редко пишут; что есть юзкейсы, а есть диаграмма юзкейсов, что если есть BPML и IDEF, то зачем нужен текстовый формат?

- И если их так настойчиво рекомендуют, то они должны иметь массу преимуществ.

- Главное преимущество вариантов использования, это то, что они варианты использования, – отрезал Шляпник и демонстративно посмотрел на свою коллекцию часов.

- А разве это не одно и то же? - робко возразил Армигер.

- Так ты еще, чего доброго, скажешь, что “разработка требований” и “требования к разработке”, - одно и то же, - вмешался Заяц.

- Так ты еще скажешь, - проговорила, не открывая глаз, Соня, - будто “тестирование производительности” и “производительность тестирования”, - одно и то же.

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

- И что?!

- А вот это интересный момент, – подключился Шляпник, – смотри. Приходит на собеседование программист. SQL знает, базы данных проектировал. Даем задание: «База данных должна содержать историю курсов валют центробанка. Спроектируйте необходимые таблицы». Обычно рисуют что-то вроде такого:

Поля:

  • Идентификатор записи
  • Код валюты
  • Курс по отношению к базовой валюте
  • Начало действия курса

Заметим, выдвинутым требованиям разрабатываемая система отвечает. История курсов хранится. Вот только есть проблема. Программист не думал, что систему будут использовать. Запросы на выборку из этой таблицы оказываются достаточно сложны. Какой курс действовал первого апреля? А какой сейчас? И далее претенденты начинают городить сложные SELECT-конструкции. В условиях стресса на собеседовании это приводит к любопытным результатам. Некоторые исписывают пару листов. А всего то нужно добавить в таблицу одно поле «Дата окончания действия» и для выборки будет достаточно простого запроса с тривиальным:

where <дата на которую производится выборка> between <Начало действия курса> and <Окончание действия курса>

Бывают и более интересные прецеденты.

Шляпник повернулся к Зайцу:

- Помнишь программиста, который предлагал в одной таблице хранить актуальные данные, а во вспомогательной сделать архив?

- А то! – откликнулся его напарник.

- А тут-то что не так? – спросил Армигер.

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

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

Далее слово взял Чеширский Кот:
- Описание использования системы позволяет избежать множества проблем. Возьмем ту же JRA-1330. Серьезнейшая ошибка, «критикал». Сколько клиентов просило ее исправить! Но исправить ее невозможно. Об этом довольно неплохо написал Максим Крамаренко. А избежать ее было очень просто. Достаточно было описать, как эта трекинговая система будет использоваться. Например, как она будет использоваться для взаимодействия между заказчиком и исполнителем. И тогда бы всплыло, что менеджмент-исполнитель захочет скрыть сумму контракта на доработку от простого исполнителя, а потраченные часы скрыть от заказчика. Всего-навсего – описать способ использования системы.
Ладно, коллеги, на сегодня разминка окончена, прошу к рабочим столам.

Кот встал, потянулся и начал исчезать. Армигер вздохнул, глядя на повисшую в воздухе улыбку, и поплелся на место.