Search
Write a publication
Pull to refresh

Comments 6

Юзкейсы, - это хорошо, но я как-то за всю практику не видел, чтобы использовали только ИХ, обычно всем скопом и другие диаграммы юзают. А еще мы use case используем вообще только в самом начале, чтобы концепцию описать, а 90% детализации уже другими диаграммами и моделями описываем.

всё, что описано в статье — это вообще не про диаграммы

А если у проекта уже имеется большое кол-во юз кейсов и не хочется от них отказываться, но их уже никак не расширить, можно ли их переформировать по формат юз кейсов 3.0?

Да, конечно. Можете просто указать конкретную практику —  которой соответствует степень проработки ваших вариантов использования. Сама техника описания почти никак не меняется.

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

Даже в примере со снятием денег в UC описано 10% задачи, потому что самое затратное по разработке там "как проверить запас", "как атомарно списать деньги" и "что делать при падении сессии во время транзакции".

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

Sign up to leave a comment.

Articles