A análise de cada solicitação de mudança inicia-se com esta filtragem.
Muitas vezes nem o cliente nem o Gerente do Projeto conseguem distinguir uma mudança de um erro.
Um erro é o comportamente ou a descrição de um produto de trabalho inconsistente com o que já foi
aprovado. Exemplos: uma interrupção da navegação do software não prevista no cenário desse caso de uso, uma ambiguidade
na especificação de requisitos do software, etc.
Se a equipe determinar que uma solicitação de mudança na verdade é um erro, deve-se iniciar o processo de tratamento de
erros e finalizar a análise.
Uma mudança é uma alteração em um item de trabalho do projeto previamente aprovado. Uma mudança
pode existir em todas as fases, níveis de detalhamentos e produtos de trabalho.
Muitas vezes as mudanças são confundidas com o refinamento do requisitos. Para isto, deve ser analisado se o nível de
refinamento considerado já havia sido validado pelo cliente e inserido no escopo do projeto.
Exemplo 1: A fase de elaboração inicia requisitos de negócios do projeto definidos e aprovado no Documento de Visão.
Durante as demais fases novos requisitos de negócios podem ser solicitados, como o escopo do projeto é alterado, esta é
uma solicitação de mudança.
Exemplo 2: Na fase de elaboração todas as telas do software são validadas, no entanto, os cenários dos casos de uso a
partir da segunda iteração ainda não foram detalhados. Neste caso, no detalhamentos destes casos de uso na construção,
pode, surgir a necessidade de um novo campo na tela. Por já terem sido validadas, a alteração da tela é uma solicitação
de mudança, no entanto, estas são solicitações de mudanças que podem ser aprovadas pelo próprio gerente do
projeto, sem impacto financeiro, pois o processo de desenvolvimento aqui considerado reconhece que a criação das telas
na fase de elaboração estão em um nível de detalhamento superior a validação das telas junto a especificação dos casos
de uso da próxima iteração.
|
