Аналитика для разработки ПО: чек-лист, без которого не стартует ни один проект

На связи ZAKUPKI.GROUP, мы проектируем корпоративное ПО на Java EE.

Мы не работаем по модным спринтам и Agile, но при этом многие клиенты продлевают с нами договоры и приходят с новыми идеями и заказами. А все потому, что работать с надежными ребятами, которые выполняют обещания и соблюдают сроки, — одно удовольствие!

В этой статье мы хотим поделиться чек-листом для аналитики на примере одного из наших проектов — системы аккаунтинга с внутренними балансами пользователей. У подобного продукта много областей применения: он может начислять зарплату, рассчитываться с поставщиками за услуги, считать налоги и т. п. Мы поставляли его экосистеме проведения турниров по играм Apex Legends.

1. Project Vision

Project Vision — документ, в котором кратко описано, что мы ожидаем получить в результате работы. Он может содержать информацию о миссии продукта, его концепции, но главная его задача — дать команде ориентир, где мы должны оказаться по завершении проекта. Вот что включал в себя наш Project Vision:

• описание клиента и продукта (экосистема, объединяющая геймеров для участия в турнирах);
• главная задача (внутренние расчеты по активностям покупателей, продавцов и игроков);
• описание основных ролей и сущностей в системе;
• информация о валюте;
• информация о транзакциях для покупателя;
• информация о комиссии;
• рейтинг покупателей, продавцов и игроков;
• безопасность учетной записи;
• пример аналогичной системы для наглядности.

Мы должны понять боль заказчика и предложить самое оптимальное решение. Наши специалисты проводят детальное интервью с клиентом, чтобы выявить все его потребности и впоследствии составить корректное ТЗ.

2. Составление реестра рисков

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

Наши аналитики пользуются каталогом RBS (Risk Breakdown Structure), где индивидуальные риски распределяются по группам: процесс разработки, бизнес-окружение, ресурсы и т. д.

3. Составление диаграммы предметной области

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

4. Формирование функциональных и нефункциональных требований

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

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

Мы всегда стремимся, чтобы сформулированные требования были конкретными, измеримыми, достижимыми, релевантными и ограниченными во времени (критерии SMART).

5. Диаграмма use-case и описание сценариев

Корректно составленная диаграмма use-case поможет разработчикам и клиенту понять, как система будет использоваться в реальном мире и на основе этого сформулировать требования и планы на ее разработку.

6. UML-диаграмма развертывания

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

7. ER-модель

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

8. Составление ТЗ

Подводя итоги, мы отражаем каждый из вышеописанных этапов в ТЗ. Наш документ содержит в себе такие разделы:

1. Введение.
2. Цель и масштаб проекта.
3. Глоссарий.
4. Деловой контекст.
5. Участники проекта.
6. Границы системы.
7. Функциональные требования.
8. Требования к данным.
9. Системные ограничения.
10. Проектные вопросы.
11. Бизнес документы и формы.
12. Ссылки (приложения).

Все эти шаги помогли нам построить микросервис для внутренних расчетов по активностям пользователей. Вот только некоторые из его функциональных характеристик:

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

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

Надеемся, статья показалась вам полезной и интересной. Будем рады, если вы, оставите свою реакцию и комментарий!