Monografia

UNIVERSIDADE FEDERAL DO CEARÁ

CAMPUS QUIXADÁ

BACHARELADO EM SISTEMAS DE INFORMAÇÃO

Francisco Dalker

Francisco Dione

Fernandes Júnior

Sidartha Carvalho

Virgínia Farias

ESTUDO COMPARATIVO DE PRÁTICAS DE GERÊNCIA DE PROJETOS EM MODELOS DE QUALIDADE

Quixadá - Ceará - Brasil

2011

Francisco Dalker

Francisco Dione

Fernandes Júnior

Sidartha Carvalho

Virgínia Farias

ESTUDO COMPARATIVO DE PRÁTICAS DE GERÊNCIA DE PROJETOS EM MODELOS DE QUALIDADE

Pesquisa Cientifica apresentada a disciplina de Qualidade de Software do Curso de Bacharelado em Sistemas de Informação da Universidade Federal do Ceará como requisito parcial para aprovação na disciplina de Qualidade de Software

Orientadora: Professora MS Carla Ilane

Quixadá - Ceará - Brasil

2011

“Uma paixão forte por qualquer objeto assegurará o sucesso, porque o desejo pelo objetivo mostrará os meios.”

William Hazlitt

RESUMO

Este trabalho irá demonstrar as práticas de gerência de projetos e um estudo comparativo dessas práticas com os modelos de qualidade, está dividido em duas partes, que são as práticas de gerência de projetos e suas definições e o estudo comparativo dessas práticas nos modelos de qualidade. Os modelos de qualidade em estudo são: Metodologia Ágil SCRUM, Capability Maturity Model Integration (CMMI), Melhoria de Processos do Software Brasileiro (MPS.Br), Project Management Body of Knowledge (PMBok), dentre essas metodologias e guias iremos selecionar os processos de gerência de projetos, defini-los e compara-los avaliando suas práticas.

http://www.softex.br/mpsbr/

http://www.softex.br/mpsbr/

ABSTRACT

SUMÁRIO

1. INTRODUÇÃO1.1 Objetivo 071.2 Conceitos 071.3 Metodologia 08

2. MODELOS DE QUALIDADE 2.1 Metodologia Ágil SCRUM 082.2 Modelo de Qualidade CMMI 092.3 Modelo de Qualidade MPS.Br xx2.4 Modelo de Qualidade PMBok

3. COMPARAÇÃO CMMI, MPS.BR, PMBok e SCRUM xx4. CONCLUSÃO5. REFERÊNCIAS 27

1. INTRODUÇÃO

1.1 Objetivo

Identificar as práticas de gerência de projetos nas metodologias e guias mais utilizados, que são: CMMI, MPS.Br, PMBok e SCRUM. E realizar uma comparação dessas práticas com os modelos de qualidade.

1.2 Conceitos

Segundo a ABNT (apud SOTILLE, M. A., 2004), na norma técnica NBR 10006, Projeto é “Processo único, consistindo de um grupo de atividades coordenadas e controladas com datas para início e término, empreendido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos.” De acordo com o Project Management Body of Knowledge projeto é “... um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. A sua natureza temporária indica um início e um término definidos. O término é alcançado quando os objetivos tiverem sido atingidos ou quando se concluir que esses objetivos não serão ou não poderão ser atingidos e o projeto for encerrado, ou quando o mesmo não for mais necessário. Temporário não significa necessariamente de curta duração. Além disso, geralmente o termo temporário não se aplica ao produto, serviço ou resultado criado pelo projeto; a maioria dos projetos é realizada para criar um resultado duradouro. Por exemplo, um projeto para a construção de um monumento nacional criará um resultado que deve durar séculos. Os projetos também podem ter impactos sociais, econômicos e ambientais com duração mais longa que a dos próprios projetos.” (PMI, 2009)

Outro conceito muito utilizado no presente trabalho é a metodologia, que vem do Grego meta e logos que significam em tradução livre caminho e estudo respectivamente, ou seja, é o estudo do caminho.

Segundo o PMBok um padrão ou guia é “ um documento formal que descreve normas, métodos, processos e práticas estabelecidas.”(PMI, 2009)

O PMBok também define gerenciamento de projetos como “... a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos. Esta aplicação de conhecimentos requer o gerenciamento eficaz de processos apropriados.”(PMI, 2009).

Segundo Sommerville (SOMMERVILLE, 2009), o gerenciamento da qualidade de software pode ser estruturado da seguinte forma, em três atividades principais que são: Garantia da Qualidade, Planejamento da Qualidade e Controle da Qualidade, a Garantia da Qualidade é o estabelecimento de um framework de procedimentos organizacionais e padrões que conduzem a um software de alta qualidade. O Planejamento da Qualidade é a seleção de procedimentos e padrões apropriados deste framework, adaptados para um projeto de software específico. Já o Controle da Qualidade é a aprovação de processos que assegurem que a equipe de desenvolvimento de software tenha seguido os procedimentos e os padrões de qualidade de projeto.

1.3 Metodologia

Diante do desafio da produção de um artigo que revele as consistências e inconsistências das práticas dos modelos de qualidade CMMI, MPS.Br, PMBok e SCRUM por conta da comparação das suas práticas, comparação essa que é o desafio desse artigo tivemos que buscar meios de solucionar esse desafio.

Utilizamos principalmente os guia PMBok, CMMI e MPS.Br para pesquisas bibliográficas, a Internet como grande meio de colher informações úteis para o trabalho, livros renomados na área de Engenharia de Software e Qualidade de Software.

Primeiramente iremos selecionar todas as práticas dos modelos de qualidade citados acima e escolher as que são referentes a área de gerenciamento de projetos, que é o foco do trabalho, após colhidas as práticas iremos conceitua-las e logo após iremos gerar um mapeamento das áreas de cada modelo de qualidade com os demais.

2. MODELOS DE QUALIDADE

2.1. Metodologia Ágil SCRUM

A metodologia SCRUM assume-se como uma metodologia extremamente ágil e flexível. Tem por objetivo definir um processo de desenvolvimento iterativo e incremental que pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa, proporcionando um excelente entrosamento entre as equipes de desenvolvimento. Com todo esse entrosamento e com a participação ativa dos clientes, o rendimento do projeto aumenta e os requisitos e solicitação de alteração passa a ser entendido mais rapidamente. (BISSI, 2007).

Papéis no SCRUM:

Product Owner: O Product Owner representa os interesses de todos os envolvidos (stakeholders), define as funcionalidades do produto e prioriza os itens de Product Backlog.

Scrum Master: O Scrum Master é o responsável por garantir que o Scrum Team se utiliza os valores e práticas do Scrum. O Scrum Master protege o time certificando-se de que os membros não se comprometam com tarefas além dos que eles conseguem cumprir dentro de uma Sprint. O Scrum Master também facilita o Daily Scrum e se torna o responsável pela remoção de quaisquer obstáculos observados pelo time durante estas reuniões.

Scrum Team: O Scrum Team constrói o produto que o cliente irá utilizar: o software ou o website, por exemplo. O time no Scrum é multifuncional, ele contém todas as especialidades necessárias para entregar o produto potencialmente utilizável a cada Sprint, e é auto-organizável, com um alto grau de autonomia e responsabilidade.

Práticas do SCRUM:

Sprint Planning Meeting: O Product Owner explica as funcionalidades de maior prioridade para o Scrum Team.

Retrospectiva da Sprint: A Retrospectiva do Sprint é uma oportunidade para o Scrum Team discutir o que está dando certo e o que não está, e consentir em ações para mudança.

Reunião de Revisão da Sprint: Ao final de cada Sprint, uma Reunião Sprint Review é realizada. Durante esta reunião, o Scrum Team apresenta o que foi realizado durante o Sprint.

Diário Scrum: Todos os dias do Sprint, o Scrum Team realiza reuniões diárias. Essas reuniões geralmente são realizadas no mesmo local e horário todos os dias.

Estimando o Product Backlog:. Essa informação é fundamental para ajudar o Product Owner a tomar decisões de priorização (alguns itens podem ter sua prioridade diminuida se o Product Owner entender que um esforço maior será requerido para sua entrega).

Priorizando o Backlog: É continuamente, atualizada pelo Product Owner que se baseia no feedback vindo do usuário final (à medida em que são expostos a novos incrementos de produtos) e, também, em resposta às evoluções técnicas e cenários de negócios.

Release Planning: No início de um projeto o time criará um Release Plan em alto nível. Não é possível que o time conheça tudo no início, portanto, um plano detalhado não é necessário.

2.2. Modelo de Qualidade CMMI

Segundo o SEI (Software Engineering Institute) CMMI é definido como “Capability Maturity Model Integration is a process improvement maturity model for the development of products and services. It consists of best practices that address development and maintenance activities that cover the product lifecycle from conception through delivery and maintenance.” (SEI, 2006).

Em uma tradução livre para o português podemos definir o CMMI como um modelo de maturidade e capacidade integrado, é um processo de desenvolvimento de produtos e serviços. Este consiste nas melhores práticas que abordam desenvolvimento e manutenção, atividades que cobrem o ciclo de vida do produto, da concepção até a entrega e manutenção do produto. A versão analisada é a 1.2 para desenvolvimento de software e possui uma divisão em cinco níveis de maturidade que são:

Nível 0 ou Incompleto Nível 1 ou Executado (Definido) Nível 2 ou Gerenciado / Gerido Nível 3 ou Definido Nível 4 ou Quantitativamente gerenciado / Gerido quantitativamente Nível 5 ou Em otimização (ou Optimizado)

E contém as seguintes práticas de gerenciamento de projetos:

Nível 0 e 1 não possuem práticas de gerenciamento de projetos.

No nível 2:

Planejamento de projeto: O objetivo do Planejamento do Projeto é estabelecer e manter planos que definem as atividades do projeto.

Desenvolver o plano do projeto: Um plano de projeto é estabelecido e mantido como base para o gerenciamento do projeto.

Interagir com os stakeholders de forma apropriada: Planejar o envolvimento dos stakeholders identificados.

Obter comprometimento com o plano: Para serem eficazes, os planos exigem compromissos daqueles que são responsáveis pela implementação e suporte do plano.

Monitoramento e Controle: Oferece um entendimento do progresso do projeto, de maneira que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano.

Monitorar os Parâmetros de Planejamento do Projeto: Comparar os valores reais do projeto com os estimados no plano e identificar os desvios significativos.

Monitorar os Compromissos: Através desse monitoramento é possível identificar os compromissos que não foram satisfeitos ou que possuam um risco significativo de não serem satisfeitos e documentar os resultados dessas revisões de compromissos.

Monitorar os Riscos do Projeto: Monitora os riscos em relação àqueles identificados no plano de projeto. É responsável por revisar periodicamente a documentação dos riscos no contexto da situação atual do projeto e outras circunstâncias.

Monitorar o Gerenciamento de Dados: Revisões periódicas das atividades de gestão de dados em relação à sua descrição no plano de projeto, sendo possível

identificar e documentar problemas significativos e seus impactos, gera um documento com o registro dos resultados dessas revisões

Monitorar o Envolvimento de stakeholders: É responsável por gerenciar as comunicações para satisfazer as necessidades das partes interessadas no projeto e resolver problemas com elas.

Conduzir revisões de Progresso: Revisar periodicamente o progresso, o desempenho e os problemas relacionados ao projeto. Essas revisões são realizadas para manter informadas as partes interessadas, podem ser informais e podem não estar previstas nos planos de projeto.

Conduzir Revisões em Marcos: A tarefa consiste na realização de revisões em marcos específicos do projeto para verificação de compromissos, planos, estado e riscos.

No nível 3:

Gestão Integrada de Projeto + IPPD: Estabelece e mantém o processo definido para o projeto que é adaptado a partir do conjunto de processos-padrão da organização. O projeto é gerenciado com base no processo definido para o projeto. O projeto utiliza os ativos de processo da organização e contribui para sua melhoria. O ambiente de trabalho do projeto é estabelecido e mantido com base nos padrões de ambiente de trabalho da organização.

Usar o Processo Definido do Projeto: O projeto é conduzido usando um processo definido que é adaptado a partir do conjunto de processos padrão da organização

Estabelecer o Processo Definido do Projeto: Ajuda a garantir que a equipe do projeto e os Stakeholders implementem um conjunto de atividades necessárias para estabelecer efetivamente um conjunto inicial de requisitos e planos para o projeto.

Usar os Ativos de Processo da Organização para Planejar as Atividades do Projeto: Usar os ativos de processo da organização e o repositório de medições para estimar e planejar as atividades do projeto

Estabelecer o Ambiente de Trabalho do Projeto: Estabelecer e manter o ambiente de trabalho do projeto com base nos padrões de ambiente de trabalho da organização.

Integrar Planos: Integrar o plano do projeto e os outros planos que o afetam para que descrevam o processo definido do projeto, estender as práticas específicas a fim de estabelecer e manter um plano de projeto para endereçar atividades de planejamento adicionais.

Gerenciar o Projeto Usando os Planos Integrados: Gerenciar o projeto usando o plano de projeto, os outros planos que o afetam e o processo definido do projeto.

Contribuir com os Ativos de Processo da Organização: Disponibilizar produtos de trabalho, medidas e experiências documentadas. Esta prática específica endereça a coleta de informações dos processos no processo definido do projeto.

Coordenar e Colaborar com os Stakeholders Relevantes: A coordenação e a colaboração dos Stackeholders relevantes do projeto são conduzidas.

Gerenciar o Envolvimento dos Stackholders Relevantes: Gerenciar o envolvimento dos Stackeholders relevantes no projeto de acordo com o processo definido e integrado do projeto.

Gerenciar Dependências: Participar com os Stackholder relevantes da identificação, negociação e acompanhamento de dependências críticas.

Solucionar Problemas de Coordenação: Solucionar problemas com os stackeholders relevantes.

Aplicar os Princípios de IPPD: criar um ambiente IPPD que permita que as equipes integradas satisfaçam de forma eficiente os requisitos do projeto e produzam um produto de qualidade.

Estabelecer a Visão Compartilhada do Projeto: Compreender as características da organização permite que o projeto alinhe sua direção, atividades e visão compartilhada com a organização e ajuda a criar um propósito comum dentro do qual as atividades de projeto possam ser coordenadas.

Estabelecer a Estrutura de Equipes Integradas: Estabelecer e manter uma estrutura de equipe integrada para o projeto. As exigências do produto, custos do projeto entre outros aspectos, são avaliados para definir as equipes integradas, suas responsabilidades, líderes e relacionamentos

Alocar Requisitos às Equipes Integradas: Alocar requisitos, responsabilidades e tarefas às equipes integradas.

Estabelecer Equipes Integradas: Equipes integradas são estabelecidas pelos patrocinadores, um documento para cada equipe integrada é estabelecido, sendo que este documento contém a alocação dos requisitos do projeto e o fornecimento dos recursos necessários para realizar as tarefas.

Garantir a Colaboração entre Equipes que se Relacionam: assegurar a colaboração entre equipes que possuam alguma conexão entre si, ou seja, equipes que possuem produtos de trabalho em comum.

No Nível 4:

Estabelecer Baselines e Modelos de Desempenho: As baselines e os modelos que caracterizam o desempenho esperado dos processos do conjunto de processos padrão da organização são estabelecidos e mantidos.

Estabelecer os objetivos do projeto: Ao estabelecer os objetivos do projeto é importante avaliar quais processos do conjunto de processos padrão da organização serão incluídos no Processo Definido do Projeto e quais dados históricos poderão estimar o desempenho do processo.

Compor o Processo Definido: Selecionar os subprocessos, que compõem o Processo Definido do Projeto, baseando-se em dados históricos de estabilidade e capacidade.

Selecionar os subprocessos que serão gerenciados estatisticamente: selecionar os subprocessos, do Processo Definido do Projeto, que serão gerenciados estatisticamente.

Gerenciar o desempenho do projeto: Nesta prática específica o projeto é monitorado, para determinar se os objetivos que visam a qualidade e o desempenho do projeto serão satisfeitos, identificando ações corretivas, se necessário.

Gerenciar Estatisticamente o Desempenho de Subprocessos: Quando os subprocessos selecionados são gerenciados estatisticamente, sua

capacidade de atingir seus objetivos pode ser determinada. Assim, é possível prever se será capaz de atingir os seus objetivos.

Selecionar medidas e técnicas analíticas: Selecionar as medidas e as técnicas analíticas que serão usadas para gerenciar os subprocessos.

Aplicar métodos estatísticos para entender a variação: Estabelecer e manter a compreensão das variações dos subprocessos selecionados, utilizando as medidas técnicas analíticas definidas. A variação dos subprocessos é a coleta e análise dos processos e medidas dos produtos

Monitorar o desempenho dos subprocessos selecionados: monitorar o desempenho dos subprocessos selecionados, para determinar se estes conseguirão atingir os objetivos de qualidade e desempenho, e também, identificar a ação corretiva quando necessário.

Gravar dados estatísticos do gerenciamento: Gravar dados do gerenciamento estatístico no repositório de medidas da organização, para posterior utilização nas estimativas do projeto.

2.3. Modelo de Qualidade MPS.Br

2.4. Modelo de Qualidade PMBok

Podemos definir o PMBok como sendo um documento contendo técnicas, métodos e processos relativos a Gerência de Projetos.

Práticas do PMBok referentes a gerência de projetos:

Área de Planejamento:

1. Desenvolver o plano de gerenciamento do projeto.

É o processo de documentação das ações necessárias para definir, integrar e coordenar todos os planos auxiliares. Ele torna-se a fonte principal de informações sobre como o mesmo será planejado, executado, monitorado, controlado e encerrado.

2. Coletar os requisitos

É o processo de definir e documentar as necessidades das partes interessadas para alcançar os objetivos do projeto.

3. Definir o escopo

É o processo de desenvolvimento de uma descrição detalhada do projeto e do produto.

4. Criar a estrutura analítica do projeto (EAP)

É o processo de subdivisão das entregas e do trabalho do projeto em componentes menores e de gerenciamento mais fácil.

5. Definir as atividades

É o processo de identificação das ações específicas a serem realizadas para produzir as entregas do projeto.

6. Sequenciar as atividades

É o processo de identificação e documentação dos relacionamentos entre as atividades do projeto.

7. Estimar os recursos das atividades

É o processo de estimativa dos tipos e quantidades de material, pessoas, equipamentos ou suprimentos que serão necessários para realizar cada atividade.

8. Estimar as durações das atividades

É o processo de estimativa do número de períodos de trabalho que serão necessários para executar atividades específicas com os recursos estimados.

9. Desenvolver o cronograma

É o processo de análise de sequências das atividades, suas durações, recursos necessários e restrições, visando criar o cronograma do projeto.

10. Estimar os custos

É o processo de desenvolvimento de uma estimativa dos recursos monetários necessários para executar as atividades do projeto.

11. Determinar o orçamento

É o processo de agregação dos custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos autorizada.

12. Planejar a qualidade

É o processo de identificação dos requisitos e/ou padrões de qualidade do projeto e do produto, além da documentação de como o projeto atingirá a conformidade.

13. Desenvolver o plano de recursos humanos

É o processo de identificação e documentação de papéis, responsabilidades e habilidades necessárias e relações hierárquicas do projeto, além da criação de um plano de gerenciamento pessoal.

14. Planejar as comunicações

É o processo de determinação das necessidades de informação das partes interessadas no projeto e definição de uma abordagem de comunicação.

15. Planejar o gerenciamento de riscos

É o processo de definição de como conduzir as atividades do gerenciamento de riscos de um projeto.

16. Identificar os riscos

É o processo de determinação dos riscos que podem afetar o projeto e de documentação de suas características.

17. Realizar a análise qualitativa de riscos

É o processo de priorização de riscos para análise ou ação adicional através da avaliação e combinação de sua probabilidade de ocorrência e impacto.

18. Realizar a análise quantitativa de riscos

É o processo de analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto.

19. Planejar respostas aos riscos

É o processo de desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.

20. Planejar as aquisições

É o processo de documentação das decisões de compras do projeto, especificando a abordagem e identificando fornecedores em potencial.

Área de Monitoramento e Controle:

1. Monitorar e controlar o trabalho do projetoÉ o processo de acompanhamento, avaliação e regulação do progresso

para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto. O monitoramento inclui relatórios de status, medições do progresso e previsões.

2. Realizar o controle integrado de mudançasÉ o processo de avaliação de todas as solicitações de mudanças,

aprovação de mudanças e gerenciamento das mesmas em entregas, ativos de processos organizacionais, documentos e plano de gerenciamento do projeto.

3. Verificar o escopoÉ o processo de formalização da aceitação das entregas terminadas do

projeto.

4. Controlar o escopoÉ o processo de monitoramento do andamento do escopo do projeto e do

produto e gerenciamento das mudanças feitas na linha de base do escopo.

5. Controlar o cronogramaÉ o processo de monitoramento do andamento do projeto para

atualização do seu progresso e gerenciamento das mudanças feitas na linha de base do cronograma.

6. Controlar os custosÉ o processo de monitoramento do andamento do projeto para

atualização do seu orçamento e gerenciamento das mudanças feitas na linha de base dos custos.

7. Realizar o controle da qualidadeÉ o processo de monitoramento e registro dos resultados da execução das

atividades de qualidade para avaliar o desempenho e recomendar as mudanças necessárias.

8. Reportar o desempenhoÉ o processo de coleta e distribuição de informações sobre o

desempenho, inclusive relatórios de andamento, medições do progresso e previsões.

9. Monitorar e controlar os riscosÉ o processo de implementação de planos de respostas aos riscos,

acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação de novos riscos e avaliação do processo de risco durante todo o projeto.

10. Administrar as aquisiçõesÉ o processo de gerenciamento dos relacionamentos das aquisições e

monitoramento dos desempenhos dos contratos, fazendo mudanças e correções conforme necessário.

3. COMPARAÇÃO CMMI, MPS.BR, PMBok e SCRUM

PMBok CMMI MPS.Br SCRUMDesenvolver o plano de gerenciamento do projeto.

Planejamento de Projeto;Desenvolver o plano do projeto.

Release Planning.

Coletar os requisitos Não há mapeamento direto.

Estimando o Product Backlog.

Definir o escopo Não há mapeamento direto.

Estimando o Product Backlog.

Criar a estrutura analítica do projeto (EAP)

Não há mapeamento direto.


Definir as atividades Não há mapeamento direto.

Sprint Planning Meeting.

Sequenciar as atividades


Preparação da Sprint.

Estimar os recursos das atividades


Diário Scrum

Estimar as durações das atividades


Sprint Planning Meeting

Desenvolver o cronograma


Release Planning

Estimar os custos Não há mapeamento direto.

Release Planning

Determinar o orçamento


Release Planning

Planejar a qualidade Não há mapeamento direto.

Priorizando o Backlog

Desenvolver o plano de recursos humanos

Estabelecer Equipes Integradas ;Garantir a Colaboração entre Equipes que se Relacionam;Alocar Requisitos às Equipes Integradas.

Estimando o Product Backlog

Planejar as comunicações

Interagir com os stakeholders de forma apropriada;Estabelecer o Ambiente de Trabalho do Projeto;Estabelecer a Visão Compartilhada do Projeto.

Reunião de Revisão da Sprint

Planejar o gerenciamento de riscos

Desenvolver o plano do projeto.

Identificar os riscos Monitorar os Riscos do Projeto.

Diário Scrum

Realizar a análise qualitativa de riscos


Realizar a análise quantitativa de riscos

Conduzir Revisões em Marcos.

Planejar respostas aos riscos

Planejamento de Projeto.

Planejar as aquisições


Monitorar e controlar o trabalho do projeto

Monitorar os Parâmetros de Planejamento do Projeto;Monitorar os Compromissos;Monitorar o Envolvimento de Stakeholders;Conduzir revisões de Progresso.

Reunião de Revisão de Sprint

Realizar o controle integrado de mudanças

Gerenciar o Projeto Usando os Planos Integrados.

Priorizando o Backlog

Verificar o escopo Não há mapeamento direto.


Controlar o escopo Não há mapeamento direto.


Controlar o cronograma

Estabelecer Baselines e Modelos de Desempenho


Controlar os custos Estabelecer Baselines e Modelos de Desempenho

Realizar o controle da qualidade

Gerenciar o desempenho do projeto

Reportar o desempenho

Gerenciar o desempenho do projeto


Monitorar e controlar os riscos

Monitorar os Riscos do Projeto

Administrar as aquisições


4. CONCLUSÃO

5. REFERÊNCIAS

SOTILLE, M. A. Gerenciamento de Projetos na Engenharia de Software. 2004

SOMMERVILLE, Ian. Engenharia de Software 8ª edição. 2009.

Project Management Institute – PMI. Um Guia do Conhecimento em Gerenciamento de Projetos. 2009.

BISSI http://revista.grupointegrado.br/revista/index.php/campodigital/article/download/312/146

SEI. CMMI for Development, Version 1.2. Software Enginnering Institute, Carnegie Mellon University, 2006.

Documents

Monografia