Alvarofpinheiroesw 141126221524 Conversion Gate01 PDF

https://www.facebook.
com/alvarofpinheiroaulas/
br.linkedin.com/in/alvarofpinheiro/
Engenharia de Software
Fundamentos
http://www.alvarofpinheiro.eti.br
Projeto
www.alvarofpinheiro.eti.br
Projetos
Origem dos erros nos softwares
Outros
10%
Programação
7%
Análise
56%
Desenho
27%
Projetos
Custo de correção dos erros
Incremento de
100 a 1000 vezes
Custo
Etapas do ciclo de desenvolvimento
Projetos
Incremento do custo dos erros
1 Captura de requisitos
2,5 Análise e Desenho
5 Codificação
10 Teste Unitário
25 Prova de Aceitação
100 Manutenção
Boehm, 1988
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.
Êxito do projeto segundo seu tamanho
60
50
até $750m
40 $750ma $1.5M
Porcentagem de
êxito (%) $1.5Ma $3M
30
$3Ma $6M
20 $6Ma $10M
+ de $10M
10
0
Tamanho do projeto ($)
Standish Group, 1999
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
Análise
Engenharia
de
Requisitos
Metodologias
Modelos
Processos
Técnicas
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.
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.
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.
Metodologias
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
As metodologias ágeis incentivam

a mudança nos requisitos, pois
desta forma é possível realmente
entregar ao cliente o produto que
ele precisa.
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.
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.
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.
Metodologias Ágeis
Introdução
Desta forma existem maiores

possibilidades de atender aos
requisitos do cliente, que muitas
vezes são mutáveis.
Metodologias Ágeis
Modelos
Dentre as várias metodologias

ágeis existentes, as mais
conhecidas são a eXtreme
Programming e a Scrum.
Metodologias Ágeis
X
Metodologias Tradicionais
Um exemplo de uma metodologia

tradicional ou pesada é o modelo
em Cascata, que é composto
basicamente por atividades
seqüenciais de levantamento de
requisitos, análise, projeto,
implementação, teste,
implantação e manutenção.
Metodologias
Manifesto Ágil
O resultado foi a criação da

Aliança Ágil e o estabelecimento
do “Manifesto Ágil” (Agile
Manifesto).
Metodologias
Manifesto Ágil Conceitos
Indivíduos e interações ao invés de
processos e ferramentas.
Software executável ao invés de

documentaçã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.
Metodologias
É uma metodologia ágil para

equipes pequenas e médias que
desenvolvem software baseado
em requisitos vagos e que se
modificam rapidamente.
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.
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.
Processo
O que é um processo
• Um processo define quem faz o que,

quando e como para se alcançar
um objetivo
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
Processo de desenvolvimento
de um software
• Elicitação de requisitos
• Definição da arquitetura
• Análise
• Projeto
• Implementação
• Testes
• Implantação
• Manutenção
Controle dos Processos
• Arquitetura
• CMMI
• Fases
• Software Process Automation
• Fabrica de Software
Metodologias
Tradicionais
Rational
Unified
Process
(RUP)
RUP
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
Metodologias
Ágeis
Scrum
Scrum
Fases
• Planejamento
• Sprints
– Ciclos
• Encerramento
Scrum
Outra metodologia ágil que

apresenta uma comunidade
grande de usuários.
Scrum
Objetivo
Seu objetivo é fornecer um

processo conveniente para projeto
e desenvolvimento orientado a
objeto.
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.
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.
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.
Scrum
Idéia
A idéia principal da Scrum é que o

desenvolvimento 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.
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.
Scrum
A Scrum divide o desenvolvimento em

iteraçõ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.
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.
Scrum
Introdução
ORIGEM: METODOLOGIA:
ADM (Advanced Gerenciamento, manutenção
Development Methods) e desenvolvimento de softwares:
+ simples e pequenos
VMARK Software grandes e complexos
PROCESSO:
Ágil BASE P/ SCRUM:
Empírico Técnicas e tools OO
Incremental
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.
Scrum
Fases
Planejamento
• Processo definido
Backlog
• 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
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
Fonte: Mountain Goat Software
• Sempre apresentam um executável ao final
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
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
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
Scrum
Qualidade, Gerenciamento e Testes
 Passos e papéis bem definidos
 Gerenciamento de riscos Controles
 Revisões frequentes / diárias Backlog

 Definição de padrões
Release/Melhoria
Mudanças
 Realização de testes Problemas
 Elaboração de documentação Soluções
Issues
 Grupo QA
Scrum
Conclusões
 Divisão de responsabilidades  Ausência de práticas de

 papéis bem definidos Engenharia de Software
 Processo ágil e flexível (técnicas e notações) e
 inúmeras mudanças no decorrer do tools
projeto
 Necessidade de
 Foco em controle/gerenciamento
associação com outras
 minimiza risco
 maximiza qualidade metodologias e tools
(XP, GNATS)
 Times pequenos
 Colaboração  Dificuldade na
implementação de
mudanças
XP – eXtreme
Programming
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.
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.
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.
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.
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).
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.
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 o
projeto ficou pronto em pouco
mais de um ano.
Paradigma
A maioria das regras da XP causa

polêmica à primeira vista e muitas
não fazem sentido se aplicadas
isoladamente.
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.
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.
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.
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.
Regra: Feedback
A prática do feedback constante significa
que 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.
Regra: Coragem
É necessário coragem para implantar
os três valores anteriores. Por
exemplo, não são todas as pessoas
que possuem facilidade de
comunicaçã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
Práticas
A XP baseia-se nas 12 práticas.
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
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.
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 ter
o 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 a
probabilidade do software final estar de acordo
com os requisitos do cliente.
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 o
desenvolvimento do software.
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 ser
adicionados assim que eles realmente
existirem. Esta forma de raciocínio se
opõe ao “implemente para hoje e
projete para amanhã”.
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.
Prática 6: Refatoração
Focaliza o aperfeiçoamento do
projeto do software e está presente
em todo o desenvolvimento. A
refatoraçã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.
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.
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.
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.
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.
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.
Prática 12: Código Padrão
Padronização na arquitetura do
código, para que este possa ser
compartilhado entre todos os
programadores.
Crystal
Processo de
Desenvolvimento
de Software
• 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:
• 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
• 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.
• 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.
• 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.
• 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
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.
Feature Driven
Development
Desenvolvimento
orientado a
funcionalidades
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
FDD - Processos
 O FDD consiste de 5 processos principais:
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)
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)
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)
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
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..
Dynamic Systems
Development
Method (DSDM)
Método dinâmico de
desenvolvimento de
sistemas
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
DSDM - Fases
 O DSDM consiste de 5 fases:
Feasibility
Review Study
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)
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)
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
Adaptive Software
Development
Desenvolvimento
Adaptável de
Software
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)
ASD - Fases
 O ASD possui ciclos de 3 fases:
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
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
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
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)
Paradigma
Orientada a
Objetos
Desenvolvimento de Software
Programas
Processos
Dados
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
Objetos
Visualiza e representa o mundo real

como um conjunto de objetos que
interagem entre si para que determinadas
operações sejam realizadas.
Motorista Carro
Parar
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
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
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
Objetos (o domínio da aplicação)
pilha de saída
chefe docs doc
doc
docs secretária
pilha de entrada
arquivo
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
Objetos (o modelo de objetos)
doc
Instrução Pilha de saída
Chefe
Interrupção doc
Próximo
Próximo Instrução
Secretária
doc
Pilha de Empilhamento Registro/Status

doc entrada
Arquivo
Cópia
Anotação
doc Edição
Abstração
eliminação
do
irrelevante
e
amplificação
do
essencial
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.
Três abstrações de um carro
Registros Registros Registros

de oficina em casa Detran
Placa, conserto, Km/l, Identificação,

pagamento, manutenção, impostos, placa,
etc... etc... etc...
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
Conta corrente
deposito()
saldo
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
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
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)
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
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
Funcionário
Cozinheiro Garçom Serviços
Cardápio Caixa
Tipo
Prato Comanda
Preço
+AlteraPreço +CalculaConta
+GetPreço
Pedido Cliente
Classes - Fabrica de Objetos
Definição da classe
Objetos
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
Programas x Classes
Programas Classes
processos atributos
dados operações
Notação para Classes
class Fruta
{
int gramas;
int cals_por_gramas;
int total_calorias ()
{ return gramas * cals_por_grama; }
}
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
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
Classe Exemplo
class Exemplo
{
public static void Main (string args[])
{
Fruta AlgumaFruta = new Fruta();
Citros Laranja = new Citros();
AlgumaFruta.Descascar();
Laranja.Descascar();
Laranja.Espremer();
}
}
Encapsulamento
separa os
aspectos
externos de um
objeto dos
detalhes de
implementação
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.
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
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
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
Interfaces Públicas
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
Cliente Conta
nc debite
a1 b1
a2 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.
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);
}
}
Generalização
• Generalização identifica e define coisas
comuns em uma coleção de objetos
Moveis
Cadeiras Mesas Biros
Quadrada Redonda
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 individuais www.alvarofpinheiro.eti.br
Herança
Conta Sobremesa
ContaCorrente Poupança Bolo Sorvete
ContaEspecial BoloDeChocolate
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.
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.
Herança
Polígono
Figura Num de lados

vértices
Cor
posição central Círculo
raio
Herança (Java)
class Fruta
{
int gramas;
}
class Citros extends Fruta

{
void espremer () {/*............*/}
}
Todas as cítricas são frutas
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
Polimorfismo de Sobreposição
Fruta
Descasca()
Cítrica Não Cítrica

Descasca()
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
Polimorfismo
Ícone O tratamento do exibir() em

origem: Ponto Botão irá “overridar”
o exibir() do Ícone,
exibir()
Apesar de herdar o método
dele e poder reutilizá-lo, ele
implementará de outra
Botão maneira este método
exibir()
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
Polimorfismo (Java)
class Fruta
{
int gramas;
void descascar () {System.Out.Println (descasca uma fruta); }
}
class Citros extends Fruta

{
void espremer () {/*............*/}
void descascar () {System.Out.Println (descasca uma citro); }
}
Polimorfismo (Java)
class Exemplo
{
public static void Main (string args [ ] )
{
Fruta AlgumaFruta = new Fruta ();
Citros Laranja = new Citros ();
AlgumaFruta.Descascar ();
Laranja.Descascar ();
Laranja.Espremer ();
}
}
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
Associação – Agregação – Composição
Associação – Agregação – Composição
Notação: ------- <>------ <>---------
Empresa (todo) <> --------------- Depto. (parte)
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
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.
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
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
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
Herança Múltipla
Máquina Voadora Máquina Flutuadora
Hidroavião
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 () {/*..................*/}
}
MaquinaFlutuadora interface
Navio implementação
Lancha Veleiro etc.....
Windsurf
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 Navio

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
Acesso
GUI Interface Negócio Interface Dados
CLIENTE BD
Interfaces
– Estudo de Caso
– Arquitetura do software para Java
Interface Camada de
Gráfica Aplicação
insert Implementação
Interface delete
update
Comandos
Camada de SQL
BD
Acesso a Dados
Interfaces
– Estudo de Caso
– Arquitetura do software para Java
Interface Camada de
Gráfica Aplicação
insert Implementação muda

Interface delete
mantida update
Chamada stored
Camada de procedure
BD
Acesso a Dados
Abordagem Orientada a Objetos
INTERFACE
INTERFACE
Dados solicita serviço Dados
+ responde a +
solicitação Operações
Operações
Abordagem Orientada a Objetos
• 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
Unified
Modeling
Language
(UML)www.alvarofpinheiro.eti.br
Esquema da evolução
da
análise de sistemas
Métodos orientados a processos

simples e notação simples
Métodos orientados a dados

simples e notação simples Processos de desenvolvimento
Complexo (RUP)
Métodos orientados a objetos

Simples e notação complexa
Notação complexa
(UML)
1994
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
Evolução
da
Análise Orientada a Objetos
1980 1985 1990 1995 2000
Características
Comportamentos
UML
O caminho até a unificação
• Grady Booch manifiesta a necessidade de unificar critérios
• James Rumbaugh se une a Booch em outubro de 1994
• Ambos elaboram a versão 0.8 do Unified Method
• Em 1995 Ivar Jacobson completa o trio de “amigos”
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
UML
UML 1.4
UML 1.3
OMG Acceptance, Nov 1997
Final submission to OMG, Sep ‘97 UML 1.1
public First submission to OMG, Jan ´97
feedback
UML partners UML 1.0
Web - June ´96 UML 0.9
OOPSLA ´95 Unified Method 0.8
Other methods Booch method OMT OOSE
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
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
Modelos, Visões e Diagramas
A model is a complete
description of a system
from a particular
perspective Use Case
Use Case
Diagrams State
Use Case
Diagrams State
Diagrams
Diagrams Class
Diagrams
Diagrams
Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams
Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Models Component
Diagrams
Diagrams Diagrams
Scenario
Scenario
Diagrams
Statechart
Diagrams Component
Component
Diagrams
Diagrams Deployment
Diagrams
Diagrams
Desenvolvimento centrado em Modelos
Necessidade
dos Usuários Processo de Desenvolvimento de SW
Processo 1 Modelo 1 Processo n
Processo 2 Modelo 2 SW Novo/

Modificado
Desenvolver Software é transformar modelos

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 informais
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
modelagem
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.
Arquitetura dos Modelos
Visão de Visão de
desenho implementação
Estrutura Visão de Estrutura

(UC,Classes,Relações) casos de uso Componentes
Visão de Visão de
processos Distribuição
Escalabilidade Física (Topologia,

(threads) Implantação,comunicação)
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
Ferramentas da UML
• Modelo de requisito • Diagrama de casos de uso
• Modelo de estrutura • Diagrama de clases

• Diagrama de objetos
• Modelo de interação • Diagrama de sequências

• Diagrama de colaboracionais
• Modelo de comportamento • Diagrama de estados

• Diagrama de atividades
• Ferramentas de desenho • Diagrama de componentes

• Diagrama de distribuição
• Organização de modelo • Diagrama de pacotes
O Porquê destas ferramentas
Levantamento
Modelo de classes
Modelo de
Classe Classe
casos de uso
Modelo de comportamento
Modelo de interação
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”
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 usuarios
Estratégia de Levantamento
Funcionalidade Erros
desejada Exceções
Caminho
Base
Funcionalidade
não desejada
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
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
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
Casos de Uso
Ator
Emprestar
título
Devolver título
Usuário
Reservar título
Diagrama de Casos de Uso
Abrir o.s.
<<extend>>
Atendente de
1º nível
Fechar o.s.
<<extend>>
Cadastrar anamnese
Atendente de
1º nível
Realizar atendimento de 1º
nível
<<uses>>
Cadastrar satisfação do Consultar base de

solicitante conhecimento
USE CASE: ABRIR O.S.
Fluxo de dados principal:
O use case inicia quando o solicitante telefona para o ramal do Call Center para a
resolução de um problema. O atendente de 1o nível informa a matrícula do
solicitante. O sistema verifica se o solicitante está cadastrado. Se o mesmo estiver
cadastrado, o atendente informa o equipamento e então o sistema verifica se o
mesmo está em manutenção. Se o equipamento não estiver em manutenção, o
sistema verifica se o equipamento está em garantia. Se não estiver em garantia, o
sistema busca os softwares associados àquele equipamento e o atendente verifica
a necessidade de execução do processo de anamnese. O sistema sugere a
prioridade do atendimento a partir do nível do solicitante e o atendente de 1 o nível
confirma a prioridade do atendimento. Em seguida, informa a ocorrência do
problema. O atendente de 1o nível usa (consultar base de conhecimento). A
seguir, o atendente de 1o nível registra data, hora, tipo e dados obrigatórios da
O.S.
Fluxo de dados excepcional:

1. Se o solicitante não estiver cadastrado, o sistema não permite que o
atendimento seja realizado.
2. Se após a abertura da O.S., o atendente de 1o nível encontrou a solução do
problema, estende (fechar O.S).
3. Se o equipamento estiver em manutenção, o sistema não permite que o
atendimento seja realizado.
4. Caso o equipamento esteja em garantia e o tipo da O.S. não for de software, o
atendente de 1o nível registra data, hora, tipo, dados obrigatórios da O.S e
número do contrato, encaminhando-a para o coordenador de 2 o nível.
Diagrama de Classes
1..* 0..*
Aluno
matricula-se
pertence a
1 0..6
1..* 1..*
Curso Disciplina
0..*
ensina
1
Aspectos estáticos
Professor
Diagrama de Classes
• Diagrama utilizado para representar os aspectos

estáticos do Sistema
• Exibe um conjunto de classes e seus

relacionamentos
Diagrama de Seqüência
: Form : Solicitante
: Atendente de 1º
AbrirOS
nível
Abrir( )
Informar Matrícula Usuário( )
Validar Usuário( )
Usuário Não Cadastrado
Finalizar
Aspectos
Dinâmicos
Diagrama de Seqüência
• 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 Componentes
Aplicação Específica Software
Aplicação Geral
Gerencial Atendimento
Contratos Equipamento
Manutenção OS Ambiente de
Preventiva Conhecimento
Software Hardware Func_Help_Desk Defeito
MiddleWare
MTS
Relacionamento
System Software
Windows NT Oracle
entre os
Componentes
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
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;
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.
Diagrama de Distribuição
SERVIDOR DE DADOS SERVIDOR DE OBJETOS
Atendimento.DLL
Gerencial.DLL
WINDOWS NT
Equipamento.DLL
Contrato.DLL
ORACLE Ambiente de
OS.DLL Conhecimento
.DLL
Manutenção Func_Help_
Preventiva.DLL Desk.DLL
Associação
Defeito.DLL Hardware.DLL
dos componentes
ao Hardware Software.DLL
REDE
Micros Atendimento Micros Coordenação Micros Atendimento Micros Gerência

1º Nível 2º Nível
HD.EXE HD.EXE HD.EXE HD.EXE
Arquitetura
Acabamento
Instalações
Ambientação
Estrutura
Reboco
Base
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
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
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
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
Definição de Arquitetura
A atividade em Contexto:
Requisitos de
Qualidade Arquitetura de HW
Análise de Domínio Desenho de Desenho

Análise de Requisitos Arquitetura de de Arquitetura
Análise de Riscos Software de Hardware
Modificações Modificações
Arquitetura de SW
Restrições
Desenho Detalhado,
Codificação,
Integração e Testes
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
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
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
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
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
As 4 Visões
Componentes
Conectores
Configuração
Visão Conceitual
Restrições
de Execução
Componentes
Conectores Restrições de Módulos
Visão de
Configuração Execução
Módulos
Arquitetura de
Visão de Módulo
Hardware
Nova partição
de módulos
Módulos
Subsistemas Nova partição de módulos
Camadas
Entidades de
tempo de
execução
Visão de Código
Mudanças nas entidades
Construção de Código 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
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?
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
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?
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
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?
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
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?
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
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
Propriedades
Relembrando
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.
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
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
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
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

Arquitetura do Comércio Eletrônico
Camada Apresentação Servlet Interface Java
(Cliente) Servidor Internet
HTTP Windows Acesso SGDB

SERVLET Camada
HTML Browser 2000 JSERV Aplicação Dados
(web) Server Oracle
Inteligência
Request e Response da Infra-Estrutura
Internet Explorer do Browser
Formata HTML de
Aplicação SGBD
Netscape Midware p/ interação Resposta
HotJava com Servelets
• Passos do projeto de arquitetura
• Estruturação do sistema
• Modelagem de controle
• Decomposição modular
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
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
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
• 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
• 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
• 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
separado
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 software
• Exemplo de Arquitetura
Interface
Gráfica
Comunicação
Processamento de Cadastramento de
Pedidos Informações
Acesso a Dados
• 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
Cliente 1 Cliente 2 Cliente N
Rede (LAN, WAN ou Internet)
Servidor 1 Servidor 2 Servidor N
– 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)
–Visão client-server da arquitetura (visão
mais física dos componentes de software)
GUI
Rede Local TCP/IP
Servidor de Servidor de
Dados Aplicação
O Modelo Multi-Camadas
Componentes de Apresentação
Windows
Browser NetPC Windows Other
Terminal
Componentes de lógica de Aplicação
DADOS: SQL, Mail, ISAM, Host, não-Estruturado
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 hierarquia

de generalização/especialização
• Disparar mensagens para uma classe (que é

o papel de um programa principal), e iniciar a
execução de um programa
– 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 funcionamento
do mesmo
– Este detalhamento deve levar em

consideração a filosofia de arquitetura
adotada (em camadas, client-server por
exemplo)
– Devem ser observadas situações de reuso

– Exemplo: sistema de vendas de livros
– Detalhamento Módulo de Cadastros + 1camada
GUI Cliente Comm Servidor Comm

Cad Livros Cadastros Cadastros
GUI
Cad Autores Cadastro Cadastro
Autores Livros
Acesso a Dados Autores Acesso a Dados 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
– Detalhamento do módulo de importação de
clientes
Servidor TCP JAVA
Servidor Comm Entrada Clientes
Processador Arquivos Clientes
Acesso a Dados Driver

SGBD
Clientes JDBC
–Identificação das principais interfaces para o
módulo de processamento de pedidos
GUI Cliente Comm Servidor Comm
Proc Pedido Proc Pedido Proc Pedido
Manutenção
Pedidos
Acesso a Dados Pedidos Acesso a Dados Livros

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 o
cliente e o servidor;
Duas Camadas
Servidor Cliente
Arquitetura em duas camadas
• 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
3 Camadas
Servidor
Servidor de Cliente
Aplicação
Arquitetura em 3 camadas
• 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
• 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.
Cliente
Arquitetura
(GUI)
Negócios
Acesso a Dados
BD
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;
Acesso
GUI Interface Negócio Interface Dados
CLIENTE BD
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.
Padrões
de Projeto
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.
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.
Padronização
Através do padrão adotado estaremos
portanto disponibilizando:
• Programas estruturados e com menos

riscos de erro;
• Programas desenvolvidos mais

rapidamente;
• Programas mais fáceis de alterar, sem risco

de comprometimento da estrutura original;
• Programas testados integralmente e em

tempo menor.
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.
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.
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.
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.
Regras
• Aumento de Produtividade
Prover direções na melhoria do desenvolvimento de código.
• Melhorias sem impacto

Permite que design e codificação mudem com o mínimo de
impacto no código.
• Abstração
O uso de abstração permite uma mudança transparente.
• Implementações Late Binding

Permite que tipos de dados sejam resolvidos em tempo de
run-time.
• Aumento de Qualidade
Permite o aumento de qualidade como um código mais
legível. Legibilidade implica em uma taxa baixa de erros.
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.
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
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.)
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
GRASP
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).
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
GoF
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)
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
• 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
• 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
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.
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.
Qual o escopo de Padrões?
Scope Class Creational Structural Behavioral
Factory Method Adapter Interpreter

Template Method
Object Abstract Factory Adapter Chain
Responsibility
Builder Bridge Command
Prototype Composite Iterator
Singleton Decorator Mediator
Façade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
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]
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).
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.
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
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.
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.
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.
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.
Interface
Realiza a
interface
Clonável
Hierarquia de
classes
Subclasses de
Documento
“Instâncias
prototípicas”
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.
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.
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]
• Adapter permite que um objeto cliente utilize serviços de outros
objetos com interfaces diferentes por meio de uma interface única.
Ponto único de
acesso
Utiliza métodos
de classes
distintas por
uma interface
única
Subclasses
distintas
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.
• 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étodo
DesenhaBorda() que por sua vez realiza "n" chamadas ao método DesenhaLinha() da classe
XWindowImpl ou MSWindowImpl, dependendo da plataforma desejada.
Interfaces
Implementação
das Interfaces
Hierarquias
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.
• Composite o diagrama abaixo mostra a estrutura de classes que
permite que clientes tratem de modo uniforme tanto objetos individuais
quanto suas composições.
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.
Decorator definimos uma subclasse de ElementoDeDocumento chamada MonoElementoDeDocumento
MonoElementoDeDocumento é uma classe abstrata para todos os ElementoDeDocumento de
embelezamento
Interface
Classe abstrata
Classe abstrata
para
embelezamento
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.
Facade define uma interface de mais alto nível que torna um subsistema de mais fácil
uso
Classe de mais
alto nível
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.
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.
Proxy provê um ponto de atendimento para que outro objeto possa controlar o acesso ao
primeiro
Classe que
provê ponto de
atendimento
Classe que
realiza a
interface Classe
controlada
Classe que
controla outra
classe
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.
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.
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]
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.
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
Pode ser
atendida de
várias formas
Envia
solicitação
parametrizada
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 Command
deve 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.
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.
Iterator provê uma forma de acessar seqüencialmente os elementos de um agregado de objetos, sem
expor a sua representação interna
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.
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.
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.
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
• 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.
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.
State permite
que um objeto
altere seu
comportamento
quando seu
estado interno
se modifica e o
objeto parecerá
ter mudado de
classe
• 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.
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
• 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.
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.
• 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.
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.
• 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.
Qualidade
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
Qualidade
Motivação
• Diminuição do custo de correção de defeitos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Conceitos Básicos
Qualidade
Custo da Qualidade
Qualidade
Qualidade de Software
Qualidade
Princípios da Qualidade
Qualidade
Software
Qualidade
Produto de Software
Qualidade
Produto de Software
Qualidade
Produto de Software
Qualidade
Produto de Software
Qualidade
Processo de Software
Qualidade
Processo de Software
Qualidade
Barreiras
Qualidade
Iniciando
Qualidade
Modelo de Melhoria PDCA
Qualidade
Modelo de Melhoria IDEAL
Qualidade
Modelo de Melhoria
Qualidade
Metodologia
Qualidade
Modelo a ser Seguido
Qualidade
Modelo a ser Seguido
Qualidade
Escopo
Qualidade
Equipe
Qualidade
Equipe
Qualidade
Equipe
Qualidade
Auditorias
Qualidade
Auditorias
Qualidade
Auditorias
Qualidade
Auditorias
Qualidade
Auditorias
Qualidade
Auditorias
Qualidade
Auditorias
Qualidade
Auditorias
Qualidade
SQA
Estimativas
"Não se pode controlar
aquilo que não se
consegue medir.“
Tom de Marco
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
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...
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 ?
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
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, ...
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
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
Técnicas de
Estimativas
WideBand Delphi
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
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”
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
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.
Estimativa
Planejamento
Reunião de
Kick-off
Preparação
Individual
Reunião de
Estimativas
Organização dos
resultados
Revisão dos
resultados finais
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
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
Estimativa
Planejamento
Reunião de
Kick-off
Preparação
Individual
Reunião de
Estimativas
Organização dos
resultados
Revisão dos
resultados finais
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
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
Estimativa
Planejamento
Reunião de
Kickoff
Preparação
Individual
Reunião de
Estimativas
Organização dos
resultados
Revisão dos
resultados finais
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
Wideband Delphi –
Preparação Individual
 Padrão de formulário para registro da lista de atividades
e estimativas
Tarefas Iteração Iteração Iteração Iteração
#1 #2 #3 #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
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
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
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
Estimativa
Planejamento
Reunião de
Kickoff
Preparação
Individual
Reunião de
Estimativas
Organização dos
resultados
Revisão dos
resultados finais
Estimativas
• O moderador coleta as estimativas individuais de cada
participante e gera um gráfico a partir das mesmas
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
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
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
Estimativas
 Gráfico de estimavas mostrando os resultados de
três iterações de uma sessão de Wideband Delphi
Estimativa
Planejamento
Reunião de
Kickoff
Preparação
Individual
Reunião de
Estimativas
Organização dos
resultados
Revisão dos
resultados finais
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
Estimativa
Planejamento
Reunião de
Kickoff
Preparação
Individual
Reunião de
Estimativas
Organização dos
resultados
Revisão dos
resultados finais
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
Estimativa
Os participantes devem revisar a lista final de forma a

garantir que a mesma é a mais completa possível
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
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
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
Técnicas de
Estimativas
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
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.
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
• 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
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

ambientais
Calcular pontos de
casos de uso ajustados
• 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.
• Tabela de peso dos atores
Tipo do ator Descrição Peso
Interface de um
Simples 1
sistema
Interface interativa
Médio ou via protocolos de 2
comunicação
Complexo Interface gráfica 3
• 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.
• 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

de uso


técnicos

ambientais
Calcular pontos de
• 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
• A tabela abaixo lista o fator e a classificação de cada tipo de
caso de uso.
Tipo do Caso de
Descrição Peso
Uso
<= 3
Simples transações 5
/cenários
De 4 a 7
Médio transações 10
/ cenários
Mais do que 7
Complexo transações 15
/ cenários
• 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
• 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
Tipo do Caso de
Descrição Peso
Uso
Menos do que 5
Simples 5
classes de análise.
De 5 a 10 classes de
Médio 10
análise.
Mais do que 10 classes
Complexo 15
de análise.
• 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)

de uso


técnicos

ambientais
Calcular pontos de
• 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
desenvolvimento
Fator dos atores + Fator dos casos de uso = UUCP

de uso


técnicos

ambientais
Calcular pontos de
• É 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)
“Fatores Técnicos”
Descrição do Fator Peso padrão do fator
Numero do (para o método UCP)
fator
T1 Sistema distribuído 2
T2 Objetivos de tempo de resposta e 1
capacidade de taxa de transferência
T3 Alta eficiência para o usuário final 1
(sistemas on-line)
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 1
externos

de uso


técnicos

ambientais
Calcular pontos de
• 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
“Fatores Ambientais”
Número do Fator Descrição do Fator Peso Padrão
F1 Familiar com o processo de 1.5

desenvolvimento
F2 Experiência no domínio da 0.5
aplicação
F3 Experiência em Orientação a 1
Objetos
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 -1
complexa
• 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 experts
e 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
• 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)

de uso


técnicos

ambientais
Calcular pontos de
• 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
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;
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.
GQM
Goal Question
Metric
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.
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.
Significado de GQM
• Goal
– Quais são as metas/objetivos?
• Question
– Quais questões se deseja responder?
• Metric
– Quais métricas poderão ajudar?
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.
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).
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.
GQM – Estrutura Hierárquica
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.
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.
Exemplo
Decidir quando o software
estará pronto para a implantação
Qual é o requisito Qual é a atual Quais são as

de estabilidade? confiabilidade? métricas temporais?
Pessoas
Tamanho de Defeitos Casos de Horas de Horas
disponíveis por
código descobertos testes utilização
www.alvarofpinheiro.eti.br de teste
dia para testes
GQM - Fases
1. 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.
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.
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.
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)!
CMMi
Capability Maturity Model
e Rational Unified Process
Relembrando os níveis de
maturidade...
Optimizing
5 Foco na melhoria do
processo
Quantitatively
Managed
4 Processo medido e
controlado
Defined
3 Processo proativo e
definido para a
organização
Managed
Processo definido para
2 o nível de projetos e
frequentemente reativo
Performed
1 Processo imprevisível,
pouco controlado
Relembrando ...
Um Processo Gerenciado
Planejado Pessoas capacitadas
Executado de acordo
com políticas
Stakeholders
relevantes
Monitorado e
Controlado Aderência
é verificada
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”.
Motivação
Standish Group
Pesquisa realizada com 30.000 projetos de empresas

americanas, de pequeno, médio e grande porte.
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.
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.
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.
Níveis de Maturidade
Processo
Otimizando (5)
de
Melhoria
Contínua
Gerenciado (4) Processo
Previsível
Definido (3) Processo

Padronizado e
Consistente
Repetível (2) Processo
Disciplinado
Inicial (1) Processo

Caótico
Estrutura do CMM
indicam
Níveis de
Capacitação do Maturidade
Processo
contêm
alcançam Áreas-chave de
Metas Processo
Organizadas pelas
abordam Características Compromisso

Implementação
Comuns são Habilitação
ou
Atividade
institucionalizaçã
Medição e análise
o
contêm Verificação
descrevem Práticas-chave
Atividades ou
infra-estrutura
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
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.
KPA Planejamento de
Projetos
Metas:
• Documentar as estimativas de software a
serem usadas no planejamento e
acompanhamento do projeto.
• Planejar e documentar as atividades e os
compromissos do projeto de
desenvolvimento de software.
• Obter a concordância dos grupos e das
pessoas envolvidas quanto aos respectivos
compromissos relacionados ao projeto de
KPA Supervisão e
Acompanhamento de
Projeto
Metas:
• Acompanhar os resultados e desempenhos
reais confrontando-os com o plano de
• 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.
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.
KPA Garantia da Qualidade
Metas:
• Planejar atividades de GQS
• Verificar conformidade das atividades e
produtos de software.
• Informar aos envolvidos as atividades e
resultados de GQS.
• Encaminhar à gerência questões de não-
conformidade não resolvidas no âmbito do
projeto de software.
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.
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).
• 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.
• 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.
• 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.
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
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)
In Out
• 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
Áreas de Processo - Nível 3
• Desenvolvimento dos Requisitos Optimizing

• Solução Técnica
• Integração do Produto
• Verificação Antigas Quantitatively
• Validação do CMM Managed
• Foco no Processo da Organização
• Definição do Processo da Organização
• Treinamento Organizacional Defined
• Gerenciamento Integrado de Projetos
• Análise de Decisão e
Resolução Managed
• Gerenciamento de Riscos
• Gerenciamento Integrado de Fornecedor
• Ambiente Organizacional para
Performed
Integração
• Integração de Equipes
As áreas de engenharia do
nível 3
Requisitos
REQM
Requisitos do produto e requisitos dos

componentes do produto
Soluções alternativas
RD Requisitos TS PI Cliente
Componentes do produto, produtos de trabalho

Relatórios de verificação e validação
Ver Val
Necessidades do cliente
Desenvolvimento dos
Requisitos
Produzir e analisar requisitos do cliente,
do produtos e dos componentes
• 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
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
Solução Técnica
Projetar, desenvolver e implementar soluções para

os requisitos. Envolve a escolha da melhor solução
para atender aos requisitos
• 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
Solução Técnica
– 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.
Integração do Produto
Montar o produto a partir dos componentes desenvolvidos,

garantir que o produto integrado funciona de
forma adequada e pode ser entregue
• 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
Integração do Produto
– 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
V&V – Verificação e Validação
Estamos construindo o produto de forma correta?

Estamos atendendo aos requisitos especificados?
Garantir que os produtos de trabalho selecionados

atendem aos requisitos especificados
X
Estamos construindo o produto correto?
Estamos atendendo às necessidades operacionais?
Demonstrar que o produto ou componente atende
a intenção de uso quando implantado no ambiente
planejado
V&V – Verificação e Validação
Verificação Validação
• SG1: Preparar para • SG1: Preparar para

verificação validação
– Garantir que os produtos – Garantir que os produtos
estejam prontos estejam prontos para
• SG2: Realizar peer reviews validação
– Nos produtos de trabalho • SG2: Validar o produto ou
selecionados componentes do produto
• SG3: Verificar produtos de – O produtos e/ou seus
trabalho selecionados componentes são validados
para garantir que estão
– Os produtos de trabalhos adequados para o uso no
são verificados com base ambiente operacional
nos requisitos especificados apropriado
As demais áreas serão explicadas de

forma breve...
Foco no processo da
organização & Definição do
processo da organização
Planejar e implementar a melhoria do processo
organizacional baseada nos pontos fortes e fracos
existentes no processo
• SG1: Determinar oportunidades Estabelecer e manter o processo
de melhoria de processos (assets do processo) da organização
– Periodicamente os pontos fracos
e oportunidades de melhoria do  SG1: Estabelecer o processo (e
processo são identificados seus assets) da organização
• 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
Treinamento Organizacional
Desenvolver e manter as habilidades e conhecimentos das
pessoas para que elas possam executar seus Papéis de
forma efetiva e eficiente
• 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
Gerenciamento Integrado de
Projetos
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
• 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
Gerenciamento de Riscos
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
• 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
Gerenciamento Integrado de
Fornecedor
Identificar proativamente produtos e/ou componentes
que possam ser usados para satisfazer requisitos do projeto
e gerenciar os fornecedores selecionados de forma cooperada
• SG1: Analisar e selecionar fontes de produtos /

componentes
• SG2: Coordenar o trabalho com os fornecedores

– Garantir que o contrato será executado de forma apropriada
Análise de Decisão e
Resolução
Analisar possíveis decisões através de um processo
de avaliação formal que avalia alternativas identificadas
com base em critério estabelecido
• SG1: Avaliar alternativas

– Decisões são baseadas em uma avaliação de alternativas
através de um 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
Á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
• 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
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
• 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
In Out
• Progresso e problemas são medidos

• A gerência tem bases objetivas para tomada de decisão
Nível 4: Endereçando as
causas especiais de variação...
Variações
especiais
% Esforço Organizacional
160%
140% % Esforço
% Esforço Org.
120% Organizacional
100% Goal
80%
60%
40% UCL
20%
0%
LCL
Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez
• Performance do Processo Organizacional
• Gerenciamento Quantitativo de Projetos Optimizing
Quantitatively
Managed
Defined
Managed
Performed
Performance do Processo
Organizacional
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
• SG1: Estabelecer Baselines de

Performance e Modelos Estatísticos
Gerenciamento Quantitativo
de Projetos
Gerenciar quantitativamente os processos definidos do projeto

a fim de alcançar os objetivos de qualidade e performance
do projeto
• 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
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
Nível 5 – Otimizando
In Out
“A Melhoria de processo contínua e “mensurável” é um estilo de

vida...”
Nível 5: Endereçando as
causas comuns de variação...
Variações
Comuns
% Esforço Organizacional
140%
120% % Esforço
% Esforço Org.
100% Organizacional
80% Goal
60%
40% UCL
20%
0%
LCL
Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez
• Desenvolvimento e Inovação Organizacional
• Análise Causal e Resolução Optimizing
Quantitatively
Managed
Defined
Managed
Performed
Desenvolvimento e Inovação
Organizacional
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.
• 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
Análise Causal e Resolução
Identificar as causas dos defeitos e de outros problemas e tomar
ações corretivas para prevenir que os mesmos voltem a
ocorrer no futuro
• 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
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
• 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
• 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
• 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!!!
Gerência de
Projetos
Áreas de resultados
Clientes
Fronteira
Organização
Recursos
Processos
Produtos e Serviços
Atendimento
Necessidades
Áreas de resultados – de fora para dentro
Impactos: a mudança da
realidade da clientela
Clientes
Fronteira
Organização
Recursos
Processos
que são gerados pelos...
Atendimento
Necessidades
são atendidas através de...
Cadeia de resultados
Clientes
Fronteira
P
Organização
R
Recursos
Processos
O
J
E
T
Atendimento O
Necessidades
ESTRATÉGIA
É uma definição de um futuro desejado e dos meios
eficazes para alcançá-lo
(Ackoff)
Aonde
A melhor maneira pretendemos
de evoluir de “B” para “A” chegar
(A)
• Programas
• Projetos Portfólio
Onde • Outros trabalhos
estamos?
(B)
Todas as empresas que estão no mundo de negócios

de hoje possuem um portfólio de projetos.
GESTÃO DE PORTFÓLIO
É a PONTE, que liga as

estratégias organizacionais
com os projetos.
Processos mais eficazes de gerenciamento de portfólio
O novo padrão do PMI

The Standard for Portfólio Management
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
SINAIS DE PROBLEMAS NA GESTÃO DE
PORTFÓLIOS
• Não há um entendimento claro e formal
1 de como os PROJETOS estão conectados à
ESTRATÉGIA da organização.
• Gerentes de Projetos e Gerentes

2 Funcionais estão permanentemente
“BRIGANDO” por recursos.
3 • As PRIORIDADES estão freqüentemente

mudando.
• Projetos são aprovados

4 INDEPENDENTEMENTE de haver ou não
RECURSOS disponíveis.
SISTEMÁTICA DE GESTÃO
Assegurar que a coleção de projetos escolhidos esteja alinhada
com os objetivos da organização.
DEFINIÇÃO
Portfólio
Portfólio Projetos Programas
Programas Projetos Programas Projetos Outros trabalhos
Projetos 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
Portfólio
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.
SEPARANDO CONCEITOS...
SUCESSO NO GERENCIAMENTO
Gerenciamento de Gerenciamento de
PROJETOS PORTFÓLIO
Cliente satisfeito com os resultados Objetivos estratégicos alcançados
Prazos cumpridos conforme o acordado Redução do ciclo de vida dos projetos
Ausência de desvios no orçamento Retorno adequado dos investimentos
Produto dentro das especificações Rentabilidade do portfólio de acordo

técnicas com a esperada
COMPARANDO
PROJETOS PROGRAMAS PORTFÓLIO

Escopo mais restrito e Escopo mais amplo que pode Escopo de negócios que
com entregas específicas. mudar para atingir a muda com as metas
expectativa da organização. estratégicas da organização.
Os gerentes tentam Os gerentes têm expectativa Os gerentes monitoram as
manter o mínimo de de mudanças e até mesmo mudanças num ambiente
mudança. promovê-las. amplo.
O sucesso é medido por O sucesso é medido em termos O sucesso é medido em
estar dentro do de Retorno sobre o termos de desempenho
orçamento, no prazo e Investimento (ROI), novas agregado nos componentes
por produtos entregues capacidades e benefícios do portfólio.
conforme especificação. entregues.
Os gerentes monitoram e Os gerentes monitoram Os gerentes monitoram o
controlam tarefas e o projetos e o andamento do desempenho agregado e os
trabalho de produção dos trabalho ao longo da estrutura indicadores de valor.
produtos do projeto. de governança.
CONTEXTO ORGANIZACIONAL
Quais componentes poderiam

ser alocados
propositadamente no
portfólio?
Fonte: The Standard for

Portfólio Management - PMI®
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.
“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

VISÃO GERAL DOS PROCESSOS
Processos de Gerenciamento do Portfólio
Plano Estratégico atual Grupo de Processos de Grupo de Processos Processos dos

da Organização Alinhamento de Monitoramento e Componentes
Controle
Plano Estratégico Identificação Priorização

Execução dos
•Objetivos estratégicos componentes
•Metas Categorização Balanceamento Revisão do
do Portfólio Portfólio e
•Critérios de Comunicação
desempenho
Avaliação
•Definição de Autorização
capacidade
Seleção
não Mudança
Estratégica
sim
PROCESSOS DE ALINHAMENTO
Identifi- Categori- Priori- Balancea- Autori-

Avaliação Seleção
cação zação zação mento zação
 Identificação do componente
– Número, nome, descrição, etc.
Componentes  Objetivos estratégicos apoiados
inventariados e
 Benefícios quantitativos e qualitativos
documentados
 Recursos requeridos
 Cliente
 Patrocinador
 Stakeholders
 Cronograma
 Resultados tangíveis
 Riscos

Componentes Crescimento das vendas

combinados em Aumento da participação de mercado
grupos de negócio Melhoria de eficiência ou de processos
relevantes Obrigações regulamentares
conforme o plano Redução de riscos empresariais
estratégico
Satisfação do cliente
...
Validar com os stakeholders

Posicionamento de cada Critérios de avaliação

componente dentro do  Negócios
portfólio
 Melhoria de eficiência ou de processos
 Finanças
 Riscos
 Marketing
 Foco técnico
...

Ranqueamento
multicritérios
 ROI
 Custos
 Duração
 Riscos
 Recursos
 Preço
 Promoção


Comparação gráfica baseada em dois critérios
Critério 1
Ir em frente
alto
Cuidado
médio Finalizar
baixo
baixo médio alto Critério 2

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.

Lista priorizada de componentes

potenciais do portfólio, todos
listados dentro de suas categorias
estratégicas específicas.

Portfólio Management - PMI® www.alvarofpinheiro.eti.br

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.

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 

Um método gráfico
O tamanho da bolha reflete
Investimentos para Unidade de Negócio

o custo do projeto. Investimentos nas Categorias
1 2 3 4 5
As cores das bolhas
1 1
representam critérios. Unidades de Negócio
As categorias 4 e 5 contam 2 2
com apenas dois projetos. 3 3
A unidade de negócio 1 4 4
possui somente um projeto 5 5
na categoria de
6 6
investimentos 2.
1 2 3 4 5
Cada critério parece ter Projetos por Categoria
uma correlação direta com
a unidade de negócio.

• 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. Plano formal de comunicações para
o gerenciamento do portfólio
MONITORAMENTO E CONTROLE
Processos de Gerenciamento do Portfólio
Plano Estratégico atual Grupo de Processos de Grupo de Processos Processos dos

da Organização Alinhamento de Monitoramento e Componentes
Controle
Plano Estratégico Identificação Priorização

Execução dos
•Objetivos estratégicos componentes
•Metas Categorização Balanceamento Revisão do
do Portfólio Portfólio e
•Critérios de Comunicação
desempenho
Avaliação
•Definição de Autorização
capacidade
Seleção
não Mudança
Estratégica
sim
REVISÃO DO PORTFÓLIO E COMUNICAÇÃO
Informações consistentes
e precisas
Visão, Missão e
Plano Estratégico
Planejamento
Revisão do desempenho
Estratégico do Portfólio
Identificação,
categorização,
Operações Gerenciamento avaliação, seleção,
Solicitações de
Programas e
do Portfólio priorização,
balanceamento e
Projetos autorização de
componentes do
Portfólio
Gerenciamento
Revisão do desempenho
de Programas e de Programas e Projetos
Entregas concluídas Projetos
para operações
Processos 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
Revisões atuais e futuras? Novo critério
A organização será capaz de competir em
diferentes cenários futuros? O portfólio de
projetos inclui alternativas?
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.
DEFINIÇÃO
Portfólio
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.
DEFINIÇÃO
Portfólio
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.
COMPARANDO
PROJETOS PROGRAMAS PORTFÓLIO

Escopo mais restrito e Escopo mais amplo que pode Escopo de negócios que
com entregas específicas. mudar para atingir a muda com as metas
expectativa da organização. estratégicas da organização.
Os gerentes tentam Os gerentes têm expectativa Os gerentes monitoram as
manter o mínimo de de mudanças e até mesmo mudanças num ambiente
mudança. promovê-las. amplo.
O sucesso é medido por O sucesso é medido em termos O sucesso é medido em
estar dentro do de Retorno sobre o termos de desempenho
orçamento, no prazo e Investimento (ROI), novas agregado nos componentes
por produtos entregues capacidades e benefícios do portfólio.
conforme especificação. entregues.
Os gerentes monitoram e Os gerentes monitoram Os gerentes monitoram o
controlam tarefas e o projetos e o andamento do desempenho agregado e os
trabalho de produção dos trabalho ao longo da estrutura indicadores de valor.
produtos do projeto. de governança.
UM EXEMPLO DO GOVERNO
DE
Visão de Futuro
MINAS
Tornar Minas
Gerais o
melhor Estado
Opções para se viver
Estratégicas
10
31 Objetivos
Programas Estratégico
Estruturadore s
s
Artigo publicado na revista Mundo

PM www.alvarofpinheiro.eti.br
UM EXEMPLO DO GOVERNO DE MINAS
Programas estruturadores (exemplos)

2 Corredores Radiais de Integração e
Desenvolvimento
Reduzir o “custo de transporte” e aumentar...
Programas
5 Saneamento Básico: Mais Saúde para Todos
Ampliar a cobertura dos sistemas públicos...
10 Modernização da Receita Estadual Projetos

Alavancar as fontes de receita do Estado...
12 Regionalização da Assistência à Saúde Atividade

Adequar a oferta de serviço à demanda... s
27 Arranjos Produtivos Locais
Desenvolvimento dos arranjos produtivos...
Pilares para o gerenciamento
GP
ORGANIZACIONAL
INFORMATIZAÇÃO
METODOLOGIA
ESTRUTURA
COMPETÊNCIAS
Aumento do nível de execução dos projetos
Previsibilidade e controle sobre os resultados
Benefícios
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.”
GERENCIAMENTO DE BENEFÍCIOS
Programa  Avalia o impacto
organizacional do
Benefícios discretos programa
 Avalia as
interdependências dos
Benefícios benefícios
A1...n
 Designa responsabilidades
Projeto A pelos benefícios reais
Projeto B
Benefícios
coordenados
Gestão do
Benefício Benefícios do
Projeto C Programa
s Programa
1...n
Projeto D
Projeto E
Benefícios
E1...n

Program Management - PMI®
GERENCIAMENTO DE PROGRAMAS NO
PLANEJAMENTO ESTRATÉGICO
Visão estratégica
Mobilização Objetivos
Opções estratégicasPortfólio estratégico
estratégicos
Programas
Infraestrutura Entrega de Conclusão
Set up Pre- Set up do Operações
gerencial e técnica benefícios do Transição
Programa Programa regulares
para o Programa incrementais Programa
Projetos
CICLO DE VIDA DO PROGRAMA
Set up Infra-estrutura Entrega de benefícios incrementaisConclusão Transição Operações

Programa gerencial e técnica do regulares
para o Programa Programa
Custo
Perfil de Entrega de
Custos benefícios
Tempo
CICLO DE VIDA DO PROGRAMA
Governança do Programa
Fase 1 G1 Fase 2 G2 Fase 3 G3 Fase 4 G4 Fase 5 G5
• 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
TEMAS DO GERENCIAMENTO DE
PROGRAMAS
• Gerenciamento de
1 benefícios
• Gerenciamento das partes

2 interessadas do programa
3 • Governança do programa
GERENCIAMENTO DE BENEFÍCIOS
Identificação Análise Planejament Realização Transição
o
Identificar e Derivar e Estabelecer Monitorar Consolidar
qualificar os priorizar plano de componentes benefícios
benefícios de componentes realização de coordenados
negócios benefícios
Derivar Estabelecer Manter registro Transferir

métricas de monitoramento dos benefícios responsabilidad
benefícios de benefícios e para operação
Mapear Reportar
benefícios no benefícios
Plano do
Programa
GERENCIAMENTO DAS PARTES
INTERESSADAS
“São indivíduos ou organizações cujos interesses podem ser
afetados pelos resultados do programa, positiva ou
negativamente”.
 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
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.
PROCESSOS DE GERENCIAMENTO
Iniciação Define
DE e autoriza o programa ou um projeto dentro do
PROGRAMAS
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 Monitora o programa e projetos associados em

controle 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.

Alvarofpinheiroesw 141126221524 Conversion Gate01 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Alvarofpinheiroesw 141126221524 Conversion Gate01 PDF

Título original:

Enviado por

Direitos autorais:

Formatos disponíveis

https://www.facebook.

Etapas do ciclo de desenvolvimento

2,5 Análise e Desenho

• Em 1998 o Standish Group levantou 365 companhias e 8000

• Melhora no êxito dos projetos: 16% en 1994 vs. 26% em

• Causas: participação dos usuários, suporte executivo, claro

Standish Group, 1999

O termo Engenharia de Software

Desta forma, a idéia foi propor a

Dentre os fatores responsáveis

As metodologias ágeis incentivam

Para ser realmente considerada

O problema é como receber,

Desta forma existem maiores

Dentre as várias metodologias

Um exemplo de uma metodologia

O resultado foi a criação da

Software executável ao invés de

Colaboração do cliente ao invés de

Respostas rápidas a mudanças ao

É uma metodologia ágil para

O modelo em Cascata dominou a

O pesquisador, Tom Gilb,

• Um processo define quem faz o que,

• Especificar quais artefatos devem ser

• Direcionar as Atividades individuais e de

• Oferecer critérios para o gerenciamento

• Software Process Automation

RUP é um framework de processo centrado na

Outra metodologia ágil que

Seu objetivo é fornecer um

 Produzir um sistema susceptível a mudanças de

A Scrum apresenta uma

A idéia principal da Scrum é que o

A Scrum divide o desenvolvimento em

Na Scrum existem reuniões de

 Times de desenvolvimento pequenos (por volta de 6);

• Apresentação do produto à clientes e/ou diretores de marketing

• Produto pode até ser lançado no mercado

 Gerenciamento de riscos Controles

 Revisões frequentes / diárias Backlog

 Divisão de responsabilidades  Ausência de práticas de

Não se pode comparar XP com

Entretanto, diferente dos processos

1. O problema a ser tratado é

Dentre as principais diferenças da

Em XP a modelagem não deve ser

Em XP assume-se que o sistema

Qual a vantagem em usar XP em

XP é baseado em sistemas que sofrem

O primeiro projeto a usar XP foi o

A maioria das regras da XP causa

As regras, práticas e valores da

A XP baseia-se nas 12 práticas.

São as descrições de um software

O programa desenvolvido pelo método

É fundamental a participação do cliente

• Criada por Alistair Cockburn

 Método ágil e adaptativo;

 Desenvolver um modelo compreensível (Develop

 Modelagem de objetos de domínio (Domain Object Modeling)

Estudo das possibilidades (Feasibility