Metodologia de Sistemas
Metodologia de Sistemas
Metodologia de Sistemas
DESENVOLVIMENTO DE
SISTEMAS
autor
ANDR LUS BELMIRO MOREIRA RAMOS
1 edio
SESES
rio de janeiro 2017
Conselho editorial roberto paes eluciana varga
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.
isbn: 978-85-5548-434-6
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
Vises do RUP 69
Elementos do RUP 76
Papel 77
Atividade 78
Artefato 78
Fluxo de Trabalho 78
Disciplina 78
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
5. Scrum 121
Introduo ao Scrum 122
Kanban 143
Prefcio
Prezados(as) alunos(as),
Bons estudos!
7
1
Introduo s
metodologias de
desenvolvimento de
sistemas
Introduo s metodologias de
desenvolvimento de sistemas
OBJETIVOS
Entender a importncia de seguir uma metodologia de desenvolvimento de sistemas;
Discutir os principais aspectos de diferentes metodologias 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.
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.
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.
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
Anlise
Projeto
Implementao
Testes
Manuteno
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
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
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
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
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.
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.
Atividades
Interativas
Especificao
DESCRIO
Desenvolvimento
INICIAL
Validao
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.
Interao
1
Interao
Interao
Business Anlise Projeto 2
Requisitos Priorizao 3
Case inicial arquitetural
Elaborao Tempo
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
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/>.
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.
Desenvolvimento Validao
e integrao de sistema
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.
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.
Tabela 1.1 Tabela referente s diferenas entre os modelos tradicionais e o modelo ba-
seado em componentes.
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
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
captulo 1 30
Custos de Desenvolvimento de Software
3%
8%
7% Requisitos
Projeto
15% Implementao
Testes
67%
Manuteno
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
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.
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.
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.
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.
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.
SAIBA MAIS
Para ver exemplos dos tipos de requisitos estudados at o momento, acesse: <https://
prezi.com/hrq9wuxvzr7j/requisitos-de-usuario/>.
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.
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.
captulo 2 41
A engenharia de requisitos
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>.
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)
captulo 2 44
Anlise Projeto
Informao Informao
importante para importante
o cliente apenas para o
aprovar e programador
discutir
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.
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>.
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.
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
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
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>.
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.
captulo 2 51
Testes nas etapas anteriores codificao
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.
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/>.
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
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.
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.
Custo 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.
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
REFERNCIAS BIBLIOGRFICAS
SOMMERVILLE, I. Engenharia de Software. 9 Edio. Editora Pearson, 2011.
PRESSMAN, R. S. Engenharia de Software. 6 Edio. Editora McGraw Hill, 2006.
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.
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
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
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.
Disponibilizao
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.
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.
WORKFLOW DESCRIO
Os processos de negcio so modelados por meio
Modelagem de negcios
de casos de uso de negcios.
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.
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
Canal de
aprovao Codificao
Bug
Teste
outros stakeholders
Change request
Manuteno
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
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
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( )
captulo 3 70
Cliente Funcionamento Filme Locao
Solicitar Filme
Tem no estoque
Sim
Decrementa estoque
Calcula Devoo
Data Devoluo
Cria Locao
Confirmar Locao
1.1:create(valorEntregue)
linha de link
:Pagamento
primeira mensagem
instncia parmetro
captulo 3 71
Login Relatrios Reembolsos 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
Busca no cadastro no
C_consultas Banco de Dados Banco de Dados
Cadastro de livros
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.
<<SERIAL>>
<<TCPAP>> <<HTTP>>
Impressora
Computadores do
Administrador/
Funcionrio
browser
<<SERIAL>>
Impressora
captulo 3 73
Cliente Sistema Pizzaria
Escolher Produto
Sabor, tamanho, borda
recheada
Definir Quantidade
[Continuar Comprando]
OP: Lote
Gribeiro: Proprietario area = 100
nome = Gilberto
SJC: Lote
area = 120
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
Funcionrio Autorizado
<<include>>
Lanar Contas e
Receber
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
Usurio-final,
Desenvolvedor, gerente Projetista do sistema
desenvolvedor
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
captulo 3 76
Business
Modeling Requirements
Analysis e Design
Planning
Environment Test
Deployment
Evaluction Organizado em
Processo de Engenharia de Software Disciplina
expressada
como
Organiza
sequencia de Descrito por
para
usa
Res
Papel pon
sve
l po
r
Artefato Mentor de
Ferramenta
referncia
para
Papel
captulo 3 77
Atividade
Artefato
Fluxo de Trabalho
Disciplina
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.
Objetivos da fase:
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.
Fase de Elaborao:
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:
Fase de Construo:
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:
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
Objetivos da fase:
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.
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.
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.
REFERNCIAS BIBLIOGRFICAS
SOMMERVILLE, I. Engenharia de Software. 9 Edio. Editora Pearson, 2011.
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
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.
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
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.
captulo 4 92
Indivduos e interaes sobre Ferramentas e processos
Colaborao com o
sobre Negociao de contratos
cliente
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.
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.
Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se ajustam e
otimizam seu comportamento de acordo.
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.
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.
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
Espera Espera
Movimento Movimento
Defeitos Defeitos
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>.
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.
Trabalho
Espera
Trabalho
Espera
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.
Amplificar o aprendizado
captulo 4 102
Tomar decises o mais tarde 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.
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.
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
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
Construir integridade
Visualizar o todo
captulo 4 105
XP
Conceitos e Definies
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.
Selecionar histrias
Dividir histrias
do usurio para Planejar release
em tarefas
este release
Desenvolver/
Avaliar Liberar
integrar/
sistema software
testar software
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.
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
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.
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.
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
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
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.
Princpios do XP
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.
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.
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.
Projeto
Anlise
Verso Final
Estimativas de esforo
Estrias
Prioridades
Integrao
Feedback contnua Pequena Verses
Verso Atualizadas
Teste Base de
dados
coletiva
Fase de Explorao
captulo 4 115
Fase de Planejamento
Fase de Iterao
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
captulo 4 116
Fase de Morte
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.
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:
PRESSMAN, R. S. Engenharia de Software. 6 Edio. Editora McGraw Hill, 2011.
captulo 4 118
REFERNCIAS BIBLIOGRFICAS
SOMMERVILLE, I. Engenharia de Software. 9 Edio. Editora Pearson, 2011.
PRESSMAN, R. S. Engenharia de Software. 6 Edio. Editora McGraw Hill, 2011.
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.
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
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.
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.
Figura 5.2 Exemplo de roadmap do produto. (SABBAGH, R. Scrum: Gesto gil para
projetos de sucesso, 2016, pgina 270)
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
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.
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)
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)
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.
Product Owner
Planejamento Esclarecimento
SCRUM
Equipe de
Scrum Master
Desenvolvimento
Progresso
captulo 5 129
Time de desenvolvimento
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.
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.
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
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
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.
Executivos
Scrum Master
Product Owner
Time de
Desenvolvimento
User
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
Product Owner
captulo 5 135
Envolvimento Cliente/Usurio
Scrum
Tradicional
Tempo Projeto
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.
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.
Escudo contra
Coach Scrum Interferncias
Master
Removedor de
Lder Servidor
Impedimentos
Autoridade no Agente de
Processo Mudanas
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
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
captulo 5 138
Jul/2016 Dez/2016 Jan/2017
Release 1 Release 2 Release 3
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.
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.
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
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
Sprint
captulo 5 141
Planejamento do release
Planejamento da Sprint
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
Kanban
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>.
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.
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>.
REFERNCIAS BIBLIOGRFICAS
PRESSMAN, R. S. Engenharia de Software. 6 Edio. Editora McGraw Hill, 2011.
SABBAGH, R. Scrum: Gesto gil para projetos de sucesso, 2016
SOMMERVILLE, I. Engenharia de Software. 9 Edio. Editora Pearson, 2011.
GABARITO
Captulo1
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.
Captulo2
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.
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.
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.
Captulo5
02. D 04. A
captulo 5 149
ANOTAES
captulo 5 150
ANOTAES
captulo 5 151
ANOTAES
captulo 5 152