Bruno Junqueira Alves - Monografia - Metodologia Agil

Estudo Comparativo entre Mtodos geis e
Tradicionais de Fabricao de Software

Trabalho de Concluso de Curso

Engenharia da Computao

Bruno Junqueira Alves
Orientador: Prof. Srgio Murilo Maciel Fernandes

ii

Universidade de Pernambuco
Escola Politcnica de Pernambuco
Graduao em Engenharia de Computao

Bruno Junqueira Alves

Estudo Comparativo entre Mtodos
geis e Tradicionais de Fabricao de
Software

Monografia apresentada como requisito parcial para obteno do diploma de
Bacharel em Engenharia de Computao pela Escola Politcnica de Pernambuco
Universidade de Pernambuco.

Recife, Agosto/2012.

iii

De acordo

Recife

____/___________/_____

_____________________________________
Orientador da Monografia

iv

Dedico esse trabalho a todos que me deram o apoio necessrio, minha famlia, meu
orientador e amigo Srgio Murilo e, principalmente, Deus.

v

Resumo
Nesse trabalho, foi feita uma pesquisa a respeito dos atuais mtodos de
fabricao de software utilizados pelas principais software houses do mundo.
Tambm foram citados mtodos usados no incio da modernizao dos processos
de desenvolvimento. Atravs de entrevistas com especialistas na rea, leitura
especializada e um estudo de caso, foi possvel chegar a uma comparao concisa
entre os existentes mtodos de construo de software.

vi

Abstract
In this study, a survey was made about the current software development
methods that are used by major software houses in the world. This work also
mentions the methods used at the beginning of the modernization of development
processes. Based on interviews with experts in the field, reading specialized books
and performing a case study, it was possible to reach a concise comparison between
the existing methods of software development.

vii

Sumrio
Captulo 1 Introduo 1
1.1 Objetivo 2
1.2 Estrutura do trabalho 2
1.3 Metodologia 3
Captulo 2 Os processos de desenvolvimento de software. 4
2.1 Modelo cascata 4
2.2 Modelos incrementais de processo 6
2.2.1 O modelo Incremental 7
2.2.1.1 RUP (Rational Unified Process) 8
2.2.2 O modelo RAD 11
2.3 Modelos evolucionrios de software 13
2.3.1 Prototipagem 13
2.3.2 Modelo espiral 14
2.4 Desenvolvimento gil 17
Captulo 3 Comparao entre metodologias geis e metodologias
clssicas 23
3.1 Introduo 23
3.2 Comparativo entre as metodologias 23
3.2.1 Incio do projeto 24

viii

3.2.2 Planejamento 25
3.2.2.1 Escopo 26
3.2.2.2 Tempo 26
3.2.2.3 Qualidade 27
3.2.2.4 Riscos 29
3.2.2.5 Recursos Humanos 29
3.2.2.6 Custos 30
3.2.3 Execuo 31
3.2.4 Controle 31
3.2.5 Encerramento 32
Captulo 4 Estudo de caso Sistema de Gesto Empresarial
Pirmide 34
4.1 A Procenge 34
4.2 O Pirmide 35
4.3 Estudo de caso 35
Captulo 5 Concluses e trabalhos futuros 39
Referncias 41

ix

Lista de Figuras
Figura 1. Etapas da metodologia cascata................................................................. 5
Figura 2. Modelo Incremental ................................................................................... 7
Figura 3. Viso geral do RUP ................................................................................... 9
Figura 4. Fases de desenvolvimento do RUP ........................................................ 10
Figura 5. Modelo RAD ............................................................................................ 12
Figura 6. Ciclo da Prototipagem ............................................................................. 14
Figura 7. O modelo espiral ..................................................................................... 16
Figura 8. Metodologia Scrum .................................................................................. 21
Figura 9. Desenvolvimento guiado por caractersticas ........................................... 22
Figura 10. Fatores de projeto ................................................................................ 25
Figura 11. Sistema de Gesto procenge ............................................................... 36

Captulo 1 - Introduo
Bruno Junqueira Alves 1
Captulo 1
Introduo
A engenharia de software uma disciplina relativamente nova. A ideia de
engenharia de software apareceu na dcada de 1960, exatamente em 1968. Nessa
poca, o hardware passava para um nvel mais avanado de construo, tornando
os computadores capazes de efetuarem tarefas antes impensveis e tornando a
fabricao mais barata. Mas, ao contrrio dessa facilidade do hardware, o software
estava ficando mais caro e a entrega com mais atraso. Portanto, novos mtodos
eram necessrios para controlar a complexidade de sua fabricao.
Ento foram criados os primeiros processos de fabricao de software, onde
o objetivo era tornar a criao do software semelhante a um processo industrial, a
fim de acompanhar o desenvolvimento do hardware das mquinas.
Houve um grande progresso desde essa poca, mas ainda existem
problemas para entregar os projetos no prazo e manter o custo inicialmente
acordado. Por ser um processo intelectual, que usa julgamento humano, os
processos de desenvolvimento de software so complexos e suas tentativas de
automatizao no obtiveram sucesso pleno.
Os primeiros mtodos de desenvolvimento possuam orientao esttica,
exatamente como uma linha de montagem. Com um tempo, as empresas
comearam a adotar uma postura mais dinmica, onde as mudanas no cdigo no
representam tantos problemas para a adaptao a um cliente especfico. A partir da,
foram criados os mtodos geis, cujo foco era nas pessoas e no nos processos
estticos de desenvolvimento.

1.1 Objetivo
Nesse trabalho, sero demonstrados os principais processos de
desenvolvimento de software usados nas fbricas de software e tambm os que
deixaram de ser utilizados devido a mudanas nos projetos do software. No final,
ser apresentada uma concluso a partir de uma comparao entre esses
processos.
1.2 Estrutura do trabalho
No captulo 2, sero apresentados os mtodos criados para o
aperfeioamento do desenvolvimento do software desde o incio da crise, durante a
dcada de 1960.
Na primeira seo deste captulo, a seo 2.1, ser apresentada a
metodologia em cascata. Na seo 2.2, sero apresentados os modelos
incrementais de processo. Esses modelos se dividem em processo incremental e
modelo RAD.
Na seo seguinte, 2.3, sero detalhados os modelos evolucionrios de
processo de software, nos quais sero citados o uso de prototipagem e o modelo
espiral.
Na ltima seo do captulo 2, ser detalhado o desenvolvimento gil. Nessa
seo, ser apresentada a sua histria e porque esse modelo de processo de
desenvolvimento vem sendo mais adotado pelas software houses.
No captulo 3, ser feita a comparao entre os modelos, citando suas
vantagens e desvantagens em relao ao planejamento, execuo e controle da
fabricao.
No captulo 4, ser mostrado um estudo de caso a partir de uma empresa
estabelecida no mercado, demonstrando a evoluo e os ganhos da empresa ao
utilizar a metodologia de desenvolvimento gil em seu ambiente.

O captulo 5, e ltimo desse trabalho, levantar as concluses e os trabalhos
futuros possveis a partir desse estudo comparativo, de modo que outros
interessados realizem mais pesquisas em relao ao mercado de software houses
brasileiro.
1.3 Metodologia
A metodologia adotada nesse estudo foi a leitura de livros, artigos e trabalhos
especializados na rea de desenvolvimento de software junto com entrevistas com
profissionais que trabalham na rea de desenvolvimento e gerncia de qualidade de
software.
Captulo 2 Os processos de desenvolvimento de software
Captulo 2
Os processos de desenvolvimento
de software.
O processo de desenvolvimento de software pode ser definido como uma
coleo de padres que definem um conjunto de atividades, aes, tarefas de
trabalho, produtos de trabalho e/ou comportamentos relacionados e necessrios ao
desenvolvimento de software de computador. Pela combinao de padres, uma
equipe de software pode definir um processo que melhor satisfaa s necessidades
de um projeto.
Nesse captulo sero apresentados os principais mtodos conhecidos de
desenvolvimento de software, de modo que se possa ter um entendimento para a
comparao desses mtodos.
2.1 Modelo cascata
Existem ocasies onde todos os requisitos de um sistema so bem
compreendidos. O sistema a ser construdo no precisa passar por muitas
adaptaes ou evolues (aperfeioamentos), tornando sua implementao linear.
O modelo cascata, ou clssico, foi a primeira metodologia de desenvolvimento
de software apresentada. Ela usa uma abordagem sistemtica e sequencial para o
desenvolvimento do software [4]. um modelo onde a etapa seguinte s
executada aps a anterior ser totalmente finalizada. Para ser iniciada uma etapa, a
anterior precisar estar totalmente documentada e aprovada. Essa metodologia surgiu
em um contexto de desenvolvimento de software muito diferente do atual, baseado
apenas em um mainframe e terminais burros [6]. A Figura 1 ilustra bem o processo.


Figura 1. Etapas da metodologia cascata
[Fonte: retirado de [6]]
1. Definio de requisitos: As funes, as restries e os objetivos do
sistema so estabelecidos atravs de entrevista com usurios do sistema.
Aps isso, esses trs pontos so definidos em detalhes e servem como
uma especificao do sistema.
2. Projetos de sistemas e de software: O processo de projeto de sistemas
agrupa os requisitos em sistemas de hardware e software [9]. Ele
estabelece uma arquitetura do sistema geral. O projeto de software
envolve a identificao e a descrio das funes fundamentais do
sistema de software e suas relaes.
3. Implementao e teste de unidades: Durante esse estgio, o projeto de
software compreendido como um conjunto de programas ou unidades de
programa [4][7]. O teste de unidades certifica que as especificaes de
cada unidade foram atendidas.
4. Integrao e teste de sistemas: As unidades de programa ou programas
individuais so integrados e testados como um sistema nico a fim de
garantir que todas as especificaes foram atendidas. Depois do teste de
sistemas, o software entregue ao cliente.
5. Operao e manuteno: Normalmente, embora no necessariamente,
esta a fase mais longa do ciclo de vida [7]. O sistema instalado e sua
operao iniciada. A manuteno envolve corrigir erros que no foram
descobertos anteriormente, em estgios anteriores do ciclo de vida. Com
isso, as implementaes do sistema so melhoradas e a quantidade de
funes aumentada medida que novas especificaes so
descobertas.
O maior problema dessa metodologia a sua alta burocracia e inflexibilidade
na diviso do processo em fases bem distintas [6]. Esses dois fatores levam a um
alto nmero de atrasos ou at a cancelamentos de projetos. Em relao aos atrasos,
os custos se elevam, superando os custos previstos inicialmente, tornando o
software mais caro.
Outro problema originado a partir desses dois pontos o da qualidade do
software. Os que so entregues dentro do prazo, e custando o acordado
inicialmente, possuem qualidade duvidosa, pois houve muita presso nos
desenvolvedores para cumprir os prazos.
Hoje em dia, o trabalho em software de ritmo rpido e com grande
quantidade de pedidos de modificaes. Com isso, o modelo cascata inadequado
para esse tipo de trabalho. O modelo pode ser til em projetos onde os requisitos
so fixos e o trabalho deve seguir de modo linear.
2.2 Modelos incrementais de processo
H situaes em que os requisitos iniciais do software so razoavelmente
definidos, mas o escopo global do esforo de desenvolvimento elimina um processo
puramente linear. Alm disso, pode haver a necessidade de fornecer um conjunto
limitado de funcionalidades do software aos usurios e depois refinar e expandir
aquela funcionalidade em verses posteriores do software. Em tais casos, o
processo de desenvolver o software incrementalmente escolhido [4].
2.2.1 O modelo Incremental
O modelo incremental possui elementos do modelo cascata, que aplicado
de maneira iterativa [4]. No modelo incremental, so aplicadas sequncias lineares
de uma forma racional medida que o tempo passa, como mostrado na Figura 2.
Cada sequncia linear produz incrementos do software passveis de serem
entregues.
Figura 2. Modelo Incremental
No processo incremental, o primeiro incremento desenvolvido chamado de
ncleo. Esse ncleo contm as caractersticas mais bsicas do software. Ao longo
do tempo o usurio solicita melhorias, ou seja, novos incrementos. So feitos novos
planos de projeto a fim de que o software seja aperfeioado. Esse processo
repetido at que o sistema esteja com todas as funcionalidades implementadas.
A vantagem do uso desse modelo a previso de uso de mo de obra extra e
de novas tecnologias de hardware. Atravs desse modelo, pode-se prever o uso de
mais ou menos desenvolvedores. No caso de novas tecnologias de hardware,
podem ser feitos planos de projeto de modo que se evite o uso dessas novas
tecnologias com data de lanamento incerta.
O modelo incremental iterativo por natureza [4]. E tem o objetivo de
apresentar um novo produto operacional a cada incremento.
2.2.1.1 RUP (Rational Unified Process)
O RUP um processo proprietrio de engenharia de software. Foi criada pela
Rational Software Corporation, adquirida posteriormente pela IBM, ficando
conhecida como RUP IBM ou IRUP.
Esse processo fornece tcnicas s equipes de desenvolvimento de software
objetivando o aumento da produtividade seguindo uma abordagem prescritiva. O
RUP se baseia no paradigma de Orientao a Objetos e documentado utilizando
UML (Unified Modeling Language) para ilustrar os processos em ao.
O principal objetivo do RUP atender as necessidades dos usurios
garantindo uma produo de software de alta qualidade que cumpra um cronograma
e um oramento previsveis [8].
considerado um processo pesado (tradicional) por muitos especialistas e
preferencialmente aplicvel a grandes equipes de desenvolvimento e a grandes
projetos.
O RUP permite definir quem o responsvel pelo o que deve ser feito, como
deve ser feito e quando deve ser feito, descrevendo todas as metas especficas de
desenvolvimento para que sejam alcanadas. A Figura 3 ilustra de forma geral esse
processo.


Figura 3. Viso geral do RUP
O RUP organiza o desenvolvimento em quatro fases, como ilustrado na figura
4 e explicado a seguir. Cada fase tem um papel fundamental para que o objetivo
seja cumprido:
Concepo ou Iniciao: Essa fase abrange as tarefas de comunicao
com o cliente e planejamento. Ocorre a identificao e a especificao dos
casos de uso do projeto. Tambm feito um plano de projeto, analisando
seus riscos, delimitando os custos e os prazos e estabelecendo as
prioridades.
Elaborao: realizada a anlise da extenso do sistema. Tambm
definida a arquitetura que ser utilizada no sistema. Essa arquitetura deve
ser estvel e robusta. Usando essa arquitetura como guia, feita a anlise
e o projeto dos casos de uso, posteriormente documentados.
Construo: O objetivo dessa fase o desenvolvimento de componentes
e outros recursos do sistema. nessa fase que ocorre a produo de
cdigos e os testes alfa para certificar que os casos de uso esto sendo
implementados corretamente. Devem-se aplicar processos de testes
estveis.
Transio: O foco nessa fase assegurar que o software esteja disponvel
para seus usurios finais [9]. As atividades nessa fase incluem o
treinamento dos usurios finais e a realizao dos testes beta do sistema
visando que o mesmo tenha os nveis de qualidade adequados.

Figura 4. Fases de desenvolvimento do RUP
O RUP tenta diminuir os riscos do desenvolvimento, a fim de torn-lo mais
eficiente, utilizando seis prticas bsicas a serem executadas durante o projeto:
Desenvolver iterativamente Esta prtica permite que requisitos sejam
identificados ou modificados mais facilmente, ocorra uma integrao
progressiva de elementos ao software, ocasionando uma melhora na
identificao dos riscos.
Gerenciar requerimentos Prov uma maneira prtica de produzir,
organizar e comunicar os requisitos de um projeto. O gerenciamento de
recursos acarreta um melhor controle sobre projetos complexos [10].
Utilizar arquiteturas baseadas em componentes O processo foca no
desenvolvimento inicial de uma arquitetura robusta, antes do
comprometimento de recursos em larga escala. Essa prtica descreve
como projetar uma arquitetura flexvel, que suporta mudanas e promove
um reuso de software efetivo. O RUP prov uma aproximao sistemtica
para definir uma arquitetura atravs de componentes novos ou existentes
[10]. Um componente pode ser definido como um mdulo no-trivial ou um
subsistema que cumpre uma funo clara.
Modelar visualmente O processo mostra como modelar visualmente um
software para identificar a estrutura e o comportamento da arquitetura e
dos componentes. Isso permite entender melhor no s a concepo e
complexidade do sistema, como tambm dimensionar, alm de facilitar a
identificao e a soluo de problemas. O RUP, atravs da UML, permite
uma modelagem compreensiva de sistemas complexos, formando uma
base para a implementao e capturando requisitos com preciso.
Verificao contnua da qualidade O RUP toma a qualidade como
responsabilidade de todos os integrantes do projeto. Durante o ciclo de
vida do projeto, os integrantes implementam, medem e avaliam tanto a
qualidade do processo como a do produto.
Controle de mudanas O RUP mostra como possvel controlar,
monitorar e identificar mudanas para obter um desenvolvimento iterativo
com sucesso. Isso ajuda o software a obter uma boa qualidade durante e
depois de seu desenvolvimento.
2.2.2 O modelo RAD
O RAD (Rapid Application Development, desenvolvimento rpido de
aplicao) um modelo de processo focado no curto desenvolvimento. O modelo
RAD uma adaptao de alta velocidade do modelo cascata, no qual o
desenvolvimento rpido alcanado com o uso de uma abordagem de construo
baseada em componentes [4].
Esse modelo altamente recomendado para casos de projeto onde as
principais funcionalidades podem ser implementadas em menos de trs meses.
Cada funo pode ser tratada por uma equipe RAD diferente, no final juntando todas
as funes em um todo. A Figura 5 ilustra bem como acontece um projeto usando
metodologia RAD em seu desenvolvimento.

Figura 5. Modelo RAD
As desvantagens desse modelo so:
Necessidade de alto nmero de recursos humanos para desenvolver as
funes em tempo hbil;
Comprometimento dos desenvolvedores e clientes;
Necessidade de alta modularizao do sistema, o que consome muito
tempo de reunio, diminuindo o tempo de desenvolvimento;
Devido ao estilo de alta velocidade de desenvolvimento, pode no ser
adequado quando existem altos riscos.
2.3 Modelos evolucionrios de software
Com o passar do tempo, o software evolui como todo sistema complexo. Os
requisitos mudam, os prazos para entregar o produto final ficam cada vez mais
curtos. Com isso, os processos de software se adaptaram de modo que se entregue
uma verso reduzida, mas que atenda todos os requisitos bsicos, num prazo curto
que permita seu uso pelos clientes.
A ideia por trs do desenvolvimento evolucionrio implementar um sistema
bsico, uma verso inicial, mas que, ao passar do tempo, outras verses, com
funcionalidades mais complexas, sejam entregues para completar o projeto.
A abordagem evolucionria do desenvolvimento de software, muitas vezes,
mais eficaz do que a abordagem cascata, no sentido de produzir sistemas que
atendam s necessidades imediatas dos clientes [7].
O modelo evolucionrio tem como vantagem o fato da especificao do
sistema ser feita gradativamente. medida que o usurio adquire maior
conhecimento em relao s suas preferncias no sistema, compreendendo melhor
seus problemas, isso passa a ser refletido no software.
Sero brevemente apresentados dois processos evolucionrios:
prototipagem, modelo espiral.
2.3.1 Prototipagem
Muitas vezes o cliente no tem uma clara viso dos requisitos que lhe
interessam, ou o desenvolvedor no tem certeza sobre o uso de um certo algoritmo
ou sobre a portabilidade para um sistema operacional, ou qual interao
homem/mquina o sistema deve assumir. Nesses casos, o uso da prototipagem se
faz muito til.
Primeiramente, o engenheiro de software se rene com o cliente a fim de
delinear os requisitos bsicos do sistema, as necessidades conhecidas e requisitos
que precisam ser mais bem definidos. A seguir, o projeto se concentra em entregar
um executvel com todos os requisitos bsicos e uma interface prxima do ideal. O
feedback do cliente vai servir para aprimorar esses requisitos e implementar outros
mais complexos, tornando o entendimento por parte do desenvolvedor mais fcil. A
Figura 6 ilustra como o processo de prototipagem acontece dentro do projeto.
Idealmente, o prottipo serve apenas para identificar os requisitos que esto
sendo satisfeitos e como o sistema pode ser aprimorado. Mas muitos clientes usam
esse prottipo inicial como se fosse o executvel final, ao perceberem que no o
produto final, eles reclamam e exigem consertos, ao invs de esperarem por uma
nova verso mais refinada do sistema, com mais qualidade e robustez.

Figura 6. Ciclo da Prototipagem
Apesar desses problemas, o paradigma de prototipagem pode ser muito
efetivo para os engenheiros de software. O importante definir as regras de
desenvolvimento logo no incio do projeto (linguagem e algoritmos) assim como
entender todos os requisitos do cliente.
2.3.2 Modelo espiral
O modelo espiral foi proposto por Boehm, em 1988 [4]. um modelo de
processo de software que combina a natureza iterativa da prototipagem e os
aspectos controlados do desenvolvimento em cascata. Ao invs de representar o
processo como uma sequncia de atividades, cujo retorno essencial para iniciar a
prxima atividade, o modelo representado como uma espiral.
Cada loop da espiral divido em quatro setores:
Definio de objetivos So definidos os objetivos especficos do projeto.
Tambm so identificadas as restries para o processo e o produto e
preparado um plano de gerenciamento. Os riscos tambm so identificados e,
dependendo desses riscos, estratgias alternativas so planejadas.
Avaliao e reduo de riscos Aps os riscos serem identificados, uma
anlise detalhada dos mesmos feita e providncias so tomadas para
reduzi-los.
Desenvolvimento e validao Aps a avaliao dos riscos, um modelo
de desenvolvimento escolhido para o projeto. Por exemplo, se o risco
principal identificado na fase anterior for a integrao de sistemas, o modelo
cascata pode ser adotado.
Planejamento O projeto revisado para que seja tomada uma deciso a
respeito do prximo loop da espiral. Caso seja decidido continuar, novos
planos sero traados para o projeto seguindo a mesma metodologia.
A Figura 7 ilustra como ocorre um desenvolvimento de projeto seguindo o
padro espiral de projeto. Observar que a cada nova espiral realizada, novos
planejamentos so feitos para o projeto.

Figura 7. O modelo espiral
Uma importante diferena do modelo espiral para ou outros modelos de
processo, exceto o RUP, a explcita considerao dos riscos no modelo espiral. Os
riscos podem resultar em problemas no projeto, como ultrapassar o prazo ou o custo
previsto.
Diferentemente dos outros processos, que so encerrados quando o software
entregue, no modelo em espiral existe uma constante evoluo do produto,
tornando o mesmo mais robusto e mais de acordo com os pedidos do cliente.
O modelo espiral uma abordagem realista do desenvolvimento de software
e sistemas de grande porte [4]. Como o software evolui, tanto o desenvolvedor como
o cliente podem entender melhor o sistema e terem a reao adequada aos riscos
de cada nvel evolucionrio. O modelo usa a prototipagem como uma ferramenta de
reduo de riscos, como exibido na Figura 7, porm, pode permitir que a
prototipagem seja usada em mais de um estgio da evoluo do produto.
Para convencer os clientes de que a abordagem espiral controlvel, deve-se
ter uma competncia considervel para avaliar os riscos. Caso um risco grave no
seja identificado no incio, certamente ocorrero problemas.
2.4 Desenvolvimento gil
A partir da dcada de 90, comearam a surgir novos mtodos sugerindo uma
abordagem de desenvolvimento gil onde os processos adotados tentam se adaptar
s mudanas, apoiando a equipe de desenvolvimento no seu trabalho.
Os mtodos geis caracterizam-se pelo seu carter adaptativo e orientado a
pessoas. As abordagens geis compartilham, na sua essncia, o processo de
desenvolvimento centrado nas pessoas, orientado obteno de artefatos a partir
de iteraes, o que, consequentemente, impe o carter adaptativo durante todo o
ciclo de desenvolvimento.
No incio da primeira dcada de 2000, um grupo de especialistas formulou um
conjunto de princpios que definem a metodologia gil [1]. Estes so os seguintes:
A prioridade satisfazer o cliente atravs de entregas contnuas e
frequentes;
Receber bem as mudanas de requisitos, mesmo em uma fase avanada do
projeto;
Entregas com frequncia, sempre na menor escala de tempo;
As equipes de negcio e de desenvolvimento devem trabalhar juntas
diariamente;
Manter uma equipe motivada fornecendo ambiente, apoio e confiana
necessrios;
A maneira mais eficiente da informao circular dentro do time de
desenvolvimento atravs de uma conversa presencial;
Ter o sistema funcionando a melhor medida de progresso;
Processos geis promovem o desenvolvimento sustentvel;
Ateno contnua excelncia tcnica e a um bom design, aumenta a
agilidade;
Simplicidade essencial;
As melhores arquiteturas, requisitos e projetos provm de equipes
organizadas;
Em intervalos regulares, a equipe deve refletir sobre como se tornar mais
eficaz.
Com base nesses princpios, as metodologias geis existentes apresentam
um conjunto de atividades a serem adotadas durante o desenvolvimento de
sistemas. O termo metodologias geis tornou-se popular em 2001 quando
dezessete especialistas em desenvolvimento de software representando os mtodos
Scrum, Extreme Programming e outros [6], estabeleceram os princpios comuns,
anteriormente listados, compartilhados por esses mtodos.
Os processos geis mais conhecidos so os seguintes:
Extreme programming (XP): uma abordagem deliberada e disciplinada
para o desenvolvimento do software. O primeiro projeto a usar o XP foi o C3, da
Chrysler [4]. uma metodologia baseada em quatro categorias de regras e prticas
a fim de garantir a qualidade do software produzido:
Planejamento O cliente descreve suas atividades que sero
absorvidas pelo software, conhecidas como estrias do usurio. O cliente,
ento atribui um valor a essas estrias, que definem as prioridades das
funcionalidades do sistema. A equipe XP, ento, atribui um custo a cada
estria, medido em semanas de desenvolvimento. Caso o custo de uma
estria ultrapasse trs semanas, pede-se que o cliente divida a estria original
em estrias menores e o processo de atribuio de custos e valor acontece
novamente. Uma observao importante, novas estrias podem ser escritas a
qualquer momento do processo. Uma vez feito um compromisso entre equipe
e cliente de quais estrias iro entrar na verso do software e a data de
entrega dessa verso, a equipe estuda qual o modo seguir:
Todas as estrias sero implementadas;
As estrias de maior prioridade sero implementadas primeiro;
As estrias com maior risco sero implementadas primeiro.
Aps a entrega da primeira verso, a equipe calcula a velocidade do
projeto de acordo com a quantidade de estrias que foram entregues na
primeira verso. Essa medio ajuda em dois pontos: em relao ao tempo
de entrega do sistema; e em relao ao comprometimento (esforo) da equipe
dentro de uma verso. Se ocorrer um comprometimento excessivo dos
profissionais, haver uma modificao no contedo das verses ou na data
de entrega.
Projeto Segue rigorosamente o princpio KIS (keep it simple
mantenha a simplicidade). Fornece diretrizes de implementao para uma
estria a partir da maneira como ela foi escrita. Se for encontrado um
problema difcil nessa fase, recomendada a construo de um prottipo
operacional, que no ser uma verso final do sistema. Esse prottipo
denominado soluo de ponta, e ser avaliado a fim de diminuir o risco de
uma estria quando a verdadeira implementao for iniciada e revisar as
estimativas de entrega das verses.
Codificao Tem como caracterstica chave a programao em
pares, s vezes at uma terceira pessoa entra no processo de codificao.
Essa caracterstica importante, pois mantm os desenvolvedores
concentrados no problema a ser resolvido. Na prtica cada um pode assumir
uma tarefa diferente durante a codificao. Por exemplo, um desenvolvedor
fica responsvel pelos clculos a serem escritos no cdigo enquanto outro
desenvolvedor fica responsvel pela adequao do cdigo aos critrios de
codificao, garantindo que esse cdigo encaixe no projeto mais amplo da
estria. Isso faz com que a funcionalidade de uma estria seja entregue no
tempo correto, seguindo todos os padres do projeto e com qualidade para o
cliente.
Testes recomendado que, ao terminar de projetar as estrias do
cliente, sejam criados testes unitrios, os quais exercitaro a interface, as
estruturas de dados e a funcionalidade de um componente do projeto. Essa
prtica encoraja a prtica de testes de regresso: testar as funcionalidades j
implementadas, sempre quando o cdigo for modificado. medida que os
testes unitrios so realizados e organizados numa sequncia, o teste de
integrao pode ser feito diariamente. Isso fornece equipe uma viso de
progresso e indica sinais de alerta caso o projeto tenha problemas. Ao final
so feitos os testes de aceitao, estes feitos pelo cliente, que so testes das
estrias do usurio implementadas numa verso do sistema.
SCRUM: Desenvolvido na dcada de 1990 por Jeff Sutherland e sua equipe.
O nome deriva de uma atividade decorrente do jogo de rugby. Esse mtodo orienta-
se por trs princpios: a visibilidade, a inspeo e a adaptabilidade. Todos os
requisitos devem estar visveis a todos os envolvidos no desenvolvimento, a
inspeo deve ser uma ao frequente e, consequentemente, as aes para
adaptao do produto de software devem ser realizadas. No SCRUM, so
incorporadas as seguintes atividades de desenvolvimento: requisitos, anlise,
projeto, evoluo e entrega. Essas atividades so reunidas em um padro de
processo, chamado Sprint.
Dentro de uma Sprint, o problema do cliente adaptado, definido e
executado, podendo sofrer modificaes durante a Sprint. O tempo da Sprint
definido pelo responsvel do projeto, podendo ter 30 dias ou uma semana, na Figura
8, este tempo definido em 30 dias.
A cada dia da Sprint, feita uma reunio rpida de 15 minutos para discutir
brevemente o que foi feito no dia anterior, o que est atrapalhando o
desenvolvimento da nova funcionalidade e o que ser feito at a prxima reunio
rpida (stand up meeting), que acontece no dia seguinte, preferivelmente sempre no
mesmo horrio.
No final da Sprint, uma verso de demonstrao com as funes definidas no
incio apresentada ao cliente e o mesmo realiza a avaliao. Com o SCRUM, uma
equipe de desenvolvimento pode trabalhar de modo que os problemas possam ser
previamente vistos, ocasionando novas reunies de projeto para sanar esses
problemas, tornando o desenvolvimento mais bem sucedido.
Figura 8. Metodologia Scrum
FDD (Feature Driven Development Desenvolvimento Guiado por
Caractersticas): Foi concebido como um modelo prtico de processo de engenharia
de software orientada a objetos. Em seu contexto, uma caracterstica seria uma
funo valorizada pelo cliente que poderia ser implementada em duas semanas ou
menos. Esse mtodo se baseia nos seguintes processos: desenvolver um modelo
global, construir uma lista de caractersticas, planejar por caractersticas, projetar e
construir por caractersticas. Estes processos so ilustrados na Figura 9. O FDD d
mais nfase em diretrizes e tcnicas de gesto de projeto do que os outros mtodos
geis [4].

Figura 9. Desenvolvimento guiado por caractersticas
Desta forma, conclui-se a apresentao dos principais modelos de
desenvolvimento de software. No prximo captulo, estes modelos sero
comparados entre si, destacando os pontos positivos e negativos de cada um deles.
Ou seja, em quais situaes devemos preferir um ou outro modelo.
Captulo 3 Comparao entre as metodologias geis e metodologias
clssicas
Captulo 3
Comparao entre metodologias
geis e metodologias clssicas
3.1 Introduo
Nesse captulo sero detalhadas vantagens das metodologias geis em
relao s metodologias clssicas de engenharia de software.
Com essa comparao, mostrado o porqu da maior adoo das
metodologias geis nas empresas especializadas em desenvolvimento de software a
fim de acelerarem a rea de manuteno de sistemas. Com isso, as empresas
aumentam a satisfao dos clientes, podendo alcanar maiores ganhos financeiros e
de novos clientes.
3.2 Comparativo entre as metodologias
A maioria das metodologias geis nada possui de novo [3]. A primeira
diferena das metodologias geis para as tradicionais a priorizao das pessoas e
no dos documentos. Com isso, as metodologias geis conseguem ser mais
dinmicas s mudanas de requisitos, pelo fato de realizarem reunies rpidas para
definir as solues a serem implementadas.
Outras diferenas aparecem no que diz respeito ao incio do projeto,
planejamento, execuo, controle e encerramento do mesmo. Essas diferenas
sero apontadas ao longo do captulo, ilustrando as vantagens e desvantagens entre
as metodologias.
clssicas
3.2.1 Incio do projeto
Na metodologia tradicional, os objetivos e o escopo devem ser previamente
estabelecidos [5]. Aps identificar todos os elementos do sistema, esse escopo
inicial do projeto dever descrever todas as principais funes que o sistema dever
realizar. Neste momento, tambm sero identificadas solues alternativas e
restries tcnicas e administrativas do projeto.
A dificuldade encontrada nesse modo de iniciao de projeto se d ao fato
que no se pode ter certeza em relao ao custo e ao prazo de concluso do
projeto. Prever o tempo que ser gasto para desenvolver as funes sem possuir
informaes detalhadas a respeito das atividades torna a atividade complicada. A
ideia de especificar totalmente um software antes do incio de sua implementao
extremamente difcil [2].
Nas metodologias geis, a iniciao do projeto comea pela identificao dos
objetivos do cliente, mapeando suas estrias em elementos do produto [5]. A
obteno dos requisitos se d junto ao cliente, escutando suas estrias, a fim de
criar seus requisitos de maneira superficial, porm objetivos, atendendo as
expectativas do cliente.
Esses requisitos so definidos sem muitos detalhes, j que, na metodologia
gil, eles podem ser alterados dinamicamente pelo cliente. Outra preocupao em
relao aos requisitos se tornarem obsoletos realidade do cliente. A equipe de
desenvolvimento precisa estar preparada para tais mudanas. Essa falta de preparo
uma das principais causas de falha nos projetos de softwares, portanto uma
equipe preparada para as mudanas se torna mais eficiente e menos sujeita a
fracassos.
Na Figura 10, so destacados os pontos principais de incio de projeto que
so considerados pelas duas metodologias. Enquanto a metodologia tradicional
prioriza o escopo, o prazo e o custo, sacrificando a qualidade do sistema, o que
pode deixar o cliente insatisfeito com a empresa; a metodologia gil tem foco na
qualidade, no prazo e no custo. O destaque est na qualidade, que, na metodologia
clssicas
gil, no negocivel. O produto sempre deve ter uma boa qualidade para garantir a
satisfao do cliente.

Figura 10. Fatores de projeto
3.2.2 Planejamento
Na fase de planejamento, muitos fatores so considerados:
Escopo;
Qualidade;
Tempo;
Riscos;
Recursos humanos;
Custos.
Sero detalhadas as comparaes entre as metodologias geis e tradicionais
para cada um desses fatores apresentados, esclarecendo as vantagens e
desvantagens entre as mesmas.
clssicas
3.2.2.1 Escopo
No modelo tradicional, a aquisio dos requisitos intensa nessa fase. A
equipe de desenvolvimento far entrevistas com o cliente e o usurio final, obtendo
todas as informaes a respeito dos processos de negcio, as funes que o
software ir realizar. Nessa fase no pode haver erros, como interpretaes
errneas e informaes falsas. Isso pode ocasionar o fracasso do projeto.
Os resultados obtidos atravs dessas entrevistas, e aps anlise, devero
ser documentados para que outros analistas - de prazo, custos e riscos possam
us-los para a posterior anlise.
Na metodologia gil, ocorre um planejamento superficial dos requisitos, no
incio do projeto, com a finalidade de informar a equipe de anlise de requisitos
todas as estrias identificadas.
Diferentemente da metodologia tradicional, a metodologia gil detalha o
escopo a cada iterao no caso do Scrum, a cada Sprint. Essa forma de
detalhamento feita sem a obrigatoriedade de documentao, de forma interativa,
junto com o cliente.
Ao final, percebe-se que o planejamento sai da fase inicial do processo e
passa a ser executado a cada iterao, na fase de execuo, ao longo do projeto.
3.2.2.2 Tempo
Na metodologia tradicional, o planejamento do tempo baseado na
separao das atividades do projeto, desde o incio at a entrega ao cliente,
organizando-as numa sequncia coerente e realizando a estimativa de durao.
Ainda assim, uma atividade muito complicada, pois no possvel prever
precisamente todos os detalhes e quais atividades estaro sendo feitas no futuro.
Essas estimativas precisam ser revistas ao longo do projeto, caso apaream novas
informaes durante o desenvolvimento.
Um detalhe importante no desenvolvimento de sistemas que o principal
fator de influncia o ser humano. Ento a estimativa de prazo precisa respeitar os
clssicas
aspectos humanos. Por exemplo, caso algum desenvolvedor fique doente, tenha
problemas particulares graves, entre outras possibilidades. Por esses motivos,
geralmente o gerente de projeto cria estimativas com prazos um pouco maiores para
ter algum tempo de folga, caso apaream problemas de fator humano no projeto.
Mas deve-se tomar cuidado para que essas estimativas no ultrapassem o prazo de
entrega do produto, muitas vezes acordado no incio do projeto.
J na metodologia gil, ocorre uma diviso de atividades de acordo com a
importncia das mesmas em relao ao cliente. As mais importantes so escolhidas
para serem desenvolvidas primeiro ento esses requisitos so divididos em
pequenas tarefas que sero desenvolvidas dentro de uma iterao.
O sequenciamento de atividades no existe na metodologia gil [5]. Nessa
metodologia, diferentemente da metodologia tradicional, no feito um
planejamento de todas as atividades que sero executadas no projeto. O
planejamento feito de forma dinmica ao longo da iterao.
Em casos onde as empresas que adotam a metodologia gil para a parte
de desenvolvimento, mas que se envolvem em negcios onde preciso exibir os
custos antecipadamente, por exemplo, numa licitao, ocorre um uso de
metodologias hbridas. Nesses casos, comum o uso de metodologia tradicional no
que se diz respeito documentao do processo e base de custos. Nessas
metodologias hbridas, o processo de documentao importante para passar ao
cliente as estimativas de preo e custo, a fim de que o mesmo aprove ou realize
eventuais revises.
3.2.2.3 Qualidade
Na metodologia tradicional, o plano de qualidade feito pela equipe de
gerncia de qualidade do projeto. Nesse plano esto listados os atributos de
qualidade do projeto. Entre esses atributos esto: segurana, confiabilidade,
modularidade, portabilidade, facilidade de uso e outros. Dependendo da finalidade
do software, o seu desenvolvimento ser executado de acordo com a ordem de
importncia dos atributos.
clssicas
necessrio definir a importncia de cada atributo, evitando que a equipe
de desenvolvimento utilize fora mais que necessria para executar o projeto.
Entende-se fora mais que necessria como tecnologias que no precisam estar no
projeto.
Tambm considerado um atributo de qualidade de software a
conformidade das funes do mesmo com as necessidades do cliente. Mesmo que o
software preencha vrios atributos como segurana, confiabilidade e modularidade,
um software que no atende as necessidades do cliente considerado de m
qualidade.
Na metodologia gil, o planejamento de qualidade, mais uma vez, deixa de
ser feito no incio do projeto, o que levaria previso de aes num futuro distante e
passa a ser feito iterativamente, durante o desenvolvimento, visando aproximao
com as necessidades do cliente.
Nessa metodologia, cada requisito, e no atributos de qualidade, avaliado
quanto sua importncia. a chamada avaliao externa do produto, feita pelo
cliente, que ter por finalidade obter do cliente as caractersticas que mais lhe
interessam.
Existe tambm a qualidade interna do software. Esta anlise feita pela
equipe de desenvolvimento do software. Nesse tipo de qualidade, so vistos os
aspectos de como o software deve ser desenvolvido, quais tcnicas e qual o prazo
para a entrega do mesmo.
A qualidade interna deve ser discutida entre o cliente, geralmente os
responsveis pela rea de T.I. do cliente, e os desenvolvedores durante o
planejamento de cada iterao. O cliente pode interferir no aspecto de segurana e
portabilidade, a fim de atender s suas necessidades, mas quanto ao prazo, isso fica
exclusivamente sob responsabilidade dos desenvolvedores. O prazo dito com
atributo no negocivel.
Nesse ponto, destaca-se a observao de que as metodologias tradicionais
usam o controle para medir a qualidade do desenvolvimento. J as metodologias
geis usam uma abordagem com foco na qualidade durante o desenvolvimento.
clssicas
3.2.2.4 Riscos
Os riscos, dentro da metodologia tradicional, so identificados e as suas
solues ser incorporadas ao plano de projeto. Em muitos casos, uma equipe de
desenvolvimento tem capacidade de identificar os riscos durante o perodo inicial do
desenvolvimento, mas prever riscos que podero acontecer ao longo dos anos
uma tarefa extremamente complicada.
Na metodologia gil, para diminuir riscos de desenvolvimento, o cliente
comea a fazer parte da equipe de trabalho. Ele ajudar nos problemas relacionados
ao escopo do projeto, pois, com suas estrias, o especialista pode identificar um
risco grande, trazendo sua soluo j para o incio do projeto.
Nas metodologias geis, no se faz uso de documentos contendo um plano
formal de gerncia de riscos. Esses riscos so abordados atravs das reunies
dirias realizadas pela equipe de desenvolvimento.
3.2.2.5 Recursos Humanos
As pessoas que iro trabalhar na equipe de desenvolvimento do software
sero contratadas pela equipe de gerncia de recursos humanos. desejvel que
sejam contratadas pessoas com grande experincia e possuam conhecimentos
apropriados para o projeto. Porm, existe a possibilidade do oramento ser limitado,
fazendo com que o gerente de recursos humanos contrate pessoas sem muita
experincia, mas tambm com pouca remunerao.
O problema de contratar pessoas sem muita experincia consiste no
aparecimento de pequenos erros ao longo do projeto que podem aumentar os riscos
relacionados ao tempo, qualidade e custo do projeto.
Grupos de projetos de software no devem ter mais que oito participantes,
devido dificuldade de grandes equipes trabalharem de maneira eficaz para
resolver um nico problema [7]. Com isso, dividindo a equipe, os problemas de
comunicao so diminudos.
clssicas
Na metodologia tradicional, a equipe tem uma diviso bem clara de
funes. Analista de sistemas, programador e testador so os cargos de uma equipe
nessa metodologia. Cada um participa exclusivamente da fase de projeto que lhe diz
respeito. O uso de pessoas especializadas em uma nica fase do projeto facilita o
caso de substituio, utilizando a mo de obra disponvel do mercado.
Na metodologia gil, o desenvolvedor exerce todas as funes listadas
anteriormente. Com isso, ele pode ser usado em diversas etapas do projeto. O
problema que com essa acumulao de funes, os profissionais dessa
metodologia precisam ser de alta capacidade, capazes de definir a melhor forma de
desenvolvimento e testes.
O desenvolvedor, nas metodologias geis multi-capacitado, sendo de
difcil substituio. Por outro lado, essas metodologias incentivam o aprimoramento
do profissional, tornando-o mais importante dentro de uma equipe.
3.2.2.6 Custos
Na metodologia tradicional, os custos j so alocados no incio do projeto,
a partir das tarefas designadas s equipes de desenvolvimento e anlises de
estimativas. Portanto elaborada uma base de custos que ser acompanhada
durante a execuo do projeto com a finalidade de comparar os custos atuais com
os custos iniciais.
Na metodologia gil, o custo do projeto fixo e s ir variar caso o cliente
solicite uma renovao do contrato. Essa renovao est associada ao fato do
cliente estar satisfeito com a empresa ou com alguma alterao no escopo de
projeto corrente solicitada pelo cliente.
A alocao de recursos no feita no incio do projeto e sim, durante a
realizao do mesmo, a cada iterao. O desenvolvedor tem a livre escolha para
executar as tarefas do projeto em funo do andamento do desenvolvimento. Como
ele tem uma viso mais tcnica, o melhor a tomar essa deciso.
clssicas
3.2.3 Execuo
Nas metodologias tradicionais, ao iniciar a execuo de um projeto, deve-se
seguir exatamente o que est definido no plano de projeto, definido na fase de
planejamento. A equipe de desenvolvedores segue essa documentao e suas
equipes so supervisionadas pela equipe de gesto de qualidade de modo que os
padres definidos sejam respeitados.
As equipes so divididas em funes especficas, como analistas,
programadores e testadores. Devido a essa diviso, uma capacitao pode ser
usada para desenvolver uma equipe que est apresentando um baixo ndice de
produtividade, para no comprometer o prazo de entrega do projeto. Existe tambm
um problema com a interao entre os membros da equipe, dificultando a
disseminao do conhecimento sobre o projeto e sobre as tecnologias usadas
durante a execuo do mesmo.
Nas metodologias geis, a execuo do projeto ocorre de forma mais
dinmica, onde os requisitos que sero desenvolvidos so discutidos em reunio na
fase inicial de cada iterao. Ocorre uma maior integrao entre os membros da
equipe, facilitando a comunicao e, com isso, aumentando o conhecimento a
respeito do projeto, tornando o profissional mais qualificado para projetos
posteriores.
3.2.4 Controle
Nas metodologias tradicionais, existe um rgido controle quanto s mudanas
no escopo do projeto. Qualquer alterao reflete como um risco a todo o projeto,
exigindo uma anlise de impacto em todas as reas que sero afetadas. Quanto ao
controle do tempo, existe um cronograma a ser seguido e tradicionalmente usado
o grfico de Gantt como referncia para saber se o desenvolvimento do projeto est
obedecendo ao tempo previsto no planejamento inicial.
Os custos do projeto so monitorados atravs da equipe de gerncia de
custos, a qual faz uma comparao com a linha de base de custos do projeto. Uma
no conformidade dos custos pode trazer a falta dos mesmos para a execuo do
resto do projeto, implicando at em sua paralisao para novas negociaes.
clssicas
Por fim, a qualidade controlada com o uso de documentao peridica,
escrita pela equipe de gerncia de qualidade. Caso existam no conformidades, a
equipe gera um relatrio que ser enviado s reas responsveis a fim de sanar os
problemas.
Na metodologia gil, no existe um controle rgido sobre o escopo. As
mudanas ficam a cargo do cliente. Essas mudanas so vistas como algo positivo,
pois trazem mais aprendizado equipe de desenvolvimento. No Scrum, por
exemplo, o controle do tempo se d com o auxlio de um grfico, chamado
Burndown. Esse grfico apresenta quais requisitos foram concludos e se o tempo
de execuo est obedecendo ao estipulado na reunio inicial da iterao. Caso um
requisito leve mais tempo que o necessrio, os outros membros da equipe realizam
um maior esforo, de modo que esse requisito seja finalizado dentro dessa
interao.
Nessa metodologia, no existe um controle rgido dos custos, pois com as
mudanas de escopo definidas pelo cliente, esses custos podem tanto aumentar
como diminuir. Ficar a cargo do cliente a gerncia dos custos, pois este est
participando ativamente da equipe de desenvolvimento.
Em alguns casos, os clientes no querem pagar mais do que j foi estipulado
no incio do projeto, como nos casos de uso hbrido de metodologias. Nessas
circunstncias, a estimativa de tempo no pode ter muitos erros, para no ocasionar
altos custos ao cliente. Existem ainda casos, como quando o sistema precisa de
uma correo, onde a empresa assume os custos para que o cliente no se sinta
insatisfeito com a empresa.
3.2.5 Encerramento
Nas metodologias tradicionais, no momento de encerramento de um projeto,
os participantes sero informados atravs de um documento formal. Sero
mostrados os indicadores de desempenho e de qualidade medidos durante a
execuo do projeto, e essas informaes sero levadas aos responsveis pelo
patrocnio do mesmo.
clssicas
J na metodologia gil, ser feita uma reunio, onde sero discutidos os erros
e acertos ocorridos durante o projeto. Esta definida com reunio de retrospectiva,
no caso do Scrum. Essa reunio tem como objetivo fortalecer o aprendizado entre os
membros da equipe. Tambm importante a participao do cliente para elevar a
moral da equipe, comemorando a entrega do projeto. Normalmente, no so
gerados documentos de entrega ao final do projeto.
Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide
Captulo 4
Estudo de caso Sistema de
Gesto Empresarial Pirmide
Nesse captulo, ser demonstrado como o uso de metodologias geis
ajudou o desenvolvimento em uma software house de modo que a alta demanda dos
clientes fosse suprida. Essas metodologias tambm ajudaram na gerncia de uma
maior quantidade de pessoas que foram contratadas para as equipes de
desenvolvimento.
A seguir ser feita uma apresentao da empresa Procenge e o sistema
estudado, o Pirmide. Aps essa apresentao, sero sintetizadas as opinies dos
especialistas da rea de qualidade de software, como tambm a opinio de
profissionais que antes trabalhavam usando somente a metodologia tradicional na
rea de manuteno e passaram a utilizar a metodologia gil, especificamente o
Scrum, para terem maior rendimento na produtividade.
4.1 A Procenge
A Procenge surgiu h 40 anos com o propsito de desenvolver sistemas de
gesto administrativa e de apoio tomada de decises. Est instalada no Porto
Digital do Recife desde 1998. Nesses anos de sua histria, desenvolveu parcerias
com empresas privadas e pblicas. Atualmente o maior foco da Procenge est nos
setores de saneamento, sucroenergtico (usinas de cana-de-acar), sade e gs.
Desde 2002, a Procenge passou a adotar normas exigidas pelas certificaes
de qualidade. Com isso, implantou o SGP Sistema de Gesto Procenge, que
redefiniu as orientaes estratgicas com definies de processos, prticas e
aplicao de recursos.
Aps essa reestruturao na sua gesto, a Procenge foi certificada com os
selos de qualidade ISO 9001:2008, CMMI nvel 2 e MPS.Br nvel F. O sistema de
gesto passa por revises peridicas, adaptando-se s mudanas exigidas por
essas instituies de qualidade.
4.2 O Pirmide
O sistema Pirmide o principal produto da Procenge. Esse sistema
proporciona que os diretores e gerentes obtenham todas as informaes
necessrias ao funcionamento da empresa de modo interligado. Oferecendo, assim,
agilidade e transparncia nos processos de gesto administrativa, do financeiro ao
setor de compras, do fiscal ao estoque. Por ser constitudo de vrios mdulos, a
manuteno do sistema se tornou muito difcil de ser gerido por apenas um gerente
de projeto.
O Pirmide uma soluo ERP (Enterprise Resource Planning) que se
aplica a empresas de todos os setores da economia. Ele incorpora aos seus
mdulos aspectos fundamentais da gesto empresarial, valorizando a integrao de
dados e flexibilidade de adaptao a empresas dos mais variados segmentos. O
software automatiza e integra os processos de diversas reas da organizao, tais
como: contabilidade, controladoria, financeira, suprimentos, produo, comercial,
logstica e RH, facilitando o fluxo de informaes entre elas.
4.3 Estudo de caso
O caso estudado foi como a incorporao da metodologia gil no processo
de manuteno e evoluo do Pirmide ajudou as equipes de desenvolvimento a
terem maior produtividade e aquisio de conhecimento tcnico e de negcios,
tornando-se mais especializados.
Anteriormente, usando somente a metodologia tradicional, especificamente
a metodologia em cascata, toda a rea de manuteno era gerida a partir de
documentos de especificao e implementao. A fbrica do Pirmide conseguia
suprir a demanda dos clientes no que diz respeito s correes e novas
funcionalidades, mas o tempo de desenvolvimento estava se tornando alto,
justamente pelo alto uso de documentao de projeto, principalmente na
especificao dos requisitos e na implementao.
A partir de ento, comeou a ser adotado um sistema de gesto, onde
todos os procedimentos de atendimento do Pirmide foram mapeados,
documentados e organizados. A esse sistema foi dado o nome de SGP Sistema de
Gesto Procenge. A Figura 11 ilustra de modo geral como composto o sistema.
Figura 11. Sistema de Gesto procenge
[Fonte: Intranet Procenge]
O SGP contm todos os procedimentos os quais os profissionais
contratados pela Procenge devem tomar como referncia para o desenvolvimento do
Pirmide. O sistema est estruturado conforme as normas da ISO 9001. No topo
dessa estrutura de documentao est o manual da qualidade, que um documento
estratgico da organizao, e que apresenta o modelo de gesto da empresa. Neste
esto contemplados a poltica e os objetivos da qualidade, as autoridades e
responsabilidades, o comprometimento da alta direo, o escopo, os indicadores de
acompanhamento de objetivos e processos e o mapeamento dos processos do
SGP, assim como referncias aos procedimentos que orientam a operacionalizao
desses processos.
Aps a criao desse sistema, a gerncia de qualidade tomou a deciso de
incorporar a metodologia gil, especificamente o Scrum, no processo de
manuteno e evoluo do Pirmide.
A partir do uso de metodologia gil, o tempo entre receber a solicitao de
mudana do cliente e a entrega da verso final diminuiu. Em termos de medio,
uma mudana que levaria duas semanas para ser entregue usando a metodologia
em cascata, est sendo entregue em uma semana; pois, com as reunies de
planejamento feitas no comeo de cada iterao (Sprint) o entendimento fica mais
disseminado entre os membros da equipe.
O software tambm se tornou mais robusto e confivel com o uso do
Scrum, pois todos os membros da equipe adquirem maior conhecimento para
realizar os testes necessrios identificao de bugs.
Outra vantagem trazida pelo Scrum fbrica foi a descentralizao da
gerncia de projetos. O acompanhamento comeou a ser feito pelos Scrum Masters;
assim, o gerente de projetos deixou de acompanhar cada desenvolvedor
individualmente. Ele agora acompanha as equipes, que passaram a distribuir o
escopo de maneira interna, tornando-as auto gerenciveis, o que aumentou a
responsabilidade dos membros.
Por ltimo, houve tambm a disseminao do conhecimento de negcio do
Pirmide entre os membros da equipe. Hoje no somente a pessoa que ir
desenvolver uma solicitao que deve entender o que foi pedido, mas todos na
equipe de desenvolvimento devem entender, caso seja necessrio ajudar na entrega
desse pedido em um tempo mais curto do que foi inicialmente estimado.
O que ocorre nesse projeto , na verdade, uma hibridizao de
metodologias. O processo se inicia com uma solicitao do cliente empresa
referente a uma modificao que se queira realizar no software. Ento, esse pedido
encaminhado ao especialista de produto, que um profissional com alto
conhecimento de prticas de mercado, para que ele encontre uma soluo que
obedea aos padres do sistema.
Aps essa soluo ter sido documentada num documento de requisitos
tradicional, a mesma encaminhada ao analista de sistemas responsvel pela rea
do sistema em que essa soluo far parte. Este ento faz a estimativa de tempo e
esforo, a qual indicar os valores a serem cobrados pela Procenge ao cliente.
Somente aps a validao dessa documentao de estimativa e custos pelo cliente,
que a metodologia gil comea a ser usada.
Com o Scrum, essas requisies de cliente validadas ficam dentro do backlog
de produto, no qual so organizados em ordem de prioridade, definida pela
Procenge. Ao incio de uma Sprint, essas requisies so discutidas e
implementadas pela equipe de desenvolvimento. No momento da entrega, os
detalhes da soluo so documentados para uma posterior consulta de outros
clientes e desenvolvedores.
A cada dois meses, um documento redigido com todos os indicadores de
qualidade e produtividade para ser mostrado aos gestores da Procenge. Existem
tambm documentos com instrues relativas manuteno da qualidade de todo o
processo, que todos os membros da equipe devem seguir.
O apoio do Scrum, junto prtica das metodologias tradicionais,
proporcionou, segundo os profissionais de qualidade e de desenvolvimento, maiores
ndices de satisfao dos clientes, melhores ndices de produtividade das equipes e
maior qualidade ao software. Tornando-o, portanto, mais confivel.
Captulo 5 Concluses e trabalhos futuros
Captulo 5
Concluses e trabalhos futuros
A partir do estudo feito, conclui-se que o uso das metodologias tradicionais
est cedendo seu espao, pelo menos nas reas de manuteno de sistemas, s
metodologias geis devido sua alta burocracia, que exige todo o planejamento j
na fase inicial do projeto. J a metodologia gil, chega para tornar o ambiente de
desenvolvimento de softwares mais produtivo e dinmico, ajudando s empresas a
conquistarem mais clientes e trazendo mais qualidade aos seus produtos.
Nas metodologias geis, os profissionais tornam-se mais especializados, ao
passo que eles precisam ter conhecimento de anlise, programao e testes. Com
isso, as empresas encontram dificuldades em contratar pessoas com grandes nveis
de conhecimento. preciso tambm levar em conta que, dependendo do projeto, se
torna necessria uma equipe relativamente grande para o desenvolvimento do
sistema. No caso do Pirmide, alguns mdulos possuem mais profissionais que
outros, devido ao seu uso ser mais intenso nos clientes.
Com o uso de metodologias tradicionais, no final de um projeto, o sistema
pode ficar defasado em relao aos requisitos do cliente, caso as necessidades do
negcio do cliente mudem com o tempo. Nas metodologias geis, o
desenvolvimento do sistema acompanha as atualizaes nos processos da empresa
solicitante.
As metodologias geis oferecem uma abordagem com foco maior na
qualidade, diferentemente das metodologias tradicionais. As metodologias geis
procuram sempre validar com o cliente quais so os requisitos mais importantes a
serem desenvolvidos, garantindo maior qualidade e satisfao dos clientes.
No futuro, a ideia seria trabalhar algumas limitaes das metodologias geis,
como a falta de anlise de riscos, que ainda um ponto mais tratado pelas
metodologias tradicionais. Sem essa anlise mais profunda, um risco de grandes
Captulo 5 Concluses e trabalhos futuros
propores, que no foi visto anteriormente, pode aparecer j na fase de entrega do
projeto, causando um atraso, que, por sua vez, pode causar insatisfao do cliente.
Ao trabalhar nesse ponto, as metodologias geis podem se tornar mais
completas e auxiliar o uso de metodologias tradicionais nos projetos mais recentes,
possibilitando o aparecimento de processos hbridos de desenvolvimento de
sistemas.

Referncias
Referncias
[1] Agile Manifesto. Disponvel em: http://www.agilemanifesto.org/iso/ptbr/.
Acesso em: 20/10/2012.
[2] Brooks, F. No Silver Bullet: Essence and Accidents of Software Engineering.
Proc. IFIP, IEEE CS Press, pp. 1069-1076; reprinted in IEEE Computer, pp. 10-19,
Apr. 1987.
[3] Cockburn, A. e Highsmith, J. Agile Software evelopment: The Business of
Innovation, IEEE Computer, Sept., pp. 120-122, 2001.
[4] Pressman, R. Engenharia de Software. McGraw-Hill, 6 Edio. 2006
[5] Silva, F. L. de Carvalho e da Silva, V. B. Estudo comparativo dos processos
de desenvolvimento de software gil e tradicional, sob a tica do guia PMBOK,
Trabalho final do curso de ps-graduao em produo de sistemas no Instituto
Federal de Educao, Cincia e Tecnologia Fluminense, 2009.
[6] Soares, S. M. Comparao entre Metodologias geis e Tradicionais para
Desenvolvimento de Software, INFOCOMP Journal of Computer Science, v. 3, n. 2,
pp. 08-13, 2004.
[7] Sommerville, I. Engenharia de Software. Editora Addison-Wesley. 592p, 2003.
[8] Marina Martinez. RUP. Disponvel em: http://www.infoescola.com/engenharia-
de-software/rup/. Acesso em 15 de dez. 2012.
[9] Guia on-line do RUP. Disponvel em:
http://www.wthreex.com/rup/portugues/index.htm. Acesso em 15 de dez. 2012.
[10] Best Practices for Development Teams. Disponvel em:
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_
bestpractices_TP026B.pdf. Acesso em: 15 de dez. 2012

Bruno Junqueira Alves - Monografia - Metodologia Agil

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bruno Junqueira Alves - Monografia - Metodologia Agil

Enviado por

Direitos autorais:

Formatos disponíveis

Estudo Comparativo entre Mtodos geis e

Tradicionais de Fabricao de Software

Você também pode gostar