UNIVERSIDADE PRESBITERIANA MACKENZIE

Faculdade de Computao e Informtica

Rinaldo Bezerra Junior

Metodologia Tradicional x Metodologia gil

So Paulo Abril de 2012

Universidade Presbiteriana Mackenzie Faculdade de Computao e Informtica Anlise de Sistemas II Prof. Ms. Regiane Moreno

Rinaldo Bezerra Junior

Metodologia Tradicional x Metodologia gil

So Paulo, Abril de 2012

Resumo
Nesse trabalho introduziu o leitor no histrico das metodologias de criao de software e apresentamos um comparativo entre a metodologia tradicional e a metodologia gil, demonstrando a origem, bem como os pontos positivos e negativos, suas principais funcionalidades e principais usos.

Sumrio
1.Introduo................................................................................................................................1 1 2.Objetivos..................................................................................................................................2 Apresentar um comparativo entre as metodologias de desenvolvimento de software tradicionais e as metodologias geis, demonstrando os pontos fortes de cada e as melhores utilizaes de cada um. Apresentamos de forma sucinta os conceitos de cada um, e a importncia de cada mtodo no desenvolvimento de sistemas.............................2 3.Aspectos Histricos .................................................................................................................3 4.Metodologia Tradicional..........................................................................................................6 4.1.Metodologia em Cascata.............................................................................................6

ii

1. Introduo
publico e notrio, atualmente, a importncia que as metodologias de desenvolvimento de software tm nas organizaes de TI, seus conceitos j esto consolidados no mercado mundial e seus resultados so cada vez melhores, medida que so aprimorados os processos de desenvolvimento de novos sistemas. A eficincia, a qualidade do software, os padres existentes permitem-nos afirmar que temos um arsenal suficiente para implantao de qualquer sistema com qualidade e eficincia. Temos uma gama enorme de padres, mtodos e conceitos que com certeza se encaixam na criao de um projeto. Metodologias tradicionais, como modelos incremental, espiral e de cascata alm do UP/RUP e metodologias geis como XP e Scrum disponibilizam a ns todo tipo de sustentao para cada projeto independente da ferramenta, linguagem de programao ou banco de dados usado.. Porm nem sempre foi assim, durante muito tempo, a inexistncia de padres de desenvolvimento trouxe rea de TI uma insegurana na criao e uma srie de questionamentos sobre a qualidade muito contestvel do produto final. Erros acumulados, falta de testes, ausncia de documentao e tantas outras razes produziram grandes prejuzos tanto financeiros como humanos. Foi uma poca onde os desenvolvedores faziam tudo na base do improviso, de uma forma quase amadora. Mas todo esse estado que alguns autores chamam de caos serviu para que houvesse todo esse progresso que temos hoje em termos de metodologia de desenvolvimento de software, com qualidade, prazos definidos e sistemas eficientes.

2. Objetivos
Apresentar um comparativo entre as metodologias de desenvolvimento de software tradicionais e as metodologias geis, demonstrando os pontos fortes de cada e as melhores utilizaes de cada um. Apresentamos de forma sucinta os conceitos de cada um, e a importncia de cada mtodo no desenvolvimento de sistemas.

3. Aspectos Histricos
Atualmente os sistemas so desenvolvidos utilizando uma grande quantidade de variveis, altamente complexos e torna-se primordial a utilizao de um planejamento para que esse sistema tenha sucesso na implantao. Existem muitas metodologias disponveis no mercado mas nem sempre foi assim, nos anos 60 com a ascenso da aplicao industrial dos softwares e o fim da exclusividade dos sistemas apenas para fins militares e cientficos e somando ao surgimento de novas linguagens de programao como o COBOL, resultaram em um expressivo crescimento na criao de softwares. O que se viu foi uma completa desorganizao no desenvolvimento de softwares. Empresas desenvolvendo e entregando aos seus clientes software complexos porm, apresentando defeitos, mal estruturados, que consumiam memria excessiva e principalmente no atendendo s necessidades dos usurios. Some-se a esse problema os atrasos no cumprimento de prazos ou cancelamentos de entregas dos sistemas ou ainda a difcil atualizao dos mesmos. O desenvolvimento de um sistema, naquele perodo, ocorria de maneira totalmente informal, sem metodologias, padres ou algo parecido, eram dependentes da lgica do programador que realizava todas as etapas segundo a mesma lgica. Os desenvolvedores estavam envolvidos em especificaes e as caractersticas particulares de hardware, restries de recursos como memria e armazenamento, delegando os problemas de software a um segundo plano, j que o grande custo na poca pertencia ao hardware. medida que os programas eram desenvolvidos e consequentemente crescia tambm o nmero de sistemas, comearam a surgir os problemas de um desenvolvimento sem padro ou planejamento que garantisse qualidade ou que reduzissem o mximo possvel os atrasos, as falhas de execuo, os custos imprevisveis e a manuteno difcil de realizar. Diante desse estado quase catico que se encontrava a rea de desenvolvimento, aconteceu na cidade de Gamish, na Alemanha, em 1968 uma conferncia internacional com o objetivo de tentar encontrar solues para o desenvolvimento de sistemas. A conferncia foi promovida pelo grupo de estudos em computao da OTAN (Organizao do Tratado do Atlntico Norte) que teve como figura principal o professor Fritz Bauer que deu o nome de

Engenharia de Software, deixando claro qual seria a motivao desse encontro, ou seja, na direo de criar uma metodologia de software assim como uma engenharia propriamente dita. No houve porm, ao final do encontro, uma proposta concreta que tivesse a aceitao da maioria, mas a partir da i que se viu foi uma disseminao da ideia que era necessria a criao de algo que padronizasse o desenvolvimento de sistemas. Com o passar do tempo, dentre as propostas que sugiram, um modelo estruturado foi se destacando em relao a outros. Esse modelo estruturado tinha como ponto de partida os processos j existentes no sistema e ia ampliando-se at uma viso total do sistema e depois dividia-se em parte menores partindo do todo para as partes, TopDown como conhecemos hoje, de cima para baixo, conforme o sistema se desenvolvia e chegava at as partes menores, iam focando os dados do sistema. Porm com o passar dos anos, surgiu um novo problema, o crescimento do volume de dados e a complexidade cada vez maior de suas estruturas e relacionamentos, e consequentemente o custo de armazenamento desses dados, j que o custo do hardware era alto. Isso acabou proporcionando um lugar de destaque aos dados, proporcionou o desenvolvimento dos SGBD (Sistemas Gerenciamento de Banco de Dados e surge um modelo de dados que teria um papel relevante que o Diagrama Entidade-Relacionamento).

Porm a importncia excessiva dada aos dados produziu um impasse, se por um lado havia profissionais que afirmavam ser a organizao dos dados o ponto mais importante a serem tratado em um sistema, outros declaravam que os processos eram a pea chave dos sistemas. Uns defendiam a criao do sistema a partir dos processos e outros a partir dos dados e o que prevaleceu foi o modelo tendo como inicio os dados j que havia um modelo de diagrama que podia representar a ligao fsico-lgico e a facilidade de implantao proporcionada pelos SGBD. At hoje muitos acreditam que a criao de um sistema deva ter incio no modelo de dados deixando os processos em segundo plano. Por volta de 1984, Sthepehn Mcmenamim e John Palmer propem a anlise essencial, um mtodo que utiliza o conceito de que dados so peas adjacentes aos processos e os primeiros elementos de um sistema a serem identificados so os processos existentes e suas utilizaes, aproximando da ideia que temos atualmente.

Um sistema desenvolvido pelo mtodo de anlise essencial tem que responder solicitaes de eventos do negcio e apresenta funcionalidades disposio dos usurios sem se preocupar como e onde esto os dados. A partir da dcada de 80 inicia-se um perodo em que a orientao a objeto comea a entrar em evidncia, comeam a surgir uma srie de diagramas diferentes que se de um lado oferecem uma grande gama de possibilidades para desenvolvedores, do outro lado, s vezes ficava difcil escolher um padro, consequentemente a isso em 1997 o OMG(Object Management Group) fez uma seleo para escolher um mtodo nico de diagramas a ser adotado como padro e a proposta escolhida foi apresentada pela Rational Software Corporation e recebeu o nome de UML. Com isso estabelece o paradigma de orientao a objeto com colaborao de diagramas, padres e metodologia de projeto com essa orientao.

4. Metodologia Tradicional
Foi a primeira metodologia a ser criada, conhecida tambm como modelo clssico de desenvolvimento, a mais antiga metodologia e tem extrema ligao com as linguagens de programao estruturadas, foram de certa maneira criadas para essas linguagens e fazem parte de uma primeira gerao de metodologias de desenvolvimento de softwares.

4.1. Metodologia em Cascata

uma metodologia sequencial, isto , a cada etapa cumprida segue-se a prxima. As principais caractersticas so: As atividades de especificar, codificar e os testes seguem uma disciplina; Uma atividade no iniciada sem que a atividade anterior tenha sido finalizada; H uma sequncia de atividades a serem seguidas; O usurio envolvido apenas no incio e no fim do processo.

Primeiro feita a especificao do projeto com as necessidades do sistema, as viabilidades tcnicas, econmicas e operacionais como por exemplo, hardware e softwares disponveis, possibilidades de aquisio de algum complemento ao sistema, impactos que possam ser ocasionados por alguma mudana no sistema ou nos processos e suas implicaes na empresa. Depois comea um levantamento dos processos e dados para que se tenha uma ideia das funcionalidades que devem estar presentes no software de forma que se consiga atender plenamente a necessidade do usurio, as regras de negcio e as restries que devem existir no sistema e tudo deve ser documentado. A partir desse ponto, tem incio a fase de projeto com descrio detalhada do software, interface do usurio e armazenamento dos dados e tambm deve ocorrer documentao desse estgio do projeto.

Aps toda essa documentao, comea a implementao do sistema na qual os processos comeam a tomar forma atravs da codificao do projeto, sendo seguida pela fase de testes e simulaes para identificar e solucionar problemas. Todos os testes devem ser feitos com o sistema completo e tambm com os subprogramas, verificar a integrao com algum outro software e ajustar para preparar a fase de implantao. Na fase de implantao acontece o treinamento dos usurios no novo sistema e a disponibilizao do sistema para o usurio, colocando-o em produo. Por fim a ltima fase envolve a manuteno que envolve os pequenos ajustes de erros identificados na implantao.

Figura1 Exemplo de metodologia em cascata

4.2. Modelo Espiral

Esse modelo reuniu as melhores caractersticas de modelos anteriores e apresentou uma dimenso diferente da concebida at ento, utilizando uma forma radial, Berry Boehm, seu criador, definiu que o incio se daria no centro e se expandiria de forma circular como um espiral. O processo dividido em atividades chamadas de regies de tarefas, que podem variar de 3 a 6 onde acontecem as seguintes atividades: Comunicao efetiva entre o desenvolvedor e o cliente;

Planejamento onde so definidos os recursos, o cronograma e demais informaes do projeto;

Anlise de Risco em mbito gerencial e tcnico; Engenharia de implementao de uma ou mais representao do software; Construo e Entrega, ou seja, quando se implementa, testa, instala e disponibiliza suporte ao usurio;

Avaliao do Cliente que oferece uma realimentao do cliente baseada na avaliao entre o que foi planejado e o que foi executado.

Cada processo se move a partir de seu centro no sentido horrio e cada rodada representa um tipo de projeto, e o software desenvolvido em uma srie de entregas incrementais. A cada iterao, avana-se no desenvolvimento do software e o sistema vai ficando mais complexo. A grande vantagem dessa metodologia em relao ao processo em cascata e o incremental so como atividades gerenciais so explicitadas junto com a engenharia do projeto, o envolvimento do cliente em cada etapa no projeto de maneira ativa. A participao maior do cliente/usurio, que acontece durante todo desenvolvimento, favorece um processo de evoluo onde desenvolvedor e cliente interagem melhor e compreendem a necessidade de cada etapa do software, entendendo os riscos tcnicos e gerenciais e diminuindo a ocasio de problemas

4.4 Processos Unificados RUP/UP

O processo unificado (UP) destaca as fases dinmicas do processo e os fluxos de trabalho (workflows), diferentemente dos processos analisados anteriormente, um processo proposto dentro do cenrio da abordagem orientada objetos, utiliza a UML e em particular dirigido Casos de Uso que uma tcnica que aborda o problema segundo a tica do usurio e tambm tem inspiraes no desenvolvimento iterativo e incremental (metodologia espiral), foi estabelecido para unificar uma srie de abordagens existentes, centrado na arquitetura do sistema desde o incio. De suas propostas surgiu o RUP (Rational Unified Process), uma metodologia em forma de framework desenvolvida pela Rational Software que ampliou e melhorou alguns pontos do UP. Abordaremos nesse trabalho o RUP por ser uma variante do UP mais completa.

O RUP surgiu de uma metodologia iniciada na Ericsson, baseada em componentes que se aglutinavam e colaboravam entre si e essa colaborao era estabelecida previamente utilizando o que se chamava casos de negcio (casos de uso). Essa ideia inicial teve colaborao do processo chamado Objectory (Object Factory) da empresa Objectory AB no sentido de aprofundar o conceito e a utilizao dos casos de uso e em 1995 a Rational Software Corporation adquire a Objectory AB com o propsito de unificar os princpios do desenvolvimento de software existentes. Da surge o ROP (Rational Objectory Process) que comeava a aprofundar a utilizao da UML na modelagem, mas como ainda no havia o envolvimento de questes de gesto de projeto, ambiente, implementao e testes, surgiu uma nova proposta que abrangia todos esses conceitos e deu origem ao RUP. Segundo Tonsig O RUP se preocupa em retratar a arquitetura do sistema, isto , uma viso do desenho completo ressaltando as mais importantes caractersticas, identificadas pelas pessoas que tenham responsabilidade na construo do projeto.. Consideremos como pessoas responsveis pelo projeto o cliente/usurio e os analistas de sistema e de negcio, e cada projeto definido deve ter caractersticas que caminhem junto para uma funcionalidade do sistema como um todo. Quando o RUP utiliza os casos de uso, demonstra claramente uma preocupao com as partes menores do projeto e sua interconexo para que ao final o sistema esteja funcionando perfeitamente. Os princpios do RUP so: Desenvolvimento iterativo do software que facilita a descrio dos requisitos e a identificao de problemas de inconsistncia; Administrao de requisitos que consiste em analisar e administrar os requisitos e suas mudanas no sistema; Utilizao de arquitetura baseada em componentes que oferece a possibilidade de reutilizao dos componentes; Modelagem visual do software que facilita a visualizao, construo e documentao da arquitetura do software;

Qualidade do software considerada fundamental em todo processo implicando em verificao contnua da funcionalidade, confiabilidade e validao do sistema;

Gesto das alternativas no software que coordena as verses do software.

O RUP se desenvolve atravs de uma srie de ciclos e formam uma verso do sistema. E cada ciclo envolve quatro fases e em cada uma dessas fases se realizam iteraes constitudas de uma srie de trabalhos. As fases so: Concepo - onde se estabelece o escopo do projeto e a viabilidade econmica; Elaborao - onde se identifica e elimina os principais riscos; Construo - que acontece de forma iterativa do incio do produto at a finalizao; Transio - onde o produto disponibilizado ao usurio.

Todas as fases so finalizadas com um milestone no qual se verifica se os objetivos traados foram alcanados. As atividades do RUP so: Modelagem do Negcio que na verdade uma compreenso pelos membros da estrutura, o modelo de gesto e a dinmica da organizao do cliente; Requerimentos que a documentao dos requisitos do sistema, gesto do escopo e busca das funcionalidades do sistema e suas mudanas; Anlise e projeto e trata-se da transformao dos requisitos em documentao tcnica com a descrio de como implementar o software; Implementao formada pela criao dos programas e pela integrao com outros sistemas que se achar necessrio; Testes so os testes feitos com o sistema criado e com outros sistemas a serem integrados e a validao com base nos requisitos; Desenvolvimento envolve a distribuio, instalao e treinamento dos usurios;

10

Gesto da configurao e so envolve o gerenciamento de todos os componentes criados durante o desenvolvimento;

Gesto de projeto formada pelo planejamento, acompanhamento do desenvolvimento e gerenciamento de riscos;

Ambiente organizao do ambiente de trabalho para a equipe e o acompanhamento da configurao do RUP para o projeto em questo.

Dessa maneira o RUP procura garantir um eficiente processo de desenvolvimento do software procurando eliminar riscos de fracasso, procurando uma qualidade mxima do sistema, estruturandose de forma a garantir ao cliente o melhor possvel.

Figura 2: Atividades e fases do RUP

5 Metodologia gil
11

Durante o ms de fevereiro de 2001, dezessete desenvolvedores de software, que se denominaram Agile Alliance, reuniram-se e produziram um documento chamado Manifesto Agil ou do ingls Manifesto for Agile Software Development, apresentando uma srie de mudanas de conceitos e paradigmas no desenvolvimento de software. Diziam no Manifesto; Estamos descobrindo maneiras melhores de desenvolver software fazendoo ns mesmos e ajudando outros a faz-lo. Atravs deste trabalho, passamos a valorizar: Indivduos e interaes entre eles mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o Cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano.

O fruto desse trabalho foi a propagao da metodologia gil atravs principalmente do Scrum e do XP (xtreme programing). Os processos geis tem por caractersticas o fato de darem menos importncia a analise, e a documentao e maior importncia a entregar um software funcionando o mais rpido possvel e a respostas mudanas nas necessidades de forma rpida. Como um dos princpios do Manifesto entregar um software funcionando com bastante frequncia em duas a trs semanas, eles entendem que dessa maneira o cliente fica mais satisfeito por ver uma nova funcionalidade em pouco tempo e se sente mais seguro em relao a prazos. Outro princpio do Manifesto uma pequena reunio diria de quinze minutos e em p, onde so respondidas a cinco perguntas: O que fiz desde a reunio de ontem? Em que estou trabalhando hoje? Que problemas esto me impedindo de atingir esse objetivo? O que acabamos esquecendo? O que aprendi e o que acharia interessante compartilhar com o resto da equipo?

12

O objetivo da reunio em p apresentar problemas e no resolve-las, a soluo se dar na reunio seguinte, o que acaba por se caracterizar em uma boa ideia de gesto do tempo. Outra ideia importante a programao em pares onde dois programadores se revezam num mesmo computador escrevendo um mesmo cdigo, dessa maneira os dois sabem e so responsveis pelo que est sendo escrito.

6 Concluso
Todos as metodologias tm seus pontos positivos e negativos, mas o que importante na hora de escolher uma metodologia analisar qual o tamanho do projeto, a quantidade de pessoas envolvidas, e a cultura do cliente. Os processos geis foram usados com sucesso em muitos projetos de pequena escala, porm em grandes projetos, existe um temor por parte de engenheiros e analistas da sua eficincia pois para eles, esse sucesso inda no os credencia para um desenvolvimento de um software maior com uma grande quantidade de dados, subprogramas e rotinas e envolvendo uma grande equipe, j que a metodologia no prioriza a documentao, e trabalha com equipes pequenas, algo que primordial no desenvolvimento de um grande sistema. J as metodologias tradicionais so consideradas muito quadradas por alguns, o RUP considerado muito pesado para desenvolvimento em pequenos software e isso tem implicao no tempo de entrega do sistema. Uma das crticas ao desenvolvimento gil a de que como o cliente o proprietrio do projeto, e que diz o que quer e suas funcionalidades, elimina-se a figura do analista de negcios e dessa maneira pode acontecer que o produto final no seja o melhor produto para aquele cliente. H alguns que defendem um modelo hbrido de desenvolvimento com a metodologia tradicional nas fases de anlise, gerenciamento e deixando as metodologias geis somente no desenvolvimento. Para sistemas grandes vejo como mais indicado ainda as metodologias tradicionais, particularmente o RUP, pois a documentao, as atividades e fases produzem um trabalho mais minucioso e com menos possibilidade de riscos e insucessos, j para um software pequeno a metodologia gil pode ser usada com grande possibilidade de sucesso tambm haja vista que envolve uma pequena quantidade der recursos financeiros.

7 Bibliografia
13

ruppers.com.br/overview/

http://erzuliani.blogspot.com.br/2009/04/scrum-x-rup.html

http://www.sdtimes.com/content/article.aspx?ArticleID=36195&page=1

http://manifestoagil.com.br/
Engenharia de Software Analise e projeto de sistemas Sergio Luiz Tonsig Engenharia de Software Qualidade e Produtividade com Tecnologia Kechi Hirama Engenharia de Software: Os paradigmas Clssico & Orientado a Objetos

14