Você está na página 1de 7

Desenvolvimento de projectos de Software: Metodologias geis ou Tradicionais?

Diogo Pinheiro
Gesto Estratgica de Sistemas de Informao
Mestrado em Informtica e Gesto
Instituto Superior das Cincias do Trabalho e da Empresa (ISCTE)
1. RESUMO

A indstria de desenvolvimento de software


tem-se tornado uma das mais importantes
indstrias da actualidade. Empregando
milhares de trabalhadores em todos os pases
do mundo, esta indstria cria alguns dos
produtos mais essenciais que ns utilizamos
para manter o nosso estilo de vida. medida
que as exigncias dos consumidores e do
mercado vo crescendo novos produtos cada
vez mais sofisticados e complexos tero de
ser desenvolvidos. Para o sucesso no
desenvolvimento
destes
projectos
de
Software essencial existir uma boa
utilizao de metodologias responsveis pela
gesto de toda a equipa e implementao dos
requisitos no decorrer do mesmo. Como tal,
agora mais de que nunca, grandes
discusses se tm realizado a fim de
descobrir qual a melhor metodologia a utilizar
para se construir e gerir um software perfeito,
no menor prazo possvel, e que no final
clientes e equipas responsveis se sintam
satisfeitos com o resultado obtido.
Esta
indeciso
engloba
duas
grandes
metodologias: a mais antiga e mais utilizada
nos primrdios de gesto de projectos, a
metodologia tradicional, e a mais recente, a
metodologia gil. O que se pretende neste
artigo efectuar uma sntese, com base nos
estudos anteriores, de forma a identificar qual
destas metodologias ser mais indicada para
a gesto de projectos de software. Palavraschave: gesto de projectos, metodologias
geis, metodologia tradicional, iterativa,
software, projectos de software.
2. INTRODUAO

A Gesto de Projectos moderna surgiu


inicialmente no Departamento de Defesa dos
Estados Unidos, no Projecto Manhattan em
1940 (Lenfle, 2008). As prticas e tcnicas
modernas de gesto de projectos foram
desenvolvidas durante os projectos Atlas e

Polaris na dcada de 1950 (Kerzner, 2005)


pelo Dep. De Defesa e, noutros grandes
projectos de engenharia nos sectores da
construo civil e aeroespacial (Maylor,
2001). Tais prticas e tcnicas modernas tm
evoludo ao longo dos anos, tendo dado
origem ao Body of Knowledge (BoK)
expresso como o PMBoK, que servem como
padro de terminologia e aplicao (Conforto,
2009, p. 21) e so mantidos por institutos e
associaes como o Project Management
Institute
(PMI),
International
Project
Management Association (IPMA), Australian
Institute of Project Management (AIPM) e a
Association for Project Management of United
Kingdom (APM-UK). Nos projectos de
software, a gesto de projectos foi introduzida
por meio de abordagens actualmente
denominadas tradicionais ou pesadas,
baseadas no desenvolvimento em cascata
Waterfall termo utilizado pela primeira vez
no artigo Managing the development of large
software systems (Royce, 1970). Estas
abordagens distinguem-se por concentrar
grande esforo no levantamento detalhado
dos requisitos funcionais na fase de anlise,
identificao
e
mitigao
de
riscos,
elaborao de planos de contingncia com o
objectivo de produzir um documento de
especificao dos requisitos Software
Requirement Specification (SRS) o qual
serve como entrada para o desenho do
produto. Um projecto de desenvolvimento de
software pode ser considerado muitas vezes
como um processo incerto, ao contrrio, por
exemplo, de um projecto de construo civil,
que sustentado por leis da Matemtica e da
Fsica. Em consequncia da inerente
incerteza e complexidade envolvida no
processo de desenvolvimento de software,
diferentes abordagens de gesto de projectos
foram
criadas
e
actualmente
so
consideradas tradicionais, tais como as
sequenciais e as iterativas. As abordagens
geis ou leves Lightweight Methods (Beck, et al., 2001) ganharam fora na
dcada de 1990 com uma proposta do

desenvolvimento incremental, adaptvel e


flexvel para compensar tais incertezas e
variveis desconhecidas definidas por
Rumsfeld (2011) como unknown unknowns.
Entre os dias 11 e 13 de Fevereiro de 2001,
no The Lodge em Snowbird, em Utah nos
Estados Unidos, um grupo de 17 experientes
programadores (Beck, et al., 2001) e
consultores em desenvolvimento de software
assinaram e introduziram as abordagens
geis sob a forma de um manifesto. Esse
grupo posteriormente fundou a Agile Alliance,
que em 2001 props o Manifesto para o
Desenvolvimento gil de Software ou
Manifesto gil [1].
Pretende-se neste artigo, com base em
estudos j realizados, analisar e comparar
estas duas metodologias com o objectivo de
identificar qual delas se deve escolher no
desenvolvimento de projectos de software.
Por outro lado, defino como objectivo dar um
contributo sustentado para um maior
conhecimento e divulgao destas duas
metodologias para as organizaes, em
particular empresa onde me encontro e s
eventuais empresas onde possa estar
empregado no futuro.

metodologia que existe numa sequncia a ser


seguida de uma etapa a outra. Cada etapa
tem associada ao seu trmino uma
documentao padro que deve ser aprovada
para que se inicie a etapa imediatamente
posterior. De uma forma geral as fases que
fazem parte do modelo Clssico so a
definio de requisitos, projecto do software,
implementao e testes unitrio, integrao e
teste do sistema, operao e manuteno. O
problema do modelo em Cascata sua
inflexvel diviso do projecto em fases
distintas, o que dificulta possveis alteraes
que
so
bastantes
comuns
no
desenvolvimento dum projecto. um modelo
que deve ser usado somente quando os
requisitos forem bem compreendidos.

3. METODOLOGIAS TRADICIONAIS

As metodologias tradicionais so tambm


chamadas de pesadas ou orientadas a
documentao. Essas metodologias surgiram
num contexto de desenvolvimento de
software muito diferente do actual, baseado
apenas numa mainframe [Royce (1970)]. Na
poca, o custo de fazer alteraes e
correces era muito alto, uma vez que o
acesso aos computadores eram limitados e
no existiam ferramentas modernas de apoio
ao desenvolvimento do software, como
depuradores e analisadores de cdigo. Por
isso o software era todo planejado e
documentado antes de ser implementado. A
principal metodologia tradicional e muito
utilizada at hoje o modelo Clssico.
3.1.

MODELO CLSSICO

O modelo Clssico ou Sequencial [Pressman


(2001)] foi o primeiro processo publicado de
desenvolvimento de software. Desde a sua
introduo tem sido bastante utilizado. uma

A figura 1 ilustra graficamente o modelo


Clssico. Este dominou a forma de
desenvolvimento de software at o incio da
dcada de 90, apesar das advertncias dos
pesquisadores da rea e dos programadores,
que identificaram os problemas gerados ao se
adoptar esta viso sequencial de tarefas. Por
exemplo, um investigador, Tom Gilb,
desencoraja o uso do modelo Clssico em
grandes
softwares,
estimulando
o
desenvolvimento incremental como um
modelo que apresenta menores riscos e
maiores possibilidades de sucesso [Gilb
(1999)]. Dados de 1995 [Standish Group,
(1995)], utilizando como base 8380 projectos,
mostram que apenas 16,2% dos projectos
foram entregues respeitando os prazos,
custos
e
todas
as
funcionalidades
especificadas. Aproximadamente 31% dos
projectos foram cancelados antes de estarem
completos e 52,7% foram entregues, porm
com prazos e custos maiores ou com menos

funcionalidades do que especificado no incio


dos mesmos. Entre os projectos que no
foram finalizados de acordo com os prazos e
custos especificados, a mdia de atrasos foi
de 222%, e a mdia de custo foi de 189% a
mais do que o previsto. Considerando todos
os projectos que foram entregues para l do
prazo e com custo maior, em mdia, apenas
61% das funcionalidades originais foram
includas. Mesmo os projectos que foram
entregues respeitando os limites de prazo e
custo possuem qualidade suspeita, uma vez
que provavelmente foram feitos com muita
presso
sobre
os
programadores
responsveis, o que pode quadruplicar o
nmero de erros de software, segundo a
mesma pesquisa. As principais razes destas
falhas estavam relacionadas com o modelo
Clssico. A recomendao final foi que o
desenvolvimento de software deveria ser
baseado em modelos incrementais, o que
poderia evitar muitas das falhas reportadas.

software estar executvel, com a colaborao


do cliente e as respostas rpidas a mudanas
e alteraes. Esses conceitos aproximam-se
melhor com a forma que pequenas e mdias
organizaes trabalham e respondem a
mudanas. Entre as metodologias geis a
mais conhecida a Extreme Programming.

4. METODOLOGIAS AGEIS

O primeiro projecto a usar XP foi o C3, da


Chrysler. Aps anos de fracasso utilizando
metodologias tradicionais, com o uso da XP o
projecto ficou pronto em pouco mais de um
ano [Highsmith et al., (2000)]. A maioria das
regras da XP causam polmica primeira
vista e muitas no fazem sentido se aplicadas
isoladamente. a sinergia do seu conjunto
que sustenta o sucesso da XP, encabeando
uma
verdadeira
revoluo
no
desenvolvimento de software. A XP enfatiza o
desenvolvimento rpido do projecto e visa
garantir a satisfao do cliente, alm de
favorecer o cumprimento das estimativas. As
regras,
prticas
e
valores
da
XP
proporcionam um agradvel ambiente de
desenvolvimento de software para os seus
seguidores, que so conduzidos por quatro
valores: comunicao, simplicidade, feedback
e coragem [Beck (1999)]. A finalidade do
princpio de comunicao manter o melhor
relacionamento possvel entre clientes e
programadores,
preferindo
conversas
pessoais a outros meios de comunicao. A
comunicao entre os programadores e o
gestor de projecto tambm encorajada. A
simplicidade visa permitir a criao de cdigo
simples que no deve possuir funes
desnecessrias. Por cdigo simples entendese implementar o software com o menor

O termo Metodologias geis tornou-se


popular em 2001 quando dezassete
especialistas
em
processos
de
desenvolvimento de software representando
os mtodos Scrum [Schwaber e Beedle
(2002)], Extreme Programming (XP) [Beck
(1999)] e outros, estabeleceram princpios
comuns compartilhados por todos esses
mtodos. Foi ento criada a Aliana gil e o
estabelecimento do Manifesto gil [Agile
Manifesto (2004)]. Os conceitos chave deste
manifesto so:

Indivduos e interaces ao invs


de processos e ferramentas.
Software executvel ao invs de
documentao.
Colaborao do cliente ao invs de
negociao de contratos.
Respostas rpidas a mudanas ao
invs de seguir planos.

O Manifesto gil no rejeita os processos e


ferramentas, a documentao, a negociao
de contratos ou o planeamento, mas
simplesmente mostra que estes tm uma
importncia secundria quando comparado
com os indivduos e interaces, com o

4.1.

EXTREME PROGRAMING

A Extreme Programming (XP) uma


metodologia gil para pequenas e mdias
equipas que desenvolvem software baseado
em requisitos vagos e que se modificam
rapidamente [Beck (1999)]. As principais
diferenas da XP em relao s outras
metodologias so:

Feedback constante;
Abordagem incremental;
A comunicao entre as pessoas
encorajada.

nmero possvel de classes e mtodos. Outro


factor importante da simplicidade procurar
implementar apenas requisitos actuais,
evitando adicionar funcionalidades que
podem ser importantes no futuro. A prtica do
feedback
constante
significa
que
o
programador ter informaes constantes
relativas ao cdigo e ao cliente. A informao
do cdigo dada pelos testes constantes,
que indicam os erros tanto individuais quanto
do software integrado. Em relao ao cliente,
o feedback constante significa que ele ter
frequentemente uma parte do software
totalmente funcional para avaliar. O cliente
sugere
ento
constantemente
novas
melhorias
e
funcionalidades
aos
desenvolvedores. Eventuais erros e no
conformidades so rapidamente identificados
e corrigidos nas prximas verses. Desta
forma, a tendncia que o produto final
esteja de acordo com as expectativas reais
do cliente. Por vezes necessrio mudar a
mentalidade dos envolvidos e da organizao
j que no so todas as pessoas que
possuem esta facilidade de comunicao e
tm o dom do bom relacionamento
interpessoal. ainda necessrio estar
sempre receptivo e aceitar os pedidos de
mudanas constantes. A coragem tambm d
suporte simplicidade, pois assim que a

oportunidade de simplificar o software


percebida, a equipa pode experimentar.
5. COMPARAO ENTRE METODOLOGIAS

Figura 2 - Modelo do Extreme Programing

As metodologias geis ainda esto numa fase


muito precoce, no entanto j apresentam
resultados efectivos. Por exemplo, um artigo
[2] comparando mtodos geis com as
metodologias tradicionais mostrou que os
projectos que usam os mtodos geis
obtiveram melhores resultados em termos de
cumprimento de prazos, custos e padres de
qualidade. Alm disso, o mesmo estudo
mostra que o tamanho dos projectos e das
equipas que utilizam as metodologias geis
tm crescido. Apesar de serem propostas
idealmente para serem utilizadas por equipas
pequenas e mdias (at 12 programadores),
aproximadamente 15% dos projectos que
usam metodologias geis so desenvolvidos
por equipas de 21 a 50 pessoas, e 10% dos
projectos so desenvolvidos por equipas
formadas por mais de 50 pessoas,
considerando um universo de 200 empresas
usado no estudo. Em relao do software,
de acordo com [3] e [4] o uso correcto da XP
pode levar a organizao a atingir os nveis
CMM [5] 2 e 3, apesar do CMM ser orientado
a metodologias tradicionais e ter como foco o
que fazer, enquanto a XP foca o como
fazer. Juntos estes mtodos formam uma
framework para estruturar o desenvolvimento
de software de uma organizao.
Para ser realmente considerada gil a
metodologia deve aceitar a mudana ao invs
de tentar prever o futuro. O problema no a
mudana em si, at porque ela ocorrer de
qualquer forma. O problema como receber,
avaliar e responder s mudanas. Como
exemplo, as aplicaes baseadas em Web
so melhor modeladas usando metodologias
geis, uma vez que o ambiente Web muito
dinmico. As metodologias pesadas devem
ser aplicadas apenas em situaes em que
os requisitos do software so estveis e
requisitos futuros so previsveis. Estas
situaes so difceis de serem atingidas,
uma vez que os requisitos para o
desenvolvimento de um software so
mutveis. Entre os factores responsveis por
alteraes nos requisitos esto a dinmica
das organizaes, as alteraes nas leis e as
mudanas pedidas pelos stakeholders, que
geralmente tm dificuldades em definir o
escopo do futuro do software. Estima-se que
caso alguma alterao tenha como custo 1x
quando feita na fase de requisitos, esta ter
um custo de 60x a 100x quando feita na

fase de implementao [Pressman (2001)], ao


se usar o modelo Clssico. Portanto,
alteraes nos requisitos no modelo Clssico
no so desejveis. [6] Estas entregas
constantes das metodologias geis evitam
que o cliente precise de esperar muito para
ver o software a funcionar, como nas
metodologias tradicionais. A integrao e os
testes contnuos tambm possibilitam a
melhoria na qualidade do software.

No entanto, a XP apresenta tambm algumas


desvantagens e problemas, e tem recebido
ao longo do tempo algumas crticas. Muitos
acreditam que esta incentiva a um processo
catico de desenvolvimento de software,
conhecido tambm como codifica-remenda
[7]. Este modelo catico existe principalmente
nas pequenas e mdias organizaes que
no podem suportar os altos custos de
desenvolvimento ao usar metodologias
tradicionais. A XP possui a tendncia de
eliminar vrias boas prticas que existiram
durante muitos anos no desenvolvimento de
software. Por exemplo, a anlise do problema
por meio de diagramas. Tambm a anlise de
requisitos parece ser muito informal. Esta
informalidade na captura de requisitos pode
no ser bem vista pelos clientes, que podem
sentir
alguma
insegurana.
Outra
possibilidade de insegurana a grande
refactorizao de cdigo, que pode ser vista
pelos
clientes
como
amadorismo
e
incompetncia. Na XP no existe a
preocupao formal em fazer a anlise e o
planeamento de riscos. Como os riscos
acontecem normalmente nos projectos de
desenvolvimento de software, este um
ponto negativo da XP. Deve-se, portanto,
procurar implementar uma estratgia de
gesto de riscos sem tornar a metodologia
muito complexa. De forma geral, as 12 [8]
prticas da XP apoiam-se mutuamente.
Portanto,
deve-se
procurar
aplic-las

utilizadas por equipas de pequena dimenso,


como referido em cima. Neste caso, pelo
menos necessrio resolver os problemas de
comunicao internos na equipa, uma vez
que comum em grandes empresas os
funcionrios
estarem
separados
geograficamente.

totalmente, ou a maior parte possvel. No


entanto a implementao de todas as prticas
pode ser confusa, levando ao abandono
prematuro da XP. Segundo Beck [9], as
prticas da XP podem ser implementadas
uma a uma para que sejam evitadas
confuses, desentendimentos e presses,
pois a equipa sobre presso tem a tendncia
de voltar a aplicar as prticas mais fceis e
por vezes menos correctas para a situao
correspondente.

Atendendo a esta situao e analisando todos


os pontos sobre cada uma das metodologias
apresentadas neste artigo fulcral entender o
projecto antes de decidir qual das duas usar.
Se, na viso do cliente, o produto apenas faz
sentido se for entregue na sua totalidade,
utilizar mtodos geis ignorar os riscos,
para alm de aumentar os custos. Outro
ponto a ser considerado quando se decide
por mtodos tradicionais ou geis a cultura
da empresa. Muitas vezes, mesmo quando
faz sentido no projecto uma gesto gil,
muitas vezes no ser possvel porque os
agentes envolvidos no esto acostumados
com esta forma de trabalho de entregas
rpidas e percepo de valor antes do
produto final.
Portanto, em suma, ambas as abordagens
so excelentes, mas no perfeitas, pois
possuem fraquezas em reas especficas ou
em determinados tipos de aplicaes em
projectos distintos. No entanto, quando
aplicadas em conjunto, podemse fortalecer e
complementar uma outra. [10]

6. CONCLUSO

As metodologias geis tm sido bem aceites


pela
indstria
de
software
e
por
investigadores da Engenharia de Software.
Apesar de no haver ainda uma grande base
de comparaes, os primeiros resultados tm
sido satisfatrios em relao s metodologias
Figura 3 - Comparao entre metodologias [1]

tradicionais. O desafio do futuro desta


metodologia ser encontrar meios para
eliminar alguns dos seus pontos fracos, que
so, no fundo, os pontos fortes das
tradicionais, como a falta de anlise de riscos,
sem torn-las metodologias pesadas. Outro
desafio como usar essa metodologia em
grandes empresas e equipas, uma vez que
normalmente
essas
metodologias
so

7. BIBLIOGRAFIA E REFERNCIAS

1. Elton Santos Vianna, Contribuio da


gesto gil para projectos de software: um
estudo emprico em portais de notcias do
Brasil, ISCTE-IUL, (2013)
2. Charette, R. Fair Fight? Agile Versus
Heavy Methodologies Cutter Consortium Eproject Management Advisory Service, 2001
3. Paulk, M. C. Extreme Programming from
a CMM perspective, IEEE Software, vol. 18,
n. 6, (2001), pp 19-26
4. Glazer, H. Dispelling the process myth:
having a process does not mean sacrificing
agility or creativity, Crosstalk, (2001)

5. The Capability Maturity Model: Guidelines


for Improving the Software Process, AddisonWesley, (1995)
6. Michel dos Santos Soares, Comparao
entre Metodologias geis e Tradicionais para
o Desenvolvimento de Software, Faculdade
de Tecnologia e Cincias de Conselheiro
Lafaiete
7. Pressman, R. Engenharia de Software

McGraw-Hill, (2001)
8. http://www.informant.com.br/blog/2014/03/
24/as-12-praticas-do-extreme-programming/,
2015
9. Beck, K., Programao
Explicada, Bookman, (1999)

Extrema

10. http://www.projectbuilder.com.br/ blogpb/entry/projetos/gestao-de-projetos-agil-outradicional-entenda-as-diferencas