Каково различие между ошибкой и запросом на изменение в MSF для CMMI?
По-видимому, это также может быть вызвано переименованием APK до его установки. Я хотел уменьшить количество пользователей, которых нужно было сделать, чтобы получить приложение с нашего веб-сайта, сократив имя файла. После этого они не смогли установить его.
Как только я вернусь к исходному имени файла, используемому при создании и подписании пакета, я смог обновить установленное приложение.
5 ответов
@Luke
Я не не соглашаюсь с Вами, но этим различием обычно является объяснение, данное, для того, почему существует два различных процесса, доступные для обработки двух типов проблем.
Я сказал бы, что, если цвет домашней страницы был первоначально разработан для красного, и по некоторым причинам это сине, это - легко быстрое исправление и не должно вовлекать многих людей или человеко-часы, чтобы сделать изменение. Просто проверьте файл, измените цвет, перепроверьте его в и обновите ошибку.
Однако, если цвет домашней страницы был разработан для красного, и красный, но кто-то думает, что это должно быть сине, то есть, мне так или иначе, другому типу изменения. Например, кто-то думал о влиянии, которое это могло бы оказать на другие части страницы, как изображения и логотипы, накладывающие синий фон? Могли быть границы вещей, который выглядит плохо? Ссылка, подчеркивающая, является синей, который обнаружится?
Как пример, я красный/зеленый страдающий дальтонизмом, изменение цвета чего-то, для меня, не чего-то, что я беру слегка. Существует достаточно веб-страниц в сети, которая дает мне проблемы. Только для высказывания мнения, что даже самое тривиальное изменение может быть нетривиальным, если Вы рассматриваете все.
Фактическое изменение реализации конца является, вероятно, большой частью того же, но мне запрос на изменение является другим зверем, точно потому что это, как должны думать, о больше удостоверяется, что будет работать как ожидалось.
Ошибка, однако, то, что кто-то сказал, что это - то, как мы собираемся сделать это, и затем кто-то сделал это по-другому.
Запрос на изменение больше похож, но мы должны рассмотреть эту другую вещь также... хм....
Существуют исключения, конечно, но позволяют мне демонтировать Ваши примеры.
Если сервер был разработан для обработки больше чем 300,000,000,000 просмотров страниц, то да, это - ошибка, которую это не делает. Но разрабатывая сервер для обработки этого много просмотров страниц больше, чем просто говорят, что наш сервер должен обработать 300,000,000,000 просмотров страниц, он должен содержать очень подробную спецификацию для того, как он может сделать это, право вниз на гарантии времени обработки и средние времена доступа к диску. Если код затем реализован точно столь же разработанный и не могущий работать как ожидалось, то вопрос становится: мы разрабатывали его неправильно, или мы реализовывали его неправильно?.
Я соглашаюсь, что в этом случае, нужно ли это рассмотреть, недостаток дизайна или дефект реализации зависят от истинной причины для того, почему этому не удается соответствовать ожиданиям. Например, если бы кто-то предположил, что диски были 100x времена с такой скоростью, как они на самом деле, и это, как считают, причина того, почему серверу не удается работать как ожидалось, то я сказал бы, что это - ошибка дизайна, и кто-то должен перепроектировать. Если, исходным требованием которого много просмотров страниц должны все еще быть сохранены, главную модернизацию с большим количеством данных в оперативной памяти и подобный, возможно, придется предпринять.
Однако, если кому-то только что не удалось принять во внимание, как диски набега работают и как правильно извлечь выгоду из чередуемых медиа, это - ошибка и, возможно, не нуждалось бы в этом большом из изменения для фиксации.
Снова, конечно, будут исключения.
В любом случае исходным различием, которое я заявил, является то, которое я нашел, чтобы быть верным в большинстве случаев.
Ошибка - что-то, что повреждается в требовании, которое было уже утверждено для реализации.
Запрос на изменение должен пройти цикл, в котором влияние и усилие должны быть оценены для того изменения, и затем это должно быть утверждено для реализации, прежде чем работа над ним сможет начаться.
Эти два существенно отличаются под CMM.
Следует иметь в виду, что часть определения Типа изделия Работы для TFS является определением, он - "Рабочий процесс", означающий состояния, которыми объект работы может быть и переходы между состояниями. Это может быть защищено ролью безопасности.
Таким образом - вообще говоря, - "Запрос на изменение" инициировался бы и утверждался бы кем-то относительно высоко в организации (кто-то с правами "Спонсорства", связанными с расходами ресурсов для создания (возможно очень большой), изменяется на систему. В конечном счете этот человек был бы тем, чтобы утвердить, что изменение было внесено успешно.
Для "Ошибки" однако, ЛЮБОЙ пользователь приложения должен смочь инициировать Ошибку.
В организации я реализовал TFS в, только Начальники отделов могут быть инициаторами "Запроса на изменение" - но "Ошибки" были созданы из билетов "Справочной службы" (не автоматизированный, только посредством процесса...)
Обычно, хотя я не могу говорить за CMM, запросы на изменение и ошибки обрабатывают и рассматривают по-другому, потому что они обычно обращаются к различным частям Вашего жизненного цикла приложения.
Ошибка является дефектом в Вашей реализации программы. Например, при разработке программы, чтобы смочь добавить два числа и дать пользователю сумму, дефект был бы то, что она не обрабатывает отрицательные числа правильно и таким образом ошибку.
Запрос на изменение состоит в том, когда у Вас есть дефект дизайна. Например, Вы, возможно, конкретно сказали, что Ваша программа не должна обрабатывать отрицательные числа. Запрос на изменение затем регистрируется, чтобы перепроектировать и таким образом повторно реализовать ту часть. Дефект дизайна не мог бы быть намеренным, но мог легко быть, потому что Вы просто не полагали, что часть при исходной разработке программы или новых случаев, которые не существовали в то время, когда первоначальный проект был создан, была изобретена или обнаружена с тех пор.
Другими словами, программа могла бы работать точно, как разработано, но должна быть изменена. Это - запрос на изменение.
Как правило, исправление ошибки считают намного более дешевым действием, чем выполнение запроса на изменение, поскольку ошибка никогда не предназначалась, чтобы быть частью Вашей программы. Дизайн, однако, был.
И таким образом другой рабочий процесс мог бы быть необходимым для обработки двух различных сценариев. Например, у Вас мог бы быть другой способ подтвердить и зарегистрировать ошибки, чем Вы имеете для запросов на изменение, которые могли бы потребовать, чтобы больше работы разметило последствия изменения.
Действительно ли мое предположение является неправильным затем, что запросы на изменение должны быть сгенерированы от ошибок? Я смущен, потому что я не думаю, что все ошибки должны быть автоматически утверждены для реализации - они могут быть тривиальными, и по крайней мере в нашем случае пройдет тот же процесс рассмотрения как запрос на изменение прежде чем быть присвоенным разработчику.