Modelo de Plano de Projetorepositorio.roca.utfpr.edu.br/jspui/bitstream/1/8240/1/CT_COSIS_2016_5.pdfdentro do modelo de desenvolvimento atual. Apresenta-se como resultado um plano

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

Fonte: Pressman (2010)

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

Tabela 3- REQM01 Fonte: Autoria Própria

4.2.1 REQM

Figura 24 - Relação de REQM com as outras áreas de processo


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.

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

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

PRODUTOS

SUBPRÁTICAS

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

http://www.dtic.mil/dtic/tr/fulltext/u2/a558352.pdf

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.

http://www.agilealliance.org/home

91

APÊNDICE A

92

93

94

95

96

97

98

99

APÊNDICE B

Ações de Melhoria REQM

Tabela 4- REQM01 Fonte: Autoria Própria

Tabela 5 - REQM02 Fonte: Autoria Própria


Tabela 7 - REQM01


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.

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

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

PRODUTOS

SUBPRÁTICAS

ID REQM02

AÇÃO Obter comprometimento com os requisitos

DESCRIÇÃO Obter comprometimento dos participantes do projeto com os requisitos.

Análise de impacto dos requisitos.

Acordos documentados sobre os requisitos e suas mudanças.

Analisar o impacto dos requisitos nos compromissos existentes.

Negociar e registrar compromissos.

PRODUTOS

SUBPRÁTICAS

ID REQM03

AÇÃO Gerenciar mudanças com os requisitos

DESCRIÇÃO Gerenciar mudanças nos requisitos à medida que evoluem durante o projeto.

Status dos requisitos.

Banco de dados dos requisitos.

Banco de dados das decisões sobre requisitos.

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.

PRODUTOS

SUBPRÁTICAS

ID REQM04

AÇÃO Manter rastreabilidade bidirecional dos requisitos

DESCRIÇÃO Manter a rastreabilidade bidirecional dos requisitos e produtos de trabalho.

Matriz de rastreabilidade de requisitos.

Sistema de rastreamento de requisitos.

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.

SUBPRÁTICAS

PRODUTOS

100


Ações de melhoria PP

Tabela 9 - PP01


Tabela 10 - PP02


Tabela 11 - PP03


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.

Documentação das inconsistências, incluindo origens, condições e linha de raciocínio utilizada.

Ações corretivas.

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.

SUBPRÁTICAS

PRODUTOS

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.

Descrições de tarefas.

Descrições de pacotes de trabalho.

WBS.

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.

PRODUTOS

SUBPRÁTICAS

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.

Abordagem técnica.

Tamanho e complexidade de produtos de trabalho e de tarefas.

Modelos de estimativas.

Estimativas de atributo.

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.

PRODUTOS

SUBPRÁTICAS

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

101

Tabela 12 - PP04


Tabela 13 - PP05


Tabela 14 - PP06


Tabela 15 - PP07


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.

Raciocínio utilizado nas estimativas.

Estimativas de esforço do projeto.

Estimativas de custo do projeto.

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.

PRODUTOS

SUBPRÁTICAS

ID PP05

AÇÃO Estabelecer Orçamento e Cronograma

DESCRIÇÃO Estabelecer e manter o orçamento e o cronograma do projeto.

Cronogramas do projeto.

Dependências de cronograma.

Orçamento do projeto.

Identificar principais marcos.

Identificar hipóteses utilizadas no cronograma.

Identificar restrições.

Identificar dependências entre tarefas.

Definir orçamento e cronograma.

PRODUTOS

SUBPRÁTICAS

ID PP06

AÇÃO Identificar Riscos do Projeto

DESCRIÇÃO Identificar e analisar riscos do projeto.

Riscos identificados.

Impacto e probabilidade de ocorrência dos riscos

Prioridade de riscos.

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.

PRODUTOS

SUBPRÁTICAS

ID PP07

AÇÃO Planejar Gestão de Dados

DESCRIÇÃO Planejar a gestão de dados do projeto.

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.

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.

SUBPRÁTICAS

PRODUTOS

102

Tabela 16 - PP08


Tabela 17 - PP09


Tabela 18 - PP10


Tabela 19 - PP11


Tabela 20 - PP12


ID PP08

AÇÃO Planejar Recursos do Projeto

DESCRIÇÃO Planejar os recursos necessários para execução do projeto.

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.

Determinar requisitos de processo.

Determinar requisitos para composição da equipe.

Determinar requisitos de infraestrutura, equipamento e componentes.

PRODUTOS

SUBPRÁTICAS

ID PP09

AÇÃO Planejar Habilidades e Conhecimento Necessários

DESCRIÇÃO Planejar habilidades e conhecimento necessários para a execução do projeto.

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.

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.

PRODUTOS

SUBPRÁTICAS

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

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

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

103

Tabela 21 - PP13


Tabela 22 - PP14


Ações de melhoria PM

Tabela 23 - PMC01


Tabela 24 - PMC02


ID PP13

AÇÃO Conciliar Carga de Trabalho e Recursos

DESCRIÇÃO Conciliar o plano do projeto com os recursos estimados e disponíveis.

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

PRODUTOS

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.

Solicitações de compromisso documentadas.

Compromissos documentados.

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.

PRODUTOS

SUBPRÁTICAS

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.

Registros de desempenho de projeto.

Registros de desvios significativos.

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.

PRODUTOS

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

104

Tabela 25 - PMC03


Tabela 26 - PMC04


Tabela 27 - PMC05


Tabela 28 - PMC06


Tabela 29 - PMC07


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.

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.

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

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.

Revisar periodicamente o envolvimento das partes interessadas.


Documentar os resultados das revisões de status do envolvimento das partes interessadas.

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

105

Tabela 30 - PMC08


Tabela 31 - PMC09


Tabela 32 - PMC10


Ações de melhoria SAM

Tabela 33 - SAM01


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.

Identificar questões críticas para análise.

Analisar as questões críticas para determinar a necessidade de ações corretivas.

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

ID PMC10

AÇÃO Gerenciar Ações Corretivas

DESCRIÇÃO Gerenciar ações corretivas até sua conclusão.

PRODUTOS Resultados de ações corretivas.

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.

SUBPRÁTICAS

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

106

Tabela 34 - SAM02


Tabela 35 - SAM03


Tabela 36 - SAM04


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.

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.

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.

SUBPRÁTICAS

PRODUTOS

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.

Declarações de trabalho.

Contratos.

Memorandos de acordo entre as partes.

Contrato de licenciamento.

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.

SUBPRÁTICAS

PRODUTOS

ID SAM04

AÇÃO Executar Contrato com Fornecedor

DESCRIÇÃO Executar atividades com o fornecedor conforme especificado no contrato com o fornecedor.

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.

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.

SUBPRÁTICAS

PRODUTOS

107

Tabela 37 - SAM05


Tabela 38 - SAM06


Tabela 39 - SAM07


Tabela 40 - SAM08


Ações de melhoria MA

ID SAM05

AÇÃO Monitorar Processos Selecionados do Fornecedor

DESCRIÇÃO Selecionar, monitorar e analisar processos utilizados pelo fornecedor.

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.

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.

SUBPRÁTICAS

PRODUTOS

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.

Lista de produtos de trabalho selecionados para monitoramento ou justificativas para a não seleção.

Relatórios de atividade.

Relatórios de problemas.

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.

SUBPRÁTICAS

PRODUTOS

ID SAM07

AÇÃO Aceitar Produto Adquirido

DESCRIÇÃO Assegurar que o contrato com o fornecedor seja cumprido antes de aceitar o produto adquirido.

Procedimentos de teste de aceitação.

Resultados de teste de aceitação.

Relatórios de problemas ou planos de ação corretiva.

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.

SUBPRÁTICAS

PRODUTOS

ID SAM08

AÇÃO Transferir Produtos

DESCRIÇÃO Transferir para o projeto os produtos adquiridos do fornecedor.

Planos de transferência.

Relatórios de treinamento.

Relatórios de manutenção e suporte.

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.

PRODUTOS

SUBPRÁTICAS

108

Tabela 41 - MA01


Tabela 42 - MA02


Tabela 43 - MA03


Tabela 44 - MA04


Tabela 45 - MA05


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.

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.

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

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.

Procedimentos de coleta e armazenamento de dados.

Ferramentas para coleta de dados.

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.

PRODUTOS

SUBPRÁTICAS

ID MA04

AÇÃO Especificar Procedimento de Análise

DESCRIÇÃO Especificar como os dados resultantes de medição são analisados e comunicados.

Especificações e procedimentos de análise.

Ferramentas de análise de dados.

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.

SUBPRÁTICAS

PRODUTOS

ID MA05

AÇÃO Coletar Dados Resultantes de Medição

DESCRIÇÃO Obter dados resultantes de medição especificados.

Conjuntos de dados de medições-base e de medições derivadas.

Resultados de testes de integridade de dados.

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.

PRODUTOS

SUBPRÁTICAS

109

Tabela 46 - MA06


Tabela 47 - MA07


Tabela 48 - MA08


Ações de melhoria PPQA

Tabela 49 - PPQA01


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.

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.

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

ID MA08

AÇÃO Comunicar Resultados

DESCRIÇÃO Relatar resultados das atividades de medição e análise para todas as partes interessadas relevantes.

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.

Informar regularmente as partes interessadas relevantes sobre os resultados das medições.

Auxiliar as partes interessadas relevantes no entendimento dos resultados.

PRODUTOS

SUBPRÁTICAS

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.

Relatórios de avaliação.

Relatórios de não conformidades.

Ações corretivas.

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.

PRODUTOS

SUBPRÁTICAS

110

Tabela 50 - PPQA02


Tabela 51 - PPQA03


Tabela 52 - PPQA04


Ações de melhoria CM

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.


Relatórios de não conformidades.

Ações corretivas.

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.

PRODUTOS

SUBPRÁTICAS

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.

Relatórios de ação corretiva.


Tendências de qualidade.

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.

PRODUTOS

SUBPRÁTICAS

ID PPQA04

AÇÃO Estabelecer Registros

DESCRIÇÃO Estabelecer e manter registros das atividades de garantia da qualidade.

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.

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

SUBPRÁTICAS

PRODUTOS

111

Tabela 53 - CM01


Tabela 54 - CM02


Tabela 55 - CM03


Tabela 56 - CM04


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.

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.

SUBPRÁTICAS

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.

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.

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.

PRODUTOS

SUBPRÁTICAS

ID CM03

AÇÃO Criar ou Liberar Baselines

DESCRIÇÃO Criar ou liberar baselines para uso interno e para entrega ao cliente.

Baselines

Descrição dos baselines

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.

PRODUTOS

SUBPRÁTICAS

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.

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.

SUBPRÁTICAS

112

Tabela 57 - CM05


Tabela 58 - CM06


Tabela 59 - CM07


ID CM05

AÇÃO Controlar Itens de Configuração

DESCRIÇÃO Controlar mudanças nos itens de configuração.

Histórico de alterações de itens de configuração.

Baselines arquivados.

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.

PRODUTOS

SUBPRÁTICAS

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.

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.

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.

PRODUTOS

SUBPRÁTICAS

ID CM07

AÇÃO Executar Auditorias de Configuração

DESCRIÇÃO Executar auditorias de configuração para manter a integridade dos baselines.

Resultados de auditorias de configuração.

Itens de ação.

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.

SUBPRÁTICAS

PRODUTOS

Documents

Modelo de Plano de Projetorepositorio.roca.utfpr.edu.br/jspui/bitstream/1/8240/1/CT_COSIS_2016_5.pdfdentro do modelo de desenvolvimento atual. Apresenta-se como resultado um plano