Upload
sqalab
View
1.494
Download
4
Embed Size (px)
DESCRIPTION
Доклад Суровой Ирины на конференции Analyst Days-2. 25 мая, Санкт-Петербург. www.analystdays.com
Citation preview
Ирина Сурова для 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)
Выводы
Где и когда применима данная схема
Качество реализации бизнес-требований критично для успеха продукта на рынке
Выход в срок критичен для успеха проекта Продукт содержит несколько подсистем со
сложными взаимосвязями, которые разрабатывают разные команды
подсистемы переиспользуются в разных продуктах
Процессы разработки в разных проектах похожи
Что требуется для создания и поддержки процесса
Практики и правила должны быть хорошо описаны и понятны всем
Инструменты должны быть настроены под практики и удобны для пользователей
Команда, поддерживающая инструменты, должна быть квалифицированная и мотивированная
Между разными проектными командами должен быть налажен обмен знаниями и практиками
Необходимая поддержка руководства
Выделение ресурсов на разработку и поддержку процесса
Мотивация сотрудников всех ролей на регулярное использование процесса