Unidade IV. Unidade IV

Transcrição

1 Unidade IV 4 MODELOS DE QUALIDADE DE SOFTWARE 4.1 Introdução 1 As mudanças que estão ocorrendo nos clientes e nos ambientes de negócios altamente competitivos têm motivado as empresas a modificarem estruturas organizacionais e seus processos produtivos na área de software. Todavia, alcançar a competitividade pela qualidade implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. Como vem acontecendo com as empresas de outros setores, como, por exemplo, a indústria automobilística, as empresas de serviços da área médica, a indústria aeronáutica etc., a qualidade tem se tornado fator crítico de sucesso para a indústria de software. De acordo com o modelo MPS. BR (Melhoria de Processo do Software Brasileiro), para que o Brasil possua um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando a oferta de produtos de software e serviços correlatos conforme padrões (normas e modelos) internacionais de qualidade. Neste módulo serão apresentados os três principais modelos de qualidade de software que têm como foco a melhoria contínua da qualidade nos processos e produtos de software: o modelo MPS.BR, o modelo ISO/IEC 4 e o modelo CMMI-DEV. 90

2 QUALIDADE DE SOFTWARE 4.2 O modelo MPS.BR Introdução 1 Conforme o manual do MPS.BR, o foco principal do modelo brasileiro, é atender ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Outro fator importante é que ele seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo. O MPS.BR atende à necessidade de implantar os princípios de engenharia de software de forma adequada ao contexto das empresas brasileiras, estando em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software. Como em outros modelos internacionais, o MPS.BR baseiase nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos. Para atender a esses serviços, o MPS.BR foi organizado em três componentes: Modelo de Referência (MR-MPS4), Método de Avaliação (MA-MPS4) e Modelo de Negócio (MN-MPS4) Descrição geral do MPS.BR O MPS.BR é um programa brasileiro de qualidade de software lançado em dezembro de 03, coordenado pela Associação para Promoção da Excelência do Software Brasileiro (Softex). O programa conta com investimentos das empresas, da Softex, por meio do Banco Interamericano de Desenvolvimento (BID), e de outros parceiros como o Sebrae e o CNPq. 91

3 1 O MPS.BR está descrito através de documentos em formato de guias: o guia geral que contém a descrição geral do MPS.BR e detalha o Modelo de Referência (MR-MPS) com seus componentes e as definições comuns necessárias para seu entendimento e aplicação; o guia de aquisição que contém recomendações para a condução de compras de software e serviços correlatos e que foi descrito como forma de apoiar as instituições brasilerias que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS; o guia de implementação que contém orientações para a implementação dos sete níveis do Modelo de Referência MR-MPS; e o guia de avaliação que descreve o processo e o Método de Avaliação MA-MPS, tendo como base a norma internacional ISO/IEC 4 (Guerra & Colombo, 09). O MPS.BR tambem é um programa brasileiro de qualificação e certificação de empresas em processos de melhoria de qualidade de software. Ele atesta a excelência dos processos de desenvolvimento, engenharia, manutenção e aquisição de software em uma empresa, a um custo muito inferior ao similar internacional: o CMMI (Capability Maturity Model Integrated) Objetivos do MPS.BR 2 O modelo MPS.BR visa à melhoria de processos de software em empresas brasileiras, a um custo acessível, especialmente na grande massa de micro, pequenas e médias empresas e tem como objetivos: definir o Modelo de Referência para melhoria de processo de software (MR-MPS) para aplicação nas empresas brasileiras; disseminar o modelo, em diversos locais do país, da seguinte forma: - a capacitação no uso do modelo; 30 - o credenciamento de instituições implementadoras e avaliadoras do modelo, especialmente instituições de ensino e centros tecnológicos; 92

4 QUALIDADE DE SOFTWARE - a implementação e avaliação do modelo com foco em grupos de empresas. A figura apresenta uma visão do modelo MPS.BR e nela tem-se um padrão de definição e implementação do modelo: a partir de uma avaliação da realidade das empresas brasileiras e com o apoio da Softex, do governo e de universidades monta-se o modelo brasileiro de qualidade de software. Este modelo foi inspirado nos modelos internacionais CMMI da SEI (Software Engineering Institute) e do padrão ISO 4 (também denominado de SPICE). Para a implementação do modelo nas empresas brasileiras foram definidos dois tipos de instituições: 1 Instituições Credenciadas para Implementação (ICI), que têm como função o preparo das empresas para o uso do modelo; Instituições Credenciadas para Avaliação (ICA), que têm como foco a avaliação das empresas com relação à sua maturidade no desenvolvimento e na manutenção de software. Figura : Modelo para melhoria do processo de software brasileiro (componentes do modelo) MPS.BR CMMI-DEV ISO/IEC 127 SPICE (ISO/IEC 4) Modelo MPS.BR Modelo de referência (MR-MPS) Modelo de avaliação (MA-MPS) Modelo de negócios (MN-MPS) Guia geral Guia de aquisição Guia de avaliação Documentos do programa Guia de implementação 93

5 1 A base técnica para a construção e o aprimoramento deste modelo de melhoria e avaliação de processo de software é composta pelas normas ISO/IEC 127:08 (ISO/IEC, 08ª) e ISO/IEC 4-2 (ISO/IEC, 03). Uma avaliação MPS é realizada utilizando o processo e o método de avaliação MA- MPS descritos no guia de avaliação. Uma avaliação MPS verifica a conformidade de uma organização/unidade organizacional aos processos do MR-MPS. O modelo MPS é definido em consonância com a norma internacional ISO/IEC 127:08, adaptando-a às necessidades da comunidade de interesse. O modelo CMMI foi desenvolvido no SEI (Software Engineering Institute) a pedido do Departamento de Defesa dos Estados Unidos. Além disso, o framework CMMI foi desenvolvido para ser consistente e compatível com a ISO/IEC 4. Em 06, foi publicada a versão 1.2 do CMMI, o CMMI-DEV (CMMI for Development) (SEI, 06) Os níveis de maturidade do modelo MPS.BR Conforme descrito no modelo MPS.BR, os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS define sete níveis de maturidade: 2 A. em otimização; B. gerenciado quantitativamente; C. definido; D. largamente definido; E. parcialmente definido; 94

6 QUALIDADE DE SOFTWARE F. gerenciado; G. parcialmente gerenciado. 1 A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indica onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos para aquele nível. A divisão em sete estágios tem o objetivo de possibilitar uma implementação e uma avaliação adequadas às micros, pequenas e médias empresas. A possibilidade de se realizar avaliações, considerando mais níveis também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos. Os níveis de maturidade devem ser entendidos na sua complexidade de forma inversa às letras que os compõem, isto é, as empresas iniciam no nível G e vão ao longo do tempo evoluindo em direção ao nível A, que indica as empresas com o maior nível de maturidade. Nível G Parcialmente gerenciado Este nível apresenta duas áreas de processo, conforme mostra a tabela 1. O nível G é composto pelos processos: Gerência de Projetos e Gerência de Requisitos. 2 Tabela 1: Nível G de maturidade do modelo MPS.BR Áreas de processo Gerência de Requisitos GRE Objetivos O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. 9

7 O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. Gerência de Projetos GPR O propósito deste processo evolui à medida que a organização cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são incorporados, de forma que a gerência de projetos passa a ser realizada com base no processo definido para o projeto e nos planos integrados. No nível B, a gerência de projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da organização. Novamente, alguns resultados evoluem e outros são incorporados. Nível F Gerenciado Este nível apresenta cinco áreas de processo, conforme mostra a tabela 2. O nível de maturidade F é composto pelos processos do nível de maturidade anterior (G) acrescidos dos processos Aquisição, Garantia da Qualidade, Gerência de Configuração, Gerência de Portfólio de Projetos e Medição. Tabela 2: Nível F de maturidade do modelo MPS.BR Áreas de processo Aquisição AQU Gerência de Configuração GCO Garantia da Qualidade GQA Gerência de Portfólio de Projetos GPP Objetivos O propósito do processo Aquisição é gerenciar a aquisição de produtos que satisfaçam às necessidades expressas pelo adquirente. O propósito do processo Gerência de Configuração é estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos. O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos. O propósito do processo Gerência de Portfólio de Projetos é iniciar e manter projetos que sejam necessários, suficientes e sustentáveis, de forma a atender aos objetivos estratégicos da organização. Este processo compromete o investimento e os recursos organizacionais adequados e estabelece a autoridade necessária para executar os projetos selecionados. Ele executa a qualificação contínua de projetos para confirmar que eles justificam a continuidade dos investimentos, ou podem ser redirecionados para justificar. 96

8 QUALIDADE DE SOFTWARE Medição MED O propósito do processo Medição é coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais. Nível E Parcialmente definido Este nível apresenta quatro áreas de processo, conforme mostra a tabela 3. O nível de maturidade E é composto pelos processos dos níveis de maturidade anteriores (G e F), acrescidos dos processos Avaliação e Melhoria do Processo Organizacional, Definição do Processo Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização. O processo Gerência de Projetos sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com base no processo definido para o projeto e nos planos integrados. Tabela 3: Nível E de maturidade do modelo MPS.BR Áreas de processo Avaliação e Melhoria do Processo Organizacional AMP Definição do Processo Organizacional DFP Gerência de Recursos Humanos GRH Gerência de Reutilização GRU Objetivos O propósito do processo Avaliação e Melhoria do Processo Organizacional é determinar o quanto os processos-padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização a planejar, realizar e implantar melhorias contínuas nos processos com base no entendimento de seus pontos fortes e fracos. O propósito do processo Definição do Processo Organizacional é estabelecer e manter um conjunto de ativos de processo organizacional e padrões do ambiente de trabalho usáveis e aplicáveis às necessidades de negócio da organização. O propósito do processo Gerência de Recursos Humanos é prover a organização e os projetos com os recursos humanos necessários e manter suas competências adequadas às necessidades do negócio. O propósito do processo Gerência de Reutilização é gerenciar o ciclo de vida dos ativos reutilizáveis. 97

9 Nível D Largamente definido Este nível apresenta cinco áreas de processo, conforme mostra a tabela 4. O nível de maturidade D é composto pelos processos dos níveis de maturidade anteriores (G ao E), acrescidos dos processos Desenvolvimento de Requisitos, Integração do Produto, Projeto e Construção do Produto, Validação e Verificação. Tabela 4: Nível D de maturidade do modelo MPS.BR Áreas de processo Desenvolvimento de Requisitos DRE Integração do Produto ITP Projeto e Construção do Produto PCP Validação VAL Verificação VER Objetivos O propósito do processo Desenvolvimento de Requisitos é definir os requisitos do cliente, do produto e dos componentes do produto. O propósito do processo Integração do Produto é compor os componentes do produto, produzindo um produto integrado consistente com seu projeto, e demonstrar que os requisitos funcionais e não funcionais são satisfeitos para o ambiente-alvo ou equivalente. O propósito do processo Projeto e Construção do Produto é projetar, desenvolver e implementar soluções para atender aos requisitos. O propósito do processo Validação é confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido. O propósito do processo Verificação é confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente aos requisitos especificados. Nível C Definido Este nível apresenta três áreas de processo, conforme mostra a tabela. O nível de maturidade C é composto pelos processos dos níveis de maturidade anteriores (G ao D), acrescidos dos processos Desenvolvimento para Reutilização, Gerência de Decisões e Gerência de Riscos. 98

10 QUALIDADE DE SOFTWARE Tabela : Nível C de maturidade do modelo MPS.BR Áreas de processo Desenvolvimento para Reutilização DRU Gerência de Decisões GDE Gerência de Riscos GRI Objetivos O propósito do processo Desenvolvimento para Reutilização é identificar oportunidades de reutilização sistemática de ativos na organização e, se possível, estabelecer um programa de reutilização para desenvolver ativos a partir de engenharia de domínios de aplicação. O propósito do processo Gerência de Decisões é analisar possíveis decisões críticas usando um processo formal, com critérios estabelecidos, para avaliação das alternativas identificadas com seu projeto, e demonstrar que os requisitos funcionais e não funcionais são satisfeitos para o ambientealvo ou equivalente. O propósito do processo Gerência de Riscos é identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto. 1 Nível B Gerenciado quantitativamente Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao C). Neste nível o processo de Gerência de Projetos sofre sua segunda evolução (Gerência de Projetos GPR), sendo acrescentados novos resultados para atender aos objetivos de gerenciamento quantitativo. Neste nível a implementação dos processos deve satisfazer aos atributos dos processos: o processo é executado, o processo é gerenciado, os produtos de trabalho do processo são gerenciados, o processo é definido, o processo está implementado e o processo é otimizado continuamente. A implementação dos processos selecionados para análise de desempenho deve satisfazer integralmente aos atributos de processo: o processo é medido e o processo é controlado. Este nível não possui processos específicos. Nível A Em otimização Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao B). Neste nível a 99

11 implementação dos processos deve satisfazer aos atributos de processo: o processo é executado, o processo é gerenciado, os produtos de trabalho do processo são gerenciados, o processo é definido, o processo está implementado e o processo é medido. A implementação dos processos selecionados para análise de desempenho deve satisfazer integralmente aos atributos de processo: o processo é medido e o processo é controlado. Os atributos de processo: o processo é medido e controlado; o processo é objeto de melhorias e inovações; e o processo é otimizado continuamente. Este nível não possui processos específicos. 4.3 O modelo ISO/IEC 4 (Software Process Assesment) Introdução 1 O modelo ou norma ISO/IEC 4 foi criado para harmonizar as diferentes abordagens de avaliação do processo de software. O modelo ou norma ISO/IEC 4 também é conhecido como projeto SPICE para avaliação de processos de software. SPICE significa Software Process Improvement and Capability determination e tem como objetivo produzir um relatório mais geral e abrangente que os modelos existentes e mais específico que a norma ISO Objetivos da ISO/IEC 4 O modelo tem dois objetivos: a melhoria dos processos; a determinação da capacidade de processos de uma organização. 0

12 QUALIDADE DE SOFTWARE Se uma organização tem por objetivo a melhoria de seus processos, a norma permite avaliar os processos e, a partir dessa avaliação, elaborar um plano de melhorias. A figura 11 mostra o uso da ISSO/IEC 4 para a melhoria de processos. Figura 11: Aplicação da ISO/IEC 4 para melhoria de processos Necessidades da organização e metas Melhoria de processos Melhorias institucionalizadas Contexto, restrições e objetivos Pedido Avaliação de processos Registro e perfis de capacidade Modelos e métodos Se a organização tem como objetivo avaliar um fornecedor obtendo o seu perfil de capacidade, ela deve definir os objetivos e o contexto da avaliação, como mostra a figura 12. O perfil de capacidade permite à organização contratante avaliar os riscos associados à contratação desse fornecedor. Figura 12: Aplicação da ISO/IEC 4 para a determinação da capacidade Requisitos Contexto, restrições e objetivos Pedido Determinação da capacidade do processo Avaliação de processo Registro e perfis de capacidade Relatório de capacidade Modelos e métodos 1

13 Os manuais da norma ou modelo 4 têm nove partes (Cortês & Chiossi, 01): Parte 1 Informativa: conceitos e guia introdutório. Parte 2 Normativa: um modelo de referência para processos e capacidade de processos. Descreve o modelo de duas dimensões a dimensão processo e a dimensão capacidades de processos. Parte 3 - Normativa: realizando uma avaliação. Contém os requisitos para a realização de uma avaliação de tal maneira que os resultados sejam repetíveis. Parte 4 Informativa: guia para realização de avaliações. Fornece orientações para uma avaliação em vários contextos. 1 Parte Informativa: um modelo de avaliação e guia de indicadores. Fornece um modelo de referência detalhado para a realização de uma avaliação. Parte 6 Informativa: guia para competência de assessores. Descreve os requisitos para a qualificação de avaliadores. 2 Parte 7 Informativa: guia para uso em melhoria de processos. Apresenta orientações para o uso do modelo para fins de melhoria de processos. Parte 8 Informativa: guia para uso na determinação da capacidade de processos de fornecedores. Apresenta orientações para o uso do modelo para fins de avaliação da capacidade de um fornecedor em potencial. Parte 9 Informativa: vocabulário utilizado na norma. 2

14 QUALIDADE DE SOFTWARE O modelo de referência parte 2 documenta um conjunto universal de processos da engenharia de software que são fundamentais para uma boa engenharia de software, cobrindo as atividades de melhores práticas. Ele descreve processos que uma organização pode realizar para adquirir, fornecer, desenvolver e operar software e os atributos de processos que caracterizam a capacidade desses processos. O propósito do modelo de referência é fornecer uma base comum para modelos e métodos diferentes para avaliação de processos de software, garantindo que os resultados de avaliação possam ser relatados num contexto comum As dimensões do modelo de referência A arquitetura do modelo de referência é de duas dimensões: 1. A dimensão processo 1 É caracterizada pela declaração dos propósitos do processo, que são os objetivos essenciais e quantificáveis de um processo. Essa dimensão foi fortemente baseada na norma ISO/IEC 127. Ela apresenta cinco categorias de processos, conforme apresentadas na figura 13, e suas siglas são: 2 CUS (customer-supplier) cliente-fornecedor: estão nessa categoria os processos que afetam diretamente o cliente, desde a aquisição, fornecimento, instalação e assistência técnica. ENG (engineering) engenharia de software: esse grupo de processo tem o objetivo de transformar requisitos em um produto de software e foi subdividido em sete subprocessos ou componentes. 3

15 SUP (support) apoio: os processos de apoio ou suporte, em número de oito, podem ser usados por quaisquer dos demais processos em qualquer ponto do ciclo de vida do software. MAN (management) gestão: essa categoria consiste de quatro processos que contêm práticas de natureza geral, afetando qualquer pessoa que execute tarefas gerenciais, em qualquer ponto do ciclo de vida. ORG (organization) organização: essa categoria de processos consiste de seis processos associados às atividades gerais da organização, desde os objetivos do negócio até a gestão de recursos humanos. Figura 13: Estrutura ou arquitetura da dimensão de processos Processos primários CUS.1 - Aquisição CUS.2 - Fornecimento CUS.3 - Elicitação de requisitos CUS.4 - Operação ENG.1 - Desenvolvimento ENG.2 - Manutenção Processos de apoio SUP.1 - Documentação SUP.2 - Gestão configuração SUP.3 - SQA SUP.4 - Verificação SUP. - Validação SUP.6 - Revisão SUP.7 - Auditoria SUP.8 - Solução de problemas Processos organizacionais MAN.1 - Gestão MAN.2 - Gestão de projeto MAN.3 - Gestão da qualidade MAN.4 - Gestão de risco ORG. 1 - Alinhamento ORG. 2 - Melhoria ORG. 3 - RH ORG. 4 - Infraestrutura ORG. - Medidas ORG. - Reuso 4

16 QUALIDADE DE SOFTWARE 2. A dimensão de capacidade de processo Estabelece uma escala de capacidade de processo em geral. A capacidade é definida em uma escala de seis níveis crescentes, desde o nível inferior, o nível 0, até o nível superior, o nível. Esses níveis são caracterizados por uma série de atributos de processo aplicáveis para qualquer processo, que representam características quantificáveis necessárias para gerenciar um processo e melhorar sua capacidade de realização. Cada atributo de processo descreve um aspecto de todas as capacidades de gerenciamento e melhoria da efetividade de um processo na busca de seus propósitos e contribuição para as metas de negócio da organização. 1 Há nove atributos de processo (PA) que são agrupados nos níveis de capacidade, como mostrado na figura 14. Figura 14: Os atributos de processo e os seis níveis de capacidade Atributos de processo PA 1.1 PA 2.1 PA 2.2 PA 3.1 PA 3.2 PA 4.1 PA 4.2 PA.1 PA.2 Níveis de capacidade nomes dos atributos de processo Nível 0 - Incompleto Nível 1 - Executado Atributo de execução de processo Nível 2 - Gerenciado Atributo de gestão de execução Atributo de gestão de produto de trabalho Nível 3 - Estabelecido Atributo de definição de processo Atributo de recursos de processo Nível 4 - Previsível Atributo de definição de processo Atributo de recursos de processo Nível Em Otimização Atributo de mudança de processo Atributo de melhoria contínua

17 Os níveis de capacidade constituem uma maneira racional de progredir na melhoria da capacidade dos processos. Esses níveis são conceitualmente os mesmos níveis de maturidade do modelo CMM, embora aplicados para o processo em vez da organização. Nível 0 Incompleto: o processo falha no seu propósito, pois não existe uma clara identificação dos produtos ou saídas do processo em que os resultados sejam realmente alcançados Nível 1 Executado: o propósito do processo é geralmente alcançado. A realização do processo não é rigorosamente planejada e controlada. Todavia, existem produtos. Nível 2 Gerenciado: o processo fornece produtos de trabalho de acordo com os procedimentos especificados, planejados e controlados. Os produtos de trabalho são gerados conforme os padrões e requisitos especificados. Nível 3 Estabelecido: o processo é realizado e gerenciado usando um processo definido com base nos bons princípios de engenharia de software. Implementações individuais do processo usam versões adaptadas e aprovadas do processo-padrão para alcançar os resultados do processo. Nível 4 Previsível: o processo definido é executado de forma consistente na prática, definindo limites de controle para atingir os objetivos processo. Nível Em otimização: o desempenho do processo é otimizado para atender às necessidades de negócios atuais e futuros. O processo atinge repetibilidade na realização dos objetivos dos negócios definidos. 6

18 QUALIDADE DE SOFTWARE Conforme Côrtes & Chiossi (01), a filosofia do SPICE (ISO/IEC 4) baseia-se na verificação do grau de satisfação dos atributos de processos (PAs) apresentados na figura 14. A pontuação é feita em uma escala ordenada de quatro valores, escolhidos de acordo com um percentual de atendimento aos requisitos do atributo de processo, os quatro valores são: N (não atendido 0% a 1%); P (parcialmente atendido 16% a 0%); L (largamento atendido 1% a 8%) e T (totalmente atendido 86% a 0%) Conclusão Pode-se dizer que o SPICE é o modelo que herda e deverá substituir a ISO/IEC 127, sob pressão do CMM/CMMI e de outros modelos. Ele se encontra mais distante da ISO 9001 do que a ISO/IEC 127 e do que o CMM/CMMI, apesar de ser um projeto da ISO (Côrtes & Chiossi, 01). 4.4 O modelo CMMI-DEV adpatado do manual CMU/SEI-06-TR ESC-TR improving processes for better products Introdução Agora, mais do que nunca, as empresas querem oferecer produtos e serviços melhores, mais rápidos e mais baratos. Ao mesmo tempo, no ambiente de alta tecnologia do século XXI quase todas as organizações têm construído cada vez mais produtos e serviços complexos. Hoje, uma única empresa geralmente não desenvolve todos os componentes que compõem um produto ou serviço. Mais comumente, alguns componentes são construídos em casa, alguns são adquiridos no mercado e todos os componentes são integrados no produto ou serviço final. 7

19 1 2 As organizações devem ser capazes de gerir e controlar este processo complexo de desenvolvimento e manutenção. Os problemas destas organizações apontadas nos dias de hoje envolvem soluções para toda a empresa, que exigem uma abordagem integrada. Uma gestão eficaz dos ativos da organização é fundamental para o sucesso empresarial. No mercado atual, existem modelos de maturidade, normas, metodologias e diretrizes que podem ajudar uma organização a melhorar a forma como faz negócios. No entanto, as mais disponíveis concentram-se em uma parte específica do negócio e não têm uma abordagem sistêmica para os problemas que a maioria das organizações estão enfrentando. Ao se concentrar em melhorar uma área de uma empresa, estes modelos têm, infelizmente, perpetuado as barreiras que existem nas organizações. O Capability Maturity Model Integration (CMMI ) oferece uma oportunidade para evitar ou eliminar esses obstáculos por meio de modelos integrados que transcendem as disciplinas. O modelo CMMI-DEV para o desenvolvimento é constituído pelas melhores práticas que as atividades de desenvolvimento e manutenção indicam como aplicadas aos produtos e serviços. Dirige-se a práticas que cobrem o ciclo de vida do produto desde a concepção até a entrega e manutenção. A ênfase é sobre o trabalho necessário para construir e manter um produto total. 30 Em sua pesquisa para ajudar as organizações a desenvolver e manter a qualidade de produtos e serviços, o Software Engineering Institute (SEI) tem encontrado várias dimensões nas quais uma organização pode se concentrar para melhorar seus negócios. A Figura 1 ilustra as três dimensões críticas nas quais as organizações geralmente se concentram: pessoas; processos e métodos; e ferramentas e equipamentos. 8

20 QUALIDADE DE SOFTWARE Figura 1: As três dimensões críticas Procedimentos e métodos, definindo as relações de tarefas B A D C Pessoas com habilidades e motivação Ferramentas e equipamentos 1 Mas o que mantém tudo isso junto? Trata-se dos processos utilizados na organização. Processos permitem alinhar a maneira de fazer negócios. Eles permitem que se aponte para a escalabilidade e fornece uma maneira de incorporar conhecimento de como fazer as coisas melhor. Processos permitem alavancar recursos e examinar as tendências de negócios. Isso não quer dizer que as pessoas e a tecnologia não são importantes. Vive-se em um mundo onde a tecnologia está mudando por uma ordem de magnitude a cada dez anos. Da mesma forma, as pessoas normalmente trabalham para muitas empresas ao longo das suas carreiras, ou seja, vive-se em um mundo dinâmico. O foco no processo fornece a infraestrutura necessária para lidar com uma supramudança do mundo e para maximizar a produtividade das pessoas e do uso de tecnologia para ser mais competitivo. A Manufara há muito reconheceu a importância da eficácia e eficiência do processo. Hoje, muitas organizações de manufatura e de serviços reconhecem a importância dos processos de qualidade. Processo de ajuda a trabalhadores de uma organização para atender aos objetivos de negócio, 9

21 ajudando-os a trabalhar com melhor consistência. Processos eficazes que também fornecem um veículo para a utilização de novas tecnologias de uma forma que melhor atenda aos objetivos de negócio da organização. 1 2 Watts Humphrey, Ron Radice e outros aplicam os princípios da qualidade total para a área de software em seu trabalho na IBM, e Humphrey, em seu livro Managing the software process, fornece uma descrição dos princípios e conceitos básicos sobre os quais muitos dos modelos de capacidade de maturidade (CMMs ) se baseiam. O SEI tem divulgado a premissa de gestão de processos, a qualidade de um sistema ou de um produto é altamente influenciada pela qualidade dos processos utilizados para desenvolver e manter isso, e os modelos CMMs incorporam essa premissa. A crença nessa premissa é vista em todo o mundo em termos de movimentos da qualidade, como evidenciado pela ISO / IEC. Os modelos contêm os elementos essenciais de processos efetivos para uma ou mais disciplinas e descrevem um caminho de melhoria evolutiva ad hoc, processos imaturos disciplinados, processos maduros com melhor qualidade e eficácia. O valor da presente abordagem de melhoria de processos foi confirmado ao longo do tempo. As organizações têm experimentado o aumento de produtividade e qualidade, a melhoria no tempo de ciclo de desenvolvimento, cronogramas muito mais precisos e previsíveis e acerto nos orçamentos (Gibson, 06) Evolução do CMMI Desde 1991, os modelos CMMs têm sido desenvolvidos para diversas disciplinas. Alguns dos mais notáveis deles incluem modelos de sistemas de engenharia, engenharia de software, aquisição de software, gerenciamento de força de trabalho e desenvolvimento integrado de produtos, e desenvolvimento de processos (IPPD). Embora estes modelos tenham se mostrado 1

22 QUALIDADE DE SOFTWARE úteis para muitas organizações diferentes, o uso de vários modelos tem sido problemático. Muitas organizações gostariam que os seus esforços de melhoria abrangessem diferentes grupos em suas organizações. No entanto, as diferenças entre os modelos de disciplinas específicas utilizadas por cada grupo, incluindo a sua arquitetura, seu conteúdo e sua abordagem, têm limitado essas organizações a ampliar suas melhorias com êxito. Além disso, a aplicação de vários modelos que não estão integrados por meio da organização é dispendiosa em termos de treinamento, avaliação e melhoria das atividades. O projeto CMM Integration (CMMI) foi formado para resolver o problema do uso de diversos CMMs. A missão inicial do time de produto CMMI era combinar três modelos-fonte: O Capability Maturity Model for Software (SW-CMM) v2.0 projeto C (SEI 1997b). 2. O Systems Engineering Capability Model (SECM) (EIA 1998). 3. O Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 (SEI 1997a). A combinação desses modelos em um único quadro de melhoria foi utilizada por organizações na busca de toda empresa pela melhoria dos processos. Estes três modelos de fonte foram escolhidos devido a sua ampla adoção do software, engenharia de sistemas e comunidades, por causa de suas diferentes abordagens para a melhoria dos processos em uma organização. 30 Utilizando as informações destes modelos populares e o material bem considerado de origem, o CMMI Product Team criou um conjunto coeso de modelos integrados que podem ser 111

23 adotados por aqueles que usam atualmente os modelos-origens, assim como por aqueles que são novos para o conceito de CMM. Por isso, CMMI é um resultado da evolução do SW-CMM, o SECM e o IPD-CMM. Desenvolver um conjunto de modelos integrados envolveu mais do que simplesmente combinar materiais dos modelos existentes. Para a utilização de processos que promovam consenso, o CMMI Product Team construiu um quadro que acomoda múltiplas disciplinas e é flexível o suficiente para suportar as diferentes abordagens dos modelos de origem (Ahern, 03). A figura 16 mostra um quadro da evolução dos modelos CMMs: Figura 16: A história dos modelos CMMs History of CMMs CMM for software v1.1 (1993) INCOSE SECAM (1996) Systems Engineering CMM v1.1 (199) Software CMM v2, draft C (1997) EIA 731 SECM (1998) Integrated Product Development CMM (1997) CMMI for Acquisition v1.2 (07) v1.02 (00) v1.1 (00) CMMI for Development v1.2 (06) CMMI for Services v1.2 (07) 1 Fonte: Manual do CMMI-DEV, V 1.2, 06. Desde o lançamento do CMMI V1.1, o SEI notou que este quadro de melhoria pode ser aplicado a outras áreas de interesse. Para aplicar a várias áreas de interesse, os grupos do quadro de melhores práticas foram chamados de constelações. Uma constelação é uma coleção de componentes CMMI que são 112

24 QUALIDADE DE SOFTWARE usados para construir modelos, desenvolvimento de materiais (guias, apostilas, orientações etc.) e documentos de avaliação Objetivos do CMMI O CMMI foi montado para atender aos seguintes objetivos: 1 2 integrar os diversos modelos CMMs existentes, e, com isso, eliminar inconsistências e reduzir as duplicações; reduzir o custo de implementação de processo de melhoria baseado em modelos; aumentar a compreensão sobre a terminologia, estilo, regras e componentes dos modelos existentes; assegurar a consistência com a ISO 4 ou o SPICE que avalia a capacidade dos processos e não da organização, para isso o CMMI cria a representação contínua; considerar impactos sobre a utilização de modelos anteriores. Dessa forma, o CMMI melhora o modelo anterior SW-CMM e outras práticas ao: conectar mais explicitamente as atividades de gerenciamento e engenharia com os objetivos do negócio; expandir o escopo e a visibilidade do ciclo de vida do produto e atividades de engenharia ao assegurar que produtos ou serviços atendem às expectativas dos clientes; incorporar lições aprendidas de áreas adicionais de melhores práticas, isto é, medição, gerenciamento de riscos e gerenciamento de fornecedor; implementar práticas mais robustas de alta maturidade; 113

25 tratar funções organizacionais adicionais críticas para produtos e serviços; estar em maior conformidade com padrões ISO. Para isso, foram considerados relacionamentos entre diversos modelos mostrados na figura 17: Figura 17: Relacionamento entre os modelos SPICE ou ISO/IEC 4 CMM (P/SA/SE/SW CMM e PIPD- CMM) CMMI (por estágios e contínuo) Onde: 1 SPICE Software Process Improvement & Capability determination: modelo ISO/IEC 4 usado para melhoria de processo e determinação da capacidade de processo. P-CMM Personal Capability Maturity Model: avalia a maturidade da organização em seus processos de gerenciamento de recursos humanos naquilo que se refere ao software, ao recrutamento e à seleção de profissionais de tecnolologia da informação, treinamento e desenvolvimento, remuneração etc. SA-CMM Software Acquisition Capability Maturity Model: usado para avaliar a maturidade de uma 114

26 QUALIDADE DE SOFTWARE organização em seus processos de seleção, aquisição e instalação de software de terceiros. 1 SE-CMM System Engineering Capability Maturity Model: avalia a maturidade da organização em seus processos de engenharia de sistemas, concebidos como sendo algo maior que o software. Inclui hardware, software e outros elementos que participam do produto completo. SW-CMM Software Capability Maturity Model: usado para avaliar a maturidade de uma organização em seus processos de desenvolvimento de software. IPD-CMM Integrated Product Development Capability Maturity Model: mais abrangente que o SE-CMM; inclui processos necessários à produção e ao suporte para o produto, tais como suporte ao usuário, processos de fabricação, entre outros Agrupamentos do CMMI O modelo CMMI possui duas representações ou agrupamentos: o agrupamento ou a representação por estágio (staged); o agrupamento ou a representação contínua (continuous). Na prática, essas formas de representação determinam a forma pela qual a organização irá trabalhar com as áreas de processo do CMMI (Kulpa & Johnson, 03). A forma de agrupamento por estágios é mais conhecida e provém do CMM, ela estabelece uma estrutura na qual a organização irá evoluindo por meio dos níveis de maturidade dos seus processos, de acordo com a implantação das práticas de determinadas áreas de processo. O modelo integrado ainda organiza as áreas de processos (PAs) em quatro áreas de conhecimento para escolha da 11

27 1 2 organização quando da seleção de um modelo CMMI. As quatro áreas de conhecimento são: engenharia de sistemas, engenharia de software, produto e processo de desenvolvimento integrados e monitoramento (gestão) de fornecedores. Engenharia de sistemas cobre o desenvolvimento total de sistemas, que pode ou não incluir software. Ela é focada na transformação das necessidades dos clientes, expectativas, e restrições nas soluções dos produtos e suporte desses produtos a partir do ciclo de vida do produto. Quando a engenharia de sistemas é selecionada para ser o modelo, deve conter as áreas de processos: gerenciamento de processos, gerenciamento de projetos, suporte e engenharia de processos. Engenharia de software cobre o desenvolvimento de sistemas de software. Ela é focada na aplicação sistemática, disciplinada e na abordagem quantifícável para o desenvolvimento, operação e manutenção de software. Quando a engenharia de software é selecionada para ser o modelo, deve conter as áreas de processos: gerenciamento de processos, gerenciamento de projetos, suporte e engenharia de processos. Produto e processo de desenvolvimento integrados (IPPD) é uma abordagem sistemática que busca uma colaboração pontual dos stakeholders relevantes, a partir da vida do produto, para melhor satisfazer às necessidades, às expectativas e aos requisitos. 30 Os processos para suportar uma abordagem IPPD são integrados com outros processos na organização. As áreas de processos IPPD, especificam metas e práticas específicas que sozinhas não realizam o IPPD. Ele inclui: gerenciamento de processos, gerenciamento de projetos, e áreas de processos da engenharia que podem ser aplicadas em conjuntos com IPPD. 116

28 QUALIDADE DE SOFTWARE Monitoramento (gestão) de fornecedores, certos projetos podem usar fornecedores para realizar funções ou acrescentar modificações aos produtos que são necessários ao projeto. Quando essas atividades são críticas, o projeto se beneficia da análise dos fornecimentos e do monitoramento das atividades dos fornecedores antes da liberação do produto. A disciplina de monitoramento de fornecedores (supplier sourcing) cobre a aquisição de produtos de fornecedores nessas circunstâncias. Esta disciplina conterá: gerência de processos, gerência de projetos, suporte e áreas de processos da engenharia que se aplicam tanto para o supplier sourcing quanto para o modelo da organização Agrupamentos por estágio 1 2 O agrupamento por estágio tem foco na maturidade da organização e é organizado em cinco níveis de maturidade, que são: Inicial (nível 1): processo imprevisível, pouco controlado e reativo; o sucesso depende de heróis; Gerenciado (nível 2): processo caracterizado por projetos e, frequentemente, reativo; capacidade de gestão de projetos; Definido (nível 3): processo caracterizado para a organização, sendo proativo, processo comum adaptado às necessidades dos projetos; Quantitativamente gerenciado (nível 4): processo medido e controlado; capacidade de planejar estatisticamente a qualidade; Otimizado (nível ): foco na melhoria contínua do processo, capacidade de prevenir defeitos. 117

29 Os níveis de maturidade caracterizam um conjunto de práticas que, quando empregadas, conferem à organização uma determinada capacidade. Este agrupamento provê um caminho predefinido para a melhoria organizacional baseada em agrupamentos comprovados, ordenamento de processos e relacionamentos organizacionais associados. Segundo Chrissis, Konrad & Shurm (04) as áreas de processo (PA) são consideradas um grupo de práticas relacionadas, que quando implantadas coletivamente satisfazem às metas importantes para realizar uma melhora significativa naquela área ou naquele tema. A figura 18 mostra uma visão estrutural do modelo de agrupamento por estágios do manual do CMMI da SEI. 1 Figura 18: Visão estrutural do modelo por estágios Maturity Levels Níveis de Maturidade Process Area 1 Process Area 2 Process Area n PAs SG Specific Goals Generic Goals GG Common Features Commitement to Perform Ability to Perform Directing Implementation Verifyng Implementation Specific Practices SP Generic Practices GP 118

30 QUALIDADE DE SOFTWARE Nesta representação os níveis de maturidade (2 a ) proveem uma ordem recomendada para a abordagem de melhoria de processos (PAs - Process Area) em estágios. As PAs são organizadas em metas específicas (SG - Specific Goals) e metas genéricas (GG - Generic Goals). Já as metas genéricas são organizadas em práticas genéricas (GP - Generic Practices) e as metas específicas em práticas específicas (SP - Specific Practices). A figura 19 apresenta uma visão da organização dos níveis com seus focos e as áreas de processos (PAs) envolvidas em cada nível. Figura 19: CMMI por estágios Nível de maturidade 1 (inicial) 2 (gerenciado) 3 (definido) 4 (gerenciado quantitativamente) (otimizando) Foco Prática inconsistente ( Just do it ) Gerenciamento básico de projeto Padronização de processos Gerenciamento quantitativo Melhoria contínua Nenhuma Área de processo (PA - Process Area) Gerenciamento de requisitos Planejamento do projeto Acompanhamento e controle de projeto Gerenciamento de acordo com o fornecedor Medição e análise Garantia da qualidade de produto e processo Gerenciamento de configuração Desenvolvimento de requisitos Solução técnica Integração de produto Verificação Foco no processo organizacional Definição do processo organizacional Treinamento organizacional Gerenciamento integrado de projeto para IPPD Gerenciamento de riscos Integração de equipes Gerenciamento integrado de fornecedor Análise de decisão e resolução Ambiente organizacional para integração Desempenho organizacional do processo Gerenciamento quantitativo do projeto Inovação e implantação organizacional Análise de causa e resolução 7 PAs no nível 2 de maturidade 14 PAs no nível 2 de maturidade 2 PAs no nível 2 de maturidade 2 PAs no nível 2 de maturidade 119

31 Agrupamento contínuo 1 A outra forma de representação, a contínua, é dividida em categorias e não em níveis de maturidade, em que cada área de processo tem um nível de capacitação, ou seja, uma organização pode evoluir nas áreas de processo mais adequadas aos processos e à cultura de sua organização (Ahern, Clouse & Turner, 03). O foco desse agrupamento é a capacidade do processo e abrange o gerenciamento de processo, o gerenciamento de projeto, a engenharia e o suporte. Ele provê flexibilidade para as organizações escolherem quais processos devem enfatizar para buscar melhorias, bem como quanto devem melhorar em cada processo. Este agrupamento ou esta representação são contínuos e permitem que a organização selecione a ordem de melhorias que atenda aos objetivos de seu negócio e que mitigue as áreas de riscos. Permite o cruzamento entre organizações numa área de processo ou pela comparação de resultados através do uso de estágios equivalentes. Fornece uma migração fácil da Electronic Industries Alliance Interim Standard (EIA/IS) 731 para o CMMI e propicia uma comparação fácil da melhoria de processo da International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 4 devido à similaridade da organização das áreas de processo A figura mostra a representação contínua, sendo que o gráfico de barras mostra no eixo horizontal as áreas de processo (PAs) e no eixo vertical os níveis de maturidade ou capacidade de cada área de processo. O desenho inferior da figura mostra a organização das áreas de processo nas metas genéricas e específicas e estas nas práticas genéricas e específicas também. 1

32 QUALIDADE DE SOFTWARE Figura : CMMI contínuo CMMI contínuo Continuous Níveis de maturidade dos processos (PAs) Capability Áreas de processos (PAs) Áreas de processos (PAs) Process areas 1 Process areas 2 Process areas 3 Metas específicas Práticas específicas Specific goals Generic goals Metas genéricas Práticas genéricas Specific practices Capability levels Generic practices A organização contínua apresenta o nível de capacidade do processo em vez de nível de maturidade do CMMI por estágio. Cada PA (área de processo) é considerado isoladamente e recebe sua própria classificação que vai de 0 a, sendo que: 0 Incompleto; 1 Realizado; 2 Administrado; 3 Definido; 4 Administrado quantitativamente; Otimizado. Neste tipo de organização é possível uma organização estar no nível de capacidade 3 para gerenciamento de requisitos e 121

33 nível 2 para gerenciamento de configuração. Modelo ideal para empresas que buscam melhoria de processos a partir de um enfoque minimalista ou segmentado. A figura apresenta uma visão da organização das PAs do modelo contínuo por categoria e por áreas de processo. Categoria Gerenciamento de processo Gerenciamento de projeto Engenharia Suporte Organização contínua das áreas de processo Foco no processo organizacional Definição do processo organizacional Treinamento organizacional Desempenho do processo organizacional Implantação e inovação organizacional Planejamento de projeto Acompanhamento e controle de projeto Gerenciamento de acordo de fornecedor Gerenciamento integrado de projeto Gerenciamento de riscos Integração de equipe Gerenciamento integrado de fornecedor Gerenciamento quantitativo de projeto Gerenciamento de requisitos Desenvolvimento de requisitos Solução técnica Integração de produto Verificação Validação Gerenciamento de configuração Garantia de qualidade de produto e processo Medição e análise Análise de decisão e resolução Ambiente organizacional para integração Análise de causa e resolução As metas e as práticas dos agrupamentos por estágio e contínuo As metas genéricas e específicas são numeradas sequencialmente, por exemplo: SG 1 e SG 2. Com relação às práticas, elas são tratadas de forma diferente em cada agrupamento: Na representação por estágios, temos: 122

34 QUALIDADE DE SOFTWARE - cada prática genérica começa com GP, seguida de um número no formato x.y, como, por exemplo: GP 1.1, onde: x = número da meta/nível de capacidade e y= número sequencial da prática. Na representação contínua, temos: - Cada prática específica começa com SP seguida de um número no formato x.y-z, por exemplo: SP 1.1-1, onde: x = número da meta/nível de capacidade, y = número sequencial e z = ampliação do nível de capacidade. Exemplo para o agrupamento ou representação contínuo: Categoria gerenciamento do processo: 1 * Área de Processo (PA) foco no processo organizacional: estabelecer e manter uma compreensão sobre os processos organizacionais, e identificar, planejar e implementar atividades de melhorias de processos. - SG 1 (meta específica) determine oportunidades de melhoria de processos; - SP estabecer necessidades dos processos organizacionais; - SP avaliar os processos da organização. Categoria gerenciamento de projeto: 2 * Área de Processo (PA) planejamento de projeto: estabelecer e manter planos que definam atividade do projeto. - SG 1 (meta específica) estabeleça estimativas. - SP estimar o escopo do projeto. - SP estabelecer estimativas de produtos de trabalhos e atributos das tarefas. 123

35 4.4. Métodos de avaliação 1 O framework do CMMI ainda trás outras partes fundamentais que são os métodos de avaliação da maturidade das organizações: o CBA IPI, que utiliza o SW-CMM como modelo de referência; o SCE, que é um método raramente utilizado fora do contexto de contratos militares dos EUA; e mode SCAMPI, que é uma metodologia que combina características dos métodos CBA-IPI e SCE. O método SCAMPI é utilizado para avaliar o processo de engenharia (software, sistemas, hardware) versus o CMMI. É contratada por um patrocinador e liderada por um lead appraiser autorizado que, junto com uma equipe de 4 a pessoas, avalia requisitos específicos internos ou externos à organização. Utiliza o CMMI como modelo de referência, gasta um grande esforço de coleta de dados e evidências antes do trabalho onsite e não está somente focado em software, mas também em sistema Conclusão A representação por estágio utiliza nível de maturidade para medir a melhoria organizacional, tem somente um tipo de prática específica e somente aparecem práticas genéricas para os níveis de capacidade 2 e 3 e não existem para os níveis 4 e. A representação contínua utiliza níveis de capacidade para medir a melhoria de processos, tem mais práticas específicas, pois há dois tipos de práticas: básicas e avançadas e existem práticas genéricas em todos os níveis de capacidade de 1 a. Referências bibliográficas ABNT - Associação Brasileira de Normas Técnicas NBR- ISO Normas de gestão da qualidade e garantia da qualidade,