Оценка процессов управления требованиями в проекте Р4 -
«Автоматизация Российских студенческих отрядов»
|
№ |
Код |
Показатель |
Значение |
Опасное значение |
Целевое значение |
|
|
А1 |
Время разработки концептуальной модели |
8 дней |
20 дней |
10 дней |
|
|
А2 |
Количество замечаний Заказчика к концептуальной модели |
6 |
>25 |
10 |
|
|
А3 |
Затраты на формирование концептуальной модели |
5% |
20% бюджета проекта |
Сделать этап экономически выгодным |
|
|
В1 |
Время сбора требований |
10 дней |
25 дней |
15 дней |
|
|
В2 |
Покрытие требованиями предметной области |
98% |
<70% |
100% |
|
|
В3 |
Среднее количество обращений к заинтересованным сторонам до момента получения требований |
3 |
>8 |
4 |
|
|
С1 |
Процент подлежащих реализации требований |
90% |
<60% |
80% |
|
|
С2 |
Количество дополнительных требований |
5 |
30 |
10 |
|
|
С3 |
Процент требований, подлежащих корректировке |
1% |
20% |
3% |
|
|
С4 |
Точность планирования аналитических работ |
0,03 |
0,2 |
0,05 |
|
|
D1 |
Затраты на проектирование системы |
20% |
50% бюджета |
Сделать этап экономически выгодным |
|
|
D2 |
Время проектирования системы |
20% |
50% |
30% |
|
|
D3 |
Процент измененных требований |
1% |
10% |
3% |
|
|
E1 |
Количество замечаний, поступивших от Заказчика |
7 |
>20 |
10 |
|
|
E2 |
Время разработки прототипа |
3% |
>10% |
5% |
|
|
E3 |
Стоимость разработки прототипа |
3% |
>10% |
5% |
|
|
F1 |
Количество несогласованных требований |
10 |
10 |
5 |
|
|
F2 |
Процент утвержденных изменений |
90% |
80% |
50% |
|
|
F3 |
Количество новых выявленных требований |
10 |
10 |
5 |
|
|
F4 |
Стоимость выявленных изменений |
Экономически выгодно |
Превышение бюджета проекта |
Сделать этап экономически выгодным |
|
|
F5 |
Количество требований, потерявших актуальность |
2 |
5 |
0 |
|
|
F6 |
Процент нереализованных требований |
0,5% |
2% |
0 |
Оценка процессов управления требованиями в проекте Р5 -
Автоматизация открытых R&D центров - ФРИП ТПП
|
№ |
Код |
Показатель |
Значение |
Опасное значение |
Целевое значение |
|
|
А1 |
Время разработки концептуальной модели |
18 дней |
20 дней |
10 дней |
|
|
А2 |
Количество замечаний Заказчика к концептуальной модели |
3 |
>25 |
10 |
|
|
А3 |
Затраты на формирование концептуальной модели |
5% |
20% бюджета проекта |
Сделать этап экономически выгодным |
|
|
В1 |
Время сбора требований |
5 дней |
25 дней |
15 дней |
|
|
В2 |
Покрытие требованиями предметной области |
98% |
<70% |
100% |
|
|
В3 |
Среднее количество обращений к заинтересованным сторонам до момента получения требований |
2 |
>8 |
4 |
|
|
С1 |
Процент подлежащих реализации требований |
95% |
<60% |
80% |
|
|
С2 |
Количество дополнительных требований |
0 |
30 |
10 |
|
|
С3 |
Процент требований, подлежащих корректировке |
0,05% |
20% |
3% |
|
|
С4 |
Точность планирования аналитических работ |
0,1 |
0,2 |
0,05 |
|
|
D1 |
Затраты на проектирование системы |
45% |
50% бюджета |
Сделать этап экономически выгодным |
|
|
D2 |
Время проектирования системы |
45% |
50% |
30% |
|
|
D3 |
Процент измененных требований |
5% |
10% |
3% |
|
|
E1 |
Количество замечаний, поступивших от Заказчика |
3 |
>20 |
10 |
|
|
E2 |
Время разработки прототипа |
10% |
>10% |
5% |
|
|
E3 |
Стоимость разработки прототипа |
7% |
>10% |
5% |
|
|
F1 |
Количество несогласованных требований |
1 |
10 |
5 |
|
|
F2 |
Процент утвержденных изменений |
50% |
80% |
50% |
|
|
F3 |
Количество новых выявленных требований |
3 |
10 |
5 |
|
|
F4 |
Стоимость выявленных изменений |
Экономически невыгодно |
Превышение бюджета проекта |
Сделать этап экономически выгодным |
|
|
F5 |
Количество требований, потерявших актуальность |
0 |
5 |
0 |
|
|
F6 |
Процент нереализованных требований |
4% |
2% |
0 |
Задачи и роли процесса управления запросами на изменения
|
Задача |
Описание задачи |
Роль |
Вход |
Выход |
|
Планирование контроля изменений |
Создается план, который определяет каким образом изменяются требования, упорядочиваются, отслеживаются в течение жизненного цикла проекта |
Менеджер проекта |
План создания продукта |
План управления изменениями |
|
Регистрация запроса на изменение |
Запрос на изменение регистрируется в системе и ставится в очередь на рассмотрение |
Регистратор |
Запрос заинтересованной стороны |
Зарегистрированный запрос на изменение |
|
Пересмотр запроса на изменение |
Определяется обоснованность запроса. Если запрос обоснован, то определяется принадлежность изменения к текущей версии. Определение основывается на графике работ, доступных ресурсах, риске и т.д. |
Менеджер изменений |
Запрос на изменение |
Запрос на изменение |
|
Подтверждение состояния «Отклонено» или «Дубликат» для запроса на изменение |
Если запрос является дубликатом уже зарегистрированного ранее запроса или идентифицируется как неправильный, ему назначается соответствующий статус |
Менеджер изменений |
Запрос на изменение |
Запрос на изменение с соответствующим статусом |
|
Обновление запроса на изменение |
Если требуется дополнительная информация для оценки запроса, то после ее поступления, регистратор вносит данные и вновь ставит запрос в очередь рассмотрения |
Регистратор |
Запрос на изменение |
Обновленный запрос на изменение |
|
Выполнение изменений |
Назначенный сотрудник выполняет ряд работ, необходимых для выполнения запрошенных изменений |
Назначенный член команды разработчика |
Запрос на изменение |
Выполненный запрос на изменение |
|
Верификация изменений в тестовой сборке |
Проверка выполненных изменений в тестовой сборке продукта |
Тестировщик |
Запрос на изменение; Тестовая сборка; Журнал тестирования |
Запрос на изменение; Результаты тестирования |
|
Верификация изменений в собранном релизе |
Проверка выполненных изменений в сборке релиза продукта |
Тестировщик |
Запрос на изменение; Сборка; Журнал тестирования |
Запрос на изменение; Результаты тестирования |
|
Распределение работ |
Назначаются работы соответствующему члену команды разработчика в зависимости от типа запроса. Вносятся соответствующие изменения в график работ |
Менеджер проекта |
График работ |
Обновленный график работ |
Форма запроса на изменение
· Идентификация
o проект;
o номер запроса на изменение;
o тип запроса на изменение: (проблема или улучшение);
o заголовок;
o дата внесения;
o инициатор;
o приоритет запроса на изменение.
· Текущая проблема
o описание текущей проблемы;
o серьезная ошибка;
o неудобство;
o улучшение;
o новое требование;
o условия обнаружения проблемы;
o текущая среда разработки: оборудование;
o операционная система;
o компилятор;
o источник текущей проблемы;
o издержки от текущей проблемы.
· Предложенное изменение (инициатор)
o описание предложенного изменения;
o оценка стоимости реализации предложенного изменения.
· Предложенное изменение (группа оценки изменения)
o действие;
o одобрено;
o не одобрено;
o отсрочено;
o описание предложенного изменения;
o затрагиваемые элементы конфигурации;
o категория;
o исправление;
o улучшение;
o новые свойства;
o другое.
· Решение
o предполагаемая цена реализации предложенного изменения;
o программист;
o время реализации изменения;
o анализ;
o реализация;
o тестирование;
o документация;
o число изменяемых строк кода.
· Оценка
o методы тестирования;
o инспекция;
o демонстрация;
o тестирование;
o платформы тестирования;
o сценарии тестирования.
Задачи и роли процесса сбора требований
|
Задача |
Описание задачи |
Роль |
Вход |
Выход |
|
Разработка плана управления требованиями |
Разрабатывается документ, в котором описываются типы требований, их структура, методы сбора требований |
Аналитик |
Запросы заинтересованных сторон |
План управления требованиями |
|
Разработка концепции ИС |
Определяются основные свойства системы, устанавливаются границы |
Аналитик |
Запросы заинтересованных сторон; Бизнес-модель; |
Концепция |
|
Детализация требований |
Структурируются все требования к системе. Недостаточно описанные требования дополняются. Формируются спецификации требований |
Спецификатор требований |
Концепция; Варианты использования; Модель вариантов использования |
Спецификация программных требований; Дополнительная спецификация |
|
Приоритизация требований |
Определяется порядок реализации функциональности продукта |
Аналитик |
Концепция; Модель вариантов использования; План итерации |
Архитектура системы; План итерации уточненный |
|
Определение заинтересованных сторон и вариантов использования |
Определяются агенты и варианты использования системы. Варианты использования кратко описываются. Формируется модель вариантов использования |
Аналитик |
Концепция; Бизнес-модель; Запросы заинтересованных сторон |
Варианты использования; Модель вариантов использования |
|
Детализация вариантов использования |
Детализируется описание каждого варианта использования. Определяются дополнительные требования |
Спецификатор требований |
Концепция; Варианты использования (не детализированные); Модель вариантов использования (не детализированная) |
Варианты использования детализированные; Модель вариантов использования детализированнаая |
|
Моделирование пользовательского интерфейса |
Варианты использования описываются в терминах интерфейсных классов |
Дизайнер |
Модель вариантов использования детализированная; Дополнительная спецификация |
Интерфейсное описание вариантов использования |
Задачи/активности тестирования по методологии RUP
Задачи тестирования:
· Планирование тестов (Plan Test):
o Определение требований к тестам (Identify requirements for test);
o Формирование стратегии (Develop test strategy);
o Определение ресурсов (Identify test resources);
o Формирование графика работ (Create schedule);
o Разработка Плана тестирования (Generate Test Plan);
· Дизайн тестов (Design Test):
o Анализ объема работ (Prepare workload analysis);
o Описание тестовых случаев (Identify and describe test cases);
o Определение и структурирование тестовых процедур (Identify and structure test procedures);
o Обзор и оценка тестового покрытия (Review and assess test coverage);
· Разработка тестов (Implement Test):
o Разработка тестовых скриптов (Record or program test scripts);
o Создание/подготовка тестовых наборов данных (Establish external data sets);
· Выполнение тестов (Execute Test):
o Выполнение тестовых процедур (Execute Test procedures);
o Оценка выполнения тестов (Evaluate execution of Test);
o Проверка результатов (Verify the results);
o Исследование непредвиденных результатов (Investigate unexpected results);
o Запись ошибок (Log defects);
· Оценка тестов (Evaluate Test):
o Оценка покрытия тестовыми случаями (Evaluate Test-case coverage);
o Оценка покрытия кода (Evaluate code coverage);
o Анализ дефектов (Analyze defects);
o Определение критериев завершения и успешности тестирования (Determine if Test Completion Criteria and Success Criteria
have been achieved.
Таблица
Роли в процессе тестирования
|
Роль |
Описание |
|
Менеджер проекта по тестированию |
Производит управленческий контроль |
|
Тест дизайнер |
Разрабатывает план тестирования; Разрабатывает модель тестирования; Определяет тестовые наборы; Оценивает эффективность тестирования. |
|
Администратор тестовой системы |
Администрирует систему управления тестированием; Устанавливает и управляет доступом к тестовой системе. |
|
Тестировщик |
Выполняет тесты; Фиксирует результаты тестирования. |
|
Разработчик тестов |
Разрабатывает тестовые наборы; Создает тестовые классы; Собирает тестовые пакеты и интегрирует их в тестовую модель |