UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE

Transcrição

1 1 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE A INFLUÊNCIA DOS MODELOS DE MATURIDADE NA QUALIDADE DA GESTÃO DE PROJETOS DE SOFTWARE Por: Orlando Pereira Junior Orientador Prof. Jorge Tadeu Vieira Lourenço Rio de Janeiro 2009

2 2 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE A INFLUÊNCIA DOS MODELOS DE MATURIDADE NA QUALIDADE DA GESTÃO DE PROJETOS DE SOFTWARE Apresentação de monografia ao Instituto A Vez do Mestre Universidade Candido Mendes como requisito parcial para obtenção do grau de especialista em Gestão de Projetos. Por: Orlando Pereira Junior

3 3 AGRADECIMENTOS A minha mãe, meu pai (Euvaldir) e meus irmãos, pelo apoio e dedicação em toda a minha formação pessoal, educacional e profissional.

4 4 DEDICATÓRIA Dedico esse trabalho a minha esposa Angélica pelo amor e paciência em todos esses anos e a meus filhos Ana Carla, Beatriz, Lucas e Leonardo que são a luz da minha vida.

5 5 RESUMO Esse trabalho visa mostrar como a qualidade do gerenciamento dos projetos de software está diretamente ligada à maturidade das organizações que atuam na área de desenvolvimento de software, e como os modelos de maturidade ajudam nesse processo.

6 6 METODOLOGIA A metodologia baseou-se na pesquisa bibliográfica utilizando livro, manuais, artigos e sites especializados no assunto (Internet).

7 7 SUMÁRIO INTRODUÇÃO 08 CAPÍTULO I - Projeto e Gerenciamento de Projetos 10 CAPÍTULO II - Qualidade em Projetos de Software 17 CAPÍTULO III - A maturidade em Gerenciamento de Projetos e os modelos de maturidade 25 CAPÍTULO IV Modelo CMMI 46 CONCLUSÃO 72 BIBLIOGRAFIA 74 ÍNDICE 75 FOLHA DE AVALIAÇÃO 78

8 8 INTRODUÇÃO No intuito de atender os clientes, a área de TI das organizações é uma das mais demandadas, uma vez que tem interação com todas as áreas e deve lhes fornecer ferramentas que possibilitem incremento da produtividade e resolução de problemas. Para tanto é fundamental que os processos estejam documentados, atualizados e disponíveis. Devem existir padrões e ferramentas, aplicadas e utilizadas formalmente buscando resultados previsíveis. Não se podem deixar estas tarefas a mercê de esforços individuais. Se isso não ocorre, as áreas de sistemas passam a agir reativamente, o que em geral não viabiliza atingir os resultados esperados pela organização. Faz-se então necessário focar no planejamento, visando reduzir os erros e o retrabalho nos sistemas. Nesse cenário os modelos de maturidade, podem auxiliar os gerentes de projeto de software como ferramentas para a melhoria dos processos organizacionais, auxiliando no desenvolvimento, na aquisição e na manutenção de produtos e serviços de software. Os modelos de maturidade organizam as práticas, que já são consideradas efetivas, em estruturas que visam auxiliar as organizações a estabelecerem prioridades para a melhoria da qualidade e também fornecem guias para a implementação dessas melhorias. No capítulo 1 vamos mostrar alguns conceitos de projeto e gerenciamento de projetos, descrever qualidade em projetos, falar sobre alguns modelos de maturidade de projetos. No capítulo 2 falaremos sobre qualidade em projetos de software e a sua importância.

9 9 No capítulo 3 abordaremos a maturidade do gerenciamento de projetos e os modelos de maturidade. No capítulo 4 vamos abordar o CMMI, que é um modelo de maturidade voltado para a área de TI, e ver quais são seus principais benefícios e as vantagens da adoção desse modelo na qualidade do gerenciamento dos projetos. Finalmente na conclusão avaliaremos se a utilização dos modelos de maturidade efetivamente melhoram a qualidade do produto final que é o software.

10 10 CAPÍTULO I PROJETO E GERENCIAMENTO DE PROJETOS 1.1 PROJETO Conceito de projeto Segundo Vargas (2002) projeto é um conjunto de atividades com um ponto de início, um ponto definido para encerramento, um escopo de trabalho claramente definido, um orçamento, tendo por finalidade alcançar um objetivo predeterminado. Para Kerzner (2002), um projeto é qualquer série de atividades e tarefas que tenha um objetivo específico a ser completado dentre certos requisitos, prazos de início e fim definidos, bem como limites de recursos financeiros, humanos e de equipamento. Para Dinsmore (2004), projeto é um esforço temporário realizado para criar um produto ou serviço único, diferente, de alguma maneira, de todos os outros produtos e serviços, com início e fim definidos, que utiliza recursos, é dirigido por pessoas e obedece a parâmetros de custo, tempo e qualidade. Projeto É um empreendimento temporário com o objetivo de criar um produto ou serviço único. (PMI, 2004, 3ª Edição) Características de um projeto Segundo o PMI, um projeto possui as seguintes características: têm natureza temporária, ou seja, possuem datas de início e fim definidas;

11 11 são elaborados progressivamente; quer dizer, ao longo do projeto inteiro são executadas etapas incrementais com o objetivo de atender a necessidade e a exigências do produto do projeto; como os recursos em uma organização são limitados, a elaboração de um projeto sofre restrições; servem para lançar um produto ou serviço ou resultados exclusivos, ou seja, que não exista anteriormente, sendo assim o projeto é único Restrições no projeto Em uma organização, é comum existirem projetos a serem realizados, mas sem possuir recursos suficientes. Neste caso, os recursos são uma restrição. Ao desenvolvermos um projeto dentro das restrições apresentadas pela organização, é importante sabermos que a qualidade do projeto é afetada pelo balanceamento de três restrições: tempo, custo e qualidade (Fig.1). Essa situação é denominada restrição tripla, ou seja, dentro de um projeto uma ou duas dessas três restrições (às vezes as três) são limitadas. Alguns autores consideram o escopo do projeto mais um item a ser considerado nas restrições, visto que o escopo de um projeto e uma alteração desse escopo pode impactar diretamente o prazo, a qualidade e os custos do projeto (Fig. 1). Figura 1- Evolução dos critérios de restrição da gestão de projeto Extraído de: Extensão de Governança: Gestão, Auditoria e TIC, 2008, Conceitos e Fundamentos de Projetos, p. 7

12 12 Escopo Em projeto o termo escopo pode se referir a: Escopo do produto são as características e funções que descrevem um produto, serviço ou resultado. Escopo do projeto é a soma total de todos os produtos do projeto e seus requerimentos ou características Partes interessadas no projeto Partes interessadas no projeto são pessoas, grupos ou organizações envolvidas no projeto ou cujos interesses podem ser afetados positiva ou negativamente com o resultado da execução ou do término do projeto. As principais partes envolvidas no projeto são: gerente de projetos; cliente/usuário; organização executora (diretoria e gerentes de departamentos); membros da equipe do projeto; equipe de gestão de projetos; patrocinador do projeto; influenciadores; fornecedores; escritório de projeto Quando os projetos são necessários As organizações participam hoje de um mercado competitivo, globalizado e turbulento; nesse cenário, as organizações são, cada vez mais, obrigadas a atender às exigências do mercado por mudanças no desenvolvimento de produtos, melhoria de processos, ações comerciais e de marketing, modernização, desenvolvimento e implantação de novas tecnologias e de sistemas de apoio.

13 13 A fim de que as respostas para as questões demandadas sejam fornecidas de forma eficaz e eficiente, é necessário ter informações oportunas e conhecimentos personalizados, para que essas informações efetivamente auxiliem a gestão na tomada de decisão de forma inteligente e em tempo certo. Diante dessa realidade, a elaboração de projetos faz-se importante para que as organizações se mantenham competitivas no mercado Causas de fracasso Os projetos executados pelas organizações precisam estar alinhados com a estratégia da empresa e ser concluídos de acordo com prazos e orçamentos estipulados, de forma garantir o máximo de eficiência, produtividade e satisfação. Segundo o estudo de benchmarking em gestão de projetos realizado em 2007 pelo PMI, foram identificadas as principais causas de fracasso de projeto. Benchmarking É a comparação de práticas de projetos reais ou planejadas às de outros projetos para gerar idéias de melhoria e para oferecer uma base pela qual deve ser medido o desempenho. (PMI, 2004). As principais causas de fracasso de projeto são: não cumprimento dos prazos; problemas de comunicação; escopo não definido adequadamente; recursos humanos insuficientes; riscos não avaliados corretamente; mudanças de prioridade constantes; estimativas incorretas ou sem fundamento; falta de definição de responsabilidades; problemas com fornecedores; retrabalho em função da falta de qualidade do produto;

14 14 falta de competência para gerenciar projetos; falta de ferramenta ou de metodologia de apoio; falta de apoio da alta administração; falta de conhecimento técnico Causas de sucesso As definições modernas de sucesso de projeto dão-se em função de fatores primários (prazo, orçamento e qualidade) e de fatores secundários (aceitação e a concordância do cliente). A necessidade das organizações por maior eficiência e velocidade para atender às necessidades do mercado faz com que os projetos tenham que ser implantados dentro dos prazos requeridos, de acordo com o orçamento aprovado e conforme os requisitos definidos pelo cliente. Para que tudo isso aconteça, alguns fatores são apontados como causas de sucesso: disciplina e rigor no uso de uma metodologia para gerenciar o projeto; definição clara dos objetivos, requisitos e resultados esperados; apoio da alta gerência ao projeto; especificação detalhada dos passos e ações para a implantação do projeto; comunicação, envolvimento e participação de todos os envolvidos no projeto; recrutamento, seleção e treinamento do pessoal necessário para compor a equipe do projeto; alocação de recursos adequados para cada etapa do projeto; acompanhamento e feedback das informações referentes ao andamento e conclusão do projeto; habilidade do gerente de projeto em lidar com crises inesperadas e mudança de plano; aceite do cliente ao receber o produto do projeto.

15 GESTÃO DE PROJETO Gestão de Projeto É a aplicação de conhecimento, habilidades, ferramentas e técnicas as atividades do projeto a fim de atender a seus requisitos. (PMI, 2004). Gerenciar um projeto inclui: identificar as necessidades; estabelecer os objetivos claros e alcançáveis; balancear as demandas conflitantes de qualidade, escopo, tempo e custo; adaptar as especificações, dos planos e da abordagem às diferentes preocupações e expectativas das diversas partes interessadas Objetivo da Gestão de Projeto O objetivo principal da gestão de projetos é alcançar o sucesso da execução dos projetos Benefício da Gestão de Projeto Dentre os benefícios da gestão de projetos podemos citar o maior controle de mudança do escopo e o aumento da qualidade do projeto Importância da Gestão de Projeto A importância da gestão de projetos está no acúmulo de conhecimentos adquiridos para aplicação futura.

16 Fatores Críticos de Sucesso e Indicadores de desempenho Os fatores críticos de sucesso do projeto indicam aspectos indispensáveis para atender às necessidades do cliente, medem o resultado final, como o cliente os visualiza. Os fatores críticos são representados por: cumprimento da programação; atendimento do orçamento; concretização da qualidade; conveniência e oportunidade da assinatura do contrato; cumprimento do processo de controle da mudança; aditivos ao contrato de execução do projeto. Os indicadores de desempenho medem a qualidade do processo utilizado para alcançar os resultados finais e que podem ser revisados ao longo do ciclo de vida do projeto. Os indicadores de desempenho são representados por: utilização da metodologia de gestão de projeto; estabelecimento dos processos de controle; uso de indicadores; qualidade dos recursos aplicados x planejados; envolvimento do cliente Estruturas Organizacionais Segundo o PMI alguns fatores organizacionais influenciam o projeto, tais como: a maturidade da organização em relação ao seu sistema de gerenciamento de projetos; sua cultura; seu estilo; sua estrutura organizacional; e seu escritório de projetos.

17 17 CAPÍTULO II QUALIDADE EM PROJETOS DE SOFTWARE 2.1 Definição de Qualidade Termo subjetivo para o qual cada pessoa ou setor tem sua própria definição. Na utilização técnica, a qualidade pode ter dois significados: as características de um produto ou serviço que o torna capaz de satisfazer as necessidades implícitas ou declaradas; um produto ou um serviço livres de deficiências. requisitos". Segundo Joseph Juran, a qualidade significa adequação ao uso. De acordo com Philip Crosby, significa "conformidade com os 2.2 Gerenciamento da Qualidade do Projeto Aplica-se tanto aos resultados dos projetos e aos produtos e serviços a serem gerados quanto ao gerenciamento do projeto; Deve identificar os padrões de qualidade relevantes para o projeto e determinar as métricas e atividades para controlar a Qualidade e as atividades de garantia da Qualidade. Garantia x Controle, deve garantir da qualidade que tem caráter preventivo sobre a qualidade e controlar a qualidade com objetivo de verificar o atendimento dos padrões de qualidade. Deve atender tanto ao gerenciamento do projeto quanto ao gerenciamento do produto do projeto; Abordagem compatível com padrões e diretrizes ISSO, Deming, Juran, Crosby, Melhoria Contínua, TQC e outros conceitos e abordagens proprietárias e não proprietárias. Gerência de qualidade e gerência de projetos são complementares; Crescimento da atenção para com os requisitos dos clientes como base para a gestão da qualidade;

18 18 A expectativa do cliente deve ser atendida para que o projeto seja reconhecido. Porém, exceder os requisitos especificados no escopo do projeto é considerado uma perda de tempo e dinheiro, que não agregar valor ao projeto (Goldplating). Satisfação do cliente - Especificações x percepção; Planejamento - transformar necessidades identificadas e implícitas em requisitos do projeto; Prevenção e controle - evitar erros x corrigir erros; Responsabilidade da gerência - fornecer os recursos necessários para que se alcance o sucesso; melhoria contínua - PDCA, Seis Sigma, CMM, CMMI e OPM3; custo / benefício - duração limitada, controle de alterações. 2.3 Responsabilidade pela Qualidade Cada participante do projeto tem a responsabilidade pelo resultado da atividade que ele está conduzindo individualmente, devendo medir o seu desempenho e os resultados da atividade que está conduzindo individualmente, para garantir que a conformidade seja continuamente atingida; O sucesso requer a participação de todos os membros da equipe do projeto; É responsabilidade gerencial prover os recursos necessários ao sucesso. 2.4 Abordagens Gerenciais Just In Time Esta é uma abordagem gerencial que minimiza ou até elimina os estoques em processo; A filosofia é que sem estoques em processo os problemas de qualidade ficarão mais visíveis e poderão ser corrigidos.

19 Trilogia Juran Planejamento da Qualidade é o processo de preparação para obtenção dos objetivos. Identificar os clientes; Determinar as necessidades dos clientes; Definir as características dos produtos que respondem às necessidades dos clientes. Controle da Qualidade é o processo para assegurar o cumprimento dos objetivos definidos no planejamento. Avaliar o desempenho; Comparar o desempenho obtido com as metas; Atuar a partir das diferenças. Melhoria da Qualidade é o processo para produzir com níveis superiores. Estabelecer a infra-estrutura necessária para assegurar uma constante melhoria; Identificar as necessidades específicas para a criação de projetos de melhoria Ciclo de Deming (PDCA) ACT Agir A P PLAN Planejar CHECK Verificar C D DO Fazer Figura 2 - PDCA

20 20 PLAN - Deve-se estabelecer os objetivos e metas, para que sejam desenvolvidos métodos, procedimentos e padrões para alcançá-los. DO - Deve-se implementar o planejado, fornecendo educação e treinamento para a execução dos métodos desenvolvidos no planejamento. CHECK - Deve-se verificar se o planejado foi alcançado através da comparação entre as metas desejadas e os resultados obtidos. ACT - Caso as metas planejadas não tenham sido alcançadas, devese buscar as causas fundamentais a fim de prevenir a repetição dos efeitos indesejados. E caso tenham sido alcançadas, deve-se adotar como padrão o planejado Absolutos da Qualidade segundo Philip Crosby Qualidade significa conformidade com os requisitos; Qualidade vem da prevenção; O desempenho padrão é o do zero defeito ; Qualidade é medida pelo custo da não-conformidade Controle de Qualidade Total (Total Quality Control - TQC) segundo Feigenbaum Qualidade: é um instrumento estratégico pelo qual todos os trabalhadores devem ser responsáveis; é um filosofia de gestão e um compromisso com a excelência; tem por base a orientação ao cliente; está ligada a todas as funções e atividades da organização.

21 Melhoria Contínua (Kaisen) A idéia fundamental é que a melhoria não é um evento discreto ou pontual e todos devem se unir na responsabilidade de olhar constantemente para oportunidades de melhoria dos processos e produtos Círculos de Qualidade Visam aumentar a produtividade e melhorar a qualidade do que fazem, e formar grupos de funcionários que buscam constantemente o aprimoramento de suas tarefas e o aumento da efetividade de seu trabalho Alta ADM Superv Geral 4% 9% Problemas Conhecidos 100% Iceberg da Ignorância Figura Qualidade de Software Objetivo do Processo de Qualidade de Software A qualidade do produto de software é um dos objetivos do processo de desenvolvimento, assim, ao desenvolver-se um produto, deve-se ter previamente estabelecidas, como perspectiva, as características de qualidade que se deseja alcançar.

22 O que é qualidade de software? Um produto de software apresenta qualidade dependendo do grau de satisfação das necessidades dos clientes sob todos os aspectos do produto. (Sanders, 1994) Qualidade de software é a conformidade a requisitos funcionais e desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a características implícitas que são esperadas de todo o software desenvolvido por profissionais. (Pressman, 1994) Reflexão A ausência de funcionalidades não pode ser compensada por funcionalidades auxiliares genéricas não solicitadas, como: calculadora, agenda, cor de tela, etc. Um software de qualidade deve encantar o cliente e não somente funcionara direito e não ter erros. (Bill Gates). Software de qualidade é aquele que não apenas satisfaz as exigências, mas também é implementado a tempo e de acordo com o orçamento. (Juran) Fatores de Qualidade Explícitos Visíveis para o usuário Usabilidade expressa a facilidade de uso; Confiabilidade capacidade de dependência do software por determinado período de tempo; Integridade controle de acesso ao sistema; Prazo tempo estimado para a entrega;

23 23 Informações sobre o progresso relatórios descrevendo o progresso; Tempo de atendimento tempo gasto para manutenções; Retorno de investimento retorno em forma de benefícios Implícitos Visíveis para os desenvolvedores Flexibilidade facilidade de modificação; Manutenabilidade esforço necessário para remover defeitos; Testabilidade facilidade para executar testes; Eficiência quantidade de recursos para cumprir determinada tarefa; Interoperabilidade integração das partes de um sistema; Reusabilidade possibilidade de reaproveitamento de software ou partes do software; Portabilidade capacidade de usar diferentes plataformas; Estimativas exatidão nas estimativas de custo, prazo e esforço; Estabilidade extensão do ciclo de vida onde se mantém a qualidade Custo da Qualidade x Custo da não Qualidade Custo da Qualidade Planejamento dos trabalhos; Treinamento nos processos, técnicas e ferramentas; Controles do processo de desenvolvimento; Testes; Revisões de documentos; Auditorias de processos.

24 24 Custo da não Qualidade Retrabalhos; Ações corretivas; Atrasos nos cronogramas; Perdas financeiras e operacionais; Perdas de oportunidades.

25 25 CAPÍTULO III A MATURIDADE EM GERENCIAMENTO DE PROJETOS E OS MODELOS DE MATURIDADE 3.1 Maturidade em Gerenciamento de Projetos O conceito de maturidade em Gerenciamento de Projetos tem sua raiz no conceito de maturidade de processo, originado no movimento de TQM (Total Quality Management), em que técnicas de controle estatístico da qualidade possibilitaram a redução da variação de resultado dos processos e uma substancial melhoria na performance do processo.(cooke- Davies;Arzymanow, 2003) Kerzner (2002) define: A maturidade em gestão de projetos é o desenvolvimento de sistemas e processos que são, por natureza, repetitivos e garantem uma alta probabilidade de cada um deles ser um sucesso. Entretanto, processos e sistemas repetitivos não são, por si, garantia de sucesso. Apenas aumentam a sua probabilidade. (p.45) Entretanto, a obtenção da maturidade depende de tempo em melhorias de seus processos de Gerenciamento de Projetos, o que pode levar a cerca de cinco anos para assim colher seus benefícios. Há dois fatores críticos que podem acelerar o processo de maturidade: (Kerzner, 1987) primeiro: a percepção por parte da organização da necessidade de haver gerenciamento de projetos, através da existência de projetos estratégicos, expectativas dos clientes, ganho de competitividade, desenvolvimento de novos produtos, eficiência e efetividade, ou até mesmo assegurar a sobrevivência da organização.

26 26 segundo: entendimento e comprometimento corporativo em educar e treinar toda a organização, em todos os níveis hierárquicos, em Gerenciamento de Projetos. Para Cooke-Davies e Arzymanow (2003), quanto mais tempo uma indústria sofrer pressões comerciais para obter melhor performance maior a maturidade deste setor. A maturidade do Gerenciamento de Projetos nos auxilia a compreender vários aspectos, entre eles, medir a competência dos profissionais em gerenciamento de Projetos em escalas generalizadas. Também nos auxilia a compreender o ambiente de trabalho dos profissionais e a avaliar a aderência ao negócio para qual o projeto está sendo desenvolvido. A maturidade em gestão de projetos também cria a oportunidade de estudar e compreender a formação de excelentes gerentes de projetos, e pode nos auxiliar a compreender o mecanismo que está por trás deste crescimento. (Hartman; Skulmoski, 1998) Ciclo de Vida da Maturidade em Projetos Para Kezner (2002), a maturidade em projetos possui um ciclo de vida, no qual uma empresa que tenha atingido qualquer grau de maturidade obrigatoriamente passou por estas etapas:

27 27 Tabela 1: Estágios da maturidade em gerenciamento de projetos. Extraído de: Kerzner, 2002, p. 46. A adoção de uma metodologia em Gerenciamento de Projetos, de forma definida e implantada, não é, por si só, um elemento suficiente para adquirir o nível de maturidade de uma organização no gerenciamento de seus projetos. Para tanto é necessário um conjunto de elementos que gravitam ao redor dessa metodologia: uma estrutura organizacional que promova e suporte o gerenciamento de projetos, organizações apropriadas com a existência de centros de excelência em gerenciamento de projetos, que, unidos à metodologia, confirmam a efetiva maturidade organizacional. (Bouer; Carvalho, 2005) Os modelos de maturidade são ferramentas que têm por objetivo auxiliar as empresas a alcançar a maturidade no gerenciamento de seus projetos, através da identificação das melhores práticas, realizadas por empresas líderes de mercado. (Kerzner, 2002). Para Hartman e Skulmoski

28 28 (1998) nenhum modelo de maturidade será completo ou correto, pois a contínua evolução do Gerenciamento de Projetos irá afetar os conceitos dos modelos. Através do modelo CMM, desenvolvido pela SEI, o conceito de maturidade de processos passou para a medida de uma maturidade organizacional. Como softwares são desenvolvidos através de projetos, foi natural que o conceito de maturidade migrasse de desenvolvimento de software para gerenciamento de projetos, gerando assim, no meio dos anos 90, o desenvolvimento de modelos de maturidade em Gerenciamento de Projetos. Na próxima sessão são apresentados os modelos de maturidade mais citados na literatura de modelos de maturidade em Gerenciamento de Projetos (Bouer; Carvalho; 2005; Cooke-Daviese; Arzymanow, 2003; Hartman; Skulmoski, 1998; Rabechini; Pessôa, 2005), além dos modelos desenvolvidos no Brasil, o MPCM com forte fundamento empresarial - e o MPS.BR, cuja importância afeta os resultados desta pesquisa. 3.2 Modelos de Maturidade O P3M3 Portfolio, Programme and Project Management Maturity Model O modelo de maturidade P3M3 foi desenvolvido pela OCG, Office Goverment Commerce, a Secretaria de Compras Governamentais do Reino Unido, mesma instituição que desenvolveu o PRINCE2. O P3M3 contempla em seu conteúdo a avaliação da maturidade no gerenciamento de projetos, portfólios e programas, e é tido como uma evolução de um modelo de maturidade anterior desenvolvido pela OCG, o P1M3 Project Management Maturity Model, que possuía como escopo o gerenciamento de projetos. A partir deste modelo, a OCG desenvolveu os modelos P2M3 - Portfolio and Project Management Maturity Model, que contempla projetos e portfólios e o P2MM - PRINCE2 Maturity Model que

29 29 contempla a maturidade no uso da metodologia PRINCE2 em gerenciamento de projetos. Figura 4: Estrutura dos modelos de maturidade desenvolvidos pela OCG. Extraído de: APMGroup, 2006, p.3. Segundo a OCG (2006), o modelo P3M3, auxilia as empresas a direcionar aspectos importantes no gerenciamento de portfólios programas e projetos, melhorando a qualidade e o sucesso dos resultados, através da construção de uma infra-estrutura para uma abordagem orientada a projetos com base em práticas gerenciais. O modelo afirma que os níveis de maturidade indicam como as áreas de processos podem estruturar hierarquicamente as organizações, fazendo com que as metas de melhoria sejam reais e perceptíveis. O modelo P3M3 tem como objetivos (OGC, 2006): entender as práticas chaves que compõem um efetivo processo de gerenciamento de projetos; identificar as práticas chaves que são necessárias à organização para atingir um nível mais alto de maturidade; para que organizações possam compreender e melhorar sua capacidade de gerir programas e projetos de forma mais efetiva;

30 30 para que consumidores possam avaliar os riscos atrelados a questões da capacidade de fornecedores contratados. O P3M3 é baseado em cinco níveis de maturidade, derivado do modelo de maturidade CMM, desenvolvido pela SEI, de acordo com a organização apresentada no quadro abaixo: Tabela 2: Características de maturidade no P3M3 para projetos, programas e portfólios de projetos. Extraído de: OCG, 2006, p.7.

31 31 Para cada nível de maturidade foi estabelecido um conjunto de processos, e cada um destes processos possui uma estrutura, que ao mesmo tempo é informativa e foca em resultados: metas do processo, abordagem, extensão, revisão, percepção e medidas de performance. As empresas que desejam ter seu nível de maturidade para gerenciamento de programas não poderão obter um nível de maturidade maior que o atingido no gerenciamento de projetos, assim como o nível de maturidade atingido com portfólios não pode ser maior que o de programas. A certificação em P3M3 para empresas é conduzida pela APM Group através de um questionário de acordo com seus processos de certificação, a mesma empresa que realiza as certificações profissionais na metodologia em gestão de projetos PRINCE2. O questionário de avaliação deve ser aplicado por um consultor registrado de acordo com o processo de credenciamento da APMG. As observações e recomendações do consultor serão avaliadas pela APMG, que irá atribuir a Avaliação de Nível de Maturidade para a organização. Para obtenção da certificação, há um número mínimo de perguntas a serem respondidas, e uma lista mínima de pessoas que devem responder as questões. O objetivo da certificação vai além da avaliação, procurando também fornecer a empresas um guia para melhoria de performance e maturidade para a organização Project Management Process Maturity (PM²) Model Inicialmente, o modelo de maturidade Project Management Process Maturity Model (PM²) teve o nome de The Berkeley Project Management Process Maturity Model, já que foi desenvolvido pelo professor Youg Hoon Kwak, da Berkeley University, juntamente com o professor C. William Ibbs, da George Washington University.

32 32 Este modelo de maturidade resultou de dois processos: do estudo e comparação de diversos modelos de maturidade em projetos e em desenvolvimento de produto, e do benchmarking dos processos e práticas em gestão de projetos em 43 empresas. O PM² adota a integração dos diversos modelos de maturidade em empresas de quaisquer setores, e divide as práticas em gerenciamento de projetos em nove áreas do conhecimento e cinco processos, de acordo com as práticas do PMBOK. Como a maioria dos modelos de maturidade mais conhecidos, o PM² adota também os cinco níveis de maturidade e o conceito de melhoria contínua comum à grande maioria dos modelos de maturidade (Kwak; Ibbs, 2002). Segundo Hartman e Skulmoski (1998), o PM² tem ligeira semelhança com o modelo CMMI da SEI. Segundo Kwak e Ibbs (2002), as grandes contribuições do modelo PM² estão exatamente na possibilidade de uso do modelo em empresas dos mais diferentes setores e também na força que o modelo possui em relação à área financeira, através de medição da efetividade financeira de acordo com dados reais relacionados à gestão do projeto, são checadas a relação entre efetividade do projeto e performance do projeto e é estabelecido um retorno do investimento do projeto (PM/ROI), derivado da mensuração e projeção dos benefícios potenciais do investimento no projeto O MMGP Modelo de Maturidade em Gestão de Projetos O MMGP (Modelo de Maturidade em Gestão de Projetos) ou MPCM (Maturity by Project Category Model) foi desenvolvido de 1999 a 2002, pelo consultor brasileiro Darci Prado, com base em sua experiência profissional como consultor. Sua criação teve como objetivo inicial auxiliar a equipe de gerenciamento de projetos da Consultoria INDG no diagnóstico do estágio de maturidade em que se encontravam as empresas para as quais prestavam serviços.

33 33 Embora possa ser aplicada a toda uma organização, o modelo MMPG é conhecido como setorial, ou seja, é aplicado separadamente em cada setor de uma organização, tomando por base a teoria de que cada área da empresa possui diferentes níveis de maturidade. (Prado, 2005) O MMPG utiliza-se de dois conceitos chaves, os níveis de maturidade e as dimensões da maturidade. São seis dimensões da maturidade, sendo estas: conhecimento de gerenciamento - que compreende: conhecimento de gerenciamento de projetos e conhecimento de outras práticas de gerenciamento empregadas na empresa; uso prático de metodologias; informatização; relacionamentos humanos; estrutura organizacional e alinhamento com os negócios na organização. Os cinco níveis de maturidade do modelo MMGP são: Inicial (ad hoc): baixo conhecimento, uso da intuição, inexistência de metodologia; Conhecido: aumento no nível de conhecimento, iniciativas isoladas; Padronizado: mapeamento de processos, uso de metodologia e informatização, alinhamento com a estratégia, e uso de padrões pelos gerentes de projeto; Gerenciado: processos e padrões são aceitos e praticados, causas de erros identificadas e eliminadas, relacionamentos humanos eficientes. Otimizado: otimização de custos, prazos, qualidades e processos de gerenciamento.

34 34 abaixo: As seis dimensões permeiam os cinco níveis, de acordo com a tabela Tabela 3: Dimensões e níveis de maturidade do MMGP. Extraído de: Prado, O nível de maturidade da empresa é determinado pelo preenchimento de um questionário de 40 questões no qual é atribuída uma pontuação de acordo com suas respostas. De acordo com Prado (2005), o MMGP apresenta como grandes contribuições sua simplicidade e facilidade de uso, além de aderência à realidade das empresas brasileiras, já que foi elaborado a partir de informações das mesmas, além de permitir que seja estabelecido às empresas avaliadas um plano de crescimento O MPS.BR Melhoria de Processo de Software Brasileiro O MPS.BR não é definido como um modelo de maturidade, entretanto, utiliza-se de conceitos semelhantes ao CMMI e outros modelos de maturidade, e influencia nos resultados desta pesquisa. O programa Melhoria de Processo de Software Brasileiro é um programa mobilizador, resultado do esforço contínuo nas duas últimas décadas para a melhoria da qualidade da produção de software no Brasil.

35 35 Por programa mobilizador podemos compreender: Um programa capaz de arregimentar, aglutinar organizar e por em movimento, ou criar o potencial necessário para uma ação política que vise o desenvolvimento econômico, social e/ou militar, por meio do domínio, uso, aperfeiçoamento ou geração de conhecimento empíricos, intuitivos, científicos e tecnológicos ou inovações que resultem em processos, produtos sistemas ou serviços novos ou substancialmente melhorados. Ele é, em geral, composto por um conjunto articulado de projetos de pesquisa básica, pesquisa aplicada, de desenvolvimento experimental, de engenharia não rotineira e de comercialização pioneira, conduzido, cooperativamente, por empresas, órgãos governamentais, universidades, centros e institutos de pesquisa, e outros atores da área científica e tecnológica. (Longo, 2005, p.1535). O MPS.BR foi iniciado pela Associação para a Promoção da Excelência do Software Brasileiro (SOFTEX) e envolveu universidades, centros de pesquisa, organizações atuantes na área de melhoria de processo de software, instituições implementadoras e instituições avaliadoras. Também é apoiado pelo Ministério da Ciência e Tecnologia, e pela FINEP Financiadora de Estudos e Projetos. A partir de 2005, passou a contar com o apoio do BID Banco Interamericano de Desenvolvimento, através do FUMIN Fundo Multilateral de Investimento. Com o objetivo de melhoria no processo de produção do software brasileiro, o MPS.BR possui duas grandes metas estabelecidas, uma sendo técnica, e outra de disseminação do programa no mercado brasileiro, divididas em macro atividades (Weber, 2006): Meta 1 técnica Criação e aprimoramento do programa MPS. BR; Capacitação por meio de programas de treinamento, composto de cursos, provas e workshops a um custo viável; Credenciamento de instituições implementadoras; Credenciamento de instituições avaliadoras.

36 36 Meta 2 disseminação Criação e aprimoramento de um modelo de negócios para o MPS.BR; Implementação do MPS.BR em pequenas e médias empresas a um custo viável; Avaliação do MPS.BR nas empresas a um custo viável. O MPS.BR é composto de um Modelo de Referência e um Método de Avaliação que estão em conformidade com a as normas ISO/IEC e ISO/IEC 15504, são compatíveis com o CMMI e com foco na realidade das empresas brasileiras. Além destes dois componentes, o MPS.BR possui um Modelo de Negócio. Cada um dos componentes é composto por outros documentos conforme a figura a seguir. Figura 5: Estrutura do programa MPS.BR. Extraído de: Weber, 2006, p Definição O MPS.BR é composto por níveis de maturidade, patamares de evolução de processos, seqüenciais e cumulativos. São sete os níveis de maturidade, numa escala decrescente de maturidade: A (Em otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido),

37 37 E (Parcialmente definido), F (Gerenciado), G (Parcialmente Gerenciado). (Weber, 2004). Segundo Weber (2006), a graduação em sete níveis permite uma implementação e um reconhecimento mais gradual da melhoria do processo de produção de software e uma visualização de resultados em prazos mais curtos, o que facilitaria a sua aquisição por parte de pequenas e médias empresas. figura a seguir: Os níveis do MPS.BR tem relação com os níveis do CMMI, conforme Figura 6: Comparação entre os níveis MPS.BR e CMMI Os níveis E e D são intermediários aos níveis 2 e 3 do CMMI e o G é intermediário aos níveis 1 e 2 do CMMI. O relacionamento entre o MPS.BR e o CMMI foi proposital, de maneira a permitir às organizações que os esforços utilizados na melhoria de seus processos sejam reconhecidos por diversas avaliações. O MPS.BR é composto por quatro documentos (Weber, 2006): Guia Geral: contém a descrição geral do MPS.BR, e apresenta os conceitos necessários para o entendimento e aplicação do programa.

38 38 Guia de avaliação: apresenta o Método de Avaliação do MPS.BR e apresenta basicamente o processo de avaliação, o método de avaliação e a qualificação necessária para os avaliadores. Guia de Aquisição: apresenta um processo de aquisição de software e serviços em conformidade com a norma ISO/IEC 12207, e o relacionamento entre esta norma e o MPS.BR. Modelo de Negócios: O modelo de negócio do MPS.BR é formado por três esferas: a gestão do programa, pela SOFTEX, as instituições implementadoras e avaliadoras, empresas e grupos de empresas. O documento MN-MPS (Modelo de Negócios-MPS), é formado por um modelo de negócio cooperado nos quais várias pequenas e médias empresas usufruem dos processos de melhoria de software ou um modelo de negócio específico, no qual uma única empresa usufrui das melhorias O futuro do MPS.BR Segundo Weber (2007), em relação a empresas avaliadas, até agosto de 2008 contava-se com 107 avaliações MPS publicadas (com prazo de validade de 3 anos). Num cenário referente aos próximos anos, espera-se ter um total de 377 empresas com avaliação oficial MAMPS até dezembro de 2010 [Weber, 2008].

39 39 Os resultados das avaliações estão disponíveis no quadro abaixo. Figura 7: Quadro com as avaliações MPS Extraído de: O PMMM - Project Manegement Maturity Model O PMMM (Project Management Maturity Model) foi desenvolvido pelo pesquisador Harold Kerzner em 2001, e é uma combinação dos conceitos do PMBOK e do CMM, antecessor do CMMI. Este modelo introduz a ferramenta do benchmarking para mensuração do seu nível de maturidade com cinco fases (Rabechini e Pessôa, 2005; Kerzner, 2002): linguagem comum: primeiro estágio de reconhecimento por parte de uma organização sobre a necessidade de uma metodologia em gerenciamento de projetos; processos comuns: segundo estágio, no qual há a necessidade de processos comuns objetivando repetir o sucesso obtido em projetos passados, e evitar erros cometidos; metodologia singular: terceiro estágio, em que as várias metodologias em gerenciamento de projeto existentes na organização são combinadas sob um único eixo;

40 40 benchmark: quarto estágio, no qual a empresa estabelece comparações entre suas práticas gerencias com a de outras empresas, buscando obter informações que possibilitem a melhoria na condução de seus projetos; melhoria contínua: as informações obtidas no nível anterior são utilizadas e implementadas, buscando a melhoria contínua nos processos de condução dos projetos. Figura 8: O modelo PMMM. Fonte: KERZNER, 2002, p.197. níveis: Conforme figura acima, o modelo pressupõe a sobreposição entre Sobreposição entre os níveis 1 e 2 durante o estabelecimento de processos comuns, a empresa pode ainda aprimorar a linguagem comuns; Sobreposição entre os níveis 3 e 4 enquanto a empresa desenvolve a metodologia, o benchmarking pode auxiliar no aprimoramento dessa metodologia; Sobreposição entre os níveis 4 e 5 à medida que a empresa evolui o benchmarking e a melhoria contínua passa a fazer parte de um processo rotineiro, a velocidade das mudanças aumenta, e faz

41 41 com os haja uma sobreposição e feedback do nível 5 para os níveis 3 e 4, aumentando a sobreposição, propiciando uma evolução contínua ao longo do tempo. Para Kerzner (2002), o nível 3 representa o nível de maior risco e maior grau de dificuldade para a organização. Após atingi-lo, os níveis 4 e 5 possuem um baixo grau de dificuldade, entretanto, para atingir o nível 3, a empresa deve passar por drásticas mudanças culturais O OPM3 (Organizational Project Management Maturity Model) O OPM3 (Organizational Project Management Maturity Model) é o modelo de maturidade em gerenciamento de projetos desenvolvido pelo PMI, com início de sua elaboração em Foi lançado em 2003 e tem como foco o gerenciamento sistemático de projetos, programas e portfólios, associado aos objetivos estratégicos. Para seu desenvolvimento, foram recrutados mais de 800 profissionais voluntários da área de Gerenciamento de Projetos para a análise de 27 modelos de maturidade além de alinhamento completo com o PMBOK resultando nas 600 melhores práticas, avaliadas através de 151 questões de respostas fechadas, que compõem as principais capacidades inerentes ao gerenciamento de projetos (Rabechini; Pessôa, 2005). Expostos a seguir: Padronização e integração de métodos e processos - visando estabelecimento de uma linguagem comum a todos os envolvidos com gerenciamento de projetos atingida pela padronização de documentos; Desempenho e métricas-estabelecimento de medidas de desempenho, com ênfase em custos, prazos e qualidade; Comprometimento com procedimentos de gerenciamento de projetos criação de políticas de gerenciamento atreladas a metas; Priorização de projetos e alinhamento estratégico geração de projetos que sustentem as estratégias da empresa;

42 42 Melhoramento contínuo garantia de formação de um banco de conhecimento dos projetos, que permita evitar falhas em projetos futuros; Estabelecimento de critérios de sucesso identificar projetos com valores adequados às estratégias da empresa; Pessoas e competências - criação de ferramentas formais de avaliação de competências das equipes de projetos; Alocação pessoal auxiliar no estabelecimento de prioridades dos projetos de acordo com as estratégias da empresa; Aspectos organizacionais formação das estruturas das equipes de projetos de acordo com a estrutura organizacional vigente; Equipes - formação de uma cultura de projetos que permita estabelecer em conjunto níveis de inovação e criatividade. Este modelo de maturidade é composto por quatro conceitos chaves: best pratices, capabilities, outcomes, e KPIs (key performance indicators). Cada best pratice é formada por um número de capabilities. Cada capability é formada por um outcome, a evidência de que a capability existe ou foi atingida pela organização. O KPI é uma métrica quantitativa ou qualitativa indicativa deste outcome. (Fahrenkrog, 2003) As best pratices podem ter relação entre si, assim como as capabilities de uma best pratice e de outra, conforme figura abaixo: Figura 9: O modelo OPM3. Extraído de: Fahrenkrog, 2003 p.3.

43 43 No exemplo acima, a best pratice A só é atingida com a obtenção das capabilities A1, A2 e A3, cada qual formada por uma outcome e seu respectivo KPI. Para obtenção da best pratice B, é necessário obter a best pratice A e para obter a capability B3 é necessário conseguir a capability A2, demonstrando a relação de dependência entre as best pratices e suas capabilities. O modelo também utiliza os conceitos de níveis, utilizando-se de quatro níveis (padronizado, medido, controlado e melhoria contínua) cruzado com os Grupos de Processos de Gerenciamento de Projetos (PMI, 2004): processos de iniciação: autorização para o projeto; processos de planejamento: definição e seleção das ações e alternativas a serem tomadas para o cumprimento dos objetivos estabelecidos pelo projeto; processos de execução: coordenação de pessoas e recursos para condução do projeto; processos de controle: estabelecer medidas e pontos de monitoramento regulares para verificação do andamento do projeto e definição de ações para correção se necessários; processos de finalização: aceitação formal do projeto, com cumprimento dos objetivos. Assim, cada best pratice encaixa-se num ponto de uma matriz tridimensional que se localiza dentro de um cruzamento entre os Grupos de Processo de Gerenciamento de Projetos, os níveis de maturidade, e se estamos tratando de gestão de projetos, gestão de programas ou gestão de portfólios. No OPM3, a empresa se auto-diagnostica e se auto-desenvolve em ciclos evolutivos constantes. Isso ocorre devido a necessidade de uma organização de (Fahrenkrog, 2003):

44 44 saber quais são as práticas específicas em gestão de projetos (conhecimento, habilidades, ferramentas e técnicas) que sejam mais desejadas ou úteis para seu funcionamento; um método que possibilite contrapor seu atual status em gerenciamento de projetos em relação as práticas desejadas; saber como melhorar a si mesma contra determinadas capabilities identificadas como necessidade de melhoria.

45 3.2.7 Comparativo dos Modelos de Maturidade Na tabela 4 são comparados os diferentes modelos de maturidade expostos aqui: Tabela 4: Comparação entre modelos de maturidade 45

46 46 CAPÍTULO IV MODELO CMMI Os estudos mais recentes sobre qualidade são voltados para o melhoramento do processo de software. Segundo Maciel [apud em Carosia], a qualidade do produto de software está diretamente relacionada à qualidade do processo que o produz. Por esta razão os certificados mais valiosos são aqueles que certificam o processo de produção de um produto e não os que certificam simplesmente o produto, pois ao garantir a qualidade do processo, já se está dando um grande passo para garantir também a qualidade do produto. O CMMI é um modelo de maturidade para melhoria de processos de desenvolvimento de produtos e serviços. Consiste nas melhores práticas, direcionando atividades de desenvolvimento e manutenção que cobrem o ciclo de vida de um produto desde a sua concepção até a sua entrega e manutenção. (SEI; 2006b, p.i, tradução própria) Assim como um modelo de maturidade, o CMMI também é classificado como um SPI (Software Process Improvement), ou seja, um processo de melhoria de software, embora a SEI venha realizando um grande esforço no sentido de afastar a imagem do CMMI de um processo de maturidade exclusivo para desenvolvimento de software, viés reproduzido inclusive por pesquisadores em Gerenciamento de Projetos. (Bouer; Carvalho, 2005) 4.1 Conceitos O CMMI (Capability Maturity Model Integration) é um modelo de referência desenvolvido pelo SEI (Software Engineering Institute) que visa orientar as organizações de software na implementação de melhorias contínuas em seu processo de desenvolvimento. Um modelo é uma representação simplificada do mundo, que tem como objetivo estabelecer - baseado em estudos, históricos e conhecimento operacional - um conjunto de "melhores práticas" que devem ser utilizadas com fim específico.

47 47 O CMMI é um modelo de maturidade para melhoria de processos de desenvolvimento de produtos e serviços. Consiste nas melhores práticas, direcionando atividades de desenvolvimento e manutenção que cobrem o ciclo de vida de um produto desde a sua concepção até a sua entrega e manutenção. (SEI; 2006b) Assim como um modelo de maturidade, o CMMI também é classificado como um SPI (Software Process Improvement), ou seja, um processo de melhoria de software. O CMMI estabelece conceitos relacionados aos níveis de maturidade das empresas de desenvolvimento de software no que diz respeito ao grau de evolução em que estas se encontram nos seus processos de desenvolvimento. O modelo estabelece também as providências que podem ser tomadas pelas empresas para que aumentem gradativamente o seu grau de maturidade, melhorando por conseqüência sua produtividade e a qualidade do produto de software. Para entender melhor o modelo, é necessário compreender conceitos como: processo, capabilidade e maturidade. Um processo de desenvolvimento de software corresponde ao conjunto de atividades, métodos, práticas e transformações que uma equipe utiliza para desenvolver e manter software e seus produtos associados. De acordo com Humphrey [apud em Jaciara], um processo de software envolve métodos, ferramentas e pessoas. Figura 10 Processo de Software

48 48 Para um processo funcionar de forma satisfatória ele deve possuir: Procedimentos e métodos que descrevam a relação entre as tarefas executadas; Ferramentas e equipamentos que dêem suporte a realização das tarefas, simplificando e automatizando o trabalho; Pessoas com habilidades e perfil adequado, treinadas nos métodos e ferramentas para terem condições de realizar as atividades de forma adequada; Este conjunto deve estar integrado harmoniosamente para funcionar de maneira eficaz. A capabilidade de um processo de software está relacionada aos resultados que podem ser obtidos pela sua utilização em um ou em vários projetos. Ela está relacionada aos resultados "esperados", permitindo estabelecer uma estimativa de resultados em futuros projetos. A maturidade de um processo de software estabelece os meios pelos quais ele é definido, gerenciado, medido, controlado e efetivo, implicando num potencial de evolução da capabilidade. À medida que uma organização cresce em termos de maturidade, seu processo de desenvolvimento de software é institucionalizado através de políticas, normas e estruturas organizacionais, as quais geram uma infraestrutura e uma cultura de suporte aos métodos e procedimentos de desenvolvimento.

49 Origem do CMMI O CMMI - Capability Maturity Model Integration foi construído sobre a estrutura do modelo do CMM - Capability Maturity Model, modelo de melhoria de processo mais difundido e utilizado na comunidade de software. Em Novembro de 1986, o SEI começou a desenvolver uma estrutura de maturidade do processo. Essa iniciativa se deu em resposta a uma solicitação do Departamento de Defesa dos Estados Unidos - DoD que precisava de um modelo formal que lhe permitisse selecionar os seus fornecedores de software de forma adequada, através de um método que avaliasse a capacidade ou capabilidade de software dos mesmos. Em Setembro de 1987, foi lançado pelo SEI uma breve descrição de um ambiente de maturidade de processo de software e um questionário da maturidade, que serviriam para avaliar o estado corrente das práticas de software e identificaria as áreas que necessitavam de melhoria. Segundo Tingey [apud em Jaciara], Crosby mostrou que a implementação de sistemas de qualidade em empresas segue um amadurecimento gradativo em patamares denominados: incerteza, despertar, esclarecimento, sabedoria e certeza. Em 1991, após quatro anos de experiência com a estrutura de maturidade de processo e versão preliminar do questionário da maturidade, foi lançado o CMM - versão 1.0, como uma evolução do ambiente proposto por Humphrey. A versão 1.1 foi lançada em 1993 e a partir daí o tema melhoria do processo foi ganhando força como conseqüência dos resultados práticos obtidos pelas empresas que realizaram programas de melhoria com o CMM como modelo de referência. O CMM é baseado no conhecimento adquirido a partir de verificações do processo de software e da realimentação extensiva da indústria e do governo. Através da elaboração da estrutura de maturidade, o modelo tem

50 50 mostrado que fornece às organizações um guia mais efetivo para o estabelecimento de programas de melhoria do processo. O modelo de qualidade de software, também conhecido como SW- CMM, tem seu foco no processo de software da mesma forma que no produto, pois entende que a qualidade de um sistema de software é fortemente influenciada pela qualidade do processo que é utilizado para desenvolvê-lo e mantê-lo. Pois ao enfocar apenas o produto perde-se conhecimento de como produzi-lo melhor. O SW-CMM, segundo Belloquim, tornou-se ao longo de uma década de uso por várias organizações de software de diversos tamanhos e setores, o modelo mais conhecido, usado e respeitado pela comunidade de engenharia de software. Pelo fato de ser um modelo baseado nas experiências reais de organizações bem sucedidas no desenvolvimento de software, fez com que as práticas que recomenda sejam eficientes e eficazes, não sendo apenas um modelo meramente teórico. Segundo Furlan, o CMM é descritivo, não prescritivo, concentra-se no questionamento, e não na resposta. Não se propõe a resolver problemas, mas ajudar as organizações a encontrar suas próprias soluções. Também não é proposta de auto-ajuda, mas sim um modelo estabelecido em bases racionais que para obter sucesso, requer apoio da gerência, bom domínio de conhecimento, habilitação técnica, participação e esforço de todos os envolvidos.

51 Família de Modelos CMMI Na esteira do sucesso do SW-CMM diversos outros modelos foram criados, procurando cobrir outras áreas de interesse não cobertas pelo modelo. Uma breve descrição destes modelos é dada na Tabela 5. Tabela 5 - Disciplinas CMMI MODELO Software Acquisition CMM (SA-CMM) Systems Engineering CMM (SE-CMM) Integrated Product Development CMM (IPD-CMM) People CMM (P- CMM) CARACTERISTICAS Avalia a maturidade de uma organização em seus processos de seleção, compra e instalação de software desenvolvido por terceiros Avalia a maturidade da organização em seus processos de engenharia de sistemas, concebidos como algo maior que o software. Um sistema inclui o software, o hardware e quaisquer outros elementos que participam do produto completo. Ainda mais abrangente que o SE-CMM, inclui também outros processos necessários à produção e suporte ao produto, tais como suporte ao cliente e processos de fabricação. Avalia a maturidade da organização em seus processos de administração de recursos humanos no que se refere a software, recrutamento e seleção, treinamento e desenvolvimento de profissionais. O surgimento destes modelos gerou alguns problemas, tornando-se necessário uma padronização. Dentre estes problemas destacam-se: nem todos usavam a mesma terminologia, sendo que um mesmo conceito podia receber nomes diferentes em cada modelo; a estrutura carecia de um formato padrão, pois os modelos tinham números diferentes de níveis ou formas diferentes de avaliar o processo; alto custo de treinamento, avaliação e harmonização para organizações que tentasse usar mais de um modelo. Com uma década de uso do SW-CMM, foram identificados pontos em que o modelo poderia ser melhorado. Além disso, a ISO, em conjunto com a

52 52 comunidade internacional, através do projeto SPICE, (Software Process Improvement and Capability Determination), vinha desenvolvendo desde 1993 uma norma internacional para avaliação de processos denominada norma ISO 15504, sendo necessário tornar o CMM compatível com a mesma. A norma ISO (1997) define um modelo bi-dimensional que tem por objetivo a realização de avaliações de processos de software com foco na melhoria dos processos (gerando um perfil dos processos, identificando os pontos fracos e fortes, que serão utilizados para elaboração de um plano de melhorias) e na determinação da capacidade dos processos viabilizando a avaliação de um fornecedor em potencial. Com o objetivo de gerar uma nova versão do CMM que minimizassem os problemas citados acima, o SEI iniciou um projeto chamado CMMI (CMM Integration). A primeira idéia era integrar os diversos CMMs numa única estrutura, todos com a mesma terminologia, processos de avaliação e estrutura que fosse compatível com a norma ISO 15504, de modo que as avaliações em um modelo fossem reconhecidas como equivalentes as avaliações do outro, incorporando ao CMM as sugestões de melhoria surgidas ao longo dos anos. O CMMI resultou da integração dos seguintes modelos: SW-CMM V2C Capability Maturity Model for Software V2.0, draft C. SECM-EIA Interim Standard 731 System Engineering Capability Model. IPD-CMM Integrated Product Development Capability Maturity Model, draft Esses três modelos foram selecionados por serem muito difundidos nas comunidades de Engenharia de Software e Engenharia de Sistemas, e também por seus diferentes enfoques na melhoria do processo organizacional.

53 53 A primeira versão do CMMI (versão 1.0) foi lançada em agosto de 2000, e a versão 1.1 foi lançada em março de Além da integração dos modelos e redução dos custos com melhorias de processo, os seguintes objetivos também fazem parte do projeto CMMI: eliminar inconsistência e reduzir duplicidades; utilização de terminologia comum e estado consistente; assegurar a consistência com a norma ISO/IEC 15504; sensibilidade às implicações dos esforços ligados; auxiliar as empresas a conhecerem e melhorarem seus processos de desenvolvimento e manutenção de software; aumento do foco das atividades; integração dos processos existentes; flexibilidade e extensão para outras disciplinas; fornecer uma estrutura conceitual para guiar as empresas para obterem controles de seus processos, com melhoria contínua de seus produtos de software. 4.4 A Estrutura do CMMI O CMMI está estruturado em quatro áreas de conhecimento: Engenharia de Sistemas, Engenharia de Software, Desenvolvimento do Processo e Produto Integrado e Contrato de Fornecedores. A Tabela 6 descreve o objetivo geral de cada uma destas áreas de conhecimento. Estas áreas de conhecimento também são denominadas disciplinas.

54 54 Tabela 6 Abordagens do CMMI DISCIPLINAS Engenharia de Sistemas Engenharia de Software Desenvolvimento do processo e Produto Integrado Contrato de Fornecedores CARACTERISTICAS Compreende o desenvolvimento do sistema como um todo podendo incluir ou não o software. O foco é dado nas necessidades do consumidor, expectativas e restrições para o desenvolvimento dos produtos e suporte aos mesmos. Cobre o desenvolvimento de sistemas de software. Foco na aplicação de uma abordagem sistemática, disciplinada e quantitativa para desenvolver, operar e manter o software. É uma abordagem sistêmica que busca colaboração dos interessados, através da vida do produto para melhor satisfazer as necessidades, expectativas e requisitos do cliente. Cobre a aquisição de produtos de fornecedores, através do monitoramento das atividades dos fornecedores antes da entrega do produto. O CMMI fornece modelos com foco em disciplinas individuais e em disciplinas combinadas. A escolha da disciplina varia de acordo com o escopo da organização na qual será implementado o modelo. As disciplinas são estruturadas em áreas de processo. Uma área de processo corresponde a um conjunto de melhores práticas em uma determinada área que, quando implementadas coletivamente, satisfazem um conjunto de objetivos considerados importantes para levar a melhorias significantes nesta área. As vinte cinco áreas de processos que compõem o CMMI estão descritas resumidamente a seguir: 1. Foco no Processo Organizacional (OPF - Organizational Process Focus): o propósito desta área de processo é planejar e implementar melhorias no processo organizacional, através do entendimento dos pontos positivos e negativos dos processos da organização. 2. Definição de Processo Organizacional (OPD - Organizational Process Definition): o objetivo desta área é estabelecer e manter um conjunto de itens de processo organizacional usável por toda organização. Estes itens incluem a descrição do processo, tarefas e atividades do processo, descrição de modelos

55 55 de ciclo de vida, guia de execução de processo, dados e documentação do processo. 3. Treinamento Organizacional (OT - Organizational Training): esta área está relacionada com o desenvolvimento das habilidades e conhecimentos dos colaboradores para que eles possam desempenhar seu trabalho de forma efetiva e eficiente. 4. Desempenho do Processo Organizacional (OPP - Organizational Process Perform): o propósito desta área é estabelecer e manter um entendimento quantitativo da capacidade dos processos padrões em suportar objetivos de qualidade e de desempenho, visando colher os dados necessários ao gerenciamento quantitativo dos projetos da organização. 5. Desenvolvimento e Inovação Organizacional (OID - Organizational Innovation and Deployment): o objetivo desta área é permitir a seleção e distribuição ordenada de melhorais (incrementais e inovadoras) que podem aumentar a habilidade da organização para alcançar os seus objetivos de qualidade e desempenho do processo. 6. Planejamento de Projeto (PP Project Planning): o objetivo desta área compreende o estabelecimento e manutenção de planos que definam as atividades do projeto. 7. Controle e Monitoramento de Projeto (PMC - Project Monitoring and Control): o propósito desta área é proporcionar um entendimento do processo utilizado em um projeto, de tal forma que ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto desvia significativamente do plano estabelecido.

56 56 8. Gerência de Contrato de Fornecedores (SAM Supplier Agreement Management): esta área gerencia a aquisição de produtos de fornecedores de forma que exista um contrato formal. 9. Gerência de Projeto Integrado (IPM Integrated Supplier Management): esta área estabelece e gerencia o projeto e o envolvimento dos stakeholders relevantes (indivíduos ou grupos envolvidos com o projeto, como fornecedores, clientes, usuários, e outros), de acordo com um processo definido e integrado baseado nos processos padrões da organização. 10. Gerência de Riscos (RSKM Risk Management): o objetivo desta área é identificar potenciais problemas antes que eles ocorram, através do planejamento e execução de atividades específicas em situações de riscos, visando atenuar os impactos adversos que possam influenciar no alcance aos objetivos. 11. Gerência Quantitativa de Projeto (QPM Quantitative Project Management): o propósito desta área é gerenciar quantitativamente o processo definido para o projeto, visando atingir os objetivos de qualidade e de desempenho estabelecidos para o mesmo. 12. Gerência de Requisitos (REQM Requirements Management): esta área de processo tem o propósito de gerenciar os requisitos dos produtos do projeto e seus componentes, e identificar inconsistências entre estes requisitos e os estabelecidos no plano. 13. Desenvolvimento de Requisitos (RD Requirements Development): o objetivo desta área de processo é produzir e analisar os requisitos do cliente, do produto e dos componentes do produto, de modo que supram as necessidades das pessoas envolvidas com o projeto.

57 Solução Técnica (TS Technical Solution): o propósito desta área é projetar, desenvolver e implementar soluções para os requisitos, abrangendo produtos, componentes de produtos e produtos do ciclo de vida do processo, cada um individualmente ou combinados. 15. Integração de Produto (PI Product Integration): o objetivo desta área é reunir todos os componentes do produto, e assegurar que o produto, quando integrado, funciona bem. 16. Verificação (VER Verification): o objetivo é garantir que os produtos de trabalho estão de acordo com os requisitos especificados. 17. Validação (VAL Validation): o objetivo é demonstrar que o produto ou seus componentes cumpre seu uso desejado quando mantido em ambiente específico. 18. Gerência da Configuração (CM Configuration Management): tem como propósito estabelecer e manter a integridade dos produtos de trabalho usando identificação, controle, relatório de status e auditoria da configuração, durante todo ciclo de vida. 19. Garantia de Qualidade de Produto e Processo (PPQA Process and Product Quality Assurance): o objetivo desta área é garantir a entrega de produtos e serviços de alta qualidade, através da avaliação da qualidade do processo de desenvolvimento. 20. Medições e Análises (MA Measurement and Analysis): o objetivo desta área é desenvolver e sustentar uma capacidade de medição usada para suportar o gerenciamento das informações necessárias.

58 Resolução e Análise de Decisão (DAR Decision Analysis and Resolution): o propósito desta área é analisar decisões usando um processo da avaliação formal que avalia as possíveis alternativas e estabelece critérios. 22. Resolução e Análise das Causas (CAR Causal Analysis and Resolution): o objetivo desta área é analisar as causas dos defeitos e de outros problemas e tomar atitudes para que eles não voltem a ocorrer no futuro. 23. Gerência Integrada de Fornecedores (ISM Integrated Supplier Management): o propósito desta área é identificar origens de produtos que possam ser utilizados para satisfazer os requisitos do projeto e gerenciar fornecedores selecionados, e ao mesmo tempo, manter um relacionamento cooperativo com os fornecedores. 24. Integração do Time (IT Integrated Teaming): essa área de processo tem como propósito formar e manter um time integrado para o esenvolvimento dos produtos. 25. Ambiente Organizacional para Integração (OEI Organizational Environment for Integration): o objetivo desta área de processo é fornecer a infra-estrutura para o desenvolvimento integrado do produto e do processo bem como gerenciar a integração das pessoas.

59 59 As áreas de processo são estruturadas em componentes do modelo. A Figura 11 ilustra estes componentes e seus relacionamentos. Figura 11 - Componentes do modelo Os Objetivos Específicos descrevem o que deve ser atingido para satisfazer cada área chave de processo. As Práticas Específicas, por sua vez, descrevem o que deve ser executado para atingir cada objetivo específico. Os Objetivos Genéricos são assim chamados porque um mesmo objetivo é aplicado a múltiplas áreas de processo. E as Práticas Genéricas são atributos a serem observados que indicam se a implementação e a institucionalização de cada área de processo é efetiva, repetível e duradoura. 4.5 As Abordagens do CMMI O CMMI é apresentado em duas abordagens, Abordagem por Estágio (Staged) e Abordagem Contínua (Continuous). A Tabela 7 descreve resumidamente cada uma destas abordagens.