41407

Обыгрывание ролей

Лекция

Информатика, кибернетика и программирование

Проблема требований Цель Статистика Основные причины успеха и провала проектов Высокая цена ошибок требований 2. Инженерия систем интенсивно использующих программное обеспечение Задача выявления требований 7. Преграды на пути выявления требований Синдром да но. МЕТОДЫ ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ Совещания посвященные требованиям Мозговой штурм и отбор идей Раскадровка Применение прецедентов 9.

Русский

2013-10-24

196.5 KB

3 чел.

13

Лекция N 4 – 11/12/02 

Содержимое предыдущих лекций

Лекция N 1-2-3 30/10/02-12/11/02-26/11/02

Объектно-ориентированный анализ и проектирование

Управление требованиями

1. Проблема требований

  1.  Цель
    1.  Статистика
    2.  Основные причины успеха и провала проектов
    3.  Высокая цена ошибок требований

2. Введение в управление требованиями

2.1. Определения

2.2. Подход к управлению требованиями

3. Команда разработчиков

3.1. Разработка программного обеспечения как командная деятельность

3.2. Профессиональные навыки, которыми должна обладать команда для эффективного управления требованиями

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

4. Анализ проблемы

4.1. Пять этапов анализа проблемы

  1.  Достижение соглашения об определении проблемы
  2.  Выделение основных причин — проблем, стоящих за проблемой
  3.  Выявление заинтересованных лиц и пользователей
  4.  Определение границ системы-решения
  5.  Выявление ограничений, налагаемых на решение

5. Моделирование бизнес – процессов

5.1. Цели моделирования бизнес-процесса

  1.  Использование методов инженерии программного обеспечения для моделирования бизнес – процессов
    1.  Унифицированный язык моделирования (UML)

6. Инженерия систем, интенсивно использующих программное обеспечение

  1.  Задача выявления требований

7.1. Преграды на пути выявления требований

  •  Синдром "да, но..."
  •  Синдром "неоткрытых руин"
  •  Синдром "пользователя и разработчика"

  1.  Функции продукта или системы

  1.  Потребности заинтересованных лиц и пользователей
    1.  Функции
    2.  Управление сложностью путем выбора уровня абстракции
    3.  Атрибуты функций продукта

9. МЕТОДЫ ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ

  1.   Совещания, посвященные требованиям
    1.   Мозговой штурм и отбор идей
    2.   Раскадровка
    3.   Применение прецедентов
    •  9.5.  Обыгрывание ролей

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

  •  Мы должны понимать, что многие пользователи не могут описать процедуры, которые они выполняют, или потребности, которые необходимо учесть. Зачастую это не входит в их задачу, и их никогда прежде не спрашивали об этом. Кроме того, это гораздо сложнее, чем кажется! Например, попытайтесь описать процедуру, с помощью которой вы зашнуровываете туфли.
  •  Многие пользователи опасаются признаться, что они не следуют предписанной процедуре; следовательно, то, что они вам говорят, может являться (а может и не являться) тем, что они делают в действительности.
  •  Некоторые пользователи применяют нестандартные или уникальные способы выполнения рабочих действий, которые могут маскировать реальные проблемы от наблюдателя.
  •  Ни один разработчик не в состоянии предвидеть все вопросы, которые необходимо задать, и ни один пользователь не знает, какие вопросы должен задать разработчик.
  •  Обыгрывание ролей может помочь при решении этих проблем. Оно не требует значительных затрат времени и средств. Обычно достаточно часа или половины дня, чтобы все стало ясно.

Методы, аналогичные обыгрыванию ролей

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

Сценарный просмотр

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

Одним из преимуществ сценарного просмотра является то, что сценарий можно модифицировать и проигрывать снова столько раз, сколько необходимо, пока актеры не сочтут его правильным. Сценарий можно также повторно использовать для обучения новых членов команды. Его можно модифицировать и проигрывать вновь, когда необходимо изменить поведение системы. В определенном смысле данный сценарий становится "живой" раскадровкой для проекта.

CRC-карточки (Class-Responsibility-Collaboration, класс-обязанность-взаимодействие)

Один из методов обыгрывания ролей часто применяется в объектно-ориентированном анализе. В данном случае каждому участнику выдается набор индексных карточек, описывающих класс (объект); обязанности (поведение); а также взаимодействия (с какими из моделируемых сущностей взаимодействует объект). Эти взаимодействия могут просто представлять сущности проблемной области (такие, как пользователи, нажатые кнопки, лампы и подъемники) или объекты, существующие в области решения (такие, как подсветка выключателя в холле, окно многодокументного интерфейса или кабина лифта).

Обыгрывание ролей является замечательным методом, хотя он используется не очень часто. Почему? Причин много. Во-первых, существует фактор дискомфорта. Не очень приятно портить простой заказ на покупку, когда за вами наблюдает заказчик или клерк, вводящий заказы. Во-вторых, имеется фактор смущения: столкнувшись с необходимостью общаться с реальными людьми вместо клавиатуры, мы оказываемся не в своей тарелке; в конце концов, мы посещали занятия по теории компиляторов, когда наши ровесники участвовали в драмкружках!

  1.  Создание прототипов

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

Виды прототипов

Существует много способов разбиения прототипов на категории. Например, Дэвис (Davis, 1995,а) в своей работе выделял следующие прототипы: отбрасываемые, эволюционирующие и операционные; вертикальные и горизонтальные: пользовательские интерфейсы и алгоритмические; и т.д. Каким должен быть прототип в каждом конкретном случае, зависит от того, какую проблему вы пытаетесь решить путем построения прототипа.

Например, если риск проекта связан преимущественно с применением технологического подхода— просто это никогда прежде не делалось таким способом и вы не уверены, сможет ли применяемая технология обеспечить нужную производительность или пропускную способность — можно создать архитектурный прототип, который главным образом демонстрирует осуществимость используемой технологии. Архитектурный прототип может быть отбрасываемым или эволюционирующим. "Отбрасываемый"" означает, что его задача состоит только в определении осуществимости; можно использовать всевозможные сокращения, альтернативные технологии, имитации для ее достижения. По окончании прототип просто отбрасывается, сохраняется только полученное в результате знавие. "Эволюционирующий" означает, что прототип реализуется в той же архитектуре, которую вы намерены использовать в конечной версии системы, и можно строить рабочую версию системы, развивая данный прототип.

Если же основной риск в проекте представляет интерфейс пользователя, можно разработать прототип требований с помощью любых технологий, позволяющих создать прототип пользовательского интерфейса как можно быстрее. На рис. 1 представлено дерево решений, которое можно использовать при выборе вида прототипа, наиболее подходящего для вашего проекта.

Рис.1  Дерево решений для выбора вида прототипа: верхняя ветвь— прототипы требований; нижняя — архитектурные прототипы

Прототипы требований

Для выявления требований мы сосредоточим наше внимание на видах прототипов, расположенных на верхней ветви данного дерева. Для начала рассмотрим определение.

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

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

• Созданный разработчиком прототип может использоваться для получения подтверждения заказчика, что разработчик правильно понимает требования.

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

• Созданный заказчиком прототип может помочь донести требования до разработчика.

Во всех трех случаях цель состоит в создании прототипа с наименьшими затратами. Если его создание обойдется слишком дорого, может оказаться более эффективным сразу создавать реальную систему!

Многие прототипы программного обеспечения являются прототипами требований и используются в основном для фиксации элементов интерфейса пользователя создаваемой системы. Тому есть две причины.

1. Появление множества недорогих и широко доступных средств быстрого построения интерфейсов пользователя.

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

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

Что прототипировать

Как же узнать, какую часть системы нужно прототипировать? В типичной ситуации наше понимание потребностей пользователей находится в диапазоне от хорошо понятных и легко объяснимых до совершенно неизвестных (рис. 2 ).

Рис.2. Наше понимание потребностей пользователей

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

Неизвестные требования являются теми "неоткрытыми руинами", которые мы хотели бы найти. К сожалению, мы не можем по-настоящему прототипировать их, так как в противном случае они уже не были бы неизвестными! Таким образом в качестве объекта прототирования остаются расположенные в середине "неясные" требования. Эти требования могут быть известны, но плохо определены и плохо понимаемы.

Построение прототипа

Выбор технологии, используемой для построения прототипа, зависит от принятия дальнейших решений в правой части дерева решений на рис. 1. Например, для отбрасываемого GUI-прототипа можно выбрать любой метод (при условии, что он является самым быстрым, самым недорогим способом реализации образцов GUI).

Если выбран эволюционирующий прототип, нужно применить тот же язык реализации и ту же среду разработки, которые будут использоваться в промышленном изделии. Придется затратить значительные усилия на проектирование архитектуры системы, а также применить все стандарты кодирования и программные процессы, которые вы намереваетесь использовать при создании системы. В противном случае вы будете пытаться развивать систему, которая имеет существенные недостатки в одном или нескольких из этих аспектов. В конце концов, может оказаться, что прототип придется отбросить! Или, что еще хуже, созданный из лучших побуждений прототип требований отрицательно повлияет на качество развертываемой системы.

Оценка результатов

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

Результат процесса прототипирования будет следующим.

1. Неясные требования становятся более понятными.

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

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

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

Заключение

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

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

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

10. Определение системы

10.1. Организация информации о требованиях

Ранее рассматривались методы анализа проблем. Они позволяют достичь понимания проблемы до того, как будут затрачены значительные усилия на ее решение. В этой части мы занимались исключительно областью проблемы.

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

Сейчас мы переходим из области проблемы к области решения и концентрируем свои усилия на определении системы, которую можно создать для удовлетворения потребностей пользователей и заинтересованных лиц. Чем ниже мы спускаемся по пирамиде (рис. 3), тем больше объем информации. Например, для выполнения одной потребности пользователя может понадобиться значительное число системных функций. Для дальнейшего определения поведения системы необходима дополнительная конкретизация; таким образом, объем необходимой информации увеличивается.

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

Рис.3. Функции в пирамиде требований

На данном этапе мы займемся организацией информации о требованиях, определением концепции  и организацией нашей команды для решения задачи управления требованиями к системе.

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

Реалии бюджета и графика таковы, что в конкретной версии вряд ли возможно удовлетворить все потребности пользователей. В любой деятельности, в которой участвует много людей, неизбежно возникают проблемы взаимодействия. Поэтому необходимо создать документ, с которым могут сверяться и на который могут ссылаться все участники.

Такой документ называется спецификацией требований. Спецификация требований к системе (или приложению) описывает ее внешнее поведение.

Замечание. Следуя исторической традиции, мы будем использовать в данном разделе термин документ, но требования могут храниться в виде документа, базы данных, модели прецедентов, архива требований или комбинации этих элементов. Как будет показано далее, для хранения данной информации можно использовать "пакет требований к программному обеспечению".

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

Система может быть очень сложной.

• Потребности заказчиков могут быть документированы до того, как производится  документирование подробных требовании.

• Система может быть членом семейства родственных продуктов.

• Создаваемая система может удовлетворять только некоторое подмножество всех  выявленных требований.

•  Цели маркетинга и бизнеса следует отделить от подробных требований к продукту.

В любой из этих ситуаций приходится вести множество документов.

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

Рис. 4. Система, состоящая из подсистем

В таких случаях создается спецификация требовании системного уровня, которая описывает внешнее поведение системы в целом (без учета ее разбиения на подсистемы), такое как запас топлива или скорость набора высоты. Полученная в результате системная архитектура описывает это разбиение и интерфейсы между полученными подсистемами.

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

 Процесс проектирования системы сам по себе создает новые классы требований.

Требования этого нового типа описывают уже внешнее поведение не системы (разве что в агрегированном виде), а новой подсистемы. В частности, интерфейсы между этими подсистемами становятся ключевыми требованиями: они представляют собой, по сути, контракты между подсистемами или обещания функционировать так, как условлено.

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

Рис. 5. Иерархия спецификаций, полученная в результате проектирования системы

Как показано па рис. 5, спецификации, которые в свою очередь уточняются дополнительными спецификациями подсистем, называются спецификациями системных требований (или спецификациями требований системного уровня).

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

Организация требований к семействам продуктов

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

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

• Разработать документ-концепцию семейства продуктов, который описывает способы совместной работы продуктов и их общие совместно используемые функции.

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

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

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

Полученная в результате организация требований представлена на рис. 6.

Рис. 6. Организация требований для семейства программных продуктов

"Будущие" требования

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

Лучше всего записывать оба типа требований в документ, но необходимо четко выделять те из них, которые планируется реализовать в текущей версии.

Отличие бизнес-требований и требований маркетинга от требований к продукту

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

Эти соображения следует задокументировать; но они не являются частью спецификаций требований.

Некоторые организации используют документ требований маркетинга (marketing requirement document, MRD), чтобы упростить общение между руководством, службой маркетинга и разработчиками и помочь в принятии разумных бизнес-решений, в том числе самого важного решения "делать, не делать".

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

• Кто является заказчиком?

• Кто является пользователем?

• На каких рынках предполагается продавать продукт?

• Как поделены эти рынки?

• Различаются ли требования пользователей в различных сегментах рынка?

•  Какие классы пользователей существуют?

• Какие потребности удовлетворяет продукт?

• Что это за продукт?

• В чем заключаются основные преимущества продукта; почему его будут покупать?

• Что собой представляют конкуренты?

• Что отличает продукт от конкурирующих продуктов?

• В какой среде будет использоваться система?

• Какими будут затраты на разработку?

• По какой цене предполагается продавать продукт?

• Как будет осуществляться инсталляция, дистрибуция и сопровождение продукта?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

функции.

1.3. Ссылки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предлагается обобщенная краткая характеристика (на самом высоком уровне абстракции) уникальной позиции, которую должен занять продукт на рынке. Мур (Moore) (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 Me"

  1.  Маркировка и упаковка
    1.   Глоссарий

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

Документ Delta Vision


Разработка документа-концепции и работа с ним, являясь центром приложения действий многих участников (заказчиков, пользователей, представителей руководства проекта и маркетинга), могут играть заметную роль в успехе (или неудаче) программного проекта. Зачастую к разработке и пересмотру этого документа привлекается даже дирекция компании. Ведение документа-концепции является важным профессиональным приемом, который в состоянии значительно повысить общую производительность работы над проектом.

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

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

Лидер продукта


 

А также другие работы, которые могут Вас заинтересовать

68149. ЛЮТЕРАНСТВО В КОНТЕКСТІ ЗАГАЛЬНОЄВРОПЕЙСЬКОГО ДУХОВНОГО РОЗВИТКУ: ОСОБЛИВОСТІ РЕЛІГІЙНО-КУЛЬТУРНИХ ВІДНОСИН 175 KB
  Науковий інтерес щодо вивчення лютеранства є досить закономірним що пояснюється недостатнім рівнем його висвітлення в нашій країні протягом тривалого часу а також наявністю певних тенденцій відродження духовного потенціалу України на засадах толерантності діалогічності та плюралізму.
68150. Драма-діалог Лесі Українки та діалогічна традиція в європейських літературах 204.5 KB
  Драматичні твори Лесі Українки завдяки своєрідності поєднання в жанрі філософського контексту й драматичної форми дозволяють виділити в них діалогізм філософськоестетичний спосіб мислення та діалогічність здатність до комунікації і окреслити їх поняттям драмадіалог. Творчі пошуки Лесі Українки...
68151. ТРУБНО-ПЕРИТОНЕАЛЬНА БЕЗПЛІДНІСТЬ ТА ДИСГОРМОНАЛЬНІ ЗАХВОРЮВАННЯ МОЛОЧНИХ ЗАЛОЗ 456.5 KB
  Відновлення репродуктивної функції жінок які страждають на безплідність частота якої коливається у межах від 10 до 20 є актуальною медичною та соціальною проблемою В. Тому дисгормональні захворювання молочних залоз ДЗМЗ являють значний інтерес з одного боку як можливий фон для виникнення злоякісного процесу...
68152. ОСНОВОПОЛОЖНІ ПРИНЦИПИ ПРАВА ЯК ІНТЕГРУЮЧИЙ ЕЛЕМЕНТ ПРАВОВОЇ СИСТЕМИ УКРАЇНИ 152 KB
  Протягом багатьох років принципи права є однією з центральних тем у теорії держави і права. В юридичній літературі слушно зазначається, що на підставі та з урахуванням принципів формується вся система права, приймаються юридичні акти, здійснюється правозастосування і тлумачення права.
68153. ЗАХОДИ АДМІНІСТРАТИВНОГО ВПЛИВУ, ЩО ЗАСТОСОВУЮТЬСЯ ДО НЕПОВНОЛІТНІХ 150 KB
  Така загрозлива тенденція зумовила у свою чергу необхідність пошуку оптимальних шляхів до покращання ситуації зокрема вжиття ефективних заходів адміністративного впливу спрямованих як на виховання так і на попередження адміністративних проступків серед молоді. Так до заходів адміністративної...
68154. ПРАГМАТИКО-ФУНКЦІОНАЛЬНІ ОСОБЛИВОСТІ ПОЛІТИЧНОГО ДИСКУРСУ США ТА УКРАЇНИ ХХІ СТОЛІТТЯ 948 KB
  Метою дисертаційної роботи є виявлення лексико-семантичних та синтактико-стилістичних типологічних особливостей сучасного українського й американського політичного дискурсу що зумовлює вирішення таких завдань: структурувати дефініції термінів політичний...
68155. КОНЦЕПТУАЛЬНА МЕТАФОРА У КЛІШЕ АНГЛОМОВНОГО НАУКОВОГО ТЕКСТУ 204.5 KB
  Для досягнення цієї мети в роботі вирішуються такі конкретні завдання: з’ясування ролі метафори у формуванні змісту наукового тексту а також ролі клішеметафор як стилістичного засобу мови науки; визначення основних положень теорії концептуальної метафори у їх взаємозв’язку з положеннями попередніх...
68156. ПСИХОЛОГІЧНІ ОСОБЛИВОСТІ ВІКОВОЇ ДИНАМІКИ СТРАХІВ У НАВЧАЛЬНІЙ ДІЯЛЬНОСТІ ШКОЛЯРІВ 240 KB
  Динамічний розвиток сучасного суспільства висуває до людини все більш високі вимоги. Для того, щоб бути активним учасником подій, людина має мобілізувати усі сили, як розумові, так і фізичні, що передбачає високий рівень психологічного напруження. Не секрет, що шкільне навчання часто супроводжується виникненням страхів.
68157. ОСНОВИ ТЕХНОЛОГІЧНОЇ ПІДГОТОВКИ АВІАЦІЙНОГО ВИРОБНИЦТВА СКЛАДНОПРОФІЛЬНИХ ВИРОБІВ НА БАЗІ АНАЛІТИЧНИХ МОДЕЛЕЙ ПРОЦЕСУ ФОРМОУТВОРЕННЯ 13.91 MB
  Виникає необхідність у зміненні підходів до теорії формоутворення. Процеси формоутворення при цьому багато в чому визначаються керівними програмами аналітичними залежностями інтерполяційних функцій законами розгону й гальмування робочих органів обладнання. Крім того шляхом застосування аналітичних моделей...