Atividade:
| ||||||||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: As práticas de Controle de Mudança do Projeto precisam ser estabelecidas no início da Fase de Elaboração, após a aprovação do projeto, e verificadas novamente ao longo do ciclo de vida do projeto, no início das Fases de Construção e Transição. | |
| Papel: Gerente de Controle de Mudança | |
| Mentores de Ferramentas: | |
| Detalhamentos do Fluxo de Trabalho: |
Finalidade
|
| Subetapas |
| Mentores de Ferramentas |
| Mais Informações: Conceitos: Gerenciamento de Solicitações de Mudança |
Um procedimento comum para administrar Solicitações de Mudança é mostrado no diagrama de atividades a seguir. (Clique em qualquer local no diagrama para obter uma descrição completa de Conceitos: Gerenciamento de Solicitações de Mudança)
O Formulário de Solicitação de Mudança é um artefato enviado formalmente que é usado para rastrear todas as solicitações (incluindo novos recursos, solicitações de melhoria, defeitos, mudança de requisitos etc.), junto com as informações de status relacionadas durante todo o ciclo de vida do projeto. Todo o histórico de mudanças será mantido com a Solicitação de Mudança, o que inclui todas as mudanças de estado, datas e motivos da mudança. Essas informações ficam disponíveis para revisões repetidas e para fechamento final. Um exemplo de Formulário de Solicitação de Mudança é fornecido em Artefato: Solicitações de Mudança.
O diagrama de estados a seguir mostra estados comuns pelos quais uma Solicitação de Mudança pode passar. (Clique em qualquer local no diagrama para obter uma descrição completa de Conceitos: Gerenciamento de Solicitações de Mudança)
Depois que uma Solicitação de Mudança é enviada, ela é analisada para garantir que seja realmente válida e possa ser avaliada quanto à validade pela equipe técnica e de gerenciamento apropriada. É necessário revisar as Solicitações de Mudança em diversos níveis da equipe de desenvolvimento. Em geral, o chefe da equipe revisará e aprovará as Solicitações de Mudança enviadas por membros da sua equipe. No entanto, se o escopo de uma mudança ultrapassar as responsabilidades da equipe, ela será escalada para o nível de revisão seguinte. Se o impacto da mudança atingir diversas equipes de desenvolvimento distintas, ela será revisada pelo Comitê de Controle de Mudança. No Rational Unified Process, o papel de Gerente de Controle de Mudança é usado para representar o papel do Comitê de Controle de Mudança (CCB).
Ocasionalmente, um problema de funcionamento do sistema relatado pode ser decorrente mais do uso, do que do fato de estar vinculado ao sistema de implementação. Também pode acontecer de o 'problema' já ter sido relatado e estar sendo abordado.
O resultado do passo de análise é aceitar a Solicitação de Mudança ou rejeitá-la com base no fato de ser inválida, duplicada ou 'fora do escopo', de acordo com as regras ou a visão do projeto atual.
No caso das mudanças válidas, o passo seguinte é avaliar a mudança e estabelecer o seu custo, com base no impacto que possui sobre todo o sistema e na facilidade com que pode ser implementada.
As informações do passo de estabelecimento de custo são fornecidas ao CCB para avaliação. O CCB revisa a Solicitação de Mudança e o impacto correspondente do ponto de vista estratégico, organizacional e técnico. Esse comitê deverá decidir se a Solicitação de Mudança pode ser justificada economicamente.
Depois que uma Solicitação de Mudança é aprovada, ela pode ser aplicada ao software. O software revisado passará por verificações de garantia de qualidade para assegurar que as mudanças tenham sido efetuadas de acordo com as práticas adotadas pelo projeto e não prejudiquem outras partes do software existente.
Após a implementação das mudanças, a nova versão do software será verificada em um build de teste do produto, incorporada a uma versão de 'release' de todo o software e testada nessa versão.
À medida que são efetuadas mudanças no software, é importante manter um registro de todas elas.
Uma forma eficaz de manter um histórico de mudanças é estabelecê-lo no início de cada componente de software e nas solicitações de mudança.
O exemplo a seguir mostra o tipo de dados de mudança a ser mantido em um cabeçalho de componente:
Histórico de Modificações
Versão Modificador Data Mudança Motivo
1.1 Bruce Bogtrotter 01.05.98 Intervalos de Teste CR#232
1.2 Maria Mussolini 02.06.98 Requisitos CR#454
Finalidade
|
| Subetapas |
O CCB se reúne com freqüência e conforme necessário.
As suas tarefas básicas são declarar baselines de produtos, revisar mudanças na baseline, bem como aprovar, rejeitar ou adiar a implementação dessas mudanças.
A finalidade deste passo é configurar um CCB que seja formado pelas 'pessoas certas', com autoridade efetiva sobre seus pares e conhecimento suficiente para evitar propostas de mudança imprudentes ou dispendiosas. O CCB precisa incluir representantes de todas as organizações ou envolvidos afetados, como:
O presidente do CCB deve fazer parte da empresa de Gerenciamento do Projeto. Ele deverá ter a capacidade de resolver conflitos na equipe de forma clara e aplicar as decisões da equipe ao projeto.
Sempre que possível, as decisões do CCB deverão ser tomadas por meio de consenso. A dinâmica do grupo reflete a natureza cooperativa do projeto de desenvolvimento. O papel do presidente é cultivar essa visão cooperativa e executar ações unilaterais, se necessário.
O CCB deverá se reunir com freqüência e conforme necessário para assegurar que as Propostas de Mudança sejam revisadas e organizadas de forma oportuna. A equipe de desenvolvimento deverá ver esse grupo como uma entidade confiável para a resolução de problemas que poderiam travar o progresso do projeto.
Finalidade
|
| Mentor de Ferramentas: Definir Notificações de Revisão e Mudança Usando o Rational ClearQuest |
A entrada para este passo é a lista de artefatos a ser desenvolvida durante o andamento do projeto.
Os membros da equipe precisam revisar artefatos relacionados a produtos para decidir se satisfazem ou não aos padrões de qualidade definidos do projeto, de modo que passem para a etapa seguinte de desenvolvimento. Se um produto for reprovado na revisão, ele será submetido a retrabalho, mudança e nova revisão.
Para que uma revisão seja 'eficaz', o produto deverá ser avaliado pelas pessoas certas que compreendem o escopo e o impacto de uma mudança ou melhoria proposta. Além disso, as revisões precisam ser de 'custo efetivo', de forma que o tempo da equipe dos principais implementadores e integradores não esteja sendo gasto na geração de defeitos de 'baixo impacto'.
Os membros da equipe que precisam estar envolvidos em uma revisão são representantes por parte do produtor, receptor e gerenciamento do 'produto'. O objetivo disso é garantir que todos os envolvidos com um interesse particular na qualidade do produto possam decidir se ele está pronto para passar para o nível seguinte de desenvolvimento.
No ambiente de equipe, todo o projeto é dividido em pacotes de trabalho. Os pacotes de trabalho são alocados para indivíduos responsáveis, para fins de implementação e integração. Por exemplo, todo o sistema é dividido em subsistemas e, depois, em pacotes individuais. Os membros de equipe responsáveis pela implementação de um pacote precisam se certificar de que suas mudanças sejam revisadas pelos seus pares no subsistema e por qualquer outra pessoa em outros subsistemas que possa ser atingida pelas mudanças.
O princípio da notificação de revisão e mudança é a comunicação com os pares, chefes de equipe e receptores das mudanças propostas, e a oportunidade de eles revisarem as propostas e fazerem comentários sobre elas.
Para obter mais orientações sobre este assunto, consulte Conceitos: Gerenciamento de Solicitações de Mudança.
|
Rational Unified Process
|
