Bruno Junqueira Alves
Contents
1. e Ter o sistema funcionando a melhor medida de progresso e Processos geis promovem o desenvolvimento sustent vel e Aten o cont nua excel ncia t cnica e a um bom design aumenta a agilidade e Simplicidade essencial e As melhores arquiteturas requisitos e projetos prov m de equipes organizadas e Em intervalos regulares a equipe deve refletir sobre como se tornar mais eficaz Com base nesses princ pios 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 m todos Scrum Extreme Programming e outros 6 estabeleceram os princ pios comuns anteriormente listados compartilhados por esses m todos Os processos geis mais conhecidos s o os seguintes e 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 pr ticas a fim de garantir a qualidade do software produzido gt Planejamento O cliente descreve suas atividades que ser o absorvidas pelo software conhecidas como est rias do usu rio O cliente ent o atribui um valor a essas est rias que definem as prioridades das funcionalidades do sistema A equipe XP ent o2. e UPE POLI fd comp POLE Engenharia de computacao GRADUA O Estudo Comparativo entre M todos geis e Tradicionais de Fabrica o de Software Trabalho de Conclus o de Curso Engenharia da Computa o Bruno Junqueira Alves Orientador Prof S rgio Murilo Maciel Fernandes UNIVERSIDADE DE PERNAMBUCO Universidade de Pernambuco Escola Polit cnica de Pernambuco Gradua o em Engenharia de Computa o Bruno Junqueira Alves Estudo Comparativo entre M todos Ageis e Tradicionais de Fabrica o de Software Monografia apresentada como requisito parcial para obten o do diploma de Bacharel em Engenharia de Computa o pela Escola Polit cnica de Pernambuco Universidade de Pernambuco Recife Agosto 2012 De acordo Recife Orientador da Monografia Dedico esse trabalho a todos que me deram o apoio necess rio minha familia meu orientador e amigo S rgio Murilo e principalmente Deus Resumo Nesse trabalho foi feita uma pesquisa a respeito dos atuais m todos de fabrica o de software utilizados pelas principais software houses do mundo Tamb m foram citados m todos usados no in cio da moderniza o dos processos de desenvolvimento Atrav s de entrevistas com especialistas na rea leitura especializada e um estudo de caso foi poss vel chegar a uma compara o concisa entre os existentes m todos de constru o de software Abstract In this study a survey was made about the cu
3. pida 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 pr xima reuni o r pida stand up meeting que acontece no dia seguinte preferivelmente sempre no mesmo hor rio Bruno Junqueira Alves 20 Capitulo 2 Os processos de desenvolvimento de software No final da Sprint uma vers o de demonstra o com as fun es definidas no in cio apresentada ao cliente e o mesmo realiza a avalia o Com o SCRUM uma equipe de desenvolvimento pode trabalhar de modo que os problemas possam ser previamente vistos ocasionando novas reuni es de projeto para sanar esses problemas tornando o desenvolvimento mais bem sucedido Si acada 24 horas Em gt a a Scrum 15 minutos de reuni o di ria aio Os membros da equipe respondem s quest es b sicas a O que voc fez desde a ltima Registro de Pend ncias reuni o Serum Sprint Pend ncia a Voc tem algum obst culo Caracteristica s itens L 30 dias 3 O que voc vai fazer antes da associcda s expandidos pr xima reuni o ao sprint por equipe Nova funcionalidade demonstrada ao final do sprint Pend ncia de Produtos Caracianielians ERROS do produto desejado pelo cliente Figura 8 Metodologia Scrum Fonte retirado de 4 e FDD Feature Driven Development Desenvolvimento Guiado por Caracteristicas Foi
4. uma modelagem compreensiva de sistemas complexos formando uma base para a implementa o e capturando requisitos com precis o e Verifica o continua 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 e Controle de mudan as O RUP mostra como poss vel controlar monitorar e identificar mudan as 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 r pido de aplica o um modelo de processo focado no curto desenvolvimento O modelo RAD uma adapta o de alta velocidade do modelo cascata no qual o desenvolvimento r pido alcan ado com o uso de uma abordagem de constru o baseada em componentes 4 Esse modelo altamente recomendado para casos de projeto onde as principais funcionalidades podem ser implementadas em menos de tr s meses Cada fun o pode ser tratada por uma equipe RAD diferente no final juntando todas Bruno Junqueira Alves 11 Capitulo 2 Os processos de desenvolvimento de software as fun es em um todo A Figura 5 ilustra bem como acontece um projeto usando metodologia RAD em seu desenvolvimento Equipe n Equipe 1 6
5. 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Etapas da metodologia CASCA sia ni 5 Modelo Incremental POOR DAR ERR RA RENNES RP 7 Vis o geral do RUP rss nas a he ae ee a ls Sila Slate alas a ete 9 Fases de desenvolvimento do RUP 10 Modelo RAD raai eae aaaea ia a a E a loan atadas alada 12 Ciclo da Prototipagem ace ue siloia ts Sos oi oia Red e aid aged o ori dao os lotada RUE ia a 14 O modelo spiral ae RD aai a akada 16 Metodologia Serum innar a E aa 21 Desenvolvimento guiado por caracter sticas ccccceeceeeeeeeeeeeeeeeeeeeees 22 Fatores de projeto sssssssseesseeeseertetrtrrrnrnttssrinnnntrnertrtttnnnnnnnseerrnnen nn 25 Sistema de Gest o procenge area 36 Capitulo 1 Introdu o Cap tulo 1 Introdu o A engenharia de software uma disciplina relativamente nova A ideia de engenharia de software apareceu na d cada de 1960 exatamente em 1968 Nessa poca o hardware passava para um n vel mais avan ado de constru o tornando os computadores capazes de efetuarem tarefas antes impens veis e tornando a fabrica o mais barata Mas ao contr rio dessa facilidade do hardware o software estava ficando mais caro e a entrega com mais atraso Portanto novos m todos eram necess rios para controlar a complexidade de sua fabrica o Ent o foram criados os prim
6. a especifica o dos casos de uso do projeto Tamb m feito um plano de projeto analisando seus riscos delimitando os custos e os prazos e estabelecendo as prioridades e Elabora o realizada a an lise da extens o do sistema Tamb m definida a arquitetura que ser utilizada no sistema Essa arquitetura deve ser est vel e robusta Usando essa arquitetura como guia feita a an lise e o projeto dos casos de uso posteriormente documentados e Constru o O objetivo dessa fase o desenvolvimento de componentes e outros recursos do sistema nessa fase que ocorre a produ o de c digos e os testes alfa para certificar que os casos de uso est o sendo implementados corretamente Devem se aplicar processos de testes est veis Bruno Junqueira Alves 9 Capitulo 2 Os processos de desenvolvimento de software e Transi o O foco nessa fase assegurar que o software esteja dispon vel para seus usu rios finais 9 As atividades nessa fase incluem o treinamento dos usu rios finais e a realiza o dos testes beta do sistema visando que o mesmo tenha os n veis de qualidade adequados P BB i A CONSTRU O y Mi CONCEP O iy fy Vv Vl TRANSI O 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 pr ticas b sicas a serem executadas
7. a participa o do cliente para elevar a moral da equipe comemorando a entrega do projeto Normalmente n o s o gerados documentos de entrega ao final do projeto Bruno Junqueira Alves 33 Cap tulo 4 Estudo de caso Sistema de Gest o Empresarial Pir mide Cap tulo 4 Estudo de caso Sistema de Gest o Empresarial Pir mide Nesse cap tulo 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 tamb m ajudaram na ger ncia de uma maior quantidade de pessoas que foram contratadas para as equipes de desenvolvimento A seguir ser feita uma apresenta o da empresa Procenge e o sistema estudado o Pir mide Ap s essa apresenta o ser o sintetizadas as opini es dos especialistas da rea de qualidade de software como tamb m a opini o de profissionais que antes trabalhavam usando somente a metodologia tradicional na rea de manuten o 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 prop sito de desenvolver sistemas de gest o administrativa e de apoio tomada de decis es Est instalada no Porto Digital do Recife desde 1998 Nesses anos de sua hist ria desenvolveu parcerias com empresas privadas e p blicas Atualmente o maior foco da Procenge est nos setores de
8. concebido como um modelo pratico de processo de engenharia de software orientada a objetos Em seu contexto uma caracteristica seria uma fungao valorizada pelo cliente que poderia ser implementada em duas semanas ou menos Esse m todo se baseia nos seguintes processos desenvolver um modelo global construir uma lista de caracteristicas planejar por caracteristicas projetar e construir por caracteristicas Estes processos sao ilustrados na Figura 9 O FDD da mais nfase em diretrizes e t cnicas de gest o de projeto do que os outros m todos geis 4 Bruno Junqueira Alves 21 Capitulo 2 Os processos de desenvolvimento de software Uma lista de caracter sticas agrupadas em conjuntos e reas de assunto mais forma que conte do Um plano de Um pacote Fun o E desenvolvimento de projeto cliente valor propriet rios do sequencias completada conjunto de desenvolvimento Figura 9 Desenvolvimento guiado por caracter sticas Fonte retirado de 4 Desta forma conclui se a apresenta o dos principais modelos de desenvolvimento de software No pr ximo cap tulo estes modelos ser o comparados entre si destacando os pontos positivos e negativos de cada um deles Ou seja em quais situa es devemos preferir um ou outro modelo Bruno Junqueira Alves 22 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas Cap tulo 3 Compara o e
9. de testes de regress o testar as funcionalidades j implementadas sempre quando o c digo for modificado medida que os testes unit rios s o realizados e organizados numa sequ ncia o teste de integra o pode ser feito diariamente Isso fornece equipe uma vis o de progresso e indica sinais de alerta caso o projeto tenha problemas Ao final s o feitos os testes de aceita o estes feitos pelo cliente que s o testes das est rias do usu rio implementadas numa vers o do sistema e SCRUM Desenvolvido na d cada de 1990 por Jeff Sutherland e sua equipe O nome deriva de uma atividade decorrente do jogo de rugby Esse m todo orienta se por tr s princ pios a visibilidade a inspe o e a adaptabilidade Todos os requisitos devem estar vis veis a todos os envolvidos no desenvolvimento a inspe o deve ser uma a o frequente e consequentemente as a es para adapta o do produto de software devem ser realizadas No SCRUM s o incorporadas as seguintes atividades de desenvolvimento requisitos an lise projeto evolu o e entrega Essas atividades s o reunidas em um padr o de processo chamado Sprint Dentro de uma Sprint o problema do cliente adaptado definido e executado podendo sofrer modifica es durante a Sprint O tempo da Sprint definido pelo respons vel 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 reuni o r
10. durante o projeto e Desenvolver iterativamente Esta pr tica permite que requisitos sejam identificados ou modificados mais facilmente ocorra uma integra o progressiva de elementos ao software ocasionando uma melhora na identifica o dos riscos e Gerenciar requerimentos Prov uma maneira pr tica de produzir organizar e comunicar os requisitos de um projeto O gerenciamento de recursos acarreta um melhor controle sobre projetos complexos 10 e Utilizar arquiteturas baseadas em componentes O processo foca no desenvolvimento inicial de uma arquitetura robusta antes do comprometimento de recursos em larga escala Essa pr tica descreve como projetar uma arquitetura flex vel que suporta mudan as e promove Bruno Junqueira Alves 10 Capitulo 2 Os processos de desenvolvimento de software um reuso de software efetivo O RUP prov uma aproxima o sistem tica para definir uma arquitetura atrav s de componentes novos ou existentes 10 Um componente pode ser definido como um m dulo n o trivial ou um subsistema que cumpre uma fun o clara e 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 n o s a concep o e complexidade do sistema como tamb m dimensionar al m de facilitar a identifica o e a solu o de problemas O RUP atrav s da UML permite
11. flexibilidade de adapta o a empresas dos mais variados segmentos O software automatiza e integra os processos de diversas reas da organiza o tais como contabilidade controladoria financeira suprimentos produ o comercial log stica e RH facilitando o fluxo de informa es entre elas 4 3 Estudo de caso O caso estudado foi como a incorpora o da metodologia gil no processo de manuten o e evolu o do Pir mide ajudou as equipes de desenvolvimento a terem maior produtividade e aquisi o de conhecimento t cnico e de neg cios tornando se mais especializados Anteriormente usando somente a metodologia tradicional especificamente a metodologia em cascata toda a rea de manuten o era gerida a partir de documentos de especifica o e implementa o A f brica do Pir mide conseguia Bruno Junqueira Alves 35 Capitulo 4 Estudo de caso Sistema de Gest o Empresarial Pir mide suprir a demanda dos clientes no que diz respeito s corre es e novas funcionalidades mas o tempo de desenvolvimento estava se tornando alto justamente pelo alto uso de documenta o de projeto principalmente na especifica o dos requisitos e na implementa o A partir de ent o come ou a ser adotado um sistema de gest o onde todos os procedimentos de atendimento do Pir mide foram mapeados documentados e organizados A esse sistema foi dado o nome de SGP Sistema de Gest o Procenge A Figura 11 i
12. o aumento da produtividade seguindo uma abordagem prescritiva O RUP se baseia no paradigma de Orienta o a Objetos e documentado utilizando UML Unified Modeling Language para ilustrar os processos em a o O principal objetivo do RUP atender as necessidades dos usu rios garantindo uma produ o de software de alta qualidade que cumpra um cronograma e um or amento previs veis 8 considerado um processo pesado tradicional por muitos especialistas e preferencialmente aplic vel a grandes equipes de desenvolvimento e a grandes projetos O RUP permite definir quem o respons vel pelo o que deve ser feito como deve ser feito e quando deve ser feito descrevendo todas as metas espec ficas de desenvolvimento para que sejam alcan adas A Figura 3 ilustra de forma geral esse processo Bruno Junqueira Alves 8 Capitulo 2 Os processos de desenvolvimento de software Disciplinas Modelagem de Neg cios Requisitos An lise e Design Implementa o Teste Implanta o Geren de Configura o e Mudan a Gerenciamento de Projeto Ambiente Figura 3 Vis o 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 e Concep o ou Inicia o Essa fase abrange as tarefas de comunica o com o cliente e planejamento Ocorre a identifica o e
13. saneamento sucroenerg tico usinas de cana de a car sa de e g s Desde 2002 a Procenge passou a adotar normas exigidas pelas certifica es de qualidade Com isso implantou o SGP Sistema de Gest o Procenge que redefiniu as orienta es estrat gicas com defini es de processos pr ticas e aplica o de recursos Bruno Junqueira Alves 34 Cap tulo 4 Estudo de caso Sistema de Gest o Empresarial Pir mide Ap s essa reestrutura o na sua gest o a Procenge foi certificada com os selos de qualidade ISO 9001 2008 CMMI n vel 2 e MPS Br n vel F O sistema de gest o passa por revis es peri dicas adaptando se s mudan as exigidas por essas institui es de qualidade 4 2 O Pir mide O sistema Pir mide o principal produto da Procenge Esse sistema proporciona que os diretores e gerentes obtenham todas as informa es necess rias ao funcionamento da empresa de modo interligado Oferecendo assim agilidade e transpar ncia nos processos de gest o administrativa do financeiro ao setor de compras do fiscal ao estoque Por ser constitu do de v rios m dulos a manuten o do sistema se tornou muito dif cil de ser gerido por apenas um gerente de projeto O Pir mide uma solu o ERP Enterprise Resource Planning que se aplica a empresas de todos os setores da economia Ele incorpora aos seus m dulos aspectos fundamentais da gest o empresarial valorizando a integra o de dados e
14. solicita o de mudan a do cliente e a entrega da vers o final diminuiu Em termos de medi o uma mudan a que levaria duas semanas para ser entregue usando a metodologia em cascata est sendo entregue em uma semana pois com as reuni es de planejamento feitas no come o de cada itera o Sprint o entendimento fica mais disseminado entre os membros da equipe O software tamb m se tornou mais robusto e confi vel com o uso do Scrum pois todos os membros da equipe adquirem maior conhecimento para realizar os testes necess rios a identifica o de bugs Outra vantagem trazida pelo Scrum f brica foi a descentraliza o da ger ncia de projetos O acompanhamento come ou 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 gerenci veis o que aumentou a responsabilidade dos membros Por ltimo houve tamb m a dissemina o do conhecimento de neg cio do Pir mide entre os membros da equipe Hoje n o somente a pessoa que ir desenvolver uma solicita o que deve entender o que foi pedido mas todos na equipe de desenvolvimento devem entender caso seja necess rio ajudar na entrega desse pedido em um tempo mais curto do que foi inicialmente estimado z O que ocorre nesse projeto na verdade uma hibridiza o de metodologias O processo se i
15. 0 90 dias Figura 5 Modelo RAD Fonte retirado de 4 As desvantagens desse modelo s o e Necessidade de alto n mero de recursos humanos para desenvolver as fun es em tempo h bil e Comprometimento dos desenvolvedores e clientes e Necessidade de alta modulariza o do sistema o que consome muito tempo de reuni o diminuindo o tempo de desenvolvimento e Devido ao estilo de alta velocidade de desenvolvimento pode n o ser adequado quando existem altos riscos Bruno Junqueira Alves 12 Capitulo 2 Os processos de desenvolvimento de software 2 3 Modelos evolucion rios 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 vers o reduzida mas que atenda todos os requisitos b sicos num prazo curto que permita seu uso pelos clientes A ideia por tr s do desenvolvimento evolucion rio implementar um sistema b sico uma vers o inicial mas que ao passar do tempo outras vers es com funcionalidades mais complexas sejam entregues para completar o projeto A abordagem evolucion ria 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 evolucion rio tem como vantagem o fato
16. arte de desenvolvimento mas que se envolvem em neg cios onde preciso exibir os custos antecipadamente por exemplo numa licita o ocorre um uso de metodologias h bridas Nesses casos comum o uso de metodologia tradicional no que se diz respeito documenta o do processo e base de custos Nessas metodologias h bridas o processo de documenta o importante para passar ao cliente as estimativas de pre o e custo a fim de que o mesmo aprove ou realize eventuais revis es 3 2 2 3 Qualidade Na metodologia tradicional o plano de qualidade feito pela equipe de ger ncia de qualidade do projeto Nesse plano est o listados os atributos de qualidade do projeto Entre esses atributos est o seguran a confiabilidade modularidade portabilidade facilidade de uso e outros Dependendo da finalidade do software o seu desenvolvimento ser executado de acordo com a ordem de import ncia dos atributos Bruno Junqueira Alves 27 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas necess rio definir a import ncia de cada atributo evitando que a equipe de desenvolvimento utilize for a mais que necess ria para executar o projeto Entende se for a mais que necess ria como tecnologias que n o precisam estar no projeto Tamb m considerado um atributo de qualidade de software a conformidade das fun es do mesmo com as necessidades do cliente Mesmo que o software preenc
17. as mudan as se torna mais eficiente e menos sujeita a fracassos Na Figura 10 s o destacados os pontos principais de in cio de projeto que s o 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 Bruno Junqueira Alves 24 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas gil n o negoci vel O produto sempre deve ter uma boa qualidade para garantir a satisfa o do cliente Cl ssico gil Figura 10 Fatores de projeto Fonte retirado de 5 3 2 2 Planejamento Na fase de planejamento muitos fatores s o considerados e Escopo e Qualidade e Tempo e Riscos e Recursos humanos e Custos Ser o detalhadas as compara es entre as metodologias geis e tradicionais para cada um desses fatores apresentados esclarecendo as vantagens e desvantagens entre as mesmas Bruno Junqueira Alves 25 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas 3 2 2 1 Escopo No modelo tradicional a aquisi o dos requisitos intensa nessa fase A equipe de desenvolvimento far entrevistas com o cliente e o usu rio final obtendo todas as informa es a respeito dos proce
18. atribui um custo a cada est ria medido em semanas de desenvolvimento Caso o custo de uma est ria ultrapasse tr s semanas pede se que o cliente divida a est ria original em est rias menores e o processo de atribui o de custos e valor acontece novamente Uma observa o importante novas est rias podem ser escritas a Bruno Junqueira Alves 18 Capitulo 2 Os processos de desenvolvimento de software qualquer momento do processo Uma vez feito um compromisso entre equipe e cliente de quais est rias ir o entrar na vers o do software e a data de entrega dessa vers o a equipe estuda qual o modo seguir Todas as est rias ser o implementadas As est rias de maior prioridade ser o implementadas primeiro As est rias com maior risco ser o implementadas primeiro Ap s a entrega da primeira vers o a equipe calcula a velocidade do projeto de acordo com a quantidade de est rias que foram entregues na primeira vers o Essa medi o ajuda em dois pontos em rela o ao tempo de entrega do sistema e em rela o ao comprometimento esfor o da equipe dentro de uma vers o Se ocorrer um comprometimento excessivo dos profissionais haver uma modifica o no conte do das vers es ou na data de entrega gt Projeto Segue rigorosamente o princ pio KIS keep it simple mantenha a simplicidade Fornece diretrizes de implementa o para uma est ria a partir da maneira como ela foi escrita Se for encon
19. brary content 03July 1000 1251 1251 bestpractices TP026B paf Acesso em 15 de dez 2012 Bruno Junqueira Alves 41
20. da especifica o do sistema ser feita gradativamente medida que o usu rio adquire maior conhecimento em rela o s suas prefer ncias no sistema compreendendo melhor seus problemas isso passa a ser refletido no software Ser o brevemente apresentados dois processos evolucionarios prototipagem modelo espiral 2 3 1 Prototipagem Muitas vezes o cliente n o tem uma clara vis o dos requisitos que lhe interessam ou o desenvolvedor n o tem certeza sobre o uso de um certo algoritmo ou sobre a portabilidade para um sistema operacional ou qual intera o homem m quina o sistema deve assumir Nesses casos o uso da prototipagem se faz muito til Primeiramente o engenheiro de software se re ne com o cliente a fim de delinear os requisitos b sicos do sistema as necessidades conhecidas e requisitos que precisam ser mais bem definidos A seguir o projeto se concentra em entregar um execut vel com todos os requisitos b sicos e uma interface pr xima do ideal O Bruno Junqueira Alves 13 Capitulo 2 Os processos de desenvolvimento de software feedback do cliente vai servir para aprimorar esses requisitos e implementar outros mais complexos tornando o entendimento por parte do desenvolvedor mais f cil A Figura 6 ilustra como o processo de prototipagem acontece dentro do projeto Idealmente o prot tipo serve apenas para identificar os requisitos que est o sendo satisfeitos e como o sistema pode ser apri
21. de Projeto Integra o V amp V e plano de teste Planejar a pr xima fase integra o Teste de aceita o Desenvolver verificar produto de pr ximo n vel Opera o Figura 7 O modelo espiral Fonte retirado de 7 Uma importante diferen a do modelo espiral para ou outros modelos de processo exceto o RUP a expl cita considera o 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 s o encerrados quando o software entregue no modelo em espiral existe uma constante evolu o 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 rea o adequada aos riscos de cada n vel evolucion rio O modelo usa a prototipagem como uma ferramenta de redu o de riscos como exibido na Figura 7 por m pode permitir que a prototipagem seja usada em mais de um est gio da evolu o do produto Bruno Junqueira Alves 16 Capitulo 2 Os processos de desenvolvimento de software Para convencer os clientes de que a abordagem espiral control vel deve se ter uma compet ncia consider vel para avaliar os riscos Caso um risco g
22. dulos 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 rela o aos requisitos do cliente caso as necessidades do neg cio do cliente mudem com o tempo Nas metodologias geis o desenvolvimento do sistema acompanha as atualiza es 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 s o os requisitos mais importantes a serem desenvolvidos garantindo maior qualidade e satisfa o dos clientes No futuro a ideia seria trabalhar algumas limita es das metodologias geis como a falta de an lise de riscos que ainda um ponto mais tratado pelas metodologias tradicionais Sem essa an lise mais profunda um risco de grandes Bruno Junqueira Alves 39 Capitulo 5 Conclus es e trabalhos futuros propor es que n o foi visto anteriormente pode aparecer j na fase de entrega do projeto causando um atraso que por sua vez pode causar insatisfa o 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 h bridos de desenvolvimento de sistemas Bruno Ju
23. e testes O desenvolvedor nas metodologias geis multi capacitado sendo de dif cil substitui o 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 s o alocados no in cio do projeto a partir das tarefas designadas s equipes de desenvolvimento e an lises de estimativas Portanto elaborada uma base de custos que ser acompanhada durante a execu o 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 renova o do contrato Essa renova o est associada ao fato do cliente estar satisfeito com a empresa ou com alguma altera o no escopo de projeto corrente solicitada pelo cliente A aloca o de recursos n o feita no in cio do projeto e sim durante a realiza o do mesmo a cada itera o O desenvolvedor tem a livre escolha para executar as tarefas do projeto em fun o do andamento do desenvolvimento Como ele tem uma vis o mais t cnica o melhor a tomar essa decis o Bruno Junqueira Alves 30 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas 3 2 3 Execu o Nas metodologias tradicionais ao iniciar a execu o de um projeto deve se seguir exatamente o que est definido no plano de projeto def
24. eiros processos de fabrica o de software onde o objetivo era tornar a cria o do software semelhante a um processo industrial a fim de acompanhar o desenvolvimento do hardware das m quinas 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 s o complexos e suas tentativas de automatiza o n o obtiveram sucesso pleno Os primeiros m todos de desenvolvimento possu am orienta o est tica exatamente como uma linha de montagem Com um tempo as empresas come aram a adotar uma postura mais din mica onde as mudan as no c digo n o representam tantos problemas para a adapta o a um cliente espec fico A partir da foram criados os m todos geis cujo foco era nas pessoas e n o nos processos est ticos de desenvolvimento Bruno Junqueira Alves 1 Capitulo 1 Introdu o 1 1 Objetivo Nesse trabalho ser o demonstrados os principais processos de desenvolvimento de software usados nas f bricas de software e tamb m os que deixaram de ser utilizados devido a mudan as nos projetos do software No final ser apresentada uma conclus o a partir de uma compara o entre esses processos 1 2 Estrutura do trabalho No cap tulo 2 ser o apresentados os m todos criados para o aperfei oamento do desenvolvim
25. enciamento Os riscos tamb m s o identificados e dependendo desses riscos estrat gias alternativas s o planejadas e Avalia o e redu o de riscos Ap s os riscos serem identificados uma an lise detalhada dos mesmos feita e provid ncias s o tomadas para reduzi los e Desenvolvimento e valida o Ap s a avalia o dos riscos um modelo de desenvolvimento escolhido para o projeto Por exemplo se o risco principal identificado na fase anterior for a integra o de sistemas o modelo cascata pode ser adotado e Planejamento O projeto revisado para que seja tomada uma decis o a respeito do pr ximo loop da espiral Caso seja decidido continuar novos planos ser o tra ados para o projeto seguindo a mesma metodologia A Figura 7 ilustra como ocorre um desenvolvimento de projeto seguindo o padr o espiral de projeto Observar que a cada nova espiral realizada novos planejamentos s o feitos para o projeto Bruno Junqueira Alves 15 Capitulo 2 Os processos de desenvolvimento de software Determinar objetivos alternativas e restri es Avaliar alternativas identificar resolver riscos An lise de risco An lise de risco SE gt Conceito de opera o Prot tipo operacional Plano de requisitos Plano de ciclo de vida Projeto detalhado Valida o Piano ae de requisito desenvolvimento C digo Teste
26. ento do software desde o in cio da crise durante a d cada de 1960 Na primeira se o deste cap tulo a se o 2 1 ser apresentada a metodologia em cascata Na se o 2 2 ser o apresentados os modelos incrementais de processo Esses modelos se dividem em processo incremental e modelo RAD Na se o seguinte 2 3 ser o detalhados os modelos evolucion rios de processo de software nos quais ser o citados o uso de prototipagem e o modelo espiral Na ltima se o do cap tulo 2 ser detalhado o desenvolvimento gil Nessa se o ser apresentada a sua hist ria e porque esse modelo de processo de desenvolvimento vem sendo mais adotado pelas software houses No cap tulo 3 ser feita a compara o entre os modelos citando suas vantagens e desvantagens em rela o ao planejamento execu o e controle da fabrica o No cap tulo 4 ser mostrado um estudo de caso a partir de uma empresa estabelecida no mercado demonstrando a evolu o e os ganhos da empresa ao utilizar a metodologia de desenvolvimento gil em seu ambiente Bruno Junqueira Alves 2 Capitulo 1 Introdu o O cap tulo 5 e ltimo desse trabalho levantar as conclus es e os trabalhos futuros poss veis a partir desse estudo comparativo de modo que outros interessados realizem mais pesquisas em rela o ao mercado de software houses brasileiro 1 3 Metodologia A metodologia adotada nesse estudo foi a leitura de livro
27. ha v rios atributos como seguran a confiabilidade e modularidade um software que n o atende as necessidades do cliente considerado de m qualidade Na metodologia gil o planejamento de qualidade mais uma vez deixa de ser feito no in cio do projeto o que levaria previs o de a es num futuro distante e passa a ser feito iterativamente durante o desenvolvimento visando aproxima o com as necessidades do cliente Nessa metodologia cada requisito e n o atributos de qualidade avaliado quanto sua import ncia a chamada avalia o externa do produto feita pelo cliente que ter por finalidade obter do cliente as caracter sticas que mais lhe interessam Existe tamb m a qualidade interna do software Esta an lise feita pela equipe de desenvolvimento do software Nesse tipo de qualidade s o vistos os aspectos de como o software deve ser desenvolvido quais t cnicas e qual o prazo para a entrega do mesmo A qualidade interna deve ser discutida entre o cliente geralmente os respons veis pela rea de T l do cliente e os desenvolvedores durante o planejamento de cada itera o O cliente pode interferir no aspecto de seguran a 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 n o negoci vel Nesse ponto destaca se a observa o de que as metodologias tradicionais u
28. idas 4 Integra o e teste de sistemas As unidades de programa ou programas individuais s o integrados e testados como um sistema nico a fim de garantir que todas as especifica es foram atendidas Depois do teste de sistemas o software entregue ao cliente Bruno Junqueira Alves 5 Capitulo 2 Os processos de desenvolvimento de software 5 Opera o e manuten o Normalmente embora n o necessariamente esta a fase mais longa do ciclo de vida 7 O sistema instalado e sua opera o iniciada A manuten o envolve corrigir erros que n o foram descobertos anteriormente em est gios anteriores do ciclo de vida Com isso as implementa es do sistema s o melhoradas e a quantidade de fun es aumentada medida que novas especifica es s o descobertas O maior problema dessa metodologia a sua alta burocracia e inflexibilidade na divis o do processo em fases bem distintas 6 Esses dois fatores levam a um alto n mero de atrasos ou at a cancelamentos de projetos Em rela o 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 s o entregues dentro do prazo e custando o acordado inicialmente possuem qualidade duvidosa pois houve muita press o nos desenvolvedores para cumprir os prazos Hoje em dia o trabalho em software de rit
29. inalizada 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 Bruno Junqueira Alves 4 Capitulo 2 Os processos de desenvolvimento de software DEFINI O DOS REQUISITOS PROJETOS DE SISTEMAS E DE SOFTWARE IMPLEMENTA O E TESTE DE UNIDADES INTEGRA O E TESTE DE SISTEMAS OPERA O E MANUTEN O Figura 1 Etapas da metodologia cascata Fonte retirado de 6 1 Defini o de requisitos As fun es as restri es e os objetivos do sistema s o estabelecidos atrav s de entrevista com usu rios do sistema Ap s isso esses tr s pontos s o definidos em detalhes e servem como uma especifica o 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 identifica o e a descri o das fun es fundamentais do sistema de software e suas rela es 3 Implementa o e teste de unidades Durante esse est gio o projeto de software compreendido como um conjunto de programas ou unidades de programa 4 7 O teste de unidades certifica que as especifica es de cada unidade foram atend
30. inido na fase de planejamento A equipe de desenvolvedores segue essa documenta o e suas equipes s o supervisionadas pela equipe de gest o de qualidade de modo que os padr es definidos sejam respeitados As equipes s o divididas em fun es espec ficas como analistas programadores e testadores Devido a essa divis o uma capacita o pode ser usada para desenvolver uma equipe que est apresentando um baixo ndice de produtividade para n o comprometer o prazo de entrega do projeto Existe tamb m um problema com a intera o entre os membros da equipe dificultando a dissemina o do conhecimento sobre o projeto e sobre as tecnologias usadas durante a execu o do mesmo Nas metodologias geis a execu o do projeto ocorre de forma mais din mica onde os requisitos que ser o desenvolvidos s o discutidos em reuni o na fase inicial de cada itera o Ocorre uma maior integra o entre os membros da equipe facilitando a comunica o 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 r gido controle quanto s mudan as no escopo do projeto Qualquer altera o reflete como um risco a todo o projeto exigindo uma an lise de impacto em todas as reas que ser o afetadas Quanto ao controle do tempo existe um cronograma a ser seguido e tradicionalmente usado o gr fico de Gantt co
31. jeto caso apare am novas informa es durante o desenvolvimento Um detalhe importante no desenvolvimento de sistemas que o principal fator de influ ncia o ser humano Ent o a estimativa de prazo precisa respeitar os Bruno Junqueira Alves 26 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas 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 apare am problemas de fator humano no projeto Mas deve se tomar cuidado para que essas estimativas n o ultrapassem o prazo de entrega do produto muitas vezes acordado no in cio do projeto J na metodologia gil ocorre uma divis o de atividades de acordo com a import ncia das mesmas em rela o ao cliente As mais importantes s o escolhidas para serem desenvolvidas primeiro ent o esses requisitos s o divididos em pequenas tarefas que ser o desenvolvidas dentro de uma itera o O sequenciamento de atividades n o existe na metodologia gil 5 Nessa metodologia diferentemente da metodologia tradicional n o feito um planejamento de todas as atividades que ser o executadas no projeto O planejamento feito de forma din mica ao longo da itera o Em casos onde as empresas que adotam a metodologia gil para a p
32. lementos do sistema esse escopo inicial do projeto dever descrever todas as principais fun es que o sistema dever realizar Neste momento tamb m ser o identificadas solu es alternativas e restri es t cnicas e administrativas do projeto A dificuldade encontrada nesse modo de inicia o de projeto se d ao fato que n o se pode ter certeza em rela o ao custo e ao prazo de conclus o do projeto Prever o tempo que ser gasto para desenvolver as fun es sem possuir informa es detalhadas a respeito das atividades torna a atividade complicada A ideia de especificar totalmente um software antes do in cio de sua implementa o extremamente dif cil 2 Nas metodologias geis a inicia o do projeto come a pela identifica o dos objetivos do cliente mapeando suas est rias em elementos do produto 5 A obten o dos requisitos se d junto ao cliente escutando suas est rias a fim de criar seus requisitos de maneira superficial por m objetivos atendendo as expectativas do cliente Esses requisitos s o definidos sem muitos detalhes j que na metodologia gil eles podem ser alterados dinamicamente pelo cliente Outra preocupa o em rela o aos requisitos se tornarem obsoletos realidade do cliente A equipe de desenvolvimento precisa estar preparada para tais mudan as Essa falta de preparo uma das principais causas de falha nos projetos de softwares portanto uma equipe preparada para
33. lustra de modo geral como composto o sistema Responsabilidade da Dire o Gest o de Medi o An lise alistar Recursos Melhoria CLIENTES 4 CLIENTES e outras partes Requisit Said e outras partes mA Realiza o do K PRODUTO F interessadas nr Produto rss eai po interessadas Figura 11 Sistema de Gest o procenge Fonte Intranet Procenge O SGP cont m todos os procedimentos os quais os profissionais contratados pela Procenge devem tomar como refer ncia para o desenvolvimento do Pir mide O sistema est estruturado conforme as normas da ISO 9001 No topo dessa estrutura de documenta o est o manual da qualidade que um documento estrat gico da organiza o e que apresenta o modelo de gest o da empresa Neste est o contemplados a pol tica e os objetivos da qualidade as autoridades e responsabilidades o comprometimento da alta dire o o escopo os indicadores de acompanhamento de objetivos e processos e o mapeamento dos processos do SGP assim como refer ncias aos procedimentos que orientam a operacionaliza o desses processos Bruno Junqueira Alves 36 Cap tulo 4 Estudo de caso Sistema de Gest o Empresarial Pir mide Ap s a cria o desse sistema a ger ncia de qualidade tomou a decis o de incorporar a metodologia gil especificamente o Scrum no processo de manuten o e evolu o do Pir mide A partir do uso de metodologia gil o tempo entre receber a
34. mo r pido e com grande quantidade de pedidos de modifica es Com isso o modelo cascata inadequado para esse tipo de trabalho O modelo pode ser til em projetos onde os requisitos s o fixos e o trabalho deve seguir de modo linear 2 2 Modelos incrementais de processo H situa es em que os requisitos iniciais do software s o razoavelmente definidos mas o escopo global do esfor o de desenvolvimento elimina um processo puramente linear Al m disso pode haver a necessidade de fornecer um conjunto limitado de funcionalidades do software aos usu rios e depois refinar e expandir aquela funcionalidade em vers es posteriores do software Em tais casos o processo de desenvolver o software incrementalmente escolhido 4 Bruno Junqueira Alves 6 Capitulo 2 Os processos de desenvolvimento de software 2 2 1 O modelo Incremental O modelo incremental possui elementos do modelo cascata que aplicado de maneira iterativa 4 No modelo incremental s o aplicadas sequ ncias lineares de uma forma racional medida que o tempo passa como mostrado na Figura 2 Cada sequ ncia linear produz incrementos do software pass veis de serem entregues Comunica o 9 ku 2 F Planejamento 8 Modelagem an lise projeto o incremento n Vu Constru o c digo teste M y E 4 Implanta o entrega feedback E ape 5 e entrega do 5 incremento 2 n incremento W o Q ol en
35. mo refer ncia para saber se o desenvolvimento do projeto est obedecendo ao tempo previsto no planejamento inicial Os custos do projeto s o monitorados atrav s da equipe de ger ncia de custos a qual faz uma compara o com a linha de base de custos do projeto Uma n o conformidade dos custos pode trazer a falta dos mesmos para a execu o do resto do projeto implicando at em sua paralisa o para novas negocia es Bruno Junqueira Alves 31 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas Por fim a qualidade controlada com o uso de documenta o peri dica escrita pela equipe de ger ncia de qualidade Caso existam n o conformidades a equipe gera um relat rio que ser enviado s reas respons veis a fim de sanar os problemas Na metodologia gil n o existe um controle r gido sobre o escopo As mudan as ficam a cargo do cliente Essas mudan as s o vistas como algo positivo pois trazem mais aprendizado equipe de desenvolvimento No Scrum por exemplo o controle do tempo se d com o aux lio de um gr fico chamado Burndown Esse gr fico apresenta quais requisitos foram conclu dos e se o tempo de execu o est obedecendo ao estipulado na reuni o inicial da itera o Caso um requisito leve mais tempo que o necess rio os outros membros da equipe realizam um maior esfor o de modo que esse requisito seja finalizado dentro dessa intera o Nessa metodol
36. morado Mas muitos clientes usam esse prot tipo inicial como se fosse o execut vel final ao perceberem que n o o produto final eles reclamam e exigem consertos ao inv s de esperarem por uma nova vers o mais refinada do sistema com mais qualidade e robustez Modelagem Projeto r pido Comunica o implanta o Enhegae Feedback E Constru o do prot tipo 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 in cio 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 inv s de representar o Bruno Junqueira Alves 14 Capitulo 2 Os processos de desenvolvimento de software processo como uma sequ ncia de atividades cujo retorno essencial para iniciar a pr xima atividade o modelo representado como uma espiral Cada loop da espiral divido em quatro setores e Defini o de objetivos S o definidos os objetivos espec ficos do projeto Tamb m s o identificadas as restri es para o processo e o produto e preparado um plano de ger
37. nicia com uma solicita o do cliente empresa referente a uma modifica o que se queira realizar no software Ent o esse pedido encaminhado ao especialista de produto que um profissional com alto conhecimento de pr ticas de mercado para que ele encontre uma solu o que obede a aos padr es do sistema Bruno Junqueira Alves 37 Cap tulo 4 Estudo de caso Sistema de Gest o Empresarial Pir mide Ap s essa solu o ter sido documentada num documento de requisitos tradicional a mesma encaminhada ao analista de sistemas respons vel pela rea do sistema em que essa solu o far parte Este ent o faz a estimativa de tempo e esfor o a qual indicar os valores a serem cobrados pela Procenge ao cliente Somente ap s a valida o dessa documenta o de estimativa e custos pelo cliente que a metodologia gil come a a ser usada Com o Scrum essas requisi es de cliente validadas ficam dentro do backlog de produto no qual s o organizados em ordem de prioridade definida pela Procenge Ao in cio de uma Sprint essas requisi es s o discutidas e implementadas pela equipe de desenvolvimento No momento da entrega os detalhes da solu o s o 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 tamb m documentos com in
38. nqueira Alves 40 Refer ncias Refer ncias 1 Agile Manifesto Dispon vel 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 Edi o 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 p s gradua o em produ o de sistemas no Instituto Federal de Educa o Ci ncia e Tecnologia Fluminense 2009 6 Soares S M Compara o entre Metodologias geis e Tradicionais para Desenvolvimento de Software INFOCOMP Journal of Computer Science v 3 n 2 pp 08 13 2004 7 Sommerville Engenharia de Software Editora Addison Wesley 592p 2003 8 Marina Martinez RUP Dispon vel em http www infoescola com engenharia de software rup Acesso em 15 de dez 2012 9 Guia on line do RUP Dispon vel em http www wthreex com rup portugues index htm Acesso em 15 de dez 2012 10 Best Practices for Development Teams Dispon vel em http www ibm com developerworks rational li
39. ntre metodologias geis e metodologias cl ssicas 3 1 Introdu o Nesse cap tulo ser o detalhadas vantagens das metodologias geis em rela o s metodologias cl ssicas de engenharia de software Com essa compara o mostrado o porqu da maior ado o das metodologias geis nas empresas especializadas em desenvolvimento de software a fim de acelerarem a rea de manuten o de sistemas Com isso as empresas aumentam a satisfa o dos clientes podendo alcan ar 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 diferen a das metodologias geis para as tradicionais a prioriza o das pessoas e n o dos documentos Com isso as metodologias geis conseguem ser mais din micas s mudan as de requisitos pelo fato de realizarem reuni es r pidas para definir as solu es a serem implementadas Outras diferen as aparecem no que diz respeito ao in cio do projeto planejamento execu o controle e encerramento do mesmo Essas diferen as ser o apontadas ao longo do cap tulo ilustrando as vantagens e desvantagens entre as metodologias Bruno Junqueira Alves 23 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas 3 2 1 In cio do projeto Na metodologia tradicional os objetivos e o escopo devem ser previamente estabelecidos 5 Ap s identificar todos os e
40. ogia n o existe um controle r gido dos custos pois com as mudan as de escopo definidas pelo cliente esses custos podem tanto aumentar como diminuir Ficar a cargo do cliente a ger ncia dos custos pois este est participando ativamente da equipe de desenvolvimento Em alguns casos os clientes n o querem pagar mais do que j foi estipulado no in cio do projeto como nos casos de uso h brido de metodologias Nessas circunst ncias a estimativa de tempo n o pode ter muitos erros para n o ocasionar altos custos ao cliente Existem ainda casos como quando o sistema precisa de uma corre o onde a empresa assume os custos para que o cliente n o se sinta insatisfeito com a empresa 3 2 5 Encerramento Nas metodologias tradicionais no momento de encerramento de um projeto os participantes ser o informados atrav s de um documento formal Ser o mostrados os indicadores de desempenho e de qualidade medidos durante a execu o do projeto e essas informa es ser o levadas aos respons veis pelo patroc nio do mesmo Bruno Junqueira Alves 32 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas J na metodologia gil ser feita uma reuni o onde ser o discutidos os erros e acertos ocorridos durante o projeto Esta definida com reuni o de retrospectiva no caso do Scrum Essa reuni o tem como objetivo fortalecer o aprendizado entre os membros da equipe Tamb m importante
41. ossibilidade do or amento ser limitado fazendo com que o gerente de recursos humanos contrate pessoas sem muita experi ncia mas tamb m com pouca remunera o O problema de contratar pessoas sem muita experi ncia 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 n o 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 comunica o s o diminu dos Bruno Junqueira Alves 29 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas Na metodologia tradicional a equipe tem uma divis o bem clara de fun es Analista de sistemas programador e testador s o 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 substitui o utilizando a m o de obra dispon vel do mercado Na metodologia gil o desenvolvedor exerce todas as fun es listadas anteriormente Com isso ele pode ser usado em diversas etapas do projeto O problema que com essa acumula o de fun es os profissionais dessa metodologia precisam ser de alta capacidade capazes de definir a melhor forma de desenvolvimento
42. rave n o seja identificado no in cio certamente ocorrer o problemas 2 4 Desenvolvimento gil A partir da d cada de 90 come aram a surgir novos m todos sugerindo uma abordagem de desenvolvimento gil onde os processos adotados tentam se adaptar as mudan as apoiando a equipe de desenvolvimento no seu trabalho Os m todos geis caracterizam se pelo seu car ter adaptativo e orientado a pessoas As abordagens geis compartilham na sua ess ncia o processo de desenvolvimento centrado nas pessoas orientado obten o de artefatos a partir de itera es o que consequentemente imp e o car ter adaptativo durante todo o ciclo de desenvolvimento No in cio da primeira d cada de 2000 um grupo de especialistas formulou um conjunto de princ pios que definem a metodologia gil 1 Estes s o os seguintes eA prioridade satisfazer o cliente atrav s de entregas cont nuas e frequentes e Receber bem as mudan as de requisitos mesmo em uma fase avan ada do projeto e Entregas com frequ ncia sempre na menor escala de tempo e As equipes de neg cio e de desenvolvimento devem trabalhar juntas diariamente e Manter uma equipe motivada fornecendo ambiente apoio e confian a necess rios e A maneira mais eficiente da informa o circular dentro do time de desenvolvimento atrav s de uma conversa presencial Bruno Junqueira Alves 17 Capitulo 2 Os processos de desenvolvimento de software
43. rrent 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 vi Sumario Cap tulo 1 Introdu o 1 1 Objetivo 1 2 Estrutura do trabalho 1 3 Metodologia Cap tulo 2 Os processos de desenvolvimento de software 2 1 Modelo cascata 2 2 Modelos incrementais de processo 2 2 1 O modelo Incremental 2 2 1 1 RUP Rational Unified Process 2 2 2 O modelo RAD 2 3 Modelos evolucion rios de software 2 3 1 Prototipagem 2 3 2 Modelo espiral 2 4 Desenvolvimento gil Cap tulo 3 Compara o entre metodologias geis e metodologias cl ssicas 3 1 Introdu o 3 2 Comparativo entre as metodologias 3 2 1 In cio do projeto 23 23 23 24 vii 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 Execu o 31 3 2 4 Controle 31 3 2 5 Encerramento 32 Cap tulo 4 Estudo de caso Sistema de Gest o Empresarial Pir mide 34 4 1 A Procenge 34 4 2 O Pir mide 35 4 3 Estudo de caso 35 Cap tulo 5 Conclus es e trabalhos futuros 39 Refer ncias 41 vili Lista de Figuras Figura
44. s artigos e trabalhos especializados na rea de desenvolvimento de software junto com entrevistas com profissionais que trabalham na rea de desenvolvimento e ger ncia de qualidade de software Bruno Junqueira Alves 3 Capitulo 2 Os processos de desenvolvimento de software Cap tulo 2 Os processos de desenvolvimento de software O processo de desenvolvimento de software pode ser definido como uma cole o de padr es que definem um conjunto de atividades a es tarefas de trabalho produtos de trabalho e ou comportamentos relacionados e necess rios ao desenvolvimento de software de computador Pela combina o de padr es uma equipe de software pode definir um processo que melhor satisfa a s necessidades de um projeto Nesse cap tulo ser o apresentados os principais m todos conhecidos de desenvolvimento de software de modo que se possa ter um entendimento para a compara o desses m todos 2 1 Modelo cascata Existem ocasi es onde todos os requisitos de um sistema s o bem compreendidos O sistema a ser constru do n o precisa passar por muitas adapta es ou evolu es aperfei oamentos tornando sua implementa o linear O modelo cascata ou cl ssico foi a primeira metodologia de desenvolvimento de software apresentada Ela usa uma abordagem sistem tica e sequencial para o desenvolvimento do software 4 um modelo onde a etapa seguinte s executada ap s a anterior ser totalmente f
45. sam o controle para medir a qualidade do desenvolvimento J as metodologias geis usam uma abordagem com foco na qualidade durante o desenvolvimento Bruno Junqueira Alves 28 Capitulo 3 Compara o entre as metodologias geis e metodologias cl ssicas 3 2 2 4 Riscos Os riscos dentro da metodologia tradicional s o identificados e as suas solu es ser incorporadas ao plano de projeto Em muitos casos uma equipe de desenvolvimento tem capacidade de identificar os riscos durante o per odo inicial do desenvolvimento mas prever riscos que poder o acontecer ao longo dos anos uma tarefa extremamente complicada Na metodologia gil para diminuir riscos de desenvolvimento o cliente come a a fazer parte da equipe de trabalho Ele ajudar nos problemas relacionados ao escopo do projeto pois com suas est rias o especialista pode identificar um risco grande trazendo sua solu o j para o in cio do projeto Nas metodologias geis n o se faz uso de documentos contendo um plano formal de ger ncia de riscos Esses riscos s o abordados atrav s das reuni es di rias realizadas pela equipe de desenvolvimento 3 2 2 5 Recursos Humanos As pessoas que ir o trabalhar na equipe de desenvolvimento do software ser o contratadas pela equipe de ger ncia de recursos humanos desej vel que sejam contratadas pessoas com grande experi ncia e possuam conhecimentos apropriados para o projeto Por m existe a p
46. ssos de neg cio as fun es que o software ir realizar Nessa fase n o pode haver erros como interpreta es err neas e informa es falsas Isso pode ocasionar o fracasso do projeto Os resultados obtidos atrav s dessas entrevistas e ap s an lise dever o ser documentados para que outros analistas de prazo custos e riscos possam us los para a posterior an lise Na metodologia gil ocorre um planejamento superficial dos requisitos no in cio do projeto com a finalidade de informar a equipe de an lise de requisitos todas as est rias identificadas Diferentemente da metodologia tradicional a metodologia gil detalha o escopo a cada itera o no caso do Scrum a cada Sprint Essa forma de detalhamento feita sem a obrigatoriedade de documenta o 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 itera o na fase de execu o ao longo do projeto 3 2 2 2 Tempo Na metodologia tradicional o planejamento do tempo baseado na separa o das atividades do projeto desde o in cio at a entrega ao cliente organizando as numa sequ ncia coerente e realizando a estimativa de dura o Ainda assim uma atividade muito complicada pois n o poss vel prever precisamente todos os detalhes e quais atividades estar o sendo feitas no futuro Essas estimativas precisam ser revistas ao longo do pro
47. stru es relativas manuten o da qualidade de todo o processo que todos os membros da equipe devem seguir O apoio do Scrum junto pr tica das metodologias tradicionais proporcionou segundo os profissionais de qualidade e de desenvolvimento maiores ndices de satisfa o dos clientes melhores ndices de produtividade das equipes e maior qualidade ao software Tornando o portanto mais confi vel Bruno Junqueira Alves 38 Capitulo 5 Conclus es e trabalhos futuros Cap tulo 5 Conclus es e trabalhos futuros A partir do estudo feito conclui se que o uso das metodologias tradicionais est cedendo seu espa o pelo menos nas reas de manuten o de sistemas s metodologias geis devido sua alta burocracia que exige todo o planejamento j na fase inicial do projeto J a metodologia gil cnega para tornar o ambiente de desenvolvimento de softwares mais produtivo e din mico 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 an lise programa o e testes Com isso as empresas encontram dificuldades em contratar pessoas com grandes n veis de conhecimento preciso tamb m levar em conta que dependendo do projeto se torna necess ria uma equipe relativamente grande para o desenvolvimento do sistema No caso do Pir mide alguns m
48. trado um problema dif cil nessa fase recomendada a constru o de um prot tipo operacional que n o ser uma vers o final do sistema Esse prot tipo denominado solu o de ponta e ser avaliado a fim de diminuir o risco de uma est ria quando a verdadeira implementa o for iniciada e revisar as estimativas de entrega das vers es gt Codifica o Tem como caracter stica chave a programa o em pares s vezes at uma terceira pessoa entra no processo de codifica o Essa caracter stica importante pois mant m os desenvolvedores concentrados no problema a ser resolvido Na pr tica cada um pode assumir uma tarefa diferente durante a codifica o Por exemplo um desenvolvedor fica respons vel pelos c lculos a serem escritos no c digo enquanto outro desenvolvedor fica respons vel pela adequa o do c digo aos crit rios de codifica o garantindo que esse c digo encaixe no projeto mais amplo da est ria Isso faz com que a funcionalidade de uma est ria seja entregue no Bruno Junqueira Alves 19 Capitulo 2 Os processos de desenvolvimento de software tempo correto seguindo todos os padr es do projeto e com qualidade para o cliente gt Testes recomendado que ao terminar de projetar as est rias do cliente sejam criados testes unit rios os quais exercitar o a interface as estruturas de dados e a funcionalidade de um componente do projeto Essa pr tica encoraja a pr tica
49. trega do 3 incremento 2 incremento 5 E 8 g entrega do 2 1 incremento Tempo Decorrido da Projeto Figura 2 Modelo Incremental Fonte retirado de 4 No processo incremental o primeiro incremento desenvolvido chamado de n cleo Esse n cleo cont m as caracter sticas mais b sicas do software Ao longo do tempo o usu rio solicita melhorias ou seja novos incrementos S o feitos novos planos de projeto a fim de que o software seja aperfei oado Esse processo repetido at que o sistema esteja com todas as funcionalidades implementadas A vantagem do uso desse modelo a previs o de uso de m o de obra extra e de novas tecnologias de hardware Atrav s 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 lan amento incerta Bruno Junqueira Alves 7 Capitulo 2 Os processos de desenvolvimento de software 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 propriet rio de engenharia de software Foi criada pela Rational Software Corporation adquirida posteriormente pela IBM ficando conhecida como RUP IBM ou IRUP Esse processo fornece t cnicas s equipes de desenvolvimento de software objetivando
Download Pdf Manuals
Related Search