O Processo Unified Processo de Desenvolvimento de Software Necessidades do Usuário Processo de Desenvolvimento Elementos Participantes Trabalhadores Atividades Recursos Humanos Artefatos de Software Sistema de Software O Processo Unified Ciclo de Vida de um Software O Processo Unified O Processo Unified Modelos O Começo do Processo Pré-Projeto antes de começar o projeto de um software, (ou seja, antes de começarmos as iterações) é necessário fazermos um planejamento prévio de como esse desenvolvimento se dará Visão do Problema Compreensão do Problema - descrição verbal do domínio do problema - elicitação das necessidades dos investidores Proposta de Solução de Software - descrição verbal propondo como se pode visualizar um sistema de software para resolver o problema estabelecimento de metas e objetivos Visão Geral dos Pré-Requisitos funções do sistema - o que se supõe que o sistema faça atributos do sistema - o que se supõe que o sistema seja O Começo do Processo Planejamento Logístico Equipes de Trabalho - pessoas envolvidas no projeto Grupos Afetados - grupos afetados pelo projeto Fatos Presumidos - fatos que se presumem verdadeiros antes de se iniciar o projeto Riscos - coisas que podem levar ao fracasso ou atrasos no projeto - potenciais consequências do fracasso ou do atraso Dependências - outros parceiros, sistemas ou produtos dos quais o projeto depende para sua implementação Glossário (Vocabulário) de Termos levantamento dos principais termos utilizados para descrever as características do problema Modelo Conceitual de Domínio Modelo Conceitual ilustra conceitos significativos de um domínio - aquilo que devemos estar cientes a respeito do domínio representa coisas do mundo real, NÃO componentes de software obtido a partir da Análise do Domínio Conteúdo conceitos, expressos em um diagrama de classes associações entre os conceitos atributos dos conceitos Análise Estruturada x Análise Orientada a Objetos Análise estruturada enfoca em processos ou funções Análise orientada a objetos enfoca em conceitos Modelo Conceitual de Domínio Lista de Categorias de Conceitos objetos físicos ou tangíveis especificações ou descrições de coisas lugares transações ítens sendo transacionados papéis de pessoas coisas que contém outras coisas coisas que são contidas em outras coisas regras e políticas eventos catálogos de coisas etc... Modelo Conceitual de Domínio Lista de Associações Comuns A A A A A A A A A A A A é uma parte física de B é uma parte lógica de B está fisicamente contido em B está logicamente contido em B é uma descrição para B é um ítem transacionado por B é armazenado em B é membro de B utiliza ou gerencia B se comunica com B possui ou é possuído por B está próximo de B Modelo Conceitual de Domínio PagerMessage get String Listener show Character receives PhoneNumber has IncomingCall opens uses dials Channel Digit Ring has ConfidentialPhoneNumber VibraCall Dialer feed search Catalog receives DialingRequest Password ConfidentialCatalog MainCatalog VoiceRegister Name EmergencyCatalog PreviousDialedMemory Especificação dos Requisitos Encontrar Atores e Casos de Uso Encontrar Atores e Casos de Uso Objetivo iniciar o processo de especificação dos requisitos, desenvolvendo cenários genéricos descrevendo a interação entre o(s) usuário(s) e o sistema Nesta Atividade Explora-se a descoberta de diferentes possíveis casos de uso Casos de uso devem envolver todos os tipos de interações desejadas entre o sistema e os usuários Caso de Uso Narrativa genérica de um caso de interação entre o(s) usuário(s) e o sistema Resultado diagrama de casos de uso Diagrama de Casos de Uso Exemplo: Casos de Uso para um Telefone Celular User Delete Number in Memory Program Number in Memory <<extends>> Search Memory <<extends>> Dial Confidential Phone Number Check Password <<include>> Validate User Dial Number in Memory Dial Phone Number Voice Validation Priorização dos Casos de Uso Priorização dos Casos de Uso Objetivo coletar subsídios para a priorização dos casos de uso, determinando quais deles devem ser desenvolvidos (i.e. analisados, desenhados, implementados, etc) nas primeiras iterações e quais podem ser desenvolvidos nas iterações posteriores Resultados capturados na visão arquitetural do modelo de casos de uso esta visão é considerada pelo gerente de projeto e utilizada para o planejamento do que deve ser desenvolvido na iteração este planejamento leva em consideração também aspectos nãotécnicos, tais como aspectos políticos ou estratégicos visão arquitetural deve destacar os casos de uso que descrevem funcionalidades críticas ou importantes Detalhamento de Casos de Uso Detalhamento de Casos de Uso Objetivo descrever de maneira detalhada os caso de uso selecionados na etapa anterior, referenciando de maneira minuciosa o fluxo de eventos entre os atores e o sistema, incluindo-se como o caso de uso começa, termina e quais as atividades realizadas tanto pelos atores como pelo sistema Descrição de Caso de Uso pode ser realizada por meio de diferentes tipos de artefatos de software: texto (sumarizada ou detalhada) diagrama de estados diagrama de atividades a escolha do artefato ideal depende do grau de complexidade do caso de uso Exemplo de Descrição (Sumária) de Caso de Uso Caso de Uso Atores Propósito DialPhoneNumber Usuário Descrever o processo de discagem de um número Fluxo de Eventos O Usuário informa ao dispositivo que deseja fazer a discagem de um número, entra com uma sequência de n dígitos, informa ao sistema que terminou o número e o sistema inicia o processo de discagem Tipo Primário e Conceitual Variações na Descrição de Casos de Uso Descrição de Caso de Uso pode se tornar bem intrincada Estratégia Básica descrever um fluxo de eventos básico, do começo ao fim, e acrescentar as excessões que podem aparecer a cada instante todas as alternativas, desvios ou excessões devem ser colocadas, para que se possa dizer que o caso de uso está especificado Elementos Essenciais pré-condições: condições necessárias para que o caso de uso possa se iniciar pós-condições: condições que determinam que o caso de uso tenha realmente se encerrado Detalhamento de um Caso de Uso por Diagrama de Atividades Prototipação da Interface com o Usuário Prototipação da Interface com o Usuário Objetivos construir um protótipo da interface com o usuário essa interface não será a interface definitiva, mas deve conter as informações necessárias para a efetivação dos casos de usos descritos nas etapas anteriores Etapas observação dos casos de uso e abstração das informações necessárias a serem implementadas pelas interfaces, para cada ator criação física de protótipos de interfaces com o usuário que ilustram como o sistema poderia implementar os casos de uso Resultado Final conjunto de sketches e protótipos de interface com o usuário, que servirão de inspiração posteriormente na fase de design Estruturação do Modelo de Casos de Uso Estruturação do Modelo de Casos de Uso Objetivo reestruturar os elementos do modelo de casos de uso capturados anteriormente (que podem ter sido capturados de maneira independente entre si) e gerar um modelo que seja homogêneo, consistente e simples de ser interpretado Identificando Descrições Compartilhadas de Funcionalidade relação de generalização Identificando Descrições Adicionais ou Opcionais de Funcionalidade relação de extensão Identificando Descrições Repetidas de Funcionalidade relação de inclusão Análise Análise dos Requisitos: aprofundamento das investigações, detalhamento e refinamento das especificações dos requisitos Objetivos obter uma melhor compreensão dos requisitos, mantendo uma descrição dos requisitos que seja compreensível e auxilie no posterior design do sistema transladar as especificações dos requisitos que se encontram na “linguagem do cliente” para uma representação que use uma “linguagem do desenvolvedor” passar de um modelo de casos de usos para um modelo de análise Principal Desafio: manter um nível abstrato de investigação, sem entrar em questões de design Classes Estereotipadas Classes Boundary utilizada para modelar a interação entre o sistema e os atores interação envolve o recebimento e apresentação de informações Classes Control representam a coordenação, sequenciamento, transações e controle de outros objetos derivações e cálculos Classes Entity modela informações (dados) de longa duração, frequentemente persistentes Análise Análise Arquitetural Análise Arquitetural Objetivo gerar um outline do modelo de análise e da arquitetura por meio da identificação dos pacotes de análise, das classes de análise e de requisitos especiais necessários Sub-Tarefas Identificação dos Pacotes de Análise Identificação de Classes Óbvias do tipo “Entity” Identificação de Requisitos Especiais persistência, distribuição ou concorrência, restrições de segurança, tolerância a falhas e gerenciamento de transações Análise dos Casos de Uso Análise dos Casos de Uso Objetivos identificação das classes de análise cujos objetos são necessários para implementar o fluxo de eventos de um caso de uso em particular – diagrama de classes estereotipadas distribuição do comportamento em um caso de uso por um conjunto de objetos interagindo entre si – diagrama de colaboração ou sequência captura dos requisitos especiais relativos à realização de um caso de uso em particular Análise de Casos de Uso Exemplo de Diagrama de Classes de Análise Análise de Casos de Uso Exemplo de Diagrama de Colaboração da Análise Análise de uma Classe Análise de uma Classe Objetivos identificação e formalização das responsabilidades de uma classe de análise – contrato identificação e formalização dos atributos e relacionamentos de uma classe de análise – enriquecimento do diagrama de classes captura de requisitos especiais Identificação de Responsabilidades Responsabilidades: papéis que objetos da classe assumem em diferentes realizações de casos de uso Associadas às mensagens que uma classe pode receber Análise de uma Classe Descrição de Responsabilidades por meio de Contratos Contratos: descrevem as responsabilidades de uma determinada classe, em termos de quais mudanças no estado do objeto são realizadas quando este recebe mensagens (ou invocações) descrevem O QUE o objeto deve fazer, sem explicar COMO ele o faz Para cada mensagem aparecendo em um diagrama de colaboração, deve haver um contrato correspondente Seções de um Contrato Um contrato está dividido em seções Cada seção provê informações sobre uma parte específica do contrato Nem todas as seções são obrigatórias, devendo aparecer quando necessário Análise de uma Classe Seções de um Contrato Nome: nome da operação e eventualmente seus parâmetros Responsabilidades: uma descrição informal das responsabilidades que a operação deve implementar Tipo:conceitual, classe de software ou interface Referências Cruzadas: outras classes que utilizam o mesmo contrato, etc. Notas: informações adicionais, algoritmos, etc. Exceções: casos excepcionais Saídas Secundárias: saídas não relacionadas à interface com o usuário, e.g. mensagens de erros, logs, etc. Pré-Condições: condições referentes ao estado do sistema antes da execução da operação Pós-Condições: estado do sistema após a conclusão da operação Analisando Pacotes Analisando Pacotes Objetivos garantir a independência entre diferentes pacotes garantir que um pacote de análise implementa seu propósito de realizar classes de domínio ou casos de uso descrever dependências entre pacotes, de tal forma que o efeito de mudanças futuras possa ser estimado Guidelines para a Análise de Pacotes definir e formalizar as dependências entre pacotes, dependendo das classes que estes contiverem garantir que os pacotes contenham as classes corretas. Deve-se tentar manter os pacotes coesos, por meio da inclusão somente de objetos que estejam funcionalmente correlacionados tentar limitar as dependências entre pacotes - deve-se considerar a relocação de classes que criem muitas dependências entre pacotes Design Objetivos do Design Requisitos não-funcionais e restrições relacionadas a: linguagens de programação, reuso de componentes, sistemas operacionais, tecnologias de distribuição e concorrência, tecnologias de bancos de dados, tecnologias de interface com o usuário, tecnologias de gerenciamento de transações, etc ... Definição de subsistemas, interfaces e classes Decomposição do trabalho entre equipes de trabalho Interfaces entre subsistemas arquitetura do software, para a sincronização entre diferentes equipes de trabalho Especificação de elementos lógicos Abstração objetiva da implementação do sistema implementação seja um mero refinamento para o design geração automática de código Patterns e Design Patterns Patterns desenvolvedores de software orientado a objetos experientes acumularam um repertório de princípios gerais e soluções que os guiam frequentemente em suas decisões no desenvolvimento de novos softwares esses princípios são formalizados/compilados, dando origem aos chamados Patterns (padrões) patterns codificam um conhecimento comum sobre princípios de como resolver problemas que aparecem repetidamente Formato par problema/solução que pode ser aplicado em novos contextos, acompanhados de conselhos sobre como devem ser aplicados nomes sugestivos: enraízam o conceito do pattern em nossa memória e promovem seu uso, sempre que possível Patterns e Design Patterns Origem dos Patterns “Design Patterns: Elements of Reusable Object-Oriented Software” de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (Gang of Four - GoF) Vários diferentes domínios: organizações, processos, ensino, arquitetura, etc…. Atualmente: arquitetura e design de software, outras fases do desenvolvimento de software (análise, etc…) Outros livros: Pattern-Oriented Software Architecture: A System of Patterns” (POSA book), de Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Somerlad e Michael Stal (Siemens Gang of Five - GoV) Pattern Languages of Program Design and PLPD 2 - selected papers from 1st and 2nd conferences on Patterns Languages of Program Design Frameworks Frameworks de Software são mini-arquiteturas reutilizáveis que provêm a estrutura genérica e comportamento para famílias de abstrações de software, junto com um contexto de metáforas que especificam sua aplicação e uso dentro de um dado domínio correspondem a um conjunto de classes cooperantes que permitem uma reutilização de design para uma classe de software específica. Um framework provê uma orientação arquitetural, definindo quais as responsabilidade e colaborações entre objetos. Um designer customiza um framework para uma aplicação em particular, normalmente por meio do subclasseamento e geração de instâncias de classes derivadas das classes do framework reutilização do design por meio da reutilização do código implementação de um sistema de design patterns Design Design Arquitetural Design Arquitetural Objetivo desenvolver um outline dos modelos de design e de distribuição, bem como sua arquitetura, identificando-se os seguintes: nós computacionais envolvidos e arquitetura de rede subsistemas e suas interfaces classes de design arquiteturalmente significativas, tais como classes ativas mecanismos genéricos de design que garantam a implementação dos requisitos especiais sobre persistência, distribuição, desempenho, etc. Reuso nesta atividade, considera-se as diferentes possibilidade de reuso, tais como o reuso de partes, componentes, subsistemas, etc... Design Arquitetural Sistemas de Software Aplicações Monolíticas Aplicações Multi-Thread Sistemas Cliente-Servidor Sistemas Baseados em Componentes Design Arquitetural Identificação de Nós e Configuração de Rede configuração de rede pode ser fundamental para a aplicação em desenvolvimento configurações de rede normalmente utilizam uma arquitetura em três camadas aspectos da configuração de rede incluem: quais nós estão envolvidos e quais suas capacidades que tipo de conexões há entre os nós e quais protocolos utilizam quais as características das conexões (capacidade, qualidade, etc) existe necessidade de processamento redundante, etc.. Conhecendo os limites e possibilidades dos nós e suas conexões, o arquiteto pode incorporar tecnologias tais como ORBs (Object Request Brokers), serviços de replicação de dados, etc ... Design Arquitetural Exemplo de Identificação de Nós e Configuração de Rede cada configuração de rede, incluindo configurações especiais para teste e simulações, deve ser descrita em um diagrama de distribuição em separado Design Arquitetural Identificando Subsistemas e suas Dependências Design Arquitetural Identificando Interfaces de Subsistemas interfaces de subsistemas definem operações que são acessíveis “de fora” do subsistema essas interfaces são providas por classes ou outros subsistemas (recursivamente) dentro do subsistema inicialmente, antes que o conteúdo de um subsistema seja conhecido começa-se considerando as dependências entre subsistemas em seguida, analisa-se as classes dentro dos pacotes de análise interfaces para os subsistemas de middleware e software de sistema interfaces pré-definidas pelo produto utilizado não basta identificar somente quais são as interfaces identificar as operações disponibilizadas por cada interface Design Arquitetural Identificando Classes de Design Arquiteturalmente Significativas classes de design derivadas de classes de análise identificação de classes ativas: considerações sobre os requisitos de concorrência do sistema requisitos sobre desempenho, throughput, disponibilidade e tempo de resposta necessários pelos diferentes atores interagindo com o sistema (e.g. caso o ator demande certo tempo de resposta, devese disponibilizar um objeto ativo somente para a interação) distribuição do sistema pelos nós (e.g. caso seja necessário suportar distribuição por diversos nós, cada nó demandará pelo menos um objeto ativo para gerenciar a comunicação) outros requisitos, tais como requisitos de inicialização e shutdown, sobrevivência, evitação de deadlocks, capacidade de reconfiguração de nós, etc ... Design Arquitetural Identificação de Mecanismos Genéricos de Design neste passo, estudam-se os requisitos comuns, tais como os requisitos especiais identificados durante a análise, decidindo-se como implementá-los, dadas as tecnologias de implementação disponíveis resultado é um conjunto de mecanismos genéricos de design, instanciados em classes de design tipos de requisitos instanciados persistência distribuição de objetos transparente (objetos distribuídos) requisitos de segurança detecção e recuperação de erros gerenciamento de transações Design de Casos de Uso Design de Casos de Uso Objetivos identificação das classes de design e subsistemas cujas instâncias são necessárias para realizar o fluxo de eventos de um caso de uso distribuição do comportamento do caso de uso entre objetos de design interagindo entre si ou com outros subsistemas definição dos requisitos sobre as operações disponíveis nas classes de design e/ou subsistemas com interfaces Sub-Atividades identificação das classes de design participantes descrição das interações entre objetos de design identificação de subsistemas participantes e suas interfaces descrição das interações entre subsistemas captura dos requisitos de implementação para o caso de uso Design de Casos de Uso Identificação das Classes de Design Participantes estudo das classes de análise estudo dos requisitos especiais diagrama de classes de design Descrição das Interações diagramas de sequência ou de colaboração Design de Casos de Uso Identificação de Subsistemas e Interfaces estudo das classes de análise estudo dos requisitos especiais diagrama de classes Descrição das Interações entre Subsistemas diagramas de sequência lifelines denotam subsistemas e não objetos cada subsistema deve ter sua própria lifeline mensagens dizem respeito a operações da interface do subsistema Captura de Requisitos de Implementação captura de requisitos (não funcionais) que afetam diretamente a implementação Design de Classes Design de Classes Objetivos criação de classes de design que exercem seu papel na realização do caso de uso, obedecendo os requisitos nãofuncionais que se aplicam aspectos sendo detalhados: operações atributos relacionamentos dos quais participa métodos (como realizar as operações) estados válidos dependências para com mecanismos genéricos de design requisitos importantes para a implementação realização correta das interfaces com as quais está envolvida Design de Classes Sub-Etapas criando um outline da classe de design identificando operações e atributos identificando associações, agregações e generalizações descrevendo métodos descrevendo estados gerenciando requisitos especiais Design de Subsistemas Design de Subsistemas Objetivos garantir que os subsistemas sejam tão independentes quanto possível de outros subsistemas e suas interfaces garantir que os subsistemas provêm uma interface adequada garantir que os subsistemas realizam seu propósito, ou seja, oferecem uma realização adequada das operações definidas por suas interfaces Sub-Etapas Gerenciamento das Dependências entre Subsistemas Gerenciamento das Interfaces providas pelo susbsistema Gerenciamento do Conteúdo dos subsistemas para cada interface, associa com as classes de design do subsistema que provê a funcionalidade Implementação Implementação utiliza-se os artefatos desenvolvidos no design para implementar o sistema em termos de seus componentes, ou seja, código fonte, scripts, binários, executáveis, etc ... Objetivos planejar a integração do sistema necessária na iteração corrente distribuir o sistema entre componentes executáveis localizados nos nós do modelo de distribuição implementação das classes de design e dos subsistemas especificados no design (geração de código) teste individual dos componentes e posterior integração em módulos executáveis Implementação Componentes possuem diversos estereótipos «executable», «file», «library», «table», «document» possuem relacionamentos do tipo «trace» com os elementos do modelo que implementam podem implementar individualmente diversos modelos diferentes Implementação Implementação Subsistemas de Implementação package em Java project em VisualBasic diretório de arquivos em um projeto C++ subsistema em IDEs tais como o Rational Apex component view package, em ferramentas de modelagem visual tais como o Rational Rose Implementação Implementação Arquitetural Implementação Arquitetural Objetivo criar um outline do modelo de implementação identificação de componentes arquiteturalmente significativos, tais como componentes executáveis mapeamento desses componentes em nós da configuração de rede Identificação de Componentes arquiteturalmente significativos diagrama de componentes Identificação dos Componentes Executáveis e seu Mapeamento nos Nós diagrama de distribuição, mostrando onde se localizam componentes objetos ativos (aqueles com Thread de controle individual) Integração do Sistema Integração do Sistema Objetivos criação da um plano de construção integrado, descrevendo as construções necessárias na iteração corrente e quais os requisitos que essa construção implementa definição efetiva de quais componentes serão integrados e criação de scripts de compilação e linkagem Planejamento da Construção verificação de implementações de iterações anteriores e eventual reuso de partes já consolidadas adição de funcionalidades para a construção corrente, por meio da adição de novos casos de uso Integrando a Construção criação de scripts de compilação e linkagem das versões corretas dos diferentes componentes sendo integrados Implementação de Subsistemas Implementação de Subsistemas Objetivos garantir que a implementação de um subsistema cumpra seu papel, a cada construção, como estipulado pelo plano de construção integrada garantir que os casos de uso e cenários estejam corretos e que as interfaces estejam corretas Gerenciamento do Conteúdo de Subsistemas mesmo que o conteúdo de um subsistema já esteja determinado pelo arquiteto, ele pode requerer pequenos refinamentos implementados pelo engenheiro de componentes, a medida que a implementação se desenvolve à medida que subsistemas contenham outros subsistemas recursivamente, a metodologia de mapeamento entre componentes e classes de design é análoga em cada nível Implementando Classes Implementando Classes Objetivos implementação de classes de design na forma de componentes distribuição do código fonte em um ou diversos arquivos • componentes do tipo «file» geração do código fonte a partir das classes de design e dos relacionamentos em que participa • esqueletos de código podem ser gerados automaticamente implementação das operações das classes de design em termos de métodos • alguns tipos de operações podem também ser geradas automaticamente, sendo complementadas com edição posterior verificação de que o componente provê a mesma interface que a classe de design que implementa eventualmente, conserto de defeitos, quando a classe já havia sido implementada em outras iterações Teste de Unidade Teste de Unidade Objetivos realização de um teste individual do componente implementado, sem considerar sua posterior integração Tipos de Testes Teste de Especificação verifica o comportamento observável externo da unidade, sem entrar no mérito de como esse comportamento é implementado focaliza nas entradas e saídas da unidade Teste Estrutural verifica a implementação interna da unidade, fazendo com que cada trecho do código seja executado Outros Testes testes de desempenho, uso de memória, escalabilidade e capacidade Testes Fase de Testes verificação dos resultados da implementação por meio do teste de cada módulo do sistema e sua integração Objetivos planejamento dos testes a serem executados em cada iteração design e implementação dos testes por meio de casos de teste que especificam o que testar e quais os procedimentos a serem utilizados para os testes criação de componentes de teste executáveis para a automação de testes, quando possível avaliar sistematicamente os resultados de cada teste e encaminhar os módulos defectivos para que estes possam ser retrabalhados Testes Modelos de Teste descreve como componentes executáveis do modelo de implementação são testados por meio de testes de integração e testes de sistema descreve os aspectos específicos do sistema que serão testados coleção de casos de teste, procedimentos de teste e componentes de teste Caso de Teste corresponde a um caso de uso, só que com finalidades de teste especifica um cenário de teste, incluindo o que testar, com que entradas e com quais resultados esperados caso de teste pode estar associado a um caso de uso ou à realização do caso de uso no design Testes Procedimentos de Teste especifica como realizar um ou mais casos de teste Componente de Teste automatizam um ou mais procedimentos de teste linguagens de script ou linguagens de programação Testes Tipos de Teste Testes de Instalação verificam que o sistema pode ser instalado na plataforma do cliente e que o sistema opera corretamente após instalado Testes de Configuração verificam que o sistema opera corretamente sob diferentes configurações Testes Negativos tentam ocasionar falhas no sistema para revelar suas fraquezas tenta-se utilizar o sistema de maneiras para as quais ele não foi projetado, e.g. testando-se configurações de rede defeituosas, hardware insuficiente ou demanda de uso (carga) intensiva Testes de Stress tentam verificar como o sistema se comporta quando os recursos disponíveis são insuficientes ou estão indisponíveis Testes Planejamento de Testes Planejamento de Testes Objetivos planejar os esforços de teste dentro de uma iteração descrevendo uma estratégia de testes estimando os requisitos para o esforço de teste, tais como recursos humanos e do sistema criando uma escala de testes a ser executada Plano de Testes são construídos com base nos diversos modelos utilizados nas fases de especificação, análise, design e implementação Estratégia Geral de Testes que tipos de testes serão executados, como executá-los, quando executá-los e como avaliar os resultados dos testes testes custam recursos e tempo, portanto deve-se efetuar uma solução de testes que tenha uma boa relação custo/benefício Projeto de Testes Projeto de Testes Objetivos identificar e descrever casos de teste para cada módulo identificar e estruturar procedimentos de teste especificando como realizar os casos de teste Sub-Etapas Projetando casos de teste de integração Projetando casos de teste de sistema Projetando casos de teste regressivos aproveitam casos de teste de iterações anteriores Identificando e Estruturando Procedimentos de Teste Regra Geral deve-se utilizar um conjunto de testes que requeiram um mínimo esforço, dado um plano de testes mínimo “overlap” entre casos de teste Implementação de Testes Implementação de Testes Objetivos automatizar procedimentos de teste por meio da criação de componentes de teste, se possível (nem todos os procedimentos de teste podem ser automatizados) Componentes de Teste criados utilizando os procedimentos de teste como entrada quando se utiliza uma ferramenta de automação, um conjunto de ações são previamente criadas para que o módulo em questão seja testado. A própria ferramenta se encarrega de criar os componentes de teste quando programando os componentes de teste explicitamente, utiliza-se os procedimentos de teste como uma forma de especificação para que os componentes de teste sejam desenvolvidos Teste de Integração Teste de Integração Objetivos realizar os testes de integração especificados para cada módulo do sistema Sequência de Testes de Integração realizar os testes de integração relevantes por meio da execução manual dos procedimentos de teste para cada caso de teste ou por meio de algum componente de teste disponível para o procedimento de teste em questão comparação dos resultados com os resultados esperados e a discriminação dos casos que apresentaram resultados inesperados relatar os defeitos encontrados ao engenheiro de componentes, para que estes possam corrigir os componentes defeituosos relatar os defeitos ao engenheiro de testes, para que este possa estimar os resultados finais da sequência de testes Teste de Sistema Teste de Sistema Objetivos realizar os testes de sistema especificados a cada iteração, capturando os resultados do teste Teste de Sistema se inicia quando os testes de integração indicam que o sistema atende as metas de qualidade quanto a integração de seus componentes para a iteração corrente (e.g. 95 % dos testes de integração executam com resultado esperado) são realizados de maneira análoga aos testes de integração (i.e. seguindo uma sequência de testes análoga ao dos testes de integração avaliam o comportamento do funcionamento do sistema como um todo, e não somente com relação à integração individual entre alguns de seus componentes Avaliação de Testes Avaliação de Testes Objetivo avaliação dos esforços de teste para a iteração corrente comparação dos resultados com as metas especificadas no planejamento de testes criação de métricas que determinem o nível de qualidade do software, especificando maiores testes que necessitem ser realizados Exemplos de Métricas Métricas de Completude derivadas da cobertura dos casos de teste e dos componentes de teste. Indicam qual a porcentagem de casos de teste que foram executados e qual a porcentagem de código que foi testada Métricas de Confiabilidade baseadas na análise dos defeitos descobertos com relação aos casos que tiveram um resultado como esperado Referências Complementares The Unified Software Development Process Ivar Jacobson, Grady Booch, James Rumbaugh Addison-Wesley, 1999 - ISBN 0-201-57169-2 UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language Martin Fowler, Kendall Scott, Grady Booch 2nd edition, Addison-Wesley, 1999 - ISBN 0-201-65783-X Applying UML and Patterns Craig Larman Prentice Hall, 1998 - ISBN 0-137-48880-7 Unified Modeling Language (UML), version 1.5 Norma Técnica da OMG ftp://ftp.omg.org/pub/docs/formal/03-03-01.pdf