Tutorial Pech

Como Gerenciar na Prática Projetos
de Desenvolvimento de Software
Gerson Pech
Universidade do Estado do Rio de Janeiro
15 de março de 1990
Gerson Pech - UERJ 2

Apenas 5 dias para:
Alterar o sistema de 420 instituições financeiras;
Cruzado Novo – Cruzeiro;
Bloqueio dos saldos das contas correntes e

cadernetas de poupança acima de CR$ 50,00;
Criação de novos tributos;
Criação de duas contas para cada cliente:

Uma podendo movimentar, a outra não.

Como foi a reabertura dos bancos?
Saldos não batiam;

Diversas informações desencontradas;
Alguns bancos nem puderam fornecer
os saldos;
Caos Total
Entretanto, as bases estavam lá

Uno mile online
• Aumento da demanda por carros
populares;
• Fiat lança novo modelo para a compra
de carros;
• Compra por telefone com prazos
determinados de entrega;
• O programa é um sucesso:
1o. VW 62% 22%
2o. Fiat 8% 30%

Uno mille off line
• Apenas 5% nas revendas ligadas por

3270 a fábrica;
• O resto se comunicando por fax;
• Entrada no sistema: Digitação;
• Retorno para a empresa com prazo de
entrega.

Antes de começar algumas lições
• Não bastam apenas processos padronizados;

• Não basta que toda a documentação esteja
institucionalizada;
• Não basta a tecnologia que será implantada;
O que importa é o uso que se faz de tudo isso!

Quem solicita um software sabe o
que quer?
Os usuários normalmente sabem exatamente o que
não precisam, depois de ver o software;
À medida que o sw se desenvolve, tornando-se
tangível, os usuários vêem novas possibilidades e
tentam mudar o projeto de acordo com elas;
Seu software fracassará se ele não for corretamente
utilizado ou não atender as especificações de seus
clientes.
S=P–E

Problemas de software
• Prazo estourados;
• Custo acima do esperado;
• Dificuldade/impossibilidade de
manutenção;
• Desempenho inadequado;
• Não faz o que deveria fazer ...

O que é gerência de projeto de
software?
Gerência de Projeto de Software é a

aplicação de conhecimento, habilidades,
ferramentas e técnicas no
desenvolvimento de software com o
objetivo de atender os requerimentos do
projeto.
Baseado no PMI – PMBook, 2000

www.pmi.org
Principal Dificuldade
Atingir
Atingir ou
ou exceder
exceder necessidades
necessidades
ee expectativas
expectativas
Balancear
Balancear demandas
demandas conflitante
conflitante

A Restrição Tripla
Escopo
Recursos Prazo

Stakeholders ?

O que são Stakeholders?
Todos aqueles que influenciam o

projeto.

Processo de Gerência de Stakeholders
Identificar os
controlando planejando
Stakeholders
Levantar
Informações
sobre os stk
Implementar
a gerência
dirigindo
Equipe
Prever o Identificar a
de
comportamento missão dos stk
dos stk Gerência
de sw
Identificar a Determinar
estratégia os pts fortes e
organizando
dos stk fracos dos stk
motivando
Nível de Atividade Ciclo de vida
Tempo
Concepção
• Identificação das necessidades;

• Definição do problema;
• Determinação dos objetivos, metas e
escopo;
• Análise do ambiente;
• Análise das potencialidades e recursos
disponíveis;

Concepção
• Estudo das viabilidades dos objetivos;

• Estimativa dos recursos necessários;
• Elaboração da proposta do projeto;
• Apresentação da proposta;
• Decisão (ou não) de execução.

Planejamento
• Detalhamento das metas e objetivos;

• Programação das atividades;
• Determinação dos pontos de controle
(milestones);
• Programação de recursos;
• Análise de Riscos;
• Elaboração do Plano de Projeto.

Planejamento de Qualidade de Software
ISO 9000-3 (Orientações)
Definição do ciclo de vida utilizado
Definição dos critérios para início e fim de

cada fase
Identificação dos tipos de análise crítica

Identificação dos procedimentos de gestão de
configuração, validação, verificação e testes

Planejamento
Planos para cada fase do desenvolvimento

Análise dos superiores hierárquicos e aprovação,
antes de entrar para a execução
Procedimentos para acompanhamento e análises
críticas periódicas pela gerência/clientes

Plano de Projeto
• Quanto detalhado deve ser o Plano de

Projeto?
• Quando deve ser iniciada a elaboração
do Plano de Projeto?
• Quem deve participar desta elaboração?
• Quem deve receber uma cópia do
Plano?
• Quem é o responsável final pelo Plano?

Plano de Projeto
• Sumário Executivo;
• WBS;
• Declaração de Escopo;
• Cronograma;
• Plano de Gerência de Custos;
• Plano de Qualidade;
• Plano de RH;
• Plano de Comunicação;
• Plano de Gerência de Riscos;
• Plano de Responsabilidades;
• Plano de Avaliação para o Fechamento do Projeto.

WBS (Work Breakdown Structrure)
Estrutura de Desmembramento do Projeto
• Identifica todas as tarefas do projeto;

• Fornece uma ilustração detalhada do
escopo do projeto;
• Monitora o progresso do projeto;
• Facilita o entendimento das
responsabilidades de cada membro de
equipe;

WBS
Desmembrar o projeto em unidades de

trabalho menores que tenham
significado e que sejam gerenciáveis.

Desenvolvimento do Sistema Acadêmico
Desenv. do
Planej. de
Turmas Desenv. da Desenvolv. do Desenvolv. do
Inscrição em Controle Acadêmico Controle Curricular
discip.
Realizar Análise
de Requisitos
Modelar Codificar Testar Implantar
Identificar
usuários
Desenvolver Implementar Realizar os Treinar usuários
o modelo programas testes
funcional internos
Entrevistar
Desenvolver Codificar Realizar Apresentação
o modelo de conversão de testes no
dados dados usuário
Documentar
e Elaborar projeto Realizar Gerar versão
apresentar físico piloto

27 01
Id Nome da tarefa Início Término T Q Q S S
1 INSCRIÇÃO - REQUERIMENTOS DE IN Ter 2/13/01 Sex 5/4/01
2 Atualizar DADOS VESTIBULAR - Pa Ter 2/13/01 Ter 2/13/01
3 Emitir REQUERIMENTO DE INSCRI Ter 2/13/01 Seg 2/26/01
4 Registrar REMESSA DE REQUERIM Ter 2/13/01 Sex 3/23/01
5 Informar REQUERIMENTO DANIFIC Ter 2/13/01 Sex 5/4/01
6 Substituir REQUERIMENTO DE INS Ter 2/13/01 Sex 3/23/01
7 INSCRIÇÃO DE CANDIDATOS Ter 3/13/01 Sex 3/23/01
8 CADASTRAMENTO BÁSICO Ter 3/13/01 Seg 4/2/01
15 CADASTRAMENTO DO EDITAL Ter 3/13/01 Qui 5/3/01
21 DIGITAÇÃO E DIGITALIZAÇÃO Seg 4/2/01 Ter 4/17/01
25 INSCRIÇÃO - ATUALIZAÇÃO DE CADA Ter 4/3/01 Qua 4/11/01
32 IDENTIFICAÇÃO E CORREÇÃO DE NÚ Ter 4/3/01 Qua 4/11/01
38 INSCRIÇÃO - ATLZ DO CADASTRO DE Qua 4/11/01 Ter 4/17/01
47 CADASTRAMENTO DE SALAS Seg 4/2/01 Ter 4/17/01
55 ALOCAÇÃO DE CANDIDATOS Qua 4/18/01 Ter 4/24/01
67 RETIF. E 2a VIA CARTÃO CONFIRMAÇ Sex 4/27/01 Sex 5/4/01

Planejamento
Limitações
Escopo
Atribuir e
Criar sequência Calcular o
Redistribuir
para as tarefas cronograma
Criar recursos
WBS
Gerência de Estimar recursos

Desenvolver
Riscos para as tarefas
orçamento
Regras Plano do
Projeto
Execução
• Execução das etapas previstas no plano

de projeto;
• Utilização dos recursos conforme
programado;
• Solução dos conflitos;
• Metas.

Finalização
• Finalização formal;
• Gestão de Conhecimento;
• Re-alocação dos recursos;

Ciclo de vida
Custo para
Consertar um erro
Riscos e
Incertezas
Nível de Atividade
Tempo
Processos de Gerência
Uma série de ações que geram um

resultado padronizado essencial para o
desenvolvimento do software;

Grupos de Processos - PMI
Processos de Iniciação;
Processos de Planejamento;
Processos de Execução;
Processos de Controle;
Processos de Encerramento

Processos de
Iniciação Processos de
Planejamento
Processos de
Processos de
Controle
Execução
Processos de
Encerramento

Controle – Reuniões de Análise Crítica
http:/www.abnt.org.br
Verificação do andamento do projeto com

relação ao cronograma de desenvolvimento
Verificação das pendências do próprio cliente
Verificação da adequação dos produtos
desenvolvidos com relação ao especificado
Verificação do andamento do treinamento e
conversão de dados
Testes de aceitação
Controle – Medição
ISO 9126 (Definições)
Eficiência
Funcionalidade
Confiabilidade Manutenibilidade
Usabilidade Portabilidade
• Propõe-se a fazer o que devia?
• Gera resultados conforme

acordados?
• É capaz de interagir com os
Funcionalidade sistemas especificados?
• Evita acesso não autorizado,
acidental a programas e dados?
• Está de acordo com normas e
convenções previstas em lei e
descrições similares?

• Com que frequência apresenta

falhas?
• Ocorrendo falhas como ele

reage?
Confiabilidade
• É capaz de recuperar dados
depois de uma falha?

• É fácil entender os conceitos

utilizados?
• É fácil aprender a usar?

Usabilidade
• É fácil de operar e controlar a
operação?

• Qual o tempo de resposta e

de processamento?
• Quanto recurso utiliza?

Eficiência
• Os recursos e os tempos são
compatíveis com o nível de
desempenho requerido?

• É fácil encontrar uma falha

quando ela ocorre?
• É fácil modificar e remover

defeitos?
Manutenibilidade • Há grandes riscos de bugs

quando se faz uma alteração?
• É fácil testar quando se faz

uma alterações?

• É fácil adaptar a outros ambientes

sem aplicar outras ações ou meios
além dos fornecidos para esta
finalidade ?
• É fácil instalar em outros ambientes?

Portabilidade
• É fácil substituir por outro software?
• Está de acordo com padrões ou

convenções de portabilidade?

Nível de Atividade
Execução
Planejamento
Controle Final.
Iniciação
Tempo
Controle das alterações
Plano de Plano de Projeto

atualizado
Projeto
Ações corretivas
Relatório de
desempenho
Lições aprendidas
Requisições de
mudança

Alterações de Requisitos
ISO 9000-3
(Orientações)
É comum que requisitos não estejam

completos durante a assinatura do contrato de
desenvolvimento, mas as mudanças
posteriores devem ter o seu impacto
devidamente registrados no contrato.
Gerenciamento dos Riscos
O gerenciamento dos riscos é o meio pelo qual a

incerteza é sistematicamente gerenciada para
aumentar a probabilidade de cumprir os objetivos
do projeto.

Gerenciamento de Riscos
Desenvolvimento
Identificação de Respostas Controle
dos Riscos
Riscos novos Riscos novos

Identificação Desenvolvimento
dos Riscos de Respostas Controle

Identificação dos Riscos
Perguntar aos participantes;
Sessões de criação de idéias;
Crie a maior lista possível de riscos potenciais;
Combine os riscos semelhantes
Tudo que pode dar errado dará errado

Lei de Murphy

Como Identificar os Riscos?
• Aprenda a partir de projetos de

desenvolvimento antigos
Perfil de Riscos
São específicos a uma determinada área;
São específicos a uma determinada
organização;
Devem ser atualizados.

Equipe do Projeto
• Quantas pessoas tem a equipe?

• Que percentual da equipe está dedicada
integralmente ao projeto?
• Que membros da equipe irão gastar menos que
20% de tempo trabalhando no projeto?
• Qual o nível de experiência da equipe?
• Os membros da equipe já trabalharam juntos
antes?
• A equipe está geograficamente espalhada?
• Quais os membros da equipe que
poderão abandonar o projeto?

Cliente
• O cliente irá mudar seus processos atuais para

utilizar o sistema?
• O sistema para ser utilizado precisará de
reorganização do cliente?
• Os clientes são de departamentos diferentes?
• Existe sistema atual para as funcionalidades que
serão desenvolvidas?
• Existe resistência por parte do usuário?

Tecnologia
• A tecnologia que será usada é novidade para a

equipe de desenvolvimento?
• A tecnologia que será usada é novidade para a
clientes e usuários?
• Existe alguma tecnologia de ponta no projeto?
• A equipe possui maturidade para o
desenvolvimento de sistemas dessa complexidade?
• Existem ferramentas disponíveis para o trabalho?
Perfil de Riscos – SEI

Continuous Risk Management Guidebook
http://www.sei.cmu.edu/

Realize Registros Históricos
• Desempenho: Planejado X Real;

• Problemas relativos a mudanças
inesperadas; e como elas foram
transportadas;
• Análise após o fim do projeto;
• Satisfação do cliente.

Desenvolvimento
Identificação de Respostas Controle
dos Riscos

Como Desenvolver uma Estratégia de
Resposta
1o passo: Defina a gravidade do risco;

Qual o impacto do risco?
2o passo: Atribua uma probabilidade;

Qual a probabilidade do problema ocorrer?
3o passo: Desenvolva uma estratégia para

reduzir um possível dano.

Risco maldefinido:
O projeto de desenvolvimento exige o uso de
uma nova tecnologia.
Melhor:
O departamento de RH exige que o acesso ao
sistema se dê através da Web. Os programadores
do departamento de informática ainda não
desenvolveram programas nessa tecnologia.

Definição Risco: Os usuários nunca utilizaram leitoras de código de barra,
ferramentas que serão as componentes de entrada de dados para o
processamento.
Conseqüência: A utilização incorreta irá introduzir erros na base. Estes
erros poderão causar retrabalho de até três dias para a equipe causando
Probabilidade
atraso no prazo final de entrega dos relatórios finais.
Probabilidade de retrabalho de 1d. – 20% - R$ 10.000,00

Probabilidade de retrabalho de 2d. – 10% - R$ 20.000,00 grave
Probabilidade de retrabalho de 3d. – 5% - R$ 30.000,00 ...
Enviar todos os operadores para um curso intensivo;

Estratégia
R$ 2.000,00 – 2d
Contratar o fornecedor para suprir dois ou três operadores especializados;
R$ 600,00 /d/op

Definição Risco: mudanças nas leis que regulamentam as aplicações financeiras
introduzirão novas exigências no projeto de desenvolvimento do sw.
Conseqüência: O software não mais irá atender aos requisitos

estabelecidos pelo usuário.
Probabilidade
30% no final de um semestre – Dados históricos;
Analisar com todos os detalhes todas as mudanças ocorridas nos últimos

Estratégia
quatro anos;
Deixar o sistema parametrizado/generalizado para as principais mudanças;
Tempo: + 2,5 meses
Custo: + 280.000,00
Como prevenir as conseqüências dos riscos?
• Aceitar
• Evitar
• Monitorar e preparar os planos de contingência
• Transferir
• Mitigar
Contratos fixos também têm riscos:

• Você pode ser cobrado a mais;
• Os terceirizados podem ter subestimado
os custos;

Terceirizar um serviço especializado
Risco Terceirizado
Terceirização Falta de controle no projeto

Dificuldade de comunicação

Avaliação de Riscos
Para cada risco:
{ri , Pi , Ii }
ri iésimo risco
Pi prob. do ri ocorrer
Ii impacto de ri
Curva de Segurança
Impacto
ri
I1
I2
P1
P2
Probabilidade
Impacto
Perigo
Risco controlável
Probabilidade

MA 2 2 23 24 2
1 2 5
A 16 1 18 19 20
7
M 11 1 1 14 15
2 3
B 8 9 10
6 7
MB 1 2 3 4 5
MB B M A MA

Identificação Desenvolvimento
dos Riscos de Respostas Controle

Controle dos Riscos
Executar uma estratégia contra os

riscos;
Monitorar os riscos;
Vigiar novos riscos;
Documentar os problemas.

Os Erros Clássicos
“Nunca esquecem, e nunca aprendem”

• 70% dos grandes projetos sofrem de instabilidade dos requisitos;
• Pelo menos 50% dos projetos são executados com níveis
de produtividade abaixo da normal;
• Pelo menos 25% dos sw de prateleira e 50% dos feitos
por encomenda apresentam mais defeitos do que o
razoável;
• Produtos feitos sob pressão de prazos podem quadruplicar
o número de defeitos;
• Pelo menos 50% dos grandes projetos de sw estouram
seu orçamento e prazo;
• 2/3 dos projetos de sw muito grandes são cancelados antes
do fim;
• Tipicamente 50% do patrimônio de sw da empresa não
são utilizados;
• Atritos entre a área de TI e a alta gerência ocorrem em mais de
30% das organizações;
• Atritos com os clientes ocorrem em 50% dos contratos por
administração e 65% dos contratos por empreitada.
Base 4.000 projetos – Assessment and Control of Software Risks – Prentice-Hall

Capers Jones
Erros Estratégia
Requisitos: Análise detalhada de novos requisitos
Características
interessantes Análise de impacto
Requisitos:
Adição descontrolada de
novos requisitos Acabar com a inércia na tomada de
decisões
Prazos:
Desperdício antes do início Controle das pressões de clientes e da
alta gerência com a demonstração de
Prazos:
dados históricos e do plano do projeto
Prazos excessivamente
otimistas Definir as estimativas corretas e
Planejamento: terminar com o excesso de otimismo
Incompleto e insuficiente
Falta de controle gerencial para Estabelecimento de marcos claros e

cumprir o planejado acompanhamento das atividades de perto
Para o cumprimento de prazos As atividades planejamento dos

impossíveis, abandono dos testes, garantia de qualidade não
planos devem ser cortadas
Erros Estratégia
Codificação desenfreada
Aumentar a qualidade técnica dos
Falha de subcontratados produtos da análise. Modelo físico.
Procedimentos de controle das tarefas
realizadas pelos subcontratados
Conseguir autorização para adiamento
Entrega prematura do produto dos prazos. Atenção nunca usar a
Estratégia Vietnã.
O comprometimento dos sponsors deve
Falta de patrocínio eficaz ser trabalhado através de reuniões e
apresentações
Falta de participação das Torna-las parte do projeto. Mostrar que
partes interessadas no produto se o projeto sair vitorioso, será por causa
do deles.
Atritos entre os desenvolve- Gestão das expectativas dos
dores e os clientes/usuários clientes/usuários
Defeitos de formação do staff Métodos adequados de seleção.
do Projeto. Desenvolvedores mais experientes
podem treinar os novatos. Cuidado com
o aumento de profissionais.
Erros Estratégia
Salas apinhadas e barulhentas Organização do ambiente para o
aumento da concentração
Falta de motivação dos
desenvolvedores Programa de avaliação baseado em
metas reais e desafios profissionais
Estimativa exagerada dos O importante não é a tecnologia , mas

ganhos de produtividade Como ela será utilizada
Mudança de ferramenta no Mudanças de tecnologia devem ser

meio do projeto (sw/hw) avaliadas, planejadas e introduzidas
fora da pressão dos prazos
Ferramentas para automatizar a gestão

Falta de automação de de configurações.
algumas atividades Ferramenta para a modelagem.
A execução e controle dos testes
precisa ser automatizada.
Problemas Comuns
Base: Princípios e Técnicas

de Gerência de Projetos - FGV

1o Problema Comum:
Responsabilidade além da sua autoridade
Você é o gerente de desenvolvim ento e

possuiem sua equipe analistas que não estão
sob a sua gerência direta e nem sob a
gerência do Sponsor do projeto.C om o
transform a-los em um tim e que responda,com
entusiasm o e confiança,pelo projeto?
1o Problema Comum:
Sugestões:
Project Charter: Publicação pelo sponsor.

Ênfase na autoridade do PM.
Razão do Projeto: Explicação para a equipe da

importância do projeto.
Sponsor: Informação.

1o Problema Comum:
Sugestões:
Deliverables: Importância e responsabilidade

dentro do projeto.
Diagrama de Rede: Conexão e integração entre as

atividades de todos.
Plano de Comunicação: Participação máxima da

elaboração.

2o Problema Comum:
O Salvador da Pátria
O projeto está um com pleto desastre.C

ronogram a atrasado,orçam ento
estourado,cliente insatisfeito, grande pressão
interna.Porisso,o PM foidem itido e
você assum e o seu lugar.O que fazer?
2o Problema Comum:
Sugestões:
Análise Financeira: Decisão go/no go.
Objetivos e Escopo: Quais os objetivos do projeto?

Priorize o que falta do escopo.
Esclareça as penalidades.
Time: Ouça o que eles tem a dizer.

Alternativas podem surgir

2o Problema Comum:
Sugestões:
Novo Cronograma:
Refaça a análise do caminho crítico supondo todos os
recursos necessários.
Negocie mais tempo, mais recursos e menos escopo.
Esteja 100% seguro antes de entregar o seu 1o
Cronograma.
Faça reuniões freqüentes e pequenas focadas nos
resultados e marcos. Celebre pequenas vitórias.

3o Problema Comum:
Estimativas Impossíveis
Você foidesignado para um projeto com tarefas

m uito difíceis de serem estim adas.Apesarde
fazer parte dos processos já definidos,você
não quer divulgarum cronogram a,porque sem
pre acontece algum a coisa que aum enta em
30% ou 40% suas estim ativas.O que fazer?

3o Problema Comum:
Estimativas Impossíveis
Sugestões:
Estimativas por fases: Não vá além do que está em

seu horizonte.
Tarefas Pequenas: Isole as tarefas mais imprevisíveis.
Dados Históricos: Pesquise se existem riscos comuns

com projetos passsados.

4o Problema Comum:
Time to Market
Você é obrigado a terum tem po de

desenvolvim ento de softw are 25% m enordo
planejado.Entretanto,
a funcionalidade e recursos não podem
seralterados. O que fazer?
4o Problema Comum:
Time to Market
Sugestões:
Base: Comece construindo uma base

sólida.
Fases Distintas: Não detalhe o cronograma até o

final. Trabalhe por fases.
Plano do Projeto: Construa o plano por fases

contendo planos de qualidade.

Programa de Melhoria de
Processos

Programa de Melhoria de Processos - Condições
• Forte apoio da alta administração;

• Gerentes devem ter participação ativa;
• Envolvimento de todos;
• Processos atuais devem ser conhecidos;
• Investimentos;
• Estágios intermediários com pontos de
controle.
Engenharia de software
Wilson de P. Paula. LTC Ed.
Prog. de Melhoria de Processos - Estabilização
• Formação de grupos de MP;

• Formação de estruturas
organizacionais;
• Desenvolvimento de recursos de apoio;
• Treinamento, orientação,
aconselhamento e comunicação;
• Medições do grau de progresso;

Os Personagens
• Campeões;
• Patrocinadores;
• Agentes.

Fase Atividade
s
Motivação
Início Patrocínio
Infra-estrutura
Aferições
Diagnóstico
Recomendações
Priorização
Estabeleciment Abordagem
o Planejamento
Criação da solução
Ação Testes-piloto
Refinamento
Análise e Validação
Lições
Proposição de ações futuras
Processos – ISO 12207
FUNDAMENTAIS APOIO
Documentação
Aquisição
G. de Configuração
Fornecimento Garantia de Qualidade
Verificação
Operação Validação
Desenvol
- vimento Revisão Conjunta
Manutençã Auditoria
o Resolução de Problemas
Organizacionais
Gerência Infra-estrutura
Melhoria Treinamento
CMM – Modelo de Maturidade de
Capacitação para Software
http://www.sei.cmu.edu/cmm
SEI – Carnegie Mellon University

Pittsburgh, Penn EUA
Criado em 1984 pelo DoD
“Melhorando o processo é possível melhorarmos

o software.”

O que é Maturidade de Capacitação?
• Assegurar a gerenciabilidade do
projeto
• Assegurar a qualidade do produto
gerado
• Assegurar a adaptação do processo
às características específicas da
empresa
• Assegurar melhora contínua.

CMM – Caminho de Melhoria Evolutiva
5o. Otimizado – Melhoria contínua

do processo.
4o. Gerenciado – Processos e produtos são
quantitativa// compreendidos e controlados.
3o. Definido – Processo padronizado e integra-
do em um processo padrão p/ a organização.
2o. Repetível – Processos básicos de gestão são

definidos.
1o. Inicial – Poucos processos são definidos. Sucesso
depende do esforço individual.
Nível 1 - Inicial
Planejamento ineficiente
Compromissos reativos
Faltam práticas de gestão Abandono aos

procedimentos
planejados
Processos
constantemente
Alterados
Desempenho imprevisível

Visibilidade da Gerência no Nível 1
IN OUT

Nível 2 - Repetível
Estabilidade: das políticas de gestão e

dos procedimentos para implementá-las
Experiência Adquirida Controle de custos, cronogra-

ma e funcionabilidade
Institucionalização dos Problemas com

processos compromissos
são identificados
IN OUT

Nível 3 - Definido
Práticas de ES efetivas - SEPG
Processo de sw
Programa de Qualidade
padrão para a
Treinamento controlada
organização
Processo de sw definido do
projeto

IN OUT

Nível 4 - Gerenciado
Metas quantitativas de
Metas quantitativas de qualidade para os processos
qualidade para os produtos
O processo opera dentro

Gestão do de limites mensuráveis
conhecimento
Capabilidade previsível
Produtos de alta qualidade
IN OUT

Nível 5 – Em Otimização
A organização está voltada para a melhoria
contínua do processo
Identificação das oportunidades
Análise de custo/benefício de novas tecnologias
Análise das falhas para determinar as causas
Lições são disseminadas

IN OUT
5
1
Probabilidade
Tempo/Custo
SPICE – Software Process Improvement and
Cabability dEtermination - ISO 15505
Seis Níveis de Capabilidade – Escala crescente

Qualquer processo pode estar em qualquer nível
Nível Processo
0 Incompleto
1 Executado
2 Gerenciado
3 Estabelecido
4 Previsível
5 Otimizado

A Estrutura do CMM

indica
Ní v el d e M
N ív e ld e M a Contém
at uri d a d e
tu rid a d e
Capabilidade
Ár e as C h
do processo Á r ea av se Cs dh
alcança
a v e sd e Organizado
e por
Pr o c e
P ro c e s
ss o
so
Metas encaminha
as
C ar a ct e sC o m
C ar ír sa tci tce C o m u
rís tic a u ns
n s
Contém
Institucionalização descreve Pr áti c a s C h

P rá tic a s C h
a v es
a v e s
Infraestrutura ou
atividade

do processo.

definidos.
Áreas-chave de Processo do Nível 2
Gestão de Requisitos
Planejamento de Projeto de Software
Acompanhamento e Supervisão de Projeto de Software
Gestão de Subcontratação de Software
Garantia de Qualidade de Software
Gestão de Configuração de Software

Metas
Meta 1 Os requisitos de sistema alocados ao sw são

controlados para estabelecer um baseline para
o desenvolvimento de sw e para uso
gerencial.
Meta 2 Os planos, os produtos e as atividades de

software são mantidos consistentes com os
requisitos de sistema alocados ao software.
Práticas Chave
Compromisso 1 O projeto segue uma política

estabelecida pela organização para o
gerenciamento de requisitos de
sistema alocados ao software.

Práticas Chave
Habilidade 1 Para cada projeto é definida a

responsabilidade pelos RS e sua alocação
ao hw, ao sw a aos outros componentes
do sistema.
Habilidade 2 Os requisitos alocados são

documentados.
Habilidade 3 Recursos e orçamentos adequados são

providos para a gerência dos requisitos
alocados.

Práticas Chave
Habilidade 4 Os membros da equipe de

desenvolvimento de sw e outros grupos
de sw relacionados são treinados para
realizar suas atividades de GR.

Práticas Chave
Atividade 1 A equipe de desenvolvimento revisa os

requisitos alocados antes deles serem
incorporados ao projeto de sw.
Atividade 2 A equipe de desenvolvimento deve utilizar os

requisitos alocados como base para os planos,
para os produtos e para as atividades de sw.
Atividade 3 As modificações nos requisitos alocados são

revisadas e incorporadas ao projeto.

Práticas Chave
Medições e As medições são realizadas e utilizadas

Análises 1 para determinar a situação das
atividades de gestão de requisitos

Práticas Chave
Verificação 1 As atividades de GR são revisadas
periodicamente por um gerente superior.
Verificação 2 As atividades de GR alocados são

revisadas pelo gerente de projeto, tanto
periodicamente,como motivadas por
um evento.
Verificação 3 A equipe de garantia da qualidade de sw

deve revisar e/ou proceder à auditoria
das atividades e dos produtos da GR
alocados e reportar os resultados.
Gestão de Requisitos:
Procedimentos
Cadastramento
Cadastramento Rastreamento
Rastreamento
Al t e r a ç õ e s
A lt e r a ç õ e s
Númer Nome do requisito Tipo Importânci Complexidad Estabili a
o a e d d
e
1 Interface de usuário Tela de Abertura do Caixa Interface Essencial Baixa Média
2 Interface de usuário Tela de Compras Interface Essencial Média Média
3 Interface de usuário Tela de Estoque Interface Desejável Média Baixa
4 Interface de usuário Tela de Fechamento do Caixa Interface Essencial Baixa Média
5 Interface de usuário Tela de Fornecedores Interface Essencial Média Baixa
6 Interface de usuário Tela de Mercadorias Interface Essencial Média Alta
7 Interface de usuário Tela de Nota Fiscal Interface Desejável Baixa Alta
8 Interface de usuário Tela de Pedidos de Compras Interface Opcional Baixa Baixa
9 Interface de usuário Tela de Relatórios Interface Essencial Baixa Baixa
10 Interface de usuário Tela de Usuários Interface Essencial Baixa Média
11 Interface de usuário Tela de Vendas Interface Essencial Alta Média
12 Interface de usuário Relatório de Estoque Baixo Interface Desejável Média Baixa
13 Interface de usuário Relatório de Fornecedores Interface Desejável Média Baixa
14 Interface de usuário Relatório de Mercadorias Interface Desejável Média Alta
15 Interface de usuário Nota Fiscal Interface Essencial Média Baixa
16 Interface de usuário Pedido de Compra Interface Opcional Baixa Baixa
17 Interface de usuário Relação de Pedidos de Compra Interface Opcional Média Média
18 Interface de usuário Ticket de Venda Interface Essencial Média Média
19 Interface de software Sistema Financeiro Interface Desejável Média Média
20 Caso de uso Abertura do Caixa Caso de uso Essencial Baixa Média
21 Caso de uso Emissão de Nota Fiscal Caso de uso Desejável Média Média
22 Caso de uso Emissão de Relatórios Caso de uso Essencial Baixa Baixa
23 Caso de uso Fechamento do Caixa Caso de uso Essencial Baixa Média
24 Caso de uso Gestão de Fornecedores Caso de uso Essencial Média Baixa
25 Caso de uso Gestão de Mercadorias Caso de uso Essencial Média Média
26 Caso de uso Gestão de Pedidos de Compra Caso de uso Opcional Baixa Baixa
27 Caso de uso Gestão de Usuários Caso de uso Essencial Baixa Média
28 Caso de uso Gestão Manual de Estoque Caso de uso Desejável Média Baixa
29 Caso de uso Operação de Venda Caso de uso Essencial Alta Média
30 Requisito de desempenho Tempo de resposta Não Desejável Baixa Alta
funcional
31 Restrição ao desenho Padrão de Nota Fiscal Não Essencial Média Alta
funcional
32 Restrição ao desenho Expansibilidade Não Opcional Alta Média
funcional
33 Atributo da qualidade Segurança do Acesso Não Desejável Média Média
funcional
34 Atributo da qualidade Apreensibilidade Nfu ãncional
o Desejável Média A lt a
Gerson Pech - UJ E
R 1 2 0
No Regra de Mudança
1 Alterações nos requisitos só devem ocorrer em marcos

pré- definidos e acordados.
2 As alterações devem ser revisadas pelos grupos envolvidos.
3 Os impactos nos compromissos devem ser avaliados.
4 Os impactos devem ser comunicados na busca de acordo.

As alterações devem ser aprovadas pelos usuários-chave,
5
gerente do projeto e gerentes executivos.
Devem ser produzidas novas versões do Plano de GR
6
incorporando as alterações.
Engenharia de software
Wilson de P. Paula. LTC Ed.
Cadastro Atualizado de Requisitos
Núme Nome do requisito Tipo Import. Comple Esta Status

ro x. b.
1 Interface de usuário Tela de Abertura do Caixa Interface Essencia Baixa Méd Origin
l ia al
2 Interface de usuário Tela de Compras Interface Essencia Média Méd Origin
l ia al
3 Interface de usuário Tela de Estoque Interface Desejáv Média Baix Altera
el a do
19 Interface de software Sistema Financeiro Interface Desejáv Média Méd Origin
el ia al
20 Caso de uso Abertura do Caixa Caso de uso Essencia Baixa Méd Origin
l ia al
21 Caso de uso Emissão de Nota Fiscal Caso de uso Desejáv Média Méd Origin
el ia al
22 Caso de uso Emissão de Relatórios Caso de uso Essencia Baixa Baix Origin
l a al
30 Requisito de desempenho Tempo de resposta Não Desejáv Baixa Alta Origin
funcional el al
31 Restrição ao desenho Padrão de Nota Fiscal Não Essencia Média Alta Altera
funcional l do
32 Restrição ao desenho Expansibilidade Não Opciona Alta Méd Origin
funcional l ia al
33 Atributo da qualidade Segurança do Acesso Não Desejáv Média Méd Origin
funcional el ia al
34 Atributo da qualidade Apreensibilidade Não Desejáv Média Alta Origin
funcional el al
35 Atributo de qualidade portabilidade Não Essencia Média Baix Novo
funcional l a

Tabela de Mudança de Requisitos
Data Requisito alterado Tipo de mudança Motivo Impacto
Caso de uso 3 dias de atraso; mais

26/5/20 Alteração no fluxo Falha da Análise
01 Operação de 15 horas de
Venda esforço
Interface de usuário
25/6/20 Emissão Alteração no Mudança de Mais 2 horas de
01 leiaute legislação esforço
de Notas Fiscais
Interface de usuário 1 dia de atraso;
17/7/20 Alteração no Falha da Análise
Tela de mais 4 horas de
01 leiaute
Estoque esforço
Diagrama de classes Alteração em 2 Conseqüência 2 dias de atraso;
18/7/20
01 persistentes operações da Classe da mais 6 horas de
Mercadoria alteração 3 esforço
Rastreamento
Item de requisitos
Num Nome do item Tipo 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
1 Tela de Abertura do Caixa Cl. fronteira x
2 Tela de Compras Cl. fronteira x x
3 Tela de Estoque Cl. fronteira x x
4 Tela de Fechamento do Caixa Cl. fronteira x
5 Tela de Fornecedores Cl. fronteira x x
6 Tela de Mercadorias Cl. fronteira x x
7 Tela de Nota Fiscal Cl. fronteira x x
8 Tela de Pedidos de Compras Cl. fronteira x x
9 Tela de Relatórios Cl. fronteira x
10 Tela de Usuários Cl. fronteira x x
11 Tela de Vendas Cl. fronteira x x
12 Sistema Financeiro Cl. fronteira x x x
13 Caixa Cl. entidade x x
14 Fornecedor Cl. entidade x x x x x x x
15 Item de Compra Cl. entidade x x x x
16 Item de Mercadoria Cl. entidade x x x x x x x
17 Item de Venda Cl. entidade x x x x
18 Mercadoria Cl. entidade x x x x x x x
19 Usuário Cl. entidade x
20 Nota Fiscal Cl. entidade x x
21 Pedido de Compra Cl. controle x x x x x x x
22 Venda Cl. controle x x x x x x x x
23 Controlador de Mercadorias Cl. controle x x
24 Controlador de Estoque Cl. controle x x
25 Controlador de Compras Cl. controle
26 Controlador de Fornecedores Cl. controle x x
27 Emissor de Relatórios Cl. controle
28 Tratador de Usuários Cl. controle x

Planejamento de Projeto
Metas
Meta 1 As estimativas de sw são documentadas para

serem utilizadas no planejamento e no
acompanhamento de projeto.
Meta 2 As atividades e os compromissos do projeto de

sw são planejados e documentados.
Meta 3 Os grupos e as pessoas afetadas estão de

acordo com os seus compromissos
relacionados ao projeto de sw.

Planejamento de Projetos - Procedimentos
Estimativa de tamanho
Esforço total do projeto
Distribuição do esforço
Distribuição dos recursos
Elaboração do cronograma
Estimativa do Esforço Total do Projeto (ET )
ET
Dados Históricos
Pontos por Função (FP)

Estimativa do Esforço Total do Projeto (ET)
ET

Estimativa do Esforço Total do Projeto (ET)
ET
http://www.ifpug.org/
ET = a FP + b
a
b

Concepçã Elaboração Construção Transiçã Total

o o
Requisito 4,00% 7,00% 1,10% 0,20% 12,30
s %
Análise 0,75% 11,00% 2,75% 0,40% 14,90
%
Desenho 0,15% 1,00% 16,50% 2,00% 19,65
%
Implem. 0,05% 0,60% 24,75% 4,00% 29,40
%
Testes 0,05% 0,40% 9,90% 13,40% 23,75
%
Total 5,00% 20,00% 55,00% 20,00% 100 %
Gerson UERJ 1
Pech - 3
0
Id Nome da tarefa Duração Q
1 Sistema de Desembolso Descentralizado 92 dias
2 Análise de Requisitos 26 dias
3 Reuniões de Iniciação 2 dias
4 Definição do Escopo 2 dias
5 Levantamento Inicial 5 dias
6 Levantamento Detalhado dos Requisitos 7 dias
7 Levantamento Detalhado dos Casos de Uso 7 dias
8 Apresentação do Levantamento 2 dias
9 Conclusão do Levantamento 1 dia
10 Definição dos Requisitos 3 dias
11 Estudo de Viabilidade 1 dia
12 Construção do Modelo Lógico 34 dias
13 Detalhamento de Objetos e Classes 6 dias
14 Organizações das Classes e Relacionamentos 6 dias
15 Desenho Inicial 2 dias
16 Esboço do Modelo do sw 2 dias
17 Elaboração do Modelo de Banco de Dados 6 dias
18 Detalhamento dos Diagramas 20 dias
19 Construção do Modelo Físico 14 dias
20 Modelagem Física - Fase Inicial 7 dias
21 Modelagem Física - Fase Final 7 dias
22 Implementação 27 dias
Esforço Acumul
IDE = EESR ERSR EESE
ERSR
IDP = EESR VE
EESE
EESR
VP
mar/02 abri/02 mai/02 jun/02 jul/02 ago/02 set/02 out/02
Tempo
Planejamento de Projetos - Procedimentos
Planejamento de Custos
Estimativa de Custos
Orçamento de Custos
Controle de Custos

Plano de Entregáveis Despesas Despesas Datas Planejado Desembolsos Percentual Agregado Agregado
Contas Planejado Realizado Acumulado Acumulados Realizado Acumulado
1.2 CADASTRAM 1K R$ 20,00 1K R$ 22,00 02/Abr/01 1K R$ 20,00 1K R$ 22,00 100% 1K R$ 20,00 1K R$
20,00
1.5 INSCRIÇÃO - 1K R$ 30,00 1K R$ 31,00 11/Abr/01 1K R$ 50,00 1K R$ 53,00 100% 1K R$ 30,00 1K R$
50,00
1.6 IDENTIFICAÇ 1K R$ 35,00 1K R$ 37,00 13/Abr/01 1K R$ 85,00 1K R$ 90,00 100% 1K R$ 35,00 1K R$
85,00
1.4 DIGITAÇÃO E 1K R$ 30,00 1K R$ 32,00 17/Abr/01 1K R$ 115,00 1K R$ 122,00 100% 1K R$ 30,00 1K R$ 115,00
1.7 INSCRIÇÃO - 1K R$ 35,00 1K R$ 35,00 17/Abr/01 1K R$ 150,00 1K R$ 157,00 100% 1K R$ 35,00 1K R$ 150,00
1.8 CADASTRAM 1K R$ 40,00 1K R$ 39,00 17/Abr/01 1K R$ 190,00 1K R$ 196,00 100% 1K R$ 40,00 1K R$ 190,00
1.9 ALOCAÇÃO D 1K R$ 40,00 1K R$ 43,00 24/Abr/01 1K R$ 230,00 1K R$ 239,00 100% 1K R$ 40,00 1K R$ 230,00
1.3 CADASTRAM 1K R$ 15,00 1K R$ 20,00 01/Mai/01 1K R$ 245,00 1K R$ 259,00 100% 1K R$ 15,00 1K R$ 245,00
1.1 INSCRIÇÃO - 1K R$ 30,00 1K R$ 40,00 03/Mai/01 1K R$ 275,00 1K R$ 299,00 100% 1K R$ 30,00 1K R$ 275,00
1.10 RETIF. E 2a 1K R$ 55,00 1K R$ 56,00 04/Mai/01 1K R$ 330,00 1K R$ 355,00 100% 1K R$ 55,00 1K R$ 330,00
1.11 RETIFICAÇÃ 1K R$ 55,00 1K R$ 60,00 08/Mai/01 1K R$ 385,00 1K R$ 415,00 100% 1K R$ 55,00 1K R$ 385,00
1.13 ALOCAÇÃO - 1K R$ 25,00 1K R$ 26,00 18/Mai/01 1K R$ 410,00 1K R$ 441,00 100% 1K R$ 25,00 1K U$ 410,00
1.12 REALIZAÇÃO 1K R$ 30,00 1K R$ 30,00 26/Mai/01 1K R$ 440,00 1K R$ 471,00 20% 1K R$ 6,00 1K U$ 416,00
1.14 APLICAÇÃO 1K R$ 10,00 27/Mai/01 1K R$ 450,00
1.15 LEITURA CAR 1K R$ 20,00 01/Jun/01 1K R$ 470,00
1.16 CORREÇÃO 1K R$ 15,00 01/Jun/01 1K R$ 485,00
1.17 RELATORIOS 1K R$ 20,00 13/Jun/01 1K R$ 505,00
1.18 RESULTADO 1K R$ 15,00 19/Jun/01 1K R$ 520,00
COSR
IDC = CRSR
Acumulado
COSE
COSR CRSR
COSE
IDP =
VC
Custo
COSR
VP
mar/01 abri/01 mai/01 jun/01 jul/01 ago/01 set/01 out/01
Tempo

do processo.

definidos.
Área Chave – Nível 4
Gestão Quantitativa de Processo
Metas
Meta 1 As atividades de gerência quantitativa de
processo são planejadas
Meta 2 O desempenho do processo de software

definido para o projeto é controlado
quantitativamente
Meta 3 A capabilidade do processo padrão de software

da organização é conhecido em termos
quantitativos

PSM
Practical Software Measurement -
Objective Information for Decision Makers
Addison-Wesley

Conceitos-Chave
Medição é um processo – Não é uma lista pré-definida de

gráficos e relatórios
Tanto a coleta quanto a análise de dados devem ser
Planejadas
O PSM é flexível – Adaptado para atender Necessidades de
Informação específicas
O PSM suporta as Necessidades Integradas de Informação
do fornecedor e do cliente
O PSM aborda as relações e compromissos entre os objetivos
do projeto

Produto de
Necessidades de
Informação Informação
Indicador
Interpretação Modelo de
análise
Medida Derivada Medida Derivada
Função de
Medição
Medida Básica Medidas Básicas
Método de Método de
Medição Medição
Atributo Atributo
Propriedades
relevantes
PSM - Categorias de Informação
Cronograma e Progresso
Recursos e Custo
Tamanho e Estabilidade do Produto
Qualidade do Produto
Performance do Processo
Eficácia da Tecnologia
Satisfação do Cliente
PSM - Categorias de Informação
Recursos e Custo
Tamanho e Estabilidade do Produto
Qualidade do Produto
Performance do Processo
Eficácia da Tecnologia
Satisfação do Cliente
PSM - Conceito Mensurável
Alcance dos Marcos
Performance do CP
Progresso das Unidades de Trabalho
Capacidade Incremental

PSM - Conceito Mensurável
Alcance dos Marcos
Performance do CP
Capacidade Incremental

PSM - Medida

Requisitos Rastreados
Requisitos Testados
Relatórios de Problemas Abertos
Relatórios de Problemas Fechados
Revisões Completadas
Requisições de Mudanças Abertas
Requisições de Mudanças Fechadas
Unidades Codificadas
Unidades Integradas
Casos de Testes Executados
Casos de Testes Passados
Itens de Ação Abertos
Itens de Ações Completados

Tamanho e Eficácia da Performance
Estabilidade Tecnologia do Processo
do Produto
Recursos e
Custos
Cronograma
e Progresso
Satisfação
Qualidade
do Cliente
do Produto

PSM - Atividade de Medição
ISO - 15939

A Clínica de Saúde João Guimarães – CSJG - tem o seu serviço de
informática terceirizado há quatro anos. Entretanto, Os funcionários da
clínica vivem se queixando do sistema, cujas informações são duvidosas e
cuja tecnologia não corresponde as expectativas dos médicos. O software
controla praticamente toda a clínica. Pacientes, prontuário, ambulatório,
internação, exames, farmácia, cobrança, pessoal etc.
Há cinco meses o conselho que administra a Clínica contratou uma outra

empresa – TSOFT - para a construção de um novo sistema que fosse apto a
realizar todos os procedimentos necessários à gestão administrativa e
médica da CSJG.
O contrato estipula um prazo de oito meses para a implantação. Define o

padrão de qualidade do produto, treinamento dos usuários, custos
necessários a implantação e um escopo bastante claro onde as funções do
produto final são resumidas.
A TSOFT inicia o projeto, entretanto, tem dificuldades na contratação de

Analistas que tenham experiência na área médica.

Defeitos Acumulados
Defeitos
DR
60
50 DE
40 DC
30
20
5 10 15 20 25
Semanas
Defeitos na Fase de Análise de Requisitos
40%
30%
20%
10%
RI DO VP DE

Defeitos por Fases
Requisitos Projeto
40%
30%
20%
10%
RI DO VP DE RI DO VP DE

Evolução dos Requisitos
RA
120
RE
100
80
60
40
5 10 15 20 25
Semanas
Incrementos ou mudanças nos requisitos
40%
30%
20%
10%
RH Conselho Compras Outros

Progresso da Implementação
% do sw Estimado
codif. e
testado
75
60 Real
45
30
15 20 25 30
Semanas
Manutenção - Backlog
No. de
solicitações
25
Solicitações Recebidas
20
15 Solicitações Fechadas
10
2 4 6 8
Semanas
Gerson Pech
pech@uerj.br
Tel: 21 99691655
21 25877477

Tutorial Pech

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tutorial Pech

Uploaded by

Copyright:

Available Formats

Como Gerenciar na Prática Projetos

Gerson Pech - UERJ 2

Alterar o sistema de 420 instituições financeiras;

Cruzado Novo – Cruzeiro;

Bloqueio dos saldos das contas correntes e

Criação de novos tributos;

Criação de duas contas para cada cliente:

Gerson Pech - UERJ 4

Saldos não batiam;

Entretanto, as bases estavam lá

Gerson Pech - UERJ 5

Gerson Pech - UERJ 7

• Apenas 5% nas revendas ligadas por

Gerson Pech - UERJ 8

• Não bastam apenas processos padronizados;

O que importa é o uso que se faz de tudo isso!

Gerson Pech - UERJ 9

Gerson Pech - UERJ 10

Gerson Pech - UERJ 11

Gerência de Projeto de Software é a

Baseado no PMI – PMBook, 2000

Gerson Pech - UERJ 13

Gerson Pech - UERJ 14

Gerson Pech - UERJ 15

Todos aqueles que influenciam o

Gerson Pech - UERJ 16

• Identificação das necessidades;

Gerson Pech - UERJ 19

• Estudo das viabilidades dos objetivos;

Gerson Pech - UERJ 20

• Detalhamento das metas e objetivos;

Gerson Pech - UERJ 21

Definição do ciclo de vida utilizado

Definição dos critérios para início e fim de

Identificação dos tipos de análise crítica

Gerson Pech - UERJ 22

Planos para cada fase do desenvolvimento

Gerson Pech - UERJ 23

• Quanto detalhado deve ser o Plano de

Gerson Pech - UERJ 24

Gerson Pech - UERJ 25

• Identifica todas as tarefas do projeto;

Gerson Pech - UERJ 26

Desmembrar o projeto em unidades de

Gerson Pech - UERJ 27

Gerson Pech - UERJ 28

Gerson Pech - UERJ 29

Gerência de Estimar recursos

• Execução das etapas previstas no plano

Gerson Pech - UERJ 31

Gerson Pech - UERJ 32

Uma série de ações que geram um

Gerson Pech - UERJ 34

Gerson Pech - UERJ 35

Gerson Pech - UERJ 36

Verificação do andamento do projeto com

• Propõe-se a fazer o que devia?

• Gera resultados conforme

Gerson Pech - UERJ 39

• Com que frequência apresenta

• Ocorrendo falhas como ele

Gerson Pech - UERJ 40

• É fácil entender os conceitos

• É fácil aprender a usar?