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

@Luke

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для "Bug", однако, ANY пользователь приложения должен иметь возможность инициировать ошибку.

В организации, в которой я реализовал TFS, только руководители отделов могут быть инициаторами "Change Request"-но "Bugs" были созданы из "Help Desk" билетов(не автоматизированных, а просто через процесс...)

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

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

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

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

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

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

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

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

Эти две вещи фундаментально различны при CMM.

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