UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA MECÂNICA
COMISSÃO DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Práticas Recomendadas para a
Melhoria da Qualidade com
Base em Modelos de Gestão de
Projetos de Software
Autor: Josiane Banov Russo
Orientador: Dr. Ettore Bresciani Filho
02/04
UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA MECÂNICA
COMISSÃO DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Práticas Recomendadas para a
Melhoria da Qualidade com
Base em Modelos de Gestão de
Projetos de Software
Autor: Josiane Banov Russo
Orientador: Dr. Ettore Bresciani Filho Co-orientador:
Curso: Engenharia Mecânica- Mestrado Profissional Área de Concentração: Gestão da Qualidade Total
Trabalho Final de Mestrado Profissional apresentada à comissão de Pós Graduação da Faculdade de Engenharia Mecânica, como requisito para a obtenção do título de Mestre Profissional em Engenharia Mecânica/ Gestão da Qualidade Total.
Campinas, 2004 S.P . – Brasil
UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA MECÂNICA
COMISSÃO DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Trabalho Final de Mestrado Profissional
Práticas Recomendadas para a
Melhoria da Qualidade com
Base em Modelos de Gestão de
Projetos de Software
Autor: Josiane Banov RussoOrientador: Dr. Ettore Bresciani Filho
Prof. Dr. Ettore Bresciani Filho DEMA/FEM/UNICAMP
____________________________________________________ Prof. Dr. Sergio Tonini Button
DEMA/FEM/UNICAMP
____________________________________________________ Prof. Dr. Waldormiro Pelágio Diniz de C. Loyolla
Campinas, 02 de fevereiro de 2004
Dedicatória:
Para meu marido, pelo incentivo e apoio nos momentos de desafio.
Agradecimentos
Ao Prof. Dr. Ettore Bresciani Filho, pela competência e comprometimento com que orientou a elaboração deste trabalho e pela sua pronta disponibilidade e atenção.
Aos meus colegas de turma, pelos momentos agradáveis que tivemos durante o curso e pelo apoio nos momentos de dificuldades.
“Não há nada que seja maior evidência de insanidade do que fazer a mesma coisa dia após dia e esperar resultados diferentes.” (Albert Einstein)
Resumo
RUSSO, Josiane Banov, Práticas Recomendadas para a Melhoria da Qualidade com Base em Modelos de Gestão de Projetos de Software, Campinas,: Faculdade de Engenharia Mecânica, Universidade Estadual de Campinas, 2003. 87 p. Trabalho Final de Mestrado Profissional.
As atividades relacionadas à gestão dos projetos têm impacto direto sobre o seu sucesso ou fracasso, afetando também a qualidade do resultado final.
Para facilitar o trabalho das organizações na identificação das atividades relevantes à gestão de projetos e na definição de processos padronizados para a realização de tais atividades, são criados modelos, padrões e normas de reconhecimento e utilização mundial.
Entretanto, com o objetivo obter melhores resultados dentro de padrões internacionais, algumas organizações adotam mais de um modelo de gestão de projetos. Tal combinação torna complexo o processo de definição e padronização das atividades, considerando que modelos diferentes podem definir práticas para as mesmas atividades. É o que acontece entre o ‘Corpo’ de Conhecimento em Gestão de Projetos (PMBOK - Project Management Body of Knowledge) e o Modelo de Maturidade da Capacidade (CMM - Capability Maturity Model) pois, dentre as diversas práticas para o desenvolvimento de software descritas pelo segundo, são encontradas práticas de gestão de projetos, objeto do ‘Corpo’ de Conhecimento em Gestão de Projetos.
Sendo assim, o objetivo deste trabalho é realizar estudo comparativo das práticas de gestão de projetos definidas pelo Modelo de Maturidade da Capacidade tendo como base as especificações do ‘Corpo’ de Conhecimento em Gestão de Projetos, com destaque para a busca de níveis de qualidade mais
elevados. Tal estudo tem como foco destacar as práticas que são tratadas por um modelo e
desprezadas pelo outro, além de indicar as diferenças e semelhanças entre práticas descritas por ambos. Desse estudo resultará um conjunto de práticas recomendadas para a gestão de projetos de software.
Palavras Chave
Abstract
RUSSO, Josiane Banov, Recommended Practices to Improve Quality Based on Software Project Management Models, Campinas,: Faculdade de Engenharia Mecânica, Universidade Estadual de Campinas, 2003. 87 p. Trabalho Final de Mestrado Profissional.
The activities related to the project management have direct impact on its success or fail, also affecting the quality of the final result.
In order to facilitate the organizations effort to identify the relevant activities to the project management and to define standardized process to perform those activities, models, standards and certifications, accepted all over the world, are created.
However, as the goal is to obtain best results within international standards, some organizations adopt more than one model of project management. This combination turns the process of defining and standardizing activities more complex, giving that different models can define practices to the same activities. This is what happens between the Project Management Body of Knowledge – PMBOK and the Capability Maturity Model – CMM, seeing that among the various practices for software development described by the last, practices related to project management, Project Management Body of Knowledge object, are found.
Considering that, this production objective is to perform a comparative study between the project management practices defined by Capability Maturity Model taking as base the Project Management Body of Knowledge specifications, emphasizing the search for higher quality levels. This study is focused
indicating the differences and similarities among the practices described by both models. From this study there will be selected a set of practices recommended for software project management.
Key Words
Índice
Lista de Figuras iii
Lista de Tabelas iv Nomenclatura v 1. Introdução 1 1.1. Considerações iniciais 1 1.2. Objetivos do trabalho 2 1.2.1. Objetivos gerais 2 1.2.2. Objetivos específicos 3 1.3. Justificativa do trabalho 3 1.4. Métodos de pesquisa 4 1.5. Organização do trabalho 5
2. Considerações sobre o Modelo ‘Corpo’ de Conhecimento em Gestão de Projetos 6
2.1. Histórico 7
2.2. Aspectos Gerais 7
2.3. Aspectos Específicos 24
2.4. Certificação Profissional 25
3. Considerações sobre o Modelo de Maturidade da Capacidade 27
3.1. Histórico 27
3.4. Avaliação de Maturidade 47
4. Comparação das Características dos Modelos 49
4.1. Características Gerais dos Modelos 49
4.2. Características Específicas 52
4.3. Quadro comparativo 75
5. Práticas Recomendadas para a Gestão de Projetos de Software 78
5.1. Principais dificuldades em projetos de software 78
5.2. Práticas de gestão recomendadas aos projetos de software 80
6. Conclusões e Sugestões para Próximos Trabalhos 86
6.1. Conclusão sobre a comparação dos modelos 86
6.2. Conclusão sobre as práticas de gestão de projetos de software recomendadas 87
6.3. Conclusão sobre a utilização dos modelos 88
6.4. Proposta para Novos Trabalhos 88
Lista de Figuras
1 Áreas de conhecimento e processos da gestão de projetos 9
2 Relação entre os grupos de processos em uma fase do projeto 10
3 Sobreposição dos grupos de processo em uma fase 10
4 Estrutura do Modelo de Maturidade da Capacidade 30
5 A Gestão da Qualidade Total e o Modelo de Maturidade da Capacidade 46
6 Exemplo de ciclo de vida genérico descrito pelo PMBOK 55
Lista de Tabelas
1 Os níveis de maturidade do Modelo de Maturidade da Capacidade 29
2 Relação entre o PMBOK e o nível 2 do CMM 50
3 Classificação das áreas chave do CMM 51
4 Classificação das áreas de conhecimento do PMBOK 52
Nomenclatura
Abreviações
EUA – Estados Unidos da América
Siglas
ABNT – Associação Brasileira de Normas Técnicas
CAF – Estrutura de Avaliação CMM (CMM Appraisal Framework)
CAPM – Associado Certificado em Gestão de Projetos (Certified Associate in Project Management) CBA IPI – Avaliação Baseada no CMM para Melhoria Interna de Processo (CMM-Based Appraisal
for Internal Process Improvement)
CMM – Modelo de Maturidade da Capacidade (Capability Maturity Model)
ISO - Organização Internacional para a Padronização ( International Organization for Standardization) PDCA – Planejar-Executar-Verificar-Agir (Plan-Do-Check-Act)
PMBOK – ‘Corpo’ de Conhecimento em Gestão de Projetos (Project Management Body of Kowledge)
PMI – Instituto de Gestão de Projetos (Project Management Institute) PMJ – Jornal da Gestão de Projetos (Project Management Journal)
PMP – Profissional de Gestão de Projetos (Project Management Professional) PMQ – Periódico Trimestral de Gestão de Projetos (Project Management Quarterly) SCE – Avaliação da Capacidade de Software (Software Capability Evaluation) SEI – Instituto de Engenharia de Software (Software Engineering Institute)
SPICE – Determinação da Melhoria e Capacidade do Processo de Software (Software Process Improvement and Capability dEtermination):
SWEBOK – ‘Corpo’ de Conhecimento em Engenharia de Software (Software Engineering Book of Knowledge)
Capítulo 1
Introdução
1.1. Considerações iniciais
Segundo a NBR ISO 10006:2000 (2000, p.3), projeto é um “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”. Sendo assim, para que um projeto seja concluído com sucesso, é necessário que a realização das atividades, o tempo, o custo e os recursos sejam gerenciados ao longo do seu desenvolvimento, de forma a garantir a qualidade processo do projeto e a qualidade do produto do projeto.
Para tanto, a identificação das atividades relevantes para a gestão dos projetos e a definição de processos padronizados para a realização de tais atividades facilitam o trabalho dos responsáveis por garantir a execução do projeto dentro do prazo, custo e recursos definidos.
Visando auxiliar as organizações nesta complexa missão, são criados modelos, padrões e normas de reconhecimento e utilização mundial, os quais identificam e descrevem atividades e práticas para a realização de determinadas tarefas.
Alguns desses modelos, padrões e certificações são inteiramente direcionados na identificação, definição e padronização de atividades relacionadas a tarefas específicas, como a gestão de projetos. Dentro deste conjunto temos o ‘Corpo’ de Conhecimento em Gestão de Projetos (PMBOK – Project
Management Body of Knowledge), que agrupa as atividades de gestão de projetos em áreas de conhecimento.
Outros modelos, padrões e certificações descrevem práticas para atividades relacionadas a diversas tarefas, as quais devem ser realizadas para atingir um objetivo comum. É o caso do Modelo de Maturidade da Capacidade (CMM – Capability Maturity Model), o qual descreve em cinco níveis de maturidade as atividades a serem realizadas durante o desenvolvimento de um projeto de software. Dentre as práticas descritas pelo Modelo de Maturidade da Capacidade são encontradas as relacionadas com atividades de gestão de projetos.
Entretanto, com o objetivo de obter melhores resultados dentro de padrões internacionais, algumas organizações adotam mais de um modelo de gestão de projetos para a padronização de processos e realização de atividades. Essa combinação torna tal tarefa ainda mais complexa, tendo em vista que modelos diferentes podem definir práticas para as mesmas atividades. Esta situação é verificada em organizações que desejam implementar as práticas descritas no Modelo de Maturidade da Capacidade em conjunto com as especificações do ‘Corpo’ de Conhecimento em Gestão de Projetos.
Sendo assim, são apresentados neste trabalho o Modelo de Maturidade da Capacidade e ‘Corpo’ de Conhecimento em Gestão de Projetos, além de apresentar estudo comparativo das práticas de gestão de projetos definidas pelos modelos, com destaque para a busca de níveis de qualidade mais elevados. São destacadas as práticas que são tratadas por um modelo e desprezadas pelo outro, e também são identificadas as diferenças e semelhanças entre práticas descritas por ambos. Ao final do trabalho é apresentado um conjunto de práticas recomendadas para a gestão de projetos de software.
1.2. Objetivos do trabalho
1.2.1. Objetivos gerais
Realizar estudo comparativo das práticas de gestão de projetos definidas pelo Modelo de Maturidade da Capacidade tendo como base as especificações descritas no ‘Corpo’ de Conhecimento em Gestão de Projetos, com destaque para a busca de níveis de qualidade mais elevados. Tal estudo
tem como foco comprovar a hipótese de que os modelos são compatíveis e podem ser implementados em conjunto, entretanto não é possível mapear completamente uma área chave do Modelo de Maturidade da Capacidade em apenas uma área de conhecimento do ‘Corpo’ de Conhecimento em Gestão de Projetos. Além disso, é incorreto assumir que, dentre os 5 níveis de maturidade definidos no Modelo de Maturidade da Capacidade, somente o nível 2, cujo enfoque é a descrição de práticas de gestão de projetos, ou o nível 4, por ser denominado o nível em que o processo é gerenciado, possuem todas as práticas de gestão descritas pelo modelo.
Para tanto, são destacadas as práticas que são tratadas por um modelo e desprezadas pelo outro, além de indicar as diferenças entre práticas descritas por ambos e também semelhanças existentes. Desse estudo deve resultar um conjunto de práticas recomendadas para a gestão de projetos de software.
1.2.2. Objetivos específicos
Para alcançar os objetivos gerais propostos, foram estabelecidos alguns objetivos específicos intermediários:
1. Conhecer em detalhes os modelos Modelo de Maturidade da Capacidade e ‘Corpo’ de Conhecimento em Gestão de Projetos, com o objetivo de identificar aspectos gerais e específicos de cada um, por meio de realização de pesquisa em material bibliográfico sobre o assunto.
2. Analisar as práticas de gestão de projetos descritas em cada modelo, visando identificar pontos de concordância e de conflito entre eles.
3. Identificar, com base no estudo e análise entre o Modelo de Maturidade da Capacidade e ‘Corpo’ de Conhecimento em Gestão de Projetos, um conjunto de práticas de gestão recomendadas para projetos de software.
Observando o comportamento de organizações desenvolvedoras de software, foi possível notar a crescente preocupação com a qualidade de seus produtos e serviços, obtida com o estabelecimento e melhoria de seus processos de software. Tal fator ocorre pela necessidade de melhoria percebida pela própria organização, por exigência de clientes ou por questões de sobrevivência no mercado.
Uma das formas das organizações atingirem esse objetivo é por meio da implantação de modelos, padrões e normas da qualidade. Entretanto, quando a organização busca por modelos, padrões e normas a serem implantados, ela percebe que, para atender sua necessidade, pode ser preciso implantar mais de um modelo ou norma.
Ao deparar com tal situação, é fundamental saber se os modelos, padrões ou normas a serem implantados são compatíveis, ou seja, não possuem divergência nas práticas requeridas.
Considerando tal preocupação, foram selecionados dois dos modelos mais utilizados no mercado para apresentar uma forma como essa comparação pode ser realizada.
Outra maneira de estabelecer ou melhorar os processos de software de uma organização é por meio da implantação das melhores práticas dentre as descritas por um ou mais modelos, padrões ou normas. Sendo assim, após a comparação dos modelos selecionados, é possível identificar quais são as práticas de maior importância para implantação em uma organização desenvolvedora de software.
1.4. Métodos de pesquisa
Para a elaboração deste trabalho foi realizado, primeiramente, estudo da bibliografia específica sobre ‘Corpo’ de Conhecimento em Gestão de Projetos e Modelo de Maturidade da Capacidade, incluindo manuais específicos e trabalhos publicados sobre o assunto. Com base neste estudo, foi realizado estudo comparativo das características dos modelos, com destaque para a busca de níveis de qualidade mais elevados. Para tanto, se fez necessário o mapeamento dos modelos no qual, para cada área de conhecimento do ‘Corpo’ de Conhecimento em Gestão de Projetos, serão relacionadas as práticas do Modelo de Maturidade da Capacidade semelhantes ou divergentes. Em seguida, foram identificadas, dentre as práticas de cada modelo, as que não são encontradas no outro modelo.
Tendo o mapeamento finalizado, as práticas relacionadas foram analisadas para, então, ser proposta a recomendação da utilização de um conjunto de práticas a serem adotadas pelas organizações envolvidas com projetos de software.
1.5. Organização do trabalho
No Capítulo 2 são apresentadas as características do ‘Corpo’ de Conhecimento em Gestão de Projetos. Primeiramente é apresentado o histórico do modelo e, em seguida, são apresentadas a descrição geral do modelo e a descrição dos processos principais que o compõem. Também é demonstrada a relação do modelo com a gestão da qualidade total e, por fim, como é o processo de certificação de um profissional.
No Capítulo 3 é apresentado o Modelo de Maturidade da Capacidade, iniciando pela apresentação do histórico de desenvolvimento e aplicação do modelo. Em seguida são apresentados os conceitos de maturidade e as áreas chave de processo. São apresentadas também a relação do modelo com a gestão da qualidade total e a forma de avaliação da maturidade.
No Capítulo 4 é apresentado estudo comparativo entre os modelos, considerando os assuntos tratados por ambos. Além disso é apresentada a confirmação da hipótese.
No Capítulo 5 são recomendadas práticas de gestão de projetos de software para organizações que desejam melhorar seu processo de software sem a implantação de modelos, padrões ou normas. As recomendações são baseadas no estudo comparativo realizado.
No Capítulo 6 são apresentadas as conclusões relativas ao estudo comparativo dos modelos, à aplicação das práticas recomendadas para a gestão de projetos de software e, por fim, conclusões relativas a implantação de ambos os modelos em uma mesma organização. Além disso, no Capítulo 6 são apresentadas propostas para novos trabalhos considerando a implantação de modelos de melhoria de processo de software.
Capítulo 2
Considerações sobre o Modelo ‘Corpo’ de Conhecimento em Gestão de
Projetos
O objetivo deste capítulo é apresentar o ‘Corpo’ de Conhecimento em Gestão de Projetos, fornecendo base para o entendimento do modelo. Inicialmente é apresentado o histórico, para então serem descritas as características, as áreas de conhecimento e os processos principais que as compõem.
É também apresentada a preocupação do modelo com os conceitos de gestão da qualidade total. Por fim, são identificadas as certificações profissionais que o modelo proporciona e o propósito de cada uma.
O ‘Corpo’ de Conhecimento em Gestão de Projetos foi desenvolvido pelo Instituto de Gestão de Projetos (PMI – Project Management Institute) e descreve “a soma de conhecimento para profissão de gestão de projeto” (PMI, 2000, p.3) . O objetivo principal do ‘Corpo’ de Conhecimento em Gestão de Projetos é identificar e descrever o conhecimento e as práticas de gestão aplicáveis à maioria dos projetos, independente de sua natureza. Além disso, o ‘Corpo’ de Conhecimento em Gestão de Projetos provê uma linguagem comum para as atividades de gestão de projetos.
2.1. Histórico
O Instituto de Gestão de Projetos foi fundado em 1969 por cinco voluntários. O estado da Pennsylvania, Estados Unidos, emitiu artigos de incorporação que significaram o início oficial da organização. No mesmo ano, o primeiro Seminário e Simpósio do Instituto de Gestão de Projetos foi realizado em Atlanta, com a participação de 83 pessoas.
Na década de 1970 foi realizada a primeira publicação do Periódico Trimestral de Gestão de Projetos (PMQ – Project Management Quarterly), o qual mais tarde foi chamado de Jornal da Gestão de Projetos (PMJ – Project Management Journal). Foi realizado o primeiro Seminário e Simpósio Anual fora dos Estados Unidos, o primeiro Capítulo do Instituto de Gestão de Projetos foi estabelecido e o Programa de Prêmio do Profissional foi estabelecido. No final da década, os membros do Instituto de Gestão de Projetos totalizavam em 2000 em todo o mundo.
Durante a década de 1980, os membros, programas e serviços do Instituto de Gestão de Projetos continuaram a crescer. Foi adotado um Código de Ética para a profissão e o primeiro exame de certificação de Profissional de Gestão de Projetos (PMP – Project Management Professional) foi realizado. O primeiro padrão de gestão de projetos foi publicado e, devido ao sucesso, deu origem a Divisão de Publicação, estabelecida na Carolina do Norte.
Em 1990, os membros do Instituto de Gestão de Projetos eram mais de 8500 e, em 1993, a taxa anual de crescimento subiu para 20 por cento. Nesta década foi publicado o Guia para o ‘Corpo’ de Conhecimento em Gestão de Projetos.
Hoje, o Instituto de Gestão de Projetos possui mais de 100.000 membros em 125 países, os quais estudam e praticam a gestão de projetos em diferentes áreas da indústria, incluindo aeroespacial, automotiva, negócios, construção, engenharia, finanças, tecnologia da informação, farmacêutica e telecomunicações.
2.2. Aspectos Gerais
O PMBOK divide as práticas de gestão de projetos em processos e os agrupou em 9 áreas de conhecimento, conforme ilustrado na Figura 1.
Figura 1 – Áreas de conhecimento e processos da gestão de projetos (adapatado de PMI, 2000, p.8)
As áreas de conhecimento são divididas em processos principais, para cada qual são apresentadas as Entradas, Ferramentas e Técnicas e as Saídas.
É importante ressaltar que não é necessário que todo o conhecimento e práticas descritos pelo PMBOK sejam aplicados uniformemente em todos os projetos. Sendo assim, deve ser estabelecido um time responsável para determinar o que é apropriado para cada projeto.
O PMBOK estabelece também uma classificação para os processos descritos pelas áreas de conhecimento, sendo estes agrupados em processos de iniciação, processos de planejamento, processos de execução, processos de controle e processos de encerramento, os quais se repetem para cada fase do projeto.
A Figura 2 ilustra a relação entre os grupos de processos para cada fase do projeto.
Gerência da Integração do Projeto Gerência do Custo
do Projeto
Gerência das Comunicações do Projeto
Gerência do Escopo do Projeto Gerência da Qualidade
do Projeto Gerência dos Riscos
do Projeto
Gerência do Tempo do Projeto Gerência dos Recursos
Humanos do Projeto Gerência das Aquisições
do Projeto
Figura 2 – Relação entre os grupos de processos em uma fase do projeto (PMI, 2000, p.31)
Entretanto, os processos de gestão de projetos não são distintos, havendo sobreposições de atividades que ocorrem em intensidades diferentes ao longo de cada fase do projeto, conforme apresentado na Figura 3.
Figura 3 – Sobreposição dos grupos de processo em uma fase (PMI, 2000, p.31) Processos de Iniciação Processos de Planejamento Processos de Controle Processos de Execução Processos de Encerramento (as setas representam o fluxo de
informações) Intensidade da Atividade Início da Fase Fim da Fase Tempo Processos de Iniciação Processos de Planejamento Processos de Controle Processos de Execução Processos de Encerramento
A seguir são descritas as áreas de conhecimento do modelo com o detalhamento dos principais processos, os quais terão identificados os grupo a que pertencem entre parênteses, após o nome. Além disso, serão apresentadas as entradas, ferramentas e saídas relacionadas a cada um.
Gerência da Integração do Projeto
A Gerência da Integração do Projeto envolve os processos necessários para assegurar que os diversos elementos do projeto sejam adequadamente coordenados. Envolve as negociações dos conflitos entre os objetivos e alternativas concorrentes, com a finalidade de atingir ou superar as necessidades e expectativas das partes interessadas.
Principais processos:
1) Desenvolvimento do Plano do Projeto (Planejamento) – integrar e coordenar os resultados dos outros processos de planejamento construindo um documento coerente e consistente. Entradas: outras saídas do planejamento; informações históricas; políticas organizacionais; restrições; premissas.
Ferramentas e Técnicas: metodologia de planejamento de projetos; habilidades e conhecimentos das partes envolvidas; sistema de informação para a gestão de projetos; gestão do valor agregado.
Saídas: plano do projeto; detalhes de suporte.
2) Execução do Plano do Projeto (Execução) – executar o planejamento do projeto por meio da realização das atividades nele incluídas.
Entradas: plano do projeto; detalhes de suporte; políticas organizacionais, ações preventivas; ações corretivas.
Ferramentas e Técnicas: habilidades gerais de gestão; habilidades técnicas e conhecimento do produto; sistema de autorização de trabalho; reuniões de revisão de status; sistema de informação para gestão de projetos; procedimentos organizacionais.
Saídas: resultados do trabalho; requisições de mudanças.
3) Controle Integrado de Mudanças (Controle) – coordenar as mudanças ocorridas em todo o projeto.
Entradas: plano do projeto; relatórios de desempenho; requisições de mudanças.
Ferramentas e Técnicas: sistema de controle de mudanças; gerência de configuração; medidas de desempenho; planejamento adicional; sistema de informação para a gestão de projetos.
Saídas: atualizações no plano do projeto; ações corretivas; lições aprendidas.
Gerência do Escopo do Projeto
A Gerência do Escopo do Projeto envolve os processos necessários para assegurar que o projeto englobe todo o trabalho necessário, e tão somente o trabalho necessário, para que o projeto seja concluído com sucesso. A preocupação fundamental compreende definir e controlar o que está ou o que não está incluído no projeto.
No contexto de projeto, o termo escopo se refere a :
• Escopo do produto – aspectos e funções que caracterizam o produto ou serviço.
• Escopo do projeto – o trabalho que deve ser feito com a finalidade de entregar um produto de acordo com os aspectos e as funções especificados.
A conclusão do escopo do projeto é mensurada considerando o plano do projeto, enquanto a conclusão do escopo do produto é mensurada considerando os requisitos. Ambos os tipos de gerência de escopo devem ser integrados para garantir que o trabalho do projeto resulte na entrega do produto especificado.
Principias processos:
1) Iniciação (Iniciação) – autorizar formalmente o início de um novo projeto ou a continuidade de um projeto existente para a próxima fase.
Entradas: descrição do produto; plano estratégico; critérios de seleção de projetos; informações históricas.
Ferramentas e Técnicas: métodos de seleção de projetos; avaliação especializada.
Saídas: contrato do projeto; gerente do projeto identificado e designado; restrições; premissas.
2) Planejamento do Escopo (Planejamento) – desenvolver uma declaração escrita do escopo como base para decisões futuras do projeto.
Entradas: descrição do produto; contrato do projeto; premissas; restrições.
Ferramentas e Técnicas: análise do produto; análise de custo/benefício; identificação de alternativas; avaliação especializada.
Saídas: declaração de escopo; detalhes de suporte; plano de gerência do escopo.
3) Definição do Escopo (Planejamento) – subdividir os principais produtos do projeto em componentes menores e mais gerenciáveis.
Entradas: declaração do escopo; restrições; premissas; saídas de outros planejamentos; informações históricas.
Ferramentas e Técnicas: modelos de estrutura analítica de trabalho; decomposição. Saídas: estrutura analítica do projeto; atualizações na declaração de escopo.
4) Verificação do Escopo (Controle) – formalizar a aceitação do escopo do projeto.
Entradas: resultados do trabalho; documentação do produto; estrutura analítica de trabalho; declaração do escopo; plano do projeto.
Ferramentas e Técnicas: inspeção. Saídas: aceitação formal.
5) Controle de Mudanças do Escopo (Controle) – controlar as mudanças de escopo do projeto.
Entradas: estrutura analítica de trabalho; relatórios de desempenho; requisições de mudança; plano de gerência do escopo.
Ferramentas e Técnicas: controle de mudanças do escopo; medição de desempenho; planejamento adicional.
Saídas: mudanças do escopo; ações corretivas; lições aprendidas, linha base ajustada.
Gerência do Tempo do Projeto
A Gerência do Tempo do Projeto envolve os processos necessários para assegurar que o projeto será concluído no prazo previsto.
Principais processos:
1) Definição das Atividades (Planejamento) – identificar as atividades específicas que devem ser realizadas para gerar os diversos produtos do projeto.
Entradas: estrutura analítica de trabalho; declaração do escopo; informações históricas; restrições; premissas; avaliação especializada.
Ferramentas e Técnicas: decomposição; modelos.
Saídas: lista de atividades; detalhes de suporte; atualizações na estrutura analítica de trabalho. 2) Seqüenciamento das Atividades (Planejamento) – identificar e documentar as relações de
dependência entre as atividades.
Entradas: lista das atividades; descrição do produto; dependências mandatórias; dependências arbitrárias; dependências externas; marcos.
Ferramentas e Técnicas: método do diagrama de precedência; método do diagrama de flecha; métodos de diagrama condicional; modelos de rede.
Saídas: diagrama de rede do projeto; atualizações da lista de atividades.
3) Estimativa da Duração das Atividades (Planejamento) – estimar a quantidade de períodos de trabalho que serão necessários para a conclusão de cada atividade.
Entradas: lista de atividades; restrições; premissas; recursos requeridos; competência dos recursos; informações históricas, riscos identificados.
Ferramentas e Técnicas: avaliação especializada; estimativas por analogia; durações baseadas quantitativamente; tempo reserva (contingência).
Saídas: estimativas de duração das atividades; bases para a estimativa; atualizações da lista de atividades.
4) Desenvolvimento do Cronograma (Planejamento) – analisar a seqüência e a duração das atividades, além dos recursos requeridos, para criar o cronograma do projeto.
Entradas: diagrama de rede do projeto; estimativas de duração das atividades; recursos requeridos; descrição do quadro de recursos; calendários; restrições; premissas; folgas e flutuações; plano de gerência de riscos; atributos das atividades.
Ferramentas e Técnicas: análise matemática; compreensão da duração; simulação; nivelamento heurístico dos recursos; softwares de gestão de projeto; estrutura de codificação. Saídas: cronograma do projeto; detalhes de suporte; plano de gerência do cronograma; atualização dos recursos requeridos.
5) Controle do Cronograma (Controle) – controlar as mudanças no cronograma do projeto.
Entradas: cronograma do projeto; relatórios de desempenho; requisições de mudança; plano de gerência do cronograma.
Ferramentas e Técnicas: sistema de controle de mudanças do cronograma; mensuração do desempenho; planejamento adicional; software de gestão de projeto; análise de variância. Saídas: atualizações do cronograma; ações corretivas; lições aprendidas.
Gerência do Custo do Projeto
A Gerência do Custo do Projeto envolve os processos necessários para assegurar que o projeto será concluído dentro do orçamento aprovado.
A Gerência do Custo do Projeto consiste, fundamentalmente, nos custos dos recursos necessários à implementação das atividades do projeto. Entretanto, a gerência do custo do projeto deve também considerar os efeitos das decisões do projeto no custo de utilização do produto do projeto. Esta visão mais ampla da gerência do custo do projeto é, freqüentemente, chamada de custo do ciclo de vida.
Principais processos:
1) Planejamento dos Recursos (Planejamento) – determinar quais recursos (pessoas, equipamentos, materiais) e qual quantidade de cada será necessária para realizar as atividades do projeto.
Entradas: estrutura analítica de trabalho; informações históricas; declaração do escopo; descrição do quadro de recursos; políticas organizacionais; estimativas de duração das atividades.
Ferramentas e Técnicas: avaliação especializada; identificação de alternativas; software de gestão de projetos.
Saídas: recursos requeridos.
2) Estimativa dos Custos (Planejamento) – desenvolver a estimativa dos custos dos recursos necessários à implementação das atividades do projeto.
Entradas: estrutura analítica de trabalho; recursos requeridos; custos dos recursos; estimativas da duração das atividades; divulgação das estimativas; informações históricas; plano de contas; riscos.
Ferramentas e Técnicas: estimativas por analogias; modelo paramétrico; estimativas de baixo para cima (Bottom-up); ferramentas computadorizadas; outros métodos de estimativas de custo.
Saídas: estimativas de custo; detalhes de suporte; plano de gerência do custo.
3) Orçamento dos Custos (Planejamento) – alocar as estimativas de custos gerais aos itens individuais de trabalho.
Entradas: estimativas de custo; estrutura analítica de trabalho; cronograma do projeto; plano de gerência de riscos.
Ferramentas e Técnicas: ferramentas e técnicas para a estimativa de custo. Saídas: linha base do custo.
4) Controle dos Custos (Controle) – controlar as mudanças no orçamento do projeto.
Entradas: linha base do custo; relatórios de desempenho; requisições de mudança; plano de gerência do custo.
Ferramentas e Técnicas: sistema de controle de mudança do custo; mensuração de desempenho; gerência do valor agregado; planejamento adicional; ferramentas computadorizadas.
Saídas: estimativas de custo revisadas; atualizações de orçamento; ações corretivas; estimativa na conclusão; lições aprendidas.
Gerência da Qualidade do Projeto
A Gerência da Qualidade do Projeto envolve os processos necessários para garantir que o projeto irá satisfazer as necessidades para as quais ele foi empreendido. Isto inclui todas as atividades de gestão que determinam as políticas de qualidade, objetivos e responsabilidades, além dos meios de implementação tais como o planejamento da qualidade, controle da qualidade, garantia da qualidade e melhoria da qualidade, dentro do sistema de qualidade.
Principais processos:
1) Planejamento da Qualidade (Planejamento) – identificar quais padrões de qualidade são relevantes para o projeto e determinar a forma de satisfazê-los.
Entradas: política da qualidade; declaração do escopo; descrição do produto; padrões e regulamentações; saídas de outros processos.
Ferramentas e Técnicas: análise de custo/benefício; comparação de práticas (benchmarking); fluxograma; projeto de experimentos; custo da qualidade.
Saídas: plano de gerência da qualidade; definições operacionais; listas de verificação; entradas para outros processos.
2) Garantia da Qualidade (Execução) – avaliar periodicamente o desempenho geral do projeto buscando assegurar a satisfação dos padrões relevantes de qualidade.
Entradas: plano de gerência da qualidade; resultados da mensuração do controle da qualidade; definições operacionais.
Ferramentas e Técnicas: ferramentas e técnicas de planejamento da qualidade; auditorias da qualidade.
Saídas: melhoria da qualidade.
3) Controle da Qualidade (Controle) – monitorar os resultados específicos do projeto para determinar se eles estão de acordo com os padrões de qualidade relevantes e identificar as formas para eliminar as causas de desempenhos insatisfatórios.
Entradas: resultados do trabalho; plano de gerência da qualidade; definições operacionais; listas de verificação.
Ferramentas e Técnicas: inspeção; gráficos de controle; diagrama de Pareto; amostragem estatística; fluxograma; análise de tendência.
Saídas: melhoria da qualidade; decisões de aceitação; re-trabalho; listas de verificação preenchidas; ajustes no processo.
Gerência dos Recursos Humanos do Projeto
A Gerência dos Recursos Humanos do Projeto envolve os processos necessários para possibilitar o uso mais efetivo das pessoas envolvidas com o projeto. Isto inclui todos os interessados pelo projeto – patrocinadores, clientes, parceiros, contribuintes individuais e outros.
Principais processos:
1) Planejamento Organizacional (Planejamento) – identificar, documentar e designar as funções, responsabilidades e relacionamentos de comunicações dentro do projeto.
Entradas: interfaces do projeto; requisitos das vagas; restrições.
Ferramentas e Técnicas: modelos; práticas de recursos humanos; teoria organizacional; análise das partes envolvidas.
Saídas: atribuição de funções e responsabilidades; plano de gerência de pessoal; organograma da organização; detalhes de suporte.
2) Montagem da Equipe (Planejamento) – conseguir que os recursos humanos necessários sejam designados e alocados ao projeto.
Entradas: plano de gerência de pessoal; descrição do quadro de pessoal; práticas de recrutamento.
Ferramentas e Técnicas: negociações; alocações prévias; contratação. Saídas: pessoal do projeto designado; relação da equipe do projeto.
3) Desenvolvimento da Equipe (Execução) – desenvolver habilidades individuais e competências de grupo para aumentar o desempenho do projeto.
Entradas: pessoal do projeto; plano do projeto; plano de gerência de pessoal; relatórios de desempenho; retorno externo.
Ferramentas e Técnicas: atividades de formação da equipe; habilidades gerais de gerência; sistemas de reconhecimento e recompensa; arranjo físico da equipe; treinamento.
Gerência das Comunicações do Projeto
A Gerência das Comunicações do Projeto envolve os processos necessários para garantir a geração, a coleta, a disseminação, o armazenamento e a disposição básica das informações do projeto, de maneira apropriada e oportuna. Fornece ligações críticas entre pessoas, idéias e informações que são necessárias para o sucesso do projeto. Todos os envolvidos no projeto devem estar preparados para enviar e receber comunicações e devem entender como as comunicações que eles estão individualmente envolvidos afetam o projeto como um todo.
Principais processos:
1) Planejamento das Comunicações (Planejamento) – determinar as informações e comunicações necessárias para os interessados: quem necessita de qual informação, quando necessitarão dela e como isso será fornecido.
Entradas: comunicações requeridas; tecnologia de comunicações; restrições; premissas. Ferramentas e Técnicas: análise das partes interessadas.
Saídas: plano de gerência de comunicações.
2) Distribuição das Informações (Execução) – disponibilizar a informações necessárias para os interessados do projeto de maneira oportuna.
Entradas: resultados do trabalho; plano de gerência de comunicações; plano do projeto. Ferramentas e Técnicas: habilidades de comunicação; sistemas de recuperação de informação; métodos de distribuição de informação.
Saídas: registros do projeto; relatórios do projeto; apresentações do projeto.
3) Relato de Desempenho (Controle) – coletar e disseminar as informações de desempenho. Inclui relatórios de situação, mensuração de progresso e previsões.
Entradas: plano do projeto; resultados do trabalho; outros registros do projeto.
Ferramentas e Técnicas: revisões de desempenho; análise de variância; análise de tendência; análise do valor agregado; ferramentas e técnicas para a distribuição da informação.
Saídas: relatórios de desempenho; requisições de mudança.
Entradas: documentação da mensuração do desempenho; documentação do produto; outros registros do projeto.
Ferramentas e Técnicas: ferramentas e técnicas de relato de desempenho; relatórios do projeto; apresentações do projeto.
Saídas: acervo do projeto; encerramento do projeto; lições aprendidas.
Gerência dos Riscos do Projeto
A Gerência de Risco do Projeto envolve o processo sistemático de identificar, analisar e reagir aos riscos do projeto. Inclui a maximização da probabilidade e conseqüências dos eventos positivos e minimização da probabilidade e conseqüências de eventos contrários aos objetivos do projeto.
Principais processos:
1) Planejamento da Gerência dos Riscos (Planejamento) – determinar como conduzir e planejar as atividades de gerência dos riscos do projeto.
Entradas: contrato do projeto; políticas organizacionais para gerência de riscos; papéis e responsabilidades definidos; tolerância aos riscos pelos interessados; modelo para o plano organizacional de gerência de riscos; estrutura analítica de trabalho.
Ferramentas e Técnicas: reuniões de planejamento. Saídas: plano de gerência dos riscos.
2) Identificação dos Riscos (Planejamento)– determinar quais os riscos são mais prováveis de afetar o projeto e documentar suas características.
Entradas: plano de gerência dos riscos; saídas do planejamento do projeto; categorias dos riscos; informações históricas.
Ferramentas e Técnicas: revisão da documentação; técnicas de reunião de informações; listas de verificação; análise de premissas; técnicas de diagramação.
Saídas: riscos; eventos potenciais de risco; entradas para outros processos.
3) Análise Qualitativa dos Riscos (Planejamento) – realizar a análise qualitativa dos riscos e das condições para priorizar seus efeitos sobre os objetivos do projeto.
Entradas: plano de gerência dos riscos; riscos identificados; situação do projeto; tipo do projeto; precisão de dados; escalas de probabilidade e impacto; premissas.
Ferramentas e Técnicas: probabilidade e impacto dos riscos; matriz de classificação de probabilidade/impacto do risco; teste das premissas do projeto; categorização da precisão dos dados.
Saídas: categorização geral dos riscos do projeto; listas dos riscos priorizados; lista dos riscos para análise e gerência adicional; tendências nos resultados da análise qualitativa dos riscos. 4) Análise Quantitativa dos Riscos (Planejamento) – mensurar a probabilidade e as
conseqüências dos riscos e estimar as implicações nos objetivos do projeto.
Entradas: plano de gerência dos riscos; riscos identificados; lista dos riscos priorizados; lista dos riscos para análise e gerência adicional; informações históricas; análise especializada; outras saídas do planejamento.
Ferramentas e Técnicas: entrevistas; análise sensitiva; análise de árvore de decisão; simulação.
Saídas: lista priorizada de riscos quantificados; análise probabilística do projeto; probabilidade de atingir os objetivos de tempo e custo; tendências nos resultados da análise quantitativa de riscos.
5) Planejamento de Respostas aos Risco (Planejamento) – desenvolver procedimentos e técnicas para aumentar oportunidades e reduzir ameaças aos objetivos do projeto.
Entradas: plano de gerência dos riscos; listas dos riscos priorizados; categorização dos riscos do projeto; lista priorizada dos riscos quantificados; análise probabilística do projeto; probabilidade de atingir os objetivos de tempo e custo; lista de respostas potenciais; estímulos aos riscos; responsáveis pelos riscos; causas comuns dos riscos; tendências nos resultados das análises qualitativa e quantitativa dos riscos.
Ferramentas e Técnicas: anulação; transferência; mitigação; aceitação.
Saídas: plano de respostas ao risco; riscos residuais; riscos secundários, acordos contratuais; valor de reserva necessário para contingência; entradas para outros processos; entradas para
6) Monitoramento e Controle dos Riscos (Controle) – monitorar riscos residuais, identificar novos riscos, executar planos de redução de riscos e avaliar os efeitos durante o ciclo de vida do projeto.
Entradas: plano de gerência de riscos; plano de resposta aos riscos; comunicações do projeto; identificação e análise de riscos adicionais; alterações de escopo.
Ferramentas e Técnicas: auditorias de respostas a riscos do projeto; revisões periódicas dos riscos do projeto; análise do valor agregado; mensuração do desempenho técnico; plano de resposta aos riscos adicionais.
Saídas: planos de evolução; ações corretivas; requisições de mudança do projeto; atualizações no plano de resposta aos riscos; banco de dados de riscos; atualizações nas listas de verificação para identificação de riscos.
Gerência das Aquisições do Projeto
A Gerência de Aquisições do Projeto envolve os processos necessários à obtenção de bens e serviços externos à organização executora.
Principais processos:
1) Planejamento das Aquisições (Planejamento) – determinar o que contratar e quando. Entradas: declaração do escopo; descrição do produto; recursos para aquisição; condições de mercado; saídas de outros planejamentos; restrições; premissas.
Ferramentas e Técnicas: análise entre fazer ou comprar; avaliação especializada; seleção do tipo de contrato.
Saídas: plano de gerência das aquisições; declaração de trabalho.
2) Planejamento da Solicitação (Planejamento) – documentar os requisitos do produto e identificar os fornecedores potenciais.
Entradas: plano de gerência das aquisições; declaração de trabalho; saídas de outros planejamentos.
Saídas: documentos de aquisição; critérios de avaliação; atualizações na declaração de trabalho.
3) Solicitação (Execução) – obter propostas de fornecimento conforme apropriado (cotações de preço, cartas-convite, licitação).
Entradas: documentos de aquisição; lista de fornecedores qualificados. Ferramentas e Técnicas: reuniões de licitação; anúncios.
Saídas: propostas.
4) Seleção de Fornecedores (Execução) – escolher entre os possíveis fornecedores. Entradas: propostas; critérios de avaliação; políticas organizacionais.
Ferramentas e Técnicas: negociação contratual; sistemas de ponderação; sistema de classificação; estimativas independentes.
Saídas: contrato.
5) Administração dos Contratos (Execução) – gerenciar o relacionamento com os fornecedores.
Entradas: contrato; resultados do trabalho; requisições de mudanças; faturas dos fornecedores.
Ferramentas e Técnicas: sistema de controle de mudanças contratuais; relatório de desempenho; sistema de pagamento.
Saídas: correspondências; mudanças contratuais; requisições de pagamento.
6) Encerramento do Contrato (Encerramento) – completar e liquidar o contrato incluindo a resolução de qualquer item pendente.
Entradas: documentação do contrato.
Ferramentas e Técnicas: auditorias de aquisição.
Saídas: arquivamento do contrato; aceitação e fechamento formais.
2.3. Aspectos Específicos
De acordo com o Guia para o ‘Corpo’ de Conhecimento em Gestão de Projetos (PMI, 2000, p.30), o conhecimento básico descrito na área de conhecimento Gerência da Qualidade do Projeto
pretende ser compatível com a Organização Internacional para a Padronização (ISO – International Organization for Standardization), conforme detalhado nas séries de padrões e guias ISO 9000 e 10.000. Esse conhecimento descrito é também compatível com os princípios da gestão da qualidade tais como aquelas recomendadas por Deming, Juran, Crosby, entre outros, e também com princípios como a Gestão da Qualidade Total (TQM – Total Quality Management), Melhoria Contínua e outros.
A gerência da qualidade do projeto deve ser direcionada tanto para a gestão do projeto quanto para o produto do projeto. O fracasso em se atingir os requisitos de qualidade em qualquer das dimensões, pode trazer conseqüências negativas sérias para uma ou até mesmo para todas as partes envolvidas do projeto.
Para o PMBOK, deve ser reconhecida a importância da satisfação do cliente, prevenção sobre a inspeção, responsabilidade de gerenciamento e o processo em fases, estando este último relacionado com o ciclo Planejar-Executar-Verificar-Agir (PDCA – Plan-Do-Check-Act).
2.4. Certificação Profissional
Desde 1994 o PMI tem se dedicado a desenvolver e manter um rigoroso programa de certificação profissional com o objetivo de investir na profissão de gerente de projetos e reconhecer as realizações individuais na gestão de projetos.
Sendo assim, o PMI conta com dois tipos de certificações profissionais aceitos e reconhecidos mundialmente. São eles:
Profissional de Gestão de Projetos (PMP – Project Management Professional)
A certificação profissional PMP é a certificação de maior reconhecimento, a qual indica que o profissional tem sólida base de conhecimento em gestão de projetos.
Para ser certificado como PMP, o profissional de gestão de projetos deve realizar treinamento específico, atender requisitos de experiência e concordar em seguir ao código de conduta profissional. Tendo atendido os critérios mencionados, o profissional passa então por um exame, administrado globalmente, para avaliar e medir seu conhecimento em gestão de projetos.
Além disso, os profissionais certificados como PMP devem demonstrar comprometimento com a gestão de projetos satisfazendo o Programa de Requisitos de Certificação Continuada do PMI.
Associado Certificado em Gestão de Projetos (CAPM – Certified Associate in Project Management)
A certificação profissional CAPM é indicada para profissionais que realizam atividades de gestão de projetos, porém são novos na profissão, sendo um passo anterior ao PMP.
Os candidatos ao CAPM também devem realizar treinamentos específicos e atender requisitos de experiência para então passarem pelo exame.
Capítulo 3
Considerações sobre o Modelo de Maturidade da Capacidade
O propósito deste capítulo é apresentar o Modelo de Maturidade da Capacidade e o conceito de maturidade de processo. Para tanto, é apresentado o histórico da evolução do modelo, desde o seu propósito inicial até tornar-se referência mundial em maturidade de processo.
Em seguida é apresentada a estrutura do modelo, considerando os níveis de maturidade propostos, as áreas chaves que compõem cada nível e as metas relativas a cada área chave. É também apresentada a relação do modelo com os conceitos da gestão da qualidade total e, por fim, as formas de avaliação de maturidade existentes.
O Modelo de Maturidade da Capacidade, desenvolvido pelo Instituto de Engenharia de Software (SEI – Software Engineering Institute) da Carnegie Mellon University, é um modelo de maturidade de processo que tem como objetivo ajudar as organizações a melhorarem o seu processo de software.
De acordo com PAULK et al. (1994, p.353), o Modelo de Maturidade da Capacidade é “uma descrição dos estágios pelos quais as organizações de software evoluem à medida que definem, implementam, medem, controlam e melhoram seu processo de software”.
3.1. Histórico
O CMM começou a ser desenvolvido em novembro de 1986, quando o governo federal dos Estados Unidos solicitou ao Instituto de Engenharia de Software (SEI – Software Engineering Insitute)
da Carniege Mellon University o desenvolvimento de um método que permitisse avaliar a capacidade do processo de software de seus fornecedores.
Em setembro de 1987 foi disponibilizada uma breve descrição do que foi chamada a estrutura da maturidade do processo de software. Haviam sido desenvolvidos dois métodos e um questionário para avaliar a maturidade do processo.
Quatro anos depois, o Instituto de Engenharia de Software finalizou a evolução da estrutura da maturidade do processo de software anteriormente desenvolvida para o CMM. A versão 1.0 do CMM foi disponiblizada em agosto de 1991.
A versão inicial do CMM foi utilizada e revista pela comunidade de software entre 1991 e 1992. Baseado no conhecimento adquirido neste período, o modelo foi revisado, sendo disponibilizada em 1994 a versão 1.1, atualmente utilizada pelas organizações de software em todo o mundo.
3.2. Aspectos Gerais
O CMM é dividido em 5 níveis de maturidade, os quais representam o nível de capacidade do processo de software. Cada nível de maturidade, com exceção do nível 1, é dividido em áreas chave de processo, que indicam onde a organização deve focalizar para melhorar seu processo de software.
A Tabela 1 apresenta os níveis de maturidade, além do foco e das áreas chave de processo a eles associados.
Tabela 1 – Os níveis de maturidade do Modelo de Maturidade da Capacidade
Nível Foco Áreas Chave de Processo Siglas
5 Otimizado Melhoria Contínua
Prevenção de Defeitos
Gerência da Mudança de Processo Gerência da Mudança de Tecnologia
DP PCM TCM 4 Gerenciado Qualidade de Produtos e Processos
Gerência Quantitativa do Processo Gerência Qualitativa do Software
QPM SQM
3 Definido Engenharia de
Processo
Foco no Processo da Organização Definição do Processo da Organização Programa de Treinamento
Gerenciamento do Software Integrado Engenharia do Produto de Software Coordenação Intergrupos
Revisões entre Pares
OPF OPD TP ISM SPE IC PR
2 Repetível Gestão de Projetos
Gerência de Requisitos
Planejamento do Projeto de Software
Acompanhamento e Supervisão do Projeto de Software Gerência da Contratação de Terceiros
Garantia da Qualidade do Software Gerência da Configuração do Software
RM SPP SPTO SSM SQA SCM 1 Inicial Heroísmo
Cada uma das áreas chaves de processo descreve os objetivos a serem atingidos por meio de sua implementação. Para tanto, as áreas chave de processo são organizadas em práticas chaves, as quais são agrupadas nas seguintes características comuns:
§ Compromissos a Realizar – descrevem as ações que a organização tem que tomar para garantir que o processo está estabelecido e irá perdurar. Envolvem o estabelecimento de políticas organizacionais e liderança.
§ Habilidades a Realizar – descrevem as pré-condições do projeto ou da organização necessárias para implementar o processo de software de forma competente. Envolvem recursos, estruturas organizacionais e treinamento.
§ Atividades Realizadas – descrevem atividades, papéis e procedimentos necessários para implementar a área chave de processo. Envolvem o estabelecimento de planos e procedimentos, a realização do trabalho, o acompanhamento e a tomada de ações corretivas quando necessário.
§ Medição e Análise – descrevem práticas de medição básicas necessárias para determinar a situação relacionada ao processo. As medidas descritas são utilizadas para controlar e melhorar o processo.
§ Verificação da Implementação – descrevem os passos para assegurar que as atividades são realizadas em conformidade com o processo estabelecido. São incluídas práticas chaves relacionadas com a supervisão do gerente sênior e gerente do projeto, além de verificações específicas da garantia da qualidade visando certificar que o processo está sendo aplicado corretamente.
A Figura 4 apresenta a estrutura do CMM considerando as práticas chaves descritas.
Figura 4 – Estrutura do Modelo de Maturidade da Capacidade (PAULK et al., 1994, p.31) Ao implementar corretamente todas as práticas chaves descritas nas áreas chaves de processo de um determinado nível do Modelo de Maturidade da Capacidade, diz-se que a organização encontra-se
Níveis de Maturidade
Áreas Chave de Processo
Características Comuns Práticas Chave contêm organizadas por contêm indicam conduzem a atingem descrevem Capacidade de Processo Metas Implementação ou Institucionalização Infraestrutura ou Atividades
nesse nível de maturidade. É importante lembrar que, para estar em um determinado nível de maturidade do Modelo de Maturidade da Capacidade, os níveis anteriores devem ter sido atendidos também.
A seguir serão detalhados os cinco níveis de maturidade do modelo, além de serem apresentados os objetivos das áreas chaves de processo de cada um nos níveis.
Nível 1 – Inicial
Organizações no nível 1 do CMM tipicamente não provêem um ambiente estável para o desenvolvimento e a manutenção do software. A presença de um processo de software é praticamente nula.
Apesar do processo quase caótico, tais organizações conseguem desenvolver softwares que funcionam, ainda que excedendo o cronograma e o orçamento. O sucesso depende da competência e heroísmo das pessoas na organização, o que dificilmente será repetido a não ser que os mesmos indivíduos sejam alocados ao próximo projeto. Dessa forma, a maturidade é uma característica dos indivíduos, e não da organização.
A grande maioria das organizações de software no mundo encontra-se no nível 1.
Nível 2 – Repetível
No nível 2, políticas para gerenciar um projeto de software e procedimentos para implementar tais políticas são estabelecidos.
Os projetos são gerenciados de forma a permitir o acompanhamento dos custos, do cronograma e da implementação das funcionalidades. São definidos padrões para os projetos de software e a organização assegura que tais padrões são seguidos. Organizações no nível 2 conseguem repetir o processo em projetos com aplicações similares.
Sendo assim, o desenvolvimento dos projeto de software passa a seguir planejamento realista baseado no desempenho de projetos anteriores.
Gerência de Requisitos
O propósito da Gerência de Requisitos é estabelecer e manter concordância com o cliente sobre os requisitos para o desenvolvimento do projeto de software, referidos pelo modelo como “requisitos de sistema alocados ao software”.
Esta concordância envolve tanto requisitos técnicos como não técnicos, por exemplo, datas de entrega. À partir destes requisitos é formada a base para a estimativa, planejamento, execução e acompanhamento das atividades do projeto de software durante o seu ciclo de vida.
O grupo de engenharia de software executa atividades específicas para garantir que os requisitos de sistemas alocados ao software sejam documentados e controlados. Para obter tal controle, é feita uma revisão visando identificar possíveis problemas antes que os requisitos sejam incorporados ao projeto de software. Quando há alguma modificação nos requisitos de sistema alocados ao software, os planos de software, produtos de trabalho e atividades afetados são ajustados para permanecerem consistentes com os requisitos atualizados.
Metas:
1) Os requisitos de sistema alocados ao software são controlados de forma a estabelecer uma linha base a ser utilizada pela engenharia de software e gerência.
2) Planos de software, produtos e atividades são mantidos consistentes com os requisitos de sistema alocados ao software.
Planejamento do Projeto de Software
O propósito do Planejamento do Projeto de Software é estabelecer planos fundamentados para realizar as atividades de engenharia do software e para gerenciar o projeto.
O Planejamento do Projeto de Software envolve desenvolver estimativas para o trabalho a ser realizado por meio do estabelecimento de compromissos necessários e da definição do plano para execução.
O processo de planejamento do software inclui a realização de estimativas de tamanho dos produtos de trabalho de software e dos recursos necessários, elaboração de cronograma, identificação e avaliação os riscos, além da negociação de compromissos.
Tendo tais atividades concluídas, é elaborado o plano para desenvolvimento do projeto, o qual provê a base para a gerência e realização das atividades do projeto, além de endereçar os compromissos relacionados com os recursos, as restrições e as capacidades do projeto de software.
1) Estimativas de software são documentadas para uso no planejamento e acompanhamento do projeto de software.
2) Atividades e compromissos do projeto de software são planejados e documentados.
3) Grupos e indivíduos afetados concordam com os compromissos relacionados ao projeto de software.
Acompanhamento e Supervisão do Projeto de Software
O propósito do Acompanhamento e Supervisão do Projeto de Software é prover visibilidade adequada do progresso do projeto de forma que possam ser tomadas ações efetivas quando o desempenho desvia significantemente do plano.
O Acompanhamento e Supervisão do Projeto de Software envolve acompanhar e confrontar as realizações e os resultados do projeto com as estimativas documentadas, compromissos e planos, visando ajustar o planejamento.
O plano documentado para o desenvolvimento do projeto é utilizado como base para acompanhar as atividades do projeto, comunicar a situação e revisar o planejamento.
Metas:
1) Resultados e desempenho atuais são acompanhados e confrontados com os planos de software.
2) Ações corretivas são tomadas e gerenciadas até sua finalização quando os resultados e desempenho atuais desviam significantemente dos planos de software.
3) Alterações nos compromissos de software são concordadas pelos grupos e indivíduos afetados.
Gerência de Contratação de Terceiros
O propósito da Gerência de Contratação de Terceiros é selecionar fornecedores de software qualificados e gerenciá-los efetivamente.
A Gerência de Contratação de Terceiros envolve selecionar um fornecedor de software, estabelecer compromissos, além de acompanhar e rever o desempenho e resultados obtidos.
Na contratação de terceiros, é estabelecido um acordo documentado cobrindo tanto os requisitos técnicos como os não técnicos, utilizado como base para a gerência do terceiro. O trabalho a ser realizado pelo terceiro e os planos para a execução das atividades são documentados. Os padrões que serão seguidos pelo terceiro devem ser compatíveis com os padrões estabelecidos pelo contratante.
O planejamento, acompanhamento e supervisão das atividades do terceiro é realizado pelo contratante de forma a garantir que tais atividades são realizadas adequadamente e que os produtos de software entregues pelo terceiro satisfazem os critérios estabelecidos.
Metas:
1) O contratante seleciona fornecedores de software qualificados.
2) O contratante e o fornecedor de software concordam com seus compromissos. 3) O contratante e o fornecedor mantêm comunicações de progresso.
4) O contratante acompanha os resultados e desempenho atuais do fornecedor de software confrontando-os com os compromissos assumidos.
Garantia da Qualidade de Software
O propósito da Garantia da Qualidade de Software é prover visibilidade apropriada dos processos utilizados pelo projeto de software e dos produtos gerados.
A Garantia da Qualidade de Software envolve rever e auditar os produtos de software e as atividades para verificar se satisfazem os procedimentos e padrões estabelecidos, fornecendo aos gerentes do projeto de software os resultados.
O grupo de garantia da qualidade de software interage com o projeto de software desde os estágios iniciais, estabelecendo planos, padrões e procedimentos que adicionarão valor ao projeto, de forma a atender as particularidades do projeto e as políticas da organização.
Questões de não conformidade identificadas são primeiramente tratadas dentro do projeto de software e resolvidas quando possível. Para questões não resolvidas, o grupo de garantia da qualidade de software encaminha o problema para o nível de gerência apropriado.
Metas:
1) As atividades de garantia da qualidade de software são planejadas.
2) A aderência dos produtos e atividades de software aos padrões, procedimentos e requisitos aplicáveis é verificada objetivamente.
3) Grupos e indivíduos afetados são informados sobre as atividades e resultados da garantia da qualidade de software.
4) Questões de não conformidade que não podem ser resolvidos no escopo do projeto de software são encaminhadas para o gerente sênior.
Gerência de Configuração de Software
O propósito da Gerência de Configuração de Software é estabelecer e manter a integridade dos produtos durante o ciclo de vida do projeto de software.
A Gerência de Configuração de Software envolve a identificação da configuração do software, o controle sistemático das alterações desta configuração, a manutenção da integridade e a capacidade de rastreamento da mesma durante o ciclo de vida do software. Os produtos de trabalho sob gerência de configuração incluem os produtos de software que serão entregues ao cliente e os itens que são requeridos para criá-los.
É estabelecida uma biblioteca contendo as linhas base do software, estabelecidas conforme os produtos são desenvolvidos. As alterações nas linhas base e nos pacotes de produtos de software gerados são controladas sistematicamente por meio do controle de versões e das funções de auditoria.
Metas:
1) As atividades de gerência de configuração de software são planejadas.
2) Produtos de trabalho selecionados são identificados, controlados e disponibilizados. 3) Alterações nos produtos de trabalho identificados são controladas.
4) Grupos e indivíduos afetados são informados da situação e conteúdo das linhas base de software.
