Processo de Desenvolvimento

1) INTRODUÇÃO
      A Fábrica III possui uma metodologia de desenvolvimento de software (processo de transformação do projeto do software no produto final) dividida em 4 fases: comercial, planejamento e gerenciamento, desenvolvimento de componentes e testes e validação.
      O fluxo de atividades executadas no "ambiente fabril" são divididas nas fases dessa metodologia e serão detalhadas neste documento, assim como os artefatos de cada fase.

1.1 Visão geral deste documento
      As demais seções apresentam os itens referentes a este documento e estão organizadas como descrito abaixo.
Seção 2 - Comercial: é a fase da definição do projeto, de acordo com as necessidades levantadas junto ao cliente;
Seção 3 - Planejamento e Gerenciamento: é a fase da elaboração do plano do projeto (plano de trabalho, riscos, acompanhamento e controle, etc) e execução das atividades recorrentes de acompanhamento e controle;
Seção 4 - Desenvolvimento de Componentes: é a fase da definição de problemas e da especificação, projeto e implementação dos componentes;
Seção 5 - Testes e Validação: é a fase dos testes e da validação dos componentes produzidos.

2) COMERCIAL

2.1 Introdução
      Para que um projeto se inicie dentro da Fábrica de Software III, ele precisa ser vendido a um cliente. No processo normal, o cliente procura a Fábrica com uma necessidade e essa necessidade é detalhada em requisitos funcionais e não-funcionais, além de serviços associados. O cliente pode já trazer a especificação da necessidade documentada, ou ela pode ser definida apenas com entrevistas entre o Gerente de Negócios e o cliente. O custo e esforço são estimados e apresentados ao cliente, que decide se contrata ou não o projeto. Independente da decisão, a fase é terminada nesse momento.

2.2 Responsáveis e Artefatos
      Os responsáveis e artefatos envolvidos neste fluxo são mostrados a seguir:

      A Proposta Técnica lista e detalha os requisitos funcionais e não-funcionais, definindo o escopo positivo e negativo do projeto. Lista também os usuários, clientes e outros sistemas, que representam os atores do sistema.
      A Planilha de Estimativa de Esforço calcula o esforço em homem/hora para a execução do projeto. É necessário se categorizar os atores e casos de uso, pois a métrica de Pontos de Caso de Uso associa valores diferentes a categorias diferentes. Os requisitos não-funcionais também são relevantes no cálculo do esforço, pois eles definem o coeficiente técnico do sistema, que ajusta os pontos de caso de uso.
      A Proposta Comercial une as informações de escopo e esforço, associando custo total e prazo de entrega. É importante ressaltar que a informação de escopo que vem na proposta comercial é apenas um resumo da informação constante na proposta técnica.

2.3 Fluxo de Atividades
      O fluxo de atividades da fase comercial é composto das seguintes atividades e respectivos responsáveis:
      1) Levantar Necessidades do Cliente - Gerente de Negócios/Cliente.
      2) Elaborar Proposta Técnica - Líderes de Equipe
      3) Estimar Esforço do Projeto - Gerente de Negócios
      4) Elaborar Proposta Comercial - Gerente de Negócios

      2.3.1 Levantar Necessidades do Cliente

      Caso o cliente apresente documentação que forneça as informações necessárias a esta atividade, esta documentação deve ser analisada antes da reunião com o cliente, ficando a reunião apenas para dirimir dúvidas.
      Identificar Usuários e Clientes do Sistema
      Nesse passo, são identificados os usuários e clientes do sistema, que representarão os atores no diagrama de caso de uso. É importante especificar quais são as responsabilidades e papéis dos clientes e usuários para que o documento também sirva como entrada para o entendimento do sistema.
      Identificar Requisitos Funcionais e Não-Funcionais
Nesse passo, serão identificados os casos de uso, com a lista de passos do fluxo de eventos principal. Os casos de uso serão necessários para a estimativa de esforço na atividade subseqüente.

      2.3.2 Elaborar Proposta Técnica

      Elaborar Proposta Técnica
      Esse passo consiste basicamente da escrita da proposta técnica a partir das informações coletadas junto ao cliente nas reuniões de levantamento dos requisitos.

      2.3.3 Estimar Esforço do Projeto

      Estimar Esforço do Projeto
      A métrica de estimativa de esforço usada pela Fábrica de Software III é Pontos de Caso de Uso. Essa atividade consiste basicamente do uso da métrica e da documentação dos parâmetros e valores usados, para que seja possível se fazer análises futuras e gerar dados históricos das estimativas, que é muito relevante para retro-alimentação do processo.

      2.3.4 Elaborar Proposta Comercial

      Elaborar Proposta Comercial
      Esse passo consiste basicamente da escrita da proposta comercial a partir das informações que estão presentes na proposta técnica e na planilha de estimativa de esforço. É importante ressaltar que apenas na proposta comercial aparece o prazo de entrega do projeto, pois esse é conseguido a partir do esforço calculado em homem/hora.
      A fase seguinte descreve o processo de planejamento e gerenciamento de uma fabrica de software.

3 PLANEJAMENTO E GERENCIAMENTO

3.1 Introdução
      O processo de administração de projetos de software inicia-se com um conjunto de atividades que são coletivamente denominadas planejamento de projetos. Os objetivos principais consistem em unificar o entendimento do produto a ser desenvolvido e fornecer uma estrutura que possibilite fazer estimativas razoáveis de recursos, custos e prazos; assim, ao utilizar-se de dados mais realísticos, aumenta-se as chances de sucesso.
      O gerenciamento da evolução do projeto é outro passo importante, uma boa forma de acompanhamento é através de controle; logo, deverão ser desenvolvidos mecanismos para avaliar do progresso, organizar o pessoal que desenvolverá o produto, rastrear e controlar o projeto.
      As próximas seções descrevem os responsáveis envolvidos nesta fase, como também os artefatos associados a cada um.

3.2 Responsáveis e Artefatos
      Os responsáveis e os artefatos envolvidos neste fluxo são mostrados a seguir:

      O Plano de Projeto fornece uma linha básica de estruturação e delimitação do trabalho, devendo produzir ações como:
      i. Comunicar o escopo e os recursos a todos os envolvidos (engenheiros de software e de testes, analistas de sistemas e de qualidade, gerentes de projeto e gerentes comerciais, clientes e líderes de equipes);
      ii. Definir riscos e sugerir técnicas para evitá-los, ou minimizá-los;
      iii. Definir cronograma com divisão de trabalho e dependência entre as atividades;
      iv. Fornecer abordagem global para o desenvolvimento de software;
      v. Planejar o acompanhamento das tarefas existentes;
      vi. Registrar o monitoramento através de relatórios, a fim de checar o planejado com o realizado efetivamente.
      É importante salientar que o plano de projeto não é um documento estático, é um registro estratégico, podendo ser revisto repetidamente, atualizando riscos, estimativas, cronogramas e informações relacionadas, à medida que o projeto progride.
      A Ata de Reuniões consiste em um resumo sobre as decisões tomadas, especificando os membros presentes ao encontro, data e duração da mesma.
      O Formulário de Controle de Mudanças foi desenvolvido para administrar as mudanças em todo o ciclo de vida do software e pode ser visto como uma atividade de garantia de qualidade de software que é aplicada durante todas as fases do processo.
      O Formulário de Validação do Cliente é elaborado ao término do produto para avaliar se o que foi produzido estava em concordância com o que o cliente solicitou.
      O Relatório Avaliando Processo de Desenvolvimento é algo elaborado com os membros internos à fábrica, com o intuito de verificar pontos positivos e negativos no processo e extrair idéias de melhorias.

3.3 Fluxo de Atividades
      O fluxo de atividades da fase de Planejamento e Gerenciamento é composto das seguintes atividades e respectivos responsáveis:
      1) Elaborar Plano de Projetos Preliminar - Gerente de Projeto
      2) Definir o Controle do Projeto - Gerente de Projeto e equipe de trabalho
      3) Acompanhar e Gerenciar o Projeto - Gerente de Projeto e Analista de Qualidade
      4) Comunicar através de Reuniões Periódicas a Evolução do Projeto - Gerente de Projeto e Equipe de Trabalho
      5) Validar o Projeto - Analista de Qualidade, Gerente de projeto, Gerente de Negócios e Cliente

      3.3.1 Elaborar Plano de Projetos Preliminar

      Avaliar e definir os objetivos, o escopo, as premissas e as restrições
      Neste passo são definidos os objetivos, o escopo, as premissas e as restrições. Os objetivos apresentam de forma genérica o trabalho a ser realizado, apresentando as necessidades do cliente. O escopo define as funcionalidades requeridas. As premissas são os pressupostos e as restrições são as dificuldades e os limites para o projeto.
      Definir a estrutura organizacional da Fábrica III
      A identificação da Fábrica III junto ao cliente é interessante, pois ele passa a conhecer as pessoas e as funções necessárias para o desenvolvimento e o gerenciamento do projeto. Isso facilita a comunicação e o reconhecimento da Fábrica de Software.
      Definir a estrutura organizacional do Cliente
      A análise da visão preliminar de requisitos permite o reconhecimento do cliente, de suas necessidades e também da sua estrutura e organização. Assim, um organograma é construído com a estrutura bem definida do cliente.
      Definir preliminarmente o Plano de Projeto
      Com a definição dos objetivos, das premissas, das restrições, do escopo e das estruturas organizacionais, faz-se um documento que terá esses tópicos, a fim de ser incrementado ao longo do processo de gerenciamento e planejamento.

      3.3.2 Definir o Controle do Projeto

      Elaborar Work Breakdown Structure Cronológico
      Documento que descreve a divisão do trabalho em atividades e identifica os marcos de referência e os produtos a serem concluídos ao longo do processo. Também define as interdependências entre tarefas, esforço e prazo previsto, além dos responsáveis, permitindo a visualização e acompanhamento do caminho crítico do projeto de software dentro do tempo estipulado.
      A abordagem baseada em componentes propõe iterações que são preenchidas por um conjunto de tarefas que permitem a equipe definir e desenvolver, não devendo sobrecarregar os participantes da equipe de desenvolvimento.
      Definir Plano de Acompanhamento e Controle
      Define as atividades de acompanhamento e controle das frentes do projeto, incluindo os seus responsáveis, para que o projeto tenha reavaliações periódicas. Enfim, detalha a forma a ser utilizada para verificar o progresso (cronograma, escopo, custos, recursos), a periodicidade de execução das atividades e o que deve ser produzido ao final.
      Os documentos apresentados nas atividades de acompanhamento e controle devem ser anexados a este plano e consolidados como um documento único.
      Elaborar Plano de Gerenciamento de Impactos
      O gerenciamento de impactos consiste do processo de identificação, análise, acompanhamento e controle dos riscos e problemas do projeto. Seu objetivo é facilitar a resolução em tempo e a comunicação das partes envolvidas. Pela identificação dos riscos previsíveis, busca-se evitá-los e controlá-los; então, depois que a ameaça tiver sido diagnosticada, recursos adicionais podem ser concentrados na área do problema, o pessoal pode ser novamente disposto ou a programação do projeto, redefinida.
      O plano de gerenciamento de impactos deverá ser estruturado de forma que possa registrar ameaças identificadas, analisar os impactos considerando a materialização das mesmas, associar um valor para representar a magnitude do problema e definir plano de resposta com contingências para tratá-las.
      Elaborar Plano de Gerenciamento de Configuração
      O gerenciamento de configuração é a identificação, organização e controle de modificações no software e artefatos que estão sendo construídos. A responsabilidade primordial é controlar mudanças, mas também estão inclusas: a auditoria da configuração do software para garantir que ele foi adequadamente desenvolvido e a comunicação de todas as mudanças aplicadas na configuração.
      Antes que um item de configuração de software torne-se uma linha básica, mudanças podem ser feitas rápidas e informalmente. Porém, assim que uma linha básica é estabelecida, precisamos de um procedimento específico, formal, para avaliar e verificar cada mudança. Assim, um pedido de mudança é submetido e avaliado quanto ao mérito técnico, potenciais efeitos colaterais e o custo projetado da mudança. Os resultados da avaliação são registrados no Formulário de Controle de Mudanças, o qual será analisado pelas partes interessadas, que em seguida mencionará a decisão final sobre o status e a prioridade da mudança. Para garantir que a mudança foi adequadamente implementada deverá ser executada uma auditoria de configuração de software, que focaliza a exatidão técnica do objeto de configuração que foi modificado, avaliando a consistência com os demais itens sob configuração, omissões ou potenciais efeitos colaterais.
      Elaborar Plano de Comunicação
      Esta fase tem como objetivo: definir os responsáveis pela geração e distribuição de informações do projeto, definir os procedimentos de geração de informações do projeto e definir os procedimentos de distribuição de informações do projeto.

      3.3.3 Acompanhar e Gerenciar o projeto

      Avaliar Work Breakdown Structure Cronológico
      Averiguar se as atividades estabelecidas estão sendo cumpridas no prazo estimado; caso algum problema tenha afetado esta estrutura, deve-se discutir formas para relocação de atividades, tentando para minimizar os efeitos negativos produzidos.
      Avaliar Plano de Gerenciamento de Impactos
      Levantar possíveis ameaças ao projeto, atribuindo ao risco ou problema um responsável. Este responsável deverá monitorar os indicadores associados e reportar-se ao gerente do projeto quando houver a iminência de sua ocorrência. O gerente de projeto deverá comunicar os riscos e executar o plano de resposta quando este se materializar
      Avaliar Plano de Gerenciamento de Configuração
      Avaliar os pedidos de mudanças e armazenar os dados de cada solicitação no Formulário de Controle de Mudanças. Nos casos que a mudança é aceita pelas partes interessadas, fica estabelecido o compromisso de, tão logo que a solicitação seja incorporada, efetuar uma auditoria para garantir que a mesma foi adequadamente implementada.
      Registrar Dados no Plano de Avaliação e Controle
      Elaborar uma síntese da avaliação conduzida, dando um parecer quanto a evolução do projeto e demonstrando o grau de satisfatoriedade com o que foi observado. Unir este documento ao Plano de Avaliação e Controle e guardar como item histórico para análises futuras.

      3.3.4 Comunicar através de Reuniões Periódicas

      Avaliar o Plano de Trabalho e o Plano de Acompanhamento e Controle
      Reunir a equipe e checar o Work Breakdown Structure Cronológico e Acompanhamento e Controle; a fim de perceber o andamento das tarefas e a produtividade dos profissionais da Fábrica. Devem ser colhidas e geradas as informações de acompanhamento e controle do projeto tais como:
      - Progresso das frentes de trabalho
      - Problemas levantados
      - Riscos levantados
      - Requisições de mudança
      Definir e Registrar as dificuldades / possíveis soluções
      Aproveita-se também para gerenciar as questões (riscos e problemas), buscando minimizá-los. O gerente de projeto deverá comunicar os riscos, as mudanças e os problemas para a equipe discutir nas reuniões de acompanhamento.
      Registrar a Ata das Reuniões
      As decisões são registradas em atas para melhor acompanhamento e confirmação dos encaminhamentos definidos. Devem ser divulgadas através do TWIKI e da lista de discussão para conhecimento de todos.

      3.3.5 Validar o Projeto

      Reunir com o cliente para validação
      Avalia-se o sucesso do projeto, a eficácia do modelo de gestão e a qualidade dos produtos gerados. A freqüência deste encontro será apenas uma vez, para fechamento e conclusão dos trabalhos no Projeto.
      Avaliar Processo de Desenvolvimento Interno
Avalia-se a forma como o projeto foi conduzido e a necessidade dos artefatos, elucidando o grau de importância de cada atividade. Assim, análises podem ser efetuadas e se necessário, mudanças incorporadas. Sugestões são coletadas e avaliadas, apresentando possibilidades de incorporação nos projetos seguintes. Efetuado apenas no fechamento do projeto.

4) DESENVOLVIMENTO DE COMPONENTES

4.1 Introdução
      Mesmo com as recentes e constantes pesquisas na área de Desenvolvimento Baseado em Componentes (DBC), ainda existe uma carência de padrões, modelos de processos e metodologias que suportem, efetivamente, tanto o desenvolvimento "para o reuso" quanto o "desenvolvimento com reuso". Considerando o término da última década, com o acelerado crescimento da Internet, onde distribuição tem se tornado um requisito não funcional essencial de muitas aplicações, o problema torna-se ainda maior. Deste cenário, surgiu a necessidade de definição de uma Estratégia de Desenvolvimento de Software Baseado em Componentes Distribuídos (DBCD) que procura orientar o engenheiro de software em todo o processo de DBCD.
      Integrando o método Catalysis de DBC, os princípios de middleware, o framework de componentes (persistence) e o Distributed Adapters Pattern (DAP), na ferramenta MVCASE, definiu-se uma Estratégia de Desenvolvimento de Software Baseado em Componentes Distribuídos.
      A estratégia foi dividida em duas etapas, conforme mostra a Figura 1, utilizando a notação SADT. Numa primeira etapa, a estratégia parte dos requisitos do domínio do problema e produz os componentes implementados numa linguagem orientada a objetos. Uma vez implementados, o engenheiro de software desenvolve as aplicações reutilizando os componentes previamente construídos.

       A atividades da primeira etapa da estratégia (Development of Distributed Components) serão adotadas no processo de desenvolvimento de software, descrito neste documento. A fase correspondente será chamada, no processo, de Desenvolvimento de Componentes.
      As próximas seções descrevem os artefatos e responsáveis presentes nesta fase, bem como seu fluxo de atividades.

4.2 Responsáveis e Artefatos
       Os responsáveis envolvidos neste fluxo são mostrados a seguir:

4.3 Fluxo de Atividades
       O fluxo de atividades da fase "Desenvolvimento de Componentes" é composta pelas seguintes atividades e respectivos responsáveis:
       1) Definir Problema - Analista de sistemas
       2) Especificar Componentes - Analista de sistemas
       3) Projetar Componentes - Analista de sistemas
       4) Implementar Componentes - Engenheiro de software
       Nesta fase, os componentes de um domínio do problema são construídos nas quatro atividades descritas acima, de acordo com a Figura 2. Na última etapa, a implementação física dos componentes é concluída.

       Segue-se uma detalhada apresentação de cada atividade do fluxo:

       4.3.1 Definir Problema

       Identificar requisitos
       Inicialmente, são identificados os requisitos do domínio, usando técnicas como storyboards ou mind-maps, visando representar as diferentes situações e cenários do domínio do problema.
       Especificar Requisitos
       Em seguida, os requisitos identificados são especificados em Modelos de Colaborações, representando a coleção de ações e os objetos participantes. Finalmente, os modelos de colaborações são refinados em Modelos de Casos de Uso é gerado o Documento de Requisitos.
       A Figura 3 resume a primeira atividade da estratégia, onde um mind-map, definido na identificação dos requisitos do domínio de Ordem de Serviços, é especificado num Modelo de Colaborações, e, posteriormente, refinado e particionado em um Modelo de Casos de Uso, visando diminuir a complexidade e melhorar o entendimento do domínio do problema.

       Após definidos os Modelos de Casos de Uso, deve ser criado (ou atualizado) o Documento Requisitos do sistema. Este documento serve como um registro dos requisitos levantados e especificados durante esta atividade.
      
       4.3.2 Especificar Componentes

       Na ferramenta CASE, o engenheiro de software refina as especificações do nível anterior, visando obter as especificações dos componentes.

       Especificar modelos de tipos
       Esse passo tem início com o refinamento dos modelos do domínio do problema. Especifica-se o Modelo de Tipos, conforme mostra a Figura 5, mostrando atributos e operações dos tipos de objetos, sem se preocupar com a implementação.

       Projetar Frameworks de Modelos
       Uma vez identificados e especificados, os tipos são agrupados em Frameworks de Modelos. Framework de Modelos são projetados num alto nível de abstração, estabelecendo um esquema genérico que pode ser importado, no nível de projeto, com substituições e extensões de modo a gerar aplicações especificas. A Figura 6 mostra este modelo.

       Os tipos com nomes entre os símbolos <> são definidos como placeholders. Esses tipos podem ser substituídos em aplicações específicas.
       Criar modelo de Aplicação do Framework
       O framework do domínio de locadora de carros pode ser reutilizado em diversas aplicações do domínio. A Figura 7 mostra essa Aplicação do Framework. Nesta aplicação, os tipos com placeholders são substituídos pelos seus respectivos tipos.

       4.3.3 Projetar Componentes

       Criar modelo de classes
       Como passo inicial, os Modelos de Tipos são refinados em Modelos de Classes, onde as classes são modeladas com seus relacionamentos, levando em consideração a identificação dos componentes e suas interfaces. A Figura 10 mostra o Modelo de Classes do domínio de Ordem de Serviços. Os Modelos de Interações, representados pelos diagramas de seqüências, são refinados para mostrar detalhes do comportamento dos métodos em cada classe.

       Criar modelo de componentes
       A partir do Modelo de Classes, usa-se o Distributed Adapters Pattern (DAP) para realizar o projeto do Modelo de Componentes, onde a organização e a dependência entre os componentes são mostradas. A seção seguinte apresenta uma visão geral deste padrão.
:: Distributed Adapters Pattern ::
       O Distributted Adapters Pattern (DAP) é um padrão que está inserido no contexto de comunicação remota entre dois componentes. De maneira a resolver esta tarefa, componentes em um cenário distribuído comunicam-se com outros por meio de algum mecanismo inter-processo. Os componentes podem se comunicar entre si ou delegar esta função a outros componentes.
       A primeira alternativa requer menos componentes, isto conduz a aplicações, onde o núcleo da funcionalidade dos componentes é realizada através de tarefas de comunicação. Deste modo, as aplicações dependem de um particular mecanismo de comunicação e os componentes se tornam difíceis de serem reutilizados e estendidos.
       A segunda alternativa (DAP) permite-se obter aplicações modulares com um conjunto de componentes interoperáveis. Como o desenvolvimento da aplicação é mais fácil de manter e estender, estes componentes podem ser facilmente reutilizados em outras aplicações.
       O DAP oferece os seguintes benefícios:
       - Um componente pode acessar serviços remotos, oferecidos por outros componentes;
       - Os componentes são independentes de Application Programming Interfaces (API) de comunicação;
       - As modificações no código dos componentes, para oferecer suporte à comunicação, são minimizadas;
       - Mudanças no mecanismo de comunicação se tornam uma tarefa facilitada, minimizando o impacto no código do negócio.
       A técnica adotada pelo DAP, para oferecer todas estas funcionalidades mencionadas acima, é introduzir um par de objetos adaptadores, visando conseguir um melhor desacoplamento dos componentes dentro de uma arquitetura distribuída. Os adaptadores, basicamente, encapsulam a API, que é necessária para permitir o acesso distribuído ou remoto, para objetos Targets. Deste modo, objetos Sources de uma aplicação possuem autonomia em relação à camada de distribuição, e as mudanças nesta camada não causam impactos.
       No padrão, existem dois tipos de adaptadores: Source Adapter e Target Adapter. Em uma típica interação, um objeto que possua a interface do usuário em uma máquina solicita serviços de um Source Adapter localizado na mesma máquina. O Source Adapter, em seguida, solicita os serviços de um correspondente Target Adapter, residido em uma máquina remota. Finalmente, o Target Adapter solicita serviços de um objeto Facade, co-localizado com o Target Adapter. A Figura 11 mostra este exemplo.

       Aplicando o DAP
       Assim, para cada classe de negócio identificada (ex. customer, employee), cria-se uma estrutura de pacotes semelhante à Figura 12.

       A partir dessa estrutura de pacotes, cria-se o Modelo de Classes com a estrutura do DAP. A Figura 13 mostra esse processo para a classe Customer.

       Uma vez criado o Modelo de Classes, especifica-se os métodos disponibilizados pelas suas interfaces e algumas características intrínsecas de distribuição. Uma vez definido o Modelo de Classes, desenvolve-se o Modelo de Componentes

       4.3.4 Implementar Componentes

       Para que o componente possa ser distribuído, é gerado o código segundo o padrão CORBA. Para cada componente, têm-se os stubs e skeletons e as interfaces que disponibilizam seus serviços.
       Uma vez gerado o código dos componentes e das interfaces, realiza-se sua compilação numa outra ferramenta, como, por exemplo, o JBuilder.
       Feito isso, seguimos para a fase de teste e validação do software. A seção seguinte apresenta uma sugestão de um processo de teste e validação para uma fábrica de software.

5) TESTES E VALIDAÇÃO

5.1 Introdução
       Durante o processo de desenvolvimento de software, há uma grande possibilidade de ocorrência de falhas no produto e o custo associado à correção destas falhas é muito alto. Por este motivo, uma série de testes bem executados, iniciados no começo do ciclo de vida do software, reduz significativamente o custo com manutenção de software.
       Os testes representam a última oportunidade de detectar erros antes do software ser distribuído aos usuários, e podem ser feitos de forma manual e/ou automática. Os principais objetivos do Fluxo de Testes são:
       - verificar a correta integração entre todos os componentes do software;
       - verificar se todos os requisitos do sistema foram corretamente implementados;
       - planejar os testes que devem ser executados em cada iteração, incluindo testes de integração e sistema;
       - executar vários testes e comparar o resultado dos mesmos com os resultados esperados, a fim de produzir uma indicação da qualidade e da confiabilidade do software;
       - realizar os testes de aceitação (homologação).
       O processo de gerenciamento dos testes pode ser feito com a utilização de ferramentas adequadas para cada sistema. Estas devem ser definidas logo que surgir uma concepção mais clara sobre o tipo de software a ser produzido.
       As seções seguintes deste documento apresentam os artefatos gerados nesta fase juntamente com seus responsáveis, e detalha o fluxo de atividades da fase.

5.2 Responsáveis e artefatos
       Os responsáveis e artefatos envolvidos nesta fase são mostrados a seguir:

       Os artefatos descritos acima são assim descritos:
       - O Plano de Testes descreve as estratégias, os casos e os procedimentos de testes realizados em uma iteração e seu cronograma. Na estratégia de teste estão definidos os tipos de teste que serão executados na iteração e os objetivos que devem ser atingidos. Um caso de teste especifica uma maneira de testar o sistema: o que testar, que procedimentos de teste usar levando em consideração um aspecto de qualidade como, por exemplo, corretude, desempenho ou robustez. Um procedimento de teste especifica como realizar um ou diversos casos de teste. É um conjunto de instruções para execução e avaliação de resultados para um ou mais casos de teste, que podem ser efetivadas manualmente ou através de ferramentas.
       - O Relatório de Avaliação dos Testes é uma análise da cobertura dos casos de teste, bem como de métricas associadas aos testes, de modo a verificar a necessidade de realização de novos testes ou de testes de regressão na próxima iteração.
       - Um Componente de Teste automatiza um ou mais procedimentos de teste, ou partes deles, e pode ser desenvolvido usando-se uma linguagem de programação ou gerado através de uma interação com uma ferramenta de testes. Os componentes de teste podem ser programas, ou scripts e são usados para testar os componentes do modelo de implementação, fornecendo entradas, controlando e monitorando a execução e reportando os resultados.

5.3 Fluxo de atividades
       O fluxo de atividades da fase de testes e validação é composta das seguintes atividades e respectivos responsáveis:
       1) Elaborar Plano de Testes - Engenheiro de testes
       2) Implementar Testes - Engenheiro de software
       3) Executar Testes - Engenheiro de testes
       4) Avaliar Testes - Engenheiro de testes
       5) Executar Testes de Aceitação - Usuário/cliente validador
       Cada uma das fase é melhor descrita nas subseções seguintes:

       5.3.1 Elaborar Plano de Testes

       Definir requisitos a testar
       Neste passo, são definidos os requisitos (casos de uso e requisitos não-funcionais) que devem ser testados. Requisitos a testar são itens que têm seus comportamentos observados e medidos.
       Descrever casos de teste
       A identificação dos casos de testes é feita através da análise dos fluxos de eventos, e dos diferentes cenários dos casos de uso.
       A análise dos fluxos de eventos tem por objetivo descrever as ações do ator ao interagir com o sistema e utilizar estas ações para identificar os casos de testes necessários.
       Os casos de testes funcionais são identificados a partir dos diferentes cenários dos casos de uso (fluxos básicos e alternativos).
       O modelo de análise e projeto e os requisitos não-funcionais devem ser analisados para identificar casos de testes não-funcionais, que podem não ter sido encontrados apenas com base nos casos de uso e seus cenários.
       Estruturar procedimentos de teste
       Um procedimento de testes descreve, basicamente, passos e informações necessárias para realização do caso de teste ao qual está associado. Deve conter:
       - Preparação do ambiente (environment set-up): Prover as condições (massa de dados, ferramentas de apoio e equipamentos) necessárias para que o caso de testes seja executado adequadamente e permita a simulação do ambiente real de produção;
       - Como (através de ferramentas de automação de testes, scripts, etc.) e quando fornecer os dados de entrada e obter os resultados da saída;
       - Passos para implementação e execução dos testes;
       - Forma de avaliação dos resultados.
       Os procedimentos de testes definirão como os testes serão implementados e executados.
       Projetar componentes
       Projetar os componentes constitui, basicamente, em definir quais serão os componentes de apoio, e como deverão ser implementados. Esses componentes podem ser scripts gerados com o auxílio de uma ferramenta de teste, ou implementados pelo engenheiro de software.
      
       5.3.2 Implementar Testes

       Nesta atividade, são gerados componentes de teste para dar apoio à execução dos testes. Por exemplo, a geração de stubs para simular o comportamento de módulos do sistema que ainda não estão prontos; componentes para geração de massa de dados, para conversão de base de dados, para registro das entradas e saídas do sistema; e scripts que simulam o funcionamento do sistema são artefatos que podem ser gerados durante a implementação dos testes.
       Gerar componentes de teste
       Neste passo, componentes de apoio existentes podem ser modificados, ou novos componentes podem ser iniciados.
       Os componentes de teste são responsáveis por executar os casos e procedimentos de teste definidos e podem ser gerados de duas formas:
       - Utilizando ferramenta de automação de testes;
       - Programando explicitamente os componentes de teste;
       Definir conjuntos de dados externos
       Aqui, o objetivo é criar e manter os dados armazenados externamente aos componentes de teste (em arquivos ou banco de dados, por exemplo), e que serão usados por estes componentes de teste durante a execução dos mesmos.
       Os conjuntos de dados externos agregam valor ao teste das seguintes maneiras:
       - Dados externos podem ser facilmente modificados com pouco ou nenhum impacto nos componentes de teste;
       - Casos de teste adicionais podem ser facilmente inseridos nos dados de teste com pouca ou nenhuma modificação nos componentes de teste;
       - Dados externos podem ser compartilhados por vários componentes de teste;
       - Conjuntos de dados externos podem conter valores de dados usados para controlar os componentes de teste.

       5.3.3 Executar Testes

       A execução dos testes acontece, basicamente, em três momentos bem definidos: durante a implementação dos casos de uso (testes unitários), onde é realizada pelo próprio programador; após a integração dos casos de uso e/ou dos demais módulos do sistema (testes de integração e/ou de sistemas), onde os testes são realizados pelos próprios programadores ou, por uma equipe independente de testes; e durante a homologação do sistema, onde os testes são executados pelo usuário (testes de aceitação).
       Executar os procedimentos de teste
       Neste passo, os procedimentos e casos de testes são executados com objetivo de encontrar falhas no caso de uso ou módulo em teste. Para tanto, o ambiente de teste, as ferramentas e componentes de apoio devem estar descritos conforme nos procedimentos de teste para que o testador possa executar os casos de teste nas condições ideais. Os testes realizados neste passo são os testes de integração ou de sistema.
       Registrar resultados
       Os resultados dos testes devem ser registrados sob forma de algum dado que possa ser posteriormente analisado: planilha, arquivo texto, etc.

       5.3.4 Avaliar Testes

       A avaliação dos testes pode ser feita através de resultados e gráficos produzidos por ferramentas usadas durante a execução dos mesmos.
       Avaliar procedimentos de teste
       A avaliação dos procedimentos de teste envolve verificar se o ambiente definido para os testes realizados refletiu a necessidade dos testes, ou seja, se os testes foram realizados no ambiente definido. Também devem ser analisados, aspectos que envolvem a cobertura dos casos de testes projetados, ou seja, se os casos de testes definidos cobriram todos os cenários para o caso de uso associado e se as informações contidas em cada caso de teste realmente refletiram o que precisava ser testado.
       Verificar se os critérios de completude e sucesso dos testes foram atingidos
       O objetivo deste passo é determinar se os testes foram completamente executados e de forma aceitável. Neste momento a estratégia definida no Plano de Testes deve ser revisada. Esta estratégia deve apresentar critérios de teste em termos de cobertura dos testes e/ou avaliação de defeitos. Os resultados dos testes, os defeitos e a análise destes defeitos devem ser estudados para verificar se eles satisfizeram os critérios estabelecidos.
       No caso dos critérios não terem sido atingidos, há algumas alternativas:
       - Coletar informações adicionais e repetir os testes;
       - Modificar o critério de aceitação dos testes e repeti-los;
       - Sugerir testes adicionais.

       5.3.5 Executar Testes de Aceitação

       Os testes de aceitação devem ter início quando a avaliação dos testes indicarem que o sistema atingiu os objetivos de qualidade definidos no Plano de Testes. Esta atividade não possui passos, uma vez que o usuário é responsável por realizar e executar testes sem seguir um roteiro fixo. Os problemas encontrados devem ser reparados.