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

1. Ирина Сурова для AnalystDays
Использование трассировок на практике.
Опыт реального проекта

2. Обо мне

В IT больше 10 лет, из них

в системном анализе 5 лет

опыт управления командой аналитиков

опыт создания и поддержки процессов
разработки

соавтор клуба прикладного системного
анализа проекта Stratoplan.ru

участник сообщества аналитиков uml2.ru

отвечаю за инструменты в отделе анализа

3. О теме

Трассировки в учебной литературе —
серебрянная пуля

Трассировки на практике — тяжело и трудно

Трассировки в research — вызовы и
надежды http://ollygotel.com/requirements-
traceability/

Я перфекционист и практик

Есть экспериментальные данные — хочу
поделиться :)

4. Контекст

1 из продуктов лаборатории Касперского

3 релиза (прошлое, настоящее, будущее)

Влияние бизнес-требований

Влияние архитектуры

Влияние окружающей среды (инструменты,
практики и т.д.)

5. Прошлое
Релиз 1

6. Релиз 1. Проектные артефакты
Бизнес-требования
Требования на функциональную область
Системные
требования на функциональную область
Остальные
артефакты
План проекта
MS Excel
Почта
MS Project

7. Вызовы и вопросы.1

Трудно определить, входит это бизнес-
требование в scope релиза или нет (C1)

Трудно определить, как добавление бизнес-
требования повлияет на скоуп релиза(C2)

Трудно определить состояние релиза (что
осталось сделать, что уже сделали) (C3)

Трудно согласовывать требования (SRS на
функциональную область – большой,
табличный формат не удобен для работы с
изменениями и комментариями (C4 - не
относится к трассировкам)

8. Вызовы и вопросы.2

Трудно точно планировать работы команды, т.к.
Функциональная область – слишком большой
элемент для планирования (C5).

Трудно точно планировать объем работ по
разработке в конкретной области, т.к.
Количество требований неизвестно (C6).

Трудно быстро определить качество разработки
конкретного функционала,так как требования и
тесткейсы не связаны (C7).

Трудно точно планировать реализацию
функционала, так как неясно, что уже поставили
смежные команды, а что нет (C8).

9. Релиз 1. Итоги

10. Надо делать следующий релиз

11. Подготовка к релизу 2

12. Источники бизнес-требований

13. Архитектура продуктов
Administrative
Server
CorporateNetwork
Internet
InfrastructureService1 InfrastructureServiceN
Kaspersky Lab Network
InternalSystem1 InternalSystem M
Product2Compo
nent 1
Compo
nent X
Product1Compo
nent1
Compo
nent N

14. Требования к изменениям
процесса

Удобство создания требований для команды
аналитиков — максимально

Удобство поддержки трассировок
требований - максимально

Изменения для команды разработки —
минимальны

Время, затрачиваемое на
переформатирование/изменение форматов
— минимально

Изобретение велосипедов - минимально

15. Продуктовые трассировки. Релиз 2
BRQ
[Epic] BRQ
SRSR
CR
SRS
TFS
SR
BRQ
SR
EA
[Epic] BRQ
SharePoint
CR
Bug
TeamTrack
CR
Bug
TestCases

16. Контекст проекта

Жесткие сроки выхода релизов (Time Driven
Development)

Большая и распределенная команда

Нет сложившегося процесса, который
устраивает команду

17. Предлагаемые изменения к релизу 2

База данных Бизнес-требований (BRQ) на
SharePoint со статусами и признаком
вхождения в scope релиза (было - список)

Новые продуктовые требования хранятся в
EA (было — запись в xls- файле)

Команда проекта работает по SRS

SRS - doc-файл на одно бизнес-требование
(было — xls-файл на функциональную
область)

Единица измерения релиза — BRQ (было —
функциональная область

18. Принятые изменения в процессах

Декомпозиция больших BRQ на набор маленьких (C4,
C5)

Использование реестра для ведения бизнес-
требований (с полями «in scope/out of scope» и пр.)
(С1)

Создание уникально идентифицируемых атомарных
требований, трассируемых к BRQ, и хранение их в
общем репозитарии СУТ (с доп. Полями, например
списком зависимых компонентов) (С6)

Генерация SRS из СУТ по каждому BRQ для
разработки и управления (С4)

Использование в качестве единицы измерения работ
атомарных SR, а не функциональных областей (С2,
С3, С6, С8)

19. Типы трассировок для проверки,
ревью и согласования требований

На уровне продукта: BRQ — SRS (для
согласования)

На уровне компонентов/сервисов: BRQ-
компонентный CR-компонентная SRS (BRQ-
InfraCR-InfraSRS)

Для проверки покрытия: продуктовые
требования — компонентные требования

20. Типы трассировок для
управления

Для реализации и тестирования: BRQ-SRы

Для сложных для реализации требований:
SR — DevTask

Для синхронизации работ разных команд:
BRQ-CRы

Для планирования последовательности
работ: SRы — CR

Для мониторинга состояния продуктовой
разработки BRQ (статусы) - SRы (статусы),
BRQ (статусы) - CRы (статусы)

21. Версия 2. Результаты

22. Надо делать следующий релиз

23. Подготовка к следующему релизу

24. Подготовка к релизу 3. Как было
BRQ
[Epic] BRQ
SRSR
CR
SRS
TFS
SR
BRQ
SR
EA
[Epic] BRQ
SharePoint
CR
Bug
TeamTrack
CR
Bug
TestCases

25. Подготовка к релизу 3. Как будет
Change Requests
System requirements
Business Requirements
[EPIC] [BRQ] BRQ1
[EPIC] [BRQ] BRQ1.1
[BRQ] BRQ1.1.1
Just a grouping element
ДекомпозицияEPIC-а. В ней же
содержатся BUS-ы. Epic Decomposition
SR
CR: EP / Plugin / SC
CR: Component
CR: Infrastructure
[Constraint][BRQ] Constraint1related
Development Constraint.
Не является элементом управления .
SR
SR
SR
Создается по мере
разработки системных
требованийCreate and
trace with SR development
Создается после маппирования
архитектором системных
требований наPDK Create and
trace after component impact
analysis of SR
Линкуется после маппирования
архитектором системных
требований наPDK
Линкуется по мере
разработки системных
требований
Testing (Test Cases + Defects)
TestCase
Defect
TestCase
Defect
Component SRS
Infrastructure SRS
related
related

26. Lessons Learned

Использование атомарных бизнес-требований
позволяет нам быстрее понимать текущее
состояние проекта (LL1)

Использование атомарных системных требований
в качестве задач для разработки/тестирования
повышает качество продукта (LL2), но меняет
смысл требования (в пользу постановки задачи)

Отсутствие трассировок между требованиями и
артефактами тестирования (TestCase и багами)
мешает понять текущий статус конкретного
требования (C7, LL3)

Использование нескольких разных инструментов
для поддержки процесса снижает эффективность
разработки и качество продукта (LL4)

27. Выводы

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

29. Что требуется для создания и
поддержки процесса

Практики и правила должны быть хорошо
описаны и понятны всем

Инструменты должны быть настроены под
практики и удобны для пользователей

Команда, поддерживающая инструменты,
должна быть квалифицированная и
мотивированная

Между разными проектными командами
должен быть налажен обмен знаниями и
практиками

30. Необходимая поддержка
руководства

Выделение ресурсов на разработку и поддержку
процесса

Мотивация сотрудников всех ролей на
регулярное использование процесса

31. Спасибо!
Вопросы?
Ирина Сурова
mailto: Irina.Surova@kaspersky.com