Jump to content

Приоритизация требований

Приоритизация требований используется в управлении программным продуктом для определения того, какие требования -кандидаты к программному продукту должны быть включены в определенную версию. Требования также имеют приоритет для минимизации рисков во время разработки, поэтому наиболее важные требования или требования с высоким уровнем риска реализуются в первую очередь. Существует несколько методов оценки приоритетности требований к программному обеспечению. [1] [2]

Введение

[ редактировать ]

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

Затратно-стоимостной подход

[ редактировать ]

Хорошим и относительно простым в использовании методом определения приоритетности требований к программному продукту является подход «затраты и стоимость». Этот подход был разработан Йоахимом Карлссоном и Кевином Райаном. Затем этот подход получил дальнейшее развитие и коммерциализацию в компании Focal Point (которая была приобретена Telelogic в 2005 году). Их основная идея заключалась в том, чтобы определить для каждого отдельного требования кандидата, какова будет стоимость реализации этого требования и какую ценность это требование имеет.

Оценка стоимости и стоимости требований была выполнена с использованием процесса аналитической иерархии (AHP). Этот метод был создан Томасом Саати . Его основная идея заключается в том, что для всех пар требований (кандидатов) человек оценивает ценность или стоимость, сравнивая одно требование пары с другим. Например, значение 3 для (Req1, Req2) указывает, что требование 1 ценится в три раза выше, чем требование 2. Проще говоря, это означает, что (Req2, Req1) имеет значение ⅓. В подходе Карлссона и Райана выделяются пять шагов по рассмотрению требований кандидата и определению приоритета среди них. Они суммированы ниже. [3]

  1. Инженеры по требованиям тщательно проверяют требования-кандидаты на предмет полноты и однозначности их изложения.
  2. Заказчики и пользователи (или подходящие заменители) применяют метод парного сравнения AHP для оценки относительной ценности требований-кандидатов.
  3. Опытные инженеры-программисты используют парное сравнение AHP для оценки относительной стоимости реализации каждого требования-кандидата.
  4. Инженер-программист использует AHP для расчета относительной стоимости каждого потенциального требования и стоимости реализации и отображает их на диаграмме стоимости. Стоимость отображается на оси Y этой диаграммы, а предполагаемая стоимость — на оси X.
  5. Заинтересованные стороны используют диаграмму «затраты-стоимость» в качестве концептуальной карты для анализа и обсуждения требований кандидата. Теперь менеджеры по программному обеспечению расставляют приоритеты требований и решают, какие из них будут реализованы.

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

Процесс планирования релиза состоит из подпроцессов:

  1. Приоритизация требований
  2. Выберите требования
  3. Определить требования к выпуску
  4. Проверка требований к выпуску
  5. Подготовить запуск

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

[ редактировать ]
  1. ^ Лехтола, Лаура, Марджо Кауппинен и Сари Куджала. « Проблемы приоритезации требований на практике ». Улучшение процесса разработки программного обеспечения, ориентированного на продукт. Springer Berlin Heidelberg, 2004. 497–508.
  2. ^ Берандер, Патрик и Аннелиз Эндрюс. « Приоритизация требований ». Разработка и управление требованиями к программному обеспечению. Springer Berlin Heidelberg, 2005. 69–94.
  3. ^ Карлссон Дж. и Райан К. (1997). Экономический подход к определению приоритетов требований, IEEE Software, сентябрь/октябрь 1997 г. , 67–74.
  4. ^ «Модель оценки ICE для определения приоритетов» .

Дальнейшее чтение

[ редактировать ]
  • И. ван де Верд, Сьяак Бринккемпер , Р. Ньювенхейс, Дж. Версендал и Л. Бийлсма (2006). Эталонная структура управления программными продуктами. Научный отчет. Департамент информационных и вычислительных наук, Утрехтский университет, Нидерланды, 2006 г. Представлено для публикации.
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: fc13ceb89960592c1d69e74bc58ac61d__1668600780
URL1:https://arc.ask3.ru/arc/aa/fc/1d/fc13ceb89960592c1d69e74bc58ac61d.html
Заголовок, (Title) документа по адресу, URL1:
Requirement prioritization - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)