Моя компания разрабатывает богатый графический интерфейс пользователя из подробного документа спецификации, написанного в виде более 100 вариантов использования (UC). Эти подробные UC движут развитием. Они написаны в виде таблиц с актером и столбцами описания. Мы (я и другие) исказили настоящий стиль прозы UC, чтобы поддержать интерактивный характер нашего приложения.
Мы также используем спецификацию для генерации (вручную) тестовой спецификации, поэтому детали (на мой взгляд) кажутся важными. Эта тестовая спецификация используется при проверке для получения подтверждения.
Примечание. В нашем продукте намного больше компонентов, чем просто графический интерфейс. Команда с графическим интерфейсом 6-10 человек, проект в целом около 60.
До недавнего времени я создавал «раскадровку» документа, детализирующую каждую панель и ее взаимодействия в соответствии со спецификацией. Раньше также была архитектура с графическим интерфейсом, а также проекты для основных подкомпонентов. Ой! Это привело к очень медленному времени разработки, плохой базе кода (ха!) И плохо мотивированной команде.
Приложение представляет собой скорее IDE, позволяя пользователям создавать свои собственные тест-кейсы (для тестирования мобильных телефонов), используя идиома drag'n'drop, блок-схему. Это очень сложный, зрелый (7+ лет) и предлагает много функций. Затем выполняются тестовые случаи и анализируются результаты. Будучи таким бесплатным инструментом (пользователь может пройти почти бесконечное количество путей через инструмент), он, похоже, делает бессмысленным последовательных вариантов использования. Мы используем «O» для обозначения необязательного, «R» для обозначения повторяемого, вложения и многих других «расширений». UC в основном плохо подходят для разработки взаимодействий IDE. Представьте себе, что это приложение предлагает пустую рабочую поверхность (например, текстовый процессор или электронную таблицу), где пользователи могут делать что угодно в любом порядке: это привело к раздутию UC.
В настоящее время существует желание упростить спецификацию со 100+ UC до фундаментальных UC: «Разработка контрольного примера», «Выполнение контрольного примера», «Анализ результатов» (или что-то подобное).
Хотя я понимаю, что наши UC не являются «настоящими» UC (ориентируясь на ценность для бизнеса), меня беспокоит то, что команда, возглавляющая GUI и разработчик, состоит в том, что без подробной информации мои ребята не будут знать, что именно развиваться. Три UC кажутся слишком абстрактными.
Мы придерживаемся формы Унифицированного Процесса, причем спецификации выполняются заранее. Возможно, нам следует перейти к более гибкому процессу, когда разработчики сами проектируют взаимодействие.