TCC Metodos Ageis V6

7/25/2019 TCC Metodos Ageis V6

1/13

Os desafos dos Mtodos Tradicionais e geis na Engenharia deSotware

(V 6)

Raael Gulfer Reis

[email protected]

os do !ar"o Rodrigues# MSc# $h%[email protected]

Curso de Ps-Graduao Lato Sensu em Engenharia e Arquitetura deoft!are da "#EA $ "ni%ersidade Est&cio de &.

Resu"o' (resente trabalho tra) as abordagens *radicional e +gil, no mbito

da engenharia de soft!are, e discute as similaridades e diferenas entre

as duas metodologias. udanas na sociedade e ino%a/es tecnolgicastra)em mudanas signi0cati%as no mercado, le%ando a demandas (orso0sticao, (or (arte dos usu&rios e frequentes modi0ca/es no designdos (rodutos (or (arte dos clientes. Para o desen%ol%imento de umsoft!are 1 necess&rio seguir (rocessos que assegurem a qualidade dodesen%ol%imento e a (adroni)ao do (roduto com(utacional. 's odelosde Processos de oft!are, tem como objeti%o, fa)er com que odesen%ol%imento do mesmo, siga m1todos es(ec20cos (ara cada &rea dea(licao desen%ol%ida. A etodologia +gil 1 em(regada em diferentesdisci(linas em res(osta as atuais mudanas no mercado. Este artigo tem

como objeti%o com(arar caracter2sticas, a(lica/es e formas de trabalhodas duas metodologias de desen%ol%imento de soft!are. A metodologiaem(regada foi uma e3tensa re%iso de artigos, li%ros e sites da internet(ara obteno de base argumentati%a e de refer4ncia. 5oi reali)ado umcom(arati%o entre as t1cnicas 6P e 7"P bem como de maneira geral entrea etodologia *radicional e a +gil. Atra%1s destes com(arati%os, foi(oss2%el justi0car as (rinci(ais diferenas entre estas duas metodologiasde desen%ol%imento, estabelecendo uma relao de com(arao entreelas e a(ontando as (rinci(ais %antagens da metodologia &gil sobre atradicional.

$ala&ras'cha&e etodologia +gil, *ecnologia da 8nformao, Projeto,9esen%ol%imento +gil de oft!are.

* +ntrodu,-o

's m1todos de desen%ol%imento &gil de soft!are :9A; socaracteri)ados (or se ada(tarem a constantes mudanas de requisitos(elos clientes bem como reali)ar (rojetos em um es(ao de tem(o muitomenor. ' ambiente dinmico de negcios e a customi)ao em massale%aram a mudanas na (roduo de com(anhias e na im(lementao damanufatura &gil, o que se e%idenciou nas


2/13

=

de (roduo le%ando a a(licao do &gil na manufatura :ilos, =>?;. A(rinci(al moti%ao (or tr&s da agilidade 1 a mudana.

9e acordo com ilos :=>?; #agel e 9o%e introdu)iram o conceitode manufatura &gil em seus trabalhos sobre a ind?=, (. =;.

9e forma semelhante ao Agile Manufacturing, em algumasem(resas de *8 foi tamb1m introdu)ido a mesma 0loso0a sendo chamadaAgile Software Developmentou 9esen%ol%imento de oft!are +gil :9A;segundo assi 5ilho :=>??, (. =?;. ' estudo das ideias e (rinc2(ios dessametodologia so fundamentalmente as mesmas tanto na ind??, (.==;.

.* /unda"enta,-o Te0rica

.** Metodologia tradicional de desen&ol&i"ento de sotware


3/13

7equerimento

Projeto

8m(lementao

Feri0cao

.anuteno

"ma maneira de melhorar o desen%ol%imento de um (rojeto 1 ainsero de um conjunto de (rocessos re(etiti%os adequados queintrodu)em consist4ncia, e3ibilidades e e0ci4ncia de forma a melhorar aqualidade do desen%ol%imento em de(artamentos e em(resas como umtodo. Consiste em (rocessos descriti%os, (adr/es e atribuio deres(onsabilidades, ciclos de %ida e estruturas organi)ando inter%alos notrabalho, tudo somando a um su(orte de informao :assi 5ilho, =>??,(.;. As metodologias tradicionais de desen%ol%imento de soft!are,tamb1m conhecidas como H(esadasI, t4m como caracter2stica marcantesua di%iso em eta(as ou fases. Para Pressman :=>??; essas fases sode0nidas e englobam ati%idades como An&lise, odelagem,9esen%ol%imento e *estes. #a concluso de cada fase gera-se um marco,que (ode ser um documento, como 9iagramas de "B, um (rotti(o ou%erso do soft!are. etodologias tradicionais geralmente sodesen%ol%idas no Hmodelo em cascataI, e a cada alterao do (rojeto,ser& necess&rio J %olta ao in2cio do (rojeto (ara alterao da

documentao ou de outro marco :Pressman, =>??; conforme mostra a5igura ?.

5igura ? $ odelo de metodologia em cascata.

5onteD :Autoria Pr(ria;

E3istem di%ersas metodologias tradicionais de desen%ol%imento,(or1m a re%iso bibliogr&0ca feita neste artigo se limitou ao estudo detr4s delas, sendo a equencial Binear, Rational Unied Process:7"P; e aEs(iral. ' (rocesso equencial Binear 1 um modelo (ro(osto em ?K>,onde as fases so sistematicamente seguidas de maneira linear. L omodelo mais utili)ado no mercado :ommer%ille, =>??, (.?M;, (or1m no1 considerado o mais e0ca), (ois raros (rojetos seguem u3o linear, al1mde mudanas de requisitos que ocorrem no (rojeto no serem de f&cilada(tao, (orque alteram toda a documentao desen%ol%ida.


4/13

N

As eta(as do (rocesso linear so descritas de forma geral a seguir:ommer%ille, =>??, (.?M-?;D

- 9e0nio dos requisitosD 9e%e-se identi0car juntamente aosusu&rios do soft!are, os ser%ios, metas e restri/es im(ostas ao sistemaO

- Projeto do sistema e do soft!areD 's requisitos identi0cados soma(eados em com(onentes de hard!are e soft!are, de modo que osistema (ossa ser (osteriormente im(lementado. 'corre, ainda, afundamentao da arquitetura geral do sistemaO

- 8m(lementao e testes unit&riosD Por meio da linguagem de(rogramao, im(lementa-se o (rojeto de soft!are em unidades de(rogramasO

- 8ntegrao e teste do sistemaD A 0m de se garantir o atendimentoa todos os requisitos de soft!are, as unidades de (rogramas sointegradas e testadas como um sistema com(leto. 's testes de%em serreali)ados J medida que os com(onentes indi%iduais do sistema sointegrados. Ao 0nal do (rocesso 1 recomendado um teste de toda a

a(licao.- '(erao e manutenoD ' sistema 1 instalado e colocado emo(erao. Posteriormente, 1 e%olu2do quando surgirem falhas no sistemaou quando surgirem no%as necessidades do

cliente, %oltando ao u3o inicial do (rocesso (ara in2cio damanuteno.

' 7"P 1 um (rocesso de desen%ol%imento iterati%o e incrementalque tem como objeti%o garantir que a (roduo de soft!are seja de altaqualidade e atenda Js necessidades de seus usu&rios 0nais em umcronograma e um oramento (re%is2%el :agner, =>??, (.>;. ' modeloincremental 1 uma ada(tao do Hodelo equencial BinearI. Assume

que o software agregar& no%as funcionalidades, e a cada no%afuncionalidade ou conjunto de no%as funcionalidades ser& um incrementoe seguir& as fases do modelo linear :Pressman, =>??;.

' 7"P 1 com(osto (or quatro fases :8niciao, elaborao,construo e transio;, nas quais h& uma ou mais itera/es e so0nali)adas com um e%ento ou criao de um artefato. Conforme mostradono Quadro ? as fases t4m diferentes conte


5/13

5onteD :"BBAS, =>?N, (.N;A fase de iniciao tem o foco no lanamento do (rojeto. #esta faseum case do (rojeto tem de ser reali)ado incluindo o ambiente de negcio,os fatores de sucesso e a an&lise 0nanceira. *amb1m so (rodu)idos o(lano de (rojeto, o risco estimado e a descrio do (rojeto :requerimentosde hard!are, limita/es, (ontos (rinci(ais, oramento do custo e detem(o de desen%ol%imento; :"llah, =>?N, (.NN;.

#a fase de elaborao o foco consiste na identi0cao dos riscost1cnicos do (rojeto. ' (ro(sito desta fase 1 criar a arquitetura b&sica dosistema, o que res(onde a maioria dos (otenciais (roblemas t1cnicos.Esta (ode ser considerada uma das fases mais cr2ticas (ois 1 a fase que

de0ne se o (rojeto segue at1 o 0m ou de%e ser cancelado. A(s esta faseo (rojeto se torna uma o(erao de alto risco onde altera/es so dedif2cil im(lementao e (odem dani0car o (rojeto :"llah, =>?N, (.NN;.

A fase de construo foca na criao do sistema o(eracionalutili)ando a arquitetura de0nida na fase anterior. ' objeti%o 1 desen%ol%eros com(onentes e funcionalidades. A maior (arte do cdigo 1 feita nestafase, assim como a fase de testes :"llah, =>?N, (.NN;. Em grandes(rojetos %&rias fases de construo (odem ser e3ecutadas, o que facilita ogerenciamento. Ao 0nal desta fase o time de (rojeto de%e fornecer omanual do usu&rio e uma %erso beta do sistema j& em uso. A fase de

transio (ode ser adiada caso o (roduto no esteja est&%el o su0ciente(ara ser a%aliado (elos usu&rios 0nais.' ??, (.N;. "ma s1rie de lanamentos e (rotti(os e%olu2dos solanados durante o (rojeto. ' (rimeiro circuito :no sentido hor&rio; resulta


6/13

T

na es(eci0cao do (roduto, em seguida %ai (ara o desen%ol%imento do(rotti(o e ento (ara %ers/es mais so0sticadas do soft!are. Cada %oltaresulta em ajustes ao (lanejamento do (rojeto. Custo e (ra)os soajustados de acordo com o retorno. ' (rocesso 1 re(resentado como umaes(iral conforme mostrado na 5igura =D

5igura = $ etodologia e%olucion&ria em es(iral

5onteD Ada(tado de :ommer%ille =>??;

#a (rimeira fase de%em ser determinados objeti%os, solu/esalternati%as e restri/es. #a fase dois, de%em ser analisados os riscos dasdecis/es do est&gio anterior. 9urante este est&gio (odem ser constru2dos(rotti(os ou reali)ar-se simula/es do soft!are. A fase tr4s consiste nasati%idades da fase de desen%ol%imento, incluindo design, es(eci0cao,codi0cao e %eri0cao. A quarta fase com(reende a re%iso das eta(asanteriores e o (lanejamento da (r3ima fase. #este (lanejamento,de(endendo dos resultados obtidos nos est&gios anteriores, comodecis/es, an&lise de riscos e %eri0cao, (ode-se o(tar (or seguir odesen%ol%imento num modelo cascata :linear; ou e%oluti%o. Por e3em(lo,se j& no (rimeiro ciclo, os requisitos forem com(letamente es(eci0cados e%alidados (ode-se o(tar (or seguir o modelo em cascata. Caso contr&rio,(ode-se o(tar (ela construo de no%os (rotti(os, incrementando-o,a%aliando no%os riscos e re(lanejando o (rocesso :Pressman, =>??, (.NT;.

.*. Metodologia gil de desen&ol&i"ento de sotware

' desen%ol%imento &gil de soft!are (ode ser considerado, segundobrocco :=>?=, (.MK; como uma reao ad%ersa aos m1todos (esados dedesen%ol%imento de soft!are. A (artir da ree3o sobre os m1todostradicionais, no%os frame!orRs (ara (rocesso de desen%ol%imentoscomearam a surgir sendo conhecidos inicialmente (ela denominaoHm1todos le%esI :brocco, =>?=, (.MK;. A(esar de ser um assuntorelati%amente recente, e3istem di%ersas metodologias dedesen%ol%imento &gil, contudo este artigo limitou-se ao estudo de tr4s

delas, sendo estas o crum, 6P e Uanban.


7/13

K

egundo ch!aber e utherland :=>?;, o crum 1 um frame!orRque trata e resol%e (roblemas com(le3os e ada(tati%os, de forma(roduti%a e criati%a, entregando (rodutos com o mais alto %alor (oss2%el.

A metodologia &gil 6P en%ol%e um conjunto de regras e (r&ticasconstantes no conte3to de quatro ati%idades metodolgicasD(lanejamento, (rojeto, codi0cao e testes. 9entre as (rinci(aisdiferenas da 6P em relao Js outras metodologias esto feedbackconstante, abordagem incremental, encorajamento de comunicao facea face :Pressman, =>??;. ' Uanban, com seu mecanismo de sinali)ao,tem o objeti%o de a(resentar ati%idades de trabalho em (rocesso, ou seja,o n?, (. =;.

#o trabalho de 6iaofeng ang :=>??, (.?-; foi demonstrada arelao entre m1todos &geis como 6P e crum e metodologias degerenciamento de (rojeto como Bean quando a(licadas em conjunto naengenharia de soft!are. Este trabalho (ossibilita o entendimento da

a(licao dos m1todos &geis nas rotinas de desen%ol%imento de soft!aree de (rojetos. #o trabalho de PanRaj Uamthan :=>?, (T==-T=; foramestudadas as mudanas feitas na engenharia de soft!are na ind>? hou%ea criao do anifesto +gil, neste documento os %alores centrais e outrosdo)e (rinc2(ios fundamentais da 0loso0a so de0nidos. A(esar de oanifesto +gil ter sido escrito (ara o desen%ol%imento de soft!ares, todosseus (rinc2(ios tamb1m (odem ser utili)ados em gerenciamento de(rojetos. 's %alores centrais da metodologia &gil soD contribui/esindi%iduais e intera/es sobre (rocessos e ferramentas, soft!are detrabalho sobre documentao abrangente, colaborao de clientes sobre

negociao e contrato e res(osta a mudanas em relao ao (lanode0nido :9enning, =>?, (.?=;.

1* %esen&ol&i"ento

1** Gerencia"ento de 2ro3etos tradicional &ersus gerencia"entode 2ro3etos 4geis

A tend4ncia atual ao uso de t1cnicas &geis 1 muito im(ortante. *oim(ortante que at1 mesmo o Proect Management !nstitutecriou um no%oe3ame embasado na t1cnica &gil (ara a o (rograma de certi0cao, o

PM!"Agile #ertied Practitioner :P8-ACP;. egundo o P8 esse 1 ocerti0cado de desen%ol%imento e crescimento mais r&(ido, que abrangedi%ersas abordagens focando em &gil, tais como Scrum$ %anban$ Lean$e&treme Programing '&P( e )est"Driven Development ')DD( :chuh, et.al., =>?N, (.?-T;

Ada(tabilidade 1 o (rinci(al segredo da abordagem &gil, aindamesmo mais im(ortante que a (re%isibilidade, a qual 1 a base daabordagem tradicional. udanas so ine%it&%eis, (ortanto no%asabordagens de%em (ossibilitar mudanas e o reconhecimento de que 1(raticamente im(oss2%el criar um (rojeto com(leto desde o (rinc2(io:A!ad, =>?, (.?M;. A abordagem &gil a(oia-se mais em comunicao e

colaborao entre os membros da equi(e de (rojetos, no meramente nos(assos do (rocesso em si. Portanto, os membros da equi(e so maisen%ol%idos nas tomadas de decis/es.


8/13

M

A abordagem tradicional 1 mais adequada (ara (rojetos nos quaisas metas e as e3ig4ncias iniciais so bem claras, (ortanto 1 ra)o&%ela0rmar que essa categoria de (rojetos e3ige uma incerte)a muito bai3a,al1m de, ha%er (ouca e3(ectati%a de mudanas de e3ig4ncias no soft!are:Sossain, =>?, (.K;. Entretanto, os (rojetos gerenciados atra%1s daabordagem &gil so caracteri)ados (or altos n2%eis de incerte)a,incom(letos e nem sem(re tem claros requisitos do (rojeto, al1m de,metas nem sem(re claramente de0nidas. Ainda que (ara alguns desses(rojetos (ode-se assumir que ha%er& mudanas signi0cati%as durantetodo o (rojeto, com a metodologia &gil o desen%ol%imento comea antesdos requisitos serem bem de0nidos e as mudanas no tra)em umim(acto negati%o :Sossain, =>?, (.M;.

"ma das consequ4ncias da abordagem &gil 1 a falta dedocumentao, (ortanto, o conhecimento do desen%ol%imento do (rojeto1 de grande im(ortncia, atribuindo tamb1m a fatores humanos o sucessodo (rojeto. egundo Sossain :=>?, (.T; esses fatores incluem a

com(et4ncia dos membros do time, moti%ao, conhecimento dosgerentes no (rocesso &gil, gerentes que sejam ada(t&%eis, boa relaocom o cliente.

1*.* !o"2arati&o 5$ e R$

A an&lise e3austi%a das (rinci(ais caracter2sticas das metodologias6P e 7"P (ermite a identi0cao de elementos em comum que (ermitemuma com(arao sistem&tica :mith, =>?=, (.N;. Estes (rocessos (odemser resumidos em um u3o en%ol%endo ati%idades reali)adas (or (arceiros

:indi%2duos e3ternos ou a (r(ria equi(e; com


9/13

#a metodologia 6P as itera/es le%am cerca de duas semanas (araserem conclu2das e os releases, determinados nas reuni/es com osclientes, so liberados de dois em dois meses. Estes releases equi%alemJs itera/es do m1todo 7"P :mith, =>?=, (.?;. Para estimar o custo,esforo e tem(o em(regados no (rojeto, utili)ou-se o C'C''88 :oehm,=>?T;. Considera-se que um time com de) (rogramadores seja ideal (araum (rojeto com durao de do)e meses, (ois com mais integrantes as(r&ticas seriam dif2ceis de ser im(lantadas.

1*.*.* 7ti&idades

#o m1todo 7"P as ati%idades so tarefas desem(enhadas (or umente com uma funo. As tarefas so e3ecutadas usando e modi0candodocumentos e (rodu)indo no%os artefatos e est& relacionada com umadisci(lina. As ati%idades t4m como objeti%o trabalhar cada artefato,fa)endo com que se tornem menos abstratos e mais focados nas metas

do (rojeto, ajudando a determinar %ari&%eis como custo, tem(o e esforo.Esses artefatos ser%em como guias no decorrer do (rojeto. V& na 6P, (orter uma %iso sim(li0cada como abordagem do (rojeto, tem a(enasquatro ati%idades b&sicas que soD codi0car, testar, ou%ir e (rojetar:"BBAS, =>?N, (.=K;.

1*.*1* /un,8es

A maior diferena, em relao Js fun/es, 1 a quantidadea(resentada em cada metodologia. ' 7"P tem listadas cerca de trintafun/es enquanto que a 6P tem a(enas sete fun/es sem atribui/es

es(eci0cas dentro de suas ati%idades. ' moti%o (ara esta diferena sede%e ao fato que o 7"P caracteri)a melhor cada uma das fun/esdesem(enhadas e na 6P so de0nidas de forma mais abrangente. Asfun/es, em ambas as metodologias, (odem ser desem(enhadas (or umaequi(e ou mesmo (or um


10/13

?>

caracter2stica muito discutida sobre a metodologia 7"P 1 a documentaoe3cessi%a. Atualmente o 7"P descre%e mais de cem ti(os de documentos,o que o torna in%i&%el sob a tica de (rojetos (equenos. #a 7"P estaquantidade de documentos %isa dei3ar o (rocesso mais objeti%o commetas bem de0nidas. #a 6P no h& a necessidade de tal quantidade dedocumentos, %isto que os (rojetos, em geral, demandam menorcom(le3idade. ' manifesto das metodologias &geis di) que osdocumentos de%em ser gerados somente se muito necess&rios, sendo a6P uma metodologia &gil, essa caracter2stica %ale (ara a mesma :mith,=>?=, (.;.

1*1* 7n4lise genrica entre "etodologias tradicionais e 4geisPara que os m1todos tamb1m fossem com(arados de maneira geral

e no somente em um caso (articular, escolheu-se alguns crit1riosobtidos da literatura :Pressman, =>?? e ommer%ille, =>??; (ara quetodas as metodologias &geis e tradicionais fossem a%aliadas de forma

equi%alente. Estes crit1rios foram a(licados nas duas metodologias e seusresultados com(arados. #o Quadro = so a(resentadas as caracter2sticasdos m1todos de desen%ol%imento tradicional de soft!are :9*; e odesen%ol%imento &gil de soft!are :9A;.

Quadro =D An&lise com(arati%a entre modelos de desen%ol%imento desoft!are.

Tradicional gil9e0nido no in2cio e com (oucas

mudanasCriati%o e sem requerimentos

claros

Clientes no en%ol%idos

En%ol%ido e com colaborao

frequente

9ocumentao 5ormal e obrigatria

9ocumentao formada (eloConhecimento dos membros e(assada (essoalmente ou (or

anota/esProjetos grandes Projetos (equenos

9esencoraja a entrega frequente desoft!are (ara o cliente

Entrega soft!are continuamenteao cliente

Binear Com(le3o e iterati%o5onteD :Autoria Pr(ria;

1*1** En&ol&i"ento co" o cliente

Enquanto no 9* h& a necessidade de um e3tenso detalhamentodos requerimentos (or (arte do cliente, no 9A h& maior e3ibilidadede%ido ao sistema iterati%o de trabalho. #o 9A o cliente est& eminterao constante, fa)endo sugest/es de melhorias e re%isando cadafase. Este (rocesso fa) com que mudanas de (aradigma sejam f&ceis deserem im(lementadas, ao contr&rio do 9*, aonde uma grande (arte dosoft!are (recisaria ser desmembrada (ara que (equenas melhoriasfossem e3ecutadas. A facilidade de mudanas no (rojeto tra)idas (elo

9A aumenta a satisfao do consumidor (or1m (ode aumentar o tem(oestimado de%ido as constantes altera/es.

1*1*.* /le;i


11/13

??

#o 9* o (a(el do (rogramador e do analista ou gerente do (rojeto1 se(arado. A arquitetura (arte dos requerimentos coletados na faseinicial e ento encaminhado (ara o analista ou gerente e s ento seguem(ara o (rogramador. #o 9A, de%ido J interao constante com o cliente eo fato do (rogramador de fato ser a entidade que mani(ula o soft!are, ae3ibilidade na arquitetura e a funcionalidade so maiores.

1*1*1* %ocu"enta,-o e co"unica,-o

"ma das (oucas &reas em que o 9A tem e3trema des%antagemem relao ao 9* 1 na documentao. ' 9* tem slida base nadocumentao e re%iso de cada (asso do desen%ol%imento. ' (rocessode documentao, a(esar de e3tenso e muitas %e)es considerado (esado,se torna mais sim(les de%ido a caracter2stica unidirecional do algoritmo.#o 9A, al1m da falta de artefatos, a interface (rim&ria de documentaoe re%iso do cdigo, muitas %e)es, se tornam as anota/es e coment&riosadicionados (elos desen%ol%edores e esta (r&tica (ode se tornar

(roblem&tica ao longo do (rojeto na questo de comunicao interna ecom o cliente. A(esar de ser a(ontada como uma grande des%antagem,(or ser considerada e3cessi%a no caso do 9*, a documentao no (odeser totalmente descartada e isto indica que o (rocesso de comunicaono 9A de%e ser (ensado com seriedade.

1*1*9* !a2acidade do siste"a

istemas (equenos, ou mesmo m1dios, so os ti(os de sistemascom melhores resultados no 9A (ois oferecem maior com(atibilidadecom a elasticidade que m1todo tra). istemas grandes oferecem uma

in1rcia maior (ara mudanas iterati%as em alguns as(ectos,es(ecialmente com (artes (erif1ricas do design. #este sentido (ode-setratar o (rojeto (ela tica do 9*A ou di%idir o sistema em (equenos(rocessos de 9A e trabalhar na com(atibili)ao destes.

9* !onclus-o

9e modo geral, a etodologia +gil 1 utili)ada em (rojetos que(ossuem requisitos mut&%eis ou onde estes mesmos no so claros (ara aequi(e e (ara o cliente, (or1m ela (ossui limita/es que di0cultam sua(r&tica tais como a di0culdade em de0nir as fun/es de cada membro ougerenciar a quantidade de recursos (ara o (rojeto. 'utro (onto

im(ortante a ser considerado 1 a cultura do cliente e tamb1m da equi(e.S& clientes que (recisam da documentao (ara manter sua sensao decontrole sobre o (rojeto, como tamb1m (odem no estar sem(redis(on2%eis (ara dialogar. 8sto causa atrasos signi0cati%os em um (rojeto&gil. Para os (rogramadores, mesmo os mais ca(acitados, (odem sentirdi0culdades em trabalhar nas de0ni/es da metodologia &gil, caso noestejam acostumados J constante comunicao no decorrer do (rojeto.

A etodologia *radicional (ossui uma estrutura que (ossibilita sertrabalhada em grandes (rojetos, de%ido J sua di%iso bem de0nida deati%idades, fun/es e tarefas junto a uma coleo de artefatos utili)ados

como (rodutos de entrada e sa2da de (rocessos, mas todo esse esforo:custo; (ode no ser justi0c&%el com uma equi(e (equena.' 9A no 1 a(enas de0nido (or um (equeno conjunto de (r&ticas

e t1cnicas. Atra%1s dos trabalhos e refer4ncias consultados (Wde-se


12/13

?=

concluir que o 9A trata de uma ca(acidade estrat1gica de criar eres(onder a mudanas, re(resentando um balano entre e3ibilidade eestrutura, ca(acidade de liberar a criati%idade e ino%ao do time dedesen%ol%edores e a ca(acidade de guiar as organi)a/es atra%1s demomentos de turbul4ncia. etodologias tradicionais ainda tero es(aonestes momentos de turbul4ncia (ois di%ersas &reas ainda t4m anecessidade de grande documentao.

's m1todos tradicionais baseiam-se em documenta/es enecessidades estabelecidas no in2cio do (rojeto, o que muitas %e)esdi0culta ou in%iabili)a modi0ca/es (osteriores, (or1m setores como dearmamento e defesa necessitam de (armetros r2gidos e documentaoacurada, o(tando assim (or este m1todo, (or1m o m1todo decomunicao no 9A de%e ter alguma rastreabilidade (ara que acomunicao no seja (erdida ao longo do (rocesso.

Com suas de%idas mudanas, a metodologia tradicional (odecontem(lar (arte dos (rocessos da metodologia &gil tornando-os bem

(r3imos ou equi%alentes em relao ao tem(o e esforo, mas a ess4nciada metodologia &gil est& nos quatro %alores do manifesto &gil focando naorgani)ao, nas (essoas e na cultura. E isso, certamente, 1 um (ontoim(ortante tra)ido (elo desen%ol%imento &gil na engenharia de soft!are.

Reer=ncias >i??.9is(on2%el emD htt(DYYgoo.glYdmF=6. Acesso em >KY>NY=>?T.

'ES, .O Constructive Cost Model II (COCOMOII*California, =>?T.9is(on2%el emDhtt(DYYsunset.usc.eduYcsseYresearchYC'C''88YcocomoZmain.html.Acessado emD ?=Y>Y=>?T.

9E##8#G, .O !pdating the Agile Manifesto, trategX [ Beadershi(aga)ine, "nited Uingdom, Fol. N, (.?=, =>?.

S'A8#, A.O Evaluation of agile methods and implementation*asters Programme in 8nformation *echnologX, Centria "ni%ersitX ofA((lied ciences, UoRRola-Pietarsaari, =>?. 9is(on2%el emDhtt(sDYYgoo.glY!"*R>. Acessado emD =?Y>NY=>?T.

UA*SA#, P.O On the "ole of #i$i for Managing %nowledge in AgileSoftware Development, 9e(artment of Com(uter cience andoft!are Engineering 7esearch, Concordia "ni%ersitX ontreal,

Canada, (. T==-T=, =>?.
http://goo.gl/9dmV2Xhttp://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.htmlhttps://goo.gl/wUTk0http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.htmlhttps://goo.gl/wUTk0http://goo.gl/9dmV2X


13/13

?

BA#9E7, E.O "eport to the president on capturing domesticcompetitive advantage in advanced manufacturing, E3ecuti%e'\ce of the President President]s Council of Ad%isors on cienceand *echnologX, ashington, =>?=. 9is(on2%el emDhtt(sDYYgoo.glYFMluK. Acessado emD =?Y>NY=>?T.

A78'**8, 5. .O ?an?. 9is(on2%el emhtt(DYYgoo.glYd"C'TU Acessado emD ==Y>NY=>?T.

8B', V.O 'VA#, B.O A#*'#8A, .O A#*'#8-B"^, .O The agile approachin industrial and software engineering pro&ect management,(. =,(ain, =>?.9is(on2%el emD htt(DYYgoo.glYUE*"U Acesso emD?KY>NY=>?T.

P7EA#, 7. Engenharia de Sotware "a 7?N.

CSAE7, U.O "*SE7BA#9, V.O Guia do Scru"* =>?. 9is(on2%el emDhtt(DYYgoo.glYah=Aa Acesso emD >NY>Y=>?T.

8*S, V. A.O Comparison of the I-M "ational !ni.ed 'rocess ande/treme 'rogramming, #e! orR, =>?=. 9is(on2%el emDhtt(DYYgoo.glY59Bn. Acessado emD =?Y>NY?T.

'E7F8BBE, 8.O Engenharia de Sotware* _ ed. o PauloD PersonPrentice Sall, =>??.

"BBAS, .O Comparison and problems between traditional andagile software development methodsO Ba((eenranta "ni%ersitXof *echnologX. 5inland, =>?N. 9is(on2%el emD htt(sDYYgoo.glY>ht`qR.Acessado emD =?Y>NY?T.

AG#E7, 7.O $rocessos de %esen&ol&i"ento de Sotware !onf4&eis>aseados e" $adr8es de Seguran,a $ "ni%ersidade 5ederal deanta aria. anta aria, 7, (.>, =>??. 9is(on2%el emDhtt(DYYgoo.glYbnb?qu. Acesso emD ?KY>NY=>?T.

A#G, 6.O The Combination of Agile and 0ean in Software

Development1 An 2)perience"eport Analsis, 8EEE Com(uterocietX, Agile Conference, Bero $ the 8rish oft!are Engineering7esearch CentreBimericR, 8reland, (. ?-, =>??.
https://goo.gl/V8Blu7http://goo.gl/dUCO6Khttp://goo.gl/KETBUKhttp://goo.gl/bnb1quhttps://goo.gl/V8Blu7http://goo.gl/dUCO6Khttp://goo.gl/KETBUKhttp://goo.gl/bnb1qu

Documents

TCC Metodos Ageis V6