А сейчас расскажем, к чему этот опрос был ↓

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

Задача подрядчика — помочь клиенту оценить время на разработку, чтобы определить необходимые ресурсы. Для этого можно воспользоваться одним из методов — оценка по UCP (use case points, оценка на основании вариантов использования).

Метод оценки проектов по UCP был предложен Густавом Карнером в 1993 году. Автор предложил оценивать затраты на разработку, учитывая вес параметров следующих групп в баллах:

◾ Функциональные параметры (UUCP*): кто и что может делать в информационной системе.
◾ Технические параметры (TCF*): сложность архитектуры, требования к безопасности, производительности, нагрузке и прочее.
◾Факторы окружения (ECF*): погружение команды разработки в предметную область, наличие опыта разработки аналогичных систем, уровень квалификации и прочее.

Работа по оценке методом UCP делится на два этапа:

🔹1. Unadjusted — проработка ролей в системе и Use Cases (вариантов использования).

На этом этапе необходимо составить списки:

▪️ UAW: количество действующих лиц в системе и их способ взаимодействия с ней (через UI, посредством API или доступ по FTP, например)
▪️ UUCW: количество и сложность Use Cases
Это самая ответственная часть — от того, насколько качественно вы их пропишете, будет зависеть итоговая оценка. Чтобы ничего не упустить, можно использовать UseCase-диаграмму.

🔹2. На следующем этапе необходимо расставить вес всех параметров в группах Unadjusted, технические факторы и факторы окружения.

Мы, например, применяем такие коэффициенты:

▪️ Простой Use Case (1-3 шага) — 5 баллов, сложный (7-11 шагов) — 15 баллов.
▪️ Взаимодействие с системой по API — 1 балл, с помощью UI — 3 балла.
▪️ Для технических факторов и факторов окружения мы используем баллы: 0-3-5.

Чем больше суммарный балл, тем сложнее система и выше итоговая оценка проекта.

При составлении списка Use Cases важно писать их от лица пользователей: неодушевленные участники информационного обмена участвуют в Use Cases как «шаги». Например, «Я как пользователь могу посмотреть штрафы, пришедшие от ГИБДД».

Также в этом методе присутствуют дополнительные множители — «вес факторов», которые мы использовали для адаптации этого метода оценки под наши реалии. Подробности об этом в статье 🙂

*расшифровка аббревиатур в статье