Ирина Сурова для AnalystDays

 Использование трассировок на практике.

Опыт реального проекта

Компания «Лаборатория Касперского»

Обо мне В IT больше 10 лет, из них в системном анализе 5 лет опыт управления командой аналитиков опыт создания и поддержки процессов

разработки соавтор клуба прикладного системного

анализа проекта Stratoplan.ru участник сообщества аналитиков uml2.ru отвечаю за инструменты в отделе анализа

О теме

Трассировки в учебной литературе — серебрянная пуля

Трассировки на практике — тяжело и трудно Трассировки в research — вызовы и

надежды http://ollygotel.com/requirements-traceability/

Я перфекционист и практик Есть экспериментальные данные — хочу

поделиться :)

Контекст

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

практики и т.д.)

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

Релиз 1. Проектные артефакты

Бизнес-требования

Требования на функциональную областьСистемные

требования на функциональную область

Остальные артефактыПлан проекта

MS Excel

ПочтаMS Project

Вызовы и вопросы.1 Трудно определить, входит это бизнес-

требование в scope релиза или нет (C1) Трудно определить, как добавление бизнес-

требования повлияет на скоуп релиза(C2) Трудно определить состояние релиза (что

осталось сделать, что уже сделали) (C3) Трудно согласовывать требования (SRS на

функциональную область – большой, табличный формат не удобен для работы с изменениями и комментариями (C4 - не относится к трассировкам)

Вызовы и вопросы.2 Трудно точно планировать работы команды, т.к.

Функциональная область – слишком большой элемент для планирования (C5).

Трудно точно планировать объем работ по разработке в конкретной области, т.к. Количество требований неизвестно (C6).

Трудно быстро определить качество разработки конкретного функционала,так как требования и тесткейсы не связаны (C7).

Трудно точно планировать реализацию функционала, так как неясно, что уже поставили смежные команды, а что нет (C8).

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

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

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

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

Архитектура продуктов

Administrative Server

Corporate Network

Internet

Infrastructure Service 1 Infrastructure Service N

Kaspersky Lab Network

Internal System 1 Internal System M

Product 2Component 1

Component X

Product 1Component 1

Component N

Требования к изменениям процесса

Удобство создания требований для команды аналитиков — максимально

Удобство поддержки трассировок требований - максимально

Изменения для команды разработки — минимальны

Время, затрачиваемое на переформатирование/изменение форматов — минимально

Изобретение велосипедов - минимально

Продуктовые трассировки. Релиз 2

BRQ

[Epic] BRQ

SRSR

CR

SRS

TFS

SR

BRQ

SR

EA

[Epic] BRQ

SharePoint

CR

Bug

TeamTrack

CR

Bug

TestCases

Контекст проекта

Жесткие сроки выхода релизов (Time Driven Development)

Большая и распределенная команда Нет сложившегося процесса, который

устраивает команду

Предлагаемые изменения к релизу 2 База данных Бизнес-требований (BRQ) на

SharePoint со статусами и признаком вхождения в scope релиза (было - список)

Новые продуктовые требования хранятся в EA (было — запись в xls- файле)

Команда проекта работает по SRS SRS - doc-файл на одно бизнес-требование

(было — xls-файл на функциональную область)

Единица измерения релиза — BRQ (было — функциональная область

Принятые изменения в процессах Декомпозиция больших BRQ на набор маленьких (C4,

C5) Использование реестра для ведения бизнес-

требований (с полями «in scope/out of scope» и пр.) (С1)

Создание уникально идентифицируемых атомарных требований, трассируемых к BRQ, и хранение их в общем репозитарии СУТ (с доп. Полями, например списком зависимых компонентов) (С6)

Генерация SRS из СУТ по каждому BRQ для разработки и управления (С4)

Использование в качестве единицы измерения работ атомарных SR, а не функциональных областей (С2, С3, С6, С8)

Типы трассировок для проверки, ревью и согласования требований На уровне продукта: BRQ — SRS (для

согласования) На уровне компонентов/сервисов: BRQ-

компонентный CR-компонентная SRS (BRQ-InfraCR-InfraSRS)

Для проверки покрытия: продуктовые требования — компонентные требования

Типы трассировок для управления

Для реализации и тестирования: BRQ-SRы Для сложных для реализации требований:

SR — DevTask Для синхронизации работ разных команд:

BRQ-CRы Для планирования последовательности

работ: SRы — CR Для мониторинга состояния продуктовой

разработки BRQ (статусы) - SRы (статусы), BRQ (статусы) - CRы (статусы)

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

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

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

Подготовка к релизу 3. Как было

BRQ

[Epic] BRQ

SRSR

CR

SRS

TFS

SR

BRQ

SR

EA

[Epic] BRQ

SharePoint

CR

Bug

TeamTrack

CR

Bug

TestCases

Подготовка к релизу 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] Constraint1relatedDevelopment 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

Lessons Learned Использование атомарных бизнес-требований

позволяет нам быстрее понимать текущее состояние проекта (LL1)

Использование атомарных системных требований в качестве задач для разработки/тестирования повышает качество продукта (LL2), но меняет смысл требования (в пользу постановки задачи)

Отсутствие трассировок между требованиями и артефактами тестирования (TestCase и багами) мешает понять текущий статус конкретного требования (C7, LL3)

Использование нескольких разных инструментов для поддержки процесса снижает эффективность разработки и качество продукта (LL4)

Выводы

Где и когда применима данная схема

Качество реализации бизнес-требований критично для успеха продукта на рынке

Выход в срок критичен для успеха проекта Продукт содержит несколько подсистем со

сложными взаимосвязями, которые разрабатывают разные команды

подсистемы переиспользуются в разных продуктах

Процессы разработки в разных проектах похожи

Что требуется для создания и поддержки процесса

Практики и правила должны быть хорошо описаны и понятны всем

Инструменты должны быть настроены под практики и удобны для пользователей

Команда, поддерживающая инструменты, должна быть квалифицированная и мотивированная

Между разными проектными командами должен быть налажен обмен знаниями и практиками

Необходимая поддержка руководства

Выделение ресурсов на разработку и поддержку процесса

Мотивация сотрудников всех ролей на регулярное использование процесса

Спасибо!

Вопросы?

Ирина Сурова

mailto: Irina.Surova@kaspersky.com