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

@ Люк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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