UNIVERSIDADE FEDERAL DE SANTA CATARINA Implantação do MPS.BR Nível G Autor: Thais Oliveira Bergmann Florianópolis 2008/1 1
UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE SISTEMAS DE INFORMAÇÃO Implantação do MPS.BR Nível G Thais Oliveira Bergmann Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação Florianópolis - SC 2008/1 2
Thais Oliveira Bergmann Implantação do MPS.BR Nível G Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof, Roberto C. S. Pacheco Banca examinadora: Professor José Salm Jr. Professor Nikolai Dimitri 3
Dedicatória Dedico este trabalho aos meus pais, in memoriam. 4
Agradecimentos Agradeço ao Marcos pela compreensão e paciência, à minha família e a todos que estiveram de alguma forma presentes e me apoiaram nesta caminhada. Agradeço também à Ilog Tecnologia, empresa onde este trabalho foi desenvolvido e ao professor João Bosco da Motta Alves, pelas conversas orientadoras no começo do curso. 5
LISTA DE FIGURAS Figura 1 - Estrutura da Norma ISO/IEC 12207...19 Figura 2 - Modelo de Ciclo de Vida em Cascata...20 Figura 3 - Modelo de Ciclo de Vida Incremental...21 Figura 4 - Modelo de Ciclo de Vida Iterativo...22 Figura 5 - Modelo de Ciclo de Vida em Espiral...23 Figura 6 - Modelo de Ciclo de Vida Espiral...24 Figura 7 - Modelo V...25 Figure 8 Níveis de Classificação dos Processos ISO/IEC 15504...28 Figura 9 - Estrutura da norma ISO/IEC 15504...29 Figura 10 - Estrutura da Documentação do MPS.BR...34 Figura 11 - Organograma Ilog Fonte Ilog...43 Figura 12 - Processo de Fornecimento...48 Figura 13 - Template Checklist Aceitação de Requisitos...53 Figura 14 - Template para Estimativas de Esforço...54 Figura 15 - Processo de Planejamento de Projeto...56 Figura 16 - Template para Plano de Gerência de Dados...57 Figura 17 - Template para Plano de Comunicação Organizacional...58 Figura 18 - Template para Descrição de Papéis...65 Figura 19 - Template para Mapa de Habilidades e Competências...65 Figura 20 - Template para Ata de Reunião de Comprometimento...67 Figura 21 - Processo de Gerência de Mudança de Requisitos...69 Figura 22 - Template para Requisição de Mudança de Requisitos...72 Figura 23 - Processo de Monitoração de Projetos...75 Figura 24 - Estrutura de Dados de Desenvolvimento de Processo...81 Figura 25 - Relatório de Alocação de Recursos...82
Lista de Tabelas Tabela 1 Vantagens de desvantagens dos modelos de ciclo de vida...26 Tabela 2 - Comparação entre níveis de maturidade e níveis capacidade...30 Tabela 3 - Comparação entre níveis de maturidade CMMI e MPS.BR... 33 Tabela 4 - Estrutura de processos e níveis do MPS.BR...37 7
Lista de Reduções MPS.BR Melhoria de Processo do Software Brasileiro CMMI - Capability Maturity Model Integration SEI Software Engineering Institute AP Atributo de Processo RAP Resultados de Atributo de Processo GRE Resultado Esperado para o Processo de Gerência de Requisitos GPR Resultado Esperado para o Processo de Gerência de Projetos EAD Ensino a Distância ACATE Associação Catarinense de Empresas de Tecnologia PERT - Program Evaluation and Review Technique WBS - Work Breakdown Structure ISO International Organization for Standardization 8
Sumário 1 Introdução...12 1.1 Apresentação...12 1.2 Objetivo Geral...12 1.3 Objetivos Específicos...12 1.4 Motivação...13 1.5 Justificativa...13 1.6 Organização deste documento...14 2 Engenharia de Software...14 2.1 O que é software...14 2.2 Crise do Software...15 2.3 ISO/IEC 12207 Processos do Ciclo de Vida do Software...16 2.3.1 Processo Fundamental...17 2.3.2 Processo Organizacional...17 2.3.3 Processo de Apoio...18 2.3.4 Modelos de Ciclo de Vida...19 2.3.4.1 Modelo de Ciclo de Vida Cascata...19 2.3.4.2 Modelos de Ciclo de Vida Incremental, Iterativo e Espiral [3]...20 2.3.4.3 Modelos de Ciclo de Vida Evolucionário...23 2.3.4.4 Modelos de Ciclo de Vida V...24 2.3.5 Vantagens e Desvantagens dos Modelos de Ciclo de Vida...25 3 Padrões de Qualidade de Processo de Software...26 3.1 ISO/IEC 15504 Avaliação do Processo de Software...26 3.2 CMMI [10]...29 3.2.1 Abordagem Contínua...31 3.3 MPS.BR Melhoria de Processo do Software Brasileiro...32 3.3.1 Guias e Documentação MPS.BR...34 3.3.2 Conceitos Importantes no MPS.BR...35 3.3.3 Níveis de Maturidade no MPS.BR...36 3.3.4 Processo...36 3.3.5 Estrutura de Processos e Níveis do MPS.BR...37 4 Implantação do MPS.BR na Ilog Tecnologia...43 4.1 Ilog Tecnologia...43 4.2 Atividades para Implantação do MPS.BR...44 4.2.1 Primeira Atividade - Conscientização...44 9
4.2.2 Segunda Atividade Diagnosticação da Situação Atual...44 4.2.3 Terceira Atividade Treinamento...45 4.2.4 Quarta Atividade Mapeamento dos Processos...45 4.2.5 Quinta Atividade Detalhamento dos Processos Mapeados...45 4.2.6 Sexta Atividade Treinamento do Processo Organizacional...46 4.2.7 Sétima Atividade Avaliação Interna nos Projetos da Empresa...46 4.2.8 Oitava Atividade Simulados...46 4.3 Preparação para Avaliação Oficial...46 4.3.1 Descrição dos Processos...47 4.3.2 Processo de Fornecimento...47 4.3.3 Planejamento do Projeto...55 4.3.4 Encerrar o Projeto...67 4.3.5 Gerência de Mudanças de Requisitos...68 4.3.6 Monitoração do Projeto...74 4.3.7 Atributos de Processo...78 4.4 Avaliação...80 4.5 Ferramentas Utilizadas...80 4.5.1 Eclipse Process Framework EPF...80 4.5.2 JExpChannel...81 4.5.3 SVN...82 4.5.4 Pacote Microsoft Office...82 4.5.5 Enterprise Architect...83 5 Conclusões...84 5.1 Trabalhos Futuros...85 10
Resumo Este trabalho relata a implantação do MPS.BR nível G na empresa Ilog Tecnologia. Além disso, revisa os principais conceitos de engenharia de software e padrões de qualidade de processo de software como a ISO/IEC 15504, CMMI e MPS.BR. Abstract This document describes the deployment of MPS.BR level G at Ilog Technology company. Moreover, it reviews the main concepts about software engineering and quality standard of software process as ISO/IEC 15504, CMMI and MPS.BR. E palavras-chave: ISO/IEC 12207, ISO/IEC 15504, MPS.BR, CMMI, Engenharia de Software e Melhoria de Software. 11
1 Introdução 1.1 Apresentação O desenvolvimento de software está entre as mais promissoras atividades realizadas em Santa Catarina. Estimam-se 1500 empresas de Tecnologia em Santa Catarina, cujo faturamento é de 1 bilhão de reais 1. Nesse contexto pode ser percebida a importância de se ter um processo de desenvolvimento de software para que a produção seja potencializada no estado e conseqüentemente no país. Dentre os principais fatores limitadores do crescimento das empresas de desenvolvimento de software está o caos em que essas operam, na maioria das vezes. Freqüentemente essas empresas até tem processos informais de desenvolvimento que são abandonados sempre que ocorre algum problema como, por exemplo, atraso no cronograma ou mudança de prioridade do projeto na empresa. Para esse contexto foi criado o MPS.BR, que é o programa de melhoria de processos de software. O MPS.BR é mais adequado a realidade brasileira se comparada ao CMMI por exemplo. Uma vez que é dividido em sete níveis, equivalentes ao CMMI, porém mais adequado a realidade das empresas de micro e pequeno porte, que podem implantar o modelo em etapas menores. Além disso, o MPS.BR custa em torno de quatro vezes menos que a certificação CMMI. O MPS.BR é coordenado pela Associação para Promoção da Excelência do Software Brasileiro, a Softex, que vem realizando esforços para obter o reconhecimento internacional do MPS.BR como garantia de qualidade, uma vez que é um modelo equivalente ao CMMI. 1.2 Objetivo Geral Implantar o MPS.BR nível G na empresa Ilog Tecnologia. 1.3 Objetivos Específicos Estudar o MPS.BR; Mapear os processos necessários para a implantação do MPS.BR nível G; 1 Mercado Brasileiro de Software - Panorama e Tendências - Abes 2008 12
Institucionalizar, ou seja, descrever e implantar, os processos de gerência de projetos e gerência de requisitos, requeridos para obter o nível G do MPS.BR; Realizar simulados de avaliação do MPS.BR; Obter o nível G do MPS.BR; 1.4 Motivação A falta de metodologia para desenvolvimento de software é certamente o principal fator de fracasso nos projetos de desenvolvimento de software em pequenas e micro empresas. Na maioria das vezes, o projeto tem um dono na empresa, que diz o que deve ser feito. Porém se o dono do projeto for substituído o projeto será executado de uma forma diferente. A execução das atividades dos projetos acontece de forma caótica, com o cronograma apertado, muitas vezes impossível para ser mantido mas que foi imposto pelo cliente. Freqüentemente o software resultante desses projetos tem baixa qualidade, difícil manutenção e nenhuma documentação. A motivação é mostrar que é possível uma micro empresa seguir uma metodologia de desenvolvimento de software, que produza um produto com qualidade levando em conta as características de uma micro empresa. 1.5 Justificativa Haja vista o imenso potencial brasileiro no mercado de software, produzir um produto com qualidade e com preços acessíveis são características imprescindíveis para manter-se competitivo neste mercado. Estas características: qualidade e competitividade podem ser obtidas desde que a empresa adote uma metodologia de desenvolvimento de software que a permita detectar oportunidades de melhorias e pontos fortes do seu processo. A razão para adotar uma metodologia conhecida como o CMMI ou MPS.BR é que essas metodologias já se mostraram eficientes, o que reduz o tempo de implantação de um processo para desenvolvimento de software. Além da qualidade e competitividade, seguir uma metodologia conhecida é um diferencial competitivo em relação a empresas que seguem metodologias próprias, que não são conhecidas ou que não tem metodologias/processos. 13
1.6 Organização deste documento Este trabalho está organizado em 5 capítulos. O primeiro capítulo traz a introdução ao conteúdo a ser apresentado neste documento, como a apresentação do tema, o objetivo geral, os objetivos específicos, motivação e justificativa. O segundo capítulo traz informações sobre a Engenharia de Software e Ciclo de Vida do Software, assuntos introdutórios para melhor entendimento dos demais temas abordados neste documento. O terceiro capítulo discorre sobre os principais padrões de qualidade para processo de desenvolvimento de software. No quarto é relatado como ocorreu a implantação do MPS.BR na Ilog Tecnologia. O quinto capítulo traz as conclusões obtidas a partir deste trabalho assim como os trabalhos futuros. 2 Engenharia de Software 2.1 O que é software Software é: (1) Instruções (programas de computador) que quando executadas, produzem a função e o desempenho desejados; (2) estruturas de dados que permitem que os programas manipulem adequadamente a informação; e (3) documentos que descrevem a operação e ouso dos programas. Pressman, 1995. Segundo Pressman, para entender o que é software é necessário que sejam verificadas as características que o difere de outros produtos criados pelo homem. O software como sendo o resultado de um sistema lógico, não toma forma física quando pronto como é o caso do hardware, por exemplo. As principais características que diferem o software dos demais produtos são as seguintes: O software é desenvolvido por engenharia: Assim como os demais produtos manufaturados, o software precisa ser projetado. A diferença está na forma de construção deste uma vez que não é físico não é trivial saber exatamente o que se tem pronto ou quanto ainda falta para finalizá-lo. Enfim, uma das grandes dificuldades na construção do software é para obter as métricas do projeto. O software não se desgasta: Diferente dos demais produtos produzidos pelo homem, o software não desgasta com o passar do tempo. Porém, ainda segundo Pressman, o software deteriora, pois ao longo da vida o software sofre modificações que são como pontos de inserção de defeitos, o 14
que ao passar do tempo aumenta o número de falhas que o software poderá apresentar. A maioria dos softwares é feita sob medida: Na maioria das vezes a construção de um software parte do zero, ou seja, não existem componentes que simplesmente combinados formam o software. 2.2 Crise do Software No início dos anos 80 a crise do software atraiu a atenção das empresas e governo americano. Nessa época o congresso americano verificou o impacto que a tecnologia tinha sobre a economia americana e na competitividade global dos Estados Unidos. O congresso verificou que o impacto da desordem vivida na época seria desastroso uma vez que a tecnologia dava forma ao futuro. A conclusão foi de que a melhor forma de se ter um futuro em ordem seria organizar o presente. A maior causa da crise do software é que as máquinas tornaram-se várias ordens de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, programar não era um problema; quando tivemos computadores fracos, isso se tornou um problema pequeno e agora que temos computadores gigantescos, programar tornou-se um problema gigantesco. Edsger Dijkstra na sua apresentação The Humble Programmer, Em 1984, o congresso americano fundou uma organização chamada Software Engineering Instituite (SEI), com uma equipe formada pelos mais importantes centros de pesquisa sobre o assunto nos EUA. Essa equipe ficou hospedada na Universidade Carnegie- Mellon em Pittsburgh. O objetivo do SEI é trabalhar para estabelecer normas e metodologias no campo de desenvolvimento de software para ajudar a América a manter a competitividade frente aos esforços tecnológicos no mundo. O SEI cumpriria esse objetivo através de programas de pesquisa, treinamentos e desenvolvimento profissional [11]. A primeira definição de engenharia de software foi proposta por Fritz Bauer em 1969, que é a seguinte: O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais. Segundo Pressman (1995), a engenharia de software deriva da engenharia de sistemas e de hardware, e que abrange um conjunto de três elementos fundamentais que possibilitam o controle do processo de desenvolvimento de software e oferecem 15
uma base para a construção de software de alta qualidade, produtivamente. Os três elementos fundamentais da engenharia de software, também chamados como Paradigmas da Engenharia de Software, são: Métodos: Proporcionam orientações sobre como construir o software; Ferramentas de Engenharia de Software: automatizam os métodos para construção de software; Processos de Engenharia de Software: que formam a ligação entre métodos e ferramentas para que o software seja construído. Ainda segundo Pressman, esses três elementos fundamentais passam por três fases genéricas, a saber: Definição: identificar a função do software a ser desenvolvido. Nessa fase acontecem a análise de requisitos e análise e projeto do software. Desenvolvimento: executa o que foi planejado, nessa fase ocorrem os testes e codificação do software. Manutenção: correções, adaptação e melhorias no software. 2.3 ISO/IEC 12207 Processos do Ciclo de Vida do Software A ISO/IEC 12207 Standard for Information Technology Software life cycle process guia como estruturar e gerenciar o todo ciclo de desenvolvimento de software, proporcionando assim a visão geral de todo o processo. Essa norma contém um conjunto de processos, atividade e tarefas que podem ser adaptadas a cada tipo de projeto de software. Esse conjunto de processos, atividades e tarefas cobrem o software desde a sua criação até sua aposentaria. Ciclo de vida é a estrutura que contém processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos até o término de seu uso. NBR ISO/IEC 12207 Uma passagem completa por quatro fases: concepção, elaboração, construção e transição. O espaço de tempo entre o início da fase de concepção e o final de transição. IBM/Rational, Glossário do RUP A norma ISO/IEC 12207, crida em 1995 revisada em 2002 e 2004 estabelece um 16
framework padrão para definição do ciclo de vida de software. O objetivo da ISO/IEC 12207 é que cliente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e desenvolvedores utilizem a mesma estrutura de processos, com terminologias bem definidas, que podem ser referenciadas pela indústria de software. Para isso foram definidos três macro processos: o processo fundamental, processo organizacional e processo de apoio. [1] 2.3.1 Processo Fundamental O processo fundamental contempla a contratação, desenvolvimento, operação e manutenção dos produtos de software ao longo do ciclo de vida do software. O processo Fundamental abrange as atividades de aquisição, fornecimento, desenvolvimento, operação e manutenção [1]. Aquisição: atividades para contratar a organização que desenvolveu o sistema, software ou serviço. Fornecimento: atividades dos fornecedores, da organização que provem o sistema ou o serviço que precisa ser adquirido. Desenvolvimento: papéis e atividades para desenvolvimento do software. Operação: atividades para operação do produto de software e suporte operacional aos usuários; Manutenção: atividades de manutenção do software. Isso inclui a gestão de mudanças, migração e fim do ciclo de vida do software. 2.3.2 Processo Organizacional O processo organizacional auxilia o desenvolvimento de processos, produtos e recursos a serem utilizados nos projetos para que a organização atinja seus objetivos de negócio. No processo organizacional, encontram-se as seguintes atividades: gestão, infraestrutura e recursos, melhoria e treinamento. Gestão: atividades básicas de gestão, incluindo gestão de projetos relacionada ao ciclo de vida do software. Infra-estrutura e Recursos: os recursos e infra-estrutura para os processos realizados pela organização ao longo do ciclo de vida do software. 17
Melhoria: atividades básicas que a organização necessita para controlar, medir e melhorar seu processo de ciclo de vida do software. Treinamento: define as atividades para prover um treinamento adequado. 2.3.3 Processo de Apoio O processo de apoio auxilia e contribui para o sucesso e qualidade dos outros processos envolvidos no ciclo de vida do software. No processo de Apoio encontram-se as seguintes atividades [1]: documentação, gestão de configuração, garantia da qualidade, verificação, validação, auditoria e resolução de problemas. Documentação: atividades para registrar as informações produzidas ao longo do ciclo de vida do software. Gestão de Configuração: define as atividades de gestão de configuração. Garantia da Qualidade: atividades objetivamente para garantir que o software produzido está de acordo com as especificações de requisitos e aderente aos planos estabelecidos. As técnicas de revisões compartilhadas, auditorias, verificação e validação podem ser usadas para garantia da qualidade. Verificação: atividades para verificação do software e serviços em diferentes profundidades de acordo com o projeto do software. Validação: atividades para validação do software de acordo com o projeto do software. Auditoria: atividade para determinação da conformidade com os requisitos, planos e contrato. Este processo pode ser empregado pela equipe auditora e equipe auditada. Resolução de Problemas: processo de análise e remoção dos problemas, inclusive não-conformidades, independente da causa raiz, descobertos durante a execução dos processos ao longo do ciclo de vida do software. Abaixo está a ilustração de como está estruturada a norma ISO/IEC 12207: 18
Figura 1 Estrutura da Norma ISO/IEC 12207 Fonte: NBR ISO/IEC 12207 2.3.4 Modelos de Ciclo de Vida O modelo de ciclo de vida do software consiste de todas as atividades desde a criação até a aposentadoria deste. A escolha do modelo de ciclo de vida é uma das mais influentes decisões para o sucesso do projeto em questão, pois se adequada contribui para que o processo de desenvolvimento do software seja eficiente, seja obtido um produto com mais qualidade além de minimizar os riscos inerentes ao processo. Assim como a escolha de um modelo de ciclo de vida inadequado ou a falta de um pode fazer que haja muito atividades desnecessárias e frustração ao longo do ciclo de vida do software. [31] 2.3.4.1 Modelo de Ciclo de Vida Cascata Ainda que largamente desprezado como ineficiente, o modelo cascata é o mais antigo e usado até hoje. Pois é fácil para ser entendido, explicado e demonstrado. Para projetos que tem um cronograma seqüencial, é um modelo de ciclo de vida eficiente. Porém quando os riscos do projeto são altos o suficiente para requerer mais flexibilidade no cronograma o modelo cascata é desfavorável quando comparado com outros modelos de ciclo de vida mais sofisticados [1]. No modelo cascata, o projeto é planejado em uma seqüência de fases (Figura 2). Cada fase é definida em termos de entradas, saídas e 19
tarefas. No final de cada fase, a fase é revista em uma reunião que deve ser conduzida para verificar quais tarefas foram executadas, e que saídas estão prontas para a próxima fase [1]. É aconselhado o uso do modelo de ciclo de vida cascata nas seguintes ocasiões [3]: O contrato de trabalho está completo, correto e não-ambíguo. Os requisitos e critérios de aceitação são completos, corretos e não ambíguos. O trabalho pode ser completado sem restrições. Mudanças nos requisitos ou projeto não acontecerão a necessidade do cliente é estática. O problema e solução são bem entendidos e claramente definidos. Não serão cometidos erros durante a identificação de requisitos ou planejamento do projeto. Figura 2 Modelo de Ciclo de Vida em Cascata Fonte: [1] 2.3.4.2 Modelos de Ciclo de Vida Incremental, Iterativo e Espiral [3] Existem vários modelos de ciclo de vida das famílias incrementais e iterativas que foram desenvolvidos nos anos 80, para progressivamente resolver os problemas do 20
modelo cascata. Isto inclui incrementos em mini-cascatas, modelos iterativos e espirais e modelos evolucionários. Ciclo de Vida Incremental [3] O modelo de ciclo de vida incremental é similar ao modelo cascata, porém o trabalho é agrupado em pequenos ciclos seqüenciais, e cada ciclo segue o modelo cascata conforme Figura 3. Esse modelo é eficiente quando o conjunto de requisitos do projeto tem alto risco de sofrer mudanças, assim se os requisitos tiverem de ser modificados o orçamento ficaria menos comprometido do que se tivesse sido utilizado um modelo seqüencial. [19] Figura 3 - Modelo de Ciclo de Vida Incremental - Fonte: [1] 21
Ciclo de Vida Iterativo No modelo iterativo (Figura 4), o projeto é dividido em ciclos que são repetidos, permitindo que o trabalho seja revisto e refinado [3]. Dessa forma o software é liberado em forma de uma série de implementações que são gradualmente mais completas, uma vez que as disciplinas de desenvolvimento, entendimento dos requisitos e planejamento da arquitetura são percorridas várias vezes (uma vez a cada iteração). [20] Figura 4: Modelo de Ciclo de Vida Iterativo. Fonte [36] Ciclo de Vida Espiral [1] No modelo de ciclo de vida espiral (Figura 5) são permitidas múltiplas interações entre atividades similares do projeto [1]. O progresso é representado como um espiral iniciando no centro. A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral. Cada setor da espiral corresponde a uma fase do desenvolvimento. No modelo original foram propostas as seguintes quatro fases [21]: Determinação de objetivos, alternativas e restrições: fase onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Avaliação de alternativas identificação e solução de riscos: feita a análise de risco. Desenvolvimento do produto: neste quadrante pode-se considerar o modelo cascata; 22
Avaliação do produto para iniciar um novo ciclo [21] Figura 5 Modelo de Ciclo de Vida em Espiral - Fonte [1] 2.3.4.3 Modelos de Ciclo de Vida Evolucionário O modelo evolucionário (Figura 6) foi desenvolvido para ajudar a quebrar o software em pedaços que podem ser entregues para o cliente o mais cedo possível. Nesse modelo o software é desenvolvido em ciclos do modelo cascata. Nas fases de operação e manutenção ocorre a sobreposição dessas fases com o desenvolvimento da nova fase. [21] 23
Figura 6: Modelo de Ciclo de Vida Espiral. - Fonte: [1] 2.3.4.4 Modelos de Ciclo de Vida V O modelo de ciclo de vida em V descreve revisões nas atividades como um teste antecipado, com objetivo de detectar erros precocemente ao longo do ciclo de desenvolvimento. [3] No modelo de ciclo de vida V existem avaliações, verificações, validações e testes em todas as etapas do processo de desenvolvimento de software, conforme ilustra a figura 7. O trabalho pode ser prosseguido quando todos os produtos de uma fase do projeto se encontrem em conformidade com as exigências de verificação e validação da organização. [22] 24
Figura 7 - Modelo V - Fonte: [3] 2.3.5 Vantagens e Desvantagens dos Modelos de Ciclo de Vida A tabela abaixo apresenta algumas das vantagens de desvantagens dos modelos de ciclo de vida de desenvolvimento de software apresentados anteriormente [3]. Modelo de Ciclo de Vida Cascata Incremental Vantagens Passos bem definidos fazem a gerência do projeto e gestão de recursos mais fáceis. Permite que grandes problemas sejam quebrados em problemas menores para serem entregues a uma equipe. Desvantagens Erros nos requisitos e projeto não são encontrados até a fase de teste, se torna caro para reparar. Não permite mudanças nos requisitos. Não resolve problemas do modelo cascata, a menos que combinado com os modelos de ciclo de vida iterativo, espiral ou evolucionário. 25
Iterativo/Espiral Evolucionário Modelo V Permite mudanças e o cliente é envolvido ao longo do ciclo de vida; Alguns usuários acham fácil de gerenciar o tempo; Permite o refinamento dos planos e idéias; Teste acontece cedo falhas podem ser encontradas mais cedo. Áreas importantes podem ser testadas primeiro; Assim como o modelo de ciclo de vida iterativo e espiral, mais adequado aos marcos, menor tempo entre início e produção, entregas para áreas importantes primeiro. Fácil de gerenciar, de acordo com os critérios da ISO 9000. Teste é contínuo e custo benefício em termos de defeitos encontrados e facilidade para consertar. Tempo para testar e fazer testes de regressão são elevados; Bastante tempo entre o início e produção; Alguns usuários acham que não é tão fácil para gerenciar por estágios; Pode ser difícil controlar custos e tempo; Menos clareza nos marcos do projeto; Assim como os modelos de ciclo de vida iterativo/ espiral, riscos por falhas podem continuar se propagando se os testes forem insuficientes. Necessita de muitos recursos para testar todos os derivados do projeto; No começo o ciclo de vida pode parecer caro e burocrático; Tabela 1 Vantagens de Desvantagens dos Modelos de Ciclo de Vida - Fonte [3] 3 Padrões de Qualidade de Processo de Software Os padrões de qualidade de processo de software mais conhecidos são a ISO/IEC 15504, CMMI e MPS.BR. Foram utilizados como base para o MPS.BR, foco deste trabalho, a ISO/IEC 12207, ISO/IEC 15504 e CMMI como base para sua concepção. 3.1 ISO/IEC 15504 Avaliação do Processo de Software A ISO/IEC 15504 - Standard for Information Technology Software process assessment foi publicada em 2004, com base no projeto SPICE (Software Process Improvement and Capability determination). Essa 1 A ISO/IEC 15504 define um modelo referência de processos considerados essenciais para a engenharia de software no mundo [6]. A ISO/IEC 15504, cuja estrutura pode ser vista na (Figura 9), descreve duas dimensões a serem consideradas para avaliar a evolução e capacidade dos processos, a primeira dimensão define os processos que devem ser 26
avaliados e a segunda dimensão define as escalas utilizadas para medição da capacidade dos processos avaliados [6]. Na primeira dimensão estão os processos: cliente-fornecedor, engenharia, suporte, gestão e organização [6]. Cliente-Fornecedor consiste dos processos que afetam clientes, suporte ao desenvolvimento e transição do software ao cliente. Engenharia - consiste dos processos para especificar, implementar, fazer manutenções no sistema e produzir documentação aos usuários. Suporte consiste dos processos que podem ser empregados por qualquer outro processo ao longo do ciclo de vida do software. Gestão consiste do processo que contêm práticas de natureza genérica, que podem ser usadas por qualquer gestor em qualquer projeto ao longo do ciclo de vida do software. Organização consiste do processo que estabelece as metas do negócio da organização e desenvolvimento dos processos, produtos, recursos e bens que quando usando por projetos, ajudam a organização a atender suas metas. Na segunda dimensão da norma ISO/IEC 15504, estão os critérios para classificar os processos em cada nível [6]: Nível 0 Incompleto: produtos de trabalho e saídas dos processos não são identificados facilmente; Nível 1 Executado: execução pode não ser rigorosamente planejada e executada. Porém indivíduos da organização reconhecem que o processo deve ser executado e existe a aceitação de que o processo é executado e necessário. Existem produtos de trabalhos do processo identificados e declaração de realização do que foi proposto; Nível 2 Gerenciado: execução do acordo especificado nos procedimentos planejada e executada. Produtos de trabalho estão conforme as especificações nas normas e requisitos. A distinção primária do nível 1 Executado é que a execução do processo é planejada e gerenciada e os progressos acontecem de acordo com o processo definido. Nível 3 Estabelecido: processo estabelecido de acordo com um processo padrão definido e eficiente, baseado em boas práticas de 27
engenharia de software. A distinção principal do Nível 2 Gerenciado é que o processo no Nível 3 Estabelecido é planejado e gerenciado usando processos normalizados baseado em boas práticas de engenharia de software Nível 4 Repetível Medições detalhadas de desempenho são coletadas e analisadas. Conduzindo para o entendimento quantitativo da capacidade do processo e melhoria da habilidade de repetição. Desempenho é fortemente gerenciado. A qualidade dos produtos de trabalho é qualitativamente sabida. A principal distinção em relação ao Nível 3 Estabelecido é que o processo é quantitativamente entendido e controlado; Nível 5 Otimizado processo quantitativamente efetivo e metas eficientes para desempenho são estabelecidas, baseadas nas metas de negócio da organização. Contínuo processo de monitoração, metas são estabelecidas para gerar um feedback quantitativo, melhorias são alcançadas através de análises de resultados. Processo otimizado envolve idéias inovadoras, tecnologias e mudanças em processo ineficazes para atingir as metas ou objetivos da organização. A avaliação de acordo com a ISO/IEC 15504 provê um modelo para medição em desenvolvimento de software. Os dados reunidos das avaliações podem ser usados para guiar o processo de melhoria contínua, conduzindo ganhos em produtividade, qualidade de produtos e entregas [6]. Classificação dos processos da ISO/IEC 15504 avaliados em seis níveis, conforme a Figura 8, abaixo: Figure 8: Níveis de Classificação dos Processos ISO/IEC 15504 Fonte: [6] 28
A figura abaixo contém a estrutura da norma ISO/IEC 15504: Figura 9 Estrutura da norma ISO/IEC 15504 - Fonte: ISO/IEC 15504 [9] 3.2 CMMI [10] O CMMI foi criado pelo SEI no ano 2000 e teve a versão 1.1 lançada em 2002. O CMMI foi criado para integrar e evoluir os modelos: SW-CMM - Capability Maturity Model for Software, IPD-CMM Integrated Product Development e CMM SECM EIA 731, System Engineering Capability Model. Além de tornar-se compatível com a norma ISO/IEC 15504 [10]. Os principais objetivos alcançados ao criar o CMMI foram: eliminar inconsistências entre os modelos existentes, implementar melhorias no modelo CMM, estar compatível com a norma ISO/IEC 15504 e contemplar a forma de representação contínua. O CMMI permite duas representações, por estágios e contínua. A representação contínua utiliza os níveis de capacidade para[10] avaliação. A tabela 2 ilustra as duas representações, por estágios e contínua. Pode-se perceber que as duas 29
representações são muito parecidas. As duas contém os mesmos componentes e estes componentes têm a mesma hierarquia e configuração. A diferença principal é que na representação contínua o foco é na capacidade de processo como forma de mensurar o nível de capacidade. Já na representação por estágios o foco é na maturidade da organização, medida por níveis de maturidade [10]. Níveis de capacidade são aplicáveis em organizações em busca de melhoria de processo em Áreas de Processos individuais. Estes níveis são o meio para incrementar a melhoria dos processos correspondendo a uma determinada área de processo [10]. Existem seis níveis de capacidade numerados de 0 a 5. Níveis de Maturidade são aplicáveis a organizações cujo processo de melhoria deve ser alcançado através de múltiplas áreas de processo. Estes níveis são a base para prever os resultados para os próximos projetos da organização [10]. Existem cinco níveis de maturidade, numerado de 1 a 5. A tabela a seguir mostra a comparação dos 6 níveis de capacidade com os 5 níveis de maturidade: Representação Contínua Nível de Capacidade Representação por Estágios Nível de maturidade Nível 0 Incompleto Não aplicável Nível 1 Repetível Inicio Nível 2 Gerenciado Gerenciado Nível 3 Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente Gerenciado Quantitativamente Gerenciado Quantitativamente Nível 5 Otimizado Otimizado Tabela 2 - Comparação entre Níveis de Maturidade e Níveis Capacidade Fonte: [10] Na representação contínua preocupa-se com a seleção de uma área de processo particular para melhoria e o nível de capacidade desejado para aquela área de processo. Neste contexto, se o processo é repetível ou incompleto é importante. Então, o nome incompleto é o ponto de partida para a representação contínua [10]. 30
A representação por estágio é focada na maturidade da organização, se os processos estão repetíveis ou incompletos, esse não é o foco principal. Então, o nome início é o ponto de início da representação por estágios [10]. O nível de capacidade e nível de maturidade provém o caminho para medir o quão bem a organização pode e faz a melhoria dos seus processos. 3.2.1 Abordagem Contínua Nível de Capacidade 0 - Incompleto Um processo incompleto é um processo não repetível ou parcialmente repetível. Um ou mais objetivos específicos das áreas de processo não estão satisfeitos [10]. Nível de capacidade 1 Repetível No nível de capacidade 1 o processo é caracterizado como um processo repetível. O processo repetível é o processo que satisfaz os objetivos específicos da área de processo, isto é, suporta e habilita o trabalho necessário para adquirir capacidades. [10] Nível 2 de capacidade Gerenciado[10] No nível de capacidade 2 o processo é caracterizado como um processo gerenciado. Um processo gerenciado é repetível (nível 1), tem a infra-estrutura básica para suportar o processo, isto é, planejado e executado em acordo com políticas, por trabalhadores competentes e pessoas que tem recursos adequados para produzir saídas controladas. Envolve stakeholders relevantes, é revisado, monitorado e controlado e é avaliado se está aderente aos processos. A disciplina no processo, refletida pelo nível de capacidade 2 ajuda a assegurar que práticas existentes são retidas mesmo durante os momentos de pressão. [10] Nível de capacidade 3 - Definido[10] O nível de capacidade 3 é caracterizado como o processo definido. Um processo definido é gerenciado (nível 2 de capacidade) faz parte da cultura da organização, o conjunto de processos padrão está de acordo com os demais processos da organização, como guias, produtos de trabalho, medições e outros processo de melhoria. [10] A principal diferença entre os níveis de capacidade 2 e 3 é o escopo das normas, descrições de processo e procedimentos. No nível de capacidade 2, a norma, descrição de processo e procedimentos podem ser um pouco diferentes em cada instância específica dos processos. No nível de capacidade 3, os padrões, descrições de processo e procedimentos para o 31
planejamento de projeto estão de acordo com os processos padrão da organização. Outra crítica distinção é que no nível de capacidade 3, processos são tipicamente descritos mais rigorosamente que no nível de capacidade 2. O processo definido deixa mais claros o estados das propostas, entradas, critérios de entrada, atividades, papéis, medições, passos de verificação, saídas, e critérios de saída. No nível de capacidade 3, processos são gerenciados com mais pró- atividade usando um entendimento das inter-relações entre as atividades de processo e detalhadas medições dos processos, produtos de trabalho e seus serviços. [10] Nível de Capacidade 4 Gerenciado Quantitativamente [10] No nível de capacidade 4 o processo é caracterizado como processo gerenciado quantitativamente. Processo gerenciado quantitativamente é definido (nível de capacidade 3) e é controlado usando estatística e outras técnicas quantitativas. Objetivos quantitativos para a qualidade e desempenho do processo são estabelecidos e usados como critério no processo gerenciado. Qualidade e desempenho do processo são entendidos em termos estatísticos e são gerenciados por toda a vida do processo. [10] Nível de Capacidade 5 Otimizado [10] No nível de capacidade 5 o processo é caracterizado como um processo otimizado. Um processo otimizado é gerenciado quantitativamente (nível de capacidade 4) e é melhorado sistematicamente. O foco de um processo otimizado é a melhoria contínua do desempenho do processo através de melhorias incrementais e inovações [10]. 3.3 MPS.BR Melhoria de Processo do Software Brasileiro O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro, está em desenvolvimento desde dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Guia Geral Dentre os objetivos do MPS.BR está o de definir e aprimorar um modelo de melhoria e avaliação do processo de software apropriado ao contexto das micro, pequenas e médias empresas, uma vez que o CMMI, que é o principal modelo de melhoria de software existente, não é o mais adequado em termos de estrutura e custos às empresas deste porte, que são maioria no Brasil. Um outro objetivo do MPS.BR é ser reconhecido nacional e 32
internacionalmente como modelo de melhoria de processos para a indústria de software. O MPS.BR além do processo de melhoria, estabelece o método de avaliação das empresas e processo de aquisição. Foi desenvolvido baseado nas normas ISO/IEC 12207 Processos de Ciclo de Vida de Software, suas emendas 1 e 2, na ISO/IEC 15504 Avaliação de Processo e CMMI. Dessa forma está de acordo com o conteúdo do CMMI-DEV [12]. A equivalência entre os modelos CMMI, representação por estágios e MPS.BR pode ser verificada na tabela abaixo: Comparação entre Níveis de Maturidade CMMI e MPS.BR CMMI MPS.BR 5 A 4 B 3 C -- D -- E 2 F -- G 1 Não é definido Tabela 3 - Comparação entre níveis de maturidade CMMI e níveis de maturidade MPS.BR A documentação do MPS.BR está dividida em três componentes: o Modelo de referência, Método de Avaliação e Modelo de Negócio, que são documentados através de guias, conforme figura abaixo [12]. 33
Figura 10 Estrutura da Documentação do MPS.BR Fonte: Guia Geral MPS.BR [12] 3.3.1 Guias e Documentação MPS.BR No Guia Geral está descrito o Modelo de Referência do MPS.BR. Ou seja, os processos e em função de seus resultados esperados, os níveis de maturidade e capacidades. Esses elementos descrevem a estrutura a ser implementada pela organização que deseja ter seus processos em conformidade com o MPS.BR [12]. O Guia de Aquisição contém as boas práticas para a aquisição de software e serviços correlatos [12]. O Guia de Avaliação contém o método e descrição dos papéis participantes de uma avaliação de maturidade no MPS.BR [12]. O Modelo de Negócios contém as regras para tornar-se uma instituição implementadora do MR-MPS, assim como para tornar-se uma instituição avaliadora. Além disso, contém orientações para organização de grupos de empresas para implementação e avaliação no MPS.BR, chamado de projeto cooperado e informações para obter a certificação de consultores de aquisição e treinamentos. [12] Guias de Implementação: faz parte do conjunto de documentos de apoio ao MPS.BR. Estes guias fornecem orientações para implementar nas organizações os níveis de maturidade descritos no modelo de referência, detalhando os processos contemplados nos respectivos níveis de 34
maturidade e os resultados esperados com a implementação dos processos. Para cada nível de maturidade existe uma guia de implementação. [13] Todos os guias do MPS.BR estão disponíveis no website da Softex: www.softex.br. 3.3.2 Conceitos Importantes no MPS.BR Atributo de processo é uma característica mensurável da capacidade do processo aplicável a qualquer processo [ISO/IEC 15504-1, 2004]. Perfil do processo é um conjunto de pontuação de atributos de processo para um processo avaliado [ISO/IEC 15504-1, 2004]. Resultado esperado do processo é resultado observável do sucesso do alcance do propósito do processo [ISO/IEC 12207:1995/Amd 1:2002]. A capacidade do processo é representada por um conjunto de atributos de processo descritos em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização. No MPS, à medida que a organização evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela organização [12]. No MPS.BR existem cinco atributos de processo. Cada atributo de processo (AP) está detalhado em termos de resultados esperados deste atributo de processo (RAP) [12]. Para o nível G devem ser contemplados dois atributos de processo, o AP 1.1 e AP 2.1. AP 1.1 O processo é executado RAP1. O processo atinge seus resultados definidos. AP 2.1 O processo é gerenciado RAP 2. Existe uma política organizacional estabelecida e mantida para o processo; RAP 3. A execução do processo é planejada; RAP 4 (para o Nível G)7. A execução do processo é monitorada e ajustes são realizados para atender aos planos; RAP 5. Os recursos necessários para a execução do processo são identificados e disponibilizados; 35
RAP 6. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; RAP 7. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto; RAP 8. O estado, atividades e resultados do processo são revistos com os níveis adequados de gerência (incluindo a gerência de alto nível) e problemas pertinentes são tratados. 3.3.3 Níveis de Maturidade no MPS.BR O MPS.BR estabelece sete níveis de maturidade que mostram os patamares da evolução dos processos da organização, caracterizados pelos estágios de implementação de melhorias nos processo da organização[12]. Os níveis de maturidade são os seguintes: A Em otimização Equivalente ao nível 5 CMMI; B Gerenciado Quantitativamente Equivalente ao nível 4 do CMMI; C Definido Equivalente ao nível 3 do CMMI; D Largamente Definido Parcialmente de acordo com o nível 3 do CMMI; E Parcialmente Definido - Parcialmente de acordo com o nível 3 do CMMI; F Gerenciado Equivalente ao nível 2 do CMMI; G Parcialmente Gerenciado - Parcialmente de acordo com o nível 2 do CMMI; A organização obtém determinado nível de maturidade quando atende aos propósitos de todos os resultados esperados nos processos e atributos de processo do respectivo nível de maturidade. A divisão em estágio, baseada no CMMI-SE-SW, tem graduação diferente para possibilitar mais etapas durante a implementação, mais adequado ao contexto das micro, pequenas e médias empresas. Além disso, ter mais níveis possibilita que os resultados de melhorias sejam visualizados mais rapidamente [12]. 3.3.4 Processo Os processos no MPS.BR são descritos em termos de propósito, resultados esperados e informações adicionais. O propósito descreve o objetivo geral a ser atingido durante a execução do processo [12]. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação dos processos em determinado nível. Estes 36
resultados podem ser evidenciados por um artefato produzido ou uma mudança significativa de estado ao se executar o processo [12]. 3.3.5 Estrutura de Processos e Níveis do MPS.BR Nível Processo Atributo de Processo A B C D E Análise de Causas de Problemas e Resolução-ACP Gerência de Projetos GPR (evolução) Gerência de Riscos GRI Desenvolvimento para Reutilização DRU Análise de Decisão e Resolução ADR Gerência de Reutilização GRU (evolução) Verificação VER Validação - VAL Projeto e Construção do Produto PCP Integração do Produto ITP Desenvolvimento de Requisitos DRE Gerência de Projetos GPR (evolução) Gerência de Reutilização GRU Gerência de Recursos Humanos GRH Definição do Processo Organizacional DFP Avaliação e Melhoria do Processo Organizacional AMP AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 AP 4.2, AP 5.1 e AP 5.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 37
Medição MED AP 1.1, AP 2.1 e AP 2.2 F Garantia da Qualidade - GQA Gerência de Configuração GCO G Aquisição AQU Gerência de Requisitos GRE Gerência de Projetos - GPR AP 1.1 e AP 2.1 Tabela 4 - Estrutura de Processos e Níveis do MPS.BR - [MR-MPS.BR] Fonte: [12] Cada processo tem um propósito e seus resultados esperados. No nível G, estão os processos Gerência de Projetos e Gerência de Projetos. Os atributos de processo a serem atendidos nesse nível são o AP 1.1 e AP 2.1 [12], conforme citado anteriormente. O propósito do processo Gerência de Projetos é: O propósito do processo Gerência de Projetos é identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou serviço, no contexto dos requisitos e restrições do projeto. [12] Guia Geral Os resultados esperados para o Processo de Gerência de Projetos são [12]: GPR 1. O escopo do trabalho para o projeto está definido Espera-se que a organização tenha artefatos que mostrem o trabalho a ser realizado para criar o produto que satisfaça as necessidades especificadas para o projeto. Um exemplo de artefato que atenderia a esse resultado seria a EAP do projeto. GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados Espera-se que a complexidade das tarefas a serem executadas tenha sido estimada através de métodos adequados. GPR 3. O modelo e as fases do ciclo de vida do projeto são definidas 38
Espera-se que a organização tenha adotado um modelo de ciclo de vida para seus projetos de desenvolvimento de software. GPR 4. (Até o nível F). O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas Este resultado espera que a organização estime o esforço para as atividades do projeto baseada em métodos estatísticos adequados e que essas estimativas tenham sido documentadas. GPR 5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos Espera-se que tenha sido estabelecido o orçamento e cronograma para o projeto. Espera-se ainda que o cronograma e orçamento sejam mantidos atualizados ao longo da execução do projeto. GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados Espera-se que os riscos aos quais o projeto está exposto sejam identificados, e que o impacto, probabilidade de ocorrência e prioridade no tratamento tenham sido documentados e monitorados ao longo do projeto. GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo Esperam-se nesse resultado artefatos que mostrem que os recursos humanos que executarão as atividades do projeto tenham sido escolhidos baseados no perfil e conhecimentos necessários para executar a atividade do projeto. GPR 8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados. Nesse resultado são esperados artefatos que mostrem que a infra-estrutura necessária 39
para executar cada atividade do projeto tenha sido planejada e disponibilizada ao longo do projeto. GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança Nesse resultado esperam-se artefatos que mostrem que os dados do projeto sejam gerenciados ao longo da execução dos projetos. GPR 10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto Nesse resultado esperam-se artefatos que mostrem o planejamento da execução do projeto, por exemplo, um plano de projeto que relacione as informações deste entre si. GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados Nesse resultado esperam-se artefatos que mostrem que a viabilidade para atingir as metas do projeto tenha sido avaliada. GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido Nesse resultado espera-se que todos os envolvidos com a execução do projeto conheçam e se comprometam com o Plano de Projeto. GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados Nesse resultado espera-se que haja um documento que registre as monitorações do projeto, ou seja, se existe um controle entre as diferenças do que foi planejado e o que está sendo realizado no projeto. 40