Engenharia de Software I - Slides de Aula Unidade III

Prévia do material em texto

Unidade III 
 
 
ENGENHARIA DE SOFTWARE I 
 
 
 
Prof. André Luiz 
Manifesto Ágil 
 Em 2001, Kent Beck e 16 outros notáveis desenvolvedores, 
produtores e consumidores de software, conhecidos como 
Aliança Ágil, assinaram o Manifesto para o Desenvolvimento 
Ágil de Software (http://agilemanifesto.org/). 
Manifesto Ágil 
 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. 
 Resposta às modificações em vez de seguir um plano. 
 
Manifesto Ágil: Princípios 
1. Satisfação do cliente por meio de entrega contínua. 
2. Modificação de requisitos são bem-vindas. 
3. Entrega de software funcionando frequentemente. 
4. Pessoal de negócio e desenvolvedores trabalhando juntos. 
5. Indivíduos motivados. 
6. Conversa face a face para levantar informações. 
 
 
Manifesto Ágil: Princípios 
 7. Software funcionando como medida de progresso. 
 8. Ritmo constante de desenvolvimento sustentável. 
 9. Excelência técnica. 
10. Simplicidade. 
11. Equipes auto-organizadas. 
12. Equipe reflete sobre como se tornar mais efetiva, então, 
sintoniza e ajusta adequadamente seu comportamento. 
 
Manifesto Ágil 
Como os times ágeis agregam valor: 
 
 
 
 
 
 
 
 
 
Fonte: Livro-texto. 
Manifesto Ágil 
Diferenças entre modelo tradicional e ágil: 
 
 
 
 
 
 
 
 
 
Fonte: Livro-texto. 
Extreme Programming (XP)‏ 
Princípios básicos do XP 
 Feedback rápido. 
 Assumir a simplicidade. 
 Mudanças incrementais. 
 Abraçar a mudança. 
 Trabalho de qualidade. 
 
 
 
XP: As 12 práticas 
 Processo de planejamento: planning game.‏ 
 Releases curtos. 
 Metáfora. 
 Projeto (design) simples. 
 Testes. 
 Refactoring. 
 Gerenciar a qualidade. 
 Programação em pares. 
 Propriedade coletiva do código. 
 Integração contínua. 
 Semana de 40 horas. 
 On-site customer: cliente sempre presente.‏ 
XP: Ciclo de Desenvolvimento 
 
 
 
 
 
 
 
 
 
 
Fonte: Livro-texto. 
XP: Problemas do Processo 
 Não haver nenhuma documentação do projeto. 
 Trabalhar somente com recursos de nível sênior é mais caro e 
mais difícil. 
 Difícil controle para projetos grandes. 
 Software é construído para o agora. 
 Mudança cultural. 
Interatividade 
Métodos ágeis visam acelerar o processo de desenvolvimento 
de software. Dentre as opções abaixo, qual representa uma 
prática proposta pelo Manifesto Ágil? 
a) Processo cascata de desenvolvimento. 
b) Equipe com perfil misto. 
c) Grande quantidade de desenvolvedores. 
d) Horas-extras não essenciais. 
e) Entregas contínuas. 
SCRUM 
 Originado em um estilo de gerenciamento ágil de projetos 
ágeis em empresas de fabricação de automóveis. 
 É um processo incremental para o desenvolvimento de 
qualquer produto de software e para o gerenciamento de 
qualquer projeto. 
 É extremamente formal e tem passos predefinidos a serem 
seguidos e com pouca flexibilidade de mudanças. 
 
 
SCRUM: Componentes 
 Processos: reunião de planejamento, reunião diária, reuniões 
de revisão e de lições aprendidas. 
 Ferramentas: quadro Kanban, estórias, gráficos de controle. 
 Pessoas: scrum master, product owner e equipe. 
 Cultura: time multidisciplinar, time autogerenciável, entrega de 
valor, cliente parte do time, entregas contínuas e colaboração. 
 
SCRUM: O processo 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Livro-texto. 
SCRUM: Conceitos 
 O Product Backlog é uma lista com todos os requisitos 
priorizados e ordenados de acordo com o valor que 
representam para o cliente e para o negócio. 
 Um sprint é um incremento de 2 a 4 semanas que a equipe de 
projeto tem para produzir o incremento. 
 Uma review meeting é uma reunião feita no final do sprint para 
o cliente realizar o aceite do incremento. 
 Uma retrostective meeting é uma reunião para o time avaliar os 
fatos positivos e negativos observados. 
SCRUM: Controles 
 
Fonte: Livro-texto. 
Quadro 
Kanban 
Gráfico 
Burndown 
SCRUM: Fatores de sucesso 
 Times pequenos. 
 Bom entendimento das necessidades do cliente. 
 Garantia de que os recursos e pessoas necessárias 
estão disponíveis. 
 Autogerenciamento fluente. 
 Práticas de engenharia e de outras disciplinas presentes. 
 
Iconix 
 É um modelo ágil dirigido por casos de uso, que utiliza 
prototipação desde o início e diagramas da UML. 
 Os diagramas utilizados são: casos de uso, diagrama de 
classes, diagrama de objetos e diagrama de sequência. 
 É um processo mais simples que o processo unificado, 
sem perder a simplicidade do XP. 
Iconix: O processo 
 
Fonte: Livro-texto. 
Iconix: Passo a passo 
1. Prototipar a interface com o usuário. 
2. Escrever um caso de uso que defina como a interface irá 
se comportar. 
3. Elaborar o diagrama de classes de domínio. 
4. Incluir a visão de solução técnica a partir dos casos de uso 
com o digrama de objetos. 
5. Elaborar os diagramas de sequência dos cenários. 
6. Implementar o caso de uso. 
7. Retornar ao passo 1 até terminarem as interfaces. 
 
 
Interatividade 
O SCRUM é um dos modelos ágeis mais utilizados no mercado. Qual 
das opções abaixo se refere a uma atividade do método SCRUM? 
a) Gerente de projetos. 
b) Reuniões de diárias e de revisão. 
c) Diagrama de classes. 
d) Dirigido por casos de uso. 
e) Protótipo de interface desde o início. 
Feature Driven Development (FDD) 
 Esse método existia antes do Manifesto ágil, publicado em 2001. 
 Baseia-se no desenvolvimento por funcionalidade, ou seja, por 
requisitos funcionais do sistema. 
 Pode ser utilizado em conjunto com o SCRUM, onde o FDD seja 
o processo de desenvolvimento e o SCRUM de gerenciamento. 
 
 
 
 
Feature Driven Development (FDD) 
Processos básicos 
 Análise orientada a objetos. 
 Decomposição funcional para criar a lista de funcionalidades. 
 Planejamento incremental por funcionalidade. 
 Desenho orientado a objetos. 
 Construção por funcionalidade. 
 Testes contínuos por funcionalidade. 
 
 
 
Feature Driven Development (FDD): 
Integração contínua 
 
Fonte: Livro-texto. 
Feature Driven Development (FDD) 
Uso de boas práticas 
 Modelagem orientada a objetos. 
 Desenvolvimento incremental. 
 Equipes pequenas. 
 Inspeção para garantir a qualidade. 
 Integração contínua. 
Problema 
 Desenvolvedor é incentivado como único responsável pelo 
módulo que desenvolve. 
Adaptative Softaware Development (ASD) 
Principais características 
 É incremental. 
 Ciclos de 4 a 8 semanas. 
 Cliente sempre presente durante o processo. 
 Pode ser usado para sistemas grandes. 
 Utiliza técnica de reunião JAD (Joint Application Development) 
para o desenvolvimento de aplicações. 
 
 
 
Adaptative Softaware Development (ASD): 
Fases do processo 
 Especular: define prazos e objetivos. 
 Colaborar: constrói de forma 
concorrente os vários componentes. 
 Aprender: faz-se repetidas revisões 
de qualidade, com a participação 
do cliente. 
início 
Fonte: Livro-texto. 
Adaptative Softaware Development (ASD) 
Uso de boas práticas 
 Desenvolvimento orientado a riscos. 
 Desenvolvimento baseado em componentes. 
 Equipes pequenas. 
 Prazos pré-fixados (time-boxed). 
 Boa tolerância a mudanças. 
Problema 
 Pouco levantamento de requisitos.Dynamic System Development Method (DSDM): 
Características 
 É o predecessor do método XP e baseado no RAD. 
 Utilização de fixação de tempo. 
 Equipes pequenas. 
 Bom suporte a mudanças. 
Dynamic System Development Method (DSDM): 
Fases do processo 
Funções que devem ser 
obedecidas 
 Equipes mistas. 
 Coordenador-técnico. 
 Usuário-embaixador. 
 Usuário-consultor. 
 Visionário. 
 Executivo responsável. 
 Especialista de domínio. 
 Gerente. 
 
Fonte: Livro-texto. 
Dynamic System Development Method (DSDM) 
Práticas utilizadas 
 Desenvolvimento incremental. 
 Usuário sempre envolvido. 
 Equipe DSDM autorizada a tomar decisões. 
 Foca na entrega frequente do produto. 
 “Construa‏certo‏antes‏de‏construir‏corretamente”. 
 Testes são integrados ao ciclo de vida. 
Problemas 
 Requisitos são acompanhados em alto nível. 
 Depende de autonomia para tomada de decisões. 
 
 
Interatividade 
O FDD, ASD e DSDM são métodos ágeis que precedem o 
Manifesto Ágil de 2001, mas já propõem uma série de boas 
práticas recomendadas pelo Manifesto. Das alternativas abaixo, 
qual contém práticas comuns aos três métodos? 
a) Cliente sempre presente e desenvolvimento incremental. 
b) Desenvolvimento incremental e prototipação. 
c) Baseado em componentes e reuso. 
d) Testes incorporados ao ciclo de vida e prototipação. 
e) Nenhuma das anteriores. 
Método crystal: 
Características 
Faz parte de um conjunto de métodos ágeis propostos por 
Alistar Cockburn em 2004. 
Considera os seguintes fatores 
 Cada projeto tem suas próprias características. 
 Equipes motivadas são fundamentais. 
 Comunicação precisa ser efetiva. 
 Foco na gestão de pessoas. 
 
Método crystal 
 Difere dos demais métodos ágeis por ser uma família de 
metodologias e não apenas uma. 
As famílias são definidas pelo tamanho da equipe e permitem 
a adaptação do método de acordo com o projeto: 
 Crystal Clear: 3 a 10 pessoas. 
 Crystal Yellow: 15 a 30 pessoas. 
 Crystal Orange: 30 a 50 pessoas. 
 
Método crystal 
Práticas utilizadas 
 Ênfase no processo de comunicação da equipe. 
 Especificações e modelos são informais. 
 Utiliza casos de uso da UML. 
 Usa incrementos regulares de um mês. 
 Método é pouco definido para permitir adaptações. 
Problemas 
 Informalidade pode gerar dúvidas em projetos maiores. 
 Flexibilidade de adaptação pode gerar falhas. 
 
Test Driven Development (TDD): 
Características 
 Não é um método de testes, mas sim de desenvolvimento, 
criado por Kent Beck, em 2003. 
Baseia-se em ciclos curtos e é caracterizado por 
 Primeiro o desenvolvedor cria casos de testes para uma 
melhoria ou nova funcionalidade. 
 Depois é produzido um código para atender aos testes esperados. 
Test Driven Development (TDD): 
Ciclo de Desenvolvimento 
Adicionar um teste 
 Escrever um teste baseado na especificação. 
 Faz o desenvolvedor focar nos requisitos 
 Na primeira execução, os testes devem falhar, pois o código 
não está pronto. 
Escrever o código 
 Construir o código para passar nos testes escritos e 
automatizados. 
 Todos os testes devem passar com sucesso. 
Test Driven Development (TDD): 
Ciclo de Desenvolvimento 
Refatorar o código 
 Melhoria do código escrito. 
 Refazer os testes após alterações. 
Repetir tudo 
 Iniciando outro teste, o ciclo é repetido. 
 Incorpora requisitos e novos testes até ficar 100% correto. 
 Usar a integração contínua para reversão. 
 
Test Driven Development (TDD) 
Práticas utilizadas 
 Processo incremental. 
 Especificações e modelos são informais. 
 Testes unitários efetivos. 
 Aumento da produtividade em alterações. 
Problemas 
 Sem especificações não se constrói. 
 A criação de testes automatizados pode gerar atrasos no 
tempo de construção. 
Modelagem Ágil 
 É um caminho alternativo para a falta de modelos preconizada 
pelos métodos ágeis, criando padrões, documentos e 
contratações formais. 
 Propõe-se a encontrar um meio-termo, que permita uma 
modelagem suficiente para o desenvolvimento e não se torne 
um fardo para as equipes de construção. 
 Permite que cada equipe defina o que é suficiente para o 
cliente e para o desenvolvimento. 
 
Modelagem Ágil 
 
Fonte: Livro-texto. 
Modelagem Ágil: Objetivos 
 Definir e colocar em exercício um conjunto de práticas que 
atendam às necessidades. 
 Lidar com a questão de incluir modelos aos métodos ágeis, 
tornando-o mais formal. 
 Discutir e propor um conjunto de atividades mínimas para a 
quebra do paradigma. 
Interatividade 
O Test Driven Development (TDD) é um método que tem como 
característica principal: 
a) Aumentar a qualidade da especificação. 
b) Fazer testes integrados. 
c) Escrever os testes antes da codificação. 
d) Elaborar protótipo. 
e) Codificar e depois testar. 
 
 
 
 
 
ATÉ A PRÓXIMA!