Aula 2 - (2012)

Prévia do material em texto

06/03/2012
1
Modelos Presctivos de Processos
Modelo Comerciai
Ferramentas de Modelagem de Processos de Software
Modelos de Maturidade de Processos de Software
06/03/2012
2
• Um conjunto estruturado de atividades necessárias para
desenvolver um sistema de software.
• Existem vários processos de desenvolvimento de software
diferentes mas a maioria envolve:
� especificação – definição do quê o sistema deve fazer;
� projeto e implementação – definição da organização do sistema e
implementação do sistema;
� validação – checagem de que o sistema faz o que o cliente deseja;
� evolução – evolução em resposta a mudanças nas necessidades do cliente.
• Um modelo de processo de desenvolvimento de software
• É uma representação abstrata de um processo.
• Ele apresenta uma descrição do processo de uma perspectiva geral.
� Modelo e Processo de Software
Processo de Sw:
o que acontece na realidade
Modelo de Processo de Sw:
representação abstrata daquilo de como
proceder ou do que ocorreu em um processo
06/03/2012
3
5
Atividades
Problema Solução
dados
relatórios
restrições
procedimentos
Software
• Quando descrevemos processos, geralmente falamos sobre as
atividades desses processos, tais como:
• Especificação de modelo de dados, desenvolvimento de interface de
usuário, etc. e a organização dessas atividades.
• Descrições de processos também podem incluir:
�Produtos, que são os resultados de uma atividade do processo;
�Papéis, que refletem as responsabilidades das pessoas envolvidas no
processo;
�Pré e pós-condições
�Declarações que devem ser verdadeiras antes e depois de uma atividade
do processo ser executada, ou um produto ser produzido.
06/03/2012
4
Processo de 
Software
Relatórios
Ferramentas
Pessoas
Treinamentos
Métricas/
Estimativas
Contratos
Custos
Prazos
Artefatos
Recursos
• Processos dirigidos a planos são processos em que todas as
atividades do processo são planejadas com antecedência e o
progresso é medido em relação a esse plano.
• Nos processos ágeis o planejamento é incremental e é mais
fácil modificar o processo para refletir alterações nos
requisitos do cliente.
• Na realidade, os processos mais práticos incluem elementos
dos processos ágeis e dirigidos a planos.
• Não existe processo de software certo ou errado.
06/03/2012
5
Processo de Software
� Processos vem sendo propostos pela 
indústria, países e academia
◦ Análise Estruturada (Yourdon, Gane)
◦ Objectory (Jacobson)
◦ V-Model (Alemanha)
◦ Rational Unified Process - RUP
◦ XP - eXtreme Programming
06/03/2012
6
� Paradoxo:
◦ Para todos os programas construídos há a 
necessidade de se entender os requisitos e 
o processo de negócio do contratante
◦ Na grande maioria das situações não há 
documentação de como a organização de 
desenvolvimento de software vai agir para 
atender a requisição
◦ Se a organização não sabe como trabalha, 
como vai descrever soluções para terceiros?
12
Porque problemas no processo 
provavelmente geram defeitos no 
produto!
Por que o foco está no 
processo?
06/03/2012
7
13
� Qualidade do processo
◦ Aumento da qualidade do produto
◦ Diminuição do retrabalho
◦ Maior produtividade
◦ Redução do tempo para atender o mercado
◦ Maior competitividade
◦ Maior precisão nas estimativas
� Fases Genéricas do Processo de Sw
◦ Fase de Definição: o quêo quêo quêo quê
� Engenheiro de Software tenta identificar: 
que informação deve ser processada, que 
função e desempenho são desejados, que 
comportamento deve ser esperado do 
sistema, que interfaces devem ser 
estabelecidas, quais restrições de projeto, 
quais critérios de validação
� Os requisitos-chave do sistema e do 
software são identificados
06/03/2012
8
� Fases Genéricas do Processo de Sw
◦ Fase de Desenvolvimento: comocomocomocomo
� Definição de como os dados devem ser estruturados, 
como a função deve ser implementada dentro da 
arquitetura do software, como os detalhes
procedimentais devem ser implementados, como as 
interfaces devem ser caracterizadas, como o projeto
deve ser traduzido em linguagem de programação, e 
como o teste deve ser realizado
◦ Fase de Manutenção: modificaçõesmodificaçõesmodificaçõesmodificações
� Tipos: Corretiva, Adaptativa, Perfectiva e Preventiva
� Evolução do desenvolvimento de software 
(Antigamente)
◦ Atividade solitária, onde o sucesso era determinado por 
bons analistas/programadores com domínio da tecnologia 
envolvida
◦ O cliente possuía pouco domínio da tecnologia envolvida
◦ O software desenvolvido normalmente estava relacionado 
com as atividades-meio do cliente
� Exemplos: Folha de pagamento, Controle de Patrimônio
◦ Distribuição de dados e aplicações era limitada ao domínio 
físico de redes locais
◦ Desenvolvimento de software - “um tipo de Arte”
06/03/2012
9
� Evolução do desenvolvimento de software (Hoje)
◦ Grande quantidade e variedade de profissionais
� Ex: Designers, DBA, Especialistas em web, Programação de sistemas 
distribuídos
◦ O cliente possui domínio acerca da tecnologia
◦ Software desenvolvido para atividades-fim
� Aplicações críticas para o negócio do cliente
� Exemplo: e-business
◦ Distribuição de dados e aplicações: Internet
◦ Desenvolvimento de software
� Exigência de abordagem metodológica por parte do cliente
� Empresas espalhadas em diferentes regiões
� Evolução da Engenharia de Software
◦ Apesar de processos de software serem estudados 
e estarem disponíveis há bastante tempo, outros 
aspectos atraíam a atenção
Notações
Ferramentas
CASE
Desenvolvimento
Baseado em
Reutilização
Processos
de
Software
Te
cn
o
lo
g
ia
G
er
ên
ci
a
A
rq
u
it
et
u
ra
A
rt
ef
at
o
06/03/2012
10
� Crescente importância de métodos para 
avaliação da qualidade de software baseados 
no processo
◦ Capability Maturity Model (SEI-CMM) e SPICE (ISO)
� Avalia uma organização segundo:
� capacidade de produzir resultados planejados
� maturidade, a qual indica o crescimento contínuo da 
capacidade;
� Qualidade na definição do processo é um dos 
elementos-chave para que uma organização possa 
atingir melhores níveis de maturidade;
20
CaracterísticasCaracterísticasCaracterísticasCaracterísticas
� Ad hoc - Improvisado
� Fortemente dependente dos profissionais
� Indisciplinado
ConseqüênciasConseqüênciasConseqüênciasConseqüências
•Pouca produtividade
•Qualidade de difícil previsão
•Alto custo de manutenção
•Risco na adoção de novas tecnologias
06/03/2012
11
� Processo conhecido por todos
� Apoio visível da alta administração
� Auditagem da fidelidade ao processo
� Medidas do produto e do processo
� Adoção disciplinada de tecnologias
21
� Papéis e responsabilidades claramente 
definidos
� Acompanhamento da qualidade do produto e 
da satisfação do cliente
� Expectativas para custos, cronograma, 
funcionalidades e qualidade do produto 
são usualmente alcançadas
22
06/03/2012
12
Papéis e responsabilidades
bem definidos
Processo improvisado
Existe base histórica Não existe base histórica
A qualidade dos produtos e
processos é monitorada
Qualidade e funcionalidade do
produto sacrificadas
O processo pode ser
atualizado
Não há rigor no processo a
ser seguido
Existe comunicação entre o
gerente e seu grupo
Resolução de crises imediatas
Organizações maduras Organizações imaturas
Construir software consiste na
aplicação de técnicas 
Construir software é “arte”
06/03/2012
13
Máquina de
Processo
desenvolvedores gerentes
Domínio da Definição do Processo Domínio da Realização do Processo
Domínio da Execução do Processo
feedback
Assistência e
suporte à 
realização do 
processoModelos de
processo Evolução
[Dowson 91]
� Formar um entendimento comum
� Encontrar inconsistências, redundâncias e 
omissões
� Encontrar e avaliar atividades propostas mais 
adequadas aos objetivos
� Fazer um processo geral para uma situação 
particular na qual ele será utilizado
� Benefícios da Execução e outras ferramentas
06/03/2012
14
27
� Atividades guarda-chuva: transversaistransversaistransversaistransversais às 
demais etapas
◦ Acompanhamento e controle do projeto de software
◦ Revisões técnicas formais
◦ Garantia de qualidade de software
◦ Gestão de configuração de software
◦ Preparação e produção de documentos
◦ Gestão de reutilização
◦ Medição
◦ Gestão de Risco
28
� Caracterização
Estrutura comum de processoEstrutura comum de processoEstrutura comum de processoEstrutura comum de processo
Tarefas
Marcos, produtos finais ou
intermediários sujeitos a entrega
Pontos de garantia de
Qualidade de software
Conjuntos de TarefasConjuntos de TarefasConjuntos de TarefasConjuntos de Tarefas
Atividades guardaAtividades guardaAtividades guardaAtividades guarda----chuvachuvachuvachuva
06/03/2012
15
29
� Estrutura Comum de 
Processo
◦ É estabelecida definindo 
um pequeno número de 
atividades que são 
aplicáveis a todos os 
projetos de software, 
independente de seu 
tamanho ou 
complexidade
Estrutura comum de processo
Tarefas
Marcos, produtos finais ou
intermediários sujeitos a entrega
Pontos de garantia de
Qualidade de software
Conjuntos de Tarefas
Atividades guarda-chuva
30
� Conjuntos de Tarefas
◦ Permite que as atividades 
da estrutura sejam 
adaptadas às 
características do projeto 
e às necessidades da 
equipe de projeto
Estrutura comum de processo
Tarefas
Marcos, produtos finais ou
intermediários sujeitos a entrega
Pontos de garantia de
Qualidade de software
Conjuntos de Tarefas
Atividades guarda-chuva
06/03/2012
16
31
� Atividades guarda-
chuva
◦ Garantia de qualidade
◦ Gestão de configuração 
de software
◦ Medição
Estrutura comum de processo
Tarefas
Marcos, produtos finais ou
intermediários sujeitos a entrega
Pontos de garantia de
Qualidade de software
Conjuntos de Tarefas
Atividades guarda-chuva
• Modelo Cascata – Modelo dirigido a planos. Fases de especificação
e desenvolvimento separadas e distintas.
• Desenvolvimento Incremental – Especificação, desenvolvimento e
validação são intercaladas. Pode ser dirigido a planos ou ágil.
• Engenharia de software orientada a reúso – O sistema é montado a
partir de componentes já existentes. Pode ser dirigido a planos ou
ágil.
� Na realidade a maioria dos grandes sistemas são desenvolvidos
usando um processo que incorpora elementos de todos esses
modelos.
06/03/2012
17
� The waterfall model (Cascata) - Modelo Sequencial
Linear
◦ Etapas separadas e distintas para especificação e 
desenvolvimento
� Prototipagem
� Modelo RAD
� Desenvolvimento formal de sistemas
◦ Um modelo de sistema matemático é transformado ou orienta
a implementação
� Desenvolvimento orientado a reuso
◦ O sistema é construído a partir de componentes existentes
� Processos baseados em Iteração
◦ Incremental
◦ Espiral
34
� O processo Cascata está associado às 
metodologias propostas nas décadas de 
1970-1980
◦ Notadamente as metodologias Estruturadas
� Yourdon
� Constantine
� Chris Gane
� Page-Jones
06/03/2012
18
• Existem fases identificadas e separadas no modelo cascata:
�Análise e definição de requisitos
� Projeto de sistema e software
� Implementação e teste de unidade
� Integração e teste de sistema
�Operação e manutenção
• O principal inconveniente do modelo cascata é a dificuldade de acomodação
de mudanças depois que o processo já foi iniciado. Em princípio, uma fase
precisa ser completada antes de se mover para a próxima fase.
06/03/2012
19
37
� Divisão inflexível do projeto em estágios distintos torna difícil
responder às mudanças nos requisitos do cliente.
◦ O cliente precisa ter paciência
� Poucos sistemas de negócio possuem requisitos estáveis.
◦ Dificuldade em congelar os requisitos no início e em acomodar
mudanças dinâmicas
� Projetos reais raramente seguem o fluxo seqüencial
� Apropriado quando os requisitos são bem entendidos e as 
mudanças durante o processo de projeto serão limitadas. 
◦ Pode ser usado em trabalhos acadêmicos com etapas bem definidas de 
“levantamento bibliográfico”
38
� Cliente normalmente:
◦ Define um conjunto de objetivos gerais para o 
software
◦ Mas não identifica detalhadamente os requisitos de 
entrada, processamento ou saída
06/03/2012
20
39
listen
to
customer
build/revise
mock-up
customer
test-drives
mock-up
Ouvir o 
Cliente
Construi ou
revisar 
protótipo
Mock-up é a 
simulação 
de um módulo 
funcionando
Testes do módulo 
pelo Cliente
40
� Problemas:
◦ O cliente vê o que parecer ser uma versão 
executável do software
� Ignora que o protótipo funciona de maneira precária
◦ O desenvolvedor freqüentemente faz concessões na 
implementação a fim de conseguir rapidamente um 
protótipo executável
06/03/2012
21
41
� Desenvolvimento rápido de aplicação
◦ Incremental, com ciclo curto
◦ É uma adaptação “de alta velocidade” do modelo 
seqüencial linear, no qual a rapidez é obtida com 
componentes
◦ Fases
� Modelagem do negócio
� Modelagem dos dados
� Modelagem do processo
� Geração da aplicação
� Teste e entrega
42
business
modeling
data
modeling
process
modeling
application
generation
testing
&
turnover
business
modeling
data
modeling
process
modeling
application
generation
testing
&
turnover
business
modeling
data
modeling
process
modeling
application
generation
testing
&
turnover
team #1
team #2
team #3
60 - 90 days
06/03/2012
22
43
� Principais desvantagens
◦ Nem todos os tipos de aplicação são apropriados 
para o RAD.
� Se o sistema não puder ser adequadamente 
modularizado, a construção e seleção de componentes 
será problemática
◦ Não é adequado quando são enfrentados riscos 
técnicos elevados
� Por exemplo, adoção profunda de uma nova tecnologia
44
� Para a maioria dos grandes sistemas, existe a 
necessidade de utilizar diferentes abordagens para 
diferentes partes do sistema
◦ Abordagem híbrida
� Iteração
◦ repetir partes do processo à medida que os requisitos do 
sistema evoluem
◦ Por exemplo, deve-se refazer (ou complementar) o projeto 
do sistema e sua implementação para incluir novos 
requisitos
◦ Cada ciclo desenvolve uma versão mais completa
06/03/2012
23
45
Sommerville:Sommerville:Sommerville:Sommerville:
Descrição geralDescrição geralDescrição geralDescrição geral
46
� Modelo Incremental
◦ Combina Cascata com Prototipagem
◦ Cada seqüência produz um incremento
◦ Exemplo: Processador de Texto
� 1o release: gestão básica de arquivos, edição e produção 
de documentos (núcleo do produto)(núcleo do produto)(núcleo do produto)(núcleo do produto)
� 2o: capacidades mais sofisticadas de edição
� 3o: verificação sintática e gramatical
� 4o: capacidade avançada de disposição de página
06/03/2012
24
48
� Vantagens
◦ Os clientes não precisam esperar até que todo o 
sistema seja entregue, para então tirarem proveito 
dele.
� O primeiro estágio deve satisfazer os requisitos mais 
importantes e, assim, o software pode ser imediatamente 
usado
◦ Os clientes podem utilizar os primeiros incrementos 
como um protótipo e obter uma experiência que 
forneça os requisitos para estágios posteriores
◦ Existe um risco menor de fracasso completo do 
sistema
◦ Cada entrega é uma versão funcional do sistema
06/03/2012
25� O custo para acomodar mudanças nos requisitos do cliente é reduzido. 
� A quantidade de análise e documentação que precisa ser feita, a cada 
incremento, é bem menor do que o necessária no modelo cascata.
� É mais fácil obter feedback do cliente sobre o trabalho de 
desenvolvimento que tem sido feito. 
� Os clientes podem comentar demonstrações do software e ver quanto 
foi implementado. 
� Possibilidade de mais rapidez na entrega e implantação de software útil 
para o cliente. 
� Os clientes podem usar e obter ganhos do software mais cedo do que é 
possível no processo cascata. 
50
� Problemas
◦ Pode ser difícil mapear os requisitos para incrementos 
específicos
◦ É difícil identificar facilidades comuns que todos os 
incrementos exijam
◦ A estrutura do sistema tende a degradar conforme novos
incrementos são adicionados
� As mudanças regulares tendem a corromper a estrutura do 
sistema
� A incorporação posterior de mudanças no software se torna
progressivamente mais difícil e cara
06/03/2012
26
51
� Espiral
◦ Proposto Boehm (1988)
◦ O processo é representado como uma espiral, onde 
cada loop representa uma fase do processo.
◦ O Processo Espiral é similar ao Incremental mas:
� Cada ciclo produz algo a ser avaliado não 
necessariamente código
� Gerência de Riscos embutida no processso
� Ao final de cada loop é perguntado “Devemos continuar?”
• Cada loop na espiral representa uma fase do
processo.
• Não existem fases fixas como especificação ou
projeto
• Os loops na espiral são escolhidos de acordo com a
necessidade.
• Os riscos são avaliados explicitamente e resolvidos no
decorrer do processo.
06/03/2012
27
53
� Visão geral do processo
O modelo de processo de software 
espiral de Boehm
06/03/2012
28
• Definição de objetivos
�São identificados os objetivos específicos para cada fase.
• Avaliação e redução de riscos
�Os riscos são avaliados e atividades executadas para reduzir os
principais riscos.
• Desenvolvimento e validação
�Um modelo de desenvolvimento para o sistema é escolhido, pode ser
qualquer um dos modelos genéricos.
• Planejamento
�O projeto é revisto e a próxima fase da espiral é planejada.
56
� Baseado na transformação de uma especificação
matemática através de refinamentos sucessivos até
um programa executável
� Transformações devem “preservar a correção”, isto
é, permitem mostrar que o programa está de acordo
com a sua especificação
� Exemplo mais conhecido: Cleanroom (IBM)
◦ Incremental, onde para cada estágio é demonstrada a 
correção em relação ao anterior
06/03/2012
29
57
Definição dos 
Requisitos
Especificação 
Formal
Desenvolvimento a 
Partir da Especificação
Teste de Sistema 
e Integrãção
58
� Problemas
◦ Demanda pessoal especializado
◦ Dificuldade em especificar formalmente alguns
aspectos de sistemas
� Interface com usuário
� Aplicação
◦ Sistemas críticos onde segurança e/ou
confiabilidade devem ser garantidas antes mesmo
que o sistema entre em operação
06/03/2012
30
59
� Baseia-se na reutilização sistemática onde sistemas são
integrados a partir de
◦ Componentes existentes
� (in-house)
◦ Componentes de prateleira
� [COTS (Commercial-off-the-shelf)] – Software de Prateleira
� Estágios do processo:
◦ Análise de componentes;
◦ Modificação de requisitos;
◦ Projeto de sistema com reúso;
◦ Desenvolvimento e integração.
Atualmente, o reúso é a abordagem padrão para a 
construção de vários tipos de sistemas de negócio.
06/03/2012
31
� É um processo genérico moderno, derivado da 
UML e outros processos associados.
� Reúne aspectos dos 3 modelos genéricos 
discutidos previamente.
� Geralmente descrito por 3 perspectivas:
◦ Uma perspectiva dinâmica que mostra fases no tempo;
◦ Uma perspectiva estática que mostra atividades do 
processo;
◦ Uma perspectiva prática que sugere boas práticas.
06/03/2012
32
• Concepção
�Estabelece o business case para o sistema.
• Elaboração
�Desenvolve um entendimento da extensão do problema e da
arquitetura do sistema.
• Construção
�Projeta o sistema, programa e testa o sistema.
• Transição
� Implanta o sistema no seu ambiente de operação.
Iteração do RUPIteração do RUP
• Iteração Intra-fase
�Cada fase é iterativa aos resultados desenvolvidos incrementalmente
• Iteração Inter-fase
�Como mostrado pelo loop no modelo RUP, o conjunto todo de fases
pode ser executado incrementalmente.
06/03/2012
33
06/03/2012
34
• Desenvolve software iterativamente
� Planeja incrementos baseando-se nas prioridades do cliente e
entregar as de prioridade mais alta primeiro.
• Gerencia os requisitos
� Documenta explicitamente os requisitos do cliente e manter registros
de mudanças desses requisitos.
• Usa arquiteturas baseadas em componentes
� Organiza a arquitetura do sistema como um conjunto de
componentes reusáveis.
• Modela o processo visualmente
� Usa modelos gráficos da UML para representar visões dinâmicas e
estáticas do processo e software.
• Verifica a qualidade do software
� Garante que o software atenda aos padrões de qualidade
organizacional.
• Controla as mudanças do software
� Gerencia as mudanças no software usando um sistema de
gerenciamento de mudanças e ferramentas de gerenciamento de
configuração.
06/03/2012
35
� Divulgação de processo a ser adotado pela 
empresa
� Repositório com modelos de artefatos
� Alguns permitem a edição pelo usuário final
� Vantagem:
◦ Fácil adoção
� Desvantagem:
◦ Não há garantia que será usado na empresa
69
70
06/03/2012
36
� Divulgação eletrônica do modelo de processo 
da Rational
� Artefatos padronizados
� Visões personalizadas
� Capacidade de Adaptação do Processo
◦ RUP Builder
71
72
06/03/2012
37
73
74
06/03/2012
38
Software Process Elicitation, Analysis, Reviw
and Modeling in an Integrated Environment
76
06/03/2012
39
77
78
06/03/2012
40
79
80
06/03/2012
41
06/03/2012
42
06/03/2012
43
86
06/03/2012
44
06/03/2012
45
06/03/2012
46
06/03/2012
47
94
06/03/2012
48
�Origens
◦Edital FINEP/Software Livre 2003
� Parceria com SERPRO-Belém
◦Programa de P&D Eletronorte 
2004
� Laboratório Central
95
06/03/2012
49
97
98
06/03/2012
50
99
Versão PRO
Versão 
Software
Livre
Versão de Pesquisa
(usada internamente e com parceiros)
� Elementos do processo
◦ Atividades
◦ Artefatos
◦ Agentes e Grupos
◦ Ferramentas e Recursos
◦ Políticas
10
0
06/03/2012
51
10
1
� Elementos a destacar
◦ Definição do Planejamento de Atividade
◦ Perfil de Recursos Humanos
◦ Gestão de configuração de software
10
2
06/03/2012
52
10
3
10
4
06/03/2012
53
10
5
Perfil de Recursos Humanos
10
6
Perfil de Recursos Humanos
06/03/2012
54
10
7
Plano de Recursos Humanos
Processo: Cadastro_Online_Calouros
Atividade do Processo Papel Agente
Analisar os Requisitos
Líder de Projeto Thiago Rubeni
Apresentar Avaliação do Projeto e Lições Aprendidas
Líder de Projeto Thiago Rubeni
Atualizar a Matriz de Rastreabilidade
Analista de Requisitos Elaine Gleyce Mira de Figueiredo
Analista de Requisitos Elaine Gleyce Mira de Figueiredo
Analista de Requisitos Elaine Gleyce Mira de Figueiredo
Líder de Projeto Thiago Rubeni
Analista de Requisitos Thiago Rubeni
Avaliar Final
Coordenador da Equipe de Implementaçãoadmin
Avaliar Plano do Projeto
Líder de Projeto Thiago Rubeni
Avaliar Plano do Projeto e Gerar Relatório de Monitoramento
Líder de Projeto Thiago Rubeni
Líder de Projeto Thiago Rubeni
Líderde Projeto Thiago Rubeni
Avaliar Requisitos
Líder de Projeto Thiago Rubeni
Analista de Requisitos Elaine Gleyce Mira de Figueiredo
Avaliar Viabilidade do Projeto
Líder de Projeto Thiago Rubeni
10
8
Plano de 
Custos 
Processo: Cadastro_Online_Calouros
Recursos Descrição Quantidade Custo Unitário Custo Total
Recursos Humanos Papel Descrição Horas Trabalhadas
Elaine Gleyce Mira de Figueiredo Gerente de Requisitos 10,00
Thiago Rubeni Líder de Projeto 13,00
Thiago Rubeni Gerente de Requisitos 25,00
Vanderlene Covre Rocha Implementador de Processo 39,00
Process: Processo SIGDCT
Atividade
número de 
dias início fim
número de 
envolvidos MARCO
CAMINHO 
CRÍTICO
Planejamento <D> 0 0
Planejamento do Projeto <D> 0 0
Configurar Ambiente 2 24/06/2008 25/06/2008 1
Elaborar Proposta Tecnica 1 24/06/2008 24/06/2008 1
Elicitar Requisitos Iniciais <D> 0 0
Elaborar Lista de Requisitos 3 24/06/2008 26/06/2008 1 *
Avaliacao da Lista de Requisitos 2 27/06/2008 28/06/2008 1
Aceitacao dos Requisitos pelo Cliente 1 29/06/2008 29/06/2008 1 *
Realizar Estimativas 1 30/06/2008 30/06/2008 TODOS *
Planejar o Projeto 2 30/06/2008 01/07/2008 1 *
Avaliacao e Comprometimento com o Plano <D> 0 0
Avaliar a Viabilidade do Projeto 1 02/07/2008 02/07/2008 1
Obter Comprometimento com o Plano do Projeto 1 02/07/2008 02/07/2008 TODOS *
Analise dos Requisitos <D> 0 0
Analisar Requisitos <D> 0 0
Especificar Requisitos 2 02/07/2008 03/07/2008 1 *
Criar Matriz de Rastreabilidade 103/07/2008 03/07/2008 1 *
Avaliar Especificacao de Requisitos 1 04/07/2008 04/07/2008 1
Revisar o Plano do Projeto - MARCO 104/07/2008 04/07/2008 TODOS MARCO
Projeto e Arquitetura do Software <D> 0 0
Definir Projeto de Arquitetura <D> 0 0
Especificar Arquitetura 1 07/07/2008 07/07/2008 2 *
Atualizar Matriz de Rastreabilidade 107/07/2008 07/07/2008 1 *
Definir Projeto do Software <D> 0 0
Elaborar Modelo de Analise e Projeto 1 08/07/2008 08/07/2008 2 *
Gerenciar Requisitos (atividade continua) <D> 0 0
Gerenciar Mudanças de Requisitos 3 07/07/2008 09/07/2008 1
Atualizar a Matriz de Rastreabilidade 109/07/2008 09/07/2008 1
Cronograma:
06/03/2012
55
10
9
Lucia Lucia Costa 1 Analyst
Paulo Paulo Silva 3 Analyst
Ana Ana Maria 5 Analyst
Lucia Lucia Costa 1 Analyst
Paulo Paulo Silva 3 Analyst
Ana Ana Maria 5 Analyst
06/03/2012
56
INICIAL
REPETÍVEL
Organizações 
Disciplinadas
DEFINIDO
Organizações 
Padronizadas
GERENCIADO
Organizações 
Previsíveis
OTIMIZADO
Organizações com 
Melhoria Contínua
Organizações 
Caóticas
Software Engineering Institute-SEI
112
� Processo de desenvolvimento caótico;
� Falta de integração;
� Sucesso dos projetos se deve a esforços heróicos;
� Diante de uma crise, a organização abandona os 
procedimentos definidos e reverte à codificação e 
testes.
Chega desse negócio de projeto!Chega desse negócio de projeto!Chega desse negócio de projeto!Chega desse negócio de projeto!
Estamos atrasados!Estamos atrasados!Estamos atrasados!Estamos atrasados!
Vamos COMEÇAR A PROGRAMAR!!!Vamos COMEÇAR A PROGRAMAR!!!Vamos COMEÇAR A PROGRAMAR!!!Vamos COMEÇAR A PROGRAMAR!!!
06/03/2012
57
113
� Gerência do projeto, segurança do produto e 
controle de mudanças já estabelecidos;
� A organização cumpre seus prazos e 
orçamentos;
� Sucesso através de administração de projetos 
básica, convencional;
� Se o gerente de projetos deixar essa 
organização, os projetos poderão “cair por 
terra”.
114
� Estabelecimento de um Grupo de Processo de 
Engenharia de Software responsável por:
◦ focalizar e cobrir os esforços de melhoria do processo;
◦ manter a gerência informada do estado desses esforços
◦ facilitar a introdução de métodos e técnicas de engenharia 
de software.
� O processo foi codificado e institucionalizado
� Existe um processo formal definido que todos 
seguem
� Constante possibilidade de melhoria do processo;
� Falta de avaliação da eficiência
06/03/2012
58
115
� Conjunto de métricas de 
qualidade e produtividade foi
estabelecido;
� Banco de dados do processo
com análises de recursos e 
experiências disponíveis para
consulta;
� Ênfase na coleta de métricas
para melhorar a qualidade
tanto do processo quanto do 
produto
116
� A organização possui Know-how para identificar 
seus elementos de processo mais fracos e reforçá-
los;
� Disponibilidade de dados para justificativa da 
aplicação da tecnologia;
� A gerência preocupa-se com a melhoria do 
processo ao invés de com os reparos nos produtos;
� Análise rigorosa da causa dos defeitos e prevenção 
de falhas.
06/03/2012
59
Nível CMM Foco Áreas-chave de processo
Inicial Pessoas competentes e heróis
Repetível
Processos de
gerenciamento
de projetos
- Gerenciamento de requisitos
- Planejamento do projeto
- Visão geral e acompanhamento do projeto
- Gerenciamento de subcontratados
- Garantia da qualidade do software
- Gerenciamento de configuração
Definido
Processos de engenharia
e apoio
- Definição do processo organização
- Programa de treinamento
- Gerenciamento de software integrado
- Engenharia de produto de software
- Coordenação intergrupos
- Revisão conjunta
Gerenciado
Qualidade do produto e
do processo
- Gerenciamento quantitativo dos processos
- Gerenciamento da qualidade de software
Otimizado
Melhoramento contínuo
do processo
- Prevenção de defeitos
- Gerenciamento de mudanças tecnológicas
- Gerenciamento de mudanças no processo
118Evolução da
maturidade
06/03/2012
60
“Melhoria de processosprocessosprocessosprocessos de software 
nas micromicromicromicro, pequenaspequenaspequenaspequenas e médiasmédiasmédiasmédias
empresas, a um custo acessível, 
em diversos locais do país.”
www.softex.br/mpsbr
ISO/IEC 12207 
Definição de Processos 
Propósitos e Resultados
ISO/IEC 15504 
Definição da Capacidade 
de Processos 
Requisitos de Avaliação
CMMI 
Complementação de 
Processos
06/03/2012
61
12
1
Gerenciado Gerenciado Gerenciado Gerenciado 
QuantitativamentQuantitativamentQuantitativamentQuantitativament
e e e e 
Parcialmente Parcialmente Parcialmente Parcialmente 
GerenciadoGerenciadoGerenciadoGerenciado
GerenciadoGerenciadoGerenciadoGerenciado
Parcialmente Parcialmente Parcialmente Parcialmente 
Definido Definido Definido Definido 
Largamente Largamente Largamente Largamente 
Definido Definido Definido Definido 
Definido Definido Definido Definido 
Em Otimização Em Otimização Em Otimização Em Otimização 
121
MediçãoMediçãoMediçãoMedição ---- MEDMEDMEDMED //// GerênciaGerênciaGerênciaGerência dededede ConfiguraçãoConfiguraçãoConfiguraçãoConfiguração ---- GCOGCOGCOGCO
AquisiçãoAquisiçãoAquisiçãoAquisição ---- AQUAQUAQUAQU //// GarantiaGarantiaGarantiaGarantia dadadada QualidadeQualidadeQualidadeQualidade ---- GQAGQAGQAGQA
GerênciaGerênciaGerênciaGerência dededede PortfólioPortfólioPortfólioPortfólio dededede ProjetosProjetosProjetosProjetos ---- GPPGPPGPPGPP
AvaliaçãoAvaliaçãoAvaliaçãoAvaliação eeee MelhoriaMelhoriaMelhoriaMelhoria dodododo ProcessoProcessoProcessoProcesso OrganizacionalOrganizacionalOrganizacionalOrganizacional ---- AMPAMPAMPAMP
DefiniçãoDefiniçãoDefiniçãoDefinição dodododo ProcessoProcessoProcessoProcesso OrganizacionalOrganizacionalOrganizacionalOrganizacional ---- DFPDFPDFPDFP
GerênciaGerênciaGerênciaGerência dededede ReutilizaçãoReutilizaçãoReutilizaçãoReutilização ---- GRUGRUGRUGRU
GerênciaGerênciaGerênciaGerência dededede RecursosRecursosRecursosRecursos HumanosHumanosHumanosHumanos ---- GRHGRHGRHGRH
GerênciaGerênciaGerênciaGerência dededede ProjetosProjetosProjetosProjetos ---- GPRGPRGPRGPR (evolução)(evolução)(evolução)(evolução)
DesenvolvimentoDesenvolvimentoDesenvolvimentoDesenvolvimentodededede RequisitosRequisitosRequisitosRequisitos ---- DREDREDREDRE
ProjetoProjetoProjetoProjeto eeee ConstruçãoConstruçãoConstruçãoConstrução dodododo ProdutoProdutoProdutoProduto ---- PCPPCPPCPPCP
IntegraçãoIntegraçãoIntegraçãoIntegração dodododo ProdutoProdutoProdutoProduto ---- ITPITPITPITP
VerificaçãoVerificaçãoVerificaçãoVerificação ---- VERVERVERVER //// ValidaçãoValidaçãoValidaçãoValidação ---- VALVALVALVAL
GerênciaGerênciaGerênciaGerência dededede DecisõesDecisõesDecisõesDecisões ---- GDEGDEGDEGDE
DesenvolvimentoDesenvolvimentoDesenvolvimentoDesenvolvimento paraparaparapara ReutilizaçãoReutilizaçãoReutilizaçãoReutilização ---- DRUDRUDRUDRU
GerênciaGerênciaGerênciaGerência dededede RiscosRiscosRiscosRiscos ---- GRIGRIGRIGRI
GGGG
FFFF
EEEE
DDDD
CCCC
Gerência de Requisitos Gerência de Requisitos Gerência de Requisitos Gerência de Requisitos ---- GREGREGREGRE
Gerência de ProjetosGerência de ProjetosGerência de ProjetosGerência de Projetos ---- GPRGPRGPRGPR
AAAA
BBBB
Gerência de ProjetosGerência de ProjetosGerência de ProjetosGerência de Projetos ---- GPR (evolução)GPR (evolução)GPR (evolução)GPR (evolução)
(sem processo específico)(sem processo específico)(sem processo específico)(sem processo específico)
12
2
06/03/2012
62
� www.softex.br/mpsbr
12
3
124
Referências: Básicas � ISO/IEC 12207:2008 e ISO/IEC 
15504
Complementar � CMMI
Objetivo: Descrever de forma detalhada o Modelo de 
Referência para Melhoria do Processo de Software (MR-MPS) 
e contém algumas definições comuns aos diversos 
documentos do MPS.BR
Público alvo: Instituições interessadas em aplicar o MR-MPS 
para melhoria de seus processos de software e Instituições 
implementadoras e avaliadoras segundo o MR-MPS
06/03/2012
63
12
5
Níveis de maturidade 
Capacidade
Resultado
Processo
Propósito
Resultado
Atributo
126
� Atributos de Processo (AP)
◦ AP 1.1: O processo é executado
◦ AP 2.1: O processo é gerenciado
◦ AP 2.2: Os produtos de trabalho do processo são 
gerenciados
◦ AP 3.1: O processo é definido
◦ AP 3.2: O processo está implementado
◦ AP 4.1: O processo é medido 
◦ AP 4.2: O processo é controlado
◦ AP 5.1: O processo é objeto de melhorias e 
inovações
◦ AP 5.2: O processo é otimizado continuamente
06/03/2012
64
12
7
Processos MPS.BR nível G
Fonte: Riosoft/Paulo Santos 2009
128
Nível Processos Capacidade
G
Gerência de Projetos
GPR 1; GPR2; GPR 3; GPR 4 (até F); GPR 5; 
GPR 6; GPR 7; GPR 8; GPR 9; GPR 10; 
GPR 11; GPR12; GPR 13; GPR 14; GPR 15; 
GPR 16 e GPR 17
AP1.1 e AP2.1:
RAP 1 RAP 2
RAP 3 RAP 4 (G) 
RAP 5 (até F)
RAP 6 (até F)
RAP 7 (até F)
RAP 8
RAP 9 (até F)
RAP 10 (G)
Gerência de Requisitos
GRE 1; GRE 2; GRE 3; GRE 4 e GRE 5
06/03/2012
65
� 1) Defina processo de software
� 2) Defina modelo de processo de software
� 3) Quais são as características de um 
processo maduro e de um processo imaturo
� 4) Quais são os tipos de modelos presctivos
� 5) Defina cada modelo presctivo
� 6) Apresente exemplos de ferramentas de 
modelagem de processo de software
06/03/2012
66
� 7) Defina CMM e MPS.BR
� 8) Quais são as fases de cada modelo de 
melhoria de processo apresentado
132
Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)
PropósitoPropósitoPropósitoPropósito
O propósito do processo Gerência de Projetos é 
estabelecer e manter planos que definem as 
atividades, recursos e responsabilidades do 
projeto, bem como prover informações sobre o 
andamento do projeto que permitam a 
realização de correções quando houver desvios 
significativos no desempenho do projeto. O 
propósito deste processo evolui à medida que a 
organização cresce em maturidade. 
06/03/2012
67
133
Resultados esperados
GPR 1. O escopo do trabalho para o projeto é 
definido;
GPR 2. As tarefas e os produtos de trabalho do 
projeto são dimensionados utilizando métodos 
apropriados;
GPR 3. O modelo e as fases do ciclo de vida do 
projeto são definidos;
134
Resultados esperados
GPR 4. (Até o nível F) O esforço e o custo para a 
execução das tarefas e dos produtos de trabalho 
são estimados com base em dados históricos ou 
referências técnicas;
GPR 5. O orçamento e o cronograma do projeto, 
incluindo a definição de marcos e pontos de 
controle, são estabelecidos e mantidos;
06/03/2012
68
135
Resultados esperados
GPR 6. Os riscos do projeto são identificados e o 
seu impacto, probabilidade de ocorrência e 
prioridade de tratamento são determinados e 
documentados;
GPR 7. Os recursos humanos para o projeto são 
planejados considerando o perfil e o 
conhecimento necessários para executá-lo;
136
Resultados esperados
GPR 8. Os recursos e o ambiente de trabalho 
necessários para executar o projeto são 
planejados;
GPR 9. Os dados relevantes do projeto são 
identificados e planejados quanto à forma de 
coleta, armazenamento e distribuição. Um 
mecanismo é estabelecido para acessá-los, 
incluindo, se pertinente, questões de privacidade 
e segurança;
06/03/2012
69
137
Resultados esperados
GPR 10. Um plano geral para a execução do 
projeto é estabelecido com a integração de 
planos específicos;
GPR 11. A viabilidade de atingir as metas do 
projeto, considerando as restrições e os recursos 
disponíveis, é avaliada. Se necessário, ajustes 
são realizados;
GPR 12. O Plano do Projeto é revisado com 
todos os interessados e o compromisso com ele 
é obtido;
138
Resultados esperados
GPR 13. O projeto é gerenciado utilizando-se o 
Plano do Projeto e outros planos que afetam o 
projeto e os resultados são documentados;
GPR 14. O envolvimento das partes interessadas 
no projeto é gerenciado;
GPR 15. Revisões são realizadas em marcos do 
projeto e conforme estabelecido no 
planejamento;
06/03/2012
70
139
Resultados esperados
GPR 16. Registros de problemas identificados e 
o resultado da análise de questões pertinentes, 
incluindo dependências críticas, são 
estabelecidos e tratados com as partes 
interessadas;
GPR 17. Ações para corrigir desvios em relação 
ao planejado e para prevenir a repetição dos 
problemas identificados são estabelecidas, 
implementadas e acompanhadas até a sua 
conclusão;
140
Gerência de Requisitos (GRE)Gerência de Requisitos (GRE)Gerência de Requisitos (GRE)Gerência de Requisitos (GRE)
PropósitoPropósitoPropósitoPropósito
O propósito do processo Gerência de Requisitos 
é gerenciar os requisitos do produto e dos 
componentes do produto do projeto e identificar 
inconsistências entre os requisitos, os planos do 
projeto e os produtos de trabalho do projeto.
06/03/2012
71
141
Resultados esperados
GRE 1. Os requisitos são entendidos, avaliados 
e aceitos junto aos fornecedores de requisitos, 
utilizando critérios objetivos;
GRE 2. O comprometimento da equipe técnica 
com os requisitos aprovados é obtido;
GRE 3. A rastreabilidade bidirecional entre os 
requisitos e os produtos de trabalho é 
estabelecida e mantida;
142
Resultados esperados
GRE 4. Revisões em planos e produtos de 
trabalho do projeto são realizadas visando a 
identificar e corrigir inconsistências em relação 
aos requisitos; 
GRE 5. Mudanças nos requisitos são 
gerenciadas ao longo do projeto.
06/03/2012
72
143
Medida do quanto o processo atinge o seu Medida do quanto o processo atinge o seu Medida do quanto o processo atinge o seu Medida do quanto o processo atinge o seu 
propósitopropósitopropósitopropósito
Resultado esperado do Atributo do Processo
RAP 1. O processo atinge seus resultados 
definidos
* RAP – Resultado do Atributo de Processo144
Medida do quanto a execução do processo é Medida do quanto a execução do processo é Medida do quanto a execução do processo é Medida do quanto a execução do processo é 
gerenciadagerenciadagerenciadagerenciada
Resultados esperados do Atributo do Processo
RAP 2. Existe uma política organizacional 
estabelecida e mantida para o processo
RAP 3. A execução do processo é planejada
RAP 4. (Para o Nível G) . A execução do 
processo é monitorada e ajustes são 
realizados
Processo de Processo de 
gerência de 
projetos/proces
so de gerência 
de requisitos
06/03/2012
73
145
Resultados esperados do Atributo do Processo
RAP 5. (Até o Nível F) As informações e os 
recursos necessários para a execução do 
processo são identificados e disponibilizados 
RAP 6. (Até o Nível F) As responsabilidades e 
a autoridade para executar o processo são 
definidas, atribuídas e comunicadas
RAP 7. (Até o Nível F) As pessoas que 
executam o processo são competentes em 
termos de formação, treinamento e experiência
Resultados esperados do Atributo do Processo
RAP 8. A comunicação entre as partes 
interessadas no processo é gerenciada de forma a 
garantir o seu envolvimento
RAP 9. (Até o Nível F) Os resultados do processo 
são revistos com a gerência de alto nível para 
fornecer visibilidade sobre a sua situação na 
organização
RAP 10. (Para o Nível G) O processo planejado 
para o projeto é executado