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

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

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

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

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

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

7.08.2008 21:17:58
6 ОТВЕТОВ
РЕШЕНИЕ

@Luke

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

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

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

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

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

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

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

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

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

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

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

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

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

12
7.08.2008 22:17:29

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

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

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

1
7.08.2008 21:21:11

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

0
7.08.2008 21:26:59

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

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

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

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


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

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

2
7.08.2008 21:54:48

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

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

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

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

4
7.09.2008 13:36:55

Реализация всегда исходит из требований. Это может быть от менеджера по продукту, это может быть от некоторых случайных мыслей. Это может быть задокументировано, это может быть из какого-то разговора. В конце концов, даже такая простая вещь a := a + 1, как «реальная» реализация, будет основана на компиляторе, компоновщике, процессоре и т. Д., Что зависит от физического закона реальной жизни.

Ошибка - это то, что реализовано против ОРИГИНАЛЬНОГО требования. Кроме этого, это запрос на изменение.

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

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

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

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

0
10.09.2019 21:07:21