Engenharia de Software I 2012.

Modelos de Processo
de Software
Ricardo Argenton Ramos
ricargentonramos@gmail.com

A Engenharia de Software
Uma Tecnologia em Camadas

Gerenciamento da Qualidade Total e filosofias similares

produzem uma mudana cultural que permite o
desenvolvimento crescente de abordagens mais maduras para
a Engenharia de Software
2

ENGENHARIA DE SOFTWARE
pode ser vista como uma abordagem dedesenvolvimento
de software elaborada com disciplina e mtodos bem
definidos.

.....a construo por mltiplas pessoas de um

software com mltiplas verses [Parnas 1987]
3

Modelos de Processo de
Software

Existem vrios modelos de processo de

software (ou paradigmas de engenharia de
software)
Cada um representa uma tentativa de
colocar ordem em uma atividade
inerentemente catica

Modelos de Processo de
Software
O Modelo Seqencial Linear
(tambm chamado Ciclo de Vida Clssico ou
Modelo Cascata)

O Modelo
Baseado em
Componentes

O Modelo Espiral

O Paradigma de
Prototipao
Processo Unificado

O Modelo Seqencial Linear

(tambm chamado Ciclo de Vida
Clssico ou Modelo Cascata)

O Modelo Cascata

modelo mais antigo e o mais

amplamente usado da engenharia
de software
modelado em funo do ciclo da
engenharia convencional
requer uma abordagem sistemtica,
seqencial ao desenvolvimento de
software
o resultado de uma fase se constitui
na entrada da outra
7

O Modelo em Cascata
Verificar Plano
Explorao de
conceitos
Requisitos

Projeto

Projeto de V & V

Implementao
Evoluir

O qu

Requisitos de V & V

Testes

Como

Sistema de V & V
Tarefas de V & V

Operao
Sistema

Feedback

Instalao e
de V & V
liberao
Operao
Manuteno e
de V & V
operao
8

O Modelo em Cascata
Explorao de Conceitos / Informao e
Modelagem

Engenharia de
Sistemas
Anlise de
Requisitosde requisitos do sistema, com uma pequena

Envolve a elicitao
quantidade de projeto e Projeto
anlise de alto nvel;

Codificao como engenharia

Preocupa-se com aquilo que conhecemos
progressiva de produto de software;
Testes
Iniciar com um modelo conceitual de alto nvel para um sistema e
Manuteno
prosseguir com o projeto, implementao e teste
do modelo fsico do
sistema.

O Modelo em Cascata

Anlise de Requisitos de Software

o processo
dede elicitao dos requisitos
Engenharia
Sistemas
intensificado
eAnlise
concentrado
especificamente no
de
Requisitos
software
Projeto
deve-se compreender o domnio
Codificao da informao, a
funo, desempenho e interfaces
exigidos
Testes
os requisitos (para o sistema e para o Manuteno
software) so
documentados e revistos com o cliente
10

O Modelo em Cascata

Projeto
traduo dos requisitos do software para um
conjunto de representaes que podem ser
avaliadas quanto qualidade, antes que a
codificao inicie

11

O Modelo em Cascata

Implementao
traduo das representaes do projeto para uma
linguagem artificial resultando em instrues
executveis pelo computador e implementado
num ambiente de trabalho.

12

O Modelo em Cascata
Testes

Concentra-se:

nos aspectos lgicos internos do software,

garantindo que todas as instrues tenham sido
testadas
nos aspectos funcionais externos, para descobrir
erros e garantir que a entrada definida produza
resultados que concordem com os esperados.

13

O Modelo em Cascata

Manuteno
provavelmente o software dever sofrer
mudanas depois que for entregue ao cliente
causas das mudanas: erros, adaptao do
software para acomodar mudanas em seu
ambiente externo e exigncia do cliente para
acrscimos funcionais e de desempenho

14

com o Modelo em
Cascata


Projetos reais raramente seguem o fluxo seqencial

que o modelo prope;
Logo no incio difcil estabelecer explicitamente
todos os requisitos. No comeo dos projetos sempre
existe uma incerteza natural;
O cliente deve ter pacincia. Uma verso executvel
do software s fica disponvel numa etapa avanada
do desenvolvimento (na instalao);
Difcil identificao de sistemas legados (no
acomoda a engenharia reversa).
15

Embora o Modelo em Cascata

tenha fragilidades, ele
significativamente melhor do
que uma abordagem casual de
desenvolvimento de software.

16

O Modelo em Cascata

O Modelo de processo em Cascata trouxe

contribuies importantes para o processo de
desenvolvimento de software:

Imposio de disciplina, planejamento e

gerenciamento
a implementao do produto deve ser postergada at
que os objetivos tenham sido completamente entendidos;
Permite gerncia do baseline, que identifica um conjunto
fixo de documentos produzidos ao longo do processo de
desenvolvimento;

17

O Paradigma de Prototipao

18

O Modelo de Prototipao

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 para quando o cliente no definiu
detalhadamente os requisitos.

19

O Paradigma de Prototipao
para obteno dos requisitos

Obter Requisitos

Elaborar Projeto Rpido

Refinamento do Prottipo

Construir Prottipo
Avaliar Prottipo
20

O Paradigma de Prototipao
para obteno dos requisitos

1- OBTENO
DOS REQUISITOS:
Obter Requisitos
desenvolvedor e cliente definem os
objetivos gerais do software,
identificam quais requisitos
so Projeto Rpido
Elaborar
conhecidos e as reas que necessitam
Refinamento do Prottipo
de definies adicionais.

Construir Prottipo
Avaliar Prottipo
21

O Paradigma de Prototipao
para obteno dos requisitos

Obter Requisitos

2- PROJETO RPIDO:
Elaborar Projeto Rpido
representao dos aspectos do
Refinamento do Prottipo
software que so visveis ao usurio
(abordagens de entrada e formatos
de sada)
Construir Prottipo
Avaliar Prottipo
22

O Paradigma de Prototipao
para obteno dos requisitos

Obter Requisitos

Elaborar Projeto Rpido

Refinamento do Prottipo

3- CONSTRUO DO PROTTIPO:

implementao rpida do
projeto
Construir Prottipo
Avaliar Prottipo
23

O Paradigma de Prototipao
para obteno dos requisitos

Obter Requisitos

Elaborar Projeto Rpido

Refinamento do Prottipo

4- AVALIAO DO PROTTIPO: cliente e

Construir Prottipo
desenvolvedor avaliam o prottipo
Avaliar Prottipo
24

O Paradigma de Prototipao
para obteno dos requisitos

Obter Requisitos

Elaborar
Projeto
5- REFINAMENTO DO PROTTIPO:
cliente
e Rpido
Refinamento
do Prottipo
desenvolvedor
refinam

os requisitos do
software a ser desenvolvido.
Construir Prottipo
Avaliar Prottipo
25

O Paradigma de Prototipao
para obteno dos requisitos

Obter Requisitos

CONSTRUO
Refinamento
do Prottipo
DO
PRODUTO

Elaborar Projeto Rpido

Construir Prottipo
Avaliar Prottipo
26

O Paradigma de Prototipao
para obteno dos requisitos

Obter Requisitos

6- CONSTRUO PRODUTO:

identificados os requisitos, o
Elaborar
Projeto Rpido
prottipo
deve
ser
descartado
e
a
CONSTRUO
verso
de do
produo
Refinamento
Prottipo deve ser
DO
PRODUTO
construda considerando os
critrios de qualidade.
Construir Prottipo
Avaliar Prottipo
27

Problemas com a Prototipao

cliente no sabe que o software que ele v

no considerou, durante o desenvolvimento,
a qualidade global e a manutenibilidade a
longo prazo
desenvolvedor freqentemente faz uma
implementao comprometida (utilizando o
que est disponvel) com o objetivo de
produzir rapidamente um prottipo
28

Comentrios sobre o
Paradigma de Prototipao

ainda que possam ocorrer problemas, a

prototipao um ciclo de vida eficiente.
a chave definir as regras do jogo logo no
comeo.
o cliente e o desenvolvedor devem ambos
concordar que o prottipo seja construdo
para servir como um mecanismo para definir
os requisitos
29

Exerccio

Vamos refazer o exerccio da primeira aula,

agora utilizando a Prototipao para construir
o Projeto.
Obter Requisitos

Refinamento do
Prottipo
Avaliar Prottipo

Elaborar Projeto
Rpido
Construir Prottipo

30

O Modelo Espiral

31

O Modelo Espiral

(Boehm, 1986)

O modelo espiral acopla a natureza iterativa da

prototipao com os aspectos controlados e
sistemticos do modelo cascata.
O modelo espiral dividido em uma srie de
atividades de trabalho ou regies de tarefa.
Existem tipicamente de 3 a 6 regies de tarefa.
Combina as caractersticas positivas da gerncia
baseline (documentos associados ao processo);

32

O Modelo Espiral (com 4 regies)

AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS

DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES

Risk
analys is
Risk
analys is
Risk
analys is

REVIEW
Requirements plan
Life-cycle plan

Develop ment
plan
Integrati on
and test p lan
PLANEJAR PRXIMA FASE

Prot otyp e 3

Prot otyp e 2
Risk
analysis Prot oty pe 1

Operati onal
protoyp e

Sim ul ati ons, m odels, b en ch marks

Concept o f
Operati on

S/W
requi rement s

Requi rement
valid ati on

Prod uct
desi gn

Detail ed
desi gn

Code
Uni t tes t
Desi gn
V& V
Integr ati on
test
Accep tance
test
Serv ice
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL

33

O Modelo Espiral (com 4 regies)

AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS

DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES

Risk
analys is
Risk
analys is

cada ciclo na espiral

representa uma
REVIEW
fase do processo
de
Requirements plan
Life-cycle plan
software
Develop ment
plan
Integrati on
and test p lan
PLANEJAR PRXIMA FASE

Risk
analys is

Prot otyp e 3

Prot otyp e 2
Risk
analysis Prot oty pe 1

Operati onal
protoyp e

Sim ul ati ons, m odels, b en ch marks

Concept o f
Operati on

S/W
requi rement s

Requi rement
valid ati on

Prod uct
desi gn

Detail ed
desi gn

Code
Uni t tes t
Desi gn
V& V
Integr ati on
test
Accep tance
test
Serv ice
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL

34

O Modelo Espiral de Processo

de Software
o ciclo mais interno
est concentrado
nas possibilidades
do sistema
REVIEW
Requirements plan
Life-cycle plan

Risk
analysis Prototy pe 1
Concept o f
Operati on

35

O Modelo Espiral de Processo

de Software
o prximo ciclo est
concentrado na
definio dos
requisitos do
sistema

Risk
analys is
Prototype

Simul ati ons, models, benchmarks

SW
requi rements

Development
plan

Requi rement
validati on

36

O Modelo Espiral de Processo

de Software
Risk
analys is

o ciclo um pouco
mais externo est
concentrado no
projeto do sistema
Integrati on
and test plan

prototype 3

si mul ati ons, models, benchmarks

Product
desi gn

Desi gn
V&V

37

O Modelo Espiral de Processo

de Software
Risk
nalys is

um ciclo ainda mais

externo est
concentrado na
construo do
sistema

Operati onal
protoype

Simul ati ons, models, benchmarks

Detail ed
desi gn

Code
Uni t tes t
Integrati on
test
Acceptance
test
Serv ice
38

O Modelo Espiral (com 4 regies)

AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS

DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES

Risk
analys is

no existem fases fixas no modelo

as fases mostradas na figura so meramente
exemplos
a gerncia decide como estruturar o projeto
em fases
Risk
analys is

Risk
analys is

REVIEW

Requirements plan
Life-cycle plan

Develop ment
plan
Integrati on
and test p lan
PLANEJAR PRXIMA FASE

Prot otyp e 3

Prot otyp e 2
Risk
analysis Prot oty pe 1

Operati onal
protoyp e

Sim ul ati ons, m odels, b en ch marks

Concept o f
Operati on

S/W
requi rement s

Requi rement
valid ati on

Prod uct
desi gn

Detail ed
desi gn

Code
Uni t tes t
Desi gn
V& V
Integr ati on
test
Accep tance
test
Serv ice
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL

39

Cada loopEspiral
do espiral(com
dividido
O
Modelo
4 regies)em 4
setores
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS

DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES

Risk
analys is

ESTABELECIMENTO DE
OBJETIVOS
REVIEW
Requirements plan
Life-cycle plan

PLANEJAMENTO
Develop ment
plan
Integrati on
and test p lan
PLANEJAR PRXIMA FASE

Risk
analys is
Risk
analys is

AVALIAO E
REDUO DE
RISCOS OperaProt otyp e 3
ti onal
protoyp e

Prot otyp e 2
Risk
analysis Prot oty pe 1

Sim ul ati ons, m odels, b en ch marks

Concept o f
Operati on

S/W
requi rement s

Detail ed
desi gn

DESENVOLVIMENTO E
Code
VALIDAO
Uni t tes t

Requi rement
valid ati on
Desi gn
V& V

Prod uct
desi gn

Integr ati on
test
Accep tance
test
Serv ice
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL

40

O Modelo Espiral de Processo

de Software
so definidos objetivos

ESTABELECIMENTO DE
OBJETIVOS

especficos para a fase do projeto

so identificadas restries sobre
o processo e o produto
projetado um plano de
gerenciamento detalhado
so identificados riscos do
projeto
dependendo dos riscos,
estratgias alternativas podem
ser planejadas

41

O Modelo Espiral de Processo

de Software
para cada um dos riscos
identificados,
COLOCAO
DEuma anlise
detalhada executada.
OBJETIVOS
passos so tomados para reduzir o
risco

AVALIAO E
REDUO DE
RISCOS

42

O Modelo Espiral de Processo

de Software

ESTABELECIMENTO DE
OBJETIVOS

depois da avaliao do risco, um

modelo de desenvolvimento
escolhido para o sistema

AVALIAO E
REDUO DE
RISCOS

DESENVOLVIMENTO
E VALIDAO

43

O Modelo Espiral de Processo

de Software
AVALIAO E
COLOCAO DE
REDUO DE
OBJETIVOS
RISCOS
o projeto revisto e tomada
uma deciso de continuidade
se decidido continuar, so
projetados planos
para a prxima
DESENVOLVIMENTO
PLANEJAMENTO
fase do projeto (prximo
loop )
E VALIDAO

44

O Modelo Espiral
engloba as melhores caractersticas do ciclo de
vida Clssico e da Prototipao, adicionando um
novo elemento: a Anlise de Risco

segue a abordagem de passos sistemticos do
Ciclo de Vida Clssico incorporando-os numa
estrutura iterativa que reflete mais realisticamente
o mundo real

usa a Prototipao em todas as etapas da
evoluo do produto, como mecanismo de reduo
de riscos

45

Comentrios sobre o Ciclo de

Vida em Espiral

usa uma abordagem que capacita o

desenvolvedor e o cliente a entender e
reagir aos riscos em cada etapa evolutiva

pode ser difcil convencer os clientes que

uma abordagem "evolutiva" controlvel

46

Comentrios sobre o Ciclo de

Vida em Espiral

exige considervel experincia na

determinao de riscos e depende dessa
experincia para ter sucesso
o modelo relativamente novo e no tem
sido amplamente usado. Demorar muitos
anos at que a eficcia desse modelo possa
ser determinada com certeza absoluta

47

O Modelo Espiral

adiciona um novo elemento: a Anlise de Risco

usa a Prototipao, em qualquer etapa da

evoluo do produto, como mecanismo de reduo
de riscos

exige considervel experincia na determinao de

riscos e depende dessa experincia para ter
sucesso
48

O MODELO BASEADO EM
COMPONENTES

49

O Modelo Baseado em
Componentes

Utiliza tecnologias orientadas a objeto

Quando projetadas e implementadas
apropriadamente as classes orientadas a
objeto so reutilizveis em diferentes
aplicaes e arquiteturas de sistema
O modelo de montagem de componentes
incorpora muitas das caractersticas do
modelo espiral.

50

O Modelo de Montagem de
Componentes
Planejamento
Anlise de Riscos
Comunicao
com Cliente

Avaliao do Cliente
Engenharia
Construo e Liberao

51

O Modeloidentificar
de Montagem de
componentes
Componentes
candidatas
procurar Planejamento
Construir a na
componentes
iterao do
na biblioteca
sistema
extrair
Comunicao
componentes
com
Cliente

se disponveis

Anlise de Riscos

colocar os
novos
componentes
na biblioteca

construir os
componentes
no
Avaliao do Cliente
disponveis

Engenharia
Construo e Liberao

52

O Modelo Baseado em
Componentes

O modelo baseado em componentes conduz ao

reuso do software
a reusabilidade fornece uma srie de benefcios:

reduo de at 70% no tempo de desenvolvimento

reduo de at 84% no custo do projeto
ndice de produtividade de at 26.2 (normal da indstria de
16.9)

esses resultados dependem da robustez da biblioteca

de componentes

53

Processo Unificado da
Rational

54

O que o RUP?

O nome uma abreviao de Rational

Unified Process

mas na verdade

Processo + Mtodos + Linguagem (UML)

e os autores argumentam que

Framework para gerar processos

O que o RUP?

Conjunto de atividades

bem definidas
com responsveis
com artefatos de entrada e sada
com dependncias entre as mesmas e ordem de execuo
com modelo de ciclo de vida
descrio sistemtica de como devem ser realizadas
guias (de ferramentas ou no), templates
utilizando diagramas de UML

Caractersticas Principais do
RUP

O desenvolvimento de sistemas seguindo o

RUP

Iterativo e incremental
Guiado por casos de uso (use cases)
Baseado na arquitetura do sistema

O RUP iterativo e
incremental

O ciclo de vida de um sistema consiste de

quatro fases:
concepo

elaborao

construo

tempo






Concepo (define o escopo do projeto)

Elaborao (detalha os requisitos e a arquitetura)
Construo (desenvolve o sistema)
Transio (implanta o sistema)

transio

O RUP iterativo e
incremental

Cada fase dividida em iteraes:

Inception

Preliminary
iteration

Elaboration

Construction

Architect. Architect. Devel..

iteration iteration iteration

Devel..
iteration

Minor Milestones: Releases

Devel..
iteration

Transition

Transition
iteration

Transition
iteration

O RUP iterativo e
incremental

Cada iterao

planejada
realiza uma seqncia de atividades (de
elicitao de requisitos, anlise e projeto,
implementao, etc.) distintas
geralmente resulta em uma verso executvel do
sistema
avaliada segundo critrios de sucesso
previamente definidos

O RUP iterativo e incremental

Passos dentro de
uma iterao

Iterao e Workflow
Fases
Core Workflows

Concepo

Elaborao

Construo

Transio

Requisito

Uma iterao na
fase de Elaborao

Anlise

Desenho
Implementao
Teste

Iterao
Preliminar

ite r.
#1

ite r.
#2

ite r.
#n

ite r.
#n+1

ite r.
#n+2

ite r.
#m

ite r.
#m +1

O RUP guiado por casos de

uso

Os casos de uso no servem apenas para

definir os requisitos do sistema
Vrias atividades do RUP so guiadas pelos
casos de uso:

planejamento das iteraes

criao e validao do modelo de projeto
planejamento da integrao do sistema
definio dos casos de teste

O RUP baseado na
arquitetura do sistema

Arquitetura

viso geral do sistema em termos dos seus

subsistemas e como estes se relacionam

A arquitetura prototipada e definida logo

nas primeiras iteraes
O desenvolvimento consiste em
complementar a arquitetura
A arquitetura serve para definir a
organizao da equipe de desenvolvimento e
identificar oportunidades de reuso

Organizao do RUP

Fluxos de atividades
Atividades

passos
entradas e sadas
guias (de ferramentas ou no), templates

Responsveis (papel e perfil, no pessoa)

Artefatos

Exemplo de Fluxo:
Planejamento e Gerenciamento
Iniciar
Projeto

Aprovar
Projeto

Atestar
Concluso
do Projeto

Contratante

Identificar
Riscos
Estudar
Viabilidade

Desenvolve
r Plano de
Projeto
Gerente de
projeto

Arquiteto

Executar
Plano de
Iterao

Desenvolve
r Plano de
Iterao

Avaliar
Iterao
Reavaliar
Riscos

Priorizar
Casos de
Uso

Finalizar
Projeto

Resumo

O RUP :
iterativo e incremental
guiado por casos de uso
baseado na arquitetura do sistema
organizado em fases, iteraes, fluxos,
atividades e passos

Vamos Navegar pelo RUP

Entre no site:

http://www.wthreex.com/rup/portugues/index.htm

68

Mtodos geis

69

Novos ventos no mundo do

Desenvolvimento de Software

Sociedade demanda

grande quantidade de sistemas/aplicaes

software complexo, sistemas distribudos,
heterogneos
requisitos mutantes (todo ano, todo ms, todo dia)

Mas, infelizmente,
no h gente suficiente para
desenvolver tanto software com qualidade.

Problemas

Com metodologias de desenvolvimento

Supem que possvel prever o futuro

Pouca interao com os clientes
nfase em burocracias (documentos, formulrios,
processos, controles rgidos, etc.)
Avaliao do progresso baseado na evoluo da
burocracia e no do cdigo

Com software

Grande quantidade de erros

Falta de flexibilidade

Como resolver esse impasse?

Melhores Tecnologias

Padres de Projeto (reutilizao de idias)

Componentes (reutilizao de cdigo)
Middleware (aumenta a abstrao)

Melhores Metodologias

Mtodos geis
outras... (RUP, relacionadas a CMM, etc.)

Mtodos geis de
Desenvolvimento de Software

Movimento iniciado por programadores

experientes e consultores em desenvolvimento
de software.
Questionam e se ope a uma srie de
mitos/prticas adotadas em abordagens
tradicionais de Engenharia de Software e
Gerncia de Projetos.
Manifesto gil:
Assinado por 17 desenvolvedores em Utah em
fevereiro/2001.

O Manifesto do
Desenvolvimento gil de Software
1.

Indivduos e interaes so mais importantes

que processos e ferramentas.

2.

Software funcionando mais importante do

que documentao completa e detalhada.

3.

Colaborao com o cliente mais importante

do que negociao de contratos.

4.

Adaptao a mudanas mais importante do

que seguir o plano inicial.

Princpios do Manifesto gil

Objetivo: satisfazer o cliente entregando,

rapidamente e com freqncia, sistemas com
algum valor.

Entregar verses funcionais em prazos curtos.

Estar preparado para requisitos mutantes.

Pessoal de negcios e desenvolvedores juntos.

Troca de informaes atravs de conversas diretas.

75 / 69

Principais Mtodos geis

Crystal (uma famlia de mtodos)

Scrum
Programao eXtrema (XP)
Adaptive Software Development
Feature Driven Development
etc.

A famlia Crystal de Mtodos

Criada por Alistair Cockburn

http://alistair.cockburn.us/crystal
Editor da srie Agile Software Development da
Addison-Wesley.

Scrum
Definio informal:
Estratgia em um jogo de rugby onde
jogadores colocam uma bola quase perdida
novamente em jogo atravs de trabalho em
equipe.

Scrum

Scrum um esqueleto de processo que

contm grupos de prticas e papis prdefinidos. Os principais papis so:

ScrumMaster, que mantm os processos

(normalmente no lugar de um gerente de projeto);
Proprietrio do Produto, ou Product Owner, que
representa os stakeholders e o negcio;
a Equipe, ou Team, um grupo multifuncional com
cerca de 7 pessoas e que fazem a anlise,
projeto, implementao, teste etc.
79

Programao eXtrema

XP

Metodologia de desenvolvimento de software

aperfeioada nos ltimos 5 anos.

Ganhou notoriedade a partir da

OOPSLA2000.

Nome principal: Kent Beck

Tambm importante: Ward Cunningham

A Quem se Destina os
Mtodos geis

Grupos de 2 a 10 programadores
Projetos de 1 a 36 meses (calendrio)
De 1000 a 250 000 linhas de cdigo

Caractersticas Comuns dos

Mtodos geis

Coloca o foco

Na entrega freqente de sub-verses do software

[funcionando] para o cliente.
Nos seres humanos que desenvolvem o software.

Retira o foco de

Processos rgidos e burocratizados.

Documentaes e contratos detalhados.
Ferramentas que so usadas pelos seres humanos.

Para escolha de um Modelo de

Processo de Software:

natureza do projeto e da aplicao

mtodos e ferramentas a serem usados

controles e produtos que precisam ser

entregues

83

Exerccio

Voc e mais 4 scios resolveram criar uma empresa de

desenvolvimento de Software e voc ficou responsvel por definir
algumas reas da empresa. Cada questo abaixo ser a sua parte
para a criao desta empresa.
1) Defina uma abordagem para o desenvolvimento de software que compreenda os
benefcios dos modelos de desenvolvimento clssicos (Cascata, prototipao e
Espiral). Inclua as caractersticas de outros modelos se achar necessrios.
2) Defina uma abordagem para fazer a analise da viabilidade de sistemas a serem
desenvolvidos. Esta abordagem consiste de uma relao das atividades em ordem
cronolgica para analisar a viabilidade de qualquer sistema que for desenvolvido
pela empresa.
3) O seu primeiro sistema a ser desenvolvido pela nova empresa de
desenvolvimento de software ser para a Farmcia Pague Pouco. Eles querem
informatizar o sistema de vendas e controle de estoque, desejam armazenar a
seguinte informao: qual vendedor vendeu qual produto para qual cliente. Relate,
de acordo com o modelo de software criado na primeira questo e com a abordagem
de analise da segunda, quais a as atividades devero ser realizadas para o
84
desenvolvimento do sistema da Farmcia Pague Pouco.