6.2. Этап Уточняющий.
На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.
Одновременно в виде пошаговых сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.
Возможны два варианта взаимодействия "прототип-документация":
1) При относительно четком представлении о функциональностидо разработки очередного прототипа должны быть готовы основные пункты "Документации", описывающие его работу. В данном случае "Документация" одновременно играет роль нечеткой спецификации на прототип. Нечеткость заключается в том, что "Документация" может быть исправлена с целью соответствия реализации в прототипе, если прототип реализовал удачное, но не документированное решение.
2) При отсутствии представления о лучшем вариантереализации по краткому заданию на основе "Постановки Задачи" сначала создается прототип . После одобрения Заказчиком документируется желаемое поведение системы.
Пользователь оценивает прототип и документацию одновременно. Если, осмотрев прототип, пользователь согласен с описанием поведения конечной системы в "Документации Пользователя", осуществляется переход к созданию прототипа следующего функционального модуля.
Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:
Описание программы делается на языке, понятном пользователю.
Уже на первых этапах разработки программы пользователь включается в анализ своей рабочей документации.
Нет необходимости править ТЗ и Документацию одновременно.
Как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.
Степень Важности | Продукт этапа | Описание продукта |
1 | Прототип всей системы | Прототип системы - это набор прототипов проверяющий не менее 80% пользовательских и архитектурных решений. Все прототипы должны быть приняты Заказчиком. |
2 | Документация (ТЗ) | Должны быть составлены и одобрены сценарии не менее 80% поведения конечной Системы. |
Условие завершения этапа: этап завершается письменным соглашением Заказчика и Исполнителя о том, что конечная система будет принята, если соответствует последней согласованной версии "Документации Пользователя"; архитектура и требования стабильны, не предвидится изменений более чем на 20% в ходе следующего этапа.
Важное замечание о юридической стороне. Вполне возможно, что не удается достигнуть согласия ключевых пользователей с прототипом или описанием в Документации. В данном случае Заказчик должен принять волевое решение на уровне топ-менеджера и определиться с требованиями. Если этого не происходит, или если требования выходят за рамки "Постановки задачи" с учетом надбавок на риск, рекомендуется пересмотреть трудоемкость/цену проекта или прекратить его. Указанная возможность прекращения проекта должна быть предусмотрена в договоре.
- Курс лекций по предмету «Метрология и качество программного обеспечения» Оглавление
- Введение
- 1. Проект
- 1.1. Направленность на достижение целей.
- 1.2. Координированное выполнение взаимосвязанных действий.
- 1.3. Ограниченная протяженность во времени.
- 1.4. Уникальность.
- 2. Управление проектом
- 2.1. Компьютерная модель проекта
- 2.2. Эффективность
- 2.3. Причины краха проектов.
- 3. Жизненный цикл проекта.
- 3.1. Формулирование проекта
- 3.2. Планирование.
- 3.3. Осуществление.
- 3.4. Завершение.
- 4. Процессы управления проектом
- 4.1. Процессы проекта
- 4.2. Группы процессов
- 4.3. Взаимосвязи процессов
- 4.4. Процессы инициации
- 4.5. Процессы планирования
- 4.6. Процессы анализа
- 4.7. Процессы исполнения и контроля
- 4.8. Процессы управления
- 4.9. Процессы завершения
- 5. Планирование проекта.
- 5.1. Типичные ошибки планирования
- 5.2. Определение целей проекта.
- 5.3. Управление и планирование ресурсов.
- 5.4. Оценка стоимости проекта.
- 5.5. Анализ и планирование рисков
- 5.5.1. Планирование управления рисками.
- 5.5.2. Идентификация рисков.
- 5.5.3. Качественная оценка рисков.
- 5.5.4. Количественная оценка рисков.
- 5.5.5. Планирование реагирования на риски.
- 5.5.6. Мониторинг и контроль.
- 6. Методика мягкого внедрения
- 6.1. Этап Постановочный.
- 6.2. Этап Уточняющий.
- 6.3. Этап Стабилизирующий.
- 6.4. Этап Внедрение.
- 7. Контроль качества.
- 7.1. Введение в стандарты iso 9000
- 1. Ориентация на клиента
- Общие требования
- Структура документации системы качества
- 8 Принципов менеджмента качества
- 8. Программные средства для управления проектами.
- 8.1.Open Plan.
- 8.2.Spider Project.
- 8.3.Primavera.