 |
|
Смысл этого
тренинга |
|
Без качественных требований невозможно предсказать
сроки и стоимость, организовать разработку, применять
управление изменениями. Тренинг дает цельную картину
того, как выстроить процесс разработки требований
и управления ими на своем проекте. |
|
 |
|
|
|
SPM-03
Разработка требований к ПО и управление
ими |
|
Требования к ПО - отправная
точка любой разработки. От того, насколько они полны и детальны,
зависит правильность оценок продолжительности и стоимости
проекта. От того, насколько они ясны и проверяемы, зависит
количество переделок и удовлетворение Заказчика. Таким образом,
начиная разработку без качественной спецификации требований,
лишь с набором "пользовательских хотелок", Вы обрекаете
свои проект на превышение бюджета, невыполнение графика,
недовольство Заказчика. |
|
Именно поэтому независимо от
того, какой процесс Вы используете, он включает в себя действия
по сбору и обработке требований. Работа с требованиями подразумевает:
выявление источников, выявление целей, выявление требований,
трансляцию требований в детали спецификации, представление
спецификации способом, понятным всем заинтересованным лицам,
управление меняющимися требованиями. Все детали этой мозаики
одинаково важны - стоит выпасть одному фрагменту, и распадется
вся мозаика. |
|
Любой практик знает, насколько
тяжело не упустить ничего из виду при постановке процесса
управления требованиями на проекте. Поэтому мы собрали лучшие
практики, типичные ошибки и практические советы в одном
тематическом тренинге. |
|
Назначение тренинга |
|
Дать слушателям всю необходимую
теоретическую информацию о разработке требований и управлении
ими, дополнив ее практическими навыками и "дорожной картой"
выстраивания соответствующих процессов в своем проекте. |
|
Цели тренинга |
- Систематизировать
знания о типах требованиях и способах их документирования.
- Ввести
понятие уровней требований и трассируемости.
- Рассказать
о методиках выявления требований.
- Рассказать
о методиках документирования требований и снабдить слушателями
необходимыми практическими навыками документирования.
- Ввести
понятие "базовой версии требований" и рассказать о процессе
управления требованиями в проекте разработки.
- Познакомить
слушателями с базовыми возможностями UML
для документирования требований.
|
|
Необходимые предварительные знания |
- Опыт
работы разработчиком в команде, желательно над системой
большого размера.
- Опыт
руководства коллективом разработчиков существенно поможет.
- Знание
основ Unified Modeling Language
существенно поможет.
|
|
План
тренинга |
|
День
1 -
Документирование
требований |
День
2
-
Выявление
требований и управление ими |
|
Лекция 1 - Типы требований
и их источники |
Лекция 1 - Выявление
требований |
-
Что есть требование.
Типы требований и их взаимосвязи.
-
Требования и успех
проекта.
-
Требования в различных
процессах разработки.
-
Уровни требований.
Понятие о трассируемости.
-
Особые виды требований.
-
Типичные ошибки,
связанные с переходами по уровням.
|
-
Типичные проблемы
при выявлении требований.
-
Источники этих
проблем, классификация.
-
Техники выявления
требований.
-
Горизонтальные
и вертикальные прототипы.
- Quality Focus
Deployment (QFD).
- Joint Application
Development (JAD).
- On-Site Customer
(OSC).
|
|
Лекция 2 - Характеристики превосходных
требований |
Лекция 2 - Тонкости выявления требований |
-
Понятие о проверяемости.
Количественные и качественные проверки.
-
Ключевые вопросы.
Варианты использования, прототипы, эскизы интерфейса.
-
Что отличает превосходные
требования?
-
Типичные ошибки
формулировки требований.
-
Приоритизация требований.
Относительные и абсолютные приоритеты.
|
-
Где искать требования.
Таксономия типичных источников.
-
Заинтересованные
лица и пользователи системы.
-
Привилегированные
и непривилегированные классы.
-
Тонкости проведения
наблюдения.
- JAD
и ОSC -
сходства и различия.
-
Когда применять JAD.
-
Когда JAD
точно не сработает.
-
Аналитик требований
и его роль в проекте.
|
|
Лекция 3 -
Методики документирования требований |
Лекция 3 - Тестирование требований |
-
Основные методы
описания требований для каждого из уровней.
-
Образ и границы
проекта. Ширина и глубина описания требований.
-
Контекстные диаграммы
и диаграммы вариантов использования.
-
Особенности написания
вариантов использования.
-
Особенности подготовки
эскизов интерфейсов.
-
Шаблон IEEE 830-1998.
Рекомендации по использованию.
|
- V-образная
модель требований и тестирование требований.
-
Поиск неучтенных
требований.
-
Совместная работа над требованиями
(peer reviews).
-
Просмотр и инспекция
требований.
-
Правила проведения
инспекции.
-
Представление и
интерпретация результатов.
-
Трудности тестирования
требований и способы их преодоления.
|
|
Лекция 4 - Тонкости
документирования требований |
Лекция 4 -
Управление требованиями |
-
Тонкости написания
вариантов использования.
-
Аналитический паралич.
Первые оценки проекта.
-
Использование UML
для упрощения документирования.
- CASE-средства
- за и против.
-
Типичные ошибки
при документировании.
-
Лучшие практики
при документировании.
|
-
Причины изменчивости
требований. Три правила управления требованиями.
-
Типичный процесс
запроса изменений.
-
Проведение оценки
влияния.
-
Совет по управлению
изменениями.
-
Запросы-исключения.
|
|
|
Практические
занятия |
- Коллективный
разбор четырех кейсов.
- Домашнее
задание - разработка комплекта документации.
|
|
Аттестация |
-
Предварительное тестирование слушателей.
*)
-
Экзамен после тренинга.
*)
Предварительное и послетренинговое
тестирование включают вопросы примерно одного уровня, что
дает возможность оценить эффективность обучения и способности
обучаемого.
|
|
|
|
|
|
