Prof Andrea Padovan Jubileu

MODELOS DE PROCESSO MODELOS DE PROCESSO

DE SOFTWARE DE SOFTWARE
Definio e Elementos de Processo de Software
Alguns Modelos Prescritivos
Alguns Modelos geis
Viso Genrica do Desenvolvimento de Software 2
Modelos de Processo de Software Modelos de Processo de Software
Procuram descrever formalmente e de maneira organizada
todas as atividades que devem ser seguidas para a obteno
segura de um produto de software
A escolha do modelo de processo de software depende:
da natureza do projeto e da aplicao
dos mtodos e ferramentas a serem usados
dos controles e produtos que precisam ser entregues
Existem vrios modelos de processo de software (ou
paradigmas de engenharia de software ou modelos de ciclo de
vida)
Cada um representa uma tentativa de colocar ordem em uma
atividade inerentemente catica
3
Modelos de Processo de Software Modelos de Processo de Software
Alguns Modelos de Processos Prescritivos
Tradicionais
Modelo Seqencial Linear (Modelo Cascata)
Paradigma de Prototipao
Modelo Incremental
Modelo Espiral
4
Modelo Cascata Modelo Cascata (1/9) (1/9)
modelo mais antigo e o mais amplamente usado da
engenharia de software
requer uma abordagem sistemtica, seqencial ao
desenvolvimento de software
enfoque desse modelo nos documentos e nos artefatos
5
Modelo Cascata Modelo Cascata (2/9) (2/9)
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
6
Modelo Cascata Modelo Cascata (3/9) (3/9)
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
Engenharia de
Sistemas
Engenharia de Sistemas
coleta de requisitos em nvel de sistema
7
Modelo Cascata Modelo Cascata (4/9) (4/9)
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
Anlise de
Requisitos
Anlise de Requisitos de
Software
coleta dos requisitos
concentrado especificamente no
software
os requisitos (para o sistema e
para o software) so documentados
e revistos com o cliente
8
Modelo Cascata Modelo Cascata (5/9) (5/9)
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
Projeto
Projeto Projeto
traduo dos requisitos
do software para um
conjunto de representaes
que podem ser avaliadas
quanto qualidade, antes
que a codificao se inicie
Estrutura de Dados
Arquitetura de Software
Detalhes Procedimentais e
Caracterizao de
Interfaces
9
Modelo Cascata Modelo Cascata (6/9) (6/9)
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
Codificao
Codificao Codificao
traduo das
representaes do
projeto em instrues
executveis pelo
computador
10
Modelo Cascata Modelo Cascata (7/9) (7/9)
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
Testes
Testes Testes
Concentra-se:
nos aspectos lgicos internos do
software garantia que todas as
instrues tenham sido testadas
nos aspectos funcionais externos
do software garantia que a
entrada definida produza resultados
que concordem com os esperados
11
Modelo Cascata Modelo Cascata (8/9) (8/9)
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno Manuteno
Manuteno Manuteno
provavelmente o software dever sofrer
mudanas depois que for entregue ao cliente
causas das mudanas
erros Manut. Corretiva
adaptao do software Manut.
Adaptativa
acrscimos funcionais e de desempenho
Manut. Evolutiva
melhoria da manutenibilidade Manut.
Preditiva
12
Problemas com o Modelo Cascata Problemas com o Modelo Cascata (9/9) (9/9)
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
13
Modelo de Prototipao Modelo de Prototipao (1/9) (1/9)
Objetivo: entender os requisitos do usurio
possibilita que o desenvolvedor crie um modelo
(prottipo)do software que deve ser construdo
apropriado quando o cliente definiu um conjunto
de objetivos gerais para o software, mas no
identificou detalhadamente esses requisitos
14
Modelo de Prototipao Modelo de Prototipao (2/9) (2/9)
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
15
Modelo de Prototipao Modelo de Prototipao (3/9) (3/9)
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
Obter Requisitos Obter Requisitos
Desenvolvedor e cliente:
definem os objetivos gerais do software
identificam quais requisitos so conhecidos
identificam as reas que necessitam de definies
adicionais
16
Modelo de Prototipao Modelo de Prototipao (4/9) (4/9)
Obter Requisitos
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo
Elaborar Projeto Rpido Elaborar Projeto Rpido
Representao dos aspectos do software que so
visveis ao usurio
abordagens de entrada e
formatos de sada
17
Modelo de Prototipao Modelo de Prototipao (5/9) (5/9)
Avaliar Prottipo
Refinamento do Prottipo
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo Construir Prottipo
Implementao rpida do
projeto
18
Modelo de Prototipao Modelo de Prototipao (6/9) (6/9)
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Refinamento do Prottipo
Avaliar Prottipo Avaliar Prottipo
Cliente e desenvolvedor
avaliam o prottipo
19
Modelo de Prototipao Modelo de Prototipao (7/9) (7/9)
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
Refinamento do Prottipo Refinamento do Prottipo
Cliente e desenvolvedor refinam os
requisitos do software a ser desenvolvido
20
Modelo de Prototipao Modelo de Prototipao (8/9) (8/9)
Obter Requisitos
Elaborar Projeto Rpido
Construir Prottipo
Avaliar Prottipo
CONSTRUO DO CONSTRUO DO
PRODUTO PRODUTO
Identificados os requisitos, o prottipo deve
ser descartado e a verso de produo deve
ser construda considerando os critrios de
qualidade
21
Problemas Problemas com a Prototipao com a Prototipao (9/9) (9/9)
a qualidade global e a manutenibilidade ao longo do
desenvolvimento no foram consideradas
utiliza-se o que h disponvel na implementao com o
objetivo de produzir rapidamente um prottipo
implementao comprometida
Ainda que possam ocorrer problemas, a prototipao
um ciclo de vida eficiente
Chave definir as regras do jogo logo no comeo
Acordo entre cliente e desenvolvedor o prottipo construdo
para servir como um mecanismo a fim de definir os requisitos
22
Modelo Incremental Modelo Incremental (1/4) (1/4)
Tem os benefcios do modelo cascata e da
prototipao
Idia bsica: desenvolvimento (projeto,
codificao e teste) incremental do software
Priorizao das funcionalidades principais do
software
23
Modelo Incremental Modelo Incremental (2/4) (2/4)
Definir escopo
do requisitos
Priorizar
requisitos
(incrementos)
Projetar
Arquitetura
Desenvolver
incremento
Integrar
incremento
Verificar e
Validar
incremento
Validar
software
Verses
Verso Final
24
Modelo Incremental Modelo Incremental (3/4) (3/4)
Definir escopo
do requisitos
Priorizar
requisitos
(incrementos)
Projetar
Arquitetura
Desenvolver
incremento
Integrar
incremento
Verificar e
Validar
incremento
Validar
software
Verses
Verso Final
Um plano desenvolvido para o prximo
incremento, como resultado do uso e/ou
avaliao por parte do cliente
25
Modelo Incremental Modelo Incremental (4/4) (4/4)
Os clientes no precisam esperar que a verso final do
software seja entregue para us-lo
Os clientes podem utilizar os primeiros incrementos
desenvolvidos como um prottipo, de forma a definir
melhor alguns requisitos do software
Existe um risco menor de fracasso do software
Como as funes prioritrias so entregues primeiro,
inevitvel que estas passem por um perodo de testes
mais intensivo
26
Modelo Espiral Modelo Espiral (1/11) (1/11)
Engloba as melhores caractersticas do modelo cascata e
da prototipao, adicionando um novo elemento: a
Anlise de Risco
Usa a prototipao, em qualquer etapa da evoluo do
produto, como mecanismo de reduo de riscos
O modelo espiral dividido em uma srie de atividades
de trabalho ou regies de tarefa
Existem tipicamente de 3 a 6 regies de tarefa
27
Modelo Espiral Modelo Espiral (com 4 regies) (com 4 regies) (2/11) (2/11)
DETERMINAROBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMAFASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTONOPRXIMONVEL
Oramento1 Oramento2 Oramento3 Oramento4
Alternativas1
Restries1
Alternativas2
Alternativas3
Alternativas4
Restries2
Restries3
Restries4
Concepo
da
Operao
Prottipo2 Prottipo3 Prottipo4
Anlise
de
Riscos1
Anlise de
Riscos 2
Anlise de
Riscos 3
Anlise de
Riscos 4
Protti-
po1
Validaode
requisitos
Requisitos de
Software
Projeto verificado
e validado
Projeto de
Software
Projeto
Detalhado
Cdigo
Testes de
Unidades
Teste do
Sistema
Teste de
aceitao
Plano de
Implementao
Plano de testes
e de integrao
Plano de
Desenvolvimento
Plano de Requisitos
Plano do ciclo de vida
28
Modelo Espiral Modelo Espiral (com 4 regies) (com 4 regies) (3/11) (3/11)
DETERMINAROBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMAFASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTONOPRXIMONVEL
Oramento1 Oramento2 Oramento3 Oramento4
Alternativas1
Restries1
Alternativas2
Alternativas3
Alternativas4
Restries2
Restries3
Restries4
Concepo
da
Operao
Prottipo2 Prottipo3 Prottipo4
Anlise
de
Riscos1
Anlise de
Riscos 2
Anlise de
Riscos 3
Anlise de
Riscos 4
Protti-
po1
Validaode
requisitos
Requisitos de
Software
Projeto verificado
e validado
Projeto de
Software
Projeto
Detalhado
Cdigo
Testes de
Unidades
Teste do
Sistema
Teste de
aceitao
Plano de
Implementao
Plano de testes
e de integrao
Plano de
Desenvolvimento
Plano de Requisitos
Plano do ciclo de vida
Cada loop no
espiral representa
uma fase do
processo de
software
29
Modelo Espiral Modelo Espiral (com 4 regies) (com 4 regies) (4/11) (4/11)
Oramento1
Alternativas1
Restries1
Concepo
da
Operao
Anlise
de
Riscos1
Plano de Requisitos
Plano do ciclo de vida
O loop mais
interno est
concentrado na
viabilidade do
software
DETERMINAROBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMAFASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTONOPRXIMONVEL
30
Modelo Espiral Modelo Espiral (com 4 regies) (com 4 regies) (5/11) (5/11)
Oramento2
Alternativas2
Prottipo2
Anlise de
Riscos 2
Validaode
requisitos
Requisitos de
Software
Plano de
Desenvolvimento
O prximo loop
est concentrado na
definio dos
requisitos do
software
DETERMINAROBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMAFASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTONOPRXIMONVEL
31
Modelo Espiral Modelo Espiral (com 4 regies) (com 4 regies) (6/11) (6/11)
PLANEJAR PRXIMAFASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTONOPRXIMONVEL
Prottipo3
Anlise de
Riscos 3
Projeto verificado
e validado
Projeto de
Software
Plano de testes
e de integrao
O loop um pouco
mais externo est
concentrado no
projeto do software
DETERMINAROBJETIVOS,
ALTERNATIVAS E
RESTRIES
32
Modelo Espiral Modelo Espiral (com 4 regies) (com 4 regies) (7/11) (7/11)
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTONOPRXIMONVEL
Prottipo
Operacional
Anlise de
Riscos 4
Projeto
Detalhado
Cdigo
Testes de
Unidades
Teste do
Sistema
Teste de
aceitao
Plano de
Implementao
Um loop ainda
mais externo est
concentrado na
construo do
software
DETERMINAROBJETIVOS,
ALTERNATIVAS E
RESTRIES
PLANEJAR PRXIMAFASE
33
DESENVOLVER, VERIFICAR O
PRODUTONOPRXIMONVEL
no existem fases fixas no modelo
as fases mostradas na figura so meramente
exemplos
a gerncia decide como estruturar o projeto
em fases
Modelo Espiral Modelo Espiral (com 4 regies) (com 4 regies) (8/11) (8/11)
34
Planejamento
Anlise de Riscos
Engenharia
Construo e Liberao
Avaliao do Cliente
Comunicao
com Cliente
Modelo Espiral Modelo Espiral (com 6 regies) (com 6 regies) (10/11) (10/11)
As tarefas das regies so
adaptadas s
caractersticas do projeto
35
Comentrios sobre o Ciclo de Vida Comentrios sobre o Ciclo de Vida
em Espiral em Espiral (11/11) (11/11)
Exige considervel experincia na determinao
de riscos e depende dessa experincia para ter
sucesso
Possibilita ao desenvolvedor e ao cliente
entender e reagir aos riscos em cada etapa
evolutiva
36
Modelos de Processo de Software Modelos de Processo de Software
Modelos de Processos Prescritivos
Visam assegurar a aderncia s normas e padres
estabelecidos
Processos com forte nfase em controles e
documentaes
Voltados para equipes grandes e/ou dispersas
Em geral, especificam vrias atividades alm do
desenvolvimento de software
Buscam satisfazer o maior nmero possvel de
contextos, para serem usados como o nico processo
Atendem a muitas exigncias do CMMI e ISO
Geralmente so personalizados para cada projeto
e/ou empresa
37
Modelos de Processo de Software Modelos de Processo de Software
Alguns Modelos de Processos Prescritivos
Unified Process (UP/RUP) e suas instanciaes (EUP
Enterprise Unified Process)
MSF (Microsoft Solutions Framework)
ICONIX
CATALISYS
OPEN (Object-oriented Process, Environment and
Notation)
38
UP UP (1/7) (1/7)
UP RUP sem o copyrighted de produto Rational Unified
Process
O UP baseia-se em trs princpios:
direcionado por Use Cases
Cada uma das interaes dos diferentes tipos de usurio (atores)
com o sistema chamada Use Case
centrado em Arquitetura
A Arquitetura de um sistema refere-se s diferentes vises que
compem a soluo completa (abstraes)
Iterativo e Incremental
Projeto para desenvolvimento de sistema deve ser quebrado em
mini-projetos, chamados Iteraes
39
UP UP (2/7) (2/7)
40
UP UP
Uma iterao uma seqncia completa de disciplinas (workflow).
O resultado de uma iterao um artefato ou uma srie de artefatos.
Um artefato pode ser um cdigo-fonte, um modelo, etc.
Uma vez que os artefatos para uma fase especfica foram completados
ocorre a passagem para a prxima fase.
41
UP UP (4/7) (4/7)
Define-se o escopo do projeto
Avalia-se a tecnologia
Relaciona-se os riscos principais
Detecta-se reas mais crticas a
serem tratadas
Verifica-se a viabilidade do projeto
42
UP UP (5/7) (5/7)
Especifica-se os requisitos em
detalhes
Identifica-se e avalia-se a
arquitetura do software
43
UP UP (6/7) (6/7)
Constri-se o produto
Testa-se as verses beta do
produto
44
UP UP (8/7) (8/7)
Testa-se a verso do produto para
entrega ao cliente
Implanta-se o sistema
45
EUP EUP Enterprise Unified Process Enterprise Unified Process (1/2) (1/2)
Extenso do RUP
Essa extenso inclui:
Duas novas fases:
Produo: apoio na operao e suporte
Retirada: retirar o sistema em operao. A troca de sistema
legados por novos sistemas deve ter impacto mnimo nas
operaes de negcio
Novas disciplinas:
Modelagem do Negcio da Empresa, Gesto de Portflio,
Arquitetura Empresarial, Reuso Estratgico, Gesto de
Pessoas, Administrao Empresarial, Melhoria do Processo
de Software
46
EUP EUP (2/2) (2/2)
47
Modelos de Processo de Software Modelos de Processo de Software
Modelos de Processos geis
Agilidade a habilidade tanto para criar quanto para responder
mudana, de forma a obter lucro em um ambiente turbulento
de negcios
Visam diminuir a quantidade de documentao
Tm o foco nas pessoas e suas interaes
Alguns Modelos de Processos geis
XP (Extreme Programming), SCRUM
AUP, Famlia CRYSTAL
FDD (Feature-Driven Development)
DSDM (Dynamic Systems Development Method)
ASD (Adaptive Software Development) 48
XP XP Extreme Programming Extreme Programming (1/5) (1/5)
Criada por Kent Beck e Ward Cunningham em 1999
Segundo Beck (1999), representa uma disciplina e no
um mtodo de desenvolvimento de software
XP baseia-se em regras que devem ser usadas todo tempo e no
em uma seqncia de procedimentos estticos
Voltada para equipes de at 10 integrantes engajados no
desenvolvimento de software cujos requisitos so vagos
ou se encontram em constante mudana
49
XP XP Extreme Programming Extreme Programming (2/5) (2/5)
XP define um conjunto de doze prticas escolhidas com base em quatro
valores que so: comunicao, simplicidade, feedback e coragem.
Jogo do Planejamento (The Planning Game). Determina
rapidamente o escopo das prximas verses, combinando as
prioridades de negcio e as estimativas tcnicas
Pequenas Verses (Small releases). A equipe deve colocar
rapidamente um sistema simples em produo, uma verso pequena,
e depois entregar novas verses em poucos dias ou poucas
semanas
Metfora (Metaphor). Uma metfora uma descrio simples de
como o sistema funciona. Serve como uma linguagem comum entre
cliente e desenvolvedores, facilitando a compreenso do sistema que
est sendo desenvolvido
Projeto simples (Simple design). O sistema deve ser projetado o
mais simples possvel. Complexidade extra removida assim que
descoberta
50
XP XP Extreme Programming Extreme Programming (3/5) (3/5)
Testes (Testing). Os programadores escrevem testes de unidade
continuamente. Esses testes so criados antes do cdigo e devem
ser executados perfeitamente para que o desenvolvimento continue.
Os clientes tambm escrevem testes para validar se as funes
esto finalizadas
Refatorao (Refactoring). Os programadores reestruturam o
sistema durante todo o desenvolvimento, sem modificar seu
comportamento externo. Isso feito para simplificar o sistema,
adicionar flexibilidade ou melhorar o cdigo
Programao pareada (Pair programming). Todo cdigo produzido
feito em pares, duas pessoas trabalhando em conjunto na mesma
mquina
Propriedade coletiva (Collective ownership). Qualquer um pode
alterar qualquer cdigo em qualquer momento, o cdigo de
propriedade coletiva
51
XP XP Extreme Programming Extreme Programming (4/5) (4/5)
Integrao contnua (Continuous integration). Uma nova parte do
cdigo deve ser integrada assim que estiver pronta.
Conseqentemente, o sistema integrado e construdo vrias vezes
ao dia
Semana de 40 horas (40-hour week). XP defende um ritmo de
trabalho que possa ser mantido, sem prejudicar o bem estar da
equipe. Trabalho alm do horrio normal pode ser necessrio, mas
fazer horas extras por perodos maiores que uma semana sinal de
que algo est errado com o projeto
Cliente junto aos desenvolvedores (On-site customer). Os
desenvolvedores devem ter o cliente disponvel todo o tempo, para
que ele possa responder s dvidas que os desenvolvedores
possam ter
Padronizao do Cdigo (Coding standards). Os programadores
escrevem o cdigo seguindo regras comuns enfatizando a
comunicao por meio do cdigo
52
XP XP Extreme Programming Extreme Programming (5/5) (5/5)
uma codificao para reduzir o risco de um problema
tecnolgico ou aumentar a confiabilidade da estimativa
da user storie.
53
SCRUM SCRUM (1/5) (1/5)
Objetivo: fornecer um processo conveniente para
projetos e desenvolvimento orientado a objetos
A metodologia baseada em princpios semelhantes
aos de XP:
equipes pequenas
requisitos pouco estveis ou desconhecidos
iteraes curtas para promover visibilidade para o
desenvolvimento
Scrum e XP Scrum e XP so complementares
Scrum prov prticas geis de gerenciamento
XP prov prticas integradas de engenharia de software
54
SCRUM SCRUM (2/5) (2/5)
O processo do SCRUM inclui as seguintes fases:
1) Pr-Desenvolvimento (Pre-Game)
Planejamento: criar condies mnimas para o incio do projeto
Definio da equipe
Definio de ferramentas e infra-estrutura
Anlise de riscos
Aprovao gerencial
Criao de um product backlog com todos os requisitos
conhecidos no momento
Definio da entrega das verses e das datas para
realizao das tarefas
Modelagem de alto nvel: criar um modelo de alto nvel
incluindo a arquitetura do projeto, que atenda as requisitos
definidos no backlog, at ento
55
SCRUM SCRUM (3/5) (3/5)
O processo do SCRUM inclui as seguintes fases:
2) Desenvolvimento (Game) - parte gil
Ocorre por meio de uma srie de sprints (30 dias)
Durante um sprint a equipe se organiza para produzir um
incremento do produto
Sprint: inclui as fases tradicionais do desenvolvimento de
software - anlise, projeto, implementao, testes e entrega
A arquitetura, modelos, documentos e backlog evoluem
atravs de constantes modificaes e adaptaes
Backlog: lista de atividades, priorizadas e estimadas
Product Backlog : contm o trabalho de todo o projeto
Sprint Backlog: especfico para cada iterao (subconjunto
do product backlog a ser realizado durante a iterao)
56
SCRUM SCRUM (4/5) (4/5)
24h
30 dias
sprint
Acmulo de tarefas
pela equipe
Novo incremento
Reunio diria do Scrum
(15 min)
Quais atividades realizadas
desde a ltima reunio?
Quais problemas foram
enfrentados?
Quais atividades sero
realizadas at a prxima
reunio?
Sprint Backlog
Controle e
planejamento
Product Backlog
Realiza-se uma
priorizao
57
SCRUM SCRUM (5/5) (5/5)
O processo do SCRUM inclui as seguintes fases:
3) Ps-Desenvolvimento (Post-Game)
Preparao para a entrega do resultado final
Atividades:
Testes de integrao
Testes de sistema
Documentao do usurio
Preparao de material de treinamento
Preparao de material de marketing
58
AUP AUP (1/2) (1/2)
Verso simplificado do RUP
Abordagem que utiliza tcnicas e conceitos geis
As tcnicas geis utilizadas so:
Test Driven Development (TDD)
Agile Model Driven Development (AMDD)
Agile change management
Database refactoring
A disciplina Modelo engloba as disciplinas Modelagem de Negcios,
Requisitos e Anlise e Projeto do RUP
A disciplina de Gesto de Mudana e Configurao tornou-se a
disciplina Gesto de Configurao
no desenvolvimento gil as atividades de gesto de mudana fazem
parte dos esforos de gesto dos requisitos (que faz parte da disciplina
Modelo)
59
AUP AUP (2/2) (2/2)
60
Bibliografia Bibliografia
SANCHES, ROSELY. Material Didtico: Engenharia de Software. ICMC-USP, 2005.
PRESSMAN, ROGER S. Engenharia de Software. 5 edio. Rio de Janeiro:
McGraw-Hill, 2002.
SOMERVILLE, IAN. Engenharia de Software. 6 edio. So Paulo: Addison Wesley,
2003.
DON WELLS. Extreme Programming: A gentle introduction. Disponvel em:
<http://www.extremeprogramming.org/index.html>. Acessado em: 07 abr 2006.
Control Chaos. SCRUM. Disponvel em: <http://www.controlchaos.com/>. Acessado
em: 07 abr 2006.
X-tier SAE Inc. Using RUP/UP: 10 Easy Steps. Disponvel em: <www.x-
tier.com/public/RUPUPIn10EasySteps.doc>. Acessado em: 07 abr 2006.
AMBLER, Scott W. Agile Modeling and the Rational Unified Process (RUP).
Disponvel em: <http://www.agilemodeling.com/essays/agileModelingRUP.htm>.
Acessado em: 07 abr 2006.