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

Question

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

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

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

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

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

Answer 1

@Люк

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

---

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

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

Answer 4

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

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

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

Answer 5

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