Unidade4 Es Ti FG

Prof. Francisco Gerson A.
de Meneses
Contedo Programtico
Engenharia de Software
Unidade IV Desenvolvimento gil
Introduo O que agilidade? O que um processo gil
A poltica de desenvolvimento gil Fatores humanos
Prof. Francisco Gerson A. de Meneses
Modelos geis de processo

Extreme Programming (XP) Scrum
franciscogerson10@gmail.com
Outros modelos geis de processo
Introduo
Em 2001, Kent Beck e 16 outros notveis desenvolvedores, produtores e consultores de software (conhecidos como Aliana gil) assinaram o Manifesto para o Desenvolvimento gil de Softwares Eles declararam: Estamos descobrindo melhores modos de desenvolvimento de software, fazendo-o e ajudando outros a faz-lo. Por meio desse trabalho passamos a valorizar:
Introduo
Indivduos e interaes em vez de processos e ferramentas; Software funcionando em vez de documentao abrangente; Colaborao do cliente em vez de negociao de contratos; Respostas a modificaes em vez de seguir um plano.
Introduo
Embora as idias subjacentes que guiam o desenvolvimento gil tenham estado conosco h muitos anos, somente durante a dcada de 1990 que foram cristalizados em um movimento. Em essncia os mtodos geis foram desenvolvidos em um esforo para vencer as fraquezas percebidas e reais da engenharia de software convencional. O desenvolvimento gil pode fornecer importantes benefcios, mas ele no aplicvel a todos os projetos, produtos, pessoas e situaes. Ele tambm no o contrrio slida prtica de engenharia de software e pode ser aplicado como uma filosofia prevalecente a todo trabalho do software.
Introduo
Na economia moderna frequentemente difcil ou impossvel prever como um sistema baseado em computador evoluir com o passar do tempo. Condies de mercado mudam rapidamente, necessidades dos usurios finais evoluem e novas ameaas de competio emergem sem alerta. Em muitas situaes, no podemos mais definir completamente os requisitos antes do incio do projeto. Os engenheiros de software devem ser geis o suficiente para responder a um ambiente de negcio mutante.
Introduo
Isso significa que o reconhecimento dessas causas realsticas modernas nos obrigam a descartar princpios, conceitos, mtodos e ferramentas, todos importantes na engenharia de software? Certamente que no, como todas as disciplinas da engenharia, a engenharia de software continua a evoluir. Ela pode ser adequada facilmente para encarar os desafios colocados pela demanda por agilidade.
O que agilidade?
O que agilidade no contexto da engenharia de software? Ivan Jacobson fornece uma discusso til: Agilidade tornou-se atualmente uma palavra mgica quando se descreve um processo moderno de software. Tudo gil. Uma equipe gil uma equipe esperta, capaz de responder adequadamente a modificaes. Modificaes (software, membros da equipe, tecnologias, etc) o foco principal do projeto e tem impacto no produto final. O apoio para modificaes deveria ser incorporado em tudo que fazemos em software, algo que se adota porque est no corao e na alma do software. Uma equipe gil reconhece que o software desenvolvido por indivduos trabalhando em equipes e que as especialidades dessas pessoas e sua capacidade de colaborar esto no mago do sucesso do projeto.
O que agilidade?
Na viso de Jacobson, o acolhimento de modificaes o principal guia para a agilidade. Os engenheiros de software devem reagir rapidamente se tiverem de acomodar as rpidas modificaes citadas.
O que agilidade?
Mas a agilidade mais do que uma resposta efetiva modificao. Ela encoraja estruturas e atitudes de equipe que tornam a comunicao mais fcil, entre todos os envolvidos no processo. Enfatiza a rpida entrega do software e d menos importncia para produtos intermedirios (nem sempre uma boa coisa).
Agilidade dinmica, especfica em contedo, agressiva no acolhimento de modificaes e orientada a crescimento. Steven Goldman No devemos cometer o erro de considerar que a agilidade nos d licena de improvisar solues. Um processo necessrio e disciplina essencial
Adota os clientes como parte da equipe de desenvolvimento. Admite que o planejamento em um mundo incerto tem seus limites e que um plano de projeto deve ser flexvel.
O que agilidade?
A Aliana gil define 12 princpios para aqueles que querem alcanar agilidade: 1- Nossa maior prioridade satisfazer o cliente desde o incio por meio de entrega contnua de software valioso. 2 - Modificaes de requisitos so bem vindas, mesmo que tardias no desenvolvimento. Os processos geis aproveitam as modificaes como vantagens para a competitividade do cliente. 3 - Entrega de softwares funcionando frequentemente, a cada duas semanas at dois meses, de preferncia no menos espao de tempo. 4 - O pessoal do negcio e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.
O que agilidade?
Cont.: 5 Construo de projetos em torno de indivduos motivados. Fornea-lhes o ambiente e apoio que precisam e confie que eles faro o trabalho. 6 O mtodo mais eficiente e efetivo de levar informaes para dentro da equipe de desenvolvimento a conversa face a face. 7 Softwares funcionando a principal medida de progresso. 8 Processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios, devem ser capazes de manter um ritmo constante, indefinidamente.
O que agilidade?
Cont.: 9 Ateno contnua excelncia tcnica e ao bom projeto facilitam a agilidade. 10 Simplicidade a arte de maximizar a quantidade de trabalho no efetuado essencial. 11 As melhores arquiteturas, requisitos e projetos surgem de equipes auto organizadas. 12 Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, ento sintoniza e ajusta adequadamente seu comportamento.
O que agilidade?
A agilidade pode ser aplicada a qualquer processo de software. Entretanto para conseguir isso essencial que o processo seja de modo que permita equipe de projeto adaptar tarefas e aperfeio-las. Conduzir o planejamento para que se entenda a fluidez de uma abordagem de desenvolvimento gil, eliminar tudo, menos os produtos de trabalho mais essenciais e mant-los simples. Enfatizar uma estratgia de entrega incremental que fornea o software funcionando ao cliente o mais rpido possvel .
O que um Processo gil?

Qualquer processo gil de software caracterizado de modo que atenda a trs suposies chave:
1 difcil prever antecipadamente quais requisitos de software vo persistir e quais sero modificados. igualmente difcil prever como as prioridades do cliente sero modificadas a medida que o projeto prossegue. 2 Para muitos tipos de software, o projeto e a construo so intercalados, isto , as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados a medida que so criados. difcil prever o quanto de projeto necessrio antes que a construo seja usada para comprovar o projeto.

Cont.
3 Anlise, projeto, construo e testes no so to previsveis (do ponto de vista do planejamento) como gostaramos.
Dadas essas trs suposies surge uma questo importante, como criar um processo que possa gerenciar a imprevisibilidade? A resposta est na adaptabilidade do processo (as modificaes rpidas do projeto e das condies tcnicas). Um processo gil, portanto, deve ser adaptvel incrementalmente.

Para realizar a adaptao incremental, uma equipe gil requer o feedback do cliente (de modo que adaptaes apropriadas possam ser feitas), isso pode ser feito atravs de prottipos operacionais. Assim, uma estratgia de desenvolvimento incremental deve ser instituda. Incrementos de software devem ser entregues em curtos perodos de tempo de modo que a adaptao acerte o passo com as modificaes (imprevisibilidade).

Essa abordagem interativa habilita o cliente a avaliar o incremento de software regularmente, fornece o feedback necessrio equipe de software e influencia as adaptaes do processo feitas para acomodar o feedback.
A poltica do Desenvolvimento gil

H um considervel debate sobre os benefcios e a aplicabilidade do desenvolvimento gil de software em contraposio aos processos mais convencionais de engenharia de software. Os agilistas dizem: Os metodologistas tradicionais so um punhado de bitolados que preferem produzir documentao perfeita a um sistema funcionando que satisfaa s necessidades do negcio. Os tradicionalistas dizem: Os metodologistas levianos quer dizer, geis, so um punhado de gloriosos hackers que tero uma grande surpresa quando tiverem de ampliar seus brinquedos para chegar a um software que abranja toda a empresa.

Como toda argumentao sobre tecnologia de software, esse debate metodolgico arrisca-se a degenerar em uma guerra religiosa, se isso tiver incio o pensamento racional desaparecer e crenas, em vez de fatos, orientaro a tomada deciso. Ningum contra a agilidade. A verdadeira questo : qual o melhor modo de alcan-la? Outra questo to importante como essa : como construir softwares que satisfaam s necessidades do cliente atual e exiba caracterstica de qualidade que lhe permitam ser estendido e ampliado para satisfazer s necessidades do cliente no longo prazo?

No existem respostas absolutas para qualquer uma dessas questes. Mesmo dentro da escola gil, h muitos modelos de processo propostos, cada qual com uma abordagem sutilmente diferente para o problema da agilidade. Em cada modelo h um conjunto de idias que representam um afastamento significativo da engenharia de software convencional. No entanto, muitos conceitos geis so simples adaptaes, de bons conceitos da engenharia de software. Concluso: h muito a ser ganho considerando o melhor de ambas as escolas, e quase nada a ser ganho denegrindo qualquer uma dessas abordagens.

Voc no tem que escolher entre agilidade e engenharia de software. Em vez disso, defina uma abordagem de engenharia de software que seja gil.
Fatores Humanos
Os proponentes do desenvolvimento gil de software sofrem muito para enfatizar a importncia dos fatores pessoais no desenvolvimento gil bem sucedido. O desenvolvimento gil enfoca os talentos e habilidades dos indivduos moldando o processo a pessoas e equipes especficas. O ponto chave dessa declarao que o processo se molda s necessidades das pessoas e da equipe, e no o contrrio. O que considerado meramente suficiente por uma equipe ou suficiente ou insuficiente para outra.
Fatores Humanos
Se os membros de uma equipe de software tiverem de estabelecer as caractersticas do processo que aplicado para construir software, uma certa quantidade de caractersticas chave deve existir entre as pessoas de uma equipe gil e na equipe em si. So elas:
Competncia Foco comum Colaborao Capacidade de tomada de deciso Habilidade de resolver problemas vagos (ambigidades) Respeito e confiana mtua Auto organizao
Fatores Humanos
No contexto de desenvolvimento gil, a auto organizao implica trs coisas: 1 a equipe gil organiza-se para o trabalho a ser feito. 2 a equipe organiza o processo para melhor acomodar seu ambiente local. 3 a equipe organiza o cronograma de trabalho para conseguir melhor entrega do incremento do software.
Fatores Humanos
A auto organizao tem um certo nmero de benefcios tcnicos, porm, mas importante que isso, ela serve para aperfeioar a colaborao e aumentar a moral da equipe. Em essncia, a equipe serve como sua prpria gerncia. A equipe seleciona quanto trabalho acredita que pode realizar dentro da iterao e a equipe se compromete com o trabalho. Nada desmotiva tanto uma equipe quanto algum de fora assumir compromissos por ela. Nada motiva tanto uma equipe quanto a aceitao da responsabilidade de cumprir os compromissos que ela prpria estabeleceu.
Fatores Humanos
Uma equipe auto organizada est no controle de trabalho que realiza. A equipe estabelece os seus prprios compromissos e define os planos para cumpri-los.
Revisando... desenvolvimento gil...

O que ? Quem faz? Por que importante? Quais so os passos? Qual o produto do trabalho? Como tenho certeza que fiz corretamente?

O que ?
A engenharia de software gil combina uma filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfao do cliente e a entrega incremental do software logo de incio, equipes de projeto pequenas, altamente motivadas, mtodos informais, produtos de trabalho de engenharia de software mnimos e simplicidade global do desenvolvimento. As diretrizes de desenvolvimento enfatizam a entrega em contraposio anlise e ao projeto (apesar dessas atividades no serem desencorajadas) e a comunicao ativa e contnua entre desenvolvedores e clientes.

Quem faz?
Engenheiros de software e outros interessados no projeto (gerentes, clientes e usurios finais) trabalham juntos em uma equipe gil uma equipe que auto- organizada e controla seu prprio destino. Uma equipe gil enfatiza a comunicao e a colaborao entre todos que a compem.

Por que importante?
O ambiente moderno de negcios que cria sistemas baseados em computador e produtos de software apressado e sempre mutvel. A engenharia gil de software representa uma alternativa razovel para a engenharia de software convencional para certas categorias de software e certos tipos de projeto de software. Tem sido demonstrado que ela entrega rapidamente sistemas bem sucedidos.

Quais so os passos?
As atividades bsicas da engenharia de software: comunicao com o cliente, planejamento, modelagem, construo, entrega e avaliao permanecem. Porm, so reduzidas a um conjunto mnimo de tarefas que leva a equipe de projeto construo e entrega.

Qual o produto do trabalho?
Cliente e engenheiros de software que tem adotado a filosofia gil tem a mesma impresso o nico produto de trabalho realmente importante um incremento do software operacional que entregue ao cliente na data de entrega combinada.

Como tenho certeza que fiz corretamente?
Se a equipe gil concordar que o processo funciona e produzir incrementos de software em condies de serem entregues e que satisfaam ao cliente, voc fez corretamente.

A histria da engenharia de software est congestionada com dzias de descries e metodologias obsoletas de processos, mtodos de modelagem e notaes, ferramentas e tecnologias. Cada uma delas ganhou notoriedade e foi depois eclipsada por algo mais novo e (pretensamente) melhor. Com a introduo de uma ampla gama de modelos geis de processo - cada qual lutando por aceitao na comunidade de desenvolvimento de software o movimento gil est seguindo o mesmo caminho histrico.

Os modelos geis de processo foram projetados de forma a atender aos quatro tpicos chave, de acordo com a filosofia gil: A importncia de equipes auto-organizadas que tem controle sobre o trabalho que executam; Comunicao e colaborao entre os membros da equipe e entre os profissionais e seus clientes; Um reconhecimento de que as modificaes representam uma oportunidade; nfase na entrega rpida de softwares que satisfaam ao cliente. Vejamos alguns:
Extreme Programming (XP)

O XP usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento predileto. Inclui um conjunto de regras e prticas que ocorrem no contexto de quatro atividades: planejamento, projeto, codificao e teste. Vejamos cada uma das atividades:

Planejamento:
Comea com a criao de um conjunto de histrias (histrias do usurio) que descrevem as caractersticas e funcionalidades requeridas para o software a ser construdo. Cada histria escrita pelo cliente e colocada em um carto de indexao.

Planejamento:
O cliente atribui um valor (prioridade) para a histria, com base no valor de negcio global da caracterstica ou da funo. Membros da equipe XP avaliam ento cada histria e lhe atribuem um custo medido em semanas de desenvolvimento.

Planejamento:
Se a histria precisar mais do que trs semanas de desenvolvimento, pedese ao cliente para dividir a histria em histrias menores e a atribuio de valor e custo ocorre novamente. Novas histrias podem ser escritas a qualquer momento.

Planejamento:

Planejamento:
Os clientes e a equipe XP trabalham juntos para decidir como agrupar histrias na verso seguinte (prximo incremento) a ser desenvolvido pela equipe XP. Uma vez feito um compromisso bsico para a verso (acordo quanto s histrias includas, data de entrega e outros assuntos de projeto), a equipe XP determina as histrias que sero desenvolvidas seguindo os critrios a seguir:
Histrias

Planejamento:
1 todas as histrias sero implementadas imediatamente (dentro de poucas semanas); 2 as histrias com valor mais alto sero antecipadas no cronograma e implementadas primeiro; 3 as histrias de maior risco sero antecipadas no cronograma.

Planejamento:
Depois que a primeira verso do projeto (incremento) tiver sido entregue, a equipe XP calcula a velocidade do projeto. Isso pode ser usado principalmente para ajudar a estimar as datas de entrega e o cronograma para verses subseqentes; A medida que o trabalho de desenvolvimento prossegue, o cliente pode adicionar histrias, mudar o valor de uma histria existente, subdividir histrias ou elimin-las. A equipe XP ento reconsidera todas as verses remanescentes e modifica os seus planos adequadamente.

Projeto:
O projeto XP segue rigorosamente o princpio KIS (keep it simple mantenha a simplicidade). Um projeto simples sempre prefervel em relao a uma representao mais complexa. Alm disso, o projeto fornece diretrizes de implementao para uma histria como ela est escrita nada mais e nada menos. O XP encoraja o uso de cartes CRC (Class Responsability Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos.

Projeto:
Os cartes CRC identificam e organizam as classes orientada a objetos que so relevantes para o incremento do software atual; eles so o nico produto de trabalho do projeto que realizado como parte do processo XP.

Projeto:
No trabalho de modelagem, cartes CRC (Classes, Responsabilidade, Colaboraes) podem ser usados na etapa inicial de identificao de classes ou de candidatos a classe. So cartes (fichas de papel), cada ficha corresponde a uma classe. Cada ficha contm o nome da classe e 2 colunas com descrio de suas responsabilidades e colaboraes. Colaboraes apresentam outras classes que interagem com a classe descrita para o cumprimento de suas responsabilidades.

Projeto:
Se um problema de projeto encontrado como parte do projeto de uma histria, o XP recomenda a criao imediata de um prottipo operacional daquela parte do projeto. Denominado soluo de ponta, o prottipo de projeto implementado e avaliado. A inteno diminuir o risco quando a implementao verdadeira comear a validar as estimativas originais correspondentes histria que contm o problema de projeto.

Projeto:
O XP encoraja a refabricao uma tcnica de construo que tambm uma tcnica de projeto (altera e aperfeioa o cdigo sem alterar o comportamento externo).

Projeto:
Como o projeto XP praticamente no usa nenhuma notao e produz poucos ou nenhum produto de trabalho que no seja os cartes CRC e as solues de ponta, o projeto visto como um artefato provisrio que pode e deve ser continuamente modificado medida que a construo prossegue.

Projeto:
A inteno da refabricao controlar essas modificaes sugerindo pequenas alteraes de projeto que podem aperfeioar rapidamente o projeto. Deve-se notar, no entanto, que o reforo necessrio refabricao pode crescer sensivelmente medida que o tamanho de uma aplicao cresce. Um noo central do XP de que o projeto ocorre tanto antes quanto depois que a codificao comea. Refabricao significa que o projeto ocorre continuamente medida que o sistema construdo. De fato, a atividade de construo em si vai fornecer equipe XP diretrizes sobre como aperfeioar o projeto.

Codificao:
O XP recomenda que depois que as histrias forem desenvolvidas e o trabalho preliminar de projeto for feito, a equipe no avance para o cdigo mas, em vez disso, desenvolva uma srie de testes unitrios que exercitaro cada uma das histrias que devem ser includas na verso atual (incremento).

Codificao:
Uma vez criados os testes unitrios, o desenvolvedor esta melhor preparado para focalizar o que precisa ser implementado para passar no teste unitrio. Completado o cdigo, ele pode ser submetido imediatamente ao teste unitrio, fornecendo assim feedback instantneo para os desenvolvedores.

Codificao:
Um conceito chave durante a atividade de codificao a programao em pares.

Codificao:
O XP recomenda que duas pessoas trabalhem juntas em uma estao de trabalho de computador para criar o cdigo correspondente a uma histria. Isso fornece um mecanismo de soluo de problemas em tempo real e de garantia de qualidade, tambm mantm os desenvolvedores focados no problema em mos. Na prtica, cada pessoa assume um papel ligeiramente diferente. Por exemplo, uma pessoa poderia pensar nos detalhes do cdigo de uma parte especfica do projeto, enquanto a outra garante que as normas de codificao esto sendo seguidas e que o cdigo gerado vai se encaixar no projeto mais amplo da histria.

Codificao:
medida que os pares de programadores contemplam o seu trabalho, o cdigo que eles desenvolvem integrado ao trabalho dos outros. Em alguns casos, isso realizado diariamente por uma equipe de integrao. Em outros casos, os pares de programadores tem a responsabilidade de integrao. Essa estratgia de integrao contnua ajuda a evitar problemas de compatibilidade e interface e fornece um mecanismo de teste de fumaa que ajuda a descobrir rapidamente erros.

Teste:
J mencionamos que a criao de um teste unitrio antes da codificao comear um elemento chave da abordagem XP. Os testes unitrios que so criados devem ser implementados usando parmetros que lhes permita ser automatizados. Isso encoraja uma estratgia de teste de regresso sempre que o cdigo modificado.

Teste:
A medida que os testes unitrios individuais so organizados em uma seqncia universal de testes o teste de integrao e validao do sistema pode ocorrer diariamente. Isso fornece equipe XP uma indicao contnua de progresso e tambm pode levantar sinais de alerta se as coisas no estiverem bem.
Resolver pequenos problemas a cada intervalo de umas poucas horas leva menos tempo do que resolver grandes problemas perto da data de entrega.

Teste:
Os testes de aceitao XP, tambm chamados de testes do cliente, so especificados pelo cliente e focalizam as caractersticas e funcionalidades do sistema global que so visveis e passivos de reviso pelo cliente.
Testes de aceitao so derivados das histrias do usurio que foram implementadas como parte de uma verso do software.
Arquitetura XP
Scrum
um modo gil de processo que foi desenvolvido por Jeff Sutherland e por sua equipe no incio da dcada de 1990. Nos ltimos anos foi realizado desenvolvimento adicional de mtodos Scrum por Sewaber e Beedle.
Scrum
Os princpios Scrum so consistentes com o manifesto gil:
Pequenas equipes de trabalho so organizadas de modo a maximizar a comunicao, minimizar a superviso e maximizar o compartilhamento de conhecimento tcito informal. O processo precisa ser adaptvel tanto a modificaes tcnicas quanto de negcios para garantir que o melhor produto possvel seja produzido. O processo produz frequentes incrementos do software que podem ser inspecionados, ajustados, testados, documentados e expandidos.
Scrum
O trabalho de desenvolvimento e o pessoal que o realiza dividido em parties claras de baixo acoplamento, ou em pacotes. Testes e documentao constantes so realizados medida que o produto construdo. O processo Scrum fornece a habilidade de declarar o produto pronto sempre que necessrio (porque a concorrncia acabou de entregar, porque a empresa precisa de dinheiro, porque o usurio/cliente precisa das funes, porque foi para essa data que foi prometido.)
Scrum
Os princpios Scrum so usados para guiar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades genricas:
Requisitos, Anlise, Projeto, Evoluo, Entrega.
Em cada atividade, as tarefas de trabalho ocorrem dentro de um padro de processo chamado de sprint.
Scrum
Sprint: consiste de unidades de trabalho que so necessrias para satisfazer a um requisito definido na pendncia que precisa ser cumprido em um intervalo de tempo predefinido. Pendncia: uma lista priorizada de requisitos ou caractersticas de projeto que fornecem valor de negcio para o cliente. Itens podem ser adicionados pendncia a qualquer momento ( assim que as modificaes so introduzidas). O gerente de produto avalia a pendncia e atualiza as prioridades quando necessrio.
Scrum
O Scrum incorporou um conjunto de padres de processo que enfatiza prioridade de projeto, unidades de trabalho compartimentalizadas, comunicao e feedback frequente do cliente.
Fluxo de processo Scrum
Scrum
O trabalho conduzido dentro de um sprint adaptado ao problema em mos e definido, e frequentemente, modificado em tempo real pela equipe Scrum. A quantidade de sprints necessria para cada atividade varia dependendo da complexidade e do tamanho do produto.
Scrum
Reunies Scrum so curtas (normalmente 15 minutos) feitas diariamente pela equipe. Trs questes-chave so formuladas e respondidas por todos os membros da equipe.
O que voc fez desde a ltima reunio de equipe? Que obstculos voc est encontrando? O que voc planeja realizar at a prxima reunio de equipe?
O Scrum permite a construo de softwares mais flexveis.
Scrum
Um lder da equipe, chamado de Scrum Master, lidera a reunio e avalia as respostas de cada pessoa. Essas reunies dirias ajudam a equipe a descobrir problemas potenciais to cedo quanto possvel. Elas levam tambm socializao do conhecimento e promovem, assim, uma estrutura de equipe auto-organizada.
Scrum
Demos entrega do incremento de software ao cliente de modo que a funcionalidade implementada possa ser demonstrada e avaliada pelo cliente. importante observar que a demo talvez no contenha toda a funcionalidade planejada, mas, em vez disso, as funes que podem ser entregues dentro do intervalo de tempo estabelecido.
Scrum
Beedle e seus colegas apresentam uma discusso abrangente desses padres na qual eles declaram: O Scrum considera antecipadamente a existncia do caos.... Os padres de processo Scrum permitem equipe de desenvolvimento de software trabalhar de modo bem sucedido em um mundo em que se busca a eliminao da incerteza.

O DAS (Desenvolvimento Adaptativo de Software) ressalta a colaborao humana e a auto-organizao da equipe. Organizado como trs atividades de arcabouo: especulao, colaborao e aprendizado. Usa um processo iterativo que incorpora planejamento do ciclo adaptativo, mtodos relativamente rigorosos para o levantamento de requisitos e um ciclo de desenvolvimento iterativo que incorpora grupos enfocados nos clientes e revises tcnicas formais como mecanismos de feedback em tempo real.

O DSDM (Mtodo de Desenvolvimento Dinmico de Sistemas) define trs diferentes ciclos interativos iterao do modelo funcional, iterao de projeto e construo e implementao procedidos por duas atividades de ciclo de vida adicionais estudo de viabilidade e estudo do negcio. Recomenda o uso de cronogramao a cada intervalo de tempo e sugere que, em cada incremento de software, necessrio apenas o trabalho suficiente a fim de facilitar o avano para o incremento suficiente.

O Crystal uma famlia de modelos geis de processo que podem ser adotados para as caractersticas especficas de um projeto. Como outras abordagens geis, o Crystal adota uma estratgia iterativa, mas ajusta o rigor do processo de modo a acomodar projetos de diferentes tamanhos e complexidades.

O FDD (Desenvolvimento Guiado por Caractersticas) algo mais formal do que outros mtodos geis, mas ainda mantm agilidade por concentrar a equipe de projeto no desenvolvimento das caractersticas funes valiosas para o cliente que podem ser implementadas em duas semanas ou menos. Fornece maior nfase em gesto do projeto e qualidade do que outras abordagens geis.

A Modelagem gil (AM) sugere que a modelagem essencial para todos os sistemas, mas que a complexidade, tipo e tamanho do modelo devem estar sintonizados com o software a ser construdo. Por meio da proposio de um conjunto de princpios de modelagem centrais e suplementares, a AM fornece uma guia til para os profissionais durante as tarefas de anlise e do projeto.
Exerccio
1 - Quais pontos principais o "Manifesto para o Desenvolvimento gil de Softwares" valoriza? 2 - Qual o seu entendimento a partir da afirmao: "O Desenvolvimento gil no o contrrio slida prtica de engenharia de software e pode ser aplicado como uma filosofia prevalecente a todo trabalho do software"? 3 - Quais princpios definidos pela Aliana gil chamam mais a sua ateno? 4 - Qual o seu conceito para Agilidade, no cenrio da Engenharia de Software? 5 - Um processo gil de software caracterizado de modo que atenda a trs suposies chave, quais so elas? 6 - "H um considervel debate sobre os benefcios e a aplicabilidade do desenvolvimento gil de software em contraposio aos processos mais convencionais de engenharia de software." Qual a sua opinio sobre isso? 7 - Que caractersticas principais uma equipe gil deve ter? 8 - Qual o produto de trabalho realmente importante no desenvolvimento gil? 9 - Que pontos importantes voc destacaria no Modelo gil XP? 10 - Que pontos importantes voc destacaria no Modelo gil Scrum? 11 - O que refabricao? 12 - Que outros modelos geis de processo voc destacaria?
Bibliografia
PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: McGraw-Hill, 2007. Palestra Vinicius Teles. Notas de aula

Unidade4 Es Ti FG

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Unidade4 Es Ti FG

Загружено:

Авторское право:

Доступные форматы

Prof. Francisco Gerson A.

Modelos geis de processo

Outros modelos geis de processo

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

O que um Processo gil?

O que um Processo gil?

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

O que um Processo gil?

O que um Processo gil?

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

A poltica do Desenvolvimento gil

A poltica do Desenvolvimento gil

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

A poltica do Desenvolvimento gil

A poltica do Desenvolvimento gil

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Revisando... desenvolvimento gil...

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Revisando... desenvolvimento gil...

Revisando... desenvolvimento gil...

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Revisando... desenvolvimento gil...

Revisando... desenvolvimento gil...

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Revisando... desenvolvimento gil...

Revisando... desenvolvimento gil...

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Modelos geis de processo

Modelos geis de processo

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Extreme Programming (XP)

Extreme Programming (XP)

Prof. Francisco Gerson A. de Meneses

Prof. Francisco Gerson A. de Meneses

Extreme Programming (XP)

Extreme Programming (XP)

Prof. Francisco Gerson A. de Meneses