FIP SI Sabrina de F. Souto.

Processo
Processo de Software
Modelo Constri e Conserta
Modelo Cascata
Modelo de Prototipao
Modelo Espiral
IBM Rational Unified Process RUP
eXtreme Programming
Teste de Software
Fluxo de Teste
Processo de Teste

Um processo:
uma ao regular e contnua (ou sucesso de aes)
realizada de forma bem definida, levando a um resultado
[Oxford English Dictionary]
um conjunto parcialmente ordenado de atividades (ou
passos) para se atingir um objetivo [Feiler & Humphrey]
define quem est fazendo o que, quando e como para
atingir um certo objetivo [Jacobson, Booch, Rumbaugh]

Em engenharia de software, o objetivo

desenvolvimento de um produto de software

Em
engenharia
de
processos,
o
objetivo
desenvolvimento de um (modelo de) processo

O termo ciclo de vida evoluiu para processo

Exemplos de ciclos de vida de software:
incremental

cascata, espiral,

Conjunto de atividades,
atividades mtodos,
mtodos
prticas e tecnologias que as
pessoas utilizam para desenvolver
e manter software e produtos
relacionados

O processo a ponta do tringulo

que unifica os outros aspectos

Mesmo as melhores pessoas no conseguem trabalhar de

forma eficiente se o processo problemtico ou mal
compreendido

Investimentos em tecnologia sem um guia que defina como

utiliz-la um desperdcio de recursos

Sem processos claros e eficientes, uma empresa no

escalvel

O interesse do processo de software est baseado em duas

premissas:
1.

A qualidade de um produto de software

fortemente
dependente da qualidade do processo pelo qual ele
construdo e mantido

2.

O processo de software pode ser definido, gerenciado, medido

e melhorado

Um processo definido deve estar descrito em detalhes

de forma a poder ser usado de forma consistente

O nmero de defeitos presentes no software quando

entregue para testes funo direta da qualidade do
processo usado para a construo do software
o

Testes s podem detectar 70% dos defeitos latentes no cdigo

Inspees podem detectar 80 a 90% dos erros antes dos testes

Mas, um bom processo evita a presena de defeitos no

produto.

Precisamos aprender a atacar a doena e

no os sintomas:
o processo e no os defeitos no software

O produto construdo sem qualquer especificao ou

projeto;
O produto retrabalhado quantas vezes for necessrio para
satisfazer o cliente;
Este modelo pode funcionar razoavelmente para micro
projetos (<400 pessoas/hora);
No entanto para projetos maiores

ele inadequado.

10

recomendado para sistemas onde a segurana e a

confiabilidade tem grande importncia.

Pontos fortes
o
o
o

uma abordagem disciplinada

Definio da documentao libervel em cada fase
Todos os produtos de cada fase tem que ser formalmente
revisados

Cada fase possui procedimentos de verificao e validao

(incluindo testes)

Uma vez definido o modelo de ciclo de desenvolvimento,

existem trs abordagens para implement-lo:
o
o
o

Cascata Pura
Incremental
Evolucionria

11

Todas as fases do ciclo de desenvolvimento so executadas

em seqncia.

Esta abordagem adequada quando :

o
o
o

existe um conjunto de requisitos estvel e de alta qualidade

a durao do projeto pequena(<2 anos)
o sistema completo deve estar disponvel de um nica vez

Requisitos
Projeto
Implementao
Teste
Manuteno
12

A abordagem incremental adequada quando:

o

a liberao do software deve estar de acordo com um conjunto de

prioridades definidas nos requisitos
necessrio melhorar a eficincia da integrao do software com
outra partes de um sistema maior
requerido antecipadamente evidncias de que o produto ser aceito

Requisitos
Projeto
Implementao
Teste
Manuteno
13

Esta abordagem adequada quando:

o

o
o

necessrio alguma experincia do usurio para refinar e completar

requisitos
algumas partes da implementao podem depender da existncia de
tecnologia ainda no disponvel
existem requisitos do usurio ainda no conhecidos
alguns requisitos so muito mais difceis de serem implementados do
que outros, decidindo-se no implement-lo para no atrasar o
projeto

14

O objetivo entender os requisitos do usurio e, assim, obter

uma melhor definio dos requisitos do sistema

Possibilita que o desenvolvedor crie um modelo (prottipo) do

software que deve ser construdo

Apropriado quando o cliente no definiu detalhadamente os

requisitos

Esse modelo pode assumir uma das trs formas:

o

Um prottipo em papel ou modelo baseado em PC que retrata a

interao homem-mquina de uma forma que capacita o usurio a
entender quanto a interao ocorrer
Um prottipo de trabalho que implemente algum subconjunto da
funo exigida do software desejado, ou
Um programa existente que executa toda a funo desejada, mas
que tem outras caractersticas que sero melhoradas em um novo
esforo de desenvolvimento

15

Obter Requisitos

Elaborar Projeto Rpido

Refinamento do Prottipo

CONSTRUO
DO PRODUTO
Construir Prottipo

Avaliar Prottipo
16

Foi originalmente proposto por Boehm em 1988

Uma maneira simplista de analisar este modelo considerlo como um modelo cascata onde cada fase precedida por
uma anlise de risco e sua execuo feita
incrementalmente

A dimenso radial representa o custo acumulado atualizado

e a dimenso angular representa o progresso atravs da
espiral

Cada setor da espiral corresponde a uma tarefa (fase)do

desenvolvimento

17

18

Um ciclo se inicia com a "Determinao de objetivos,

alternativas e restries "(primeira tarefa) onde ocorre o
comprometimento dos envolvidos e o estabelecimento de
uma estratgia para alcanar os objetivos

Na segunda tarefa: "Avaliao de alternativas, identificao e

soluo de riscos", executa-se uma anlise de risco

Prototipao uma boa ferramenta para tratar riscos. Se o

risco for considerado inaceitvel, pode parar o projeto

Na terceira tarefa ocorre o desenvolvimento do produto. Neste

quadrante pode-se considerar o modelo cascata

Na quarta tarefa o produto avaliado e se prepara para iniciar

um novo ciclo

19

20

Variaes do modelo espiral consideram entre trs e seis

tarefas ou setores da espiral. Um exemplo so as regies:
1.

Comunicao com o cliente

2.

Planejamento

3.

Anlise de risco

4.

Engenharia

5.

Construo e liberao

6.

Avaliao do cliente

21

A manuteno de um software utilizando

este modelo de ciclo de vida tratado da
mesma forma que o desenvolvimento

22

O Rational Unified Process um processo de engenharia de

software, que procura disciplinar atribuies de tarefas e
responsabilidades
dentro
de
uma
estrutura
de
desenvolvimento de software. Sua meta principal garantir a
produo de software com alta qualidade satisfazendo as
necessidades dos seus usurios, dentro de um cronograma e
oramento previsvel. (Rational Unified Process, 2008)

O RUP um processo configurvel, ajustando-se tanto para

pequenas equipes de desenvolvimento quanto para grandes

23

Rene muitas das melhores prticas em desenvolvimento de

software:
o

Desenvolvimento iterativo de software

Gerenciamento de requisitos

Arquitetura baseada em componentes

Modelagem visual do software (prottipo)

Verificao da qualidade do software (testes)

Controle de mudanas no software

24

25

De acordo com o RUP, as fases constituem os ciclos de vida

do software, sendo cada ciclo responsvel por uma verso
nova do produto. Estas fases so:
o
o
o
o

Concepo (Inception)
Elaborao (Elaboration)
Construo (Construction)
Transio (Transition)

O RUP representado usando quatro elementos para

modelagem:
o
o
o
o

Papis/Equipe (quem est fazendo o que)

Artefatos (o que produzido)
Atividades (como o trabalho conduzido)
Workflows (quando uma tarefa conduzida)

26

A Extreme Programming - XP - uma metodologia gil

voltada s equipes pequenas e mdias que desenvolvem
software baseado em requisitos vagos e que se alteram com
rapidez (Beck, 2004)

O objetivo de XP tornar o projeto flexvel, diminuindo o

custo a possveis mudanas

Por que o termo extreme no nome?

27

XP leva ao extremo seus princpios e prticas:

o

Se revisar o cdigo bom, ento vamos revisar o cdigo durante

todo o tempo (programao em par)
Se testar bom, ento todo mundo vai testar durante todo o
tempo (teste de unidade), at os clientes (teste funcional)
Se design bom, ento vamos fazer com que isso seja parte do
dia-a-dia da equipe (refatorao de cdigo)
Se ter simplicidade bom, ento vamos deixar o sistema com o
design o mais simples possvel
Se arquitetura importante, todo mundo ir defin-la e refin-la
durante todo o tempo (metfora)
Se teste de integrao importante, ento vamos integrar e
testar vrias vezes ao dia (integrao contnua)
Se ter iteraes pequenas legal, ento vamos fazer iteraes
muito pequenas segundos/minutos/hora (Planning Game)

28

As prticas promovidas por XP se forem examinadas

individualmente apresentaro falhas, mas uma das foras da
XP que as prticas se combinam de um modo mtuo
apoiando-se

Fases de XP:
o
o
o
o
o
o

Explorao
Planejamento
Iteraes para release
Validao para produto
Manuteno
Morte

29

30

Qual atende melhor?

31

32