41408

Документ Delta Vision

Лекция

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

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

Русский

2013-10-24

225 KB

0 чел.

22

Лекция 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.   Применение прецедентов
    4.   Обыгрывание ролей

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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.   Глоссарий

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

Документ Delta Vision

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

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

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

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

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

Документ-концепция версии 1.0

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

• Общая информация и введение

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

• Прочие требования (регуляторные и требования среды)

• Будущие функции, которые были выявлены, но не вошли в версию 1.0

Документ-концепция версии 1.0

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

Документ-концепция версии 2.0

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

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

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

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

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

Документ Delta Vision v2.0

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

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

• Документ-концепция 1.0 является всеобъемлющей точкой отсчета; здесь представлено все, что необходимо знать о нашем проекте.

• Delta Vision 2.0 определяет то, что отличает данную версию.

• Объединение этих двух документов задает полное определение продукта.

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

Если это необходимо, можно достаточно просто соединить содержимое документа-концепции 1.0 и Delta 2.0 в новый документ-концепцию 2.0, который представляет всеобъемлющую и полную картину проекта.

Не существует строгих правил относительно определений этих документов или того, что каждый из них содержит. В других обстоятельствах может оказаться удобным использовать Delta Vision только при относительно небольших модификациях (таких, как версии 1.1 и 1.2) и начинать все сначала и пересматривать определение продукта в целом для каждой крупной реализации (версии 2.0 или 3.0). В любом случае применение документа Delta Vision поможет лучше справиться с процессом управления требованиями, так как позволит команде сконцентрироваться на "том, что действительно важно" на каждом конкретном этапе.

Документ Delta Vision для уже существующей системы

Крайне редко практикуется документирование полных требований крупномасштабной существующей системы.


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

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

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

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

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

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

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

Роль лидера продукта

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

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

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

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

• Владеть концепцией продукта.

• Защищать интересы продукта.

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

• Противодействовать "просачиванию" функций.

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

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

• Управлять ожиданиями клиентов, исполнительной дирекции и внутренних отделов маркетинга и проектирования.

• Сообщать о реализуемых функциях всем заинтересованным лицам.

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

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

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

Лидер продукта в среде программных продуктов

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

В конце концов, команда оглядывалась на исполнительного директора по маркетингу, ожидая от него ответов, возможно, потому, что этот человек был наиболее активен. Он сказал: «Вы знаете, что больше всего беспокоит меня в этой команде? Я в любое время могу попросить, чтобы была добавлена некая новая функция, и никто никогда не скажет мне "нет". Как же мы можем надеяться хоть когда-нибудь отгрузить продукт ?».

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

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

Роль лидера выполняет Кэти, менеджер продукта. Заметим, что в данном случае менеджер продукта отвечает за маркетинг, а не за техническую сторону. Это достаточно типично для компаний, создающих программные продукты, так как, по крайней мере в теории, менеджер продукта ближе всех находится к заказчику, определяющему конечный успех или неудачу проекта. Более важная причина заключается в том, что именно маркетинг в конечном счете определяет "Итог", т.е. доход, связанный с выпуском продукта. Так и должно быть, ведь маркетинг отвечает за продажи и, соответственно, должен отвечать за принятие трудных решений.

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

Менеджер продукта (лидер):   Продукт должен иметь функции А,В и С, и вы должны создавать его, используя технологию X.

Менеджер разработки:        Я думаю, он должен иметь функцию D, а не С, и основываться на технологии Y.

Менеджер продукта:           А я говорю, что он должен иметь функции А, В и С. В конце концов, я отвечаю за достижение квоты сбыта и поэтому должен удовлетворить потребности моих клиентов. Если вы хотите отвечать за бизнес-результат, вы можете добавить функцию D, если при этом еще сможете вписаться в график.

Менеджер разработки:         Х-м-м (раздумывая о том, что означает для него помогать команде в достижении квоты}. Я не уверен, что это хорошая мысль. Мы действительно сделаем А, В и С. Но готовы ли вы отвечать за то, будет ли программа работать на самом деле?

Менеджер продукта:           (представляя себе, что в последующие 48 часов вместо подготовки к выходу на рынок с новым товаром он будет учиться тому, как пишется код) Ну что же, вы можете создавать программу, используя любую наиболее подходящую технологию.

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

Менеджер продукта:          Договорились.

Рис. Рабочий пример: структура команды, разрабатывающей программное обеспечение

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

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

Лидер продукта в отделе информационных технологий и систем (IS/IT)

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

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

Вопрос: "Кто отвечает за документ-концепцию?" имел подтекст: "Кто захочет сделать весьма опасный для карьеры шаг, ввязавшись в управление данным проектом?".

После анализа ситуации стало ясно, что никто из руководителей команды разработчиков не имеет необходимого авторитета для принятия столь сложных решений, но, тем не менее, лидера нужно было назначить. Команда выбрала Трейси, занимавшую должность руководителя проекта, и уполномочила ее выявлять и организовывать требования. Она владела документом-концепцией. Кроме того, она интервьюировала пользователей, устанавливала их относительные приоритеты и фиксировала данные в функционально-ориентированном формате. Но одновременно был также создан специальный управляющий комитет, или совет по контролю за изменениями проекта (project change control board, CCB). В его состав вошли три представителя руководства, каждый из которых имел свои функциональные обязанности.

Вопрос:

Лидер + Совет по контролю за изменениями

Что получится?

Ответ:

Шанс добиться успеха

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

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

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

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

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

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

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

• Ресурсами, которыми располагает проект.

• Временем, выделенным на реализацию.

На рис. 19.1 изображен "прямоугольник", который мы можем использовать для представления масштаба проекта.

Рис. Масштаб проекта

Площадь прямоугольника на рисунке представляет достижимый масштаб проекта. Его определяют следующие элементы.

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

Еще в 1970-х годах Фред Брукс (Fred Brooks) (1975) показал, что предложение добавить ресурсы в программный проект с целью увеличить отдачу является, в лучшем случае, рискованным. Закон Брукса гласит, что дополнительное привлечение рабочей силы к запаздывающему программному проекту приведет к еще большему его запаздыванию.

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

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

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

"Какой масштаб в начале проекта вам обычно задает руководство, заказчики или заинтересованные лица?". В ответ только изредка можно услышать "до 100 процентов". Как правило, числа в ответах варьируются от 125 до 500 процентов. Среднее значение каждый раз получается приблизительно одинаковым и составляет около 200 процентов. Эти данные в значительной мере совпадают с результатами исследований группы Стендиша, свидетельствующими, что более половины проектов будут стоить примерно вдвое больше, чем предполагалось. Теперь мы, возможно, понимаем, почему.

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

Перед командой встает дилемма: как сократить масштаб и удовлетворить заказчика ? Это один из самых трудных вопросов. Но еще не все потеряно! Мы рассмотрим способы решения данной проблемы в следующих двух главах.

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

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

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

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

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

Рис. Базовыйуровень требований

Первый шаг при задании базового уровня состоит в простом перечислении функций, Которые были определены для приложения. Очень важно при этом следить за уровнем детализации. Ранее  мы утверждали, что любую новую систему, независимо от того, насколько сложной она является, можно описать с помощью списка из 25-99 функций. Если их будет больше, то описание проекта будет слишком детализировано, что будет помехой при обсуждении его с заказчиками и командой разработчиков. Если же меньше — уровень детализации будет недостаточным для обеспечения удовлетворительного понимания приложения и оценки уровня необходимых для его реализации трудозатрат.

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

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

Функция 1. Поддержка внешней реляционной базы данных

Функция 2. Многопользовательская безопасность

Функция 3. Возможность клонирования проекта

Функция 4. Порт для новой версии операционной системы (ОС)

Функция 5. Новый "мастер" проекта

Функция 6. Импортирование внешних данных по стилям

Функция 7. Реализация средств предупреждения

Функция 8. Интеграция с подсистемой управления версиями

Таблица 1. Упорядоченные по приоритетам функции

Функция

Приоритет

Функция 1. Поддержка внешней реляционной базы данных Функция 4. Порт для новой версии ОС Функция 6. Импортирование внешних данных по стилям

Критический Критический Критический

Функция 3. Возможность клонирования проекта Функция 2. Многопользовательская безопасность Функция 5. Новый "мастер" проекта Функция 7. Реализация средств предупреждения Функция 8. Интеграция с подсистемой управления версиями

Важный Важный Важный Полезный Полезный

Оценка трудозатрат

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

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

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

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

Менеджер продукта: Насколько трудно сделать эту функцию?

Команда разработчиков: Мы не знаем. У нас до сих пор еще нет никаких

требований или результатов проектирования. Менеджер продукта: Я это понимаю, но является ли эта функция самой

простой, которую вам доводилось когда-либо создавать? Команда разработчиков: Нет. :

Менеджер продукта: Хорошо, является ли она наиболее сложной функцией в

списке? Команда разработчиков: Нет. Менеджер продукта: По шкале "низкая-средняя-высокая" мы присвоим ей

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

Среднюю степень сложности. Вы согласны? Команда разработчиков: Да. Она является средней. Менеджер продукта: Хорошо. Переходим к следующей функции.

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

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

Таблица. Список функций с добавленными оценками трудоемкости

Функция

Приоритет

Трудоемкость

Функция 1. Поддержка внешней реляционной базы данных

Критический

Средняя

Функция 4. Порт для новой версии ОС

Критический

Высокая

функция 6. Импортирование внешних данных по стилям

Критический

Низкая

Функция 3. Возможность клонирования проекта

Важный

Высокая

Функция 2. Многопользовательская безопасность

Важный

Низкая

Функция 5. Новый "мастер" проекта

Важный

Низкая

Функция 7. Реализация средств предупреждения

Полезный

Низкая

Функция 8. Интеграция с подсистемой управления версиями

Полезный

Высокая

Добавление элемента риска

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


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

Таблица. Список функций с добавленными оценками риска

Функция

Приоритет

Трудоемкость

Риск

Функция 1. Поддержка внешней реляционной базы данных

Критический

Средняя

Низкий

Функция 4. Порт для новой версии ОС

Критический

Высокая

Средний

Функция 6. Импортирование внешних данных

Критический

Низкая

Высокий

по стилям

Функция 3. Возможность клонирования проекта

Важный

Высокая

Средний

Функция 2. Многопользовательская безопасность

Важный

Низкая

Высокий

Функция 5. Новый "мастер" проекта

Важный

Низкая

Низкий

Функция 7. Реализация средств предупреждения

Полезный

Низкая

Высокий

Функция 8. Интеграция с подсистемой управ

Полезный

Высокая

Низкий

ления версиями

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

Сокращение масштаба

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


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

Атрибуты и их значения

Что делать

Приоритет: критический Трудоемкость: высокая

Риск: высокий

Приоритет: критический Трудоемкость: высокая

Риск: низкий

Приоритет: критический Трудоемкость: низкая Риск: низкий

Внимание! Нужно немедленно определить стратегию снижения риска; немедленно финансировать; основное внимание необходимо уделить достижимости посредством архитектуры

По-видимому, трудоемкий элемент; немедленно финансировать Финансировать как безрисковый фактор или отложить на потом

Привлечение заказчиков к управлению масштабом их проекта

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

Это заключение основывается на нескольких важных моментах.

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

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

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

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

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

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

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

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

Для этого проще всего сначала представить себе систему как некий черный ящик и подумать о том, что следует определить, чтобы полностью описать, что делает этот черный ящик

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

Рис. Элементы системы

Используя аналогичный подход, Дэвис (Davis, 1999) отметил, что для полного опре-1еления системы необходимо описать следующие пять основных категорий элементов.

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

2. Выводы системы. Нужно описать поддерживаемые устройства вывода, такие как речевой вывод или видеотерминал, а также протокол и форматы генерируемой системой информации.

3. Функции системы. Отображение вводов в выводы и их различные комбинации.,

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

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

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

Взаимосвязь между функциями и требованиями к программному обеспечению

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

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

Больше внимания требованиям, а не проектированию

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

• Разработка требований предшествует проектированию.

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

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

Это удачная модель, от которой можно отталкиваться при решении задач управления требованиями. Дэвис (Davis, 1993) назвал ее парадигмой "что вместо как", где "что" — это требования ("что" система должна делать), а "как" представляет собой проектное решение, которое следует реализовать для достижения этой цели.

Для такого представления есть причины. Действительно, лучше понять требования перед тем, как приступать к проектированию, а большинство ограничений проектирования ("использовать XYZ-библиотеку классов для доступа к базе данных") являются важными проектными решениями, записанными в активы требований с тем, чтобы мы знали, что они получены по условиям контракта или по достаточно веским техническим причинам.


 

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

49604. Усилитель звуковой частоты на биполярных транзисторах отечественного производства 667.5 KB
  Выбор обоснование и расчет структурной схемы усилителя. Расчет АЧХ усилителя. На их основе можно сконструировать отдельные каскады и структурные блоки усилителя мощности. Выбор того или иного варианта реализации усилителя зависит от поставленной перед инженером задачи простоты исполнения и экономических соображений.
49606. ПРОЕКТИРОВАНИЕ АНАЛОГО-ЦИФРОВОГО ПРЕОБРАЗОВАТЕЛЯ С USB - ВЫХОДОМ 1.03 MB
  ПРОЕКТИРОВАНИЕ АНАЛОГОЦИФРОВОГО ПРЕОБРАЗОВАТЕЛЯ С USB ВЫХОДОМ Пояснительная записка к курсовому проекту по дисциплине Схемотехника ЭВМ ИНМВ. Омск 2013 Задание Проектирование аналогоцифрового преобразователя с USB выходом. Объектом исследования является аналогоцифровой преобразователь с USB выходом. Цель работы – разработать функциональную и принципиальную схему АЦП рассчитать входные усилители и фильтры нижних частот выбрать микросхему АЦП выбрать тип конвертора USB рассчитать и выбрать преобразователи DCDC и микросхемы...
49609. Расчёт токов короткого замыкания для оценки параметров основного оборудования подстанций сети. Выявление необходимости реактирования линий 10 кВ, отходящих от подстанций 4.99 MB
  В первой части расчетнопояснительной записки представлены обоснование и выбор вариантов схем электрической сети произведен выбор основных параметров схем сравнение техникоэкономических показателей схем и определение наилучшего варианта. Вторая часть содержит теоретические выкладки и пример практического расчета по теме: Расчёт токов короткого замыкания для оценки параметров основного оборудования подстанций сети. ФОРМИРОВАНИЕ ВАРИАНТОВ СХЕМ СЕТИ. ВЫБОР НОМИНАЛЬНОГО НАПРЯЖЕНИЯ СЕТИ.
49610. Расчет защиты зерноочистительного комплекса 1.82 MB
  Чтобы обеспечить бесперебойную и качественную работу необходимо применять защиту для электродвигателей. Для этого существует множество аппаратов, которые способны обеспечить защиту, как по току, так и по напряжению.