Os desafios dos Mtodos Tradicionais e geis na Engenharia de

Software
(V 6)
Rafael Gulfier Reis
rafaelreis.ti@gmail.com
Jos do Carmo Rodrigues, MSc, PhD
jcrodrigues@uol.com.br
Curso de Ps-Graduao Lato Sensu em Engenharia e Arquitetura de
Software da UNESA Universidade Estcio de S.
Resumo
O presente trabalho traz as abordagens Tradicional e gil, no mbito
da engenharia de software, e discute as similaridades e diferenas entre
as duas metodologias. Mudanas na sociedade e inovaes tecnolgicas
trazem mudanas significativas no mercado, levando a demandas por
sofisticao, por parte dos usurios e frequentes modificaes no design
dos produtos por parte dos clientes. Para o desenvolvimento de um
software necessrio seguir processos que assegurem a qualidade do
desenvolvimento e a padronizao do produto computacional. Os Modelos
de Processos de Software, tem como objetivo, fazer com que o
desenvolvimento do mesmo, siga mtodos especficos para cada rea de
aplicao desenvolvida. A Metodologia gil empregada em diferentes
disciplinas em resposta as atuais mudanas no mercado. Este artigo tem
como objetivo comparar caractersticas, aplicaes e formas de trabalho
das duas metodologias de desenvolvimento de software. A metodologia
empregada foi uma extensa reviso de artigos, livros e sites da internet
para obteno de base argumentativa e de referncia. Foi realizado um
comparativo entre as tcnicas XP e RUP bem como de maneira geral entre
a Metodologia Tradicional e a gil. Atravs destes comparativos, foi
possvel justificar as principais diferenas entre estas duas metodologias
de desenvolvimento, estabelecendo uma relao de comparao entre
elas e apontando as principais vantagens da metodologia gil sobre a
tradicional.
Palavras-chave: Metodologia gil, Tecnologia da Informao, Projeto,
Desenvolvimento gil de Software.
1. Introduo
Os mtodos de desenvolvimento gil de software (DAS) so
caracterizados por se adaptarem a constantes mudanas de requisitos
pelos clientes bem como realizar projetos em um espao de tempo muito
menor. O ambiente dinmico de negcios e a customizao em massa
levaram a mudanas na produo de companhias e na implementao da
manufatura gil, o que se evidenciou nas ltimas dcadas. Por um lado,
tinha-se alta demanda de produtos customizados e, por outro, os produtos
oferecidos pelos produtores, o que juntos geraram a quebra no paradigma

de produo levando a aplicao do gil na manufatura (Milos, 2015). A

principal motivao por trs da agilidade a mudana.
De acordo com Milos (2015) Nagel e Dove introduziram o conceito
de manufatura gil em seus trabalhos sobre a indstria, os quais notaram
que essa teoria uma reao ao ambiente dinmico de negcios. O uso
de novas tecnologias trouxe necessidades mais exigentes dos usurios
resultando de diversas tendncias na sociedade, por exemplo, pelo uso de
redes sociais e de smartphones e similares (Milos, 2013, p. 2). Tendncias
similares podem ser observadas em TI e em desenvolvimentos de
software.
No final da dcada de sessenta e durante a dcada de setenta
diversas associaes de gerenciamento de projetos e community of
practice (CoP) fundiram-se (PMI, IPMA, PRINCE2), criando, portanto,
padres reconhecidos a serem usados por gerentes de projetos. O
processo de desenvolvimento de software baseado tambm na forma de
projeto. Alm disso, as definies do processo padro a ser executado nas
fases de incio, planejamento, implementao, controle e fechamento so
etapas fundamentais nesse campo. Projetos de manufatura, TI ou outros
projetos industriais da dcada de setenta eram previsveis. As exigncias
no mudavam to rapidamente e o mtodo plan drive, padro, era usado
sem problemas naquele momento (Lander, 2012, p. 2).
De forma semelhante ao Agile Manufacturing, em algumas
empresas de TI foi tambm introduzido a mesma filosofia sendo chamada
Agile Software Development ou Desenvolvimento de Software gil (DAS)
segundo Bassi Filho (2011, p. 21). O estudo das ideias e princpios dessa
metodologia so fundamentalmente as mesmas tanto na indstria quanto
na rea de TI. No desenvolvimento de software o termo gil implica na
capacidade de mudana rpida e fcil e isto a que se refere as
metodologias geis de desenvolvimento de software. Os mtodos geis
so muito apreciados e foram introduzidos durante os ltimos anos para
atender a demanda por softwares de alta qualidade em um espao de
tempo curto. Em diversas empresas a cultura organizacional
contempornea exige a criao de softwares em curto tempo, com custo
mnimo e em ambientes no ideais ou por muitas vezes altamente
mutveis (Bassi Filho, 2011, p.21-22).
Metodologias de desenvolvimento de software geis tm diversas
caractersticas particulares, tais como: prototipagem, desenvolvimento
interativo, maior interao com o cliente e membros do time e
documentao mnima, sendo uma metodologia alternativa aos mtodos
tradicionais de gerenciamento de projeto utilizadas no desenvolvimento
de software. O desenvolvimento de software gil (DSA) uma
metodologia criativa que possibilita flexibilidade e praticidade na entrega
do produto, focando em manter o cdigo simples, testando e entregando
a aplicao em partes e seu estudo traz ganhos significativos ao
gerenciamento de projetos nas corporaes (Bassi Filho, 2011, p.22).
2. Fundamentao Terica
2.1.

Metodologia tradicional de desenvolvimento de software

Uma maneira de melhorar o desenvolvimento de um projeto a

insero de um conjunto de processos repetitivos adequados que
introduzem consistncia, flexibilidades e eficincia de forma a melhorar a
qualidade do desenvolvimento em departamentos e empresas como um
todo. Consiste em processos descritivos, padres e atribuio de
responsabilidades, ciclos de vida e estruturas organizando intervalos no
trabalho, tudo somando a um suporte de informao (Bassi Filho, 2011,
p.9). As metodologias tradicionais de desenvolvimento de software,
tambm conhecidas como pesadas, tm como caracterstica marcante
sua diviso em etapas ou fases. Para Pressman (2011) essas fases so
definidas
e
englobam
atividades
como
Anlise,
Modelagem,
Desenvolvimento e Testes. Na concluso de cada fase gera-se um marco,
que pode ser um documento, como Diagramas de UML, um prottipo ou
verso do software. Metodologias
tradicionais
geralmente
so
desenvolvidas no modelo em cascata, e a cada alterao do projeto,
ser necessrio volta ao incio do projeto para alterao da
documentao ou de outro marco (Pressman, 2011) conforme mostra a
Figura 1.
Figura 1 Modelo de metodologia em cascata.
Requerimento

Projeto

Implementa
o

Verificao

Manuteno

Fonte: (Autoria Prpria)

Existem diversas metodologias tradicionais de desenvolvimento,

porm a reviso bibliogrfica feita neste artigo se limitou ao estudo de
trs delas, sendo a Sequencial Linear, Rational Unified Process (RUP) e a
Espiral. O processo Sequencial Linear um modelo proposto em 1970,
onde as fases so sistematicamente seguidas de maneira linear. o
modelo mais utilizado no mercado (Sommerville, 2011, p.18), porm no
considerado o mais eficaz, pois raros projetos seguem fluxo linear, alm
de mudanas de requisitos que ocorrem no projeto no serem de fcil
adaptao, porque alteram toda a documentao desenvolvida.

As etapas do processo linear so descritas de forma geral a seguir

(Sommerville, 2011, p.18-19):
- Definio dos requisitos: Deve-se identificar juntamente aos
usurios do software, os servios, metas e restries impostas ao sistema;
- Projeto do sistema e do software: Os requisitos identificados so
mapeados em componentes de hardware e software, de modo que o
sistema possa ser posteriormente implementado. Ocorre, ainda, a
fundamentao da arquitetura geral do sistema;
- Implementao e testes unitrios: Por meio da linguagem de
programao, implementa-se o projeto de software em unidades de
programas;
- Integrao e teste do sistema: A fim de se garantir o atendimento
a todos os requisitos de software, as unidades de programas so
integradas e testadas como um sistema completo. Os testes devem ser
realizados medida que os componentes individuais do sistema so
integrados. Ao final do processo recomendado um teste de toda a
aplicao.
- Operao e manuteno: O sistema instalado e colocado em
operao. Posteriormente, evoludo quando surgirem falhas no sistema
ou quando surgirem novas necessidades do
cliente, voltando ao fluxo inicial do processo para incio da
manuteno.
O RUP um processo de desenvolvimento iterativo e incremental
que tem como objetivo garantir que a produo de software seja de alta
qualidade e atenda s necessidades de seus usurios finais em um
cronograma e um oramento previsvel (Wagner, 2011, p.30). O modelo
incremental uma adaptao do Modelo Sequencial Linear. Assume
que o software agregar novas funcionalidades, e a cada nova
funcionalidade ou conjunto de novas funcionalidades ser um incremento
e seguir as fases do modelo linear (Pressman, 2011).
O RUP composto por quatro fases (Iniciao, elaborao,
construo e transio), nas quais h uma ou mais iteraes e so
finalizadas com um evento ou criao de um artefato. Conforme mostrado
no Quadro 1 as fases tm diferentes contedos e durao. O foco em cada
iterao produzir artefatos que preencham os objetivos da fase vigente
(Ullah, 2014, p.43).
Quadro 1: Organizao e workflow do mtodo RUP.

Fonte: (ULLAH, 2014, p.43)

A fase de iniciao tem o foco no lanamento do projeto. Nesta fase
um case do projeto tem de ser realizado incluindo o ambiente de negcio,
os fatores de sucesso e a anlise financeira. Tambm so produzidos o
plano de projeto, o risco estimado e a descrio do projeto (requerimentos
de hardware, limitaes, pontos principais, oramento do custo e de
tempo de desenvolvimento) (Ullah, 2014, p.44).
Na fase de elaborao o foco consiste na identificao dos riscos
tcnicos do projeto. O propsito desta fase criar a arquitetura bsica do
sistema, o que responde a maioria dos potenciais problemas tcnicos.
Esta pode ser considerada uma das fases mais crticas pois a fase que
define se o projeto segue at o fim ou deve ser cancelado. Aps esta fase
o projeto se torna uma operao de alto risco onde alteraes so de
difcil implementao e podem danificar o projeto (Ullah, 2014, p.44).
A fase de construo foca na criao do sistema operacional
utilizando a arquitetura definida na fase anterior. O objetivo desenvolver
os componentes e funcionalidades. A maior parte do cdigo feita nesta
fase, assim como a fase de testes (Ullah, 2014, p.44). Em grandes
projetos vrias fases de construo podem ser executadas, o que facilita o
gerenciamento. Ao final desta fase o time de projeto deve fornecer o
manual do usurio e uma verso beta do sistema j em uso. A fase de
transio pode ser adiada caso o produto no esteja estvel o suficiente
para ser avaliado pelos usurios finais.
O ltimo estgio a fase de transio que tem como objetivo levar
o software da fase de desenvolvimento para a de produo. O sistema
deve atender os requerimentos e necessidades dos usurios, por isto,
nesta fase, o sistema avaliado e refinado baseado no retorno por parte
dos usurios. Este procedimento visa apenas polir o sistema pois este j
deve atender ao usurio (Ullah, 2014, p.45). Ao fim desta fase o sistema
lanado e o projeto avaliado.
O Modelo Espiral um modelo evolucionrio de processo de
software que combina a natureza iterativa da prototipagem com os
aspectos controlados e sistemticos do modelo em cascata (Pressman,
2011, p.45). Uma srie de lanamentos e prottipos evoludos so
lanados durante o projeto. O primeiro circuito (no sentido horrio) resulta

na especificao do produto, em seguida vai para o desenvolvimento do

prottipo e ento para verses mais sofisticadas do software. Cada volta
resulta em ajustes ao planejamento do projeto. Custo e prazos so
ajustados de acordo com o retorno. O processo representado como uma
espiral conforme mostrado na Figura 2:
Figura 2 Metodologia evolucionria em espiral

Fonte: Adaptado de (Sommerville 2011)

Na primeira fase devem ser determinados objetivos, solues
alternativas e restries. Na fase dois, devem ser analisados os riscos das
decises do estgio anterior. Durante este estgio podem ser construdos
prottipos ou realizar-se simulaes do software. A fase trs consiste nas
atividades da fase de desenvolvimento, incluindo design, especificao,
codificao e verificao. A quarta fase compreende a reviso das etapas
anteriores e o planejamento da prxima fase. Neste planejamento,
dependendo dos resultados obtidos nos estgios anteriores, como
decises, anlise de riscos e verificao, pode-se optar por seguir o
desenvolvimento num modelo cascata (linear) ou evolutivo. Por exemplo,
se j no primeiro ciclo, os requisitos forem completamente especificados e
validados pode-se optar por seguir o modelo em cascata. Caso contrrio,
pode-se optar pela construo de novos prottipos, incrementando-o,
avaliando novos riscos e replanejando o processo (Pressman, 2011, p.46).
2.2

Metodologia gil de desenvolvimento de software

O desenvolvimento gil de software pode ser considerado, segundo

Sbrocco (2012, p.87) como uma reao adversa aos mtodos pesados de
desenvolvimento de software. A partir da reflexo sobre os mtodos
tradicionais, novos frameworks para processo de desenvolvimentos
comearam a surgir sendo conhecidos inicialmente pela denominao
mtodos leves (Sbrocco, 2012, p.87). Apesar de ser um assunto
relativamente
recente,
existem
diversas
metodologias
de
desenvolvimento gil, contudo este artigo limitou-se ao estudo de trs
delas, sendo estas o Scrum, XP e Kanban.

Segundo Schwaber e Sutherland (2013), o Scrum um framework

que trata e resolve problemas complexos e adaptativos, de forma
produtiva e criativa, entregando produtos com o mais alto valor possvel.
A metodologia gil XP envolve um conjunto de regras e prticas
constantes
no
contexto
de
quatro
atividades
metodolgicas:
planejamento, projeto, codificao e testes. Dentre as principais
diferenas da XP em relao s outras metodologias esto feedback
constante, abordagem incremental, encorajamento de comunicao face
a face (Pressman, 2011). O Kanban, com seu mecanismo de sinalizao,
tem o objetivo de apresentar atividades de trabalho em processo, ou seja,
o nmero de atividades ou cartes em circulao equivalente
capacidade do sistema (Mariotti, 2015, p. 2).
No trabalho de Xiaofeng Wang (2011, p.1-9) foi demonstrada a
relao entre mtodos geis como XP e Scrum e metodologias de
gerenciamento de projeto como Lean quando aplicadas em conjunto na
engenharia de software. Este trabalho possibilita o entendimento da
aplicao dos mtodos geis nas rotinas de desenvolvimento de software
e de projetos. No trabalho de Pankaj Kamthan (2013, p622-623) foram
estudadas as mudanas feitas na engenharia de software na indstria,
incluindo as mudanas voltadas para a metodologia gil. Em 2001 houve
a criao do Manifesto gil, neste documento os valores centrais e outros
doze princpios fundamentais da filosofia so definidos. Apesar de o
Manifesto gil ter sido escrito para o desenvolvimento de softwares, todos
seus princpios tambm podem ser utilizados em gerenciamento de
projetos. Os valores centrais da metodologia gil so: contribuies
individuais e interaes sobre processos e ferramentas, software de
trabalho sobre documentao abrangente, colaborao de clientes sobre
negociao e contrato e resposta a mudanas em relao ao plano
definido (Denning, 2015, p.12).
3. Desenvolvimento
3.1. Gerenciamento de projetos tradicional versus gerenciamento
de projetos geis
A tendncia atual ao uso de tcnicas geis muito importante. To
importante que at mesmo o Project Management Institute criou um novo
exame embasado na tcnica gil para a o programa de certificao, o
PMI-Agile Certified Practitioner (PMI-ACP). Segundo o PMI esse o
certificado de desenvolvimento e crescimento mais rpido, que abrange
diversas abordagens focando em gil, tais como Scrum, Kanban, Lean,
eXtreme Programing (XP) e Test-Driven Development (TDD) (Schuh, et.
al., 2014, p.51-56)
Adaptabilidade o principal segredo da abordagem gil, ainda
mesmo mais importante que a previsibilidade, a qual a base da
abordagem tradicional. Mudanas so inevitveis, portanto novas
abordagens devem possibilitar mudanas e o reconhecimento de que
praticamente impossvel criar um projeto completo desde o princpio
(Awad, 2015, p.18). A abordagem gil apoia-se mais em comunicao e
colaborao entre os membros da equipe de projetos, no meramente nos
passos do processo em si. Portanto, os membros da equipe so mais
envolvidos nas tomadas de decises.

A abordagem tradicional mais adequada para projetos nos quais

as metas e as exigncias iniciais so bem claras, portanto razovel
afirmar que essa categoria de projetos exige uma incerteza muito baixa,
alm de, haver pouca expectativa de mudanas de exigncias no software
(Hossain, 2015, p.7). Entretanto, os projetos gerenciados atravs da
abordagem gil so caracterizados por altos nveis de incerteza,
incompletos e nem sempre tem claros requisitos do projeto, alm de,
metas nem sempre claramente definidas. Ainda que para alguns desses
projetos pode-se assumir que haver mudanas significativas durante
todo o projeto, com a metodologia gil o desenvolvimento comea antes
dos requisitos serem bem definidos e as mudanas no trazem um
impacto negativo (Hossain, 2015, p.8).
Uma das consequncias da abordagem gil a falta de
documentao, portanto, o conhecimento do desenvolvimento do projeto
de grande importncia, atribuindo tambm a fatores humanos o sucesso
do projeto. Segundo Hossain (2015, p.6) esses fatores incluem a
competncia dos membros do time, motivao, conhecimento dos
gerentes no processo gil, gerentes que sejam adaptveis, boa relao
com o cliente.
3.2. Comparativo XP e RUP
A anlise exaustiva das principais caractersticas das metodologias
XP e RUP permite a identificao de elementos em comum que permitem
uma comparao sistemtica (Smith, 2012, p.4). Estes processos podem
ser resumidos em um fluxo envolvendo atividades realizadas por parceiros
(indivduos externos ou a prpria equipe) com nica finalidade de gerar
artefatos para serem entregues ao cliente, sendo avaliados por este, para
que o desenvolvimento siga, termine ou recomece segundo as mudanas
requeridas pelo cliente. A anlise realizada neste artigo identificou os
processos em comum entre as metodologias tais como tempo e esforo,
artefatos, atividades, disciplinas e papis. Para o melhor entendimento
descreveu-se a comparao entre a metodologia XP e RUP quanto aos
critrios descritos acima.
3.2.1.

Alocao de tempo e esforo

No desenvolvimento de software o tempo pode ser um dos pontos

que pode gerar mais atrito entre equipe e cliente. Projetos que durem
mais tempo que o especificado no contrato ou pelo modelo certamente
necessitaro de uma equipe de desenvolvimento maior, quantidade maior
de recursos ou investimentos e maior prazo pois a prpria estratgia de
desenvolvimento pode mudar como no caso do desenvolvimento serial
para o paralelo. No mtodo RUP a diviso feita em fases, essas fases
so divididas em iteraes e essas iteraes podem conter vrios ciclos.
Uma iterao do RUP leva entre duas semanas e seis meses e
considerando que em um projeto o nmero de iteraes recomendadas
entre trs e nove, pode-se concluir que a faixa de tempo que um projeto
orientado pelo processo dessa metodologia leva de seis semanas a
cinquenta e quatro meses (Smith, 2012, p.15).

Na metodologia XP as iteraes levam cerca de duas semanas para

serem concludas e os releases, determinados nas reunies com os
clientes, so liberados de dois em dois meses. Estes releases equivalem
s iteraes do mtodo RUP (Smith, 2012, p.15). Para estimar o custo,
esforo e tempo empregados no projeto, utilizou-se o COCOMOII (Boehm,
2016). Considera-se que um time com dez programadores seja ideal para
um projeto com durao de doze meses, pois com mais integrantes as
prticas seriam difceis de ser implantadas.
3.2.2. Atividades
No mtodo RUP as atividades so tarefas desempenhadas por um
ente com uma funo. As tarefas so executadas usando e modificando
documentos e produzindo novos artefatos e est relacionada com uma
disciplina. As atividades tm como objetivo trabalhar cada artefato,
fazendo com que se tornem menos abstratos e mais focados nas metas
do projeto, ajudando a determinar variveis como custo, tempo e esforo.
Esses artefatos servem como guias no decorrer do projeto. J na XP, por
ter uma viso simplificada como abordagem do projeto, tem apenas
quatro atividades bsicas que so: codificar, testar, ouvir e projetar
(ULLAH, 2014, p.27).
3.2.3. Funes
A maior diferena, em relao s funes, a quantidade
apresentada em cada metodologia. O RUP tem listadas cerca de trinta
funes enquanto que a XP tem apenas sete funes sem atribuies
especificas dentro de suas atividades. O motivo para esta diferena se
deve ao fato que o RUP caracteriza melhor cada uma das funes
desempenhadas e na XP so definidas de forma mais abrangente. As
funes, em ambas as metodologias, podem ser desempenhadas por uma
equipe ou mesmo por um nico indivduo e o mesmo indivduo, ou grupo,
pode executar mais de uma funo pr-estabelecida.
3.2.4. Disciplinas
Em relao s disciplinas, o RUP possui nove ao todo e as divide em
seis de engenharia de software e trs de suporte no entrando no mrito
de contratao de colaboradores ou contato com o cliente. Na XP algumas
disciplinas so equivalentes para a RUP, como o Jogo do Planejamento na
XP com a disciplina Gerncia de Projeto no RUP (Smith, 2012, p.16), no
sendo, contudo, todas as disciplinas do RUP mapeveis nas prticas da XP.
Por exemplo, modelagem de negcios e especificao de requisitos que
no fazem parte do workflow da XP.
3.2.5 Artefatos
Artefatos so entidades ou documentos criados durante o processo
de desenvolvimento e servem como meio de comunicao. No RUP a
comunicao se d atravs dos artefatos, j na XP a comunicao feita
de forma direta com o cliente, atravs do dilogo, presencial ou no. Uma

10

caracterstica muito discutida sobre a metodologia RUP a documentao

excessiva. Atualmente o RUP descreve mais de cem tipos de documentos,
o que o torna invivel sob a tica de projetos pequenos. Na RUP esta
quantidade de documentos visa deixar o processo mais objetivo com
metas bem definidas. Na XP no h a necessidade de tal quantidade de
documentos, visto que os projetos, em geral, demandam menor
complexidade. O manifesto das metodologias geis diz que os
documentos devem ser gerados somente se muito necessrios, sendo a
XP uma metodologia gil, essa caracterstica vale para a mesma (Smith,
2012, p.9).
3.3. Anlise genrica entre metodologias tradicionais e geis
Para que os mtodos tambm fossem comparados de maneira geral
e no somente em um caso particular, escolheu-se alguns critrios
obtidos da literatura (Pressman, 2011 e Sommerville, 2011) para que
todas as metodologias geis e tradicionais fossem avaliadas de forma
equivalente. Estes critrios foram aplicados nas duas metodologias e seus
resultados comparados. No Quadro 2 so apresentadas as caractersticas
dos mtodos de desenvolvimento tradicional de software (DTS) e o
desenvolvimento gil de software (DAS).
Quadro 2: Anlise comparativa entre modelos de desenvolvimento de
software.
Tradicional
Definido no incio e com poucas
mudanas
Clientes no envolvidos
Documentao Formal e obrigatria
Projetos grandes
Desencoraja a entrega frequente de
software para o cliente
Linear

gil
Criativo e sem requerimentos
claros
Envolvido e com colaborao
frequente
Documentao formada pelo
Conhecimento dos membros e
passada pessoalmente ou por
anotaes
Projetos pequenos
Entrega software continuamente
ao cliente
Complexo e iterativo

Fonte: (Autoria Prpria)

3.3.1. Envolvimento com o cliente
Enquanto no DTS h a necessidade de um extenso detalhamento
dos requerimentos por parte do cliente, no DAS h maior flexibilidade
devido ao sistema iterativo de trabalho. No DAS o cliente est em
interao constante, fazendo sugestes de melhorias e revisando cada
fase. Este processo faz com que mudanas de paradigma sejam fceis de
serem implementadas, ao contrrio do DTS, aonde uma grande parte do
software precisaria ser desmembrada para que pequenas melhorias
fossem executadas. A facilidade de mudanas no projeto trazidas pelo
DAS aumenta a satisfao do consumidor porm pode aumentar o tempo
estimado devido as constantes alteraes.
3.3.2. Flexibilidade

11

No DTS o papel do programador e do analista ou gerente do projeto

separado. A arquitetura parte dos requerimentos coletados na fase
inicial e ento encaminhado para o analista ou gerente e s ento seguem
para o programador. No DAS, devido interao constante com o cliente e
o fato do programador de fato ser a entidade que manipula o software, a
flexibilidade na arquitetura e a funcionalidade so maiores.
3.3.3. Documentao e comunicao
Uma das poucas reas em que o DAS tem extrema desvantagem
em relao ao DTS na documentao. O DTS tem slida base na
documentao e reviso de cada passo do desenvolvimento. O processo
de documentao, apesar de extenso e muitas vezes considerado pesado,
se torna mais simples devido a caracterstica unidirecional do algoritmo.
No DAS, alm da falta de artefatos, a interface primria de documentao
e reviso do cdigo, muitas vezes, se tornam as anotaes e comentrios
adicionados pelos desenvolvedores e esta prtica pode se tornar
problemtica ao longo do projeto na questo de comunicao interna e
com o cliente. Apesar de ser apontada como uma grande desvantagem,
por ser considerada excessiva no caso do DTS, a documentao no pode
ser totalmente descartada e isto indica que o processo de comunicao
no DAS deve ser pensado com seriedade.
3.3.4. Capacidade do sistema
Sistemas pequenos, ou mesmo mdios, so os tipos de sistemas
com melhores resultados no DAS pois oferecem maior compatibilidade
com a elasticidade que mtodo traz. Sistemas grandes oferecem uma
inrcia maior para mudanas iterativas em alguns aspectos,
especialmente com partes perifricas do design. Neste sentido pode-se
tratar o projeto pela tica do DTA ou dividir o sistema em pequenos
processos de DAS e trabalhar na compatibilizao destes.
4. Concluso
De modo geral, a Metodologia gil utilizada em projetos que
possuem requisitos mutveis ou onde estes mesmos no so claros para a
equipe e para o cliente, porm ela possui limitaes que dificultam sua
prtica tais como a dificuldade em definir as funes de cada membro ou
gerenciar a quantidade de recursos para o projeto. Outro ponto
importante a ser considerado a cultura do cliente e tambm da equipe.
H clientes que precisam da documentao para manter sua sensao de
controle sobre o projeto, como tambm podem no estar sempre
disponveis para dialogar. Isto causa atrasos significativos em um projeto
gil. Para os programadores, mesmo os mais capacitados, podem sentir
dificuldades em trabalhar nas definies da metodologia gil, caso no
estejam acostumados constante comunicao no decorrer do projeto.
A Metodologia Tradicional possui uma estrutura que possibilita ser
trabalhada em grandes projetos, devido sua diviso bem definida de
atividades, funes e tarefas junto a uma coleo de artefatos utilizados
como produtos de entrada e sada de processos, mas todo esse esforo
(custo) pode no ser justificvel com uma equipe pequena.
O DAS no apenas definido por um pequeno conjunto de prticas
e tcnicas. Atravs dos trabalhos e referncias consultados pde-se

12

concluir que o DAS trata de uma capacidade estratgica de criar e

responder a mudanas, representando um balano entre flexibilidade e
estrutura, capacidade de liberar a criatividade e inovao do time de
desenvolvedores e a capacidade de guiar as organizaes atravs de
momentos de turbulncia. Metodologias tradicionais ainda tero espao
nestes momentos de turbulncia pois diversas reas ainda tm a
necessidade de grande documentao.
Os mtodos tradicionais baseiam-se em documentaes e
necessidades estabelecidas no incio do projeto, o que muitas vezes
dificulta ou inviabiliza modificaes posteriores, porm setores como de
armamento e defesa necessitam de parmetros rgidos e documentao
acurada, optando assim por este mtodo, porm o mtodo de
comunicao no DAS deve ter alguma rastreabilidade para que a
comunicao no seja perdida ao longo do processo.
Com suas devidas mudanas, a metodologia tradicional pode
contemplar parte dos processos da metodologia gil tornando-os bem
prximos ou equivalentes em relao ao tempo e esforo, mas a essncia
da metodologia gil est nos quatro valores do manifesto gil focando na
organizao, nas pessoas e na cultura. E isso, certamente, um ponto
importante trazido pelo desenvolvimento gil na engenharia de software.
Referncias Bibliogrficas
AWAD, M. A.; A Comparison between Agile and Traditional Software
Development Methodologies, School of Computer Science and
software Engineering, The University of Western Australia, 2015.
BASSI FILHO, D. L.; Experincias com desenvolvimento gil, Instituto
de Matemtica e Estatstica da Universidade de So Paulo, 2011.
Disponvel em: http://goo.gl/9dmV2X. Acesso em 07/04/2016.
BOEHM, B.; Constructive Cost Model II (COCOMOII). California, 2016.
Disponvel
em:
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html.
Acessado em: 12/03/2016.
DENNING, S.; Updating the Agile Manifesto, Strategy & Leadership
Magazine, United Kingdom, Vol. 43, p.12, 2015.
HOSSAIN, A.; Evaluation of agile methods and implementation.
Masters Programme in Information Technology, Centria University of
Applied Sciences, Kokkola-Pietarsaari, 2015. Disponvel em:
https://goo.gl/wUTk0 . Acessado em: 21/04/2016.
KAMTHAN, P.; On the Role of Wiki for Managing Knowledge in Agile
Software Development, Department of Computer Science and
Software Engineering Research, Concordia University Montreal,
Canada, p. 622-623, 2013.

13

LANDER, E.; Report to the president on capturing domestic

competitive advantage in advanced manufacturing, Executive
Office of the President Presidents Council of Advisors on Science
and
Technology,
Washington,
2012.
Disponvel
em:
https://goo.gl/V8Blu7. Acessado em: 21/04/2016.
MARIOTTI, F. S.; Kanban: o gil adaptativo, 2015. Disponvel em
http://goo.gl/dUCO6K Acessado em: 22/04/2016.
MILOS, J.; BOJAN, L.; ANTONIA, M.; ANTONI-LUS, M.; The agile approach
in industrial and software engineering project management,
p. 2, Spain, 2015. Disponvel em: http://goo.gl/KETBUK Acesso em:
17/04/2016.
PRESSMAN, R. Engenharia de Software Uma Abordagem
Profissional. Traduo Ariovaldo Griesi, Mario Moro Fecchio. 7 ed. So Paulo, SP: MGH Editora Ltda, 2011.
SBROCCO, J. H. T. C.; MACEDO, P. C.; Metodologias geis: Engenharia
de Software Sob Medida. Editora rica Ltda. 1 ed., So Paulo,
p.87, 2012.
SCHUH, G.; POTENTE, T.; WESCH-POTENTE, C.; WEBER, A. R.; PROTE, J. P.;
Collaboration Mechanisms to Increase Productivity in the
Context of Industrie 4.0, Procedia CIRP, vol. 19, no. RoMaC, p. 51
56, 2014.
SCHWABER, K.; SUTHERLAND, J.; Guia do Scrum. 2013. Disponvel em:
http://goo.gl/ah2AaM Acesso em: 04/03/2016.
SMITH, J. A.; Comparison of the IBM Rational Unified Process and
eXtreme Programming, New York, 2012. Disponvel em:
http://goo.gl/MFDLn. Acessado em: 21/04/16.
SOMMERVILLE, I.; Engenharia de Software. 9 ed. So Paulo: Person
Prentice Hall, 2011.
ULLAH, M.; Comparison and problems between traditional and
agile software development methods; Lappeenranta University
of Technology. Finland, 2014. Disponvel em: https://goo.gl/0htYqk.
Acessado em: 21/04/16.
WAGNER, R.; Processos de Desenvolvimento de Software Confiveis
Baseados em Padres de Segurana Universidade Federal de
Santa Maria. Santa Maria, RS, p.30, 2011. Disponvel em:
http://goo.gl/bnb1qu . Acesso em: 17/04/2016.
WANG, X.; The Combination of Agile and Lean in Software
Development: An ExperienceReport Analysis, IEEE Computer
Society, Agile Conference, Lero the Irish Software Engineering
Research CentreLimerick, Ireland, p. 1-9, 2011.