Execução - Abordagem Tradicional¶
Construção¶
Objetivo
Esta fase pode ser iterativa, e deve ser definida no plano de projeto. São realizadas modelagem, codificação, testes e integração do produto. Pode haver entrega parcial nesta fase.
Elaborar / Atualizar documento de canal¶
Executor Primário:
- Analista de Negócios / requisitos;
- Líder de Projeto.
Obrigatório:
- Documento de Arquitetura;
- Estimativas do Projeto;
- Plano de Projeto;
- Proposta Técnica.
1. Analisar Proposta Técnica e Documento de Arquitetura
Antes de iniciar o refinamento dos canais do portal, o Analista de Negócios / requisitos deve analisar a Proposta Técnica e o Documento de Arquitetura. Dúvidas e esclarecimentos devem ser feitos com o Gerente do Projeto e Líder Técnico.
Ao analisar a Proposta Técnica o Analista de Negócios / requisitos deve identificar os requisitos funcionais e requisitos não funcionais planejados para a iteração que serão a referência para a elaboração dos Documentos de Canal.
2. Especificar o Documento de Canal
O Analista de Negócios / requisitos deve especificar os Documentos de Canal da iteração a partir do escopo definido na Proposta Técnica utilizando o respectivo template.
3. Revisar o Documento de Canal
Conforme os requisitos definidos nas Diretrizes de Verificação, as revisões deverão ser executadas pelo Analista de Negócios / requisitos par ou Líder Técnico, quando houver dois Analista de Negócios / requisitos no projeto. Quando não houver Analista de Negócios / requisitos par, somente o Líder Técnico deverá revisar.
Revisar os Documentos de Canal utilizando o “Checklist de Verificação de Documento de Canal”.
Utilizar um checklist para cada documento de Canal. Terminada a revisão, armazenar os checklists junto com os documentos revisados no repositório do projeto e notificar o Analista de Negócios / requisitos.
4. Ajustar o Documento de Canal
O Analista de Negócios / requisitos deve analisar e tratar todas as considerações realizadas na revisão e registradas no checklist. Quando aplicável deve ajustar os Documentos de Canal em consenso com o Líder Técnico.
Se necessário, quando indicado durante a etapa de revisão, o Documento de Canal deve ser encaminhado novamente para revisão (etapa 4 desta atividade).
- Checklist de Verificação de Documento de Canal;
- Documento de Canais.
Elaborar / Atualizar Casos de Uso¶
Executor Primário:
- Analista de Negócios / requisitos;
- Líder Técnico.
Obrigatório:
- Estimativas do Projeto;
- Plano de Projeto.
Opcional:
- Documento de arquitetura.
1. Analisar Proposta Técnica e Documento de Arquitetura
Antes de iniciar o refinamento dos requisitos do sistema, o Analista de Negócios / requisitos deve analisar a Proposta Técnica e o Documento de Arquitetura. Dúvidas e esclarecimentos devem ser feitos com o Gerente do Projeto e Líder Técnico.
Ao analisar a Proposta Técnica o Analista de Negócios / requisitos deve identificar os requisitos funcionais e requisitos não funcionais planejados para a iteração que serão a referência para a elaboração dos Casos de Uso.
2. Especificar Casos de Uso
O Analista de Negócios / requisitos deve especificar os Casos de Uso da iteração a partir do escopo definido na Proposta Técnica utilizando o respectivo template.
Cada Caso de Uso deve ter como conteúdo mínimo:
- Descrição;
- Atores, Pré-condições e pós-condições;
- Fluxo Básico;
- Fluxos Alternativos;
- Requisitos Especiais, Pontos de relacionamento e interface por protótipos, quando aplicável;
Se necessário, o Analista de Negócios / requisitos deve elaborar também Regras de Negócio para especificar particularidades e regras comuns dos Casos de Uso.
Também quando for aplicável, devem ser elaborados Protótipos para ilustrar os Casos de Uso e facilitar a comunicação com o cliente.
Todos os casos de uso elaborados devem ser relacionados com os requisitos do projeto pela ferramenta (ver atividade Elaborar/atualizar rastreabilidade de requisitos).
Quando a ferramenta Borland Caliber RM não for utilizada para registro dos Casos de Uso, como alternativa poder ser utilizado o template de Caso de Uso. Neste caso a opção pelo uso alternativo deve ser especificada no Plano de Projeto.
Os Casos de Uso, Regras de Negócio, Mensagens do sistema, Especificação suplementar e Protótipos devem ser armazenados no repositório do projeto conforme estrutura definida.
O Analista de Negócios / requisitos também pode elaborar o documento de Requisitos Funcionais com o objetivo de fornecer uma visão geral de todos os Requisitos Funcionais e o documento com a Descrição Geral de Casos de Uso com a descrição, de forma resumida, dos casos de uso que permeiam o sistema. Esses dois documentos são opcionais e quando criados devem utilizar os templates correspondentes e serem armazenados conforme estrutura definida.
3. Revisar Casos de Uso
Conforme os requisitos definidos nas Diretrizes de Verificação, as revisões deverão ser executadas pelo Analista de Negócios / requisitos par ou Líder Técnico, quando houver dois Analista de Negócios / requisitos no projeto. Quando não houver Analista de Negócios / requisitos par somente o Líder Técnico deverá revisar.
Revisar os Casos de Uso, seguindo o documento “Diretrizes de Verificação” e utilizar o “Checklist de Verificação de Casos de Uso”.
Utilizar um checklist para cada documento de Caso de Uso. Terminada a revisão, armazenar o checklist junto com o documento revisado no repositório do projeto e notificar o Analista de Negócios / requisitos.
** 4.Ajustar Casos de Uso**
O Analista de Negócios / requisitos deve analisar e tratar todas as considerações realizadas na revisão e registradas no checklist. Quando aplicável deve ajustar os Casos de Uso em consenso com o Líder Técnico.
Se necessário, quando indicado durante a etapa de revisão, o Caso de Uso deve ser encaminhado novamente para revisão (etapa 4 desta atividade).
- Caso de Uso;
- Checklist de Verificação de Casos de Uso;
- Descrição Geral de Casos de Uso;
- Especificação Suplementar;
- Mensagens do Sistema;
- Regras de Negócio Gerais;
- Requisitos Funcionais de Sistema.
Elaborar / Atualizar Documentação Técnica¶
Executor Primário:
- Líder Técnico.
Executores Adicionais:
- Analista de Negócios / requisitos;
- Desenvolvedor.
Obrigatório:
- Caso de Uso;
- Documento de Arquitetura;
- Plano de Composição.
1. Analisar Casos de Uso
Após aprovação dos Casos de Usos, estes devem ser analisados pelo Líder Técnico para a distribuição das atividades de construção da iteração para a equipe.
Durante a análise o Líder Técnico deve utilizar as definições do Documento de Arquitetura e planejar as necessidades de documentação técnica adicional e testes de unidades além de definir a estratégia de composição, ou montagem, do produto.
2. Planejar Especificação, Codificação e Testes dos Casos de Uso
O Desenvolvedor deve registrar as estratégias de construção do produto para cada Caso de Uso no documento Plano de Implementação utilizando seu respectivo template.
Periodicidade: Elaborar um PLI por caso de Uso.
O Plano de Implementação deve conter no mínimo:
- Especificação de componentes e pacotes de desenvolvimento;
- Revisão de Código.
Os Planos de Implementação devem ser armazenados no repositório do projeto conforme estrutura definida.
3. Elaborar Pacote de Especificações Técnicas
O Líder técnico deve elaborar o Diagrama de Classes e as documentações técnicas adicionais do pacote de especificações técnicas (definidas no Plano de Composição) para cada Caso de Uso.
O conteúdo do pacote de especificações pode variar para cada Caso de Uso e pode conter, não se limitando a estes:
- Modelo de dados;
- Diagrama de sequência;
- Diagrama de estados;
- Protótipo.
Todos os artefatos elaborados ou atualizados devem ser relacionados aos Casos de Uso do projeto através da ferramenta de rastreabilidade (ver atividade Elaborar/atualizar rastreabilidade de requisitos).
As especificações devem seguir as definições do Documento de Arquitetura e do Plano de Implementação, e armazenadas no repositório do projeto conforme estrutura definida.
4. Distribuir Tarefas
O Líder Técnico deve distribuir os Planos de Implementação para cada Desenvolvedor responsável. Os respectivos Casos de Uso e Diagramas de Classes devem ser disponibilizados, assim como a documentação técnica do pacote de especificação técnica, quando aplicável.
- Plano de Implementação.
Elaborar / Atualizar Rastreabilidade de Requisitos¶
Executor Primário:
- Analista de Negócios / requisitos.
Obrigatório:
- Proposta técnica.
1. Registrar a rastreabilidade dos produtos de trabalho
O Analista de Negócios / requisitos deve registrar a rastreabilidade dos produtos de trabalho indicando o relacionamento entre eles conforme o esquema abaixo:
| Requisitos | Casos de Uso | Classes | Código-fonte |
|---|---|---|---|
| Casos de Teste | |||
| Especificações Técnicas |
Da mesma forma os impactos entre os requisitos devem ser mapeados pelo Analista de Negócios / requisitos.
- O mapeamento deve permitir que qualquer produto de trabalho do projeto seja rastreado até seu requisito de origem;
- A partir de qualquer requisito identificar os produtos de trabalho relacionados.
Quando outros artefatos fizerem parte do pacote de Especificações Técnicas, estes também devem ser relacionados direta ou indiretamente aos requisitos através da rastreabilidade.
A rastreabilidade é realizada por meio do identificador dos artefatos elaborados no projeto.
Em caso de mudanças nos documentos e artefatos relacionados na rastreabilidade, o Analista de Negócios / requisitos deve revisar e ajustar os relacionamentos entre os mesmos na ferramenta.
- .
Codificar e Testar Unidades¶
Executor Primário:
- Desenvolvedor.
Executores Adicionais:
- Líder Técnico.
Obrigatório:
- Caso de Uso;
- Documento de Arquitetura;
- Plano de Implementação.
1. Analisar Documentação
O Desenvolvedor deve ler e analisar toda documentação recebida para iniciar a construção dos componentes. Eventuais dúvidas devem ser tratadas com o Líder Técnico. No mínimo, o Desenvolvedor deve receber para cada Caso de Uso:
- Diagrama de Classes;
- Caso de Uso;
- Plano de Implementação;
- Documento de Arquitetura.
2. Codificar Componentes
Após o completo entendimento, o Desenvolvedor deve escrever o código-fonte dos Casos de Uso sob sua responsabilidade, respeitando o Diagrama de Classes e as especificações técnicas.
Necessidades de codificação que não foram previstas nas especificações, como por exemplo, novas classes ou restrições do framework, devem ser encaminhadas para o Líder Técnico analisar e tomar as providências.
3. Testar os Componentes
O Desenvolvedor deve codificar os scripts de teste de unidade ou elaborar os casos de testes de acordo com a definição do Plano de Implementação. Preferencialmente deve-se usar aplicativos específicos para testes de unidade (JUnit, NUnit, etc.), quando não for aplicável à linguagem utilizada, o programador deve escrever um programa dedicado para executar o script de teste.
A massa de testes a ser usada na execução deve ser definida e preparada nesta etapa.
Scritps, programas e massa de testes devem ser armazenados no repositório do projeto acompanhando o código-fonte, conforme estrutura de diretórios definida.
O Desenvolvedor deve realizar os testes de unidade executando os scripts gerados. Durante a execução dos testes, o Desenvolvedor pode acrescentar novas condições de teste, se avaliar necessário.
O Desenvolvedor deve ajustar e corrigir o código-fonte até que os testes sejam concluídos com sucesso.
Os registros da execução com sucesso destes testes devem ser armazenados no repositório do projeto acompanhando o código-fonte, conforme estrutura de diretórios definida.
4. Revisar Código-fonte
O código-fonte gerado ou modificado deve ser verificado pelo Líder Técnico ou Desenvolvedor (diferente do autor) conforme definido no Plano de Implementação.
O Desenvolvedor deve tratar todas as ocorrências apontadas na verificação e refazer a verificação caso seja decidido pelo responsável pela verificação..
Líder Técnico ou Desenvolvedor (diferente do autor) deve revisar o código fonte seguindo o documento Diretrizes de Verificação e deve utilizar o template do Checklist de verificação de Código Fonte.
5. Liberar Código para Integração
Após revisão e testes o código-fonte pode ser liberado para composição. O código-fonte deve ser armazenado no repositório do projeto respeitando a estrutura de diretórios definida.
O Desenvolvedor deve notificar o Líder Técnico sobre a conclusão da codificação.
- Checklist de verificação de Código Fonte;
- Código Fonte;
- Testes de Unidade.
Elaborar / Atualizar Casos de Testes de Sistemas¶
Executor Primário:
- Analista de Testes.
Executores Adicionais:
- Líder Técnico.
Obrigatório:
- Caso de Uso;
- Documento de Arquitetura;
- Plano de Implementação.
1. Elaborar Casos de Testes
O Analista de Testes deve elaborar as especificações de Casos de Testes, para cada tipo de teste planejado no escopo do projeto, utilizando a ferramenta definida no Plano de Projeto.
A base de referência para a especificação dos casos de testes são os documentos de Casos de Uso e o pacote de Especificação Técnica, quando aplicável.
Os casos de testes devem possuir a ação a ser executada e o resultado esperado e devem ser agrupados por requisitos de sistema ou funcionalidades em um documento de especificação para cada Caso de Uso*.
Todos os Casos de Testes devem ser relacionados a pelo menos um Caso de Uso para mapeamento da rastreabilidade dos requisitos e devem ser usadas técnicas de caixa preta para o projeto dos testes.
(*) A forma de registro dos Casos de Teste está definida no Plano de Projeto.
2. Revisar Casos de Testes com Outro Analista de Testes (Líder Técnico alternativo)
O Analista de Testes deve enviar os Casos de Testes para revisão. O revisor pode ser outro Analista de Testes, Analista de Negócios / requisitos ou o Líder Técnico, conforme definido no Plano do Projeto.
O responsável deve revisar os Casos de Testes seguindo o documento Diretrizes de Verificação e utilizar o Checklist de Verificação de Casos de Teste. Deve ser utilizado um Checklist para cada documento de Caso de Teste. Terminada a revisão o responsável deve armazenar o Checklist junto com o documento revisado no repositório do projeto e notificar o Analista de Testes.
**3. Ajustar Casos de Testes
O Analista de Testes deve analisar e tratar todas as considerações realizadas na revisão e registradas no checklist. Quando aplicável deve ajustar os Casos de Testes em consenso com o responsável pela revisão.
Se necessário, quando indicado durante a etapa de revisão, o Caso de Teste deve ser encaminhado novamente para revisão (etapa 2 desta atividade).
- Casos de Testes;
- Checklist de Verificação de Casos de Teste.
Integrar e Testar Componentes Integrados¶
Executor Primário:
- Líder Técnico.
Executores Adicionais:
- Desenvolvedor.
Obrigatório:
- Plano de Composição.
1. Preparar Ambiente para Build Integrado
Antes de iniciar a composição, o Líder Técnico deve preparar o ambiente de composição com as ferramentas, bibliotecas, atualizações planejadas e necessárias conforme definido no Plano de Composição.
O líder Técnico deve checar se todos os componentes ou Casos de Uso necessários para iniciar a composição já foram concluídos pelos Analistas de Sistemas.
2. Montar o Build com os Componentes Codificados
O Líder Técnico deve realizar a composição das unidades:
- Outras unidades construídas anteriormente;
- Unidades desenvolvidas por outras equipes;
- Estrutura básica do sistema em desenvolvimento;
- Módulos externos (simuladores, emuladores, etc).
A composição das unidades deve seguir a estratégia adotada Plano de Composição, respeitando a sequência de composição das partes do projeto.
3. Testar Composição
O Líder Técnico deve codificar os scripts de teste ou elaborar os casos de testes de acordo com a definição do Plano de Composição.
Deve-se reaproveitar ao máximo os scripts de testes de unidade utilizados anteriormente. Preferencialmente deve-se usar aplicativos específicos para testes de unidade (JUnit, NUnit, etc.), quando não for aplicável à linguagem utilizada, o Líder Técnico deve escrever um programa dedicado para executar o script de teste.
A massa de testes a ser usada na execução deve ser definida e preparada nesta etapa.
Scripts, programas e massa de testes devem ser armazenados no repositório do projeto acompanhando o código-fonte, conforme estrutura de diretórios definida.
O Líder Técnico deve realizar os testes de composição executando os scripts gerados. Durante a execução dos testes, o Líder Técnico pode acrescentar novas condições de teste se avaliar necessário. Eventualmente alguns testes de composição podem ser realizados durante os Testes de Sistema, neste caso, o Líder Técnico deve informar o Analista de Negócios / requisitos para que sejam incluídos nos Casos de Testes de sistema.
O Desenvolvedor deve ajustar e corrigir o código-fonte dos componentes até que os testes sejam concluídos com sucesso.
Os registros da execução com sucesso destes testes devem ser armazenados no repositório do projeto acompanhando o código-fonte, conforme estrutura de diretórios definida.
- Build de Integração.
Executar Testes de Sistemas¶
Executor Primário:
- Analista de Testes;
- Líder Técnico.
Executores Adicionais:
- Gerente do Projeto.
Obrigatório:
- Build de Integração;
- Casos de Testes.
1. Executar Testes de Sistemas
O Analista de Testes deve iniciar um ciclo de teste na ferramenta Borland Silk Test e executar o produto conforme cada caso de teste especificado e completar com as informações do resultado obtido nos testes.
O caso de teste é considerado satisfatório quando o resultado obtido é igual ao resultado esperado. E insatisfatório quando o resultado obtido é diferente do resultado esperado.
Dúvidas na execução dos testes e problemas com o ambiente devem ser comunicadas ao Líder Técnico.
Quando a ferramentaBorland Silk Test não for utilizada para registro dos Casos de Teste, como alternativa à execução dos testes deve-se utilizar o template de Caso de Teste. Neste caso a opção pelo uso alternativo deve ser especificada no Plano de Projeto.
Para o uso do template de Caso de Teste devem ser registrados:
- Resultado obtido nos testes;
- Realizado por: (nome do executor do teste);
- Data da realização do teste;
- Status.
Em caso de reteste, se o defeito identificado anteriormente foi corrigido, deve-se preencher também:
- Corrigido por: (nome do Analista Desenvolvedor);
- Data da correção;
- Retestado por: (nome do executor do reteste).
2. Registar Defeitos Identificados
Todos os defeitos identificados no teste de sistema devem ser registrados na ferramenta de gestão de defeitos (Mantis ou Trac, por exemplo). Cópias de telas, arquivos e outras evidências podem ser anexadas para auxiliar no entendimento.
Os defeitos devem ser atribuídos ao Líder Técnico que deve analisar cada um deles e encaminhar para o tratamento atribuindo-os para os respectivos Analistas de Sistemas.
Quando a ferramenta Borland Silk Test não for utilizada para registro dos Casos de Teste, como alternativa o registro dos defeitos deve-se utilizar uma ferramenta de gestão de defeitos (Mantis ou Trac, por exemplo). Neste caso a opção pelo uso alternativo, bem como a definição da ferramenta utilizada, deve ser especificada no Plano de Projeto.
3. Analisar Liberação do Produto
Após a realização do ciclo de testes, o Líder Técnico deve analisar os Casos de Teste e os defeitos registrados na ferramenta. O Analista de Testes deve ser consultado para esclarecer dúvidas sobre os defeitos.
O Líder Técnico deve verificar se o resultado dos testes está dentro do critério de liberação do produto no Plano de Projeto para aprovar sua entrega. Caso o produto esteja abaixo dos critérios estabelecidos, deve-se encaminhar à atividade Tratar Defeitos.
Mesmo que o produto atenda os critérios de liberação, mas ainda assim possua defeitos registrados, o Gerente de Projeto deve conduzir o tratamento destes defeitos conforme atividade Tratar Defeitos.
- Casos de Testes;
- Registros de Defeitos.
Tratar Defeitos¶
Executor Primário:
- Desenvolvedor;
- Líder Técnico.
Executores Adicionais:
- Analista de Testes.
Obrigatório:
- Casos de Testes;
- Registros de Defeitos.
1. Analisar Defeitos Relatados
Caso o código-fonte possua problemas que geraram os defeitos relatados durante os Testes de Sistema, o Desenvolvedor deve avaliar os pontos que necessitam de manutenção, propor soluções e implementar os ajustes necessários. Os testes de unidade devem ser refeitos para as unidades modificadas.
O Desenvolvedor deve verificar, através da rastreabilidade para os requisitos do código-fonte, se a modificação realizada afeta outras unidades ou módulos do projeto e avisar o Analista de Negócios / requisitos para providenciar os ajustes.
Dúvidas sobre o defeito registrado devem ser tratadas com o Analista de Testes.
2. Registar Respostas aos Defeitos
O Desenvolvedor deve editar o registro do defeito na ferramenta Borland Silk Test e responder informando o tratamento realizado para o mesmo.
Após todos os defeitos serem respondidos, o Líder Técnico deve notificar o Analista de Testes para que realize novamente o teste da iteração.
Quando a ferramenta Borland Silk Test não for utilizada para registro dos Casos de Teste, como alternativa o registro do tratamento dos defeitos deve-se utilizar uma ferramenta de gestão de defeitos (Mantis ou Trac, por exemplo). Neste caso a opção pelo uso alternativo, bem como a definição da ferramenta utilizada, deve ser especificada no Plano de Projeto.
3. Registrar Resultados Consolidados
Registrar resultados consolidados na ferramenta Git.
- Registros de Defeitos.
Entrega¶
Objetivo
Elaborar / atualizar manuais, com todos os passos necessários para o entendimento do cliente, verificar e corrigir erros, e entregar o produto para o cliente.
Elaborar / Atualizar Manuais¶
Executor Primário:
- Analista de Negócios / requisitos.
Obrigatório:
- Caso de Uso;
- Documento de Arquitetura;
- Manual de Instalação;
- Proposta Técnica.
1. Elaborar Manual de Instalação e Configuração
O Analista de Negócios / requisitos deve elaborar o Manual de Instalação e Configuração do produto para entrega ao cliente. Este manual deve conter no mínimo os passos necessários para que o cliente consiga instalar e configurar o sistema.
Para elaboração deste manual o Analista de Negócios / requisitos deve utilizar como referência o Documento de Arquitetura e os Casos de Uso.
O Manual de Instalação e configuração deve ser armazenado no repositório do projeto conforme estrutura de diretórios definida.
Este manual pode ser feito apenas uma vez durante o ciclo de vida do projeto.
2. Elaborar Manuais Suplementares
Quando estabelecido na Proposta Técnica, o Analista de Negócios / requisitos também deve elaborar manuais e documentações adicionais para o cliente. Documentações e manuais suplementares podem ser, não se limitando a estes:
- Manual do usuário;
- Procedimentos de backup e restore;
- Procedimentos de monitoração;
- Diagramas ou fluxogramas de operação do sistema.
A documentação suplementar deve ser armazenada no repositório do projeto de acordo com a estrutura de diretórios definida.
3. Entregar Documentação ao Cliente
O Analista de Negócios / requisitos deve realizar a entrega da documentação do sistema para o cliente. Faz parte da documentação a ser entregue:
- Casos de Uso da iteração;
- Manual de Instalação e configuração;
- Documentações suplementares, quando previsto na Proposta Técnica.
- Manual de Instalação.
Entregar Produto¶
Executor Primário:
- Arquiteto;
- Gerente do Projeto;
- Líder Técnico.
Executores Adicionais:
- Analista de Negócios / requisitos.
Obrigatório:
- Caso de Uso;
- Código Fonte;
- Documentações Suplementares;
- Manual de Instalação.
1. Gerar Baseline
O Líder Técnico ou Arquiteto deve gerar a baseline, conforme itens de configuração descritos nas Diretrizes de Gestão de Configuração de Projetos.
2. Auditar Baseline
Outro Líder Técnico ou Arquiteto (o auditor deve ser diferente do autor baseline) deve auditar todas as baselines utilizando como base o Checklist de Auditoria de Baseline do Projeto. Deve ser utilizado um checklist para cada baseline. No caso de NC, registrar o problema no checklist e na lista de problemas do projeto. A ação de correção será realizada conforme determinado na ação de correção do problema. Uma nova baseline deve ser gerada, e uma nova auditoria realizada para verificar a correção.
3. Gerar Pacote de Entrega
O Líder Técnico deve gerar o pacote de entrega para o cliente. O build de entrega deve ser criado e os códigos-fonte devem ser separados, dependendo do contrato junto ao cliente.
Enviar os Casos de Uso relacionadas à entrega para a Equipe de Métricas realizar a contagem APF detalhada.
O Analista de Negócios / requisitos deve preparar a entrega da documentação do sistema para o cliente, contendo:
- Casos de Uso da iteração;
- Manual de Instalação e configuração;
- Documentações suplementares, quando previsto no Plano de Projeto.
Enviar no pacote informações sobre possíveis impactos da entrega no funcionamento do sistema.
4. Verificar Pacote de Entrega
O Arquiteto deve verificar o pacote de entrega gerado utilizando o Checklist de Verificação Pacote de Entrega.
5. Realizar a Entrega do Pacote para o Cliente
O Gerente do Projeto deve enviar o Pacote de Entrega para o cliente.
- Build de Entrega;
- Checklist de Auditoria de Baseline do Projeto;
- Checklist de Verificação Pacote de Entrega.
Analisar Reprovação¶
Executor Primário:
- Analista de Negócios / requisitos.
Obrigatório:
- E-mail.
1. Analisar Reprovação
O Analista de Negócios / requisitos deve analisar, verificar e confirmar a reprovação reportada pelo cliente.
2. Registrar Defeitos Identificados
Todos os defeitos identificados no teste de aceite por parte do cliente devem ser registrados na ferramenta de gestão de defeitos (Mantis ou Trac, por exemplo) pelo Analista de Negócios / requisitos. Cópias de telas, arquivos e outras evidências podem ser anexadas para auxiliar no entendimento.
Os defeitos devem ser atribuídos ao Líder Técnico que deve analisar cada um deles e encaminhar para o tratamento atribuindo-os para os respectivos Analistas de Sistemas.
Quando a ferramenta Borland Silk Test não for utilizada para registro dos Casos de Teste, como alternativa o registro dos defeitos deve-se utilizar uma ferramenta de gestão de defeitos (Mantis ou Trac, por exemplo). Neste caso a opção pelo uso alternativo, bem como a definição da ferramenta utilizada
- Análise de Reprovação.