Desenvolvimento gil de software Desenvolvimento gil de software (do ingls Agile software development) ou Mtodo gil um conjunto de metodologias de desenvolvimento de software. O desenvolvimento gil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.

1 Introduo 2 Princpios 3 Histria 4 Comparaes com outros mtodos

o o o

4.1 Comparao com o desenvolvimento iterativo 4.2 Comparao com o modelo em cascata 4.3 Comparao com a "codificao cowboy"

5 Aplicabilidade dos mtodos geis 6 Adaptabilidade dos mtodos geis 7 Mtodos geis e o gerenciamento de projeto 8 Metodologias 9 Crticas

Introduo Existem inmeras metodologias de desenvolvimento de software rpido. A maioria dos mtodos geis tenta minimizar o risco pelo desenvolvimento do software em curtos perodos, chamados de iterao. Cada iterao como um projeto de software em miniatura de seu prprio, e inclui todas as tarefas necessrias para implantar uma nova funcionalidade: planejamento, anlise de requisitos, projeto, codificao, teste e documentao. Mtodos geis enfatizam comunicaes em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo gil devem estar agrupados em uma sala. Isto inclui todas as pessoas necessrias para terminar o software. No mnimo, isto inclui os programadores e seus clientes (clientes so as pessoas que definem o produto, eles podem ser os gerentes, analistas de negcio, ou realmente os clientes). Nesta sala devem tambm se encontrar os testadores, projetistas de iterao, redatores tcnicos e

gerentes. Mtodos geis tambm enfatizam trabalho no software como uma medida primria de progresso. Combinado com a comunicao face-a-face, mtodos geis produzem pouca documentao em relao a outros mtodos, sendo este um dos pontos que podem ser considerados negativos. recomendada a produo de documentao que realmente ser til. Histria As definies modernas de desenvolvimento de software gil evoluram a partir da metade de 1990 como parte de uma reao contra mtodos "pesados", caracterizados por uma pesada regulamentao, regimentao e micro gerenciamento usado no modelo em cascata para desenvolvimento. O processo originou-se da viso de que o modelo em cascata era burocrtico, lento e contraditrio a forma usual com que os engenheiros de software sempre realizaram trabalho com eficincia. Uma viso que levou ao desenvolvimento de mtodos geis e iterativos era retorno a prtica de desenvolvimento vistas nos primrdios da histria do desenvolvimento de software. Inicialmente, mtodos geis eram conhecidos como mtodos leves. Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome mtodos geis, tendo publicado o Manifesto gil, documento que rene os princpios e prticas desta metodologia de desenvolvimento. Mais tarde, algumas pessoas formaram a Agile Alliance, uma organizao no lucrativa que promove o desenvolvimento gil. Os mtodos geis iniciaiscriado a priore em 2000 incluam Scrum (1986), Crystal Clear, Programao extrema (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (1995). Comparao com o desenvolvimento iterativo A maioria dos mtodos geis compartilha a nfase no Desenvolvimento iterativo e incremental para a construo de verses implantadas do software em curtos perodos de tempo. Mtodos geis diferem dos mtodos iterativos porque seus perodos de tempo so medidos em semanas, ao invs de meses, e a realizao efetuada de uma maneira altamente colaborativa. estendendo-se a tudo. Comparao com o modelo em cascata O desenvolvimento gil tem pouco em comum com o modelo em cascata. Na viso de alguns este modelo desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata uma das metodologias com maior nfase no planejamento, seguindo seus passos atravs da captura dos requisitos, anlise, projeto, codificao e testes em uma seqncia pr-planejada e restrita. O progresso geralmente medido em termos de entrega de artefatos especificao de requisitos, documentos de projeto, planos de teste, reviso do cdigo, e outros. O modelo em cascata resulta em uma substancial integrao

e esforo de teste para alcanar o fim do ciclo de vida, um perodo que tipicamente se estende por vrios meses ou anos. O tamanho e dificuldade deste esforo de integrao e teste uma das causas das falhas do projeto em cascata. Mtodos geis, pelo contrrio, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num perodo de poucas semanas ou meses. Enfatiza a obteno de pequenos pedaos de funcionalidades executveis para agregar valor ao negcio cedo, e continuamente agregar novas funcionalidades atravs do ciclo de vida do projeto. Algumas equipes geis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iterao. Outras equipes, mais especificamente as equipes de Programao extrema, trabalham com atividades simultaneamente. Comparao com o codifica remenda O codifica remenda a ausncia de metodologias de desenvolvimento de Software: os membros da equipe fazem o que eles sentem que correto. Como os desenvolvedores que utilizam mtodos geis freqentemente reavaliam os planos, enfatizam a comunicao face a face e fazem o uso relativamente esparso de documentos, ocasionalmente levam as pessoas a confundirem isto com o codifica remenda. Equipes geis, contudo, seguem o processo definido (e freqentemente de forma disciplinada e rigorosa). Como em todas as metodologias, o conhecimento e a experincia dos usurios definem o grau de sucesso e/ou fracasso de cada atividade. Os controles mais rgidos e sistematizados aplicados em um processo implicam altos nveis de responsabilidade para os usurios. A degradao de procedimentos bemintencionados e organizados pode levar as atividades a serem caracterizadas como codifica remenda. Aplicabilidade dos mtodos geis Embora os mtodos geis apresentem diferenas entre suas prticas, eles compartilham inmeras caractersticas em comum, incluindo o desenvolvimento iterativo, e um foco na comunicao interativa e na reduo do esforo empregado em artefatos intermedirios. A aplicabilidade dos mtodos geis em geral pode ser examinada de mltiplas perspectivas. Da perspectiva do produto, mtodos geis so mais adequados quando os requisitos esto emergindo e mudando rapidamente, embora no exista um consenso completo neste ponto. De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando trs dimenses chaves da organizao: cultura, pessoal e comunicao. Em relao a estas reas inmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):

A cultura da organizao deve apoiar a negociao. As pessoas devem ser confiantes.

Poucas pessoas, mas competentes. A organizao deve promover as decises que os desenvolvedores tomam. A Organizao necessita ter um ambiente que facilite a rpida comunicao entre os membros.

O fator mais importante provavelmente o tamanho do projeto. Com o aumento do tamanho, a comunicao face a face se torna mais difcil. Portanto, mtodos geis so mais adequados para projetos com pequenos times, com no mximo de 20 a 40 pessoas. De forma a determinar a aplicabilidade de mtodos geis especficos, uma anlise mais sofisticada necessria. O mtodo dinmico para o desenvolvimento de sistemas, por exemplo, prov o denominado 'filtro de aplicabilidade' para este propsito. Tambm, a famlia de mtodos Crystal prov uma caracterizao de quando selecionar o mtodo para um projeto. A seleo baseada no tamanho do projeto, criticidade e prioridade. Contudo, outros mtodos geis no fornecem um instrumento explcito para definir sua aplicabilidade a um projeto. Alguns mtodos geis, como DSDM e Feature Driven Development, afirmam se aplicar a qualquer projeto de desenvolvimento gil, sem importar suas caractersticas (Abrahamsonn et al., 2003). A comparao dos mtodos geis ir revelar que eles suportam diferentes fases de um ciclo de vida do software em diferentes nveis. Estas caractersticas individuais dos mtodos geis podem ser usadas como um critrio de seleo de sua aplicabilidade. O desenvolvimento gil particularmente adequado para equipes que tm que lidar com mudanas rpidas ou imprevisveis nos requisitos. Barry Boehm e Richard Turner sugeriram que anlise de risco pode ser usada para escolher entre mtodos adaptativos ("geis") e preditivos ("dirigidos pelo planejamento"). Ambiente ideal para o desenvolvimento gil:

Baixa criticidade Desenvolvedores senior Mudanas freqente de requisitos Pequeno nmero de desenvolvedores Cultura que tem sucesso no caos.

Ambiente ideal para o desenvolvimento direcionado ao planejamento:

Alta criticidade Desenvolvedores Junior Baixa mudana nos requisitos Grande nmero de desenvolvedores Cultura que procura a ordem.

Adaptabilidade dos mtodos geis Um mtodo deve ser bastante flexvel para permitir ajustes durante a execuo do projeto. Mtodos geis e o gerenciamento de projeto Os mtodos geis diferem largamente no que diz respeito a forma de serem gerenciados. Algum mtodos so suplementados com guias para direcionar o gerenciamento do projeto, mas nem todos so aplicveis. Uma caracterstica comum dos processos geis a capacidade de funcionar em ambientes muito exigentes que tem um grande nmero de incertezas e flutuaes (mudanas) que podem vir de vrias fontes como: equipe em processo de formao que ainda no trabalhou junto em outros projetos, requisitos volteis, baixo conhecimento do domnio de negcio pela equipe, adoo de novas tecnologias, novas ferramentas, mudanas muito bruscas e rpidas no ambiente de negcios das empresas: novos concorrentes, novos produtos, novos modelos de negcio. Sistemas de gerenciamento de projetos lineares e prescritivos, neste tipo de ambiente, falham em oferecer as caractersticas necessrias para responder de forma gil as mudanas requeridas. Sua adoo pode incrementar desnecessariamente os riscos, o custo, o prazo e baixar a qualidade do produto gerado, desgastando a equipe e todos os envolvidos no processo. A abordagem Scrum, para gesto de projetos geis, leva em considerao planejamento no linear, porm de maneira mais exaustiva e est focada em agregar valor para o cliente e em gerenciar os riscos, fornecendo um ambiente seguro. Pode ser utilizada na gesto do projeto aliada a uma metodologia de desenvolvimento como Programao Extrema, FDD, OpenUP, DSDM, Crystal ou outras. Metodologias

Programao extrema Scrum Feature Driven Development

DSDM Adaptive Software Development Crystal Pragmatic Programming Test Driven Development

Principais Crticas

falta de estrutura e documentao necessrias somente trabalhar com desenvolvedores de nvel snior incorpora de forma insuficiente o projeto de software requer a adoo de muita mudana cultural poder levar a maiores dificuldades nas negociaes contratuais

Scrum O Scrum um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento gil de software. Apesar de Scrum ter sido destinado para gerenciamento de projetos de software, ele pode ser utilizado em equipes de manuteno de software ou como uma abordagem geral de gerenciamento de projetos/programas.

1 Histria 2 Caractersticas

o o

2.1 Product backlog e Sprint backlog 2.2 Planejamento de sprint

3 Scrum simplificado 4 Algumas caractersticas de Scrum 5 Agendando discusses dirias 6 Scrum Solo 7 Ver tambm 8 Livros 9 Ligaes externas

Histria Inicialmentee, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricao de automveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes formao Scrum do Rugby (utilizada para reincio do jogo em certos casos). Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo no desenvolvimento de softwares em todo o mundo. Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.

A funo primria do Scrum ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porm, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de um casamento. Caractersticas Scrum um esqueleto de processo que contm grupos de prticas e papis prdefinidos. Os principais papis so: 1. o ScrumMaster, que mantm os processos (normalmente no lugar de um gerente de projeto) 2. o Proprietrio do Produto, ou Product Owner, que representa os stakeholders e o negcio 3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a anlise, projeto, implementao, teste etc.

Cada sprint uma iterao que segue um ciclo (PDCA) e entrega incremento de software pronto. Um backlog conjunto de requisitos, priorizado pelo Product Owner (responsvel pelo ROI e por conhecer as necessidades do cliente); H entrega de conjunto fixo de itens do backlog em srie de interaes curtas ou sprints; Breve reunio diria, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm chamado de Standup Meeting ou Daily Meeting, j que os membros da equipe geralmente ficam em p para no prolongar a reunio). Breve sesso de planejamento, na qual os itens do backlog para uma sprint (iterao) so definidos; Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

O Scrum facilitado por um Scrum Master, que tem como funo primria remover qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas), mas atua como um mediador entre a equipe e qualquer influncia desestabilizadora. Outra funo extremamente importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint. Scrum permite a criao de equipes auto-organizadas, encorajando a comunicao verbal entre todos os membros da equipe e entre todas as disciplinas que esto envolvidas no projeto. Um princpio chave do Scrum o reconhecimento de que desafios fundamentalmente empricos no podem ser resolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem emprica, aceitando que o problema no pode ser totalmente entendido ou definido, focando na maximizao da habilidade da equipe de responder de forma gil aos desafios emergentes. Uma das grandes vantagens do Scrum, porm, que no tem abordagem "receita de bolo" do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade atravs da aplicao de uma srie de processos prescritos. Product backlog e Sprint backlog Um backlog uma lista de itens priorizados a serem desenvolvidos para um software. O Product backlog mantido pelo Product Owner e uma lista de requisitos que tipicamente vm do cliente. O Product Owner pode altera-lo a qualquer momento, desde que os itens alterados no estejam na sprint. O Sprint backlog uma interpretao do Product backlog e contm tarefas concretas que sero realizadas durante o prximo sprint para implementar alguns dos itens principais no Product backlog. O Product backlog e o sprint backlog so, ento, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nvel e o segundo contendo informaes sobre como a equipe ir implementar os requisitos do produto. Planejamento de sprint

Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe ir trabalhar durante o prximo sprint. O Product Owner mantm uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe ento planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto so ento destrinchados em tarefas que se tornam o backlog do sprint. Scrum simplificado Muitas organizaes tm sido resistentes s metodologias introduzidas em baixos nveis da organizao. Porm, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisvel ("stealth"), usando os trs passos:

Agende uma demonstrao do software com seu cliente em um ms a partir de agora; Como equipe, tome um ms para deixar o software pronto para uma demo, com funcionalidades prontas, no simplesmente telas; Na demonstrao, obtenha feedback e use-o para guiar o seu prximo ms de trabalho de desenvolvimento.

Algumas caractersticas de Scrum

Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na sada);

Entregas frequentes desenvolvidas;

e

intermedirias

de

funcionalidades

100%

Planos frequentes de mitigao de riscos desenvolvidos pela equipe; Discusses dirias de status com a equipe; A discusso diria na qual cada membro da equipe responde s seguintes perguntas:

o o o

O que fiz desde ontem? O que estou planejando fazer at amanh? Existe algo me impedindo de atingir minha meta?

Transparncia no planejamento e desenvolvimento;

Reunies frequentes com os stakeholders (todos os envolvidos no processo) para monitorizar o progresso; Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer problema no visto;

Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" no necessariamente significa "produzir mais".

Agendando discusses dirias Um momento bom para as discusses dirias depois do almoo. Durante a manh pode ser complicado. Estas discusses de status no demoram e uma forma eficiente de fazer estas reunies seria ficar em p e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoo, ter uma viva reunio em p nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manh, suas mentes esto focadas no trabalho e no em questes pessoais. Scrum Solo Scrum baseado em pequenas equipes. Ele permite a comunicao entre os membros da equipe. Entretanto, h uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um s programador pode ainda se beneficiar de alguns princpios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo uma verso adaptada para uso de programadores solo.

Programao extrema Programao extrema (do ingls eXtreme Programming), ou simplesmente XP, uma metodologia gil para equipes pequenas e mdias e que iro desenvolver software com requisitos vagos e em constante mudana. Para isso, adota a estratgia de constante acompanhamento e realizao de vrios pequenos ajustes durante o desenvolvimento de software. Os valores fundamentais da metodologia XP so: Comunicao Simplicidade Feedback Coragem Respeito

A partir desses valores, possui como princpios bsicos: Feedback rpido Presumir simplicidade Mudanas incrementais Abraar mudanas Trabalho de alta qualidade.

Dentre as variveis de controle em projetos (custo, tempo, qualidade e escopo), h um foco explcito em escopo. Para isso, recomenda-se a priorizao de funcionalidades que representem maior valor possvel para o negcio. Desta forma, caso seja necessrio a diminuio de escopo, as funcionalidades menos valiosas sero adiadas ou canceladas. A XP incentiva o controle da qualidade como varivel do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, no compensado por perdas (ou at impedimentos) a mdio e longo prazo. Prticas Para aplicar os valores e princpios durante o desenvolvimento de software, XP prope uma srie de prticas. H uma confiana muito grande na sinergia entre elas, os pontos fracos de cada uma so superados pelos pontos fortes de outras.

Jogo de Planejamento (Planning Game): O desenvolvimento feito

em iteraes semanais. No incio da semana, desenvolvedores e cliente renem-se para priorizar as funcionalidades. Essa reunio recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente essencial neste processo e assim ele fica sabendo o que est acontecendo e o que vai acontecer no projeto. Como o escopo reavaliado semanalmente, o projeto regido por um contrato de escopo negocivel, que difere significativamente das formas tradicionais de contratao de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produo.

Pequenas Verses (Small Releases): A liberao de pequenas verses funcionais do projeto auxilia muito no processo de aceitao por parte do cliente, que j pode testar uma parte do sistema que est comprando. As verses chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. Metfora (Metaphor): Procura facilitar a comunicao com o cliente, entendendo a realidade dele. O conceito de rpido para um cliente de um sistema jurdico diferente para um programador experiente em controlar comunicao em sistemas em tempo real, como controle de trfego areo. preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto. Projeto Simples (Simple Design): Simplicidade um princpio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira verso apenas o usurio "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, voc vai fazer o cdigo exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticao e restries de acesso. Um erro comum ao adotar essa prtica a confuso por parte dos programadores de cdigo simples e cdigo fcil. Nem sempre o cdigo mais fcil de ser desenvolvido levar a soluo mais simples por parte de projeto. Esse entendimento fundamental para o bom andamento do XP. Cdigo fcil deve ser identificado e substitudo por cdigo simples. Time Coeso (Whole Team): A equipe de desenvolvimento formada pelo cliente e pela equipe de desenvolvimento.

Testes de Aceitao (Customer Tests): So testes construdos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.

Ritmo Sustentvel (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudvel (40 horas/semana, 8 horas/ dia), sem horas extras. Horas extras so permitidas quando trouxerem

produtividade para a execuo do projeto. Outra prtica que se verifica neste processo a prtica de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivao da equipe devem estar sempre em harmonia.

Reunies em p (Stand-up Meeting): Reunies em p para no se perder o foco nos assuntos, produzindo reunies rpidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe. Posse Coletiva (Collective Ownership): O cdigo fonte no tem dono e ningum precisa solicitar permisso para poder modificar o mesmo. O objetivo com isto fazer a equipe conhecer todas as partes do sistema. Programao em Pares (Pair Programming): a programao em par/ dupla num nico computador. Geralmente a dupla formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como apenas um computador, o novato que fica frente fazendo a codificao, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto buscase sempre a evoluo da equipe, melhorando a qualidade do cdigo fonte gerado. Padres

de Codificao (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecer que todo o cdigo fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitrios (unit tests) e depois crie o cdigo para que os testes funcionem. Esta abordagem complexa no incio, pois vai contra o processo de desenvolvimento de muitos anos. S que os testes unitrios so essenciais para que a qualidade do projeto seja mantida. Refatorao (Refactoring): um processo que permite a melhoria continua da programao, com o mnimo de introduo de erros e mantendo a compatibilidade com o cdigo j existente. Refabricar melhora a clareza (leitura) do cdigo, divide-o em mdulos mais coesos e de maior reaproveitamento, evitando a duplicao de cdigo-fonte; Integrao Contnua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar verso atual do sistema. Isto s aumenta a possibilidade de conflitos e a possibilidade de erros no cdigo fonte. Integrar de forma contnua permite saber o status real da programao.