Modelos de Processo

de Software
Ricardo Argenton Ramos
ricargentonramos@gmail.com
Engenharia de Software I 2012.2
2
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
3
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]
4
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
Processo Unificado
O Modelo Seqencial Linear
(tambm chamado Ciclo de Vida Clssico ou
Modelo Cascata)
O Paradigma de
Prototipao
O Modelo Espiral O Modelo
Baseado em
Componentes
O Modelo Seqencial Linear
(tambm chamado Ciclo de Vida
Clssico ou Modelo Cascata)
6
7
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
8
O Modelo em Cascata
Explorao de
conceitos
Requisitos
Projeto
Implementao
Testes
Instalao e
liberao
Feedback
Evoluir Evoluir Evoluir Evoluir
Manuteno e
operao
O qu
Como
Operao
Verificar Plano
Requisitos de V & V
Projeto de V & V
Sistema de V & V
Tarefas de V & V
Sistema
de V & V
Operao
de V & V
9
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
O Modelo em Cascata
Explorao de Conceitos / Informao e
Modelagem
Envolve a elicitao de requisitos do sistema, com uma pequena
quantidade de projeto e anlise de alto nvel;
Preocupa-se com aquilo que conhecemos como engenharia
progressiva de produto de software;
Iniciar com um modelo conceitual de alto nvel para um sistema e
prosseguir com o projeto, implementao e teste do modelo fsico do
sistema.
10
O Modelo em Cascata
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
Anlise de Requisitos de Software
o processo de elicitao dos requisitos
intensificado e concentrado especificamente no
software
deve-se compreender o domnio da informao, a
funo, desempenho e interfaces exigidos
os requisitos (para o sistema e para o software) so
documentados e revistos com o cliente
11
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
12
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.
13
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.
14
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
15
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).
16
Embora o Modelo em Cascata
tenha fragilidades, ele
significativamente melhor do
que uma abordagem casual de
desenvolvimento de software.
17
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;
O Paradigma de Prototipao
18
19
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.
20
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
21
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
1- OBTENO DOS REQUISITOS:
desenvolvedor e cliente definem os
objetivos gerais do software,
identificam quais requisitos so
conhecidos e as reas que necessitam
de definies adicionais.
22
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
2- PROJETO RPIDO:
representao dos aspectos do
software que so visveis ao usurio
(abordagens de entrada e formatos
de sada)
23
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
3- CONSTRUO DO PROTTIPO:
implementao rpida do
projeto
24
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
4- AVALIAO DO PROTTIPO: cliente e
desenvolvedor avaliam o prottipo
25
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
5- REFINAMENTO DO PROTTIPO: cliente e
desenvolvedor refinam os requisitos do
software a ser desenvolvido.
26
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
CONSTRUO
DO PRODUTO
27
O Paradigma de Prototipao
para obteno dos requisitos
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
CONSTRUO
DO PRODUTO
6- CONSTRUO PRODUTO:
identificados os requisitos, o
prottipo deve ser descartado e a
verso de produo deve ser
construda considerando os
critrios de qualidade.
28
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
29
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
Exerccio
Vamos refazer o exerccio da primeira aula,
agora utilizando a Prototipao para construir
o Projeto.
30
Obter Requisitos
Elaborar Projeto
Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do
Prottipo
O Modelo Espiral
31
32
O Modelo Espiral
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);
(Boehm, 1986)
33
O Modelo Espiral (com 4 regies)
Risk
analys is
Risk
analys is
Risk
analys is
Risk
analysis
Prot o-
type 1
Prot otype 2
Prot otype 3
Opera-
ti onal
prot oype
Concept of
Operati on
Simul ati ons, models, benchmarks
S/W
requi rement s
Requi rement
validati on
Desi gn
V&V
Product
desi gn
Detail ed
desi gn
Code
Uni t t es t
Integr ati on
test
Acceptance
test
Service
Integrati on
and t est plan
Development
pl an
Requi rement s pl an
Li fe-cycle pl an
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL
34
O Modelo Espiral (com 4 regies)
Risk
analys is
Risk
analys is
Risk
analys is
Risk
analysis
Prot o-
type 1
Prot otype 2
Prot otype 3
Opera-
ti onal
prot oype
Concept of
Operati on
Simul ati ons, models, benchmarks
S/W
requi rement s
Requi rement
validati on
Desi gn
V&V
Product
desi gn
Detail ed
desi gn
Code
Uni t t es t
Integr ati on
test
Acceptance
test
Service
Integrati on
and t est plan
Development
pl an
Requi rement s pl an
Li fe-cycle pl an
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL
cada ciclo na espiral
representa uma
fase do processo de
software
35
O Modelo Espiral de Processo
de Software
Risk
analysis
Proto-
type 1
Concept of
Operati on
Requi rements pl an
Li fe-cycle pl an
REVIEW
o ciclo mais interno
est concentrado
nas possibilidades
do sistema
36
O Modelo Espiral de Processo
de Software
Risk
analys is
Prototype
Simul ati ons, models, benchmarks
SW
requi rements
Requi rement
validati on
Development
pl an
o prximo ciclo est
concentrado na
definio dos
requisitos do
sistema
37
O Modelo Espiral de Processo
de Software
Risk
analys is
prototype 3
si mul ati ons, models, benchmarks
Desi gn
V&V
Product
desi gn
Integrati on
and test plan
o ciclo um pouco
mais externo est
concentrado no
projeto do sistema
38
O Modelo Espiral de Processo
de Software
Risk
nalys is
Opera-
ti onal
protoype
Simul ati ons, models, benchmarks
Detail ed
desi gn
Code
Uni t tes t
Integrati on
test
Acceptance
test
Service
um ciclo ainda mais
externo est
concentrado na
construo do
sistema
39
Risk
analys is
Risk
analys is
Risk
analys is
Risk
analysis
Prot o-
type 1
Prot otype 2
Prot otype 3
Opera-
ti onal
prot oype
Concept of
Operati on
Simul ati ons, models, benchmarks
S/W
requi rement s
Requi rement
validati on
Desi gn
V&V
Product
desi gn
Detail ed
desi gn
Code
Uni t t es t
Integr ati on
test
Acceptance
test
Service
Integrati on
and t est plan
Development
pl an
Requi rement s pl an
Li fe-cycle pl an
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL
no existem fases fixas no modelo
as fases mostradas na figura so meramente
exemplos
a gerncia decide como estruturar o projeto
em fases
O Modelo Espiral (com 4 regies)
40
O Modelo Espiral (com 4 regies)
Risk
analys is
Risk
analys is
Risk
analys is
Risk
analysis
Prot o-
type 1
Prot otype 2
Prot otype 3
Opera-
ti onal
prot oype
Concept of
Operati on
Simul ati ons, models, benchmarks
S/W
requi rement s
Requi rement
validati on
Desi gn
V&V
Product
desi gn
Detail ed
desi gn
Code
Uni t t es t
Integr ati on
test
Acceptance
test
Service
Integrati on
and t est plan
Development
pl an
Requi rement s pl an
Li fe-cycle pl an
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL
ESTABELECIMENTO DE
OBJETIVOS
AVALIAO E
REDUO DE
RISCOS
Cada loop do espiral dividido em 4
setores
DESENVOLVIMENTO E
VALIDAO
PLANEJAMENTO
41
O Modelo Espiral de Processo
de Software
ESTABELECIMENTO DE
OBJETIVOS
so definidos 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
42
O Modelo Espiral de Processo
de Software
AVALIAO E
REDUO DE
RISCOS
COLOCAO DE
OBJETIVOS
para cada um dos riscos
identificados, uma anlise
detalhada executada.
passos so tomados para reduzir o
risco
43
O Modelo Espiral de Processo
de Software
AVALIAO E
REDUO DE
RISCOS
ESTABELECIMENTO DE
OBJETIVOS
depois da avaliao do risco, um
modelo de desenvolvimento
escolhido para o sistema
DESENVOLVIMENTO
E VALIDAO
44
O Modelo Espiral de Processo
de Software
AVALIAO E
REDUO DE
RISCOS
COLOCAO DE
OBJETIVOS
DESENVOLVIMENTO
E VALIDAO
PLANEJAMENTO
o projeto revisto e tomada
uma deciso de continuidade
se decidido continuar, so
projetados planos para a prxima
fase do projeto (prximo loop )
45
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
46
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
47
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
48
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
O MODELO BASEADO EM
COMPONENTES
49
50
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.
51
O Modelo de Montagem de
Componentes
Planejamento
Anlise de Riscos
Avaliao do Cliente
Comunicao
com Cliente
Engenharia
Construo e Liberao
52
O Modelo de Montagem de
Componentes
Planejamento
Anlise de Riscos
Avaliao do Cliente
Comunicao
com Cliente
Engenharia
Construo e Liberao
identificar
componentes
candidatas
procurar
componentes
na biblioteca
extrair
componentes
se disponveis
construir os
componentes
no
disponveis
colocar os
novos
componentes
na biblioteca
Construir a n
a
iterao do
sistema
53
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
O Modelo Baseado em
Componentes
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 (define o escopo do projeto)
Elaborao (detalha os requisitos e a arquitetura)
Construo (desenvolve o sistema)
Transio (implanta o sistema)
tempo
concepo
elaborao construo transio
O RUP iterativo e
incremental
Cada fase dividida em iteraes:
Minor Milestones: Releases
Inception Elaboration Construction
Transition
Transition
iteration
Preliminary
iteration
Architect.
iteration
Architect.
iteration
Devel..
iteration
Devel..
iteration
Devel..
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
Iterao e Workflow
Core Workflows
Requisito
Anlise
Desenho
Implemen-
tao
Teste
Fases
iter.
#1
iter.
#2
iter.
#n
iter.
#n+1
ite r.
#n+2
it er.
#m
iter.
#m+1
Iterao
Preliminar
Uma iterao na
fase de Elaborao
Concepo Elaborao
Transio Construo
Passos dentro de
uma iterao
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
Gerente de
projeto
Arquiteto
Contratante
Iniciar
Projeto
Aprovar
Projeto
Estudar
Viabilidade
Atestar
Concluso
do Projeto
Identificar
Riscos
Desenvolve
r Plano de
Projeto
Desenvolve
r Plano de
Iterao
Executar
Plano de
Iterao
Avaliar
Iterao
Finalizar
Projeto
Reavaliar
Riscos
Priorizar
Casos de
Uso
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.
75 / 69
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.
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 pr-
definidos. 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.
83
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
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
desenvolvimento do sistema da Farmcia Pague Pouco.
84