Implementação do CMMI na MedicineOne

Transcrição

1 Instituto Politécnico de Coimbra Instituto Superior de Engenharia de Coimbra Departamento de Engenharia Informática e de Sistemas Implementação do CMMI na MedicineOne Processos de Gestão de Configurações e de Garantia de Qualidade 2010 / Gonçalo José Freitas Carnaz

2 Implementação do CMMI na MedicineOne Processos de Gestão de Configurações e de Garantia de Qualidade 2010 / Gonçalo José Freitas Carnaz Mestrado em Informática e Sistemas Ramo Desenvolvimento de Software Dezembro, 2011 Orientador ISEC: Professor Doutor João Cunha Supervisor Externo: Engenheiro Carlos Graça

3 "Agradeço pela crítica mais severa apenas se ela permanecer imparcial." (Otto Bismarck) iii

4 Agradecimentos Começo com uma frase que muito aprecio, A satisfação está no esforço e não apenas na realização final. - Mahatma Gandhi, no esforço que realizei e pelas diversas pessoas que me ajudaram, que agradeço pela sua simpatia, disponibilidade e conhecimento. Agradeço a toda a equipa da MedicineOne, por formarem e deixarem-me integrar neste fantástico grupo de pessoas, em especial, ao João Miguel Domingos, pela facilidade com que transmite confiança, força de vontade e crença; ao Engenheiro Carlos Graça, pela disponibilidade, exigência e simplicidade na resolução de problemas; à Engenheira Cristina Coelho pela experiência transmitida, amizade, e pelas discussões saudáveis, finalmente ao Engenheiro Nuno Silva, pela sua disponibilidade, paciência e conhecimento. Agradeço ao Engenheiro Ricardo Jesus, da Critical Software, pela transmissão de conhecimentos, pela ajuda em decifrar o código CMMI, que ajudaram a sintetizar os conceitos e as ideias pré-feitas. Agradeço ao Professor Doutor João Cunha, pela sua exigência, disponibilidade, transmissão de conhecimento, e pela paciência quase infinita durante a escrita do relatório. Finalmente e não menos importante, à minha família, pelas minhas ausências, mesmo estando presente na mesma sala, que me ajudaram a ultrapassar esta batalha, pelos sorrisos dos meus filhos e pelo conforto da minha esposa. v

5 Resumo O presente relatório representa os meses de trabalho na recolha de informação, filtragem e compreensão do modelo CMMI e da sua implementação na Empresa MedicineOne e dos processos CM Configuration Management e PPQA Process and Product Quality Assurance, tem uma visão geral da criação do departamento de qualidade e do trabalho aí desenvolvido. O problema que tinha para resolver era: implementação dos processos CM e PPQA, integrado numa equipa, com o máximo de 3 colaboradores. Como foi resolvido? Estudei o CMMI em toda a sua plenitude, obtive formação e, finalmente, iniciei o processo de criação de todos os documentos de apoio à sua implementação. Neste momento os resultados só podem ser analisados de uma forma qualitativa, dado que são dois processos de suporte, que dependem de outros processos. De referi que, existe uma grande aceitação por parte de todos os colaboradores, em conversas informais e em conversas tidas nas reuniões CMMI. Apesar de acharem o processo complicado, têm tido uma avaliação muito boa, sobre a sua viabilidade e principalmente sobre as vantagens do mesmo para a MedicineOne. Palavras Chave (Tema): Processos, Procedimentos e Qualidade. Palavras Chave (Tecnologias): CMMI, Sistemas de Gestão de Configurações e Sharepoint. vii

6 Índice Agradecimentos... v Resumo...vii Índice... ix Índice de Figuras... xi Notação e Glossário MedicineOne MedicineOne O Produto Departamento de Qualidade A MedicineOne antes do Departamento de Qualidade A MedicineOne depois do Departamento de Qualidade Os Capability Maturity Models O Capability Maturity Model Integration ( CMMI ) O Objectivo do CMMI e os Corpos do Conhecimento As Diferentes Abordagens Representação Contínua Representação Faseada Componentes das áreas de processo Relações entre as Áreas de Processo Gestão de Processos Gestão de Projectos Engenharia Suporte Benefícios na Implementação do CMMI Qualidade Entrevista Necessidade e Vontade para o CMMI MedicineOne e a Qualidade ix

7 4.4 Os resultados do CMMI em diversas empresas Processo CM Objectivo Práticas Específicas Objectivos Genéricos Implementação SG 1 Estabelecer as Baselines SG 2 Acompanhar e Controlar as Mudanças SG 3 Estabelecer a Integridade Resultados Processo PPQA Objectivo Práticas Especificas Objectivos Genéricos Implementação do Processo SG 1 Avaliar objectivamente os processos e os produtos de trabalho SG 2 Fornecer visibilidade Resultados Bibliografia...61 Conteúdos em anexos...63 x

8 Índice de Figuras Ilustração 1 - Webpage 5 Ilustração 2 - Ultima versão do produto Ilustração 3 Procedimento para a execução de testes Ilustração 4 Checklist Internamento Ilustração 5 - Representação Faseada[3] Ilustração 7 Áreas de Processo[3] Ilustração 8 Gestão de Processos Ilustração 9 Gestão de Projectos Ilustração 10 - Engenharia Ilustração 11 Sharepoint Quality Assurance Page Ilustração 13 TFS Ilustração 14 ALM MedicineOne Ilustração 15 OnTime Ilustração 16 Worflow Steps Ilustração 17 Esquema SP PPQA Ilustração 18 Organização dos Registos PPQA xi

9 Notação e Glossário CMMI Capability Maturity Model Integration PPQA Process and Product Quality Assurance CM Configuration Management SG Specific Goals SP Specific Practices TFS Team Foundation Server ALM Application Life Cycle Management SEI Software Engineering Institute CMM Capability Maturity Model 1

10 1. Introdução Em linguagem comum, o termo "Qualidade" designa um modo de ser e de actuar, um software de qualidade: "este software é realmente muito bom, mas tem alguns erros!". A utilização dos termos pode ser ambígua porque subentende, muitas vezes, o que se faz de melhor, enquanto etimologicamente o significado está mais relacionado com a conformidade ou a aptidão para desempenhar uma certa função. Mas como obter qualidade? Que passos? Que caminho tenho/temos de percorrer? Com o "abrir" das fronteiras físicas e virtuais, as empresas portuguesas enfrentam as poderosas empresas multinacionais, que cada vez mais vêm ganhando credibilidade e enorme espaço no mercado português. Neste contexto de exigência a "conversão à qualidade", não só à qualidade dos seus produtos, mas também dos seus processos, as empresas portuguesas necessitam mostrar que podem ser uma alternativa válida e confiável para todos os clientes. Em qualquer empresa encontramos estes aspectos, de conformidades e de aptidões, e a MedicineOne, não foge à regra. Na história da industrialização, o Taylorismo permitiu desenvolver esta noção de conformidade (um grande número de modelos idênticos). Esta abordagem, hoje muito criticada, permitiu à Ford fornecer o modelo T muito apreciado no contexto económico da época. A concorrência, como falamos atrás, devido à industrialização, tornou-se muito intensa. Para estarem seguros das suas escolhas, os potenciais clientes têm necessidade de confiar nas aptidões dos seus fornecedores. A Norma ISO 9000 é importante pois certifica uma aptidão destinada a tranquilizar o cliente, porém o CMMI não sendo uma norma de qualidade, mas a definição de processos, procedimentos e normas que permitem trilhar um caminho para qualidade, isso não exclui a implementação da Norma ISO O termo qualidade, por ser ambíguo, foi definido ao nível da ISO, "qualidade, aptidão de um conjunto de características intrínsecas para satisfazer as exigências"[4]. O objectivo do meu estágio é a implementação do CMMI na MedicineOne, tendo como responsabilidade a implementação e disseminação dos processos CM Configuration Management e PPQA Process and Product Quality Assurance, em equipa com colaboradores da MedicineOne. Sendo assim, o objectivo final é atingir a qualidade como meta (qualidade de processos e produto), passando por todos os 2

11 passos que permitam chegar a essa meta, iniciando assim o processo de certificação CMMI. Esse processo teve início em 2010 com a realização de uma formação a diversos elementos da equipa de desenvolvimento, gestores de projecto e qualidade, e a divisão de equipas, para os diferentes processos do CMMI. O relatório está organizado da seguinte forma, numa parte inicial, a descrição da empresa MedicineOne e do seu principal produto - MedicineOne. Depois, foca-se o departamento de qualidade, o antes e depois da sua existência na empresa, e as minhas funções neste. Dado que o relatório se centra no CMMI, existe um capítulo dedicado ao estado da arte do CMMI, passando depois à vontade da empresa MedicineOne para a implementação do CMMI. Finalmente apresenta-se a descrição, implementação e resultados implementação obtidos com os processos CM e PPQA. 3

12 2. A Empresa Neste capítulo é efectuada uma breve descrição da empresa, do produto MedicineOne, do departamento de qualidade, e do trabalho que desenvolvo em paralelo com a implementação do CMMI e de algumas métricas do produto. 2.1 MedicineOne A MedicineOne é uma empresa sedeada em Coimbra e que se dedica exclusivamente ao desenvolvimento e manutenção de soluções de software para a área da saúde. Tem como principal objectivo criar inovação e qualidade que se traduza em mais-valia para os utilizadores das suas soluções. Ao longo de 19 anos, a MedicineOne (anteriormente denominada Consultórios) tem explorado e aberto novos caminhos na forma de utilizar software, conseguindo ser uma preciosa ajuda à sua comunidade de utilizadores que são, neste momento, mais de Ilustração 1 - Webpage O desenvolvimento dos produtos iniciou-se em Nessa altura, e durante muitos anos, o mercado da saúde em Portugal era extremamente reduzido. O grupo de médicos que estava disponível para experimentar as novas tecnologias, e disposto a investir o seu próprio dinheiro em ferramentas que deveriam ser adquiridas pelo Estado, era muito 5

13 pequeno. Este facto fez com que os primeiros anos se traduzissem num crescimento lento, mas sólido. Com a evolução da tecnologia, a comunidade de profissionais de saúde foi despertando para a necessidade de possuir ferramentas que fossem um apoio efectivo à prática clínica. O próprio Estado sentiu essa mesma necessidade e começaram a aparecer as primeiras instalações em pequenas extensões de Centros de Saúde e, posteriormente, em Centros de Saúde completos. Actualmente, as soluções permitem uma informatização completa na área clínica, e clínica administrativa, em unidades públicas e privadas de cuidados primários, unidades hospitalares e unidades de cuidados continuados. Possibilitam que os profissionais de saúde atinjam o seu potencial máximo na prestação de cuidados e no apoio às pessoas na melhoria da sua qualidade de vida. Presentemente a MedicineOne tem como clientes: EDP, TAP, Serviços Sociais da Câmara Municipal de Lisboa, Unidades Saúde Familiares (USF s), entre outros. A MedicineOne tem colaboradores de diferentes áreas de conhecimento: Engenharia, Gestão, Direito, Marketing e Design. 6

14 2.2 MedicineOne O Produto O produto MedicineOne é uma solução de gestão clínica integrada, centrada no utente, e concebida para dar resposta às diferentes necessidades das Unidades de Saúde nacionais. O MedicineOne gere toda a informação clínica e administrativa dos utentes, promovendo uma boa colaboração entre os profissionais através de workflows de trabalho integrados, optimizando os processos e apoiando a prática clínica no sentido de a tornar mais efectiva e isenta de erros. O produto MedicineOne é produzido e mantido pela MedicineOne, empresa sedeada em Coimbra, dedicada inteiramente ao desenvolvimento de soluções para a área da saúde. A MedicineOne mantém, desde há 19 anos, um estreito contacto com os profissionais de saúde e é em contacto com eles que desenvolve as suas ferramentas de gestão. Ilustração 2 - Ultima versão do produto. O produto MedicineOne é constituído por 13 módulos distintos: Medicina, Enfermagem, Recepção, Bloco Operatório, Internamento, Fisioterapia, Alimentação, Saúde Ocupacional, Stocks, Estatísticas, Qualidade, Simposium e Configuração. O produto sofre todos os meses a adição de novas funcionalidades. 7

15 2.3 Departamento de Qualidade Iniciei as minhas funções no departamento de qualidade da MedicineOne, que até então não existia. Fui, por isso, o primeiro elemento (neste momento somos 3), as minhas tarefas iniciais foram e continuam a ser: Criar o ambiente de teste para o MedicineOne e para a MedicineOne, integrando isso no processo de desenvolvimento; O Processo de Teste do MedicineOne (ainda em revisão); Bug Tracking (tarefa contínua e reiniciada a cada nova release); Teste de novas funcionalidades (tarefa contínua e reiniciada a cada nova release); Criação dos Casos de Testes para os diferentes módulos do produto (tarefa contínua e revista a cada nova release); Produção de Templates de documentos para os diferentes departamentos; Revisão de documentos produzidos. Nota: Devo referir que estive cerca de meio ano, apenas como o único elemento do departamento de qualidade. O crescimento do departamento de qualidade deveu-se ao crescimento do produto, e às necessidades inerentes desse crescimento, já que a introdução de uma linha de código, é fonte de um ou vários potenciais erros, e com o aumento da equipa de desenvolvimento houve a necessidade de aumentar a equipa de qualidade. Assim a integração de mais um elemento na equipa, foi possível, testar mais rápido e melhor. Para isso também contribuiu a experiência do novo elemento, que veio trazer um novo vigor, e uma entreajuda entre os elementos da equipa de qualidade (recentemente, Outubro de 2011, foi admitido mais um elemento na equipa). 8

16 2.3.1 A MedicineOne antes do Departamento de Qualidade Mas como era a MedicineOne antes do Departamento de Qualidade: Os testes eram realizados pelos Developers (existem imensos problemas com este cenário, pois quem desenvolve apenas testa ( Test to Pass), e não os cenários de Test to Fail); Nem sempre os bugs eram registados, o que não permitia ter métricas de qualidade; O tempo despendido nos testes era prejudicial para quem tinha apenas a função de programar; Não havia documentos, e os que existiam eram realizados de forma desgarrada, sem seguir um template, e o histórico de revisões era inexistente; Não existiam casos de testes; Não existia um procedimento de testes; Não havia ambiente de testes; Por isso a aposta no Departamento de Qualidade, era urgente A MedicineOne depois do Departamento de Qualidade Depois da criação do Departamento de Qualidade, ouve mudanças significativas, das quais passo a enumerar: Criou-se um procedimento para a execução dos testes; Os testes são realizados pela equipa de testes; Os bugs são registados no OnTime [5], a ferramenta de Bug Tracking, o que permite a medição (métricas); Aumentou-se o tempo de programação; Desenvolveu-se os documentos necessários para os testes: Especificação de Testes, Checklists de Testes (observe a Ilustração 3); Criou-se um ambiente de testes; Realizam-se Testes Automáticos. 9

17 Criou-se um procedimento para a execução de testes, que se encontra no Anexo 5 M1.PRD.QMS.Procedimento de Execução de Testes-v1.2, e que podemos observar a seguir: Ilustração 3 Procedimento para a execução de testes Na Ilustração 3, podemos observar o ciclo de testes, que o produto sofre, até que seja aprovado, nele são realizados os testes: Testes Funcionais de Features concluídas e Bugs corrigidos incluídos na release, testes automáticos e os testes funcionais a partir dos casos de teste. O procedimento segue um lógica, que assenta em features e bugs, sempre que estes não estejam testados, ou verificados, a release ou o hotfix não é aprovado, passando assim por um ciclos de testes. 10

18 Na Ilustração 4 podemos observar uma checklist que verifica as funcionalidades básicas e fundamentais para que o produto seja aprovado: Ilustração 4 Checklist Internamento A ferramenta utilizada para o bug tracking é o OnTime, que permite o registo dos bugs detectados, inserção de novas funcionalidades e registo de incidentes reportados pelos clientes ou parceiros da MedicineOne. OnTime - Ano Bug Fixed Bugs Fixed Gráfico 1- Resultados retirados do OnTime ( Ano 2010 ) Bugs Fixed 11

19 No Gráfico 1 podemos observar a evolução do número de bugs,entre o mês de Janeiro de 2010 e Dezembro de 2010, e que se encontravam no estado Bug Fixed (Bugs que foram corrigidos pelos Developers e por isso bugs que realmente existiam). OnTime - Ano 2011 ( Até Outubro )- Bug Fixed Bugs Fixed Gráfico 2- Resultados retirados do OnTime ( Ano 2011 até Outubro ) Bugs Fixed Era a altura em que o Departamento de Qualidade ainda estava em obras, onde os documentos que referi, como tarefas, estavam a ser criados, mas existe uma grande diferença, a partir de Junho de 2010, no Gráfico 2, isto deve-se ao facto da entrada de uma nova pessoa para o Departamento de Qualidade, com o trabalho que tinha vindo a ser iniciado por mim, a detecção de erros aumentou, mas não só pela eficiência que colocamos nos testes e na sua documentação, mas também pelo aumento das funcionalidades, o que produz mais erros, dado que os Developers introduzem mais código logo a probabilidade de introduzir mais erros. Mas o MedicineOne aumentou na sua estabilidade e qualidade, aumentou significativamente, isso pode ser observado no Gráfico 2, houve uma estabilização do número de bugs, dado que a maior parte destes bugs vêm das novas funcionalidades, logo o cliente não teve contacto com os bugs reportados. A utilização de uma ferramenta de testes automáticos (TestComplete), embora o desenvolvimento dos scripts para os testes, sejam trabalhosos, têm resultados óbvios quando pretendemos testar funcionalidade básicas ( operações CRUD Create,Read, Update e Delete), e isso foi uma peça fundamental para o incremento da qualidade do produto. 12

20 3. CMMI Estado da Arte Segundo o dicionário da língua portuguesa da Porto Editora, modelo significa imagem, desenho ou objecto que serve para ser imitado (desenhado ou esculpido). O que se pretende ao longo do meu relatório é isso mesmo, demonstrar que a partir de um modelo, pré-definido e testado, é possível de implementar o CMMI, esculpir de forma a adaptar-se à empresa MedicineOne. Neste capítulo, pretende-se efectuar uma introdução ao modelo de maturidade CMMI, onde irá ser dado a conhecer as suas origens, objectivos e principais características. Irão ser abordados, de uma forma geral, os modelos de maturidade, destacando a sua definição, no que disponibilizam e na necessidade da sua criação, sendo também disponibilizado uma tabela em que se encontram alguns modelos de maturidade existentes. O modelo CMMI tem dois tipos de representação, a representação faseada e a contínua, e iremos comparar as vantagens de cada uma delas, com destaque para a representação faseada (por estágios) que irá ser implementada pela MedicineOne. Será apresentado o processo de certificação que uma empresa terá de passar para atingir os diversos níveis do CMMI. Será ainda realizada uma abordagem às vantagens e desvantagens do modelo CMMI, referidas outras normas que implementam processos e qualidade do desenvolvimento de software, e identificadas as entidades que as certificam. 3.1 Os Capability Maturity Models O conceito de capability maturity model foi o primeiro descoberto e lançado pelo Software Engineering Institute (SEI). Este Instituto, pertencente à Carnegie Mellon University, descobriu diversas dimensões em que uma organização se pode concentrar em três dimensões consideradas críticas: Pessoas (com aptidões, treino e motivação ); Procedimentos e métodos (definindo as relações das tarefas); Ferramentas e equipamento. O que agrega estas dimensões são os processos usados na organização, os quais permitem o alinhamento da forma como se processa o negócio. Os processos permitem tratar do problema da escalabilidade e fornecem um meio de incorporar conhecimento sobre a forma de fazer melhor,e mais rápido. Permitem igualmente potenciar os recursos 13

21 organizacionais e examinar as tendências do negócio. Os processos proporcionaram a infra-estrutura necessária para lidar com a permanente mudança e para minimizar a competitividade do pessoal e da tecnologia. Actualmente, muitas organizações pertencentes às indústrias de serviços e de bens (produtos) reconhecem a importância de ter processos de qualidade. Os processos ajudam os recursos humanos de uma organização a atingir os objectivos de negócio, ao permitirlhes trabalhar de forma mais consciente e inteligente. Walter Shewart [6] foi o pioneiro da melhoria de processos, ao utilizar os princípios do controlo estatístico da qualidade, na década de Na década de 1980, Deming e Juran refinaram estes princípios. Seguiram-se-lhes Watts Humphrey, Ron Radice e outros, que ampliaram estes princípios e começaram a aplicá-los ao desenvolvimento de software na IBM e no SEI. Os princípios e conceitos básicos apresentados por Humphrey na sua célebre obra Managing The Software Process [Humphrey, 1989] serviram de base a muitos dos modelos de maturidade existentes actualmente. O SEI, ao afirmar que a qualidade de um sistema ou produto é grandemente influenciada pela qualidade dos processos usados para o desenvolver e manter, tomou a premissa da gestão dos processos e definiu modelos de maturidade que incorporam essa premissa. Os capatibily maturity models (CMM) têm como objectivo a melhoria dos processos numa organização, contêm os elementos essenciais de processos eficazes para uma ou mais disciplinas e descrevem o caminho de melhoria evolutiva desde a existência de processos imaturos, ad hoc, até à implementação de processos disciplinados e maduros com maior qualidade e eficácia. Um grupo do SEI liderado por Mark Paulk criou o primeiro CMM destinado a organizações de software, o qual foi publicado num livro editado pelo SEI The Capability Maturity Model: Guidelines for Improving the Software Process [SEI,1995]. O livro pegou nos princípios introduzidos quase um século antes e aplicou-os ao infindável ciclo de melhoria de processos. O tempo tem-se encarregado de provar o valor desta abordagem de melhoria de processos. Muitas empresas têm experimentado e relatado aumentos substanciais na produtividade e na qualidade, melhorias no ciclo de produção e maior precisão e previsibilidade nos orçamentos e nos prazos, basicamente, o que a MedicineOne pretende. Desde 1991, têm sido desenvolvidos CMM para um largo conjunto de disciplinas, Alguns dos mais notáveis incluem modelos para engenharia de sistemas, engenharia de software, 14

22 aquisição de software, gestão e desenvolvimento de pessoal e desenvolvimento integrado de produtos e processos. Embora se tenha provado a utilidade destes modelos para muitas organizações, o uso de múltiplos modelos tem-se revelado problemático. Muitas organizações gostariam de concentrar os seus esforços em melhorias interdisciplinares no seu seio. No entanto, as diferenças entre estes modelos orientados e específicos por disciplina (incluindo a sua arquitectura, conteúdo e abordagem) limitaram a capacidade de melhoria dessas organizações. 3.2 O Capability Maturity Model Integration ( CMMI ) Mais do que nunca as organizações procuram entregar produtos da melhor forma, mais rápida e mais económica, garantindo a qualidade. Em simultâneo, no ambiente de alta tecnologia do século XXI, quase todas as organizações estão a desenvolver produtos cada vez mais complexos, sendo rara a companhia que desenvolve todos os componentes que integram os seus produtos. Por outro lado, muitas organizações que não eram tipicamente empresas de software, como, por exemplo, instituições financeiras e fabricantes de automóveis e de aviões, descobriram que grande parte do seu negócio, depende de software e que este último constitui, muitas vezes, o seu diferenciador face à concorrência. Os problemas que estas empresas tratam actualmente envolvem software e engenharia de sistemas, tornando-se estas disciplinas uma parte cada vez mais crítica dos seus negócios. Em essência, essas organizações são fabricantes de produtos que necessitam de possuir uma abordagem integrada à sua engenharia de sistemas e ao seu software, como forma de alcançar os seus objectivos de negócio. No mercado actual existem modelos de maturidade, normas, metodologias e linhas de orientação que podem ajudar uma organização a melhorar a sua forma de fazer negócio. No entanto, a maioria das metodologias de melhoramento disponíveis centram-se numa parte específica do negócio e não fazem uma abordagem sistémica aos problemas que a maioria das organizações enfrenta. Por exemplo, existem muitos modelos de maturidade disponíveis, como o Capability Maturity Model for Software (SW-CMM) do SEI, que se concentra na melhoria do processo de produção de software, e o Systems Engineering Capability Model (SECM) da Electronics Industries Alliance ( EIA ), que se concentra na engenharia de sistemas. O CMMI proporciona uma oportunidade para evitar, ou mesmo eliminar esses estrangulamentos e barreiras através de modelos integrados que transcendem disciplinas. O CMMI engloba as melhores práticas que tratam do 15

23 desenvolvimento e manutenção de produtos e que cobrem o ciclo de vida do produto desde a concepção até à entrega e manutenção, é colocada uma ênfase na engenharia de sistemas e na engenharia de software em simultâneo, bem como na integração necessária para construir e manter o produto total. O projecto CMMI foi lançado com o objectivo de resolver o problema da utilização de múltiplos modelos de maturidade, através da combinação de três modelos base: Capabiliy Maturity Model for Software ( SW-CMM ) do SEI, agora na Versão 1.3; Systems Engineering Capability Model ( SECM ) da EIA; Integrated Product Development Capability Maturity Model ( IPD CMM ) da Enterprise Process Improvement Collaboration ( EPIC ). A selecção destes três modelos específicos deveu-se à sua adopção por muitas organizações das comunidades de software e engenharia de sistemas e às diferentes abordagens de melhoria de processos que lhes estão subjacentes. Desenvolveu-se um conjunto de modelos integrados, envolveram mais do que a simples combinação de vários modelos. Usando processos que promovem consensos, a equipa do CMMI construiu um modelo que acomoda múltiplas disciplinas e é suficientemente flexível para suportar as diferentes abordagens dos modelos que lhe serviram de fonte. A estrutura do CMMI foi desenhada igualmente com o propósito de suportar a futura integração de outras disciplinas. Para além disso, é consistente e compatível com o ISO/IEC Technical Report for Software Process Assessment [ISO, 1998]. Diversas versões do CMMI foram efectuadas desde 2001, para incorporarem milhares de pedidos de alteração e melhorias sucessivas. 16

24 3.3 O Objectivo do CMMI e os Corpos do Conhecimento O objectivo do CMMI é proporcionar um modelo de maturidade que não cubra apenas o desenvolvimento e manutenção de produtos e serviços, mas que possibilite também uma estrutura extensível que permita a incorporação de novos corpos de conhecimento. Actualmente estão disponíveis quatro corpos de conhecimento, ou disciplinas, para o planeamento de processos usando o CMMI: Engenharia de Sistemas (Systems Engineering SE) cobre o desenvolvimento de sistemas totais que podem incluir, ou não, software. Os engenheiros de sistemas concentram-se em transformar necessidades, expectativas e restrições de clientes, em produtos e em suportar esses produtos ao longo da respectiva vida; Engenharia de Software ( Software Engineering SW ) cobre o desenvolvimento de sistemas de software. Os engenheiros de software concentram-se na aplicação de metodologias sistemáticas, disciplinas e quantificáveis ao desenvolvimento, operação e manutenção de software; Desenvolvimento Integrado de Produtos e Processos ( Integrated Product and Process Development IPPD ) abordagem sistemática que visa uma colaboração, em tempo oportuno, de stakeholders relevantes, ao longo da vida do produto, com o objectivo de satisfazer as necessidades, expectativas e requisitos dos clientes; Uso de Fornecedores ( Supplier Sourcing SS ) abordagem sistemática da análise, selecção e gestão de fornecedores de um projecto ou organização. Uma área de processo (process area), na terminologia do CMMI, corresponde a um grupo de melhores práticas numa área que, quando implementadas colectivamente, satisfazem um conjunto de objectivos considerados importantes para a obtenção de melhorias significativas nessa área. Todos os CMM possuem áreas de processo definidas por níveis. 17

25 Para atingir os seus objectivos, uma organização tem que aplicar selectivamente as áreas de processo adequadas. A tabela seguinte mostra as áreas de processo para os diversos corpos de conhecimento: Corpos de conhecimento Áreas de Processo engenharia de sistemas Casual Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Measurement and Analysis (MA) Organizational Innovation and Deployment (OID) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Process Performance (OPP) Organizational Training (OT) Product Integration (PI) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Quantitative Project Management (QPM) Requirements Development (RD) Requirements Management (RM) Risk Management (RM) Supplier Agreement Management (SAM) Technical Solution (TS) Validation (VAL) Verification (VER) engenharia de software As mesmas que para a engenharia de sistemas. desenvolvimento integrado de produtos e processos As mesmas que para a engenharia de sistemas, mais estas duas: Integrated Teaming (IT) Organizational Enviroment for Integration (OEI) uso de fornecedores As mesmas que para a engenharia de sistemas, mais esta: Integrated Supplier Management (ISM) Tabela 1 - Áreas de processo do CMMI 18