Atividade:
| ||||||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Assim que o item de configuração tiver uma baseline e tiver entrado no sistema de gerenciamento de configuração, todas as solicitações de mudanças nele deverão passar pelo processo oficial de gerenciamento de solicitações de mudanças. | |
| Papel: Analista de Teste | |
| Mentores de Ferramentas: |
|
| Mais Informações: |
|
| Detalhamento do Fluxo de Trabalho: |
O papel Designado executará o conjunto de atividades definidas na seção adequada do processo (por exemplo, requisitos, análise e design, implementação, produzir materiais de suporte ao usuário, projetar testes, etc.) para efetuar as mudanças solicitadas. Essas atividades incluem todas as atividades normais de revisão e de testes unitários, como descrito no processo normal de desenvolvimento. A Solicitação de Mudança será, então, marcada como Resolvida. Isso significa que a resolução dessa Solicitação de Mudança foi concluída e está pronta para verificação.
Depois de Resolvidas pelo papel designado (analista, desenvolvedor, testador, redator técnico, etc.), as mudanças são colocadas em uma fila de teste designada a um testador e Verificadas em um build de teste do produto. Uma Solicitação de Mudança que foi Verificada em um build de teste está pronta para ser incluída em um release. Uma Solicitação de Mudança que falha em um build de teste ou em um release será colocada em um estado de Teste Reprovado. A propriedade passa automaticamente para o papel que resolveu a solicitação.
Depois que a mudança resolvida é Verificada em um build de teste do produto, a Solicitação de Mudança é colocada em uma fila de releases para ser comparada a um build do release do produto e produzir notas de release, e a solicitação é Fechada.
Uma Solicitação de Mudança Fechada não requer mais atenção. Este é o estado final a ser atribuído a uma Solicitação de Mudança. Somente o Administrador de Revisão do CCB pode fechar uma Solicitação de Mudança. Depois que a solicitação for Fechada, o solicitante receberá uma notificação por e-mail com o estado final da Solicitação de Mudança. Uma Solicitação de Mudança pode ser Fechada: 1) depois que a resolução Verificada é validada em um build de release, 2) quando o estado Recusada é confirmado ou 3) depois de confirmado que a solicitação é Duplicada. No último caso, o solicitante será informado da solicitação duplicada e ela será acrescentada à Solicitação de Mudança para futuras notificações (consulte as definições de estado "Recusada" e "Duplicada" para obter mais detalhes). Se o solicitante quiser argumentar contra algum fechamento, a solicitação deverá ser atualizada e Enviada novamente para revisão do CCB.
Os estados típicos pelos quais uma Solicitação de Mudança passa são mostrados em Conceitos: Gerenciamento de Solicitações de Mudança)
| Finalidade: | Verificar se a atividade foi concluída de modo adequado e se os artefatos resultantes são aceitáveis. |
Agora que o trabalho foi concluído, convém certificar-se de que o trabalho foi vantajoso e que não foi apenas um grande consumo de papel. Você deve avaliar se o trabalho é de qualidade adequada, e se ele é completo o suficiente para ser útil aos membros da equipe que o usarão em seguida como entrada para o trabalho deles. Onde for possível, use listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência são "suficientemente boas".
Faça as pessoas que realizam as atividades posteriores, que dependem do seu trabalho como entrada, participarem da revisão do trabalho temporário. Faça isso enquanto você tiver tempo disponível para tomar alguma ação para resolver os problemas delas. Você também deve avaliar o trabalho em relação aos principais artefatos de entrada para certificar-se de que eles foram representados de modo exato e suficiente. Talvez seja conveniente que o autor do artefato informado revise o seu trabalho nesse sentido.
Não se esqueça que o RUP é um processo iterativo e que, em muitos casos, os artefatos evoluem com o tempo. Como tal, nem sempre é necessário — e é contraproducente — formar um artefato que será usado apenas parcialmente, ou nem será usado, no trabalho subseqüente imediato. Isso acontece porque há uma grande probabilidade de mudança na situação em torno do artefato — e de os pressupostos feitos quando o artefato foi criado se provem incorretos — antes que o artefato seja usado, resultando em esforço perdido e retrabalho dispendioso. Evite também a armadilha de gastar muitos ciclos na apresentação em detrimento do valor do conteúdo. Nos ambientes de projeto em que a apresentação tem importância e valor econômico como um produto liberado do projeto, convém usar um recurso administrativo para executar as tarefas de apresentação.
|
Rational Unified Process
|
