Desenvolvimento ágil

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Projeto indiciplinar
Matheus Prado 
Lucas Eduardo
Com base no livro Engenharia de Software por Roger S. Pressman
Desenvolvimento ágil
Indivíduos e interações acima do processo de ferramentas
Software operando acima de documentação completa
Colaboração dos clientes acima de negociação contratual
Respostas a mudanças acima de seguir um plano
Desenvolvimento ágil
Métodos ágeis oferecem benefícios importantes para um projeto, porem, não é indicado para todas as situações.
Um dos benefícios dos métodos ágeis é a característica de reduzir os custos das mudanças ao longo do processo de software
O desenvolvimento ágil foca em talentos e habilidades de indivíduos moldando o processo de acordo com as pessoas e equipes
	
		
Desenvolvimento ágil
Preceitos-chave:
Dificuldade de afirmar quais requisitos de software iram continuar e quais serão alterados ao longo do processo.
Dificuldade em prever o tempo de trabalho necessário antes do desenvolvimento do projeto
Analise, projeto, desenvolvimento e teste não são tão previsíveis.
Desenvolvimento ágil
Princípios da agilidade:
Satisfazer o cliente com entrega continua do software;
Acolhimento de pedidos de alteração;
Entrega freqüente de software em funcionamento;
Toda equipe deve trabalhar em conjunto;
Construção de projeto em torno de indivíduos motivados;
Conversa aberta, de forma presencial.
Desenvolvimento ágil
Princípios da agilidade
Software funcionando principal medida de progresso
A equipe deve manter um ritmo constante indefinidamente
Atenção continua aumenta a agilidade
Simplicidade é essencial
As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam
Em intervalos de tempo a equipe se avalia para se tornar-se mais eficiente
Desenvolvimento ágil
Fatores humanos
	“O desenvolvimento ágil foca em talentos e habilidades de indivíduos moldando o processo de acordo com as pessoas e equipes”
	Competência
	Foco comum
	colaboração
	habilidade de tomada de decisão
	habilidade de solução de problemas confusos
	confiança mutua e respeito
	auto-organização
Extreme Programming - XP
Valores da XP:	
Comunicação
Simplicidade
 Feedback
 Coragem
 Respeito 
Extreme Programming - XP
O Processo XP:
	O processo de desenvolvimento XP envolve um conjunto de regras e praticas constantes no contexto de quatro atividades metodológicas
	Planejamento
	Projeto
	Codificação
	Teste
Extreme Programming - XP
Planejamento
Atividade de levantamento de requisitos onde possibilita os técnicos da equipe XP compreender os fatores principais e funcionalidades do software.
A habilidade de “ouvir” possibilita a criação de um conjunto de historias de usuários onde descreve o resultado, características e funcionalidades de cada requisito a ser construído para o software.
Os membros avaliam cada historia e dão um custo medido em semanas para o desenvolvimento;
A equipe ordena as historias de três formas;
Todas serão implementadas imediatamente;
As historias de maior valor serão deslocadas para cima;
As historias de maior risco serão deslocadas para cima.
Extreme Programming - XP
Projeto
	A parte de projeto segue o principio de simplicidade, onde ele oferece um guia de implementação para uma historia a medida onde ela é escrita.
	A XP faz o uso de cartões CRC onde tem o propósito de identificar e organizar as classes orientadas a objetos relevantes para o software
	Um aspecto importante na XP é o de que a elaboração do projeto ocorre tanto antes como depois de ser iniciado a codificação.
Extreme Programming - XP
Codificação
Depois do desenvolvimento das historias a equipe não passa para a codificação, mas sim, uma serie de testes de unidade que exercitaram cada uma das historias para focar-se no que deve ser implementado para ser aprovado no teste.
Um dos conceitos chaves da XP é a programação em dupla, onde duas pessoas trabalham juntas para criar o código para uma historia, onde facilita a resolução de problemas e garantia de tempo, onde também mantém os desenvolvedores focados.
Extreme Programming - XP
Teste
Os testes são implementados usando uma metodologia onde possibilita eles a serem automatizados.Os teste de integração e validação do sistema podem ocorre diariamente.
Os testes de aceitação da XP, são especificados pelo cliente e mantêm o foco nas características e funcionalidades do sistema.Testes de aceitação são obtidos de historias de usuários como parte de uma versão do software
Industrial XP
“Evolução orgânica da XP onde possui espírito minimalista, centrado no cliente e orientado a testes com maior inclusão do gerenciamento” – Joshua Kerievsky
	Avaliação Imediata;
	Comunidade de projeto;
	Mapeamento do projeto;
	Gerenciamento orientado a testes;
	Retrospectivas;
	Aprendizagem continua.
Desenvolvimento de software adaptativo - ADS
Em ADS é usada uma técnica para construção de software e sistemas complexos onde ela possui três fases do seu ciclo de vida:
Especulação
Colaboração
Aprendizagem
Especulação
Planejamento de ciclos adaptativos
restrições do projeto
Requisitos básicos
Plano de entrega
Desenvolvimento de software adaptativo - ADS
Colaboração
Levantamento de necessidades
mini especificações
Aprendizagem
Componentes implementados/testados
Grupos focados para feedback
Revisões técnicas formais
Scrum
Scrum é usado para orientara atividades de desenvolvimento dentro de um processo que possui as seguintes atividades estruturais:
Requisito
Analise
Projeto
Evolução
Entrega
Scrum
Backlog – Lista com prioridades dos requisitos ou funcionalidade do projeto
Sprints – Unidades de trabalho solicitadas para atingir um requisito estabelecido no backlog
As alterações não são introduzidas durante a execução de um sprint.
Scrum
Reuniões Scrum – São reuniões curtas realizadas diariamente pela equipe, onde são feitas três perguntas para todos os membros da equipe
O que você realizou desde a ultima reunião ? 
Você esta tendo alguma dificuldade ?
O que você ira fazer antes da próxima reunião
Método de desenvolvimento de sistemas dinâmicos - DSDM
Utilizasse uma metodologia para construir e manter sistemas que atendem restrições de prazo apertados através do uso de protótipos em um ambiente de projeto controlado
80% de uma aplicação pode ser entregue em 20% do tempo que levaria para entregar a aplicação completa
Método de desenvolvimento de sistemas dinâmicos - DSDM
Ciclo de vida DSDM
Estudo da viabilidade – Estabelece os requisitos e restrições a serem aplicadas
Estudo do negocio – Estabelece os requisitos funcionais e de informação, definem a arquitetura básica 
Interação de modelos funcionais – Produz um conjunto de protótipos que demonstram a funcionalidade para o cliente, onde o objetivo é juntar requisitos adicionais ao se obter o feedback dos usuários
Método de desenvolvimento de sistemas dinâmicos - DSDM
Ciclo de vida DSDM
Interação de projeto e desenvolvimento – Revista protótipos desenvolvidos durante a interação de modelos funcionais para ter certeza que cada um passou pelo processo de engenharia para capacitá-los
Implementação – Desenvolve a ultima versão do incremento de software onde ele não pode estar 100% completo ou as alterações podem vir a ser solicitadas conforme o incremento.
Crystal
A Crystal nada mais é que um conjunto de metodologias com elementos essenciais comuns a todas mas com papeis, padrões de processo, produtos de trabalho e praticas únicos para cada uma delas.
A família Crystal é um conjunto de exemplos de processos ágeis que são efetivos para diferentes tipos de projeto onde a intenção é possibilitar que equipes ágeis selecionem o membro da família Crystal mais apropriado.
Desenvolvimento Dirigido a Funcionalidades - FDD
O FDD é um processo ágil onde pode ser aplicado a projetos de software de porte moderado e a projetos maiores
O FDD enfatiza a colaboração entre a equipe, gerencia problemas e complexidade
de projetos usando a decomposição baseada pela integração dos incrementos e a comunicação de detalhes técnicos usando meios verbais gráficos e texto
Desenvolvimento Dirigido a Funcionalidades - FDD
Funcionalidade
É uma função valorizada pelo cliente que possa ser implementada num prazo de 2 semanas ou menos. Onde na definição de funcionalidades podemos gerar os seguintes benefícios:
Funcionalidades podem ser organizadas em agrupamentos hierárquico relacionada com negócios
A equipe desenvolve funcionalidades operacionais a cada suas semanas 
Funcionalidades formam blocos pequenos que podem ser entregue, onde os usuários podem descrever mais facilmente e compreender como relacionam entre si mais prontamente, revisá-las de melhor termos.
Desenvolvimento Dirigido a Funcionalidades - FDD
Definição de uma funcionalidade
<acao> o <resultado> <por| para quem | de |para que> um <objeto>
Onde um objeto é uma pessoa local ou coisa, exemplo:
Adicione o produto ao carrinho
Mostre as especificações técnicas do Produto
Armazene as informações de remessa para o cliente
Um conjunto de funcionalidades agrupadas em categoria é definido com <acao> um <objeto>
Desenvolvimento Dirigido a Funcionalidades - FDD
Atividades metodológicas
Desenvolver um modelo geral 
Construir uma lista de funcionalidades – Lista de funcionalidades agrupadas em conjunto em áreas com afinidades temáticas
Planejar por funcionalidades – Um plano de desenvolvimento proprietário de classes
Projetar por funcionalidades – Um pacote de projetos
Desenvolver por funcionalidades – Função valor-cliente completada
Desenvolvimento de software enxuto - LSD
Princípios da LSD:
Eliminar desperdício – não adicionar recursos ou funções estranhas;
Incorporar qualidade – avaliar o impacto do custo e do cronograma;
Criar conhecimento – eliminar quaisquer etapas de processo supérfluas;
Adiar compromissos – estabelecer mecanismos para aprimorar o modo que a equipe levanta informações.
Desenvolvimento de software enxuto - LSD
Princípios da LSD:
Entrega rápida – assegurar-se que os testes encontrem o maior numero de erros;
Respeitar as pessoas – reduzir o tempo necessário para solicitar e obter uma decisão que afete o software; 
Otimizar o todo – racionalizar a maneira pela qual informações são transmitidas para os envolvidos.
Modelagem ágil - AM
Modelagem ágil nada mais é que uma metodologia baseada na pratica voltada para o desenvolvimento e documentação do sistema com base no software operacional
Ao desenvolver um sistema grande, com detalhes críticos o modo em que o sistema tende ser modelado é onde:
Todas as partes envolvidas passam entender melhor os requisitos a serem atingidos
O problema possa ser subdividido eficientemente
A equipe possa ser avaliada durante o desenvolvimento do sistema
Processo unificado Ágil - AUP
A AUP adota uma filosofia onde “serial para o que é amplo” e “iterativa para o que é particular”
O processo unificado ágil adota as atividades em fases UP clássicas, inicio, elaboração, construção e transição.
Camada serial – sequência linear de atividades de engenharia de software que possibilita a equipe a visualizar o fluxo do processo geral de um projeto. Porem dentro de cada atividade a equipe repete para alcançar a agilidade de entrega de incrementos de software para os usuários finais rapidamente.
Processo unificado Ágil - AUP
Cada iteração da AUP dirige-se para as seguintes atividades:
Modelagem – representação UML de universo de negocio e do problema são criados;
Implementação – os modelos são traduzidos para o código-fonte;
Teste – executado uma series de testes para assegurar que o código-fonte se ajuste aos requisitos;
Modelos de Processo
Processo de Software podemos dizer que é uma metodologia usada para as atividades ações e tarefas necessárias para desenvolver um software de qualidade
Processo de Software:
Um roteiro que ajuda a criar um resultado de alta qualidade e dentro do prazo
Quem realiza os roteiros são engenheiros de software
Importante para estabilidade, controle e organização
Produtos de trabalho são documentos e dados produzidos em consequência das atividades
Modelos de Processo
Um processo é um conjunto de atividades de trabalho, ações e tarefas realizadas para a criação de um software onde cada atividade é composta por um conjunto de ações da engenharia de software.
Ação podemos definir como um conjunto de tarefas, aonde identifica as tarefas de trabalho a ser completadas.
Uma metodologia de processo genética para a engenharia de software estabelece cinco atividades metodologias:
Comunicação
Planejamento
Modelagem
Construção
Entrega
Fluxo de processo
O fluxo de processo descreve como são organizadas as atividades metodológicas, bem como as ações e tarefas que ocorrem dentro de cada atividade;
Fluxo de processo linear – Executa cada uma das cinco atividades em sequência;
Fluxo de processo interativo – Repete uma ou mais atividades antes de seguir para a próxima;
Fluxo de processo evolucionário – Executa as tarefas de forma circular onde cada volta pelas atividades produz uma versão mais completa do software
Fluxo de processo paralelo – Executa uma ou mais atividades paralela a outra.
Padrões de processos
Um padrão de processo descreve um problema de processo encontrado durante um trabalho de engenharia de software, identificando o ambiente onde foi encontrado e sugerindo uma ou mais soluções .
Nome do padrão – O padrão deve receber um nome que descreva o contexto do processo
Forças – Ambiente onde se encontram o padrão e as questões que tornam visível o problema e que poderiam afetar sua solução
Padrões de processos
Tipos de padrões:
Padrão de estagio – define um problema associado a uma atividade metodológica de trabalho
Padrão de tarefas – define um problema associado a uma ação da engenharia de software ou tarefa de trabalho relevando para a pratica de engenharia
Padrão de fases – define a sequência das atividades metodológicas que ocorrem dentro do processo, mesmo quando o fluxo geral de atividades é iterativo por natureza
Modelo cascata
Modelo cascata, também chamado de ciclo de vida clássico, sugere uma abordagem sequencial e sistemática para o desenvolvimento de um software, levantando necessidades por parte dos clientes, avançando pelas fases de planejamento, modelagem, construção emprego e suporte continuo para o cliente.
Comunicação;
Planejamento;
Modelagem;
construção;
Emprego.
Modelo Cascata
Os contras do modelo cascata:
Mudanças podem provocar confusão à medida que a equipe de projeto prossegue;
Dificuldade para adequar a incerteza natural que existe no inicio de muitos projetos;
Uma versão operacional do programa não estará disponível antes de estarmos próximos do final do projeto.
Modelo V
O modelo V nada mais é que uma variação do modelo cascata, onde descreve a relação entre ações de garantia da qualidade e as ações associadas a comunicação, modelagem e atividades de construção iniciais.
À medida em que a equipe de software desce em relação ao lado esquerdo do V, os requisitos básicos do problema são refinados em representações progressivamente cada vez mais detalhadas, ao terminar o código, a equipe se desloca para cima do lado direito do V, realizando uma serie de testes
Modelo V
Modelos de processo incremental
Modelo incremental combina elementos dos fluxos de processos lineares e paralelos, onde aplica sequências lineares, de forma escalonada, à medida que o tempo vai avançando.
Cada sequência linear gera “incrementais” do software de maneira similar aos incrementais gerados por um fluxo de processos evolucionários.
Modelo de Processo evolucionário
O modelo evolucionário são iterativos onde possuem características que possibilitam desenvolver versões cada vez mais completas de um software.
Prototipação:
A prototipação é utilizada quando um cliente não possui requisitos para a implementação de um. Entretanto
seu paradigma é de grande ajuda ao cliente onde possibilita melhor compreensão sobre o que esta a ser desenvolvido .
Espiral:
A espiral acopla a natureza iterativa da prototipação com aspectos sistemáticos da cascata. Neste modelo, o processo de criação tende a passar por uma criação de versões do software evoluídas.
Processo Evolucionário
Paradigma usado na prototipação
Modelo espiral usado
Modelo Concorrente
O modelo concorrente normalmente é mais utilizado com frequência em projetos onde diferentes tipos de equipes estão trabalhando juntas em um mesmo desenvolvimento de projeto
A modelagem concorrente é aplicada em todos tipos de desenvolvimentos de software onde fornece uma imagem precisa do estado atual de um projeto
Modelo de processo Especializado
Desenvolvimento baseado em componentes:
Esse modelo é baseado em características do modelo espiral sendo assim por natureza, evolucionário.
É desenvolvido por partes de componentes pré-empacotados onde são escolhidos através de etapas onde uma arquitetura de software é projetada para acomodar os componentes que são integrados na arquitetura onde são feitos testes completos para assegurar a funcionalidade do sistema.
Modelo de metodos formais:
Esse modelo de métodos formais engloba atividades onde conduzem especificações matemáticas formais do software, onde possibilita a especificação, o desenvolvimento e a verificação de um sistema através de uma aplicação matemática rigorosa.
Modelo de processo Especializado
Desenvolvimento orientado a aspectos: 
Esse desenvolvimento tem como objetivo a preocupação em desenvolver métodos, técnicas e ferramentas que dêem apoio a todas as fases do desenvolvimento
Um processo distinto orientado a aspectos ainda não atingiu maturação, porem de acordo com Pressman é provável que um processo deste tipo ira adotar características dos modelos de processos evolucionários quanto do concorrente.
Processo Unificado
Um processo unificado é a tentativa de aproveitar os melhores recursos e características dos modelos tradicionais de processos de software;
Reconhece a importância da comunicação com o ciente de métodos racionalizados para descrevera a visão do cliente sobre um sistema;
Sugere um fluxo de processo iterativo e incremental, proporcionando sensações evolucionarias.
Processo Unificado
Modelo de processo pessoal e de equipe
“Modelo pessoal e de equipe enfatizam a medição, o planejamento e auto-direcionamento como ingredientes-chave para um processo de software bem-sucedido.”			 				- Roger S. Pressman
PSP(personal software process):
O PSP enfatiza a medição pessoal, tanto do artefato de software gerado quando da qualidade resultante dele.
Nesse processo é enfatizado a necessidade de identificar erros precocemente.
Prescrições:
Planejamento (requisitos, estimativas, cronograma);
Projeto de alto nível (projeto de componentes e protótipos;
Revisão de projeto de alto nível (verificações formais);
Desenvolvimento (projeto é refinado e revisado);
Autópsia (determina-se a eficácia do projeto).
Modelo de processo pessoal e de equipe
TSP(Team software process):
O TSP enfatiza a criação de equipes de processo ”auto-dirigidas” para a criação de um software de qualidade.
Objetivos TSP:
Criar equipes auto-dirigidas;
Mostrar aos gerentes como treinar e moticar a equipe;
Acelerar o aperfeiçoamento dos processos de software;
Fornecer orientações par melhorias.
Termologias:
Lançamento de projeto;
Projeto de alto nivel;
Implementação;
Integração;
Autopsia.