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



Documentos relacionados
Engenharia de Software II

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

Com metodologias de desenvolvimento

Prof. Me. Marcos Echevarria

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Capítulo 2. Processos de Software Pearson Prentice Hall. Todos os direitos reservados. slide 1

Engenharia de Software II

Processos de gerenciamento de projetos em um projeto

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

Práticas de. Engenharia de Software. Givanaldo Rocha de Souza

Engenharia de Software II

Programação Extrema. Luis Fernando Machado. Engenharia de Software

Roteiro SENAC. Análise de Riscos. Planejamento do Gerenciamento de Riscos. Planejamento do Gerenciamento de Riscos

3 Qualidade de Software

Atividades da Engenharia de Software ATIVIDADES DE APOIO. Atividades da Engenharia de Software. Atividades da Engenharia de Software

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE

INTRODUÇÃO A PROJETOS

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Gerenciamento de Projetos Modulo II Clico de Vida e Organização

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

ENGENHARIA DE SOFTWARE I

Gerenciamento de Projetos Modulo VIII Riscos

Gerenciamento de Projetos Modulo III Grupo de Processos

Profa. Dra. Ana Paula Gonçalves Serra

Risco de projeto é um evento ou condição incerta que, se ocorrer, tem um efeito positivo ou um negativo no objetivo de um projeto.

Por que sua organização deve implementar a ABR - Auditoria Baseada em Riscos

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

UNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini

ITIL v3 - Operação de Serviço - Parte 1

Porque estudar Gestão de Projetos?

Administração de Pessoas

PMBoK Comentários das Provas TRE-PR 2009

Gerenciamento da Integração (PMBoK 5ª ed.)

3. Fase de Planejamento dos Ciclos de Construção do Software

POLÍTICA DE GESTÃO DE RISCO - PGR

Capítulo 2 Objetivos e benefícios de um Sistema de Informação

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis

Desenvolvimento Ágil de Software

Qualidade de Software

Introdução à. Engenharia de Software. Givanaldo Rocha de Souza

Unidade I Conceitos BásicosB. Conceitos BásicosB

29/05/2012. Gestão de Projetos. Luciano Gonçalves de Carvalho FATEC. Agenda. Gerenciamento de Integração do Projeto Exercícios Referências FATEC

ESTUDO DE VIABILIDADE. Santander, Victor - Unioeste Aula de Luiz Eduardo Guarino de Vasconcelos

UNIVERSIDADE FEDERAL DO PARANÁ UFPR BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Gestão dos Prazos e Custos do Projeto

O Processo Unificado

Qualidade de Software

Fundamentos de Teste de Software

Levantamento, Análise e Gestão Requisitos. Aula 06

Introdução. Gerência de Projetos de Software. Sumário. Sistemas de Informação para Processos Produtivos

Copyright Proibida Reprodução. Prof. Éder Clementino dos Santos

Disciplina: Técnicas de Racionalização de Processos Líder da Disciplina: Rosely Gaeta NOTA DE AULA 04 O PROJETO DE MELHORIA DOS PROCESSOS

7 perguntas para fazer a qualquer fornecedor de automação de força de vendas

Realização. Conselho Brasileiro de Manejo Florestal FSC Brasil.

agility made possible

COMO COMEÇAR 2016 se organizando?

TIPOS DE REUNIÕES. Mariangela de Paiva Oliveira. As pessoas se encontram em diferentes âmbitos:

A NECESSIDADE DE UMA NOVA VISÃO DO PROJETO NOS CURSOS DE ENGENHARIA CIVIL, FRENTE À NOVA REALIDADE DO SETOR EM BUSCA DA QUALIDADE

Projeto da Disciplina Parte1: Estudo de Viabilidade. Um Estudo de Viabilidade

Manual das planilhas de Obras v2.5

Aula 4 Estatística Conceitos básicos

Desenvolvimento Ágil. O Manifesto para o Desenvolvimento de Software Ágil

ELABORAÇÃO DE PROJETOS

Qualidade de Software

CONSIDERE ESTRATÉGIAS DE AQUISIÇÃO DE SELOS MECÂNICOS QUE SEJAM MUTUAMENTE BENÉFICAS. por Heinz P. Bloch

Medindo a Produtividade do Desenvolvimento de Aplicativos

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

Bem-vindo ao tópico sobre administração de listas de preços.

Primeiros passos das Planilhas de Obra v2.6

Engenharia de Software

<SUA EMPRESA> PROPOSTA DE SERVIÇOS

Pós Graduação Engenharia de Software

UML & Padrões Aula 3. UML e Padrões - Profª Kelly Christine C. Silva

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini prof.andre.luis.belini@gmail.com /

Comparativo entre Processos Ágeis. Daniel Ferreira

Especialização em Engenharia de Software e Banco de Dados

Guia passo a passo. Como se tornar um pequeno produtor certificado FSC

Desenvolvimento Ágil de Software em Larga Escala

Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização

A SEGUIR ALGUMAS DICAS PARA O DESENVOLVIMENTO DE UM PROJETO CIENTÍFICO

Engenharia de Software

MELHORES PRÁTICAS DA OCDE

PLANEJAMENTO ESTRATÉGICO

Módulo 9 A Avaliação de Desempenho faz parte do subsistema de aplicação de recursos humanos.

Gerenciamento de Requisitos Gerenciamento de Requisitos

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 03

Aula 17 Projetos de Melhorias

BSC Balance Score Card

Projeto de Desenvolvimento de Software. Apresentação (Ementa) e Introdução

NORMA NBR ISO 9001:2008

Sistemas Operacionais. Prof. André Y. Kusumoto

Engenharia da WEB 16/08/2011. Vida moderna. Sistemas WEB

Transcrição:

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

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

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

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

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

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

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

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

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

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

É um modo ágil de processo que foi desenvolvido por Jeff Sutherland e por sua equipe no início da década de 1990. 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

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

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, 2007. Palestra Vinicius Teles. Notas de aula 13