Компоненты документа-концепции

Документ-концепция

Основные положения

• Документ-концепция (Vision document) описывает приложение в целом, включая описания целевых рынков, пользователей системы и функций приложения. |

• Документ- концепция определяет на наивысшем уровне абстракции как проблему, так и решение.

• Практически все программные проекты выиграют от наличия документа-концепции.

• Документ Delta Vision акцентирует внимание на том, что.изменилось.

Данная глава посвящена рассмотрению документа-концепции. Наш коллега Филипп крачтен (Philippe Kruchten) как-то сказал: "Если бы мне разрешили разработать только один документ, модель или другой артефакт для поддержки программного проекта, я бы выбрал краткий, хорошо сформулированный документ-концепцию. Документ-концепция сочетает в себе некоторые основные элементы документа маркетинговых требований и документа требований к продукту. Нам необходимо разработать этот конкретный документ по двум причинам.

Документ-концепция моего проекта

1. Каждому проекту нужен документ-концепция.

2. Это поможет нам в демонстрации процесса работы с требованиями, поскольку некоторые ключевые элементы данного процесса будут записаны в этом документе.

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

Документ-концепция — это важнейший документ программного проекта, который фиксирует потребности пользователя, функции системы и другие общие требования к проекту. Сфера действия документа-концепции распространяется на два верхних уровня пирамиды требований. Таким образом, он описывает на высоком уровне абстракции как проблему, так и решение.

Масштаб документа-концепции

Сфера действия документа-концепции

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

1. Отделом маркетинга, который выступает в качестве доверенного лица заказчика и пользователя и отвечает за успех продукта после реализации.

2. Командой проекта, разрабатывающей приложение.

3. Руководством, которое несет ответственность за бизнес-результат попытки.

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

Поскольку все программные проекты выиграют от наличия документа-концепции, мы собираемся описать его более подробно. Хотя наш пример ориентирован на программный продукт, его достаточно легко модифицировать, чтобы он отражал содержание любого конкретного продукта.

На рис. 17.1 представлена краткая схема документа-концепции, которая (с некоторыми настройками) использовалась для сотен программных продуктов и приложений. Полная версия данного документа приводится в приложении Б.

1.Введение

В данном разделе предлагается общий обзор документа-концепции.

1.1. Назначение документам концепции

В данном документе фиксируются, анализируются и задаются высокоуровневые потребности пользователей и функции продукта.

1.2. Краткое описание продукта

Формулируется цель приложения, версии и новые предоставляемые

функции.

1.3. Ссылки

Приводится полный список всех документов, упоминаемых в документе-концепции.

2. Описание пользователя

Кратко представлены общие сведения о пользователях системы.

2.1. Данные о пользователе/рынке

Кратко представлены основные данные о рынке, которые мотивируют решения относительно продукта.

2.2. Типы пользователей

Кратко описываются будущие пользователи системы.

2.3. Среда пользователя

2.4. Основные потребности пользователей

Перечисляются основные проблемы или потребности пользователей.

2.5. Альтернативы и конкуренты

Выявляются все приемлемые (с точки зрения пользователя) альтернативы.

3. Краткое описание продукта

3.1. Общий вид продукта

Предлагается блок-схема продукта или системы и ее интерфейсов с

внешней средой.

3.2. Определение позиции продукта на рынке

Предлагается обобщенная краткая характеристика (на самом высоком уровне абстракции) уникальной позиции, которую должен занять продукт на рынке. Мур (Мооrе) (1991) рекомендует использовать следующую форму.

Для [целевой клиент]
Который [формулировка потребности или возможности]
[Название продукта] является [категория продукта]
Который [формулировка основных преимуществ, т.е. указание причин, по которым продукт будет покупаться]
В отличие от [основные конкурирующие альтернативы]
Наш продукт [формулировка основных отличий]

3.3. Характеристика возможностей

Перечисляются основные возможности и функции, которые будут предоставлены продуктом.

Возможности клиентов Поддерживающие функции
Возможность 1 Функция
Возможность 2 Функция
Возможность 3 Функция

3.4. Предположения и зависимости

3.5. Затраты и цены

4. Атрибуты функций

Описываются атрибуты функций, которые будут использоваться для

оценки, отслеживания, задания приоритетов и управления функциями.

Некоторые из них перечислены ниже.

Статус Предлагаемый, принятый, включенный
Приоритет Число голосов но результатам накопительного голосования или критический, важный, полезный
Трудоемкость Низкая, средняя, высокая; командо -недели; человеко-месяцы;
Риск Низкий, средний, высокий
Стабильность Низкая, средняя, высокая
Целевая версия Номер версии
Предназначен для Фамилия
Причина Текстовое поле

5. Функции продукта

В данном разделе перечисляются функции продукта.

5.1. Функция №1

5.2. Функция №2

6. Ключевые прецеденты

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

7. Другие требования к продукту

7.1. Применяемые стандарты

Перечисляются все стандарты, которым должен соответствовать продукт.

7.2. Системные требования

Задаются все системные требования, которым должно соответствовать приложение.

7.3. Лицензирование в установка

Описываются все инсталляционные требования, которые оказывают влияние на создание программного кода или вызывают потребность в создании отдельного инсталляционного программного обеспечения.

7.4. Требования к производительности

Этот раздел используется для подробного описания требований к производительности.

8. Требования к документации

Описывается, какую документацию необходимо разработать для успешного развертывания приложения.

8.1. Руководство пользователя

Описывается цель и содержание руководства пользователя.

8.2. Интерактивные подсказки

Требования к интерактивным подсказкам, средствам предупреждения и т.п.

8.3. Руководства по инсталляции, конфигурация и файлы "Read Ме"

8.4. Маркировка и упаковка

9. Глоссарий

Рис. 17.1. Схема документа-концепции некоего программного продукта

Итак, документ-концепция кратко описывает все, что вы считаете более важным для продукта или приложения. Он представляет собой достаточно подробное описание на естественном языке, поэтому основным участникам проекта легко с ним работать.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: