Universidade Federal de Pernambuco Centro de Informtica

Graduao em Cincia da Computao

Compondo Mtodos geis de Desenvolvimento de SoftwareTiago de Farias Silva TRABALHO DE GRADUAO

Recife 01 de Julho de 2009

Universidade Federal de Pernambuco Centro de Informtica

Tiago de Farias Silva

Compondo Mtodos geis de Desenvolvimento de Software

Trabalho apresentado ao Programa de Graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do grau de Bacharel em Cincia da Computao. Orientador: Prof. Hermano Perrelli de Moura

Recife 01 de Julho de 2009

ii

Quem refreia suas prprias declaraes possudo de conhecimento e o homem de discernimento de esprito frio. - Provrbios 17:27 1

RESUMOCom o surgimento do Manifesto gil em 2001, o processo de gerenciamento de projetos de software sofreu intensas mutaes. Com princpios focados em resultados rpidos e entregas constantes, diversas metodologias se consolidaram. Essas metodologias, utilizadas amplamente no indstria mundial de softwares, mostram-se muito teis em projetos que apresentam mudanas bruscas e ambientes pouco previsveis. Dessas metodologias, as mais conhecidas atualmente so: Scrum, XP e Feature Driven Development. Por sua vez, essas metodologias podem trazer consigo catalisadores, ou seja, tcnicas orientadas ao desenvolvimento de Software propriamente dito, que aumentam o desempenho das metodologias geis e provem mais qualidade ao produto final. Esse trabalho tem por objetivo mostrar como essas tcnicas de desenvolvimento de Software e metodologias geis so mais poderosas combinadas do que individualmente. Palavras-chave: Agilidade, Scrum, XP, Feature Driven Development, Domain Driven Design, Test Driven Development, Tcnicas geis, Gerenciamento de Projetos, Desenvolvimento de Software, Composio de Mtodos geis.

2

ABSTRACTWith the emergence of the Agile Manifesto in 2001, the process of projectmanagement software has undergone intense mutations. With new principles, this time focused on quick results and constant deliverables, several methodologies have arisen. These methods, widely used in the world market for software, are very useful in projects that have sudden changes and hardly predictable environments. These methodologies, the best known today are: Scrum, XP and Feature Driven Development. In turn, these methodologies can bring their own catalysts, that is, oriented techniques to software development itself, which increase the performance of agile methodologies and provide more quality to the final product. This work has as its prime objective to show how the techniques of software development and agile methodologies are more powerful together than individually. Keywords: Agile, Scrum, XP, Feature Driven Development, Domain Driven Design, Test Driven Development, Agile Techniques, Project Management, Software Development, Composition of Agile Practices.

3

AGRADECIMENTOS

Relutei um pouco pra fazer essa parte porque eu sabia desde o comeo que muita gente que eu tenho de agradecer. Desde colegas do curso, do colgio, do trabalho, do extrabalho, so muitas pessoas e possvel que eu no consiga citar todos por nome. De qualquer forma, esses que no foram citados diretamente saibam que toda vez que eu vir vocs, sempre lembrarei o apoio (por menor que tenha sido) dado. Primeiramente agradeo a meus pais pelo apoio incondicional em meus empreendimentos, tanto em sentido emocional, quanto financeiro, jamais ser esquecido por mim (talvez quando eu estiver com Alzheimer daqui h 83 anos). Agradeo profundamente ao meu orientador, Professor Hermano Perrelli, que foi muito paciente e extremamente prestativo comigo durante a elaborao deste trabalho. Apesar de muito atarefado, mostrou-se pronto pra ajudar a qualquer momento com seu conhecimento da rea e raciocnio. Agradeo aos meus colegas de curso (por ordem alfabtica): Apebo, Arara, Alysson, Borba, Braga, Caio, Felipe Fifo, Jera, Joo Doido, Joo Paulo, Leila, Mrio, Rafael Formiga, Reaf, Riffa e Sos. Ao pessoal da Educandus, primeiramente ao Professor Ricardo Lessa pela grande oportunidade concedida a mim desde o comeo do curso, assim como tambm por ser uma fonte de inspirao pela grande pessoa que . Mas tambm a outros que passaram por l e me ensinaram muitas lies: Mestre Tairone, Tia Las, Bruna, Lo, Joo Augusto, Ricardo Teixeira, Teoria, enfim, muito obrigado a todos pelo aprendizado do dia a dia! A Provider Sistemas e os caras de l, pois foi nesse ambiente de trabalho que pude ver na prtica os benefcios de se usar mtodos geis. Marcos Pereira e Igor Macabas eram os pioneiros nisso, mas agradeo a todos por esclarecer coisas sobre o assunto e a abrir minha mente para novas tecnologias. Obviamente no podia esquecer da galerinha do CPI. Foi onde a instiga comeou. A todo o grupo de estudiosos: Bruno BB, Jefferson Fefa, Humberto Panz, Paulo Bolado, Renata, Ana Rita, Zoby e todos os demais que de alguma forma me inspiraram a conseguir essa conquista. Enfim, muito obrigado a todos! 4

SUMRIO

RESUMO ............................................................................................................................... 2 ABSTRACT ........................................................................................................................... 3 AGRADECIMENTOS ........................................................................................................... 4 SUMRIO .............................................................................................................................. 5 LISTA DE FIGURAS ............................................................................................................ 7 LISTA DE TABELAS ........................................................................................................... 8 1. INTRODUO .............................................................................................................. 9 1.1 Contexto do Trabalho ................................................................................................... 9 1.2 Motivao ..................................................................................................................... 9 1.3 Objetivos..................................................................................................................... 11 1.4 Estrutura do Trabalho ................................................................................................. 11 2. METODOLOGIAS GEIS .......................................................................................... 12 2.1 Uma breve histria de agilidade Manifesto gil ..................................................... 13 2.2 Scrum .......................................................................................................................... 15 2.2.1 Definies ............................................................................................................ 15 2.2.2 Fases .................................................................................................................... 19 2.2.3 Vantagens e desvantagens ................................................................................... 20 2.3 Extreme Programming................................................................................................ 22 2.3.1 Princpios e diferenas para outras metodologias................................................ 23 2.3.2 Boas Prticas ....................................................................................................... 24 2.3.3 Elementos ............................................................................................................ 26 2.3.4 Fases .................................................................................................................... 27 2.4 Feature Driven Development...................................................................................... 29 2.4.1 Elementos ............................................................................................................ 29 2.4.2 Boas prticas ........................................................................................................ 31 2.4.3 Fases .................................................................................................................... 32 2.4.4 Vantagens e desvantagens ................................................................................... 35 2.5 Anlise Comparativa .................................................................................................. 37 3. TCNICAS E ABORDAGENS GEIS .......................................................................... 44 3.1 Test Driven Development........................................................................................... 44 3.1.1 Como funciona .................................................................................................... 44 3.1.2 Benefcios ............................................................................................................ 46 3.1.3 Limitaes ........................................................................................................... 47 3.2 Outras tcnicas ............................................................................................................ 48 3.2.1 Design Patterns .................................................................................................... 49 3.2.2 Controle de verso ............................................................................................... 51 3.3 Domain Driven Design Uma abordagem gil ......................................................... 53 3.3.1 Conhecimento do domnio................................................................................... 54 3.3.2 Uma linguagem ubqua ........................................................................................ 55 3.3.3 Model Driven Design .......................................................................................... 56 3.3.4 Elementos do Model Driven Design ................................................................... 57 3.3.5 Benefcios ............................................................................................................ 61 4. COMPONDO MTODOS GEIS .............................................................................. 63 5

4.1 Scrum + XP + TDD .................................................................................................... 63 4.1.1 Praticando Scrum + XP + TDD ........................................................................... 65 4.1.2 Vantagens da composio ................................................................................... 68 4.1.3 Concluso ............................................................................................................ 70 4.2 FDD + DDD + Design Patterns .................................................................................. 70 4.2.1 FDD + DDD + Design Patterns na prtica .......................................................... 71 4.2.2 Vantagens da composio ................................................................................... 74 5. CONCLUSES E TRABALHOS FUTUROS ............................................................ 76 4.1 Trabalhos futuros ........................................................................................................ 77 REFERNCIAS BIBLIOGRFICAS ................................................................................. 78

6

LISTA DE FIGURAS

Figura 1. Esquema de um dashboard no meio de uma sprint, mostrando tarefas a fazer, em processo, a verificar e finalizada .......................................................................................... 19 Figura 2. Funcionamento de uma Sprint recebendo Sprint Backlog como entrada e aps vrios Daily Scrums (durao mdia da Sprint de 2 a 4 semanas), a entrega do incremento de software funcionando ....................................................................................................... 20 Figura 3. Os 5 processos do FDD ......................................................................................... 35 Figura 4. Grafo mostrando as etapas do Test Driven Development ..................................... 46 Figura 5. Relaes entre os elementos que compem o Domain Driven Design. ............... 61 Figura 6. XP sendo executado dentro das iteraes do Scrum ............................................. 67

7

LISTA DE TABELAS

Tabela 1. Anlise comparativa entre Scrum, XP e FDD. ..................................................... 38

8

1. INTRODUO

1.1 Contexto do Trabalho Com o crescente aumento da competitividade dos mercados internacionais, a exigncia sobre o produto tornou-se um diferencial determinante. E visto que o software tornou-se essencial para a manuteno do controle e da produtividade nos mais diversos setores organizacionais, j era previsvel o surgimento de novas metodologias e tcnicas que buscassem garantir agilidade e ao mesmo tempo robustez no processo de desenvolvimento de software. Assim surgiu o Manifesto gil, com o objetivo de promover prticas geis de desenvolvimento de software e gerenciamento de projetos. Essas prticas tm como conceito base o incentivo ao trabalho em equipe, equipes auto-organizadas e responsveis, um conjunto de tcnicas de engenharia que permitem rpidas entregas de produtos com alto nvel de qualidade, alm de uma nova abordagem ao alinhar os interesses dos clientes com os objetivos dos desenvolvedores. Como os conceitos advindos do Manifesto gil mostraram-se de intenso valor para as boas prticas organizacionais, uma grande quantidade de engenheiros de software e gerentes de projeto comearam a adaptar tais conceitos para o seu prprio contexto. Dessa forma surgiram novas metodologias e diferentes tcnicas focadas em dinamizar o processo de desenvolvimento. Entretanto, essas tcnicas e metodologias podem se mostrar tambm deficientes em alguns aspectos. Porm, ao analisar as fraquezas e os pontos fortes de cada uma delas, possvel encontrar os pontos onde estas se complementam. 1.2 Motivao

Com o crescimento do mercado mundial de Software, novas empresas com novas estratgias de marketing e idias inovadoras tm surgido. Nos ltimos 8 anos, por exemplo,

9

muito tm-se falado sobre Agilidade. No de admirar, pois a comunidade gil tem-se mostrado bastante eficaz, trazendo maneiras novas de resolver problemas antigos na rea de Gerenciamento de Projetos e Desenvolvimento de Software. Dentro dessa comunidade, existe um verdadeiro ecossistema composto por metodologias, tcnicas e abordagens que, se executadas em conjunto de forma equilibrada, so extremamente robustas do ponto de vista organizacional, garantindo qualidade, objetividade e agilidade ao projeto. importante definir o conceito de metodologia, tcnica, abordagem e mtodo no contexto desse trabalho: Uma metodologia um conjunto estruturado de prticas (por exemplo: Material de Treinamento, Programas de educao formais, Planilhas, e Diagramas) que pode ser repetvel durante o processo de produo de software. Na verdade, metodologias de Engenharia de Software abrangem muitas disciplinas, incluindo Gerenciamento de Projetos, e as suas fases como: anlise, projeto, codificao, teste, e mesmo a Garantia da Qualidade. Uma tcnica uma prtica de desenvolvimento de software aplicada a uma determinada fase. Por exemplo, uma tcnica pode existir tanto na fase de codificao quanto na fase de testes. Uma abordagem uma forma de visualizar o projeto de software em questo. Com uma srie de boas prticas e princpios, prope uma forma diferente de encarar o projeto numa determinada fase. No completamente especificada com regras. Mas, deixa o desenvolvedor do projeto livre para aplicar regras que se adquem aos conceitos propostos pela abordagem. Mtodo, no contexto desse trabalho, um termo geral utilizado para se referir a metodologias, tcnicas e abordagens.

10

1.3 Objetivos

O objetivo deste Trabalho de Graduao mostrar como as metodologias, abordagens e tcnicas de desenvolvimento de software existentes atualmente na comunidade gil podem ser mais bem aproveitadas do ponto de vista organizacional se aplicadas em conjunto, ao invs de individualmente. Tornando-se assim mais robustas e eficientes sem perder o foco na agilidade. 1.4 Estrutura do Trabalho

No Captulo 2 temos a definio do que so Metodologias geis. Ser abordado como tudo comeou com o surgimento do Manifesto gil em 2001 e o que este prope, ou seja, quais seus princpios bsicos. Neste mesmo captulo sero apresentadas as metodologias mais conhecidas de toda comunidade gil: Scrum, Extreme Programming (tambm conhecida pela sua abreviao XP) e Feature Driven Development. Ao final deste captulo ser realizada uma anlise comparativa sobre estas metodologias. O Captulo 3 descreve as tcnicas de engenharia utilizadas como catalisadores para os processos geis. So apresentadas as suas respectivas definies, funcionamento e aplicaes no contexto de anlise e desenvolvimento de software. apresentada a tcnica Test Driven Development (TDD) e a abordagem Domain Driven Design (DDD), assim como outras tcnicas de programao como Design Patterns e ferramentas de controle de verso. O Captulo 4 o corao deste Trabalho de Graduao, analisando como as metodologias geis podem ser aliadas as tcnicas ou prticas de engenharia de modo a conceber agilidade e qualidade em todas as camadas de um projeto de software. Primeiramente, analisamos a composio das metodologias Scrum, XP e TDD. Depois, a metodologia FDD, a abordagem DDD e a tcnica de Design Patterns. O Captulo 5 apresenta as concluses do trabalho, trabalhos relacionados e propostas futuras.

11

2. METODOLOGIAS GEIS

A filosofia aceita e pregada para o desenvolvimento de sistemas de que o processo de desenvolvimento perfeitamente previsvel, podendo ser planejado, estimado e completado com sucesso [3]. No entanto, isso tem se mostrado incorreto na prtica. O ambiente de desenvolvimento catico e sofre constantes mudanas, muitas vezes bruscas, o que causa grande impacto no produto final. O processo de desenvolvimento gil prope uma nova abordagem. Essa abordagem um conjunto de novas idias, velhas idias e velhas idias modificadas, e enfatiza [2]: Uma maior colaborao entre programadores e especialistas do domnio; Comunicao cara-a-cara (como sendo mais eficiente do que comunicao documentada); Entregas constantes de novas funcionalidades com valor de negcio; Equipes auto-organizadas; Maneiras de adaptar o cdigo e a equipe a novos requisitos que poderiam causar grande confuso; De forma geral, metodologias geis priorizam software funcionando como principal mtrica de progresso. Tendo em vista a preferncia por comunicao cara-acara, os mtodos geis normalmente produzem menos documentao do que os outros mtodos. notvel tambm a grande adaptabilidade dos projetos em relao a mudanas, o que no consagrado modelo Waterfall ou Cascata permanece uma grande dificuldade [4]. Neste captulo ser apresentado o ideal por trs do Manifesto gil, seus princpios e objetivos. Sero apresentadas tambm algumas das metodologias mais praticadas atualmente no mercado de software, como: Scrum, Extreme Programming (XP) e Feature

12

Driven Development (FDD). Analisaremos o funcionamento de cada uma delas, assim como tambm suas principais caractersticas, pontos fortes e pontos fracos, com o objetivo de comparar cada uma dessas metodologias. 2.1 Uma breve histria de agilidade Manifesto gil

O Manifesto gil uma declarao sobre os princpios que servem como base para o desenvolvimento gil de software. [5] Foi elaborado de 11 a 13 de Fevereiro de 2001, em Utah, onde representantes de vrias novas metodologias, tais como Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature Driven Development, Pragmatic Programming, se reuniram para discutir a necessidade de alternativas mais leves em contraposio as tradicionais metodologias existentes [1]. Simplificadamente, o Manifesto gil prega os seguintes valores [5]: Indivduos e interaes acima de processos e ferramentas; Software funcional acima de documentao compreensiva; Colaborao do cliente acima de negociao do contrato; Responder a mudanas acima de seguir um plano fixo; Nomeando a si mesmos como Agile Alliance, esse grupo de inovadores em desenvolvimento de software concordaram em chamar esses novos valores de Manifesto para o Desenvolvimento gil de Software (em ingls: Manifesto for Agile Software Development). A frase final do Manifesto expressa de forma sucinta esse ideal [5]: Sendo assim, enquanto existe valor agregado aos itens da direita, ns valorizamos mais os itens da esquerda. Atravs desses valores, os fundadores do Manifesto gil chegaram a concluso de doze princpios que deveriam reger as metodologias geis [6]: 1. Nossa maior prioridade satisfazer o cliente, mediante a rpida e contnua entrega de software funcional. 13

2. Permitir mudanas nos requisitos, mesmo que tardiamente no projeto. Processos geis aproveitam mudanas para o benefcio do cliente. 3. Entregar software funcional frequentemente, podendo variar entre semanas ou meses, com uma preferncia por escalas de tempo menores. 4. Especialistas do domnio e desenvolvedores devem trabalhar juntos diariamente durante o projeto. 5. Desenvolver projetos em torno de indivduos motivados. Dar a eles o ambiente e apoio de que precisam, e confiar neles para a realizao do trabalho. 6. O mtodo mais prtico e eficiente de se comunicar com a equipe de desenvolvimento conversar cara-a-cara com os integrantes. 7. Software funcional a medida primria de progresso. 8. Processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante. 9. Ateno contnua a excelncia tcnica e bom design aumenta a agilidade. 10. Simplicidade - a arte de maximizar a quantidade de trabalho no terminado - essencial. 11. As melhores arquiteturas, requisitos e modelos surgem de equipes autoorganizadas. 12. Em intervalos regulares de tempo, a equipe reflete em como se tornar mais eficiente, ento se prepara e se ajusta de acordo. Esses princpios, ao contrrio do que muitos dizem, no formam a base para uma anti-metodologia. De fato, as metodologias geis no so uma forma de contrariar completamente as metodologias tradicionais. Na verdade, o Manifesto gil props uma nova abordagem na forma de desenvolver projetos. Por exemplo, modelagem uma prtica utilizada, mas no a ponto de se tornar primordial. Documentao outra prtica adotada

14

nos projetos, mas jamais levantar uma srie de relatrios que jamais sero completamente lidos ou que levaro muito tempo para serem revisados. Logo, os princpios e valores propostos pelo Manifesto gil so uma nova forma de pensar desenvolvimento e gerenciamento de software, tendo em mente um conjunto de valores compatveis, baseados na confiana e respeito pelos companheiros de equipe e promovendo modelos organizacionais simplificados e centrados em pessoas e em colaborao. Dessa maneira, construindo comunidades organizacionais nas quais seria prazeroso trabalhar. 2.2 Scrum

Scrum um processo leve que visa gerenciar e controlar o desenvolvimento de software: uma metodologia de gerncia de projetos. No entanto, ao invs de promover a tradicional abordagem do modelo cascata ou waterfall, anlise modelagem codificao teste instalao do sistema, Scrum adota as prticas iterativa e incremental. Assim, Scrum no dirigido a artefato (ou artifact-driven), onde so criados grandes documentos de requisitos, especificaes, documentos de modelagem e diagramas. Pelo contrrio, Scrum exige pouqussimos artefatos. Ele se concentra no que de fato importante: Gerenciar um projeto ou codificar um software que produza valor de negcio [4]. 2.2.1 Definies

Sprint: Uma Sprint uma iterao que segue o ciclo PDCA (Plan Do Check Act) e entrega incremento de software funcional. Essas iteraes duram normalmente de 2 a 4 semanas e comeam e terminam com uma reunio da equipe. Scrum Master: o responsvel por proteger os membros da equipe de desenvolvimento de qualquer presso ou ameaa externa, seja isto clientes esbravejantes, diretores da empresa insatisfeitos ou qualquer outra coisa que seja considerado perigoso para a produtividade da equipe. Tenta garantir que todas as prticas do Scrum sejam utilizadas com perfeio pela equipe. Assim como tambm tem um papel de facilitador nas reunies da Sprint. Normalmente assumem esse papel os gerentes de projeto ou lder 15

tcnico, mas na prtica pode ser assumido por qualquer um com experincia o suficiente na metodologia. Product Owner: o responsvel por priorizar o Product Backlog. Este um papel importante pois a equipe de desenvolvimento observar o Product Backlog priorizado e construir o Sprint Backlog, comprometendo-se a entregar os itens postados. O Product Owner garante que durante a Sprint no haver mudanas nos requisitos solicitados, porm, nos intervalos entre Sprints ele possui total liberdade para modific-los. Essa funo realizada por uma pessoa que simular o papel de cliente em relao ao produto (da o nome Owner). O papel normalmente exercido por algum da rea de marketing ou por algum usurio muito importante no contexto do desenvolvimento do produto. Scrum Team: a prpria equipe de desenvolvimento. No entanto, isso no significa que uma equipe tradicional de desenvolvimento de software com programadores, especialistas em BD, testadores e etc. . Na verdade, as equipes de desenvolvimento em Scrum so incentivadas a serem multidisciplinares, ou seja, todos trabalham cooperativamente para entregar as funcionalidades que a equipe se comprometeu a entregar no comeo do Sprint. O tamanho tpico de uma equipe varia entre 6 e 10 pessoas, mas nada impede que as equipes possuam mais colaboradores. Dashboard: Visto que o Scrum prega a transparncia dentro de uma equipe de desenvolvimento, um quadro onde todas as histrias (requisitos) existentes para um produto estejam expostas extremamente til. Este quadro conhecido como Dashboard. Nele esto registradas, preferencialmente atravs de post-its, as issues a serem entregues para o desenvolvimento de um produto. O dashboard possui o status das issues a serem entregues pela equipe. As issues vo se movendo no Dashboard com o passar do tempo de acordo com seu status, por exemplo: issue no Product Backlog (no est contida na Sprint atual), issue no Sprint Backlog (est contida na Sprint atual), issue no Work in Progress (trabalho sendo feito no momento exato), issue na reviso e issue finalizada. As divises existentes podem ser modificadas de acordo com a necessidade de cada equipe. A figura 1 mostra como deve ser a organizao de um dashboard;

16

Product Backlog: a lista principal de funcionalidades para o desenvolvimento de um dado produto. O Product Backlog pode e deve mudar no decorrer das sprints tornandose maior, melhor especificado e mudando as prioridades das issues. um elemento essencial na reunio de Planning, pois com o Product Backlog (priorizado) que o Product Owner ir se comunicar com a equipe de desenvolvimento com o objetivo de expressar suas maiores necessidades para aquela sprint. Sprint Backlog: Na reunio de planejamento da Sprint (Planning) o Product Owner dever mostrar o Product Backlog priorizado e a equipe ir escolher quais issues daquela lista sero realizadas durante aquela sprint. As issues escolhidas sero colocadas na sesso de Sprint Backlog, ou seja, lista de funcionalidades a serem implementadas na sprint corrente. Issue ou Estria: Cada elemento da lista conhecido como Issue e deve ser identificado com um nome e/ou id com objetivos de identificao e rastreamento. Essas issues devem possuir tambm uma breve descrio das funcionalidades requeridas pelo Product Owner para um dado produto. O time pode dividir uma issue em tarefas, de preferncia pequenas, para que, com a concluso de todas as tarefas, a prpria issue esteja concluda. uma forma de usar a abordagem dividir para conquistar em gerenciamento de projetos. Sprint Planning: a reunio principal do Scrum. Nela so planejadas as atividades para a sprint corrente. Nesta reunio, o Product Owner apresenta o Product Backlog priorizado, para da ento, os membros da equipe decidirem quais issues do Product Backlog sero includas no Sprint Backlog. De forma coletiva, o Product Owner e a equipe de desenvolvimento definem um objetivo para o Sprint, que na verdade uma breve descrio sobre o que se deseja entregar na Sprint. Sprint Review: No final de cada sprint, a equipe de desenvolvimento, o Scrum Master e o Product Owner se renem para verificar o que foi feito durante a sprint. A equipe apresenta as funcionalidades prontas e o Product Owner aprova ou desaprova o produto. Essa reunio aberta para qualquer outra equipe presente na empresa que queira observar a apresentao das issues completadas durante o sprint. A reunio possui a forma

17

de uma demo de produto, onde so apresentadas novas funcionalidades, bugs consertados entre outras coisas. Sprint Retrospective: realizada logo aps o Sprint Review e tem como objetivo extrair para todos da equipe a essncia do que houve de melhor e do que pode melhorar na sprint analisada. Essa reunio fechada para apenas a equipe e o Scrum Master. Durante essa reunio sero colhidas, atravs de comunicao cara-a-cara entre os integrantes da equipe, informaes sobre o andamento do projeto. Os membros da equipe so incentivados a falar sobre o que esto achando do projeto (em todos os sentidos) e realizada pelos prprios membros uma retrospectiva em formato de timeline especificando as datas chave para o sprint. Essa reunio considerada muito importante para o crescimento da equipe, pois nela onde sero mostrados os erros e consequentemente as lies aprendidas durante a sprint. Daily Scrum: uma reunio realizada diariamente entre os membros da equipe, Scrum Master e opcionalmente com a presena do Product Owner com o objetivo de analisar o que cada membro da equipe fez no dia anterior, o que pretende fazer durante o dia presente e quais os impedimentos ou obstculos que tem para cumprir com as tarefas. Normalmente feita em formato de Stand-up-meeting e de durao bem curta. uma forma eficiente de manter a comunicao aberta entre os membros da equipe de desenvolvimento e o Scrum Master.

18

Figura 1. Esquema de um dashboard no meio de uma sprint, mostrando tarefas a fazer, em processo, a verificar e finalizada. [13]

2.2.2 Fases

Planejamento: Essa fase marca o incio de uma nova Sprint. O Sprint Planning a cerimnia na qual a equipe se rene com o Product Owner para analisar as issues priorizadas por este e decidir quais destas a equipe se compromete em entregar. Essas reunies costumam durar de 1 a 3 horas com a participao ativa de todos da equipe. Geralmente o Product Owner explica brevemente o objetivo de cada issue e, caso surja alguma dvida, explica mais detalhadamente para todos.

Desenvolvimento: Essa fase a maior do Sprint, pois representa todos os dias em que a equipe est trabalhando concentradamente na entrega do software. Em cada um desses dias realizado o Daily Scrum com os membros da equipe. Neste so discutidas questes relativas entrega do software, como o que foi feito e o que pretendo fazer at o prximo Daily Scrum.

19

Concluso: A concluso de uma sprint marcada por duas cerimnias: Sprint Review e Sprint Retrospective. A Sprint Review uma cerimnia aberta para toda a empresa com o objetivo de mostrar as novas funcionalidades implementadas pela equipe de desenvolvimento durante a Sprint. A equipe faz uma breve demonstrao para o Product Owner, que aprova ou no a nova funcionalidade. Normalmente a Sprint Retrospective acontece logo aps a Sprint Review. A Sprint Retrospective de fato a ltima reunio da Sprint. Nesta reunio moderada pelo Scrum Master, a equipe discute seus melhores e piores momentos no decorrer da Sprint. comum acontecer que, ao final desta reunio, surjam feedbacks de coisas a melhorar, seja na equipe ou na prpria organizao. vlido salientar que esta reunio no aberta nem mesmo ao Product Owner, mas somente a equipe e ao Scrum Master, pois tem como objetivo realmente extrair o que cada membro est sentindo com relao ao andamento do projeto. Por este motivo, desaconselhada a presena de pessoas externas ao grupo na sala de reunio da equipe.

Figura 2. Funcionamento de uma Sprint recebendo Sprint Backlog como entrada e aps vrios Daily Scrums (durao mdia da Sprint de 2 a 4 semanas), a entrega do incremento de software funcionando. [13]

2.2.3 Vantagens e desvantagens

As metodologias tradicionais so projetadas para reagir a mudanas imprevisveis apenas no comeo de um ciclo de desenvolvimento. Mesmo as metodologias que no

20

seguem o modelo cascata (seguem o modelo espiral por exemplo), mostram-se limitadas para reagir a mudanas uma vez que o projeto tenha comeado. Scrum, por outro lado, lightweight, ou seja, leve. Foi modelado para ser adaptvel a mudanas durante todas as fases do projeto. Ele prov mecanismos de controle para planejar uma entrega de produto e, enquanto o projeto avana, prov variveis de gerenciamento. essa abordagem que permite a mudana do projeto e de entregas a qualquer momento, entregando assim, a parte mais apropriada do software desenvolvido. Scrum incentiva a criatividade dos membros da equipe de desenvolvimento na resoluo de problemas. Isso acontece quando os problemas surgem no projeto e/ou o ambiente de desenvolvimento sofre mudanas. Neste caso, os membros da equipe podem vir com as solues mais diferentes possveis de modo a resolver o problema e trazer a equipe novamente ao rumo correto. A deciso nesses casos sempre da equipe. Equipes pequenas, colaborativas e multidisciplinares compartilham conhecimento sobre todas as fases do processo de desenvolvimento. A conseqncia imediata disto a baixa concentrao de informao em apenas um membro da equipe. Caso algum membro precise sair da equipe por qualquer que seja o motivo, o impacto sobre o restante do grupo no ser muito grande. Alm do mais, essa caracterstica prov um treinamento excelente para todos os membros da equipe em todas as reas do processo de desenvolvimento. A tecnologia Orientada a Objetos (OO) prov a base para o Scrum. Por ser bastante prtica e limpa, a viso OO garante que os processos de Scrum sero simples de entender e de usar [7]. O curto intervalo de tempo entre os releases uma vantagem. Dessa forma, o cliente pode acompanhar de perto a evoluo do projeto e fornecer feedbacks a cada sprint, tornando-se assim tambm uma vantagem para a equipe desenvolvedora. Desenvolve-se desde cedo uma relao de confiana com o cliente, o que um grande fator de sucesso organizacional atualmente. [7] Scrum no se mostra vantajoso no caso de grandes projetos com durao muito longa, prazo muito curto, muitas pessoas trabalhando em muitas camadas e oramento

21

muito alto. Ken Schwaber, um dos fundadores de Scrum diz que quando se investe muito alto num projeto com um prazo muito apertado, os lderes da organizao no esto apoiando a independncia das equipes de desenvolvimento. O que costuma acontecer que, aps apenas uma Sprint, os gerentes de projeto analisam o Release Burndown e constatam que impossvel entregar o produto no prazo determinado. Normalmente os investidores recuam e o projeto cancelado. Nesses casos mais vantajoso usar o modelo cascata, pois s se constata que o projeto vai atrasar de fato aps alguns meses de trabalho e j tarde demais para cancelar o projeto [7]. Scrum um mtodo que exige uma gesto constante e muito prxima. Isso significa que o gestor deve estar sempre removendo barreiras e monitorando as equipes de desenvolvimento, se certificando de que as prticas da metodologia esto sendo postas em prtica como deveriam. Monitoramento constante exigido do gestor. Como Scrum prov um alto nvel de independncia s equipes, o gestor deve permitir que as equipes tomem suas prprias decises, permitindo at que estas falhem ao faz-lo. Assim, possvel haver prejuzos em curto prazo, tanto em sentido financeiro quanto em tempo. vlido lembrar que Scrum uma metodologia relativamente nova e que as pessoas so resistentes a mudanas. Na fase inicial de implantao da metodologia numa organizao, desconforto pode existir. H tambm a possibilidade de alguns elementos dentro da organizao no conseguirem se adaptar ao novo ritmo e nova filosofia do Scrum. [6] 2.3 Extreme Programming

Extreme Programming (XP) na verdade uma abordagem para o desenvolvimento de Software. Esta metodologia foi criada com o objetivo de entregar o software que o cliente precisa quando ele precisa. XP encoraja os desenvolvedores a se adaptarem a mudanas no escopo do projeto, mesmo que tardiamente no ciclo de produo do software.

22

Assim como a metodologia Scrum, XP enfatiza o trabalho em equipe como chave para um processo de produo de Software mais gil e com melhor qualidade. [13] 2.3.1 Princpios e diferenas para outras metodologias

Os princpios vistos no Manifesto gil so a base dos princpios do XP [14]. So eles: Codificar a atividade chave; Cultura de Software pronto no tempo do cliente; Ciclos freqentes de lanamento (Release); Comunicao feita a partir do cdigo; Melhorar cdigo com Refactoring.

Esses princpios no indicam que o desenvolvedor, quando estiver trabalhando, apenas comece a escrever cdigo rpida e desesperadamente. Pelo contrrio, preciso ser disciplinado nesse sentido ou o efeito ser contrrio ao desejado. A aplicao desses princpios num projeto de desenvolvimento de software a base para o estabelecimento da metodologia XP. Logo, diferentes caractersticas surgiro desta nova metodologia em relao a outras existentes no mercado. Podemos citar algumas dessas diferenas [17]: 1. Feedback rpido e contnuo advindo de um ciclo de vida mais curto do projeto; 2. Planejamento incremental, no esttico. Neste o plano de projeto pode evoluir; 3. Implementao de forma flexvel, de modo a se adequar s necessidades do cliente;

23

4. Baseia-se em comunicao oral, testes, e escrever cdigo como uma forma de descrever a estrutura e propsito do sistema; 5. Alto nvel de colaborao entre programadores com menos habilidades; 2.3.2 Boas Prticas

Pair-Programming: Programao em par ou Pair-Programming uma tcnica para o desenvolvimento de software na qual um programador no trabalha sozinho, mas sim com um companheiro de equipe. Assim, compartilham experincias, pensam juntos antes de escrever cdigo, tiram dvidas um do outro, enfim, trabalham conjuntamente num mesmo computador. Nesta tcnica, temos um piloto, que o usurio que est escrevendo cdigo, e temos o navegador, que o usurio responsvel por revisar cada linha de cdigo escrita. Isso costuma aliviar a presso em cima do piloto, pois o navegador possui tambm a responsabilidade de procurar eventuais falhas tanto na escrita quanto no design do cdigo [15]. Para que nenhuma das duas partes se limite a apenas um tipo de atividade (s codificar ou s revisar), os usurios devem trocar de lugar frequentemente. A grande vantagem da programao em par que, dessa forma, o cdigo final apresenta maior legibilidade, melhor design e menor susceptibilidade a erros. Por outro lado, a

programao em par pode causar intimidao em alguns programadores mais retrados ou menos habilidosos, diminuindo a produtividade da dupla. Planning Game: O processo de planejamento na metodologia Extreme Programming chamado de Planning Game ou Jogo do Planejamento. Esse jogo acontece uma vez por iterao e dividida em duas fases [15]: Planejamento do Release: O foco desta reunio planejar quais requisitos sero escolhidos para a prxima iterao e quando ser realizada a entrega dessas funcionalidades. Primeiramente, o cliente prover uma lista de requisitos que deseja para a sua aplicao. Estes requisitos sero mapeados em estrias e escritos em cartes. Da a equipe desenvolvedora ir escolher algumas dessas estrias para ser

24

implementadas e se comprometero com a entrega dessas. Finalmente, com as estrias em mos, a equipe e o cliente podero se reunir e decidir se algo mais ser acrescentado quela estria, removido da estria ou replanejado. Planejamento de Iterao: Neste planejamento, o cliente no participa. Apenas a equipe de desenvolvedores se rene para dividir as estrias escolhidas em tarefas menores. Primeiramente, as estrias so repartidas em tarefas e atividades e escritas em cartes. Da, os desenvolvedores decidem quem ficar com qual tarefa e estimam quanto tempo gastaro para termin-las. Aps as tarefas serem concludas, feita uma comparao entre o que foi planejado e o que de fato foi feito. Testes: Um fator que chama ateno na metodologia XP que num projeto, a equipe inteira tem responsabilidade pela qualidade do produto. Dessa maneira, todos os participantes da equipe, tanto programadores quanto testadores, so responsveis por criar testes (incluindo todos os tipos) para a aplicao. Testar uma atividade integrada num projeto XP. Os testadores devem fazer o mximo para transferir suas habilidades relativas atividade para todos os membros da equipe. Abaixo, citamos algumas atividades dos testadores numa equipe XP [16]: Negociar qualidade com o cliente (o cliente que decide o quo padronizado ele quer o cdigo); Esclarecer estrias e retirar dvidas que surgem durante a

implementao; Certificar-se de que os testes de aceitao verificam a qualidade especificada pelo cliente; Ajudar a equipe a automatizar testes; Testar a qualquer momento, sem qualquer restrio para isso. Qualquer integrante pode testar na hora em que quiser;

25

Definio e redefinio da arquitetura a todo o momento: Visto que em XP, a equipe de desenvolvimento est sempre analisando cdigo, testando funcionalidades e alterando o design da aplicao, a arquitetura est sempre sendo atualizada. Isso no implica dizer que a aplicao no possui uma padronizao na arquitetura. Pelo contrrio, a equipe est frequentemente alterando a estrutura da aplicao para ter maior flexibilidade escalabilidade e legibilidade, atributos que envolvem diretamente padronizao no cdigo. No h confuso quanto s redefinies de arquitetura porque a equipe est se comunicando a toda hora (um dos princpios do Manifesto gil). Stand-up Meeting: Reunio de curta durao (entre 5 e 10 minutos) entre os membros de uma equipe XP para discutir assuntos relacionados ao projeto. Esse tipo de reunio realizada normalmente todos os dias (podendo ser convocada a qualquer hora) com os membros todos de p (da o nome stand-up). O objetivo conseguir maior concentrao dos membros durante a reunio assim como evitar distraes, como conversas paralelas, assistir a vdeos no computador, chats e coisas do tipo. Por estarem todos de p, os membros no iro tirar o foco do assunto em pauta e no demoraro muito para terminar a reunio, que deve ser curta. 2.3.3 Elementos Gerente de Equipe: o responsvel por assuntos administrativos do projeto. Deve possuir grande habilidade ao lidar com pessoas, visto que ir tratar de assuntos ligados ao projeto com a equipe e com os clientes. um tipo de mediador entre os interesses da equipe e do cliente. Outro papel do gerente de equipe manter as ameaas externas longe da equipe sob sua superviso. Tambm responsvel por tentar manter o cliente informado do projeto em questo e, ainda mais importante para a empresa, participando do desenvolvimento de forma direta. Obviamente, um bom gerente de equipe deve acreditar em todos os valores de XP para que possa cobrar isto da sua equipe. Coach: Responsvel pelas questes tcnicas do projeto de software. O coach deve possuir grande conhecimento em todas as fases do XP e conhecer bem os membros da equipe. o responsvel por estimular a equipe a dar o melhor sempre que possvel. Ao

26

conhecer e aplicar os conceitos de XP, deve estar apto para sinalizar a sua equipe os erros cometidos ao longo do projeto e dar os passos necessrios para consert-los. Analista de teste: Responsvel por garantir a qualidade do sistema desenvolvido atravs da atividade de testes do sistema. Normalmente o analista de testes ajuda o cliente a escrever os casos de testes necessrios para garantir que os requisitos ordenados sero devidamente satisfeitos. No final duma iterao, deve realizar os testes no software a ser entregue com o objetivo de verificar se existem bugs e requisitos no-cumpridos. perigoso usar um desenvolvedor do software para test-lo e construir casos de teste junto ao cliente. O que pode acontecer que, pelo fato de o desenvolvedor conhecer o cdigo, ele ter uma viso tendenciosa, evitando tocar nos pontos que ele sabe serem sensveis no sistema. Por outro lado, o analista de testes deve ter uma viso muito parecida com a do cliente. Redator tcnico: Pessoa responsvel por cuidar da documentao do projeto. Dessa forma, a equipe de desenvolvedores pode se concentrar exclusivamente em codificar. Para que a documentao esteja de acordo com o cdigo escrito e as necessidades do cliente, o redator deve estar sempre em comunicao com os desenvolvedores, sabendo o que esto desenvolvendo e como. Desenvolvedor: o papel principal no XP. O desenvolvedor responsvel por analisar, projetar e escrever cdigo para o sistema em desenvolvimento. Numa equipe de desenvolvedores utilizando XP, os desenvolvedores esto todos no mesmo nvel. Por exemplo, no existe diferena entre analista e programador uma vez que eventualmente todos executaro uma dessas atividades. 2.3.4 Fases Explorao: Esta a primeira fase de um projeto utilizando XP e realizada anteriormente construo do sistema. So estudadas vrias solues para resolver o problema do cliente e verificadas as viabilidades de cada uma destas solues. Nesta fase so pensadas as possveis arquiteturas e ambientes, levando

27

em conta as condies necessrias para a implementao do sistema, como plataforma, sistema operacional, configuraes da rede, hardware e linguagem utilizada. O objetivo desta fase fazer os programadores e os prprios clientes ganharem confiana no planejamento do projeto para que, logo mais, comecem a escrever estrias e comear a construo do sistema. Planejamento inicial: utilizada para que os clientes e a empresa desenvolvedora do sistema possam acordar em uma data para o primeiro release. O planejamento tem incio com os programadores estimando as estrias escritas na fase de explorao e as escrevendo com seu valor estimado em cartes. Aps a estimativa de cada uma das estrias, a equipe informa quantas estrias podem ser entregues levando em considerao a mdia de estrias entregues em iteraes passadas. Por sua vez, o cliente prioriza as estrias em seu ponto de vista. O planejamento inicial obtm como sada uma srie de cartes com as estrias priorizadas e estimadas pela equipe, prontas para guiar os desenvolvedores na prxima fase. Normalmente a fase de planejamento inicial dura de uma a trs semanas e cada release dura de dois a quatro meses. Iteraes do release: Nessa fase comea a construo do sistema propriamente dita. Os desenvolvedores comeam a codificar, testar, refatorar, analisar cdigo, depurar bugs e projetar, sempre seguindo os princpios e valores da metodologia XP. Frequentemente durante uma iterao, a equipe realiza reunies de stand-up meeting, onde sero discutidas questes relativas a implementao do sistema. O resultado da primeira iterao de um produto essencial para o cliente ter uma idia de como o produto est sendo construdo (se est cumprindo os requisitos acordados anteriormente) e se haver atraso na entrega da release. Produo: Aps um release, o sistema est pronto para ser simulado em um ambiente de produo. Nesta fase, o sistema ser testado observando atributos como confiabilidade e performance. Testes de aceitao podem ser realizados de acordo com a necessidade do cliente. Manuteno: Aps um release o sistema estar funcionando bem o suficiente para poderem ser feitas manutenes. Isso pode envolver vrias atividades como por exemplo: refatoramento de cdigo existente, introduo de uma nova

28

arquitetura, instalao de um novo servidor no ambiente de desenvolvimento ou introduo de uma nova tecnologia. vlido ressaltar que uma vez que o sistema estiver em produo, fazer manutenes se torna perigoso. Por isso, a equipe deve tomar muito cuidado ao modificar o sistema, visto que uma alterao errada ou mal planejada pode causar danos gigantescos ao sistema, causando prejuzo ao cliente. Morte: Essa fase constitui o fim de um projeto XP. Normalmente ocorre quando o cliente j est plenamente satisfeito com o sistema obtido e no consegue visualizar nenhuma funcionalidade essencial para ser implementada

futuramente. Porm, podem ocorrer casos de um projeto XP morrer antes de completar o produto final. Por exemplo, se aps a primeira iterao o cliente observar que o tempo e oramento necessrios para a finalizao do projeto esto fora do alcance. Nestes casos, os clientes podem cancelar o projeto, causando seu fim. 2.4 Feature Driven Development

Feature Driven Development (FDD) uma metodologia gil para desenvolvimento de software, voltada para o cliente e orientada a modelagem. Consiste de cinco atividades ou fases bsicas e possui mtricas para marcar o progresso dessas atividades [22]. Nessa metodologia, as entregas, assim como nas outras apresentadas nesse trabalho, so incrementais. Atualmente, crescente o nmero de empresas de software que a utilizam por esta oferecer um esquema orientado a modelagem e agilidade ao processo de desenvolvimento [23]. 2.4.1 Elementos

Gerente de Projeto: o personagem central deste mtodo. Est frente do projeto. Possui como tarefas, delegar responsabilidades aos arquitetos-chefe e ao gerente de configurao (podendo tambm acumular esse papel), assim como tambm resolver problemas administrativos ligados ao projeto.

29

Arquitetos-chefe: Responsveis pela modelagem do sistema em todas as fases. Como o FDD d bastante nfase modelagem, os arquitetos-chefe so bastante cobrados e so diretamente responsveis pelo sucesso do projeto.

Programadores-chefe: Os programadores-chefe so os desenvolvedores mais experientes. A eles so atribudas funcionalidades a serem construdas. Entretanto, eles no as constroem sozinhos. Ao invs disso, o programadorchefe identifica quais classes esto envolvidas para se desenvolver a funcionalidade e rene seus proprietrios de classes, criando uma equipe para implementar aquela funcionalidade. O programador-chefe age como um coordenador, designer lder e mentor, enquanto os proprietrios de classes fazem a maior parte da programao das funcionalidades.

Proprietrios de cdigo/classes: So os desenvolvedores da equipe. Codificam, projetam e fazem anlise de cdigo a qualquer nvel. Possuem propriedade sobre o cdigo, de forma que ficam responsveis pela parte de cdigo que lhes foi designada. Assim, so diretamente responsveis pela legibilidade, bom design e clareza do cdigo.

Especialistas do domnio: Podem ser membros externos ou internos do projeto. Interno seria algum membro designado para entender completamente as necessidades do cliente de modo que pudesse represent-lo nas reunies da equipe. Externo no caso de o prprio cliente participar das reunies no projeto. So as pessoas que mais conhecem sobre o assunto abordado. O objetivo deles passar para a equipe o mximo de conhecimento sobre o domnio, de modo que os membros da equipe possam tambm se tornar experts no domnio.

Gerente de configurao: Membro responsvel por controlar o cdigo fonte de todo o sistema, mantendo sempre atualizadas as alteraes realizadas ao trmino ou incio de cada funcionalidade. Normalmente o gerente de configurao assume outros papis relativos configurao dos sistemas da equipe de desenvolvimento, aliviando a quantidade de trabalho desperdiada pelos desenvolvedores com problemas relativos a falhas tcnicas das mquinas (formatao do sistema, backups, troca de mouses ou teclados e etc.) entre outras coisas.

30

Testador: Membro responsvel por testar as funcionalidades implementadas pelos desenvolvedores do projeto. Escrever testes, casos de teste e testar funcionalidades manualmente so as principais tarefas do testador.

Redator tcnico: Responsvel pela documentao gerada nas reunies de planejamento da equipe. Dessa maneira, alivia os membros da equipe de trabalhos relativos escrita de documentos, focando exclusivamente na modelagem e construo das funcionalidades.

2.4.2 Boas prticas

Feature Driven Development possui um conjunto de boas prticas baseadas nas prticas de engenharia de software. Essas prticas so baseadas na viso de valor do cliente, e no da equipe de desenvolvimento [23]. justamente essa fuso de prticas e tcnicas que torna o FDD to til. Algumas prticas que tm sido amplamente aproveitadas no mercado de desenvolvimento de software so listadas. Modelagem do domnio: Explora e explica o domnio do problema a ser resolvido tendo como perspectiva a orientao a objetos. Esta considerada uma boa prtica, pois ajuda a descrever o domnio da aplicao, provendo uma modelagem genrica de alto nvel no qual podem ser adicionadas vrias funcionalidades. Desenvolvimento por funcionalidade: Qualquer atividade a ser desenvolvida deve ser analisada para verificar se esta pode ser quebrada em atividades menores, ou funcionalidades atmicas (indivisveis). Essa prtica torna o cdigo inteiro mais seguro contra erros. Alm do mais, garante flexibilidade e escalabilidade ao cdigo [24]. Posse sobre o cdigo: Em FDD, os desenvolvedores possuem individualmente posse de cdigo. Por exemplo, a classe A, B e C pertencem ao programador 1, enquanto as classes X, Y e Z pertencem ao programador 2. O proprietrio do cdigo torna-se automaticamente responsvel pela performance, consistncia, corretude e integrao da classe. O proprietrio aconselhado a utilizar os melhores padres da engenharia de software. No entanto, est livre para criar seus prprios padres. Equipes de funcionalidades: So equipes pequenas responsveis por desenvolver uma pequena atividade. Dessa forma, a equipe decide de forma conjunta como ser feito o

31

design de determinada funcionalidade. Com mais de uma pessoa pensando no mesmo problema, solues diferentes podem surgir. O que se torna muito eficiente, visto que no final essas solues podem ser fundidas em uma soluo final da equipe. Inspees: Inspeo de cdigo uma tima prtica de engenharia, pois alm de fazer verificaes contra erros, incentiva uma melhor modelagem do sistema, junto com atributos como legibilidade e alta coeso. Gerncia de configurao: Essa prtica tem como objetivo manter um controle sobre o cdigo fonte das funcionalidades implementadas, mapeando as funcionalidades aos seus respectivos cdigos-fontes e aos seus proprietrios. Alm disso, mantm as datas de modificao do cdigo, guardando um histrico de alteraes. Build constante: Deve existir sempre uma verso do sistema rodando numa mquina. Isso garante que a equipe possui pelo menos uma verso do sistema que funciona. Dessa forma, sempre que for necessrio apresentar alguma funcionalidade para o cliente, existir uma verso do sistema que pode ser utilizada para isso. Visibilidade do progresso: Como sempre mantido um relatrio de progresso das atividades do projeto, todos na equipe e fora dela sabem exatamente como esto em termos de produtividade. No entanto, essa atividade deve ser feita com muita preciso e frequncia. Caso contrrio, os dados extrados do relatrio sero enganosos e podero levar a decises desastrosas para o cliente. 2.4.3 Fases

O Feature Driven Development dividido em 5 atividades, cada uma destas possuindo sub-atividades que compem o processo como um todo. Essas 5 atividades so (em ordem) [23]: Desenvolver um modelo geral, gerar uma lista de funcionalidades, planejar por funcionalidade, modelar por funcionalidade e construir por funcionalidade. As trs primeiras so realizadas uma vez antes da realizao do projeto e as 2 restantes so realizadas a cada iterao. Todas essas atividades sero explicadas e suas sub-atividades sero listadas nesse tpico.

32

Desenvolver um modelo geral: O projeto comea com uma anlise superficial do escopo do sistema e seu contexto. Assim, so estudados os domnios de negcio do sistema e criado um modelo geral baseado nestes. Depois criada uma modelagem superficial para cada rea de domnio existente. Cada um desses modelos revisado por um grupo aleatrio de membros do projeto e melhorias so discutidas. escolhido o modelo de domnio melhor projetado, ou seno escolhido um modelo que a juno de mais de um domnio projetado. Finalmente, os modelos escolhidos para cada rea de domnio so fundidos para gerar um modelo do domnio como um todo (ou domnio principal) do sistema.

Sub-atividades: Formar equipe de modelagem; Estudar o domnio de negcio; Estudar os documentos; Formar vrias equipes pequenas para sugerir uma soluo de modelo; Desenvolver o modelo escolhido; Refinar o modelo geral gerado; Escrever notas explicativas sobre o modelo final;

Gerar uma lista de funcionalidades: O conhecimento obtido na fase de desenvolvimento do modelo geral essencial para esta fase. Nesta, ser elaborada uma lista de funcionalidades do sistema decompondo as reas de domnio obtidas. Cada funcionalidade uma pequena tarefa a ser implementada que gere valor para o cliente. Devem seguir o formato , por exemplo: Gerar relatrio de vendas ou Validar a senha do usurio. Essas funcionalidades so muito importantes para o processo como um todo. A no identificao delas causa um impacto enorme sobre o projeto, pois significa que a primeira fase no foi feita com sucesso e consequentemente os efeitos aparecem em cascata nas prximas fases [22].

Sub-atividades: Escolher uma equipe para gerar uma lista de funcionalidades; Gerar a lista de funcionalidades.

33

Planejar por funcionalidade: realizado o planejamento de desenvolvimento de cada funcionalidade da lista obtida da fase anterior. So designadas classes ou cdigo especfico para os programadores-chefe tomarem conta. Da em diante, os programadoreschefe sero responsveis pelo cdigo produzido nessas classes.

Sub-atividades: Formar uma equipe de planejamento Determinar a sequncia de desenvolvimento das funcionalidades; Designar atividades de negcio para os programadores-chefe; Designar classes para os desenvolvedores.

Modelar por funcionalidade: Os programadores-chefe escolhem algumas funcionalidades para que, junto com os proprietrios de cdigo, sejam feitos os diagramas de sequncia e a modelagem completa das funcionalidades. A diferena desta modelagem para a modelagem feita na primeira fase que esta especfica para a funcionalidade em questo. Ou seja, nesta etapa pensa-se nas classes, mtodos e atributos que iro existir. Ao final da modelagem, realizada uma inspeo do modelo pela equipe que a fez ou por outra equipe designada.

Sub-atividades: Formar uma equipe para a funcionalidade em questo; Estudar a funcionalidade como parte inserida no modelo de domnio; Estudar documentos relacionados funcionalidade; Desenvolver diagrama de sequncia; Refinar objeto modelo; Escrever as classes e as assinaturas dos mtodos (tipo de retorno, parmetros e excees lanadas); Realizar inspeo da modelagem.

34

Construir por funcionalidade: Aps a modelagem, o cdigo finalmente implementado e os testes finalmente escritos. Assim, o cdigo fonte produzido e as funcionalidades ganham vida. O programador-chefe designa um programador para implementar uma certa funcionalidade. Logo, este ltimo ser o proprietrio do cdigo escrito. Aps uma inspeo no cdigo escrito, a funcionalidade terminada.

Sub-atividades: Implementar as regras de negcio das classes; Inspecionar cdigo; Conduzir testes unitrios; Release da funcionalidade.

Figura 3. Os 5 processos do FDD.[24]

2.4.4 Vantagens e desvantagens

Por ser orientado a modelo e utilizar logo cedo no projeto (na fase de Desenvolvimento de um modelo geral) transferncia de conhecimento ao utilizar vrias equipes para projetar vrias solues para o domnio pedido, FDD agrega valor aos membros das equipes [24]. E ainda por cima, o conhecimento do domnio estar crescendo de forma similar atravs de todos os membros de todas as equipes. Isso possvel pelo fato

35

de a modelagem realizada inicialmente ser feita de maneira superficial e no especfica, habilitando todos os membros das equipes a aprenderem sobre o domnio. Para um gerente de projeto, ter um modelo preciso para poder se basear essencial para o andamento do projeto. Para se ter esse modelo preciso, deve haver algum tipo de atividade de anlise que gere informao. exatamente o que faz a primeira fase do FDD [24]. FDD torna o trabalho do gerente de projeto mais fcil ao medir o progresso de cada funcionalidade em termos de valor para o cliente. Se todo o projeto feito utilizando a noo de valor do cliente, ser mais fcil discutir assuntos como mudanas e escopo do projeto. Ou seja, unifica a linguagem utilizada por todos no projeto, incentivando a comunicao de todos os pontos. FDD enfatiza bastante a modelagem do sistema. Apesar de a ltima fase ser implementao do cdigo, a fase mais crtica dessa metodologia a fase de modelagem das funcionalidades. A arquitetura do sistema analisada em quase todas as fases. Por estar sempre sendo testada, a modelagem do sistema tende a ser mais flexvel e reutilizvel. Apesar de possuir um ciclo completo de documentao, a especificao original da aplicao no comenta sobre sua aplicabilidade a manuteno de sistemas. Este um ponto em aberto para a metodologia FDD [22]. Por ser extremamente focado em documentao de modelagem do sistema, FDD foge um pouco de um dos princpios do Manifesto gil: Software funcional sobre documentao abrangente.. Muita documentao produzida durante as 4 primeiras fases e o cdigo s realmente experimentado na ltima fase, perdendo prioridade diante de outras atividades de modelagem. Por possuir vrios papis, fica evidente que uma equipe FDD no pode ser muito menor que o nmero de papis existentes na metodologia. Caso isto ocorra, uma mesma pessoa passar a assumir vrias responsabilidades distintas dentro de uma mesma equipe. Assim, o foco deste membro no ser to consistente, poder ocorrer sobrecarga de trabalho e conflitos de interesses, causando impacto sobre o projeto.

36

2.5 Anlise Comparativa

As 3 metodologias analisadas possuem um objetivo comum: conferir agilidade ao processo de desenvolvimento de software ganhando eficincia. Porm, as trs possuem caractersticas diferentes. So essas caractersticas que sero comparadas neste tpico. No quadro abaixo so mostrados alguns atributos e como as metodologias se adaptam a estes. Observe a legenda: * - 1 asterisco (Acontece com freqncia razovel) ** - 2 asteriscos (Acontece com freqncia alta) - 0 asterisco (Ausncia desse atributo)

Caractersticas/Metodologia Equipes pequenas nfase no modelo nfase gerencial Interao Cliente/Desenvolvedor Gerenciamento de risco Projetos grandes/complexos Stand-up meetings Especialista em

FDD ** * *

XP * **

SCRUM ** ** **

* **

** *

* ** -

37

documentao Cdigo coletivo ** *

Tabela 1. Anlise comparativa entre Scrum, XP e FDD.

Analisemos agora, essas caractersticas uma por uma. Equipes pequenas:

Scrum: Em Scrum existem poucos papis (Scrum Master, Product Owner e membro da equipe) que no podem ser acumulados por um mesmo membro. Alm disso, as tcnicas gerenciais do Scrum so muito flexveis, podendo ser usadas em projetos no ligados a rea de software, inclusive com pouqussimas pessoas numa equipe. XP: Prega-se a comunicao pessoal como um dos princpios da metodologia. Comunicao que deve ser feita a todo momento entre os membros de uma equipe. Obviamente, esse princpio melhor colocado em prtica no caso de equipes pequenas.

FDD: Como envolve muitos papis entre os membros e esses papis no podem ser exercidos pela mesma pessoa por questes de conflitos de interesses, FDD no d margem para equipes muito pequenas. Normalmente, quando bem distribudos entre os membros, os papis so de vital importncia para o sucesso do projeto. XP e Scrum no possuem este problema.

nfase no modelo:

Scrum: Em Scrum no h essa preocupao com a arquitetura do sistema, pois a metodologia no foi projetada com o intuito exclusivo de ser utilizada no desenvolvimento de software [7]. Assim, a nfase nas interaes entre os indivduos.

XP: Em XP, a nfase na codificao/manuteno do cdigo.

38

FDD: a nica destas trs metodologias que possui um foco na arquitetura ou modelagem do sistema. Nesta metodologia, a arquitetura pensada desde a primeira fase do ciclo iterativo e passa por inspees durante todas as outras fases [23].

nfase gerencial:

Scrum: uma metodologia focada em processos gerenciais [7]. No existe uma lista de tcnicas agregadas aos processos de Scrum assim como existe em XP, por exemplo. Por outro lado, existe uma carga maior de prticas gerenciais que incentivam agilidade em equipe quando comparado a outras metodologias geis.

XP: uma metodologia orientada a processos de desenvolvimento. Assim, no possui nfase gerencial.

FDD: Possui certa nfase gerencial. Existem membros dentro de uma equipe FDD responsveis por outros setores. Por exemplo, programador-chefe um papel gerencial, no sentido de que coordena os desenvolvedores nas atividades destes. Por sua vez, respondem a superiores (gerentes de equipe), afirmando um carter gerencial a metodologia.

Interao cliente/desenvolvedor:

Scrum: Por ser uma das principais caractersticas das metodologias geis, todas as trs metodologias mencionadas aplicam-na de alguma forma. Scrum aplica intensivamente, visto que o Product Owner faz o papel do cliente durante a Sprint e suas cerimnias. Assim, participa das reunies de planejamento junto aos desenvolvedores e explica os requisitos pessoalmente, priorizando os de maior necessidade. O ideal que o Product Owner seja o prprio cliente ou algum representante do cliente. No entanto, caso isso no seja possvel, a equipe do projeto designar um membro experiente para estudar as necessidades do cliente e executar o papel deste. Dessa maneira, em Scrum, sempre h um alto nvel de interao entre os desenvolvedores e o cliente.

39

XP: Este na verdade um dos poucos requisitos do XP. O cliente deve estar presente todo momento. No apenas para ajudar o time de desenvolvimento, mas tambm para ser parte dele. Todas as fases de um projeto XP dependem de comunicao com o cliente, de preferncia cara a cara [14]. O cliente escrever estrias junto com os desenvolvedores, avaliar funcionalidades implementadas e daro feedback o mais rpido possvel para a equipe de desenvolvimento.

FDD: Existe interao com o prprio cliente. O cliente deve estar sempre presente nas reunies de planejamento e principalmente durante a primeira fase de modelagem do ciclo. O cliente normalmente tambm o especialista no domnio, explicando as regras de negcio para os arquitetos e os programadores-chefe. Entretanto, como os programadores-chefe no so propriamente desenvolvedores, o contato entre o cliente e os desenvolvedores ser realizado indiretamente, diminuindo a intensidade da interao Cliente/Desenvolvedor. Alm disso, os desenvolvedores comeam a trabalhar baseados na modelagem existente do sistema, a qual tarefa dos arquitetos e programadores-chefe junto ao cliente.

Projetos grandes e complexos:

Scrum: Scrum foi primeiramente pensado para controlar grupos pequenos. No entanto, pode ser escalvel para trabalhar com grupos de 50 ou 60 pessoas [7]. Mas, nesse caso necessrio dividir o grupo em grupos menores e executar um Scrum de Scrums, onde cada grupo utiliza Scrum internamente e um Scrum Master controla as interaes entre os grupos existentes. Alm disso, por haver uma quantidade grande de pessoas trabalhando num mesmo projeto, torna-se mais difcil a comunicao cara-a-cara entre elas, prejudicando a obedincia ao princpio da comunicao no Scrum.

XP: Segue o mesmo princpio de pequenas equipes auto-organizadas que existe no Scrum. Semelhantemente, pode ser escalvel para grandes equipes em grandes projetos, mas originalmente foi idealizado para equipes pequenas com poder de deciso prprio.

40

FDD: O primeiro projeto utilizando FDD foi realizado para um banco em Cingapura no ano de 1997. Neste projeto, participavam 50 pessoas e o prazo era de 15 meses [22]. Assim, a prpria origem da metodologia indica que FDD pode ser utilizado em projetos grandes sem necessitar repartir os membros em pequenos grupos de FDD. Isto se d pelo perfil hierrquico ao qual a metodologia se apega. Diferentemente de XP e Scrum, FDD possui uma hierarquia especfica, podendo assim delegar grupos de pessoas sob a responsabilidade de um membro, por exemplo, um gerente. o que acontece entre os papis de desenvolvedor e programador-chefe - vrios desenvolvedores esto subordinados a um ou mais programadores-chefe.

Gerenciamento de riscos:

Scrum: A cada Daily Scrum, a equipe se rene e conversa sobre o que foi feito desde a ltima reunio at ento. So discutidos tambm possveis impedimentos e riscos que podem atrapalhar o trabalho de desenvolvimento da equipe. Os membros da equipe devem se sentir absolutamente livres para expressar algo que est ameaando a equipe: influncias externas, falta de recursos, desmotivao, falta de clareza nos requisitos, entre outros. Esse impedimento escrito em um carto e colado no Dashboard da equipe, indicando para o Scrum Master que existe um obstculo a ser retirado. uma forma rpida e descomplicada de levantar riscos e elimin-los (sempre que possvel) [8]. Por outro lado, no h um plano explcito para (1) identificar riscos, (2) estabelecer estratgias de gerenciamento de riscos e (3) mitigar riscos.

XP: Como a nfase no processo de desenvolvimento e no no processo de gerncia, no h uma base para tratar riscos em XP.

FDD: Cabe ao gerente de projeto identificar e eliminar riscos durante o projeto. No existe um documento de Gerenciamento de Riscos assim como tambm no h impedimentos levantados pela equipe. Os riscos so vigiados pelo gerente de

41

projeto e tratados de acordo com sua estratgia. O objetivo dessa abordagem diante de riscos justamente evitar se concentrar em problemas gerenciais, de modo a se concentrar principalmente no design e conseqente implementao do sistema.

Stand-up meetings:

Scrum: Esse estilo de reunio proposto inicialmente na metodologia XP utilizado tambm por Scrum. Em Scrum, essas reunies so chamadas de Daily Scrum e as equipes programam um horrio especfico para realiz-la todos os dias.

XP: No h um horrio especfico para realizar essas reunies. desejvel que seja realizada todos os dias, mas no uma cerimnia formal e qualquer membro da equipe pode convocar um stand-up meeting a qualquer momento [13].

FDD: Apesar de a comunicao interna ser estimulada, no existem traos especficos deste estilo de reunio entre os membros de uma equipe.

Especialista em documentao:

Scrum: No h um redator tcnico. O prprio Scrum Master ou Product Owner se responsabilizam pela documentao produzida.

XP: Em XP, existe um especialista em documentao assim como no FDD, se responsabilizando sobre documentos de requisitos, casos de uso, mudanas de requisitos, entre outros. No entanto, como esses documentos s so produzidos quando promovem algum valor para o cliente, a importncia do redator tcnico no to grande.

FDD: Como FDD d muita ateno documentao produzida durante a modelagem, uma pessoa responsvel por estes documentos: o redator tcnico. Este responsvel por aliviar a carga sobre os desenvolvedores e gerentes, tomando conta da documentao produzida durante as fases de desenvolvimento.

42

Cdigo coletivo:

Scrum: Quando utilizado em projetos de software, no prega abertamente a coletividade do cdigo. No entanto, seus princpios se adquam a esta caracterstica advinda do XP [18]. Quando uma estria est sendo implementada, a equipe inteira j se comprometeu com aquela estria. Logo, toda equipe deve ter acesso ao cdigo fonte e liberdade para modific-lo.

XP: Possui a coletividade do cdigo como um princpio [13]. O cdigo pertence equipe e todos devem estar cientes disso. Esse princpio estimulado por outra tcnica de XP - Pair-Programming. Ferramentas de desenvolvimento como CVS e SVN so utilizadas como forma de repositrio para o cdigo implementado.

FDD: Designa alguns membros especficos como proprietrios de classe. Isso bate de frente com a idia de cdigo coletivo pregada por XP. Na verdade, FDD foi pensado realmente desta forma. Seu criador, Jeff De Luca, escreveu que cdigo coletivo no uma estrutura em que ele realmente acredita [22].

43

3. TCNICAS E ABORDAGENS GEIS

Neste captulo sero apresentadas algumas tcnicas geis de desenvolvimento bastante utilizadas na indstria de software. As explicaes sobre essas tcnicas de engenharia so breves e enfatizam trs pontos: funcionamento; benefcios de aplicar a tcnica; e limitaes desta. 3.1 Test Driven Development

Test Driven Development uma tcnica de desenvolvimento de Software que utiliza pequenas iteraes de desenvolvimento atravs de testes unitrios escritos antes de ser escrito o cdigo pertencente funcionalidade em questo. Cada iterao produz cdigo necessrio exclusivamente para passar pelos testes daquela iterao. Quando essa fase de iteraes termina, o programador faz um refactor no cdigo gerado. 3.1.1 Como funciona

1. Criando um teste: Antes de uma funcionalidade ser criada, o programador escreve um teste para ela. Obviamente, nesta primeira tentativa o teste ir falhar. Mas ele deve falhar, porque no h como testar uma funcionalidade sem antes constru-la. A grande vantagem de escrever um teste antes de implementar uma funcionalidade que o desenvolvedor ir pensar nos requisitos antes de codificar, ao contrrio do que se faz normalmente. essencial que o programador entenda bem a regra de negcio em questo antes de escrever o teste, pois dessa forma, evita escrever um teste errado do ponto de vista da lgica de negcio, anulando o teste [8]. 2. Teste o teste: O prximo passo rodar todos os testes e verificar se o teste em questo passa. Se ele passar, significa que intil, pois est aprovando cdigo que na verdade no deveria passar (a funcionalidade correspondente daquele teste ainda no existe). Esse passo realizado com o propsito de assegurar para 44

o programador que esse teste realmente est funcionando de forma correta, falhando quando deve falhar [8]. 3. Escreva cdigo: O programador deve escrever cdigo correspondente a funcionalidade testada. Ou seja, implementar a funcionalidade exclusivamente para o respectivo teste passar. Caso o teste passe mas de alguma forma o programador no tenha ficado satisfeito com a forma como isso aconteceu, no se deve ajustar o cdigo imediatamente. Esse passo est mais adiante. 4. Faa todos os testes passarem: O prximo passo rodar todos os testes e verificar se passaram com a incluso do novo teste em questo. Caso acontea algum erro em qualquer dos testes, o programador repete o passo anterior at que o teste passe. 5. Faa o refactor: Finalmente, aps o novo teste passar junto com todos os testes existentes anteriormente, o programador deve limpar o cdigo. Isso pode envolver vrias coisas, como por exemplo, remover cdigo duplicado ou melhorar desempenho [11]. Nesse passo que sero feitas as adaptaes necessrias de acordo com a vontade do programador, por exemplo, remover algum artifcio tcnico (um if a mais ou algum nmero mgico colocado no cdigo para fazer o teste passar). Caso acontea algum erro em qualquer dos testes, o programador deve voltar aos passos 3 e 4, at que o teste passe e o cdigo esteja refatorado de maneira satisfatria. 6. Loop: Com o cdigo pronto e todos os testes passando, o programador deve passar para a prxima iterao, repetindo o ciclo desde o comeo. importante que o tamanho das alteraes seja pequeno, forando o programador a pensar em cada pequena etapa individualmente. uma forma de usar a abordagem Dividir para Conquistar para assegurar que, se as pequenas partes do cdigo esto funcionando e seus respectivos testes esto sendo aprovados, a aplicao como um todo ir funcionar e estar completamente testada [9].

45

Figura 4. Grafo mostrando as etapas do Test Driven Development. [12]

3.1.2 Benefcios

Um estudo realizado em 2005 mostrou que os programadores que utilizavam TDD escreviam mais testes e, por sua vez, programadores que escreviam mais testes tinham a tendncia de ser mais produtivos [10]. Logo, Test Driven Development indicado para equipes de desenvolvimento que desejam construir software de forma mais rpida sem perder qualidade. Essa tcnica oferece mais do que apenas corretude, mas pode tambm melhorar a arquitetura do software. Um grande benefcio obtido por utilizar TDD a capacidade de uma aplicao inteira em pequenos passos. Isso significa que o programador ir se concentrar na tarefa atual - fazer o teste passar sem interferir nos outros testes j aprovados. Cada pequena parte do cdigo ser analisada cuidadosamente e ter a ateno do programador, cada uma por

46

vez. Casos excepcionais e erros complexos no so considerados inicialmente. Para esses casos especiais, devem ser criados separadamente testes para verific-los [9]. Outra vantagem de se utilizar TDD num projeto de desenvolvimento de software a grande cobertura de testes provida pela tcnica. Se as pequenas partes do cdigo esto funcionando e testadas, o cdigo como um todo estar seguro. Alm disso, a futura manuteno do cdigo ser mais fcil e uma grande margem de segurana quanto a erros ser dada aos clientes. Normalmente um programador que utiliza TDD escreve mais testes (e consequentemente mais cdigo) do que um programador que no utiliza TDD [10]. No entanto, o tempo total de implementao menor utilizando TDD [8]. Uma grande quantidade de testes limita a quantidade de erros num projeto de software. Se esses testes forem aprovados junto com o trmino das funcionalidades, ou seja, no incio do projeto, haver uma base concreta de preveno contra erros endmicos, poupando o desenvolvedor do trabalho de lenta e custosa depurao de cdigo. TDD tende a deixar o cdigo mais flexvel, modularizado e extensvel. Esse efeito obtido pela caracterstica do prprio TDD de analisar cada parte do cdigo individualmente quanto corretude e design. Dessa forma, as classes tendem a ser menores, centradas num s objetivo e com baixo acoplamento. Ao incentivar os desenvolvedores a programarem o suficiente apenas para o teste correspondente passar, TDD torna o cdigo mais simples e fcil de entender. 3.1.3 Limitaes

Assim como toda tcnica de engenharia, TDD tambm tem seus pontos fracos, por assim dizer. Na verdade, so situaes onde se torna difcil aplicar seus conceitos e obter bons resultados.

47

Ao desenvolver partes do cdigo concernente a interfaces grficas o TDD no proveitoso porque nesse caso so necessrios testes completamente funcionais. Qualquer outra situao que exigir testes completamente funcionais no se aplica a TDD [9]. Em casos onde a organizao/empresa inteira no est totalmente convencida de que TDD aumenta a agilidade e a produtividade, TDD no costuma obter sucesso. Isso acontece pelo fato de, mais cedo ou mais tarde, a gerncia comea a achar que o tempo gasto escrevendo testes tempo desperdiado [9]. Visto que nesta tcnica o desenvolvedor escreve os testes para o cdigo que ele mesmo implementou, pode haver algum ponto cego, ou seja, um pedao de cdigo implementado com potencial de erro, mas nenhum teste escrito para este pedao. Pair Programming pode ser a soluo nesses casos. Se o desenvolvedor no entendeu completamente o fundamento do TDD, ao criar os testes para seu prprio cdigo, ele pode cair no erro de simplesmente querer fazer os testes passarem para livrar seus cdigos de erros, sem realmente analisar se os testes so efetivos. Isso gera um falso senso de segurana na equipe desenvolvedora e, uma vez que encontrados os erros, o prejuzo ser muito maior. 3.2 Outras tcnicas

Existem inmeras outras tcnicas de engenharia que podem tornar o desenvolvimento de software mais rpida e de melhor qualidade. Essas tcnicas apresentadas aqui no so consideradas tcnicas geis propriamente ditas, mas, so tcnicas que aceleram o desenvolvimento de software dentro de uma empresa. No entanto, abordamos aqui duas tcnicas que se mostram muito populares atualmente na indstria de desenvolvimento de software. A primeira delas Design Patterns, que uma tcnica de modelagem/desenvolvimento de software. E a segunda delas Controle de Verso, que uma tcnica de suporte ao desenvolvimento de software.

48

3.2.1 Design Patterns

Design Patterns, termo conhecido em portugus como padres de projeto ou padres de desenho de software, descrevem solues para problemas decorrentes no desenvolvimento de sistemas de software orientados a objetos. Por padro, um design pattern descreve [26]:

Um problema recorrente; Uma soluo; Quando aplicar a soluo; Conseqncias.

Os objetivos dos design patterns so: permitir o reuso do cdigo, facilitar o design das classes orientadas a objetos e melhorar a documentao e o aprendizado de um projeto de software. Para isso, o padro precisa definir uma soluo para um problema especfico, ser independente e mostrar claramente onde se aplica. Os design patterns GoF (Gang of Four) totalizam 23 design patterns documentados e catalogados, que so, ao mesmo tempo, os mais populares e mais utilizados entre desenvolvedores de software na indstria [26]. Esses design patterns so divididos em 3 categorias ou tipos de padro: Criacional: Esse padro lida com a melhor forma de se criar instncias de classes. A idia que um programa no dependa da forma como os objetos e classes so criados e inicializados dentro dele. Os padres criacionais so: o Abstract Factory; o Builder; o Factory Method; o Prototype; o Singleton.

49

Estrutural: Este padro lida com a implementao das classes e dos objetos. Tem por objetivo suavizar o design do sistema por identificar formas de realizar relacionamentos entre entidades existentes no modelo de uma maneira simples. Os padres estruturais so: o Adapter; o Bridge; o Composite; o Decorator; o Faade ou Fachada; o Flyweight; o Proxy.

Comportamental: Tem por objetivo encontrar dinamicamente padres de comunicao entre objetos e identificar esses padres. Dessa forma, os padres comportamentais aumentam a flexibilidade na forma como a comunicao exercida. Os padres comportamentais so: o Chain of Responsability; o Command; o Iterator; o Mediator; o Memento; o Observer; o State; o Strategy; o Template Method; o Visitor.

O uso de design patterns durante a etapa de desenvolvimento de software possui diversas vantagens. Para os desenvolvedores de uma equipe extremamente produtivo, pois incentiva uma forma clara e otimizada de comunicao. Projetistas de software podem discutir a soluo para um problema de forma transparente, visto que todos na equipe de

50

desenvolvimento entendem os padres de projeto. O tempo de aprendizado da equipe de desenvolvimento reduzido drasticamente [27]. Tambm, prov uma melhor forma de documentar solues e resolver problemas de maneira prtica. Alm disso, por ter sido utilizada em diversos projetos que apresentaram o mesmo problema, essas solues mostram-se comprovadamente eficazes. Padres de projeto tornam o cdigo mais coeso e com acoplamento mnimo, atributos desejveis de engenharia de software [27]. A complexidade do cdigo reduzida por causa da forma como so tratadas as abstraes de classes e instncias. Por apresentar atributos como rapidez no processo de aprendizagem dos desenvolvedores, transparncia das solues apresentadas, alto nvel de reuso de cdigo no sistema, baixo nvel de complexidade, praticidade ao resolver problemas recorrentes e melhoria na capacidade de expresso da equipe, os padres de projeto mostram ser uma tcnica de engenharia bastante eficaz para ser utilizada durante a fase de codificao/modelagem de software.

3.2.2 Controle de verso

Um sistema de controle de verso um software que tem por finalidade gerenciar as verses geradas de um software durante todo o processo de fabricao deste [28]. Na verdade, estes softwares so utilizados para salvar histrico de modificaes de qualquer documento. Entretanto, na indstria de softwares eles so extremamente necessrios por guardar diferentes verses de cdigo-fonte e documentao do projeto. Sistemas de controle de verso so muito populares atualmente e podem ser encontrados em forma de softwares livres, como CVS e SVN, ou softwares comerciais, como o ClearCase da IBM. Uma diferena entre as solues comerciais e livres, que as verses livres no oferecem garantia contra erros, por exemplo, perda de dados. Por outro lado, as verses livres possuem melhor performance e maior segurana contra ataques externos [28].

51

O funcionamento bsico de um sistema de controle de verso bastante simples e pode ser explicado brevemente por meio dos elementos que compem este sistema [28]: Servidor: Uma mquina que possui espao para armazenamento de arquivos. Deve possuir um endereo lgico, que pode ser uma URL ou um conjunto IP/porta. Esse endereo necessrio para o cliente poder se conectar ao servidor. Repositrio: o sistema de arquivos responsvel por armazenar os dados gravados dos documentos. Esses dados devem ser guardados de forma persistente (como num banco de dados) e facilmente resgatveis. Um servidor pode possuir mais de um repositrio. Por exemplo, o repositrio A conter os arquivos produzidos pelo projeto X. Enquanto o repositrio B armazenar os arquivos produzidos pelo projeto Y. Cpia local: Todo desenvolvedor possui em sua mquina uma cpia dos seus documentos. Esses documentos so sempre a verso mais atual existente no sistema. Quando um desenvolvedor resolve salvar (fazer um commit) um documento no sistema de controle de verso pela primeira vez, este documento fica salvo no repositrio especificado pelo desenvolvedor. Caso outro desenvolvedor do mesmo projeto que possui acesso ao documento salvo faa uma alterao na sua cpia local e deseje salv-la no respositrio, o sistema no permitir. De fato, o sistema indicar para este usurio que ele possui uma verso desatualizada daquele documento. Uma vez que o desenvolvedor atualiza a verso mais nova do documento, ele capaz de alterar este documento e salv-lo no sistema novamente. Num projeto de software, extremamente til manter um histrico das verses do produto em desenvolvimento. exatamente esse o objetivo dos sistemas de controle de verso. Esses sistemas oferecem facilidade ao fazer/desfazer modificaes nos documentos do projeto, possibilitando uma anlise do histrico de desenvolvimento. Alguns sistemas, como CVS e SVN, por exemplo, exibem at mesmo comparaes entre verses produzidas

52

[29]. Assim, todos os elementos da equipe podem compartilhar cdigo-fonte do sistema em desenvolvimento sem medo de fazer alteraes irreversveis. Alm disso, o cdigo se torna acessvel e compreensvel por todos da equipe, promovendo a integrao entre os membros. Ao mesmo tempo, evita conflitos de verses, que pode ocorrer sempre que dois usurios esto modificando um mesmo arquivo ao mesmo tempo. Muitos sistemas permitem que os usurios salvem uma verso estvel do projeto inteiro ou tag. A idia que, caso o lanamento de uma nova verso acontea com erros, fazendo surgir uma verso instvel, possvel pedir ao sistema para voltar ltima verso estvel do projeto [28]. Assim, uma equipe de desenvolvimento pode sempre possuir uma verso relativamente estvel do produto em desenvolvimento, facilitando inclusive a manuteno do software. Sistemas de controle de verso mostram-se tambm ser uma ferramenta de suporte que confere agilidade ao projeto. Ao utilizar esse sistema, uma equipe de desenvolvimento pode desenvolver funcionalidades em paralelo, sem que uma interfira na outra.

3.3 Domain Driven Design Uma abordagem gil

Modelagem de software como uma arte e no pode ser ensinada como uma cincia exata por meio de frmulas e teoremas. Podem ser utilizados princpios e mtodos para melhorar a construo de um software, no entanto, jamais existir um caminho exato a ser seguido para prover as necessidades de um sistema no mundo real com um software. Assim como na construo de um prdio, a construo de um software ir refletir caractersticas das pessoas que o modelaram e o implementaram. Existem vrias formas de abordar o modelo de um sistema. Nos ltimos 20 anos, a indstria de software tem utilizado vrios mtodos de modelagem para criar seus produtos, cada um deles com suas vantagens e desvantagens [26]. O objetivo deste tpico abordar uma abordagem de modelagem que tem sido aprimorada por mais de duas dcadas,

53

contudo, tem se afirmado mais claramente como um mtodo h poucos anos: Domain Driven Design (DDD). DDD uma abordagem da modelagem que visa tornar a idealizao e consequentemente a construo de software mais gil, fazendo isso de uma forma transparente a todos envolvidos no processo. DDD combina prticas de modelagem e desenvolvimento, e mostra como bom design e desenvolvimento podem trabalhar juntos para criar uma soluo tima. Um bom design ir acelerar o desenvolvimento, enquanto feedback constante provido por parte do desenvolvimento aumentar a qualidade do design.[25] 3.3.1 Conhecimento do domnio

Como o prprio nome da tcnica diz, o foco desta tcnica o domnio de negcio. Por onde comear a idealizao de um