Upload
alvaro-farias-pinheiro
View
607
Download
4
Embed Size (px)
DESCRIPTION
Coletânea dos principais fundamentos da Engenharia de Software
Citation preview
https://www.facebook.com/alvarofpinheiroaulas/
br.linkedin.com/in/alvarofpinheiro/
Engenharia de SoftwareFundamentos
http://www.alvarofpinheiro.eti.br
Projeto
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
ProjetosOrigem dos erros nos softwares
Análise
56%
Desenho
27%
Programação
7%
Outros
10%
www.alvarofpinheiro.eti.br
ProjetosCusto de correção dos erros
Cu
sto
Etapas do ciclo de desenvolvimento
Incremento de
100 a 1000 vezes
www.alvarofpinheiro.eti.br
Projetos Incremento do custo dos erros
Captura de requisitos
Manutenção
Prova de Aceitação
Teste Unitário
Codificação
Análise e Desenho
1
2,5
5
10
25
100
Boehm, 1988
www.alvarofpinheiro.eti.br
Fatores de êxito dos projetos
• Em 1998 o Standish Group levantou 365 companhias e 8000
projetos e apresentou os resultados em seu informe de 1999
• Melhora no êxito dos projetos: 16% en 1994 vs. 26% em
1998 além de redução de custos e tempos
• Causas: participação dos usuários, suporte executivo, claro
estabelecimento dos objetivos do negócio, administração de
projetos, entregas permanentes, requisitos firmes, menor
tamanho e duração do projeto, etc.
www.alvarofpinheiro.eti.br
Êxito do projeto segundo seu tamanho
0
10
20
30
40
50
60
até $750m
$750m a $1.5M
$1.5M a $3M
$3M a $6M
$6M a $10M
+ de $10M
Standish Group, 1999
Porcentagem de
êxito (%)
Tamanho do projeto ($)
www.alvarofpinheiro.eti.br
As seis melhores práticas para
desenvolver Projetos de SW
• Desenvolvimento iterativo
• Administração de requisitos
• Uso de arquitetura de componentes
• Modelo visual (UML)
• Verificação contínua da qualidade
• Administração de Mudanças
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Análise
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Engenharia
de
Requisitoswww.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Metodologias
Modelos
Processos
Técnicaswww.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Engenharia de Software
Metodologias
O termo Engenharia de Software surgiu em uma conferência no final da década de 60. A proposta inicial era a sistematização do desenvolvimento de software, que deveria ser tratado com engenharia e não como arte.
www.alvarofpinheiro.eti.br
Engenharia de Software
Metodologias
Desta forma, a idéia foi propor a utilização de métodos, ferramentas e técnicas para a produção de software confiável, correto e entregue respeitando os prazos e custos definidos.
www.alvarofpinheiro.eti.br
Metodologias
As metodologias tradicionais devem ser aplicadas apenas em situações em que os requisitos do software são estáveis e requisitos futuros são previsíveis.
www.alvarofpinheiro.eti.br
Dentre os fatores responsáveis por alterações nos requisitos estão a dinâmica das organizações, as alterações nas leis e as mudanças pedidas pelos stakeholders, que geralmente têm dificuldades em definir o escopo do futuro software.
Metodologias
www.alvarofpinheiro.eti.br
Metodologias
As metodologias ágeis incentivam a mudança nos requisitos, pois desta forma é possível realmente entregar ao cliente o produto que ele precisa.
www.alvarofpinheiro.eti.br
Metodologias
O termo “metodologias ágeis” tornou-se popular em 2001 quando dezessete especialistas em processos de desenvolvimento de software representando os métodos Extreme Programming(XP), Scrum, DSDM, Crystal e outros, estabeleceram princípios comuns compartilhados por todos esses métodos.
www.alvarofpinheiro.eti.br
Metodologias Ágeis
Conceito
Para ser realmente considerada ágil a metodologia deve aceitar as mudanças ao invés de tentar prever o futuro.
O problema é como receber,avaliar e responder às mudanças.
www.alvarofpinheiro.eti.br
Metodologias Ágeis
Introdução
Enquanto as metodologias ágeis variam em termos de práticas e ênfases, elas compartilham algumas características, como desenvolvimento iterativo e incremental, comunicação e redução de produtos intermediários, como documentação extensiva.
www.alvarofpinheiro.eti.br
Metodologias Ágeis
Introdução
Desta forma existem maiores possibilidades de atender aos requisitos do cliente, que muitasvezes são mutáveis.
www.alvarofpinheiro.eti.br
Metodologias Ágeis
Modelos
Dentre as várias metodologias ágeis existentes, as mais conhecidas são a eXtremeProgramming e a Scrum.
www.alvarofpinheiro.eti.br
Metodologias Ágeis
X
Metodologias Tradicionais
Um exemplo de uma metodologiatradicional ou pesada é o modelo em Cascata, que é composto basicamente por atividadesseqüenciais de levantamento de requisitos, análise, projeto, implementação, teste, implantação e manutenção.
www.alvarofpinheiro.eti.br
Metodologias
Manifesto Ágil
O resultado foi a criação da Aliança Ágil e o estabelecimento do “Manifesto Ágil” (Agile Manifesto).
www.alvarofpinheiro.eti.br
Metodologias
Manifesto Ágil Conceitos
Indivíduos e interações ao invés de processos e ferramentas.
Software executável ao invés dedocumentação.
Colaboração do cliente ao invés de negociação de contratos.
Respostas rápidas a mudanças ao invés de seguir planos.
www.alvarofpinheiro.eti.br
Metodologias
É uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente.
www.alvarofpinheiro.eti.br
Modelo Cascata
O modelo em Cascata dominou a forma de desenvolvimento de software até o início da década de 90, apesar das advertências dos pesquisadores da área e dos desenvolvedores, que identificaram os problemas gerados ao se adotar esta visão seqüencial de tarefas.
www.alvarofpinheiro.eti.br
Modelo Cascata
O pesquisador, Tom Gilb, desencoraja o uso do modelo em Cascata para grandes softwares, estimulando o desenvolvimento incremental como um modelo que apresenta menores riscos e maiores possibilidades de sucesso.
www.alvarofpinheiro.eti.br
Processo
www.alvarofpinheiro.eti.br
O que é um processo
• Um processo define quem faz o que,
quando e como para se alcançar
um objetivo
www.alvarofpinheiro.eti.br
Processo
• Servir de guia para todos
• Especificar quais artefatos devem ser
gerados e quando devem ser gerados.
• Direcionar as Atividades individuais e de
equipes.
• Oferecer critérios para o gerenciamento
ISO9000-3
www.alvarofpinheiro.eti.br
Processo de desenvolvimento
de um software
• Elicitação de requisitos
• Definição da arquitetura
• Análise
• Projeto
• Implementação
• Testes
• Implantação
• Manutenção
www.alvarofpinheiro.eti.br
Controle dos Processos
• Arquitetura
• CMMI
• Fases
• Software Process Automation
• Fabrica de Software
www.alvarofpinheiro.eti.br
Metodologias
Tradicionais
www.alvarofpinheiro.eti.br
Rational
Unified
Process
(RUP)www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
RUP é um framework de processo centrado na
arquitetura, baseado em UML, dirigido por casos
de uso e como tal, precisa ser instanciado de
acordo com variáveis de tamanho,
complexidade e domínio do sistema, de acordo
com a organização com seus níveis de
processos e experiências e capacidade das
pessoas
RUP
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Metodologias
Ágeis
www.alvarofpinheiro.eti.br
Scrum
www.alvarofpinheiro.eti.br
Scrum
Fases• Planejamento
• Sprints– Ciclos
• Encerramento
www.alvarofpinheiro.eti.br
Scrum
Outra metodologia ágil que apresenta uma comunidade grande de usuários.
www.alvarofpinheiro.eti.br
Scrum
Objetivo
Seu objetivo é fornecer um processo conveniente para projeto e desenvolvimento orientado a objeto.
www.alvarofpinheiro.eti.br
Scrum
Outros Objetivos
Garantir maior flexibilidade e habilidade para
tratamento de sistemas complexos e simples;
Produzir um sistema susceptível a mudanças de
requisitos iniciais e adicionais durante o projeto:
Requerimentos dos clientes;
Necessidades do negócio; Pressão relativa ao tempo;
Competitividade do mercado;
Qualidade;
Recursos.
www.alvarofpinheiro.eti.br
Scrum
Abordagem
A Scrum apresenta uma abordagem empírica que aplica algumas idéias da teoria de controle de processos industriais para o desenvolvimento de softwares, reintroduzindo as idéias de flexibilidade, adaptabilidade e produtividade.
www.alvarofpinheiro.eti.br
Scrum
Abordagem
O foco da metodologia é encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente em constante mudança.
www.alvarofpinheiro.eti.br
Scrum
Idéia
A idéia principal da Scrum é que odesenvolvimento de softwares envolve muitas variáveis técnicas e do ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças.
www.alvarofpinheiro.eti.br
Scrum
A metodologia é baseada em princípios semelhantes aos da XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas para promover visibilidade para o desenvolvimento.
No entanto, as dimensões em Scrum diferem de XP.
www.alvarofpinheiro.eti.br
Scrum
A Scrum divide o desenvolvimento emiterações (sprints) de trinta dias. Equipes pequenas, de até dez pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (os requisitos, em outras palavras) definidas no início de cada sprint. A equipe é responsável pelo desenvolvimento desta funcionalidade.
www.alvarofpinheiro.eti.br
Scrum
Na Scrum existem reuniões de acompanhamento diárias. Nessas reuniões, que são preferencialmente de curta duração (aproximadamente quinze minutos), são discutidos pontos como o que foi feito desde a última reunião e o que precisa ser feito até a próxima. As dificuldades encontradas e os fatores de impedimento (bottlenecks) são identificados e resolvidos.
www.alvarofpinheiro.eti.br
Scrum
Introdução
ORIGEM:
ADM (Advanced
Development Methods)
+
VMARK Software
METODOLOGIA:
Gerenciamento, manutenção
e desenvolvimento de softwares:
simples e pequenos
grandes e complexos
PROCESSO:
Ágil
Empírico
Incremental
BASE P/ SCRUM:
Técnicas e tools OO
www.alvarofpinheiro.eti.br
Scrum
Características
Deliverable flexível;
Cronograma flexível;
Times de desenvolvimento pequenos (por volta de 6);
Revisões frequentes;
Colaboração;
Orientação a Objeto.
www.alvarofpinheiro.eti.br
Scrum
Fases
Planejamento• Processo definido
• Relativamente curta
• Design da arquitetura do sistema
• Estimativas de datas e custos
• Criação do backlog
– Participação de clientes e outros departamentos
• Levantamento dos requisitos e atribuição de prioridades
• Definição de equipes e seus líderes
• Definição de pacotes a serem desenvolvidos
Backlog
www.alvarofpinheiro.eti.br
Scrum
Fases
Sprint
• Processo Empírico
• Cada time recebe uma parte do backlog para desenvolvimento – O backlog não sofrerá modificações durante o Sprint
• Duração de 1 a 4 semanas
• Sempre apresentam um executável ao final Fonte: Mountain Goat Software
www.alvarofpinheiro.eti.br
Scrum
Fases – Sprint
Reuniões Diárias• Cerca de 15 minutos de duração
• Gerenciada pelo líder de cada equipe
• Todos respondem às perguntas:– O que você realizou desde a última reunião?
– Quais problemas você enfrentou?
– Em que você trabalhará até a próxima reunião?
• Benefícios:– Maior integração entre os membros da equipe
– Rápida solução de problemas
• Promovem o compartilhamento de conhecimento
– Progresso medido continuamente
• Minimização de riscos
www.alvarofpinheiro.eti.br
Scrum
Fases – Sprint
Revisão• Deve obedecer à data de entrega
– Permitida a diminuição de funcionalidades
• Apresentação do produto à clientes e/ou diretores de marketing
– Sugestões de mudanças são incorporadas ao backlog
• Produto pode até ser lançado no mercado
• Benefícios:
– Apresentar resultados concretos ao cliente
– Integrar e testar uma boa parte do software
– Motivação da equipe
www.alvarofpinheiro.eti.br
Scrum
Fases
Encerramento• Iniciada quando todos os aspectos são
satisfatórios (tempo, competitividade, requisitos,
qualidade, custo)
• Atividades:
– Testes de integração
– Testes de sistema
– Documentação do usuário
– Preparação de material de treinamento
– Preparação de material de marketing
www.alvarofpinheiro.eti.br
Qualidade, Gerenciamento e Testes
Passos e papéis bem definidos
Gerenciamento de riscos
Revisões frequentes / diárias
Definição de padrões
Realização de testes
Elaboração de documentação
Grupo QA
Controles
Backlog
Release/Melhoria
Mudanças
Problemas
Soluções
Issues
Scrum
www.alvarofpinheiro.eti.br
Conclusões
Divisão de responsabilidades papéis bem definidos
Processo ágil e flexível inúmeras mudanças no decorrer do
projeto
Foco em controle/gerenciamento minimiza risco
maximiza qualidade
Times pequenos
Colaboração
Ausência de práticas de
Engenharia de Software
(técnicas e notações) e
tools
Necessidade de
associação com outras
metodologias e tools
(XP, GNATS)
Dificuldade na
implementação de
mudanças
Scrum
www.alvarofpinheiro.eti.br
XP – eXtreme
Programming
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Introdução
Não se pode comparar XP com UML, já que UML se presta apenas como linguagem de modelagem, não define processos e XP define processo e não modelagem. Conclusão, se você quiser pode usar UML com XP.
www.alvarofpinheiro.eti.br
Introdução
Entretanto, diferente dos processos tradicionais, em XP a modelagem tem duas utilidades:
1. O problema a ser tratado é complexo e precisa ser melhor entendido.2. Uma parte do sistema ficou "estável" (sem muitas modificações), e pode ser documentada.
www.alvarofpinheiro.eti.br
Metodologia
XP – eXtreme Programming
Dentre as principais diferenças da XP em relação às outras metodologias estão:
· Feedback constante;· Abordagem incremental;· A comunicação entre as pessoas
é encorajada.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Conceito
Em XP a modelagem não deve ser usada para definir o design do sistema.
Em XP assume-se que o sistema está em constante mudança, ou seja, seu design vai mudar, e sua modelagem vai estar furada.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Teste Primeiro o Desenvolvimento
Se quiser modelar para ter um melhor entendimento, sem problemas, mas tenha em mente que é uma modelagem que pode não servir assim que o sistema sofrer alterações, ao invés, XP prega que se use Test First Design(ou Test Driven Development, outro nome pra mesma coisa).
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Vantagem
Qual a vantagem em usar XP em relação às metodologias tradicionais?
XP é baseado em sistemas que sofrem constante mudança de requisitos, para esse tipo de sistema, a vantagem é poder mudar os requisitos sem o impacto no desenvolvimento caso fosse utilizada uma metodologia tradicional.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Primeiro Projeto
O primeiro projeto a usar XP foi o C3, da Chrysler. Após anos de fracasso utilizando metodologias tradicionais, com o uso da XP oprojeto ficou pronto em pouco mais de um ano.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Paradigma
A maioria das regras da XP causapolêmica à primeira vista e muitas não fazem sentido se aplicadas isoladamente.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Paradigma
A XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Paradigma
As regras, práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Regra: Comunicação
A finalidade do princípio de comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação. A comunicação entre os desenvolvedores e o gerente do projeto também é encorajada.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Regra: Simplicidade
A simplicidade visa permitir a criação de código simples que não deve possuir funções desnecessárias. Por código simples entende-se implementar o software com o menor número possível de classes e métodos. Outra idéia importante da simplicidade é procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Regra: Feedback
A prática do feedback constante significaque o programador terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Em relação ao cliente, o feedback constante significa que ele terá freqüentemente uma parte do software totalmente funcional para avaliar. O cliente então constantemente sugere novas características e informações aos desenvolvedores. Eventuais erros e não conformidades são rapidamente identificados e corrigidos nas próximas versões. Desta forma, a tendência é que o produto final esteja de acordo com as expectativas reais do cliente.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Regra: Coragem
É necessário coragem para implantar os três valores anteriores. Por exemplo, não são todas as pessoas que possuem facilidade decomunicação e têm bom relacionamento. A coragem também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar. Além disso, é preciso coragem para obter feedback constante do cliente.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Práticas
A XP baseia-se nas 12 práticas.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Práticas
· Planejamento· Entregas freqüentes· Metáfora· Projeto simples· Testes· Refatoração· Programação em pares· Propriedade coletiva· Integração contínua· 40 horas de trabalho semanal· Cliente presente· Código padrão
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 1: Planejamento
Consiste em decidir o que é necessário ser feito e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros. Além disso, a XP procura evitar os problemas de relacionamento entre a área de negócios (clientes) e a área de desenvolvimento. As duas áreas devem cooperar para o sucesso do projeto, e cada uma deve focar em partes específicas do projeto. Desta forma, enquanto a área de negócios deve decidir sobre o escopo, a composição das versões e as datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma detalhado para que o software seja entregue nas datas especificadas.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 2: Entregas Freqüêntes
Visa à construção de um software simples, e conforme os requisitos surgem, há a atualização do software. Cada versão entregue deve tero menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo, melhora as avaliações e o feedback do cliente, aumentando aprobabilidade do software final estar de acordo com os requisitos do cliente.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 3: Metáfora
São as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar odesenvolvimento do software.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 4: Projeto Simples
O programa desenvolvido pelo método XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem seradicionados assim que eles realmenteexistirem. Esta forma de raciocínio seopõe ao “implemente para hoje e projete para amanhã”.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 5: Testes
A XP focaliza a validação do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando primeiramente os testes.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 6: Refatoração
Focaliza o aperfeiçoamento do projeto do software e está presenteem todo o desenvolvimento. Arefatoração deve ser feita apenas quando é necessário, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que é possível simplificar o módulo atual sem perder nenhuma funcionalidade.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 7: Programação em Pares
A implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. O desenvolvedor que está com o controle do teclado e do mouse implementa o código, enquanto o outro observa continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos e semânticos e pensando estrategicamente em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser alterados continuamente. Uma grande vantagem da programação em dupla é a possibilidade dos desenvolvedores estarem continuamente aprendendo um com o outro.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 8: Propriedade Coletiva
O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça a bateria de testes necessária. Isto é possível porque na XP todos são responsáveis pelo software inteiro. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto com poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 9: Integração Contínua
Interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos. Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem porque fica óbvio quem deve fazer as correções quando os testes falham: a última equipe que integrou código novo ao software. Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ter livre acesso a todos os membros da equipe.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 10: 40 hs de trabalho
semanal
A XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prática procura ratificar o foco nas pessoas e não em processos e planejamentos. Caso seja necessário, os planos devem ser alterados, ao invés de sobrecarregar as pessoas.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 11: Cliente Presente
É fundamental a participação do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento.
www.alvarofpinheiro.eti.br
XP – eXtreme Programming
Prática 12: Código Padrão
Padronização na arquitetura do código, para que este possa ser compartilhado entre todos os programadores.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Crystal
Processo de
Desenvolvimento
de Software
www.alvarofpinheiro.eti.br
• Crystal/Clear faz parte, na realidade, de um conjunto de metodologias criado por Cockburn. As premissas apresentadas para a existência deste conjunto são:
www.alvarofpinheiro.eti.br
• Todo projeto tem necessidades, convenções e uma metodologia diferentes.
• O funcionamento do projeto é influenciado por fatores humanos, e há melhora neste quando os indivíduos produzem melhor.
• Comunicação melhor e lançamentos freqüentes reduzem a necessidade de construir produtos intermediários do processo
www.alvarofpinheiro.eti.br
• Crystal/Clear é uma metodologia direcionada a projetos pequenos, com equipes de até 6 desenvolvedores. Assim como com SCRUM, os membros da equipe tem especialidades distintas. Existe uma forte ênfase na comunicação entre os membros do grupo.
Existem outras metodologias Crystal para grupos maiores.
www.alvarofpinheiro.eti.br
• Toda a especificação e projeto são feitos informalmente, utilizando quadros publicamente visíveis. Os requisitos são elaborados utilizando casos de uso, um conceito similar às estórias de usuário em XP, onde são enunciados os requisitos como tarefas e um processo para sua execução.
www.alvarofpinheiro.eti.br
• As entregas das novas versões de software são feitos em incrementos regulares de um mês, e existem alguns subprodutos do processo que são responsabilidade de membros específicos do projeto.
www.alvarofpinheiro.eti.br
• Grande parte da metodologia é pouco definida, e segundo o autor, isto é proposital; a idéia de Crystal/Clear é permitir que cada organização implemente as atividades que lhe parecem adequadas, fornecendo um mínimo de suporte útil do ponto de vista de comunicação e documentos
www.alvarofpinheiro.eti.br
A família Crystal de Métodos
• Criada por Alistair Cockburn
• http://alistair.cockburn.us/crystal
• Editor da série Agile Software Development
da Addison-Wesley.
www.alvarofpinheiro.eti.br
Feature Driven
Development
Desenvolvimento
orientado a
funcionalidadeswww.alvarofpinheiro.eti.br
FDD - Características
Método ágil e adaptativo;
Foco nas fases de desenho e construção
Interage com outras metodologias
Não exige nenhum processo específico de modelagem
Possui desenvolvimento iterativo
Enfatiza aspectos de qualidade durante o processo e
inclui entregas freqüentes e tangíveis
Suporta desenvolvimento ágil com rápidas adaptações às
mudanças de requisitos e necessidades do mercado
www.alvarofpinheiro.eti.br
FDD - Processos
O FDD consiste de 5 processos principais:
www.alvarofpinheiro.eti.br
FDD – Processos (Cont.)
Desenvolver um modelo compreensível (Develop
an overall model)
Construir uma lista de funcionalidades (Build a
features list)
Planejar por funcionalidade (Plan By Feature)
Projetar por funcionalidade (Design by feature)
Construir por funcionalidade (Build by feature)
www.alvarofpinheiro.eti.br
FDD - Cargos e Responsabilidades
Principais Gerente de projeto (Project Manager)
Arquiteto líder (Chief architect)
Gerente de desenvolvimento (Development Manager)
Programador líder (Chief programmer)
Proprietário de classe (Class owner)
Especialísta do domínio (Domain experts)
Gerente do domínio (Domain manager)
www.alvarofpinheiro.eti.br
FDD - Cargos e Responsabilidades
(Cont.)
De apoio Gerente de versão (Release manager)
Guru de linguagem (Language lawyer/language guru)
Engenheiro de construção (Build engineer)
“Ferramenteiro” (Toolsmith)
Administrador de sistemas (System Administrator)
Adicionais Testadores (Testers)
Instaladores (Deployers)
Escritores técnicos (Technical writes)
www.alvarofpinheiro.eti.br
FDD - Boas Práticas
Modelagem de objetos de domínio (Domain Object Modeling)
Exploração e explicação do problema do domínio
Resulta em um arcabouço
Desenvolver por funcionalidade (Developing by feature)
Desenvolvimento e acompanhamento do progresso através de da lista de
funcionalidades.
Proprietários de classes individuais (Individual class ownership)
Cada classe possui um único desenvolvedor responsável
www.alvarofpinheiro.eti.br
FDD - Boas Práticas (Cont.)
Equipe de funcionalidades (Feature teams)
Formação de equipes pequenas e dinâmicas.
Inspeção (Inspection)
Uso dos melhores métodos conhecidos de detecção de erros.
Construções freqüentes (Regular Builds)
Garantir que existe um sistema sempre disponível e de-monstrável.
Administração de Configuração (Configuration Manager)
Habilita acompanhamento do histórico do código-fonte..
www.alvarofpinheiro.eti.br
Dynamic Systems
Development
Method (DSDM)
Método dinâmico de
desenvolvimento de
sistemas www.alvarofpinheiro.eti.br
DSDM - Características
Progenitor do XP
Arcabouço para desenvolvimento rápido de
aplicações (RAD)
Fixa tempo e recursos ajustando a quantia de
funcio-nalidades
Pequenas equipes
Suporta mudanças nos requisitos durante o ciclo
de vida
www.alvarofpinheiro.eti.br
DSDM - FasesO DSDM consiste de 5 fases:
Feasibility
Review Study
www.alvarofpinheiro.eti.br
DSDM – Fases (Cont.)
Estudo das possibilidades (Feasibility
study)
Estudo dos negócios (Business study)
Iteração do modelo funcional (Functional
model iteration)
Iteração de projeto e construção (Design
and build iteration)
Implementação final (Final implementation)
www.alvarofpinheiro.eti.br
DSDM - Cargos e
Responsabilidades
Desenvolvedores (Developers)
Desenvolvedores Sêniores (Senior Developers)
Coordenador Técnico (Technical Coordinator
Usuário Embaixador (Ambassador User)
Usuário Consultor (Adviser User)
Visionário (Visionary)
Executivo responsável (Executive Sponsor)
Especialísta do domínio (Domain experts)
Gerente do domínio (Domain manager)
www.alvarofpinheiro.eti.br
DSDM - Práticas
Usuário sempre envolvido
Equipe do DSDM autorizada a tomar decisões
Foco na frequente entrega de produtos
Adaptação ao negócio é o critério para entregas
“Construa o produto certo antes de você construí-lo corretamente”
Desenvolvimento iterativo e incremental
Mudanças são reversíveis utilizando pequenas iterações
Requisitos são acompanhados em alto nível
Testes integrados ao ciclo de vida
www.alvarofpinheiro.eti.br
Adaptive Software
Development
Desenvolvimento
Adaptável de
Softwarewww.alvarofpinheiro.eti.br
ASD - Características
Iterativo e incremental
Sistemas grandes e complexos
Arcabouço para evitar o caos
Cliente sempre presente
Desenvolvimento de aplicações em
conjunto (Joint Application development –
JAD)
www.alvarofpinheiro.eti.br
ASD - Fases
O ASD possui ciclos de 3 fases:
www.alvarofpinheiro.eti.br
ASD – Fases (Cont.)
Especular (Speculate)
Fixa prazos e objetivos
Define um plano baseado em componentes
Colaborar (Collaborate)
Construção concorrente de vários componentes
Aprender (Learn)
Repetitivas revisões de qualidade e foco na demostranção das
funcionalidades desenvolvidas (Learning loop)
Presença do cliente e especialistas do domínio
Os ciclos duram de 4 a 8 semanas
www.alvarofpinheiro.eti.br
ASD - Propriedades
Orientado a missões (Misson-driven) Atividades são justificadas através de uma missão, que pode mudar ao
longo do projeto
Baseado em componentes (Component-
based) Construir o sistema em pequenos pedaços
Iterativo (Iterative) Desenvolvimento em cascata (Waterfall) só funciona em ambientes bem
definidos e compreendidos. O ASD possui foco em refazer do que fazer
corretamente já na primeira vez
www.alvarofpinheiro.eti.br
ASD – Propriedades (Cont.)
Prazos pré-fixados (Time-boxed) Força os participantes do projeto a definir severamente decisões do projeto
logo cedo.
Tolerância a mudanças (Change-tolerant) As mudanças são freqüentes
É sempre melhor estar pronto a adaptá-las do que controlá-las
Constante avaliação de quais componentes podem mudar
Orientado a riscos (Risk driver) Itens de alto risco são desenvolvidos primeiro
www.alvarofpinheiro.eti.br
ASD - Cargos e Responsabilidades Este método não descreve cargos em detalhes
Executivo responsável (Executive Sponsor)
Participantes de uma sessão (workshop) do desenvolvimento de aplicações em
conjunto (JAD)
Facilitador (Facilitator)
Liderar e planejar as sessões
Escriba (Scribe)
Efetuar anotações
Cliente (Customer)
Sempre presente
Gerente de Projetos (Project Manager)
Desenvolvedores (Developers)
www.alvarofpinheiro.eti.br
Paradigma
Orientada a
Objetos
www.alvarofpinheiro.eti.br
Desenvolvimento de Software
Programas
Processos
Dados
www.alvarofpinheiro.eti.br
Enfoque a Programas
• Visão tradicional usa perspectiva de algoritmo
• O principal bloco de construção é o procedimento ou função
• Conduz o foco de atenção para questões referentes ao controle e a decomposição de algoritmos maiores em outros menores
• Modelagem de dados quebrando os objetos em tabelas, e criando mecanismos para junção posterior
www.alvarofpinheiro.eti.br
Desenvolvimento de Software
Objetos
Visualiza e representa o mundo real
como um conjunto de objetos que
interagem entre si para que determinadas
operações sejam realizadas.
Parar
Motorista Carro
www.alvarofpinheiro.eti.br
Enfoque a Objetos
• Visão contemporânea adota perspectiva OO
• Forma de construir software que difere bastante
dos enfoques tradicionais
• Programação orientada a objetos é
freqüentemente referenciada como um “novo”
paradigma de programação.
• A palavra paradigma, neste contexto, significa
um conjunto de teorias, padrões e métodos que
juntos representam uma forma de organizar o
conhecimento
www.alvarofpinheiro.eti.br
Enfoque a Objetos
• Ela é definida, no mais puro senso, como a programação implementada pelo envio de mensagens. A solução de um problema consiste em identificar os objetos, mensagens e seqüências de mensagens para efetuar a solução
• Um software desenvolvido com essa tecnologia guarda muita semelhança com os objetos do mundo real
• Cada objeto do mundo real transforma-se em um “objeto” de software
• Conduz o foco de atenção para a montagem de sistemas a partir de componentes
www.alvarofpinheiro.eti.br
Exemplo
• Você resolve jantar numa pizzaria
• Existem vários objetos na pizzaria:
– Prédio
– Mesa
– Garçom, etc....
• Cada Objeto tem características que o
descrevem
– Mesa redonda ou quadrada
– Mesa desocupada ou não
www.alvarofpinheiro.eti.br
Objetos (o domínio da aplicação)
pilha de entrada
pilha de saída
chefe
secretária
doc
doc
arquivo
docs
docs
www.alvarofpinheiro.eti.br
Representando o mundo real
• Temos a representação do mundo real
• A aplicação de Entrada e Saída de
documentos nas caixas de entrada e saída
de uma secretária
• Transformando em representação de objetos
observamos que eles executam apenas
trocas de mensagens para se comunicar
entre si
www.alvarofpinheiro.eti.br
Objetos (o modelo de objetos)
Chefe
Arquivo
Secretária
Pilha de saída
Pilha de
entrada
doc
doc
doc
doc
doc
Cópia
Anotação
Edição
Próximo
Instrução
Interrupção
Instrução
Empilhamento Registro/Status
Próximo
www.alvarofpinheiro.eti.br
Abstração
eliminação
do
irrelevante
e
amplificação
do
essencial
www.alvarofpinheiro.eti.br
Abstração
• É o mecanismo que nos permite
representar uma realidade complexa em
termos de um modelo simplificado, de
modo que detalhes irrelevantes possam
ser suprimidos.
• Processo de filtragem de detalhes sem
importância do objeto, para que apenas as
características apropriadas que o
descrevem permaneçam.
www.alvarofpinheiro.eti.br
Três abstrações de um carro
Placa, conserto,
pagamento,
etc...
Km/l,
manutenção,
etc...
Identificação,
impostos, placa,
etc...
Registros
de oficina
Registros
em casa
Registros
Detran
www.alvarofpinheiro.eti.br
Extraindo o essencial...
• Para processar algo do mundo real em computador, temos que extrair as características essenciais. Os dados que representam estas características são maneira como representam tal coisa em um sistema
• Um mesmo objeto, por exemplo um carro pode dependendo do contexto ser visualizado de formas diferentes. Os dados relevantes do carro para uma oficina, são diferentes dos dados relevantes para o Detran, por exemplo
www.alvarofpinheiro.eti.br
Objetos
saldo
deposito()
Conta corrente
www.alvarofpinheiro.eti.br
Objetos
• Um objeto é qualquer coisa, real ou abstrata, sobre a
qual armazenamos dados e operações que manipulam
tais dados
• Unidade básica de modularização do sistema na
abordagem OO
• Um objeto é um ente independente, composto por:
– atributos, isto é, características ou propriedades que definem o
objeto
– comportamento, isto é, um conjunto de ações pré-definidas
(denominada métodos), através das quais o objeto responderá
à demanda de processamento por parte de outros objetos
www.alvarofpinheiro.eti.br
Objetos
• Validação de um Objeto
– É aplicável ao contexto ?
– Existe independente de outros Objetos ?
– Possui atributos e operações ?
– Exemplos
• Cor
• Exercício: Defina um computador PC segundo os
princípios de Orientação a Objetos
www.alvarofpinheiro.eti.br
Simplificando...
• Sob o ponto de vista superficial , a expressão orientada a objetos significa que o aplicativo é organizado como uma coleção de objetos que incorporam tanto a estrutura como o comportamento dos dados
• Reflita alguns minutos como poderíamos montar este ambiente em termos de objetos!!!.
• A seguir um exemplo de um controle de
Pizzaria (imagine como seria modelar este
ambiente em OO para calcular uma conta)
www.alvarofpinheiro.eti.br
Controle de Pizzarias
• Sistema que informatiza os pedidos de pizza em um
restaurante
• Poderia ser modelado pelos objetos, Pedido, Cardápio,
Pizza, Caixa, Cliente, Garçom, Cozinheiro, etc.
• O Cardápio teria como responsabilidade, armazenar os
preços, mantendo-os atualizados
• Pedido seria responsável pelo processamento dos
pedidos feitos pelos clientes
www.alvarofpinheiro.eti.br
Controle de Pizzarias
• Caixa calcularia a conta a ser paga.
• Caso houvesse alteração no sistema para atender a
necessidade de atualização de preços, esta seria
uma responsabilidade do Cardápio. Os demais
Objetos não sofreriam qualquer espécie de
alteração
• Caso a forma de calcular a conta fosse modificada
(por exemplo a gorjeta), o Caixa seria refeito.
• Enfim cada Objeto com sua respectiva função
www.alvarofpinheiro.eti.br
Funcionário
ServiçosGarçomCozinheiro
Cardápio
Tipo
Prato
Preço
+AlteraPreço
+GetPreço
ClientePedido
Caixa
Comanda
+CalculaConta
www.alvarofpinheiro.eti.br
Classes - Fabrica de Objetos
Definição da classe
Objetoswww.alvarofpinheiro.eti.br
Classes
• Podemos fazer uma analogia dizendo que as classes são “fábricas” de objetos.
• Exemplificando, temos que Pessoa é uma classe e João é um objeto (instância) da classe Pessoa
• Um carro é uma classe; “meu carro” é um objeto
• Objetos similares são agrupados em classes
www.alvarofpinheiro.eti.br
Programas Classes
processos atributos
dados operações
Desenvolvimento de Software
Programas x Classes
www.alvarofpinheiro.eti.br
Notação para Classes
class Fruta
{
int gramas;
int cals_por_gramas;
int total_calorias ()
{ return gramas * cals_por_grama; }
}
www.alvarofpinheiro.eti.br
Mensagem
• A POO identifica uma abordagem em que o
programador visualiza seu programa em
execução em termos de objetos que se
comunicam através de trocas de mensagens
• Mensagem - composta por um seletor e por
parâmetros (opcional)
Cliente Conta
debite(50R$) debite
www.alvarofpinheiro.eti.br
Mensagem
• Objetos interagem enviando mensagens uns para
os outros.
• O objeto que receber a mensagem responderá
através da seleção e execução de um método que
fará parte de seu comportamento
• Após a execução, o controle volta para o objeto
que enviou a mensagem
• Uma mesma mensagem pode gerar ações
diferentes (alguma forma de polimorfismo)
• Em geral, classes bem projetadas escondem seus
dados de maneira que eles só possam ser
modificados por métodos daquela classe
www.alvarofpinheiro.eti.br
Classe Exemplo
class Exemplo
{
public static void Main (string args[])
{
Fruta AlgumaFruta = new Fruta();
Citros Laranja = new Citros();
AlgumaFruta.Descascar();
Laranja.Descascar();
Laranja.Espremer();
}
} www.alvarofpinheiro.eti.br
Encapsulamento
separa os
aspectos
externos de um
objeto dos
detalhes de
implementação
www.alvarofpinheiro.eti.br
Encapsulamento
• Encapsulamento separa os aspectos externos de um
objeto dos detalhes de implementação internos do
objeto
• É a propriedade dos objetos de agregarem, em seu
interior, dados e as operações que atuam sobre estes
dados.
• O encapsulamento possibilita que os objetos
escondam parte de seus componentes do mundo
exterior, de modo que o acesso às suas informações
seja controlado
• Você não precisa saber como um telefone realmente
funciona, para poder usar-lo. Só precisamos saber
para que ele serve, e conhecer sua interface, ou seja a
forma de nos comunicarmos com ele.
www.alvarofpinheiro.eti.br
Encapsulamento
• Se a companhia telefônica mudar seus
processos, você vai continuar usando o
aparelho normalmente
• A implementação de uma classe, pode ser
alterada sem afetar a sua interface. Se um novo
telefone for criado, como um telefone digital, a
implementação foi alterada, mas a interface
permanece a mesma
• Reflita associando as idéias com um
liquidificador
www.alvarofpinheiro.eti.br
Implementando o encapsulamento
• Telefone
– interface pública - que você usa para
interagir com o objeto
– implementação - as operações internas,
o propósito do objeto
• Carro
– interfaces públicas - pedais, direção,
câmbio
– implementação - o propósito do carro
www.alvarofpinheiro.eti.br
Implementando o encapsulamento
• Em sistemas puramente orientado a objetos, todos os atributos são privados e apenas podem ser acessados ou alterados através de operações na interface pública
Exercício
• Descreva as interfaces disponíveis num Sistema de Som
Baixar,Aumentar,Gravar,Adiantar,Voltar
www.alvarofpinheiro.eti.br
Interfaces Públicas
Cliente Conta
debitenc
a1
a2
b1
b2
nc é o número da conta do cliente (do tipo Conta) e enxerga os métodos
debite, mb2 e mb3.
Um objeto do tipo Cliente não precisa saber detalhes de implementação
do método debite para chamá-lo, ele só precisa saber que a operação faz
um débito na Conta e conhecer a sua assinatura.
Os detalhes de como são os métodos internamente, ou de
como eles são implementados não são visíveis através da
interface
www.alvarofpinheiro.eti.br
class Conta
{
private double saldo;
private long numero;
public void credite(double val)
{
saldo = saldo + val;
}
public void debite(double val)
{
saldo = saldo - val;
}
public void imprimaSaldo()
{
System.Out.Println(“Conta:“+numero+“Saldo:R$“ + saldo);
}
}
www.alvarofpinheiro.eti.br
Generalização
• Generalização identifica e define coisas
comuns em uma coleção de objetos
Moveis
Cadeiras Mesas Biros
Quadrada Redonda
www.alvarofpinheiro.eti.br
Generalização/Especialização
• Generalização é um processo que ajuda
a identificar as classes principais do
sistema. Ao identificar as partes comuns
dos objetos, a generalização ajuda a
reduzir as redundâncias, e promove
reutilização
• O processo inverso a generalização, e a
Especialização, que foca a criação de
classes mais individuaiswww.alvarofpinheiro.eti.br
Herança
Conta
ContaCorrente Poupança
ContaEspecial
Sobremesa
Bolo Sorvete
BoloDeChocolate
www.alvarofpinheiro.eti.br
Herança
• É o mecanismo para definir uma nova
classe em termos de uma já existente
• É o relacionamento entre classes de
objetos que permite a uma classe incluir
atributos e operações definidas por outra
classe mais genérica.
• A classe mais genérica é chamada de
superclasse e as classe mais específicas
de subclasse.
www.alvarofpinheiro.eti.br
Herança
• A forma de validar herança é usar a
frase “é um”.
• Exemplo da bicicleta e o avião, que
ambos tem rodas, assento, capacidade
de bagagem.
• Bicicleta é um avião
• Avião é uma bicicleta.
www.alvarofpinheiro.eti.br
Herança
Figura
Polígono
CírculoCor
posição central
Num de lados
vértices
raio
www.alvarofpinheiro.eti.br
class Citros extends Fruta
{
void espremer () {/*............*/}
}
Herança (Java)class Fruta
{
int gramas;
int cals_por_gramas;
int total_calorias ()
{ return gramas * cals_por_grama; }
}
Todas as cítricas são frutas
www.alvarofpinheiro.eti.br
Polimorfismo
• Significa que a mesma operação pode ter
implementações diferentes.
• Uma subclasse pode sobrepor a
implementação de uma operação que ela
herda de uma superclasse.
• Somente pode ser usado com a herança
www.alvarofpinheiro.eti.br
Polimorfismo de Sobreposição
Fruta
Descasca()
Descasca()
Cítrica Não Cítrica
www.alvarofpinheiro.eti.br
Polimorfismo
• O polimorfismo de sobreposição é resolvido dinamicamente
• Ocorre quando uma classe possui um método com o mesmo nome e assinatura(número, tipo e ordem dos parâmetros) de um método da superclasse. Quando isso acontece, dizemos que a subclasse sobrepõe (overrides) o método da superclasse
www.alvarofpinheiro.eti.br
Polimorfismo
Ícone
origem: Ponto
exibir()
Botão
exibir()
O tratamento do exibir() em
Botão irá “overridar”
o exibir() do Ícone,
Apesar de herdar o método
dele e poder reutilizá-lo, ele
implementará de outra
maneira este método
www.alvarofpinheiro.eti.br
Polimorfismo
• No exemplo do Sistema de Controle de Pizzaria
• Na pizzaria, a mensagem PRINT para Pedido
produz a conta
• Enviada para Cardápio, imprime a lista de
preços
www.alvarofpinheiro.eti.br
class Fruta
{
int gramas;
int cals_por_gramas;
int total_calorias ()
{ return gramas * cals_por_grama; }
void descascar () {System.Out.Println (descasca uma fruta); }
}
class Citros extends Fruta
{
void espremer () {/*............*/}
void descascar () {System.Out.Println (descasca uma citro); }
}
Polimorfismo (Java)
www.alvarofpinheiro.eti.br
class Exemplo
{
public static void Main (string args [ ] )
{
Fruta AlgumaFruta = new Fruta ();
Citros Laranja = new Citros ();
AlgumaFruta.Descascar ();
Laranja.Descascar ();
Laranja.Espremer ();
}
}
Polimorfismo (Java)
www.alvarofpinheiro.eti.br
Associação e Composição
• Objetos são associados quando um usa os
serviços do outro, e eles existem
independentemente
– A pessoa usa o computador
• A composição ocorre quando um objeto
esta contido no outro (tem).
– Lápis - grafite , receptáculo de madeira
www.alvarofpinheiro.eti.br
Associação – Agregação – Composição
Notação: ------- <>------ <>---------
Empresa (todo) <> --------------- Depto. (parte)
Associação – Agregação – Composição
www.alvarofpinheiro.eti.br
Custodia de um objeto
• Propriedade de um objeto e a
responsabilidade posterior de destruí-lo
• Exemplo:
• biblioteca e livros (custodia da biblioteca)
– se a biblioteca for destruída, os livros serão
destruídos, a menos dos livros emprestados que
a custodia esta com os usuários
www.alvarofpinheiro.eti.br
Interfaces - Definições
• Uma interface é um esqueleto de uma
classe (a forma que a classe deve ter),
mostrando os métodos que a classe terá
quando alguém a implementar.
• É uma coleção de operações usadas para
especificar um serviço de uma classe ou
componente.
www.alvarofpinheiro.eti.br
Interfaces
– Características
– Interfaces formalizam o polimorfismo
– Aumentam o nível de reusabilidade
– Viabilizam o uso de componentes
– Reduzem o esforço de evolução da aplicação
www.alvarofpinheiro.eti.br
Interfaces
– Características
– Definem um tipo especificando apenas a assinatura de seus métodos
– Não podem ser instanciadas
– Não possuem atributos e seus métodos não tem corpo
– Classes implementam interfaces, ou seja, provêem implementação para os métodos especificados em uma interface
www.alvarofpinheiro.eti.br
Interfaces
– Utilidades e capacidades
– Garantir independência entre componentes de software
– Garantir substituição de um serviço sem necessidade de alterar quem está usando este serviço
– Usada para generalizar conceitos
– Em JAVA, interface tem uma conotação muito forte e poderosa e “emula”, de forma bastante eficiente, herança múltipla
www.alvarofpinheiro.eti.br
Herança Múltipla
Máquina Voadora Máquina Flutuadora
Hidroavião
www.alvarofpinheiro.eti.br
interface MaquinaVoadora
{
int Navegar (ponto de, ponto para);
void Pousar ();
void Decolar (double combustivel);
}
class Helicoptero implements MaquinaVoadora
{
double Tanque_Combust;
int Rotac_motor;
int Rotores;
int Navegar (ponto de, ponto para) { */ o codigo aqui */ }
void Decolar (double combustivel)
{
Tanque_Combust + = combustivel;
for (; Rotac_motor < 6000; Rotac_motor ++);
}
void Pousar () {/*..................*/}
}
www.alvarofpinheiro.eti.br
MaquinaFlutuadora
Navio
interface
implementação
Veleiro etc.....Lancha
Windsurf
www.alvarofpinheiro.eti.br
interface MaquinaFlutuadora
{
int Navegar (ponto de, ponto para);
void LancarAncora ();
void LevantarAncora (double combustivel);
}
class Navio implements MaquinaFlutuadora
class Veleiro implements MaquinaFlutuadora
class Veleiro extends Naviowww.alvarofpinheiro.eti.br
class HidroAviao implements Navio, MaquinaVoadora
{
double Tanque_Combust;
int Rotac_motor;
int Cabo_ancora;
void LancarAncora () { Cabo_ancora = 200; }
void LevantarAncora () { Cabo_ancora = 0; }
int Navegar (ponto de, ponto para) {/*................*/};
void Pousar ()
{
for ( ; Rotac_motor > 0; Rotac_motor --);
LancarAncora ();
}
void Decolar (double combustivel)
{
LevantarAncora ();
Tanque_Combust + = combustivel;
for ( ; Rotac_motor < 6000; Rotac_motor ++);
}
} www.alvarofpinheiro.eti.br
NegócioAcesso
DadosGUI Interface Interface
BDCLIENTE
www.alvarofpinheiro.eti.br
Interfaces
– Estudo de Caso
– Arquitetura do software para Java
Interface
Gráfica
Camada de
Aplicação
Camada de
Acesso a Dados
Comandos SQL
insertdeleteupdate
InterfaceImplementação
BD
www.alvarofpinheiro.eti.br
Interface
Gráfica
Camada de
Aplicação
Camada de
Acesso a Dados
Chamada stored procedure
insertdeleteupdate
Interface
mantida
Implementação muda
BD
Interfaces
– Estudo de Caso
– Arquitetura do software para Java
www.alvarofpinheiro.eti.br
Abordagem Orientada a Objetos
INT
ER
FA
CE
Dados
+
Operações
INT
ER
FA
CE Dados
+
Operações
solicita serviço
responde a
solicitação
www.alvarofpinheiro.eti.br
• Analogia com o LEGO (montar os componentes)– Javabeans, EJB, ActiveX
• Em Java temos poucos tipos primitivos
(int, long, short, double, float, char, boolean)
Tudo são classes.
Exceções: Linhas de codigo, Guis, Strings, etc...
• Pacotes de bibliotecas de classes da plataforma Java– java.lang - nucleo da linguagem
– java.awt - interface gráfica
– java.net - operações na rede
– java.io - lidar com arquivos
– java.util - utilitários
Abordagem Orientada a Objetos
www.alvarofpinheiro.eti.br
Unified
Modeling
Language
(UML)www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Esquema da evoluçãoda
análise de sistemas
Métodos orientados a processos
simples e notação simples
Métodos orientados a dados
simples e notação simples
Métodos orientados a objetos
Simples e notação complexa
1994
Processos de desenvolvimento
Complexo (RUP)
Notação complexa
(UML)
www.alvarofpinheiro.eti.br
Evolução
da
Análise Orientada a Objetos
• No princípio encontramos recomendações de desenho
(Booch, 1986)
• Se impõe o modelo orientado as características dos objetos
(Shlaer & Mellor, 1988)
• Surgem muitos métodos, mas de autores provenientes das bases de
dados relacionais
(Coad & Yourdon, Martin & Odell, Rumbaugh, Embley, etc., 1990)
• Se impõe os métodos orientados ao comportamento dos objetos
(Wirfs-Brock, Jacobson, Rubin & Goldberg, 1994)
• Começa a iniciar-se a UML (1994) www.alvarofpinheiro.eti.br
Características
UML
1980 1985 1990 1995 2000
Comportamentos
Evolução
da
Análise Orientada a Objetos
www.alvarofpinheiro.eti.br
O caminho até a unificação
• Grady Booch manifiesta a necessidade de unificar critérios
• Em 1995 Ivar Jacobson completa o trio de “amigos”
• Ambos elaboram a versão 0.8 do Unified Method
• James Rumbaugh se une a Booch em outubro de 1994
www.alvarofpinheiro.eti.br
O caminho até o padrão
• Se elabora a versão 0.9 do Unified Modeling Language
• Durante 1996 se realizam sucessivas modificações na base e
um acréscimo de novos participantes (versões 0.91 e 1.0)
• Se realiza a versão 1.1 em conjunto com outras importantes
empresas, que é apresentada a OMG (Object Management
Group)
• A OMG adota a UML versão 1.1 como standard no final de
1997
• Atualmente se encontra vigente a versão 1.4 e se está gerando
as bases da versão 2.0, que se espera seja mais estável
www.alvarofpinheiro.eti.br
UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther methods
UML 0.9Web - June ´96
public
feedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1
OMG Acceptance, Nov 1997
UML 1.3
UML 1.0UML partners
UML 1.4
www.alvarofpinheiro.eti.br
UML
• Linguagem para visualizar,
especificar, construir e documentar
software
• Padrão aberto
• Suporta o ciclo completo do
desenvolvimento de sofware
• Suportada por várias ferramentas
www.alvarofpinheiro.eti.br
Objetivos da UML
• Estabelecer uma linguagem visual de modelo,
expressivo e sensível em seu uso
• Manter uma independência dos processos de
modelagem das linguagens de programação
• Estabelecer bases formais
• Integrar as melhores práticas
• Impor um padrão mundial
www.alvarofpinheiro.eti.br
Modelos, Visões e DiagramasA model is a complete
description of a system
from a particular
perspective Use CaseDiagramsUse Case
DiagramsUse CaseDiagrams
ScenarioDiagramsScenario
DiagramsCollaborationDiagrams
StateDiagramsState
DiagramsComponentDiagrams
ComponentDiagramsComponent
DiagramsDeploymentDiagrams
ScenarioDiagramsScenario
DiagramsStatechartDiagrams
Use CaseDiagramsUse Case
DiagramsSequenceDiagrams
StateDiagramsState
DiagramsClassDiagrams
Models
www.alvarofpinheiro.eti.br
Desenvolvimento centrado em Modelos
Desenvolver Software é transformar modelos
Processo 1
Processo 2
Processo n
Modelo 2
Modelo 1
Processo de Desenvolvimento de SWNecessidade
dos Usuários
SW Novo/
Modificado
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Uso de Modelos
• Representações simplificadas de coisas reais
• Usados há muitos anos em outros ramos da
Engenharia,mais maduras que a nossa
• Se constroem para melhorar o entendimento
• Exemplos:
Maquetes, Planos, Equações, Protótipos,
Simulação por Computador,
Gráficos informaiswww.alvarofpinheiro.eti.br
Modelar não é um fim• É um meio para construir melhor
• Se é mais barato construir e corrigir os erros sobre o
produto, Modelar não tem sentido
• É muito melhor ver o produto do software do que o
modelo, porém terminar o SW e ver que ele não atende
as Necessidades é muito mais caro
• A Correção é muito mais eficiente nas etapas iniciais do
Processo, e os modelos servirão de base para antecipá-los
• É conveniente conhecer vários tipos de Modelos. Distintos
problemas ou partes deles, requerem distintas técnicas de
modelagemwww.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Estrutural: modela aspectos estáticos do software focando nas entidades participantes e seus relacionamentos. Os diagramas deste conjunto são: diagrama de classes, objetos, componentes e implementação.
Comportamental: modela aspectos dinâmicos do software focando, na maioria das vezes, como as entidades interagem para prover uma determinada funcionalidade para o usuário. Os diagramas deste conjunto são: diagrama de casos de uso, seqüência, colaboração, estados e atividades.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Arquitetura dos Modelos
Visão de
implementação
Visão de
Distribuição
Visão de
processos
Visão de
desenho
Visão de
casos de usoEstrutura
(UC,Classes,Relações)
Estrutura
Componentes
Física (Topologia,
Implantação,comunicação)
Escalabilidade
(threads)
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Ferramentas da UML
– O porquê das ferramentas da UML
– Administração de requisitos com casos de uso
– Modelos de interação
– Modelos de comportamento
– Modelos de desenhos
www.alvarofpinheiro.eti.br
• Modelo de requisito
• Modelo de estrutura
• Modelo de interação
• Modelo de comportamento
• Ferramentas de desenho
• Organização de modelo
• Diagrama de casos de uso
• Diagrama de clases
• Diagrama de objetos
• Diagrama de sequências
• Diagrama de colaboracionais
• Diagrama de estados
• Diagrama de atividades
• Diagrama de componentes
• Diagrama de distribuição
• Diagrama de pacotes
Ferramentas da UML
www.alvarofpinheiro.eti.br
O Porquê destas ferramentas
ClasseClasse
Levantamento
Modelo de
casos de uso
Modelo de classes
Modelo de comportamentoModelo de interação
www.alvarofpinheiro.eti.br
Modelo de Requisitos
• Nos primeiros estágios da programação praticamente
se construía a aplicação dos requisitos em linguagem
natural
• Com o advento dos métodos de análise, se supunha
que os requisitos estavam completamente definidos
antes da modelagem
• Com os métodos orientados a objetos começam a
aparecer técnicas de modelagem de requerimentos,
baseados na criação de “cenários”
www.alvarofpinheiro.eti.br
Construção dos Diagramas
• Passos recomendados:
• elaborar uma lista de atores e definir suas funções
• eleger o ator mais representativo do sistema para começar o diagrama
• esgotar todas necessidades funcionais do ator incorporando casos de uso da
funcionalidade base
• para cada caso de uso, buscar os atores que devam colaborar com ele
• repetir os dois passos anteriores para cada ator
• incorporar a funcionalidade necessária para exceções e erros
• fatorizar os casos de uso
• obter os atores abstratos mediante generalização
• descrever cada caso de uso a medida que se inclue no modelo
• validar e verificar o modelo junto com os usuarioswww.alvarofpinheiro.eti.br
Estratégia de Levantamento
Erros
Exceções
Caminho
Base
Funcionalidade
desejada
Funcionalidade
não desejada
www.alvarofpinheiro.eti.br
Casos de Uso
• Introduzido formalmente por Ivar Jacobson
• Aceitado pela comunidade usuária de OO e por muitos
metodologistas
• É empregado na etapa de levantamento para captar os
requerimentos dos usuários
• De fácil compreensão por parte dos usuários dos
sistemas
• Ferramenta que precisa de outros complementos para
ser utilizado em processos de modelagem OO
www.alvarofpinheiro.eti.br
Casos de Uso
• São empregados para capturar o comportamento
que se espera do sistema, sem ter de especificar
como este comportamento é implementado (caixa
preta);
• Possibilitam que desenvolvedores obtenham uma
compreensão comum do sistema , junto aos
usuários e especialistas do domínio
www.alvarofpinheiro.eti.br
Ainda sobre Casos de Uso
• Cada caso de uso descreve uma forma possível
de utilização do sistema por representar uma
porção de sua funcionalidade;
• Um caso de uso é uma descrição de um conjunto
de seqüência de ações, incluindo variações que
um sistema executa a partir das interações
externas ao sistema
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Casos de Uso
Usuário
Emprestar
título
Devolver título
Reservar título
Ator
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Cadastrar anamneseAtendente de
1º nível
Consultar base de
conhecimento
Cadastrar satisfação do
solicitante
Abrir o.s.
Fechar o.s.
<<extend>>
Realizar atendimento de 1º
nível
<<extend>>
<<uses>>
Atendente de
1º nível
Diagrama de Casos de Uso
www.alvarofpinheiro.eti.br
USE CASE: ABRIR O.S.
Fluxo de dados principal:
O use case inicia quando o solicitante telefona para o ramal do Call Center para aresolução de um problema. O atendente de 1o nível informa a matrícula dosolicitante. O sistema verifica se o solicitante está cadastrado. Se o mesmo estivercadastrado, o atendente informa o equipamento e então o sistema verifica se omesmo está em manutenção. Se o equipamento não estiver em manutenção, osistema verifica se o equipamento está em garantia. Se não estiver em garantia, osistema busca os softwares associados àquele equipamento e o atendente verificaa necessidade de execução do processo de anamnese. O sistema sugere aprioridade do atendimento a partir do nível do solicitante e o atendente de 1o nívelconfirma a prioridade do atendimento. Em seguida, informa a ocorrência doproblema. O atendente de 1o nível usa (consultar base de conhecimento). Aseguir, o atendente de 1o nível registra data, hora, tipo e dados obrigatórios daO.S.
Fluxo de dados excepcional:
1. Se o solicitante não estiver cadastrado, o sistema não permite que oatendimento seja realizado.
2. Se após a abertura da O.S., o atendente de 1o nível encontrou a solução doproblema, estende (fechar O.S).
3. Se o equipamento estiver em manutenção, o sistema não permite que oatendimento seja realizado.
4. Caso o equipamento esteja em garantia e o tipo da O.S. não for de software, oatendente de 1o nível registra data, hora, tipo, dados obrigatórios da O.S enúmero do contrato, encaminhando-a para o coordenador de 2o nível.
www.alvarofpinheiro.eti.br
Diagrama de Classes
Curso Disciplina
Aluno
Professor
1
1..*
0..6
0..*
0..*
1
1..*1..*
matricula-se
ensina
pertence a
Aspectos estáticos
www.alvarofpinheiro.eti.br
• Diagrama utilizado para representar os aspectos
estáticos do Sistema
• Exibe um conjunto de classes e seus
relacionamentos
Diagrama de Classes
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Diagrama de Seqüência
: Atendente de 1º
nível
: Form
AbrirOS
: Solicitante
Abrir( )
Informar Matrícula Usuário( )
Finalizar
Validar Usuário( )
Usuário Não Cadastrado
Aspectos
Dinâmicos
www.alvarofpinheiro.eti.br
• Usados para modelar os aspectos dinâmicos
do Sistema
• É um diagrama de interação que enfatiza a
ordenação de mensagens com relação ao tempo
Diagrama de Seqüência
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Aplicação Específica
Aplicação Geral
MiddleWare
System Software
Gerencial Atendimento
Contratos Equipamento
Manutenção
Preventiva
Hardware
MTS
Software
Windows NT
OS Ambiente de
Conhecimento
Func_Help_Desk DefeitoSoftware
Oracle
Relacionamento
entre os
Componentes
Diagrama de Componentes
www.alvarofpinheiro.eti.br
Componentes
• Os componentes são um importante bloco de
construção na modelagem dos aspectos físicos do
sistema;
• Um componente é uma parte física e substituível
do sistema que realiza uma interface ou usa os
serviços da mesma;
• Um componente tipicamente representa o
empacotamento físico dos elementos lógicos como
classes, interfaces e colaborações
www.alvarofpinheiro.eti.br
Componentes
Uma interface é uma coleção de operações que são
usadas para especificar um serviço de uma classe
ou um componente;
O Diagrama de Componentes exibe as organizações
e dependências entre componentes, com o
propósito de modelar a visão de implementação dos
módulos de software executáveis de um sistema;
www.alvarofpinheiro.eti.br
Diagrama de Componentes
• Um nodo (nó) é um elemento físico que existe em tempo de
execução e representa um recurso computacional, geralmente
tendo pelo menos alguma memória e, freqüentemente,
capacidade de processamento
Nodos e Componentes
• Componente são as “coisas” que participam na execução de
um sistema; os nodos são as “coisas” que executam os
componentes;
• Os componentes representam o empacotamento físico dos
elementos lógicos; os nodos representam a distribuição física
dos componentes.
www.alvarofpinheiro.eti.br
Diagrama de Distribuição
SERVIDOR DE DADOS SERVIDOR DE OBJETOS
Contrato.DLL
OS.DLL
Manutenção
Preventiva.DLL
Defeito.DLL
Software.DLL
Gerencial.DLL
Equipamento.DLL
Ambiente de
Conhecimento
.DLL
Func_Help_
Desk.DLL
Hardware.DLL
Atendimento.DLL
WINDOWS NT
ORACLE
Micros Atendimento
1º Nível
HD.EXE
Micros Coordenação
HD.EXE
Micros Atendimento
2º Nível
HD.EXE
Micros Gerência
HD.EXE
REDE
Associação
dos componentes
ao Hardware
www.alvarofpinheiro.eti.br
Arquitetura
www.alvarofpinheiro.eti.br
Base
Reboco
Estrutura
Instalações
Acabamento
Ambientação
www.alvarofpinheiro.eti.br
Definição de Arquitetura
•A Arquitetura é uma série de abstrações que
permitem lidar com a complexidade das
soluções
• A Arquitetura forma a espinha dorsal para se
construir sistemas de software com sucesso
www.alvarofpinheiro.eti.br
O que é Arquitetura de Software?
• É a visão do software a nível de funções
(subsistemas) e as interconexões entre
estas funções
• A arquitetura do software reflete como este
software irá funcionar
• Aspectos cruciais de um software são
determinados na definição da arquitetura do
mesmo
• A definição da arquitetura está baseada nos
requisitos funcionais e não-funcionais do
software em questão
www.alvarofpinheiro.eti.br
O que é Arquitetura de SW?
“Uma arquitetura é composta de:
• Uma coleção de componentes,conexões e restrições
• Uma coleção de declarações de stakeholders sobre suas necessidades
• As razões que justifiquem que os componentes,suas conexões e restrições satisfaçam as necessidades dos stakeholders”
Barry Boehm
www.alvarofpinheiro.eti.br
Relaciona-se com.....
A organização de sistemas em termos de componentes
Estruturas globais de controle
Protocolos de Comunicação
Sincronização e acesso a dados
Alocação de funcionalidades aos elementos de projeto
Composição dos elementos de Projeto
Distribuição Física
Escalabilidade e Desempenho
Evolução do Sistema
Seleção entre alternativas sobre decisões de projetos
www.alvarofpinheiro.eti.br
Definição de Arquitetura
A atividade em Contexto:
Requisitos de
Qualidade Arquitetura de HW
Modificações
Arquitetura de SW
Modificações
Restrições
Análise de Domínio
Análise de Requisitos
Análise de Riscos
Desenho de
Arquitetura de
Software
Desenho
de Arquitetura
de Hardware
Desenho Detalhado,
Codificação,
Integração e Testes
www.alvarofpinheiro.eti.br
Estilo de Arquitetura
Um estilo define uma família de sistemas em termos
de seus padrões de organização estrutural
Descrição do Estilo
• Componentes: unidades de software
• Conectores: comunicação entre componentes
• Estruturas de Controle e Comunicação de Dados
• Interação entre Dados e Controle, Regras e Restrições
www.alvarofpinheiro.eti.br
Exemplos de Estilo - Arquitetura
Sistemas em Camadas
Baseado em Eventos
Repositório Compartilhado
Interpretadores
Processamento Distribuído
Programa Principal/Subrotinas
Orientados a um domínio específico
Pipe & Filter
www.alvarofpinheiro.eti.br
Arquitetura de Software
• Modelos de Arquitetura
• O projeto de arquitetura pode ser
expresso através de diagramas de bloco
apresentando uma visão geral da
estrutura do sistema
• Modelos mais específicos mostram
• Compartilhamento de dados
• Distribuição
• Interfaces entre os sistemas
• Relacionamentos entre subsistemas
www.alvarofpinheiro.eti.br
Modelos de Arquitetura
• Estrutura, controle e decomposição
modular podem ser baseados num
modelo ou estilo de arquitetura particular
• Como a maioria dos sistemas são
heterogêneos, filosofias de vários
modelos são utilizadas em um projeto
real de arquitetura
www.alvarofpinheiro.eti.br
Modelos de Arquitetura
• O modelo de arquitetura usado afeta
– Desempenho
– Robustez
– Distributividade
– Manutenibilidade
• Alguns domínios de aplicação possuem modelos específicos
–Compiladores
–Sistemas de acesso a redes locais
www.alvarofpinheiro.eti.br
As 4 Visões
Arquitetura de Software
Visão Conceitual
Visão de Módulo
Visão de Código
Visão de
Execução
Componentes
Conectores
Configuração
Nova partição de módulos
Módulos
Subsistemas
Camadas
Construção de Código
Arquitetura de
Hardware
Restrições de Módulos
Componentes
Conectores
Configuração
Restrições
de Execução
Nova partição
de módulos
Módulos
Entidades de
tempo de
execução
Mudanças nas entidades
www.alvarofpinheiro.eti.br
4 Visões
Visão Conceitual
• A funcionalidade do sistema se mapeia através de
componentes conceituais, e a coordenação
(fluxo lógico de controle) e a comunicação se resolve
com conectores
• É uma visão mais abstrata do domínio da aplicação
• Integração de Pacotes
www.alvarofpinheiro.eti.br
Arquitetura:Visão Conceitual -Perguntas
• Os requisitos funcionais estão sendo atendidos?
• Como se integram os COTS (pacotes)?
• Como se incorporam SW/HW específico do
domínio?
• Como ela suportará a linha de produtos?.
• Como minimizar as mudanças de requisitos ou
domínio?
www.alvarofpinheiro.eti.br
4 Visões
Visão de Módulos
• Aplicar abstração,encapsulamento e interfaces
• Decomposição do sistema em módulos e divisão
em camadas
www.alvarofpinheiro.eti.br
Arquitetura:Visão de Módulos - Perguntas
• Como se mapeia o produto na plataforma de SW?
• Que serviços suporta/usa o sistema e exatamente onde?
• Como se pode testar?
• Como minimizar dependências e maximizar reuso de
módulos?
• Como podemos isolar as mudanças nos COTS
(commercial of the shelf), na plataforma de SW/HW?
www.alvarofpinheiro.eti.br
4 Visões
Visão de Execução
• Distribuição de funcionalidades em entidades de tempo
de execução
• Resolução, Coordenação e Comunicação
• Assinalar os Hardwares
www.alvarofpinheiro.eti.br
Arquitetura:Visão de Execução -
Perguntas
• Como se mapeia o produto em elementos de tempo
de execução?
• Como cumprimos os requisitos de performance,
recuperação e reconfiguração?
• Como se consegue concorrência, distribuição e
replicação sem fazer complexos algoritmos de
controle?
• Como se minimiza o impacto de mudanças na
plataforma de execução?
www.alvarofpinheiro.eti.br
4 Visões
Visão de Código
• O código está dividido em muitos arquivos de distintos
tipos(bibliotecas, executáveis,etc.)
• Organizado em estruturas de armazenamento
• Depende da linguagem de programação
• Em versão e com implementações complexas
www.alvarofpinheiro.eti.br
Arquitetura:Visão de Código -Perguntas
• Como se mapeiam as entidades de execução em
componentes de distribuição, como os módulos são
mapeados em código origem?
• Como se constroem os componentes de distribuição?
• Como se pode administrar versões?
• Como reduzir tempo e esforço na construção do
produto e suas melhoras?.
• Que ferramentas de desenvolvimenro seriam úteis e
como se suportam a integração e os testes?
www.alvarofpinheiro.eti.br
Diferentes visões de uma Arquitetura
• Cada Projeto vai possuir uma visão dominante
Por exemplo, frequentemente a visão de módulos
é dominante
As demais visões são moldadas ou adaptadas
para se enquadrarem na visão dominante
www.alvarofpinheiro.eti.br
Propriedades
• Arquiteturas definem componentes, porém omitem
seus detalhes privados( informações não arquiteturais)
• Explicita informações de como um componente
(USA, É USADO, SE RELACIONA COM, INTERAGE COM
OUTRO COMPONENTE)
• Comporta várias visões mais nenhuma visão
isoladamente pode ser considerada uma arquitetura
• Todo sistema tem Arquitetura
• O comportamento dos componentes é parte da
Arquitetura
www.alvarofpinheiro.eti.br
PropriedadesRelembrando
O papel dos componentes, relacionamentos e até
mesmo o contexto mudam em cada visão
Exemplos:
Componentes podem ser : Módulos,Processos,etc.
Relacionamentos : É-Sub-Módulo,
Sincroniza-com,etc.
Contexto: Em tempo de desenvolvimento,
Em tempo de execução,etc.
www.alvarofpinheiro.eti.br
Importância do projeto de
arquitetura
– Um mau projeto de arquitetura não pode ser salvo por uma boa implementação
– Existem modelos e estilos diferentes de arquitetura
– Normalmente, vários modelos são utilizados em um mesmo projeto de software
www.alvarofpinheiro.eti.br
Importância da Arquitetura
• A arquitetura abstrai informações detalhadas do sistema mas consegue prover informação suficiente para:
– Análise do sistema como um todo
– Tomada de Decisões (técnicas ou gerenciais)
– Redução de Riscos
• Se o projeto ainda não definiu a Arquitetura do Sistema, incluindo sua justificativa, ele não deve prosseguir com o desenvolvimento em larga escala
www.alvarofpinheiro.eti.br
A Arquitetura auxilia a...
• Comunicação com os stakeholders
– Abstração de Alto nível comum a todos
– Cria um entendimento mútuo e consensual
• Decisões iniciais de projeto
– São críticas ( infra-estrutura, espinha dorsal do sistema) e com impacto em todo ciclo de vida
• Reusabilidade de Abstrações
– A arquitetura é um artefato relativamente pequeno, fácil de entender e que pode ser reusado em outros projetos
www.alvarofpinheiro.eti.br
Recomendações(Arquitetura)
• Trabalhar com grupo pequeno de liderados(+experientes)
• Partir dos requisitos e da lista priorizada dos atributos
de qualidade
•Deixar tudo sempre documentado
•Descrever como os requisitos são cumpridos
•Revisada por usuários e analisada formalmente
•Criar incrementalmente o sistema ao redor dela
•Seguir princípios de desenho
www.alvarofpinheiro.eti.br
Arquitetura do Comércio Eletrônico
HTML Browser
Camada Apresentação
(Cliente)
Internet Explorer
Netscape
HotJava
HTTP
(web)
Windows
2000
Server
Servidor Internet
JSERV
Midware p/ interação
com Servelets
SERVLET Camada
Aplicação
Acesso
DadosSGDB
Oracle
Servlet Interface Java
Request e Response
do Browser
Formata HTML de
Resposta
SGBD
Inteligência
da
Aplicação
Infra-Estrutura
www.alvarofpinheiro.eti.br
Arquitetura de Software
• Passos do projeto de arquitetura
• Estruturação do sistema
• Modelagem de controle
• Decomposição modular
www.alvarofpinheiro.eti.br
Tipos de Modelos
– Modelos Estruturais
• Modelo de Repositório -Case
• Modelo Cliente-Servidor
• Modelo de Camada - Modelo OSI
– Modelos de Controle
• Controle Centralizado
– Modelo de Retorno de Chamada
– Modelo de Gerente
• Controle Baseado em Eventos
– Modelo Broadcasting
– Modelo Baseado em Interrupções
www.alvarofpinheiro.eti.br
Estruturação do Sistema
• O sistema é decomposto em vários
subsistemas principais e as comunicações
entre eles são identificadas
• Nesta etapa, os subsistemas são
determinados através de critérios gerais e
comuns a todos os softwares existentes
Exemplos:
• Acesso a banco de dados
• Regra de negócios e processamento
• Interface gráfica
• Comunicação
www.alvarofpinheiro.eti.br
Estruturação do sistema
– Nesta fase, uma visão MACRO das
partes componentes do sistema e
suas respectivas interconexões são
obtidas
– Os requisitos do sistema têm que
estar estabelecidos para que critérios
de definição de arquitetura sejam
aplicados
www.alvarofpinheiro.eti.br
Arquitetura de Software
• Modelagem de controle
• Um modelo do relacionamento de controle
entre as diferentes partes do sistema é
estabelecido
• Controle Centralizado
• Modelo de Retorno de Chamada
• Modelo de Gerente
• Controle baseado em Eventos
• Modelo Broadcasting
• Modelo de Interrupções
www.alvarofpinheiro.eti.br
Arquitetura de Software• Decomposição modular
• Os subsistemas identificados são
decompostos em módulos
• Nesta fase, ocorre o detalhamento da
visão macro estabelecida na fase de
estruturação do sistema
• Exemplos:
• Subsistema Caixa
• Modulo de Recebimento
• Modulo de Abertura/Fechamento
www.alvarofpinheiro.eti.br
Arquitetura de Software• Decomposição modular
• Subsistema
• Um subsistema é também um sistema,
cuja operação é independente dos
serviços providos por outros
subsistemas
• Módulo
• Um módulo é um componente do
sistema que provê serviços a outros
componentes mas que normalmente
não seria considerado um sistema
separadowww.alvarofpinheiro.eti.br
Decomposição modular
• Diferença entre subsistemas e
módulos• Não há uma definição clara
• Nomenclatura normalmente usada
indistintamente por projetistas e
analistas
• Engenharia de software moderna usa
estes termos para designar elementos
diferentes em um projeto de softwarewww.alvarofpinheiro.eti.br
Arquitetura de Software
Processamento de
Pedidos
• Exemplo de Arquitetura
Acesso a Dados
Cadastramento de
Informações
Comunicação
Interface
Gráfica
www.alvarofpinheiro.eti.br
Arquitetura de Software• Modelo Cliente-Servidor
• Modelo de arquitetura que mostra como dados e processamento são distribuídos entre processadores
• Componentes:
• Conjunto de servidores separados que realizam serviços específicos
• Conjunto de clientes que usam estes serviços
• Rede que permite que clientes acessem os servidores
• Modelo largamente aplicado em sistemas modernos
www.alvarofpinheiro.eti.br
Arquitetura de Software
• Modelo Cliente-Servidor
Rede (LAN, WAN ou Internet)
Cliente NCliente 2Cliente 1
Servidor 1 Servidor 2 Servidor N
www.alvarofpinheiro.eti.br
Arquitetura de Software
– Exemplo: Sistema de Vendas de Livros
–Sistema cliente-servidor 3 camadas
–Manutenção de livros e autores
–Processamento de pedidos de livros
–Exportação de pedidos (automática)
– Importação de cadastro de clientes (automática)
www.alvarofpinheiro.eti.br
Arquitetura de Software
– Exemplo: Sistema de Vendas de Livros
–Visão client-server da arquitetura (visão mais física dos componentes de software)
Rede Local TCP/IP
Servidor de
Dados
Servidor de
Aplicação
GUI
www.alvarofpinheiro.eti.br
Componentes de Apresentação
Windows
TerminalBrowser NetPC Windows Other
Componentes de lógica de Aplicação
DADOS: SQL, Mail, ISAM, Host, não-Estruturado
O Modelo Multi-Camadas
www.alvarofpinheiro.eti.br
Passos para construção
• Construção de um programa segundo o paradigma de orientação a objetos
• Definir classes para modelar conceitos da aplicação
• Estruturar estas classes em uma hierarquiade generalização/especialização
• Disparar mensagens para uma classe (que é o papel de um programa principal), e iniciar a execução de um programa
www.alvarofpinheiro.eti.br
Arquitetura de Software– Exemplo: Sistema de Vendas de Livros
– Questões
– Até onde detalhar os módulos do software a nível de projeto de arquitetura ?
– Normalmente, um módulo é detalhado de forma a mostrar o ciclo de funcionamentodo mesmo
– Este detalhamento deve levar em consideração a filosofia de arquiteturaadotada (em camadas, client-server por exemplo)
– Devem ser observadas situações de reusowww.alvarofpinheiro.eti.br
Arquitetura de Software– Exemplo: sistema de vendas de livros
– Detalhamento Módulo de Cadastros + 1camada
Acesso a Dados Autores
GUI
Cad Livros
Cadastro
Livros
Cliente Comm
Cadastros
Servidor Comm
Cadastros
Acesso a Dados Livros
Cadastro
Autores
GUI
Cad Autores
www.alvarofpinheiro.eti.br
Arquitetura de Software
– Exemplo: Sistema de Vendas de Livros
–Questões
–É necessário mostrar apenas os componentes a serem desenvolvidos ou todos os elementos da solução (SGBD, servidores de internet, proxies, etc.) ?
–É possível mostrar componentes de software que não serão desenvolvidos mas que fazem parte da solução
–Esta visão dá ênfase à estruturação física do sistema
www.alvarofpinheiro.eti.br
Arquitetura de Software
– Exemplo: Sistema de Vendas de Livros
– Detalhamento do módulo de importação de clientes
Processador Arquivos Clientes
Servidor Comm Entrada Clientes
Acesso a Dados
Clientes
Servidor TCP JAVA
Driver
JDBCSGBD
www.alvarofpinheiro.eti.br
Arquitetura de Software– Exemplo: Sistema de Vendas de Livros
– Identificação das principais interfaces para o módulo de processamento de pedidos
Acesso a Dados Pedidos
GUI
Proc Pedido
Manutenção
Pedidos
Cliente Comm
Proc Pedido
Servidor Comm
Proc Pedido
Acesso a Dados Livros
www.alvarofpinheiro.eti.br
Cliente-Servidor: Arquiteturas
• Arquitetura em Duas Camadas
(Two Tier Architecture)
- Processamento é realizado no cliente e/ou no servidor;
• Arquitetura em Três Camadas
(Three Tier Architecture)
– Utilização de um middleware entre ocliente e o servidor;
www.alvarofpinheiro.eti.br
Duas Camadas
Servidor Cliente
www.alvarofpinheiro.eti.br
• Os dados são armazenados em servidores com
administração centralizada, e os clientes se conectam
diretamente a esses servidores por quase todo o ciclo de
vida do aplicativo.
• Cada aplicativo cliente contem sua própria lógica de
processamento. Qualquer modificação, tem de distribuir
uma nova versão do aplicativo. Isto pode ser melhorado
usando Stored Procedures armazenadas no Banco,
movendo parte da lógica para o lado servidor.
• - Três componentes distribuídos em duas camadas:
– Interface com o usuário : Cliente
– Gerenciador de processos: Cliente/Servidor
– Gerenciador de banco de dados: Servidor
Arquitetura em duas camadas
www.alvarofpinheiro.eti.br
3 Camadas
ServidorServidor
de
Aplicação
Cliente
www.alvarofpinheiro.eti.br
• A escalabilidade e reutilização podem ser
incrivelmente melhoradas com a introdução do
modelo em 3 camadas, separando apresentação,
regras de negocio e acesso a dados em camadas
• A camada responsável pela apresentação mostra os
dados para o usuário, e utiliza os serviços da camada
de negocio, que não esta ligada a nenhum cliente
especifico
• A camada de negocio, com seus serviços
disponíveis, atende a toda e qualquer requisição que
deles venham a necessitar.
Arquitetura em 3 camadas
www.alvarofpinheiro.eti.br
• Os serviços da camada de negocio podem ser
rapidamente atualizados, se necessário.
• A camada de negocio não deve ter qualquer
conhecimento acerca de como ou onde estão os
dados sobre os quais ela atua
• Em vez disso, ela se baseia no serviço de acesso a
dados, responsável por recupera-los e armazena-los.
• Se os dados armazenados se movem ou mesmo
mudam de formato, somente o serviço de acesso aos
dados precisa ser mudado.
Arquitetura em 3 camadas
www.alvarofpinheiro.eti.br
Arquitetura
(GUI)
Negócios
Acesso a Dados
BD
Cliente
www.alvarofpinheiro.eti.br
Arquitetura 3 camadas
• Introdução de um middleware (Middle tier server)
entre a Interface com o usuário (cliente) e o
componente de gerenciamento de dados
(servidor);
– A middle tier é utilizada para executar
operações comuns (enfileiramento de
mensagens, ...)
– Aumenta a capacidade de processamento das
aplicações cliente/servidor;
www.alvarofpinheiro.eti.br
NegócioAcesso
DadosGUI Interface Interface
BDCLIENTE
www.alvarofpinheiro.eti.br
Application Server
• J2EE é uma arquitetura (Sun)
– Especificação aberta, guarda chuva, conjunto amplo de tecnologias para a criação de componentes de servidor
– varias implementações free, comerciais• Websphere, Oas, Bea Weblogic, Iplanet, etc.
• As aplicações rodam dentro de containers
• É um servidor de HTTP, OLTP, Ambiente de Desenvolvimento completo para JAVA, aderente a todos os padrões abertos.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Padrões
de Projeto
www.alvarofpinheiro.eti.br
Introdução
Os padrões para codificação de programas visam garantir que todos os desenvolvedores envolvidos no desenvolvimento e/ou manutenção de sistemas, entenderão com facilidade o objetivo e funcionamento de cada programa.
www.alvarofpinheiro.eti.br
Padronização
Os padrões devem proporcionar:
Agilidade no desenvolvimento, através do aproveitamento de templates e programas pré-existentes;
Redução de riscos, adotando padrões bem definidos e já testados diminui-se o risco de erros funcionais, desvios de performance;
Clareza do código fonte, permitindo que um programador que não tenha participado diretamente do desenvolvimento de determinada aplicação entenda com facilidade o objetivo e o funcionamento dos programas.
www.alvarofpinheiro.eti.br
Padronização
Através do padrão adotado estaremos portanto disponibilizando:
• Programas estruturados e com menosriscos de erro;
• Programas desenvolvidos maisrapidamente;
• Programas mais fáceis de alterar, sem riscode comprometimento da estrutura original;
• Programas testados integralmente e emtempo menor.
www.alvarofpinheiro.eti.br
Padronização
Mesmo tentando estabelecer padrões rígidos e detalhados, em diversas situações não será possível aplicar integralmente o padrão geral, seja por limitações de espaço em tela, por particularidades do programa ou pela facilidade de operação que um desvio de padrão poderá conferir ao programa. Em todo caso, porém, um desvio no padrão definido nesse documento deverá ser discutido previamente com o analista responsável.
www.alvarofpinheiro.eti.br
Objetivo
Este documento apresenta regras que ajudarão a desenvolver e melhorar o estilo e estrutura dos seus códigos. Ele foca em pontos comuns de erro cometidos pelos desenvolvedores de software que diretamente afetam a qualidade do código.
www.alvarofpinheiro.eti.br
Qualidade
É importante lembrar que a qualidade do software esta diretamente associada à forma de manutenção, performance e portabilidade de problemas, os quais podemos prevenir e/ou capturar, reduzindo o tempo gasto no futuro através de debug ou otimização de código, através da utilização desse documento.
www.alvarofpinheiro.eti.br
Regras
O uso deste documento também ajudará a novos desenvolvedores entenderem a padronização e o nível de expertise código. Eles não verão somente regras associadas com a qualidade na programação, mas o "entendimento" atrás das regras utilizadas. Muitas regras e definições usadas neste documento contem informações redundantes. Isto foi feito com o intuito de poder ser usado sem a necessidade de ler regras anteriores.
www.alvarofpinheiro.eti.br
Regras
• Aumento de ProdutividadeProver direções na melhoria do desenvolvimento de código.
• Melhorias sem impactoPermite que design e codificação mudem com o mínimo de impacto no código.
• AbstraçãoO uso de abstração permite uma mudança transparente.
• Implementações Late BindingPermite que tipos de dados sejam resolvidos em tempo de run-time.
• Aumento de QualidadePermite o aumento de qualidade como um código mais legível. Legibilidade implica em uma taxa baixa de erros.
www.alvarofpinheiro.eti.br
Destinado
Qualquer pessoa envolvida em projetos e lide com linguagem de desenvolvimento para a construção de aplicações. Esse documento é diretamente técnico para lideres e desenvolvedores.
www.alvarofpinheiro.eti.br
Estrutura
Este documento agrupa seus pontos em tópicos específicos. Os pontos estão em formas de regras ou definições. As regras devem "quase" nunca serem quebradas, em quanto às definições podem ser violadas com mais freqüências. Caso alguns tipos de padronização não façam sentido no projeto em desenvolvimento, esses devem ser ignorados e podem ser evoluídos durante o processo de desenvolvimento
www.alvarofpinheiro.eti.br
Por que usar Padrão de Projeto?
• Podem ser utilizados para melhorar o entendimento ou comunicação dos problemas /
decisões arquiteturais. (Fowler)
• Podem ser vistos como uma tentativa de criar um vocabulário comum para comunicação.
(Fowler)
• Experiência coletiva de arquitetos e engenheiros de software habilidosos e experientes.
(Buschmann et al.)
• Especialistas já possuem soluções para muitos dos problemas recorrentes. (Buschmann
et al.)
• Padrões capturam soluções comprovadas de uma forma facilmente acessível.
(Buschmann et al.)
• Padrões dão suporte tanto aos novatos quanto aos especialistas em desenvolvimento de
software (Buschmann et al.)
www.alvarofpinheiro.eti.br
O que é Padrão de Projeto?
• Um padrão é a solução para um determinado problema
em um determinado contexto
• Um padrão codifica conhecimento específico obtido em
uma experiência em um determinado domínio.
• Um sistema bem estruturado estará cheio de padrões
– Idiomas
– Padrões de projeto
– Padrões arquiteturais
www.alvarofpinheiro.eti.br
GRASP
www.alvarofpinheiro.eti.br
GRASP - General Responsability Assignment Software
Patterns
• O que são Padrões GRASP?
– Descrevem os princípios fundamentais do
design orientado a objetos e a atribuição de
responsabilidades, expressos como padrões
• Estes padrões servem como guia para a realização de
um Design baseado em atribuição de
Responsabilidades (RDD).
www.alvarofpinheiro.eti.br
GRASP - General Responsability Assignment Software
Patterns
• Existem nove padrões GRASP:
• Creator
• Information Expert
• Low Coupling
• Controller
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variations
www.alvarofpinheiro.eti.br
GoF
www.alvarofpinheiro.eti.br
Quais os Padrões de Projeto?
• Gamma et al descrevem vinte e três padrões que podem ser utilizados em
praticamente qualquer área de programação. Estes padrões se tornaram
clássicos da orientação a objetos. Eles foram utilizados por muitos
programadores muito antes do lançamento deste livro. Mas não tinham sido
sistematicamente documentados e catalogados. Os padrões de Gamma et
al são chamados de padrões da gangue dos quatro (Gang of Four patterns,
ou apenas GoF).
• Fachada (Facade)
• Adaptador (Adapter)
• Singleton
• Decorador (Decorator)
• Fábrica abstrata (Abstract factory)
• Estratégia (Strategy)
• Ponte (Bridge)
www.alvarofpinheiro.eti.br
Qual o template de um Padrão?
• Nome– O nome que serve como referencia para o padrão
• O Problema– Explica o problema que ocorre em um contexto, com sintomas e
em condições.
• A Solução– Elementos que constituem o design, seus relacionamentos,
responsabilidades e colaborações.
• As Conseqüências– Resultados e compromissos decorrentes da aplicação do
padrão.
– Impactos sobre a flexibilidade, extensibilidade, portabilidade ou desempenho do sistema.
– Fundamentam a escolha do padrão mais apropriado
www.alvarofpinheiro.eti.br
Qual o template de um Padrão?
• Nome e Classificação
– Identificam unicamente o padrão e o classifica para catalogação
• Intenção
– Um breve descrição que deve responder o que o padrão faz, qual sua intenção e
que problema ele trata.
• Também Conhecido Como
– Outros nomes pelo qual o padrão é conhecido
• Motivação
– Um cenário que ilustra o problema e como as classes deste padrão o
solucionam
• Aplicabilidade
– Em que situações o padrão pode ser aplicado
• Estrutura
– Representação gráfica do padrão com suas classes e colaborações
www.alvarofpinheiro.eti.br
Qual o template de um Padrão?
• Participantes
– Classes e objetos que participam no padrão, incluindo suas responsabilidades
• Colaborações
– Como os participantes colaboram entre si
• Conseqüências
– Como o padrão atende a seus objetivos e que “efeitos colaterais” seu uso pode provocar
• Implementação
– Dicas, técnicas e erros comuns ao implementar este padrão
• Exemplo de Código
– Fragmentos de código ilustrando o padrão
• Usos Conhecidos
– Exemplos de uso do padrão em sistemas reais
• Padrões Relacionados
– Padrões que estão fortemente relacionados a este , incluindo suas diferenças, ou utilizados por este
www.alvarofpinheiro.eti.br
Quais as categorias de
Padrões?• Padrões Criacionais: Auxiliam a criação de objetos, tornando o
programa menos dependente do modo como os objetos são criados e
compostos. Assim, estes padrões permitem que se mude as classes
dos objetos criados em tempo de execução com pouco esforço do
programador;
• Padrões Estruturais: Descrevem formas flexíveis para compor classes
e objetos;
• Padrões Comportamentais: Estes padrões são relacionados a
algoritmos e responsabilidades associados a cada objeto. Mudando-se
os objetos e classes utilizados, pode-se mudar o comportamento do
programa. Acoplando-se um objeto a outro, pode-se adicionar
comportamento ao segundo objeto.
www.alvarofpinheiro.eti.br
Quais os critérios de Padrões?
• Os padrões de projeto são classificados por dois critérios. O
primeiro critério, chamado objetivo, refletem as categorias
(criação, de estrutura ou de comportamento). O segundo
critério é chamado de escopo, e especifica quando o padrão é
aplicado (classes ou a objetos). Padrões com escopo de
classe lidam com relacionamentos estabelecidos através de
herança, ou seja, estáticos e definidos em tempo de
compilação. Padrões com escopo de objeto lidam com
relacionamentos de objeto, que podem ser modificados em
tempo de execução e são mais dinâmicos. Praticamente todo
padrão utiliza herança de alguma forma, por isto apenas os
padrões que focam em relacionamentos através de herança
devem ser classificados com escopo de classe. Os padrões
mais importantes estão em escopo de objeto.
www.alvarofpinheiro.eti.br
Qual o escopo de Padrões?
InterpreterAdapterFactory Method
Visitor
Strategy
StateProxy
ObserverFlyweight
MementoFaçade
MediatorDecoratorSingleton
IteratorCompositePrototype
CommandBridgeBuilder
Chain
Responsibility
AdapterAbstract Factory
Template Method
BehavioralStructuralCreational
Object
ClassScope
www.alvarofpinheiro.eti.br
O que é um Padrão Criacional?
• Padrões de projeto abstraem o processo de instanciação. Eles ajudam a tornar
o sistema independente de como os objetos são criados, compostos e
representados. Um padrão criacional de classe utiliza herança para variar a
classe que será instanciada. Um padrão criacional de objeto irá delegar a
instanciação de um objeto para outro objeto.
• Padrões criacionais tornam-se importantes a medida que os sistemas evoluem
e passam a depender mais de composição de objetos do que de herança de
classes. A medida que isto acontece, a ênfase migra da codificação de um
conjunto de comportamentos para a codificação de conjuntos menores de
comportamento, que podem ser combinados em vários conjuntos mais
complexos.
• AbstractFactory [objeto]
• Builder [objeto]
• Factory Method [classe]
• Prototype [objeto]
• Singleton [objeto]
www.alvarofpinheiro.eti.br
Abstract Factory
Interface para criação de objetos• Neste exemplo, a classe abstrata WidgetFactory possui duas especializações:
MotifWidgetFactory para widgets Motif e QtWidgetFactory para widgets Qt. Essas
especializações são classes concretas capazes de "produzir" os elementos da interface gráfica.
O cliente do toolkit obtém os elementos gráficos de que necessita através da classe (interface)
WidgetFactory sem ter conhecimento das classes concretas. Da mesma maneira, o cliente
somente interage com as interfaces que representam os elementos produzidos pela Abstract
Factory (no exemplo, a classe Janela e a classe Botao).
www.alvarofpinheiro.eti.br
Classe abstrata
Classe concreta
Abstract Factory
• Intenção: Provê uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.
• Aplicabilidade: Este padrão deve ser utilizado quando o programa precisa de independência de como seus objetos são criados, compostos e representados. Ou quando o sistema precise ser configurado para uma ou muitas famílias de classes ou objetos. Ou quando uma família de objetos relacionados é projetada para ser utilizada em conjunto e esta premissa deve ser garantida. Ou quando deseja-se prover uma biblioteca de classes, e deseja-se disponibilizar apenas as interfaces, e não as implementações.
www.alvarofpinheiro.eti.br
Builder
Separa construção da
representação• Neste exemplo, o método lerRTF() (classe LeitorRTF) percorre uma lista com os tokens
encontrados no texto de entrada (formato RTF) e, para cada tipo de token, chama um método do
objeto de tipo ConversorTexto. Dependendo do formato escolhido para o texto de destino, será
escolhida uma implementação da classe ConversorTexto: ConversorPDF, ConversorTeX ou
ConversorASCII. Cada uma destas classes implementa os métodos de acordo com as
características do formato relacionado. A classe ConversorASCII não implementa os métodos
converteParagrafo() e converteFonte() pois este formato (ASCII) não possui elementos de estilo
www.alvarofpinheiro.eti.br
Classe
representação
Classe
construção
Builder
• Intenção: Separa a construção de um objeto complexo
de sua representação, de modo que o mesmo processo
de construção possa criar diferentes representações.
• Aplicabilidade: O padrão builder deve ser utilizado
quando o algoritmo para criação de objetos complexos
deve ser independente das partes que compõem o
objeto e da forma como este objeto é “montado”. Ou
quando o processo de construção deve permitir
diferentes representações para o objeto que está sendo
construído.
www.alvarofpinheiro.eti.br
Factory Method
Delega a uma classe a instaciação de
outras• Neste exemplo, uma aplicação, que é construída através de um framework baseado
no padrão Factory Method, suporta a criação de documentos do tipo
MeuDocumento. O framework é constituído pelas classes abstratas Aplicacao e
Documento. A aplicação disponibiliza as classes concretas MinhaAplicacao e
MeuDocumento. A classe MinhaAplicacao é uma implementação da abstração
definida pela classe Aplicacao.
www.alvarofpinheiro.eti.br
Classes
abstratas
Classes
concretas
Factory Method
• Intenção: Define uma interface para criação um objeto, mas deixa
as subclasses decidirem que classe instanciar. Permite que uma
classe delegue a instanciação a suas subclasses.
• Aplicabilidade: Este padrão deve ser utilizado quando um classe
não pode antecipar a classe dos objetos que deve criar. Ou quando
a classe deseja que suas subclasses especifiquem o objeto que
será criado. O quando a classe delega a responsabilidade de
criação para um de muitas classes auxiliares, e deseja-se localizar
o “conhecimento” de que classe auxiliar deve ser delegada.
www.alvarofpinheiro.eti.br
Prototype
Criação de objetos baseados em
protótipos
• Neste exemplo é mostrado uma hierarquia de classes representando documentos de
formato ASCII e PDF que são criados através da classe Cliente. A partir de duas
instâncias prototípicas, ascii e pdf, o método criarDocumento cria clones de
documentos de acordo com o tipo desejado. A tarefa de realizar a criação da
instância é implementada na classe Documento e herdada por suas classes filhas,
ASCII e PDF.
Realiza a
interface
Clonável
Subclasses de
Documento
“Instâncias
prototípicas”
Hierarquia de
classes
Interface
www.alvarofpinheiro.eti.br
Prototype• Intenção: Especifica que tipos de objetos criar usando uma
instância prototípica do objeto. Cria novos objetos através da cópia
deste protótipo.
• Aplicabilidade: Este padrão deve ser utilizado quando a aplicação
deve ser independente de como os produtos são criados,
compostos, e representados, e, adicionalmente:
• As classes a serem instanciadas são definidas em tempo de execução
(por exemplo, dynamic loading);
• Deseja-se evitar criar um hierarquia de fábricas paralelas a hierarquia
de classes;
• Quando a instanciação da classe pode ter um de algumas poucas
combinações diferentes de estado. Isto pode ser mais conveniente criar
um número correspondente de protótipos e cloná-los ao invés de
instanciar a classe manualmente a cada vez com o estado apropriado.
www.alvarofpinheiro.eti.br
Singleton
• Intenção: Garante que uma classe possui apenas uma
única instância. Provê um ponto de acesso global a ela.
• Aplicabilidade: Este padrão de ser utilizado quando deve
haver apenas uma instância de cada classe e esta
instância deve ser acessível a todos os clientes a partir
de um ponto de acesso conhecido. Ou quando uma
única instância deve ser extensível apenas por
subclasses, e os clientes devem apenas utilizar a
instância estendida, sem modificar seu código.
www.alvarofpinheiro.eti.br
O que é um Padrão Estrutural?
• Padrões estruturais focam em como criar estruturas de maior porte através da composição de classes e objetos. Padrões estruturais de classe utilizam herança para compor interfaces ou implementações. Padrões estruturais de objeto utilizam composição de objetos para prover novas funcionalidades. A flexibilidade adicional da composição de objetos vêm da habilidade de mudar esta composição em tempo de execução, o que é impossível na composição estática de classes.
• Adapter [classe e objeto]
• Bridge [objeto]
• Composite [objeto]
• Decorator [objeto]
• Facade [objeto]
• Flyweight [objeto]
• Proxy [objeto]
www.alvarofpinheiro.eti.br
• Adapter permite que um objeto cliente utilize serviços de outros
objetos com interfaces diferentes por meio de uma interface única.
www.alvarofpinheiro.eti.br
Subclasses
distintas
Ponto único de
acesso
Utiliza métodos
de classes
distintas por
uma interface
única
Adapter
• Intenção: Converte a interface de uma classe na interface esperada pelo cliente. Compatibiliza classes de interfaces não compatíveis, permitindo que trabalhem em conjunto.
• Aplicabilidade: Este padrão deve ser utilizado quanto deseja-se utilizar uma classe já existente, e sua interface não atende a interface que você precisa. Quando deseja-se criar uma classe reusável que coopera com classes ainda não conhecidas ou não criadas, ou seja, classes que não necessariamente possui interfaces compatíveis. Necessita-se usar diversas subclasses já existentes, mas é impraticável adaptar suas interfaces através da criação de subclasses para cada uma delas.Um objeto adaptador pode adaptar a interface da superclasse.
www.alvarofpinheiro.eti.br
• Bridge O diagrama mostra a solução para o problema citado. Temos duas hierarquias de classes relacionadas: a hierarquia de tipos de janelas (Janela, Icone e Dialogo) e a de implementação nas plataformas suportadas (JanelaImpl, XWindowImpl e MSWindowImpl). O relacionamento entre as interfaces, Janela e JanelaImpl, é a "ponte" que "desacopla" a interface da implementação. Para que um ícone seja desenhado, faz-se uma chamada ao métodoDesenhaBorda() que por sua vez realiza "n" chamadas ao método DesenhaLinha() da classe XWindowImpl ou MSWindowImpl, dependendo da plataforma desejada.
Hierarquias
Interfaces
Implementação
das Interfaces
www.alvarofpinheiro.eti.br
Bridge
• Intenção: Desacopla uma abstração de sua implementação, de
modo que as duas possam variar independentemente.
• Aplicabilidade: Este padrão pode ser utilizado nas seguintes
situações:
• Deseja-se evitar uma dependência direta entre a abstração e sua
implementação. Este pode ser o caso, por exemplo, quando a
implementação tiver de ser selecionada ou substituída em tempo de
execução;
• Ambas as abstrações e suas implementações devem ser extensíveis
através da criação de subclasses. Neste caso o padrão bridge permite
que diferentes abstrações e implementações possam ser combinadas e
estendidas independentemente.
• Mudanças na implementação de uma abstração não deve impactar em
seus clientes, isto é, seu código não deve ser recompilado.
www.alvarofpinheiro.eti.br
• Composite o diagrama abaixo mostra a estrutura de classes que permite que clientes tratem de modo uniforme tanto objetos individuais quanto suas composições.
www.alvarofpinheiro.eti.br
Classe abstrata
Subclasses
Composite
• Intenção: Compõe objetos em estruturas de árvores para representar hierarquias parte-todo. Permite que clientes tratem de modo uniforme tanto objetos individuais quanto suas composições.
• Aplicabilidade: Este padrão deve ser utilizando quando deseja-se representar hierarquias parte-todo. Ou quando deseja-se que clientes sejam capazes de ignorar as diferenças entre composições dos objetos e os objetos individualmente. Clientes irão tratar uniformemente todos os objetos na estrutura composta.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Decorator definimos uma subclasse de ElementoDeDocumento chamada MonoElementoDeDocumento
MonoElementoDeDocumento é uma classe abstrata para todos os ElementoDeDocumento de
embelezamento
Classe abstrata
para
embelezamento
Interface
Classe abstrata
Classe
concretas
Decorator
• Inteção: Anexa dinamicamente responsabilidades adicionais a um
objeto. Provê uma alternativa flexível ao uso de herança como
mecanismo de extensão de funcionalidade
• Aplicabilidade: Utilize este padrão para adicionar responsabilidades
individuais a objetos dinamicamente e transparentemente, isto é,
sem afetar outros objetos. Utilize este padrão para
responsabilidades que podem ser “removidas”. Ou ainda quando a
extensão de funcionalidade através da criação de subclasses é
impraticável. Em algumas situações um grande número de
extensões independentes são possíveis e isto poderá produzir uma
grande quantidade de subclasses para suportar cada uma das
combinações.
www.alvarofpinheiro.eti.br
Facade define uma interface de mais alto nível que torna um subsistema de mais fácil
uso
Classe de mais
alto nível
www.alvarofpinheiro.eti.br
Facade
• Intenção: Provê uma interface unificada para o conjunto de interfaces de um subsistema. Define uma interface de mais alto nível que torna um subsistema de mais fácil uso
• Aplicabilidade: Utilize este padrão quando:• Deseja-se prover uma interface simples para um subsistema complexo.
A fachada pode prover uma visão padrão do subsistema que é boa o suficiente para a maior parte dos clientes. Apenas clientes que necessitem de customização terão que olhar além da fachada.
• Existem muitas dependências entre clientes e as classes que implementam as abstrações. A introdução da fachada desacopla o subsistema dos clientes e outros subsistemas, promovendo a independência e portabilidade do subsistema.
• Deseja-se quebrar o sistema em camadas. Utilize a fachada para definir um ponto de entrada para cada um dos subsistemas. Se os subsistemas são dependentes, pode-se simplificar as dependências entre eles fazendo com que se comuniquem apenas através de suas fachadas.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
FlyWeight define compartilhamento para suportar um grande número de pequenos
objetos de forma eficiente
Flyweight
• Intenção: Usa compartilhamento para suportar um
grande número de pequenos objetos de forma eficiente.
• Aplicabilidade: Este padrão deve ser utilizado quando:
• Uma aplicação utiliza um grande número de objetos;
• Armazenamento tem custo elevado devido a grande quantidade
de objetos;
• Muitos grupos de objeto podem ser substituídos por
relativamente poucos objetos compartilhados.
• A aplicação não depende da identidade do objeto. Uma vez que
os objetos podem ser compartilhados, testes de identidade irão
retornar true para objetos conceitualmente distintos.
www.alvarofpinheiro.eti.br
Proxy provê um ponto de atendimento para que outro objeto possa controlar o acesso ao
primeiro
Classe que
realiza a
interface
Classe que
controla outra
classe
Classe que
provê ponto de
atendimento
Classe
controlada
www.alvarofpinheiro.eti.br
Proxy
• Intenção: Provê um ponto de atendimento para que outro objeto possa
controlar o acesso ao primeiro.
• Aplicabilidade: Proxy é aplicável sempre que existe a necessidade de
referências mais versáteis ou sofisticadas que um ponteiro para um
objeto. Exemplos comuns são:
• Proxy remoto provendo um representante local para um objeto em
um espaço de memória diferente;
• Proxy virtual criando objetos custosos sobre demanda;
• Proxy de proteção controlando o acesso ao objeto original;
• Referência inteligente que executa ações adicionais quando o
objeto original é acessado.
www.alvarofpinheiro.eti.br
O que é um padrão
Comportamental?• Padrões comportamentais estão relacionados com algoritmos e atribuição de
responsabilidades entre objetos. Estes padrões não descrevem apenas os padrões de classes e objetos, mas também os padrões de comunicação entre estas classes e objetos. Caracterizam complexos fluxos de controle, difíceis de acompanhar em tempo de execução. Eles mudam o foco do fluxo de controle e permite que se concentre apenas na forma como os objetos estão interconectados.
• Padrões comportamentais de classes utilizam herança para distribuir o comportamento entre classes, que inclui os padrões Template Method – o mais simples deles, e o Interpreter.
• Padrões comportamentais de objetos utilizam composição de objetos, ao invés de herança, para realização de tarefas que um único objeto não poderia realizar. Estes objetos podem manter referências explícitas entre si, porém isto trás um maior acoplamento. Outros padrões permitem um menor nível de acoplamento, como o Memento, Chain of Responsability e Observer.
www.alvarofpinheiro.eti.br
O que é um padrão
Comportamental?•Chain of Responsibility [objeto]
•Command [objeto]
•Interpreter [classe]
•Iterator [objeto]
•Mediator [objeto]
•Memento [objeto]
•Observer [objeto]
•State [objeto]
•Strategy [objeto]
•Template Method [classe]
•Visitor [objeto]
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Chain of Responsability, é um modelo de objetos que assume a tarefa de descobrir qual objeto
pode satisfazer sua solicitação.
Inicia a procura
para saber qual
o objeto pode
atender a
solicitação
Chain of Responsibility
• Intenção: Evita acoplamento entre solicitantes e atendentes
permitindo que mais de um objeto tenha chance de tratar a
solicitação. Encadeia os atendentes e passa a solicitação através
desta cadeia permitindo que todos eles a tratem.
• Aplicabilidade: Este padrão deve ser usado quando:
• mais de um objeto pode tratar uma solicitação e o objeto que a tratará
não é conhecido a priori.
• o objeto que trata a solicitação deve ser escolhido automaticamente;
• deve-se emitir uma solicitação para um dentre vários objetos, sem
especificar explicitamente o receptor;
• o conjunto de objetos que pode tratar uma solicitação deveria ser
especificado dinamicamente.
www.alvarofpinheiro.eti.br
Command encapsula uma solicitação em um objeto, permitindo que se parametrize clientes com
diferentes solicitações, filas ou registros de solicitações, suportando ainda que operações sejam
desfeitas
Envia
solicitação
parametrizada
Pode ser
atendida de
várias formas
www.alvarofpinheiro.eti.br
Command
• Intenção: Encapsula uma solicitação em um objeto, permitindo que se parametrize clientes com diferentes solicitações, filas ou registros de solicitações, suportando ainda que operações sejam desfeitas.
• Aplicabilidade: Utilize este padrão para:• Parametrizar objetos por uma ação a ser executada. Você pode expressar tal
parametrização numa linguagem procedural através de uma função callback, ou seja, uma função que é registrada em algum lugar para ser chamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks;
• Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command pode ter um tempo de vida independente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneira independente do espaço de endereçamento, então você pode transferir um objeto Command para a solicitação para um processo diferente e lá atender a solicitação;
• Suportar desfazer operações. A operação Execute, de Command, pode armazenar estados para reverter seus efeitos no próprio comando. A interface do Commanddeve ter acrescentada uma operação Unexecute, que o reverte efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista histórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente, chamando operações Unexecute e Execute, respectivamente.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Interpreter dada uma linguagem, cria uma representação de sua gramática, juntamente com um
interpretador que utiliza esta representação para interpretar sentenças na linguagem.
Interpreter
• Intenção: Dada uma linguagem, cria uma representação de sua gramática,
juntamente com um interpretador que utiliza esta representação para
interpretar sentenças na linguagem.
• Aplicabilidade: Este padrão deve ser utilizado quando existe uma
linguagem a ser interpretada e é possível representar expressões nesta
linguagem como árvores sintáticas abstratas. Esse padrão funciona melhor
quando:
• A gramática é simples. Para gramáticas complexas, a hierarquia de classes se
torna muito grande e não gerenciável. Outras ferramentas como geradores de
parsers são melhores alternativas nestas situações, pois podem interpretar
expressões sem construir árvores sintáticas abstradas, o que pode salvar
espaço e possivelmente tempo;
• Eficiência não é crítico. Os interpretadores mais eficientes são usualmente não
implementados através da interpretação de árvores de parser diretamente, mas
primeiro é feita uma tradução para um outro formato.
www.alvarofpinheiro.eti.br
Iterator provê uma forma de acessar seqüencialmente os elementos de um agregado de objetos, sem
expor a sua representação interna
www.alvarofpinheiro.eti.br
Iterator
• Intenção: Provê uma forma de acessar seqüencialmente os elementos de
um agregado de objetos, sem expor a sua representação interna
• Aplicabilidade: O padrão iterator deve ser utilizado para acessar
agregações de objetos sem expor sua representação interna; para suportar
diversas “varreduras transversais” em agregados de objetos; para prover
uma interface uniforme para varrer estruturas agregadas diferentes.
www.alvarofpinheiro.eti.br
Mediator define um objeto que encapsula o modo como um conjunto de objetos interage. Promove
um acoplamento fraco entre objetos, evitando que referenciem explicitamente um ao outro, e com isto
permitindo que se possa variar independentemente a interação entre eles.
www.alvarofpinheiro.eti.br
Mediator
• Intenção: Define um objeto que encapsula o modo como um conjunto de
objetos interage. Promove um acoplamento fraco entre objetos, evitando
que referenciem explicitamente um ao outro, e com isto permitindo que se
possa variar independentemente a interação entre eles.
• Aplicabilidade: Use este padrão quando um conjunto de objetos se
comunicam de maneira complexa; o reuso de objetos é dificultado porque
este referencia e se comunica com muitos outros objetos; o comportamento
operações deve ser customizável sem a criação de inúmeras subclasses.
www.alvarofpinheiro.eti.br
Memento sem violar o
encapsulament
o, captura e
armazena
externamente o
estado de um
objeto, de modo
que o estado
anterior de um
objeto possa
ser
posteriormente
restaurado
www.alvarofpinheiro.eti.br
• Memento Aplicabilidade: Use este padrão
quando uma parte ou todo o estado de um
objeto deve ser guardado e possivelmente
recuperado posteriormente; a obtenção
direta do estado quebraria a proteção de
informação expondo detalhes de
implementação.
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Observer define
uma dependência
1-para-n entres
objetos, de modo
que quando o
estado de um
objeto é alterado
todos seus
dependentes são
notificados e
atualizados
automaticamente
• Observer Aplicabilidade: Use este padrão
quando uma mudança em um objeto deve
causar mudança em outros e não se sabe quais
e quantos são os outros objetos; quando um
objeto deve ser capaz de notificar outros objetos
sem assumir nada sobre que são estes outros
objetos. Em outras palavras, você não quer que
estes objetos estejam fortemente acoplados
entre si.
www.alvarofpinheiro.eti.br
State permite
que um objeto
altere seu
comportamento
quando seu
estado interno
se modifica e o
objeto parecerá
ter mudado de
classe
www.alvarofpinheiro.eti.br
• State Aplicabilidade: Este padrão deve ser utilizado quando:
• O comportamento de um objeto depende fortemente do seu estado e
ele deve alterar o seu comportamento em tempo de execução
dependendo do seu estado.
• Os métodos têm instruções condicionais grandes em que as condições
dependem do estado do objeto. Este estado é normalmente
representado por uma ou mais constantes do tipo enumerado.
Frequentemente, vários métodos contém esta mesma estrutura
condicional. O padrão State coloca cada ramo da instrução condicional
numa classe separada. Desta forma, o estado do objeto pode ser
tratado como um objeto ele próprio, o qual pode variar
independentemente.
www.alvarofpinheiro.eti.br
Strategy define uma família
de algoritmos, encapsula cada
um, e os faz inter-cambiáveis.
Permite que o algoritmo varie
independentemente de seus
clientes
www.alvarofpinheiro.eti.br
• Strategy Aplicabilidade: Este padrão deve ser utilizando quando:
• Diversas classes relacionados diferem apenas em
comportamento. Estratégias provêem formas de configurar a
classe com um dos muitos comportamentos;
• Necessita-se de diversas variações de um algoritmo;
• Um algoritmo utiliza dados que não devem ser conhecidos pelo
cliente. Utilize este padrão para evitar expor estruturas de dados
complexas e específicas do algoritmo.
• Um classe define diversos comportamentos, e estes aparecem
como instruções condicionais múltiplas. Ao invés de manter
estas condicionais, mova os trechos condicionais para sua
própria classe de estratégia.
www.alvarofpinheiro.eti.br
Template Method define o
esqueleto de um algoritmo
através de uma operação,
delegando alguns passos as
suas subclasses. Permitem
que subclasses redefinam
certos aspectos de um
algoritmo sem modificar a
estrutura do mesmo.
www.alvarofpinheiro.eti.br
• Template Method Aplicabilidade: Este padrão deve ser
utilizado:
• Para implementar partes invariantes de um algoritmo
uma única vez e deixar que as subclasses
implementem o comportamento que varia.
• Quando o comportamento padrão entre subclasses
devam ser fatorados e localizados em uma classe
comum para evitar duplicação de código;
• Para controlar extensões por subclasses. Pode-se
definir um template method que chama operações
gancho em pontos específicos, permitindo extensões
apenas nestes pontos.
www.alvarofpinheiro.eti.br
Visitor representa uma
operação a ser executada
sobre os elementos da
estrutura de um objeto.
Visitantes permitem que se
definam novas operações sem
modificar as classes dos
elementos sobre as quais atua.
www.alvarofpinheiro.eti.br
• Visitor Aplicabilidade: Este padrão deve ser utilizado quando:
• Uma estrutura de objetos contém muitas classes de objetos com
interfaces distintas, e deseja-se executar operações nestes objetos que
dependem de sua classe concreta;
• Muitas operações distintas e não relacionadas precisam ser executadas
em objetos em uma estrutura de objetos, e deseja-se evitar poluir estas
classes com estas operações. Visitor permite que operações
relacionadas sejam mantidas juntas definindo-as em uma classe.
Quando a estrutura do objeto é compartilhada por muitas aplicações,
utilize Visitor para colocar as operações apenas nas aplicações que
necessitem dela;
• As classes que definem a estrutura do objeto raramente muda, porém
frequentemente deseja-se adicionar novas operações sobre a estrutura.
Modificar a classe da estrutura de objetos requer redefinir a interface
para todos os visitors, o que é potencialmente custoso. Se as classes
da estrutura de objetos mudam constantemente, provavelmente é
melhor definir as operações nestas classes.
www.alvarofpinheiro.eti.br
Qualidade
www.alvarofpinheiro.eti.br
Qualidade
Motivação• Principais benefícios da qualidade
• Diminuição dos defeitos
• Aumento da confiabilidade do software
• Menos retrabalho
• Aumento da motivação da equipe
• Diminuição de custos do desenvolvimento
• Diminuição de custos da manutenção corretiva
• Aumento do valor agregado do software
• Aumento da satisfação do cliente
• Diminuição de horas extras de trabalho
www.alvarofpinheiro.eti.br
Qualidade
Motivação
• Diminuição do custo de correção de defeitos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Conceitos Básicos
www.alvarofpinheiro.eti.br
Qualidade
Custo da Qualidade
www.alvarofpinheiro.eti.br
Qualidade
Qualidade de Software
www.alvarofpinheiro.eti.br
Qualidade
Princípios da Qualidade
www.alvarofpinheiro.eti.br
Qualidade
Software
www.alvarofpinheiro.eti.br
Qualidade
Produto de Software
www.alvarofpinheiro.eti.br
Qualidade
Produto de Software
www.alvarofpinheiro.eti.br
Qualidade
Produto de Software
www.alvarofpinheiro.eti.br
Qualidade
Produto de Software
www.alvarofpinheiro.eti.br
Qualidade
Processo de Software
www.alvarofpinheiro.eti.br
Qualidade
Processo de Software
www.alvarofpinheiro.eti.br
Qualidade
Barreiras
www.alvarofpinheiro.eti.br
Qualidade
Iniciando
www.alvarofpinheiro.eti.br
Qualidade
Modelo de Melhoria PDCA
www.alvarofpinheiro.eti.br
Qualidade
Modelo de Melhoria IDEAL
www.alvarofpinheiro.eti.br
Qualidade
Modelo de Melhoria
www.alvarofpinheiro.eti.br
Qualidade
Metodologia
www.alvarofpinheiro.eti.br
Qualidade
Modelo a ser Seguido
www.alvarofpinheiro.eti.br
Qualidade
Modelo a ser Seguido
www.alvarofpinheiro.eti.br
Qualidade
Escopo
www.alvarofpinheiro.eti.br
Qualidade
Equipe
www.alvarofpinheiro.eti.br
Qualidade
Equipe
www.alvarofpinheiro.eti.br
Qualidade
Equipe
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
Auditorias
www.alvarofpinheiro.eti.br
Qualidade
SQA
www.alvarofpinheiro.eti.br
Estimativas
www.alvarofpinheiro.eti.br
"Não se pode controlar
aquilo que não se
consegue medir.“Tom de Marco
www.alvarofpinheiro.eti.br
Motivação
• Não se pode gerenciar...
– O que não se pode medir (Tom DeMarco)
• Como gerenciamos software se normalmente
não medimos o mesmo???
– São inúmeros os problemas de gestão de software
decorrentes da falta da gestão do escopo
• Estimativas são críticas para o gerenciamento
efetivo de qualquer projeto e de qualquer área
www.alvarofpinheiro.eti.br
O que medir e quando?
• O que deve ser estimado?– Tamanho, esforço, custo, …
• Quando estimar?– No início e durante todo o projeto as estimativas devem ser revisadas sempre
que necessário
• Quem deve estimar?– A equipe técnica e especialistas devem ser envolvidos
– As estimativas devem ser revisadas e concordadas
• O que considerar?– Escopo do projeto
– Atividades e produtos de trabalho
– Processo de desenvolvimento
– Modelo do ciclo de vida do projeto
– Modelos / dados históricos para converter as estimativas em homem-hora e custo...
www.alvarofpinheiro.eti.br
Medida Padrão
• A falta de uma unidade padrão para
quantificar o tamanho do software
– é o grande problema com que nos
defrontamos nos projetos de
desenvolvimento, manutenção e expansão de
sistemas.
• Que unidade de medida padronizada e
uniforme deve ser adotada para mensurar
o tamanho de um projeto ?
www.alvarofpinheiro.eti.br
Medida Padrão
• Quantidade de linhas de código?
• Quantidade de módulos?
• Quantidade de funções?
• Se cada empresa utilizar sua própria unidade, não
poderemos estabelecer comparações
www.alvarofpinheiro.eti.br
Problemas comuns
• Má interpretação do SOW
• Escopo não adequadamente definido
• Otimismo excessivo na definição dos prazos
• WBS mal elaborado
• Uso de perfis não apropriados na realização das tarefas
• Falha na identificação / tratamento de riscos
• Falha no uso de técnica de estimativa apropriada
• Falha na consideração de custos indiretos, administrativos, de overhead, ...
www.alvarofpinheiro.eti.br
Estimativas – Aspectos
importantes• As premissas e restrições utilizadas devem ser documentadas
• Dados históricos devem ser utilizados quando disponíveis
• As estimativas e toda informação necessária para reconstruí-las
devem ser armazenadas gerenciada e controlada
• Nenhuma técnica de estimativa tem valor se não houver calibração
www.alvarofpinheiro.eti.br
Estimativas – Aspectos
importantes (2)• Estimativa de esforço e custo devem estar
relacionadas
• O método utilizado para realizar as estimativas deve ser selecionado e documentado
• Alguns métodos difundidos no mercado:– Pontos de caso de uso
– Wide Band Delphi
– Pontos de função
www.alvarofpinheiro.eti.br
Técnicas de
EstimativasWideBand Delphi
www.alvarofpinheiro.eti.br
WideBand Delphi
• O método Delphi foi desenvolvido em 1948– esse método requer que um pequeno grupo de experts realizem
estimativas individuais para um determinado problema e que ao final um consenso seja alcançado através de iterações de seções de estimativas
• No inicio dos anos 70, Barry Boehm realizou modificações no método e criou a técnica atual chamada de Wideband Delphi– As mudanças buscaram criar um método de estimativas com
mais interação entre os experts responsáveis pelas estimativas
– Foi criado um procedimento repetível para a realização de estimativas em projetos de software seguindo a técnica WideBand Delphi
www.alvarofpinheiro.eti.br
WideBand Delphi
• Principais Vantagens:– As estimativas não são realizadas por uma única pessoa
– A técnica suporta a identificação do WBS do projeto (conjunto de atividades base para o planejamento do projeto)
• Todos estimam sobre a mesma base – o WBS
– As pessoas são mais comprometidas com as estimativas,sempre que participam da realização das mesmas
– A troca de conhecimento entre os experts durante as iterações de realização das estimativas permite um consenso com maior embasamento, “menos incerto”
www.alvarofpinheiro.eti.br
WideBand Delphi
• Principais Vantagens
– Pode ser utilizado para estimar qualquer coisa
– Projetos que não podem ser estimados a partir de outras
técnicas, podem ser estimadas com Wideband Delphi
• Projetos de consultoria
• Projetos que envolvam apenas documentação
• Sistemas que não envolvem apenas desenvolvimento de software
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa• Técnica de estimativa Bottom-up
• O ponto de partida para utilização da técnica é uma especificação inicial do problema a ser estimado ou uma lista alto nível das atividades a serem realizadas
• A saída do processo é:
– Lista detalhada das atividades do projeto;
– Tarefas operacionais e de overhead;
– Tarefas relacionadas ao processo;
– Premissas das estimativas;
– Estimativas de todos os participantes para as atividades do projeto.
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
Planejamento
Reunião de Kick-off
Preparação Individual
Reunião de Estimativas
Organização dos resultados
Revisão dos resultados finais
www.alvarofpinheiro.eti.br
Wideband Delphi –
Planejamento• Uma sessão de Wideband Delphi se inicia com a definição do
escopo do problema
– Problemas maiores devem ser quebrados em módulos gerenciáveis que possam ser estimados de forma mais precisa
– A pessoa responsável por iniciar o processo de estimativa deve ter a preocupação de prover o máximo de informações possíveis para o grupo responsável por estimar o projeto
• O grupo de estimativas deve possuir a seguinte configuração:
– Um moderador, responsável por planejar e coordenar as estimativas
– O gerente de projeto
– Dois ou três participantes técnicos
www.alvarofpinheiro.eti.br
Wideband Delphi –
Planejamento• O moderador deve conhecer bem o escopo a ser
estimado, de forma a poder estimar como qualquer outro
membro do grupo
– Mas o seu principal papel é agir como facilitador imparcial para
resolver conflitos durante a realização das estimativas
• Os demais participantes são selecionados com base no
seu conhecimento do negócio e com base na
experiência na tecnologia e nos processos utilizados
pela organização
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
Planejamento
Reunião de Kick-off
Preparação Individual
Reunião de Estimativas
Organização dos resultados
Revisão dos resultados finais
www.alvarofpinheiro.eti.br
Wideband Delphi – Reunião de
Kick-off• Uma reunião de kick-off é realizada com a equipe de estimativas
para garantir que todos possuem um entendimento suficiente do escopo
• O moderador fornece explicações detalhadas sobre o escopo a ser estimado– sobre a técnica de estimativas WIDEBAND para membros da equipe
que não são familiares com a mesma
• Apresenta premissas e limitações que já sejam conhecidas e que deverão impactar as estimativas
• A equipe revisa os objetivos finais das estimativas e discute todos os aspectos necessários para melhorar o entendimento do escopo
• A unidade a ser estimada é acordada: horas, dias, semanas, $, linhas de código
www.alvarofpinheiro.eti.br
Wideband Delphi – Reunião de
Kick-off• A reunião de kick-off permite que o moderador
decida se o processo de estimativa pode ser
continuado, para tal os seguintes requisitos
devem ser satisfeitos:
– A equipe selecionada deve possuir o conhecimento
necessário par estimar o projeto e todas as
informações estão disponíveis
– A reunião de kick-off deve ter acontecido com
sucesso
– A equipe deve estar em consenso a respeito do
objetivo da estimativa e da unidade a ser estimada
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
Planejamento
Reunião de Kickoff
Preparação Individual
Reunião de Estimativas
Organização dos resultados
Revisão dos resultados finais
www.alvarofpinheiro.eti.br
Wideband Delphi – Preparação
Individual• Cada participante deverá definir a lista de atividades que considerar
necessária para realizar as estimativas em um nível de detalhe apropriado
• Não é sugerido atividades com estimativa superior a 20 horas (se a unidade a ser estimada seja horas)– Nessa caso, essa atividade deve ser quebrada em atividades menores
• O responsável pela estimativa deve detalhar o máximo possível a lista de atividades– Mas as mesmas devem estar claras, pois serão consolidadas com
todas as outras atividades identificadas pelos outros membros da equipe
www.alvarofpinheiro.eti.br
Wideband Delphi –
Preparação Individual
Tarefas Iteração
#1
Iteração
#2
Iteração
#3
Iteração
#4
Requisitos
Levantar requisitos
Documentar os requisitos
Validar requisitos
Atualizar documento de requisitos
Elaborar diagrama de casos de uso
Elaborar especificação de casos de uso
Validar modelo de casos de uso
Atualizar modelo de casos de uso
Implementar protótipo de interface
Padrão de formulário para registro da lista de atividades e estimativas
www.alvarofpinheiro.eti.br
Wideband Delphi – Preparação
Individual• As estimativas não devem ser influenciadas pelo que a
gerência ou outros stakeholders do projeto almejem– Evitar que pressões externas influenciem nas estimativas
• Existem boas chances das estimativas ficarem fora das fronteiras do cronograma esperado– Negociações serão necessárias na resolução de conflitos
– Redução de escopo
– Aquisição de componentes de reuso
– Aumento da equipe
– Paralelismo de atividades
www.alvarofpinheiro.eti.br
Wideband Delphi – Preparação
Individual• Incluir atividades extras ao desenvolvimento de software
– Garantia da qualidade
– Gerência de configuração
– Atividades gerais do processo relacionadas ao ciclo de vida
adotado
– Atividades relacionadas a re-trabalho
– Atividades gerais de suporte: Treinamentos, Reuniões…
• Documentar todas as premissas tomadas como base
para realização da estimativa
www.alvarofpinheiro.eti.br
Wideband Delphi – Preparação
Individual• Orientações para realização das estimativas:
– Assumir que uma única pessoa (você) irá realizar toda a
atividade
– Assumir que todas as atividades serão realizadas
seqüencialmente
– Assumir que as atividades serão desenvolvidas de forma
ininterrupta
• Facilita o processo de estimativas
– Listar todos os períodos de dependência entre as atividades, de
forma a apoiar a tradução das estimativas em prazos
posteriormente
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
Planejamento
Reunião de Kickoff
Preparação Individual
Reunião de Estimativas
Organização dos resultados
Revisão dos resultados finais
www.alvarofpinheiro.eti.br
Wideband Delphi – Reunião de
Estimativas
• O moderador coleta as estimativas individuais de cada
participante e gera um gráfico a partir das mesmas
www.alvarofpinheiro.eti.br
Wideband Delphi – Reunião de
Estimativas• O moderador não deve identificar o responsável por cada estimativa
– O anonimato é importante para a técnica Wideband
• Cada participante explicita suas premissas e restrições levadas em consideração nas estimativas
– Sem revelar seus valores
• Uma lista de atividades mais completa é consolidada
• Um melhor entendimento a respeito do escopo a ser estimado é alcançado de forma a viabilizar um maior índice de convergência nas estimativas
www.alvarofpinheiro.eti.br
Wideband Delphi – Reunião de
Estimativas
• Após as discussões, cada participante deverá estimar “individualmente” novamente a lista de atividades– De forma a refiná-las com as informações obtidas nas discussões
da reunião
• O moderador repete o ciclo da primeira iteração, coletando os dados das estimativas individuais e adicionando ao gráfico os dados da segunda iteração das estimativas– A segunda iteração deve diminuir o intervalo entre a menor e
maior estimativa
www.alvarofpinheiro.eti.br
Wideband Delphi – Reunião de
Estimativas
• Iterações adicionais seguindo a mesma dinâmica devem ser realizadas até que…– Tenha havido 4 iterações
– As estimativas tenham convergido para um intervalo aceitável (que deve ser definido antecipadamente: dados históricos)
– O tempo da reunião de estimativa ter se esgotado (em média 2h)
– Os participantes não estejam confortáveis em alterar suas últimas estimativas
www.alvarofpinheiro.eti.br
Wideband Delphi – Reunião de
Estimativas
Gráfico de estimavas mostrando os resultados de três iterações de uma sessão de Wideband Delphi
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
Planejamento
Reunião de Kickoff
Preparação Individual
Reunião de Estimativas
Organização dos resultados
Revisão dos resultados finais
www.alvarofpinheiro.eti.br
Wideband Delphi – Organização
dos Resultados• A realização da reunião não significa o fim dos trabalhos…
• Moderador e gerente de projeto vão revisar a lista de atividades– Identificar grandes desvios nas estimativas de tarefas iguais ou
similares
– Refletir se alguma mudança precisa ser realizada
• Incluir atividades operacionais levantadas por cada um dos participantes das estimativas
• Consolidação de todas as premissas levantadas para cada atividade
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
Planejamento
Reunião de Kickoff
Preparação Individual
Reunião de Estimativas
Organização dos resultados
Revisão dos resultados finais
www.alvarofpinheiro.eti.br
Wideband Delphi – Revisão dos
Resultados Finais• Na última etapa para fechamento das estimativas a equipe revisa os
resultados finais
• O gerente de projeto apresenta a todos a lista final de atividades, as estimativas individuais, as convergências realizadas, premissas identificadas e todas as demais informações levadas em consideração para o resultado final
• A reunião final deverá durar de 30 a 60 minutos
• A equipe pode sugerir melhorias no processo de aplicação do Wideband Delphi
• Outras atividades identificadas após a reunião podem ser inseridas na lista final
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
O objetivo final é prover uma estimativa confiável (baixo
nível de variância) para o gerente de projeto continuar o
planejamento e a execução do projeto com um maior
nível de confiança
Os participantes devem revisar a lista final de forma a
garantir que a mesma é a mais completa possível
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa
• Estimativas finais: serão realizadas com base
nas estimativas finais de cada membro da
equipe
• Não é sugerido a utilização de médias simples
– O ideal é que as variações sejam mantidas
• Sugere-se a utilização do melhor caso, média e
pior caso para composição das estimativas
finais
www.alvarofpinheiro.eti.br
Wideband Delphi – Processo de
Estimativa• Os gerentes devem escolher trabalhar a
um nível de confiança (margem de erro
em torno de uma estatística) entre 10% e
90%
• Mas os dados reais devem ser coletados
para comparação com as estimativas
– De forma a permitir a melhoria contínua das
mesmas
www.alvarofpinheiro.eti.br
Técnicas de
EstimativasPontos de Caso de Uso
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Motivação• Técnica de estimativas baseada na abordagem de especificação de
casos de uso
– Que é uma técnica de especificação de requisitos para sistema
orientados a objetos
– Fácil de entender
• Baseada na técnica de pontos de função
– Técnica bastante difundida no mercado
• Permite a estimativa do tamanho e esforço do projeto
– Tamanho baseado na complexidade dos casos de uso
– Esforço derivado a partir de um fator de produtividade
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Principais conceitos
Casos de uso – Conceito da linguagem
UML para uma funcionalidade do sistema
que agregue valor para os atores do
mesmo. Casos de uso surgem dos
requisitos do sistema.
Ator – entidades externas ao sistema que
interagem com o mesmo. Entre eles
usuários e sistemas legados.
Fatores ambientais – Fatores referentes ao nível de experiência da equipe de desenvolvimento e a estabilidade do projeto.
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Principais conceitos
Fatores Técnicos – Fatores técnicos do
projeto, referentes a arquitetura do sistema,
necessidades especificas do usuário e
cliente.
UUCP – Unadjusted Use Case Points
UCP – Use Case Points
TCF – Technical Complexity Factor
EF – Environmental Factor
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Principais conceitos• Critérios de entrada para uso da técnica
– Todos os casos de uso do sistema devem
estar identificados
– Atores identificados para todos os casos de
uso do sistema
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
Atribuir peso aos atores
Atribuir peso aos casos
de uso
Calcular total de pontos de
casos de uso não ajustados
Atribuir peso aos fatores
técnicos
Atribuir peso aos fatores
ambientais
Calcular pontos de
casos de uso ajustados
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• O processo se inicia com a identificação dos
atores do sistema a ser desenvolvido, classificando-os como simples, médio e complexo
• Critérios para a classificação de atores:– Simples: um sistema legado com uma interface de
comunicação bem definida;
– Médio: sistema legado com comunicação via protocolos, por exemplo TCP/IP, ou interfaces Text-Based, por exemplo Terminal ASCII;
– Complexo: pessoa que interage com o sistema via interface gráfica.
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
• Tabela de peso dos atores
• Os atores devem ser agrupados pelo tipo em que foram classificados, cada grupo deve ser multiplicado pelo valor de seu peso e depois somados dando o peso total dos atores do sistema.
Tipo do ator Descrição Peso
SimplesInterface de um
sistema1
Médio
Interface interativa
ou via protocolos de
comunicação
2
Complexo Interface gráfica 3
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• Exemplo de atribuição de pesos aos
atores
– Usuário funcionário do banco
– Sistema de transações bancárias
– => 1 ator complexo e 1 ator médio
• Total de pontos
– 1*3 + 1*2 = 5 pontos
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
Atribuir peso aos atores
Atribuir peso aos casos
de uso
Calcular total de pontos de
casos de uso não ajustados
Atribuir peso aos fatores
técnicos
Atribuir peso aos fatores
ambientais
Calcular pontos de
casos de uso ajustados
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• Processo similar ao dos atores do sistema
• Cada caso de uso identificado para o sistema deve ser classificado como– simples, médio e complexo.
• A base para a tomada dessa decisão é o número de transações envolvidas no caso de uso, incluindo os fluxos alternativos
• O conceito de transações nesse contexto se restringe a um “conjunto atômico de atividades”, um cenário do caso de uso por exemplo
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
• A tabela abaixo lista o fator e a classificação de cada tipo de
caso de uso.
Tipo do Caso de Uso
Descrição Peso
Simples<= 3
transações /cenários
5
MédioDe 4 a 7
transações / cenários
10
ComplexoMais do que 7
transações / cenários
15
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• Outro mecanismo usado para medir a
complexidade de casos de uso é o número de
classes de análise
– a quantidade de transações nesse caso não é levada
em consideração
• Essa abordagem só pode ser utilizada quando
as classes de análise do sistema já estão
definidas, e já se sabe que classes de análise
implementam os casos de uso
– as classes de projeto não são levadas em
consideração
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
• A tabela abaixo lista o fator e a classificação de cada tipo de caso de uso de acordo com as classes de análise envolvidas
• Utilizando um dos mecanismos o total de casos de uso de cada tipo é somado e multiplicado pelo peso correspondente ao tipo (simples, médio e complexo)
Tipo do Caso de Uso
Descrição Peso
SimplesMenos do que 5 classes de análise.
5
MédioDe 5 a 10 classes de análise.
10
ComplexoMais do que 10 classes de análise.
15
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
Atribuir peso aos atores
Atribuir peso aos casos
de uso
Calcular total de pontos de
casos de uso não ajustados
Atribuir peso aos fatores
técnicos
Atribuir peso aos fatores
ambientais
Calcular pontos de
casos de uso ajustados
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• O fator calculado através dos atores do
sistema deve ser somado ao fator
calculado pelos casos de uso
• Esse fator é denominado UUCP
(Unadjusted use case points) e será
ajustado para refletir a complexidade do
projeto e a experiência da equipe de
desenvolvimentoFator dos atores + Fator dos casos de uso = UUCP
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
Atribuir peso aos atores
Atribuir peso aos casos
de uso
Calcular total de pontos de
casos de uso não ajustados
Atribuir peso aos fatores
técnicos
Atribuir peso aos fatores
ambientais
Calcular pontos de
casos de uso ajustados
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• É necessário ponderar o fator UUCP com os aspectos técnicos do
projeto: complexidade do sistema, experiência da equipe e requisitos não funcionais
• O fator TCF(Technical Complexity Factor) expressa a complexidade do sistema.
• Para o cálculo do TCF para cada fator é atribuído um peso no valor de 0 a 5, onde o 0 significa que o fator é irrelevante ao sistema e 5 indica ser essencial
• Soma-se então o valor de cada fator multiplicado pelo peso atribuído em função do sistema específico (os valores de 0 a 5).
– TFactor = SOMA ((TLevel) * (Peso Especifico))
– TCF = 0.6 + (0.01*TFactor)
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
“Fatores Técnicos”Numero do
fator
Descrição do Fator Peso padrão do fator
(para o método UCP)
T1 Sistema distribuído 2
T2 Objetivos de tempo de resposta e
capacidade de taxa de transferência
1
T3 Alta eficiência para o usuário final
(sistemas on-line)
1
T4 Processamento interno complexo 1
T5 O código deve ser reutilizável 1
T6 Facilidade de instalar 0.5
T7 Facilidade de uso 0.5
T8 Portável 2
T9 Facilidade de manutenção 1
T10 Concorrência 1
T11 Possui requisitos de segurança 1
T12 Provê interfaces para componentes
externos
1
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
Atribuir peso aos atores
Atribuir peso aos casos
de uso
Calcular total de pontos de
casos de uso não ajustados
Atribuir peso aos fatores
técnicos
Atribuir peso aos fatores
ambientais
Calcular pontos de
casos de uso ajustados
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• Após a definição do TCF, é necessário
calcular o fator relacionado ao ambiente
de desenvolvimento, incluindo equipe, o
EF (Environmental Factor).
• Para o cálculo do EF utiliza-se outro
conjunto de fatores
• Para cada um dos fatores listados no
conjunto se atribui pesos específicos para
o sistema nos limites de 0 a 5
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
“Fatores Ambientais”Número do Fator Descrição do Fator Peso Padrão
F1 Familiar com o processo de
desenvolvimento
1.5
F2 Experiência no domínio da
aplicação
0.5
F3 Experiência em Orientação a
Objetos
1
F4 Experiência do Analista Líder 0.5
F5 Motivação 1
F6 Requisitos estáveis 2
F7 Equipe alocada em tempo parcial -1
F8 Linguagem de programação
complexa
-1
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• A seguir são listados os critérios de atribuição dos pesos de cada
fator:
– De F1 até F4, o valor 0 indica não haver experiência, 5 significa expertse 3 um nível médio de experiência
– F5, 0 indica não existência de motivação, 5 alta motivação e 3 média
– F6, 0 indica requisitos extremamente instáveis, 5 estáveis e 3 nível parcial de instabilidade
– F7, 0 indica inexistência de pessoas da equipe em tempo parcial, 5 toda a equipe em tempo parcial e 3 expressa uma equipe mista
– F8, 0 indica linguagem de programação fácil, 5 extremamente difícil e 3 uma linguagem com nível de dificuldade médio
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• O Cálculo do fator ambiental segue a
mesma regra do fator técnico
• Soma-se então o valor de cada fator
multiplicado pelo peso atribuído em
função do sistema específico (os valores
de 0 a 5), sendo definido dessa forma o
valor EFactor
– EFactor = SOMA((FLevel) * (Peso
específico))
– EF = 1.4 + (-0.03*EFactor)www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem
Atribuir peso aos atores
Atribuir peso aos casos
de uso
Calcular total de pontos de
casos de uso não ajustados
Atribuir peso aos fatores
técnicos
Atribuir peso aos fatores
ambientais
Calcular pontos de
casos de uso ajustados
www.alvarofpinheiro.eti.br
Pontos de Caso de Uso
Processo de Contagem• Depois do cálculo de todos os fatores que
influenciam a complexidade total do
sistema, pode-se obter o total de pontos
de caso de uso através da seguinte
fórmula:UCP = UUCP * TCF * EF
www.alvarofpinheiro.eti.br
Realização das Estimativas de
Esforço• Para a estimativa de esforço do projeto, o método de Pontos de
Caso de Uso sugere o fator de 20 homens hora por Ponto de Caso
de Uso, UCP
• Uma outra análise ainda pode ser feita sobre os fatores ambientais
para ajustar esse fator:
– Na contagem dos fatores de F1 a F6 que obtiveram peso menor do que
3, e dos fatores de F7 e F8 que obtiveram peso > 3, os resultados dos
valores apresentam as seguintes situações:
• Se o valor final obtido for <= 2, é indicado o fator 20 homens/hora por UCP;
• Se o valor obtido for 3 ou 4, é indicado o fator 28 homens/hora por UCP;
www.alvarofpinheiro.eti.br
Realização das Estimativas de
Esforço• Ainda quanto ao valor do fator ambiental...
– Se o valor obtido for >= 5, o projeto deve ser revisto,
pois os fatores ambientais podem contribuir para o
insucesso do mesmo
– O fator EF se torna um pouco mais critico devido a
medir o nível de experiência da equipe e a
estabilidade do projeto
– Números negativos nessa área indicam que o projeto
terá que reservar um certo tempo para treinamento
da equipe ou para correção de problemas
introduzidos devido a inexperiência da mesma.
www.alvarofpinheiro.eti.br
GQM
Goal Question
Metric
www.alvarofpinheiro.eti.br
Introdução
• A idéia básica de GQM é derivar métricas
de software a partir de perguntas e
objetivos.
• Este método foi originalmente criado por
Victor Basili e Weis como resultado de
experiências práticas e pesquisas
acadêmicas.
www.alvarofpinheiro.eti.br
Definindo um Programa de Métricas
• O processo de definição de um programa de métricas deve ser baseado nas necessidades de informação de cada nível organizacional.
• Isto é obtido a partir do levantamento de informações junto as áreas interessadas.
• O paradigma do GQM foi proposto como uma abordagem orientada a objetivos para a medição de produtos e processos.
• Essa metodologia baseia-se na premissa de que, para ganhar uma medida prática, deve-se primeiro entender e especificar os objetivos dos artefatos de software sendo medidos e os objetivos do processo de medição.
www.alvarofpinheiro.eti.br
Significado de GQM
• Goal
– Quais são as metas/objetivos?
• Question
– Quais questões se deseja responder?
• Metric
– Quais métricas poderão ajudar?
www.alvarofpinheiro.eti.br
GQM - Vantagens
• Apóia a definição top-down do processo de medição e a análise bottom-up dos dados resultantes;
• Ajuda na identificação de métricas úteis e relevantes;
• Apóia a análise e interpretação dos dados coletados;
• Permite uma avaliação da validade das conclusões tiradas;
• Diminui a resistência das pessoas contra processos de medição.
www.alvarofpinheiro.eti.br
GQM – Passos Básicos...
1. Listar os principais objetivos do processo de
medição;
2. Derivar de cada objetivo as perguntas que devem
ser respondidas para determinar se os objetivos
foram atingidos;
3. Decidir o que precisa ser medido para ser capaz de
responder as perguntas adequadamente (definição
das métricas).
www.alvarofpinheiro.eti.br
GQM – Hierarquia dos Passos
• Os objetivos da medição são definidos em termos da
entidade, propósito, atributos de qualidade, ponto de
vista e ambiente
• Cada objetivo é refinado em um conjunto de
perguntas que representam uma definição
operacional do objetivo
• Para cada pergunta, as métricas relevantes são
definidas.
www.alvarofpinheiro.eti.br
GQM – Estrutura Hierárquica
www.alvarofpinheiro.eti.br
Premissas para a medição
• Prover resultados consistentes;
• Permitir sua obtenção por não especialistas em informática;
• Ser de fácil aprendizado;
• Ser compreensível ao usuário final;
• Servir para estimativas;
• Permitir automatização;
• Possibilitar obter séries históricas.
www.alvarofpinheiro.eti.br
Exemplo
• Problema
– Durante a fase de testes muitos defeitos
foram encontrados e suspeita-se de que a
qualidade do software poderá não atingir um
nível satisfatório na implantação (deadline).
• Solução
– Construir uma árvore GQM para auxiliar na
tomada desta decisão.
www.alvarofpinheiro.eti.br
Exemplo
Decidir quando o software
estará pronto para a implantação
Qual é o requisito
de estabilidade?
Qual é a atual
confiabilidade?
Quais são as
métricas temporais?
Tamanho de
código
Defeitos
descobertos
Casos de
testes
Horas de
utilização
Horas
de teste
Pessoas
disponíveis por
dia para testeswww.alvarofpinheiro.eti.br
GQM - Fases1. Planejamento
2. Definição
3. Coleta de dados
4. Interpretação
Além disso, a abordagem possui métodos
para refinamento de objetivos, geração
das questões, especificação das
métricas, validação, análise,
implantação do processo em uma
organização, etc.
www.alvarofpinheiro.eti.br
GQM - Problemas
• A utilização de GQM é importante para que as métricas sejam úteis, simples e diretas.
• Entretanto, as métricas não são definidas no nível de detalhes necessário para garantir confiabilidade.
• Em particular, não é explicitado se as métricas podem ou não ser repetidas, ou seja, se a medição de um atributo for repetida por uma pessoa diferente, o mesmo resultado deve ser obtido.
• Ex: linhas de código de um software.
www.alvarofpinheiro.eti.br
GQM - Problemas
• Há uma necessidade de se estabelecer um padrão de especificação de métricas que permita expressar uma métrica com detalhes suficientes para torná-la não ambígua e que ao mesmo tempo seja de fácil especificação.
• No trabalho de Kitchenham é proposto um modelo que permite a modelagem e o armazenamento de métricas de software.
• No trabalho de Ford, sugere-se que as métricas sejam categorizadas por tamanho, esforço e planejamento, qualidade, desempenho, confiabilidade e complexidade. Para cada uma destas categorias é proposto um conjunto de métricas que são agrupadas em classes de atributos relacionados ao software.
www.alvarofpinheiro.eti.br
Integração GQM e QIM
• QIM
– Quality Improvement Paradigm
• QIM será apresentado no próximo seminário!
• As 6 etapas do processo GQM são semelhantes às 6 etapas do QIM (mesmo ciclo de atividades)!
www.alvarofpinheiro.eti.br
CMMi
www.alvarofpinheiro.eti.br
Capability Maturity Model e Rational Unified Process
www.alvarofpinheiro.eti.br
www.alvarofpinheiro.eti.br
Relembrando os níveis de
maturidade...
Processo imprevisível, pouco controlado
Processo definido para o nível de projetos e frequentemente reativo
Processo proativo e definido para a organização
Processo medido e controlado
Foco na melhoria do processo
QuantitativelyManaged
Performed
Managed
Defined
1
2
3
4
5
Optimizing
www.alvarofpinheiro.eti.br
Relembrando ...
Um Processo Gerenciado
Planejado
Executado de acordo
com políticas
Pessoas capacitadas
Stakeholders
relevantes
Monitorado e
Controlado Aderência
é verificada
www.alvarofpinheiro.eti.br
A Situação Atual• Problemas comuns no desenvolvimento
de software:
– software que não atende aos requisitos de funcionalidade e qualidade esperados.
– projetos que extrapolam prazo e custo estimados.
– projetos mais complexos, com equipes maiores, mais difíceis de gerenciar.
– gerência de projetos ineficiente.
• “Crise de software é eminentemente gerencial”.
www.alvarofpinheiro.eti.br
Motivação
Standish Group
Pesquisa realizada com 30.000 projetos de empresas
americanas, de pequeno, médio e grande porte.
www.alvarofpinheiro.eti.br
Motivação
• Percentual de projetos bem sucedidos está aumentando:
– Melhores ferramentas para monitorar e controlar progresso do desenvolvimento dos projetos.
– Melhoria dos processos de gerenciamento e perfis dos gerentes.
• Busca pela qualidade do desenvolvimento de software adoção de modelos de qualidade.
www.alvarofpinheiro.eti.br
Objetivos
• Contribuir para melhoria da qualidade do desenvolvimento de software através da efetiva gerência de projetos:
–Seguindo as diretrizes do CMM 2, com foco nos processos de gerenciamento de projetos de software.
–Fazendo uso de métricas como ferramenta para gerência de projetos.
www.alvarofpinheiro.eti.br
Capability Maturity Model (CMM)
• Modelo para avaliação do processo de produção de software.
• Proposto pelo Software Engineering Institute (SEI).
• Bastante utilizado pelas empresas de software: EDS, Motorola, Boeing, IBM.
www.alvarofpinheiro.eti.br
Níveis de Maturidade
Inicial (1)
Repetível (2)
Definido (3)
Gerenciado (4)
Otimizando (5)
Processo
Caótico
Processo
Disciplinado
Processo
Padronizado e
Consistente
Processo
Previsível
Processo
de
Melhoria
Contínua
www.alvarofpinheiro.eti.br
Estrutura do CMM
Atividades ou
infra-estrutura
Implementação
ou
institucionalizaçã
o
Metas
indicam
alcançam
abordam
descrevem
contêm
contêm
Práticas-chave
Organizadas pelas
Características
Comuns são
Compromisso
Habilitação
Atividade
Medição e análise
Verificação
Níveis de
MaturidadeCapacitação do
Processo
Áreas-chave de
Processo
www.alvarofpinheiro.eti.br
Nível 2 do CMM
• Foco nos processos de gerenciamento de projetos.
• Áreas-Chave (KPAs):
– Gerenciamento de Requisitos
– Planejamento de Projeto de Software
– Supervisão e Acompanhamento de Projeto de Software
– Gerência de Contrato de Software
– Garantia da Qualidade de Software
– Gerência de Configuração de Software
www.alvarofpinheiro.eti.br
KPA Gerência de Requisitos
Metas:
• Documentar e controlar os requisitos alocados para estabelecer uma base para todo o processo de desenvolvimento.
• Manter planos, artefatos e atividades de software consistentes com os requisitos alocados.
www.alvarofpinheiro.eti.br
KPA Planejamento de Projetos
Metas:
• Documentar as estimativas de software aserem usadas no planejamento eacompanhamento do projeto.
• Planejar e documentar as atividades e oscompromissos do projeto dedesenvolvimento de software.
• Obter a concordância dos grupos e das pessoas envolvidas quanto aos respectivos compromissos relacionados ao projeto de desenvolvimento de software.
www.alvarofpinheiro.eti.br
KPA Supervisão e Acompanhamento de
ProjetoMetas:
• Acompanhar os resultados e desempenhosreais confrontando-os com o plano dedesenvolvimento de software.
• Tomar ações corretivas e gerenciá-las atésua conclusão.
• Assegurar que as alterações nos compromissos de software se dêem através de acordo entre os grupos e as pessoas envolvidas.
www.alvarofpinheiro.eti.br
KPA Gerência de Contrato de Software
Metas:
• Contratar empresa de software qualificada
• Estabelecer acordo entre contratada e contratante
• Manter comunicação efetiva entre contratada e contratante
• Contratante deve acompanhar desempenho e resultados da contratada, comparando-os com compromissos assumidos.
www.alvarofpinheiro.eti.br
KPA Garantia da Qualidade
Metas:
• Planejar atividades de GQS
• Verificar conformidade das atividades eprodutos de software.
• Informar aos envolvidos as atividades eresultados de GQS.
• Encaminhar à gerência questões de não-conformidade não resolvidas no âmbito doprojeto de software.
www.alvarofpinheiro.eti.br
KPA Gerência de Configuração de Software
Metas:
• Planejar atividades de Gerência de Configuração de Software
• Identificar, controlar e tornar disponíveis os artefatos de software
• Controlar alterações nos artefatos de software
• Informar aos envolvidos acerca do estado e conteúdo das baselines de software.
www.alvarofpinheiro.eti.br
CMM nível 2 e o RUP
• KPA Gerenciamento de Requisitos:
– Processo orientado a casos de uso.
– Fluxo de gerenciamento de mudanças.
• KPA Planejamento de Projeto de
Software:
– Elaboração do Plano de Projeto, Plano da
Iteração, Estimativas de esforço, Lista de
Riscos.
– Avaliação e revisão dos planejamentos
(avaliação e planejamento das iterações).www.alvarofpinheiro.eti.br
CMM nível 2 e o RUP
• KPA Supervisão e Acompanhamento do
Projeto de Software:
– Resultados acompanhados e avaliados ao
final de cada iteração e cada fase.
– Alterações nos compromissos acordadas e
acompanhadas pelos envolvidos.
– Planejamento das próximas iterações com
base nas avaliações.
www.alvarofpinheiro.eti.br
CMM nível 2 e o RUP
• KPA Garantia da Qualidade:
– Milestones com objetivos bem definidos para
auditorias.
– Atividades de revisões bem definidas.
– Provê modelos de documentos a serem
utilizados como padrão do projeto, para tratar
questões de não conformidade.
www.alvarofpinheiro.eti.br
CMM nível 2 e o RUP
• KPA Gerência de Configuração de
Software
– Plano de Gerenciamento de Configuração,
Plano de Gerenciamento de Builders.
• KPA Gerência de Contrato de Software:
– Não é diretamente atendido no RUP, porém,
as ferramentas, técnicas e mecanismos
existentes no RUP podem ser utilizados para
acompanhar o contrato.
www.alvarofpinheiro.eti.br
Objetivos / Expectativas
• Ao final do módulo o aluno deve:
– Entender os conceitos do CMMI nos níveis de
maturidade 3, 4 e 5
– Entender as áreas de processo e atividades
de forma macro nos respectivos níveis
www.alvarofpinheiro.eti.br
Nível 3 de Maturidade
• Processo para desenvolvimento de software é estabelecido, padronizado e documentado pela organização (adaptado quando necessário)
• Todos os projetos utilizam uma versão deste processo, personalizada para o tipo do projeto a ser desenvolvido
• Atividades de gerenciamento e engenharia de software são estáveis e repetidas (foco na organização)
www.alvarofpinheiro.eti.br
Nível 3 de Maturidade
• Funções e responsabilidades no processo são bem entendidas
• A produção do produto de software é visível através do processo de software
• Papéis, responsabilidades e interação entre atividades são bem entendidos por todos
In Out
www.alvarofpinheiro.eti.br
• Desenvolvimento dos Requisitos
• Solução Técnica
• Integração do Produto
• Verificação
• Validação
• Foco no Processo da Organização
• Definição do Processo da Organização
• Treinamento Organizacional
• Gerenciamento Integrado de Projetos
• Análise de Decisão e
Resolução
• Gerenciamento de Riscos
• Gerenciamento Integrado de Fornecedor
• Ambiente Organizacional para
Integração
• Integração de Equipes
QuantitativelyManaged
Performed
Managed
Defined
Optimizing
Áreas de Processo - Nível 3
Antigas
do CMM
www.alvarofpinheiro.eti.br
As áreas de engenharia do
nível 3
REQM
RD TS PI
Ver Val
Cliente
Soluções alternativas
Requisitos
Relatórios de verificação e validação
Componentes do produto, produtos de trabalho
Necessidades do cliente
Requisitos do produto e requisitos dos
componentes do produto
Requisitos
www.alvarofpinheiro.eti.br
Desenvolvimento dos
Requisitos
• SG1: Desenvolver requisitos do cliente
– Necessidades dos principais envolvidos, expectativas,
limitações e interfaces são traduzidas em requisitos do
cliente
• SG2: Desenvolver requisitos do produto
– Requisitos do cliente são refinados e traduzidos em
requisitos do produto e dos componentes
• SG3: Analisar e validar requisitos
– Os requisitos são analisados e validados, e uma definição
das funcionalidades é elaborada
Produzir e analisar requisitos do cliente,
do produtos e dos componentes
www.alvarofpinheiro.eti.br
Desenvolvimento dos
Requisitos• Principais atividades:
– Elicitar necessidades
– Elaborar uma visão geral dos requisitos
– Detalhar os requisitos
– Definir fluxos alternativos: como o software deve operar sobre certas condições
– Alocar os requisitos aos componentes do sistema: telas, fachada, sub-sistemas
– Identificar interfaces com outros sistemas
– Garantir que todos os requisitos são necessários e suficientes
– Validar os requisitos: confrontar restrições com as necessidades dos stakeholders
www.alvarofpinheiro.eti.br
Solução Técnica
• SG1: Selecionar Soluções para o produto
– Soluções para o produto (ou componentes) são
selecionadas a partir de soluções alternativas
• SG2: Desenvolver o Projeto
– Desenvolver o projeto do produto
• SG3: Implementar o Projeto do Produto
– Os componentes do produto e documentações relacionadas
são produzidas a partir do projeto
Projetar, desenvolver e implementar soluções para
os requisitos. Envolve a escolha da melhor solução
para atender aos requisitos
www.alvarofpinheiro.eti.br
Solução Técnica
• Principais atividades:
– Verificar e evoluir os cenários de instalação e
operação do produto
– Definir critérios para a análise das soluções
apropriadas
– Realizar análise “Make or Buy or reuse”
– Elaborar e implementar o projeto gerando o produto
final
– Elaborar documentação de suporte ao produto:
manuais, manuais de instalação e operação, etc.
www.alvarofpinheiro.eti.br
Integração do Produto
• SG1: Preparar o produto para integração
• SG2: Garantir compatibilidade entre as
interfaces
– Interfaces internas e externas devem ser
garantidas
• SG3: Montar e liberar o produto
Montar o produto a partir dos componentes desenvolvidos,
garantir que o produto integrado funciona de
forma adequada e pode ser entregue
www.alvarofpinheiro.eti.br
Integração do Produto
• Principais atividades:
– Realizar testes de integração entres os componentes
e módulos
– Estabelecer a seqüência de integração, preparar o
ambiente, estabelecer procedimentos de integração
– Revisar interfaces para garantir completude
– Garantir que os componentes estão devidamente
integrados e prontos para o release
– Liberar o produto
www.alvarofpinheiro.eti.br
V&V – Verificação e Validação
Estamos construindo o produto de forma correta?
Estamos atendendo aos requisitos especificados?
Estamos construindo o produto correto?
Estamos atendendo às necessidades operacionais?
X
Garantir que os produtos de trabalho selecionados
atendem aos requisitos especificados
Demonstrar que o produto ou componente atende
a intenção de uso quando implantado no ambiente
planejado
www.alvarofpinheiro.eti.br
V&V – Verificação e Validação
• SG1: Preparar para verificação
– Garantir que os produtos estejam prontos
• SG2: Realizar peer reviews
– Nos produtos de trabalho selecionados
• SG3: Verificar produtos de trabalho selecionados
– Os produtos de trabalhos são verificados com base nos requisitos especificados
• SG1: Preparar para validação
– Garantir que os produtos estejam prontos para validação
• SG2: Validar o produto ou componentes do produto
– O produtos e/ou seus componentes são validados para garantir que estão adequados para o uso no ambiente operacional apropriado
Verificação Validação
www.alvarofpinheiro.eti.br
Nível 3 de Maturidade
As demais áreas serão explicadas de
forma breve...
www.alvarofpinheiro.eti.br
Foco no processo da
organização & Definição do
processo da organização
• SG1: Determinar oportunidades de melhoria de processos
– Periodicamente os pontos fracos e oportunidades de melhoria do processo são identificados
• SG2: Planejar e implementar atividades de melhoria de processos
– Os ajustes e melhorias no processo são implementados de forma planejada e novas versões do processo são disponibilizadas
Planejar e implementar a melhoria do processo
organizacional baseada nos pontos fortes e fracos
existentes no processo
Estabelecer e manter o processo
(assets do processo) da organização
SG1: Estabelecer o processo (e seus assets) da organização
www.alvarofpinheiro.eti.br
Treinamento Organizacional
• SG1: Estabelecer a capacidade de treinamento
organizacional
– A capacidade de treinamentos que suporta os papéis
técnicos e gerenciais da organização é estabelecida e
mantida
• SG2: Prover os treinamentos necessários
– Treinamentos necessários para as pessoas executarem
seus papéis são fornecidos
Desenvolver e manter as habilidades e conhecimentos das
pessoas para que elas possam executar seus Papéis de
forma efetiva e eficiente
www.alvarofpinheiro.eti.br
Gerenciamento Integrado de
Projetos
• SG1: Utilizar o processo definido para o projeto
– O projeto é conduzido utilizando um processo que é
adaptado a partir do processo organizacional
• SG2: Coordenar e colaborar com os stakeholders
relevantes
– Coordenação e colaboração do projeto junto aos
stakeholders relevantes
Estabelecer e gerenciar o projeto e o envolvimento dos
stakeholders relevantes de acordo com um processo
integrado, definido e adaptado a partir do processo
da organização
www.alvarofpinheiro.eti.br
Gerenciamento de Riscos
• SG1: Preparar para a gestão dos riscos
• SG2: Identificar e analisar riscos
– Os riscos são analisados quanto a sua importância relativa no contexto do projeto
• SG3: Mitigar riscos
– Os riscos são mitigados a fim de diminuir o seu impacto no projeto ou mesmo a fim de reduzir sua probabilidade de ocorrência
Identificar problemas potenciais antes que eles ocorram,
de forma que as atividades para evitar os riscos possam
ser executadas antes que o projeto sofra grandes impactos
www.alvarofpinheiro.eti.br
Gerenciamento Integrado de
Fornecedor
• SG1: Analisar e selecionar fontes de produtos /
componentes
• SG2: Coordenar o trabalho com os fornecedores
– Garantir que o contrato será executado de forma apropriada
Identificar proativamente produtos e/ou componentes
que possam ser usados para satisfazer requisitos do projeto
e gerenciar os fornecedores selecionados de forma cooperada
www.alvarofpinheiro.eti.br
Análise de Decisão e
Resolução
• SG1: Avaliar alternativas
– Decisões são baseadas em uma avaliação de alternativas
através de um critério estabelecido
Analisar possíveis decisões através de um processo
de avaliação formal que avalia alternativas identificadas
com base em critério estabelecido
Aplicabilidade da área de processo DAR
Guidelines documentados devem ser definidos para determinar quando um processo de avaliação formal precisa ser aplicado
Os guidelines devem sugerir a utilização do processo formal sempre os itens de ação estiverem relacionados a riscos de médio ou alto impacto ou quando os desvios afetarem a capacidade do projeto de atender seus objetivos
www.alvarofpinheiro.eti.br
Áreas de processo especificas
de IPPD• Ambiente organizacional para Integração
– Prover a infra-estrutura necessária para o
desenvolvimento do processo e do produto integrado
a gerenciar pessoas para a integração
• Integração de equipes
– Formar e manter uma equipe integrada para o
desenvolvimento de produtos de trabalho
Não vamos abordá-las em maiores detalhes pois
não fazem parte do escopo do SW-CMMI
www.alvarofpinheiro.eti.br
Nível 4 de Maturidade
• Os níveis 2 e 3 de maturidade estabelecem a fundação para o gerenciamento quantitativo
• Processos definidos que– Possuem consistência com a organização
– Possuem medições comuns que acumulam dados significativos de toda organização
• Nos níveis 2 e 3 medidas são coletadas e analisadas para se entender e gerenciar as atividades e resultados do projeto– Limites são estabelecidos e ações são tomadas quando os dados
atingem os limites
– Mas não são usados outros métodos estatísticos para análise dos dados
www.alvarofpinheiro.eti.br
Nível 4 – Gerenciado Quantitativamente
• O processo de software é previsível e gerenciado quantitativamente (estável)
• Métodos estatísticos e quantitativos são utilizados no nível de projetos e da organização para:
– Entender os resultados de performance, a qualidade do produto e do serviço de projetos passados
– Prever a performance e a qualidade do produto e dos serviços de projetos futuros
Nível 4 de Maturidade
www.alvarofpinheiro.eti.br
Nível 4 de Maturidade
Nível 4 – Gerenciado Quantitativamente
• Utilização de objetivos quantitativos, para atender os necessidades dos clientes, usuários finais e da organização
• Atenção: A implementação do nível 4 deve ser considerada antecipadamente– As medições requeridas no nível 4 podem (ou não) ser diferentes
das medições requeridas no nível 3
– As análises requeridas no nível 4 demandam uma grande base de dados de medições
– É indicado um alinhamento das atividades do nível três com os objetivos futuros do nível 4
www.alvarofpinheiro.eti.br
Nível 4 de Maturidade
Nível 4 – Gerenciado Quantitativamente
• Progresso e problemas são medidos• A gerência tem bases objetivas para tomada de decisão
In Out
www.alvarofpinheiro.eti.br
% Esforço Organizacional
0%
20%
40%
60%80%
100%
120%
140%
160%
Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez
% E
sfo
rço
Org
. % Esforço
Organizacional
Goal
UCL
LCL
Nível 4: Endereçando as
causas especiais de variação...
Variações especiais
www.alvarofpinheiro.eti.br
QuantitativelyManaged
Performed
Managed
Defined
Optimizing
Áreas de Processo - Nível 4
• Performance do Processo Organizacional
• Gerenciamento Quantitativo de Projetos
www.alvarofpinheiro.eti.br
Performance do Processo
Organizacional
• SG1: Estabelecer Baselines de
Performance e Modelos Estatísticos
Estabelecer e manter um entendimento quantitativo
da performance do processo padrão da organização (e assets)
para suportar a qualidade e objetivos de performance do
processo, e prover dados de performance do processo,
baselines e modelos para gerenciar quantitativamente os
projetos da organização
www.alvarofpinheiro.eti.br
Gerenciamento Quantitativo
de Projetos
• SG1: Gerenciar quantitativamente o projeto– O projeto é gerenciado quantitativamente através dos
objetivos de qualidade e performance
• SG2: Gerenciar estatisticamente os sub-processos do projeto– Alguns sub-processos do processo definido do projeto são
gerenciados com técnicas estatísticas
Gerenciar quantitativamente os processos definidos do projeto
a fim de alcançar os objetivos de qualidade e performance
do projeto
www.alvarofpinheiro.eti.br
Nível 5 de Maturidade
Nível 5 – Otimizando
• No nível 4 a análise é direcionada às causas especiais de variação do processo => No nível 5, a análise é direcionada às causas comuns de variação do processo
• As medições são utilizadas para:
– Selecionar melhorias e inovações, estimar seus custos e acompanhar os gastos reais
• OS processo definidos da organização são alvos das atividades de melhoria
www.alvarofpinheiro.eti.br
Nível 5 de Maturidade
Nível 5 – Otimizando
“A Melhoria de processo contínua e “mensurável” é um estilo de vida...”
In Out
www.alvarofpinheiro.eti.br
% Esforço Organizacional
0%
20%
40%
60%
80%
100%
120%
140%
Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez
% E
sfo
rço
Org
. % Esforço
Organizacional
Goal
UCL
LCL
Nível 5: Endereçando as
causas comuns de variação...
Variações Comuns
www.alvarofpinheiro.eti.br
QuantitativelyManaged
Performed
Managed
Defined
Optimizing
Áreas de Processo - Nível 5
• Desenvolvimento e Inovação Organizacional
• Análise Causal e Resolução
www.alvarofpinheiro.eti.br
Desenvolvimento e Inovação
Organizacional
• SG1: Selecionar Melhorias– Processos e inovações que contribuem para o atendimento
dos objetivos de qualidade e da performance do processo são selecionadas
• SG2: Implantar as Melhorias– As melhorias mensuráveis são incorporadas aos processos
e tecnologias da organização de forma contínua e sistemática
Selecionar e implantar melhorias inovadoras de forma incremental
Que de forma mensurável melhoram os processos e
tecnologias da organização. As melhorias suportam os objetivos
de qualidade e da performance do processo da organização
derivados dos objetivos de negócio.
www.alvarofpinheiro.eti.br
Análise Causal e Resolução
• SG1: Determinar as causas dos defeitos
– As causas que geraram os defeitos e outros problemas são
identificadas
• SG2: Endereçar as causas dos defeitos
– Ações são tomadas nas causas dos problemas para evitar
que os mesmos voltem a acontecer
Identificar as causas dos defeitos e de outros problemas e tomar
ações corretivas para prevenir que os mesmos voltem a
ocorrer no futuro
www.alvarofpinheiro.eti.br
Considerações Finais
• Principais problemas:
– Institucionalização do processo
– Envolvimento da gerência sênior nas atividades necessárias para a
implantação do modelo
• Aspectos importantes:
– Definir processos que façam sentido para o escopo da organização,
caso contrário não sobreviverão após a avaliação
– O modelo permite interpretações para diversos tipos de organizações
– Atenção com a área de processo de Medição e Análise
www.alvarofpinheiro.eti.br
Considerações Finais
• Principais Benefícios
– Uma aplicação criteriosa de conceitos de gerenciamento de processos
e de melhoria da qualidade ao desenvolvimento e manutenção de
software
– Um modelo para melhoria organizacional reconhecido
internacionalmente
– Ponto forte para empresas que desejam ingressar no mercado de
exportação
– Maior controle sobre os projetos
– Criação de uma base histórica de dados organizacional
– Melhoria nas estimativas dos projetos
– Visibilidade do progresso do projeto mais perto do real
www.alvarofpinheiro.eti.br
Considerações Finais
• Mas nem tudo são flores...– No inicio da institucionalização dos processos, o
overhead percebido é grande• Nesse momento, ajustes devem ser realizados para
minimizar ao máximo o overhead
• É importante que pessoas com experiência em desenvolvimento de software participem das definições dos processos ou pelo menos aprovem
– Nem todas as práticas se aplicam a qualquer tipo de projeto
• A necessidade de adaptações criteriosas precisam ser feitas, através de práticas alternativas que atendam a intenção da prática
www.alvarofpinheiro.eti.br
Considerações Finais
• Mas nem tudo são flores...– É necessário fazer com que a equipe de desenvolvimento se torne uma
aliada dos processos• Isso é possível e os ganhos são grandes!!
– Quando o ganho não é imediato, as atividades se tornam difíceis de implantar
• No entanto, estamos na fase em que a qualidade não é mais um diferencial
• Precisamos ter não apenas qualidade, mas qualidade com excelência– A qualidade que mais se adequa a nossa realidade e a de nossos
clientes!!!
www.alvarofpinheiro.eti.br
Gerência de
Projetos
www.alvarofpinheiro.eti.br
Clientes
Necessidades
Fronteira
Produtos e Serviços
Atendimento
OrganizaçãoRecursos
Processos
Áreas de resultados
www.alvarofpinheiro.eti.br
Clientes
Necessidades
Fronteira
Produtos e Serviços
Atendimento
OrganizaçãoRecursos
Processos
Impactos: a mudança da
realidade da clientela
são atendidas através de...
que são gerados pelos...
Áreas de resultados – de fora para dentro
www.alvarofpinheiro.eti.br
Clientes
Necessidades
Fronteira
Produtos e Serviços
Atendimento
OrganizaçãoRecursos
Processos
P
R
O
J
E
T
O
Cadeia de resultados
www.alvarofpinheiro.eti.br
ESTRATÉGIA
É uma definição de um futuro desejado e dos meios
eficazes para alcançá-lo(Ackoff)
Onde
estamos?
(B)
Aonde
pretendemos
chegar
(A)
A melhor maneira
de evoluir de “B” para “A”
• Programas
• Projetos
• Outros trabalhos
Portfólio
Todas as empresas que estão no mundo de negócios
de hoje possuem um portfólio de projetos.
www.alvarofpinheiro.eti.br
GESTÃO DE PORTFÓLIO
Processos mais eficazes de gerenciamento de portfólio
O novo padrão do PMI
The Standard for Portfólio Management
É a PONTE, que liga as
estratégias organizacionais
com os projetos.
www.alvarofpinheiro.eti.br
CENÁRIO ATUAL DOS PORTFOLIOS NAS ORGANIZAÇÕES
Muitos projetos ativos
Geralmente o dobro do que a organização deveria ter
Projetos errados
Projetos que não agregam valor à organização
Projetos não alinhados
Não estão ligados aos objetivos estratégicos
Projetos importantes sem recursos
Recursos prioritários não estão sendo alocados aos projetos
prioritários
Portfólio não balanceado
Muitos projetos de melhorias, poucos de inovação
Muitos projetos de desenvolvimento, poucos de pesquisa
www.alvarofpinheiro.eti.br
SINAIS DE PROBLEMAS NA GESTÃO DE
PORTFÓLIOS• Não há um entendimento claro e formal
de como os PROJETOS estão conectados à ESTRATÉGIA da organização. 1
• Gerentes de Projetos e Gerentes Funcionais estão permanentemente “BRIGANDO” por recursos.2
• As PRIORIDADES estão freqüentemente mudando.3
• Projetos são aprovados INDEPENDENTEMENTE de haver ou não RECURSOS disponíveis.4
www.alvarofpinheiro.eti.br
SISTEMÁTICA DE GESTÃO
Assegurar que a coleção de projetos escolhidos esteja alinhada
com os objetivos da organização.
www.alvarofpinheiro.eti.br
Portfólio
Portfólio
Programas
Projetos
Projetos
Projetos Programas
Programas Projetos Outros trabalhos
Projetos Projetos
Portfólio: uma coleção de projetos e/ou programas e/ou outros trabalhos
agrupados para facilitar o gerenciamento efetivo destes trabalhos e
atingir objetivos estratégicos do negócio.
DEFINIÇÃO
www.alvarofpinheiro.eti.br
Portfólio
Portfólio
Programas
Projetos
Projetos
Projetos Programas
Programas Projetos Outros trabalhos
Projetos Projetos
Gerenciamento de Portfólio: gerenciamento centralizado de um ou mais
portfólios, que inclui identificação, priorização, autorização, gerenciamento e
controle de projetos, programas e outros trabalhos relacionados.
DEFINIÇÃO
www.alvarofpinheiro.eti.br
SEPARANDO CONCEITOS...
www.alvarofpinheiro.eti.br
SUCESSO NO GERENCIAMENTO
Cliente satisfeito com os resultados
Prazos cumpridos conforme o acordado
Ausência de desvios no orçamento
Produto dentro das especificações
técnicas
Objetivos estratégicos alcançados
Redução do ciclo de vida dos projetos
Retorno adequado dos investimentos
Rentabilidade do portfólio de acordo
com a esperada
Gerenciamento de
PORTFÓLIOGerenciamento de
PROJETOS
www.alvarofpinheiro.eti.br
COMPARANDO
PROJETOS PROGRAMAS PORTFÓLIO
Escopo mais restrito e
com entregas específicas.
Escopo mais amplo que pode
mudar para atingir a
expectativa da organização.
Escopo de negócios que
muda com as metas
estratégicas da organização.
Os gerentes tentam
manter o mínimo de
mudança.
Os gerentes têm expectativa
de mudanças e até mesmo
promovê-las.
Os gerentes monitoram as
mudanças num ambiente
amplo.
O sucesso é medido por
estar dentro do
orçamento, no prazo e
por produtos entregues
conforme especificação.
O sucesso é medido em termos
de Retorno sobre o
Investimento (ROI), novas
capacidades e benefícios
entregues.
O sucesso é medido em
termos de desempenho
agregado nos componentes
do portfólio.
Os gerentes monitoram e
controlam tarefas e o
trabalho de produção dos
produtos do projeto.
Os gerentes monitoram
projetos e o andamento do
trabalho ao longo da estrutura
de governança.
Os gerentes monitoram o
desempenho agregado e os
indicadores de valor.
www.alvarofpinheiro.eti.br
CONTEXTO ORGANIZACIONAL
Quais componentes poderiam
ser alocados
propositadamente no
portfólio?
Fonte: The Standard for
Portfólio Management - PMI®
www.alvarofpinheiro.eti.br
“Certamente não há nada tão inútil quanto fazer com grande eficiência algo que nunca deveria ter sido feito”.
Peter Ducker
GOVERNANÇA ORGANIZACIONAL
Trata-se do ato de
desenvolver, comunicar,
implementar, monitorar e
assegurar as políticas,
procedimentos, estruturas
organizacionais e práticas
associadas a um portfólio.
O resultado é um ambiente
para tomada eficaz de
decisões.
www.alvarofpinheiro.eti.br
GOVERNANÇA ORGANIZACIONAL
Fonte: The Standard for
Portfólio Management - PMI®
www.alvarofpinheiro.eti.br
Plano Estratégico
•Objetivos estratégicos
•Metas
•Critérios de
desempenho
•Definição de
capacidade
Identificação
Categorização
Avaliação
Seleção
Priorização
Balanceamento
do Portfólio
Autorização
Revisão do
Portfólio e
Comunicação
Mudança
Estratégica
Execução dos
componentes
sim
não
Plano Estratégico atual
da Organização
Grupo de Processos de
Alinhamento
Grupo de Processos
de Monitoramento e
Controle
Processos dos
Componentes
Processos de Gerenciamento do Portfólio
VISÃO GERAL DOS PROCESSOS
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identificação do componente
– Número, nome, descrição, etc.
Objetivos estratégicos apoiados
Benefícios quantitativos e qualitativos
Recursos requeridos
Cliente
Patrocinador
Stakeholders
Cronograma
Resultados tangíveis
Riscos
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Componentes
inventariados e
documentados
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Crescimento das vendas
Aumento da participação de mercado
Melhoria de eficiência ou de processos
Obrigações regulamentares
Redução de riscos empresariais
Satisfação do cliente
...
Componentes
combinados em
grupos de negócio
relevantes
conforme o plano
estratégico
Validar com os stakeholders
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Posicionamento de cada
componente dentro do
portfólio
Critérios de avaliação
Negócios
Melhoria de eficiência ou de processos
Finanças
Riscos
Marketing
Foco técnico
...
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Ranqueamento
multicritérios
ROI
Custos
Duração
Riscos
Recursos
Preço
Promoção
Fonte: The Standard for
Portfólio Management - PMI®
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Comparação gráfica baseada em dois critérios
baixo
médiobaixo
alto
alto
médio
Critério 2
Critério 1
Ir em frente
Cuidado
Finalizar
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Produzir uma lista de componentes do
portfólio representando os componentes
que atingiram as metas dos critérios da
empresa definidos e alinhá-los com a
estratégia organizacional.
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Lista priorizada de componentes
potenciais do portfólio, todos
listados dentro de suas categorias
estratégicas específicas.
Fonte: The Standard for
Portfólio Management - PMI® www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Componentes priorizados num
agrupamento de componentes
que apresente o melhor potencial
para o alcance coletivo das metas
estratégicas.
Se 90% dos componentes se alinham
com dois dos cinco objetivos
estratégicos da empresa, o portfólio
precisa ser balanceado.
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
As estratégias organizacionais, os objetivos estratégicos, os critérios de
gerenciamento de portfólio, as métricas de desempenho entram no jogo.
•Análises de custos e benefícios
•Análises quantitativas
•Análises de cenários
•Análises de probabilidades
•Métodos analíticos gráficos
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
O tamanho da bolha reflete
o custo do projeto.
As cores das bolhas
representam critérios.
As categorias 4 e 5 contam
com apenas dois projetos.
A unidade de negócio 1
possui somente um projeto
na categoria de
investimentos 2.
Cada critério parece ter
uma correlação direta com
a unidade de negócio.
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Investimentos nas Categorias1 2 3 4 5
Unid
ades
de N
egócio
1
2
3
4
5
6
Investim
ento
s para
Unid
ade d
e N
egócio
1
2
3
4
5
6
Projetos por Categoria
1 2 3 4 5
Um método gráfico
Fonte: The Standard for
Portfólio Management - PMI®
www.alvarofpinheiro.eti.br
PROCESSOS DE ALINHAMENTO
• Aprovação final dos stakeholders chave:
– Decisões sobre inclusão de
componentes;
– Autorizações, desativações ou
finalizações de componentes
selecionados;
– Realocação de orçamentos e de recursos
de componentes inativos/finalizados;
– Alocações de recursos financeiros e
humanos aos componentes selecionados;
– Comunicação sobre os resultados
esperados para os componentes
selecionados.
Identifi-
cação
Categori-
zaçãoAvaliação Seleção
Priori-
zação
Balancea-
mento
Autori-
zação
Plano formal de comunicações para
o gerenciamento do portfólio
www.alvarofpinheiro.eti.br
Plano Estratégico
•Objetivos estratégicos
•Metas
•Critérios de
desempenho
•Definição de
capacidade
Identificação
Categorização
Avaliação
Seleção
Priorização
Balanceamento
do Portfólio
Autorização
Revisão do
Portfólio e
Comunicação
Mudança
Estratégica
Execução dos
componentes
sim
não
Plano Estratégico atual
da Organização
Grupo de Processos de
Alinhamento
Grupo de Processos
de Monitoramento e
Controle
Processos dos
Componentes
Processos de Gerenciamento do PortfólioMONITORAMENTO E CONTROLE
www.alvarofpinheiro.eti.br
REVISÃO DO PORTFÓLIO E COMUNICAÇÃO
Informações consistentes
e precisas
Planejamento
Estratégico
Operações Gerenciamento
do Portfólio
Gerenciamento
de Programas e
Projetos
Identificação,
categorização,
avaliação, seleção,
priorização,
balanceamento e
autorização de
componentes do
Portfólio
Revisão do desempenho
do Portfólio
Revisão do desempenho
de Programas e Projetos
Processos
Visão, Missão e
Plano Estratégico
Entregas concluídas
para operações
Solicitações de
Programas e
Projetos
www.alvarofpinheiro.eti.br
MUDANÇA ESTRATÉGICA
Os projetos atuais são adequados para
satisfazer os objetivos e alvos estratégicos
da organização ao longo do tempo,
assegurando equilíbrio entre necessidades
atuais e futuras?
A organização será capaz de competir em
diferentes cenários futuros? O portfólio de
projetos inclui alternativas?
Revisões Novo critério
www.alvarofpinheiro.eti.br
CONTEXTO
Processos mais eficazes para gerenciamento de múltiplos projetos
e atividades relacionadas, em um ambiente de um programa
O novo padrão do PMI
The Standard for Portfólio Management
Promover uma compreensão detalhada entre grupos
organizacionais:
• Gerentes de Projetos – relacionamento e interface com
Gerentes de Programas.
• Gerentes de Programas – entendimento sobre suas regras.
• Gerentes de Portfólios - relacionamento e interface com
Gerentes de Programas.
• Stakeholders - entendimento das regras de gerenciamento de
Programas.
• Gerentes Senior – entendimento das regras dos executivos com
parte no Comitê de Programa.
www.alvarofpinheiro.eti.br
DEFINIÇÃO
Portfólio
Portfólio
Programas
Projetos
Projetos
Projetos Programas
Programas Projetos Outros trabalhos
Projetos Projetos
Programa: um grupo de projetos relacionados e gerenciados de forma
coordenada para obter benefícios e controle não disponíveis a partir de
seu gerenciamento de forma individual.
www.alvarofpinheiro.eti.br
DEFINIÇÃO
Portfólio
Portfólio
Programas
Projetos
Projetos
Projetos Programas
Programas Projetos Outros trabalhos
Projetos Projetos
Gerenciamento de Programas: gerenciamento centralizado e coordenado
de um programa de forma a obter os objetivos e benefícios estratégicos
definidos para o programa.
www.alvarofpinheiro.eti.br
COMPARANDO
PROJETOS PROGRAMAS PORTFÓLIO
Escopo mais restrito e
com entregas específicas.
Escopo mais amplo que pode
mudar para atingir a
expectativa da organização.
Escopo de negócios que
muda com as metas
estratégicas da organização.
Os gerentes tentam
manter o mínimo de
mudança.
Os gerentes têm expectativa
de mudanças e até mesmo
promovê-las.
Os gerentes monitoram as
mudanças num ambiente
amplo.
O sucesso é medido por
estar dentro do
orçamento, no prazo e
por produtos entregues
conforme especificação.
O sucesso é medido em termos
de Retorno sobre o
Investimento (ROI), novas
capacidades e benefícios
entregues.
O sucesso é medido em
termos de desempenho
agregado nos componentes
do portfólio.
Os gerentes monitoram e
controlam tarefas e o
trabalho de produção dos
produtos do projeto.
Os gerentes monitoram
projetos e o andamento do
trabalho ao longo da estrutura
de governança.
Os gerentes monitoram o
desempenho agregado e os
indicadores de valor.
www.alvarofpinheiro.eti.br
UM EXEMPLO DO GOVERNO
DE MINASVisão de Futuro
Opções
Estratégicas
Tornar Minas
Gerais o
melhor Estado
para se viver
10
Objetivos
Estratégico
s
31
Programas
Estruturadore
s
Artigo publicado na revista Mundo
PM www.alvarofpinheiro.eti.br
Programas estruturadores (exemplos)
2 Corredores Radiais de Integração e
Desenvolvimento
Reduzir o “custo de transporte” e aumentar...
5 Saneamento Básico: Mais Saúde para Todos
Ampliar a cobertura dos sistemas públicos...
10 Modernização da Receita Estadual
Alavancar as fontes de receita do Estado...
12 Regionalização da Assistência à Saúde
Adequar a oferta de serviço à demanda...
27 Arranjos Produtivos Locais
Desenvolvimento dos arranjos produtivos...
Projetos
Atividade
s
Programas
UM EXEMPLO DO GOVERNO DE MINAS
www.alvarofpinheiro.eti.br
Pilares para o gerenciamento
ME
TO
DO
LO
GIA
INF
OR
MA
TIZ
AÇ
ÃO
ES
TR
UT
UR
A
OR
GA
NIZ
AC
ION
AL
COMPETÊNCIAS
GP
UM EXEMPLO DO GOVERNO DE MINAS
www.alvarofpinheiro.eti.br
Aumento do nível de execução dos projetos
Previsibilidade e controle sobre os resultados
Conhecimento e gestão dos riscos
Visibilidade das atividades necessárias
Comprometimento do coordenador e da equipe
com as metas dos projetos
Melhoria da gestão de licitações, contratos e
convênios
“Consideramos a ferramenta de GP extremamente oportuna para aumentar a eficiência da gestão dos gastos do setor público e ampliar a contribuição deste
setor para o desenvolvimento nacional.”
Benefí
cio
sUM EXEMPLO DO GOVERNO DE MINAS
www.alvarofpinheiro.eti.br
Projeto A
Projeto B
Projeto C
Projeto D
Projeto E
Benefícios
A1...n
Benefícios
E1...n
Benefícios discretos
Benefícios
coordenados
Programa
Gestão do
ProgramaBenefício
sBenefícios do
Programa
1...n
GERENCIAMENTO DE BENEFÍCIOS
Avalia o impacto
organizacional do
programa
Avalia as
interdependências dos
benefícios
Designa responsabilidades
pelos benefícios reais
Fonte: The Standard for
Program Management - PMI®
www.alvarofpinheiro.eti.br
GERENCIAMENTO DE PROGRAMAS NO
PLANEJAMENTO ESTRATÉGICO
Visão estratégica
Programas
Projetos
Mobilização Objetivos
estratégicosOpções estratégicasPortfólio estratégico
Set up Pre-
ProgramaSet up do
Programa
Infraestrutura
gerencial e técnica
para o Programa
Entrega de
benefícios
incrementais
Conclusão
do
ProgramaTransição
Operações
regulares
www.alvarofpinheiro.eti.br
CICLO DE VIDA DO PROGRAMA
Set up
Programa
Infra-estrutura
gerencial e técnica
para o Programa
Entrega de benefícios incrementaisConclusão
do
Programa
Transição Operações
regulares
Entrega de
benefíciosPerfil de
Custos
Tempo
Cu
sto
www.alvarofpinheiro.eti.br
CICLO DE VIDA DO PROGRAMA
• Fase 1 – Set up pré-programa
• Fase 2 – Set up do programa
• Fase 3 – Estabelecimento do gerenciamento do programa e infra-estrutura
técnica
• Fase 4 – Entrega de benefícios incrementais
• Fase 5 – Conclusão do programa
Fase 1 Fase 2 G2 Fase 3 Fase 4 Fase 5G1 G3 G4 G5
Governança do Programa
www.alvarofpinheiro.eti.br
TEMAS DO GERENCIAMENTO DE
PROGRAMAS
• Gerenciamento de benefícios1
• Gerenciamento das partes interessadas do programa2
• Governança do programa3
www.alvarofpinheiro.eti.br
Identificação Análise Planejament
o
Realização Transição
Identificar e
qualificar os
benefícios de
negócios
Derivar e
priorizar
componentes
Estabelecer
plano de
realização de
benefícios
Monitorar
componentes
Consolidar
benefícios
coordenados
Derivar
métricas de
benefícios
Estabelecer
monitoramento
de benefícios
Manter registro
dos benefícios
Transferir
responsabilidad
e para operação
Mapear
benefícios no
Plano do
Programa
Reportar
benefícios
GERENCIAMENTO DE BENEFÍCIOS
www.alvarofpinheiro.eti.br
GERENCIAMENTO DAS PARTES
INTERESSADAS
Diretor de Programa
Gerente de Programa
Gerentes de Projetos
Patrocinador do Programa
Cliente
Organização executora
Membros de equipes
Escritório de gerenciamento de Programas
Comitê de Governança do Programa
“São indivíduos ou organizações cujos interesses podem ser
afetados pelos resultados do programa, positiva ou
negativamente”.
www.alvarofpinheiro.eti.br
GOVERNANÇA DO PROGRAMA
Trata-se do processo de
desenvolver, comunicar,
implementar, monitorar e
assegurar as políticas,
procedimentos, estruturas
organizacionais e práticas
associadas a um programa.
O resultado é um ambiente
para tomada de decisões de
forma eficaz.
www.alvarofpinheiro.eti.br
PROCESSOS DE GERENCIAMENTO
DE PROGRAMASIniciação Define e autoriza o programa ou um projeto dentro do
programa, gerando a declaração de benefícios do
programa e o plano de realização de benefícios.
Planejamento Planeja as melhores alternativas de ação para entrega
dos benefícios e escopo definidos para o programa.
Execução Integra projetos, pessoas e outros recursos para
execução do plano do programa e entrega dos
benefícios associados.
Monitoramento e
controle
Monitora o programa e projetos associados em
comparação com seus respectivos planos e benefícios
esperados, identificando variações e implementando
ações corretivas, quando necessário.
Encerramento Formaliza a aceitação de um produto, serviço ou
benefício, trazendo o programa ou um de seus
integrantes a um fim ordenado.
www.alvarofpinheiro.eti.br