CT Cosis 2016 5

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO ACADÊMICO DE INFORMÁTICA

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
LUCAS DE ALMEIDA CRUZ

LUIZ PHILIPPE MORO DE CARMO
ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

DESENVOLVIMENTO DE SOFTWARE
TRABALHO DE CONCLUSÃO DE CURSO
CURITIBA
2016
LUCAS DE ALMEIDA CRUZ
LUIZ PHILIPPE MORO DE CARMO
ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

DESENVOLVIMENTO DE SOFTWARE
Trabalho de Conclusão do Curso de

Bacharelado em Sistemas de Informação,
apresentado à UTFPR como requisito
parcial para obtenção do título de bacharel
em Sistemas de Informação.
Orientador: Robson Ribeiro Linhares
CURITIBA
2016
RESUMO
Cruz, L., e Moro, L. ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

DESENVOLVIMENTO DE SOFTWARE. 2016. Monografia – Trabalho de
conclusão de curso de Bacharelado em sistemas de informação,
Universidade tecnológica federal do Paraná. Curitiba, 2016.
Este trabalho apresenta a análise do grau de maturidade de

desenvolvimento de software realizada em um departamento de uma
universidade federal, utilizando os princípios do CMMI. Apresenta-se
conceitos de desenvolvimento de software e gerencia de projetos. Discute-
se os conceitos do CMMI e seus enfoques, bem como sua relação com os
processos de desenvolvimento. Complementado por uma pesquisa realizada
com os membros do departamento estudado e análises dos documentos do
processo atual, o estudo verificou as falhas de maturidade que existem
dentro do modelo de desenvolvimento atual.
Apresenta-se como resultado um plano desenvolvido posterior a análise com
objetivo de melhoria dos processos de desenvolvimento internos, buscando
atingir o nível 2 de maturidade de acordo com o CMMI, bem como um
website desenvolvido para a divulgação deste plano.
Palavras-chave: CMMI. Modelagem de sistemas. Maturidade em

desenvolvimento de software. Modelagem de processos. Gerência de
projetos.
ABSTRACT
Cruz, L., e Moro, L. ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

DESENVOLVIMENTO DE SOFTWARE. 2016. Monografia – Trabalho de
conclusão de curso de Bacharelado em sistemas de informação,
Universidade tecnológica federal do Paraná. Curitiba, 2016.
This Project presents an analysis of the maturity levels in the software

development process of a department inside a federal university, using the
principles of CMMI. The concepts of software development and project
management are presented. The CMMI model and its focus are also
discussed, as well as its relationship with the development processes.
Complemented for a research performed with the members of the studied
department, and an analysis of the process documents, the study found flaws
inside the current development model.
As result it presents an improvement plan, developed after the analysis,
which aims to help the department to reach maturity level 2 in CMMI, as well
as a website developed to publish this plan.
Keywords: CMMI. Systems modeling. Maturity in software development.

Process modeling. Project management.
LISTA DE FIGURAS
Figura 1 - Modelo Cascata.......................................................................... 21
Figura 2 - Modelo incremental ................................................................... 22
Figura 3 - Modelo de prototipação ............................................................ 23
Figura 4 - Modelo de espiral de desenvolvimento ................................... 24
Figura 5 - Comparação dos custos das mudanças em diferentes

ambientes de desenvolvimento .......................................................... 25
Figura 6 - Fluxo do processo Scrum ......................................................... 27
Figura 7 - As três dimensões críticas ....................................................... 29
Figura 8 - Áreas de Processo na representação por Estágio ................. 31
Figura 9 - Áreas de Processo na representação Contínua ..................... 31
Figura 10 - Componentes do modelo CMMI ............................................. 32
Figura 11 - Processo de Negócio do Sistema de Gerenciamento de

Frota ...................................................................................................... 51
Figura 12 - Fluxo de Atividades ................................................................. 52
Figura 13 - Comparativo das taxas de Aderência .................................... 57
Figura 14 - Aderência de REQM................................................................. 58
Figura 15 - Aderência PP ............................................................................ 59
Figura 16 - Aderência PMC......................................................................... 59
Figura 17 - Aderência SAM......................................................................... 60
Figura 18 - Aderência MA ........................................................................... 61
Figura 19 - Aderência PPQA ...................................................................... 62

Figura 20 - Aderência CM ........................................................................... 62
Figura 21 - Processo Local de desenvolvimento(PLD) ........................... 64
Figura 22 - Títulos de reponsabilidade ..................................................... 68
Figura 23 - Relação de REQM com as outras áreas de processo ........... 69
Figura 24 - Workflow de REQM .................................................................. 70
Figura 25 - Relação de PP com as outras áreas de processo................. 70
Figura 26 - Workflow PP ............................................................................. 71
Figura 27 - Relação de PMC com as outras áreas de processo ............. 72
Figura 28 - Workflow PMC .......................................................................... 73
Figura 29 - Relação de SAM com as outras áreas de processo ............. 74
Figura 30 - Worflow de SAM....................................................................... 75
Figura 31 - Relação de MA com as outras áreas de processo ................ 76
Figura 32 - Workflow de MA ....................................................................... 77
Figura 33 - Relação de PPQA com as outras áreas de processo ........... 77
Figura 34 - Workflow de PPQA .................................................................. 78
Figura 35 - Relação de CM com as outras áreas de processo ................ 79
Figura 36 - Workflow de CM ....................................................................... 79
Figura 37 - Tela Inicial do Site.................................................................... 82
Figura 38 - Tela de apresentação do Processo Local .............................. 83
Figura 39 - Tela de apresentação da área Planejamento de Projeto ...... 84

LISTA DE TABELAS
Tabela 1 - Metas Genéricas e Nomes de Processos ................................ 33
Tabela 2 - Critérios SCAMPI x Pesquisa ................................................... 55
Tabela 3- REQM01....................................................................................... 69
Tabela 3- REQM01....................................................................................... 99
Tabela 4 - REQM02...................................................................................... 99
Tabela 5 - REQM03...................................................................................... 99
Tabela 6 - REQM01...................................................................................... 99
Tabela 7 - REQM05.................................................................................... 100
Tabela 8 - PP01.......................................................................................... 100
Tabela 9 - PP02.......................................................................................... 100
Tabela 10 - PP03........................................................................................ 100
Tabela 11 - PP04........................................................................................ 101
Tabela 12 - PP05........................................................................................ 101
Tabela 13 - PP06........................................................................................ 101
Tabela 14 - PP07........................................................................................ 101
Tabela 15 - PP08........................................................................................ 102
Tabela 16 - PP09........................................................................................ 102
Tabela 17 - PP10........................................................................................ 102
Tabela 18 - PP11........................................................................................ 102
Tabela 19 - PP12........................................................................................ 102
Tabela 20 - PP13........................................................................................ 103

Tabela 21 - PP14........................................................................................ 103
Tabela 22 - PMC01 .................................................................................... 103
Tabela 23 - PMC02 .................................................................................... 103
Tabela 24 - PMC03 .................................................................................... 104
Tabela 25 - PMC04 .................................................................................... 104
Tabela 26 - PMC05 .................................................................................... 104
Tabela 27 - PMC06 .................................................................................... 104
Tabela 28 - PMC07 .................................................................................... 104
Tabela 29 - PMC08 .................................................................................... 105
Tabela 30 - PMC09 .................................................................................... 105
Tabela 31 - PMC10 .................................................................................... 105
Tabela 32 - SAM01 .................................................................................... 105
Tabela 33 - SAM02 .................................................................................... 106
Tabela 34 - SAM03 .................................................................................... 106
Tabela 35 - SAM04 .................................................................................... 106
Tabela 36 - SAM05 .................................................................................... 107
Tabela 37 - SAM06 .................................................................................... 107
Tabela 38 - SAM07 .................................................................................... 107
Tabela 39 - SAM08 .................................................................................... 107
Tabela 40 - MA01 ....................................................................................... 108
Tabela 41 - MA02 ....................................................................................... 108
Tabela 42 - MA03 ....................................................................................... 108
Tabela 43 - MA04 ....................................................................................... 108

Tabela 44 - MA05 ....................................................................................... 108
Tabela 45 - MA06 ....................................................................................... 109
Tabela 46 - MA07 ....................................................................................... 109
Tabela 47 - MA08 ....................................................................................... 109
Tabela 48 - PPQA01 .................................................................................. 109
Tabela 49 - PPQA02 .................................................................................. 110
Tabela 50 - PPQA03 .................................................................................. 110
Tabela 51 - PPQA04 .................................................................................. 110
Tabela 52 - CM01 ....................................................................................... 111
Tabela 53 - CM02 ....................................................................................... 111
Tabela 54 - CM03 ....................................................................................... 111
Tabela 55 - CM04 ....................................................................................... 111
Tabela 56 - CM05 ....................................................................................... 112
Tabela 57 - CM06 ....................................................................................... 112
Tabela 58 - CM07 ....................................................................................... 112

LISTA DE SIGLAS
CMMI Capability Maturity Model® Integration

SEI Software Engineering Institute
RUP Rational Unified Process
REQM Gerenciamento de Requisitos
PP Planejamento de Projeto
PMC Monitoramento e Controle de Projeto
SAM Gestão de Acordos com Fornecedores
MA Medição e Análise
PPQA Garantia da Qualidade de Processo e Produto
CM Gerenciamento de Configuração
AI Amplamente Implementada
PI Parcialmente Implementada
NI Não Implementada
LISTA DE SÍMBOLOS
∑ Somatório
n Número de respostas
ai Resposta amplamente implementada
pi Resposta parcialmente implementada
p Peso (0 – 1) das respostas parcialmente implementada
SUMÁRIO
1 INTRODUÇÃO ........................................................................................... 15
1.1 Objetivo Geral .................................................................................... 15
1.2 Objetivos Específicos ........................................................................ 15
1.3 Justificativa ........................................................................................ 16
1.4 Método de Pesquisa .......................................................................... 16
1.5 Organização do Trabalho .................................................................. 17
2 REFERENCIAL TEÓRICO ........................................................................ 19
2.1 Processos de Software ..................................................................... 19
2.2 Modelos de Processo ........................................................................ 20
2.2.1 Modelo Cascata ............................................................................ 20
2.2.2 Modelo de Processo Incremental ............................................... 21
2.2.3 Modelo de Processo Evolucionário ........................................... 22
2.3 Desenvolvimento Ágil ....................................................................... 24
2.3.1 O Processo Ágil ........................................................................... 25
2.3.2 Os Princípios da Agilidade.......................................................... 26
2.3.3 Scrum ............................................................................................ 26
2.4 CMMI ................................................................................................... 27
2.4.1 Tipo de Representação................................................................ 30
2.4.2 Componentes das Áreas de Processo ....................................... 31
2.4.3 Metas e Práticas ........................................................................... 33
2.4.4 Níveis de Maturidade ................................................................... 34

2.4.5 As Áreas de Processo do Nível 2 de Maturidade ...................... 35
2.4.6 Planos em Melhoria de Processo ............................................... 41
2.5 Métodos de Avaliação e Diagnóstico ............................................... 41
2.5.1 SCAMPI ......................................................................................... 42
2.5.1 PIID ................................................................................................ 44
2.6 Estudos de Casos Relacionados em CMMI ..................................... 44
2.7 Norma ISO/IEC 15504 ........................................................................ 45
2.8 Considerações Finais ........................................................................ 46
3 ANÁLISE DE MATURIDADE .................................................................... 48
3.1 Contexto ............................................................................................. 48
3.2 Método de Análise da Maturidade .................................................... 52
3.3 Diagnóstico ........................................................................................ 52
3.4 Análise ................................................................................................ 55
3.5 Conclusões da Análise ...................................................................... 63
4 PROPOSTA DE PROCESSO LOCAL DE DESENVOLVIMENTO ........... 64
4.1 Etapas de Desenvolvimento ............................................................. 64
4.2 Detalhamento das Áreas de Processo ............................................. 68
4.2.1 REQM ............................................................................................ 69
4.2.2 PP .................................................................................................. 70
4.2.3 PMC ............................................................................................... 72
4.2.4 SAM ............................................................................................... 74
4.2.5 MA ................................................................................................. 75
4.2.6 PPQA ............................................................................................. 77
4.2.7 CM ................................................................................................. 79
4.3 Site de Divulgação ............................................................................. 80
4.3.1 Aspectos Técnicos ...................................................................... 80
4.3.2 Desenvolvimento ......................................................................... 81
5 CONCLUSÃO ............................................................................................ 85
5.1 Objetivos Alcançados ....................................................................... 85
5.2 Desafios .............................................................................................. 85
5.3 Conclusões sobre a Pesquisa .......................................................... 86
5.4 Trabalhos Futuros ............................................................................. 86
REFERÊNCIAS ............................................................................................ 88
APÊNDICE A ................................................................................................ 91
APÊNDICE B ................................................................................................ 99
15
1 INTRODUÇÃO
O desenvolvimento de software é a base na pirâmide para a evolução

tecnológica na área da computação. Existem inúmeras etapas pelas quais
um software passa desde a sua idealização até sua produção e
posteriormente sua aplicação e suporte. O principal foco da Engenharia de
Software é organizar todo esse processo conhecido como ciclo de vida de
um software, que pode vir a ser extremamente complexo e problemático
dependendo do nível de maturidade da organização. (CMMI-DEV, 2006).
Uma das maneiras para saber a situação de maturidade do

desenvolvimento de software em uma organização é pelo Capability Maturity
Model Integration (CMMI), que é homologado pela Software Engineering
Institute. (CMMI-DEV, 2006).
1.1 Objetivo Geral

O principal objetivo deste trabalho de conclusão de curso é a análise
das metodologias aplicadas no desenvolvimento de software dentro da
Universidade Tecnológica Federal do Paraná (UTFPR) para descobrir em
qual nível de maturidade a organização se encontra de acordo com o CMMI
e propor a aplicação de práticas que visem a melhorar este nível de
maturidade.
1.2 Objetivos Específicos

Os objetivos específicos são:
 Análise das metodologias no desenvolvimento de software aplicadas

atualmente na UTFPR por meio de um caso de estudo
 Criação de uma proposta de modelo de desenvolvimento de software
baseado em CMMI para aplicação interna da UTFPR
16
 Divulgação deste modelo local por meio de um website de consulta de

conteúdo para divulgar os processos a serem seguidos no
desenvolvimento de software.
1.3 Justificativa
Um dos grandes desafios encontrados na produção de software é o
gerenciamento da informação. Hoje em dia a tradicional divisão entre
engenharia de software e o gerenciamento da informação nele contida vem
diminuindo, e em grandes empresas o gerenciamento da informação já é
moldado pela estrutura de processos usada na mesma.
Muitas empresas aplicam as práticas propostas pelo CMMI buscando

uma maior maturidade no desenvolvimento de software, isso aperfeiçoa
seus processos internos, o que consequentemente reduz os custos e
aumenta sua produção. Ao se aplicar essas mesmas práticas na UTFPR é
esperado um aumento da qualidade dos softwares produzidos caso ela
venha a adotar um modelo estratégico eficiente. Outro fator muito importante
é que como se trata de uma Universidade pública que muitas vezes tem
recursos bem limitados, a redução do custo de desenvolvimento pode criar
um melhor aproveitamento das verbas disponíveis para os projetos em
questão.
1.4 Método de Pesquisa

O primeiro passo da pesquisa foi encontrar um departamento de
desenvolvimento de software com projetos em andamento que pudéssemos
avaliar. Foi encontrado um Departamento da Universidade (DU) que era
responsável pelo desenvolvimento de software na UTFPR.
Foi entrado em contato com o diretor do departamento que em uma
primeira instância se mostrou bastante entusiasmado com a ideia e nos
forneceu a documentação do projeto que estava em desenvolvimento. A
17
partir daí deu se início a pesquisa do referencial teórico, avaliando quais

seriam os melhores métodos a serem utilizados para analisar a situação
atual do processo de desenvolvimento utilizado pelo DU e qual seu nível de
maturidade.
Após um período de estudo do CMMI e de seus processos de análise,
foi decidido que a melhor maneira de realizar a análise do nível de
maturidade atual do departamento seria por meio de uma adaptação do
Practical Implementation Indicator Document (PIID). Com isso foi criado um
questionário (Apêndice A) que foi respondido pelos membros do time de
desenvolvimento e que juntamente com a análise da documentação do
projeto, nos permitiram avaliar as deficiências no processo do departamento
estudado.
A partir do resultado dessa análise, foi construído um plano de
melhoria que foi baseado nos planos e metas e no GAP analisys do CMMI,
onde são listadas todas as ações que são necessárias para se atingir o nível
2 de maturidade do CMMI, em seguida as ações foram organizadas por
áreas de processo e adaptadas para a realidade do departamento,
customizando-as de modo a gerar uma proposta de melhoria simples e
organizada que pudesse de fato ser seguida e implementada.
Por fim, com o intuito de disponibilizar a proposta do plano de
melhoria, foi criado um website que pudesse ser facilmente acessado e visto
por todos os membros e gestores do time de desenvolvimento do DU.
1.5 Organização do Trabalho

Este trabalho está dividido em 5 capítulos. Este primeiro capitulo de
introdução situa o contexto deste trabalho e descreve os principais objetivos
a serem alcançados.
No segundo capitulo é apresentado o referencial teórico do modelo
CMMI bem como o de outros processos de desenvolvimento de software.
18
No Terceiro Capitulo é dissertado sobre o processo de análise que foi

realizado durante este trabalho, e explicado sobre a metodologia utilizada e
são apresentados os resultados que foram obtidos.
No quarto capitulo é apresentada a proposta de melhoria criada com
base na análise realizada.
No quinto e último capitulo são relatadas as conclusões obtidas no
trabalho e sugestões para trabalhos futuros.
19
2 REFERENCIAL TEÓRICO
Neste capitulo é apresentado o referencial teórico dos principais

modelos de processo de software e do modelo de maturidade escolhido para
a análise de CMMI.
2.1 Processos de Software
Uma das melhores definições do que é um processo de software foi

apresentada por um economista chamado Howard Baetjer, que diz o
seguinte:
“Pelo fato de software, como todo capital, ser conhecimento

incorporado, e pelo fato de esse conhecimento ser, inicialmente, disperso,
tácito, latente e em considerável medida, incompleto, o desenvolvimento de
software é um processo de aprendizado social.” (Baetjer, 1998)
A metodologia para as atividades, ações e tarefas no

desenvolvimento de software poderiam ser traduzidas como “processo de
software”. Este processo segue uma metodologia genérica de engenharia de
software que pode ser apresentada em cinco atividades: comunicação,
planejamento, modelagem, construção e emprego (Pressman, 2010).
A primeira atividade é a comunicação que compreende o momento

anterior ao início da parte técnica no desenvolvimento do software. Sua
principal função é o levantamento dos requisitos do sistema que irão definir
as características e funções do software. Nesta etapa do processo é de
extrema importância a comunicação entre os stakeholders, neste caso o
cliente e o grupo de desenvolvimento.
A segunda atividade é o planejamento que tem como objetivo a

criação de um plano de projeto de software, que deve descrever as tarefas
técnicas a serem conduzidas, quais são os riscos possíveis, quais recursos
serão utilizados, o que será produzido e um cronograma do projeto.
20
A terceira atividade é a modelagem que tem como finalidade

desenvolver um “esboço” da solução, para que se tenha uma ideia de tudo
que o software precisa. Caso seja necessário compreender melhor o
problema e como resolvê-lo, deve-se refinar o tal “esboço” para que possa
atender as necessidades do projeto.
A quarta atividade é a construção que é caracterizada por ser mais

técnica, onde é gerado o código do software (manual ou automatizada) e
são realizados os testes de software para que estejam atendendo os
requisitos.
A última atividade é o emprego que é conhecida muitas vezes como

entrega ou integração, no qual o cliente recebe o software e faz uma
avaliação e fornece um feedback.
2.2 Modelos de Processo
A seguir são apresentados os modelos de processo de software mais

relevantes no escopo deste trabalho
2.2.1 Modelo Cascata
Muitas vezes conhecido como ciclo de vida clássico no

desenvolvimento de software, o modelo cascata tem uma abordagem
sequencial e sistemática do processo de desenvolvimento de software.
Começando desde o levantamento de requisitos pelo cliente, avançando
para o planejamento, modelagem, construção, até a entrega e suporte
continuo do software (Pressman, 2010). O modelo cascata é considerado o
paradigma mais antigo dentro da engenharia de software, que pode ser
visualizado na Figura 1.
21
Figura 1 - Modelo Cascata

Fonte: Pressman (2010)
Ao longo do tempo alguns problemas foram encontrados (Hanna,

1995). O primeiro problema encontrado foi que muitas vezes os projetos
reais dificilmente seguem um fluxo sequencial que é proposto no modelo, e
as mudanças que podem ocorrer num projeto real atrapalha esse fluxo
sequencial. Outro problema é a dificuldade do cliente de explicitar logo de
início todos os requisitos que o sistema deve conter, com isso a dificuldade
de se adequar as mudanças que o cliente deseja. E por fim, uma versão
operacional do sistema só estará pronta nas etapas finais do projeto,
podendo assim o resultado ser desastroso se não atender as expectativas
do cliente.
2.2.2 Modelo de Processo Incremental
Da combinação de elementos sequenciais e paralelos surgiu o

modelo incremental, que aplica essas sequencias lineares de uma maneira
escalonada conforme o decorrer do tempo o projeto (Figura 2). Os
incrementos, que para esse modelo seriam os artefatos entregáveis do
software, são gerados por cada sequência linear (McDermid e Rook, 1993).
22
Figura 2 - Modelo incremental

Um bom exemplo de uso do modelo incremental seria o

desenvolvimento de um processador de texto, que primeiramente liberaria as
funções básicas de gerenciamento de arquivos, edição e produção de
documentos num primeiro incremento. E num segundo incremento poderia
apresentar funções adicionais como revisão ortográfica e gramatical
(Pressman, 2010). Por isso é comum o primeiro incremento ser conhecido
como o produto essencial, que atende aos requisitos básicos para o sistema
operar. Além disso, este modelo tem como objetivo ter um produto
operacional entregue em cada um dos seus incrementos. Quando
comparado ao modelo anterior (cascata) que só teria a possibilidade de ter o
produto em operação nas partes finais do processo, este modelo resolve o
problema de alinhamento com as necessidades do cliente antes que seja
tarde demais.
2.2.3 Modelo de Processo Evolucionário
Os sistemas estão em constante evolução e o software não foge a

essa regra. O modelo evolucionário tenta estar preparado para as inúmeras
possibilidades de evolução que o processo de desenvolvimento de software
23
pode ter. Por isso mesmo, que este modelo é iterativo e apresenta
características que possibilite o desenvolvimento de versões cada vez mais
completas de software. Existem dois modelos que surgiram a partir do
processo evolucionário: prototipação e espiral (Pressman, 2010).
O primeiro modelo, de prototipação, é muitas vezes usado quando o

cliente não tem definido quais são as funcionalidades para o sistema, mas
sabe quais são seus objetivos gerais. Em outro momento, podem ser os
desenvolvedores que não sabem ao certo como vai ocorrer a interação do
homem com o software. Este modelo (Figura 3) tem início com a
Comunicação, como nos modelos anteriores, mas a partir daí o processo
muda completamente com relação aos anteriores. A partir do processo de
comunicação se inicia o projeto rápido que tem como finalidade o início da
construção do protótipo que deve ser realizado por meio dos processos
seguintes. De maneira geral a ideia é que esses protótipos tenham uma
opinião do cliente para que o software sofra o processo evolucionário e que
a cada ciclo se transforme até o ponto de ser um sistema real. Toda a parte
de prototipagem está mais voltada à parte de interação do cliente com o
software.
Figura 3 - Modelo de prototipação

24
O segundo modelo, o espiral (Figura 4), foi proposto por Barry Boehm
que descreve esse modelo da seguinte forma: “O modelo espiral de
desenvolvimento é um gerador de modelo de processos dirigidos a riscos e
é utilizado para guiar a engenharia de sistemas intensivos de software, que
ocorre de forma concorrente e em múltiplos envolvidos.” (Boehm, 2001). De
maneira geral, quando se utiliza o modelo espiral se tem uma combinação
das iterações da prototipação com os aspectos sistemáticos do modelo
cascata, para que seja iterativo e ao mesmo tempo seja bem controlado. De
maneira resumida cada um dos passos como o de comunicação,
planejamento, modelagem, construção, emprego, são muito próximos
daqueles explicados anteriormente, mas com a diferença que ao longo do
ciclo de vida ele é realizado novamente várias vezes. Dessa maneira se
tornando um processo evolutivo de desenvolvimento de software, se
baseando no que havia sido realizado anteriormente.
Figura 4 - Modelo de espiral de desenvolvimento

2.3 Desenvolvimento Ágil
Antes de buscar entender o que é o desenvolvimento Ágil deve-se

buscar entender o que seria o termo agilidade na engenharia de software.
Para explicar melhor este termo, Ivar Jacobson coloca a agilidade como
sendo a palavra em comum nos dias atuais para descrever um moderno
processo de software. Além disso, para ele o principal condutor para a
agilidade é a inserção da mudança no decorrer do desenvolvimento
25
(Jacobson, 2002). A partir desse ponto pode se fazer uma comparação dos
custos das mudanças em ambiente de desenvolvimento ágil que está
preparado para a mudança com um clássico que não está (Figura 5).
Figura 5 - Comparação dos custos das mudanças em diferentes ambientes de

desenvolvimento
2.3.1 O Processo Ágil
A partir de um melhor entendimento do que seria a agilidade dentro

da engenharia de software já é possível entender um pouco o que seria esse
processo ágil. Os projetos de software que utilizam esse processo são
caracterizados pela maneira que interagem com uma série de processos
chaves que são (Fowler, 2002):
 A dificuldade de definir antecipadamente os requisitos do software

que irão persistir ou serão alterados;
 Indefinição com relação à quantidade de trabalho do projeto que será
necessário antes da construção, para avaliar o projeto;
 As partes de análise, projeto, construção e testes não são muito
previsíveis, com relação ao planejamento.
26
2.3.2 Os Princípios da Agilidade
Para quem deseja ter agilidade a Aliança de Agilidade (Agile Alliance,

2003) estabelece os 12 princípios a seguir:
 Garantir a satisfação do consumidor entregando rapidamente e

continuamente software funcionais;
 Software funcionais são entregues frequentemente (semanas, ao

invés de meses);
 Software funcionais são a principal medida de progresso do projeto;
 Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
 Cooperação constante entre pessoas que entendem do “negócio” e

desenvolvedores;
 Projetos surgem através de indivíduos motivados, entre os quais

existe relação de confiança.
 Design do software deve prezar pela excelência técnica;
 Simplicidade;
 Rápida adaptação às mudanças;
 Indivíduos e interações mais do que processos e ferramentas;
 Software funcional mais do que documentação extensa;
 Colaboração com clientes mais do que negociação de contratos;
 Responder a mudanças mais do que seguir um plano.
2.3.3 Scrum
O Scrum foi concebido por Jeff Sutherland e sua equipe de

desenvolvimento no início dos anos 1990. E nos últimos anos sofreu
27
algumas atualizações nos métodos gráficos por Schwaber e Beedle

(Schwaber e Beedle, 2001).
O Scrum se utiliza de um conjunto padrão de processos de software

que tem provado serem muito eficientes com a necessidade de urgência de
entrega, requisitos em constante mudança do negócio.
O backlog do produto é uma lista com todas as funcionalidades

desejadas pelo cliente. E todas essas funcionalidades servem de base para
a criação de uma Sprint backlog que apresenta uma funcionalidade que
deve ser implementada durante o tempo da Sprint. Essa funcionalidade é
quebrada em diversas tarefas que são chamadas de User Stories, ou
histórias do usuário. O fluxo geral do processo Scrum é ilustrado na Figura
6.
Figura 6 - Fluxo do processo Scrum

2.4 CMMI
Existem vários modelos de maturidade, padrão, metodologias e

diretrizes que podem auxiliar uma organização a melhorar seus processos.
Contudo, as outras abordagens disponíveis tem o seu foco em uma parte
específica do negócio e não uma visão sistêmica do negócio. Esse tipo de
28
abordagem tende a criar barreiras e compartimentalizar as organizações. O

CMMI seria um caminho para evitar ou eliminar essas barreiras por meio de
modelos integrados de processos. E o CMMI-DEV (CMMI para
desenvolvimento) oferece alguma das melhores práticas relacionadas com o
desenvolvimento e manutenção de software (CMMI® for Development,
2006).
O Framework CMMI é um modelo criado pelo Instituto de Engenharia

de Software(SEI) da universidade Carnegie Mellon(EUA), com apoio do
departamento de defesa dos Estados Unidos. Esse modelo é uma evolução
de seu predecessor, o CMM, que traz massivas melhorias e que tem como
objetivo o aumento na qualidade dos produtos e serviços oferecidos, assim
como melhoria na eficiência no desenvolvimento de softwares e hardwares
(CMMI® for Development, 2006).
Existem três áreas principais nas quais as empresas normalmente

investem quando estão em busca de desenvolvimento: Pessoas, Tecnologia
e Processos. O mundo vive um momento cheio de mudanças no qual a
tecnologia está sempre em avanço e mudando, e onde as pessoas
costumam trabalhar para várias empresas diferentes durante sua carreira
profissional, por isso o principal fator que faz com que as empresas
funcionem e se mantenham estáveis são os processos. Ao se investir em
melhorias processuais as organizações estão investindo em uma área que
oferece a estabilidade e a infraestrutura necessária para lidar com um
mundo que está sempre mudando, além de potencializar o rendimento de
seu pessoal e de sua tecnologia/equipamento, aumentando assim sua
produtividade. Na Figura 7 pode-se observar essas três dimensões críticas
de CMMI (CMMI® for Development, 2006).
29
Figura 7 - As três dimensões críticas

Fonte: CMMI® for Development 2006)
Vale ressaltar que o CMMI não é um processo, o CMMI é um modelo

de processo que foi baseado nas melhores práticas para desenvolvimento e
manutenção de produtos e serviços, e que descreve as características que
são necessárias para se obter uma cadeia de processos eficiente.
2.3.1 Diferenças entre os modelos de maturidade e capacidade
Quando se fala em CMMI se apresenta duas possibilidades de

modelos a serem utilizados em sua aplicação dentro da organização, são
eles os níveis de maturidade e de capacidade. A maior diferença entre eles
está relacionada ao foco em que eles tem em relação à área de processo e
como ele permite as organização se basearem a partir deles.
Os níveis de maturidade estão ligados a um conjunto de áreas de

processos que representam a sua maturidade e os níveis de capacidade
30
estão ligados às áreas de processos em si, se aquela área tem capacidade

ou não, e reunindo um grupo delas pode-se definir a sua capacidade. Um
problema com relação à capacidade está no fato em que não foi muito
utilizada nas organizações, diferente da maturidade que é usada desde o
CMM.
2.4.1 Tipo de Representação

No CMMI são utilizados dois tipos de representação diferente para a
melhoria e avaliação dos processos: estágio e contínua. A representação
contínua (Figura 9) é focada nas áreas de processo do CMMI, e quando uma
organização escolhe essa representação o seu foco é a melhoria individual
de cada processo. Além disso, ela se utiliza de níveis de capacidade, que
representa uma melhoria ligada a uma área do processo em particular. Do
outro lado a representação por estágio (Figura 8) se utiliza de conjuntos pré-
definidos das áreas de processos que irão auxiliar na definição da melhoria
na organização. E esse caminho é definido por níveis de maturidade que é
representado por um conjunto de áreas de processos que determinam
aquele nível (CMMI® for Development, 2006).
31
Figura 8 - Áreas de Processo na representação por Estágio

Fonte: CMMI® for Development (2006)
Figura 9 - Áreas de Processo na representação Contínua

2.4.2 Componentes das Áreas de Processo

Primeiramente, antes de explicar sobre os componentes das áreas de
processo, o modelo e o tipo de representação escolhido para o
desenvolvimento desse trabalho são o modelo de maturidade e a
representação por estágios.
32
Uma área de processo é formada por componentes, que são divididos

em três categorias: requeridos, esperados e informativos. O primeiro são os
componentes requeridos que representam o que essencialmente uma
organização deve implementar para aquela área de processo. Eles são
utilizados como critério de avaliação para decidir se a área foi implementada
ou não. O segundo, são os componentes esperados que descrevem
algumas possibilidades de implantação para satisfazer um componente
requerido. Eles são constituídos de práticas genéricas e práticas específicas.
E por fim os componentes informativos que são um meio de auxiliar as
organizações no processo de implantação dos componentes requeridos e
esperados. Na Figura 10 temos uma ideia dessa organização dos
componentes dentro de uma área de processo.
Figura 10 - Componentes do modelo CMMI

33
2.4.3 Metas e Práticas

As metas e práticas dentro processo de CMMI são maneiras de
mostrar o que os processos de cada área devem apresentar. Para se ter um
maior entendimento de como eles são organizados no modelo CMMI é
necessário entender o conceito de institucionalização, por ser de extrema
importância quando se trabalha com melhoria de processo.
A institucionalização se daria à medida que o processo fosse

enraizado na forma que o trabalho é executado, assim se tornando uma
padronização na execução do processo e um comprometimento em relação
à sua execução. O nível de institucionalização é apresentado nas metas
genéricas e expresso nos nomes dos processos associados a cada meta,
como indicado na Tabela 1.
Tabela 1 - Metas Genéricas e Nomes de Processos

Nesse trabalho é dado maior destaque ao processo executado, como

apresentado pela meta genérica GG1. Esta meta define que o processo
apoia e permite a satisfação das metas específicas da área de processo,
transformando produtos de trabalho de entrada identificáveis em produtos de
trabalho de saída identificáveis.
Outro ponto de destaque é a execução das práticas específicas do

processo, auxiliando no desenvolvendo dos produtos de trabalho e também
fornecendo serviços, que ajudam a satisfazer às metas específicas que são
34
apresentadas em cada área de processo. Algo que é importante ressaltar é

que essas práticas podem ser executadas informalmente sem seguir uma
descrição documentada de processo ou um plano.
2.4.4 Níveis de Maturidade

De acordo com os princípios vistos em CMMI pode-se quantificar o
grau de maturidade de uma organização avaliando seus processos e a
maneira como eles são gerenciados (CMMI® for Development, 2006).
Existem cinco níveis de maturidade que podem ser atingidos por uma
empresa: Inicial, Gerenciado, Definido, Gerenciado quantitativamente e
Otimizando.
Nível 1 - Inicial: No nível inicial temos os processos que atingem seu

objetivo porém não são controlados ou existe um déficit em seu controle. Os
métodos usados são imprevisíveis e normalmente os projetos são feitos de
forma reativa, combatendo os problemas depois que eles já apareceram
(Fire Fighting). Nesse nível a efetividade dos processos é muito baixa e
normalmente existe um alto grau de frustração do pessoal envolvido.
Nível 2 - Gerenciado: No segundo nível encontramos os processos

Gerenciados. Processos gerenciados são aqueles que são planejados e
executados seguindo uma política bem definida da empresa. Esses
processos são executados por uma pessoa capaz, contam com recursos
adequados e tem uma produção controlada. Esses projetos normalmente
chegam mais perto de atingir objetivos específicos como custo, qualidade e
cronograma.
Um dos grandes problemas desse nível é que eles normalmente são

muito dependentes de algumas poucas pessoas experientes. Isso pode vir a
ser um grande problema pois o processo para de funcionar caso esses
“heróis” se afastem da operação por algum motivo.
35
Nível 3 - Definido: Processos classificados como definidos são

aqueles que são definidos, compreendidos e aplicados englobando toda a
organização. Os procedimentos, ferramentas, métodos e a visão do negócio
são padronizados, isso faz com que a organização inteira siga os mesmos
guidelines e esteja sempre em sincronia. Nesse nível os processos são
normalmente proativos, ou seja, ao contrário dos dois primeiros níveis eles
não são focados em arrumar problemas no improviso.
Nível 4 - Gerenciado Quantitativamente: No quarto nível de CMMI

temos os processos gerenciados quantitativamente. Esses processos
estabelecem metas de qualidade e desempenho e depois usam essas metas
como critério para gerenciar projetos futuros. A principal diferença do quarto
nível quando comparado ao terceiro é a habilidade de prever o desempenho
e a eficiência dos projetos, pois nesse nível os projetos são controlados
usando dados estatísticos e outras técnicas quantitativas.
Nível 5 - Em Otimização: Quando uma organização atinge o quinto e

último nível de CMMI ela passa a focar continuamente na melhoria de seus
processos utilizando medidas quantitativas e dados estatísticos para prever
o resultado de seus projetos.
A principal diferença entre o quinto nível e seu predecessor é o foco

de suas melhorias. No nível quatro os dados são obtidos e usados para
melhoria de processos e subprocessos, enquanto no ultimo buscamos por
melhorias que afetem a eficiência e a desempenho em nível global. Obtemos
dados de múltiplos projetos e áreas de uma empresa e cruzamos esses
dados, assim podemos ter um maior entendimento do funcionamento da
organização como um todo.
2.4.5 As Áreas de Processo do Nível 2 de Maturidade

O nível 2 de maturidade em CMMI é formado por 7 áreas de processo
(CMMI® for Development, 2006), sendo elas:
36
37
Gerência de Requisitos(REQM):
A gerência de requisitos é a área responsável por supervisionar todos

os requerimentos recebidos e gerados durante a execução do projeto.
Para que um projeto seja bem sucedido e atenda as expectativas do

cliente é essencial que a análise de requisitos seja feita de forma adequada
e que exista um alinhamento entre os planos do projeto e seus
requerimentos.
É importante também manter a documentação dos requisitos

atualizada no decorrer do projeto, já que é bastante comum que durante um
projeto as necessidades do cliente evoluam ou até mesmo mudem, que
tecnologias se tornem obsoletas e que processos sejam alterados. Isso pode
alterar drasticamente os requisitos do projeto.
Planejamento de Projeto(PP):
Área responsável pela elaboração e cumprimento do plano do projeto.

Nesse plano são estabelecidos os produtos a serem produzidos, tarefas a
serem executadas, o cronograma do projeto e também a distribuição de
recursos.
É extremamente importante que essa análise seja feita

cuidadosamente, uma vez que nessa etapa são estabelecidos pontos
cruciais do projeto como escopo, divisão do trabalho e o orçamento. Além
disso, durante o planejamento também são identificados os potenciais riscos
do projeto e definido o envolvimento de cada equipe no desenvolvimento.
Semelhante aos requisitos do projeto (REQM), é necessário sempre

manter o plano do projeto atualizado em relação ao estado atual de
desenvolvimento, visto que o plano pode vir a mudar constantemente
durante sua execução.
38
39
Acompanhamento e Controle de Projeto(PMC):
O objetivo dessa área é monitorar as atividades do projeto durante

sua execução e determinar se o desempenho encontrado é semelhante ao
que era esperado durante a fase de planejamento, assim ações corretivas
podem ser tomadas caso o desempenho do projeto fuja muito do esperado.
São monitorados:
 Riscos do projeto
 Plano do projeto
 Atividades propostas
 Envolvimento dos stakeholders
 Gerenciamento de dados
 Milestones do projeto
Dependendo do resultado encontrado durante o monitoramento

podem ser necessárias alterações no plano do projeto e no gerenciamento
do mesmo.
Gerência de Acordos com Fornecedores(SAM):
Área responsável pelo controle de bens e serviços adquiridos para

serem usados durante o projeto. Aqui são definidos os tipos de cada
aquisição, escolhidos fornecedores confiáveis e estabelecidos acordos
comerciais.
Medição e Análise(MA):
“Por que medir?
Porque sem dados concretos tudo que nós temos são opiniões.
40
Por que analisar?
Por que os dados que você coleta de nada servem se você não os entende”
(CMMI-DEV v1.2)
O foco da medição e análise é coletar dados quantitativos sobre o

processo de desenvolvimento, sobre o projeto e sobre o produto em si.
Esses dados são então medidos e analisados com objetivo de ajudar a
organização a entender melhor seus próprios processos e tomar melhores
decisões estratégicas no futuro. A análise minuciosa dos dados pode
também ajudar a identificar soluções para problemas de ineficiência dentro
da empresa e outras oportunidades de melhorias.
Garantia da Qualidade de Processo e Produto(PPQA):
PPQA existe para garantir que os produtos entregues sejam da mais

alta qualidade. Essa área proporciona aos gerentes do projeto feedback dos
processos sendo executados e seus respectivos projetos.
O principal objetivo é garantir que todos os requerimentos sejam

atendidos durante o desenvolvimento, seguindo sempre os procedimentos
adequados e corrigindo qualquer possível falha no decorrer do processo.
Gerência de Configuração(CM):
CM é uma área importante para dar suporte ao processo de

desenvolvimento do seu produto, sendo responsável por todo o processo de
configuração de ambiente do desenvolvimento e até mesmo depois no
processo de implantação.
41
2.4.6 Planos em Melhoria de Processo

No desenvolvimento de melhoria de processo é necessário definir um
plano, bem como uma estratégia. Dentro do modelo CMMI é requisitada a
criação de um plano para cada Área de Processo, e cada um desses planos
contém: procedimentos, atividades, recursos, entre outros itens.
Um ponto que deve ser realçado no contexto proposto é que um

plano não seria um cronograma, mas uma estratégia para chegar a um
processo que esteja adequado em relação ao CMMI. Os principais planos
em melhoria de processo são:
 Plano de Melhoria de Processos: plano que inclui custos, recursos e

define objetivos.
 Plano de Implantação/Operação: plano de nível tático, com maior
detalhamento, que indica qual o esforço que deve ser despendido nas
tarefas gerenciáveis baseadas no resultado de avaliação e
diagnóstico de CMMI, como o SCAMPI
 Plano de Ação: Um plano com bastante detalhamento que define o
que as equipes devem fazer e quando, são criados times que focam
nas áreas de processos que foram identificadas e necessitam de
melhoria.
O sucesso dos programas de melhoria depende mais do que de boa

política e procedimentos, esses programas necessitam que a organização
esteja convencida dos benefícios e esteja direcionando esforços para esse
objetivo.
2.5 Métodos de Avaliação e Diagnóstico

A utilização de ciclos sucessivos de melhoria, com avaliações formais
e informais em cada ciclo com o intuito de medir o avanço dos objetivos de
42
melhorias estabelecidos ou saber qual a atual situação, é de uso comum nos

programas de melhoria de processos de software (Anacleto, 2005). Porém,
com um alto custo envolvido na utilização de avaliações formais, os métodos
de avaliação menores e menos formais foram sendo desenvolvidos pelas
empresas de consultoria e empresas que implementam modelos de
qualidade (PRIKLADNICKIÇ BECKERÇ YAMAGUTI, 2005)
A utilização de um diagnóstico inicial tem como finalidade identificar

qual a real situação da empresa no início do projeto e embasar o
planejamento do CMMI a ser executado a partir daquilo. O diagnóstico
usualmente é realizado de forma simplificada, mas está embasado na lógica
das avaliações formais, porém sem o mesmo rigor.
Os métodos que serão explicados, são aqueles que são utilizados

usualmente no modelo CMMI, são eles o SCAMPI e o PIID
2.5.1 SCAMPI
O método Standard CMMI Appraisal Method for Process Improvement

(SCAMPI) é utilizado para fornecer a graduação de maturidade do processo
em relação ao modelo CMMI. O mesmo possui três tipos de avaliação:
classe A, classe B e classe C. As avaliações classe A são as avaliações
oficiais, onde a empresa recebe um certificado reconhecendo o seu nível de
maturidade. As de classe B são avaliações menores não oficiais e tem a
finalidade de verificar as oportunidades de melhoria, normalmente usada
como preparação antes de ser submetida para uma avaliação oficial. E por
último, as avaliações de classe C, ou gap analysis, são para encontrar as
lacunas no atual processo de desenvolvimento de software, realizando uma
comparação com as práticas existentes (PRIKLADNICKIÇ BECKERÇ
YAMAGUTI, 2005)
Os principais objetivos do SCAMPI são: melhorias internas de

processo, na seleção de fornecedores e no monitoramento de processos
43
através de um método de avaliação integrado e ser um método de avaliação

eficiente. As principais fontes de dados a serem coletados são:
● Instrumentos: informações escritas, tais como questionários,

descrições ou mapeamentos das práticas do modelo correspondentes
ao processos da organização.
● Apresentações: informações preparadas pela organização e

fornecidas, visual ou verbalmente, para a equipe de avaliação para
descrever o processo e a implementação das práticas do CMMI.
● Documentos: artefatos que refletem a implementação de uma

ou mais práticas do modelo (incluindo políticas organizacionais,
procedimentos e artefatos, ao nível de implementação).
● Entrevistas: reunião com os responsáveis e usuários do

processo (como líderes de projeto, gerentes, desenvolvedores).
O conceito utilizado pelo SCAMPI é que deve ocorrer uma

investigação focada na otimização dos recursos, pois o modelo CMMI
apresenta um grande número de práticas que devem ser analisadas e uma
grande quantidade de dados a serem analisados. Estes dados são
consolidados a partir de um consenso. Uma característica da implantação de
uma prática é quando se dá uma evidência objetiva. As mesmas podem ser
caracterizadas da seguinte forma:
● Totalmente implementada
● Amplamente implementada
● Parcialmente implementada
● Não implementada
44
Essas características que as práticas apresentam é a base para o

registro das observações dos pontos fortes e fracos do processo, que
formam uma avaliação preliminar. Esta avaliação é validada pela
organização quando a equipe ainda está coletando dados. O nível de
maturidade é baseado nos dados validados e são gerados no mínimo por
cada meta específica de cada área de processo no escopo da avaliação
(ASATO, SPINOLA, SILVA, 2010).
2.5.1 PIID
O PIID é um documento usado para indicar que práticas estão ou não
sendo executadas no processo de desenvolvimento. Existem 3 tipos de
PIIDs:
 Artefato direto
 Artefato indireto
 Afirmações em uma entrevista
Primeiramente o artefato direto é conhecido por qualquer resultado

que venha direto de uma implementação de uma das práticas do modelo
CMMI, por exemplo os documentos de projeto, materiais de treinamentos
entre outros. O segundo são os artefatos indiretos que seriam evidências de
se estar utilizando as práticas do modelo, por exemplo relatórios e
apresentações. E por fim as afirmações de forma escrita ou verbal
conseguidas diretamente com as pessoas envolvidas no processo, um ótimo
exemplo são as entrevistas (AMARAL, FARIA, 2010).
2.6 Estudos de Casos Relacionados em CMMI
A maioria do conteúdo sobre o processo de maturação de

organizações baseado na aplicação do framework CMMI combina o CMMI e
45
mais algum tipo de técnica e faz uma avaliação e comparação entre os

métodos usados.
Um dos exemplos que seguem esse padrão é o artigo desenvolvido

por Minna Pikkarainen e Annukka Mäntyniem (Pikkarainen e Mäntyniemi,
2006). Nesse artigo as autoras estudam o uso do CMMI dentro do
paradigma de desenvolvimento ágil, explorando três casos de uso e
relatando o resultado. Esse estudo é realmente interessante, pois
normalmente desenvolvimento de software ágil e CMMI são consideradas
duas ideologias opostas de desenvolvimento.
Outro exemplo encontrado foi o artigo escrito por Paula Alexandra

Fernandes Monteiro (Monteiro, 2014). Nesse artigo a autora explica como é
difícil para pequenas empresas adotarem o CMMI, e propõe uma solução
que integra o CMMI com a metodologia de desenvolvimento Rational Unified
Process (RUP), criando assim um conjunto de soluções que guiam
pequenas empresas na implementação dos primeiros níveis de maturidade
do CMMI.
2.7 Norma ISO/IEC 15504

O desenvolvimento da norma ISO/IEC 15504 se deu pela
necessidade de ter padrões na avaliação de processos de software, além
disso esta norma também é considerada um framework. Basicamente, a
norma é dividida em duas dimensões: níveis de processo e categorias de
processo. Para ambos os casos devem ser apresentados os seguintes
elementos:
 Os processos: um avaliador conceituado deve verificar os requisitos

previstos na norma;
 Uma escala de medida: deve apresentar um modelo de avaliação de
processo como uma referência;
 Um método de medição: segue-se o processo compatível da norma.
46
Outro ponto importante de ser apresentado é o mecanismo de pontuação

da norma, que é ordenada em uma escala de quatro valores. Esses valores
são baseados no percentual de atendimento aos requisitos do processo. As
variações são:
 0 a 15% é declarado como não atendido;

 16 a 50% é parcialmente atendido;
 51 a 85% é largamente atendido;
 86 a 100% é definido totalmente atendido;
Um exemplo é quando uma empresa pode ser considerada do nível 2

quando todos os atributos dos níveis inferiores são totalmente atendidos e
todos os atributos do nível são largamente atendidos.
2.8 Considerações Finais

Neste capítulo foram mostrados vários conceitos no processo de
desenvolvimento de software e do modelo CMMI, além de apresentar de
maneira resumida a norma ISO/IEC 15504.
Primeiramente os conceitos relacionados ao processo de

desenvolvimento de software serão utilizados no processo de análise do
processo atual de desenvolvimento do DU e também na construção da
proposta de melhoria.
Segundo, os conceitos estudados de CMMI são a referência de todo o

processo de análise da maturidade e bem como a criação de uma proposta
de melhoria.
47
E por fim, a norma ISO/IEC 15504 é utilizada como uma maneira de

definir a aderência das práticas de desenvolvimento no DU, e com isso
resultará no nível de maturidade em CMMI.
48
3 ANÁLISE DE MATURIDADE
Nesse capítulo são apresentados os métodos utilizados no processo de

avaliação e diagnóstico do nível de maturidade em CMMI, além de explicar qual a
metodologia foi utilizada no mesmo. Além disso, são apresentadas as três fontes de
análise, uma entrevista realizada com o diretor do departamento, os documentos
relacionados com o projeto de gerenciamento de frota e uma pesquisa realizada com
todo o grupo de desenvolvimento. Por fim, serão feitas as ressalvas sobre os
desafios de se aplicar todas essas avaliações em um departamento de uma
universidade pública.
3.1 Contexto
Foi realizado um contato direto com o Diretor do DU. Após a explicação sobre
os objetivos dessa pesquisa ele se mostrou bastante interessado no nosso projeto e
nos benefícios que ele poderia trazer para o departamento. Com isso ele nos
autorizou a acompanhar todo o processo de desenvolvimento do projeto de
gerenciamento de frotas da UTFPR.
O gerenciamento de Frotas da UTFPR, atualmente já é realizado, mas de

forma manual, por meio do uso de planilhas, formulários em papel e principalmente
pelo e-mail ou telefone aonde todo o processo inicia. Cada campus tem seu
agendamento, o que dificulta e muito a gestão por parte da reitoria e principalmente
as auditorias interna e eventualmente externas. O novo sistema visa agilizar o
atendimento, padroniza-lo para todos os campus informatizando ao máximo possível
as etapas, o que proporcionará mais agilidade e facilidade do gerenciamento e
auditorias/relatórios de gestão.
3.1.1 Regras de Negócio
O Solicitante realiza o pedido de uso do veículo através do formulário de

solicitação.
49
Este formulário então é entregue a chefia ou alguém responsável pela

aprovação do uso do veículo na data e hora solicitadas.
A solicitação já previamente aprovada pelo responsável é encaminhada ao

DISAU e este realiza a validação dos dados, prazos da solicitação, bem como a
disponibilidade de veículo/motorista para o dia e horários solicitados.
Havendo disponibilidade então o DISAU retorna para o solicitante avisando-o

da aprovação do uso, realiza a confirmação do agendamento (reserva veículo e
motorista), comunica motorista do itinerário, data e hora de saída e chegada.
Em caso de não haver data ou ocorrerem problemas o DISAU comunica o

solicitante do problema e solicita troca de data, correções ou encerramento da
solicitação.
50
3.1.2 Processo de Negócio
A seguir é apresentado o processo de negócio do sistema de Gerenciamento

de Frotas que foi desenvolvido pelo departamento estudado.
Esse flowchart (Figura 11) mostra o fluxo de informações e a sequência de
tomadas de decisão necessárias para gerenciar as frotas de veículos da UTFPR,
iniciando pela solicitação do transporte feita pelo usuário, passando pela aprovação
e agendamento do transporte, até a liberação e utilização do veículo.
Caso a aprovação seja declinada, ou não existam veículos disponíveis, é
criada uma ocorrência para a alteração de data do transporte. Caso não seja
possível alterar a data, a solicitação é encerrada.
Vale ressaltar também que após o uso dos veículos são criados documentos
que servem como relatórios dos transportes.
51
Figura 11 - Processo de Negócio do Sistema de Gerenciamento de Frota

Fonte: Caso de estudo
52
3.2 Método de Análise da Maturidade

A metodologia aplicada para a análise da maturidade no departamento da
UTFPR foi, partir dos estudos dos métodos de avaliação e diagnóstico explicados
anteriormente na seção 2.5, definir qual seria a melhor maneira de conseguir extrair
a real situação do grau de maturidade do departamento estudado. Para isso foi
desenvolvido uma pesquisa com aspectos do PIID e além de colaborar com os
aspectos requeridos pelo SCAMPI.
Outros materiais foram utilizados para realizar a avaliação da maturidade,

como uma análise dos documentos referentes ao projeto de gerenciamento de frotas
e uma entrevista com o diretor geral do departamento, que coordena as atividades
de desenvolvimento no departamento. A Figura 12 mostra o processo resumido de
determinação do nível de maturidade do departamento.
Figura 12 - Fluxo de Atividades

Fonte: Autoria Própria
3.3 Diagnóstico
Nos processos de análise propostos por esta metodologia existem algumas
práticas comuns usadas para extrair informações sobre o nível atual de maturidade
apresentado pela organização. Essa extração de informações normalmente é feita
através de uma pesquisa com integrantes do grupo de desenvolvimento que tenham
ligação direta com o processo de desenvolvimento, entrevistas realizadas com o
diretor do departamento em análise e validações dos documentos do projeto em
avaliação pelo CMMI.
53
Foi realizada uma pesquisa quantitativa baseada no PIID proposto pelo SEI.
Nesse diagnóstico proposto, são apresentadas várias afirmações sobre o que
deveria estar sendo realizado pelo grupo de desenvolvimento com relação a cada
uma das áreas de processo do modelo. O escopo desse trabalho foi limitado às
áreas de processo do nível 2 de maturidade. Na Figura 13 é apresentada a pesquisa
relacionada a uma das áreas de processo e no Apêndice A é apresentado o
questionário de maneira integral.
Figura 13 - Questionário de REQM

54
Os participantes da pesquisa foram convidados a selecionar umas das

opções a seguir para cada uma das afirmações acima. Essas opções foram criadas
utilizando a escala Likert, que define um método de avaliação para pesquisas.
● Concordo totalmente
● Concordo parcialmente
● Indiferente
● Discordo parcialmente
● Discordo totalmente
É importante também ressaltar que os participantes da pesquisa foram

previamente instruídos sobre as terminologias e práticas comuns do CMMI, bem
como uma breve explicação sobre cada área de processo e sua importância para a
evolução do grau de maturidade do departamento. Isso foi feito para garantir que
todas as perguntas fossem entendidas pelos participantes, visto que do contrário as
respostas perderiam seu valor.
As perguntas dessa pesquisa foram elaboradas baseando no PIID e no

SCAMPI, porém de forma simplificada. Isso foi feito pois ambos os métodos são
muito complexos e possuem um questionário bastante extenso e detalhado, de
forma que não seria possível aplica-los a realidade do departamento analisado. Para
isso nós separamos as perguntas mais importantes de cada área de processo de
forma a criar um questionário mais sucinto e que pudesse ser aplicado com mais
facilidade dentro da organização. Algumas outras questões que eram muito
especificas foram unidas em afirmações mais abrangentes, por exemplo “Ensure
that the supplier agreement is satisfied before accepting the acquired product.” e
“Perform activities with the supplier as specified in the supplier agreement.” Foram
unidas em apenas uma afirmação simplificada: “São sempre estabelecidos e
mantidos os acordos com fornecedores”.
55
3.4 Análise
A partir da compilação dos dados da pesquisa é possível realizar uma análise
na situação atual do processo de desenvolvimento dentro da organização estudada.
Primeiramente será feito uma análise geral com relação a todas as áreas de
processo do nível 2 do modelo CMMI.
Para traduzir as respostas na pesquisa em alguma das características que as

práticas de CMMI apresentam, como explicado anteriormente, foi definida a seguinte
tabela de conversão das respostas.
Tabela 2 - Critérios SCAMPI x Pesquisa

Depois de feitas as conversões das respostas foi realizada uma compilação

dos dados para se chegar em uma taxa de aderência, para isso foram calculados
dois tipos de taxa, uma levando em consideração as respostas com “parcialmente
implementada” e colocando um peso menor a essa característica em comparação a
outra característica, e uma só utilizando as “amplamente implementada” em
consideração. A seguir é possível visualizar as duas fórmulas que foram construídas,
e o valor definido para o peso na fórmula TXA’’ é de 60%, ou seja, 0,6. Esse valor foi
escolhido se baseando na norma ISO/IEC 15504, no intervalo de largamente
atendido, que varia entre 51% e 85%.
Equação 1 - Fórmula da Taxa de Aderência 1 (TXA')

Equação 2 - Fórmula da Taxa de Aderência 2 (TXA'')

56
Com isso foi gerado o gráfico da Figura 14, e como pode ser observado
temos todas as áreas de processo com uma taxa de aderência abaixo dos 60%,
independente da fórmula utilizada, mostrando o quanto ainda existe espaço para a
melhoria do processo de desenvolvimento, como vimos anteriormente com base na
norma ISO/IEC 15504, descrita no item 2.7. O importante é ressaltar como no geral a
taxa de aderência teve uma média de 15% para TXA’ e de 40% para TXA’’, de uma
maneira mais simples, uma taxa é mais pessimista e apresenta uma percentagem
bem inferior a outra que apresenta uma taxa mais otimista.
Devido a comparação dos resultados de ambas essas taxas com os

documentos fornecidos sobre o projeto e com as conversas que tivemos com o
gestor do departamento, percebemos que nenhuma das duas representava muito
bem a realidade do departamento, sendo a TXA’ pessimista demais e TXA’’ otimista
demais. Então para equilibrar essas taxas foi feito a média entre elas e teve como
resultado o MTXA que apresenta uma aderência mais próxima do real. Outro fator
que deve ser levado em conta é que o espaço amostral era extremamente limitado já
que pouco mais de 10 funcionários trabalham no departamento avaliado.
Equação 3 - Média das Taxas de Aderência 1 e 2 (MTXA)

57
Figura 14 - Comparativo das taxas de Aderência

A seguir é feita uma análise mais detalhada de cada uma das áreas de
processo, procurando entender como se chegou ao resultado acima.
A Primeira prática a ser analisada é o Gerenciamento de requisitos (Figura

14), que tem a terceira maior MTXA na avaliação, em torno de 35%. As respostas de
“Amplamente Implementada” (AI) são as que tem maior impacto no resultado final,
mas no caso dessa prática as respostas de “Parcialmente Implementada” (PI) foram
predominantes. A afirmação P4(“Existe uma preocupação pra que os planos e
atividades do projeto se mantenham alinhados aos requerimentos”) deve ser
destacada por não apresentar resposta com “Não Implementada” (NI).
58
Figura 15 - Aderência de REQM

A segunda prática é o Planejamento de Projeto (Figura 15), apresentando

uma MTXA de 29%, tem um aumento significativo das respostas de NI em
comparação à prática apresentada anteriormente. Certamente uma prática influencia
nas outras, principalmente quando apresentam tópicos parecidos, nesse caso
REQM está de certa forma próximo de PP, pois fazem parte de um contexto de
Gerenciamento de Projeto. A afirmação a ser destacada nesta prática é a P7 (“É
feito uma avaliação da diferença entre os recursos disponíveis e os necessários para
cada projeto”) por não apresentar nenhuma resposta com AI e uma predominância
de respostas com NI, chegando uma possível conclusão de que não está sendo
implementada no processo.
59
Figura 16 - Aderência PP
A terceira prática é Acompanhamento e controle do Projeto (Figura 16), que

apresenta uma MTXA de 38%, a segunda maior entre as áreas avaliadas. Um dos
destaques na avaliação dessa prática é apresentar um maior número de afirmações
a serem respondidas, e um outro destaque é que pelo menos 4 afirmações não
tiveram resposta de NI. E por fim a afirmação em destaque nesta prática é a P1 “É
feito um monitoramento dos riscos durante o projeto” que não apresenta nenhuma
resposta com AI, criando um alerta sobre o processo de monitoramento do projeto.
Figura 17 - Aderência PMC

60
A quarta prática é Gerência de acordo com fornecedores (Figura 17), que

apresenta uma das menores MTXA na avaliação, com 25%. Um destaque a ser feito
nessa prática é que apresenta poucas afirmações na pesquisa, mas mesmo assim
suas respostas são válidas e podem ser analisadas. A afirmação de maior destaque
é a P2 “Os fornecedores são selecionados baseados em avaliação de suas
habilidades para ir de encontro com os requisitos específicos e critérios
estabelecidos” que não teve nenhuma resposta com AI.
Figura 18 - Aderência SAM

A quinta prática a ser analisada é Medição e Análise (Figura 18), que dentre
todas as áreas analisadas é a que apresenta a menor MTXA, com 10%. Tem como
destaque negativo apenas uma de seis afirmações ter respostas com AI. Dentre
estas, tem destaque negativo a P3 “Existe um protocolo utilizado na análise e
prestação de contas das métricas obtidas” que tem todas as respostas como NI.
61
Figura 19 - Aderência MA
A sexta prática é Garantia de Qualidade de Processo e Produto (Figura 19), e

que apresenta uma das menores MTXA, com 18%. Tem um desempenho um pouco
acima da área de processo anterior, e isso se deve a ter mais respostas como AI,
neste caso metade das afirmações apresentaram essas respostas, mesmo com
pouca expressão. E novamente uma grande quantidade de respostas como NI,
totalizando 59% das respostas, em comparação as AI com 9%. A afirmação com
maior número de NI foi a P5 “Existe uma pessoa designada que é responsável pelo
controle de qualidade do projeto”, assume que existe uma grande necessidade de
definir uma pessoa responsável pela qualidade dentro do processo de
desenvolvimento.
62
Figura 20 - Aderência PPQA

A última prática a ser analisada é Gerenciamento de Configuração (Figura

20), que apresenta uma MTXA de 41%, bem acima das últimas práticas analisadas.
Tem um destaque positivo de apresentar em todas as afirmações pelo menos uma
resposta com AI, mostrando assim que alguma coisa no sentido desta área de
processo está sendo realizada. Outro ponto de destaque é de que em duas
afirmações não apresenta respostas com NI, aumentando ainda mais a sua
aderência ao processo. A afirmação em destaque é a que tem maior taxa de NI, que
foi a P6 “Identifica e envolve os stakeholders no processo de gerenciamento de
configuração”, que assinala a necessidade de envolver as pessoas relacionadas ao
projeto no gerenciamento da configuração.
Figura 21 - Aderência CM
63
3.5 Conclusões da Análise

Neste capítulo foi mostrado todo o caminho percorrido na análise da
maturidade no DU, bem como os resultados obtidos com um diagnóstico do
processo atual de desenvolvimento de software. Os principais itens que devem ser
ressaltados são: um grupo de desenvolvimento pequeno, a customização do
diagnóstico e o nível de maturidade encontrado.
Primeiramente, como o DU apresenta um pouco mais de 10 funcionários

responsáveis pelo desenvolvimento de software é possível notar que muitos dos
processos utilizados atualmente são informais, mas é importante destacar que
algumas práticas tem relação com o modelo CMMI, mesmo sem ter uma
documentação formal.
Em segundo, a customização do diagnóstico por meio de uma redução do

PIID através de correlação entre práticas que tivessem um objetivo próximo, para
que o questionário aplicado ao time de desenvolvimento fosse respondido com
maior precisão do que um questionário com mais de 300 afirmações.
Por fim, toda essa análise resultou na comprovação de que o nível atual de
maturidade do DU é 1, ou seja, “Inicial”. Anteriormente é possível constatar que as
taxas encontradas foram muito baixas, e se utilizando da norma ISO/IEC 15504
como referência de aderência de processo de software podemos constatar que a
maioria das áreas de processos analisadas se encontra em “está parcialmente
atendida” (15 a 50%), próxima ao “não atendida” (menos de 15%). Por essa razão se
viu necessário fazer um plano que apresente todas as áreas de processo do nível 2
de CMMI. As ações apresentadas a seguir são bem abrangentes para cobrir esse
gap de práticas que o departamento apresenta.
64
4 PROPOSTA DE PROCESSO LOCAL DE DESENVOLVIMENTO
Este capítulo apresenta a proposta de melhoria dos processos do DIRGIT,

criada com base nas conclusões alcançadas a partir da pesquisa apresentada no
capitulo 4 e usando o referencial teórico apresentado anteriormente sobre Planos de
melhoria de processos.
4.1 Etapas de Desenvolvimento

As etapas de desenvolvimento estão sendo definidas baseadas no modelo
cascata de desenvolvimento de software, como explicado no referencial teórico.
Para cada etapa foram adicionadas as ações necessárias a serem tomadas com
relação ao modelo CMMI. Dentro de cada etapa poderá estar presente uma ou mais
áreas de processo, como pode-se observar na Figura 21.
Figura 22 - Processo Local de desenvolvimento(PLD)

Depois de entender de maneira geral como funciona o processo local é

necessário entender o que acontece em cada uma das etapas de desenvolvimento.
4.1.1 Comunicação
Na etapa de comunicação é o momento do projeto em que se realiza o

levantamento dos requisitos do sistema. As ações de melhoria proposta para essa
etapa é:
 “Obter entendimento dos requisitos” (REQM01)

65
4.1.2 Planejamento
Nesta etapa de planejamento é essencial para construir todo o plano do

projeto. As ações de melhoria proposta para essa etapa é:
 “Obter comprometimento com os requisitos” (REQM01)
 “Estimar o Escopo do Projeto” (PP01)
 “Estabelecer Estimativas para Atributos de Produtos de Trabalho e de

Tarefas” (PP02)
 “Definir Ciclo de Vida do Projeto” (PP03)
 “Determinar Estimativas de Esforço e Custo” (PP04)
 “Estabelecer Orçamento e Cronograma” (PP05)
 “Identificar Riscos do Projeto” (PP06)
 “Planejar Gestão de Dados” (PP07)
 “Planejar Recursos do Projeto” (PP08)
 “Planejar Habilidades e Conhecimento Necessários” (PP09)
 “Planejar o Envolvimento das Partes Interessadas” (PP10)
 “Determinar Tipo de Aquisição” (SAM01)
 “Selecionar Fornecedores” (SAM02)
 “Estabelecer Contratos com Fornecedores” (SAM03)
 “Estabelecer Objetivos de Medição” (MA01)
 “Especificar Medidas” (MA02)
 “Especificar Procedimentos de Coleta e Armazenamento de Dados” (MA03)
 “Especificar Procedimento de Análise” (MA04)
 “Identificar Itens de Configuração” (CM01)

66
 “Estabelecer um Sistema de Gestão de Configuração” (CM02)
 “Criar ou Liberar Baselines” (CM03)
4.1.3 Modelagem
Nesta etapa é onde ocorre a modelagem do sistema. As ações de melhoria

proposta para essa etapa são:
 “Obter entendimento dos requisitos” (REQM01)
 “Estabelecer o Plano do Projeto” (PP11)
 “Revisar Planos que Afetam o Projeto” (PP12)
 “Conciliar Carga de Trabalho e Recursos” (PP13)
 “Obter Comprometimento com o Plano” (PP14)
 “Monitorar os Parâmetros de Planejamento do Projeto” (PMC01)
 “Monitorar Compromissos” (PMC02)
 “Monitorar Riscos do Projeto” (PMC03)
 “Monitorar a Gestão de Dados” (PMC04)
 “Monitorar o Envolvimento das Partes Interessadas” (PMC05)
 “Conduzir Revisões de Progresso” (PMC06)
 “Conduzir Revisões de Marco” (PMC07)
 “Executar Contrato com Fornecedor” (SAM04)
 “Monitorar Processos Selecionados do Fornecedor” (SAM05)
 “Avaliar Produtos de Trabalho Selecionados do Fornecedor” (SAM06)
 “Aceitar Produto Adquirido” (SAM07)
 “Transferir Produtos” (SAM08)
 “Acompanhar Solicitações de Mudança” (CM04)

67
 “Controlar Itens de Configuração (CM05)
4.1.4 Construção
Na etapa de construção é o momento onde se codifica tudo que foi modelado

na etapa anterior. As ações de melhoria proposta para essa etapa são:
 “Manter rastreabilidade bidirecional dos requisitos” (REQM04)
 “Analisar Questões Críticas” (PMC08)
 “Implementar Ações Corretivas” (PMC09)
 “Gerenciar Ações Corretivas” (PMC10)
 “Coletar Dados Resultantes de Medição” (MA05)
 “Estabelecer Registros de Gestão de Configuração” (CM06)
 “Executar Auditorias de Configuração” (CM07)
4.1.5 Emprego
A última etapa é o momento de entrega do projeto e finalização. As ações de

melhoria proposta para essa etapa é:
 “Identificar inconsistências entre produtos de trabalho, planos de projeto e

requisitos” (REQM05)
 “Analisar Dados Resultantes de Medição” (MA06)
 “Armazenar Dados e Resultados” (MA07)
 “Comunicar Resultados” (MA08)
 “Avaliar Objetivamente os Processos” (PPQA01)
 “Avaliar Objetivamente Produtos de Trabalho e Serviços” (PPQA02)
 “Comunicar e Assegurar a Solução de não Conformidades” (PPQA03)

68
 “Estabelecer Registros” (PPQA04)
4.2 Detalhamento das Áreas de Processo

Inicialmente foram atribuídos títulos de gerências específicos que
representam responsáveis por determinadas áreas de processo. Isso é importante,
pois no CMMI todas as ações e processos devem ter um responsável designado.
Sendo assim, cada ação é atribuída ao gerente de sua área.
Figura 23 - Títulos de reponsabilidade
Para cada uma das áreas de processo serão apresentadas as áreas de

processos relacionadas, suas metas específicas e suas ações de melhoria. Além
disso criamos o workflow dos processos isoladamente, independente das outras
áreas. Nossa ideia inicial era criar um cronograma definindo prazos para a execução
dessas ações, porém, em vez disso, optamos em criar o um workflow mostrando a
ordem em que as ações devem ser executadas, visto que definir um prazo em dias
ou meses seria impossível sem saber quantas pessoas estarão trabalhando no
processo de implantação desse plano de melhoria.
69
Exemplo de ações de melhoria
As ações de melhoria são apresentadas no seguinte padrão (tabela 3).

Apresentamos primeiramente o ID da ação que pode ser diretamente relacionado
com sua área de processo, em seguida temos uma breve descrição de qual é a ação
e por fim apresentamos os produtos e as subpráticas esperadas por ela.
A lista completa de ações pode ser encontrada nos apêndices desse

documento (APÊNDICE B).
ID REQM01
AÇÃO Obter entendimento dos requisitos
DESCRIÇÃO Trabalhar com os provedores de requisitos para obter um melhor entendimento do significado dos requisitos.
PRODUTOS Lista de critérios para identificar adequadamente os provedores de requisitos
Critérios para avaliação e aceitação dos requisitos
Resultados das análises aos critérios
Conjunto de requisitos acordados
SUBPRÁTICAS Estabelecer critérios para identificar adequadamente os provedores de requisitos
Estabelecer critérios objetivos para a avaliação e aceitação de requisitos
Analisar os requisitos para assegura satisfação dos critérios definidos
Buscar o entendimento dos requisitos com os provedores de requisitos de forma que os participantes do projeto possam se
comprometer com eles
Tabela 3- REQM01
4.2.1 REQM
Figura 24 - Relação de REQM com as outras áreas de processo

70
Metas específicas
 Gerenciamento dos Requisitos: Os requisitos são gerenciados e as

inconsistências são identificadas em relação aos planos de projeto e produtos de
trabalho. (Apêndice B: Tabela 3, Tabela 4, Tabela 5, Tabela 6 e Tabela 7)
Workflow
Figura 25 - Workflow de REQM

4.2.2 PP
Figura 26 - Relação de PP com as outras áreas de processo

Metas Gerais
71
 Estabelecer Estimativas: Estimativas de parâmetros de planejamento de

projeto são estabelecidas e mantidas. (Apêndice B: Tabela 8, Tabela 9, Tabela 10
e Tabela 11);
 Elaborar um Plano de Projeto: Um plano de projeto é estabelecido e
mantido como base para a gestão de projeto. (Apêndice B: Tabela 12, Tabela
13, Tabela 14, Tabela 15, Tabela 17, Tabela 17 e Tabela 18);
 Obter um comprometimento com o plano: Para ser efetivo, o plano exige
comprometimento dos responsáveis pela implementação e suporte ao plano.
(Apêndice B: Tabela 19, Tabela 20 e Tabela 21);
Workflow
Figura 27 - Workflow PP
72
4.2.3 PMC
Figura 28 - Relação de PMC com as outras áreas de processo

Metas Gerais
 Monitorar o Projeto em Relação ao Plano: O desempenho observado e o

progresso do projeto são monitorados em relação ao plano de projeto. (Apêndice B:
Tabela 22, Tabela 23, Tabela 24, Tabela 25, Tabela 26, Tabela 27 e Tabela 28)
 Gerenciar Ações Corretivas até sua Conclusão: Gerenciar Ações
Corretivas até sua Conclusão. (Apêndice B: Tabela 29, Tabela 30 e Tabela 31)
73
Workflow
Figura 29 - Workflow PMC

74
4.2.4 SAM
Figura 30 - Relação de SAM com as outras áreas de processo

Metas Gerais
 Estabelecer Contratos com Fornecedores: Contratos com os fornecedores

são estabelecidos e mantidos. (Apêndice B: Tabela 32, Tabela 33 e Tabela 34)
 Cumprir Contratos com Fornecedor: Contratos com os fornecedores são
cumpridos pelo projeto e pelo fornecedor. (Apêndice B: Tabela 35, Tabela
36, Tabela 37, Tabela 38 e Tabela 39)
75
Workflow
Figura 31 - Worflow de SAM

4.2.5 MA
Relação entre as áreas de Processo
76
Figura 32 - Relação de MA com as outras áreas de processo

Metas Gerais
 Alinhar Atividades de Medição e Análise: Os objetivos e as atividades de

medição são alinhados com as necessidades de informação e objetivos
identificados. (Apêndice B: Tabela 40, Tabela 41, Tabela 42 e Tabela 43)
 Fornecer Resultados de Medição: São fornecidos resultados de medição,
os quais tratam necessidades de informação e objetivos identificados. (Apêndice B:
Tabela 44, Tabela 45, Tabela 46 e Tabela 47)
Workflow
77
Figura 33 - Workflow de MA
4.2.6 PPQA
Figura 34 - Relação de PPQA com as outras áreas de processo
Metas Específicas
 Avaliar Objetivamente Processos e Produtos de Trabalho: A aderência

dos processos executados e dos produtos de trabalho e serviços associados é
objetivamente avaliada em relação à descrição dos processos, padrões e
procedimentos aplicáveis. (Apêndice B: Tabela 48 e Tabela 49)
 Fornecer Visibilidade: Questões críticas relativas a não conformidades são
monitoradas e comunicadas objetivamente, e sua solução é assegurada. (Apêndice
B: Tabela 50 e Tabela 51)
Workflow
78
Figura 35 - Workflow de PPQA

79
4.2.7 CM
Figura 36 - Relação de CM com as outras áreas de processo

Metas Específicas
 Estabelecer Baselines: Os baselines dos produtos de trabalho identificados

são estabelecidos. (Apêndice B: Tabela 52, Tabela 53 e Tabela 54)
 Acompanhar e Controlar Mudanças: As mudanças nos produtos de

trabalho sob gestão de configuração são acompanhadas e controladas.
(Apêndice B: Tabela 55 e Tabela 56)
 Estabelecer Integridade: A integridade dos baselines é estabelecida e

mantida. (Apêndice B: Tabela 57 e Tabela 58)
Workflow
Figura 37 - Workflow de CM
80
4.3 Site de Divulgação
Colocado como um dos objetivos do trabalho, o site de divulgação é um meio

de expor toda a proposta de processo local desenvolvida. O mesmo pode ser
acessado pelo seguinte endereço URL: http://cmmi-inovationtest.rhcloud.com/. Esse
capítulo se propõe a mostrar alguns dos aspectos técnicos da criação desse site e
também um conjunto de telas para exibir sua aparência.
4.3.1 Aspectos Técnicos

Com relação aos aspectos técnicos, o trabalho buscou encontrar ferramentas
que pudessem servir como um meio de divulgação, sem se aprofundar no
desenvolvimento de código para acelerar a implantação do material que seria
disponibilizado. Para isso utilizamos três ferramentas: uma de hospedagem
(OPENSHIFT, 2016); uma de controle de conteúdo (CMS GHOST, 2016); e uma de
edição e criação de workflow (DRAW.IO, 2016).
A hospedagem foi realizada pelo OpenShift, que permite por meio de sua
conta gratuita até três aplicações web. Dentro desse sistema de hospedagem é
possível utilizar diferentes tipos de servidores, como Apache Tomcat, JBoss,
NodeJS. Para o site desenvolvido foi utilizado o NodeJS.
A gestão do conteúdo se deu pelo Ghost, uma plataforma gratuita para

administrar os conteúdos de um blog. O mesmo é desenvolvido em JavaScript
utilizando o NodeJS.
E por fim a edição e criação de workflows foi realizada por meio de uma
aplicação gratuita Draw.io, que permite a criação de diferentes fluxogramas e já
apresenta diferentes templates, até para UML.
81
4.3.2 Desenvolvimento
O processo de desenvolvimento de website se deu por meio do ambiente
virtual do OpenShift, que permite a criação de um CMS de maneira simples, apenas
como um processo de instalação simples, sem precisar codificar nada. Após a
instalação do Ghost, o CMS utilizado em questão, deu-se início a inclusão de
conteúdo no site. Para isso foi utilizado todo o conteúdo descrito anteriormente.
A seguir é mostrado algumas telas do website (Figura 38 a 40), em cada uma

delas é possível observar a estrutura de blog que o site apresenta.
82
Figura 38 - Tela Inicial do Site

83
Figura 39 - Tela de apresentação do Processo Local

84
Figura 40 - Tela de apresentação da área Planejamento de Projeto

85
5 CONCLUSÃO
O processo de desenvolvimento de software vem evoluindo ao longo dos

últimos anos e o modelo CMMI é uma forma encontrada para melhorar todo esse
processo. O trabalho apresentado mostra uma análise de maturidade baseada em
CMMI do departamento responsável pelo desenvolvimento de software dentro da
UTFPR.
Durante este projeto foi feita uma análise do processo atual de

desenvolvimento de software dentro do DU na UTFPR, onde foram encontradas
inúmeras falhas e oportunidades de melhoria. A partir dessa análise foi então criado
um plano de melhoria que propõe diversas ações a serem executadas para que a
organização possa alcançar o nível 2 de CMMI, e consequentemente aumentar a
qualidade do software produzido internamente. Por fim, foi criado um website para
que fosse possível divulgar o plano de melhoria da forma mais acessível possível.
5.1 Objetivos Alcançados

O principal objetivo deste trabalho de conclusão de curso foi a análise e
aplicação das práticas de CMMI dentro de um DU para que então fosse possível
criar uma proposta de melhoria com as boas práticas adotadas pelo CMMI. Como
descrito nos capítulos anteriores foram realizadas todas as etapas do trabalho e
disponibilizado um website com o plano de melhoria proposto.
5.2 Desafios
Todo o processo de avaliação e diagnóstico no DU foi bem turbulento. Em um
primeiro momento quando foi iniciada a avaliação do processo de desenvolvimento
no departamento o mesmo parou o seu funcionamento devido à greve dos
servidores públicos que atingiu a universidade e isso fez que houvesse um atraso
em toda a pesquisa. Em um segundo momento após do fim da greve, que durou
vários meses, durante a realização da pesquisa, não foi obtido o apoio do grupo de
desenvolvimento que não respondeu a pesquisa de maneira eletrônica. Com o
86
intuito de conseguir aplicar essa pesquisa foi realizada uma segunda tentativa, mas
utilizando os meios físicos. Foi realizada uma pesquisa em papel a ser respondida
pelos integrantes do departamento e com o pedido direto do chefe do departamento
foi possível que a maior parte do grupo de desenvolvimento respondesse a
pesquisa.
5.3 Conclusões sobre a Pesquisa

Em conclusão, por meio da análise da maturidade no DU foi possível
constatar sérios problemas no planejamento e desenvolvimento de seus projetos, o
nível atual de maturidade de seus processos é bastante baixo e será um grande
desafio implementar o CMMI e conseguir elevar a organização ao nível 2.
Mesmo assim, foi possível também visualizar um grande potencial para

desenvolvimento e melhoria dentro do departamento avaliado, visto que possui
profissionais bem qualificados e experientes. É admirável que algumas das boas
práticas do CMMI já estivessem sendo aplicadas no processo, mesmo os membros
da equipe nunca terem tido nenhum contato prévio com o CMMI.
Devido ao entusiasmo com que o nosso projeto foi recebido pelo

departamento, ficou bastante claro para nós desde o início que os gestores e
membros do time estão cientes da necessidade de melhorias no processo atual de
desenvolvimento. Isto evidencia que o resultado de nossos esforços nesse projeto
não serão em vão, visto que a implementação do mesmo é uma possibilidade real e
factível considerando a realidade atual do departamento e o resultado obtido.
5.4 Trabalhos Futuros

A partir dos resultados alcançados neste trabalho as seguintes continuidades
são sugeridas:
 Para que o grau de maturidade de desenvolvimento seja realmente elevado a

nível 2 é necessário que o plano de melhoria proposto seja implementado
pelo departamento. Seria interessante acompanhar esse processo de
87
implementação e documentar as mudanças causadas pelo mesmo, de modo

a quantificar os resultados obtidos e validar as melhorias trazidas pelo CMMI;
 Após implementado o nível 2 de CMMI uma possível continuidade seria a
avaliação e proposta de um novo plano de melhoria visando alcançar nível 3
de maturidade dentro do departamento;
 Aplicação deste mesmo processo de avaliação e melhoria de processo para
outros campus da UTFPR.
88
REFERÊNCIAS
Amaral, Luis Manuel Gonzalez, and João Pascoal Faria. "A gap analysis
methodology for the team software process." Quality of Information and
Communications Technology (QUATIC), 2010 Seventh International Conference on
the. IEEE, 2010.
Anacleto, Alessandra, and C. Wangenheim. Método e modelo de avaliação para

melhoria de processos de software em micro e pequenas empresas. Diss.
Universidade Federal de Santa Catarina, Centro Tecnológico. Programa de Pós-
Graduação em Ciência de Computação., 2004.
Asato, Regina Yoneko; Spinola, Mauro Mesquita; Silva, Water Henrique de Farias.
Iniciando a implementação do modelo CMMI em uma fábrica de Software: Um
processo para a elaboração do diagnóstico e plano de ação, XIII SIMPEP -
Bauru, SP, Brasil, 6 a 8 de Novembro de 2006
Baetjer, Jr. H., “Software as Capital”, IEEE Computer Society Press, 1998, p. 85.
Boehm B., “Te Spiral Model as a Tool for Evolutionary Software Acquisition” ,
Cross-Talk, Maio 2001, disponível
http://www.researchgate.net/profile/Barry_Boehm/publication/228805054_The_spiral
_model_as_a_tool_for_evolutionary_acquisition/links/53fd97960cf2dca800035656.pd
f . Acesso em: 24 abr. 2016.
Building CMMI Process Performance Models Performance Models, disponivel

em http://www.dtic.mil/dtic/tr/fulltext/u2/a558352.pdf
Capability Maturity Model® Integration (CMMI®) Overview, fornecido pelo Software

Engineering Institute. Acesso em: 24 abr. 2016
89
CMMI® for Development, Version 1.2CMMI-DEV, Agosto 2006, fornecido pelo

Software Engineering Process Management Program, disponivel em
http://www.sei.cmu.edu/. Acesso em: 14 fev. 2016
Fowler, M, “The New Methodology”, Junho 2002, disponível em

http://www.martinfowler.com/articles/newMethodology.html#N8B.acesso em: 23 abr.
2016.
Guarizzo, Karina. “Métricas de software”, dezembro 2008, disponível em:

bibdig.poliseducacional.com.br/document/?down=184. Acesso em: 23 abr. 2016.
Hanna, M., “Farewell to Waterfalls”, Software Magazine, Maio 1995, pp 38-46.
Jacobson, I. “A Resounding ‘Yes’ to Agile Process - But Also More”, Cutter IT

Journal, volume 15, numero 1, Janeiro 2002, pp 18-24
Lessa, Rafael. e Lessa Edson., “Modelos de Processos de Engenharia de

Software”, agosto 2012.
McDermid, J. e Rook P., “Software Development Process Models”, Software

Engineer’s Reference Book, CRC Press, 1993, pp 15/26 - 15/28.
Monteiro, Paula A. F. “Tailoring CMMI-DEV and RUP Frameworks for ML2/3-

Compliance Analysis”, Abril 2014.
Pikkarainen, M., e Mäntyniemi, A., “An Approach for Using CMMI in Agile
Software Development Assessments: Experiences from Three Case Studies”,
90
Maio 2006
Pressman, Roger S. "Processos De Software." Engenharia De Software. 7ªPorto

Alegre (RS): AMGH, 2010.
Prikladnicki, Rafael, Carlos Alberto Becker, and Marcelo Hideki Yamaguti. "Uma
Abordagem para a Realização de Diagnóstico Inicial em Empresas que
Implementam o MPS. BR." I Workshop de Implementadores (W2-MPS. BR),
Brasília. 2005.
Schwaber, K, e Beedle, M., “Agile Software Development with SCRUM”, Prentice

Hall, 2001
The Agile Alliance, Página principal disponível em
http://www.agilealliance.org/home. Acesso em: 1 abr. 2016.
CMS GHOST for windows. Version 0.8.0. Developed in NodeJS. https://ghost.org/.

Acesso em: 4 abr. 2016.
OPENSHIFT ONLINE. Version M4. Red Hat, Inc. https://www.openshift.com/. Acesso

em: 3 jul. 2016.
DRAW.IO DIAGRAMS. Version: 5.4.1.8. https://draw.io. Acesso em: 12 mar. 2016.

91
APÊNDICE A
92
93
94
95
96
97
98
99
APÊNDICE B
Ações de Melhoria REQM
ID REQM01
AÇÃO Obter entendimento dos requisitos
DESCRIÇÃO Trabalhar com os provedores de requisitos para obter um melhor entendimento do significado dos requisitos.
PRODUTOS Lista de critérios para identificar adequadamente os provedores de requisitos
Critérios para avaliação e aceitação dos requisitos
Resultados das análises aos critérios
Conjunto de requisitos acordados
SUBPRÁTICAS Estabelecer critérios para identificar adequadamente os provedores de requisitos
Estabelecer critérios objetivos para a avaliação e aceitação de requisitos
Analisar os requisitos para assegura satisfação dos critérios definidos
Buscar o entendimento dos requisitos com os provedores de requisitos de forma que os participantes do projeto possam se
comprometer com eles
Tabela 4- REQM01
ID REQM02
AÇÃO Obter comprometimento com os requisitos
DESCRIÇÃO Obter comprometimento dos participantes do projeto com os requisitos.
PRODUTOS Análise de impacto dos requisitos.
Acordos documentados sobre os requisitos e suas mudanças.
SUBPRÁTICAS Analisar o impacto dos requisitos nos compromissos existentes.
Negociar e registrar compromissos.
Tabela 5 - REQM02
ID REQM03
AÇÃO Gerenciar mudanças com os requisitos
DESCRIÇÃO Gerenciar mudanças nos requisitos à medida que evoluem durante o projeto.
PRODUTOS Status dos requisitos.
Banco de dados dos requisitos.
Banco de dados das decisões sobre requisitos.
SUBPRÁTICAS Documentar todos os requisitos do projeto e suas mudanças.
Manter um histórico das mudanças de requisitos e da linha de raciocínio utilizada.
Avaliar o impacto das mudanças de requisitos do ponto de vista das partes interessadas relevantes.
Tornar disponíveis para o projeto os requisitos e dados de suas mudanças.
Tabela 6 - REQM03
ID REQM04
AÇÃO Manter rastreabilidade bidirecional dos requisitos
DESCRIÇÃO Manter a rastreabilidade bidirecional dos requisitos e produtos de trabalho.
PRODUTOS Matriz de rastreabilidade de requisitos.
Sistema de rastreamento de requisitos.
SUBPRÁTICAS Manter a rastreabilidade dos requisitos para assegurar que a origem dos requisitos detalhados (derivados) esteja
documentada.
Manter a rastreabilidade de um requisito com seus requisitos detalhados e com sua alocação a funções, interfaces, pessoas,
processos e produtos de trabalho.
Gerar a matriz de rastreabilidade de requisitos.
Tabela 7 - REQM01
100
ID REQM05
AÇÃO Identificar inconsistências entre produtos de trabalho, planos de projeto e requisitos
DESCRIÇÃO Esta prática específica procura inconsistências entre requisitos, planos de projeto e produtos de trabalho e inicia ações
corretivas para corrigi-los.
PRODUTOS Documentação das inconsistências, incluindo origens, condições e linha de raciocínio utilizada.
Ações corretivas.
SUBPRÁTICAS Revisar os planos de projeto, atividades e produtos de trabalho, visando à sua compatibilidade com os requisitos e com as
mudanças neles realizadas.
Identificar a origem e a razão das inconsistências.
Identificar mudanças a serem implementadas nos planos e produtos de trabalho como resultado de mudanças no baseline de
requisitos.
Identificar mudanças a serem implementadas nos planos e produtos de trabalho como resultado de mudanças no baseline de
requisitos.
Tabela 8 - REQM05
Ações de melhoria PP
ID PP01
AÇÃO Estimar o Escopo do Projeto
DESCRIÇÃO Estabelecer uma estrutura analítica de projeto (work breakdown structure – WBS) de alto nível para estimar o
escopo do projeto.
PRODUTOS Descrições de tarefas.
Descrições de pacotes de trabalho.
WBS.
SUBPRÁTICAS Elaborar um WBS com base na arquitetura do produto.
Identificar pacotes de trabalho em um nível de detalhe suficiente para estimar tarefas e prazos do projeto, e definir
responsabilidades.
Identificar produtos ou componentes de produto que serão adquiridos externamente.
Identificar produtos de trabalho que serão reutilizados.
Tabela 9 - PP01
ID PP02
AÇÃO Estabelecer Estimativas para Atributos de Produtos de Trabalho e de Tarefas.
DESCRIÇÃO Estabelecer e manter estimativas para atributos de produtos de trabalho e de tarefas.
PRODUTOS Abordagem técnica.
Tamanho e complexidade de produtos de trabalho e de tarefas.
Modelos de estimativas.
Estimativas de atributo.
SUBPRÁTICAS Determinar a abordagem técnica para o projeto.
Utilizar métodos apropriados para determinar os atributos de produtos de trabalho e de tarefas que serão utilizados para
estimar os requisitos de recursos.
Estimar os atributos de produtos de trabalho e de tarefas.
Tabela 10 - PP02
ID PP03
AÇÃO Definir Ciclo de Vida do Projeto
DESCRIÇÃO Definir fases do ciclo de vida do projeto para fins de planejamento.
PRODUTOS Fases do ciclo de vida do projeto.
SUBPRÁTICAS
Tabela 11 - PP03
101
ID PP04
AÇÃO Determinar Estimativas de Esforço e Custo
DESCRIÇÃO Estimar custo e esforço do projeto para os produtos de trabalho e tarefas com base no raciocínio utilizado na
estimativa.
PRODUTOS Raciocínio utilizado nas estimativas.
Estimativas de esforço do projeto.
Estimativas de custo do projeto.
SUBPRÁTICAS Selecionar os modelos ou dados históricos que serão utilizados para derivar as estimativas de esforço e de custo a partir de
atributos dos produtos de trabalho e das tarefas.
Incluir necessidades de infraestrutura de suporte ao estimar esforço e custo.
Estimar esforço e custo utilizando modelos e dados históricos.
Tabela 12 - PP04
ID PP05
AÇÃO Estabelecer Orçamento e Cronograma
DESCRIÇÃO Estabelecer e manter o orçamento e o cronograma do projeto.
PRODUTOS Cronogramas do projeto.
Dependências de cronograma.
Orçamento do projeto.
SUBPRÁTICAS Identificar principais marcos.
Identificar hipóteses utilizadas no cronograma.
Identificar restrições.
Identificar dependências entre tarefas.
Definir orçamento e cronograma.
Tabela 13 - PP05
ID PP06
AÇÃO Identificar Riscos do Projeto
DESCRIÇÃO Identificar e analisar riscos do projeto.
PRODUTOS Riscos identificados.
Impacto e probabilidade de ocorrência dos riscos
Prioridade de riscos.
SUBPRÁTICAS Identificar riscos.
Documentar os riscos.
Revisar e obter a anuência das partes interessadas relevantes sobre a completude e correção dos riscos documentados.
Atualizar os riscos quando apropriado.
Tabela 14 - PP06
ID PP07
AÇÃO Planejar Gestão de Dados
DESCRIÇÃO Planejar a gestão de dados do projeto.
PRODUTOS Plano de gestão de dados.
Lista de dados gerenciados.
Descrição de forma e conteúdo dos dados.
Lista de requisitos de dados para compradores e fornecedores.
Requisitos de privacidade.
Requisitos de segurança lógica.
Procedimentos de segurança lógica.
Mecanismos para recuperação, reprodução e distribuição de dados.
Cronograma para coleta de dados de projeto.
Lista de dados de projeto a serem coletados.
SUBPRÁTICAS Estabelecer requisitos e procedimentos para assegurar a privacidade e a segurança lógica dos dados.
Estabelecer um mecanismo para arquivamento de dados e acesso a eles.
Determinar os dados de projeto a serem identificados, coletados e distribuídos.
Tabela 15 - PP07
102
ID PP08
AÇÃO Planejar Recursos do Projeto
DESCRIÇÃO Planejar os recursos necessários para execução do projeto.
PRODUTOS Pacotes de trabalho do WBS.
Dicionário de tarefas do WBS.
Requisitos para composição da equipe com base no tamanho e escopo do projeto.
Lista de infraestrutura e equipamentos críticos.
Diagramas e definições de processo e workflow.
Lista de requisitos para administração do programa.
SUBPRÁTICAS Determinar requisitos de processo.
Determinar requisitos para composição da equipe.
Determinar requisitos de infraestrutura, equipamento e componentes.
Tabela 16 - PP08
ID PP09
AÇÃO Planejar Habilidades e Conhecimento Necessários
DESCRIÇÃO Planejar habilidades e conhecimento necessários para a execução do projeto.
PRODUTOS Relação de habilidades necessárias.
Planejamento para composição da equipe e contratação de profissionais.
Banco de dados para armazenar informações sobre habilidades e treinamentos.
SUBPRÁTICAS Identificar habilidades e conhecimento necessários para a execução do projeto.
Avaliar habilidades e conhecimento disponíveis.
Selecionar mecanismos para obter habilidades e conhecimento necessários.
Tabela 17 - PP09
ID PP10
AÇÃO Planejar o Envolvimento das Partes Interessadas
DESCRIÇÃO Planejar o envolvimento das partes interessadas identificadas.
PRODUTOS Plano do envolvimento das partes interessadas.
SUBPRÁTICAS
Tabela 18 - PP10
ID PP11
AÇÃO Estabelecer o Plano do Projeto
DESCRIÇÃO Estabelecer e manter o plano global do projeto.
PRODUTOS Plano global do projeto.
SUBPRÁTICAS
Tabela 19 - PP11
ID PP12
AÇÃO Revisar Planos que Afetam o Projeto
DESCRIÇÃO Revisar todos os planos que afetam o projeto para entender os compromissos do projeto.
PRODUTOS Registro das revisões dos planos que afetam o projeto.
SUBPRÁTICAS
Tabela 20 - PP12
103
ID PP13
AÇÃO Conciliar Carga de Trabalho e Recursos
DESCRIÇÃO Conciliar o plano do projeto com os recursos estimados e disponíveis.
PRODUTOS Métodos e seus parâmetros de estimativa atualizados (por
exemplo, melhores ferramentas e utilização de componentes de
prateleira).
Orçamentos renegociados.
Cronogramas atualizados.
Lista atualizada de requisitos.
Acordos renegociados com as partes interessadas.
SUBPRÁTICAS
Tabela 21 - PP13
ID PP14
AÇÃO Obter Comprometimento com o Plano
DESCRIÇÃO Obter o comprometimento das partes interessadas relevantes responsáveis pela execução e apoio à execução do plano.
PRODUTOS Solicitações de compromisso documentadas.
Compromissos documentados.
SUBPRÁTICAS Identificar o suporte necessário e negociar os compromissos com as partes interessadas relevantes.
Documentar todos os compromissos organizacionais, sejam eles provisórios ou definitivos, para assegurar o nível apropriado
de aprovação.
Revisar os compromissos internos com gerência sênior, conforme apropriado.
Revisar os compromissos externos com gerência sênior, conforme apropriado.
Identificar compromissos relativos a interfaces entre elementos do projeto, compromissos com outros projetos e com
unidades organizacionais, de forma que possam ser monitorados.
Tabela 22 - PP14
Ações de melhoria PM
ID PMC01
AÇÃO Monitorar os Parâmetros de Planejamento do Projeto
DESCRIÇÃO Monitorar os valores reais dos parâmetros de planejamento de projeto em relação ao plano de projeto.
PRODUTOS Registros de desempenho de projeto.
Registros de desvios significativos.
SUBPRÁTICAS Monitorar o progresso em relação ao cronograma.
Monitorar o custo e o esforço empregados no projeto.
Monitorar os atributos dos produtos de trabalho e das tarefas.
Monitorar os recursos fornecidos e utilizados.
Monitorar habilidades e conhecimento do pessoal do projeto.
Documentar os desvios significativos nos parâmetros de planejamento do projeto.
Tabela 23 - PMC01
ID PMC02
AÇÃO Monitorar Compromissos
DESCRIÇÃO Monitorar os compromissos com relação aos identificados no plano de projeto.
PRODUTOS Registros de revisões de compromissos.
SUBPRÁTICAS Revisar regularmente os compromissos (internos e externos).
Identificar os compromissos que não foram cumpridos ou que correm risco significativo de não serem cumpridos.
Documentar os resultados das revisões de compromissos.
Tabela 24 - PMC02
104
ID PMC03
AÇÃO Monitorar Riscos do Projeto
DESCRIÇÃO Monitorar os riscos em relação àqueles identificados no plano de projeto.
PRODUTOS Registros do monitoramento dos riscos do projeto.
SUBPRÁTICAS Revisar periodicamente a documentação dos riscos no contexto atual
do projeto.
Atualizar a documentação dos riscos para incorporar mudanças, na
medida em que informações adicionais estejam disponíveis.
Comunicar o status dos riscos às partes interessadas relevantes.
Tabela 25 - PMC03
ID PMC04
AÇÃO Monitorar a Gestão de Dados
DESCRIÇÃO Monitorar a gestão de dados do projeto com relação ao plano de projeto.
PRODUTOS Registros de gestão de dados.
SUBPRÁTICAS Revisar periodicamente as atividades de gestão de dados com relação à sua descrição no plano de projeto.
Identificar e documentar questões críticas relevantes e seus impactos.
Documentar os resultados das revisões das atividades de gestão de dados.
Tabela 26 - PMC04
ID PMC05
AÇÃO Monitorar o Envolvimento das Partes Interessadas
DESCRIÇÃO Monitorar o envolvimento das partes interessadas em relação ao plano de projeto.
PRODUTOS Registros do envolvimento das partes interessadas.
SUBPRÁTICAS Revisar periodicamente o envolvimento das partes interessadas.
Documentar os resultados das revisões de status do envolvimento das partes interessadas.
Tabela 27 - PMC05
ID PMC06
AÇÃO Conduzir Revisões de Progresso
DESCRIÇÃO Revisar periodicamente o progresso, o desempenho e as questões críticas do projeto.
PRODUTOS Resultados documentados de revisão do projeto.
SUBPRÁTICAS Comunicar regularmente às partes interessadas relevantes o status de atividades e produtos de trabalho selecionados.
Revisar os resultados da coleta e análise de medidas para controle do projeto.
Identificar e documentar questões críticas relevantes e desvios em relação ao plano.
Documentar solicitações de mudança e problemas identificados em quaisquer produtos de trabalho e processos.
Documentar os resultados das revisões.
Acompanhar solicitações de mudanças e relatórios de problemas até sua conclusão.
Tabela 28 - PMC06
ID PMC07
AÇÃO Conduzir Revisões de Marco
DESCRIÇÃO Revisar, em marcos selecionados do projeto, as realizações e os resultados obtidos.
PRODUTOS Resultados documentados das revisões de marco.
SUBPRÁTICAS Conduzir revisões com as partes interessadas relevantes em pontos significativos do cronograma do projeto, como por
exemplo, na conclusão de fases selecionadas.
Revisar compromissos, plano, status e riscos do projeto.
Documentar os resultados da revisão, itens de ação e decisões.
Acompanhar os itens de ação até sua conclusão.
Tabela 29 - PMC07
105
ID PMC08
AÇÃO Analisar Questões Críticas
DESCRIÇÃO Identificar e analisar questões críticas e determinar ações corretivas necessárias para tratá-las.
PRODUTOS Lista de questões críticas que necessitam de ações corretivas.
SUBPRÁTICAS Identificar questões críticas para análise.
Analisar as questões críticas para determinar a necessidade de ações corretivas.
Tabela 30 - PMC08
ID PMC09
AÇÃO Implementar Ações Corretivas
DESCRIÇÃO Implementar ações corretivas para tratar as questões críticas identificadas.
PRODUTOS Plano de ações corretivas.
SUBPRÁTICAS Determinar e documentar as ações apropriadas necessárias para tratar as questões críticas identificadas.
Revisar as ações a serem tomadas e obter anuência das partes interessadas relevantes.
Negociar mudanças em compromissos internos e externos.
Tabela 31 - PMC09
ID PMC10
AÇÃO Gerenciar Ações Corretivas
DESCRIÇÃO Gerenciar ações corretivas até sua conclusão.
PRODUTOS Resultados de ações corretivas.
SUBPRÁTICAS Monitorar as ações corretivas até sua conclusão.
Analisar os resultados das ações corretivas para determinar sua eficácia.
Determinar e documentar ações apropriadas para corrigir desvios quanto aos resultados planejados para as ações corretivas.
Tabela 32 - PMC10
Ações de melhoria SAM
ID SAM01
AÇÃO Determinar Tipo de Aquisição
DESCRIÇÃO Determinar o tipo de aquisição para cada produto ou componente de produto a ser adquirido.
PRODUTOS Lista de tipos de aquisição que serão utilizados, considerando-se todos os produtos e componentes de produtos a serem
adquiridos.
SUBPRÁTICAS
Tabela 33 - SAM01
106
ID SAM02
AÇÃO Selecionar Fornecedores
DESCRIÇÃO Selecionar fornecedores com base na avaliação de suas capacidades em satisfazer aos requisitos especificados e
critérios estabelecidos.
PRODUTOS Estudos de mercado.
Lista de fornecedores candidatos.
Lista de fornecedores preferenciais.
Análise de alternativas ou qualquer registro de critérios de avaliação, lista de vantagens e desvantagens dos fornecedores
candidatos e lógica utilizada na seleção de fornecedores.
Requisitos e documentação adicional de solicitação de informações para aquisição.
SUBPRÁTICAS Estabelecer e documentar critérios para avaliação de potenciais fornecedores
Identificar potenciais fornecedores e distribuir requisitos e documentação adicional de solicitação de informações para
aquisição.
Avaliar as propostas de acordo com critérios de avaliação.
Avaliar os riscos associados a cada fornecedor que entregou a proposta.
Avaliar a capacidade dos fornecedores que entregaram proposta para a execução do trabalho.
Selecionar o fornecedor.
Tabela 34 - SAM02
ID SAM03
AÇÃO Estabelecer Contratos com Fornecedores
DESCRIÇÃO Um contrato formal é qualquer contrato legal entre a organização (que representa o projeto) e o fornecedor. Esse
documento pode ser um contrato, uma licença, um acordo de nível de serviço ou memorando de acordo entre as partes.
PRODUTOS Declarações de trabalho.
Contratos.
Memorandos de acordo entre as partes.
Contrato de licenciamento.
SUBPRÁTICAS Atualizar os requisitos (por exemplo, requisitos de produto e requisitos de nível de serviço) a serem cumpridos pelo
fornecedor de modo a refletir as negociações com o fornecedor, quando necessário.
Documentar o que o projeto disponibilizará ao fornecedor.
Documentar o contrato com o fornecedor.
Revisar periodicamente o contrato com o fornecedor para assegurar que ele reflita precisamente o relacionamento do
projeto com o fornecedor, os riscos e condições de mercado atuais.
Assegurar que todas as partes compreendam e concordem com todos os requisitos antes da vigência do contrato ou antes
de quaisquer mudanças.
Atualizar o contrato com o fornecedor quando necessário para refletir mudanças nos processos ou nos produtos de trabalho
do fornecedor.
Atualizar os planos e compromissos do projeto, incluindo mudanças nos processos ou nos produtos de trabalho do projeto,
quando necessário, para refletir os termos do contrato com o fornecedor.
Tabela 35 - SAM03
ID SAM04
AÇÃO Executar Contrato com Fornecedor
DESCRIÇÃO Executar atividades com o fornecedor conforme especificado no contrato com o fornecedor.
PRODUTOS Relatórios de progresso do fornecedor e medidas de desempenho.
Relatórios e material de revisão do fornecedor.
Itens de ação acompanhados até sua conclusão.
Documentação da entrega de produtos e documentos.
SUBPRÁTICAS Monitorar progresso e desempenho do fornecedor (prazo, esforço, custo e desempenho técnico) como definido no
contrato.
Conduzir revisões com o fornecedor como especificado no contrato.
Conduzir revisões técnicas com o fornecedor como definido no contrato.
Conduzir revisões gerenciais com o fornecedor conforme definido no contrato.
Usar os resultados das revisões para melhorar o desempenho do fornecedor e para cultivar relacionamentos de longo prazo
com fornecedores preferenciais.
Monitorar riscos associados ao fornecedor e implementar ações corretivas quando necessário.
Tabela 36 - SAM04
107
ID SAM05
AÇÃO Monitorar Processos Selecionados do Fornecedor
DESCRIÇÃO Selecionar, monitorar e analisar processos utilizados pelo fornecedor.
PRODUTOS Lista de processos selecionados para monitoramento ou justificativas para a não seleção.
Relatórios de atividade.
Relatórios de desempenho.
Curvas de desempenho.
Relatórios de problemas.
SUBPRÁTICAS Identificar os processos do fornecedor que são críticos para o sucesso do projeto.
Monitorar os processos selecionados do fornecedor em relação à conformidade com os requisitos do contrato.
Analisar os resultados do monitoramento dos processos selecionados para detectar, o mais cedo possível, questões críticas
que possam afetar a capacidade do fornecedor em satisfazer aos requisitos do contrato.
Tabela 37 - SAM05
ID SAM06
AÇÃO Avaliar Produtos de Trabalho Selecionados do Fornecedor
DESCRIÇÃO Selecionar e avaliar produtos de trabalho do fornecedor de produtos feitos sob encomenda.
PRODUTOS Lista de produtos de trabalho selecionados para monitoramento ou justificativas para a não seleção.
Relatórios de atividade.
Relatórios de problemas.
SUBPRÁTICAS Identificar os produtos de trabalho do fornecedor que são críticos para o sucesso do projeto e para os quais seja
recomendável uma avaliação, visando auxiliar na detecção de questões críticas o mais cedo possível.
Avaliar os produtos de trabalho selecionados.
Determinar e documentar as ações necessárias para tratar as deficiências detectadas nas avaliações.
Tabela 38 - SAM06
ID SAM07
AÇÃO Aceitar Produto Adquirido
DESCRIÇÃO Assegurar que o contrato com o fornecedor seja cumprido antes de aceitar o produto adquirido.
PRODUTOS Procedimentos de teste de aceitação.
Resultados de teste de aceitação.
Relatórios de problemas ou planos de ação corretiva.
SUBPRÁTICAS Definir procedimentos de aceitação.
Revisar e obter a anuência das partes interessadas relevantes nos procedimentos de aceitação antes da revisão ou do teste
de aceitação.
Verificar se os produtos adquiridos satisfazem a seus requisitos.
Confirmar que os compromissos não técnicos associados ao produto de trabalho adquirido sejam satisfeitos.
Documentar os resultados da revisão ou do teste de aceitação.
Estabelecer e obter anuência do fornecedor sobre os planos de ação para qualquer produto de trabalho adquirido que não
passe nas revisões ou testes de aceitação.
Identificar, documentar e acompanhar itens de ação até sua conclusão.
Tabela 39 - SAM07
ID SAM08
AÇÃO Transferir Produtos
DESCRIÇÃO Transferir para o projeto os produtos adquiridos do fornecedor.
PRODUTOS Planos de transferência.
Relatórios de treinamento.
Relatórios de manutenção e suporte.
SUBPRÁTICAS Assegurar que exista infraestrutura apropriada para receber, armazenar, utilizar e manter os produtos adquiridos.
Assegurar treinamento apropriado para os envolvidos no recebimento, armazenamento, utilização e manutenção dos
produtos adquiridos.
Assegurar que o armazenamento, distribuição e uso dos produtos adquiridos sejam executados de acordo com os termos e
condições especificados no contrato com o fornecedor ou na licença de uso.
Tabela 40 - SAM08
Ações de melhoria MA
108
ID MA01
AÇÃO Estabelecer Objetivos de Medição
DESCRIÇÃO Estabelecer e manter objetivos de medição derivados de necessidades de informação e objetivos identificados.
PRODUTOS Objetivos de medição.
SUBPRÁTICAS Documentar necessidades de informação e objetivos.
Priorizar necessidades de informação e objetivos.
Documentar, revisar e atualizar objetivos de medição.
Fornecer feedback para refinar e esclarecer as necessidades de informação e objetivos, conforme necessário.
Manter rastreabilidade dos objetivos de medição com as necessidades de informação e objetivos identificados.
Tabela 41 - MA01
ID MA02
AÇÃO Especificar Medidas
DESCRIÇÃO Especificar medidas para satisfazer aos objetivos de medição.
PRODUTOS Especificações de medidas-base e de medidas derivadas.
SUBPRÁTICAS Identificar medidas candidatas com base nos objetivos de medição documentados.
Identificar medidas existentes que já satisfaçam aos objetivos de medição.
Especificar definições operacionais das medidas.
Priorizar, revisar e atualizar medidas.
Tabela 42 - MA02
ID MA03
AÇÃO Especificar Procedimentos de Coleta e Armazenamento de Dados
DESCRIÇÃO Especificar como os dados resultantes de medição são obtidos e armazenados.
PRODUTOS Procedimentos de coleta e armazenamento de dados.
Ferramentas para coleta de dados.
SUBPRÁTICAS Identificar fontes existentes de dados que são gerados a partir de produtos de trabalho, processos ou transações.
Identificar medidas para as quais são necessários dados, mas que não estão disponíveis no momento.
Especificar como coletar e armazenar os dados para cada medida necessária.
Criar mecanismos para coleta de dados e orientações para o processo.
Fornecer suporte à coleta automática de dados onde for possível e apropriado.
Priorizar, revisar e atualizar os procedimentos de coleta e armazenamento de dados.
Atualizar medidas e objetivos de medição, conforme necessário.
Tabela 43 - MA03
ID MA04
AÇÃO Especificar Procedimento de Análise
DESCRIÇÃO Especificar como os dados resultantes de medição são analisados e comunicados.
PRODUTOS Especificações e procedimentos de análise.
Ferramentas de análise de dados.
SUBPRÁTICAS Especificar e priorizar as análises a serem executadas e os relatórios a serem elaborados.
Selecionar métodos e ferramentas de análise de dados adequados.
Especificar procedimentos administrativos para análise dos dados e comunicação dos resultados.
Revisar e atualizar forma e conteúdo propostos para análises e relatórios especificados.
Atualizar medidas e objetivos de medição, conforme necessário.
Especificar critérios para avaliação da utilidade dos resultados de análise e para avaliação da execução das atividades de
medição e análise.
Tabela 44 - MA04
ID MA05
AÇÃO Coletar Dados Resultantes de Medição
DESCRIÇÃO Obter dados resultantes de medição especificados.
PRODUTOS Conjuntos de dados de medições-base e de medições derivadas.
Resultados de testes de integridade de dados.
SUBPRÁTICAS Obter os dados das medidas-base.
Gerar os dados das medidas derivadas.
Verificar a integridade de dados o mais próximo possível da origem dos dados.
Tabela 45 - MA05
109
ID MA06
AÇÃO Analisar Dados Resultantes de Medição
DESCRIÇÃO Analisar e interpretar dados resultantes de medição.
PRODUTOS Resultados de análises e relatórios preliminares.
SUBPRÁTICAS Realizar análises iniciais, interpretar os resultados e chegar a conclusões preliminares.
Realizar medição e análise adicional, conforme necessário, e preparar os resultados para apresentação.
Revisar os resultados iniciais com as partes interessadas relevantes.
Refinar os critérios para análises futuras.
Tabela 46 - MA06
ID MA07
AÇÃO Armazenar Dados e Resultados
DESCRIÇÃO Gerenciar e armazenar dados resultantes de medição, especificações de medição e resultados de análise.
PRODUTOS Relação de dados armazenados.
SUBPRÁTICAS Revisar os dados para assegurar sua completude, integridade, precisão e atualização.
Armazenar os dados de acordo com os procedimentos de armazenamento.
Tornar o conteúdo armazenado disponível somente para pessoas e grupos apropriados.
Evitar que as informações armazenadas sejam utilizadas de forma inadequada.
Tabela 47 - MA07
ID MA08
AÇÃO Comunicar Resultados
DESCRIÇÃO Relatar resultados das atividades de medição e análise para todas as partes interessadas relevantes.
PRODUTOS Relatórios entregues e resultados de análise relacionados.
Informações de contexto ou orientações para auxiliar a interpretação dos resultados de análise.
SUBPRÁTICAS Informar regularmente as partes interessadas relevantes sobre os resultados das medições.
Auxiliar as partes interessadas relevantes no entendimento dos resultados.
Tabela 48 - MA08
Ações de melhoria PPQA

ID PPQA01
AÇÃO Avaliar Objetivamente os Processos
DESCRIÇÃO Avaliar objetivamente os processos selecionados em relação às descrições de processo, padrões e procedimentos aplicáveis.
PRODUTOS Relatórios de avaliação.

Relatórios de não conformidades.
Ações corretivas.
SUBPRÁTICAS Promover um ambiente (criado como parte da gestão do projeto) que estimule os empregados a participarem na
identificação e relato de questões críticas relacionadas à qualidade.
Estabelecer e manter critérios claramente definidos para as avaliações.
Utilizar os critérios definidos para avaliar a aderência dos processos executados em relação à descrição dos processos,
padrões e procedimentos.
Identificar as não conformidades encontradas durante a avaliação.
Identificar lições aprendidas que possam ser utilizadas na melhoria de processos para produtos e serviços futuros.
Tabela 49 - PPQA01
110
ID PPQA02
AÇÃO Avaliar Objetivamente Produtos de Trabalho e Serviços
DESCRIÇÃO Avaliar objetivamente os produtos de trabalho e serviços escolhidos com relação à descrição do processo, padrões e
procedimentos aplicáveis.
PRODUTOS Relatórios de avaliação.
Relatórios de não conformidades.
Ações corretivas.
SUBPRÁTICAS Selecionar produtos de trabalho a serem avaliados de acordo com critérios de amostragem documentados, caso seja
utilizada amostragem.
Estabelecer e manter critérios claramente definidos para as avaliações de produtos de trabalho.
Utilizar os critérios definidos durante avaliações de produtos de trabalho.
Avaliar produtos de trabalho antes que sejam entregues ao cliente.
Avaliar produtos de trabalho em marcos definidos ao longo do seu desenvolvimento.
Realizar avaliações intermediárias ou incrementais de produtos de trabalho e serviços em relação às descrições de processo,
padrões e procedimentos.
Identificar as não conformidades encontradas durante as avaliações.
Identificar lições aprendidas que possam ser utilizadas na melhoria de processos para produtos e serviços futuros.
Tabela 50 - PPQA02
ID PPQA03
AÇÃO Comunicar e assegurar a solução de não conformidades
DESCRIÇÃO Comunicar as questões críticas relativas à qualidade e assegurar a solução de não conformidades com a equipe e com os
gerentes.
PRODUTOS Relatórios de ação corretiva.
Relatórios de avaliação.
Tendências de qualidade.
SUBPRÁTICAS Resolver cada não conformidade com os membros apropriados da equipe, sempre que possível.
Documentar as não conformidades que não puderem ser resolvidas no projeto.
Escalar as não conformidades para o nível gerencial designado para recebê-las e tratá-las, caso não possam ser resolvidas no
projeto.
Analisar as não conformidades para ver se existe alguma tendência em relação à qualidade que possa ser identificada e
tratada.
Assegurar que as partes interessadas relevantes sejam informadas em tempo hábil sobre os resultados das avaliações e das
tendências em relação à qualidade.
Revisar periodicamente as não conformidades abertas e suas tendências com o gerente designado para recebê-las e tratá-
las.
As não conformidades devem ser monitoradas até sua solução.
Tabela 51 - PPQA03
ID PPQA04
AÇÃO Estabelecer Registros
DESCRIÇÃO Estabelecer e manter registros das atividades de garantia da qualidade.
PRODUTOS Registros (logs) de avaliações.
Relatórios de garantia da qualidade.
Relatórios de status de ações corretivas.
Relatórios sobre tendências em relação à qualidade.
SUBPRÁTICAS Registrar as atividades de garantia da qualidade de processo e produto com nível de detalhe suficiente para que tanto o
status quanto os resultados sejam conhecidos.
Atualizar o status e o histórico das atividades de garantia da qualidade quando necessário.,
Tabela 52 - PPQA04
Ações de melhoria CM
111
ID CM01
AÇÃO Identificar Itens de Configuração
DESCRIÇÃO Identificar os itens de configuração, componentes e produtos de trabalho relacionados a serem colocados sob gestão de
configuração.
PRODUTOS Itens de configuração identificados.
SUBPRÁTICAS Selecionar os itens de configuração e os produtos de trabalho que os compõem, com base em critérios ocumentados.
Atribuir identificadores únicos para os itens de configuração.
Especificar as características importantes de cada item de configuração.
Especificar quando cada item de configuração é colocado sob gestão de configuração.
Identificar o responsável por cada item de configuração.
Tabela 53 - CM01
ID CM02
AÇÃO Estabelecer um Sistema de Gestão de Configuração
DESCRIÇÃO Estabelecer e manter um sistema de gestão de configuração e de gestão de mudanças para controlar os produtos de
trabalho.
PRODUTOS Sistema de gestão de configuração com produtos de trabalho controlados.
Procedimentos de controle de acesso ao sistema de gestão de configuração.
Banco de dados de solicitações de mudança.
SUBPRÁTICAS Estabelecer um mecanismo para gerenciar vários níveis de controle de gestão de configuração.
Armazenar e recuperar itens de configuração em um sistema de gestão de configuração.
Compartilhar e transferir itens de configuração entre os níveis de controle no sistema de gestão de configuração.
Armazenar e recuperar versões arquivadas de itens de configuração.
Armazenar, atualizar e recuperar registros de gestão de configuração.
Criar relatórios de gestão de configuração a partir do sistema de gestão de configuração.
Proteger o conteúdo do sistema de gestão de configuração.
Atualizar a estrutura de gestão de configuração, quando necessário.
Tabela 54 - CM02
ID CM03
AÇÃO Criar ou Liberar Baselines
DESCRIÇÃO Criar ou liberar baselines para uso interno e para entrega ao cliente.
PRODUTOS Baselines
Descrição dos baselines
SUBPRÁTICAS
Obter autorização do Comitê de Controle de Configuração (CCB) antes de criar ou liberar baselines de itens de configuração.
Criar ou liberar baselines somente a partir de itens de configuração armazenados no sistema de gestão de configuração.
Documentar o conjunto de itens de configuração que estão contidos em um baseline.
Tornar prontamente disponível o conjunto atual de baselines.
Tabela 55 - CM03
ID CM04
AÇÃO Acompanhar Solicitações de Mudança
DESCRIÇÃO Acompanhar as solicitações de mudança dos itens de configuração.
PRODUTOS Solicitações de mudança.
SUBPRÁTICAS Iniciar e registrar as solicitações de mudança no banco de dados de solicitações de mudança.
Analisar o impacto das mudanças e das correções propostas pelas solicitações de mudança.
Revisar as solicitações de mudança que serão tratadas no próximo baseline com as partes interessadas relevantes e obter
sua anuência.
Acompanhar o status das solicitações de mudança até sua conclusão.
Tabela 56 - CM04
112
ID CM05
AÇÃO Controlar Itens de Configuração
DESCRIÇÃO Controlar mudanças nos itens de configuração.
PRODUTOS Histórico de alterações de itens de configuração.
Baselines arquivados.
SUBPRÁTICAS Controlar mudanças nos itens de configuração ao longo da vida do produto.
Obter autorização adequada antes de incorporar itens de configuração alterados ao sistema de gestão de configuração.
Realizar atividades de check-in e check-out de itens de configuração no sistema de gestão de configuração para incorporar as
mudanças, de maneira que a correção e integridade dos itens de configuração
sejam mantidas.
Realizar revisões para assegurar que as mudanças não causaram efeitos indesejáveis nos baselines (por exemplo, assegurar
que as mudanças não comprometeram a segurança física ou a segurança
lógica do sistema).
Registrar as mudanças nos itens de configuração e os motivos das mudanças, conforme apropriado.
Tabela 57 - CM05
ID CM06
AÇÃO Estabelecer Registros de Gestão de Configuração
DESCRIÇÃO Estabelecer e manter registros que descrevem os itens de configuração.
PRODUTOS Histórico de alterações de itens de configuração.,
Registro (log) de alterações.
Cópia das solicitações de mudança.
Status de itens de configuração.
Diferenças entre os baselines.
SUBPRÁTICAS Registrar ações de gestão de configuração com nível suficiente de detalhe, de forma que o conteúdo e o status de cada item
de configuração seja conhecido e que versões anteriores possam ser recuperadas.
Assegurar que as partes interessadas relevantes tenham acesso ao status dos itens de configuração e conhecimento dele.
Especificar a última versão dos baselines.
Identificar a versão dos itens de configuração que constituem um baseline específico.
Descrever as diferenças entre baselines sucessivos.
Atualizar o status e o histórico (isto é, mudanças e outras ações) de cada item de configuração, conforme necessário.
Tabela 58 - CM06
ID CM07
AÇÃO Executar Auditorias de Configuração
DESCRIÇÃO Executar auditorias de configuração para manter a integridade dos baselines.
PRODUTOS Resultados de auditorias de configuração.
Itens de ação.
SUBPRÁTICAS Avaliar a integridade dos baselines.
Confirmar se os registros de gestão de configuração identificam corretamente dos itens de configuração.
Revisar a estrutura e a integridade dos itens no sistema de gestão de configuração.
Confirmar a completude e correção dos itens no sistema de gestão de configuração
Confirmar a conformidade com padrões e procedimentos aplicáveis de gestão de configuração.
Acompanhar os itens de ação da auditoria até sua conclusão.
Tabela 59 - CM07

CT Cosis 2016 5

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CT Cosis 2016 5

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

DEPARTAMENTO ACADÊMICO DE INFORMÁTICA

LUCAS DE ALMEIDA CRUZ

ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

TRABALHO DE CONCLUSÃO DE CURSO

ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

Trabalho de Conclusão do Curso de

Cruz, L., e Moro, L. ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

Este trabalho apresenta a análise do grau de maturidade de

Palavras-chave: CMMI. Modelagem de sistemas. Maturidade em

Cruz, L., e Moro, L. ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM

This Project presents an analysis of the maturity levels in the software

Keywords: CMMI. Systems modeling. Maturity in software development.

Figura 1 - Modelo Cascata.......................................................................... 21

Figura 2 - Modelo incremental ................................................................... 22

Figura 3 - Modelo de prototipação ............................................................ 23

Figura 4 - Modelo de espiral de desenvolvimento ................................... 24

Figura 5 - Comparação dos custos das mudanças em diferentes

Figura 6 - Fluxo do processo Scrum ......................................................... 27

Figura 7 - As três dimensões críticas ....................................................... 29

Figura 8 - Áreas de Processo na representação por Estágio ................. 31

Figura 9 - Áreas de Processo na representação Contínua ..................... 31

Figura 10 - Componentes do modelo CMMI ............................................. 32

Figura 11 - Processo de Negócio do Sistema de Gerenciamento de

Figura 12 - Fluxo de Atividades ................................................................. 52

Figura 13 - Comparativo das taxas de Aderência .................................... 57

Figura 14 - Aderência de REQM................................................................. 58

Figura 15 - Aderência PP ............................................................................ 59

Figura 16 - Aderência PMC......................................................................... 59

Figura 17 - Aderência SAM......................................................................... 60

Figura 18 - Aderência MA ........................................................................... 61

Figura 19 - Aderência PPQA ...................................................................... 62

Figura 21 - Processo Local de desenvolvimento(PLD) ........................... 64

Figura 22 - Títulos de reponsabilidade ..................................................... 68

Figura 23 - Relação de REQM com as outras áreas de processo ........... 69

Figura 24 - Workflow de REQM .................................................................. 70

Figura 25 - Relação de PP com as outras áreas de processo................. 70

Figura 26 - Workflow PP ............................................................................. 71

Figura 27 - Relação de PMC com as outras áreas de processo ............. 72

Figura 28 - Workflow PMC .......................................................................... 73

Figura 29 - Relação de SAM com as outras áreas de processo ............. 74

Figura 30 - Worflow de SAM....................................................................... 75

Figura 31 - Relação de MA com as outras áreas de processo ................ 76

Figura 32 - Workflow de MA ....................................................................... 77

Figura 33 - Relação de PPQA com as outras áreas de processo ........... 77

Figura 34 - Workflow de PPQA .................................................................. 78

Figura 35 - Relação de CM com as outras áreas de processo ................ 79

Figura 36 - Workflow de CM ....................................................................... 79

Figura 37 - Tela Inicial do Site.................................................................... 82

Figura 38 - Tela de apresentação do Processo Local .............................. 83

Figura 39 - Tela de apresentação da área Planejamento de Projeto ...... 84

Tabela 1 - Metas Genéricas e Nomes de Processos ................................ 33

Tabela 2 - Critérios SCAMPI x Pesquisa ................................................... 55

Tabela 7 - REQM05.................................................................................... 100

Tabela 8 - PP01.......................................................................................... 100

Tabela 9 - PP02.......................................................................................... 100

Tabela 10 - PP03........................................................................................ 100

Tabela 11 - PP04........................................................................................ 101

Tabela 12 - PP05........................................................................................ 101

Tabela 13 - PP06........................................................................................ 101

Tabela 14 - PP07........................................................................................ 101

Tabela 15 - PP08........................................................................................ 102

Tabela 16 - PP09........................................................................................ 102