Análise de Sistemas Unidade III A Engenharia de Software Desenvolvimento Ágil

Transcrição

1 Análise de Sistemas Unidade III A Engenharia de Software Desenvolvimento Ágil franciscogerson10@gmail.com Conteúdo Programático Introdução O que é um processo ágil A política de desenvolvimento ágil Fatores humanos Modelos ágeis de processo Outros modelos ágeis de processo Introdução Introdução Em 2001, Kent Beck e 16 outros notáveis desenvolvedores, produtores e consultores de software (conhecidos como Aliança Á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: Indivíduos e interações em vez de processos e ferramentas; Software funcionando em vez de documentação abrangente; Colaboração do cliente em vez de negociação de contratos; Respostas a modificações em vez de seguir um plano. Introdução Introdução Embora as idéias subjacentes que guiam o desenvolvimento ágil tenham estado conosco há muitos anos, somente durante a década de 1990 é que foram cristalizados em um movimento. Em essência os métodos ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e reais da engenharia de software convencional. O desenvolvimento ágil pode fornecer importantes benefícios, mas ele não é aplicável a todos os projetos, produtos, pessoas e situações. Ele também não é o contrário à sólida prática de engenharia de software e pode ser aplicado como uma filosofia prevalecente a todo trabalho do software. Na economia moderna é frequentemente difícil ou impossível prever como um sistema baseado em computador evoluirá com o passar do tempo. Condições de mercado mudam rapidamente, necessidades dos usuários finais evoluem e novas ameaças de competição emergem sem alerta. Em muitas situações, não podemos mais definir completamente os requisitos antes do início do projeto. Os engenheiros de software devem ser ágeis o suficiente para responder a um ambiente de negócio mutante. 1

2 Introdução Isso significa que o reconhecimento dessas causas realísticas modernas nos obrigam a descartar princípios, conceitos, métodos e ferramentas, todos importantes na engenharia de software? Certamente que não, 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 no contexto da engenharia de software? Ivan Jacobson fornece uma discussão útil: Agilidade tornou-se atualmente uma palavra mágica quando se descreve um processo moderno de software. Tudo é ágil. Uma equipe ágil é uma equipe esperta, capaz de responder adequadamente a modificações. Modificações (software, membros da equipe, tecnologias, etc) é o foco principal do projeto e tem impacto no produto final. O apoio para modificações deveria ser incorporado em tudo que fazemos em software, algo que se adota porque está no coração e na alma do software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as especialidades dessas pessoas e sua capacidade de colaborar estão no âmago do sucesso do projeto. Na visão de Jacobson, o acolhimento de modificações é o principal guia para a agilidade. Os engenheiros de software devem reagir rapidamente se tiverem de acomodar as rápidas modificações citadas. Agilidade é dinâmica, específica em conteúdo, agressiva no acolhimento de modificações e orientada a crescimento. Steven Goldman Não devemos cometer o erro de considerar que a agilidade nos dá licença de improvisar soluções. Um processo é necessário e disciplina é essencial Mas a agilidade é mais do que uma resposta efetiva à modificação. Ela encoraja estruturas e atitudes de equipe que tornam a comunicação mais fácil, entre todos os envolvidos no processo. Enfatiza a rápida entrega do software e dá menos importância para produtos intermediários (nem sempre uma boa coisa). 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 flexível. A Aliança Ágil define 12 princípios para aqueles que querem alcançar agilidade: 1- Nossa maior prioridade é satisfazer o cliente desde o início por meio de entrega contínua de software valioso. 2 - Modificações de requisitos são bem vindas, mesmo que tardias no desenvolvimento. Os processos ágeis aproveitam as modificações como vantagens para a competitividade do cliente. 3 - Entrega de softwares funcionando frequentemente, a cada duas semanas até dois meses, de preferência no menos espaço de tempo. 4 - O pessoal do negócio e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto. Cont.: 5 Construção de projetos em torno de indivíduos motivados. Forneça-lhes o ambiente e apoio que precisam e confie que eles farão o trabalho. 6 O método mais eficiente e efetivo de levar informações para dentro da equipe de desenvolvimento é a conversa face a face. 7 Softwares funcionando é a principal medida de progresso. 8 Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter um ritmo constante, indefinidamente. 2

3 Cont.: 9 Atenção contínua à excelência técnica e ao bom projeto facilitam a agilidade. 10 Simplicidade a arte de maximizar a quantidade de trabalho não 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, então sintoniza e ajusta adequadamente seu comportamento. 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 aperfeiçoá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 estratégia de entrega incremental que forneça o software funcionando ao cliente o mais rápido possível. O que é um Processo Ágil? O que é um Processo Ágil? Qualquer processo ágil de software é caracterizado de modo que atenda a três suposições chave: 1 É difícil prever antecipadamente quais requisitos de software vão persistir e quais serão modificados. É igualmente difícil prever como as prioridades do cliente serão modificadas a medida que o projeto prossegue. 2 Para muitos tipos de software, o projeto e a construção são intercalados, isto é, as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados a medida que são criados. É difícil prever o quanto de projeto é necessário antes que a construção seja usada para comprovar o projeto. Cont. 3 Análise, projeto, construção e testes não são tão previsíveis (do ponto de vista do planejamento) como gostaríamos. Dadas essas três suposições surge uma questão importante, como criar um processo que possa gerenciar a imprevisibilidade? A resposta está na adaptabilidade do processo (as modificações rápidas do projeto e das condições técnicas). Um processo ágil, portanto, deve ser adaptável incrementalmente. O que é um Processo Ágil? O que é um Processo Ágil? Para realizar a adaptação incremental, uma equipe ágil requer o feedback do cliente (de modo que adaptações apropriadas possam ser feitas), isso pode ser feito através de protótipos operacionais. Assim, uma estratégia de desenvolvimento incremental deve ser instituída. Essa abordagem interativa habilita o cliente a avaliar o incremento de software regularmente, fornece o feedback necessário à equipe de software e influencia as adaptações do processo feitas para acomodar o feedback. Incrementos de software devem ser entregues em curtos períodos de tempo de modo que a adaptação acerte o passo com as modificações (imprevisibilidade). 3

4 A política do Desenvolvimento Ágil A política do Desenvolvimento Ágil Há um considerável debate sobre os benefícios e a aplicabilidade do desenvolvimento ágil de software em contraposição aos processos mais convencionais de engenharia de software. Os agilistas dizem: Os metodologistas tradicionais são um punhado de bitolados que preferem produzir documentação perfeita a um sistema funcionando que satisfaça às necessidades do negócio. Os tradicionalistas dizem: Os metodologistas levianos quer dizer, ágeis, são um punhado de gloriosos hackers que terão uma grande surpresa quando tiverem de ampliar seus brinquedos para chegar a um software que abranja toda a empresa. Como toda argumentação sobre tecnologia de software, esse debate metodológico arrisca-se a degenerar em uma guerra religiosa, se isso tiver início o pensamento racional desaparecerá e crenças, em vez de fatos, orientarão a tomada decisão. Ninguém é contra a agilidade. A verdadeira questão é: qual é o melhor modo de alcançá-la? Outra questão tão importante como essa é: como construir softwares que satisfaçam às necessidades do cliente atual e exiba característica de qualidade que lhe permitam ser estendido e ampliado para satisfazer às necessidades do cliente no longo prazo? A política do Desenvolvimento Ágil A política do Desenvolvimento Ágil Não existem respostas absolutas para qualquer uma dessas questões. 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 idéias que representam um afastamento significativo da engenharia de software convencional. No entanto, muitos conceitos ágeis são simples adaptações, de bons conceitos da engenharia de software. Conclusão: há muito a ser ganho considerando o melhor de ambas as escolas, e quase nada a ser ganho denegrindo qualquer uma dessas abordagens. Você não tem que escolher entre agilidade e engenharia de software. Em vez disso, defina uma abordagem de engenharia de software que seja ágil. Fatores Humanos Fatores Humanos Os proponentes do desenvolvimento ágil de software sofrem muito para enfatizar a importância dos fatores pessoais no desenvolvimento ágil bem sucedido. O desenvolvimento ágil enfoca os talentos e habilidades dos indivíduos moldando o processo a pessoas e equipes específicas. O ponto chave dessa declaração é que o processo se molda às necessidades das pessoas e da equipe, e não o contrário. O que é considerado meramente suficiente por uma equipe é ou suficiente ou insuficiente para outra. Se os membros de uma equipe de software tiverem de estabelecer as características do processo que é aplicado para construir software, uma certa quantidade de características chave deve existir entre as pessoas de uma equipe ágil e na equipe em si. São elas: Competência Foco comum Colaboração Capacidade de tomada de decisão Habilidade de resolver problemas vagos (ambigüidades) Respeito e confiança mútua Auto organização 4

5 Fatores Humanos Fatores Humanos No contexto de desenvolvimento ágil, a auto organização implica três 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. A auto organização tem um certo número de benefícios técnicos, porém, mas importante que isso, ela serve para aperfeiçoar a colaboração e aumentar a moral da equipe. Em essência, a equipe serve como sua própria gerência. A equipe seleciona quanto trabalho acredita que pode realizar dentro da iteração e a equipe se compromete com o trabalho. Nada desmotiva tanto uma equipe quanto alguém de fora assumir compromissos por ela. Nada motiva tanto uma equipe quanto a aceitação da responsabilidade de cumprir os compromissos que ela própria estabeleceu. Fatores Humanos Uma equipe auto organizada está no controle de trabalho que realiza. A equipe estabelece os seus próprios compromissos e define os planos para cumpri-los. O que é? Quem faz? Por que é importante? Quais são 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 satisfação do cliente e a entrega incremental do software logo de início, equipes de projeto pequenas, altamente motivadas, métodos informais, produtos de trabalho de engenharia de software mínimos e simplicidade global do desenvolvimento. As diretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e ao projeto (apesar dessas atividades não serem desencorajadas) e a comunicação ativa e contínua entre desenvolvedores e clientes. Quem faz? Engenheiros de software e outros interessados no projeto (gerentes, clientes e usuários finais) trabalham juntos em uma equipe ágil uma equipe que é autoorganizada e controla seu próprio destino. Uma equipe ágil enfatiza a comunicação e a colaboração entre todos que a compõem. 5

6 Por que é importante? O ambiente moderno de negócios que cria sistemas baseados em computador e produtos de software é apressado e sempre mutável. A engenharia ágil de software representa uma alternativa razoável 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 são os passos? As atividades básicas da engenharia de software: comunicação com o cliente, planejamento, modelagem, construção, entrega e avaliação permanecem. Porém, são reduzidas a um conjunto mínimo de tarefas que leva a equipe de projeto à construção e entrega. Qual é o produto do trabalho? Cliente e engenheiros de software que tem adotado a filosofia ágil tem a mesma impressão 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 condições de serem entregues e que satisfaçam ao cliente, você fez corretamente. Modelos ágeis de processo Modelos ágeis de processo A história da engenharia de software está congestionada com dúzias de descrições e metodologias obsoletas de processos, métodos de modelagem e notações, ferramentas e tecnologias. Cada uma delas ganhou notoriedade e foi depois eclipsada por algo mais novo e (pretensamente) melhor. Com a introdução de uma ampla gama de modelos ágeis de processo - cada qual lutando por aceitação na comunidade de desenvolvimento de software o movimento ágil está seguindo o mesmo caminho histórico. Os modelos ágeis de processo foram projetados de forma a atender aos quatro tópicos chave, de acordo com a filosofia ágil: A importância de equipes auto-organizadas que tem controle sobre o trabalho que executam; Comunicação e colaboração entre os membros da equipe e entre os profissionais e seus clientes; Um reconhecimento de que as modificações representam uma oportunidade; Ênfase na entrega rápida de softwares que satisfaçam ao cliente. Vejamos alguns: 6

7 O XP usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento predileto. Inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades: planejamento, projeto, codificação e teste. Vejamos cada uma das atividades: Começa com a criação de um conjunto de histórias (histórias do usuário) que descrevem as características e funcionalidades requeridas para o software a ser construído. Cada história é escrita pelo cliente e é colocada em um cartão de indexação. O cliente atribui um valor (prioridade) para a história, com base no valor de negócio global da característica ou da função. Membros da equipe XP avaliam então cada história e lhe atribuem um custo medido em semanas de desenvolvimento. Se a história precisar mais do que três semanas de desenvolvimento, pede-se ao cliente para dividir a história em histórias menores e a atribuição de valor e custo ocorre novamente. Novas histórias podem ser escritas a qualquer momento. Os clientes e a equipe XP trabalham juntos para decidir como agrupar histórias na versão seguinte (próximo incremento) a ser desenvolvido pela equipe XP. Uma vez feito um compromisso básico para a versão (acordo quanto às histórias incluídas, data de entrega e outros assuntos de projeto), a equipe XP determina as histórias que serão desenvolvidas seguindo os critérios a seguir: Histórias 7

8 1 todas as histórias serão implementadas imediatamente (dentro de poucas semanas); 2 as histórias com valor mais alto serão antecipadas no cronograma e implementadas primeiro; 3 as histórias de maior risco serão antecipadas no cronograma. Depois que a primeira versão 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 versões subseqüentes; A medida que o trabalho de desenvolvimento prossegue, o cliente pode adicionar histórias, mudar o valor de uma história existente, subdividir histórias ou eliminá-las. A equipe XP então reconsidera todas as versões remanescentes e modifica os seus planos adequadamente. O projeto XP segue rigorosamente o princípio KIS (keep it simple mantenha a simplicidade). Um projeto simples é sempre preferível em relação a uma representação mais complexa. Os cartões CRC identificam e organizam as classes orientada a objetos que são relevantes para o incremento do software atual; eles são o único produto de trabalho do projeto que é realizado como parte do processo XP. Além disso, o projeto fornece diretrizes de implementação para uma história como ela está escrita nada mais e nada menos. O XP encoraja o uso de cartões CRC (Class Responsability Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos. No trabalho de modelagem, cartões CRC (Classes, Responsabilidade, Colaborações) podem ser usados na etapa inicial de identificação de classes ou de candidatos a classe. São cartões (fichas de papel), cada ficha corresponde a uma classe. Cada ficha contém o nome da classe e 2 colunas com descrição de suas responsabilidades e colaborações. Colaborações apresentam outras classes que interagem com a classe descrita para o cumprimento de suas responsabilidades. Se um problema de projeto é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto. Denominado solução de ponta, o protótipo de projeto é implementado e avaliado. A intenção é diminuir o risco quando a implementação verdadeira começar a validar as estimativas originais correspondentes à história que contém o problema de projeto. 8

9 O XP encoraja a refabricação uma técnica de construção que é também uma técnica de projeto (altera e aperfeiçoa o código sem alterar o comportamento externo). Como o projeto XP praticamente não usa nenhuma notação e produz poucos ou nenhum produto de trabalho que não seja os cartões CRC e as soluções de ponta, o projeto é visto como um artefato provisório que pode e deve ser continuamente modificado à medida que a construção prossegue. A intenção da refabricação é controlar essas modificações sugerindo pequenas alterações de projeto que podem aperfeiçoar rapidamente o projeto. Deve-se notar, no entanto, que o reforço necessário à refabricação pode crescer sensivelmente à medida que o tamanho de uma aplicação cresce. Um noção central do XP é de que o projeto ocorre tanto antes quanto depois que a codificação começa. Refabricação significa que o projeto ocorre continuamente à medida que o sistema é construído. De fato, a atividade de construção em si vai fornecer à equipe XP diretrizes sobre como aperfeiçoar o projeto. Codificação: O XP recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar de projeto for feito, a equipe não avance para o código mas, em vez disso, desenvolva uma série de testes unitários que exercitarão cada uma das histórias que devem ser incluídas na versão atual (incremento). Codificação: Uma vez criados os testes unitários, o desenvolvedor esta melhor preparado para focalizar o que precisa ser implementado para passar no teste unitário. Completado o código, ele pode ser submetido imediatamente ao teste unitário, fornecendo assim feedback instantâneo para os desenvolvedores. Codificação: Um conceito chave durante a atividade de codificação é a programação em pares. 9

10 Codificação: O XP recomenda que duas pessoas trabalhem juntas em uma estação de trabalho de computador para criar o código correspondente a uma história. Isso fornece um mecanismo de solução de problemas em tempo real e de garantia de qualidade, também mantém os desenvolvedores focados no problema em mãos. Na prática, cada pessoa assume um papel ligeiramente diferente. Por exemplo, uma pessoa poderia pensar nos detalhes do código de uma parte específica do projeto, enquanto a outra garante que as normas de codificação estão sendo seguidas e que o código gerado vai se encaixar no projeto mais amplo da história. Codificação: À medida que os pares de programadores contemplam o seu trabalho, o código que eles desenvolvem é integrado ao trabalho dos outros. Em alguns casos, isso é realizado diariamente por uma equipe de integração. Em outros casos, os pares de programadores tem a responsabilidade de integração. Essa estratégia de integração contínua ajuda a evitar problemas de compatibilidade e interface e fornece um mecanismo de teste de fumaça que ajuda a descobrir rapidamente erros. Teste: Já mencionamos que a criação de um teste unitário antes da codificação começar é um elemento chave da abordagem XP. Os testes unitários que são criados devem ser implementados usando parâmetros que lhes permita ser automatizados. Isso encoraja uma estratégia de teste de regressão sempre que o código é modificado. Teste: A medida que os testes unitários individuais são organizados em uma seqüência universal de testes o teste de integração e validação do sistema pode ocorrer diariamente. Isso fornece à equipe XP uma indicação contínua de progresso e também pode levantar sinais de alerta se as coisas não 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 aceitação XP, também chamados de testes do cliente, são especificados pelo cliente e focalizam as características e funcionalidades do sistema global que são visíveis e passivos de revisão pelo cliente. Testes de aceitação são derivados das histórias do usuário que foram implementadas como parte de uma versão do software. Arquitetura XP 10

11 É um modo ágil de processo que foi desenvolvido por Jeff Sutherland e por sua equipe no início da década de Nos últimos anos foi realizado desenvolvimento adicional de métodos por Sewaber e Beedle. Os princípios são consistentes com o manifesto ágil: Pequenas equipes de trabalho são organizadas de modo a maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal. O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios para garantir que o melhor produto possível seja produzido. O processo produz frequentes incrementos do software que podem ser inspecionados, ajustados, testados, documentados e expandidos. O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras de baixo acoplamento, ou em pacotes. Testes e documentação constantes são realizados à medida que o produto é construído. O processo fornece a habilidade de declarar o produto pronto sempre que necessário (porque a concorrência acabou de entregar, porque a empresa precisa de dinheiro, porque o usuário/cliente precisa das funções, porque foi para essa data que foi prometido.) Os princípios são usados para guiar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades genéricas: Requisitos, Análise, Projeto, Evolução, Entrega. Em cada atividade, as tarefas de trabalho ocorrem dentro de um padrão de processo chamado de sprint. Sprint: consiste de unidades de trabalho que são necessárias para satisfazer a um requisito definido na pendência que precisa ser cumprido em um intervalo de tempo predefinido. Pendência: uma lista priorizada de requisitos ou características de projeto que fornecem valor de negócio para o cliente. Itens podem ser adicionados à pendência a qualquer momento (é assim que as modificações são introduzidas). O incorporou um conjunto de padrões de processo que enfatiza prioridade de projeto, unidades de trabalho compartimentalizadas, comunicação e feedback frequente do cliente. O gerente de produto avalia a pendência e atualiza as prioridades quando necessário. Fluxo de processo 11

12 O trabalho conduzido dentro de um sprint é adaptado ao problema em mãos e é definido, e frequentemente, modificado em tempo real pela equipe. A quantidade de sprints necessária para cada atividade varia dependendo da complexidade e do tamanho do produto. O permite a construção de softwares mais flexíveis. Reuniões são curtas (normalmente 15 minutos) feitas diariamente pela equipe. Três questões-chave são formuladas e respondidas por todos os membros da equipe. O que você fez desde a última reunião de equipe? Que obstáculos você está encontrando? O que você planeja realizar até a próxima reunião de equipe? Um líder da equipe, chamado de Master, lidera a reunião e avalia as respostas de cada pessoa. Essas reuniões diárias ajudam a equipe a descobrir problemas potenciais tão cedo quanto possível. Elas levam também à socialização do conhecimento e promovem, assim, uma estrutura de equipe autoorganizada. 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 não contenha toda a funcionalidade planejada, mas, em vez disso, as funções que podem ser entregues dentro do intervalo de tempo estabelecido. Outros modelos ágeis de processo Beedle e seus colegas apresentam uma discussão abrangente desses padrões na qual eles declaram: O considera antecipadamente a existência do caos.... Os padrões de processo permitem à equipe de desenvolvimento de software trabalhar de modo bem sucedido em um mundo em que se busca a eliminação da incerteza. O DAS (Desenvolvimento Adaptativo de Software) ressalta a colaboração humana e a auto-organização da equipe. Organizado como três atividades de arcabouço: especulação, colaboração e aprendizado. Usa um processo iterativo que incorpora planejamento do ciclo adaptativo, métodos relativamente rigorosos para o levantamento de requisitos e um ciclo de desenvolvimento iterativo que incorpora grupos enfocados nos clientes e revisões técnicas formais como mecanismos de feedback em tempo real. 12

13 Outros modelos ágeis de processo Outros modelos ágeis de processo O DSDM (Método de Desenvolvimento Dinâmico de Sistemas) define três diferentes ciclos interativos iteração do modelo funcional, iteração de projeto e construção e implementação procedidos por duas atividades de ciclo de vida adicionais estudo de viabilidade e estudo do negócio. Recomenda o uso de cronogramação a cada intervalo de tempo e sugere que, em cada incremento de software, é necessário apenas o trabalho suficiente a fim de facilitar o avanço para o incremento suficiente. O Crystal é uma família de modelos ágeis de processo que podem ser adotados para as características específicas de um projeto. Como outras abordagens ágeis, o Crystal adota uma estratégia iterativa, mas ajusta o rigor do processo de modo a acomodar projetos de diferentes tamanhos e complexidades. Outros modelos ágeis de processo Outros modelos ágeis de processo O FDD (Desenvolvimento Guiado por Características) é algo mais formal do que outros métodos ágeis, mas ainda mantém agilidade por concentrar a equipe de projeto no desenvolvimento das características funções valiosas para o cliente que podem ser implementadas em duas semanas ou menos. Fornece maior ênfase em gestão 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 construído. Por meio da proposição de um conjunto de princípios de modelagem centrais e suplementares, a AM fornece uma guia útil para os profissionais durante as tarefas de análise e do projeto. Exercício 1 - Quais pontos principais o "Manifesto para o Desenvolvimento Ágil de Softwares" valoriza? 2 - Qual o seu entendimento a partir da afirmação: "O Desenvolvimento ágil não é o contrário à sólida prática de engenharia de software e pode ser aplicado como uma filosofia prevalecente a todo trabalho do software"? 3 - Quais princípios definidos pela Aliança Ágil chamam mais a sua atenção? 4 - Qual o seu conceito para Agilidade, no cenário da Engenharia de Software? 5 - Um processo ágil de software é caracterizado de modo que atenda a três suposições chave, quais são elas? 6 - "Há um considerável debate sobre os benefícios e a aplicabilidade do desenvolvimento ágil de software em contraposição aos processos mais convencionais de engenharia de software." Qual a sua opinião sobre isso? 7 - Que características 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? 11 - O que é refabricação? 12 - Que outros modelos ágeis de processo você destacaria? Bibliografia PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: McGraw- Hill, Palestra Vinicius Teles. Notas de aula 13