WikiSort.ru - Программирование

ПОИСК ПО САЙТУ | о проекте
Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ  Проектирование  Программирование  Документирование  Тестирование
Модели
Итеративная  Спиральная  Каскадная  V-Model  Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.)  Cleanroom  OpenUP  RAD  RUP  MSF  DSDM  TDD  BDD
Сопутствующие дисциплины
Конфигурационное управление  Управление проектами  Управление требованиями  Обеспечение качества

Управление требованиями к программному обеспечению (англ. software requirements management) — процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритизацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.

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

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

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

Отслеживаемость требований

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

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

Задачи управления требованиями

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

Исследование

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

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

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

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

Анализ осуществимости

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

Для пользовательских требований текущая стоимость работы сравнивается с будущей стоимостью установленной системы. Задаются вопросы такие как: «Сколько нам сейчас стоят ошибки ввода данных?» Или, «Какова стоимость потери данных из-за ошибки оператора связанной с используемым интерфейсом?». Фактически, потребность в новом инструменте часто распознаётся, когда подобные вопросы попадают во внимание людей, занимающихся в организации финансами.

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

Техническая стоимость связана со стоимостью разработки программного обеспечения и аппаратной стоимостью. «Есть ли у нас нужные люди, чтобы создать инструмент?» «Нуждаемся ли мы в новом оборудовании для поддержки новой системы?»

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

Эти вопросы также указывают на основную суть управления требованиями. Человек и инструмент формируют систему, и это понимание особенно важно, если инструмент — компьютер или новое приложение на компьютере. Человеческий разум крайне эффективен в параллельной обработке и интерпретации тенденций с недостаточными данными. Компьютерный процессор эффективен в последовательной обработке и точном математическом вычислении. Основная цель управления требованиями для программного проекта состояла бы в том, чтобы гарантировать, что автоматизируемая работа назначена «правильному» процессору. Например, «не заставляйте человека помнить, где она находится в системе. Заставьте интерфейс всегда сообщать о местоположении человека в системе». Или «не заставляйте человека вводить те же самые данные в два экрана. Заставьте систему хранить данные и заполнять их где необходимо автоматически».

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

См. также

Примечания

    Литература

    • Davis, Alan M. Just Enough Requirements Management: Where Software Development Meets Marketing. — Dorset House, 2005. — 240 p. ISBN 978-0932633644.
    • CMMI Product Team (August 2006). “CMMI for Development, Version 1.2” (PDF). Technical Report CMU/SEI-2006-TR-008. Software Engineering Institute. Проверено 2008-01-22.
    • Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 3-540-47689-X

    Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".

    Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.

    Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .




    Текст в блоке "Читать" взят с сайта "Википедия" и доступен по лицензии Creative Commons Attribution-ShareAlike; в отдельных случаях могут действовать дополнительные условия.

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

    2019-2024
    WikiSort.ru - проект по пересортировке и дополнению контента Википедии