Еще раз про управление требованиями и системы управления требованиями, или мифы про Agile, Наталья Желнова, Сбербанк, CEE-SECR 2017

F74d4292cc3b7b79920fcca339e02a21?s=47 CEE-SECR
October 21, 2017

Еще раз про управление требованиями и системы управления требованиями, или мифы про Agile, Наталья Желнова, Сбербанк, CEE-SECR 2017

Этот доклад будет основан на исследовании бизнес-сценариев (кейсов), касающихся выбора инструментов и подхода к организации управления требованиями, анализа наиболее распространенных ошибок при выборе и внедрении этих систем.

Доклад рассчитан на главных аналитиков и руководителей отдела системного и бизнес-анализа, сталкивающихся с проблемой оптимизации процесса управления требованиями и внедрения систем управления требованиями.

F74d4292cc3b7b79920fcca339e02a21?s=128

CEE-SECR

October 21, 2017
Tweet

Transcript

  1. Управление требованиями: невыдуманные истории и немного практики Наталья Желнова SECR,

    Санкт-Петербург, 2017
  2. Цели Поговорим о целях 2

  3. Управление требованиями: какими могут быть цели? • Организация работы аналитика?

    • Следование определенным правилам работы? • Улучшение качества требований? • Управление документацией и организация версионного контроля? • Обеспечение возможности совместной работы проектной группы над требованиями? • Возможность определить и выполнять процедуры, связанные с согласованием и утверждением требований? • Обеспечение возможности контролировать результат разработки? 3
  4. Пример из жизни 4

  5. Цели процесса управления требованиями • Сокращение времени вывода продукта на

    рынок • Сокращение затрат на вывод продукта на рынок • Возможность контролировать состояние разработки продукта и управлять его разработкой: o управлять качеством продукта o управлять временем разработки o управлять ресурсами 5
  6. Методы Методы управления требованиями 6

  7. Организация процесса • Методики управления требованиями • Политики и регламенты

    управления требованиями • Шаблоны документов, в которых мы регистрируем требования • Описание практик, пользовательская документация • Выученные уроки 7
  8. Пример из жизни 8

  9. Пример из жизни 9

  10. Три истории • Григорий Печенкин. Чего я хочу от инструментов

    разработки требований. Затычки, костыли и грабли СУТ https://habrahabr.ru/company/sqalab/blog/217737/ • Елена Журавлева. Ведение требований в вики: наш опыт https://vimeo.com/45556935 https://dokumen.tips/technology/-confluence- jira.html • Юрий Химонин. Сбор и анализ требований к программному продукту https://studfiles.net/preview/3066071/ 10
  11. Организация процесса • Определить цели • Выполнить декомпозицию целей •

    Определить вехи процесса • Определить метрики, которые будут служить индикаторами достижения целей • Определить процедуры, которые будут выполняться для сбора метрик • Определить, как будет выполняться анализ метрик 11
  12. Инструменты Инструментарий управления требованиями 12

  13. Используемые инструменты • Документы, в которых содержатся требования (ТЗ, спецификации)

    • Хранилища документов, в которых размещаются документы • Сайты, на которых публикуются документы • Wiki-системы • Системы, поддерживающие визуальное моделирование • Трекеры • Системы управления требованиями и различные комбинации этих систем 13
  14. Системы управления требованиями (СУТ) • IBM Rational/Telelogic DOORS • Sparx

    Enterprise Architect • TFS • Devprom 14
  15. Что позволяют делать СУТ? • Разрабатывать требования Три стадии разработки

    продукта: o создание o развитие o поддержка • Визуализировать требования и разрабатывать модели o сценарии использования o домены, классы, данные o компоненты • Совместно работать с требованиями и моделями • Управлять изменениями o трассировать требования на другие требования и артефакты проекта o версионировать требования o повторно использовать требования • Анализировать требования 15
  16. Что позволяют делать ALM-системы? • Управлять жизненным циклом продукта или

    приложения: o Управлять разработкой продукта o Управлять эксплуатацией продукта o Управлять сопровождением продукта o Управлять документированием продукта o Управлять конфигурацией продукта o Управлять качеством продукта o Управлять возникающими проблемами и инцидентами • Без интеграции с ALM-системой внедрение СУТ не принесет существенной пользы 16
  17. Примеры • TFS (управление требованиями) + Sharepoint (хранилище документов) o

    Иерархическая структура требований o Хранилище моделей o Трассировки • Результаты: o Ускорение разработки (~30%) o Снижение трудозатрат на поддержку кода (~50%) 17
  18. И о метриках… • Проектная инфраструктура • Объем требований •

    Качество требований • Изменяемость требований • Качество процесса бизнес- и системного анализа в целом 18
  19. Проектная инфраструктура • Проектная инфраструктура должна включать: o Инструменты для

    документирования требований o Инструменты для совместной работы с требованиями o Инструменты для изменения требований o Инструменты для версионирования требований 19
  20. Метрики объема требований • Цели: o Управление объемом требований •

    Метрики: o Число требований к продукту/проекту o Число функциональных требований o Число вариантов использования/пользовательских историй и шагов вариантов использования/элементов пользовательских историй 20
  21. Метрики качества требований • Цели: o Управление качеством требований •

    Метрики: o Общее число ошибок в требованиях на итерацию (после завершения фазы анализа) o Число ошибок, приходящееся на одно требования (плотность ошибок в требованиях) o Уровень детализации требований (высокий/средний/низкий) o Соответствие принятым в компании стандартам, шаблонам, и т.д. 21
  22. Что такое ошибки в требованиях? • Противоречивость, незавершенность, непоследовательность, неправильность

    • Двусмысленность • Отсутствие необходимости • Невозможность проверить требования 22
  23. Метрики планирования • Цели: o Качественное управление работами по бизнес-

    и системному анализу • Метрики: o Запланированное время выполнения работ по системному и бизнес-анализу o Фактическое время выполнения работ o Точность планирования: (фактическое время/запланированное время) 23
  24. Метрики управления требованиями • Цели: o Улучшение управления требованиями •

    Метрики: o Число изменений в требованиях (по итерациям, по фазам итераций, по категориям требований) o Процент изменений в требованиях в отношении к общему объему требований o Трассировки требований (на проектные артефакты) и покрытие требований трассировками 24
  25. Метрики качества продукта • Цели: o Управление качеством продукта •

    Метрики: o Число ошибок в программе, относящихся к каждому требованию o Максимальное число ошибок на одно требование o Метрики, относящиеся к атрибутам качества 25
  26. Метрики «продукт глазами пользователя» • Цели: o Обеспечить удовлетворенность пользователя

    продуктом • Метрики: o Проблемы, связанные с использованием продукта, их число o Уровень удовлетворенности пользователей продуктом 26
  27. Итоги • Процесс управления требованиями должен основываться на целях, которых

    вы хотите достичь • Цели верхнего уровня должны быть декомпозированы до нижних уровней • Цели должны быть сопоставлены с метриками, которые вы правильно анализируете и интерпретируете 27
  28. Спасибо E-mail: nzhelnova@teamcit.ru LinkedIn: Natalia Zhelnova SlideShare: http://www.slideshare.net/nzhelnova Facebook: https://www.facebook.com/nzhelnova

    28