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