Metodologia de Sistemas

METODOLOGIAS DE
DESENVOLVIMENTO DE
SISTEMAS
autor
ANDR LUS BELMIRO MOREIRA RAMOS
1 edio
SESES
rio de janeiro 2017
Conselho editorial roberto paes eluciana varga
Autor do original andr lus belmiro moreira ramos
Projeto editorial roberto paes
Coordenao de produo luciana varga, paula r. de a. machado e aline karina

rabello
Projeto grfico paulo vitor bastos
Diagramao bfs media
Reviso lingustica bfs media
Reviso de contedo luiz roberto martins bastos
Imagem de capa shaiith|shutterstock.com
Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2017.
Dados Internacionais de Catalogao na Publicao (cip)
R175m Ramos, Andr Lus Belmiro Moreira

Metodologias de desenvolvimento de sistemas. / Andr Lus Belmiro
Moreira Ramos.
Rio de Janeiro: SESES, 2017.
152 p: il.
isbn: 978-85-5548-434-6
1. Processos. 2. Extreming programming. 3. Rational Unfied Process.

4. Agilidade. 5. Scrum. I. SESES. II. Estcio. cdd 004
Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063
Sumrio
Prefcio 7
1. Introduo s metodologias de desenvolvimento

de sistemas 9
Introduo aos modelos de desenvolvimento de sistemas 10
Modelo cascata 16
Modelo de prototipao 18
Modelo espiral 20
Modelo iterativo e incremental 22
Modelo baseado em componentes 25
Custos relacionados a modelos de desenvolvimento de sistemas 29
2. Fases do desenvolvimento de sistemas 35

Introduo s fases de desenvolvimento de sistemas 36
Fase de Planejamento e Elaborao 37

A engenharia de requisitos 42
Fase de Anlise e de projeto 43

A importncia da modelagem visual 46
Fase de Implementao 48
Fase de Testes 50
Testes nas etapas anteriores codificao 52
Testes na etapa da codificao 52
Testes na implantao do sistema 54
Fase de Manuteno 55
3. Rational Unified Process - RUP 59

A viso geral do RUP 60
Vises do RUP 69
Elementos do RUP 76
Papel 77
Atividade 78
Artefato 78
Fluxo de Trabalho 78
Disciplina 78
Ciclo de vida do RUP 79

Fase de concepo (iniciao): 79
Fase de Elaborao: 80
Fase de Construo: 81
Fase de Transio 83
O RUP nos dias de hoje 84
4. Introduo metodologia gil 89

O manifesto gil 90
Lean Software Development 97

Eliminar perdas 98
Amplificar o aprendizado 102
Tomar decises o mais tarde possvel 103
Fazer entregas o mais rpido possvel 103
Tornar a equipe responsvel 103
Construir integridade 105
Visualizar o todo 105
XP 106
Conceitos e Definies 106
Valores, Papis, Princpios e Prticas do XP 107
Prticas do XP 109
Papis do XP 111
Princpios do XP 113
Ciclo de vida de um Projeto de Programao XP 115

Fase de Explorao 115
Fase de Planejamento 116
Fase de Iterao 116
Fase de produo 116
Fase de Manuteno 116
Fase de Morte 117
5. Scrum 121
Introduo ao Scrum 122
Papis no Scrum 128

Time de desenvolvimento 130
Produto Owner 134
Scrum Master 137
Artefatos do Scrum 138

Roadmap do produto 138
Backlog do produto 139
Backlog da Sprint 140
Eventos do Scrum 141

Sprint 141
Planejamento do release 142
Planejamento da Sprint 142
Reunies dirias 142
Reviso da Sprint 143
Retrospectiva da Sprint 143
Refinamento do Backlog do produto 143
Kanban 143
Prefcio
Prezados(as) alunos(as),
No desenvolvimento de sistemas, vrios fatores influenciam na qualidade final

do produto. Para que possamos sempre resolver da melhor forma os problemas
que necessitam de automatizao, precisamos conhecer as diversas metodologias
que existem na rea de produo de software. Precisamos ter em mente que no
existe uma nica melhor forma de construo de sistemas, mas sim melhores pro-
cessos em relao a determinados contextos.
Assim, este livro apresentar os conceitos bsicos e avanados das principais
metodologias de desenvolvimento de sistemas com nfase nos seus aspectos te-
ricos e prticos, com exemplos e discusso de cada uma de suas etapas. Con-
sequentemente, com os conhecimentos adquiridos, o estudante ter uma viso
clara e prtica das principais metodologias estudadas, podendo adapt-las em si-
tuaes reais de sua vida profissional.
Diante de todos os pontos descritos anteriormente, acreditamos que com o
estudo atencioso do material aqui presente, voc, com certeza, ter ferramentas
necessrias para escolher a melhor forma de desenvolver sistemas.
Bons estudos!
7
1
Introduo s
metodologias de
desenvolvimento de
sistemas
Introduo s metodologias de
desenvolvimento de sistemas
Ao longo do tempo, sistemas de computador tm desempenhado funes

cada vez mais importantes no cotidiano das pessoas. Percebemos que softwares
esto presentes em diversos setores da sociedade, fazendo com que o seu funciona-
mento correto seja imprescindvel para a vida das pessoas. Entretanto, a constru-
o de sistemas complexa, sendo necessria a adoo de diferentes metodologias
de desenvolvimento para garantir a qualidade do que produzido. Diante deste
cenrio, nesse captulo, estudaremos o funcionamento das principais metodolo-
gias de desenvolvimento de sistemas e como elas evoluram no decorrer dos anos.
OBJETIVOS
Entender a importncia de seguir uma metodologia de desenvolvimento de sistemas;
Discutir os principais aspectos de diferentes metodologias de desenvolvimento de sistemas.
Introduo aos modelos de desenvolvimento de sistemas
Desenvolver sistemas no uma tarefa fcil. Cada vez mais a necessidade dos
usurios por produtos eficientes e eficazes aumenta, fazendo com que problemas
no sejam tolerados. Porm, mesmo com o avano da tecnologia, percebemos
que grande parte das equipes de desenvolvimento ainda entregam produtos que
falham em algum momento de sua operao. Neste sentido, podemos afirmar que
quando um sistema falha, raramente o problema tcnico. Na maioria das vezes,
os erros so consequncia da falha na adoo de metodologias de desenvolvimento.
A discusso sobre formas sistemticas de construo de sistemas teve incio
com a crise do software, na dcada de 70. O termo em questo faz aluso s difi-
culdades enfrentadas pelos desenvolvedores de software da poca em consequncia
do rpido crescimento da demanda e da complexidade de sistemas, alm da ine-
xistncia de tcnicas de desenvolvimento. Nesta poca, ocorreu a Conferncia da
OTAN sobre Engenharia de Software, que marcou o nascimento da engenharia
captulo 1 10
de software. O objetivo da reunio foi o estabelecimento de melhores prticas na
construo de sistemas.
Figura 1.1 Conferncia da OTAN sobre Engenharia de Software.
Na poca, a construo de sistemas era considerada um processo artesanal,

onde a dinmica de produo consistia na implementao de verses do produto
a partir de refinamentos sucessivos, com o objetivo de consertar os defeitos at que
o cliente se mostrasse satisfeito. Nesta forma de trabalho, com base na tentativa e
erro, os requisitos so levantados de maneira informal e dificilmente o problema
modelado. O trabalho centrado no programador, que a partir do uso de sua
criatividade, resulta em produtos nicos. Neste cenrio, percebe-se a pouca utili-
zao de documentao e de boas prticas de engenharia. No h planejamento e
o cdigo mostra-se como o artefato mais importante, chegando a ser visto como
uma obra de arte.
CONEXO
Leia mais sobre a crise do software em: <http://cienciacomputacao.com.br/tecnologia/
o-que-foi-a-crise-do-software-e-o-inicio-da-engenharia-de-software/>.
captulo 1 11
Como consequncia, um dos problemas enfrentados na poca foi o tempo
necessrio para concluso de um software. Como a forma de trabalho da equipe
no era padronizada, o consequente retrabalho implicava em um prazo de de-
senvolvimento acima do esperado. Com o aumento da demanda por software, o
mercado passou a no conseguir suprir a necessidade da sociedade da poca por
sistemas informatizados. Ainda hoje comum ter atraso no projeto, fazendo com
que, muitas vezes, nos acostumemos a aceit-lo como inevitvel. Porm, o devido
planejamento e monitoramento do projeto pode minimizar o problema.
Outro problema eram os altos custos atrelados ao desenvolvimento de siste-
mas: a forma como o sistema era construdo impactava no custo do produto final,
principalmente por fazer com que recursos no fossem despendidos de forma cor-
reta ao longo do processo de desenvolvimento. Neste contexto, podemos tambm
discutir sobre a descoberta de erros antes da entrega do software aos clientes. Com
o aumento da complexidade dos produtos, passou a ser comum a entrega de sis-
temas com muitos defeitos.
Como ponto negativo, tambm podemos citar a dificuldade em produzir em
grande escala, j que o produto era artesanal e o sucesso de um projeto nem sem-
pre significava que outros projetos outros projetos similares tambm obteriam xi-
to. Alm disto, essa forma de trabalho possui uma forte dependncia do talento da
equipe e, como consequncia, a manuteno se mostra difcil j que cada produto
acaba sendo nico. Por fim, nota-se uma grande variao na qualidade.
A partir desse cenrio, ficou clara a necessidade de desenvolver softwares de
maneira mais profissional e organizada com o objetivo de minimizar os problemas
citados nos pargrafos anteriores.
CURIOSIDADE
Os irmos Wright foram os pioneiros na construo de avies. Porm, at que a inveno
fosse concluda com sucesso, diversas tentativas foram realizadas, causando desperdcio de
recursos. A ideia era a seguinte: os irmos construam a sua aeronave por completo e ao final
empurrava-a para o despenhadeiro. Se o teste no fosse concludo com sucesso, comeava-
se tudo outra vez.
captulo 1 12
Ainda hoje, muitos constroem sistemas como os irmos Wright construam
avies. Como consequncia, diversos problemas relacionados construo de sis-
temas perduram ao logo do tempo, se mostrando como desafios para a obteno
de produtos de qualidade com recursos reduzidos.
Dessa forma, necessrio entender que o desenvolvimento de sistemas no
pode ser limitado implementao do cdigo, sendo necessria a adoo de uma
forma padronizada de trabalho que envolva atividades relacionadas ao planeja-
mento, projeto, verificao e validao do que se produzido. Em suma: faz-se
necessrio a utilizao de um processo de desenvolvimento para construir produ-
tos de qualidade que atendam s necessidades dos usurios.
Um processo de desenvolvimento de sistemas um conjunto de regras que
permite organizar um projeto em particular ao estabelecer o sequenciamento
de atividades a serem realizadas. Deve responder perguntas importantes como:
Quem realiza a atividade? Como a atividade deve ser feita? Por que se faz? Quando
deve ser feito?
Nesse mbito, Pressman (2006, p. 52) define processo como sendo "um arca-
bouo para as tarefas que so necessrias para construir software de alta qualida-
de". Sommerville (2011, p. 18) define um processo de software como um conjun-
to de atividades relacionadas que levam produo de um produto de software.
Por sua vez, o Guia PMBOK define processo como sendo um conjunto de
atividades inter-relacionadas realizadas para obter um conjunto especfico de pro-
dutos, resultados ou servios (PMBOK, 2012). Para o CMMI, um processo
definido quando tem uma descrio que mantida, ou seja, tem documentao
que detalha o que feito (produto), quando (etapas), por quem (papis), os itens
utilizados (insumos) e os itens produzidos (resultados) (CMMI 2006).
A partir dessas definies, podemos perceber que grande ideia de processos de
software verificar que caminhos a equipe de desenvolvimento precisa percorrer
para ao final ter um produto com qualidade e consequentemente com mais chan-
ces de ser o que o cliente espera. Percebe-se ainda que o detalhamento dos pro-
cessos possui diferentes granularidades, podendo suas etapas serem realizadas de
forma paralela. Ainda no contexto dos processos de software, diferentes atividades
podem ser organizadas seguindo distintos modelos de desenvolvimento.
captulo 1 13
Sommerville
Um modelo de processo de software uma representao simplificada de um proces-
so de software. Cada modelo representa uma perspectiva particular de um processo e,
portanto, fornece informaes parciais sobre ele. Por exemplo, um modelo de atividade
de processo pode mostrar as atividades e sua sequncia, mas no mostrar os papis
das pessoas envolvidas.
FONTE: SOMMERVILLE, I. Engenharia de Software. 9 Edio.

Editora Pearson, 2011, pgina 18.
Dessa forma, podemos definir modelo de desenvolvimento como uma re-

presentao abstrata das atividades de um processo de software e suas interdepen-
dncias, sendo uma verso simplificada de um processo de software, geralmente
dividido em fases ou etapas.
Como no existe uma representao de processo perfeita, podemos concluir
que um modelo tem que estar adequado natureza do seu problema. Neste con-
texto, qualquer forma de desenvolvimento de sistemas deve possuir algumas fases
bsicas, como:
Planejamento e Elaborao, onde todo o planejamento da construo do
software deve ser realizado, com objetivo de antecipar possveis problemas. Nesta
fase, os requisitos do sistema so definidos, formando a descrio inicial das ca-
ractersticas e funes que o sistema deve possuir. Neste momento, a equipe en-
volvida no projeto deve ter o entendimento do que o usurio necessita, no sendo
necessrio, nesta etapa, saber como as definies sero implementadas. Alm de
uma lista de requisitos, prottipos tambm podero ser construdos para confir-
mar os detalhes de negcio;
Anlise, onde o modelo conceitual deve ser definido, a partir do refinamen-
to dos requisitos identificados na etapa anterior, para que o domnio do problema
seja melhor entendido. Nesta fase, a soluo tratada em alto nvel para atender
aos requisitos e acaba complementando a especificao, sempre do ponto de vista
do usurio, deixando de lado detalhes referentes implementao;
Projeto, onde a arquitetura do sistema definida, com o objetivo de des-
crever o funcionamento do sistema a ser desenvolvido em um baixo nvel de abs-
trao, ao explicitar como as partes do sistema interagem entre si. Nesta fase, os
captulo 1 14
modelos de anlise devem ser estendidos e detalhados com o objetivo de servir
de insumo para a fase de implementao. Como consequncia, mdulos e suas
interfaces devem ser definidos, e o uso de bibliotecas deve ser planejado. Por fim,
o esquema do banco de dados deve ser pensado;
Implementao, onde o cdigo deve ser produzido de acordo com a es-
pecificao. Vale salientar que a codificao simples depende de como o sistema
foi projetado na fase anterior. Boas prticas de programao devem ser utilizadas,
como: padres de codificao, revises de cdigo, simplicidade e refatoramento.
Nesta etapa, dificilmente novos diagramas surgem;
Testes, onde o produto construdo deve ser verificado e validado a fim de
que se tenha a garantia do correto funcionamento do sistema. Nesta fase, diversos
tipos de testes podem ser aplicados, a saber: testes de unidade, testes de integrao,
testes de sistema, testes de validao, entre outros; e, por fim,
Manuteno, onde, aps a implantao e treinamento dos usurios, rea-
lizada a evoluo do software com o objetivo de suprir a necessidade de novas
funcionalidades do produto e de correo de eventuais defeitos no detectados nas
fases anteriores.
Apesar da descrio das fases anteriormente, os modelos de desenvolvimento

no devem ser aplicados ao p da letra e sim adequados realidade da organiza-
o, sendo importante levar em considerao o tipo de sistema que est sendo
construdo. Os modelos genricos de processos de software amplamente utilizados
so o modelo em cascata, o modelo de prototipao, o modelo espiral, o modelo
iterativo e incremental e o modelo de desenvolvimento baseado em componentes.
Vale salientar que os modelos de prototipao e baseado em componentes nem
sempre so aplicados de forma isolada sendo comumente utilizados em conjunto
com outros modelos, principalmente no desenvolvimento de sistemas de grande
porte e de alta complexidade.
SAIBA MAIS
Para entender melhor a importncia da adoo de um processo de software, assista ao
vdeo a seguir: <https://www.youtube.com/watch?v=QPiR8jTMLdI>.
captulo 1 15
Modelo cascata
O modelo em cascata, por ter sido um dos primeiros modelos de desenvolvi-

mento de sistemas, tambm conhecido como ciclo de vida clssico. A ideia do
modelo em questo inspirada na engenharia tradicional, onde podemos perce-
ber uma abordagem sistemtica ao estabelecer uma sequncia entre as ativida-
des envolvidas.
O principal objetivo do modelo cascata propor uma nova forma de trabalho
que minimize os problemas relacionados com o modelo artesanal de construo
de sistemas. Vale a pena destacar que os artefatos produzidos em cada fase que
compe o modelo servem como entrada para a fase seguinte, sendo necessrio o
encerramento da fase corrente para que a prxima tenha incio.
Como podemos ver na figura 1.2, o modelo composto por diferentes fases
que englobam desde a concepo do produto at a sua implantao e consequente
manuteno.
Levantamento
de Requisitos
Anlise
Projeto
Implementao
Testes
Manuteno
Figura 1.2 Fases do modelo cascata.
captulo 1 16
Mesmo estabelecendo uma forma organizada de trabalho, o modelo em ques-
to possui diversos problemas, como podemos ver a seguir.
No prev prototipao: As necessidades do cliente so listadas em forma
de requisitos, no oferecendo ao cliente uma perspectiva visual. O grande ganho
da prototipao seria a possibilidade de o cliente validar os requisitos apontados,
como tambm ajudar na elicitao de novos requisitos que at ento estavam ape-
nas na cabea dele, de forma tcita;
Em geral, o cliente no sabe tudo o que quer no incio do projeto: A
grande parte dos clientes no entende o domnio do problema, de forma comple-
ta, no incio do projeto. Muitos deles vo descobrindo o que realmente querem ao
longo do processo de desenvolvimento. Como no modelo em cascata as atividades
so sequenciais, sendo imperativo que cada fase finalize para que a prxima te-
nha incio, faz-se necessrio possuir toda a definio de requisitos ainda no incio
do projeto;
Dificuldade em acomodar mudanas depois que o processo inicia: A
equipe deve garantir que todas as necessidades do cliente e as restries do sistema
sejam detectadas a fase inicial do projeto, o que difcil de acontecer na prtica.
O modelo em cascata no acomoda mudanas relacionadas s necessidades dos
usurios que so detectadas no decorrer da construo do sistema;
Erros graves podero ser detectados apenas num momento tardio do
desenvolvimento: Como a fase de testes realizada apenas aps toda a codifica-
o do sistema, muitos defeitos podem ser encontrados neste momento, quando
mais caro e difcil de consert-los;
O cliente s conhece o produto na fase final do processo: Apenas ao final
da etapa de validao que o cliente ter acesso ao produto, o que pode acarretar
em inconsistncia entre o que foi entregue e o que realmente o cliente queria; e,
por fim
Projetos reais raramente seguem o fluxo sequencial que o modelo pro-
pe: na prtica, o desenvolvimento de sistema no realizado da mesma for-
ma que a construo de um produto manufaturado. A natureza de produtos de
software faz com que seja natural a paralelizao da realizao das atividades, onde
muitas vezes as etapas de engenharia de requisitos, anlise, projeto, implementa-
o e testes so realizadas ao mesmo tempo.
captulo 1 17
Apesar dos problemas citados, o modelo cascata pode ser utilizado em ca-
sos especficos.
Sommerville
Em princpio, o modelo em cascata deve ser usado apenas quando os requisitos so
bem compreendidos e pouco provavelmente venham a ser radicalmente alterados du-
rante o desenvolvimento do sistema. No entanto, o modelo em cascata reflete o tipo de
processo usado em outros projetos da engenharia. Como mais fcil usar um modelo
de gerenciamento comum para todo o projeto, processo de software baseados no
modelo em cascata ainda so comumente utilizados.

Modelo de prototipao
A prototipao um tipo de modelo evolucionrio que representa o desen-

volvimento de um modelo vivo do sistema, no qual se enfatiza a interface com o
usurio. A prototipao colabora com o entendimento do que o sistema deve fa-
zer, alm de ser um mecanismo interessante que faz com que o cliente naturalmen-
te proponha melhorias ao software em desenvolvimento. Neste sentido, o processo
de prototipao ajuda a minimizar os riscos relacionados ao no atendimento das
expectativas do cliente ao final do desenvolvimento do sistema.
Nessa forma de trabalho, um prottipo construdo para experimentao,
com o objetivo de se obter requisitos dos usurios e posteriormente uma confir-
mao sobre as necessidades identificadas anteriormente. Na figura 1.3, podemos
verificar as diversas fases do modelo utilizadas para construo de produtos.
captulo 1 18
Incio
Fim Coleta e
refinamento
de requisitos
Engenharia Projeto
do prottipo rpido
Refinamento Construo
do prottipo do prottipo
Avaliao
do prottipo
pelo cliente
Figura 1.3 Fases do modelo de prototipao.
A ideia do modelo em questo tem incio na coleta dos requisitos, onde as

necessidades dos clientes sero identificadas e listadas. Na sequncia, realizado
um projeto rpido, a partir de uma modelagem breve, com o objetivo de diagra-
mar os requisitos elicitados para melhor visualizao. Aps o projeto inicial, um
prottipo construdo para o cliente valide os requisitos apresentados.
Aps a anlise do prottipo pelo cliente, o mesmo pode ser refinado para ser-
vir de insumo engenharia do produto, onde esto includas, de forma implcita,
as atividades de implementao e testes de software. Percebe-se que o modelo
proposto de forma cclica, j que o prottipo pode ser refinado sucessivas vezes at
estar pronto para ser implementado.
A prototipao apresentada ao cliente pode ser de duas diferentes formas:
Prototipao Transitria (prototipao de baixo-nvel), onde o nvel de detalha-
mento no alto e ao final da etapa o mesmo descartado; Prototipao Evolutiva
(prototipao de alto-nvel), onde o detalhamento incrementado at atingir o
objetivo final, sendo o mesmo mantido ao longo do projeto.
A maior vantagem do modelo proposto, em relao ao modelo cascata, a
disponibilizao para o cliente do aspecto visual do sistema ainda nas fases iniciais,
com o objetivo de obter informaes e apresent-las aos usurios/clientes. Outro
ponto positivo a possibilidade de refinar o prottipo do produto a partir at que
o mesmo seja validado pelo cliente para ser construdo de fato.
captulo 1 19
Apesar das vantagens apresentadas, o modelo de prototipao possui algumas
limitaes, sumariadas a seguir:
Pode encorajar a anlise superficial: Como o foco do modelo a parte
visual do sistema, o cliente e a equipe de desenvolvimento podem passar desper-
cebidos por questes importantes relacionadas construo do produto, como
o detalhamento das regras de negcio e outros diferentes aspectos tcnicos. Um
simples detalhe prototipado pode gerar um trabalho complexo que, no final das
contas, talvez no v agregar tanto valor para assim o cliente;
O usurio v aquilo que pensa ser o software, mas no : Como con-
sequncia, clientes tendem a imaginar que, a partir da validao do prottipo, o
sistema est quase pronto, o que no verdade. Em muitos casos, a negociao em
relao ao prazo de construo do software pode se tornar um desafio; e por fim
O desenvolvedor pode fazer concesses de implementao a fim de co-
locar um prottipo em funcionamento rapidamente: Mais uma vez, a equipe
de desenvolvimento e o cliente podem focar excessivamente na interface do sis-
tema, em detrimento de aspectos importantes de negcio e/ou implementao.
Modelo espiral
Proposto por Boehm, o modelo espiral, assim como o de prototipao, evo-

lucionrio, porm com aspectos sistemticos e controlados do modelo cascata.
As atividades so organizadas como uma espiral que tem vrios ciclos, cada um
representando uma determinada fase, como mostrado na figura 1.4.
O modelo dividido em quatro fases: planejamento, anlise dos riscos, enge-
nharia e avaliao do cliente. Na primeira fase, inicialmente os requisitos iniciais
so coletados e o planejamento do projeto realizado. Para isto, a equipe de proje-
to, de forma conjunta com o cliente, deve determinar os objetivos, solues alter-
nativas e restries do projeto. Conforme o projeto evolui, o mesmo replanejado
com base nos comentrios do cliente.
Na fase seguinte, os riscos identificados com base na fase anterior devem ser
analisados. Inicialmente os riscos tratados so referentes aos requisitos identifica-
dos no comeo do projeto. Posteriormente, os riscos passam a serem influenciados
pela reao do cliente ao longo da construo do software.
captulo 1 20
Planejamento Anlise dos Riscos
Coleta inicial dos requisitos
e planejamento do projeto Anlise dos riscos baseada
nos requisitos iniciais
Planejamento baseado Anlise dos riscos baseada
nos comentrios do na reao do cliente
cliente
Prottipo inicial
Prottipo no nvel seguinte

Avaliao do cliente
Sistema construdo
pela engenharia
Avaliao do cliente Engenharia
Figura 1.4 Fases do modelo espiral.
A fase trs consiste nas atividades da fase de desenvolvimento, incluindo pro-

jeto, especificao, codificao e testes. A ideia do modelo ter os primeiros ciclos
baseados na construo de prottipos, para que, somente no ltimo ciclo, o pro-
duto seja construdo de fato.
Por fim, a ltima fase consiste na avaliao do cliente com relao s etapas
anteriores, com tambm no planejamento da prxima fase. A partir deste plane-
jamento, a depender do resultado obtido, pode-se optar por seguir o desenvolvi-
mento no modelo Cascata, caso os requisitos forem completamente especificados
e validados. Caso contrrio, pode-se optar pela construo de novos prottipos,
incrementando-o, avaliando novos riscos e replanejando o processo.
O modelo em questo possui diversas vantagens em relao aos estudados
anteriormente. Um dos principais aspectos da abordagem a adio da anlise de
riscos, elemento at ento desconhecido em outros modelos. Como consequncia,
essa caracterstica torna o processo de construo de um produto complexo mais
seguro.
captulo 1 21
Sommerville
A principal diferena entre o modelo espiral e outros modelos de processos de soft-
ware o seu reconhecimento explcito do risco. Um ciclo da espiral comea com a
definio de objetivos, como desempenho e funcionalidade. Em seguida, so enume-
radas formas alternativas de atingir tais objetivos e lidar com as restries de cada
um deles. Cada alternativa avaliada em funo de cada objetivo, e as fontes dos
riscos de projetos so identificadas. O prximo passo resolver esses riscos por meio
de atividades de coleta de informaes, como anlise mais detalhada, prototipao
e simulao.
FONTE: SOMMERVILLE, I. Engenharia de Software. 9 Edio. Editora Pearson,

2011, pgina 32.
Outra importante vantagem que, por ser incremental, novas funcionalida-

des podem ser adicionadas em cada nova verso. Vale salientar que a evoluo
implcita ao modelo faz com que no exista distino entre desenvolvimento e a
manuteno do sistema construdo. Por fim, podemos comentar que a presena
constante de avaliao do cliente faz com que a qualidade seja obtida desde as fases
inicias do projeto.
Apesar das vantagens citadas anteriormente, o modelo espiral possui impor-
tantes limitaes, como:
A abordagem deste modelo exige grande experincia na avaliao dos
riscos: Muitas vezes a equipe pode no ter a maturidade suficiente para identificar
possveis riscos associados ao projeto, fazendo com que problemas no sejam iden-
tificados a tempo de serem desenvolvidas respostas aos mesmos;
Pode ser difcil convencer grandes clientes de que a abordagem evolu-
tiva controlvel: necessrio definir um prazo final do projeto sob o risco de
nunca atingir as expectativas do cliente.
Em suma, modelo espiral mais adequado para sistemas complexos e que exi-
jam um alto nvel de interaes com os usurios, a fim de possibilitar a abordagem
de todos os problemas desse sistema. Como consequncia, a abordagem utilizada
com mais frequncia em grandes projetos.
Modelo iterativo e incremental
O modelo iterativo e incremental uma adaptao da abordagem espiral,

onde o desenvolvimento e a entrega so divididos em pequenos pedaos denomi-
nados de incrementos. Cada incremento corresponde a parte da funcionalidade
captulo 1 22
requisitada pelo cliente. Desta forma, a especificao evolui junto com o desenvol-
vimento do sistema, dando suporte a requisitos parcialmente definidos.
Pfleeger
No desenvolvimento incremental, o sistema, como est especificado na documen-
tao de requisitos, dividido em subsistemas por funcionalidades. As verses so
definidas, comeando com um pequeno subsistema funcional e, ento, adicionando
mais funcionalidades a cada verso.
FONTE: PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo:

Prentice Hall, 2 edio, 2004., pgina 44.
Atividades
Interativas
Especificao
DESCRIO
Desenvolvimento
INICIAL
Validao
Figura 1.5 Fases do modelo iterativo e incremental.
Como podemos perceber a partir da figura 1.5, o modelo proposto permite

que a equipe de desenvolvimento possa trabalhar a qualidade e os detalhes do
produto com refinamentos sucessivos. A partir da descrio inicial, a viso global
do sistema pode ser analisada para garantir a viabilidade econmica do produto.
Neste momento, pode-se realizar a modelagem inicial e um pouco de implemen-
tao, principalmente ligada construo de prottipos.
As iteraes posteriores devem ser organizadas com o objetivo de garantir que,
ao final do processo, de forma incremental, todas as atividades de anlise, proje-
to, implementao e validao foram devidamente realizadas. A ideia central da
abordagem que os produtos finais de todo o processo devem ser amadurecidos e
finalizados ao longo do tempo, sendo organizados em iteraes.
captulo 1 23
Pfleeger
O desenvolvimento interativo entrega um sistema completo desde o comeo e en-
to muda a funcionalidade de cada subsistema a cada nova verso.

Prentice Hall, 2 edio, 2004., pgina 44.
Em suma, podemos perceber que no existe uma sequencialidade entre as ati-

vidades realizadas, como no modelo cascata, j que a cada iterao so realizadas as
etapas de anlise (refinamento de requisitos, refinamento do modelo conceitual),
projeto (refinamento do projeto arquitetural, projeto de baixo nvel), implemen-
tao (codificao e testes) e transio para produto (documentao, instalao,
...), como explicitado na figura 1.6
Detalhamento Implementao
Detalhes Refina Projeto

Anlise projeto baixo Codificao Testes Transio
requisitos arqu. nvel
Funcionalidade
Interao
1
Interao
Interao
Business Anlise Projeto 2
Requisitos Priorizao 3
Case inicial arquitetural
Elaborao Tempo
Figura 1.6 Detalhamento das iteraes no modelo interativo e incremental.
Em relao s abordagens anteriores, o modelo iterativo e incremental traz di-

versas vantagens relacionadas, principalmente, possibilidade de avaliao prvia
de riscos e pontos crticos do projeto, fazendo com que o monitoramento e conse-
quente preparao adequada das respostas a estes riscos sejam realizadas a tempo.
Outro ponto interessante que, a abordagem minimiza o risco de falha do
projeto como um todo, j que como os requisitos mudam, um processo iterativo
mantm frequentes contatos com o cliente o que ajuda a manter os requisitos
sincronizados e as expectativas entre equipe e cliente alinhadas.
captulo 1 24
Como o projeto quebrado em incrementos menores, o sistema posto em
funcionamento mais rapidamente. Como consequncia, a equipe sempre tem, ao
final de cada iterao, algo para entregar para o cliente.
Por fim, podemos citar que, o aumento da motivao da equipe de desenvolvi-
mento, em razo da visualizao prvia do funcionamento do sistema, resulta em
uma acelerao do tempo de desenvolvimento do projeto como um todo.
Comparando o modelo iterativo e incremental e o modelo cascata, percebemos
que a maior diferena entre os dois se d na forma de organizao das atividades.
Enquanto o modelo cascata define uma sequencialidade de tarefas, sendo a
concluso das tarefas obrigatria para que as posteriores tenham incio, o interati-
vo e incremental oferece um mecanismo de paralelizao de tarefas, como obser-
vado na figura 1.7.
Modelo Cascata Modelo Interativo
Anlise Projeto Implementao + Testes Transio
Figura 1.7 Diferenas entre os modelos iterativo, incremental e cascata.
SAIBA MAIS
Leia um pouco mais sobre o conceito de iterao em: <https://engenhariasoftware.
wordpress.com/2012/10/10/iteracao-de-projeto-ou-de-produto/>.
Modelo baseado em componentes
Cada vez mais, as organizaes anseiam por metodologias de desenvolvimen-

to de sistemas que maximizem a produtividade e tenham como consequncia a
obteno de um alto retorno sobre o investimento. Problemas relacionados ao
captulo 1 25
cumprimento do prazo e custo previstos no incio do projeto, e diminuio do
escopo acordado com o cliente, devem ser minimizados.
Neste cenrio, o modelo em questo apresenta uma abordagem alinhada com
o reuso de componentes, visando uma de melhoria de produtividade focada na
reutilizao de artefatos j construdos.
A modelagem baseada em componentes faz com que o produto seja constru-
do por partes, distribudo em pequenos mdulos, focado em apenas uma fun-
cionalidade ou um conjunto de funcionalidades semelhantes, com o objetivo de
minimizar a complexidade envolvida no desenvolvimento. Como mdulo acaba
sendo especfico, o mesmo pode vir a ser reutilizado em diversas aplicaes atravs
do acesso ao componente.
Especificaes Anlise de Modificao Projeto de sistema

de requisitos Componentes de requisitos com reuso
Desenvolvimento Validao
e integrao de sistema
Figura 1.8 Fases do modelo baseado em componentes.
Na figura 1.8, visualizamos as etapas do modelo baseado em componentes.

Como nos demais modelos de desenvolvimento de sistemas, no incio necessria
a especificao dos requisitos do software para que as necessidades do cliente/usu-
rio se estabeleam de forma clara e objetiva. A partir deste momento, uma anlise
realizada em componentes existentes com o objetivo de verificar se o conjunto
analisado supre as necessidades apontadas na etapa anterior.
Dificilmente a equipe de desenvolvimento consegue estabelecer um relacio-
namento singular entre o que foi especifica e os componentes disponveis. Desta
forma, os requisitos podem modificados para fins de adequao. Na sequncia, o
projeto do sistema realizado com base no reuso dos componentes selecionados.
Na etapa de desenvolvimento e integrao, os componentes so interligados e
novos componentes desenvolvidos para compor a soluo final. Por fim, o cliente
valida o sistema com base nas especificaes iniciais.
Ao utilizar a abordagem descrita, percebemos diversos benefcios, tais quais:
Aumento da produtividade em razo da economia de tempo de desenvolvi-
mento, dependendo do conjunto de componentes pr-existentes. Neste sentido,
o modelo permite que organizaes assumam um nmero maior de projetos em
captulo 1 26
relao abordagem tradicional de engenharia de software, j que a equipe de
desenvolvimento, ao reutilizar cdigo que j foi desenvolvido, acaba tendo mais
tempo para ser envolvida em projetos adicionais;
Aumento da robustez em razo da reutilizao de componentes que j fo-
ram amplamente verificados e validados em projetos anteriores, garantindo uma
maior qualidade no produto final. Neste contexto, os engenheiros esto trabalhan-
do na implementao de um produto previamente testado e conhecido. Desta for-
ma, depois que software estiver concludo, espera-se que menos problemas sejam
apresentados;
Utilizao de um padro de desenvolvimento orientado ao desenvolvimen-
to nos moldes da componentizao.
Em suma, as vantagens descritas acima fazem com que o prazo e o custo das
aplicaes construdas a partir da abordagem de componentes sejam reduzidos.
Como consequncia, o tempo e custo adicional pode ser utilizado pelas organiza-
es na busca de outros projetos que aumentem a sua vantagem competitiva frente
ao mercado.
Na tabela a seguir, podemos perceber algumas diferenas entre o modelo ba-
seado em componentes e os demais apresentados nas sees anteriores.
MODELOS MODELOS BASEADOS

TRADICIONAIS EM COMPONENTES
O reuso feito na montagem,
sem custos de desenvolvi-
O reuso existe, mas ocorre
mento, sem mudar a imple-
na fase de desenvolvimen-
mentao dos componentes.
CONCEITO to. Geralmente envolve a
Atualizao e extenso do
reutilizao de trechos de
sistema so feitas de forma
cdigo.
dinmica por adio/integra-
o de novos componentes.
Na especificao, so rea- Na especificao, so rea-

lizadas a anlise das ne- lizadas a anlise das ne-
cessidades do cliente, a cessidades do cliente, a es-
ESPECIFICAO especificao do sistema pecificao do sistema e a
e a validao dos mesmos validao dos mesmos pelo
pelo cliente. cliente.
captulo 1 27
MODELOS MODELOS BASEADOS
TRADICIONAIS EM COMPONENTES
No projeto, realizada a
No projeto, realiza-
modelagem do sistema e a
PROJETO implementao da arquite-
da a busca e seleo de
componentes.
tura do sistema.
Desenvolvimento de partes
no atendidas por compo-
IMPLEMENTAO Implementao do cdigo.
nentes j existentes. Integra-
o de componentes.
Disponibilizao da aplica- Disponibilizao da aplicao

IMPLANTAO o para uso em produo. para uso em produo.
Tabela 1.1 Tabela referente s diferenas entre os modelos tradicionais e o modelo ba-
seado em componentes.
A abordagem apresenta duas limitaes: Muitas vezes os componentes adqui-

ridos prontos no disponibilizam o cdigo fonte, se comportando como uma cai-
xa preta para os desenvolvedores. Tais componentes podem apresentar problemas
no funcionais que impeam a correta utilizao do produto. Outro problema est
relacionado a necessidade dos componentes possurem interfaces suficientemente
genricas, sob pena de tornar futuras integrao difceis ou at mesmo impossveis.
Apesar dos problemas, podemos afirmar que o modelo baseado em compo-
nentes importante no cenrio de reuso de software, evitando retrabalho, au-
mentando a qualidade e impactando positivamente na produtividade da equipe e
controle de prazos e custos. Alm disto, questes inerentes programao, como
confiabilidade e escalabilidade passam a ser tratadas de forma natural e contnua.
SAIBA MAIS
Leia um pouco mais sobre os conceitos de modelos baseados em componentes em:
<http://dspace.bc.uepb.edu.br/jspui/handle/123456789/8169>.
captulo 1 28
Custos relacionados a modelos de desenvolvimento de sistemas
O desenvolvimento de software est atrelado a custos. Ao mesmo tempo em

que a indstria cada vez mais constri sistemas maiores e mais complexos, torna-
se um desafio para as organizaes a entrega de produtos com qualidade, a custos
esperados e dentro do prazo.
Uma das formas de mitigar o risco em relao extrapolao do prazo esperado
realizar um planejamento do projeto que leve em consideraes o modelo de de-
senvolvimento adotado. Neste mbito, Pressman (2006) afirma que a equipe deve
organizar o trabalho e a ser feito e estimar os recursos necessrios, com base nas
atividades estipuladas, com o objetivo de antecipar possveis problemas e prever
um tempo de encerramento do projeto a partir da base histrica da organizao.
Dessa forma, Sommerville (2007) afirma que estimar o desenvolvimento de
um software no tarefa fcil, j que variveis como a qualidade do produto,
recursos humanos envolvidos e riscos atrelados podem interferir na previso. Em
suma, no existe uma resposta nica para elucidar essa questo. Contudo, pode-
mos afirmar que, em linhas gerais, os custos relacionados a tempo seguem uma
tendncia de acordo com a figura 1.9 descrita a seguir.
Modelo Cascata
Especificao Projeto Desenvolvimento Integrao e Teste

Desenvolvimento Iterativo e Incremental
Especificao Desenvolvimento Iterativo Teste de Sistema
Modelo Baseado em Componentes
Especificao Desenvolvimento Integrao e Teste
Figura 1.9 Relao de tempo gasto entre as atividades de diferentes modelos

de desenvolvimento.
Podemos perceber que, em modelos tradicionais, como o modelo casca-

ta, o tempo envolvido na construo do produto de 60% para as atividades
captulo 1 29
relacionadas ao desenvolvimento (especificao, projeto e desenvolvimento) e de
40% para as atividades relativas integrao do sistema e aos testes do sistema. O
tempo entre as atividades praticamente dividido de forma igual j que o modelo
caracterizado por uma sequncia, onde cada atividade s deve comear quando
a anterior finaliza.
Por sua vez, o desenvolvimento iterativo e incremental tem como base a pa-
ralelizao das tarefas, o que faz com que a especificao inicial no ocupe um
espao significativo no processo, j que esperado que mudanas ocorram e que
sejam acomodadas durante construo do produto. Desta forma, temos a maior
parte do modelo sendo dedicada ao processo iterativo.
Por fim, no modelo baseado em componentes temos uma situao a parte:
Metade do processo de construo destinada integrao e testes dos compo-
nentes do sistema, j que assumimos que a codificao do produto no realizada
do zero e sim com base no reuso de componentes construdos anteriormente.
Desta forma, a equipe de desenvolvimento deve realizar o seu planejamento levan-
do em considerao o tempo necessrio para integrar os componentes e test-los
individualmente e em conjunto.
Custo do desenvolvimento e evoluo do software
0 100 200 300 400
Desenvolvimento de Sistema Evoluo do Sistema
Figura 1.10 Relao de tempo gasto entre o desenvolvimento e evoluo do software.
Em relao manuteno dos produtos, como visto na figura 1.10, o tempo

de evoluo do sistema acaba sendo bem maior do que o de desenvolvimento. A
resposta para isso simples: a partir do momento em que o produto finalizado
e disponibilizado para produo, ele tende a se estabilizar, porm, com o tempo
ele deteriora em razo a novas necessidades dos usurios ou de correo de falhas
encontradas. O tempo de evoluo do software se d at o momento onde a sua
manuteno se torna mais cara do que a produo de um novo sistema que o
substitua. A figura 1.11 explicita a distribuio dos custos nas tarefas atreladas ao
desenvolvimento de software.
captulo 1 30
Custos de Desenvolvimento de Software
3%
8%
7% Requisitos
Projeto
15% Implementao
Testes
67%
Manuteno
Figura 1.11 Relao do tempo entra atividades de um modelo de desenvolvimento.
Ainda vale salientar que, como mostrado na figura 1.12, quanto maior o custo
distribudo nas atividades de desenvolvimento, menor ser o custo necessrio para
evoluir o sistema construdo. A ideia que quanto melhor desenvolvidas as etapas
iniciais, como especificao e projeto, alm de quanto mais testado for o sistema,
menor a chance de o cliente propor novas funcionalidades e descobrir erros no
futuro.
Sistema 2
Sistema 1
0% 20% 40% 60% 80% 100%

Custos de desenvolvimento Custos de manuteno
Figura 1.12 Relao do tempo entre o desenvolvimento e a manuteno do produto.
SAIBA MAIS
Leia o artigo a seguir para entender melhor o desafio em relao ao clculo
do susto de um software: <http://www.batebyte.pr.gov.br/modules/conteudo/
conteudo.php?conteudo=1332>.
captulo 1 31
ATIVIDADES
01. Qual a diferena entre modelos e processos de desenvolvimento de sistemas?
02. Defina, a partir das suas caractersticas, o modelo cascata. Voc adotaria o modelo cas-
cata em que tipo de projeto?
03. Em relao aos modelos de processos de software, pode-se dizer que o modelo iterativo
e incremental acomoda melhor as mudanas. Assinale a alternativa que melhor descreve um
modelo de produo de software iterativo.
a) As etapas so sequenciais, necessitando que a anterior finalize para que a prxima te-
nha incio.
b) Os incrementos de um software so entregues ao cliente de uma s vez.
c) As etapas no acontecem de forma paralela.
d) uma adaptao da abordagem espiral, onde o desenvolvimento e a entrega so dividi-
dos em pequenos pedaos denominados de incrementos.
e) o nico modelo a tratar questes referentes aos riscos do projeto.
04. Observe um modelo de ciclo de vida para desenvolvimento de sistemas. Nessa aborda-
gem, o desenvolvimento do produto de software dividido em ciclos, sendo identificadas em
cada ciclo, as fases de anlise, projeto, implementao e testes.
Levantamento Levantamento Levantamento

de Requisitos de Requisitos de Requisitos
Anlise de Anlise de Anlise de

Requisitos Requisitos Requisitos
Projeto Projeto Projeto
Implementao Implementao Implementao
Testes Testes Testes
Implantao Implantao Implementao
Este modelo conhecido como ciclo de vida.

a) Cascata d) Iterativo e incremental
b) Prototipao e) Baseado em componentes
c) Espiral
captulo 1 32
05. Dos diferentes modelos para o ciclo de vida de desenvolvimento de um software cor-
reto afirmar que:
a) O modelo em espiral o mais simples e o mais antigo.
b) O modelo em cascata o menos flexvel e mais simples.
c) A fase de especificao de requisitos pode estar ausente do modelo.
d) A fase de implementao sempre a ltima do modelo.
e) O modelo em cascata um dos primeiros modelos de desenvolvimento de sistemas,
tambm conhecido como ciclo de vida clssico.
REFLEXO
Neste captulo, aprendemos de forma geral, a importncia da adoo de mtodos para
desenvolver sistemas. Especificamente, estudamos as caractersticas dos principais modelos
de desenvolvimento de sistemas e suas fases, que serviro como base para o aprofundamen-
to na sequncia de nossos estudos.
Entendemos que a escolha da forma de construo de um software dependente do
seu contexto, no existindo um modelo nico a ser utilizado. Vimos tambm como os custos
esto atrelados s tarefas envolvidas nos modelos.
Sugerimos que voc faa todos os exerccios propostos e pesquise outras fontes para
aprofundar seus conhecimentos. Em caso de dvidas, retorne aos tpicos e faa a releitura
com bastante ateno.
LEITURA
Para voc avanar mais o seu nvel de aprendizagem envolvendo os conceitos de mode-
los de desenvolvimento de sistemas consulte a sugesto de captulos de livros abaixo:
Captulo 4 (Processos de Software) do livro de SOMMERVILLE, I. Engenharia de Software.
8 Edio. Editora Pearson, 2007
Captulos 1 (Desenvolvimento de software para o valor de negcios) e 2 (Processos de
desenvolvimento de software) do livro de ENGHOLM Jnior, Hlio. Engenharia de software
na prtica. So Paulo: Novatec Editora, 2010
captulo 1 33
REFERNCIAS BIBLIOGRFICAS
SOMMERVILLE, I. Engenharia de Software. 9 Edio. Editora Pearson, 2011.
PRESSMAN, R. S. Engenharia de Software. 6 Edio. Editora McGraw Hill, 2006.
ENGHOLM Jnior, Hlio. Engenharia de software na prtica. So Paulo: Novatec Editora, 2010
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall, 2 edio,
2004., pgina 44.
PMBOOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), Quinta
Edio em Portugus. Project Management Institute (PMI). Global Standard, dezembro 2012, EUA.
CHRISSIS, M. B., KONRAD, M, SHRUM, S. CMMI: Guidelines for Process Integration and Product
Improvement, Addison-Wesley, 2003.
captulo 1 34
2
Fases do
desenvolvimento de
sistemas
Fases do desenvolvimento de sistemas
Como visto no captulo 1, independente da abordagem utilizada, qualquer
metodologia de desenvolvimento de sistemas deve representar de forma abstrata
as atividades de um processo de software e suas interdependncias.
Para que fique claro o que necessrio realizar para entregar um produto,
dividimos os modelos em etapas com o objetivo de deixar claro o que necessrio
para definir, desenvolver, testar, operar e manter um sistema. Diferentes modelos,
possuem diferentes etapas, porm normalmente estas so classificadas, de forma
geral, como: planejamento e elaborao, anlise, projeto, implementao, testes
e manuteno.
OBJETIVOS
Conceituar requisitos de sistemas e discutir as tarefas envolvidas na engenharia
de requisitos;
Aprender as diferenas entre as etapas de anlise e de projeto;
Verificar a importncia da fase de implementao;
Entender o objetivo da fase de testes e aprender sobre a classificao dos testes;
Analisar os diferentes tipos de manuteno de software.
Introduo s fases de desenvolvimento de sistemas
O que suficiente para construir sistemas de computador? Muitos podem

imaginar que para desenvolver software basta conhecer uma determinada lingua-
gem de programao ou dominar tecnologias envolvidas na construo do produ-
to. De fato, ser um bom programador uma caracterstica importante no contex-
to de desenvolvimento de sistemas, porm no a nica habilidade requerida, j
que a implementao apenas uma das etapas do processo.
Para se construir um software, devemos realizar o levantamento e documen-
tao das necessidades dos usurios e das caractersticas do sistema, modelar a
anlise e projeto de software, definir as estratgias de implementao, testar se
captulo 2 36
o software atende s expectativas do cliente/usurio e evoluir o produto com o
objetivo de corrigir defeitos remanescente e incluir/alterar novas funcionalidades.
Resumindo: precisamos entender o processo de desenvolvimento do sistema e
adequ-lo ao contexto do produto. Desta forma, mais do que programao,
necessrio construir um produto com qualidade, que atenda s expectativas do
cliente e que esteja de acordo com a especificao.
Dessa forma, a partir do entendimento e utilizao de um determinado pro-
cesso de software, podemos amenizar o risco do produto no possuir atributos de
qualidade, como:
Facilidade de manuteno: o software deve ser escrito de modo que possa
evoluir para atender s necessidades mutveis dos clientes e usurios;
Nvel de confiana compatvel com o uso: o nvel de confiana envolve
confiabilidade, proteo e segurana;
Eficincia: o software no deve desperdiar os recursos do sistema compu-
tacional no qual executado;
Facilidade de uso: o software deve ser de fcil utilizao, deve ter uma in-
terface apropriada e documentao adequada.
Fase de Planejamento e Elaborao
No incio de um projeto de software geralmente o domnio do problema des-

conhecido. Mesmo que a equipe de projeto conhea parte do negcio a ser abor-
dado, a viso das pessoas envolvidas na construo do sistema sempre diferente
da viso do usurio. Para aumentar o desafio, comum no termos um referencial,
como o sistema j existente. Alm disso, cada vez mais as organizaes demandam
por sistemas com um alto grau de complexidade.
Neste mbito, necessrio realizar atividades que tem como objetivo coletar,
de forma clara e precisa, as necessidades dos usurios e as caractersticas do siste-
ma a ser construdo. Esse trabalho deve ser realizado pela equipe do projeto em
conjunto com representantes dos clientes e usurios. Alm disso, especialistas da
rea de aplicao do projeto podem interferir, levantando questes tcnicas que
so invisveis aos demais participantes. Ao conjunto de todas essas tarefas relativas
ao levantamento, detalhamento, documentao e validao dos requisitos de um
produto damos o nome de Engenharia de Requisitos.
captulo 2 37
Sommerville
Os requisitos de um sistema so as descries do que um sistema deve fazer, os
servios que oferecem e as restries a seu funcionamento. Esses requisitos refletem
a necessidades dos clientes para um sistema que serve a uma finalidade determinada,
como controlar um dispositivo, colocar um pedido ou encontrar informaes. O proces-
so de descobrir, analisar, documentar e verificar esses servios e restries chamado
de engenharia de requisitos.

2011, pgina 56.
O sucesso do projeto est diretamente associado engenharia dos requisi-

tos. Neste sentido, importante garantirmos que a maior parte das necessidades
foi compreendida, caso contrrio, teremos clientes/usurios insatisfeitos. Um dos
grandes desafios da engenharia de requisitos estabelecer os requisitos implcitos,
ou seja, as expectativas dos clientes e usurios, que so cobradas por estes, embora
no documentadas. Requisitos implcitos so indesejveis, porm mesmo requisi-
tos explcitos (documentados) e normativos (decorrente de lei ou normas) podem
apresentar problemas em relao a sua completude, consistncia e clareza.
Dessa forma, podemos perceber que requisitos mal-entendidos, imprecisos ou
incorretamente especificados representam um grande risco para o desenvolvimen-
to de software. O problema torna-se maior ao passo que o desenvolvedor tende a
simplificar a interpretao de um requisito ambguo.
Do ponto de vista de especificao, podemos classificar os requisitos de acordo
com o seu nvel de detalhe:
Requisitos do Usurio: So as necessidades, caracterstica e restries do
sistema descritas de forma abstrata, em um nvel menor de detalhamento. O ob-
jetivo comunicar ao cliente/usurio as funes que o sistema deve conter. Desta
forma, devem ser escritos em linguagem natural e no indicar a soluo para o
problema abordado;
Requisitos de Sistema: So as necessidades, caracterstica e restries do
sistema descritas de forma concreta, em um nvel maior de detalhamento. O
captulo 2 38
objetivo comunicar ao time de desenvolvimento o que o sistema deve conter.
Neste sentido, os requisitos de sistema podem incluir alguns detalhes de projeto.
Sommerville
De acordo com Sommerville, os requisitos do usurio so declaraes, em uma
linguagem natural com diagramas, de quais servios o sistema dever fornecer a seus
usurios e as restries com as quais este deve operar. J os requisitos de sistema,
so descries mais detalhadas das funes, servios e restries operacionais do
sistema de software, podendo ser parte do contrato entre o comprador do sistema e
os desenvolvedores de software.

2011, pgina 58.
SAIBA MAIS
Para ver exemplos dos tipos de requisitos estudados at o momento, acesse: <https://
prezi.com/hrq9wuxvzr7j/requisitos-de-usuario/>.
Do ponto de vista funcional, dividimos os requisitos em trs grupos: requisi-

tos funcionais, requisitos no-funcionais e requisitos de domnio.
Os requisitos funcionais descrevem as funes que o software deve conter, ou
seja, as funcionalidades que representam os anseios dos clientes e usurios. Neste
sentido, esse tipo de requisito explicita as funcionalidades e servios do sistema ao
passo que documenta como o sistema deve reagir a entradas especficas e como
deve se comportar em determinadas situaes. Alm disso, os requisitos funcionais
podem tambm indicar o que o sistema no deve fazer. A seguir, podemos verificar
alguns exemplos de requisitos funcionais:
O sistema deve emitir relatrios de vendas dirias de forma automtica;
O sistema deve possuir uma tela de cadastro de funcionrios;
O sistema deve permitir a transferncia de funcionrios entre diferentes setores;
O sistema deve permitir emisso de nota fiscal.
captulo 2 39
Pfleeger
Um requisito funcional descreve uma interao entre o sistema e seu ambiente.
Por exemplo, para se determinar os requisitos funcionais, decidimos quais estados
so aceitveis para o sistema. Alm disso, os requisitos funcionais descrevem como o
sistema deve se comportar, considerando um estmulo.

Prentice Hall, 2 edio, 2004, pgina 114.
Por sua vez, os requisitos no-funcionais so as caractersticas e restries de

um software. Esto relacionados a questes de qualidade, descritas na figura 2.1.
Requisitos
no funcionais
Requisitos Requisitos Requisitos

de produto Organizaes Externos
Requisitos Requisitos Requisitos Requisitos Requisitos

de Eficincia de Confiana de proteo Reguladores tnicos
Requisitos Requisitos Requisitos Requisitos Requisitos

de Usabilidade Ambientais Operacionais Desenvolvimento Legais
Requisitos Requisitos Requisitos Requisitos de

de Desempenho de Espao Contbeis Segurana/Proteo
Figura 2.1 Tipos de requisitos no-funcionais.
Um grande desafio em relao a este tipo de requisitos mant-los alinhados

entre si. Por exemplo, facilmente requisitos de usabilidade podem se contrapor a
requisitos de segurana.
REFLEXO
Vamos pensar um pouco: quando utilizamos um sistema bancrio muitas vezes podemos
nos chatear com exigncias do tipo confirmar a senha ao final da operao ou inserir uma
captulo 2 40
chave de segurana. Isso acontece porque estes requisitos diminuem a usabilidade do
sistema, porm aumentam a segurana. Ambos so requisitos no-funcionais que, neste
caso, se contrapem. E agora? Sabendo disso voc prefere que? Uma menor quantidade
de passos (usabilidade) ou uma maior verificao (segurana). A resposta ficou fcil! Neste
caso quanto maior a segurana, melhor para o usurio, mesmo que pagamos o preo da
facilidade de uso.
Pfleeger
Em vez de informar o que o sistema far, os requisitos no-funcionais colocam res-
tries no sistema. Isto , os requisitos no-funcionais ou restries descrevem uma
restrio no sistema que limita nossas opes para criar uma soluo para o problema.

A seguir, podemos verificar alguns exemplos de requisitos no-funcionais:

O sistema deve permitir que apenas pessoas autorizadas acessem o produto;
O sistema deve ser fcil de ser utilizado;
As principais consultas do sistema devem ter um tempo de resposta de at
3 segundos;
O sistema deve estar disponvel 7 dias por semana e 24 horas por dia.
Por fim, os requisitos de domnio so definidos pelo negcio e no pelo usu-

rio, sendo expressos atravs de linguagens especficas do domnio. Este tipo de
requisito pode ser de difcil entendimento, j que nem sempre a linguagem do
domnio de aplicao compreendida pela equipe de desenvolvimento. Outro
desafio que, muitas vezes, os especialistas em domnio compreendem a rea to
bem que no pensam em tornar os requisitos de domnio explcitos. A seguir,
podemos verificar alguns exemplos de requisitos de domnios:
Para cada dia de atraso de pagamento, ser acrescida uma multa de 1% do
valor total pago;
O clculo da mdia final de cada aluno dado pela frmula: (AV1 + AV2)/2;
Um aluno pode se matricular em uma disciplina desde que ele tenha sido
aprovado nas disciplinas consideradas pr-requisitos.
captulo 2 41
A engenharia de requisitos
Como discutido anteriormente, a engenharia de requisitos o processo de

elicitao, anlise, especificao e validao das funcionalidades, caractersticas e
restries do software.
Estudo Elicitao e Especificao Valiao

anlise de
da viabilidade requisitos de requisitos de requisitos
Figura 2.2 Tipos de requisitos no-funcionais.
O processo em questo se d a partir do estudo da viabilidade do projeto.

Mas por que to importante avaliar a viabilidade da construo do produto ain-
da na fase inicial da coleta dos requisitos? A resposta simples: necessrio que a
equipe de desenvolvimento tenha maturidade para analisar se capaz de entregar
o software da forma como os clientes e usurios esperam. Neste sentido, o estudo
da viabilidade deve ter sempre como objetivo dar insumos para as seguintes toma-
das de deciso em relao ao sistema a ser produzido:
O produto trar benefcios aos usurios interessados?
Existem solues alternativas melhores?
O projeto pode ou no ser desenvolvido?
Aps a deciso em relao viabilidade do projeto, realizada a elicitao

e anlise dos requisitos. Esta etapa a coleta propriamente dita das necessida-
des dos usurios em relao ao software, onde teremos o entendimento do dom-
nio da aplicao, do problema, do negcio e das necessidades e limitaes dos
stakeholders.
SAIBA MAIS
Entenda melhor quem so os stakeholders do projeto no vdeo a seguir: <https://www.
youtube.com/watch?v=HGBXPkrPAps>.
captulo 2 42
Diversas tcnicas podem ser utilizadas, como: entrevistas, aplicao de ques-
tionrios, brainstorm, leitura de documentos, cenrios, observaes e anlise so-
ciais (etnografia), reuso de requisito, prototipao dentre outras.
Em seguida, todos os requisitos coletados devem ser especificados, ou seja,
descritos em forma de linguagem natural para que, na sequncia, sejam validados
pelos stakeholders. Pela figura 2.2, podemos perceber que as etapas de elicitao e
anlise, especificao e validao de requisitos podem ser realizadas em paralelo,
ou seja, no necessrio finalizar a etapa anterior para partir para a prxima fase.
O artefato produzido ao final do processo chamado de documento de requisi-
tos. Segundo o Guia PMBOK, a documentao descreve como cada requisito
atende (s) necessidade(s) do negcio.
Em relao complexidade da engenharia de requisitos, produtos mais com-
plexos geralmente demandam por um investimento maior nas fases em compa-
rao com produtos mais simples. A mesma situao verificada quando temos a
relao entre um software novo e outro que tem como objetivo o aprimoramento
de um produto existente.
SAIBA MAIS
Documentao de software vale a pena? Descubra na leitura a seguir: <http://
blogdosamueldiniz.blogspot.com.br/2008/05/documentao-de-software-vale-pena.html>.
Fase de Anlise e de projeto
Aps a gerao do documento de especificao de requisitos, a equipe de desenvolvi-

mento j pode fazer a anlise e o projeto do produto. Nestas etapas, o principal objetivo
disponibilizar de forma visual as funcionalidades, caractersticas e restries do sistema.
Pfleeger
Para transformar um requisito em um sistema funcional, os projetistas devem satisfa-
zer os clientes e os construtores de sistema da equipe de desenvolvimento. Os clientes
sabem o que o sistema deve fazer. Ao mesmo tempo, os construtores do sistema de-
vem saber como o sistema funcionar.

captulo 2 43
Como consequncia da definio acima de Pfleeger, podemos afirmar que
necessria a diviso entre duas distintas etapas: a fase de anlise, onde devemos
apresentar ao cliente o que o sistema far, gerando um projeto conceitual, e a fase
de projeto, onde realizado um detalhamento para que a equipe de desenvolvi-
mento saiba quais so o hardware e software necessrios para solucionar o proble-
ma, gerando um projeto tcnico.
Neste sentido, a fase de anlise se limita a descrever o que o sistema deve fazer,
em detrimento de como os requisitos devem ser implementados, descritos na fase
de projeto. O resultado da etapa de anlise um conjunto de modelos e diagramas
que permitem fazer a transio para a fase de projeto, enquanto que o resultado
da fase de projeto um conjunto de diagramas e documentos que permitem que
a codificao seja realizada de forma mais planejada.
Na prtica, as fases de anlise e de projeto so realizadas de forma paralela,
em ciclos, onde parte da especificao, identificada na etapa anterior, analisada e
posteriormente detalhada na fase de projeto.
Neste contexto, podemos ter duas definies distintas para ambas as fases,
como descritas nas figuras 2.3 e 2.4.
Anlise Projeto
Modelagem do Modelagem da
problema Soluo
(estender) (criar)
Figura 2.3 Primeira definio das fases de anlise e projeto.
A partir desta primeira definio, temos o limite entre as fases de anlise e de

projetos bem definido, onde a fase de anlise a etapa de modelagem do proble-
ma, ou seja, contm as atividades necessrias para o entendimento do domnio do
problema. Por sua vez, a fase de projeto a etapa de modelagem da soluo, ou
seja, contm as atividades necessrias para resolver o problema.
Dessa forma, podemos resumir a definio exposta na figura 2.3 como sendo
a anlise uma tarefa de investigao, onde o que deve ser feito respondido, e o
projeto uma tarefa de criao, onde a preocupao vai ser como deve ser feito.
captulo 2 44
Anlise Projeto
Informao Informao
importante para importante
o cliente apenas para o
aprovar e programador
discutir
Figura 2.4 Segunda definio das fases de anlise e projeto.
A partir da segunda definio, descrita na figura 2.4, temos a fase de anlise

como sendo o conjunto de atividades realizadas com a cincia do cliente, ou seja,
os usurios devem discutir e validar a informao produzida. J a fase de pro-
jeto representa o conjunto das atividades que produzem informao destinada
aos programadores.
No segundo cenrio, percebemos que a anlise acaba ultrapassando os seus
limites e invade as atividades de projeto, j que o cliente acaba tendo que discutir
alguns detalhes de implementao, que teoricamente seria de interesse somente
dos programadores. Um exemplo clssico est ligado ao detalhamento da interface
do usurio, que, apesar de ser do interesse da equipe de desenvolvimento, neces-
srio ter o aval dos usurios.
A partir das definies apresentadas, podemos entender a fase de anlise como
sendo a responsvel pelo detalhamento dos requisitos obtidos no planejamento
elaborao e fase de projeto como sendo responsvel pelo detalhamento dos mo-
delos produzidos na fase de anlise.
Alm disso, a etapa de projeto tambm responsvel pelas seguintes tarefas:
Definir da arquitetura do sistema: O produto deve ser dividido em di-
ferentes mdulos e as interfaces de comunicao entre estes mdulos devem
ser pensadas;
Projetar arquitetura de acordo com os requisitos no-funcionais: o pro-
duto deve ser preparado para atender s caractersticas e restries identificadas
na etapa de requisitos, tais quais, desempenho, tolerncia a falhas, segurana en-
tre outras;
captulo 2 45
Projetar arquitetura de acordo com as boas prticas e/ou padres: o
produto deve ser planejado de acordo com padres de projeto que garantam boas
prticas de programao, como reuso, facilidade de manuteno, alta coeso, bai-
xo acoplamento, separao do software em camadas dentre outras;
Escolher ferramentas e tecnologias que sero utilizadas: nesse momen-
to onde pensado quais ferramentas e tecnologias vo ajudar na soluo do pro-
blema, tais quais, SGBD, servidores de aplicao, ferramentas de teste, sute de
desenvolvimento, linguagem de programao, dentre outras; e, por fim
Escolher estratgia(s) de desenvolvimento: nesse momento que a equi-
pe decide como se dar o desenvolvimento do produto, por exemplo, se ser ne-
cessria a aquisio de mdulos e o reuso de componentes.
Em suma, percebemos que o planejamento da arquitetura do sistema, reali-

zado na etapa de projeto, essencial para que possamos identificar componentes
do sistema, garantir o atendimento aos requisitos no funcionais e reaproveitar os
modelos em projetos semelhantes.
SAIBA MAIS
Leia o artigo a seguir para aprender um pouco mais sobre arquitetura de sistemas: <http://
www.devmedia.com.br/arquitetura-de-sistemas-de-informacao-uma-visao-geral/25326>.
A importncia da modelagem visual
Vimos que o principal objetivo das fases de anlise e projeto modelar visual-
mente o sistema, a partir dos seus requisitos. Mas o que um modelo?
Um modelo uma simplificao da realidade. Modelos so teis na descrio
de um sistema a partir de uma perspectiva particular e auxiliam no entendimento
e na formulao de problemas. Como exemplo, temos: um mapa, planta de uma
casa, desenho de estilista etc.
captulo 2 46
Sommerville
Os modelos so usados durante o processo de engenharia de requisitos para ajudar
a extrair os requisitos do sistema; durante o processo de projeto, so usados para
descrever o sistema para os engenheiros que o implementam; e, aps isso, so usados
para documentar a estrutura e a operao do sistema.

A partir da definio anterior de Sommerville, a modelagem visual pode tam-

bm ser utilizada em outras fases do processo de desenvolvimentos, j que colabo-
ra com a comunicao entre as partes envolvidas no projeto. Quanto mais com-
plexo for um produto, maior a necessidade em utilizar tcnicas de modelagem.
Alm da vantagem citada anteriormente, a modelagem tambm apresenta
como ganhos: Auxlio na visualizao do que est sendo construdo, foco na es-
pecificao da estrutura e o comportamento do sistema, melhor entendimento
dos riscos envolvidos no projeto e documentao das decises tomadas ao longo
do desenvolvimento.
Com relao aos princpios de modelagem, temos que:
A escolha dos modelos a serem criados tem uma grande influncia em como
um problema atacado e como uma soluo desenvolvida;
Todo modelo pode ser expresso em diferentes nveis de preciso;
Nenhum modelo nico suficiente. Todo sistema no-trivial melhor
abordado atravs de um conjunto pequeno de modelos relacionados;
Um sistema, geralmente, tem muitas classes (dezenas, centenas...) e nem
sempre estas classes so vistas por uma s pessoa;
Dependendo do nvel hierrquico desta pessoa, formas diferentes de apre-
sentar um diagrama de classes devem existir.
Neste contexto, para termos modelos interessantes, importante que eles se-
jam independentes da implementao, ou seja, uma implementao pode ser tro-
cada por outra sem afetar o modelo.
captulo 2 47
Alm disso, modelos devem ser descritos de acordo com uma linguagem. No
desenvolvimento de sistemas, a linguagem grfica utilizada para visualizao, es-
pecificao, construo e documentao de artefatos de um sistema de software a
UML (Unified Modeling Language).
SAIBA MAIS
Para ler mais sobre a linguagem UML, acesse o site: <http://www.uml.org/>.
Fase de Implementao
A fase de implementao consiste na codificao do software, ou seja, na etapa

de escrita do cdigo propriamente dita. Esta etapa deve garantir a execuo bem-
sucedida de todos os aspectos discutidos na fase de projeto.
Sommerville
O projeto e implementao de software um estgio do processo no qual um siste-
ma de software executvel desenvolvido. Para alguns sistemas simples, o projeto e
implementao de software a engenharia de software, e todas as outras atividades
so intercaladas com esse processo. No entanto, para grandes sistemas, o projeto e
implementao de software apenas parte de um conjunto de processos (engenharia
de requisitos, verificao e validao etc.) envolvidos na engenharia de software.

Por mais que a etapa anterior tenha sido bem realizada, nem sempre a codi-
ficao uma tarefa fcil, j que os projetistas podem no ter conhecimento su-
ficiente em relao linguagem de programao utilizada e, como consequncia,
o projeto pode no ser passvel de implementao da forma como foi planejado.
Outro problema frequente est relacionado com o trabalho em equipe, neces-
srio para esta etapa. A integrao do cdigo, produzido por diferentes pessoas,
pode se tornar um desafio. Em razo disto, os codificadores devem seguir regras de
implementao da empresa, que muitas vezes j possuem uma arquitetura bsica
pr-definida, com padres adotados. Alm do mais, regras bsicas de programa-
o, como nomes de variveis, formato de cabealhos de programas e formato de
comentrios, recuos e espaamento entre outras, devem ser utilizadas.
captulo 2 48
Falando nisso, segundo Pfleeger (2004, p. 262), cabealhos de programas so
importantes na exposio de informaes, como as seguintes: Qual o propsito do
cdigo em relao ao projeto como um todo, quem escreveu o cdigo, quando foi
escrito e revisado, entradas e sadas esperadas. O objetivo destas informaes de
servir como insumo para tarefas como a integrao com outras partes do sistema,
testes, manuteno e reuso.
Em relao aos comentrios realizados ao longo do cdigo, a sua importncia
relativa ao melhor entendimento por parte de todos os envolvidos no trabalho de
produo e reviso do produto. Muitos acreditam que um software bem codificado
no necessita de comentrios, porm esta afirmao acaba se tornando um mito,
j que, principalmente pela natureza coletiva da tarefa, dificilmente as equipes
atingem um nvel de qualidade de cdigo que faz com que comentrios adicionais
sejam dispensveis.
Por fim, Pfleeger (2004, p.264) chama ateno para a necessidade de termos
nomes significativos para variveis, indicando sua correta utilizao. Da mesma
forma, o uso adequado de recuo e espaamento entre linhas de cdigo, que aju-
dam a visualizar a estrutura de controle do programa.
Devemos prestar ateno tambm na documentao externa do programa,
to importante quanto os comentrios realizados dentro do cdigo. Na documen-
tao externa, deve ser includa a viso geral dos componentes do sistema, dos
diversos grupos de componentes e da inter-relao entre eles.
Pfleeger
Ao passo que a documentao interna concisa escrita em um nvel apropriado para
o programador, a documentao externa ser lida, tambm, por pessoas que nunca
vero o cdigo real. Por exemplo, os projetistas podem revisar a documentao ex-
terna, quando considerarem modificaes ou melhorias. Alm disso, a documentao
externa oferece uma chance de explicar tudo de uma maneira mais ampla do que pode
ser razovel em seus comentrios de programa.

Vale ressaltar que muitas vezes, por ansiedade em ver o software funcionando
rapidamente, os integrantes do projeto acabam se precipitando e chegando rpido
demais nesta etapa, fazendo com que o risco de se ter retrabalho aumente. As
etapas anteriores atuam como guia, ainda que o codificador tenha liberdade para
propor melhorias. Para que esta etapa seja concluda com sucesso, as unidades
captulo 2 49
de software devem ser codificadas e critrios de verificao das mesmas devem ser
definidos. A tarefa de reviso de cdigo tambm faz parte da fase.
SAIBA MAIS
Uma importante dica para obter cdigo de qualidade seguir padres de projeto.
Conhea um pouco mais sobre padres de projeto em: <http://www.devmedia.com.br/
conheca-os-padroes-de-projeto/957>.
Fase de Testes
A etapa de testes de software consiste na verificao e validao do produto.

Segundo Pressman, a atividade de teste o processo de executar um programa
com a inteno de descobrir um erro. Por sua vez, Sommerville (2011, p. 144)
afirma que os testes so destinados a mostrar o que um programa faz, o que
pretende fazer e para descobrir os defeitos do programa antes desse ser colocado
em uso.
A partir dessas definies, podemos afirmar que o objetivo desta etapa consis-
te, alm da procura por erros, o mais cedo possvel, na garantia de que o programa
realiza o que os usurios esperam. Mas o que seriam erros no software? conside-
rado um erro, todas as situaes a seguir:
O sistema falha em relao ao cumprimento de algum item do documento
de especificao do software;
O sistema realiza alguma funo ou possui alguma caracterstica/restrio
que claramente o documento de especificao do software diz que no deveria
fazer/ter;
O sistema possui requisitos que no esto contidos no documento de espe-
cificao do software;
O sistema no realiza alguma funo ou no apresenta alguma caractersti-
ca/ restrio que deveria estar no documento de especificao do software, mas foi
esquecida pela equipe de requisitos;
O sistema no possui uma boa usabilidade, deixando o usurio com um
sentimento de frustrao em relao ao seu uso.
captulo 2 50
CONEXO
Um mito importante na construo de produtos consiste na equipe adicionar funcionali-
dades que o usurio no pediu para melhorar o software, o famoso gold plating.
Aprenda mais sobre gold plating: <http://www.radardeprojetos.com.br/2015/02/gold-
plating-em-projetos.html>.
Na prtica, os processos de verificao e validao devem ser realizados em

paralelo com as demais etapas do desenvolvimento de software, desde o incio a
partir da reviso dos requisitos, passando pelas revises de projeto e inspees de
cdigo at os testes do sistema e de manuteno.
Sommerville
Os processos de verificao e validao objetivam verificar se o software em desen-
volvimento satisfaz suas especificaes e oferece a funcionalidade esperada pelas
pessoas que esto pagando pelo software. Esses processos de verificao iniciam-se
assim que os requisitos esto disponveis e continuam em todas as fases do processo
de desenvolvimento.

Os processos de validao so essenciais j que necessrio que os usurios

atestem que o produto final exatamente o que eles esperam. O maior objetivo
garantir que o software confivel e atende ao propsito estabelecido na etapa
de requisitos.
Com relao s tcnicas de verificao e validao, podemos classific-las em
dois grandes grupos:
Tcnicas estticas: Utilizadas no contexto onde no necessrio ter o
software sendo executado. O objetivo analisar e verificar modelos do sistema
como documento de requisitos, diagramas de anlise e projeto, cdigo-fonte do
programa. Como exemplos, temos: inspeo de software e reviso por pares;
Tcnicas dinmicas: Utilizadas no contexto onde necessrio que o
software seja executado, utilizado dados de testes. O objetivo examinar as sadas
produzidas pelo sistema a fim de analisar o seu comportamento. Como exemplo,
temos os testes funcionais.
captulo 2 51
Testes nas etapas anteriores codificao
Como vimos, as atividades de testes devem ser realizadas em paralelo com as

demais etapas do processo de desenvolvimento. Desta forma, comeamos a testar
ainda na etapa de requisitos, quando temos apenas as descries do que o usurio
necessita em relao ao produto.
Mas como podemos testar se o sistema ainda no est implementado? Vale a
pena lembrar que o produto no se resume ao cdigo! Podemos iniciar o proces-
so de verificao e validao a partir da reviso dos requisitos. Neste sentido, as
revises de software so como um filtro para a gesto da qualidade do produto. O
objetivo revelar erros e defeitos que podem ser eliminados. Assim, podemos usar
este tipo de teste para:
Verificar o que podemos adicionar para melhorar o produto;
Confirmar partes do produto os aperfeioamentos so desnecessrios; e
Aumentar a qualidade do que se produzido, a partir de verificao de
padronizao.
A reviso pode ser informal ou formal. Em uma reviso informal, a equipe

no realiza um planejamento antecipado em relao aplicao do teste e os erros
encontrados no so formalizados. Apesar de revelar problemas, menos eficaz
que as revises formais. Podemos aumentar a eficcia das revises informais a
partir da utilizao de listas de verificao (checklists) para cada artefato produzido
pela equipe de desenvolvimento do sistema.
Por sua vez, em uma reviso formal, a equipe realiza uma preparao prvia e
a aplicao do teste se d de forma controlada. Alm do mais, uma reviso formal
se concentra em uma parte especfica do sistema. Por questes de limitao de
recursos e tempo, as revises podem ser feitas por amostragem.
Testes na etapa da codificao
Durante a fase de codificao do software, podemos separar os testes em

trs grupos:
Testes unitrios: onde os testes so realizados individualmente, nas unida-
des do programa;
Testes de componentes: onde so testadas as integraes entre as unidades
do sistema e suas interfaces;
captulo 2 52
Testes de sistema: onde o sistema testado como um todo. Neste momen-
to, as interaes entre os componentes do sistema so verificadas.
Sommerville
O teste unitrio o processo os componentes do programa, como mtodos ou classes
de objeto. As funes individuais ou mtodos so o tipo mais simples de componentes.
Quando voc est testando as classes de objeto, deve projetar os testes para fornecer
uma cobertura de todas as caractersticas do objeto.

Dessa forma, fica claro que, a partir de testes unitrios, devemos testar todas
as operaes relacionadas ao objeto, definindo e verificando os valores dos seus
atributos, simulando todos os eventos que possam modificar o estado do objeto.
Neste tipo de teste:
O esforo de verificao aplicado na menor unidade de projeto do software;
Os erros encontrados so limitados ao s estruturas de controle de
cada mdulo;
A complexidade e os erros encontrados so limitados pelo escopo de tes-
te estabelecido.
Por sua vez, os testes de componentes, de acordo com Sommerville, devem

centrar-se em mostrar que a interface de componente se comporta de acordo com
a sua especificao. Desta forma, os testes de componentes atuam como uma
forma sistemtica de construo da arquitetura do software ao mesmo tempo em
que descobrem erros associados com as interfaces. Testes de componentes so im-
portantes j que:
Informaes podem ser perdidas atravs de uma interface;
Um componente, ao integrar-se com os demais, pode ter seu funcionamen-
to alterado;
Componentes combinados podem no apresentar o resultado princi-
pal desejado;
Erros tolerados em componentes podem ter seu efeito amplificado;
Estruturas de dados globais podem apresentar problemas.
captulo 2 53
Por fim, os testes de sistema verificam a combinao do software com ou-
tros elementos do sistema, como hardware, pessoal e bancos de dados, realizando
uma anlise do desempenho global do software. Os principais tipos de testes de
sistemas so: teste de recuperao, teste de segurana, teste de estresse e teste de
desempenho.
SAIBA MAIS
Unidade, integrao ou sistema? Qual teste fazer? Leia um pouco mais sobre estes
tipos de teste no artigo a seguir: <http://blog.caelum.com.br/unidade-integracao-ou-
sistema-qual-teste-fazer/>.
Testes na implantao do sistema
Aps a implementao do sistema, necessrio realizar testes como foco nos

stakeholders. O objetivo garantir que o software atende s necessidades dos usurios.
Sommerville
Teste de usurio ou de cliente um estgio no processo de teste em que os usurios
ou clientes fornecem entradas e conselhos sobre o teste de sistema. Isso pode en-
volver o teste formal de um sistema que foi aprovado por um fornecedor externo ou
processo informal em que os usurios experimentam um produto de software novo
para ver se gostam e verificar se faz o que eles precisam.

Os testes com usurios comeam com fim do teste de sistema, onde os com-
ponentes individuais j foram testados, o software est montado como um pacote
e os erros de interface j foram descobertos e corrigidos.
A validao bem-sucedida quando o software funciona do modo esperado
pelo cliente. Para o teste, so utilizados os requisitos descritos ao longo do projeto.
Neste sentido, os testes so projetados para garantir que os requisitos funcionais e
no-funcionais, principalmente usabilidade, sejam satisfeitos, e que a documenta-
o esteja completa e correta.
captulo 2 54
Podemos classificar os testes que utilizam usurios em duas categorias:
Teste Alfa: onde a conduo do teste realizada na instalao do desenvol-
vedor, utilizando os usurios finais.
Teste Beta: onde a conduo do teste realizada na instalao do usurio,
sem a presena da equipe de desenvolvimento.
SAIBA MAIS
Entregar produtos com erros pode resultar em catstrofes inimaginveis.
Veja algumas falhas que marcaram a histria: <http://crowdtest.me/10-falhas-
software-marcaram-historia/>.
Fase de Manuteno
A fase de manuteno tem incio a partir do momento em que o desenvolvi-

mento do sistema se encerra e o produto colocado em produo. Manutenes
no sistema ocorrem pela necessidade de garantir que o produto continue atenden-
do s necessidades do usurio, seja atravs de correes de possveis erros encon-
trados apenas aps a entrega, seja a partir de incluses ou alteraes de requisitos
propostos pelos clientes. Nesse sentido, percebemos que as atividades de manu-
teno esto relacionadas ao reparo de defeitos, adaptao de software e adio ou
modificao de funcionalidade.
Pfleeger
A manuteno enfoca, simultaneamente, quatro aspectos principais da evoluo do
sistema: manter o controle sobre as funes do dia a dia do sistema, manter o controle
sobre as modificaes do sistema, aperfeioar as funes aceitveis j existentes,
e tomar medidas preventivas para que o desempenho do sistema no diminua para
nveis inaceitveis.

Podemos classificar as manutenes de sistemas em:

Manuteno corretiva: onde so tratadas as mudanas relativas ao reparo
de defeitos do software;
captulo 2 55
Manuteno adaptativa: onde so tratadas as mudanas relativas s adap-
taes do software a outro ambiente;
Manuteno perfectiva: onde so tratadas as mudanas relativas melhora
de alguns aspectos do sistema, mesmo que no estejam atreladas a defeitos;
Manuteno preventiva: onde so tratadas as mudanas relativas preven-
o de possveis falhas em decorrncia de defeitos no produto;
Manuteno evolutiva: onde so tratadas as mudanas relativas adio de
novas funcionalidades no sistema.
Como podemos ver na figura 2.5, o custo de manuteno geralmente muito

maior que o custo de desenvolvimento. Desta forma, importante garantir que o
processo utilizado no desenvolvimento do sistema tenha sido bem aplicado, para
que os custos de manuteno sejam reduzidos.
Custo de
Desenvolvimento
0 100 200 300 400
Custo de
Manuteno
Figura 2.5 Comparao entre os custos de desenvolvimento e de manuteno.
Um maior custo atrelado manuteno pode ser explicado a partir dos se-
guintes fatores:
Nem sempre a equipe que mantm o sistema a mesma que o desenvolveu,
fazendo com que o esforo envolvido no entendimento do produto seja maior;
Os desenvolvedores de um sistema podem no ter responsabilidade contra-
tual pela manuteno;
Por ser uma atividade muitas vezes subvalorizada, a equipe de manuteno
geralmente menos experiente do que a equipe de desenvolvimento, alm de pos-
suir um conhecimento limitado do domnio do problema; e
Com o passar do tempo, os programas tm a sua estrutura degradada, tor-
nando-os mais difceis de serem entendidos e alterados.
captulo 2 56
ATIVIDADES
01. Qual o principal objetivo da engenharia de requisitos? Comente sobre as atividades rea-
lizadas neste processo.
02. Qual a diferena entre as etapas de anlise e projeto?
03. Por que necessrio padronizar a escrita do cdigo?
04. O que voc entende por verificao e validao de software?
05. Quais os motivos que levam ao aumento do custo em relao manuteno de produtos?
REFLEXO
Neste captulo detalhamos as fases gerais de modelos de desenvolvimento de sistemas,
que serviro como base para o aprofundamento na sequncia de nossos estudos. Para tanto,
vimos os conceitos relacionados s etapas de planejamento e elaborao, anlise e projeto,
implementao, testes e manuteno, seus objetivos e seus principais artefatos de sada.
Alm disso, problemas comuns no desenvolvimento de produtos foram abordados, como a
questo da relao entre o custo de desenvolvimento e o custo da manuteno.
LEITURA
Para voc avanar mais o seu nvel de aprendizagem envolvendo os conceitos de plane-
jamento e elaborao, anlise e projeto, implementao, testes e manuteno em projetos e
demais assuntos deste captulo, consulte a sugesto de link a seguir:
VACARI, I.; PRIKLADNICKI, R. Desenvolvimento de software na administrao pblica:
uma reviso sistemtica da literatura. Disponvel em: <http://www.pucrs.br/facin-prov/
wp-content/uploads/sites/19/2016/03/tr082.pdf>. Acesso em: Ago. 2016.
captulo 2 57
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall, 2 edio,
2004., pgina 44.
captulo 2 58
3
Rational Unified
Process - RUP
Rational Unified Process - RUP
Nos dias atuais, necessrio que as organizaes adotem uma forma padro-
nizada de construir seus sistemas, sob pena de comprometer negativamente as
propriedades do software. Desta forma, a utilizao de um processo bem definido
de desenvolvimento, passa a ser essencial na garantia da qualidade do processo e
do produto final.
Nesse contexto, o Rational Unified Process (RUP) se apresenta como uma fer-
ramenta bastante utilizada na comunidade de desenvolvimento de software atual,
sendo um arcabouo de processo que pode ser adaptado a diversos tipos de proje-
tos, independente do tamanho e complexidade. Por ser uma ferramenta comple-
xa, a sua adoo pode se tornar burocrtica, no sendo indicada a sua utilizao
em alguns contextos especficos, como em projetos de pequeno porte ou que apre-
sentam uma equipe com pouca experincia.
OBJETIVOS
Apresentar uma viso geral sobre o RUP;
Descrever as vises, princpios e elementos do RUP;
Analisar o ciclo de vida do RUP.
A viso geral do RUP
O RUP foi lanado oficialmente na dcada, pela Rational, em 1998, porm

a sua ideia tem como base pesquisas que datam os anos 60, a partir dos estudos
de Ivan Jacobson na Ericsson. Em 1987, aps a sada de Jacobson da Ericsson e
vrios anos de estudo da linguagem Objectory, Grady Booch e James Rumbaugh
se juntam ao projeto, denominados de os trs amigos, e surge o Rational
Objectory Process, como resultado da unificao das metodologias desenvolvidas
pela Rational na dcada de 80 com a de Jacobson. Em paralelo, a linguagem de
modelagem UML (Unified Modeling Language) foi desenvolvida, como tambm
foram adquiridas pela Rational diversas companhias que produziam ferramentas
para apoiar o desenvolvimento de software.
captulo 3 60
O RUP um arcabouo de processo que utiliza os conceitos do Modelo em
Espiral como alternativa para resoluo dos problemas encontrados no ento atual
modelo de desenvolvimento de software, o modelo cascata. Neste sentido, per-
cebemos que a ideia principal da ferramenta possibilitar a organizao das tarefas
de forma customizvel, iterativa e incremental, em detrimento da sequencialidade
abordada no modelo cascata. O RUP busca organizar as atribuies de tarefas e
responsabilidade de forma coerente e coesa, visando a produo de software de
qualidade a partir de um processo que aceite melhor as mudanas e faa com que
o projeto se mantenha dentro do oramento e cronograma planejados.
Fases
Disciplinas Iniciao Elaborao Construo Transio
Modelagem de Negcios
Requisitos
Anlise e Design
Implementao
Teste
Implantao
Gerenciamento de
Configurao e Mudanas
Gerenciamento de Projetos
Ambiente
Inicial E1 E2 C1 C2 CN T1 T2
Iteraes
Figura 3.1 Ciclo de vida do RUP.
Agora que conversamos sobre a histria do RUP e as razes para o seu surgi-
mento, podemos entender melhor o seu ciclo de vida, descrito na figura 3.1. O
arcabouo de processo em questo apresenta duas perspectivas: Uma dimenso
dinmica, que mostra as fases do modelo ao logo do tempo, e uma dimenso
esttica, que mostra as atividades realizadas no processo, em conjunto com os
papis, artefatos e fluxos.
Vamos primeiro nos concentrar no entendimento dos aspectos dinmicos do
modelo, relacionados s fases de concepo, elaborao, construo e transio.
captulo 3 61
Neste contexto, de acordo com Sommerville (2011, p. 34), O RUP um mode-
lo constitudo de fases que, ao contrrio do modelo em cascata, no qual as fases
so equalizadas com as atividades do processo, as fases do RUP so estreitamente
relacionadas ao negcio, e no a assuntos tcnicos.
A fase de concepo (iniciao) tem como objetivo estabelecer o entendi-
mento do negcio relacionado ao software a ser construdo, alm de realizar a
anlise de viabilidade do projeto. Nesta etapa, todas as entidades externas que iro
interagir com o sistema devem ser identificadas e as interaes devem ser descritas.
A fase de elaborao utilizada para o entendimento do domnio do proble-
ma, com o estabelecimento dos requisitos, a partir dos modelos da UML, como
tambm da definio da arquitetura e do plano de projeto. Nesta etapa, uma lista
de riscos deve ser identificada.
Na fase de construo, o projeto, codificao e os testes do produto devem
ser realizados. A implementao deve ser realizada em partes, tendo, ao final, os
mdulos integrados e funcionando como um sistema nico. nessa etapa onde a
documentao interna e externa do software produzida.
Com a fase de transio, temos a finalizao do processo do RUP, sendo
marcada pela entrega do sistema produzido para os clientes em um ambiente real.
O objetivo desta etapa realizar as atividades necessrias para permitir a disponi-
bilizao do software em um ambiente operacional
Iterao de fase
Concepo Elaborao Construo Transio
Figura 3.2 Fases do RUP.
Na figura 3.2 fica claro que as fases descritas so realizadas de forma iterativa
com os resultados desenvolvidos de forma incremental, ou seja, o trabalho relacio-
nado produo do software pode ser dividido em partes menores, como se fos-
sem miniprojetos. Assim, podemos dizer que a abordagem iterativa e incremental
consiste na repetio de atividades pr-estabelecidas que gera um acrscimo de
funcionalidade ao sistema. Vale salientar que nem todo incremento consiste em
captulo 3 62
uma adio de funcionalidades ao sistema, j que podemos ter incrementos que
so resultados de refinamento de funcionalidades, ou at mesmo de retirada de
algo que j estava rodando em produo.
As principais caractersticas do desenvolvimento iterativo so:
Permitir que riscos sejam pensados de forma antecipada, a partir do fee-
dback constante do usurio; e
Realizao da integrao e do teste de forma contnua, tornando possvel a
disponibilizao de implementaes parciais.
A maior vantagem relacionada a essa forma de trabalho est ligada ao fato do

produto poder ser validado pelo usurio enquanto o projeto ainda est em desen-
volvimento. Nesse contexto, em casos de falha, o sistema pode ser interrompido
nas fases iniciais, poupando tempo e investimento.
Gesto de Anlise e
Modelagem Requisitos Concepo
de Negcios Gerenciamento de
Configurao e
Mudanas
Planejamento
Inicial Planejamento Implementao
Gerenciamento
da Iterao de Ambientes Testes
Avaliao
Disponibilizao
Figura 3.3 O desenvolvimento iterativo e incremental do RUP.
SAIBA MAIS
Para entender melhor um modelo iterativo e incremental, assista ao vdeo a
seguir:<https://www.youtube.com/watch?v=q6_Pq5zByME>.
Agora que entendemos a viso dinmica do RUP, vamos estudar a sua perspec-
tiva esttica, focada nas suas disciplinas.
captulo 3 63
Sommerville
A viso esttica do RUP prioriza as atividades que ocorrem durante o processo de de-
senvolvimento. Na descrio do RUP, estas so chamadas de workflows. Existem seis
workflows centrais, identificados no processo, e trs workflows de apoio. O RUP foi pro-
jetado em conjunto com a UML, assim, a descrio do workflow orientada em torno de
modelos associados UML, como modelos de sequncia, modelos de objeto etc.

Voltando para a figura 3.1, podemos verificar que as disciplinas descritas de

forma esttica no esto diretamente atreladas s fases, organizadas ao longo do
tempo do projeto. O que temos que todas as disciplinas podem, em tese, estar
presentes em todas as fases descritas. Porm, comum haver uma prevalncia de
certos workflows em determinadas fases, como por exemplo, na fase de concepo
comum que as disciplinas de modelagem de negcios e requisitos sejam realiza-
das de forma mais intensa. Por sua vez, na fase de transio j no faz mais sentido
estar trabalhando intensamente com o foco na descoberta de novos requisitos ou
na modelagem do negcio, desta forma, os principais workflows desta etapa so os
relacionados implantao, gerenciamento de configurao e mudana, gerencia-
mento de projetos e ambiente.
Os nove workflows descritos na ferramenta RUP so:
Modelagem de Negcio (Business Modeling): O objetivo desta disciplina
analisar e entender o negcio envolvido, garantindo o alinhamento entre as
expectativas de todos os stakeholders do projeto e os objetivos da organizao. A
disciplina contm tarefas relacionadas ao entendimento do que construir, a iden-
tificao de funcionalidades chaves, determinao de pelo menos uma soluo
possvel e entendimento dos custos e riscos;
Requisitos (Requirements): O objetivo desta disciplina definir os limites
do sistema, de acordo com os requisitos estabelecidos. neste momento que os
casos de uso so criados para que os stakeholders tenham um melhor entendimento
em relao ao negcio;
Anlise e Design (Analysis & Design): O objetivo desta disciplina mode-
lar de forma visual os requisitos especificados nas disciplinas anteriores. A arquite-
tura do sistema definida neste momento. Alm disto, devem ser construdos os
modelos da UML que serviro de base para a implementao do produto;
captulo 3 64
Implementao (Implementation): O objetivo desta disciplina codificar
a soluo adotada, tendo como insumo os modelos produzidos na etapa anterior.
nesse momento que os testes unitrios so executados para garantir que cada
mdulo programado funciona de forma isolada;
Testes (Test): O objetivo desta disciplina verificar e validar o sistema
construdo, visando a deteco, documentao e endereamento dos defeitos en-
contrados a partir da comparao do que foi construdo com o documento de
requisitos e com a perspectiva obtida pelo usurio. Essa disciplina realizada em
conjunto com a implementao;
Implantao (Deployment): O objetivo desta disciplina garantir que o soft-
ware produzido fique disponvel para seus usurios finais, em um ambiente real;
Gerenciamento de Configurao e Mudana (Configuration & Change
Management): O objetivo desta fase permitir o controle das mudanas que
ocorrem ao longo do projeto, alm de manter a integridade dos artefatos trabalha-
dos. Neste momento, cada artefato deve ser identificado, auditados e ter nveis de
configurao e manuteno definidos;
Gerenciamento de Projeto (Project Management): O objetivo desta dis-
ciplina realizar as atividades relacionadas gesto do projeto, visando o controle
sob os riscos, cronograma, custos, pessoas, aquisies, entre outros, sempre com o
foco no atendimento das expectativas dos clientes e usurios;
Ambiente (Environment): O objetivo desta disciplina manter a configu-
rao do ambiente para que o processo e suas atividades possam ser executados.
As ferramentas necessrias para o correto desenvolvimento do produto devem ser
providas e disponibilizadas.
Na tabela 3.1 temos um resumo das disciplinas do RUP abordadas, fechando

assim o nosso estudo sobre os aspectos estticos da ferramenta.
WORKFLOW DESCRIO
Os processos de negcio so modelados por meio
Modelagem de negcios
de casos de uso de negcios.
Atores que interagem com o sistema so identifica-

Requisitos dos e casos de uso so desenvolvidos para modelar
os requisitos do sistema.
captulo 3 65
WORKFLOW DESCRIO
Um modelo de projeto criado e documentado com
Anlise e projeto modelos de arquitetura, modelos de componentes,
modelos de objetos e modelos de sequncia.
Os componentes do sistema so implementados

e estruturados em subsistemas de implementao
Implementao
gerao automtica de cdigo a partir de modelos
de projeto ajuda a acelerar esse processo.
O teste um processo iterativo que feito em con-

Teste junto com a implementao. O teste do sistema se-
gue a concluso de implementao.
Um release de produto criado, distribudo aos

Implantao
usurios e instalado em seu local de trabalho.
Gerenciamento de configura- Esse workflow de apoio gerencia as mudanas do

o e mudanas sistema (veja os captulos 25).
Esse workflow de apoio gerencia as desenvolvi-

Gerenciamento de projeto
mento do sistema (veja os captulos 22 e 23).
Esse workflow est relacionado com a disponibili-

Meio ambiente zao de ferramentas apropriadas para a equipe de
desenvolvimento de software.
Tabela 3.1 Disciplinas do RUP.
Sommerville
As inovaes mais importantes do RUP so a separao de fases e workflows e o
reconhecimento de que a implantao de software em um ambiente de usurio parte
do processo. As fases so dinmicas e tem metas. Os workflows so estticos e so
atividades tcnicas que no so associadas a uma nica fase, mas podem ser utiliza-
das durante todo o desenvolvimento para alcanar as metas especficas.

captulo 3 66
Alm das perspectivas dinmica e esttica, o RUP apresenta a perspectiva pr-
tica, que sugere boas prticas a serem seguidas ao longo do projeto:
Desenvolvimento iterativo de software: como j discutido, consiste na
diviso do projeto em miniprojetos, denominados iteraes;
Gerenciamento de requisitos: visando o alinhamento com as perspectivas
dos stakeholders, a gesto dos requisitos essencial para controlar as tarefas de eli-
citao, especificao e documentao de requisitos ao longo do projeto, mesmo
em fases finais no processo. A ideia que mudanas possam ocorrer em qualquer
momento e o projeto tem que se adaptar a elas. Para esta atividade, so utilizadas
noes de casos de uso e cenrios para facilitar a comunicao com usurios e
garantir que a equipe esteja resolvendo o problema certo e desenvolvendo o siste-
ma correto;
Arquitetura baseada em componentes: importante que a equipe projete
uma arquitetura flexvel, que leve em considerao o reuso e customizao de
componentes. Desta forma, esta boa prtica permite que o software evolua de
forma incremental, a partir da utilizao de componentes disponveis no mercado.
Como consequncia, teremos um maior encapsulamento;
Modelagem visual do software: consiste na utilizao de diagramas es-
truturais e comportamentais da UML, com o objetivo de modelar visualmente o
sistema. O maior ganho desta boa prtica a manuteno da consistncia entre
concepo e implementao do produto. Como consequncia da sua natureza
visual, a modelagem de software promove uma comunicao no ambgua entre a
equipe e os stakeholders e dentro do prprio time de desenvolvimento;
Verificao da qualidade de software: faz aluso preocupao com rela-
o s seguintes dimenses de qualidade do produto: funcionalidade, usabilidade,
confiana, suportabilidade e performance. A dimenso funcionalidade testa cada
cenrio de uso da aplicao. A dimenso usabilidade testa o software a partir da
perspectiva do usurio. A dimenso confiabilidade testa a consistncia e previsibi-
lidade do produto. A dimenso suportabilidade testa a capacidade de manuteno
do sistema em produo. Por fim, a dimenso de desempenho realiza os testes de
carga. Na figura 3.4 podemos observar as dimenses de qualidade do produto e
os seus respectivos tipos de testes, atrelados de forma especfica a cada dimenso.
captulo 3 67
Teste funcional
Teste de avaliao
de desempenho ou Funcionabilidade Teste de regresso
Benchmark (Functionality) Teste de volume
Teste de conteno Desempenho Teste de segurana
(Performance)
Teste de carga
Perfil de desempenho Usabilidade Teste de interface
FURPS
(Usability) Teste de usabilidade
Teste de configurao Suportabilidade
Teste de instalao (Supportability) Teste de integridade
Confiabilidade Teste de estrutura
(Reliability) Teste de entresse
Smoke test
Figura 3.4 Testes atrelados s dimenses de qualidade.
Controle de mudanas do software: visa garantir o controle de novos re-

quisitos, caractersticas e conserto de defeitos que surgem ao longo do processo
de desenvolvimento do sistema. Como percebido na figura 3.5, as solicitaes de
mudanas podem vir de vrias fontes durante o ciclo de vida do produto, o que
torna o seu controle essencial para o sucesso na construo do produto.
Novas caractersticas Clientes e usurios

Requisito
Novos requisitos Design Marketing
Canal de
aprovao Codificao
Bug
Teste
outros stakeholders
Change request
Manuteno
Figura 3.5 Controle de mudanas do software.
Agora que j conhecemos as boas prticas encorajadas pelo RUP, podemos

definir a ferramenta em relao a trs importantes aspectos: o processo deve ser
Guiado pelos Casos de Uso, Centrado na Arquitetura, e Iterativo e Incremental.
captulo 3 68
Os casos de uso no RUP so vistos como a fora condutora do desenvolvimen-
to, a partir do momento que so utilizados em diferentes disciplinas para captar
novos requisitos dos stakeholders e para aceitao do produto final. Este aspecto
importante na garantia da perspectiva do usurio dentro do processo de desenvol-
vimento do sistema.
O segundo aspecto destaca a importncia de se definir uma arquitetura no
incio do projeto para que as mudanas possam ser facilmente acomodadas. Neste
sentido, a arquitetura vista como um importante artefato na prova de conceitos,
construo e evoluo do sistema. Um dos pontos principais da arquitetura a
visualizao preliminar do sistema antes da etapa de codificao. nesse momento
em que questes importantes, como a componentizao, so abordadas.
A arquitetura de um sistema descrita atravs de diferentes vises do sistema:
a viso de lgica, a viso de implementao, a viso de processo, a viso de implan-
tao e a viso de caso de uso.
CONCEITO
Aprenda mais sobre arquitetura de software acessando o link disponibilizado a seguir :
<http://mds.cultura.gov.br/core.base_rup/guidances/concepts/software_
architecture_4269A354.html>.
Vises do RUP
No dia a dia, a perspectiva dos envolvidos no projeto diferente. Cada

stakeholder observa o produto que est sendo construdo sob uma tica prpria,
ressaltando propriedades que lhe interessa e omitindo outras que no so relevan-
tes para o seu contexto.
No RUP, os arquitetos de software utilizam a separao em vises com o obje-
tivo de gerenciar a complexidade do projeto, a partir da organizao de diferentes
aspectos em vises distintas. Dessa forma, o arquiteto reduz a quantidade que
informao tratada em contextos especficos. Com essa abordagem, cada compo-
nente da arquitetura de software pode ser observada de forma diferente, a depen-
der do interessado, como visto na figura 3.6.
captulo 3 69
Viso lgica Viso de implementao
Stakeholders Programadores
Funcionalidade Gerenciamento de configurao
Diagramas: Classes, Diagramas: Pacotes
Sequncia, Colaborao componentes
Viso de
Casos de Uso
Integradores Engenheiros de Sistema
Desempenho Topologia do Sistema
Escalabilidade Comunicao
Diagramas: Atividades, Objetos Diagramas: Implantao
Sequncia, Colaborao
Viso de processos Viso de implantao
Figura 3.6 Vises do RUP.
A viso lgica realizada sob a perspectiva dos stakeholders e descreve os requi-

sitos comportamentais e a decomposio do sistema em um conjunto de abstraes.
Podemos afirmar que o objetivo entender o produto do ponto de vista de problema
de negcio, o que torna a perspectiva independente de decises de projeto. Nessa tica,
os principais elementos apresentados so as classes e os objetos, tendo como principal
base a modelagem dos diagramas de classes, sequncia e colaborao (comunicao).
As figuras 3.7, 3.8 e 3.9 apresentam exemplos desses tipos de diagramas da UML.
Jornal
Interface
Textos
+ Destravar( )
+ Mover texto( )
1
+ Travar( )
Interface do Aplicador *
1
Aplicador
Interface do Paciente
+ Apresentar relatrio( ) 1..*
Paciente
+ Apresentar tela de edio de texto( )
Jornal Texto
+ Apresentar tela para selecionar diretrio( )
+ Buscar Textos( ) + Apresentar jornal travado( ) Srie
+ Destravar jornal( ) + Destravar jornal( ) Gnero
+ Editar texto( ) + Submeter jornal( ) Travado
1 Gnero
+ Escolher gnero( ) * nome
+ Editar( )
+ Inserir textos no banco( ) 1
+ Destravar( )
+ Receber jornal( ) 1 + Travar( )
1 Paciente
nome *
1 idade 1
Aplicador Sistemas de anlise
nome banco de texto
+ Analisar textos( )
Figura 3.7 Exemplo de diagrama de classes.
captulo 3 70
Cliente Funcionamento Filme Locao
Solicitar Filme
Tem no estoque
Sim
Decrementa estoque
Calcula Devoo
Data Devoluo
Cria Locao
Confirmar Locao
Figura 3.8 Exemplo de diagrama de sequncia.
direo da mensagem primeira mensagem interna
faaPagamento(valorEntregue) :TPDV faaPagamento(valorEntregue) :Venda
1.1:create(valorEntregue)
linha de link
:Pagamento
primeira mensagem
instncia parmetro
Figura 3.9 Exemplo de diagrama de colaborao (comunicao).
A viso de implementao realizada sob a perspectiva dos programadores,

sendo utilizada para descrever os mdulos do sistema e seus componentes. Nesse
sentido, o objetivo descrever detalhes do trabalho de codificao para toda a
equipe, considerando aspectos de reuso, subcontratao e aquisio de software.
Os diagramas da UML que representam essa viso so os diagramas de pacotes e
de componentes.
captulo 3 71
Login Relatrios Reembolsos Contribuies
Interface de Interface de Interface de

Login Relatrios Reembolsos Interface de
Contribuies
Lgica de Lgica de
Lgica de Lgica de
Login Relatrios
Reembolsos Contribuies
Lgica de Lgica de
Interao com Interao com
o Banco o Banco
Base de Dados
Figura 3.10 Exemplo de diagrama de pacotes.
Atualizao do Banco de Dados

C_Emprstimo C_devoluo
C_usurios C_administrador C_funcionrio
Busca no cadastro no
C_consultas Banco de Dados Banco de Dados
Cadastro de livros
Figura 3.11 Exemplo de diagrama de componentes.
captulo 3 72
A viso de implantao realizada sob a perspectiva dos desenvolvedores,
integradores e testadores, sendo utilizada para descrever como a aplicao ins-
talada. Esta viso permite avaliar requisitos no funcionais, como: desempenho,
disponibilidade, confiabilidade e escalabilidade. A viso de implantao tambm
se apresenta com o objetivo de modelar o sistema do ponto de vista da organizao
fsica, explicitando os computadores, perifricos e como eles se conectam entre si.
Esta viso representada pelo diagrama de implantao da UML.
Computadores de <<TCPAP>> Servidor <<TCPAP>> Banco de Dados

Clientes
browser <<HTTP>> Tomcat <<SSL>> Postgresol
conexo segura
<<SERIAL>>
<<TCPAP>> <<HTTP>>
Impressora
Computadores do
Administrador/
Funcionrio
browser
<<SERIAL>>
Impressora
Figura 3.12 Exemplo de diagrama de implantao.
A viso de processo realizada sob a perspectiva dos integradores, sendo

utilizada para descrever os processos do sistema e como eles se comunicam. Um
dos objetivos desta viso apresentar modelos que permitam avaliar requisitos no
funcionais relacionados execuo e comunicao, como desempenho e disponi-
bilidade. Os diagramas da UML que representam essa viso so os diagramas de
atividades, objetos, sequncia e colaborao.
captulo 3 73
Cliente Sistema Pizzaria
Pizza, Bebidas, Esfiha
Escolher Produto
Sabor, tamanho, borda
recheada
Escolher Detalhe do Produto
Definir Quantidade
[Continuar Comprando]
Escolher Forma de Pagto
Realizar o Pedido Processar Pedido Escolher Entregador
Figura 3.13 Exemplo de diagrama de atividades.
OP: Lote
Gribeiro: Proprietario area = 100
nome = Gilberto
SJC: Lote
area = 120
Figura 3.14 Exemplo de diagrama de objetos.
A viso de caso de uso realizada sob a perspectiva dos usurios, sendo uti-
lizada para descrever a funcionalidade do sistema. Um dos objetivos desta viso
apresentar casos de uso e cenrios que colaborem com o entendimento do que
necessrio ser feito do ponto de vista funcional. Essa viso tambm mapeia o
captulo 3 74
relacionamento das demais vises ao mostrar com os seus elementos interagem. O
diagrama de caso de uso representa essa viso.
Confirmar Pedido
Supervisor de Vendas <<extend>>
Consultar Pedido <<extend>> Emitir Ordem

Produo
Funcionrio Autorizado
<<include>>
Lanar Contas e
Receber
Figura 3.15 Exemplo de diagrama de caso de uso.
VISO LGICA PROCESSOS

Tarefas (processos e
Componentes Classes
threads)
Associao, herana, Mensagem, RPC, rendez-

Conectores
contenedores vous, broadcast
Containers Categoria de Classe Processo
Projetista do sistema,
Envolvidos (Stakeholders) Usurio-final
integrador
Desempenho, disponibli-
Interesses (concems) Funcionalidade
dade e, integridade
captulo 3 75
IMPLEMENTAO IMPLANTAO CASOS DE USO
Mdulos e sub-sistemas N processador Step, Scripts
Dependncia, ''includes'' Rede de comunicao-

em C, ''with'' clause. -lan, wan,
Sub-sistema (biblioteca) Sub-sistema fsico Web
Usurio-final,
Desenvolvedor, gerente Projetista do sistema
desenvolvedor
Organizao, reuso, Escalabilidade, desempe- Compreensibilidade,

portabilidade nho, disponibilidade funcionalidade
Tabela 3.2 Resumo das vises do RUP.
SAIBA MAIS
Falando em vises de arquitetura, o artefato que rene todas o documento de arqui-
tetura de software. O documento de arquitetura de software fornece uma viso geral de
arquitetura abrangente do sistema de software. Serve como um meio de comunicao entre
o arquiteto de software e outros membros de equipe de projeto, com relao a decises
arquiteturalmente significativas tomadas sobre o projeto. Aprenda mais sobre este artefato
no link a seguir:
<http://mds.cultura.gov.br/core.base_rup/workproducts/rup_software_architecture_
document_C367485C.html>.
Elementos do RUP
A ferramenta RUP possui uma srie de elementos que so utilizados para

compor um processo de desenvolvimento de sistemas com o objetivo de explicitar
quem faz o que e em que momento esta tarefa realizada ao longo da construo
do produto. So eles: papis, atividades, artefatos, fluxos de trabalho e disciplinas.
captulo 3 76
Business
Modeling Requirements
Analysis e Design
Planning
Initial Config. e Change Implementation

Planning Management
Environment Test
Deployment
Evaluction Organizado em
Processo de Engenharia de Software Disciplina
expressada
como
Organiza
sequencia de Descrito por
uta Atividade Detalhes de Fluxo Fluxo

exec (Workflow)
Referncia
(entrada)
(sada)
produz
para
usa
Res
Papel pon
sve
l po
r
Artefato Mentor de
Ferramenta
referncia
para
Diretrizes Gabarito Relatrio
Figura 3.16 Estrutura bsica do RUP.
Papel
Define o comportamento e as responsabilidades de um indivduo ou grupo

de indivduos trabalhando em equipe. O comportamento determinado pelas
atividades que o papel pode desempenhar. Por sua vez, as responsabilidades so
explicitadas atravs dos artefatos que o papel tem que produzir. So exemplos de
papis do RUP: programador, testador, gerente de projeto, arquiteto projetista,
analista de sistema dentre outros.
captulo 3 77
Atividade
um conjunto de passos, organizados em uma tarefa, realizado para produzir

um resultado esperado no processo, geralmente tendo como resultado a produo
de um artefato. Cada tarefa realizada por indivduos que representam, naquele
momento, um papel determinado. So exemplos de atividades no RUP: Planejar
uma iterao, encontrar casos de uso e atores, rever o projeto, executar um teste de
performance, dentre outras.
Artefato
o resultado final da atividade executado por um determinado papel, poden-

do ser um documento, um modelo, um cdigo-fonte, um programa-executvel
etc. importante deixar claro que cada artefato possui apenas um papel como
sendo responsvel pela sua produo, porm diferentes papis podem us-lo como
insumo para a construo de outros artefatos. So exemplos de artefatos no RUP:
plano de gerenciamento de requisitos, viso, glossrio, documento de arquitetura
dentre outros.
Fluxo de Trabalho
No conseguirmos montar um processo de desenvolvimento de sistemas ape-

nas com atividades, papis e artefatos. necessrio pensar na sequncia em que
tudo deve ser realizado e produzido. Desta forma, importante definirmos o fluxo
de trabalho, que consiste na ordem em que as atividades so executadas. Fluxos
de trabalho podem ser representados por diagramas de sequncia, diagramas de
colaborao e diagramas de atividades da linguagem UML.
O RUP utiliza trs tipos de fluxos de trabalho: fluxos de trabalho principais,
associados com cada disciplina; fluxos de trabalho de detalhe, para detalhar cada
fluxo de trabalho principal; e planos de iterao, que mostram como a iterao
dever ser executada.
Disciplina
Como j discutido anteriormente no captulo, uma disciplina o conjunto de

atividades que se inter-relacionam. O RUP possui nove disciplinas, divididas em
captulo 3 78
disciplinas do processo e de suporte. As disciplinas de processo so: modelagem
de negcios, requisitos, anlise e projeto, implementao, teste e distribuio. As
de suporte so: configurao e gerenciamento de mudanas, gerenciamento de
projeto, e ambiente.
Ciclo de vida do RUP
O ciclo de vida do RUP dividido em quatro fases e nove disciplinas.
Fase de concepo (iniciao):
Nesta fase, o foco da equipe de desenvolvimento ser nas disciplinas de

Modelagem de negcios e Requisitos. Isso acontece porque as disciplinas acima
esto relacionadas com a definio do problema e com a elicitao nas necessida-
des dos usurios frente ao software que ir ser produzido.
Apesar da maior parte do esforo se concentrar nas atividades de coleta e es-
pecificao de requisitos, neste momento as discusses acerca de uma arquitetura
inicial so pertinentes para que seja possvel analisar a viabilidade do projeto.
importante decidir de vale a pena continuar o projeto do ponto de vista financeiro
e tcnico. Da mesma forma, por exemplo, parte da camada de apresentao pode
ser codificada e testada para colaborar com a descoberta de requisitos.
A principal meta da fase de concepo o alinhamento das expectativas entre
os stakeholders, onde o escopo mapeado e os riscos iniciais identificados. Para
projetos evolutivos, a fase pode ocupar um espao menor no cronograma do pro-
jeto, porm, para novos produtos, esta etapa deve realizada de forma detalhada.
Objetivos da fase:
Definir o escopo do produto: a partir do levantamento dos casos de uso,

a equipe deve definir, junto aos usurios e clientes, quais so as necessidades, do
ponto de vista funcional e no funcional, que devem estar presentes no sistema.
importante tambm deixar claro que no vai estar contido na soluo final,
chamado de no escopo;
Estimar os custos do projeto: a partir da definio do escopo, a equi-
pe deve estimar os custos de forma inicial j que neste momento ainda no h
captulo 3 79
insumos suficientes para uma definio mais precisa de quanto vai ser gasto com
o projeto. O custo calculado pode ser revisto a cada iterao;
Estimar tempo do projeto: da mesma forma, aps a definio do escopo,
a equipe deve planejar o cronograma do projeto, tendo em mente que ser uma
atividade contnua, onde o cronograma Serpa atualizado a cada iterao;
Estimar riscos do projeto: a equipe deve analisar os casos de uso e cenrios
mais significativos do ponto de vista arquitetural para que riscos sejam levantados
e documentados;
Propor arquitetura inicial: a equipe deve propor pelo menos uma arquite-
tura bsica para que a viabilidade tcnica seja analisada.
Principais artefatos produzidos:
Documento de Viso (disciplina de Requisitos): Documento de alto n-

vel que descreve as necessidades, caracterstica e restries mais importantes do
sistema, sem entrar em detalhes tcnicos. Serve de base para o contrato;
Caso de Negcio (disciplina de Gerenciamento de Projetos): Documento
que contm informaes do ponto de vista do negcio para que seja analisada a
viabilidade financeira a partir do retorno de investimento (ROI). Contm as esti-
mativas de custos;
Plano de Desenvolvimento do Software (disciplina de Gerenciamento
de Projetos): Documento anlogo ao plano de projeto do PMBOK. Rene todas
as informaes necessrias para o gerenciamento do projeto ao longo do processo
de desenvolvimento do sistema;
Modelo de Caso de Uso: Documento que determina o escopo do sistema
a partir do mapeamento dos casos de uso do sistema;
Glossrio: Documento que rene as definies ambguas que podem acar-
retar em problemas de entendimento e clareza ao longo da construo do sistema.
Fase de Elaborao:
Na fase de elaborao, todas as disciplinas podem ser executadas, porm o

foco vai ser a disciplina de Anlise e Design. Neste momento do projeto, muitas
atividades das disciplinas de modelagem de negcios e requisitos ainda esto sen-
do executadas. As atividades de implementao ocupam um espao maior do que
na fase anterior, j que neste momento necessrio que se tenha uma arquitetura
captulo 3 80
estabilizada. A meta principal da Elaborao implementar os requisitos que pos-
suem um grande impacto na arquitetura, alm de desenvolver uma arquitetura
executvel.
Objetivos da fase:
Definir uma arquitetura executvel e estvel: a partir desta fase, impor-

tante que haja um mapeamento entre a soluo escolhida e os requisitos identifi-
cados at o momento, inclusive os requisitos no funcionais;
Tratar os riscos identificados do ponto de vista de projeto: neste mo-
mento, muitos dos riscos identificados so tratados, j que a soluo para o proble-
ma abordado comea a ser projetada. Essa ao realizada a partir da estabilizao
da arquitetura e a implementao dos casos de uso mais significativos;
Selecionar componentes: a equipe deve selecionar componentes a serem
utilizados visando o reuso;
Criar planos de iteraes para a fase de Construo: a equipe deve pla-
nejar como os requisitos sero implementados e testados ao longo das iteraes.
Prottipos: so utilizados para modelar visualmente os requisitos. Como

consequncia, atua na validao de requisitos j especificados e na descoberta de
novas necessidades.
Documento de Arquitetura de Software: documento que une as vises do
RUP discutidas anteriormente neste captulo.
Modelo de Projeto: so os diagramas comportamentais e de interao da
UML que descrevem a realizao dos casos de uso, mostrando como implement-
-los. uma abstrao do modelo de implementao e cdigo-fonte.
Modelo de Dados: modelo de implementao que descreve a representao
conceitual, lgica ou fsica dos dados persistentes no sistema.
Fase de Construo:
A fase de construo marcada pelas disciplinas de implementao e testes.

Apesar das demais disciplinas poderem ser executadas, neste momento espera-se
captulo 3 81
que a maior parte dos requisitos j tenha sido identificada e modelada. Da mesma
forma, importante que a arquitetura do sistema j tenha sido definida.
Pela natureza da fase, percebe-se um alto paralelismo da equipe a partir do uso
de diversas iteraes. Por este motivo, a disciplina de gerenciamento de configura-
o e mudanas tambm muito utilizada.
A principal meta da fase prover a implementao e os testes do projeto. Caso
haja indefinies nos requisitos, este o momento para tirar dvidas com os clien-
tes/usurios. A arquitetura pode ser evoluda.
Como estudado em captulos anteriores, a documentao externa de funda-
mental importncia para o entendimento do produto. Desta forma importante
que manuais de treinamento sejam construdos. Apesar destes artefatos terem in-
cio na fase de elaborao, na construo que so produzidos de fato.
Objetivos da fase:
Minimizar custos de desenvolvimento, otimizar recursos e evitar retra-

balho: a codificao deve ser realizada com base nas boas prticas de programao
do RUP;
Disponibilizar verses executveis do programa: a equipe deve liberar
verses de testes intermedirias para validar a codificao realizada. So comuns
verses de testes alfa, por exemplo;
Concluir a anlise, o projeto, o desenvolvimento e o teste de todas as
funcionalidades: a fase de construo marca o fim do desenvolvimento do pro-
duto, sendo o momento certo para encerrar atividades que servem de insumo ou
que so geradas pela codificao;
Verificar e decidir se o software est pronto para implantao: ao final da
construo do produto, necessrio que a equipe garanta que o sistema apresenta
os requisitos elicitados com a ajuda dos usurios, tanto do ponto de vista funcio-
nal quanto do ponto de vista das caractersticas e restries que o software deve ter.
Cdigo executvel: ao final da fase, a equipe deve disponibilizar o sistema

executvel, pronto para ser testado;
Plano de Implantao: a equipe deve produzir a verso inicial de um plano
que orienta a implantao do sistema;
captulo 3 82
Testes: a equipe deve produzir e executar um conjunto de testes que garan-
tam a estabilidade do sistema construdo.
Fase de Transio
Na fase de transio, a meta principal disponibilizar o sistema em um am-

biente real do usurio. Desta forma, a principal disciplina executada a de im-
plantao. As demais disciplinas do RUP acabam sendo pouco utilizadas nesta
fase, j que se espera que o produto esteja todo codificado e testado. Apesar da
nfase ser na disciplina de implantao, a disciplina de gesto de configurao e
mudana tambm bastante utilizada.
A durao desta fase tem uma grande variao a depender da complexidade
do sistema construdo. Normalmente projetos maiores, com requisitos instveis,
devem alocar mais tempo no cronograma para a correo de defeitos encontrados
e a disponibilizao de uma verso estvel para o usurio.
Objetivos da fase:
Disponibilizar o software ao usurio final: a equipe deve garantir que o

produto construdo seja implantando no ambiente real dos usurios;
Obter feedback do usurio: essa ao faz referncia lapidao do sistema,
devendo os ajustes serem mnimos, normalmente referentes a questes de usabili-
dade e desempenho. O aceite final pode ser obtido a partir de testes Beta;
Treinar os usurios e a manuteno: com o sistema pronto e implantado,
a depender da complexidade do negcio, os usurios devero ser treinados. Da
mesma forma, os detalhes referentes ao desenvolvimento de todo o sistema devem
ser repassados para a equipe de manuteno, que ficar responsvel por adicionar
futuras funcionalidades alm de corrigir erros encontrados aps o fim do projeto.
Notas de Release: este artefato importante na transparncia das informa-

es relacionadas s mudanas que ocorrem entre as verses do sistema. O objeti-
vo deixar claro o que mudou de uma verso para outra, quais os erros que foram
corrigidos e quais so as novas funcionalidades;
captulo 3 83
Artefatos de Instalao: a equipe deve construir uma orientao para que
a instalao do sistema seja bem-sucedida;
Material de Treinamento: a equipe deve prover material de treinamento,
guias de e manuais do sistema para que os usurios possam utilizar o produto de
forma satisfatria.
O RUP nos dias de hoje
Nunca se ouviu tanto falar em desenvolvimento gil como nos ltimos tem-
pos. A ideia que metodologias como o XP e Scrum podem resolver problemas
persistentes na produo de software com qualidade. Nesse universo, falar sobre o
RUP pode aparentar um retrocesso, mas precisamos analisar melhor o panorama
para no tirar concluses precipitadas.
preciso fazer a seguinte pergunta: o RUP de fato uma metodologia ultra-
passada ou no estamos utilizando a ferramenta da forma correta? O fato que ne-
nhum arcabouo de processo deve prometer a resoluo de todos os problemas que
as organizaes vm enfrentando desde a dcada da crise do software. Certamente
as metodologias geis tambm no so a soluo para todos os problemas.
Como estudado neste captulo, a ferramenta RUP baseada em trs concei-
tos bsicos: desenvolvimento incremental, utilizao de iteraes e customizao.
Muitas equipes no utilizam o poder do RUP ao, por exemplo, utilizar de forma
errada o conceito de incrementos. No basta dividir o projeto em entregas se voc
no utiliza os usurios para validar os mdulos construdos. Tambm importan-
te planejar o que vai ser entregue neste perodo de tempo para que a release seja
caracterizada por uma entrega de valor, ou seja, que o pedao do sistema entregue
represente parte dos sistemas que o usurio deseja utilizar.
Nesse contexto, o conceito de iteraes tambm no bem utilizado por gran-
de parte da indstria de TI. A ideia que utilizando esse mecanismo, o projeto seja
dividido em miniprojetos, onde mais fcil gerenciar riscos e aceitar as fatdicas
mudanas. Mais uma vez o arcabouo acaba perdendo fora, e pode no se mos-
trar to eficiente quanto esperamos.
O conceito de customizao tambm quase sempre esquecido, o que faz
com que as organizaes acreditem que tenham que produzir todos os artefatos
descritos no RUP, tornando o processo burocrtico para muitos contextos. A ideia
captulo 3 84
que, como arcabouo de processo, as equipes analisem o que necessrio ser
realizado para cada tipo de projeto. Certamente em projetos complexos, muito do
que est descrito no RUP ser utilizado. O mesmo no deve acontecer em projetos
menores, onde provavelmente o nmero de artefatos necessrios ser menor.
O RUP uma ferramenta poderosa e continua podendo ser utilizada, desde
que seja utilizada da forma correta, nos contextos adequados. Alm disto, o RUP
pode ser aplicado em conjunto com metodologias geis, mesclando os conceitos,
fortalecendo o conceito de documentao, buscando o atendimento das necessi-
dades dos usurios.
SAIBA MAIS
Para entender melhor a comparao entre as novas metodologias geis e o RUP, leia o
artigo a seguir: <http://www.ateomomento.com.br/scrum-rup/>.
ATIVIDADES
01. Quais as principais caractersticas do arcabouo de processo RUP?
02. A viso esttica do RUP prioriza as atividades que ocorrem durante o processo de
desenvolvimento. Na descrio do RUP, essas so chamadas de workflows. Existem seis
workflows centrais, identificadas no processo e trs de apoio, dentre os quais possvel citar
os workflows de:
a) Meio ambiente e Gerenciamento de projeto.
b) Concepo e Construo.
c) Transio e Iterao.
d) Plano de desenvolvimento e Conceito de operao.
e) Plano de desenvolvimento e Conceito de operao.
03. O RUP usa a abordagem da orientao a objetos em sua concepo e projetado e do-
cumentado utilizando a notao UML (Unified Modeling Language) para ilustrar os processos
em ao. O objetivo da disciplina de anlise e projeto :
a) modelar como o sistema deve ser implementado.
captulo 3 85
b) mostrar como o sistema pode estabelecer requisitos.
c) controlar a execuo do desenvolvimento.
d) estabelecer metodologias de anlise decorrentes de projetos.
e) mostrar como o sistema pode especificar o projeto.
04. No RUP (Rational Unified Process), casos de uso so

a) casos de usurios unificados em processos de racionalizao.
b) cenrios de utilizao do sistema por usurios.
c) cenrios de racionalizao de aplicaes.
d) casos de utilizao do RUP para maior racionalidade na aplicao dos recursos.
e) cenrios de utilizao compartilhada de solues por usurios de maior racionalidade.
05. Voc usaria um processo baseado no RUP para desenvolver um sistema Web?
REFLEXO
Neste captulo, estudamos o arcabouo de software RUP. Foi apresentado todo o seu
ciclo de vida, a partir da definio das suas fases e dimenses, e a descrio dos seus ele-
mentos bsicos. Alm disto, discutimos sobre as boas prticas de programao difundidas
pela ferramenta.
Entendemos que a ferramenta em questo no obsoleta, podendo ser utilizada em
diversos contextos, inclusive em parceria com metodologias geis. Todos estes conhecimen-
tos, certamente sero imprescindveis para sua vida profissional.
LEITURA
Para voc avanar mais o seu nvel de aprendizagem envolvendo os conceitos de RUP,
consulte a sugesto de artigos a seguir:
Souza, R., Vasconcelos, A. Uma Extenso do Fluxo de Anlise e Projeto do RUP para o
Desenvolvimento de Aplicaes Web. 2003. Disponvel no site:< http://www.lbd.dcc.ufmg.
br/colecoes/sbes/2003/0017.pdf>.
captulo 3 86
Descrio do RUP pela IBM disponvel no site:<ftp://public.dhe.ibm.com//
software/pdf/br/RUP_DS.pdf>.
Captulo 2 do livro PRESSMAN, R. S. Engenharia de Software. 6 Edio. Editora McGraw
Hill, 2011.
captulo 3 87
captulo 3 88
4
Introduo
metodologia gil
Introduo metodologia gil
Cada vez mais percebemos um aumento da presso de mercado nas organi-
zaes em relao necessidade por inovao, maximizao da produtividade,
entregas mais rpidas, minimizao dos custos, dentre outros fatores que fazem
com que as empresas apresentem uma maior vantagem competitiva frente a seus
concorrentes. Nesse contexto, dominado por projetos que geralmente no obtm
sucesso, seja por atrasos ou at mesmo cancelamento, surgem as metodologias
geis, com o propsito de modificar a forma de desenvolvimento de sistemas,
apostando na satisfao do cliente como maior prioridade.
A partir de agora estudaremos os principais conceitos das metodologias geis,
dando nfase neste captulo ao framework XP.
OBJETIVOS
Entender a importncia do manifesto gil;
Mostrar como os princpios Lean podem ser aplicados em abordagens de desenvolvimento
de software gil;
Apresentar os valores, papis, princpios e prticas da metodologia XP;
Entender o ciclo de vida do XP.
O manifesto gil
As abordagens geis so baseadas no modelo iterativo e incremental, onde o

projeto dividido em miniprojetos, como discutido no captulo anterior.
Sommerville
Os mtodos geis so mtodos de desenvolvimento incremental em que os incre-
mentos so pequenos e, normalmente, as novas verses do sistema so criadas e
disponibilizadas aos clientes a cada duas ou trs semanas. Elas envolvem os clientes
no processo de desenvolvimento para obter feedback rpido sobre as evolues dos
requisitos. Assim, minimiza-se a documentao, pois se utiliza mais a comunicao
informal do que reunies formais com documentos inscritos.

2011, pgina 39.
captulo 4 90
Dessa forma, a ideia dividir o problema em problemas menores, visando
um aumento da interao com o cliente a partir da entrega contnua de software
funcionando. Por esta razo, as metodologias geis apresentam um forte ganho s
organizaes que esto situadas em um contexto catico, como apresentado na
figura 4.1.
Um ambiente catico caracterizado por requisitos e tecnologia no total-
mente conhecidos. Neste contexto, as mudanas ao longo do projeto so inevit-
veis, sendo necessria a adoo de metodologias que aceitem melhor essas mudan-
as, como o framework Scrum.
Por sua vez, o ambiente previsvel caracterizado pela presena de requisitos e
tecnologia conhecidos e estveis. Projetos nestes contextos so facilmente adapt-
veis s metodologias com processo definido, como o framework RUP.
Vale a pena destacar que, em um ambiente anrquico, marcado por requisitos
e tecnologia desconhecidos, mesmo a utilizao de um processo gil no ir garan-
tir o sucesso do produto desenvolvido.
Desconhecido
Anarquia
Catico
Requisitos
Previsvel
Scrum
Metodologias com
Processo Definido
Co
Desconhecido
nh
Tecnologia
ec
ido
Figura 4.1 Contextos de projetos versus processos de software.
Mas como as metodologias geis diminuem os problemas relacionados um

ambiente catico de desenvolvimento de software? A resposta est atrelada a duas
questes: aumento da comunicao e entrega de valor.
Nas abordagens geis a comunicao deve ser contnua e face a face, fazendo
com que os riscos associados s incertezas do projeto sejam minimizados. A en-
trega de valor faz com que em um curto espao de tempo a equipe disponibilize
captulo 4 91
software funcionando com base nas prioridades do cliente. Como consequncia,
a resposta mudana torna-se natural, aumentando a satisfao do cliente. Em
resumo, podemos afirmar que o principal objetivo de qualquer metodologia gil
entregar um produto que seja til ao cliente e que tenha qualidade.
Alm do aumento de comunicao e da entrega de valor, podemos perceber
diversas outras vantagens das metodologias geis, tanto para o cliente, quanto para
as equipes de desenvolvimento, como mostrado a seguir.
Entrega de produto de forma contnua e rpida;
Aumento da transparncia dentro do projeto;
Facilidade na adequao de novos requisitos e na priorizao dos requisitos
j identificados;
Aumento da qualidade do produto final;
Melhora da produtividade;
Minimizao dos riscos atrelados ao projeto;
Escopo do projeto claro e detalhado no momento correto;
Equipes autogerenciveis, comprometidas e mais motivadas;
Maior adaptao do processo ao contexto do negcio;
Aumento da verificao e validao do produto;
Antecipao dos problemas e maior agilidade na tomada de aes.
Ento a discusso sobre agilidade recente? No! De acordo com Sommervile

(2011, p. 40), a insatisfao com a utilizao de metodologias baseadas fortemente
em especificao data da dcada de noventa, sendo que em 2001 diversos autores
assinaram o manifesto gil, que consiste em uma declarao que lista doze prin-
cpios do software gil.
A partir da anlise do manifesto gil, podemos derrubar alguns mitos que
rondam a cultura gil de desenvolvimento. Muitos desenvolvedores acreditam
que, em uma abordagem que prioriza entregas rpidas, os processos, ferramentas,
documentao, contratos e planos so dispensveis. Nesta tica, a utilizao desses
itens atrelada diminuio da produtividade da equipe e deve ser evitada. Porm
essa afirmao falsa! Como mostrado na tabela 4.1, os processos, ferramentas,
documentao, contratos e planos continuam sendo importantes para o projeto,
mas no se mostram mais importantes do que os indivduos e interaes entre eles,
software (ou produto) em funcionamento, colaborao com o cliente e responder
a mudanas.
captulo 4 92
Indivduos e interaes sobre Ferramentas e processos
Software funcionanado sobre Documentao extensa
Colaborao com o
sobre Negociao de contratos
cliente
Responder mudanas sobre Seguir um plano
Tabela 4.1 Valores de abordagens geis.
Manifesto gil
Estamos descobrindo maneiras melhores de desenvolver softwares, fazendo-o ns
mesmos e ajudando outros a fazerem o mesmo. Atravs deste trabalho, passamos
a valorizar: Indivduos e interaes mais que processos e ferramentas, software em
funcionamento mais que documentao abrangente, colaborao com o cliente mais
que negociao de contratos e responder a mudanas mais que seguir um plano. Ou
seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.
FONTE: AGILE MANIFESTO, Manifesto for Agile Software Development, 2001.

Disponvel em: <http://agilemanifesto.org/>. Acesso em: ago. 2016.
Valorizar os indivduos e interaes significa enfatizar a importncia da cultu-

ra organizacional das pessoas envolvidas no projeto em detrimento do processo e
ferramentas utilizadas. Neste ponto de vista, fica claro que apesar da importncia
da organizao das tarefas que levam construo do produto final, os membros
da equipe, com suas caractersticas e talentos individuais, que geram o software.
O indivduo visto como algo nico, que no pode ser simplesmente trocado sem
acarretar em perdas para o projeto.
Neste contexto, uma maior interao entre os indivduos que formam o time
de desenvolvimento essencial para que o objetivo do projeto seja alcanado. O
aumento da comunicao faz com que haja uma maior transparncia e, como
consequncia, seja necessria a elaborao de um nmero menor de artefatos,
em comparao a frameworks como o RUP. De acordo com Larman (2003) e
Highsmith (2002), as ferramentas utilizadas ao longo do desenvolvimento devem
ser simples e eficazes, assim como o processo deve ser guiar e apoiar o trabalho do
time, porm o mesmo deve se adaptar equipe e no o contrrio.
captulo 4 93
Com relao documentao, podemos verificar que as abordagens geis
priorizam o software em funcionamento em detrimento da criao e manuten-
o de artefatos. Este fato consequncia da importncia da entrega contnua para
o cliente. A documentao se mostra til ao desenvolvimento do produto, porm
a sua excessiva elaborao pode acarretar numa menor produtividade da equipe
como resultado de uma difcil manuteno. No ponto de vista gil, a satisfao
do cliente mais facilmente atingida a partir da entrega de resultados (cdigo
executvel), e no da gerao de documentao. Highsmith (2002) afirma que a
constante entrega de software funcionando faz com que o feedback do cliente seja
parte importante do desenvolvimento, o que no acontece na mesma proporo
com documentao.
Por falar em feedback, outro importante valor presente a colaborao com o
cliente. No desenvolvimento gil o cliente faz parte do time de desenvolvimento,
colaborando com o cumprimento do objetivo final, a entrega do produto. O seu
envolvimento deve ser constante, j que ele o maior conhecedor do negcio e
deve ajudar a equipe a produzir software de valor. Desta forma, a participao do
cliente deve ser colaborativa e o seu poder de deciso deve ser forte, ao ponto de
tornar contratos desnecessrios. Em certos contextos, marcados por volatilidade e
incerteza, contratos continuam sendo interessantes, porm a negociao amigvel
ser sempre a melhor sada. Transformar o cliente em um inimigo e se apoiar ape-
nas em contratos no a melhor estratgia para obter sucesso no projeto.
Ainda sobre os principais valores geis da tabela 4.1, responder s mudanas
mais interessante do que seguir um plano. O planejamento do projeto continua
sendo importante, porm temos que ter a maturidade de entender que as necessi-
dades dos clientes mudam com muita frequncia. Alm disso, a maioria dos con-
textos marcada por incerteza que fazem com que premissas sejam adotadas ao
longo do desenvolvimento que nem sempre se mostram verdadeiras. Desta forma,
podemos afirmar que mudanas so inerentes ao desenvolvimento de software, e a
equipe deve ser capaz de acomod-las de forma natural. Sempre melhor mudar
a rota do que chegar ao destina errado. isso que fazendo o tempo todo quando
estamos construindo software.
Alm dos valores discutidos, o manifesto gil apresenta tambm doze princ-
pios importantes no contexto de desenvolvimento rpido de software, que podem
ser vistos na tabela a seguir.
captulo 4 94
PRINCPIOS DO MANIFESTO GIL
Nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e contnua
de software de valor.
Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento. Processos geis se

adquam a mudanas, para que o cliente possa tirar vantagens competitivas.
Entregar software funcionando com frequncia, na escala de semanas at meses, com

preferncia aos perodos mais curtos.
Pessoas relacionadas negcios e desenvolvedores devem trabalhar em conjunto e

diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivduos motivados. Dando a eles o ambiente e suporte

necessrio, e confiar que faro seu trabalho.
O Mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro de um

time de desenvolvimento, atravs de uma conversa cara a cara.
Software funcional a medida primria de progresso
Processos geis promovem um ambiente sustentvel. Os patrocinadores, desenvolve-

dores e usurios, devem ser capazes de manter indefinidamente, passos constantes.
Contnua ateno excelncia tcnica e bom design, aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou ser feito.
As melhores arquiteturas, requisitos e designs emergem de times auto-organizveis.
Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se ajustam e
otimizam seu comportamento de acordo.
Tabela 4.2 Princpios do manifesto gil.
O primeiro princpio est ligado satisfao do cliente a partir da entrega

contnua. Como j discutimos anteriormente, a principal forma de verificar se
o cliente est satisfeito com o projeto fazendo com que ele receba de forma
antecipada pequenas partes executveis do programa. Essa entrega deve ser de
forma contnua para permitir a constante validao do produto e assim acomodar
melhor possveis mudanas e correes. Essa estratgia faz com que a qualidade do
software seja constantemente monitorada.
captulo 4 95
A necessidade de adequao s mudanas est preconizada no segundo prin-
cpio. Na maioria dos contextos de desenvolvimento de sistemas a necessidade
dos clientes no permanece a mesma no incio at o final do projeto. comum
que novas funcionalidades sejam percebidas, como tambm funcionalidades j
especificadas sejam revistas. Fazer com que o produto se adapte a estas mudanas
faz com que o software esteja sempre em sintonia com as necessidades reais dos
stakeholders, fazendo com que os mesmos obtenham vantagem competitiva frente
aos concorrentes.
Da mesma forma que a adaptao s mudanas, entregar frequentemente
software funcionando faz com que haja um aumento de vantagem competitiva
a partir do momento que o cliente torna-se parte da equipe ao avaliar constan-
temente o produto que est sendo construdo. Provveis problemas no software
podem ser antecipados e novos requisitos podem ser elicitados, mantendo sempre
um alinhamento de expectativas entre a equipe o cliente. A necessidade de uma
maior interao entre todos os envolvidos no projeto est clara no quarto prin-
cpio. Todos tm o mesmo objetivo, que obter um software com qualidade e
utilidade. Assim, os envolvidos devem trabalhar como um time, diariamente.
Como consequncia da necessidade do trabalho em equipe, o quinto princ-
pio fala sobre a motivao dos envolvidos ao longo do projeto. importante que
cada integrante saiba que o seu papel importante e faz diferena no trabalho em
conjunto. Neste contexto, podemos verificar que, em projetos geis, cada envol-
vido visto como uma pea nica que produz resultados nicos que formam o
conjunto final.
No trabalho em equipe, necessrio que a comunicao seja constante e clara.
As informaes devem ser passadas com transparncia e nenhum meio se mostra
mais eficaz do que a conversa cara a cara. Por mais que hoje em dia temos as fa-
cilidades proporcionadas por diversas tecnologias, a comunicao presencial ser
sempre mais a melhor escolha. Por esta razo, preferencialmente os projetos geis
devem ser realizados com equipes geograficamente no distribudas.
Por sua vez, o stimo princpio determina que software funcionando a me-
lhor mtrica de sucesso do projeto. Desta forma podemos afirmar que por mais
captulo 4 96
que a documentao tenha valor, entregas constantes de partes executveis do
programa se configuram como importantes insumos para a medio do progresso
do trabalho realizado. Atrelado a esse fato, o oitavo princpio afirma que o am-
biente constante de trabalho promovido por abordagens geis faz com que todos
os steakholders trabalhem com mais segurana e tranquilidade.
O nono princpio aborda a importncia da excelncia tcnica e bom design
para o aumento da agilidade. Quanto mais a equipe se torna madura em relao s
boas prticas de desenvolvimento, mais software funcionando consegue ser entre-
gue ao cliente, maximizando muitas dos princpios geis discutidos at o momen-
to. Como consequncia da excelncia tcnica, muito trabalho que no se mostra
til em relao s necessidades dos usurios deixa de ser realizado, o que aumenta
a produtividade da equipe ao concentrar os esforos nos requisitos realmente im-
portantes. Este fato est descrito no dcimo princpio.
O dcimo primeiro princpio aborda a questo de a importncia da equipe
possuir um time auto-organizado, onde todos possuem importncia e so livres
para desempenhar suas habilidades para que o objetivo do projeto seja cumprido.
Neste sentido, no obrigatrio que todos os integrantes do time dominem todos
os aspectos do desenvolvimento do sistema em questo. Porm, importante que
a equipe consiga resolver o problema sem necessitar de ajuda externa. A forma de
trabalho individual e coletiva pode ser revista de tempos em tempos, como expli-
citado no dcimo segundo princpio.
Lean Software Development
O desenvolvimento enxuto de software uma prtica gil, focada em estrat-

gias de negcio e de gerenciamento de projetos, que tem como base os conceitos
desenvolvidos na manufatura pela empresa japonesa Toyota de automveis, cha-
mado de Lean Manufacturing. O termo "Lean Software Development" vem do
livro " Lean Software Development: Na Agile Toolkit", escrito por Tom & Mary
Poppendieck em 2003. O livro apresenta sete princpios e vinte e duas ferramen-
tas que encapsulam o processo de Lean.
captulo 4 97
Franco
A histria da produo enxuta iniciou-se no Japo com a famlia Toyoda e a empresa
Toyota Motor Company, fundada em 1937. Aps ter passado por perodos difceis no
final da dcada de 1930, poca em que foi obrigada pelo governo a produzir cami-
nhes militares, com mtodos em grande parte artesanais, a Toyota resolveu ingressar
na fabricao em larga escala de carros e caminhes comerciais, porm deparou com
uma srie de problemas.
FONTE: FRANCO, Eduardo Ferreira. Um modelo de gerenciamento de projeto

baseado nas metodologias geis de desenvolvimento de software e nos princpios da
produo enxuta. So Paulo, 2007. Pgina 39.
O sistema Toyota de produo foi criado no Japo aps a segunda guerra mun-
dial. O seu maior objetivo era organizar a produo japonesa em um cenrio onde
a produtividade estava em baixa e os recursos estavam escassos, o que impossibili-
tava a produo em massa. O princpio fundamental desta abordagem tem como
base a eliminao de desperdcio na manufatura de um determinado produto. Os
outros princpios so: amplificar o aprendizado, tomar decises o mais tarde pos-
svel, fazer entregas o mais rpido possvel, tornar a equipe responsvel, construir
integridade e visualizar o todo.
Eliminar perdas
Podemos entender desperdcio como tudo que no gera valor para o cliente,
como fazer alguma atividade que no necessria no momento, movimentao,
transporte, espera, processamento extra, dentre outros. No contexto de manufa-
tura, a perda pode ocorrer, por exemplo, a partir do momento que uma fbrica
produz mais do que necessrio. No contexto de desenvolvimento de sistemas, o
desperdcio pode ser percebido nas situaes em que a equipe desenvolve funcio-
nalidades que no sero teis para o cliente.
Levando em considerao essa problemtica, Shingo (1981) identificou sete
tipos de desperdcios em manufaturas: estoque, processamento extra, superpro-
duo, transporte, espera, movimentao e defeitos. Por sua vez, Mary e Tom
Poppendieck (2003) traduziram os princpios para o contexto de desenvolvimento
de sistemas, como exposto na tabela a seguir.
captulo 4 98
PERDAS NO DESENVOLVIMENTO
PERDAS NA MANUFATURA DE SOFTWARE
Estoque Trabalho parcialmente pronto
Processamento extra Processo extra
Superproduo Funcionalidades extras
Transporte Chaveamento de tarefas
Espera Espera
Movimento Movimento
Defeitos Defeitos
Tabela 4.3 Desperdcios na manufatura e no desenvolvimento de software.
O primeiro desperdcio catalogado por Mary e Tom Poppendieck (2003) faz

referncia ao software parcialmente pronto no desenvolvimento de sistemas. De
acordo com os autores, sistemas inacabados tendem a no terem utilidade para o
cliente, ficando obsoletos. Com esse cenrio, a equipe no consegue garantir que o
sistema vai funcionar da forma como esperam e, consequentemente, se ir atender
s necessidades de negcio do cliente. Alm disto, softwares inacabados podem mi-
nar com os recursos que poderiam estar sendo melhores utilizados. Desta forma,
diminuir a quantidade de sistemas inacabados reduz riscos e perdas para o projeto.
Outro problema levantado pelos autores o excesso de documentao (proces-
sos extra) requerida por processos de desenvolvimento de sistemas. Documentao
consome recursos, diminui o tempo de resposta, esconde problemas de qualidade,
se perde, torna-se degradada e obsoleta. Desta forma, somente documentos que
sejam impeditivos na realizao de tarefas devem ser produzidos. Estes devem ser
vistos como artefatos que agregam valor ao produto e no trabalho a mais que
ningum ir consumir. Como exemplo, podemos citar a especificao de requisi-
tos: uma alternativa escrita do documento de requisitos a escrita de testes com
o foco nas necessidades do cliente. Desta forma, os testes passam a ser a prpria
documentao do que o cliente espera que o sistema realize e se comporte.
captulo 4 99
SAIBA MAIS
Para entender melhor a utilizao de testes integrados s regras de negcio, leia o artigo
a seguir sobre BDD:
<http://www.devmedia.com.br/desenvolvimento-orientado-por-comportamento-bdd-
artigo-java-magazine-91/21127>.
No muito incomum encontrar desenvolvedores que acrescentam requisi-

tos, que o cliente no pediu, no sistema desenvolvido. Acrescentar caractersticas
extras ao software em desenvolvimento parece inofensivo, mas configura perdas
para o projeto. Cada pedao de cdigo inserido na aplicao adiciona mais com-
plexidade e pode se tornar mais um ponto de falha. Todo o cdigo deve ser ins-
pecionado, compilado, integrado e testado. Dessa forma, acrescentar requisitos
funcionais ou no funcionais ao produto, impacta na produtividade da equipe.
Alm disto, o cdigo extra pode se tornar obsoleto antes de ser usado, j que no
era uma necessidade do cliente.
Outro motivo de perdas apontado por Mary e Tom Poppendieck (2003) a
constante mudana de tarefas dos integrantes da equipe. Quando um desenvolvedor
muda de tarefas, ele leva um tempo para assimilar o que deve feito, alm de interrom-
per algo que j estava encaminhado. Desta forma, os autores acreditam que atribuir
pessoas a mltiplos projetos uma fonte de perdas, sendo que o caminho mais rpido
para completar dois projetos, com a mesma equipe, faz-los sequencialmente.
Com relao espera, muito tempo de um projeto pode ser perdido enquanto
a equipe aguarda que as coisas aconteam, como: atraso para iniciar um projeto,
atraso na alocao das pessoas envolvidas, atraso devido excessiva documentao
de requisitos, atraso nos testes e atrasos na implantao. A consequncia dos atrasos
que podem ocorrer no projeto a demora na entrega de valor para o cliente, que
como j discutido anteriormente, deve acontecer o mais rpido possvel. Para alguns
projetos, os atrasos podem no ter maiores problemas, mas para os projetos que tem
como objetivo a construo de produtos competitivos, os atrasos podem acarretar
perdas incalculveis. Em um mercado altamente competitivo, se o concorrente lana
um produto na frente, todo o projeto que sofreu atraso pode perder a viabilidade.
A figura 4.2 mostra a cadeia de valor e os atrasos no modelo de desenvol-
vimento cascata. Na parte superior, podemos perceber a linha do tempo refe-
rente ao trabalho que agrega valor ao projeto, representado pelas atividades de
captulo 4 100
requisitos, anlise, projeto, codificao, testes e operao, alm de atividades de
interao com o cliente. Na parte inferior, vemos a linha do tempo relacionado
com o desperdcio.
Nego- Apro- Codifi- Implan-

vao Requisitos Incio Anlise Projeto Reviso cao Teste tao
ciao
Trabalho
Espera
Figura 4.2 Mapa de cadeia de valor do modelo cascata. (POPPENDIECK, M.;

POPPENDIECK, T., 2003).
Podemos perceber que o perodo de espera apresentado na figura 4.2 grande

quando comparado linha de trabalho que agrega valor ao projeto. O desperdcio de
tempo relacionado espera justificado pelas transies entre as etapas no modelo
cascata, que exige a verificao dos artefatos produzidos e um encerramento formal.
Com o objetivo de diminuir o tempo de espera e maximizar o tempo de
trabalho, o processo do desenvolvimento enxuto de software organiza as etapas
de anlise, projeto, codificao e testes dentro de iteraes que devem ser rea-
lizadas pelas mesmas pessoas, no necessitando de um encerramento formal. A
figura 4.3 representa a cadeia de valor e os atrasos presentes no desenvolvimento
enxuto. A linha do tempo est dividida em duas regies: a de trabalho e a de
espera. Agora, podemos verificar que os tempos de espera so menores e menos
frequentes, e os perodos de gerao de valor so maiores, me comparao com a
cadeia de valor do modelo cascata.
Selecionar Selecionar Selecionar
1 Seguimento 2 Seguimento 3 Seguimento
Avaliar os Avaliar os Avaliar os
Problemas problemas problemas
Negocia- Arquitetura Projetar, Projetar, Projetar,
Aprovao codificar e codificar e codificar e
o Preliminar
testar. testar. testar.
Revisar com Revisar com Revisar com
o cliente. o cliente. o cliente.
Implantar Implantar Implantar.
(opcional). (opcional).
Trabalho
Espera
Figura 4.3 Mapa da cadeia de valor do desenvolvimento enxuto de software mapa de

cadeia de valor do modelo cascata. (POPPENDIECK, M.; POPPENDIECK, T., 2003).
captulo 4 101
Por sua vez, o desperdcio relacionado com o movimento faz aluso ao tempo
de resposta para questes cotidianas do projeto. A equipe pode perder tempo se
movimentando para obter as informaes necessrias para o desenvolvimento do
produto. Para evitar este problema, algumas questes devem estar resolvidas ainda
nas fases inicias do projeto, como: Temos as pessoas certas para responder a per-
guntas tcnicas? O cliente est facilmente acessvel para discutir caractersticas do
produto? Em projetos geis, este problema minimizado a partir da utilizao de
ciclos curtos de entrega e aumento da comunicao entre os envolvidos.
Franco
As pessoas no so os nicos recursos que se movimentam, muitos artefatos tambm
se movimentam. Cada movimentao de artefatos est repleta de oportunidades de
desperdcios, o maior desperdcio nestas movimentaes que os artefatos no pos-
suem todas as informaes que a prxima pessoa que o utilizar precisa para conduzir
seu trabalho. Grande parcela do conhecimento tcito mantida pelo criador do artefa-
to e no entregue ao receptor.

baseado nas metodologias geis de desenvolvimento de software e nos princpios da
produo enxuta. So Paulo, 2007. Pgina 57.
Por fim, o desperdcio ligado aos defeitos determinado pelo impacto da

deteco tardia de problemas no sistema. Temos que entender que um defeito
crtico detectado em minutos no um grande desperdcio. J um defeito menor
no descoberto por semanas um desperdcio muito maior. Logo, a ideia que
defeitos sejam detectados o mais cedo possvel no processo de desenvolvimento de
software, a partir de iteraes curtas.
Amplificar o aprendizado
Na manufatura, o aprendizado obtido a partir da repetio de tarefas.

Quanto mais o trabalhador realiza aquele trabalho de forma repetitiva, mais ele
se torna especialista. No desenvolvimento de sistemas, a ideia diferente, j que o
produto final no realizado a partir de repeties pr-definidas. Para que o apren-
dizado seja amplificado, necessrio utilizar de tcnicas, como o feedback constan-
te, utilizao de iteraes curtas e sincronizao a partir de testes automatizados.
captulo 4 102
Tomar decises o mais tarde possvel
Este princpio do desenvolvimento enxuto est ligado necessidade de retar-

dar o mximo possvel a tomada de deciso em projetos que so construdos em
ambientes de incerteza. Quanto mais cedo as decises so tomadas, maximiza-se a
chance destas decises terem resultados com base em especulao e no em fatos.
No desenvolvimento de software, a melhor sada para a questo da tomada de deci-
so projetar o sistema focando na adaptao s mudanas. Desta forma, decises
podem ser revistas a partir de alterao nos requisitos.
Fazer entregas o mais rpido possvel
A entrega mais rpida de software faz com que a qualidade seja revista de forma
contnua, alm de proporcionar um mecanismo eficaz de realimentao de informaes
confivel, fazendo com que o ciclo de descoberta se mantenha tambm continuamente.
Alm disso, a velocidade da entrega permite adiar possveis decises que ainda
no estejam amadurecidas, fazendo com que partes crticas do produto sejam dei-
xadas para serem executadas em um momento mais coerente, onde existam mais
fatos para justificar as decises, diminuindo os riscos associados.
Tornar a equipe responsvel
Toda a equipe deve ser se envolver nas tomadas de decises tcnicas.

Dificilmente lderes podem responder pelos membros da equipe, j que cada inte-
grante possui o seu conhecimento tcnico individual que se mostra necessrio para
que determinados domnios de problemas sejam resolvidos.
Franco
Pelo fato das decises serem tomadas tardiamente e a execuo ser conduzida de
forma rpida, no possvel gerenciar as atividades dos trabalhadores atravs de uma
autoridade central. As prticas enxutas utilizam as tcnicas de produo puxada (pull)
para agendar o trabalho e possuem mecanismos de sinalizaes locais, de forma a
permitir que outros trabalhadores identifiquem o trabalho que necessita ser realizado.

baseado nas metodologias geis de desenvolvimento de software e nos princpios
da produo enxuta. So Paulo, 2007. Pgina 49.
captulo 4 103
No desenvolvimento enxuto de software, o envolvimento da equipe pode ser
explicitado nos acordos de entregas de verses do produto, em datas predefinidas
e regulares. De acordo com Franco (2007, p.49), A sinalizao local feita atravs
de grficos visuais, reunies dirias, integraes frequentes e testes automatizados.
A figura 4.4 exemplifica um quadro que pode ser utilizado para sinalizao
local, que pode tambm ser utilizado para nivelar e controlar o fluxo de produo.
Iterao 0 Iterao 1 Iterao2 Iterao 3 Iterao 4
Interao 1 Interao 2 Interao 3 Interao 4

Carto Tema Carto Tema Carto Tema Carto Tema
Arquitetura Arquitetura Arquitetura

1.0 1.1 1.2
Funcionalidade 4
Funcionalidade 5
Captura de Funcionalidade 3 Funcionalidade 1
Requisitos
Funcionalidade 6
Funcionalidade 2 Funcionalidade 7
Figura 4.4 Quadro de cartes de funcionalidades. (POPPENDIECK, M.;

A figura 4.5 traz um exemplo de grfico burndown, cujo objetivo controlar o

andamento das tarefas contidas na execuo do projeto. Para este grfico, a curva
azul representa a estimativa de esforo necessrio para finalizar as tarefas remanes-
centes na iterao atual e a linha amarela corresponde quantidade de funciona-
lidades remanescentes para serem codificadas e incorporadas ao incremento do
produto a ser entregue no fim da iterao.
captulo 4 104
Sprint 0404 - Grfico Burndown da Equipe Esforo remanecentes Tarefas remanecentes
500
450
400
350
300
250
200
150
100
50
0
31 r
ar
br
br
br
br
br
br
r
ne
a
/ab
/ab
/ab
/ab
/ab
/ab
/ab
/m
/m
1/a
2/a
5/a
6/a
7/a
8/a
do
12
13
14
15
16
19
20
30
Figura 4.5 Quadro de cartes de funcionalidades. (POPPENDIECK, M.;

Construir integridade
A integridade do sistema percebida a partir do funcionamento regular dos

conceitos centrais do sistema, como arquitetura bem estruturada, boa usabilidade,
utilidade, adaptabilidade e flexibilidade.
Visualizar o todo
O ltimo princpio proposto pelo desenvolvimento enxuto de software est

atrelado necessidade de ver o produto como um todo e no como partes isola-
das. comum que os especialistas trabalhem com o foco apenas nas nuances que
fazem parte do seu entendimento, o que pode dificultar a manuteno da inte-
gridade do sistema. O foco deve ser a busca pelo melhor desempenho do sistema
como um todo e no de partes isoladas do sistema.
captulo 4 105
XP
Conceitos e Definies
Extreme Programming (XP) uma metodologia gil de desenvolvimento adap-

tativa e flexvel, sendo indicada para ambientes caticos, onde os requisitos mu-
dam com frequncia e tecnologia desconhecida. Alm disto, por ser dividida em
pequenos ciclos de algumas semanas, que geram resultados capazes de agregar va-
lor ao negcio do cliente, XP uma boa sada para projetos que precisam realizar
entregas para os clientes em curtos espaos de tempo.
Sommerville
Em Extreme Programming, os requisitos so descritos como cenrios (chamados de
histrias do usurio), que so implementados diretamente como uma srie de tarefas.
Os programadores trabalham em pares e desenvolvem testes para cada tarefa antes
de escreverem o cdigo. Quando o novo cdigo integrado ao sistema, todos os
testes devem ser executados com sucesso. H um curto intervalo entre os releases
do sistema.

2011, pgina 44.
A figura 4.6 mostra o ciclo de um release em Extreme Programming. Na abor-

dagem em questo, inicialmente as histrias de usurios previamente especificadas
so escolhidas para compor a release. As histrias de usurio so as descries
textuais das funcionalidades e devem ser definidas e priorizadas, com a ajuda
do cliente, de acordo com as necessidades do negcio e o tempo e o custo da
implementao.
Selecionar histrias
Dividir histrias
do usurio para Planejar release
em tarefas
este release
Desenvolver/
Avaliar Liberar
integrar/
sistema software
testar software
Figura 4.6 Ciclo de um release em Extreme Programming. (SOMMERVILLE, I., 2011)
captulo 4 106
Na sequncia, as histrias de usurio so detalhadas na forma de uma lista de
atividades necessrias para seu funcionamento. No planejamento, as tarefas so
estimadas e distribudas entre as duplas da equipe para que sejam desenvolvidas,
integradas e testadas. Se necessrio, o cdigo refeito ou corrigido. Por fim uma
nova verso executvel j atualizada disponibilizada para toda a equipe e poste-
riormente, avaliada pelos clientes.
Valores, Papis, Princpios e Prticas do XP
No desenvolvimento de sistemas, necessrio que a equipe tenha em mente

sempre o que realmente importa para que o produto seja produzido de forma
satisfatria. Mas o que realmente importa na construo de um software? Nesse
quesito podemos compilar diferentes opinies sobre o tema: algumas pessoas da
equipe podem achar que o que realmente importa a documentao excessiva
do projeto. Outros podem afirmar que o cdigo o artefato mais importante e
deve ser o foco. Falando ainda sobre cdigo, cada um na equipe pode revelar um
estilo de programao que seja completamente diferente dos demais. Toda essa
problemtica pode fazer com que o time no caminhe em uma direo nica na
conduo do projeto.
Para minimizar o problema, o arcabouo XP se baseia em cinco valores (co-
municao, feedback, coragem, simplicidade e respeito) para guiar o desenvolvi-
mento e, consequentemente, fazer com que a equipe se concentre no que realmen-
te importa no contexto gil.
A importncia da comunicao em projetos essencial a partir do momento
em que os desenvolvedores devem compreender os anseios do cliente e os clientes
devem tambm entender as limitaes e desafios tcnicos envolvidos no projeto.
Neste contexto, o cliente apresenta um problema que deve ser solucionado com
o sistema desenvolvido e possui as ideias sobre que funcionalidades podem fazer
parte do sistema. Por sua vez, a equipe de desenvolvimento possui os conhecimen-
tos tcnicos que podem influenciar a soluo para o problema do cliente.
O sucesso da comunicao entre os cliente e membros da equipe depende
do canal utilizado. Preferencialmente, o dilogo presencial deve ser o canal de
comunicao mais usado, j que este meio facilita a compreenso entre as partes a
partir da utilizao de elementos como gestos, expresses faciais, postura, palavras
verbalizadas, tom de voz, emoes entre outros. Conversas cara-a-cara so sempre
melhores do que videoconferncias, telefonemas, e-mails, cartas ou fax.
captulo 4 107
Outro importante valor em XP o feedback. As respostas s decises tomadas
devem ser rpidas e visveis. Lavando isso em considerao, projetos desenvolvidos
com XP devem observar os resultados obtidos a partir de uma tarefa executada o
mais rpido possvel. Um exemplo disso a utilizao de releases curtos para que
o cliente observe mais rapidamente as funcionalidades pedidas. Alm disto, os
clientes, ao se manterem prximos, acabam validando e encontrando problemas
mais cedo no processo de desenvolvimento.
Em ambientes caticos, a mudana uma constante. muito comum que
os clientes revejam as suas necessidades de tempos em tempos e, inevitavelmente,
faam com que partes desenvolvidas do produto sejam revistas. Sobre este aspecto,
a equipe de desenvolvimento tem duas opes: frear a criatividade do cliente e
seguir com o planejado anteriormente ou acomodar a mudana. A primeira opo
no a ideal, j que, ao no adaptar o sistema s novas necessidades dos usurios,
o produto final pode ser um software sem utilidade. Em outras palavras, o sistema
pode se tornar obsoleto antes mesmo do seu uso.
Desta forma, a equipe deve aprender a lidar com o risco de mudanas como
algo natural. Desta forma, XP prega o valor da coragem, como sendo o sentimen-
to que o time tem em relao a essas mudanas. A equipe confia na acomodao
de novas funcionalidades e na alterao de funcionalidades antigas a partir do
momento que o arcabouo dispe de mecanismos de proteo como desenvolvi-
mento orientado a testes, programao em par e integrao contnua.
Para que mudanas sejam fceis de serem realizadas e principalmente para
que as necessidades dos usurios sejam mais rapidamente atendidas, o XP prega o
valor da simplicidade. Este valor est ligado diretamente ao conceito do desenvol-
vimento enxuto de software, baseado no mtodo Toyota de produo, que afirma
que no se deve produzir mais do que o necessrio. Extreme programming utiliza
o conceito de simplicidade para que a equipe se concentre em realizar o trabalho
estritamente necessrio, evitando fazer o que ainda no se provou como essencial.
Por fim, o respeito se mostra como um valor base, que envolve todos os de-
mais j discutidos. Todos tm sua importncia dentro da equipe e devem ser res-
peitados e valorizados para que juntos consigam atingir o objetivo final, que a
entrega de um produto com qualidade e que atenda s necessidades dos usurios.
captulo 4 108
Prticas do XP
O Extreme Programming aborda diversas prticas que refletem os princpios

da metodologia gil. Em projetos realizados com XP, o desenvolvimento deve ser
incremental para que haja entregas frequentes. No arcabouo de processo, os in-
crementos so representados por pequenos releases. Alm disto, a funcionalidade
includa baseada em cenrios especificados pelos usurios.
Releases curtas permitem que os clientes permaneam envolvidos de forma
contnua, especificando histrias do usurio e contribuindo com os testes de acei-
tao. As pessoas se tornam mais importantes do que o processo, sendo susten-
tadas por programao em pares, propriedade coletiva do cdigo do sistema e
um processo de trabalho que no envolve uma carga excessiva, como a utilizao
de horas extras. Como j discutido, as mudanas so acomodadas por meio dos
releases contnuas e do desenvolvimento guiado por testes. Por fim, a refatorao
constante aumenta a qualidade e promove simplicidade. Todas as prticas do XP
esto resumidas na tabela a seguir.
PRTICA DESCRIO
Os requisitos so gravados em cartes de histrias e
as histrias que sero includas em um release so
Planejamento incremental determinadas pelo tempo disponvel e sua relativa
prioridade. Os desenvolvedores dividem essas hist-
rias em tarefas.
Em primeiro lugar, desenvolve-se um conjunto mnimo

de funcionalidades til, que fornece o valor do neg-
Pequenos releases
cio. Releases do sistema so frequentes e gradual-
mente adicionam funcionalidades ao primeiro release.
Cada projeto realizado para atender s necessida-

Projeto simples
des atuais, e nada mais.
Um framework de testes iniciais automatizados

usado para escrever os testes para uma nova fun-
Desenvolvimento test-first
cionalidade antes que a funcionalidade em si seja
implementada.
captulo 4 109
PRTICA DESCRIO
Todos os desenvolvedores devem refatorar o cdigo
Refatorao continuamente assim que encontrarem melhorias de
cdigo. Isso mantm o cdigo simples e manutenvel.
Os desenvolvedores trabalham em pares, verificando

Programao em pares o trabalho dos outros e prestando apoio para um bom
trabalho sempre.
Os pares de desenvolvedores trabalham em todas

as reas do sistema, de um modo que no se desen-
volvam ilhas de expertise. Todos os conhecimentos e
Propriedade coletiva
todos os desenvolvedores assumem responsabilidade
por todo o cdigo. Qualquer um pode mudar qualquer
coisa.
Assim que o trabalho em uma tarefa concludo, ele

integrado ao sistema como um todo. Aps essa inte-
Integrao contnua
grao, todos os testes de unidade do sistema devem
passar.
Grandes quantidades de horas-extras no so consi-

deradas aceitveis, pois o resultado final, muitas vezes,
Ritmo sustentvel
a reduo da qualidade do cdigo e da produtividade
a mdio prazo.
Um representante do usurio final do sistema (o clien-

te) deve estar disponvel todo tempo equipe de XP.
Em um processo de Extreme Programming, o cliente
Cliente no local
um membro da equipe de desenvolvimento e res-
ponsvel por levar a ela os requisitos de sistema para
implementao.
Tabela 4.4 Prticas do Extreme Programming. (SOMMERVILLE, I., 2011)
Alm das prticas enumeradas por Sommerville (2011), podemos acrescentar

mais trs: Metfora, Padres de codificao e Testes do usurio, como exposto na
figura 4.7.
captulo 4 110
Equipe
Inteira
Propriedade Padronizao
Coletiva de Cdigo
Desenvolvimento
Orientado a teste
Testes de Programao Jogos de
Refatorao
Usurio em Par Planejamento
Design
Integrao Simples Ritmo
Contnua Sustentvel
Metfora
Entregas
Curtas
Figura 4.7 Boas prticas em Extreme Programming.
Metfora faz aluso definio das histrias do usurio, que deve usar termos
do negcio para que os desenvolvedores se comuniquem melhor com o cliente.
A padronizao da codificao deve ser adotada por toda a equipe para facilitar a
compreenso do cdigo e a comunicao entre desenvolvedores. O cdigo deve
ser o mais claro possvel para minimizar a necessidade de documentao adicional.
Por fim, os testes de usurio esto relacionados validao das funcionalidades
pelo cliente, o mais rpido possvel.
Papis do XP
Em projetos geis, as equipes envolvidas devem ser autossuficientes. Desta for-

ma, importante que o grupo responsvel por construir o produto consiga reunir
as habilidades tcnicas e de negcio necessrias para o desenvolvimento. Porm,
isso no quer dizer que todos os integrantes devem possuir todas as habilidades,
captulo 4 111
mas sim que a equipe no deve precisar de ajuda externa ao projeto para realizar
as tarefas necessrias.
Outro ponto importante que os membros da equipe devem ser autogeren-
civeis. Neste sentido, a estruturao do grupo em hierarquias desencorajada,
no sendo recomendada a diviso de tarefas. comum que no incio do projeto
as pessoas tenham uma inclinao para a realizao de tarefas que fazem parte da
sua especialidade. Desta forma, pessoas com experincia em especificao, ten-
dem a trabalhar de acordo com esse perfil. Da mesma forma, indivduos que so
reconhecidos como bons programadores iro desempenhar tarefas relacionadas
codificao do produto.
Com o tempo, a partir dos princpios do XP, naturalmente o conhecimento
dentro da equipe disseminado, fazendo com que os membros se sintam von-
tade de realizar tarefas at ento fora das suas especialidades. Esse fato relevante
para garantir que o conhecimento no seja concentrado em determinados indiv-
duos dentro do projeto, o que causa dependncia.
De forma geral, os principais papis assumidos em projetos que utilizam
Extreme Programming so: programador, coach, tracker e testador. Os programa-
dores so a maioria da equipe e tem como principal responsabilidade a produo
do cdigo executvel, alm da elaborao dos testes de unidade. Por sua vez, o
coach o programador mais experiente do grupo e tem a responsabilidade de as-
segurar que as prticas e princpios do XP esto sendo realizados da forma correta.
O tracker o programador que possui a funo de manter a equipe atualizada em
relao ao progresso do projeto e por mostrar pontos que devem ser melhorados.
Por fim, o testador o integrante responsvel por garantir que o produto est bom
o suficiente para ser entregue ao cliente, a partir de realizao de verificaes e
validaes.
Vale a pena enfatizar que o cliente parte da equipe na abordagem XP. As
suas responsabilidades esto atreladas s atividades necessrias para a compreenso
do negcio, priorizao das funcionalidades e validao constante do que cons-
trudo. O ideal que a interao entre o cliente e a equipe seja realizada a todo o
momento no decorrer do projeto.
PAPIS NO XP
Responsvel por produzir o cdigo
Programador
executvel.
captulo 4 112
PAPIS NO XP
Responsvel por garantir que as pr-
Coach ticas e princpios do XP esto sendo
praticados.
Responsvel por atualizar a equipe em

Tracker
relao ao progresso do projeto.
Responsvel pelas tarefas de verificao

Testador
e validao dentro do projeto.
Responsvel por detalhar as questes

Cliente relacionadas ao negcio, priorizar as fun-
cionalidades e validar as entregas.
Tabela 4.5 Papis no Extreme Programming.
Princpios do XP
Na abordagem XP, os princpios so utilizados para ligar os valores s prticas,

servindo como um guia. So eles: auto-semelhana, benefcio mtuo, diversidade,
economia, falha, fluidez, humanismo, melhoria, oportunidade, passos de beb,
qualidade, redundncia, reflexo e responsabilidade aceita.
PRINCPIOS DO XP
Ao encontrar solues que funcionem em um contexto, equipes
Auto-semelhana XP devem tambm procurar adot-las em outros, mesmo que
em escalas diferentes.
As prticas do XP devem ser estruturadas de modo a serem

Benefcio mtuo mutuamente benficas para todos os envolvidos em um projeto
de software.
Em projetos XP, a diversidade de habilidades, abordagens e opi-

Diversidade
nies deve ser encorajada.
XP reconhece que se investe em software com a expectativa de

Economia que gere retornos para os negcios. Suas prticas so organi-
zadas para antecipar receitas e adiar despesas.
captulo 4 113
PRINCPIOS DO XP
Na dvida, falhe! Desenvolvimento de software sempre vem
Falha acompanhado de novos problemas, muitos dos quais no temos
ideia de como resolver em princpio.
O que se busca em XP estabelecer um fluxo contnuo de va-

lor. Ao invs de impor obstculos, atravs de etapas bem de-
finidas, herdadas de uma adaptao equivocada das prticas
Fluidez
da engenharia civil, o que se faz permitir que o desenvolver
aprenda sobre um requisito e avance rapidamente para a imple-
mentao do mesmo.
XP coloca as pessoas no centro do esforo de desenvolvimento

Humanismo e suas prticas so voltadas para potencializar o melhor que
podem oferecer, bem como suprimir suas falhas.
No devemos nos preocupar em construir o software per-

feito, nem o design perfeito, nem o processo perfeito, mas
Melhoria
sim em aperfeioar esses e outros aspectos dos projetos
continuamente.
Em XP, no esperamos que tudo d certo no projeto. Temos

conscincia de que eventos inesperados podem e iro aconte-
Oportunidade
cer. Quando esse for o caso, queremos que todos aprendam ao
mximo e, juntos, criem as melhores solues.
Passos de beb determinam que melhor avanar um pouqui-

Passos de beb nho de cada vez, com segurana, que tentar dar grandes passos
sem validar suas consequncias.
Extreme Programming gera valor rapidamente e evita desper-

Qualidade dcios ao mximo. Software de m qualidade representa uma
enorme perda
Os problemas difceis e crticos em desenvolvimento de soft-

ware devem ser resolvidos de vrias formas diferentes. Mesmo
Redundncia
que uma soluo falhe completamente, as outras solues iro
prevenir um desastre.
Boas equipes no apenas fazem seu trabalho, mas tambm

pensam sobre como esto trabalhando e por que esto tra-
Reflexo balhando. Elas analisam o porqu de terem tido sucesso ou fa-
lhado. Elas no tentam esconder seus erros, mas os expem e
aprendem com eles.
captulo 4 114
PRINCPIOS DO XP
Responsabilidade no pode ser atribuda; ela s pode ser acei-
Responsabilidade
ta. Se algum tenta te dar uma responsabilidade, s voc pode
aceita
decidir se responsvel ou no.
Tabela 4.6 Princpios do Extreme Programming.
Ciclo de vida de um Projeto de Programao XP
Um projeto desenvolvido a partir da abordagem XP apresenta diversas fa-

ses, como explorao, planejamento, iteraes at verso, produo manuteno
e morte. As tarefas e artefatos envolvidos podem ser visualizados na figura 4.9.
Explorao Planejamento Iteraes at verso Produo Manuteno Morte
Reviso contnua
Atualizaes
regulares Estrias
para
prxima Programao em pares
iterao
Planejamento
para teste
Anlise
Projeto
Anlise
Verso Final
Estimativas de esforo
Estrias
Prioridades
Integrao
Feedback contnua Pequena Verses
Verso Atualizadas
Teste Base de
dados
coletiva
Figura 4.8 Ciclo de Vida Extreme Programming. Fonte:<http://www2.dc.ufscar.

br/~junia/MetAgEds.pdf>.
Fase de Explorao
A fase de explorao tem como objetivo verificar a viabilidade do projeto a

partir da anlise dos requisitos iniciais. neste momento que as funcionalidades
e caractersticas do produto so detalhadas para que todos os envolvidos tenham
uma melhor ideia do que deve ser construdo.
captulo 4 115
Fase de Planejamento
Na fase de planejamento as histrias de usurio so definidas e priorizadas.

Alm disto, cada histria estimada em relao sua complexidade. Histrias de
usurio mais complexas devem ser implementadas primeiro. Neste momento de-
vem ser definidos o tempo de iterao e de release. Cada iterao pode ser realizada
de uma a trs semanas, enquanto a release deve ter de dois a quatro meses.
Fase de Iterao
A fase de iterao a etapa de concentrao das atividades de engenharia do

produto. A equipe deve realizar de forma contnua e iterativa as atividades de an-
lise, projeto, implementao e testes a partir dos princpios, valores e prticas do
XP. Normalmente a primeira iterao tende a ser mais longa j que o problema e as
tecnologias envolvidas ainda podem ser desconhecidos. Com o tempo de projeto,
a equipe vai amadurecendo as estimativas e as iteraes podem passar a ter um
tempo mais curto.
Fase de produo
Aps o final de cada release, o produto parcial deve ser integrado e disponibili-
zao em ambiente similar ao de produo. O objetivo realizar testes em relao
ao desempenho e comportamento do software. Testes de aceitao podem ser rea-
lizados para que o cliente valide a entrega.
Fase de Manuteno
A fase de manuteno marcada pela acomodao de mudanas necessrias

para fazer com que o software continue sendo til ao cliente. Neste momento,
novas funcionalidades podem ser adicionadas ao produto, como tambm erros
podem ser corrigidos. Alm disto, o cdigo pode ser melhorado ou adaptado a
novos contextos. importante que alteraes nesta fase sejam realizadas com cau-
tela, j que erros podem ser inseridos no sistema, causando prejuzo aos clientes.
captulo 4 116
Fase de Morte
A fase da morte caracterizada pelo encerramento do projeto. A finalizao

das atividades em um projeto XP pode ocorrer por duas razes: o cliente pode
estar satisfeito ao ponto de no precisar de novas alteraes ou o sistema est
deteriorado a um ponto em que manutenes j so complexas de ser realizadas,
tornando a continuao do projeto invivel economicamente.
ATIVIDADES
01. O desenvolvimento gil de software guiado por metodologias que compartilham um
conjunto comum de valores e de princpios, conforme definido pelo Manifesto gil. Assinale
a opo que indica um princpio do desenvolvimento gil.
a) As mudanas nos requisitos devem ocorrer dentro do quadro de tempo estabelecido
para a iterao
b) O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de
desenvolvimento por meio de conversa face a face.
c) Os intervalos regulares devem ser evitados para tornar a equipe mais eficaz e maximizar
a quantidade de trabalho realizado.
d) As pessoas de negcio e desenvolvedores devem interagir somente no incio de cada
iterao.
e) A entrega contnua e adiantada de software, mesmo que o conjunto de funcionalidades
desenvolvidas no agregue valor, deve ser feita para satisfazer o cliente.
02. Como o desenvolvimento enxuto de software atua na construo do desenvolvimento

gil de sistemas?
03. NO uma caracterstica da Extreme Programming (XP):

a) simplicidade. e) documentao extensa e abundante
b) agilidade. em artefatos.
c) desenvolvimento orientado a testes.
d) programao em par.
captulo 4 117
04. Determinado projeto de software utiliza XP (Extreme Programming) como metodologia
de desenvolvimento. A esse respeito, INCORRETO afirmar que:
a) o cliente participa ativamente e acompanha os passos dos desenvolvedores diariamente.
b) os integrantes da equipe se renem rapidamente no incio do dia, de preferncia em p.
c) a equipe de desenvolvimento concentra esforos naquilo que gera maior valor para
o cliente.
d) a programao em pares dispensa o desenvolvimento orientado a testes no projeto.
e) as funcionalidades do software so descritas em histrias, da forma mais simples possvel.
05. Assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que claramente
necessrio e evite fazer o que poderia vir a ser necessrio, mas ainda no se provou essen-
cial. Este um dos cinco valores fundamentais do XP (Extreme Programming), denominado:
a) coragem. d) simplicidade.
b) respeito. e) feedback.
c) comunicao.
REFLEXO
Neste captulo estudamos os princpios de metodologias geis a partir da anlise do ma-
nifesto gil. Estes princpios norteiam abordagens como a extreme programming e o Scrum.
Continuamos nossos estudos entendendo a desenvolvimento rpido de software, criado a
partir da metodologia Toyota de produo. Aprofundamos o entendimento de gil a partir do
estudo detalhado sobre XP a partir dos seus valores, papis, princpios e prticas. Por fim,
detalhamos o ciclo de vida XP.
importante que, baseado nos conceitos apresentados, voc seja capaz de identificar
as vantagens e desvantagens de metodologias geis. Os conhecimentos adquiridos sero
importantes para o entendimento da abordagem Scrum, foco do nosso estudo no prximo
captulo.
LEITURA
Para voc avanar mais o seu nvel de aprendizagem envolvendo os conceitos de
extreme programming e demais assuntos deste captulo, consulte o captulo 3 do livro:
captulo 4 118
LARMAN, Craig. Agile & Iterative Development: A Managers Guide. Addison-Wesley, 2003.
HIGHSMITH, Jim. Agile Software Development Ecosystems. Adisson-Wesley, 2002.
FRANCO, Eduardo Ferreira. Um modelo de gerenciamento de projeto baseado nas
metodologias geis de desenvolvimento de software e nos princpios da produo enxuta.
So Paulo, 2007. Disponvel em: http://www.teses.usp.br/teses/disponiveis/3/3141/tde- 09012008-
155823/pt-br.php Acesso em: 04 de agosto de 2016.
SHINGO, S. Study of Toyota Production System from Industrial Engineering Viewpoint: Produce
What Is Needed, When Its Needed. Cambridge: Productivity Press, 1981. 291 p.
POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: An Agile Toolkit for
Software Development Managers. Primeira Edio. Boston: Addison-Wesley Professional, 2003. 240 p.
captulo 4 119
captulo 4 120
5
Scrum
Scrum
O framework Scrum surgiu na dcada de 90, porm a sua popularizao
mais recente. At os anos 2000 as abordagens tradicionais ainda eram imperativas.
Somente a partir desse perodo que os mtodos geis tornaram-se uma forma bem
sucedida de desenvolver sistemas.
Projetos que utilizam o Scrum possuem 3,5 vezes mais chances de sucesso do
que outros projetos (The Standish Group, 2015). Isso no dignifica que a adoo
do framework garante que problemas no iro acontecer. Muitas das vantagens
proporcionadas pela abordagem s podero ser percebidas caso a ferramenta seja
bem utilizada. Neste captulo vamos estudar os conceitos gerais do Scrum, seus
papeis, artefatos e eventos. Por fim vamos analisar a abordagem Kanban.
OBJETIVOS
Aprender os conceitos bsicos de Scrum;
Entender os papis envolvidos no Scrum;
Conhecer os artefatos presentes no Scrum;
Entender o ciclo de vida do XP;
Aprender os conceitos de Kanban.
Introduo ao Scrum
Sabbagh
Scrum e um framework gil, simples e leve, utilizado para a gesto do desenvolvi-
mento de produtos complexos imersos em ambientes complexos. Scrum e embasado
no empirismo, e usa uma abordagem iterativa e incremental para entregar valor com
frequncia, assim, reduzindo os riscos do projeto.
FONTE: SABBAGH, R. Scrum: Gesto gil para projetos de sucesso, 2016, pgina 19.
O Scrum uma abordagem utilizada principalmente no desenvolvimento de

sistemas que apresentam um contexto instvel do ponto de vista dos seus requisi-
tos e utilizao de tecnologia. Desta forma, o framework se encaixa em situaes
onde as mudanas ocorrem frequentemente. Com o objetivo de reduzir os riscos
captulo 5 122
inerentes a projetos que necessitam se adequar constantemente a mudanas, a
abordagem em questo foca na entrega de valor e na comunicao. Como conse-
quncia do seu uso, a qualidade do produto entregue e o aumento da produtivi-
dade da equipe pode ser percebida. Vale a pena destacar que muitos dos conceitos
da abordagem no so inditos na literatura. Podemos perceber a influncia de
prticas geis presentes em outras abordagens e no manifesto gil.
Planejamento Reunio Reviso Retrospectiva
da Sprint diria da Sprint da Sprint
24
horas
Produto Sprint
Viso
Backlog Backlog
2-4 Produto
semanas
Legenda:
Eventos
Artefatos 80
60
40
20
Papis Eventos (Reunies) Artefatos 0

1 2 3 4 5 6 7 8 9 101112
Product Owner (PO) Planejamento da Release Product Backlog 80

60
ScrumMaster (SM) Planejamento da Sprint Sprint Backlog 40

20
Equipe Scrum Diria Sprint Burndown 0

1 2 3 4 5 6 7
Reviso da Sprint Release Burndown

Retrospectiva da Sprint Sprint Burndown e
Release Burndown
Figura 5.1 Ciclo do trabalho Scrum.
Pressman
Os princpios do Scrum so consistentes com o manifesto gil e so usados para
orientar as atividades de desenvolvimento dentro de um processo que incorpora as
seguintes atividades estruturais: requisitos, anlise, projeto, evoluo e entrega. Em
cada atividade metodolgica ocorrem tarefas a realizar dentro de um padro de pro-
cesso chamado Sprint. O trabalha realizado dentro de uma Sprint (o nmero de Sprints
necessrios para cada atividade metodolgica varia dependendo do tamanho e da
complexidade do produto) adaptado ao problema em questo e definido, e muitas
vezes modificado em tempo real, pela equipe Scrum.
FONTE: PRESSMAN, R. S. Engenharia de Software. 7 Edio. Editora McGraw

Hill, 2011, pgina 95.
captulo 5 123
O ciclo do trabalho Scrum pode ser visto na figura 5.1. A abordagem tem
como ponto de partida as necessidades funcionais e no funcionais dos clientes e
usurios. importante que o produto a ser construdo possua uma viso estrat-
gica a partir de um Roadmap e tambm uma lista priorizada dos requisitos que
forma o Backlog do produto. O papel responsvel por manter estes artefatos o
dono do produto (Product Owner).
O Roadmap do Produto simboliza o planejamento em um grau de abstrao
maior do produto. Este artefato mostra como o produto deve evoluir estrategica-
mente ao longo do tempo a partir da definio de objetivos a serem realizados. Na
prtica, o artefato pode ser visto como uma linha de tempo que contm marcos e
metas do produto a serem realizadas, como exposto na figura 5.2.
hoje marco #1 marco #2 marco #3 marco #4 marco #5
Meta #1 Meta #2 Meta #3 Meta #4 Meta #5
Figura 5.2 Exemplo de roadmap do produto. (SABBAGH, R. Scrum: Gesto gil para
projetos de sucesso, 2016, pgina 270)
Por sua vez, o Backlog do produto a lista dos requisitos do produto, no

sendo necessrio estar completo no incio do desenvolvimento. O ideal que a
construo do software tenha incio a partir das necessidades conhecidas. Com o
decorrer do projeto, o Backlog do produto deve crescer. As necessidades contidas
no artefato podem estar definidas a partir de histrias de usurio ou casos de uso.
A partir do momento que o time possui o Backlog do produto definido, pode-
se realizar o planejamento da Sprint. A cerimnia em questo consiste em uma
reunio com a presena do dono do produto, do lder do projeto e do time, alm
de qualquer pessoa interessada que esteja representando a gerncia ou o cliente.
Durante a reunio, o dono do produto deve detalhar os requisitos de maior prio-
ridade para o time. A proposta que a equipe consiga quebrar as funcionalidades
em tarefas que formaro o Backlog do Sprint.
As Sprints so formadas por tempos fixos que podem variar de uma a quatro
semanas. A partir do momento que, no incio do projeto, ficou decidido o tempo
da Sprint, este nmero no pode ser alterado durante todo o processo de desen-
volvimento. Durante as Sprints, o lder do projeto (Scrum Master) deve conduzir
as reunies dirias com o objetivo de disseminar conhecimento sobre o que foi
captulo 5 124
feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realiza-
do no dia que se inicia. tambm durante as Sprints que o grfico burndown
atualizado com o objetivo de monitorar o progresso do projeto em relao ao que
foi planejado no incio. Como podemos ver na figura 5.3, o eixo horizontal de
um grfico burndown mostra os Sprints e o eixo vertical mostra a quantidade de
trabalho que ainda precisa ser feita no incio de cada Sprint. O trabalho que ainda
resta pode ser mostrado na unidade preferencial da equipe: story points, dias ideais,
team days e assim por diante.
120
A linha azul
100 representa o
atual trabalho
Neste eixo 80 realizado.
vertical
mostrado a
quantidade de 60
trabalho a ser
completado. 40 A linha vermelha
a velocidade, que
20 representa a taxa
estimada de trabalho.
0
1-Jan 2-Jan 3-Jan 4-Jan 5-Jan
As datas ou dias de execuo ficam neste eixo
Figura 5.3 Exemplo de grfico burndown.
Ao final de todas as Sprints, o time deve realizar a reviso e a retrospectiva da

Sprint. O objetivo da reunio de reviso verificar a concluso dos itens presentes
no Backlog da Sprint. A validao deve ser realizada pelo dono do produto ou pelo
cliente, sendo a melhor maneira realizar uma apresentao, ao estilo demonstra-
o, de todos os itens concludos. Com isso, o dono do produto deve avaliar o que
est sendo considerado pronto, levando em conta o produto entregue e tambm o
que no foi disponibilizado.
Por fim, a reunio de retrospectiva tem como objetivo analisar a ltima Sprint
em relao s pessoas, relaes, processos e ferramentas. Alm disto, essa cerim-
nia deve identificar e ordenar os principais itens que foram bem e as potenciais
melhorias, alm de criar um plano para implementar melhorias no modo que o
time faz seu trabalho.
captulo 5 125
A figura 5.4 resume todos os conceitos apresentados at o momento. Ainda
neste captulo, iremos detalhar os papis, artefatos e eventos do Scrum.
O Scrum Master, PO e o time planeja o Sprint, Na segunda parte do Planning
essa reunio chamada de Planning Meeting, Meeting o objetivo decompor
que dividida em duas partes. Na primeira o as informaes do Selected
objetivo de gerar o Selected Product Backlog. Product Backlog em tarefas,
onde cada membro do time ir
selecionar a tarefa que deseja
executar e estim-la. Tais
tarefas iro gerar o Sprint
O PO junto com o Scrum Master Backlog.
cria o Product Backlog, uma
lista inicial de necessidades que O time ir comear o
precisam ser produzidas para trabalho do Sprint, de
que a viso do projeto seja bem acordo com o tempo
sucedida. estimado, realizando
em todos os dias
a Daily Scrum.
No trmino do Sprint
realizada a reunio de
Aps a reunio de Review feita a ltima Review. O objetivo
reunio do Sprint a Retrospectiva, com o apresentar o que foi
objetivo de levantar os pontos bons e ruins feito para o PO e
O PO (Product Owner) define a do Sprint. Geralmente apenas o Scrum convidados.
viso com base em informaes Master e o time participam, mas o PO
colhidas com o usurio final, tambm pode participar, caso todos
time, stakeholders, gerentes. estejam de acordo.
Figura 5.4 Papis, artefatos e eventos do Scrum.
De acordo com Sabbagh (2016), os benefcios no uso do Scrum incluem:

entregas frequentes de retorno ao investimento dos clientes; reduo dos riscos do
projeto; maior qualidade no produto gerado; mudanas utilizadas como vantagem
competitiva; visibilidade do progresso do projeto; reduo do desperdcio; e au-
mento da motivao e produtividade.
Entregas frequentes so caracterizadas pela quebra do projeto em incremen-
tos, possibilitando um maior envolvimento do cliente com o produto. Muitos
projetos ainda utilizam abordagens tradicionais que permitem que o produto seja
visualizado apenas no fim do desenvolvimento, quando mudanas so mais ca-
ras e difceis de serem realizadas. Com o desenvolvimento baseado em pequenos
incrementos, o cliente interage com o produto mais cedo, podendo perceber o
retorno do investimento ainda no comeo do projeto. Alm disto, a acomodao
de possveis alteraes passa a ser um processo natural na construo do produto.
captulo 5 126
Como consequncia da proximidade do cliente e constante validao, os ris-
cos do projeto so reduzidos, j que os problemas so percebidos e enfrentados
de forma antecipada. Apesar de no estipular um processo formal de gerenciamen-
to de riscos, a abordagem Scrum minimiza a probabilidade de insucesso do projeto
a partir do momento que foca na entrega do produto correto, desenvolvido com
base em feedback constante. Alm disto, possveis atrasos so eliminados atravs da
priorizao do escopo: o que realmente importa para o cliente construdo mais
cedo. Por fim, os riscos referentes a gargalos no desenvolvimento so minimizados
pelo fato da equipe ser multifuncional.
Outro benefcio apontado o aumento da qualidade do produto gerado.
Essa qualidade atingida a partir da utilizao de testes ao longo do desenvolvi-
mento, principalmente automatizados. Alm disto, a reviso do trabalho realizado
pela prpria equipe e a validao do cliente colaboram com o desenvolvimento de
um produto mais robusto.
A qualidade do produto final tambm pode ser percebida a partir da acomo-
dao das mudanas detectadas ao longo do processo. Desta forma, as alteraes
propostas agregam valor ao produto, passando a oferecer vantagem competitiva.
Por sua vez, a visibilidade do progresso do projeto se apresenta como con-
sequncia da forma transparente como os membros do time trabalham. Alm da
adoo de entrega frequentes, que faz com que o cliente acompanhe melhor o
progresso do projeto, outras cerimnias como a reunio diria e a retrospectiva
fazem com que a equipe tenha uma melhor ideia do que foi feito e do que ainda
necessita ser construdo.
Outro problema minimizado pela adoo do Scrum a reduo do desper-
dcio. A abordagem baseada na simplicidade, tendo como objetivo a utilizao
apenas dos artefatos que so necessrios ao desenvolvimento do produto, a pro-
duo apenas das funcionalidades que sejam necessrias aos usurios e o planeja-
mento apenas com o nvel de detalhe possvel para o momento. Dos problemas
citados, podemos destacar a importncia da priorizao das funcionalidades a
serem implementadas. A partir da figura 5.5, percebe-se que cerca de 80% das
funcionalidades contidas no produto no so exercidas com frequncia, sendo que
45% nunca so utilizadas. Desta forma, fica claro como o desperdcio pode ser
presente na vida til de um software.
captulo 5 127
Sempre
7% Nunca
Com frequncia
13% 45%
s vezes
16%
Raramente
19%
Figura 5.5 Percentual de uso das funcionalidades em software, de acordo com o presidente
do Standish Group em 2002. (SABBAGH, R. Scrum: Gesto gil para projetos de sucesso, 2016)
Por fim, o aumento da motivao e produtividade potencializado a partir

de diversos fatores como: o trabalho em equipe e a autonomia do time na reali-
zao desse trabalho; a existncia de facilitao e de remoo de impedimentos; a
melhoria continua dos processos de trabalho; um ritmo sustentvel de trabalho e
a realizao do trabalho de ponta a ponta.
Papis no Scrum
Time de
desenvolvimento
Papis do
Product Owner
Scrum
Scrum Master
Figura 5.6 Papis no Scrum. (SABBAGH, R. Scrum: Gesto gil para projetos de sucesso, 2016)
Diferente de abordagens tradicionais, como o RUP, que possuem diversos papis

especializados dentro do processo de desenvolvimento, o Scrum apresenta apenas
captulo 5 128
trs papeis: o time de desenvolvimento, o Scrum Master e o Product Owner (PO)
Todos os papis so responsveis pelo sucesso do produto a partir do momento que
todos so comprometidos com os resultados dos trabalhos. Os membros do time
de desenvolvimento, o Product Owner e o Scrum Master formam o time de Scrum.
Sabbagh
Um time ou uma equipe um grupo de pessoas que trabalham juntas e colaboram em
busca de um objetivo comum. Portanto, o time de Scrum, ou seja, time de desenvolvi-
mento, Product Owner e Scrum Master, devem colaborar lado a lado, em seu dia a dia
de trabalho, em busca do objetivo comum de atingirem o sucesso do projeto, em cada
passo para chegarem l.
FONTE: SABBAGH, R. Scrum: Gesto gil para projetos de sucesso, 2016,

pgina 86.
Com relao s atividades, de forma geral, como exposto na figura 5.7, o

Product Owner participa das tarefas relacionadas ao planejamento e esclarecimen-
to das funcionalidades. Por sua vez, o Scrum Master atua no planejamento e no
progresso das tarefas. Por fim, o time de desenvolvimento solicita esclarecimentos
junto ao PO e tambm participa do progresso do produto.
Product Owner
Planejamento Esclarecimento
SCRUM
Equipe de
Scrum Master
Desenvolvimento
Progresso
Figura 5.7 Atividades gerais versus papis.
captulo 5 129
Time de desenvolvimento
O Time de Desenvolvimento o conjunto dos membros de um projeto gil.

De acordo com as definies do Scrum, o time de desenvolvimento deve ser au-
tocontido, ou seja, o grupo deve ser multidisciplinar para garantir que todo o tra-
balho necessrio vai ser realizado sem a necessidade de aquisies externas. Alm
disto, o time deve ser autogerencivel. Nesse sentido, cada indivduo responsvel
por monitorar o seu trabalho, incluindo poder de deciso em relao definio
tcnica de como o produto deve ser construdo, ao planejamento do trabalho e
acompanhamento do seu progresso. Desta forma, podemos dizer que o time
responsvel pelos seus resultados.
Sabbagh
O Time de Desenvolvimento gerencia o seu trabalho de desenvolvimento do produ-
to, balizado pelo framework Scrum. E ele que, mesmo que sujeito aos limites dados
pelo contexto do cliente e organizacional, determina tecnicamente como o produto
ser desenvolvido, planeja esse trabalho e acompanha seu progresso. Para tal, tem
propriedade e autoridade sobre suas decises e, ao mesmo tempo, e responsvel e
responsabilizado por seus resultados.

pgina 88.
As principais responsabilidades do time de desenvolvimento so:

Planejar a Sprint: inicialmente o time de desenvolvimento deve participar
do planejamento de cada Sprint com o objetivo de esclarecer possveis dvidas
sobre o escopo com o Product Owner. Alm disto, todo o Time Scrum deve estabe-
lecer a meta para o prximo Sprint. Como consequncia desta cerimnia, obtido
o Sprint Backlog.
Realizar Execuo Sprint: durante as Sprints, a equipe responsvel
por realizar as atividades de engenharia de software necessrias para a conclu-
so do produto, como a concepo, construo, integrao e testes de itens do
Product Backlog.
Realizar Inspeo e Adaptao: os membros da equipe de desenvolvimen-
to devem participar das reunies dirias com o objetivo de inspecionar o pro-
gresso da Sprint e expor possveis impedimentos em relao s suas atividades.
Caso membros do time no participem dessa cerimnia diariamente, o objetivo
da Sprint pode ser impactado.
captulo 5 130
Refinar o Product Backlog: a equipe de desenvolvimento atua junto ao
Product Owner no refinamento do Backlog do Produto e na estimativa e prioriza-
o dos itens e trabalho.
Participar da retrospectiva da Sprint: toda a equipe deve participar da
reunio de retrospectiva com o objetivo de apontar problemas na execuo das
atividades durante a Sprint corrente, como tambm ressaltar os pontos positivos
do trabalho.
Participar da reviso da Sprint: toda a equipe deve participar da reunio
de reviso com o objetivo de apresentar o resultado do trabalho realizado para o
Product Owner.
Para que as responsabilidades discutidas acima sejam assumidas com sucesso,

o time de desenvolvimento deve conter algumas caractersticas essenciais, confor-
me a figura 5.8.
Comunicao
Auto-Organizado
Frequente
Comunicao
Multi-Funcional
Transparente
Pessoal
Tamanho Certo
T-Shaped
Time de
Atitude Desenvolvimento Focado e
Mosqueteira Comprometido
Trabalho em ritmo
Entrosamento
Sustentvel
Figura 5.8 Caractersticas essenciais ao time de desenvolvimento.
A equipe de desenvolvimento deve ser auto-organizada. Na prtica, isso

quer dizer que os prprios membros do time devem escolher a melhor forma de
cumprir o objetivo da Sprint, sem a necessidade de um gerente de projetos estar
guiando e controlando o processo. Mas como os indivduos sabem exatamente o
que fazer para que o sucesso seja obtido? Em um ambiente complexo, como o de
projetos, o estabelecimento de um objetivo em comum e de regras simples fazem
captulo 5 131
com que a interao constante e o feedback culminem no encontro da melhor
forma de chegar ao ponto desejado.
Outro ponto importante que o time Scrum deve ser multifuncional. Nesse
sentido, os membros devem possuir o conjunto de habilidades necessrias para
construir durante a Sprint um potencial de entrega. Isso no quer dizer que todas
as pessoas envolvidas numa equipe gil devem saber de tudo, mas que as habilida-
des do grupo sejam suficientes para o desenvolvimento do sistema sem aquisies
externas. Equipes pouco plurais tender a fazer um trabalho incompleto e neces-
sitar de ajuda especializada. A diversidade dentro de um projeto tende a gerar
melhores resultados em termos de solues mais rpidas. Alm disto, as solues
propostas tendem a ter uma maior qualidade e inovao.
Nesse contesto, importante que os membros de um time Scrum tenham habi-
lidade em forma de T, ou T-shaped. Indivduos com essa habilidade so aqueles que
possuem um conhecimento slido em um determinado assunto especfico, porm
ao mesmo tempo tem a capacidade de compreender outros assuntos. Por exemplo,
imagine um indivduo que um exmio codificador. Apesar de conhecer a fundo pa-
dres de projetos e dominar linguagens de programao, o membro pode tambm
especificar histrias do usurio. Talvez ele no v construir as melhores histrias, mas
certamente ir ajudar o restante do time com o seu trabalho. Na figura 5.9, fica claro
a comparao entre pessoas generalistas, especialistas e T-shaped.
Generalista T-Shaped
Perfil Horizontal Eixo Horizontal
Habilidade de compreender vrias disciplinas, Habilidade de compreender vrias disciplinas
porm sem aprofundamento em nenhuma rea Ex.: Marketing, Vendas, Logstica, Produo Grfica
Especialista
Conhecimentos slidos em uma disciplina especfica
Aprofundamento em uma determinada rea,
desconhecimento de outras disciplinas
Ex.: Engenharia
Perfil Vertical
Perfil Vertical
Figura 5.9 Caractersticas de pessoas generalistas, especialistas e T-shaped.
captulo 5 132
Do ponto de vista de colaborao em grupo, ideal que todos tenham ati-
tude mosqueteira. O objetivo entender que a responsabilidade da entrega do
produto compartilhada entre os membros, e dessa todos devem colaborar para
que o objetivo final seja atingido. Essa caracterstica est intimamente ligada com
a necessidade da equipe ser t-shaped: a partir do momento que a equipe formada
por pessoas que possuem um perfil variado e, consequentemente, podem trabalhar
em diferentes tarefas, a colaborao passa a ser incentivada.
Ainda sobre as principais caractersticas de uma equipe Scrum, podemos des-
tacar a habilidade em se comunicar frequentemente. A informao dentro da
equipe deve ser repassada a todo o momento, seja para discutir impedimentos, seja
para validar o trabalho realizado. Da mesma forma, a transparncia na comuni-
cao deve ser permanente. Uma comunicao clara evita surpresas ao longo do
desenvolvimento do sistema e estabelece confiana entre os envolvidos.
Para que a comunicao seja eficaz, o tamanho do time deve ser limitado. A
abordagem Scrum preconiza que o tamanho das equipes no deve passar de nove
pessoas, sendo o mnimo de cinco. Equipes grandes levam a uma dificuldade de con-
trole e perda de qualidade na comunicao, enquanto que equipes pequenas podem
apresentar um conjunto de habilidades insuficientes para solucionar o problema.
Os membros da equipe tambm devem ser focados e comprometidos. Para
que isso acontea, no indicado que as pessoas trabalhem em mais de um tra-
balho simultaneamente. Da mesma forma, no interessante que a equipe seja
inserida em um ambiente de trabalho exaustivo, como por exemplo, onde a ne-
cessidade de realizao de horas extras seja constante. O ritmo da equipe deve ser
sustentvel, sob o risco de diminuir a qualidade dos produtos.
Por fim, interessante que haja entrosamento entre os indivduos. Um bom
entrosamento consequncia de um trabalho a longo prazo. Desta forma, reco-
mendvel que no haja uma forte rotatividade entre membros de equipes.
captulo 5 133
Produto Owner
Sabbagh
O Product Owner, tambm chamado de P.O., a pessoa responsvel pela definio do
produto, trabalho que realizado de forma incremental ao longo de todo projeto. Seu
objetivo primrio garantir e maximizar, a partir do trabalho do Time de Desenvolvi-
mento, o retorno sobre o investimento para os clientes do projeto, satisfazendo suas
necessidades com relao ao produto em desenvolvimento.

pgina 110.
A partir da definio de Sabbagh (2016), podemos afirmar que o

Product Owner representa um dos papis mais importantes no Scrum, j que exer-
ce a liderana sobre o produto, ao fazer a ponte entre o Time de Desenvolvimento
e o cliente, conforme a Figura 5.10.
Executivos
Scrum Master
Product Owner
Time de
Desenvolvimento
User
Figura 5.10 Papel do Product Owner.
Primeiramente, o trabalho do P.O. envolve o entendimento das necessidades

dos clientes e usurios. Alm disso, importante que ele atue na priorizao dos
itens do Backlog, garantindo que a soluo correta seja desenvolvida e que vai ter
utilidade. Da mesma forma, o P.O. deve manter uma forte comunicao com o
time Scrum, detalhando e validando os itens que representam os requisitos funcio-
nais e no funcionais do produto. O Product Owner tambm deve garantir que os
critrios para aceitao do produto esto especificados e que os testes que verificam
captulo 5 134
esses critrios foram executados para determinar que o produto (ou release) possa
ser considerado como pronto ao final do Sprint.
Dessa forma, podemos resumir as principais responsabilidades deste papel na
figura 5.11.
Definir Critrios de
Aceitao
Participao no Colaborar com Equipe
Planejamento de Desenvolvimento
Grooming do Colaborar com o

Product Backlog restante da Empresa
Product Owner
Figura 5.11 Responsabilidades do Product Owner.
O P.O. deve participar do planejamento do produto, do projeto e de cada

Sprint. No planejamento do produto, ele deve manter contato direto com os clien-
tes para garantir que as necessidades vo estar presentes no Backlog do produto.
No planejamento do projeto, o P.O. deve ajudar o restante do Time Scrum a
definir o escopo do trabalho e a priorizao dos itens do Backlog. Por fim, no
planejamento da Sprint, ele deve detalhar os itens e ajudar na estimativa, alm de
definir o objetivo da Sprint.
Nesse mbito, o P.O. o principal responsvel por criar, atualizar, estimar e
priorizar os itens do Backlog, o que chamamos de grooming do Product Backlog.
Alm disto, papel do P.O. definir os critrios de aceitao para cada item do
Backlog. Ao final de cada Sprint, a validao deve ser realizada com base nos cri-
trios definidos.
Para que o trabalho seja realizado com sucesso e o objetivo da Sprint seja cum-
prido, o P.O. deve manter contato frequente com o time de desenvolvimento. A
comunicao deve ser constante, diferentemente de abordagens tradicionais onde
a comunicao com o cliente prevalece apenas no incio e final da release, como
mostrado na figura 5.12. O problema da comunicao em projetos tradicionais
que muitas vezes as necessidades dos clientes podem no ser bem entendidas e
somente ao final, quando o custo de alteraes maior, que o erro percebido.
captulo 5 135
Envolvimento Cliente/Usurio
Scrum
Tradicional
Tempo Projeto
Figura 5.12 Envolvimento cliente/usurio em projetos.
Por fim, o P.O. deve colaborar com o restante da empresa, a partir do mo-
mento que uma das suas funes ser o porta-voz dos stakeholders.
Para que as responsabilidades descritas sejam assumidas, o P.O. deve possuir
as seguintes habilidades pessoais: conhecimento de negcio, habilidades com pes-
soas, autoridade e responsabilidade.
Conhecimento de Negcios Autoridade

Tem domnio do negcio Tem poder para tomar decises
um Visionrio incisivo nas decises
Sabe que nem tudo Product Owner Avalia de forma racional
precisa ser feito agora as decises
Habilidade com Pessoas Responsabilidade

Tem um bom relacionamento Assume a responsabilidade
com as pessoas pelo produto
um bom negociador comprometido com o resultado
Bom comunicador Atua como um
Motivador membro do time
Figura 5.13 Habilidades pessoais de um P.O.
CONCEITO
Aprenda mais sobre o Product Owner no vdeo a seguir: <https://www.youtube.com/
watch?time_continue=1&v=L_KX457DwaM>.
captulo 5 136
Scrum Master
Sabbagh
O Scrum Master trabalha para facilitar e potencializar o trabalho do Time de Scrum. Ou
seja, utilizando-se de seu conhecimento de Scrum, habilidade de lidar com pessoas,
tcnicas de facilitao e outras tcnicas, ele ajuda o Product Owner e Time de Desen-
volvimento a serem mais eficientes na realizao do seu trabalho.

pgina 124.
A partir da definio de Sabbagh (2016), podemos afirmar que o Scrum Master

tem como principal objetivo atuar como um coach de processo, ajudando a equipe
a compreender e executar da melhor forma os valores, princpios e prticas do
Scrum. As principais responsabilidades deste papel esto descritas na figura 5.14.
Escudo contra
Coach Scrum Interferncias
Master
Removedor de
Lder Servidor
Impedimentos
Autoridade no Agente de
Processo Mudanas
Figura 5.14 Responsabilidades do Scrum Master.
Alm de atuar como coach de processo, o Scrum Master deve ser um escudo
contra interferncias, blindando o Time de Desenvolvimento de qualquer evento
externo que possa atrapalhar o andamento das Sprints. Alm disto, ele deve atuar
como um lder servidor, se comprometendo com o trabalho de toda a equipe.
Outra importante tarefa do Scrum Master a remoo de impedimentos. A
remoo de qualquer obstculo que possa inibir a produtividade da equipe deve
ser realizada sempre que os prprios membros da equipe no podem remov-los.
Alm disso, importante que o Scrum Master domine o processo Scrum, se mos-
trando autoridade no processo. Por fim, como consequncia, os indivduos que exercem
captulo 5 137
este papel devem se mostrar como agente de mudanas dentro das organizaes. Para
muitas empresas, o mtodo de trabalho do Scrum uma mudana muito grande na cul-
tura de trabalho. O Scrum Master ajuda, ento, as pessoas a entenderem essas mudanas,
os impactos da adoo do Scrum e os benefcios que o Scrum pode ajudar a atingir.
Para que o trabalho do Scrum Master tenha sucesso, importante que ele
possua determinadas caractersticas, como exposto na figura 5.15.
Conhecimento Colaborativo
Questionador Protetor
Paciente Transparente
Figura 5.15 Caractersticas do Scrum Master.
Artefatos do Scrum
Nesta seo vamos discutir acerca dos principais artefatos do Scrum: Roadmap
do Produto, Backlog do Produto e Backlog da Sprint.
Roadmap do produto
O Roadmap do Produto um artefato que descreve como ser o produto a

cada perodo de sua evoluo. O seu maior objetivo auxiliar a organizao a
traar uma trajetria para seus produtos com base em objetivos de negcio, por
ordem de prioridade. Por ter uma viso estratgica, este artefato ajuda a comuni-
car aos interessados a viso de futuro que se tem para seus produtos.
captulo 5 138
Jul/2016 Dez/2016 Jan/2017
Release 1 Release 2 Release 3
Caracterstica 1 Caracterstica 2 Caracterstica

Melhoria A e B 3, 4 e 8 5, 6 e 7
Defeito X, Y e Z Melhoria C e F Melhoria D
Dbito Tcnico 31 Defeito W
Figura 5.16 Exemplo de Roadmap do Produto.
Para que o Roadmap ajude na conduo do produto, alguns aspectos devem ser ob-
servados na sua elaborao, como: agrupar os itens do Backlog do Produto por ordem
de prioridade, na quantidade compatvel com a capacidade de produo das equipes e
no tempo disponvel para o desenvolvimento; estabelecer uma cronologia de entregas
ou uma periodicidade; organizar reunies em que os envolvidos participem ativamen-
te da construo do Roadmap; e divulgar o Roadmap para todos os envolvidos.
Backlog do produto
SABBAGH
O Product Backlog e uma lista ordenada ou priorizada de itens sobre os quais o Time
de Desenvolvimento trabalhara no decorrer do projeto, desde os itens do topo da lista,
buscando realizar os objetivos do produto, comumente representados por uma Viso
de Produto. Ele atualizado, reordenado e refinado de acordo o nvel de detalhes que
e possvel de se ter em cada momento do projeto.

pgina 147.
A partir da definio acima, podemos entender o Product Backlog como sen-

do uma lista contendo todas as funcionalidades desejadas para um produto. Os
itens que compem o contedo desta lista so definidos pelo Product Owner. Um
ponto interessante para destacar que este artefato um documento vivo, sendo
captulo 5 139
alterado durante todo o projeto. Desta forma, o Product Backlog no precisa estar
completo no incio de um projeto. Pode-se comear com tudo aquilo que mais
bvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda
medida que se aprende mais sobre o produto e seus usurios (figura 5.17).
Maior Prioridade
Funcionalidades
Product
Backlog
Menor Prioridade
Figura 5.17 Backlog do Produto.
Backlog da Sprint
Sabbagh
O Sprint Backlog e uma lista de itens selecionados do alto do Product Backlog para o
desenvolvimento do Incremento do Produto no Sprint (o que), adicionada de um plano
de como esse trabalho ser realizado (como). O Sprint Backlog existe apenas no con-
texto de seu Sprint correspondente. Assim, ele e criado na reunio de Sprint Planning,
e deixa de existir aps as reunies de Sprint Review e Sprint Retrospective de seu
Sprint. O Sprint Backlog pertence ao Time de Desenvolvimento e uma importante
ferramenta utilizada por seus membros para organizarem o trabalho durante o Sprint.
Por essa razo, o Sprint Backlog deve ser de alta visibilidade.

pgina 157.
Como podemos perceber pela figura 5.18, os itens do Sprint Backlog so ex-
trados do Product Backlog, pela equipe, com base nas prioridades definidas pelo
Product Owner e a percepo da equipe sobre o tempo que ser necessrio para
completar as vrias funcionalidades. Cabe equipe determinar a quantidade de
itens do Product Backlog que sero trazidos para o Sprint Backlog, j que ela
quem ir se comprometer a implement-los. Durante um Sprint, o Scrum Master
mantm o Sprint Backlog atualizando-o para refletir que tarefas so completadas
e quanto tempo a equipe acredita que ser necessrio para completar aquelas que
captulo 5 140
ainda no esto prontas. A estimativa do trabalho que ainda resta a ser feito no
Sprint calculadaSelected
diariamente e colocada em um grfico, resultando em um Sprint
Burndown Chart.Product
S choose persistent write code logins
strategy test-driven
exploratory
Increment (hibernate) development
testing
SSL enable analyze example

get official
certificate Install certificate
config file
from I.T.
S update deploy
target in build.xml
exploratory
testing
update
installation
(3 browsers) document
agree on best
Reset lost password algorithm for decide where
code losing
test-driven
randomizing to put the link
development
password
S add screenshot
and text to
exploratory
testing
our manual
Figura 5.18 Relao entre o Backlog do Produto e o Backlog da Sprint.
Eventos do Scrum
O ciclo de desenvolvimento do Scrum composto por reunies e cerimnias

que vamos discutir nessa seo. Os principais eventos so: Sprint, planejamento do
release, planejamento da Sprint, reunies dirias, reviso da Sprint, retrospectiva
da Sprint e refinamento do Backlog do produto.
Sprint
Sprints so ciclos que representam uma unidade temporal onde itens de

Backlog devem ser desenvolvidos a partir de um conjunto de tarefas de engenharia
de software. No mundo gil, uma Sprint permite a implementao de um con-
junto parcial de funcionalidades definido pelo prprio cliente. Por ser parcial,
significa que no um software completamente pronto, mas uma parte funcional
dele. As Sprints possibilitam que a equipe trabalhe dentro de um prazo fixo para
a implementao de um nmero definido de funcionalidades que, por sua vez,
podem ser classificadas por prioridade.
importante ressaltar que uma vez definido o objetivo e o escopo da Sprint
(Backlog da Sprint) isto no deve mudar at o fim da durao estabelecida. O fluxo
da Sprint deve ser repetido at esgotar todos os itens do Backlog da Release.
captulo 5 141
Planejamento do release
O planejamento do release o momento de estimar o trabalho inicial para

o projeto, devendo acontecer antes do primeiro Sprint do projeto ou ao final do
ltimo Sprint da Release anterior. Neste momento, muitos aspectos relacionados
ao projeto so desconhecidos, desta forma o planejamento no deve ser detalhado.
Um ponto importante que a quantidade e durao das Sprints, o tamanho da
equipe, a quantidade de entregas, o valor a ser entregue em cada release e a data de
liberao de cada um deles devem ser definidos nesta etapa.
Com relao durao da reunio, no h um prazo estabelecido, mas im-
portante limitar um espao de tempo para a sua realizao. Para o planejamento do
release, necessria a participao do Product Owner, Time de Desenvolvimento
e do Scrum Master.
Planejamento da Sprint
A reunio de planejamento da Sprint tem como objetivo escolher os itens do

Backlog com maior prioridade para serem desenvolvidos durante a Sprint. A partir
do Backlog do release priorizado, histrias do usurio so escolhidas e quebradas
em pequenas tarefas.
Neste momento, o Product Owner detalha e prioriza as histrias de usurio.
A sua principal funo nesta etapa de auxiliar o Time de Desenvolvimento em
relao duvidas que possam surgir relacionadas aos itens do Backlog.
Reunies dirias
A reunio diria uma cerimnia curta que deve ser realizada pelo Time de
Desenvolvimento. A ideia que a durao mxima seja de quinze minutos, sendo
realizada sempre no mesmo local e hora, preferencialmente. importante que seja
mantido um foco com base nos seguintes pontos:
O que eu fiz desde a ltima reunio?
O que eu pretendo fazer ate a prxima reunio?
Que impedimentos esto em meu caminho?
O objetivo destas trs perguntas verificar se a meta da Sprint est sendo
cumprida e o que possivelmente est atrapalhando o no cumprimento da meta.
captulo 5 142
Reviso da Sprint
A reviso da Sprint deve ser realizada sempre ao final de cada ciclo de de-
senvolvimento. Durante esta cerimnia, o Time Scrum deve apresentar o que
foi produzido durante o Sprint. Devem participar da reunio o Product Owner,
o Scrum Team, o Scrum Master, gerncia, clientes e engenheiros de outros projetos.
Durante o Sprint Review, o projeto avaliado em relao aos objetivos do
Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe
completou cada um dos itens do Product Backlog trazidos para fazer parte do
Sprint, mas o importante mesmo que a equipe atinja o objetivo geral do Sprint.
Retrospectiva da Sprint
O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o

que funcionou bem, o que pode ser melhorado e que aes sero tomadas para
melhorar o trabalho do Time. Deve ser realizada no ltimo dia de cada Sprint,
aps a reunio de Sprint Review, tendo a durao mxima proporcional a trs
horas para Sprints de um ms. Time de Desenvolvimento, Product Owner e
Scrum Master devem participar desta cerimnia.
Refinamento do Backlog do produto
O objetivo principal do refinamento do Product Backlog a preparao do

Backlog para o desenvolvimento nas prximas Sprints. Essa atividade deve ser rea-
lizada pelo Time de Desenvolvimento em conjunto com o Prodct Owner, sempre
que necessrio.
O trabalho de Refinamento do Product Backlog inclui a adio de novas fun-
cionalidades, remoo de itens que no so mais teis ao produto, o desmem-
bramento de itens maiores em itens menores, a juno de itens menores em um
item maior que perdeu prioridade, o detalhamento de itens, seu reordenamento e,
possivelmente, a criao de algum tipo de estimativa.
Kanban
O sistema Kanban consiste em uma simbologia visual usada na indstria

para registrar aes. A metodologia foi criada pela empresa Toyota, sendo parte
captulo 5 143
do sistema Toyota de produo, j discutido em captulos anteriores. O seu termo,
portanto, tem origem japonesa e pode ser traduzido como carto visual. Na
tcnica, os cartes so a necessidade de peas e itens para o processo produtivo. O
objetivo principal do mtodo propiciar a interao entre a gesto do estoque e a
produo. Neste sentido a ideia atuar na entrega de uma determinada quantida-
de de peas. No momento em que as peas se esgotarem, um aviso emitido para
que novas peas sejam produzidas e entregues. uma analogia ao servio Just in
Time.
Mas como o funcionamento do sistema Kanban? O planejamento da pro-
duo e o controle de estoque so realizados a partir dos quadros e cartes visuais
que integram a tcnica. As decises so tomadas conforme a quantidade de cartes
disponveis nos quadros, priorizando o que mais importante, realizando setup
de mquinas e at mesmo as paradas para manuteno. Neste sentido, podemos
dividir a tcnica em dois tipos: o de produo e o de movimentao.
SAIBA MAIS
Aprenda mais sobre o sistema Kanban no vdeo a seguir: <https://www.youtube.com/
watch?feature=player_embedded&v=hpPBUVs9t1s>.
O Kanban de produo o carto responsvel por autorizar a produo dos

itens. Os cartes circulam entre o setor fornecedor e a produo, sendo afixados
junto s peas imediatamente aps a produo e retirados depois que vai para o
cliente. Em seguida, retorna ao processo para autorizar a produo e reposio dos
itens consumidos.
SAIBA MAIS
Aprenda mais sobre o Kanban de produo no vdeo a seguir: <https://www.youtube.
com/watch?feature=player_embedded&v=Q3x6DblDNbk>.
captulo 5 144
Kanban de Movimentao denominado ainda de Kanban de Transporte,
sendo um carto (diferente do Kanban de Produo) que autoriza a movimenta-
o fsica de peas entre o fornecedor e o cliente. Os cartes so afixados nos pro-
dutos, geralmente, o carto de movimentao afixado em substituio ao carto
de produo, e levados a outro processo ou local, onde so retirados e voltam
etapa inicial.
ATIVIDADES
01. SCRUM um framework baseado no modelo gil. No SCRUM,
a) o Scrum team a equipe de desenvolvimento, necessariamente dividida em papis
como analista, designer e programador. Em geral o Scrum team tem de 10 a 20 pessoas.
b) as funcionalidades a serem implementadas em cada projeto (requisitos ou histrias de
usurios) so mantidas em uma lista chamada de Scrum board.
c) o Scrum Master um gerente no sentido dos modelos prescritivos. um lder, um
facilitador e um solucionador de conflitos. ele quem decide quais requisitos so
mais importantes.
d) um dos conceitos mais importantes o Sprint, que consiste em um ciclo de desenvolvi-
mento que, em geral, tem durao de 4 a 7 dias.
e) o Product Owner tem, entre outras atribuies, a de indicar quais so os requisitos mais
importantes a serem tratados em cada Sprint. responsvel por conhecer e avaliar as
necessidades dos clientes.
02. Sobre os princpios do mtodo de desenvolvimento Scrum, que so consistentes com o

manifesto gil, julgue as seguintes afirmativas e assinale a alternativa correta.
I . Testes e documentao constantes so realizados medida que o produto construdo.
II. O processo produz frequentes incrementos de software que podem ser inspecionados,
ajustados, testados, documentados e expandidos.
III. O trabalho de desenvolvimento e o pessoal que o realiza dividido em parties claras,
de baixo acoplamento, ou em pacotes.
a) Apenas as afirmativas I e II so corretas.

b) Apenas as afirmativas I e III so corretas.
c) Apenas as afirmativas II e III so corretas.
d) Todas as afirmativas so corretas.
e) Nenhuma das afirmativas correta.
captulo 5 145
03. Segundo Roger S. Pressman, em seu livro Engenharia de Software, 7a edio, os prin-
cpios do Scrum so consistentes com o manifesto gil e so usados para orientar as ativi-
dades de desenvolvimento dentro de um processo que incorpora as atividades estruturais
de requisitos, anlise, projeto, evoluo e entrega. Em cada atividade metodolgica, ocorrem
tarefas a realizar dentro de um padro de processo chamado
a) process Backlog. d) Backlog.
b) Scrum Master. e) Sprint.
c) Product Owner.
04. Nos mtodos geis XP e Scrum, as entregas de partes funcionais do projeto so di-
vididas em ciclos, geralmente compreendidos no perodo de 2 a 4 semanas. Estes ciclos
denominam-se, respectivamente,
a) iteraes e Sprint.
b) reunio de planejamento e Backlog.
c) perodo de entrega e reunio de reviso.
d) Backlog e planejamento da produo.
e) entrega e retrospectiva.
05. Um dos pontos da metodologia Scrum o Daily Scrum, que consiste em uma reunio
diria com aproximadamente 15 minutos de durao onde so tratados assuntos relaciona-
dos ao projeto. Nessa reunio so feitas trs perguntas a cada membro do time de desen-
volvimento, constando o que foi feito desde a ltima reunio, o que ser feito at a prxima
reunio e qual:
a) modelo de testes est sendo utilizado pela tarefa atual.
b) o tempo restante para finalizao da tarefa.
c) a relao da tarefa atual com o outro membro da equipe.
d) a tarefa que est sendo executada no momento.
e) obstculo impede o desenvolvedor de prosseguir com a tarefa.
REFLEXO
Neste captulo aprendemos de forma geral, os conceitos e caractersticas da metodo-
logia gil Scrum de desenvolvimento de sistemas. Estudamos conceitos relacionados aos
papis, artefatos e eventos do arcabouo. Ao final, vimos como a metodologia Kanban pode
contribuir na produo, inclusive de software.
captulo 5 146
Sugerimos que voc faa todos os exerccios propostos e pesquise outras fontes para
aprofundar seus conhecimentos. Em caso de dvidas, retorne aos tpicos e faa a releitura
com bastante ateno.
LEITURA
Para voc avanar mais o seu nvel de aprendizagem envolvendo os conceitos de Scrum
e demais assuntos deste captulo, consulte a sugesto de links a seguir:
Gamonar, Flvia. Saiba mais sobre o Scrum, um framework para desenvolvimento gil de
software. Disponvel em:<https://www.linkedin.com/pulse/saiba-mais-sobre-o-Scrum-um-
framework-para-gil-de-software-gamonar>.
Gamonar, Flvia. O Scrum, o princpio de Pareto, a produtividade e outras teorias relaciona-
das. Disponvel em:<https://www.linkedin.com/pulse/o-Scrum-princpio-de-pareto-produti-
vidade-e-outras-teorias-gamonar?trk=mp-author-card>.
SABBAGH, R. Scrum: Gesto gil para projetos de sucesso, 2016
GABARITO
Captulo1
01. Um processo de desenvolvimento de sistemas um conjunto de regras que permite

organizar um projeto em particular ao estabelecer o sequenciamento de atividades a serem
realizadas, devendo estabelecer quem realiza a atividade, de que forma, como e em que
momento. Por sua vez, um modelo de processo de software uma representao simpli-
ficada de um processo de software, no sendo responsvel por estabelecer os papis das
pessoas envolvidas.
captulo 5 147
02. O modelo cascata baseado na engenharia tradicional, onde podemos perceber uma
abordagem sistemtica ao estabelecer uma sequncia entre as atividades envolvidas. Pode
ser utilizado em um contexto onde os requisitos sejam bem definidos e que mudanas no
sejam frequentes.
03. D. 04. D. 05. E.
Captulo2
01. O principal objetivo desta fase produzir o documento de especificao de requisitos,

onde devem estar contempladas todas as funcionalidades, caractersticas e restries que
o sistema deve conter, do ponto de vista dos usurios e clientes. Para que este documento
seja produzido, necessrio inicialmente verificar a viabilidade do projeto, para na sequncia
elicitar, documentar e validar os requisitos do produto.
02. A fase de anlise a etapa de modelagem do problema, ou seja, contm as atividades

necessrias para o entendimento do domnio do problema. Por sua vez, a fase de projeto a
etapa de modelagem da soluo, ou seja, contm as atividades necessrias para resolver o
problema. Tambm podemos comprar estas fases em relao participao do usurio. Nes-
te sentido, a fase de anlise o conjunto de atividades realizadas com a cincia do cliente,
ou seja, os usurios devem discutir e validar a informao produzida. J a fase de projeto re-
presenta o conjunto das atividades que produzem informao destinada aos programadores.
03. A padronizao do cdigo ajuda na integrao do trabalho realizado pela equipe. O ob-
jetivo alinhar a forma de escrita para que o resultado seja uniforme e, consequentemente,
mais fcil de ser mantido.
04. Verificao e validao de software o processo utilizado para verificar se o produto

foi construdo com base no que foi pedido na especificao e validar o produto do ponto de
vista do usurio.
05. Um maior custo atrelado manuteno pode ser explicado pelo fato da equipe de ma-
nuteno nem sempre ser a mesma equipe que desenvolveu o produto, fazendo com que o
esforo envolvido no entendimento do produto seja maior. Alm disso, os desenvolvedores
de um sistema podem no ter responsabilidade contratual pela manuteno, a equipe de
manuteno geralmente menos experiente do que a equipe de desenvolvimento, alm de
captulo 5 148
possuir um conhecimento limitado do domnio do problema; e com o passar do tempo, os
programas tem a sua estrutura degradada, tornando-os mais difceis de serem entendidos
e alterados.
Captulo3
01. As principais caractersticas da ferramenta RUP ser guiado pelos casos de uso, cen-
trado na arquitetura, e iterativo e incremental.
02. A 03. A 04. B
05. Sim. O RUP pode ser utilizado na construo de sistemas Web, independente da comple-
xidade e estabilidade dos requisitos. Como a ferramenta pode ser customizada, a depender
da complexidade, o processo pode ser composto por mais ou menos atividades e artefatos.
Captulo4
01. B
02. A partir da utilizao de princpios baseados na manufatura que tem como objetivo redu-
zir custos dos projetos, tais como: eliminar de perdas, amplificar o aprendizado, tomar deci-
ses o mais tarde possvel, fazer entregas o mais rpido possvel, tornar a equipe responsvel,
construir integridade e visualizar o todo.
03. E 04. D 05. D
Captulo5
01. E 03. E 05. E
02. D 04. A
captulo 5 149
ANOTAES
captulo 5 150
ANOTAES
captulo 5 151
ANOTAES
captulo 5 152

Metodologia de Sistemas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metodologia de Sistemas

Uploaded by

Copyright:

Available Formats

METODOLOGIAS DE

Autor do original andr lus belmiro moreira ramos

Projeto editorial roberto paes

Coordenao de produo luciana varga, paula r. de a. machado e aline karina

Projeto grfico paulo vitor bastos

Diagramao bfs media

Reviso lingustica bfs media

Reviso de contedo luiz roberto martins bastos

Imagem de capa shaiith|shutterstock.com

Dados Internacionais de Catalogao na Publicao (cip)

R175m Ramos, Andr Lus Belmiro Moreira

1. Processos. 2. Extreming programming. 3. Rational Unfied Process.

Diretoria de Ensino Fbrica de Conhecimento

1. Introduo s metodologias de desenvolvimento

Custos relacionados a modelos de desenvolvimento de sistemas 29

2. Fases do desenvolvimento de sistemas 35

Fase de Planejamento e Elaborao 37

Fase de Anlise e de projeto 43

3. Rational Unified Process - RUP 59

Ciclo de vida do RUP 79

O RUP nos dias de hoje 84

4. Introduo metodologia gil 89

Lean Software Development 97

Ciclo de vida de um Projeto de Programao XP 115

Papis no Scrum 128

Artefatos do Scrum 138

Eventos do Scrum 141

No desenvolvimento de sistemas, vrios fatores influenciam na qualidade final

Ao longo do tempo, sistemas de computador tm desempenhado funes

Introduo aos modelos de desenvolvimento de sistemas

Figura 1.1 Conferncia da OTAN sobre Engenharia de Software.

Na poca, a construo de sistemas era considerada um processo artesanal,

FONTE: SOMMERVILLE, I. Engenharia de Software. 9 Edio.

Dessa forma, podemos definir modelo de desenvolvimento como uma re-

Apesar da descrio das fases anteriormente, os modelos de desenvolvimento

O modelo em cascata, por ter sido um dos primeiros modelos de desenvolvi-

Figura 1.2 Fases do modelo cascata.

FONTE: SOMMERVILLE, I. Engenharia de Software. 9 Edio.

A prototipao um tipo de modelo evolucionrio que representa o desen-

Figura 1.3 Fases do modelo de prototipao.

A ideia do modelo em questo tem incio na coleta dos requisitos, onde as

Proposto por Boehm, o modelo espiral, assim como o de prototipao, evo-

Prottipo no nvel seguinte

Figura 1.4 Fases do modelo espiral.

A fase trs consiste nas atividades da fase de desenvolvimento, incluindo pro-

FONTE: SOMMERVILLE, I. Engenharia de Software. 9 Edio. Editora Pearson,

Outra importante vantagem que, por ser incremental, novas funcionalida-

Modelo iterativo e incremental

O modelo iterativo e incremental uma adaptao da abordagem espiral,

FONTE: PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo:

Figura 1.5 Fases do modelo iterativo e incremental.

Como podemos perceber a partir da figura 1.5, o modelo proposto permite

FONTE: PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo:

Em suma, podemos perceber que no existe uma sequencialidade entre as ati-

Detalhes Refina Projeto

Figura 1.6 Detalhamento das iteraes no modelo interativo e incremental.

Em relao s abordagens anteriores, o modelo iterativo e incremental traz di-

Anlise Projeto Implementao + Testes Transio

Figura 1.7 Diferenas entre os modelos iterativo, incremental e cascata.

Modelo baseado em componentes

Cada vez mais, as organizaes anseiam por metodologias de desenvolvimen-

Especificaes Anlise de Modificao Projeto de sistema

Figura 1.8 Fases do modelo baseado em componentes.

Na figura 1.8, visualizamos as etapas do modelo baseado em componentes.