В чем разница между ошибкой и запросом на изменение в MSF для CMMI?

Question

В настоящее время я оцениваю шаблон процесса MSF for CMMI в TFS для использования в моей команде разработчиков, и у меня возникают проблемы с пониманием необходимости в отдельных типах рабочих элементов с ошибками и запросами на изменение.

Я понимаю, что при создании отчетов полезно различать ошибки (ошибки) и запросы на изменение (изменяющиеся требования).

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

Каковы преимущества наличия отдельного рабочего процесса для ошибок?

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

Answer 1

@ Люк

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

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

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

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

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

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

Запрос на изменение больше похож на , но мы должны рассмотреть и эту другую вещь ... хм ... .

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

Если сервер был предназначен для обработки более 300 000 000 000 просмотров страниц, то да, это ошибка, которой нет. Но проектирование сервера для обработки такого количества просмотров страниц - это больше, чем просто выражение , наш сервер должен обрабатывать 300 000 000 000 просмотров страниц , он должен содержать очень подробную спецификацию того, как он может это делать, вплоть до Гарантийное время обработки и среднее время доступа к диску. Если код затем реализуется точно так, как задумано, и не может работать должным образом, возникает вопрос: неправильно ли мы его разработали или неправильно? .

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

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

Опять же, конечно, будут исключения.

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

Answer 2

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

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

Однако для «ошибки» ЛЮБОЙ пользователь приложения должен иметь возможность инициировать ошибку.

В организации, в которой я внедрил TFS, только «начальники отделов» могут быть инициаторами «Запроса на изменение», но «Ошибки» были созданы из билетов «Службы поддержки» (не автоматизированы, просто через процесс ...)

Answer 3

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

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

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

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

---

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

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

Answer 4

Ошибка - это то, что нарушено в требовании, которое уже было одобрено для реализации.

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

В CMM они принципиально отличаются.

Answer 5

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