Fundamentos da Engenharia de Software

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
Análise
56%
Programação
7%
Desenho
27%
Outros
10%

Projetos
Custo de correção dos erros
Custo
Incremento de
100 a 1000 vezes
Etapas do ciclo de desenvolvimento

Projetos
Incremento do custo dos erros
Captura de requisitos
Análise e Desenho
Codificação
Teste Unitário
Prova de Aceitação
Manutenção
1
2,5
5
10
25
100
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
40
30
20
10
0
até $750m
$750m a $1.5M
$1.5M a $3M
$3M a $6M
$6M a $10M
+ de $10M
Porcentagem de
êxito (%)
Standish Group, 1999
Tamanho do projeto ($)

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:
ADM (Advanced
Development Methods)
+
VMARK Software
METODOLOGIA:
Gerenciamento, manutenção
e desenvolvimento de softwares:
simples e pequenos
grandes e complexos
PROCESSO:
Ágil
Empírico
Incremental
BASE P/ SCRUM:
Técnicas e tools OO

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
• Relativamente curta
• Design da arquitetura do sistema
• Estimativas de datas e custos
• Criação do backlog
– Participação de clientes e outros departamentos
• Levantamento dos requisitos e atribuição de prioridades
• Definição de equipes e seus líderes
• Definição de pacotes a serem desenvolvidos
Backlog

Scrum
Fases
Sprint
• Processo Empírico
• Cada time recebe uma parte do backlog para
desenvolvimento
– O backlog não sofrerá modificações durante o Sprint
• Duração de 1 a 4 semanas
• Sempre apresentam um executável ao final
Fonte: Mountain Goat Software

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

Qualidade, Gerenciamento e Testes
 Passos e papéis bem definidos
 Gerenciamento de riscos
 Revisões frequentes / diárias
 Definição de padrões
 Realização de testes
 Elaboração de documentação
 Grupo QA
Controles
Backlog
Release/Melhoria
Mudanças
Problemas
Soluções
Issues
Scrum

Conclusões
 Divisão de responsabilidades
 papéis bem definidos
 Processo ágil e flexível
 inúmeras mudanças no decorrer do
projeto
 Foco em controle/gerenciamento
 minimiza risco
 maximiza qualidade
 Times pequenos
 Colaboração
 Ausência de práticas de
(técnicas e notações) e
tools
 Necessidade de
associação com outras
metodologias e tools
(XP, GNATS)
 Dificuldade na
implementação de
mudanças
Scrum

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.

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 entrada
pilha de saída
chefe
docs
secretária
doc
doc
arquivo
docs

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)
Chefe
Pilha de saída
Próximo
Secretária
Arquivo
Pilha de
entrada
doc
doc
doc
doc
doc
Cópia
Anotação
Edição
Próximo
Instrução
Interrupção
Instrução
Empilhamento Registro/Status

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
Placa, conserto,
pagamento,
etc...
Km/l,
manutenção,
etc...
Identificação,
impostos, placa,
etc...
Registros
de oficina
Registros
em casa
Registros
Detran

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
Tipo
Prato
Preço
+AlteraPreço
+GetPreço
Caixa
Comanda
+CalculaConta
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

Herança
Conta
ContaCorrente Poupança
ContaEspecial
Sobremesa
Bolo Sorvete
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
Figura
Polígono
Círculo
Cor
posição central
Num de lados
vértices
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
origem: Ponto
exibir()
Botão
exibir()
O tratamento do exibir() em
Botão irá “overridar”
o exibir() do Ícone,
Apesar de herdar o método
dele e poder reutilizá-lo, ele
implementará de outra
maneira este método

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
Navio
interface
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

Negócio
Acesso
GUI Interface Interface Dados
CLIENTE BD

Interfaces
– Estudo de Caso
– Arquitetura do software para Java
Interface
Gráfica
Camada de
Aplicação
Camada de
Acesso a Dados
Comandos
SQL
insert
delete
update
Interface
Implementação
BD

Interface
Gráfica
Camada de
Aplicação
Camada de
Acesso a Dados
Chamada stored
procedure
insert
delete
update
Interface
mantida
Implementação muda
BD
Interfaces
– Estudo de Caso
– Arquitetura do software para Java

Abordagem Orientada a Objetos
INTERFACE
Dados
+
Operações
INTERFACE
Dados
+
Operações
solicita serviço
responde a
solicitação

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)

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
Métodos orientados a objetos
Simples e notação complexa
Processos de desenvolvimento
1994
Complexo (RUP)
Notação complexa
(UML)

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
UML
Comportamentos

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
Web - June ´96 UML 0.9
OOPSLA ´95 Unified Method 0.8
Other methods Booch method OMT
OOSE
public
feedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1
OMG Acceptance, Nov 1997
UML 1.3
UML partners UML 1.0
UML 1.4

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
DiUasgera Cmasse
DiUagsera Cmasse
Diagrams
Use Case
DiUasgera Cmasse
DiSaegqraumensce
Diagrams
Scenario
DiSagcreanmarsio
CDoiallgarbaomrastion
Diagrams
State
DiagSrtaamtes
DCiaogmrpamonsent
Diagrams
Component
DCiaogmrapmonsent
DDeiapglroamyms ent
Diagrams
Scenario
DiSagcreanmarsio
DSiatgarteacmhsart
Diagrams
State
DiagSrtaamtes
DiagCrlaamsss
Diagrams
Models

Desenvolvimento centrado em Modelos
Necessidade
dos Usuários
Processo 1
Processo de Desenvolvimento de SW
Modelo 1
Processo 2
Processo n
Modelo 2
Desenvolver Software é transformar modelos
SW Novo/
Modificado

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
implementação
Visão de
Distribuição
Visão de
desenho
Visão de
processos
Visão de
casos de uso
Estrutura
(UC,Classes,Relações)
Estrutura
Componentes
Física (Topologia,
Implantação,comunicação)
Escalabilidade
(threads)

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
• Modelo de estrutura
• Modelo de interação
• Modelo de comportamento
• Ferramentas de desenho
• Organização de modelo
• Diagrama de casos de uso
• Diagrama de clases
• Diagrama de objetos
• Diagrama de sequências
• Diagrama de colaboracionais
• Diagrama de estados
• Diagrama de atividades
• Diagrama de componentes
• Diagrama de distribuição
• Diagrama de pacotes

O Porquê destas ferramentas
Classe Classe
Levantamento
Modelo de
casos de uso
Modelo de classes
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
Erros
Exceções
Caminho
Base
Funcionalidade
desejada
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
Usuário
Emprestar
título
Devolver título
Reservar título
Ator

Cadastrar anamnese
Atendente de
1º nível
<<extend>>
<<extend>>
Consultar base de
conhecimento
Cadastrar satisfação do
solicitante
Abrir o.s.
Fechar o.s.
Realizar atendimento de 1º
nível
<<uses>>
Atendente de
1º nível
Diagrama de Casos de Uso

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 1o 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 2o nível.

Diagrama de Classes
Aluno
Curso Disciplina
Professor
1
1..*
0..6
0..*
0..*
1
1..* 1..*
matricula-se
ensina
pertence a
Aspectos estáticos

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
: Atendente de 1º
nível
: Form
AbrirOS
: Solicitante
Abrir( )
Informar Matrícula Usuário( )
Finalizar
Validar Usuário( )
Usuário Não Cadastrado
Aspectos
Dinâmicos

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
Aplicação Geral
MiddleWare
System Software
Software
Gerencial Atendimento
Contratos Equipamento
Manutenção
Preventiva
Hardware
MTS
Windows NT
OS Ambiente de
Conhecimento
Software Func_Help_Desk Defeito
Oracle
Relacionamento
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
Gerencial.DLL
Contrato.DLL
OS.DLL
Manutenção
Preventiva.DLL
Defeito.DLL
Software.DLL
Atendimento.DLL
Equipamento.DLL
Ambiente de
Conhecimento
.DLL
Func_Help_
Desk.DLL
Hardware.DLL
WINDOWS NT
ORACLE
Associação
dos componentes
ao Hardware
Micros Atendimento
1º Nível
HD.EXE
Micros Coordenação
HD.EXE
Micros Atendimento
2º Nível
HD.EXE
Micros Gerência
HD.EXE
REDE

Arquitetura

Acabamento
Instalações
Estrutura
Reboco
Base
Ambientação

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
Modificações
Arquitetura de SW
Modificações
Restrições
Análise de Domínio
Análise de Requisitos
Análise de Riscos
Desenho de
Arquitetura de
Software
Desenho
de Arquitetura
de Hardware
Desenho Detalhado,
Codificação,
Integração e Testes

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
Visão Conceitual
Visão de Módulo
Visão de Código
Visão de
Execução
Componentes
Conectores
Configuração
Componentes
Conectores
Configuração
Restrições
de Execução
Módulos
Nova partição de módulos
Módulos
Subsistemas
Camadas
Construção de Código
Arquitetura de
Hardware
Restrições de Módulos
Nova partição
de módulos
Entidades de
tempo de
execução
Mudanças nas entidades

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
(Cliente)
HTML Browser
Internet Explorer
Netscape
HotJava
HTTP
(web)
Servidor Internet
Windows
2000
Server
JSERV
Midware p/ interação
com Servelets
SERVLET Camada
Aplicação
Acesso
Dados
SGDB
Oracle
Servlet Interface Java
Request e Response
do Browser
Formata HTML de
Resposta
SGBD
Inteligência
da
Aplicação
Infra-Estrutura

• 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
Pedidos
Cadastramento de
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)
Rede Local TCP/IP
Servidor de
Dados
Servidor de
Aplicação
GUI

O Modelo Multi-Camadas
Componentes de Apresentação
Windows
Terminal
Browser NetPC Windows Other
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

– Exemplo: Sistema de Vendas de Livros
– Questões
– Até onde detalhar os módulos do software a
nível de projeto de arquitetura ?
– Normalmente, um módulo é detalhado de
forma a mostrar o ciclo de 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
Cad Livros
Acesso a Dados Autores
Cadastro
Livros
Cliente Comm
Cadastros
Servidor Comm
Cadastros
Cadastro
Autores
Acesso a Dados Livros
GUI
Cad Autores

–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

– Exemplo: Sistema de Vendas de Livros
– Detalhamento do módulo de importação de
clientes
Servidor TCP JAVA
Servidor Comm Entrada Clientes
Processador Arquivos Clientes
Acesso a Dados
Clientes
Driver
JDBC
SGBD

–Identificação das principais interfaces para o
módulo de processamento de pedidos
GUI
Proc Pedido
Acesso a Dados Pedidos
Manutenção
Pedidos
Cliente Comm
Proc Pedido
Servidor Comm
Proc Pedido
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
Aplicação
Cliente

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.

Arquitetura
(GUI)
Negócios
Acesso a Dados
BD
Cliente

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;

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?
Creational Structural Behavioral
Factory Method Adapter Interpreter
Chain
Responsibility
Builder Bridge Command
Prototype Composite Iterator
Singleton Decorator Mediator
Façade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
Abstract Factory Adapter
Template Method
Scope Class
Object

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.
Realiza a
interface
Clonável
Hierarquia de
classes
Subclasses de
Documento
“Instâncias
prototípicas”
Interface

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.
Subclasses
distintas
Ponto único de
acesso
Utiliza métodos
de classes
distintas por
uma interface
única

Adapter
• Intenção: Converte a interface de uma classe na interface
esperada pelo cliente. Compatibiliza classes de interfaces
não compatíveis, permitindo que trabalhem em conjunto.
• Aplicabilidade: Este padrão deve ser utilizado quanto deseja-se
utilizar uma classe já existente, e sua interface não atende
a interface que você precisa. Quando deseja-se criar uma
classe reusável que coopera com classes ainda não
conhecidas ou não criadas, ou seja, classes que não
necessariamente possui interfaces compatíveis. Necessita-se
usar diversas subclasses já existentes, mas é impraticável
adaptar suas interfaces através da criação de subclasses
para cada uma delas.Um objeto adaptador pode adaptar a
interface da superclasse.

• 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
realiza a
interface
Classe que
controla outra
classe
Classe que
provê ponto de
atendimento
Classe
controlada

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
Envia
solicitação
parametrizada
Pode ser
atendida de
várias formas

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
Custo da Qualidade

Qualidade
Qualidade de Software

Qualidade
Princípios da Qualidade

Qualidade
Software

Qualidade
Produto 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
Escopo

Qualidade
Equipe

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

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
#1
Iteração
#2
Iteração
#3
Iteração
#4
Requisitos
Levantar requisitos
Documentar os requisitos
Validar requisitos
Atualizar documento de requisitos
Elaborar diagrama de casos de uso
Elaborar especificação de casos de uso
Validar modelo de casos de uso
Atualizar modelo de casos de uso
Implementar protótipo de interface

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

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

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

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
Atribuir peso aos fatores
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
Simples
Interface de um
sistema
1
Médio
Interface interativa
ou via protocolos de
comunicação
2
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

• 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
Uso
Descrição Peso
Simples
<= 3
transações
/cenários
5
Médio
De 4 a 7
transações
/ cenários
10
Complexo
Mais do que 7
transações
/ cenários
15

• 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
Uso
Descrição Peso
Simples
Menos do que 5
classes de análise.
5
Médio
De 5 a 10 classes de
análise.
10
Complexo
Mais do que 10 classes
de análise.
15
• 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)

• 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
deseFnavtoor dlovsi matoerens t+o Fator dos casos de uso = UUCP

• É 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”
Numero do
fator
Descrição do Fator Peso padrão do fator
(para o método UCP)
T1 Sistema distribuído 2
T2 Objetivos de tempo de resposta e
capacidade de taxa de transferência
1
T3 Alta eficiência para o usuário final
(sistemas on-line)
1
T4 Processamento interno complexo 1
T5 O código deve ser reutilizável 1
T6 Facilidade de instalar 0.5
T7 Facilidade de uso 0.5
T8 Portável 2
T9 Facilidade de manutenção 1
T10 Concorrência 1
T11 Possui requisitos de segurança 1
T12 Provê interfaces para componentes
externos
1

• 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
desenvolvimento
1.5
F2 Experiência no domínio da
aplicação
0.5
F3 Experiência em Orientação a
Objetos
1
F4 Experiência do Analista Líder 0.5
F5 Motivação 1
F6 Requisitos estáveis 2
F7 Equipe alocada em tempo parcial -1
F8 Linguagem de programação
complexa
-1

• 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)

• 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
de estabilidade?
Qual é a atual
confiabilidade?
Quais são as
métricas temporais?
Tamanho de
código
Defeitos
descobertos
Casos de
testes
Horas de
utilização
Horas
de teste
Pessoas
disponíveis por
dia para 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...
Foco na melhoria do
processo
Processo medido e
controlado
Processo proativo e
definido para a
organização
Processo definido para
o nível de projetos e
frequentemente reativo
Processo imprevisível,
pouco controlado
Quantitatively
Managed
Performed
Managed
Defined
5
4
3
2
1
Optimizing

Relembrando ...
Um Processo Gerenciado
Planejado
Executado de acordo
com políticas
Pessoas capacitadas
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
Inicial (1)
Repetível (2)
Definido (3)
Otimizando (5)
Gerenciado (4)
Processo
Caótico
Processo
Disciplinado
Processo
Previsível
Processo
Padronizado e
Consistente
Processo
de
Melhoria
Contínua

Estrutura do CMM
Metas
Implementação
ou
institucionalizaçã
o
Atividades ou
infra-estrutura
indicam
alcançam
abordam
descrevem
contêm
Organizadas pelas
Características
Comuns são
contêm
Práticas-chave
Compromisso
Habilitação
Atividade
Medição e análise
Verificação
Níveis de
Capacitação do Maturidade
Processo
Áreas-chave de
Processo

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
• Solução Técnica
• Integração do Produto
• Verificação
• Validação
• Foco no Processo da Organização
• Definição do Processo da Organização
• Treinamento Organizacional
• Gerenciamento Integrado de Projetos
• Análise de Decisão e
Resolução
• Gerenciamento de Riscos
• Gerenciamento Integrado de Fornecedor
• Ambiente Organizacional para
Integração
• Integração de Equipes
Quantitatively
Managed
Performed
Managed
Defined
Optimizing
Antigas
do CMM

As áreas de engenharia do
nível 3
REQM
Requisitos do produto e requisitos dos
componentes do produto
RD TS PI
Componentes do produto, produtos de trabalho
Ver Val
Cliente
Soluções alternativas
Requisitos
Relatórios de verificação e validação
Necessidades do cliente
Requisitos

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
verificação
– Garantir que os produtos
estejam prontos
• SG2: Realizar peer reviews
– Nos produtos de trabalho
selecionados
• SG3: Verificar produtos de
trabalho selecionados
– Os produtos de trabalhos
são verificados com base
nos requisitos especificados
• SG1: Preparar para
validação
– Garantir que os produtos
estejam prontos para
validação
• SG2: Validar o produto ou
componentes do produto
– O produtos e/ou seus
componentes são validados
para garantir que estão
adequados para o uso no
ambiente operacional
apropriado

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
de melhoria de processos
– Periodicamente os pontos fracos
e oportunidades de melhoria do
processo são identificados
• SG2: Planejar e implementar
atividades de melhoria de
processos
– Os ajustes e melhorias no
processo são implementados de
forma planejada e novas versões
do processo são disponibilizadas
Estabelecer e manter o processo
(assets do processo) da organização
 SG1: Estabelecer o processo (e
seus assets) da organização

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...
% Esforço Organizacional
160%
140%
120%
100%
80%
60%
40%
20%
0%
Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez
% Esforço Org.
Variações
especiais
% Esforço
Organizacional
Goal
UCL
LCL

Quantitatively
Managed
Performed
Managed
Defined
Optimizing
• Performance do Processo Organizacional
• Gerenciamento Quantitativo de Projetos

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...
% Esforço Organizacional
140%
120%
100%
80%
60%
40%
20%
0%
Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez
% Esforço Org.
% Esforço
Organizacional
Goal
UCL
LCL
Variações
Comuns

Quantitatively
Managed
Performed
Managed
Defined
Optimizing
• Desenvolvimento e Inovação Organizacional
• Análise Causal e Resolução

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
Clientes
Fronteira
Organização
Recursos
Processos
Atendimento
Necessidades
Impactos: a mudança da
realidade da clientela
que são gerados pelos...
são atendidas através de...

Clientes
Fronteira
Organização
Recursos
Processos
Atendimento
Necessidades
P
R
O
J
E
T
O
Cadeia de resultados

ESTRATÉGIA
É uma definição de um futuro desejado e dos meios
eficazes para alcançá-lo
(Ackoff)
Onde
estamos?
(B)
Aonde
pretendemos
chegar
(A)
A melhor maneira
de evoluir de “B” para “A”
• Programas
• Projetos
• Outros trabalhos
Portfólio
Todas as empresas que estão no mundo de negócios
de hoje possuem um portfólio de projetos.

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
de como os PROJETOS estão conectados à
ESTRATÉGIA da organização. 1
• Gerentes de Projetos e Gerentes
Funcionais estão permanentemente
“BRIGANDO” por recursos. 2
3 mudando.
• As PRIORIDADES estão freqüentemente
• Projetos são aprovados
INDEPENDENTEMENTE de haver ou não
RECURSOS disponíveis. 4

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
Programas
Projetos
Projetos
Projetos Programas
Programas Projetos Outros trabalhos
Projetos Projetos
Portfólio: uma coleção de projetos e/ou programas e/ou outros trabalhos
agrupados para facilitar o gerenciamento efetivo destes trabalhos e
atingir objetivos estratégicos do negócio.

DEFINIÇÃO
Portfólio
Portfólio
Programas
Projetos
Projetos
Projetos Programas
Projetos Projetos
Gerenciamento de Portfólio: gerenciamento centralizado de um ou mais
portfólios, que inclui identificação, priorização, autorização, gerenciamento e
controle de projetos, programas e outros trabalhos relacionados.

SEPARANDO CONCEITOS...

SUCESSO NO GERENCIAMENTO
Cliente satisfeito com os resultados
Prazos cumpridos conforme o acordado
Ausência de desvios no orçamento
Produto dentro das especificações
técnicas
Gerenciamento de
PORTFÓLIO
Objetivos estratégicos alcançados
Redução do ciclo de vida dos projetos
Retorno adequado dos investimentos
Rentabilidade do portfólio de acordo
com a esperada
Gerenciamento de
PROJETOS

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

CONTEXTO ORGANIZACIONAL
Quais componentes poderiam
ser alocados
propositadamente no
portfólio?
Fonte: The Standard for
Portfólio Management - PMI®

GOVERNANÇA ORGANIZACIONAL
“Certamente não há nada tão inútil quanto fazer com grande
eficiência algo que nunca deveria ter sido feito”.
Peter Ducker
 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.

GOVERNANÇA ORGANIZACIONAL

Plano Estratégico
•Objetivos estratégicos
•Metas
•Critérios de
desempenho
•Definição de
capacidade
VISÃO GERAL DOS PROCESSOS
Identificação
Categorização
Avaliação
Seleção
Priorização
Balanceamento
do Portfólio
Autorização
Revisão do
Portfólio e
Comunicação
Mudança
Estratégica
Execução dos
componentes
sim
não
Plano Estratégico atual
da Organização
Grupo de Processos de
Alinhamento
Grupo de Processos
de Monitoramento e
Controle
Processos dos
Componentes
Processos de Gerenciamento do Portfólio

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

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
Crescimento das vendas
Aumento da participação de mercado
Melhoria de eficiência ou de processos
Obrigações regulamentares
Redução de riscos empresariais
Satisfação do cliente
...
Componentes
combinados em
grupos de negócio
relevantes
conforme o plano
estratégico
Validar com os stakeholders

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
Posicionamento de cada
componente dentro do
portfólio
Critérios de avaliação
 Negócios
 Melhoria de eficiência ou de processos
 Finanças
 Riscos
 Marketing
 Foco técnico
...

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
Ranqueamento
multicritérios
 ROI
 Custos
 Duração
 Riscos
 Recursos
 Preço
 Promoção

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
Comparação gráfica baseada em dois critérios
baixo
baixo médio
alto
alto
médio
Critério 2
Critério 1
Ir em frente
Cuidado
Finalizar

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
Produzir uma lista de componentes do
portfólio representando os componentes
que atingiram as metas dos critérios da
empresa definidos e alinhá-los com a
estratégia organizacional.

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
Lista priorizada de componentes
potenciais do portfólio, todos
listados dentro de suas categorias
estratégicas específicas.
Portfólio Management - PMI® www.alvarofpinheiro.eti.br

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
Componentes priorizados num
agrupamento de componentes
que apresente o melhor potencial
para o alcance coletivo das metas
estratégicas.
Se 90% dos componentes se alinham
com dois dos cinco objetivos
estratégicos da empresa, o portfólio
precisa ser balanceado.

Identifi-cação
Categori-zação
Priori-zação
Balancea-mento
Autori-zação
As estratégias organizacionais, os objetivos estratégicos, os critérios de
gerenciamento de portfólio, as métricas de desempenho entram no jogo.
•Análises de custos e benefícios
•Análises quantitativas
•Análises de cenários
•Análises de probabilidades
•Métodos analíticos gráficos 

Identifi-cação
Categori-zação
O tamanho da bolha reflete
o custo do projeto.
As cores das bolhas
representam critérios.
As categorias 4 e 5 contam
com apenas dois projetos.
A unidade de negócio 1
possui somente um projeto
na categoria de
investimentos 2.
Cada critério parece ter
uma correlação direta com
a unidade de negócio.
Priori-zação
Balancea-mento
Autori-zação
Um método gráfico
Investimentos nas Categorias
1 2 3 4 5
Unidades de Negócio
1
2
3
4
5
6
Investimentos para Unidade de Negócio
1
2
3
4
5
6
1 2 3 4 5
Projetos por Categoria

Identifi-cação
Categori-zação
• 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.
Priori-zação
Balancea-mento
Autori-zação
Plano formal de comunicações para
o gerenciamento do portfólio

Plano Estratégico
•Objetivos estratégicos
•Metas
•Critérios de
desempenho
•Definição de
capacidade
MONITORAMENTO E CONTROLE
Identificação
Categorização
Avaliação
Seleção
Priorização
Balanceamento
do Portfólio
Autorização
Revisão do
Portfólio e
Comunicação
Mudança
Estratégica
Execução dos
componentes
sim
não
Plano Estratégico atual
da Organização
Grupo de Processos de
Alinhamento
Grupo de Processos
de Monitoramento e
Controle
Processos dos
Componentes
Processos de Gerenciamento do Portfólio

REVISÃO DO PORTFÓLIO E COMUNICAÇÃO
Informações consistentes
e precisas
Planejamento
Estratégico
Operações Gerenciamento
do Portfólio
Gerenciamento
de Programas e
Projetos
Revisão do desempenho
do Portfólio
Identificação,
categorização,
avaliação, seleção,
priorização,
balanceamento e
autorização de
componentes do
Portfólio
Revisão do desempenho
de Programas e Projetos
Processos
Visão, Missão e
Plano Estratégico
Solicitações de
Programas e
Projetos
Entregas concluídas
para operações

MUDANÇA ESTRATÉGICA
Os projetos atuais são adequados para
satisfazer os objetivos e alvos estratégicos
da organização ao longo do tempo,
assegurando equilíbrio entre necessidades
atuais e futuras?
A organização será capaz de competir em
diferentes cenários futuros? O portfólio de
projetos inclui alternativas?
Revisões Novo critério

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
Portfólio
Programas
Projetos
Projetos
Projetos Programas
Projetos Projetos
Programa: um grupo de projetos relacionados e gerenciados de forma
coordenada para obter benefícios e controle não disponíveis a partir de
seu gerenciamento de forma individual.

DEFINIÇÃO
Portfólio
Portfólio
Programas
Projetos
Projetos
Projetos Programas
Projetos Projetos
Gerenciamento de Programas: gerenciamento centralizado e coordenado
de um programa de forma a obter os objetivos e benefícios estratégicos
definidos para o programa.

UM EXEMPLO DO GOVERNO
DE MINAS
Visão de Futuro
Opções
Estratégicas
Tornar Minas
Gerais o
melhor Estado
para se viver
10
Objetivos
Estratégico
s
31
Programas
Estruturadore
s
Artigo publicado na revista Mundo
PM www.alvarofpinheiro.eti.br

Programas estruturadores (exemplos)
2 Corredores Radiais de Integração e
Desenvolvimento
Reduzir o “custo de transporte” e aumentar...
5 Saneamento Básico: Mais Saúde para Todos
Ampliar a cobertura dos sistemas públicos...
10 Modernização da Receita Estadual
Alavancar as fontes de receita do Estado...
12 Regionalização da Assistência à Saúde
Adequar a oferta de serviço à demanda...
27 Arranjos Produtivos Locais
Desenvolvimento dos arranjos produtivos...
Programas
Projetos
Atividade
s
UM EXEMPLO DO GOVERNO DE MINAS

Pilares para o gerenciamento
GP
METODOLOGIA
INFORMATIZAÇÃO
ESTRUTURA
ORGANIZACIONAL
COMPETÊNCIAS

Aumento do nível de execução dos projetos
Previsibilidade e controle sobre os resultados
Conhecimento e gestão dos riscos
Visibilidade das atividades necessárias
Comprometimento do coordenador e da equipe
com as metas dos projetos
Melhoria da gestão de licitações, contratos e
convênios
“Consideramos a ferramenta de GP
extremamente oportuna para aumentar a
eficiência da gestão dos gastos do setor
público e ampliar a contribuição deste
setor para o desenvolvimento nacional.”
Benefícios

Projeto A
Projeto B
Projeto C
Projeto D
Projeto E
GERENCIAMENTO DE BENEFÍCIOS
Benefícios discretos
Benefícios
A1...n
Benefícios
E1...n
 Avalia o impacto
organizacional do
programa
 Avalia as
interdependências dos
benefícios
 Designa responsabilidades
pelos benefícios reais
Benefícios
coordenados
Programa
Gestão do
Programa
Benefício
s
Benefícios do
Programa
1...n
Program Management - PMI®

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

CICLO DE VIDA DO PROGRAMA
Set up
Programa
Infra-estrutura
gerencial e técnica
para o Programa
Entrega de benefícios incrementaisConclusão
do
Programa
Transição Operações
regulares
Entrega de
benefícios
Perfil de
Custos
Tempo
Custo

CICLO DE VIDA DO PROGRAMA
Governança do Programa
Fase 1 Fase G1 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
1 benefícios
• Gerenciamento de
2 interessadas do programa
3 •Governança do programa
• Gerenciamento das partes

GERENCIAMENTO DE BENEFÍCIOS
Identificação Análise Planejament
o
Realização Transição
Identificar e
qualificar os
benefícios de
negócios
Derivar e
priorizar
componentes
Estabelecer
plano de
realização de
benefícios
Monitorar
componentes
Consolidar
benefícios
coordenados
Derivar
métricas de
benefícios
Estabelecer
monitoramento
de benefícios
Manter registro
dos benefícios
Transferir
responsabilidad
e para operação
Mapear
benefícios no
Plano do
Programa
Reportar
benefícios

GERENCIAMENTO 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 DefiDneE e aPutoRrizOa oG prRogrAamMa oAu uSm projeto dentro do
programa, gerando a declaração de benefícios do
programa e o plano de realização de benefícios.
Planejamento Planeja as melhores alternativas de ação para entrega
dos benefícios e escopo definidos para o programa.
Execução Integra projetos, pessoas e outros recursos para
execução do plano do programa e entrega dos
benefícios associados.
Monitoramento e
controle
Monitora o programa e projetos associados em
comparação com seus respectivos planos e benefícios
esperados, identificando variações e implementando
ações corretivas, quando necessário.
Encerramento Formaliza a aceitação de um produto, serviço ou
benefício, trazendo o programa ou um de seus
integrantes a um fim ordenado.

Fundamentos da Engenharia de Software

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Fundamentos da Engenharia de Software

Mais de Álvaro Farias Pinheiro

Último

Fundamentos da Engenharia de Software