Курсовая работа: Планирование и управление проектом
Оценку рисков требуется выразить в виде возможного превышения трудоемкости (пессимистичная оценка). Именно из данной оценки следует исходить при определении общей трудоемкости (цены) продукта.
В результате мы имеем нечетко сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может играть роль ТЗ, но с указанием в договоре на то, что более приоритетный документ "Документация пользователя" (см. ниже) и система будет приниматься по "Приемочным испытаниям" (см. также ниже)
| Степень Важности | Продукт этапа | Описание продукта |
| 1 | Постановка Задачи |
Цель проекта. Список ключевых требований без подробной расшифровки |
| 2 | Экономическое обоснование | Оценка экономического эффекта и себестоимости проекта. |
| 3 | Интерфейсный прототип | Модель одного из ключевых интерфейсов пользователя |
| 4 | Архитектурный прототип | Модель для оценочной проверки выбранной архитектуры |
Условие завершения этапа : подписание сторонами "Постановки Задачи" и "Экономического обоснования".
На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.
Одновременно в виде пошаговых сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.
Возможны два варианта взаимодействия "прототип-документация":
1) При относительно четком представлении о функциональности до разработки очередного прототипа должны быть готовы основные пункты "Документации", описывающие его работу. В данном случае "Документация" одновременно играет роль нечеткой спецификации на прототип. Нечеткость заключается в том, что "Документация" может быть исправлена с целью соответствия реализации в прототипе, если прототип реализовал удачное, но не документированное решение.
2) При отсутствии представления о лучшем варианте реализации по краткому заданию на основе "Постановки Задачи" сначала создается прототип. После одобрения Заказчиком документируется желаемое поведение системы.
Пользователь оценивает прототип и документацию одновременно. Если, осмотрев прототип, пользователь согласен с описанием поведения конечной системы в "Документации Пользователя", осуществляется переход к созданию прототипа следующего функционального модуля.
Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:
1. Описание программы делается на языке, понятном пользователю.
2. Уже на первых этапах разработки программы пользователь включается в анализ своей рабочей документации.
3. Нет необходимости править ТЗ и Документацию одновременно.
4. Как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.
|
Степень Важности | Продукт этапа | Описание продукта |
| 1 | Прототип всей системы |
Прототип системы - это набор прототипов проверяющий не менее 80% пользовательских и архитек? К-во Просмотров: 409
Бесплатно скачать Курсовая работа: Планирование и управление проектом
|