O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores...
-
Upload
thalita-domingues-peres -
Category
Documents
-
view
213 -
download
1
Transcript of O Processo Unified zProcesso de Desenvolvimento de Software zElementos Participantes yTrabalhadores...
O Processo Unified
Processo de Desenvolvimento de Software
Elementos Participantes Trabalhadores Atividades Recursos Humanos Artefatos de Software
Necessidadesdo Usuário
Sistema deSoftware
Processo de Desenvolvimento
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 é uma parte física de B A é uma parte lógica de B A está fisicamente contido em B A está logicamente contido em B A é uma descrição para B A é um ítem transacionado por B A é armazenado em B A é membro de B A utiliza ou gerencia B A se comunica com B A possui ou é possuído por B A está próximo de B
Modelo Conceitual de Domínio
EmergencyCatalog PreviousDialedMemory
Ring VibraCall
MainCatalogConfidentialCatalog
ConfidentialPhoneNumber
Password
VoiceRegister
PagerMessage
Listener
get
PhoneNumber
show
Digit
Character
String
DialingRequest
has
Dialer
dials
receives
Name
Catalog
search feed
IncomingCall
receives
has
Channel
opensuses
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
Program Number in Memory
Search Memory
Delete Number in Memory User
Validate User
Check Password
Voice Validation
Dial Confidential Phone Number
<<include>>
Dial Number in Memory
Dial Phone Number
<<extends>> <<extends>>
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ão-té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 DialPhoneNumber Atores Usuário Propósito 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 iniciao 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 sub-classeamento 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 sistemarequisitos 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, deve-se 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ão-funcionais 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
componentesobjetos 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 testesestimando os requisitos para o esforço de teste, tais como
recursos humanos e do sistemacriando 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 Confiabilidadebaseadas 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