Fundamentos da Engenharia de Software

https://www.facebook.com/alvarofpinheiroaulas/

br.linkedin.com/in/alvarofpinheiro/

Engenharia de SoftwareFundamentos

http://www.alvarofpinheiro.eti.br

Projeto

www.alvarofpinheiro.eti.br

ProjetosOrigem dos erros nos softwares

Análise

56%

Desenho

27%

Programação

7%

Outros

10%


ProjetosCusto de correção dos erros

Cu

sto

Etapas do ciclo de desenvolvimento

Incremento de

100 a 1000 vezes


Projetos Incremento do custo dos erros

Captura de requisitos

Manutenção

Prova de Aceitação

Teste Unitário

Codificação

Análise e Desenho

1

2,5

5

10

25

100

Boehm, 1988


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

0

10

20

30

40

50

60

até $750m

$750m a $1.5M

$1.5M a $3M

$3M a $6M

$6M a $10M

+ de $10M

Standish Group, 1999

Porcentagem de

êxito (%)

Tamanho do projeto ($)


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

Requisitoswww.alvarofpinheiro.eti.br

Metodologias

Modelos

Processos

Técnicaswww.alvarofpinheiro.eti.br

Engenharia de Software

Metodologias

O termo Engenharia de Software surgiu em uma conferência no final da década de 60. A proposta inicial era a sistematização do desenvolvimento de software, que deveria ser tratado com engenharia e não como arte.



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.


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


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 muitasvezes são mutáveis.


Metodologias Ágeis

Modelos

Dentre as várias metodologias ágeis existentes, as mais conhecidas são a eXtremeProgramming e a Scrum.


Metodologias Ágeis

X

Metodologias Tradicionais

Um exemplo de uma metodologiatradicional ou pesada é o modelo em Cascata, que é composto basicamente por atividadesseqüenciais de levantamento de requisitos, análise, projeto, implementação, teste, implantação e manutenção.


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 dedocumentação.

Colaboração do cliente ao invés de negociação de contratos.

Respostas rápidas a mudanças ao invés de seguir planos.


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)www.alvarofpinheiro.eti.br

RUP é um framework de processo centrado na

arquitetura, baseado em UML, dirigido por casos

de uso e como tal, precisa ser instanciado de

acordo com variáveis de tamanho,

complexidade e domínio do sistema, de acordo

com a organização com seus níveis de

processos e experiências e capacidade das

pessoas

RUP


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 odesenvolvimento de softwares envolve muitas variáveis técnicas e do ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças.


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 emiterações (sprints) de trinta dias. Equipes pequenas, de até dez pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (os requisitos, em outras palavras) definidas no início de cada sprint. A equipe é responsável pelo desenvolvimento desta funcionalidade.


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


http://www.xispe.com.br/wiki/wiki.jsp?topic=TestFirstDesign

http://www.xispe.com.br/wiki/wiki.jsp?topic=TestDrivenDevelopment


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 oprojeto ficou pronto em pouco mais de um ano.



Paradigma

A maioria das regras da XP causapolê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 significaque o programador terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Em relação ao cliente, o feedback constante significa que ele terá freqüentemente uma parte do software totalmente funcional para avaliar. O cliente então constantemente sugere novas características e informações aos desenvolvedores. Eventuais erros e não conformidades são rapidamente identificados e corrigidos nas próximas versões. Desta forma, a tendência é que o produto final esteja de acordo com as expectativas reais do cliente.



Regra: Coragem

É necessário coragem para implantar os três valores anteriores. Por exemplo, não são todas as pessoas que possuem facilidade decomunicação e têm bom relacionamento. A coragem também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar. Além disso, é preciso coragem para obter feedback constante do cliente.



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 tero menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo, melhora as avaliações e o feedback do cliente, aumentando aprobabilidade do software final estar de acordo com os requisitos do cliente.



Prática 3: Metáfora

São as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar odesenvolvimento do software.



Prática 4: Projeto Simples

O programa desenvolvido pelo método XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem seradicionados assim que eles realmenteexistirem. Esta forma de raciocínio seopõe ao “implemente para hoje e projete para amanhã”.



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á presenteem todo o desenvolvimento. Arefatoração deve ser feita apenas quando é necessário, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que é possível simplificar o módulo atual sem perder nenhuma funcionalidade.



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

funcionalidadeswww.alvarofpinheiro.eti.br

FDD - Características

Método ágil e adaptativo;

Foco nas fases de desenho e construção

Interage com outras metodologias

Não exige nenhum processo específico de modelagem

Possui desenvolvimento iterativo

Enfatiza aspectos de qualidade durante o processo e

inclui entregas freqüentes e tangíveis

Suporta desenvolvimento ágil com rápidas adaptações às

mudanças de requisitos e necessidades do mercado


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 www.alvarofpinheiro.eti.br

DSDM - Características

Progenitor do XP

Arcabouço para desenvolvimento rápido de

aplicações (RAD)

Fixa tempo e recursos ajustando a quantia de

funcio-nalidades

Pequenas equipes

Suporta mudanças nos requisitos durante o ciclo

de vida


DSDM - FasesO 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

Softwarewww.alvarofpinheiro.eti.br

ASD - Características

Iterativo e incremental

Sistemas grandes e complexos

Arcabouço para evitar o caos

Cliente sempre presente

Desenvolvimento de aplicações em

conjunto (Joint Application development –

JAD)


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.

Parar

Motorista Carro


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

secretária

doc

doc

arquivo

docs

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

Arquivo

Secretária

Pilha de saída

Pilha de

entrada

doc

doc

doc

doc

doc

Cópia

Anotação

Edição

Próximo

Instrução

Interrupção

Instrução

Empilhamento Registro/Status

Próximo


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


Objetos

saldo

deposito()

Conta corrente


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

ServiçosGarçomCozinheiro

Cardápio

Tipo

Prato

Preço

+AlteraPreço

+GetPreço

ClientePedido

Caixa

Comanda

+CalculaConta


Classes - Fabrica de Objetos

Definição da classe

Objetoswww.alvarofpinheiro.eti.br

Classes

• Podemos fazer uma analogia dizendo que as classes são “fábricas” de objetos.

• Exemplificando, temos que Pessoa é uma classe e João é um objeto (instância) da classe Pessoa

• Um carro é uma classe; “meu carro” é um objeto

• Objetos similares são agrupados em classes


Programas Classes

processos atributos

dados operações


Programas x Classes


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();

}

} www.alvarofpinheiro.eti.br

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

Cliente Conta

debitenc

a1

a2

b1

b2

nc é o número da conta do cliente (do tipo Conta) e enxerga os métodos

debite, mb2 e mb3.

Um objeto do tipo Cliente não precisa saber detalhes de implementação

do método debite para chamá-lo, ele só precisa saber que a operação faz

um débito na Conta e conhecer a sua assinatura.

Os detalhes de como são os métodos internamente, ou de

como eles são implementados não são visíveis através da

interface


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 individuaiswww.alvarofpinheiro.eti.br

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írculoCor

posição central

Num de lados

vértices

raio


class Citros extends Fruta

{

void espremer () {/*............*/}

}

Herança (Java)class Fruta

{

int gramas;




}

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

Descasca()

Cítrica Não Cítrica


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


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 ();

}

}

Polimorfismo (Java)


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

Notação: ------- <>------ <>---------

Empresa (todo) <> --------------- Depto. (parte)

Associação – Agregação – Composição


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

Veleiro etc.....Lancha

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 Naviowww.alvarofpinheiro.eti.br

class HidroAviao implements Navio, MaquinaVoadora

{

double Tanque_Combust;

int Rotac_motor;

int Cabo_ancora;

void LancarAncora () { Cabo_ancora = 200; }

void LevantarAncora () { Cabo_ancora = 0; }

int Navegar (ponto de, ponto para) {/*................*/};

void Pousar ()

{

for ( ; Rotac_motor > 0; Rotac_motor --);

LancarAncora ();

}

void Decolar (double combustivel)

{

LevantarAncora ();

Tanque_Combust + = combustivel;

for ( ; Rotac_motor < 6000; Rotac_motor ++);

}

} www.alvarofpinheiro.eti.br

NegócioAcesso

DadosGUI Interface Interface

BDCLIENTE


Interfaces

– Estudo de Caso

– Arquitetura do software para Java

Interface

Gráfica

Camada de

Aplicação

Camada de

Acesso a Dados

Comandos SQL

insertdeleteupdate

InterfaceImplementação

BD


Interface

Gráfica

Camada de

Aplicação

Camada de

Acesso a Dados

Chamada stored procedure

insertdeleteupdate

Interface

mantida

Implementação muda

BD

Interfaces

– Estudo de Caso

– Arquitetura do software para Java


Abordagem Orientada a Objetos

INT

ER

FA

CE

Dados

+

Operações

INT

ER

FA

CE Dados

+

Operações

solicita serviço

responde a

solicitação


• Analogia com o LEGO (montar os componentes)– Javabeans, EJB, ActiveX

• Em Java temos poucos tipos primitivos

(int, long, short, double, float, char, boolean)

Tudo são classes.

Exceções: Linhas de codigo, Guis, Strings, etc...

• Pacotes de bibliotecas de classes da plataforma Java– java.lang - nucleo da linguagem

– java.awt - interface gráfica

– java.net - operações na rede

– java.io - lidar com arquivos

– java.util - utilitários

Abordagem Orientada a Objetos


Unified

Modeling

Language

(UML)www.alvarofpinheiro.eti.br

Esquema da evoluçãoda

análise de sistemas

Métodos orientados a processos

simples e notação simples

Métodos orientados a dados

simples e notação simples

Métodos orientados a objetos

Simples e notação complexa

1994

Processos de desenvolvimento

Complexo (RUP)

Notação complexa

(UML)


Evolução

da

Análise Orientada a Objetos

• No princípio encontramos recomendações de desenho

(Booch, 1986)

• Se impõe o modelo orientado as características dos objetos

(Shlaer & Mellor, 1988)

• Surgem muitos métodos, mas de autores provenientes das bases de

dados relacionais

(Coad & Yourdon, Martin & Odell, Rumbaugh, Embley, etc., 1990)

• Se impõe os métodos orientados ao comportamento dos objetos

(Wirfs-Brock, Jacobson, Rubin & Goldberg, 1994)

• Começa a iniciar-se a UML (1994) www.alvarofpinheiro.eti.br

Características

UML

1980 1985 1990 1995 2000

Comportamentos

Evolução

da

Análise Orientada a Objetos


O caminho até a unificação

• Grady Booch manifiesta a necessidade de unificar critérios

• Em 1995 Ivar Jacobson completa o trio de “amigos”

• Ambos elaboram a versão 0.8 do Unified Method

• James Rumbaugh se une a Booch em outubro de 1994


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

Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9Web - June ´96

public

feedback

Final submission to OMG, Sep ‘97

First submission to OMG, Jan ´97

UML 1.1

OMG Acceptance, Nov 1997

UML 1.3

UML 1.0UML partners

UML 1.4


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 DiagramasA model is a complete

description of a system

from a particular

perspective Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

ScenarioDiagramsScenario

DiagramsCollaborationDiagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

ScenarioDiagramsScenario

DiagramsStatechartDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

StateDiagramsState

DiagramsClassDiagrams

Models


Desenvolvimento centrado em Modelos

Desenvolver Software é transformar modelos

Processo 1

Processo 2

Processo n

Modelo 2

Modelo 1

Processo de Desenvolvimento de SWNecessidade

dos Usuários

SW Novo/

Modificado


Uso de Modelos

• Representações simplificadas de coisas reais

• Usados há muitos anos em outros ramos da

Engenharia,mais maduras que a nossa

• Se constroem para melhorar o entendimento

• Exemplos:

Maquetes, Planos, Equações, Protótipos,

Simulação por Computador,

Gráficos informaiswww.alvarofpinheiro.eti.br

Modelar não é um fim• É um meio para construir melhor

• Se é mais barato construir e corrigir os erros sobre o

produto, Modelar não tem sentido

• É muito melhor ver o produto do software do que o

modelo, porém terminar o SW e ver que ele não atende

as Necessidades é muito mais caro

• A Correção é muito mais eficiente nas etapas iniciais do

Processo, e os modelos servirão de base para antecipá-los

• É conveniente conhecer vários tipos de Modelos. Distintos

problemas ou partes deles, requerem distintas técnicas de

modelagemwww.alvarofpinheiro.eti.br

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

processos

Visão de

desenho

Visão de

casos de usoEstrutura

(UC,Classes,Relações)

Estrutura

Componentes

Física (Topologia,

Implantação,comunicação)

Escalabilidade

(threads)


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


• Modelo de requisito

• Modelo de estrutura

• Modelo de interação

• Modelo de comportamento

• Ferramentas de desenho

• Organização de modelo

• Diagrama de casos de uso

• Diagrama de clases

• Diagrama de objetos

• Diagrama de sequências

• Diagrama de colaboracionais

• Diagrama de estados

• Diagrama de atividades

• Diagrama de componentes

• Diagrama de distribuição

• Diagrama de pacotes

Ferramentas da UML


O Porquê destas ferramentas

ClasseClasse

Levantamento

Modelo de

casos de uso

Modelo de classes

Modelo de comportamentoModelo 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 usuarioswww.alvarofpinheiro.eti.br

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 anamneseAtendente de

1º nível

Consultar base de

conhecimento

Cadastrar satisfação do

solicitante

Abrir o.s.

Fechar o.s.

<<extend>>

Realizar atendimento de 1º

nível

<<extend>>

<<uses>>

Atendente de

1º nível

Diagrama de Casos de Uso


USE CASE: ABRIR O.S.

Fluxo de dados principal:

O use case inicia quando o solicitante telefona para o ramal do Call Center para aresolução de um problema. O atendente de 1o nível informa a matrícula dosolicitante. O sistema verifica se o solicitante está cadastrado. Se o mesmo estivercadastrado, o atendente informa o equipamento e então o sistema verifica se omesmo está em manutenção. Se o equipamento não estiver em manutenção, osistema verifica se o equipamento está em garantia. Se não estiver em garantia, osistema busca os softwares associados àquele equipamento e o atendente verificaa necessidade de execução do processo de anamnese. O sistema sugere aprioridade do atendimento a partir do nível do solicitante e o atendente de 1o nívelconfirma a prioridade do atendimento. Em seguida, informa a ocorrência doproblema. O atendente de 1o nível usa (consultar base de conhecimento). Aseguir, o atendente de 1o nível registra data, hora, tipo e dados obrigatórios daO.S.

Fluxo de dados excepcional:

1. Se o solicitante não estiver cadastrado, o sistema não permite que oatendimento seja realizado.

2. Se após a abertura da O.S., o atendente de 1o nível encontrou a solução doproblema, estende (fechar O.S).

3. Se o equipamento estiver em manutenção, o sistema não permite que oatendimento seja realizado.

4. Caso o equipamento esteja em garantia e o tipo da O.S. não for de software, oatendente de 1o nível registra data, hora, tipo, dados obrigatórios da O.S enúmero do contrato, encaminhando-a para o coordenador de 2o nível.


Diagrama de Classes

Curso Disciplina

Aluno

Professor

1

1..*

0..6

0..*

0..*

1

1..*1..*

matricula-se

ensina

pertence a

Aspectos estáticos


• Diagrama utilizado para representar os aspectos

estáticos do Sistema

• Exibe um conjunto de classes e seus

relacionamentos

Diagrama de Classes


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


• Usados para modelar os aspectos dinâmicos

do Sistema

• É um diagrama de interação que enfatiza a

ordenação de mensagens com relação ao tempo

Diagrama de Seqüência


Aplicação Específica

Aplicação Geral

MiddleWare

System Software

Gerencial Atendimento

Contratos Equipamento

Manutenção

Preventiva

Hardware

MTS

Software

Windows NT

OS Ambiente de

Conhecimento

Func_Help_Desk DefeitoSoftware

Oracle

Relacionamento

entre os

Componentes

Diagrama de Componentes


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

Contrato.DLL

OS.DLL

Manutenção

Preventiva.DLL

Defeito.DLL

Software.DLL

Gerencial.DLL

Equipamento.DLL

Ambiente de

Conhecimento

.DLL

Func_Help_

Desk.DLL

Hardware.DLL

Atendimento.DLL

WINDOWS NT

ORACLE

Micros Atendimento

1º Nível

HD.EXE

Micros Coordenação

HD.EXE

Micros Atendimento

2º Nível

HD.EXE

Micros Gerência

HD.EXE

REDE

Associação

dos componentes

ao Hardware


Arquitetura


Base

Reboco

Estrutura

Instalações

Acabamento

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

Nova partição de módulos

Módulos

Subsistemas

Camadas

Construção de Código

Arquitetura de

Hardware

Restrições de Módulos

Componentes

Conectores

Configuração

Restrições

de Execução

Nova partição

de módulos

Módulos

Entidades de

tempo de

execução

Mudanças nas entidades


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


PropriedadesRelembrando

O papel dos componentes, relacionamentos e até

mesmo o contexto mudam em cada visão

Exemplos:

Componentes podem ser : Módulos,Processos,etc.

Relacionamentos : É-Sub-Módulo,

Sincroniza-com,etc.

Contexto: Em tempo de desenvolvimento,

Em tempo de execução,etc.


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

HTML Browser

Camada Apresentação

(Cliente)

Internet Explorer

Netscape

HotJava

HTTP

(web)

Windows

2000

Server

Servidor Internet

JSERV

Midware p/ interação

com Servelets

SERVLET Camada

Aplicação

Acesso

DadosSGDB

Oracle

Servlet Interface Java

Request e Response

do Browser

Formata HTML de

Resposta

SGBD

Inteligência

da

Aplicação

Infra-Estrutura



• 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


Arquitetura de Software• Decomposição modular

• Os subsistemas identificados são

decompostos em módulos

• Nesta fase, ocorre o detalhamento da

visão macro estabelecida na fase de

estruturação do sistema

• Exemplos:

• Subsistema Caixa

• Modulo de Recebimento

• Modulo de Abertura/Fechamento


Arquitetura de Software• Decomposição modular

• Subsistema

• Um subsistema é também um sistema,

cuja operação é independente dos

serviços providos por outros

subsistemas

• Módulo

• Um módulo é um componente do

sistema que provê serviços a outros

componentes mas que normalmente

não seria considerado um sistema

separadowww.alvarofpinheiro.eti.br

Decomposição modular

• Diferença entre subsistemas e

módulos• Não há uma definição clara

• Nomenclatura normalmente usada

indistintamente por projetistas e

analistas

• Engenharia de software moderna usa

estes termos para designar elementos

diferentes em um projeto de softwarewww.alvarofpinheiro.eti.br


Processamento de

Pedidos

• Exemplo de Arquitetura

Acesso a Dados

Cadastramento de

Informações

Comunicação

Interface

Gráfica


Arquitetura de Software• Modelo Cliente-Servidor

• Modelo de arquitetura que mostra como dados e processamento são distribuídos entre processadores

• Componentes:

• Conjunto de servidores separados que realizam serviços específicos

• Conjunto de clientes que usam estes serviços

• Rede que permite que clientes acessem os servidores

• Modelo largamente aplicado em sistemas modernos



• Modelo Cliente-Servidor

Rede (LAN, WAN ou Internet)

Cliente NCliente 2Cliente 1

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


Componentes de Apresentação

Windows

TerminalBrowser NetPC Windows Other

Componentes de lógica de Aplicação

DADOS: SQL, Mail, ISAM, Host, não-Estruturado

O Modelo Multi-Camadas


Passos para construção

• Construção de um programa segundo o paradigma de orientação a objetos

• Definir classes para modelar conceitos da aplicação

• Estruturar estas classes em uma hierarquiade generalização/especialização

• Disparar mensagens para uma classe (que é o papel de um programa principal), e iniciar a execução de um programa


Arquitetura de Software– Exemplo: Sistema de Vendas de Livros

– Questões

– Até onde detalhar os módulos do software a nível de projeto de arquitetura ?

– Normalmente, um módulo é detalhado de forma a mostrar o ciclo de funcionamentodo mesmo

– Este detalhamento deve levar em consideração a filosofia de arquiteturaadotada (em camadas, client-server por exemplo)

– Devem ser observadas situações de reusowww.alvarofpinheiro.eti.br

Arquitetura de Software– Exemplo: sistema de vendas de livros

– Detalhamento Módulo de Cadastros + 1camada

Acesso a Dados Autores

GUI

Cad Livros

Cadastro

Livros

Cliente Comm

Cadastros

Servidor Comm

Cadastros

Acesso a Dados Livros

Cadastro

Autores

GUI

Cad Autores




–Questões

–É necessário mostrar apenas os componentes a serem desenvolvidos ou todos os elementos da solução (SGBD, servidores de internet, proxies, etc.) ?

–É possível mostrar componentes de software que não serão desenvolvidos mas que fazem parte da solução

–Esta visão dá ênfase à estruturação física do sistema




– Detalhamento do módulo de importação de clientes

Processador Arquivos Clientes

Servidor Comm Entrada Clientes

Acesso a Dados

Clientes

Servidor TCP JAVA

Driver

JDBCSGBD


Arquitetura de Software– Exemplo: Sistema de Vendas de Livros

– Identificação das principais interfaces para o módulo de processamento de pedidos

Acesso a Dados Pedidos

GUI

Proc Pedido

Manutenção

Pedidos

Cliente Comm

Proc Pedido

Servidor Comm

Proc Pedido

Acesso a Dados Livros


Cliente-Servidor: Arquiteturas

• Arquitetura em Duas Camadas

(Two Tier Architecture)

- Processamento é realizado no cliente e/ou no servidor;

• Arquitetura em Três Camadas

(Three Tier Architecture)

– Utilização de um middleware entre ocliente e o servidor;


Duas Camadas

Servidor Cliente


• Os dados são armazenados em servidores com

administração centralizada, e os clientes se conectam

diretamente a esses servidores por quase todo o ciclo de

vida do aplicativo.

• Cada aplicativo cliente contem sua própria lógica de

processamento. Qualquer modificação, tem de distribuir

uma nova versão do aplicativo. Isto pode ser melhorado

usando Stored Procedures armazenadas no Banco,

movendo parte da lógica para o lado servidor.

• - Três componentes distribuídos em duas camadas:

– Interface com o usuário : Cliente

– Gerenciador de processos: Cliente/Servidor

– Gerenciador de banco de dados: Servidor

Arquitetura em duas camadas


3 Camadas

ServidorServidor

de

Aplicação

Cliente


• 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 em 3 camadas


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;


NegócioAcesso

DadosGUI Interface Interface

BDCLIENTE


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 menosriscos de erro;

• Programas desenvolvidos maisrapidamente;

• Programas mais fáceis de alterar, sem riscode comprometimento da estrutura original;

• Programas testados integralmente e emtempo 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 ProdutividadeProver direções na melhoria do desenvolvimento de código.

• Melhorias sem impactoPermite que design e codificação mudem com o mínimo de impacto no código.

• AbstraçãoO uso de abstração permite uma mudança transparente.

• Implementações Late BindingPermite que tipos de dados sejam resolvidos em tempo de run-time.

• Aumento de QualidadePermite o aumento de qualidade como um código mais legível. Legibilidade implica em uma taxa baixa de erros.


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?

InterpreterAdapterFactory Method

Visitor

Strategy

StateProxy

ObserverFlyweight

MementoFaçade

MediatorDecoratorSingleton

IteratorCompositePrototype

CommandBridgeBuilder

Chain

Responsibility

AdapterAbstract Factory

Template Method

BehavioralStructuralCreational

Object

ClassScope


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

http://pt.wikipedia.org/wiki/Widgets

http://pt.wikipedia.org/wiki/Ficheiro:Abstract_Factory.gif

http://pt.wikipedia.org/wiki/Ficheiro:Abstract_Factory.gif

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

http://pt.wikipedia.org/wiki/ASCII

http://upload.wikimedia.org/wikipedia/commons/e/e1/Builder_(padr%C3%A3o).png

http://upload.wikimedia.org/wikipedia/commons/e/e1/Builder_(padr%C3%A3o).png

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

Subclasses de

Documento

“Instâncias

prototípicas”

Hierarquia de

classes

Interface


http://pt.wikipedia.org/wiki/ASCII

http://pt.wikipedia.org/wiki/PDF

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étodoDesenhaBorda() que por sua vez realiza "n" chamadas ao método DesenhaLinha() da classe XWindowImpl ou MSWindowImpl, dependendo da plataforma desejada.

Hierarquias

Interfaces

Implementação

das Interfaces


http://pt.wikipedia.org/wiki/Acoplamento

http://pt.wikipedia.org/wiki/M%C3%A9todo_(programa%C3%A7%C3%A3o)

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

Classe abstrata

para

embelezamento

Interface

Classe abstrata

Classe

concretas

Decorator

• Inteção: Anexa dinamicamente responsabilidades adicionais a um

objeto. Provê uma alternativa flexível ao uso de herança como

mecanismo de extensão de funcionalidade

• Aplicabilidade: Utilize este padrão para adicionar responsabilidades

individuais a objetos dinamicamente e transparentemente, isto é,

sem afetar outros objetos. Utilize este padrão para

responsabilidades que podem ser “removidas”. Ou ainda quando a

extensão de funcionalidade através da criação de subclasses é

impraticável. Em algumas situações um grande número de

extensões independentes são possíveis e isto poderá produzir uma

grande quantidade de subclasses para suportar cada uma das

combinações.


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 Commanddeve ter acrescentada uma operação Unexecute, que o reverte efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista histórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente, chamando operações Unexecute e Execute, respectivamente.



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

EstimativasWideBand Delphi


WideBand Delphi

• O método Delphi foi desenvolvido em 1948– esse método requer que um pequeno grupo de experts realizem

estimativas individuais para um determinado problema e que ao final um consenso seja alcançado através de iterações de seções de estimativas

• No inicio dos anos 70, Barry Boehm realizou modificações no método e criou a técnica atual chamada de Wideband Delphi– As mudanças buscaram criar um método de estimativas com

mais interação entre os experts responsáveis pelas estimativas

– Foi criado um procedimento repetível para a realização de estimativas em projetos de software seguindo a técnica WideBand Delphi


WideBand Delphi

• Principais Vantagens:– As estimativas não são realizadas por uma única pessoa

– A técnica suporta a identificação do WBS do projeto (conjunto de atividades base para o planejamento do projeto)

• Todos estimam sobre a mesma base – o WBS

– As pessoas são mais comprometidas com as estimativas,sempre que participam da realização das mesmas

– A troca de conhecimento entre os experts durante as iterações de realização das estimativas permite um consenso com maior embasamento, “menos incerto”


WideBand Delphi

• Principais Vantagens

– Pode ser utilizado para estimar qualquer coisa

– Projetos que não podem ser estimados a partir de outras

técnicas, podem ser estimadas com Wideband Delphi

• Projetos de consultoria

• Projetos que envolvam apenas documentação

• Sistemas que não envolvem apenas desenvolvimento de software


Wideband Delphi – Processo de

Estimativa• Técnica de estimativa Bottom-up

• O ponto de partida para utilização da técnica é uma especificação inicial do problema a ser estimado ou uma lista alto nível das atividades a serem realizadas

• A saída do processo é:

– Lista detalhada das atividades do projeto;

– Tarefas operacionais e de overhead;

– Tarefas relacionadas ao processo;

– Premissas das estimativas;

– Estimativas de todos os participantes para as atividades do projeto.



Estimativa

Planejamento

Reunião de Kick-off

Preparação Individual

Reunião de Estimativas

Organização dos resultados

Revisão dos resultados finais


Wideband Delphi –

Planejamento• Uma sessão de Wideband Delphi se inicia com a definição do

escopo do problema

– Problemas maiores devem ser quebrados em módulos gerenciáveis que possam ser estimados de forma mais precisa

– A pessoa responsável por iniciar o processo de estimativa deve ter a preocupação de prover o máximo de informações possíveis para o grupo responsável por estimar o projeto

• O grupo de estimativas deve possuir a seguinte configuração:

– Um moderador, responsável por planejar e coordenar as estimativas

– O gerente de projeto

– Dois ou três participantes técnicos


Wideband Delphi –

Planejamento• O moderador deve conhecer bem o escopo a ser

estimado, de forma a poder estimar como qualquer outro

membro do grupo

– Mas o seu principal papel é agir como facilitador imparcial para

resolver conflitos durante a realização das estimativas

• Os demais participantes são selecionados com base no

seu conhecimento do negócio e com base na

experiência na tecnologia e nos processos utilizados

pela organização



Estimativa

Planejamento

Reunião de Kick-off






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






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 –


Tarefas Iteração

#1

Iteração

#2

Iteração

#3

Iteração

#4

Requisitos

Levantar requisitos

Documentar os requisitos

Validar requisitos

Atualizar documento de requisitos

Elaborar diagrama de casos de uso

Elaborar especificação de casos de uso

Validar modelo de casos de uso

Atualizar modelo de casos de uso

Implementar protótipo de interface

Padrão de formulário para registro da lista de atividades e estimativas



Individual• As estimativas não devem ser influenciadas pelo que a

gerência ou outros stakeholders do projeto almejem– Evitar que pressões externas influenciem nas estimativas

• Existem boas chances das estimativas ficarem fora das fronteiras do cronograma esperado– Negociações serão necessárias na resolução de conflitos

– Redução de escopo

– Aquisição de componentes de reuso

– Aumento da equipe

– Paralelismo de atividades



Individual• Incluir atividades extras ao desenvolvimento de software

– Garantia da qualidade

– Gerência de configuração

– Atividades gerais do processo relacionadas ao ciclo de vida

adotado

– Atividades relacionadas a re-trabalho

– Atividades gerais de suporte: Treinamentos, Reuniões…

• Documentar todas as premissas tomadas como base

para realização da estimativa



Individual• Orientações para realização das estimativas:

– Assumir que uma única pessoa (você) irá realizar toda a

atividade

– Assumir que todas as atividades serão realizadas

seqüencialmente

– Assumir que as atividades serão desenvolvidas de forma

ininterrupta

• Facilita o processo de estimativas

– Listar todos os períodos de dependência entre as atividades, de

forma a apoiar a tradução das estimativas em prazos

posteriormente



Estimativa

Planejamento

Reunião de Kickoff







Estimativas

• O moderador coleta as estimativas individuais de cada

participante e gera um gráfico a partir das mesmas



Estimativas• O moderador não deve identificar o responsável por cada estimativa

– O anonimato é importante para a técnica Wideband

• Cada participante explicita suas premissas e restrições levadas em consideração nas estimativas

– Sem revelar seus valores

• Uma lista de atividades mais completa é consolidada

• Um melhor entendimento a respeito do escopo a ser estimado é alcançado de forma a viabilizar um maior índice de convergência nas estimativas



Estimativas

• Após as discussões, cada participante deverá estimar “individualmente” novamente a lista de atividades– De forma a refiná-las com as informações obtidas nas discussões

da reunião

• O moderador repete o ciclo da primeira iteração, coletando os dados das estimativas individuais e adicionando ao gráfico os dados da segunda iteração das estimativas– A segunda iteração deve diminuir o intervalo entre a menor e

maior estimativa



Estimativas

• Iterações adicionais seguindo a mesma dinâmica devem ser realizadas até que…– Tenha havido 4 iterações

– As estimativas tenham convergido para um intervalo aceitável (que deve ser definido antecipadamente: dados históricos)

– O tempo da reunião de estimativa ter se esgotado (em média 2h)

– Os participantes não estejam confortáveis em alterar suas últimas estimativas



Estimativas

Gráfico de estimavas mostrando os resultados de três iterações de uma sessão de Wideband Delphi



Estimativa

Planejamento

Reunião de Kickoff






Wideband Delphi – Organização

dos Resultados• A realização da reunião não significa o fim dos trabalhos…

• Moderador e gerente de projeto vão revisar a lista de atividades– Identificar grandes desvios nas estimativas de tarefas iguais ou

similares

– Refletir se alguma mudança precisa ser realizada

• Incluir atividades operacionais levantadas por cada um dos participantes das estimativas

• Consolidação de todas as premissas levantadas para cada atividade



Estimativa

Planejamento

Reunião de Kickoff






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

O objetivo final é prover uma estimativa confiável (baixo

nível de variância) para o gerente de projeto continuar o

planejamento e a execução do projeto com um maior

nível de confiança

Os participantes devem revisar a lista final de forma a

garantir que a mesma é a mais completa possível



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

EstimativasPontos de Caso de Uso


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.



Principais conceitos

Fatores Técnicos – Fatores técnicos do

projeto, referentes a arquitetura do sistema,

necessidades especificas do usuário e

cliente.

UUCP – Unadjusted Use Case Points

UCP – Use Case Points

TCF – Technical Complexity Factor

EF – Environmental Factor



Principais conceitos• Critérios de entrada para uso da técnica

– Todos os casos de uso do sistema devem

estar identificados

– Atores identificados para todos os casos de

uso do sistema



Processo de Contagem

Atribuir peso aos atores

Atribuir peso aos casos

de uso

Calcular total de pontos de

casos de uso não ajustados

Atribuir peso aos fatores

técnicos


ambientais

Calcular pontos de

casos de uso ajustados



Processo de Contagem• O processo se inicia com a identificação dos

atores do sistema a ser desenvolvido, classificando-os como simples, médio e complexo

• Critérios para a classificação de atores:– Simples: um sistema legado com uma interface de

comunicação bem definida;

– Médio: sistema legado com comunicação via protocolos, por exemplo TCP/IP, ou interfaces Text-Based, por exemplo Terminal ASCII;

– Complexo: pessoa que interage com o sistema via interface gráfica.




• Tabela de peso dos atores

• Os atores devem ser agrupados pelo tipo em que foram classificados, cada grupo deve ser multiplicado pelo valor de seu peso e depois somados dando o peso total dos atores do sistema.

Tipo do ator Descrição Peso

SimplesInterface de um

sistema1

Médio

Interface interativa

ou via protocolos de

comunicação

2

Complexo Interface gráfica 3



Processo de Contagem• Exemplo de atribuição de pesos aos

atores

– Usuário funcionário do banco

– Sistema de transações bancárias

– => 1 ator complexo e 1 ator médio

• Total de pontos

– 1*3 + 1*2 = 5 pontos






de uso




técnicos


ambientais

Calcular pontos de




Processo de Contagem• Processo similar ao dos atores do sistema

• Cada caso de uso identificado para o sistema deve ser classificado como– simples, médio e complexo.

• A base para a tomada dessa decisão é o número de transações envolvidas no caso de uso, incluindo os fluxos alternativos

• O conceito de transações nesse contexto se restringe a um “conjunto atômico de atividades”, um cenário do caso de uso por exemplo




• A tabela abaixo lista o fator e a classificação de cada tipo de

caso de uso.

Tipo do Caso de Uso

Descrição Peso

Simples<= 3

transações /cenários

5

MédioDe 4 a 7

transações / cenários

10

ComplexoMais do que 7

transações / cenários

15



Processo de Contagem• Outro mecanismo usado para medir a

complexidade de casos de uso é o número de

classes de análise

– a quantidade de transações nesse caso não é levada

em consideração

• Essa abordagem só pode ser utilizada quando

as classes de análise do sistema já estão

definidas, e já se sabe que classes de análise

implementam os casos de uso

– as classes de projeto não são levadas em

consideração




• A tabela abaixo lista o fator e a classificação de cada tipo de caso de uso de acordo com as classes de análise envolvidas

• Utilizando um dos mecanismos o total de casos de uso de cada tipo é somado e multiplicado pelo peso correspondente ao tipo (simples, médio e complexo)

Tipo do Caso de Uso

Descrição Peso

SimplesMenos do que 5 classes de análise.

5

MédioDe 5 a 10 classes de análise.

10

ComplexoMais do que 10 classes de análise.

15






de uso




técnicos


ambientais

Calcular pontos de




Processo de Contagem• O fator calculado através dos atores do

sistema deve ser somado ao fator

calculado pelos casos de uso

• Esse fator é denominado UUCP

(Unadjusted use case points) e será

ajustado para refletir a complexidade do

projeto e a experiência da equipe de

desenvolvimentoFator dos atores + Fator dos casos de uso = UUCP






de uso




técnicos


ambientais

Calcular pontos de




Processo de Contagem• É necessário ponderar o fator UUCP com os aspectos técnicos do

projeto: complexidade do sistema, experiência da equipe e requisitos não funcionais

• O fator TCF(Technical Complexity Factor) expressa a complexidade do sistema.

• Para o cálculo do TCF para cada fator é atribuído um peso no valor de 0 a 5, onde o 0 significa que o fator é irrelevante ao sistema e 5 indica ser essencial

• Soma-se então o valor de cada fator multiplicado pelo peso atribuído em função do sistema específico (os valores de 0 a 5).

– TFactor = SOMA ((TLevel) * (Peso Especifico))

– TCF = 0.6 + (0.01*TFactor)




“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






de uso




técnicos


ambientais

Calcular pontos de




Processo de Contagem• Após a definição do TCF, é necessário

calcular o fator relacionado ao ambiente

de desenvolvimento, incluindo equipe, o

EF (Environmental Factor).

• Para o cálculo do EF utiliza-se outro

conjunto de fatores

• Para cada um dos fatores listados no

conjunto se atribui pesos específicos para

o sistema nos limites de 0 a 5




“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



Processo de Contagem• A seguir são listados os critérios de atribuição dos pesos de cada

fator:

– De F1 até F4, o valor 0 indica não haver experiência, 5 significa expertse 3 um nível médio de experiência

– F5, 0 indica não existência de motivação, 5 alta motivação e 3 média

– F6, 0 indica requisitos extremamente instáveis, 5 estáveis e 3 nível parcial de instabilidade

– F7, 0 indica inexistência de pessoas da equipe em tempo parcial, 5 toda a equipe em tempo parcial e 3 expressa uma equipe mista

– F8, 0 indica linguagem de programação fácil, 5 extremamente difícil e 3 uma linguagem com nível de dificuldade médio



Processo de Contagem• O Cálculo do fator ambiental segue a

mesma regra do fator técnico

• Soma-se então o valor de cada fator

multiplicado pelo peso atribuído em

função do sistema específico (os valores

de 0 a 5), sendo definido dessa forma o

valor EFactor

– EFactor = SOMA((FLevel) * (Peso

específico))

– EF = 1.4 + (-0.03*EFactor)www.alvarofpinheiro.eti.br





de uso




técnicos


ambientais

Calcular pontos de




Processo de Contagem• Depois do cálculo de todos os fatores que

influenciam a complexidade total do

sistema, pode-se obter o total de pontos

de caso de uso através da seguinte

fórmula:UCP = UUCP * TCF * EF


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 testeswww.alvarofpinheiro.eti.br

GQM - Fases1. Planejamento

2. Definição

3. Coleta de dados

4. Interpretação

Além disso, a abordagem possui métodos

para refinamento de objetivos, geração

das questões, especificação das

métricas, validação, análise,

implantação do processo em uma

organização, etc.


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

Processo imprevisível, pouco controlado

Processo definido para o nível de projetos e frequentemente reativo

Processo proativo e definido para a organização

Processo medido e controlado

Foco na melhoria do processo

QuantitativelyManaged

Performed

Managed

Defined

1

2

3

4

5

Optimizing


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)

Gerenciado (4)

Otimizando (5)

Processo

Caótico

Processo

Disciplinado

Processo

Padronizado e

Consistente

Processo

Previsível

Processo

de

Melhoria

Contínua


Estrutura do CMM

Atividades ou

infra-estrutura

Implementação

ou

institucionalizaçã

o

Metas

indicam

alcançam

abordam

descrevem

contêm

contêm

Práticas-chave

Organizadas pelas

Características

Comuns são

Compromisso

Habilitação

Atividade

Medição e análise

Verificação

Níveis de

MaturidadeCapacitação do

Processo

Áreas-chave de

Processo


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 aserem usadas no planejamento eacompanhamento do projeto.

• Planejar e documentar as atividades e oscompromissos do projeto dedesenvolvimento de software.

• Obter a concordância dos grupos e das pessoas envolvidas quanto aos respectivos compromissos relacionados ao projeto de desenvolvimento de software.


KPA Supervisão e Acompanhamento de

ProjetoMetas:

• Acompanhar os resultados e desempenhosreais confrontando-os com o plano dedesenvolvimento de software.

• Tomar ações corretivas e gerenciá-las atésua conclusão.

• Assegurar que as alterações nos compromissos de software se dêem através de acordo entre os grupos e as pessoas envolvidas.


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 eprodutos de software.

• Informar aos envolvidos as atividades eresultados de GQS.

• Encaminhar à gerência questões de não-conformidade não resolvidas no âmbito doprojeto de software.


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).www.alvarofpinheiro.eti.br


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



• Funções e responsabilidades no processo são bem entendidas

• A produção do produto de software é visível através do processo de software

• Papéis, responsabilidades e interação entre atividades são bem entendidos por todos

In Out


• 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


Performed

Managed

Defined

Optimizing

Áreas de Processo - Nível 3

Antigas

do CMM


As áreas de engenharia do

nível 3

REQM

RD TS PI

Ver Val

Cliente

Soluções alternativas

Requisitos

Relatórios de verificação e validação

Componentes do produto, produtos de trabalho

Necessidades do cliente

Requisitos do produto e requisitos dos

componentes do produto

Requisitos


Desenvolvimento dos

Requisitos

• SG1: Desenvolver requisitos do cliente

– Necessidades dos principais envolvidos, expectativas,

limitações e interfaces são traduzidas em requisitos do

cliente

• SG2: Desenvolver requisitos do produto

– Requisitos do cliente são refinados e traduzidos em

requisitos do produto e dos componentes

• SG3: Analisar e validar requisitos

– Os requisitos são analisados e validados, e uma definição

das funcionalidades é elaborada

Produzir e analisar requisitos do cliente,

do produtos e dos componentes


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

• SG1: Selecionar Soluções para o produto

– Soluções para o produto (ou componentes) são

selecionadas a partir de soluções alternativas

• SG2: Desenvolver o Projeto

– Desenvolver o projeto do produto

• SG3: Implementar o Projeto do Produto

– Os componentes do produto e documentações relacionadas

são produzidas a partir do projeto

Projetar, desenvolver e implementar soluções para

os requisitos. Envolve a escolha da melhor solução

para atender aos requisitos


Solução Técnica

• Principais atividades:

– Verificar e evoluir os cenários de instalação e

operação do produto

– Definir critérios para a análise das soluções

apropriadas

– Realizar análise “Make or Buy or reuse”

– Elaborar e implementar o projeto gerando o produto

final

– Elaborar documentação de suporte ao produto:

manuais, manuais de instalação e operação, etc.


Integração do Produto

• SG1: Preparar o produto para integração

• SG2: Garantir compatibilidade entre as

interfaces

– Interfaces internas e externas devem ser

garantidas

• SG3: Montar e liberar o produto

Montar o produto a partir dos componentes desenvolvidos,

garantir que o produto integrado funciona de

forma adequada e pode ser entregue


Integração do Produto

• Principais atividades:

– Realizar testes de integração entres os componentes

e módulos

– Estabelecer a seqüência de integração, preparar o

ambiente, estabelecer procedimentos de integração

– Revisar interfaces para garantir completude

– Garantir que os componentes estão devidamente

integrados e prontos para o release

– Liberar o produto


V&V – Verificação e Validação

Estamos construindo o produto de forma correta?

Estamos atendendo aos requisitos especificados?

Estamos construindo o produto correto?

Estamos atendendo às necessidades operacionais?

X

Garantir que os produtos de trabalho selecionados

atendem aos requisitos especificados

Demonstrar que o produto ou componente atende

a intenção de uso quando implantado no ambiente

planejado


V&V – Verificação e Validação

• SG1: Preparar para verificação

– Garantir que os produtos estejam prontos

• SG2: Realizar peer reviews

– Nos produtos de trabalho selecionados

• SG3: Verificar produtos de trabalho selecionados

– Os produtos de trabalhos são verificados com base nos requisitos especificados

• SG1: Preparar para validação

– Garantir que os produtos estejam prontos para validação

• SG2: Validar o produto ou componentes do produto

– O produtos e/ou seus componentes são validados para garantir que estão adequados para o uso no ambiente operacional apropriado

Verificação Validação



As demais áreas serão explicadas de

forma breve...


Foco no processo da

organização & Definição do

processo da organização

• SG1: Determinar oportunidades de melhoria de processos

– Periodicamente os pontos fracos e oportunidades de melhoria do processo são identificados

• SG2: Planejar e implementar atividades de melhoria de processos

– Os ajustes e melhorias no processo são implementados de forma planejada e novas versões do processo são disponibilizadas

Planejar e implementar a melhoria do processo

organizacional baseada nos pontos fortes e fracos

existentes no processo

Estabelecer e manter o processo

(assets do processo) da organização

SG1: Estabelecer o processo (e seus assets) da organização


Treinamento Organizacional

• SG1: Estabelecer a capacidade de treinamento

organizacional

– A capacidade de treinamentos que suporta os papéis

técnicos e gerenciais da organização é estabelecida e

mantida

• SG2: Prover os treinamentos necessários

– Treinamentos necessários para as pessoas executarem

seus papéis são fornecidos

Desenvolver e manter as habilidades e conhecimentos das

pessoas para que elas possam executar seus Papéis de

forma efetiva e eficiente


Gerenciamento Integrado de

Projetos

• SG1: Utilizar o processo definido para o projeto

– O projeto é conduzido utilizando um processo que é

adaptado a partir do processo organizacional

• SG2: Coordenar e colaborar com os stakeholders

relevantes

– Coordenação e colaboração do projeto junto aos

stakeholders relevantes

Estabelecer e gerenciar o projeto e o envolvimento dos

stakeholders relevantes de acordo com um processo

integrado, definido e adaptado a partir do processo

da organização


Gerenciamento de Riscos

• SG1: Preparar para a gestão dos riscos

• SG2: Identificar e analisar riscos

– Os riscos são analisados quanto a sua importância relativa no contexto do projeto

• SG3: Mitigar riscos

– Os riscos são mitigados a fim de diminuir o seu impacto no projeto ou mesmo a fim de reduzir sua probabilidade de ocorrência

Identificar problemas potenciais antes que eles ocorram,

de forma que as atividades para evitar os riscos possam

ser executadas antes que o projeto sofra grandes impactos


Gerenciamento Integrado de

Fornecedor

• SG1: Analisar e selecionar fontes de produtos /

componentes

• SG2: Coordenar o trabalho com os fornecedores

– Garantir que o contrato será executado de forma apropriada

Identificar proativamente produtos e/ou componentes

que possam ser usados para satisfazer requisitos do projeto

e gerenciar os fornecedores selecionados de forma cooperada


Análise de Decisão e

Resolução

• SG1: Avaliar alternativas

– Decisões são baseadas em uma avaliação de alternativas

através de um critério estabelecido

Analisar possíveis decisões através de um processo

de avaliação formal que avalia alternativas identificadas

com base em critério estabelecido

Aplicabilidade da área de processo DAR

Guidelines documentados devem ser definidos para determinar quando um processo de avaliação formal precisa ser aplicado

Os guidelines devem sugerir a utilização do processo formal sempre os itens de ação estiverem relacionados a riscos de médio ou alto impacto ou quando os desvios afetarem a capacidade do projeto de atender seus objetivos


Á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




• Progresso e problemas são medidos• A gerência tem bases objetivas para tomada de decisão

In Out


% Esforço Organizacional

0%

20%

40%

60%80%

100%

120%

140%

160%

Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez

% E

sfo

rço

Org

. % Esforço

Organizacional

Goal

UCL

LCL

Nível 4: Endereçando as

causas especiais de variação...

Variações especiais



Performed

Managed

Defined

Optimizing


• Performance do Processo Organizacional

• Gerenciamento Quantitativo de Projetos


Performance do Processo

Organizacional

• SG1: Estabelecer Baselines de

Performance e Modelos Estatísticos

Estabelecer e manter um entendimento quantitativo

da performance do processo padrão da organização (e assets)

para suportar a qualidade e objetivos de performance do

processo, e prover dados de performance do processo,

baselines e modelos para gerenciar quantitativamente os

projetos da organização


Gerenciamento Quantitativo

de Projetos

• SG1: Gerenciar quantitativamente o projeto– O projeto é gerenciado quantitativamente através dos

objetivos de qualidade e performance

• SG2: Gerenciar estatisticamente os sub-processos do projeto– Alguns sub-processos do processo definido do projeto são

gerenciados com técnicas estatísticas

Gerenciar quantitativamente os processos definidos do projeto

a fim de alcançar os objetivos de qualidade e performance

do projeto



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

“A Melhoria de processo contínua e “mensurável” é um estilo de vida...”

In Out


% Esforço Organizacional

0%

20%

40%

60%

80%

100%

120%

140%

Jan Fev Mar Abr Mai Jun Jul Ago Set Nov Dez

% E

sfo

rço

Org

. % Esforço

Organizacional

Goal

UCL

LCL

Nível 5: Endereçando as

causas comuns de variação...

Variações Comuns



Performed

Managed

Defined

Optimizing


• Desenvolvimento e Inovação Organizacional

• Análise Causal e Resolução


Desenvolvimento e Inovação

Organizacional

• SG1: Selecionar Melhorias– Processos e inovações que contribuem para o atendimento

dos objetivos de qualidade e da performance do processo são selecionadas

• SG2: Implantar as Melhorias– As melhorias mensuráveis são incorporadas aos processos

e tecnologias da organização de forma contínua e sistemática

Selecionar e implantar melhorias inovadoras de forma incremental

Que de forma mensurável melhoram os processos e

tecnologias da organização. As melhorias suportam os objetivos

de qualidade e da performance do processo da organização

derivados dos objetivos de negócio.


Análise Causal e Resolução

• SG1: Determinar as causas dos defeitos

– As causas que geraram os defeitos e outros problemas são

identificadas

• SG2: Endereçar as causas dos defeitos

– Ações são tomadas nas causas dos problemas para evitar

que os mesmos voltem a acontecer

Identificar as causas dos defeitos e de outros problemas e tomar

ações corretivas para prevenir que os mesmos voltem a

ocorrer no futuro


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


Clientes

Necessidades

Fronteira

Produtos e Serviços

Atendimento

OrganizaçãoRecursos

Processos

Áreas de resultados


Clientes

Necessidades

Fronteira


Atendimento


Processos

Impactos: a mudança da

realidade da clientela

são atendidas através de...

que são gerados pelos...

Áreas de resultados – de fora para dentro


Clientes

Necessidades

Fronteira


Atendimento


Processos

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

Processos mais eficazes de gerenciamento de portfólio

O novo padrão do PMI

The Standard for Portfólio Management

É a PONTE, que liga as

estratégias organizacionais

com os projetos.


../../PMI/Standards/Portfolio_unprotected.pdf

../../PMI/Standards/Portfolio_unprotected.pdf

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

• As PRIORIDADES estão freqüentemente mudando.3

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


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.

DEFINIÇÃO


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

Objetivos estratégicos alcançados

Redução do ciclo de vida dos projetos

Retorno adequado dos investimentos

Rentabilidade do portfólio de acordo

com a esperada

Gerenciamento de

PORTFÓLIOGerenciamento de

PROJETOS


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®


“Certamente não há nada tão inútil quanto fazer com grande eficiência algo que nunca deveria ter sido feito”.

Peter Ducker

GOVERNANÇA ORGANIZACIONAL

Trata-se do ato de

desenvolver, comunicar,

implementar, monitorar e

assegurar as políticas,

procedimentos, estruturas

organizacionais e práticas

associadas a um portfólio.

O resultado é um ambiente

para tomada eficaz de

decisões.


GOVERNANÇA ORGANIZACIONAL




Plano Estratégico

•Objetivos estratégicos

•Metas

•Critérios de

desempenho

•Definição de

capacidade

Identificação

Categorização

Avaliação

Seleção

Priorização

Balanceamento

do Portfólio

Autorização

Revisão do

Portfólio e

Comunicação

Mudança

Estratégica

Execução dos

componentes

sim

não

Plano Estratégico atual

da Organização

Grupo de Processos de

Alinhamento

Grupo de Processos

de Monitoramento e

Controle

Processos dos

Componentes

Processos de Gerenciamento do Portfólio

VISÃO GERAL DOS PROCESSOS


PROCESSOS DE ALINHAMENTO

Identificação do componente

– Número, nome, descrição, etc.

Objetivos estratégicos apoiados

Benefícios quantitativos e qualitativos

Recursos requeridos

Cliente

Patrocinador

Stakeholders

Cronograma

Resultados tangíveis

Riscos

Identifi-

cação

Categori-

zaçãoAvaliação Seleção

Priori-

zação

Balancea-

mento

Autori-

zação

Componentes

inventariados e

documentados



Identifi-

cação

Categori-


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-


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-


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-


Priori-

zação

Balancea-

mento

Autori-

zação

Comparação gráfica baseada em dois critérios

baixo

médiobaixo

alto

alto

médio

Critério 2

Critério 1

Ir em frente

Cuidado

Finalizar



Identifi-

cação

Categori-


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-


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-


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-


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



O tamanho da bolha reflete

o custo do projeto.

As cores das bolhas

representam critérios.

As categorias 4 e 5 contam

com apenas dois projetos.

A unidade de negócio 1

possui somente um projeto

na categoria de

investimentos 2.

Cada critério parece ter

uma correlação direta com

a unidade de negócio.

Identifi-

cação

Categori-


Priori-

zação

Balancea-

mento

Autori-

zação

Investimentos nas Categorias1 2 3 4 5

Unid

ades

de N

egócio

1

2

3

4

5

6

Investim

ento

s para

Unid

ade d

e N

egócio

1

2

3

4

5

6

Projetos por Categoria

1 2 3 4 5

Um método gráfico





• Aprovação final dos stakeholders chave:

– Decisões sobre inclusão de

componentes;

– Autorizações, desativações ou

finalizações de componentes

selecionados;

– Realocação de orçamentos e de recursos

de componentes inativos/finalizados;

– Alocações de recursos financeiros e

humanos aos componentes selecionados;

– Comunicação sobre os resultados

esperados para os componentes

selecionados.

Identifi-

cação

Categori-


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

Identificação

Categorização

Avaliação

Seleção

Priorização

Balanceamento

do Portfólio

Autorização

Revisão do

Portfólio e

Comunicação

Mudança

Estratégica

Execução dos

componentes

sim

não

Plano Estratégico atual

da Organização

Grupo de Processos de

Alinhamento

Grupo de Processos

de Monitoramento e

Controle

Processos dos

Componentes

Processos de Gerenciamento do PortfólioMONITORAMENTO E CONTROLE


REVISÃO DO PORTFÓLIO E COMUNICAÇÃO

Informações consistentes

e precisas

Planejamento

Estratégico

Operações Gerenciamento

do Portfólio

Gerenciamento

de Programas e

Projetos

Identificação,

categorização,

avaliação, seleção,

priorização,

balanceamento e

autorização de

componentes do

Portfólio

Revisão do desempenho

do Portfólio

Revisão do desempenho

de Programas e Projetos

Processos

Visão, Missão e

Plano Estratégico

Entregas concluídas

para operações

Solicitações de

Programas e

Projetos


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.


../../PMI/Standards/Program_unprotected.pdf

../../PMI/Standards/Program_unprotected.pdf

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.


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.


UM EXEMPLO DO GOVERNO

DE MINASVisão de Futuro

Opções

Estratégicas

Tornar Minas

Gerais o

melhor Estado

para se viver

10

Objetivos

Estratégico

s

31

Programas

Estruturadore

s

Artigo publicado na revista Mundo

PM www.alvarofpinheiro.eti.br

Programas estruturadores (exemplos)

2 Corredores Radiais de Integração e

Desenvolvimento

Reduzir o “custo de transporte” e aumentar...

5 Saneamento Básico: Mais Saúde para Todos

Ampliar a cobertura dos sistemas públicos...

10 Modernização da Receita Estadual

Alavancar as fontes de receita do Estado...

12 Regionalização da Assistência à Saúde

Adequar a oferta de serviço à demanda...

27 Arranjos Produtivos Locais

Desenvolvimento dos arranjos produtivos...

Projetos

Atividade

s

Programas

UM EXEMPLO DO GOVERNO DE MINAS


Pilares para o gerenciamento

ME

TO

DO

LO

GIA

INF

OR

MA

TIZ

AÇ

ÃO

ES

TR

UT

UR

A

OR

GA

NIZ

AC

ION

AL

COMPETÊNCIAS

GP

UM EXEMPLO DO GOVERNO DE MINAS


Aumento do nível de execução dos projetos

Previsibilidade e controle sobre os resultados

Conhecimento e gestão dos riscos

Visibilidade das atividades necessárias

Comprometimento do coordenador e da equipe

com as metas dos projetos

Melhoria da gestão de licitações, contratos e

convênios

“Consideramos a ferramenta de GP extremamente oportuna para aumentar a eficiência da gestão dos gastos do setor público e ampliar a contribuição deste

setor para o desenvolvimento nacional.”

Benefí

cio

sUM EXEMPLO DO GOVERNO DE MINAS


Projeto A

Projeto B

Projeto C

Projeto D

Projeto E

Benefícios

A1...n

Benefícios

E1...n

Benefícios discretos

Benefícios

coordenados

Programa

Gestão do

ProgramaBenefício

sBenefícios do

Programa

1...n

GERENCIAMENTO DE BENEFÍCIOS

Avalia o impacto

organizacional do

programa

Avalia as

interdependências dos

benefícios

Designa responsabilidades

pelos benefícios reais


Program Management - PMI®


GERENCIAMENTO DE PROGRAMAS NO

PLANEJAMENTO ESTRATÉGICO

Visão estratégica

Programas

Projetos

Mobilização Objetivos

estratégicosOpções estratégicasPortfólio estratégico

Set up Pre-

ProgramaSet up do

Programa

Infraestrutura

gerencial e técnica

para o Programa

Entrega de

benefícios

incrementais

Conclusão

do

ProgramaTransição

Operações

regulares


CICLO DE VIDA DO PROGRAMA

Set up

Programa

Infra-estrutura

gerencial e técnica

para o Programa

Entrega de benefícios incrementaisConclusão

do

Programa

Transição Operações

regulares

Entrega de

benefíciosPerfil de

Custos

Tempo

Cu

sto


CICLO DE VIDA DO PROGRAMA

• Fase 1 – Set up pré-programa

• Fase 2 – Set up do programa

• Fase 3 – Estabelecimento do gerenciamento do programa e infra-estrutura

técnica

• Fase 4 – Entrega de benefícios incrementais

• Fase 5 – Conclusão do programa

Fase 1 Fase 2 G2 Fase 3 Fase 4 Fase 5G1 G3 G4 G5

Governança do Programa


TEMAS DO GERENCIAMENTO DE

PROGRAMAS

• Gerenciamento de benefícios1

• Gerenciamento das partes interessadas do programa2

• Governança do programa3


Identificação Análise Planejament

o

Realização Transição

Identificar e

qualificar os

benefícios de

negócios

Derivar e

priorizar

componentes

Estabelecer

plano de

realização de

benefícios

Monitorar

componentes

Consolidar

benefícios

coordenados

Derivar

métricas de

benefícios

Estabelecer

monitoramento

de benefícios

Manter registro

dos benefícios

Transferir

responsabilidad

e para operação

Mapear

benefícios no

Plano do

Programa

Reportar

benefícios

GERENCIAMENTO DE BENEFÍCIOS


GERENCIAMENTO DAS PARTES

INTERESSADAS

Diretor de Programa

Gerente de Programa

Gerentes de Projetos

Patrocinador do Programa

Cliente

Organização executora

Membros de equipes

Escritório de gerenciamento de Programas

Comitê de Governança do Programa

“São indivíduos ou organizações cujos interesses podem ser

afetados pelos resultados do programa, positiva ou

negativamente”.


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

DE PROGRAMASIniciação Define e autoriza o programa ou um projeto dentro do

programa, gerando a declaração de benefícios do

programa e o plano de realização de benefícios.

Planejamento Planeja as melhores alternativas de ação para entrega

dos benefícios e escopo definidos para o programa.

Execução Integra projetos, pessoas e outros recursos para

execução do plano do programa e entrega dos

benefícios associados.

Monitoramento e

controle

Monitora o programa e projetos associados em

comparação com seus respectivos planos e benefícios

esperados, identificando variações e implementando

ações corretivas, quando necessário.

Encerramento Formaliza a aceitação de um produto, serviço ou

benefício, trazendo o programa ou um de seus

integrantes a um fim ordenado.


Fundamentos da Engenharia de Software

Technology

Transcript of Fundamentos da Engenharia de Software