1.    Estratégia de integração

1.1. Ambiente de integração

{Descrever o ambiente de integração dos diversos componentes do produto, caso pertinente. Caso o ambiente seja padrão, deve-se referenciar o documento que estabelece este ambiente. A definição do ambiente de integração do produto envolve o estabelecimento de todos os requisitos necessários para o ambiente de integração bem como os critérios necessários para verificar a prontidão deste ambiente.}

1.2. Componentes a serem integrados

{Identificar os itens do produto (itens de software, hardware, operações manuais e outros sistemas) que precisam ser integrados a partir da especificação técnica e da arquitetura do produto. A princípio os itens de software devem ser as unidades de código. Porém, dependendo do ambiente de desenvolvimento, da linguagem de programação do ciclo de vida selecionado para o projeto, pode ser que a integração entre as unidades já seja automática. Neste caso, deve-se identificar os itens (componentes) a serem integrados, por exemplo, os casos de uso ou os componentes arquiteturais, e cada item de software deve identificar as unidades de código relacionadas.}

1.3. Definir procedimentos para integração dos produtos

{Definir os procedimentos necessários para a integração dos diversos componentes do produto. Caso os procedimentos sejam padrão (no caso de integração via Git ou SVN, por exemplo), referenciar o documento que estabelece os procedimentos necessários para a integração do produto (neste caso a estratégia de versionamento). Critérios para verificação da integração (Testes de Integração) poderão fazer uso destes procedimentos para verificar a efetiva integração dos componentes.}

1.4. Identificar sequências alternativas de integração de itens do produto

{Identificar as possíveis sequências alternativas de integração dos itens do produto e as ferramentas específicas e equipamentos de teste, se necessário. Algo comum de se ocorrer em projetos iterativos é o desenvolvimento de módulos de sistema em diferentes iterações. Esses módulos deverão ser integrados sempre que estiverem estáveis, formando uma nova versão do produto. Neste caso, deve-se considerar o planejamento das iterações do projeto para as possíveis sequências de integração. Devem-se considerar também quaisquer sistemas ou subsistemas externos a serem integrados ao sistema existente.}

1.5. Escolher sequência de integração de itens do produto

{Selecionar a sequência de integração mais adequada, justificando a escolha.}

1.6. Procedimentos para geração do build

{Descrever os procedimentos para geração e disponibilização do produto.

• Compile – compila o código fonte do projeto
• Test – executa os testes unitários do código compilado, utilizando o Junit, por exemplo.
• Package – empacota o código compilado de acordo com o empacotamento escolhido, por exemplo, JAR ou WAR.
• Integration-test – processa e faz o deploy do pacote em um ambiente onde os testes de integração podem ser rodados.
• Install – instala o pacote no repositório local, para ser usado como dependência de outros projetos locais
• Deploy – feito em ambiente de integração ou de release copia o pacote final para um repositório remoto para ser compartilhado entre desenvolvedores e projetos}

2.   Estratégia de verificação & validação

2.1. Identificação dos produtos para serem verificados e/ou validados, métodos e critérios de verificação e/ou validação

{Identificar os produtos para serem verificados e/ou validados, bem como os métodos e critérios de verificação e validação.}

Produto	Método de Verificação	Método de Validação	Critérios de Verificação e/ou Validação
Estimativas de Tamanho, Prazo e Custo	Walkthrough	–	1 – A estimativa de tamanho (UST) do incremento (sprint) em questão está consistente com as necessidades identificadas no Formulário de Solicitação de Demanda. 2 – A estimativa de prazo em dias foi calculada a partir da estimativa de UST com base na taxa de entrega (UST/dia) adotada e no percentual de antecipação do prazo. 3 – A estimativa de custo em reais foi calculada a partir da quantidade e valor em reais do UST.
Especificação Funcional	Walkthrough	Walkthrough	1 – Os requisitos do cliente estão descritos são e rastreáveis com as necessidades identificadas no Formulário de Solicitação de Demanda de Software. 2 – Os requisitos do cliente descritos estão completos. 3 – Os requisitos do cliente contém informações não-ambíguas. 4 – Os requisitos do cliente contém informações corretas. 5 – Os requisitos do cliente estão consistentes entre si. 6 – Os requisitos funcionais e não-funcionais são rastreáveis com os requisitos do cliente. 7 – Os requisitos funcionais e não-funcionais são rastreáveis com casos de testes. 8 – Os requisitos funcionais e não-funcionais estão completos. 9 – Os requisitos funcionais e não-funcionais contém informações não-ambíguas. 10 – Os requisitos funcionais e não-funcionais contém informações corretas. 11 – Os requisitos funcionais e não-funcionais estão consistentes entre si.
Plano de Testes	Walkthrough	–	1 – Os casos de teste são rastreáveis com os requisitos funcionais e não-funcionais descritos na Especificação Funcional. 2 – Foram selecionados tipos de testes compatíveis com os requisitos funcionais e não-funcionais descritos na Especificação Funcional. 3 – Foram selecionados tipos de testes compatíveis com os requisitos funcionais e não-funcionais.
Especificação Técnica	Walkthrough	–	1 – Os elementos de análise e projeto da Especificação Técnica são rastreáveis com os requisitos identificados na Especificação Funcional. 2 – Os elementos de análise e projeto da Especificação Técnica são rastreáveis entre si.
Linha base de construção / sistema	Walkthrough	–	1 – A linha base de construção / sistema é integra, completa e consistente. 2 – A linha base de construção / sistema contém as unidades de código rastreáveis até os requisitos detalhados na Especificação Funcional.
Ambiente de Testes	Walkthrough	–	1 – O ambiente de teste foi criado de acordo com as informações previstas no Plano de Testes. 2 – Foi fornecida uma massa de testes adequada para a execução dos testes de sistema.
Relatório de Testes	Walkthrough	–	1 – O sumário de testes contém a análise da execução dos testes realizados. 2 – O relatório de testes apresenta os resultados da execução de todos os casos de testes associados aos requisitos funcionais e não-funcionais no incremento em questão. 3 – Todas as falhas e defeitos encontrados foram registrados e analisados.
Software	Testes	Testes	1 – Os testes foram executados de acordo com o planejamento de testes. 2 – O ambiente de testes era adequado para a execução dos casos de teste. 3 – A massa de teste disponibilizada era adequada para a execução dos casos de teste.

2.2 Ambiente de homologação

{Definir o ambiente de homologação em termos de recursos de hardware, software, permissões de acesso, entre outros, semelhante ao ambiente de produção.}

Nome do ambiente	{Nomear título do ambiente (por exemplo: “DES01”)}
Configurações de hardware	{Descrever as configurações de hardware}
Configurações de software	{Descrever as configurações de software}
Permissões de acesso	{Descrever as permissões de acesso como nome de usuário e senha.}
{Descrever o item}	{Descrever o item do ambiente de homologação}

2.3 Massa de testes

{Identificar a massa de testes para homologação do produto ou componentes do produto.}

Massa de teste 1	{Descrever a massa de teste}
Massa de teste 2	{Descrever a massa de teste}
Massa de teste 3	{Descrever a massa de teste}
Massa de teste 4	{Descrever a massa de teste}
{Identificar a massa de teste}	{Descrever a massa de teste}