-
Notifications
You must be signed in to change notification settings - Fork 18
Plano de Gerenciamento da Qualidade
Data | Versão | Descrição | Autor |
---|---|---|---|
27/09/2017 | 0.1 | Adicionando Plano de Medição | Álax Alves |
27/09/2017 | 0.2 | Consertando Links | Lucas Martins |
27/09/2017 | 1.0 | Revisando o Documento | Lucas Martins |
- GQM - Goal Question Metric
- GPP - Gestão de Portfólios e Projetos de Software
- MDS - Métodos de Desenvolvimento de Software
- RUP - Rational Unified Process
- XP - eXtreme Programming
Esta wiki descreve o trabalho desenvolvido durante a disciplina de Medição e Análise no curso de Engenharia de Software que tem o intuito de explicitar a importância da área de qualidade e possibilitar, dentro da disciplina, o contato com a prática, além da teoria na Medição. Para aplicar as medições, foi selecionado um projeto de software em desenvolvimento nas disciplinas GPP e MDS, Falko.
O projeto a ser analisado propõe a implementação de um sistema para automatizar atividades dentro da área de gestão de projetos de software, permitindo a centralização de artefatos gerados para gerência e facilitando a análise e tomada de decisões dentro de projetos. O desenvolvimento do Falko foi dividido em duas releases, até a primeira a metodologia utilizada é uma abordagem tradicional adaptada do RUP. Após essa primeira parte, utilizarão métodos ágeis do Scrum e XP.
O projeto de medição será implementado durante a segunda parte, na utilização da metodologia ágil, com o intuito de assegurar que os integrantes de GPP e MDS consigam entregar artefatos de qualidade coerentes com o que é proposto pelas respectivas disciplinas.
Durante as disciplinas de GPP e MDS o time de gerenciamento é responsável por diversas áreas:
- Gerenciamento de Aquisições;
- Gerenciamento de Custos;
- Gerenciamento de Comunicação;
- Gerenciamento de Configuração de Software;
- Gerenciamento de Escopo;
- Gerenciamento de Qualidade;
- Gerenciamento de Recursos Humanos;
- Gerenciamento de Requisitos;
- Gerenciamento de Riscos;
- Gerenciamento de Tempo.
Com o intuito de descentralizar a responsabilidade e conseguir trazer um foco maior na qualidade, propõe-se este projeto que ocorrerá em paralelo, para selecionar métricas, realizar medições e analisar resultados, recomendando ao grupo das outras disciplinas ações para gerenciamento de qualidade do seu projeto.
O método utilizado para o desenvolvimento deste trabalho é o Goal Question Metric (GQM) que possibilita a utilização de métricas orientadas a objetivo, assim permitindo a coleta de métricas apenas para fins claramente explicitados (Van Solingen, 1999, p. 21-22). Este é dividido em quatro fases: planejamento, definição, coleta de dados e análise de dados. Na disciplina, o trabalho ficou dividido em duas entregas, na primeira, serão focadas as fases de planejamento e definição e na segunda a coleta e análise de dados.
A primeira fase do GQM, a fase de Planejamento, tem como intuito a coleta de informações para formar uma introdução completa e preparar e motivar membros do projeto a realizarem o programa de medição (Van Solingen, 1999, p. 42). O artefato gerado durante esta fase é o plano de projeto, e as atividades realizadas estão descritas na Tabela abaixo.
Atividade | Descrição |
---|---|
Estabelecimento do time GQM | Escolha dos membros do time responsável pelo programa de medição. |
Selecionar área de melhoria | Selecionar uma área de melhoria de produto ou processo. |
Selecionar projeto para aplicação e estabelecer o time do projeto | Selecionar um projeto e um time que estejam dispostos a participar da medição. |
Criar o plano de projeto | Criar uma proposta de medição na qual o programa será baseado. |
Treino e promoção | O time do projeto deve ser orientado quanto à proposta do programa de medição e a metodologia GQM. |
O programa de medição proposto terá como objetivo produzir medições que auxiliem os alunos das disciplinas de GPP e MDS desenvolverem seu projeto com eficiência e qualidade. O projeto a ser trabalhado, Falko, pode ser acompanhado nas seguintes páginas:
O grupo deve atentar-se as seguintes datas:
19/09/2017 - Entrega 1 (E1): Onde serão entregues as realizações das fases de planejamento e definição
28/11/2017 - Entrega 2 (E2): Onde serão entregues as realizações das fases de coleta e análise de dados
Lista de artefatos que devem ser entregues ao longo do projeto, com suas datas de entrega sinalizadas:
- Plano de Projeto (E1)
- Plano GQM (E1)
- Plano de Medição (E1)
- Plano de Análise (E1)
- Base de métricas (E2)
- Folha de Análise (E2)
- Resultados de medição (E2)
Time GQM |
---|
Fabíola Malta Fleury |
Lucas de Araújo Martins |
Matheus Richard Torres Gomes de Melo |
Matheus Vítor Joranhezon |
Thalisson Barreto de Melo Silva |
Nome do Integrante | Disciplina sendo cursada |
---|---|
Aláx de Carvalho Alves | GPP |
Lucas Araújo Martins | GPP |
Matheus de Sousa Bernardo | GPP |
Matheus Richard Torres Gomes de Melo | GPP |
Thalisson Barreto de Melo Silva | GPP |
Adrianne Alves da Silva | MDS |
Daniel Ashton Oda | MDS |
Leonardo dos Santos Silva Barreiros | MDS |
Mateus de Oliveira Barbosa | MDS |
Matheus Roberto Alves da Silva | MDS |
Pedro Kelvin de Castro M Batista | MDS |
Vinícius de Castro Cantuária | MDS |
O processo de desenvolvimento utilizado pelo time de projeto é baseado nos métodos ágeis, sendo uma adaptação do Scrum e do XP.
O desenvolvimento é realizado em sprints, possuindo os eventos: reunião de planejamento da sprint, reunião diária, reunião de revisão da sprint e retrospectiva da sprint. Uma sprint possui o tempo de realização de uma semana e é utilizada para desenvolvimento do incremento (produto) de acordo com as tarefas que foram selecionadas na reunião de planejamento. As reuniões diárias são promovidas para analisar o desenvolvimento e descobrir se há algum impedimento, para que este seja retirado o quanto antes. A revisão e retrospectiva são reuniões de final de sprint para análise do que foi entregue e de como decorreu a sprint. Possui como principais artefatos: backlog do produto, backlog da sprint e o incremento. O backlog do produto e backlog da sprint são a forma de documentar os requisitos (em formato de histórias de usuário) e o incremento é a evolução do produto que é entregue ao final de cada sprint.
Os papéis envolvidos são: time de desenvolvimento, product owner e scrum master. O product owner é responsável por organizar o backlog do produto e priorizar histórias de usuário, contribuindo com a visão do cliente em relação ao processo. O scrum master tem como papel garantir que o scrum esteja sendo aplicado de forma correta, ajudando o time a maximizar sua produtividade. O time de desenvolvimento é responsável pela entrega do produto e deve gerenciar e organizar o seu próprio trabalho (SCHWABWER, 2013).
São também realizados testes de aceitação e testes unitários automatizados e programação em pares, seguindo o proposto pelo XP.
Durante a coleta de dados sobre o time de projeto, foi observado que os integrantes que cursam a disciplina GPP possuem algum conhecimento em medição (já cursaram ou estão cursando a disciplina Medição e Análise) enquanto os integrantes de MDS não possuem conhecimentos sobre medição.
Sendo assim, propõe-se um treino sobre a importância da utilização de métricas no desenvolvimento de software e sobre a metodologia GQM para os integrantes de MDS, antes da realização de outras etapas. Dessa forma, estarão alinhados sobre o projeto de medição e terão mais facilidade em contribuir para ele.
Também será realizada entrevista após o treino inicial, e depois da escolha das métricas, será realizado outro treino para explicá-las, sobre como o time pode contribuir para a coleta e como a analise será importante.
Durante a fase de Definição, são realizadas todas as definições formais do programa de medição. Os principais artefatos gerados durante esta fase é o plano de medição, o plano GQM e o plano de análise (Van Solingen, 1999, p. 49). As atividades exercidas podem ser observadas na tabela a seguir.
Atividade | Descrição |
---|---|
Definir objetivos de medição | Por meio da análise da área de melhoria, selecionar objetivos de medição. |
Conduzir entrevistas GQM | Conduzir entrevista com o time de projeto sobre o programa de medição. |
Definir questões e hipóteses | A partir dos resultados das entrevistas, definir as questões e hipóteses. |
Revisar questões e hipóteses | Revisar as questões e hipóteses estabelecidas. |
Definir métricas | A partir das questões e hipóteses, definir as métricas. |
Produzir plano GQM | Utilizando os objetivos de medição, questões e hipóteses e métricas, construir o plano GQM. |
Produzir plano de medição | Detalhar as métricas estabelecidas no plano de medição. |
Produzir plano de análise | Estabelecer a análise para os resultados das medições. |
Revisar planos | Revisar os três planos construídos (plano GQM, plano de medição e plano de análise). |
- [O1] Objetivo de Medição - Manutenibilidade de código
Analisar | o código |
para o propósito de | melhorar |
com respeito a | manutenibilidade |
sob o ponto de vista | dos desenvolvedores |
no contexto | do projeto Falko (GPP/MDS) |
- [O2] Objetivo de Medição - Gerenciamento de Recursos
Analisar | recursos |
para o propósito de | melhorar |
com respeito a | produtividade |
sob o ponto de vista | dos gerentes de projeto |
no contexto | do projeto Falko (GPP/MDS) |
As entrevistas foram conduzidas focadas nas quatro seções do Abstraction sheet que foi construído após o término das entrevistas de todos os membros do time de projeto.
- Quais são as métricas possíveis para atingir um objetivo(manutenibilidade e gerenciamento de recursos)?
- Das métricas que foram sugeridas, quais seus conhecimentos em relação a elas?
- Quais os fatores (de ambiente) você espera que influenciem as métricas?
- Quais os fatores (de ambiente) você espera que serão influenciados pelas métricas?
- Quais tipos de dependências entre as métricas e fatores de influência serão assumidos?
Após definidos os objetivos, elaborou-se questões derivadas do contexto e necessidades da equipe.
-
O1Q1: Qual é a porcentagem de cobertura de testes?
- Tem como objetivo equalizar a quantidade de testes feitos, de maneira a mostrar ao cliente que o código está realizando aquilo que deve.
-
O1Q2: O código está seguindo boas práticas de programação?
- Tem como objetivo garantir que o código seja escrito de maneira legível, assim como verificação da lógica de programação.
-
O1Q3: O código é complexo?
- Tem como objetivo verificar a dificuldade em se modificar o código.
-
O2Q1: O conhecimento do time está nivelado?
- Tem o objetivo de verificar a discrepância de conhecimento entre os membros do time.
-
O2Q2: O time está seguindo o planejamento da sprint estabelecido?
- Tem o objetivo de averiguar se o time está cumprindo os prazos estabelecidos para suas entregas.
-
O2Q3: Quão produtiva é a equipe?
- Tem o objetivo de verificar se o trabalho está sendo feito de forma contínua, ou apenas em espaços curtos próximos ao fim do prazo.
Objetivo | Questão | Métricas |
---|---|---|
Manutenibilidade de código | Qual é a porcentagem da cobertura de testes? | Número de linhas testadas divididas pelo número de linhas de código. |
O código está seguindo boas práticas de programação? | Número de erros com a folha de estilo. | |
Duplicação de código. | ||
Número de linhas por método. | ||
O código é complexo? | Churn vs Complexidade. | |
Duplicação de código. |
Objetivo | Questão | Métricas |
---|---|---|
Gerenciamento de Recursos | O conhecimento do time está nivelado? | Diferença entre níveis dos membros no quadro de conhecimento. |
O time está seguindo o planejamento da sprint? | Burndown da Sprint. | |
Quão produtiva é a equipe? | Velocity. | |
Burndown da Sprint. | ||
Earned value management (EVM). |
Métrica | Porcentagem de código testado |
---|---|
Objetivo de Medição | Garantir a qualidade e a manutenibilidade do código fonte. |
Descrição | Calcula a razão entre as linhas de código testadas e as linhas totais do software. |
Fórmula | C = Lts/Ltt, Onde Lts representa as linhas de código testadas, e Ltt representa as linhas totais. Esta razão resulta em C, que representa a cobertura total de testes. |
Escala | Racional |
Coleta | Responsável: Fabíola. Periodicidade do Evento: Ao final de cada sprint. Ferramenta: simplecov. |
Procedimento | Submissão do código fonte à ferramenta de análise de cobertura de testes. |
Análise | Release 1: O valor da cobertura total de testes deve ser maior ou igual a 0.3. Release 2: O valor da cobertura total de testes deve ser maior ou igual a 0.9. |
Providência | Caso a cobertura total de testes não satisfaça o intervalo determinado, serão necessários esforços de refatoração e elaboração de testes. |
Métrica | Duplicação de Código |
---|---|
Objetivo de Medição | Garantir a manutenibilidade do código fonte. |
Descrição | É a verificação da presença de código duplicado ao longo do código fonte. |
Fórmula | A ferramenta calcula a duplicação de código por meio de AST’s (abstract syntax trees) que possui nós, cada um com um tipo e um conjunto de valores. Ao calcular a duplicação, todos os nós são comparados. Nós com o mesmo tipo, mas valores diferentes, são considerados “similares”, já os nós que possuem o mesmo tipo e os mesmos valores são considerados “duplicados”. |
Escala | Racional |
Coleta | Matheus Joranhezon Periodicidade do Evento: Ao final de cada sprint. Ferramenta: rubocop (codeclimate) |
Procedimento | Submissão do código fonte à ferramenta de análise de duplicação de código. |
Análise | A duplicação de código implica em uma menor manutenibilidade [3], portanto duplicações e similaridades devem ser eliminadas, exceto em casos onde sejam estritamente necessárias. |
Providência | Deve se aplicar esforços de refatoração nas duplicações e similaridades identificadas. |
Métrica | Número de Linhas por Método |
---|---|
Objetivo de Medição | Garantir a manutenibilidade do código fonte. |
Descrição | Consiste no número de linhas de código presente em um determinado método do código fonte. |
Fórmula | Contagem de todas as linhas de código presentes em um dado método. |
Escala | Absoluta |
Coleta | Responsável: Matheus Richard. Periodicidade do Evento: Ao final de cada sprint. Ferramenta: codeclimate |
Procedimento | Submissão do código fonte à ferramenta de análise de tamanho dos métodos. |
Análise | A análise do número de linhas por método irá tomar como base os intervalos padrão da ferramenta, os quais indicam que este valor deve ser inferior ou igual a 30 [4]. |
Providência | Deve se aplicar esforços de refatoração nos métodos identificados, dividindo-os em métodos menores. |
Métricas | Complexidade Ciclomática |
---|---|
Objetivo de Medição | Garantir a manutenibilidade e a legibilidade do código fonte. |
Descrição | É a contagem dos caminhos linearmente independentes ao longo do código fonte, ou seja, o número de decisões que um determinado bloco de código deve realizar [1]. |
Fórmula | CC = A-N+2 Onde CC representa a Complexidade Ciclomática, e é calculado com base em um grafo de fluxo, onde A representa o número de arestas e N o número de nós. |
Escala | Racional |
Coleta | Responsável: Lucas Martins. Periodicidade do Evento: Ao final de cada sprint. Ferramenta: rubocop (codeclimate) |
Procedimento | Submissão do código fonte à ferramenta de análise de complexidade ciclomática. |
Análise | A análise da complexidade ciclomática irá tomar como base os intervalos padrão da ferramenta, os quais indicam que este valor deve ser inferior ou igual a 6 [4]. |
Providência | Caso a complexidade ciclomática ultrapasse os valores aceitáveis, serão alocados esforços de refatoração dos blocos de código indicados como demasiadamente complexos. |
Métrica | Churn |
---|---|
Objetivo de Medição | Garantir a manutenibilidade do código fonte. |
Descrição | É a contagem das alterações feitas em cada um dos arquivos do projeto. |
Fórmula | Cada arquivo possuirá sua contagem de número de alterações de acordo com os commits. |
Escala | Absoluta |
Coleta | Matheus Joranhezon Periodicidade do Evento: Ao final de cada sprint. Ferramenta: codeclimate |
Procedimento | Submissão do código fonte à ferramenta de análise de churn. |
Análise | A análise do churn dará-se juntamente com a análise da complexidade, por meio de gráfico, que sinaliza tanto a complexidade quanto o acesso por arquivo. |
Providência | Dependendo do quadrante que o arquivo se apresente no gráfico, recomenda-se sua refatoração. |
Métrica | Número de erros com a folha de estilo |
---|---|
Objetivo de Medição | Garantir a manutenibilidade do código fonte. |
Descrição | Consiste no número de descumprimentos que o código apresenta em relação à folha de estilo. |
Fórmula | Contagem de todos erros presentes no projeto. |
Escala | Absoluta |
Coleta | Fabíola Periodicidade do Evento: Ao final de cada sprint. Ferramenta: rubycop |
Procedimento | Submissão do código fonte à ferramenta de análise estática de lint. |
Análise | A análise do número de erros será: Ideal - nenhum erro; Bom - < 30 erros; Ruim - > 30 e <150; Péssimo - >150; |
Providência | Deve se aplicar esforços de refatoração nos erros indicados. |
Métrica | Diferença entre níveis dos membros no quadro de conhecimento |
---|---|
Objetivo de Medição | Gerenciamento de Recursos. |
Descrição | O quadro de conhecimentos consiste em uma matriz onde cada linha representa um membro da equipe, e cada coluna a uma tecnologia utilizada no projeto. Cada membro atribui um dos valores, presentes em uma escala predefinida, a cada tecnologia em sua respectiva célula. Ao longo do tempo são elaboradas diferentes versões deste quadro, indicando o estado do conhecimento da equipe ao longo do tempo. |
Fórmula | - |
Escala | Ordinal |
Coleta | Responsável: Thalisson Barreto. Periodicidade do Evento: Ao final de cada sprint. |
Procedimento | No início do projeto e ao final de cada sprint uma nova versão do quadro de conhecimentos é gerada, e nela os membros da equipe indicam qual é o seu nível de conhecimento sobre cada uma das tecnologias presentes no quadro. |
Análise | A análise é feita com base na escala a seguir: Ótimo: Indica que o membro da equipe domina aquela tecnologia em questão. Bom: Indica que o membro da equipe possui um conhecimento elevado sobre a tecnologia em questão. Regular: Indica que o membro da equipe possui um conhecimento médio sobre a tecnologia em questão. Ruim: Indica que o membro da equipe possui pouco conhecimento sobre a tecnologia em questão. Péssimo: Indica que o membro da equipe não possui qualquer conhecimento sobre a tecnologia em questão. Esta escala permite visualizar sobre quais tecnologias os membros da equipe possuem mais conhecimento, e sobre quais eles possuem menos conhecimento. Além disso, pode-se analisar o nível de alinhamento do conhecimento da equipe. |
Providência | O quadro de conhecimentos proporciona várias possibilidades de providência: - Caso o nível de conhecimento da equipe esteja alto, tarefas mais complexas podem ser alocadas em um menor período de tempo. - Caso o nível de conhecimento da equipe esteja baixo, tarefas mais simples devem ser alocadas. - Caso o nível de conhecimento da equipe esteja baixo, um maior tempo deve ser disponibilizado para a equipe realizar determinadas tarefas. - Caso o nível de conhecimento da equipe esteja baixo, treinamentos devem ser realizados para que o conhecimento da equipe seja aprimorado. - Caso o conhecimento da equipe esteja desnivelado, práticas como pareamentos podem ser implantadas para incentivar a propagação do conhecimento. |
Métrica | Earned value management (EVM) |
---|---|
Objetivo de Medição | Gerenciamento de Recursos. |
Descrição | A métrica em questão é uma técnica para medir performance e progresso do projeto, combinando custos, escopo e tempo. |
Fórmula | É expressado em um gráfico com os eixos do tempo x custo. São traçadas três retas: custo real, valor agregado e valor planejado. |
Escala | Racional |
Coleta | Responsável: Time de gerenciamento. Periodicidade do Evento: Ao final de cada sprint. |
Procedimento | O valor deve ser calculado para cada sprint e também para o total do projeto. |
Análise | Esta métrica possibilita visualizar a cada entrega da equipe, se está de acordo com o custo e o tempo planejado para tal. |
Providência | Caso o valor agregado esteja muito abaixo do valor planejado, é sinal de que a equipe está produzindo menos do que o esperado. |
Métrica | Burndown |
---|---|
Objetivo de Medição | Gerenciamento de Recursos |
Descrição | O burndown é um gráfico que representa o trabalho entregue em determinado período de tempo. A partir desse gráfico é possível identificar como está a rotina de trabalho da equipe, assim como sua rapidez para terminar as atividades propostas. |
Fórmula | O burndown utiliza um sistema de pontos que faltam entregar na sprint versus o tempo. A partir dessa medida obtém-se uma reta que indica a progressão de trabalho do time no decorrer da sprint. |
Escala | Racional |
Coleta | Responsável: Matheus Richard. Periodicidade do Evento: Ao final de cada sprint. |
Procedimento | Utilização do gráfico burndown do github. |
Análise | Existem 3 cenários possíveis ao se analisar o burndown. Primeiro, os integrantes da equipe terminam as atividades propostas em um tempo muito menor do que o esperado, o que pode significar falha de gerenciamento ou que os membros da equipe de desenvolvimento foram subestimados. Segundo, o gráfico mantêm-se constante, de maneira que indica que a equipe está seguindo com a metodologia e que houveram boas decisões de gerenciamento. Terceiro, todo o trabalho é queimado em apenas um dia, no fim da sprint, ou até mesmo não é queimado. Isso pode significar que a equipe de desenvolvimento não foi capaz de fazer as atividades por falta de conhecimento, implicando em decisões de gerenciamento falhas, ou que o time de desenvolvimento não está levando o projeto a sério. |
Providência | Primeiro caso: a sprint deverá ser terminada mais cedo do que o esperado, de maneira que ocorra urgentemente o planejamento de outra sprint. Segundo caso: mantém-se a mesma gestão da sprint anterior em relação aos pontos. Terceiro caso: espera-se treinamentos de tecnologias e pareamentos visando a disseminação de conhecimento. Além disso, as histórias para sprint seguinte devem ser mais fáceis que a anterior. |
Métricas | Velocity |
---|---|
Objetivo de Medição | Gerenciamento de Recursos |
Descrição | O velocity é uma estimativa da quantidade de trabalho que uma equipe consegue realizar dentro do período de uma sprint. |
Fórmula | [(SPn+SPn-1)/n]Onde SP é o número de pontos para uma determinada interação e n é a própria interação |
Escala | Racional |
Coleta | Responsável: Thalisson Melo. Periodicidade do Evento: Ao final de cada sprint. |
Procedimento | Verificação dos pontos definidos para a sprint e os pontos realizados pela equipe. |
Análise | Existem 3 cenários possíveis para analisar velocity: - Primeiro caso: A equipe pode realizar todos os pontos determinados para a sprint e nenhum mais, nesse caso o velocity coincide com os pontos realizados pela equipe na sprint. - Segundo caso: A equipe pode realizar todos os pontos determinados para a sprint e pontos a mais, nesse caso os pontos realizados na sprint pela equipe estão acima do velocity. - Terceiro caso: A equipe pode não realizar todos os pontos determinados para a sprint, nesse caso os pontos realizados na sprint pela equipe estão abaixo do velocity. |
Providência | Verificar os pontos definidos para a sprint e os pontos realizados pela equipe. |
[1] https://docs.codeclimate.com/v1.0/docs/cyclomatic-complexity
[2] https://docs.codeclimate.com/v1.0/docs/duplication-concept
[3] MCCONNELL, S. Code Complete http://aroma.vn/web/wp-content/uploads/2016/11/code-complete-2nd-edition-v413hav.pdf
[4] https://docs.codeclimate.com/v1.0/docs/rubocop
[5] SUTHERLAND, Scrum: The art of doing twice the work in half the time
- Folha de Estilo
- Esquema de Cores
- Como Usar o Docker
- O Padrão Adapter
- Links e Comandos Úteis
- O Padrão Observer
- Product Backlog
- Quadro Kanban
- Priorização das Histórias
- Sistema de Pontuação
- EVM Agile
- Roadmap
- Post Mortem - Release II
- Termo de Abertura do Projeto
- Plano de Gerenciamento do Projeto
- Plano de Gerenciamento do Escopo
- Plano de Gerenciamento de Requisitos
- Plano de Gerenciamento de Tempo
- Plano de Gerenciamento das Partes Interessadas
- Plano de Gerenciamento de Comunicação
- Plano de Gerenciamento das Aquisições
- Plano de Gerenciamento de Recursos Humanos
- Plano de Gerenciamento dos Riscos
- Plano de Gerenciamento de Configuração de Software
- Plano de Gerenciamento da Qualidade
- Plano de Gerenciamento dos Custos