Bruno Junqueira Alves Orientador: Prof. Srgio Murilo Maciel Fernandes
ii
Universidade de Pernambuco Escola Politcnica de Pernambuco Graduao em Engenharia de Computao
Bruno Junqueira Alves
Estudo Comparativo entre Mtodos geis e Tradicionais de Fabricao de Software
Monografia apresentada como requisito parcial para obteno do diploma de Bacharel em Engenharia de Computao pela Escola Politcnica de Pernambuco Universidade de Pernambuco.
Recife, Agosto/2012.
iii
De acordo
Recife
____/___________/_____
_____________________________________ Orientador da Monografia
iv
Dedico esse trabalho a todos que me deram o apoio necessrio, minha famlia, meu orientador e amigo Srgio Murilo e, principalmente, Deus.
v
Resumo Nesse trabalho, foi feita uma pesquisa a respeito dos atuais mtodos de fabricao de software utilizados pelas principais software houses do mundo. Tambm foram citados mtodos usados no incio da modernizao dos processos de desenvolvimento. Atravs de entrevistas com especialistas na rea, leitura especializada e um estudo de caso, foi possvel chegar a uma comparao concisa entre os existentes mtodos de construo de software.
vi
Abstract In this study, a survey was made about the current software development methods that are used by major software houses in the world. This work also mentions the methods used at the beginning of the modernization of development processes. Based on interviews with experts in the field, reading specialized books and performing a case study, it was possible to reach a concise comparison between the existing methods of software development.
vii
Sumrio Captulo 1 Introduo 1 1.1 Objetivo 2 1.2 Estrutura do trabalho 2 1.3 Metodologia 3 Captulo 2 Os processos de desenvolvimento de software. 4 2.1 Modelo cascata 4 2.2 Modelos incrementais de processo 6 2.2.1 O modelo Incremental 7 2.2.1.1 RUP (Rational Unified Process) 8 2.2.2 O modelo RAD 11 2.3 Modelos evolucionrios de software 13 2.3.1 Prototipagem 13 2.3.2 Modelo espiral 14 2.4 Desenvolvimento gil 17 Captulo 3 Comparao entre metodologias geis e metodologias clssicas 23 3.1 Introduo 23 3.2 Comparativo entre as metodologias 23 3.2.1 Incio do projeto 24
viii
3.2.2 Planejamento 25 3.2.2.1 Escopo 26 3.2.2.2 Tempo 26 3.2.2.3 Qualidade 27 3.2.2.4 Riscos 29 3.2.2.5 Recursos Humanos 29 3.2.2.6 Custos 30 3.2.3 Execuo 31 3.2.4 Controle 31 3.2.5 Encerramento 32 Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide 34 4.1 A Procenge 34 4.2 O Pirmide 35 4.3 Estudo de caso 35 Captulo 5 Concluses e trabalhos futuros 39 Referncias 41
ix
Lista de Figuras Figura 1. Etapas da metodologia cascata................................................................. 5 Figura 2. Modelo Incremental ................................................................................... 7 Figura 3. Viso geral do RUP ................................................................................... 9 Figura 4. Fases de desenvolvimento do RUP ........................................................ 10 Figura 5. Modelo RAD ............................................................................................ 12 Figura 6. Ciclo da Prototipagem ............................................................................. 14 Figura 7. O modelo espiral ..................................................................................... 16 Figura 8. Metodologia Scrum .................................................................................. 21 Figura 9. Desenvolvimento guiado por caractersticas ........................................... 22 Figura 10. Fatores de projeto ................................................................................ 25 Figura 11. Sistema de Gesto procenge ............................................................... 36
Captulo 1 - Introduo Bruno Junqueira Alves 1 Captulo 1 Introduo A engenharia de software uma disciplina relativamente nova. A ideia de engenharia de software apareceu na dcada de 1960, exatamente em 1968. Nessa poca, o hardware passava para um nvel mais avanado de construo, tornando os computadores capazes de efetuarem tarefas antes impensveis e tornando a fabricao mais barata. Mas, ao contrrio dessa facilidade do hardware, o software estava ficando mais caro e a entrega com mais atraso. Portanto, novos mtodos eram necessrios para controlar a complexidade de sua fabricao. Ento foram criados os primeiros processos de fabricao de software, onde o objetivo era tornar a criao do software semelhante a um processo industrial, a fim de acompanhar o desenvolvimento do hardware das mquinas. Houve um grande progresso desde essa poca, mas ainda existem problemas para entregar os projetos no prazo e manter o custo inicialmente acordado. Por ser um processo intelectual, que usa julgamento humano, os processos de desenvolvimento de software so complexos e suas tentativas de automatizao no obtiveram sucesso pleno. Os primeiros mtodos de desenvolvimento possuam orientao esttica, exatamente como uma linha de montagem. Com um tempo, as empresas comearam a adotar uma postura mais dinmica, onde as mudanas no cdigo no representam tantos problemas para a adaptao a um cliente especfico. A partir da, foram criados os mtodos geis, cujo foco era nas pessoas e no nos processos estticos de desenvolvimento.
Captulo 1 - Introduo Bruno Junqueira Alves 2 1.1 Objetivo Nesse trabalho, sero demonstrados os principais processos de desenvolvimento de software usados nas fbricas de software e tambm os que deixaram de ser utilizados devido a mudanas nos projetos do software. No final, ser apresentada uma concluso a partir de uma comparao entre esses processos. 1.2 Estrutura do trabalho No captulo 2, sero apresentados os mtodos criados para o aperfeioamento do desenvolvimento do software desde o incio da crise, durante a dcada de 1960. Na primeira seo deste captulo, a seo 2.1, ser apresentada a metodologia em cascata. Na seo 2.2, sero apresentados os modelos incrementais de processo. Esses modelos se dividem em processo incremental e modelo RAD. Na seo seguinte, 2.3, sero detalhados os modelos evolucionrios de processo de software, nos quais sero citados o uso de prototipagem e o modelo espiral. Na ltima seo do captulo 2, ser detalhado o desenvolvimento gil. Nessa seo, ser apresentada a sua histria e porque esse modelo de processo de desenvolvimento vem sendo mais adotado pelas software houses. No captulo 3, ser feita a comparao entre os modelos, citando suas vantagens e desvantagens em relao ao planejamento, execuo e controle da fabricao. No captulo 4, ser mostrado um estudo de caso a partir de uma empresa estabelecida no mercado, demonstrando a evoluo e os ganhos da empresa ao utilizar a metodologia de desenvolvimento gil em seu ambiente.
Captulo 1 - Introduo Bruno Junqueira Alves 3 O captulo 5, e ltimo desse trabalho, levantar as concluses e os trabalhos futuros possveis a partir desse estudo comparativo, de modo que outros interessados realizem mais pesquisas em relao ao mercado de software houses brasileiro. 1.3 Metodologia A metodologia adotada nesse estudo foi a leitura de livros, artigos e trabalhos especializados na rea de desenvolvimento de software junto com entrevistas com profissionais que trabalham na rea de desenvolvimento e gerncia de qualidade de software. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 4 Captulo 2 Os processos de desenvolvimento de software. O processo de desenvolvimento de software pode ser definido como uma coleo de padres que definem um conjunto de atividades, aes, tarefas de trabalho, produtos de trabalho e/ou comportamentos relacionados e necessrios ao desenvolvimento de software de computador. Pela combinao de padres, uma equipe de software pode definir um processo que melhor satisfaa s necessidades de um projeto. Nesse captulo sero apresentados os principais mtodos conhecidos de desenvolvimento de software, de modo que se possa ter um entendimento para a comparao desses mtodos. 2.1 Modelo cascata Existem ocasies onde todos os requisitos de um sistema so bem compreendidos. O sistema a ser construdo no precisa passar por muitas adaptaes ou evolues (aperfeioamentos), tornando sua implementao linear. O modelo cascata, ou clssico, foi a primeira metodologia de desenvolvimento de software apresentada. Ela usa uma abordagem sistemtica e sequencial para o desenvolvimento do software [4]. um modelo onde a etapa seguinte s executada aps a anterior ser totalmente finalizada. Para ser iniciada uma etapa, a anterior precisar estar totalmente documentada e aprovada. Essa metodologia surgiu em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros [6]. A Figura 1 ilustra bem o processo.
Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 5
Figura 1. Etapas da metodologia cascata [Fonte: retirado de [6]] 1. Definio de requisitos: As funes, as restries e os objetivos do sistema so estabelecidos atravs de entrevista com usurios do sistema. Aps isso, esses trs pontos so definidos em detalhes e servem como uma especificao do sistema. 2. Projetos de sistemas e de software: O processo de projeto de sistemas agrupa os requisitos em sistemas de hardware e software [9]. Ele estabelece uma arquitetura do sistema geral. O projeto de software envolve a identificao e a descrio das funes fundamentais do sistema de software e suas relaes. 3. Implementao e teste de unidades: Durante esse estgio, o projeto de software compreendido como um conjunto de programas ou unidades de programa [4][7]. O teste de unidades certifica que as especificaes de cada unidade foram atendidas. 4. Integrao e teste de sistemas: As unidades de programa ou programas individuais so integrados e testados como um sistema nico a fim de garantir que todas as especificaes foram atendidas. Depois do teste de sistemas, o software entregue ao cliente. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 6 5. Operao e manuteno: Normalmente, embora no necessariamente, esta a fase mais longa do ciclo de vida [7]. O sistema instalado e sua operao iniciada. A manuteno envolve corrigir erros que no foram descobertos anteriormente, em estgios anteriores do ciclo de vida. Com isso, as implementaes do sistema so melhoradas e a quantidade de funes aumentada medida que novas especificaes so descobertas. O maior problema dessa metodologia a sua alta burocracia e inflexibilidade na diviso do processo em fases bem distintas [6]. Esses dois fatores levam a um alto nmero de atrasos ou at a cancelamentos de projetos. Em relao aos atrasos, os custos se elevam, superando os custos previstos inicialmente, tornando o software mais caro. Outro problema originado a partir desses dois pontos o da qualidade do software. Os que so entregues dentro do prazo, e custando o acordado inicialmente, possuem qualidade duvidosa, pois houve muita presso nos desenvolvedores para cumprir os prazos. Hoje em dia, o trabalho em software de ritmo rpido e com grande quantidade de pedidos de modificaes. Com isso, o modelo cascata inadequado para esse tipo de trabalho. O modelo pode ser til em projetos onde os requisitos so fixos e o trabalho deve seguir de modo linear. 2.2 Modelos incrementais de processo H situaes em que os requisitos iniciais do software so razoavelmente definidos, mas o escopo global do esforo de desenvolvimento elimina um processo puramente linear. Alm disso, pode haver a necessidade de fornecer um conjunto limitado de funcionalidades do software aos usurios e depois refinar e expandir aquela funcionalidade em verses posteriores do software. Em tais casos, o processo de desenvolver o software incrementalmente escolhido [4]. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 7 2.2.1 O modelo Incremental O modelo incremental possui elementos do modelo cascata, que aplicado de maneira iterativa [4]. No modelo incremental, so aplicadas sequncias lineares de uma forma racional medida que o tempo passa, como mostrado na Figura 2. Cada sequncia linear produz incrementos do software passveis de serem entregues. Figura 2. Modelo Incremental [Fonte: retirado de [4]] No processo incremental, o primeiro incremento desenvolvido chamado de ncleo. Esse ncleo contm as caractersticas mais bsicas do software. Ao longo do tempo o usurio solicita melhorias, ou seja, novos incrementos. So feitos novos planos de projeto a fim de que o software seja aperfeioado. Esse processo repetido at que o sistema esteja com todas as funcionalidades implementadas. A vantagem do uso desse modelo a previso de uso de mo de obra extra e de novas tecnologias de hardware. Atravs desse modelo, pode-se prever o uso de mais ou menos desenvolvedores. No caso de novas tecnologias de hardware, podem ser feitos planos de projeto de modo que se evite o uso dessas novas tecnologias com data de lanamento incerta. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 8 O modelo incremental iterativo por natureza [4]. E tem o objetivo de apresentar um novo produto operacional a cada incremento. 2.2.1.1 RUP (Rational Unified Process) O RUP um processo proprietrio de engenharia de software. Foi criada pela Rational Software Corporation, adquirida posteriormente pela IBM, ficando conhecida como RUP IBM ou IRUP. Esse processo fornece tcnicas s equipes de desenvolvimento de software objetivando o aumento da produtividade seguindo uma abordagem prescritiva. O RUP se baseia no paradigma de Orientao a Objetos e documentado utilizando UML (Unified Modeling Language) para ilustrar os processos em ao. O principal objetivo do RUP atender as necessidades dos usurios garantindo uma produo de software de alta qualidade que cumpra um cronograma e um oramento previsveis [8]. considerado um processo pesado (tradicional) por muitos especialistas e preferencialmente aplicvel a grandes equipes de desenvolvimento e a grandes projetos. O RUP permite definir quem o responsvel pelo o que deve ser feito, como deve ser feito e quando deve ser feito, descrevendo todas as metas especficas de desenvolvimento para que sejam alcanadas. A Figura 3 ilustra de forma geral esse processo.
Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 9
Figura 3. Viso geral do RUP [Fonte: retirado de [9]] O RUP organiza o desenvolvimento em quatro fases, como ilustrado na figura 4 e explicado a seguir. Cada fase tem um papel fundamental para que o objetivo seja cumprido: Concepo ou Iniciao: Essa fase abrange as tarefas de comunicao com o cliente e planejamento. Ocorre a identificao e a especificao dos casos de uso do projeto. Tambm feito um plano de projeto, analisando seus riscos, delimitando os custos e os prazos e estabelecendo as prioridades. Elaborao: realizada a anlise da extenso do sistema. Tambm definida a arquitetura que ser utilizada no sistema. Essa arquitetura deve ser estvel e robusta. Usando essa arquitetura como guia, feita a anlise e o projeto dos casos de uso, posteriormente documentados. Construo: O objetivo dessa fase o desenvolvimento de componentes e outros recursos do sistema. nessa fase que ocorre a produo de cdigos e os testes alfa para certificar que os casos de uso esto sendo implementados corretamente. Devem-se aplicar processos de testes estveis. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 10 Transio: O foco nessa fase assegurar que o software esteja disponvel para seus usurios finais [9]. As atividades nessa fase incluem o treinamento dos usurios finais e a realizao dos testes beta do sistema visando que o mesmo tenha os nveis de qualidade adequados.
Figura 4. Fases de desenvolvimento do RUP [Fonte: retirado de [8]] O RUP tenta diminuir os riscos do desenvolvimento, a fim de torn-lo mais eficiente, utilizando seis prticas bsicas a serem executadas durante o projeto: Desenvolver iterativamente Esta prtica permite que requisitos sejam identificados ou modificados mais facilmente, ocorra uma integrao progressiva de elementos ao software, ocasionando uma melhora na identificao dos riscos. Gerenciar requerimentos Prov uma maneira prtica de produzir, organizar e comunicar os requisitos de um projeto. O gerenciamento de recursos acarreta um melhor controle sobre projetos complexos [10]. Utilizar arquiteturas baseadas em componentes O processo foca no desenvolvimento inicial de uma arquitetura robusta, antes do comprometimento de recursos em larga escala. Essa prtica descreve como projetar uma arquitetura flexvel, que suporta mudanas e promove Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 11 um reuso de software efetivo. O RUP prov uma aproximao sistemtica para definir uma arquitetura atravs de componentes novos ou existentes [10]. Um componente pode ser definido como um mdulo no-trivial ou um subsistema que cumpre uma funo clara. Modelar visualmente O processo mostra como modelar visualmente um software para identificar a estrutura e o comportamento da arquitetura e dos componentes. Isso permite entender melhor no s a concepo e complexidade do sistema, como tambm dimensionar, alm de facilitar a identificao e a soluo de problemas. O RUP, atravs da UML, permite uma modelagem compreensiva de sistemas complexos, formando uma base para a implementao e capturando requisitos com preciso. Verificao contnua da qualidade O RUP toma a qualidade como responsabilidade de todos os integrantes do projeto. Durante o ciclo de vida do projeto, os integrantes implementam, medem e avaliam tanto a qualidade do processo como a do produto. Controle de mudanas O RUP mostra como possvel controlar, monitorar e identificar mudanas para obter um desenvolvimento iterativo com sucesso. Isso ajuda o software a obter uma boa qualidade durante e depois de seu desenvolvimento. 2.2.2 O modelo RAD O RAD (Rapid Application Development, desenvolvimento rpido de aplicao) um modelo de processo focado no curto desenvolvimento. O modelo RAD uma adaptao de alta velocidade do modelo cascata, no qual o desenvolvimento rpido alcanado com o uso de uma abordagem de construo baseada em componentes [4]. Esse modelo altamente recomendado para casos de projeto onde as principais funcionalidades podem ser implementadas em menos de trs meses. Cada funo pode ser tratada por uma equipe RAD diferente, no final juntando todas Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 12 as funes em um todo. A Figura 5 ilustra bem como acontece um projeto usando metodologia RAD em seu desenvolvimento.
Figura 5. Modelo RAD [Fonte: retirado de [4]] As desvantagens desse modelo so: Necessidade de alto nmero de recursos humanos para desenvolver as funes em tempo hbil; Comprometimento dos desenvolvedores e clientes; Necessidade de alta modularizao do sistema, o que consome muito tempo de reunio, diminuindo o tempo de desenvolvimento; Devido ao estilo de alta velocidade de desenvolvimento, pode no ser adequado quando existem altos riscos. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 13 2.3 Modelos evolucionrios de software Com o passar do tempo, o software evolui como todo sistema complexo. Os requisitos mudam, os prazos para entregar o produto final ficam cada vez mais curtos. Com isso, os processos de software se adaptaram de modo que se entregue uma verso reduzida, mas que atenda todos os requisitos bsicos, num prazo curto que permita seu uso pelos clientes. A ideia por trs do desenvolvimento evolucionrio implementar um sistema bsico, uma verso inicial, mas que, ao passar do tempo, outras verses, com funcionalidades mais complexas, sejam entregues para completar o projeto. A abordagem evolucionria do desenvolvimento de software, muitas vezes, mais eficaz do que a abordagem cascata, no sentido de produzir sistemas que atendam s necessidades imediatas dos clientes [7]. O modelo evolucionrio tem como vantagem o fato da especificao do sistema ser feita gradativamente. medida que o usurio adquire maior conhecimento em relao s suas preferncias no sistema, compreendendo melhor seus problemas, isso passa a ser refletido no software. Sero brevemente apresentados dois processos evolucionrios: prototipagem, modelo espiral. 2.3.1 Prototipagem Muitas vezes o cliente no tem uma clara viso dos requisitos que lhe interessam, ou o desenvolvedor no tem certeza sobre o uso de um certo algoritmo ou sobre a portabilidade para um sistema operacional, ou qual interao homem/mquina o sistema deve assumir. Nesses casos, o uso da prototipagem se faz muito til. Primeiramente, o engenheiro de software se rene com o cliente a fim de delinear os requisitos bsicos do sistema, as necessidades conhecidas e requisitos que precisam ser mais bem definidos. A seguir, o projeto se concentra em entregar um executvel com todos os requisitos bsicos e uma interface prxima do ideal. O Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 14 feedback do cliente vai servir para aprimorar esses requisitos e implementar outros mais complexos, tornando o entendimento por parte do desenvolvedor mais fcil. A Figura 6 ilustra como o processo de prototipagem acontece dentro do projeto. Idealmente, o prottipo serve apenas para identificar os requisitos que esto sendo satisfeitos e como o sistema pode ser aprimorado. Mas muitos clientes usam esse prottipo inicial como se fosse o executvel final, ao perceberem que no o produto final, eles reclamam e exigem consertos, ao invs de esperarem por uma nova verso mais refinada do sistema, com mais qualidade e robustez.
Figura 6. Ciclo da Prototipagem [Fonte: retirado de [4]] Apesar desses problemas, o paradigma de prototipagem pode ser muito efetivo para os engenheiros de software. O importante definir as regras de desenvolvimento logo no incio do projeto (linguagem e algoritmos) assim como entender todos os requisitos do cliente. 2.3.2 Modelo espiral O modelo espiral foi proposto por Boehm, em 1988 [4]. um modelo de processo de software que combina a natureza iterativa da prototipagem e os aspectos controlados do desenvolvimento em cascata. Ao invs de representar o Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 15 processo como uma sequncia de atividades, cujo retorno essencial para iniciar a prxima atividade, o modelo representado como uma espiral. Cada loop da espiral divido em quatro setores: Definio de objetivos So definidos os objetivos especficos do projeto. Tambm so identificadas as restries para o processo e o produto e preparado um plano de gerenciamento. Os riscos tambm so identificados e, dependendo desses riscos, estratgias alternativas so planejadas. Avaliao e reduo de riscos Aps os riscos serem identificados, uma anlise detalhada dos mesmos feita e providncias so tomadas para reduzi-los. Desenvolvimento e validao Aps a avaliao dos riscos, um modelo de desenvolvimento escolhido para o projeto. Por exemplo, se o risco principal identificado na fase anterior for a integrao de sistemas, o modelo cascata pode ser adotado. Planejamento O projeto revisado para que seja tomada uma deciso a respeito do prximo loop da espiral. Caso seja decidido continuar, novos planos sero traados para o projeto seguindo a mesma metodologia. A Figura 7 ilustra como ocorre um desenvolvimento de projeto seguindo o padro espiral de projeto. Observar que a cada nova espiral realizada, novos planejamentos so feitos para o projeto. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 16
Figura 7. O modelo espiral [Fonte: retirado de [7]] Uma importante diferena do modelo espiral para ou outros modelos de processo, exceto o RUP, a explcita considerao dos riscos no modelo espiral. Os riscos podem resultar em problemas no projeto, como ultrapassar o prazo ou o custo previsto. Diferentemente dos outros processos, que so encerrados quando o software entregue, no modelo em espiral existe uma constante evoluo do produto, tornando o mesmo mais robusto e mais de acordo com os pedidos do cliente. O modelo espiral uma abordagem realista do desenvolvimento de software e sistemas de grande porte [4]. Como o software evolui, tanto o desenvolvedor como o cliente podem entender melhor o sistema e terem a reao adequada aos riscos de cada nvel evolucionrio. O modelo usa a prototipagem como uma ferramenta de reduo de riscos, como exibido na Figura 7, porm, pode permitir que a prototipagem seja usada em mais de um estgio da evoluo do produto. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 17 Para convencer os clientes de que a abordagem espiral controlvel, deve-se ter uma competncia considervel para avaliar os riscos. Caso um risco grave no seja identificado no incio, certamente ocorrero problemas. 2.4 Desenvolvimento gil A partir da dcada de 90, comearam a surgir novos mtodos sugerindo uma abordagem de desenvolvimento gil onde os processos adotados tentam se adaptar s mudanas, apoiando a equipe de desenvolvimento no seu trabalho. Os mtodos geis caracterizam-se pelo seu carter adaptativo e orientado a pessoas. As abordagens geis compartilham, na sua essncia, o processo de desenvolvimento centrado nas pessoas, orientado obteno de artefatos a partir de iteraes, o que, consequentemente, impe o carter adaptativo durante todo o ciclo de desenvolvimento. No incio da primeira dcada de 2000, um grupo de especialistas formulou um conjunto de princpios que definem a metodologia gil [1]. Estes so os seguintes: A prioridade satisfazer o cliente atravs de entregas contnuas e frequentes; Receber bem as mudanas de requisitos, mesmo em uma fase avanada do projeto; Entregas com frequncia, sempre na menor escala de tempo; As equipes de negcio e de desenvolvimento devem trabalhar juntas diariamente; Manter uma equipe motivada fornecendo ambiente, apoio e confiana necessrios; A maneira mais eficiente da informao circular dentro do time de desenvolvimento atravs de uma conversa presencial; Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 18 Ter o sistema funcionando a melhor medida de progresso; Processos geis promovem o desenvolvimento sustentvel; Ateno contnua excelncia tcnica e a um bom design, aumenta a agilidade; Simplicidade essencial; As melhores arquiteturas, requisitos e projetos provm de equipes organizadas; Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz. Com base nesses princpios, as metodologias geis existentes apresentam um conjunto de atividades a serem adotadas durante o desenvolvimento de sistemas. O termo metodologias geis tornou-se popular em 2001 quando dezessete especialistas em desenvolvimento de software representando os mtodos Scrum, Extreme Programming e outros [6], estabeleceram os princpios comuns, anteriormente listados, compartilhados por esses mtodos. Os processos geis mais conhecidos so os seguintes: Extreme programming (XP): uma abordagem deliberada e disciplinada para o desenvolvimento do software. O primeiro projeto a usar o XP foi o C3, da Chrysler [4]. uma metodologia baseada em quatro categorias de regras e prticas a fim de garantir a qualidade do software produzido: Planejamento O cliente descreve suas atividades que sero absorvidas pelo software, conhecidas como estrias do usurio. O cliente, ento atribui um valor a essas estrias, que definem as prioridades das funcionalidades do sistema. A equipe XP, ento, atribui um custo a cada estria, medido em semanas de desenvolvimento. Caso o custo de uma estria ultrapasse trs semanas, pede-se que o cliente divida a estria original em estrias menores e o processo de atribuio de custos e valor acontece novamente. Uma observao importante, novas estrias podem ser escritas a Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 19 qualquer momento do processo. Uma vez feito um compromisso entre equipe e cliente de quais estrias iro entrar na verso do software e a data de entrega dessa verso, a equipe estuda qual o modo seguir: Todas as estrias sero implementadas; As estrias de maior prioridade sero implementadas primeiro; As estrias com maior risco sero implementadas primeiro. Aps a entrega da primeira verso, a equipe calcula a velocidade do projeto de acordo com a quantidade de estrias que foram entregues na primeira verso. Essa medio ajuda em dois pontos: em relao ao tempo de entrega do sistema; e em relao ao comprometimento (esforo) da equipe dentro de uma verso. Se ocorrer um comprometimento excessivo dos profissionais, haver uma modificao no contedo das verses ou na data de entrega. Projeto Segue rigorosamente o princpio KIS (keep it simple mantenha a simplicidade). Fornece diretrizes de implementao para uma estria a partir da maneira como ela foi escrita. Se for encontrado um problema difcil nessa fase, recomendada a construo de um prottipo operacional, que no ser uma verso final do sistema. Esse prottipo denominado soluo de ponta, e ser avaliado a fim de diminuir o risco de uma estria quando a verdadeira implementao for iniciada e revisar as estimativas de entrega das verses. Codificao Tem como caracterstica chave a programao em pares, s vezes at uma terceira pessoa entra no processo de codificao. Essa caracterstica importante, pois mantm os desenvolvedores concentrados no problema a ser resolvido. Na prtica cada um pode assumir uma tarefa diferente durante a codificao. Por exemplo, um desenvolvedor fica responsvel pelos clculos a serem escritos no cdigo enquanto outro desenvolvedor fica responsvel pela adequao do cdigo aos critrios de codificao, garantindo que esse cdigo encaixe no projeto mais amplo da estria. Isso faz com que a funcionalidade de uma estria seja entregue no Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 20 tempo correto, seguindo todos os padres do projeto e com qualidade para o cliente. Testes recomendado que, ao terminar de projetar as estrias do cliente, sejam criados testes unitrios, os quais exercitaro a interface, as estruturas de dados e a funcionalidade de um componente do projeto. Essa prtica encoraja a prtica de testes de regresso: testar as funcionalidades j implementadas, sempre quando o cdigo for modificado. medida que os testes unitrios so realizados e organizados numa sequncia, o teste de integrao pode ser feito diariamente. Isso fornece equipe uma viso de progresso e indica sinais de alerta caso o projeto tenha problemas. Ao final so feitos os testes de aceitao, estes feitos pelo cliente, que so testes das estrias do usurio implementadas numa verso do sistema. SCRUM: Desenvolvido na dcada de 1990 por Jeff Sutherland e sua equipe. O nome deriva de uma atividade decorrente do jogo de rugby. Esse mtodo orienta- se por trs princpios: a visibilidade, a inspeo e a adaptabilidade. Todos os requisitos devem estar visveis a todos os envolvidos no desenvolvimento, a inspeo deve ser uma ao frequente e, consequentemente, as aes para adaptao do produto de software devem ser realizadas. No SCRUM, so incorporadas as seguintes atividades de desenvolvimento: requisitos, anlise, projeto, evoluo e entrega. Essas atividades so reunidas em um padro de processo, chamado Sprint. Dentro de uma Sprint, o problema do cliente adaptado, definido e executado, podendo sofrer modificaes durante a Sprint. O tempo da Sprint definido pelo responsvel do projeto, podendo ter 30 dias ou uma semana, na Figura 8, este tempo definido em 30 dias. A cada dia da Sprint, feita uma reunio rpida de 15 minutos para discutir brevemente o que foi feito no dia anterior, o que est atrapalhando o desenvolvimento da nova funcionalidade e o que ser feito at a prxima reunio rpida (stand up meeting), que acontece no dia seguinte, preferivelmente sempre no mesmo horrio. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 21 No final da Sprint, uma verso de demonstrao com as funes definidas no incio apresentada ao cliente e o mesmo realiza a avaliao. Com o SCRUM, uma equipe de desenvolvimento pode trabalhar de modo que os problemas possam ser previamente vistos, ocasionando novas reunies de projeto para sanar esses problemas, tornando o desenvolvimento mais bem sucedido. Figura 8. Metodologia Scrum [Fonte: retirado de [4]] FDD (Feature Driven Development Desenvolvimento Guiado por Caractersticas): Foi concebido como um modelo prtico de processo de engenharia de software orientada a objetos. Em seu contexto, uma caracterstica seria uma funo valorizada pelo cliente que poderia ser implementada em duas semanas ou menos. Esse mtodo se baseia nos seguintes processos: desenvolver um modelo global, construir uma lista de caractersticas, planejar por caractersticas, projetar e construir por caractersticas. Estes processos so ilustrados na Figura 9. O FDD d mais nfase em diretrizes e tcnicas de gesto de projeto do que os outros mtodos geis [4]. Captulo 2 Os processos de desenvolvimento de software Bruno Junqueira Alves 22
Figura 9. Desenvolvimento guiado por caractersticas [Fonte: retirado de [4]] Desta forma, conclui-se a apresentao dos principais modelos de desenvolvimento de software. No prximo captulo, estes modelos sero comparados entre si, destacando os pontos positivos e negativos de cada um deles. Ou seja, em quais situaes devemos preferir um ou outro modelo. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 23 Captulo 3 Comparao entre metodologias geis e metodologias clssicas 3.1 Introduo Nesse captulo sero detalhadas vantagens das metodologias geis em relao s metodologias clssicas de engenharia de software. Com essa comparao, mostrado o porqu da maior adoo das metodologias geis nas empresas especializadas em desenvolvimento de software a fim de acelerarem a rea de manuteno de sistemas. Com isso, as empresas aumentam a satisfao dos clientes, podendo alcanar maiores ganhos financeiros e de novos clientes. 3.2 Comparativo entre as metodologias A maioria das metodologias geis nada possui de novo [3]. A primeira diferena das metodologias geis para as tradicionais a priorizao das pessoas e no dos documentos. Com isso, as metodologias geis conseguem ser mais dinmicas s mudanas de requisitos, pelo fato de realizarem reunies rpidas para definir as solues a serem implementadas. Outras diferenas aparecem no que diz respeito ao incio do projeto, planejamento, execuo, controle e encerramento do mesmo. Essas diferenas sero apontadas ao longo do captulo, ilustrando as vantagens e desvantagens entre as metodologias. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 24 3.2.1 Incio do projeto Na metodologia tradicional, os objetivos e o escopo devem ser previamente estabelecidos [5]. Aps identificar todos os elementos do sistema, esse escopo inicial do projeto dever descrever todas as principais funes que o sistema dever realizar. Neste momento, tambm sero identificadas solues alternativas e restries tcnicas e administrativas do projeto. A dificuldade encontrada nesse modo de iniciao de projeto se d ao fato que no se pode ter certeza em relao ao custo e ao prazo de concluso do projeto. Prever o tempo que ser gasto para desenvolver as funes sem possuir informaes detalhadas a respeito das atividades torna a atividade complicada. A ideia de especificar totalmente um software antes do incio de sua implementao extremamente difcil [2]. Nas metodologias geis, a iniciao do projeto comea pela identificao dos objetivos do cliente, mapeando suas estrias em elementos do produto [5]. A obteno dos requisitos se d junto ao cliente, escutando suas estrias, a fim de criar seus requisitos de maneira superficial, porm objetivos, atendendo as expectativas do cliente. Esses requisitos so definidos sem muitos detalhes, j que, na metodologia gil, eles podem ser alterados dinamicamente pelo cliente. Outra preocupao em relao aos requisitos se tornarem obsoletos realidade do cliente. A equipe de desenvolvimento precisa estar preparada para tais mudanas. Essa falta de preparo uma das principais causas de falha nos projetos de softwares, portanto uma equipe preparada para as mudanas se torna mais eficiente e menos sujeita a fracassos. Na Figura 10, so destacados os pontos principais de incio de projeto que so considerados pelas duas metodologias. Enquanto a metodologia tradicional prioriza o escopo, o prazo e o custo, sacrificando a qualidade do sistema, o que pode deixar o cliente insatisfeito com a empresa; a metodologia gil tem foco na qualidade, no prazo e no custo. O destaque est na qualidade, que, na metodologia Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 25 gil, no negocivel. O produto sempre deve ter uma boa qualidade para garantir a satisfao do cliente.
Figura 10. Fatores de projeto [Fonte: retirado de [5]] 3.2.2 Planejamento Na fase de planejamento, muitos fatores so considerados: Escopo; Qualidade; Tempo; Riscos; Recursos humanos; Custos. Sero detalhadas as comparaes entre as metodologias geis e tradicionais para cada um desses fatores apresentados, esclarecendo as vantagens e desvantagens entre as mesmas. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 26 3.2.2.1 Escopo No modelo tradicional, a aquisio dos requisitos intensa nessa fase. A equipe de desenvolvimento far entrevistas com o cliente e o usurio final, obtendo todas as informaes a respeito dos processos de negcio, as funes que o software ir realizar. Nessa fase no pode haver erros, como interpretaes errneas e informaes falsas. Isso pode ocasionar o fracasso do projeto. Os resultados obtidos atravs dessas entrevistas, e aps anlise, devero ser documentados para que outros analistas - de prazo, custos e riscos possam us-los para a posterior anlise. Na metodologia gil, ocorre um planejamento superficial dos requisitos, no incio do projeto, com a finalidade de informar a equipe de anlise de requisitos todas as estrias identificadas. Diferentemente da metodologia tradicional, a metodologia gil detalha o escopo a cada iterao no caso do Scrum, a cada Sprint. Essa forma de detalhamento feita sem a obrigatoriedade de documentao, de forma interativa, junto com o cliente. Ao final, percebe-se que o planejamento sai da fase inicial do processo e passa a ser executado a cada iterao, na fase de execuo, ao longo do projeto. 3.2.2.2 Tempo Na metodologia tradicional, o planejamento do tempo baseado na separao das atividades do projeto, desde o incio at a entrega ao cliente, organizando-as numa sequncia coerente e realizando a estimativa de durao. Ainda assim, uma atividade muito complicada, pois no possvel prever precisamente todos os detalhes e quais atividades estaro sendo feitas no futuro. Essas estimativas precisam ser revistas ao longo do projeto, caso apaream novas informaes durante o desenvolvimento. Um detalhe importante no desenvolvimento de sistemas que o principal fator de influncia o ser humano. Ento a estimativa de prazo precisa respeitar os Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 27 aspectos humanos. Por exemplo, caso algum desenvolvedor fique doente, tenha problemas particulares graves, entre outras possibilidades. Por esses motivos, geralmente o gerente de projeto cria estimativas com prazos um pouco maiores para ter algum tempo de folga, caso apaream problemas de fator humano no projeto. Mas deve-se tomar cuidado para que essas estimativas no ultrapassem o prazo de entrega do produto, muitas vezes acordado no incio do projeto. J na metodologia gil, ocorre uma diviso de atividades de acordo com a importncia das mesmas em relao ao cliente. As mais importantes so escolhidas para serem desenvolvidas primeiro ento esses requisitos so divididos em pequenas tarefas que sero desenvolvidas dentro de uma iterao. O sequenciamento de atividades no existe na metodologia gil [5]. Nessa metodologia, diferentemente da metodologia tradicional, no feito um planejamento de todas as atividades que sero executadas no projeto. O planejamento feito de forma dinmica ao longo da iterao. Em casos onde as empresas que adotam a metodologia gil para a parte de desenvolvimento, mas que se envolvem em negcios onde preciso exibir os custos antecipadamente, por exemplo, numa licitao, ocorre um uso de metodologias hbridas. Nesses casos, comum o uso de metodologia tradicional no que se diz respeito documentao do processo e base de custos. Nessas metodologias hbridas, o processo de documentao importante para passar ao cliente as estimativas de preo e custo, a fim de que o mesmo aprove ou realize eventuais revises. 3.2.2.3 Qualidade Na metodologia tradicional, o plano de qualidade feito pela equipe de gerncia de qualidade do projeto. Nesse plano esto listados os atributos de qualidade do projeto. Entre esses atributos esto: segurana, confiabilidade, modularidade, portabilidade, facilidade de uso e outros. Dependendo da finalidade do software, o seu desenvolvimento ser executado de acordo com a ordem de importncia dos atributos. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 28 necessrio definir a importncia de cada atributo, evitando que a equipe de desenvolvimento utilize fora mais que necessria para executar o projeto. Entende-se fora mais que necessria como tecnologias que no precisam estar no projeto. Tambm considerado um atributo de qualidade de software a conformidade das funes do mesmo com as necessidades do cliente. Mesmo que o software preencha vrios atributos como segurana, confiabilidade e modularidade, um software que no atende as necessidades do cliente considerado de m qualidade. Na metodologia gil, o planejamento de qualidade, mais uma vez, deixa de ser feito no incio do projeto, o que levaria previso de aes num futuro distante e passa a ser feito iterativamente, durante o desenvolvimento, visando aproximao com as necessidades do cliente. Nessa metodologia, cada requisito, e no atributos de qualidade, avaliado quanto sua importncia. a chamada avaliao externa do produto, feita pelo cliente, que ter por finalidade obter do cliente as caractersticas que mais lhe interessam. Existe tambm a qualidade interna do software. Esta anlise feita pela equipe de desenvolvimento do software. Nesse tipo de qualidade, so vistos os aspectos de como o software deve ser desenvolvido, quais tcnicas e qual o prazo para a entrega do mesmo. A qualidade interna deve ser discutida entre o cliente, geralmente os responsveis pela rea de T.I. do cliente, e os desenvolvedores durante o planejamento de cada iterao. O cliente pode interferir no aspecto de segurana e portabilidade, a fim de atender s suas necessidades, mas quanto ao prazo, isso fica exclusivamente sob responsabilidade dos desenvolvedores. O prazo dito com atributo no negocivel. Nesse ponto, destaca-se a observao de que as metodologias tradicionais usam o controle para medir a qualidade do desenvolvimento. J as metodologias geis usam uma abordagem com foco na qualidade durante o desenvolvimento. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 29 3.2.2.4 Riscos Os riscos, dentro da metodologia tradicional, so identificados e as suas solues ser incorporadas ao plano de projeto. Em muitos casos, uma equipe de desenvolvimento tem capacidade de identificar os riscos durante o perodo inicial do desenvolvimento, mas prever riscos que podero acontecer ao longo dos anos uma tarefa extremamente complicada. Na metodologia gil, para diminuir riscos de desenvolvimento, o cliente comea a fazer parte da equipe de trabalho. Ele ajudar nos problemas relacionados ao escopo do projeto, pois, com suas estrias, o especialista pode identificar um risco grande, trazendo sua soluo j para o incio do projeto. Nas metodologias geis, no se faz uso de documentos contendo um plano formal de gerncia de riscos. Esses riscos so abordados atravs das reunies dirias realizadas pela equipe de desenvolvimento. 3.2.2.5 Recursos Humanos As pessoas que iro trabalhar na equipe de desenvolvimento do software sero contratadas pela equipe de gerncia de recursos humanos. desejvel que sejam contratadas pessoas com grande experincia e possuam conhecimentos apropriados para o projeto. Porm, existe a possibilidade do oramento ser limitado, fazendo com que o gerente de recursos humanos contrate pessoas sem muita experincia, mas tambm com pouca remunerao. O problema de contratar pessoas sem muita experincia consiste no aparecimento de pequenos erros ao longo do projeto que podem aumentar os riscos relacionados ao tempo, qualidade e custo do projeto. Grupos de projetos de software no devem ter mais que oito participantes, devido dificuldade de grandes equipes trabalharem de maneira eficaz para resolver um nico problema [7]. Com isso, dividindo a equipe, os problemas de comunicao so diminudos. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 30 Na metodologia tradicional, a equipe tem uma diviso bem clara de funes. Analista de sistemas, programador e testador so os cargos de uma equipe nessa metodologia. Cada um participa exclusivamente da fase de projeto que lhe diz respeito. O uso de pessoas especializadas em uma nica fase do projeto facilita o caso de substituio, utilizando a mo de obra disponvel do mercado. Na metodologia gil, o desenvolvedor exerce todas as funes listadas anteriormente. Com isso, ele pode ser usado em diversas etapas do projeto. O problema que com essa acumulao de funes, os profissionais dessa metodologia precisam ser de alta capacidade, capazes de definir a melhor forma de desenvolvimento e testes. O desenvolvedor, nas metodologias geis multi-capacitado, sendo de difcil substituio. Por outro lado, essas metodologias incentivam o aprimoramento do profissional, tornando-o mais importante dentro de uma equipe. 3.2.2.6 Custos Na metodologia tradicional, os custos j so alocados no incio do projeto, a partir das tarefas designadas s equipes de desenvolvimento e anlises de estimativas. Portanto elaborada uma base de custos que ser acompanhada durante a execuo do projeto com a finalidade de comparar os custos atuais com os custos iniciais. Na metodologia gil, o custo do projeto fixo e s ir variar caso o cliente solicite uma renovao do contrato. Essa renovao est associada ao fato do cliente estar satisfeito com a empresa ou com alguma alterao no escopo de projeto corrente solicitada pelo cliente. A alocao de recursos no feita no incio do projeto e sim, durante a realizao do mesmo, a cada iterao. O desenvolvedor tem a livre escolha para executar as tarefas do projeto em funo do andamento do desenvolvimento. Como ele tem uma viso mais tcnica, o melhor a tomar essa deciso. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 31 3.2.3 Execuo Nas metodologias tradicionais, ao iniciar a execuo de um projeto, deve-se seguir exatamente o que est definido no plano de projeto, definido na fase de planejamento. A equipe de desenvolvedores segue essa documentao e suas equipes so supervisionadas pela equipe de gesto de qualidade de modo que os padres definidos sejam respeitados. As equipes so divididas em funes especficas, como analistas, programadores e testadores. Devido a essa diviso, uma capacitao pode ser usada para desenvolver uma equipe que est apresentando um baixo ndice de produtividade, para no comprometer o prazo de entrega do projeto. Existe tambm um problema com a interao entre os membros da equipe, dificultando a disseminao do conhecimento sobre o projeto e sobre as tecnologias usadas durante a execuo do mesmo. Nas metodologias geis, a execuo do projeto ocorre de forma mais dinmica, onde os requisitos que sero desenvolvidos so discutidos em reunio na fase inicial de cada iterao. Ocorre uma maior integrao entre os membros da equipe, facilitando a comunicao e, com isso, aumentando o conhecimento a respeito do projeto, tornando o profissional mais qualificado para projetos posteriores. 3.2.4 Controle Nas metodologias tradicionais, existe um rgido controle quanto s mudanas no escopo do projeto. Qualquer alterao reflete como um risco a todo o projeto, exigindo uma anlise de impacto em todas as reas que sero afetadas. Quanto ao controle do tempo, existe um cronograma a ser seguido e tradicionalmente usado o grfico de Gantt como referncia para saber se o desenvolvimento do projeto est obedecendo ao tempo previsto no planejamento inicial. Os custos do projeto so monitorados atravs da equipe de gerncia de custos, a qual faz uma comparao com a linha de base de custos do projeto. Uma no conformidade dos custos pode trazer a falta dos mesmos para a execuo do resto do projeto, implicando at em sua paralisao para novas negociaes. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 32 Por fim, a qualidade controlada com o uso de documentao peridica, escrita pela equipe de gerncia de qualidade. Caso existam no conformidades, a equipe gera um relatrio que ser enviado s reas responsveis a fim de sanar os problemas. Na metodologia gil, no existe um controle rgido sobre o escopo. As mudanas ficam a cargo do cliente. Essas mudanas so vistas como algo positivo, pois trazem mais aprendizado equipe de desenvolvimento. No Scrum, por exemplo, o controle do tempo se d com o auxlio de um grfico, chamado Burndown. Esse grfico apresenta quais requisitos foram concludos e se o tempo de execuo est obedecendo ao estipulado na reunio inicial da iterao. Caso um requisito leve mais tempo que o necessrio, os outros membros da equipe realizam um maior esforo, de modo que esse requisito seja finalizado dentro dessa interao. Nessa metodologia, no existe um controle rgido dos custos, pois com as mudanas de escopo definidas pelo cliente, esses custos podem tanto aumentar como diminuir. Ficar a cargo do cliente a gerncia dos custos, pois este est participando ativamente da equipe de desenvolvimento. Em alguns casos, os clientes no querem pagar mais do que j foi estipulado no incio do projeto, como nos casos de uso hbrido de metodologias. Nessas circunstncias, a estimativa de tempo no pode ter muitos erros, para no ocasionar altos custos ao cliente. Existem ainda casos, como quando o sistema precisa de uma correo, onde a empresa assume os custos para que o cliente no se sinta insatisfeito com a empresa. 3.2.5 Encerramento Nas metodologias tradicionais, no momento de encerramento de um projeto, os participantes sero informados atravs de um documento formal. Sero mostrados os indicadores de desempenho e de qualidade medidos durante a execuo do projeto, e essas informaes sero levadas aos responsveis pelo patrocnio do mesmo. Captulo 3 Comparao entre as metodologias geis e metodologias clssicas Bruno Junqueira Alves 33 J na metodologia gil, ser feita uma reunio, onde sero discutidos os erros e acertos ocorridos durante o projeto. Esta definida com reunio de retrospectiva, no caso do Scrum. Essa reunio tem como objetivo fortalecer o aprendizado entre os membros da equipe. Tambm importante a participao do cliente para elevar a moral da equipe, comemorando a entrega do projeto. Normalmente, no so gerados documentos de entrega ao final do projeto. Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide Bruno Junqueira Alves 34 Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide Nesse captulo, ser demonstrado como o uso de metodologias geis ajudou o desenvolvimento em uma software house de modo que a alta demanda dos clientes fosse suprida. Essas metodologias tambm ajudaram na gerncia de uma maior quantidade de pessoas que foram contratadas para as equipes de desenvolvimento. A seguir ser feita uma apresentao da empresa Procenge e o sistema estudado, o Pirmide. Aps essa apresentao, sero sintetizadas as opinies dos especialistas da rea de qualidade de software, como tambm a opinio de profissionais que antes trabalhavam usando somente a metodologia tradicional na rea de manuteno e passaram a utilizar a metodologia gil, especificamente o Scrum, para terem maior rendimento na produtividade. 4.1 A Procenge A Procenge surgiu h 40 anos com o propsito de desenvolver sistemas de gesto administrativa e de apoio tomada de decises. Est instalada no Porto Digital do Recife desde 1998. Nesses anos de sua histria, desenvolveu parcerias com empresas privadas e pblicas. Atualmente o maior foco da Procenge est nos setores de saneamento, sucroenergtico (usinas de cana-de-acar), sade e gs. Desde 2002, a Procenge passou a adotar normas exigidas pelas certificaes de qualidade. Com isso, implantou o SGP Sistema de Gesto Procenge, que redefiniu as orientaes estratgicas com definies de processos, prticas e aplicao de recursos. Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide Bruno Junqueira Alves 35 Aps essa reestruturao na sua gesto, a Procenge foi certificada com os selos de qualidade ISO 9001:2008, CMMI nvel 2 e MPS.Br nvel F. O sistema de gesto passa por revises peridicas, adaptando-se s mudanas exigidas por essas instituies de qualidade. 4.2 O Pirmide O sistema Pirmide o principal produto da Procenge. Esse sistema proporciona que os diretores e gerentes obtenham todas as informaes necessrias ao funcionamento da empresa de modo interligado. Oferecendo, assim, agilidade e transparncia nos processos de gesto administrativa, do financeiro ao setor de compras, do fiscal ao estoque. Por ser constitudo de vrios mdulos, a manuteno do sistema se tornou muito difcil de ser gerido por apenas um gerente de projeto. O Pirmide uma soluo ERP (Enterprise Resource Planning) que se aplica a empresas de todos os setores da economia. Ele incorpora aos seus mdulos aspectos fundamentais da gesto empresarial, valorizando a integrao de dados e flexibilidade de adaptao a empresas dos mais variados segmentos. O software automatiza e integra os processos de diversas reas da organizao, tais como: contabilidade, controladoria, financeira, suprimentos, produo, comercial, logstica e RH, facilitando o fluxo de informaes entre elas. 4.3 Estudo de caso O caso estudado foi como a incorporao da metodologia gil no processo de manuteno e evoluo do Pirmide ajudou as equipes de desenvolvimento a terem maior produtividade e aquisio de conhecimento tcnico e de negcios, tornando-se mais especializados. Anteriormente, usando somente a metodologia tradicional, especificamente a metodologia em cascata, toda a rea de manuteno era gerida a partir de documentos de especificao e implementao. A fbrica do Pirmide conseguia Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide Bruno Junqueira Alves 36 suprir a demanda dos clientes no que diz respeito s correes e novas funcionalidades, mas o tempo de desenvolvimento estava se tornando alto, justamente pelo alto uso de documentao de projeto, principalmente na especificao dos requisitos e na implementao. A partir de ento, comeou a ser adotado um sistema de gesto, onde todos os procedimentos de atendimento do Pirmide foram mapeados, documentados e organizados. A esse sistema foi dado o nome de SGP Sistema de Gesto Procenge. A Figura 11 ilustra de modo geral como composto o sistema. Figura 11. Sistema de Gesto procenge [Fonte: Intranet Procenge] O SGP contm todos os procedimentos os quais os profissionais contratados pela Procenge devem tomar como referncia para o desenvolvimento do Pirmide. O sistema est estruturado conforme as normas da ISO 9001. No topo dessa estrutura de documentao est o manual da qualidade, que um documento estratgico da organizao, e que apresenta o modelo de gesto da empresa. Neste esto contemplados a poltica e os objetivos da qualidade, as autoridades e responsabilidades, o comprometimento da alta direo, o escopo, os indicadores de acompanhamento de objetivos e processos e o mapeamento dos processos do SGP, assim como referncias aos procedimentos que orientam a operacionalizao desses processos. Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide Bruno Junqueira Alves 37 Aps a criao desse sistema, a gerncia de qualidade tomou a deciso de incorporar a metodologia gil, especificamente o Scrum, no processo de manuteno e evoluo do Pirmide. A partir do uso de metodologia gil, o tempo entre receber a solicitao de mudana do cliente e a entrega da verso final diminuiu. Em termos de medio, uma mudana que levaria duas semanas para ser entregue usando a metodologia em cascata, est sendo entregue em uma semana; pois, com as reunies de planejamento feitas no comeo de cada iterao (Sprint) o entendimento fica mais disseminado entre os membros da equipe. O software tambm se tornou mais robusto e confivel com o uso do Scrum, pois todos os membros da equipe adquirem maior conhecimento para realizar os testes necessrios identificao de bugs. Outra vantagem trazida pelo Scrum fbrica foi a descentralizao da gerncia de projetos. O acompanhamento comeou a ser feito pelos Scrum Masters; assim, o gerente de projetos deixou de acompanhar cada desenvolvedor individualmente. Ele agora acompanha as equipes, que passaram a distribuir o escopo de maneira interna, tornando-as auto gerenciveis, o que aumentou a responsabilidade dos membros. Por ltimo, houve tambm a disseminao do conhecimento de negcio do Pirmide entre os membros da equipe. Hoje no somente a pessoa que ir desenvolver uma solicitao que deve entender o que foi pedido, mas todos na equipe de desenvolvimento devem entender, caso seja necessrio ajudar na entrega desse pedido em um tempo mais curto do que foi inicialmente estimado. O que ocorre nesse projeto , na verdade, uma hibridizao de metodologias. O processo se inicia com uma solicitao do cliente empresa referente a uma modificao que se queira realizar no software. Ento, esse pedido encaminhado ao especialista de produto, que um profissional com alto conhecimento de prticas de mercado, para que ele encontre uma soluo que obedea aos padres do sistema. Captulo 4 Estudo de caso Sistema de Gesto Empresarial Pirmide Bruno Junqueira Alves 38 Aps essa soluo ter sido documentada num documento de requisitos tradicional, a mesma encaminhada ao analista de sistemas responsvel pela rea do sistema em que essa soluo far parte. Este ento faz a estimativa de tempo e esforo, a qual indicar os valores a serem cobrados pela Procenge ao cliente. Somente aps a validao dessa documentao de estimativa e custos pelo cliente, que a metodologia gil comea a ser usada. Com o Scrum, essas requisies de cliente validadas ficam dentro do backlog de produto, no qual so organizados em ordem de prioridade, definida pela Procenge. Ao incio de uma Sprint, essas requisies so discutidas e implementadas pela equipe de desenvolvimento. No momento da entrega, os detalhes da soluo so documentados para uma posterior consulta de outros clientes e desenvolvedores. A cada dois meses, um documento redigido com todos os indicadores de qualidade e produtividade para ser mostrado aos gestores da Procenge. Existem tambm documentos com instrues relativas manuteno da qualidade de todo o processo, que todos os membros da equipe devem seguir. O apoio do Scrum, junto prtica das metodologias tradicionais, proporcionou, segundo os profissionais de qualidade e de desenvolvimento, maiores ndices de satisfao dos clientes, melhores ndices de produtividade das equipes e maior qualidade ao software. Tornando-o, portanto, mais confivel. Captulo 5 Concluses e trabalhos futuros Bruno Junqueira Alves 39 Captulo 5 Concluses e trabalhos futuros A partir do estudo feito, conclui-se que o uso das metodologias tradicionais est cedendo seu espao, pelo menos nas reas de manuteno de sistemas, s metodologias geis devido sua alta burocracia, que exige todo o planejamento j na fase inicial do projeto. J a metodologia gil, chega para tornar o ambiente de desenvolvimento de softwares mais produtivo e dinmico, ajudando s empresas a conquistarem mais clientes e trazendo mais qualidade aos seus produtos. Nas metodologias geis, os profissionais tornam-se mais especializados, ao passo que eles precisam ter conhecimento de anlise, programao e testes. Com isso, as empresas encontram dificuldades em contratar pessoas com grandes nveis de conhecimento. preciso tambm levar em conta que, dependendo do projeto, se torna necessria uma equipe relativamente grande para o desenvolvimento do sistema. No caso do Pirmide, alguns mdulos possuem mais profissionais que outros, devido ao seu uso ser mais intenso nos clientes. Com o uso de metodologias tradicionais, no final de um projeto, o sistema pode ficar defasado em relao aos requisitos do cliente, caso as necessidades do negcio do cliente mudem com o tempo. Nas metodologias geis, o desenvolvimento do sistema acompanha as atualizaes nos processos da empresa solicitante. As metodologias geis oferecem uma abordagem com foco maior na qualidade, diferentemente das metodologias tradicionais. As metodologias geis procuram sempre validar com o cliente quais so os requisitos mais importantes a serem desenvolvidos, garantindo maior qualidade e satisfao dos clientes. No futuro, a ideia seria trabalhar algumas limitaes das metodologias geis, como a falta de anlise de riscos, que ainda um ponto mais tratado pelas metodologias tradicionais. Sem essa anlise mais profunda, um risco de grandes Captulo 5 Concluses e trabalhos futuros Bruno Junqueira Alves 40 propores, que no foi visto anteriormente, pode aparecer j na fase de entrega do projeto, causando um atraso, que, por sua vez, pode causar insatisfao do cliente. Ao trabalhar nesse ponto, as metodologias geis podem se tornar mais completas e auxiliar o uso de metodologias tradicionais nos projetos mais recentes, possibilitando o aparecimento de processos hbridos de desenvolvimento de sistemas.
Referncias Bruno Junqueira Alves 41 Referncias [1] Agile Manifesto. Disponvel em: http://www.agilemanifesto.org/iso/ptbr/. Acesso em: 20/10/2012. [2] Brooks, F. No Silver Bullet: Essence and Accidents of Software Engineering. Proc. IFIP, IEEE CS Press, pp. 1069-1076; reprinted in IEEE Computer, pp. 10-19, Apr. 1987. [3] Cockburn, A. e Highsmith, J. Agile Software evelopment: The Business of Innovation, IEEE Computer, Sept., pp. 120-122, 2001. [4] Pressman, R. Engenharia de Software. McGraw-Hill, 6 Edio. 2006 [5] Silva, F. L. de Carvalho e da Silva, V. B. Estudo comparativo dos processos de desenvolvimento de software gil e tradicional, sob a tica do guia PMBOK, Trabalho final do curso de ps-graduao em produo de sistemas no Instituto Federal de Educao, Cincia e Tecnologia Fluminense, 2009. [6] Soares, S. M. Comparao entre Metodologias geis e Tradicionais para Desenvolvimento de Software, INFOCOMP Journal of Computer Science, v. 3, n. 2, pp. 08-13, 2004. [7] Sommerville, I. Engenharia de Software. Editora Addison-Wesley. 592p, 2003. [8] Marina Martinez. RUP. Disponvel em: http://www.infoescola.com/engenharia- de-software/rup/. Acesso em 15 de dez. 2012. [9] Guia on-line do RUP. Disponvel em: http://www.wthreex.com/rup/portugues/index.htm. Acesso em 15 de dez. 2012. [10] Best Practices for Development Teams. Disponvel em: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_ bestpractices_TP026B.pdf. Acesso em: 15 de dez. 2012