Nícolas dos Santos Baradel R.A.: CMMI E SPICE: ABORDAGEM E ESTUDO COMPARATIVO

Transcrição

1 Nícolas dos Santos Baradel R.A.: CMMI E SPICE: ABORDAGEM E ESTUDO COMPARATIVO JAGUARIÚNA 2007

2 Nícolas dos Santos Baradel R.A.: CMMI E SPICE: ABORDAGEM E ESTUDO COMPARATIVO Projeto apresentado à disciplina Trabalho de Graduação III, do curso de Ciência da Computação da Faculdade de Jaguariúna, sob a orientação do Prof. Luciano Calderoni, como exigência essencial à conclusão do curso de graduação JAGUARIÚNA 2007

3 BARADEL, Nicolas dos Santos. CMMI e SPICE Abordagem e Estudo Comparativo. Monografia defendida e aprovada na FAJ (Faculdade de Jaguariúna) em de de pela banca examinadora constituída pelos professores Prof. Luciano Calderoni FAJ Orientador Prof. Prof.

4 Dedicado à Clarissa, minha esposa, e à Lívia, minha filha, por sempre me apoiarem em tudo o que eu faço e pela paciência em entender o quão importante foi este trabalho para a minha graduação. Obrigado aos meus amigos e ao meu orientador, que me ajudaram sempre que necessário.

5 Agradecimentos Gostaria de agradecer a Deus por me proporcionar caminhos para que eu alcançasse meus objetivos. Ao meu orientador Luciano Calderoni, pela orientação dedicada e pelo constante estímulo em todas as fases da realização deste trabalho de graduação. Não poderia deixar de lembrar das pessoas importantes para mim e que sem elas não estaria terminando a graduação. Meus tios e padrinhos Francisco e Cacilda, vocês sabem o quanto foram importantes para mim. Aos meus avós Rolando e Cacilda, se cheguei até aqui, podem ter certeza que foi por vocês. Aos meus pais Rolando e Maria do Carmo, por deixar seus sonhos de lado para que eu e meus irmãos pudéssemos realizar os nossos. Aos meus irmãos Ana e Bruno, simplesmente pelo fato de estarem sempre unidos, nos tornando uma família completa. Gostaria também de agradecer à família a qual eu formei, minha esposa que sempre me apóia e é uma guerreira, assim como eu. Á minha filha, por saber entender que o papai gostaria de ficar mais tempo junto a ela, e devido a esta jornada tenho passado pouco tempo com vocês. Um especial agradecimento ao meu avô Rolando Baradel, o quanto foi importante em minha vida, e, tenha certeza, de onde o senhor estiver, tenho certeza que o senhor está orgulhoso do seu neto. Por tudo o que o senhor me ensinou, tenha certeza que carrego tudo comigo pra onde quer que eu vá, se termino a faculdade com este trabalho, tenha certeza, foi pelo senhor.

6 Não há nada como o sonho para criar o futuro (Victor Hugo)

7 BARADEL, Nicolas dos Santos. C.M.M.I e SPICE: Abordagem e estudo comparativo. Trabalho de Conclusão de Curso Bacharelado em Ciência da Computação, da Faculdade de Jaguariúna. Resumo Segundo estudo feito pelo The Standish Group (CHAOS REPORT, 2000) apenas 16% dos projetos de software terminam dentro do cronograma de prazo e de custo estimados inicialmente, enquanto que, 72% não respondem eficientemente ao planejamento produtivo. Destes 72%, 53% obtiveram estouros de 90% do orçamento, enquanto 31% destes projetos foram cancelados antes mesmo do seu término. Mesmo assim, observando apenas os projetos que obtiveram êxito, apenas 61% atenderam todas as características solicitadas pelo cliente. A partir dessas observações conclui-se que as empresas estudadas não possuem um departamento de engenharia preparado para atender eficazmente a demanda do mercado. Entre os problemas enfrentados pelas equipes de produção de software estão, a falta de participação do usuário, a fraca gerência, a obstrução dos requisitos do usuário, o planejamento inapropriado e as mudanças nas especificações do produto. Portanto, um estudo mais aprofundado acerca do tema se faz necessário, uma vez que, há um distanciamento entre as exigências da demanda, aliado a prazo e custos, e o produto ofertado ao cliente. Este trabalho tem como principal objetivo estudar estas duas ferramentas para o bom desenvolvimento de software, apontar as principais diferenças entre as metodologias mais utilizadas atualmente na melhoria de processos de produção de software, C.M.M.I. e SPICE. Desenvolver um comparativo entre as duas ferramentas e apontar as vantagens e desvantagens de cada uma. Dessa forma, a empresa interessada em utilizar uma ferramenta de desenvolvimento de software pode escolher qual instrumento se adequa melhor a sua realidade. Palavras-chave: C.M.M.I, SPICE, Estudo Comparativo.

8 Abstract According study done by The Standish Group (CHAOS REPORT, 2000) only 16% of software projects to finish within the time schedule and cost originally estimated, whereas 72% do not respond efficiently to production planning. Of these 72%, 53% obtained excess of 90% of the budget, while 31% of these projects were canceled before its completion of the same. Still, observing only those projects that won success, only 61% attended all the features requested by the customer. From these observations concluded that the companies studied did haven t an engineering department prepared to effectively meet the demand of the market. The problems found by the production software team are, the user not participation, management lack, user requirement not understanding, inappropriate planning and the changing in the product specification. So, an more enhanced study about the subject is necessary, because the are a distancing between demands for demand, with time and cost, and the offered client product. This study has a main objective show these two sound development tools for software, pointing out the main differences between the currently methodologies more used in process of software production, CMMI and SPICE. Develop a comparison between the tools and indicate the advantages and disadvantages of each one. The company interested in using a tool for software developer can choose witch instruments is the best suited to their solution.

9

10 9 SUMÁRIO 1. Capítulo 01 INTRODUÇÃO Capítulo 02 CMMI 2.1 A Origem do CMMI O Que é CMMI Os Níveis do CMMI Capítulo 03 SPICE 3.1 A Origem do SPICE O Que é SPICE Níveis do SPICE Capítulo 04 COMPARAÇÃO 4.1 Comparação entre CMMI e SPICE Tabela Comparativa entre CMMI e SPICE Capítulo 05 ESTUDO DE CASOS 5.1 Implementação do SPICE Implementação do CMMI Capítulo 06 CONCLUSÃO Capítulo 07 REFERÊNCIAS BIBLIOGRÁFICAS Capítulo 08 ANEXOS 8.1 Processos, Níveis e Subníveis do SPICE...34

11 10 ÍNDICE DE TABELAS Tabela 01 Os níveis do CMMI...15 Tabela 02 Os processos e Níveis do SPICE...21 Tabela 03 Comparação entre CMMI e SPICE...28

12 11 1. Capítulo 01 - INTRODUÇÃO O processo de produção de software constitui-se de uma série de etapas que visam atender os requisitos de um cliente, considerando prazos e custos da entrega de um produto de qualidade aceitável. Porém, ao longo das décadas verificou-se que no processo produtivo é impraticável atender aos requisitos sem a devida organização, principalmente quanto à disciplina e ao gerenciamento em nível básico. Em conseqüência, visando a melhoria contínua de todas as etapas de produção do software inúmeras propostas surgiram, entre elas o CMMI e o SPICE. A sigla CMMI que significa Capability Maturity Model Integration, Modelo Integrado de Maturidade e Capacitação, que é um framework 1 detalhado que descreve as melhores práticas para o desenvolvimento e manutenção de produtos e serviços incluindo todo o ciclo de vida de um produto em sua concepção, entrega e manutenção. Segundo o Software Engineering Institute (SEI) 2, foi desenvolvido para definir um ponto inicial para modelos integrados, aprimorando assim, as melhores práticas na criação de modelos com o estabelecimento de um framework, possibilitando a integração para novos futuros modelos juntamente com a criação de uma forma associada de avaliação de desempenho dos produtos. Já a ferramenta SPICE é um framework regulamentado pelo ISO 3 que fornece a avaliação dos processos de software, sendo que, este framework é usado pelas organizações para planejamento, gerenciamento, monitoração, controle e melhoria das aquisições, desenvolvimentos, operações, evoluções e suporte de software. 1 Framework:Estrutura de suporte definida em que um projeto de software pode ser organizado e desenvolvido. 2 SEI - Software Engineering Institute (Instituto de Engenharia de Software) sediado na CMU Carnegie Mellon University em Pittsburgh, Penssylvania, Estados Unidos e é um centro de pesquisa e desenvolvimento criado em pelo Departamento de Defesa dos Estados Unidos (DoD Departament of Defense). 3 ISO significa International Organization for Standardization (Organização Internacional para Normalização) sediada em Genebra, Suíça, foi fundada em e tem o propósito de desenvolver e promover normas e padrões mundiais que traduzam o consenso dos diferentes países de forma a facilitar o comércio internacional.

13 12 2. Capítulo 02 - CMMI 2.1. A Origem do CMMI O CMMI é um dos últimos resultados obtidos de uma série de evoluções referente à área de qualidade de software. A evolução dos conceitos de qualidade iniciou-se nos anos de 1930 com Walter Shewhart desenvolvendo alguns princípios para controle estático de processos. Shewhart empregava técnicas de probabilidade e gráficos de controle para detectar variações no processo de fabricação que poderia gerar produtos defeituosos. No início dos anos de 1980, Philip Crosby desenvolveu a chamada grade de maturidade da qualidade, que consistia no desenvolvimento do pensamento da qualidade, desde a incerteza, passando pelo despertar, esclarecimento e sabedoria até a plena certeza. Em 1986, Walter Humphrey, alterou a idéia da grade de maturidade da qualidade de Crosby incluindo o conceito de níveis de maturidade. No ano seguinte, em 1987, o SEI lançou uma breve descrição da estrutura da maturidade de processo [Humphrey 87a] e um questionário de maturidade [Humphrey 87b] juntamente com dois métodos de avaliação da maturidade do processo de software: Avaliação do Processo de Software (Software Process Assessment [Dunaway 96]) e Avaliação da Capacitação de Software (Software Capability Evalution [Byrnes 96]). Após quatro anos de experiência com a estrutura de maturidade de processo, o SEI evoluiu a estrutura de maturidade de processo para o chamado Capability Maturity Model for Software CMM [Paulk 91]. Em fevereiro de 1993 foi lançada a versão 1.1 do CMM como resultado de recomendações da comunidade de software. Em 1994 foi lançado o livro The Capability Maturity Model Guidelines for Improving the Software Process [Paulk 95]. Basicamente o CMMI é uma evolução do Software CMM (o CMM voltado para o desenvolvimento de software) e entre outras pequenas modificações incluiu um novo conceito que se refere à representação contínua. A idéia da representação contínua é a de oferecer maior flexibilidade à organização industrial. Uma organização deve escolher as áreas de processo que trabalhará desde que estas estejam perfeitamente alinhadas com os objetivos de negócio da empresa. Basicamente, quando uma empresa alcança uma melhora em uma área de processo pode escolher: i) se ajusta ao próximo nível de capacidade ou ii)

14 13 se aumenta o escopo do nível atual em que se encontra, incluindo as áreas de processo que possui melhor capacidade. Em suma, o CMMI é um modelo de referência que demonstra orientação para o desenvolvimento de processos de software, isto é, realizado através de áreas de projeto que citam os tópicos mais importantes de uma empresa de software.

15 O que é CMMI Conforme o SEI, o CMMI consiste em um framework de produtos que provêem a habilidade de gerar múltiplos modelos, treinamentos associados e materiais para avaliação do processo de desenvolvimento de software. Muito embora o CMMI esteja fortemente fundamentado em software, também contempla os desenvolvimentos multidisciplinares, cobrindo outras áreas do desenvolvimento de sistemas. Até o momento, são quatro as disciplinas incorporadas ao CMMI: i) Software-CMM (The Capability Maturity Model for Software - Modelo de Capacidade e Maturidade para Software) Cobre o desenvolvimento de sistemas de software, focando em aproximações sistemáticas e disciplinas determinando a aplicação do desenvolvimento, da operação e da manutenção do software; ii) SS-CMM (The Supplier Sourcing Capability) Visa o atendimento de modificações e a execução de funções específicas críticas que podem vir a serem necessárias em um produto; iii) SE-CMM (The Systems Engineering Capability Model) - Foca o desenvolvimento total de sistemas podendo ou não incluir um software. Os coordenadores dos sistemas focalizam as necessidades e as expectativas de seus clientes na elaboração dos produtos e na durabilidade dos mesmos; iv) IPD-CMM (The Integrated Product Development Capability Maturity Model) - É uma aproximação sistemática na tentativa de uma colaboração das partes relevantes durante o ciclo de vida de um produto buscando satisfazer as necessidades, expectativas e exigências dos clientes. O CMMI contempla também as chamadas áreas-chave de processo, que são designadas pelo conjunto de melhores práticas relacionadas a uma determinada área específica, que quando executada com outros procedimentos satisfaz os mesmos objetivos. Dessa forma, é um processo gradativo, ou seja, a empresa é preparada passo a passo.

16 Os níveis de CMMI A abordagem por estágios do CMMI possui cinco níveis diferentes e distintos de maturidade, segundo o SEI. O primeiro nível é considerado um nível caótico, em que a empresa não possui um ambiente estável, e geralmente depende de atos heróicos de seus colaboradores. Já o segundo nível 4 se caracteriza por ter os requisitos, os processos, os produtos e os serviços controlados, e ainda, o status dos produtos e entregas nítidos, sendo que, a gerência pode visualizá-los em alguns pontos definidos. Enquanto que, o terceiro nível 5 é qualificado por processos e compreendido aonde são descritos padrões nos procedimentos, nas ferramentas e nos métodos. O quarto nível 6 possui instrumentos para verificação estatística dos processos e é compreendido durante toda a vida do processo, baseando-se na compreensão do retorno previsto pela organização e pelo impacto que a mudança acarretará. Segundo a ISD 7, o maior problema com os profissionais brasileiros é o fato de subestimarem as mudanças e a mentalidade de que teorias geralmente não dão certo na prática. Os níveis mais altos de CMMI são geralmente identificados, segundo Salviano (2004) como complexos, representando para a empresa dificuldade em atingir tal grau de eficiência, pelo fato de consistir em uma série de mudanças comportamentais dos envolvidos, da padronização e da disciplina, que são necessárias a partir da implementação de uma série de modelos e conceitos. 4 O nível dois do CMMI aborda principalmente a questão gerencial e suas áreas-chave são as seguintes Gerenciamentos de Requisitos; Planejamento de Projetos; Monitoração e Controle de Projetos; Gerenciamento de Acordos com Fornecedores; Medição e Análise; Garantia de Qualidade do Processo e Produto; Gerência de Configuração. 5 O nível três possui as seguintes áreas-chave: Desenvolvimento dos Requisitos; Soluções Técnicas; Integração do Produto; Verificações e Validações; Processo e Treinamento Organizacional; Gerência de projeto integrada para IPPD; Gerência de Risco; Integração de Equipe; Gerência de Fornecedores; Análise e Resolução de Decisões; Ambiente Organizacional de Integração. 6 O nível quatro do CMMI possui as seguintes áreas-chave: Performance do Processo Organizacional; Gerenciamento Quantitativo de Projetos. O último nível CMMI foca as seguintes áreas: Inovação e Distribuição Organizacional; Estudos de Caso e Definições. 7 ISD Integrated System Diagnostics Brasil é uma consultoria com atuação na América do Sul focada em qualidade de processo, e é baseada em modelos reconhecidos internacionalmente.

17 16 Nível Engenharia - Desenvolvimento Apoio Gerência de Projetos Gerência de Processos Gerência de requisitos Solução técnica (pois já possui os requisitos) Medição e análise; Gramática da qualidade do processo e do produto. Análise de decisão e resolução Análise e resolução de causas. Planejamento do projeto de software; Monitoração e controle do projeto. Gerência de riscos; Integração da equipe; Gerência de risco; Integração da equipe. Tabela 01 Os níveis do CMMI. Definição do processo organizacional. Desempenho do processo organizacional. Inovação e implantação organizacional. A grande maioria das empresas se encontra no nível três, pois acaba sendo suficiente para a empresa.

18 17 3. Capítulo 03 SPICE 3.1. A Origem do SPICE A resolução 144 aprovada em junho de 1991 pela entidade certificadora ISO/IEC JTC 1/SC7 aprovara um período de estudo e investigação de requisitos para uma padronização das melhorias de processo de desenvolvimento de software. Com estes estudos a ISO obteve as seguintes as seguintes conclusões: i) A certeza da necessidade de um compromisso internacional para uma padronização dos processos de melhoria do desenvolvimento de software; ii) A necessidade da verificação das experiências dos usuários para um relatório técnico de pré-publicação para uma base para tal padrão internacional; iii) A necessidade da criação de uma consciência no mercado para um padrão de processo de desenvolvimento de software. O artigo foi aprovado em janeiro de 1993 e a partir de junho do mesmo ano foi estabelecido o programa de trabalho aprovado pela ISO/IEC para uma padronização internacional dos processos de desenvolvimento de software, fundamentando então, suas pesquisas nas conclusões mencionadas anteriormente. Em junho de 1995 o grupo terminou os esboços iniciais de seu trabalho. As diretrizes orientadoras de ISO/IEC indicaram um relatório técnico que consistia das seguintes partes: 1 Conceitos e guia introdutório; 2 Um modelo de gerenciamento de processos; 3 Processos de avaliação; 4 Guia de melhoria de condução; 5 Construção, seleção e uso de instrumentos e ferramentas de avaliação; 6 Qualificação e treinamento de assessores; 7 Guia para melhor uso dos processos; 8 Guia para determinação de potencialidade de fornecedor; 9 Vocabulário.

19 O que é SPICE O SPICE (ISO/IEC 15504) é um modelo que, como o CMMI, sua principal função é a melhoria dos processos de desenvolvimento de software e a determinação da capacidade de processos de uma organização industrial. Uma melhoria neste processo exige um exame detalhado para decisão e determinação de qual etapa é a mais importante e deve ser priorizada, sendo implementada em primeiro lugar em uma empresa. Esta decisão tem relação direta com o contexto, a regra de negócio e os riscos dessa implementação. Esse sistema prega algumas boas práticas fundamentais para uma engenharia de software eficiente. A arquitetura do framework organiza essas práticas em duas abordagens distintas: 1º) Práticas base: com foco em atividades essenciais para processos específicos agrupados por tipo de atividade; 2º) Práticas genéricas: para qualquer processo que representa fundamentalmente as atividades necessárias para a gestão do processo. O SPICE possui processos bem definidos para cada etapa do desenvolvimento e/ou manutenção de um produto de software, dentro de cada processo são definidas uma série de atividades específicas para a conclusão da implantação de cada processo. Os processos definidos pelo SPICE, de acordo com ISO 15504, são: i) Cliente-Fornecedor: Processos que possuem relação direta com o cliente, organizadas desta forma: - Gerenciar necessidades do cliente; - Prover solução ao cliente; ii) Engenharia: Responsável pela especificação, execução, manutenção e documentação de um sistema de software, pode ser descrita desta forma: - Desenvolver requisitos e o projeto de software; - Integrar e testar o software; - Manter o software;

20 19 iii) Projeto/ Suporte: Foca o controle dos recursos do projeto, organizadas nestas etapas: - Desenvolver a documentação; - Executar auditorias; - Executar revisões entre os setores responsáveis pelo software; - Foca o controle dos recursos do projeto; - Ênfase numa melhor performance de sustentação para o projeto; iv) Organização: Controla os processos, definindo objetivos. Organizadas desta forma: - Definir o processo; - Melhorar o processo; - Prover infra-estrutura organizacional para o desenvolvimento adequado do sistema de software;

21 Níveis do SPICE Ao contrário do CMMI, o SPICE possui seis níveis de capacidade (de 0 a 5) de uma organização definidos desta forma: i) Nível 0 Não executado: É a organização que não possui nenhum tipo de processo, também definido como uma organização caótica; ii) Nível 1 Informalmente executado: Trata-se da organização que não possui algumas práticas básicas, porém não documentadas e sem planejamento rigoroso, geralmente o êxito em seus projetos depende de esforços individuais de seus colaboradores; iii) Nível 2 Planejado e rastreado: Os produtos de trabalho começam a apresentar uma especificação padrão e requisitos bem delineados; iv) Nível 3 Bem definido: A empresa já possui planejamento e organização usando processos padronizados; v) Nível 4 Controlado quantitativamente: Neste nível, a empresa já possui ferramentas para medição da melhoria dos seus processos tendo o desempenho objetivamente gerenciado; vi) Nível 5 Melhoria contínua: A empresa possui uma resposta de seu desempenho e implementa novas idéias com inovações tecnológicas. A idéia é que a empresa conquiste um nível de controle e gerenciamento que possa detectar falhas em seus processos e corrigi-las. O SPICE possui mecanismos de pontuação em escala ordenada por quatro valores, escolhidos de acordo com um percentual de atendimento aos requisitos do atributo de processo. Os valores são entre 0% a 15% é declarado como não atendido, de 16% a 50% parcialmente atendido, de 51% a 85% largamente atendido e de 86% a 100% é definido como totalmente atendido. Por exemplo, uma empresa pode ser considerada do nível 2 quando todos os atributos dos níveis inferiores são totalmente atendidos e todos os atributos do nível são largamente atendidos. O SPICE possui os processos separados por categoria e subdivididos em atividades conforme especificado abaixo:

22 21 Processo Nível Atividades Cliente-Fornecedor (CSU) 1 Aquisição de produto ou serviço de software 2 Estabelecimento de contrato 3 Identificar necessidades do cliente 4 Realizar revisões e auditorias conjuntas 5 Empacotamento, entrega e instalação de software 6 Suporte à operação de software 7 Prover serviços ao cliente 8 Assegurar satisfação do cliente Processo Nível Atividades Engenharia do Produto (ENG) 1 Desenvolver requisitos e projeto do sistema 2 Desenvolver requisitos do software 3 Desenvolver projeto do software 4 Implementar projeto de software 5 Integrar e testar o software 6 Integrar e testar sistema 7 Manter sistema e software Processo Nível Atividades Projeto (PRO) 1 Planejar o ciclo de vida do projeto 2 Estabelecer plano de projeto 3 Formar equipes de projeto 4 Gerenciar requisitos 5 Gerenciar qualidade 6 Gerenciar riscos 7 Gerenciar recursos e cronograma 8 Gerenciar sub-contratados Processo Nível Atividades Suporte (SPU) 1 Desenvolver documentação 2 Realizar gerência de configuração (GC) 3 Realizar garantia da qualidade 4 Resolver problemas 5 Realizar revisões periódicas Processo Nível Atividades Organização (ORG) 1 Sistematizar o negócio 2 Definir o processo 3 Melhorar o processo 4 Realizar treinamento 5 Habilitar reuso 6 Prover um ambiente para engenharia de software (ADS) 7 Prover facilidades de trabalho Tabela 02 Os Processos e Níveis do SPICE

23 22 4. Capítulo 04 - COMPARAÇÃO 4.1. Comparação entre CMMI e SPICE As duas ferramentas de desenvolvimento de software abordadas possuem várias diferenças, porém, as duas ferramentas derivam do mesmo modelo, o modelo CMM. Enquanto o SPICE se define por um framework para avaliação nível a nível, visando assim, a melhoria continua do processo de desenvolvimento de software, o CMMI, conforme o SEI, é um framework de modelos que serve como guia para a melhoria dos processos e habilidades de organizações, focando gerenciar o desenvolvimento, a aquisição e a manutenção de produtos e serviços tecnológicos. Dessa forma, percebe-se que o CMMI propõe-se a disponibilizar mais de um tipo de modelo, dependendo do enfoque que a organização pretende dar ao problema dos processos. O SPICE, por sua vez, adquire uma visão única de framework o que pode dificultar a adoção do framework. O SPICE se propõe a demonstrar um tipo de avaliação e melhoria contínua de processos utilizando uma auto-compreensão do estado de processos de software, uma autodeterminação de adequabilidade de processos para determinados requisitos e processos de uma organização (fornecedora) no atendimento a um contrato particular. Conforme o SEI, o CMMI aborda como propósito fundamental o amadurecimento da habilidade de executar, controlar, melhorar e demonstrar melhoria numa área de processo, estabelecendo dessa forma melhorias evolutivas no processo. O CMMI pretende ainda a redução de custo da implementação de melhorias no processo multidisciplinar, baseado em modelos por meio de eliminação de inconsistências, redução de duplicidade, melhoria da clareza e entendimento, utilização de terminologia comum e estilo consistente, estabelecimento de regras de construção uniformes, manutenção de componentes comuns, consistência com as normas ISO (principalmente a ISO/IEC 15504) e sensibilidade às implicações dos esforços legados. Portanto, a diferença entre os dois frameworks é o entendimento. O SPICE faz questão de especificar que deseja que a organização tenha conhecimento o por que está adotando este processo, saiba o por que está fazendo as melhorias e ainda, quer que a organização entende o porquê o SPICE define que tais práticas sejam executadas pela

24 23 organização, Isto é uma grande vantagem para organizações que queiram ter autonomia sobre seus atos, pois o conhecimento gerado pela utilização do framework é algo que o próprio framework aconselha. Por outro lado, o CMMI usa a palavra demonstrar para explicar sua existência, o que leva a entendermos que o CMMI quer muito mais do que o conhecimento da própria organização, quer que o mercado saiba que a organização está adotando-o. Talvez isto seja um dos motivos para que a aceitação do CMMI tenha um alcance maior do que o do SPICE, a organização, mais do que melhorar, quer mostrar para seus clientes, fornecedores e concorrentes que a organização está respeitando as regras de qualidade dos processos de fabricação do software. Uma outra característica marcante e bastante importante do CMMI é a objetividade, o que fica muito claro na afirmação o CMMI pretende a redução de custo da implementação de melhoria de processo. O SPICE costuma afirmar que o objetivo principal de uma avaliação de processos é a determinação da capacidade no atendimento a requisitos e determinação de melhorias a serem implantadas. Já o CMMI acredita que a seqüência de níveis de maturidade estabelece padrões evolucionários de melhoria de processo, que estabilizam uma parte importante dos processos de uma organização. Quanto à questão do objetivo da avaliação de processos é notável que o SPICE está mais focado na questão da determinação de quais processos precisam de melhorias e quais melhorias devem ser feitas em tais processos. Enquanto, o CMMI preocupa-se na estabilização dos processos da organização, como uma cartilha de boas práticas de melhores práticas de processo como foco no software. Ambos frameworks possuem pontos positivos e negativos. O SPICE preocupando-se com as melhorias pode por conseqüência fazer a organização ficar mais comprometida com a implementação e uso do framework já que estará tudo mais claro e objetivo para os colaboradores do porque seguir o caminho especificado pelo framework. Porém, tal abordagem pode fazer com que as melhorias demorem a serem percebidas pelos clientes da organização. No CMMI a abordagem de estabilização obtendo-se níveis de maturidade é excelente para o mercado, mas por outro lado, pode fazer com que uma organização fique engessada no meio de processos e

25 24 atividades que não entende muito bem porque está fazendo, tudo em nome da qualidade exigida pelo CMMI. O SPICE geralmente é aplicado em organizações envolvidas com planejamento, gestão, monitoramento, controle e melhoria de processos de aquisição, fornecimento, desenvolvimento, operação, evolução e suporte de software. O CMMI é altamente recomendável para organizações em que as características dos processos sejam imaturas a ponto de não haver maneiras sistemáticas de produção de software, não haver ambiente estável de desenvolvimento, onde o sucesso do desenvolvimento depende mais da competência e por vezes, do heroísmo dos desenvolvedores do que da sistemática do processo da empresa. E ainda, alta dependência de pessoas específicas resultando em queda de produtividade, verificação de problemas nos cronogramas ou orçamentos estabelecidos, preocupação com práticas voltadas à garantia de qualidade dos produtos, porém, abandono dessas práticas em momento de pressão. Mais uma vez percebe-se que o CMMI possui foco mais objetivo nos pontos em que uma organização pode não estar praticando as suas atividades corretamente, o que pode acabar em uma organização confusa, pela escolha de qual framework de melhoria de processos utilizar por meio da comparação de cenários existentes com os descritos pelo CMMI. Enquanto, a definição de organizações que o SPICE sugere leva a impressão de que apenas grandes organizações com alto faturamento e com grande disponibilidade de recursos podem utilizar, talvez este seja um dos pontos mais negativos nessa definição por parte dos autores do SPICE. O SPICE define um conjunto de requisitos para a elaboração de processos de pontuação, devendo os resultados ser consistentes, repetíveis e representativos. A entrada de dados deve ser definida e um assessor deve assumir a responsabilidade pela quantidade dos resultados usando componentes pontuáveis, escalas, ponderações e registros de saída de dados. O CMMI se pauta em agregação de evidências coletadas através de observações (ferramentas, apresentações, documentos, entrevistas, entre outros) e com base em suas abordagens pontua e classifica uma organização em um dos cinco níveis de maturidade possíveis. Assim, para uma organização estar no nível dois, é necessário que todas as áreaschave deste nível estejam institucionalizadas. Para estar no nível três, é preciso cumprir

26 25 todas as áreas do nível dois e todas as do nível três, e assim por diante. Uma organização do nível dois pode, por exemplo, possuir práticas de níveis mais altos, mas ser apenas nível dois por não possuir o conjunto completo das áreas no nível mais alto. Já na abordagem chamada de modelo contínuo, cada área-chave que, no modelo em estágios, pertence exclusivamente ao nível dois, no modelo contínuo pode ter características que coloquem em outros níveis. A objetividade e maior simplicidade do CMMI aparecem também nos processos de pontuação das organizações em que atua. Tal simplicidade pode ser muito benéfica podendo não causar dúvida ou suspeita nos investidores de uma organização que está se certificando. Porém em sua abordagem seqüencial o CMMI pode pecar no mesmo ponto que o SPICE, na falta de definição e a falta de clareza nas áreas-chave que uma organização está madura. O SPICE aborda uma série de instrumentos de avaliação, ou papel ou digital, que incorporam vários indicadores de avaliação padronizados. Esses instrumentos podem ir desde o gerenciamento de processos, passando por caracterização de produtos de trabalhos diferentes, mapeamento de processos para produtos de trabalho, mapeamento de práticas base para produtos de trabalho até a tabulação através de indicadores de processos, porém, não possue explicitamente um método de avaliação. O CMMI adota métodos de mensuração de qualidade como ferramenta para seus modelos. Um dos métodos mais conhecidos é o SCAMPI que verifica, entre outros pontos, a satisfação de critérios de qualidade, a melhoria interna do processo, a determinação da capacidade externa, as práticas de seleção de fornecedores e monitoramentos gerais. Este método permite avaliar os pontos fortes e fracos de processos de engenharia de uma organização conforme o modelo CMMI, priorizar planos de melhoria de processos, produzir um escore de avaliação padronizada para níveis de capacidade e maturidade. A falta de pelo menos um método de avaliação explícito no SPICE e a força do método SCAMPI do CMMI contribuem para uma avaliação positiva quanto ao quesito de avaliação do CMMI. É de extrema importância que as organizações tenham métodos claros e objetivos de avaliação, até mesmo para a confiabilidade do trabalho executado e do resultado divulgado.

27 26 Os vários objetivos do CMMI sejam genéricos ou específicos, possuem equivalentes no modelo SPICE, fazendo com que ambos atendam e atendam ao mesmo tipo de organização. Contudo, o SPICE possui um foco mais genérico e abrangente que o CMMI, percebe-se tal diferença quando se verifica que, enquanto o CMMI trata das melhorias de processos tanto para sistemas incluindo os não de software, o SPICE também se preocupa com detalhes tais como na contratação de um fornecedor de software, estabelecimentos de contratos comerciais entre as partes, preocupação com os serviços de manutenção, preocupações em relação à instalação, entrega do software, avaliação da satisfação do cliente entre outros. Desta forma, o SPICE apresenta-se como um modelo mais flexível do que o CMMI mesmo em sua abordagem seqüencial. Tal flexibilidade acomoda melhor o conceito de evolução do nível de capacidade do processo. Outra vantagem do SPICE em relação ao CMMI é a grande quantidade de formatos de apresentação dos resultados, devido à maneira como os mecanismos de pontuação foram implementados. Por outro lado, a flexibilidade do SPICE aumenta também a sua complexibilidade, já que ele não possui roteiros claros para a melhoria do processo. O SPICE mostra-se desta forma, a melhor opção para organizações que desejam maior grau de controle em todos os processos relevantes dentro do desenvolvimento de um produto de software. O CMMI possui a grande vantagem de ser uma melhoria de um modelo já testado e com grande número de empresas usuárias CMM, além disso, sua maior simplicidade devido à estruturação em uma escala crescente de níveis e objetivos, na sua abordagem por estágios, facilita a sua aplicação em programas de melhoria.

28 Tabela Comparativa entre CMMI e SPICE Vantagem Desvantagem Diferença CMMI Modelo menos abrangente, por isso mais simples de ser aplicado e utilizado. SPICE Modelo mais abrangente e por isso contempla pontos que o CMMI não menciona. Modelo sugerido pela ISO. Usou como modelo de referência o CMM, Trilium, STD e o Bootstrap de forma harmoniosa e compatível, tendo então várias características semelhantes ao CMMI, principalmente na abordagem por estágios. O SPICE contempla controles que o CMMI não possui, como por exemplo a preocupação na contratação de um fornecedor de software, estabelecimentos de contratos comerciais entre as partes, preocupação com os serviços de manutenção, preocupações com relação à instalação, entrega do software, avaliação da satisfação do cliente, entre outros. Tabela 03 Comparação entre CMMI e SPICE Ao contrário do CMM, o CMMI também se utilizou de abordagem seqüencial que já era utilizado pelo SPICE. O CMMI pode ser considerado como uma parte do SPICE, pois os dois modelos vieram basicamente do mesmo modelo(cmm) possuindo assim um foco mais amplo que o CMM, porém mais restrito que o SPICE, fazendo com que não contemple o nível de controle que o SPICE sugere.

29 28 5. Capítulo 05 ESTUDO DE CASOS 5.1. Implementação da ISO/IEC (SPICE) A Sênior Sistemas, fundada em 1988 com sede na cidade de Blumenau/ SC, é uma empresa nacional que atualmente desenvolve, evolui e comercializa quatro produtos: VETORH, para administração de recursos humanos, SAPIENS, para gestão empresarial, REGENTE, para administração de agências de viagem e RONDA para controle de acesso. A empresa pode ser considerada, para avaliação de processos, como composta por seis unidades organizacionais: uma para cada um dos produtos, uma para a área comum dos produtos e a outra para a empresa como um todo. Em 1999, a empresa realizou uma avaliação de processos baseada na ISO/IEC TR 15504, onde foram selecionadas cinco processos (Customer Suport Process, Quality Assurance Process, Project Management Process, Organizational Alignment Process e Process Establishment Process). Na análise dos motivos do não-atendimento de alguns objetivos, percebeu-se a dificuldade da empresa em estabelecer processos e garantir a qualidade dos produtos. No final da implantação, que ocorreu entre fevereiro de 2000 e março de 2001, todos os objetivos foram atendidos com a criação de um departamento de qualidade. Em maio de 2002 foi realizada uma avaliação de processos com a norma 15504, com o objetivo de comparar o estado atual com o estado encontrado em A avaliação dos processos foi realizada por dois avaliadores em três fases seqüenciais: 1.) Preparação da avaliação; 2.) Obtenção e análise de dados e determinação dos resultados; 3.) Produção do relatório de avaliação; Durante os meses de abril de 2002 e maio de 2002 foi planejada a avaliação e aplicados os questionários sobre processos a pessoas selecionadas da empresa. Foram selecionados sete processos da norma para sem avaliados até o nível três de capacidade dentre as quais cinco da avaliação anterior. Quatro fontes de informações foram utilizadas: resposta a questionários, entrevistas, análise de documentos e discussão sobre resultado preliminar. Estas observações foram utilizadas como base para a atribuição das notas de cada processo.

30 29 Foram identificadas ao todo cerca de setenta observações positivas e cinqüenta oportunidades de melhoria, relacionadas às práticas descritas no SPICE. O resultado da avaliação em 2002 indicou uma melhoria em termos de capacidade de processo. Em geral, houve uma evolução do nível zero para o nível dois, com alguns casos de melhoria para o nível um. A prática de utilização de indicadores para acompanhar as atividades e subsidiar a tomada de decisões também existe na empresa. Existem atualmente doze indicadores relacionados ao desenvolvimento e quatro relacionados ao suporte ao cliente, em que praticamente tudo é analisado e registrado, inclusive reclamações dos clientes e requisitos para evolução dos produtos. No trabalho de planejamento de melhorias foram identificadas evidências do sucesso do início do trabalho, mas já existia a consciência de que o sucesso seria atingido com a melhoria dos processos desenvolvidos pela empresa.

31 Implementação do CMMI A Microsiga, fundada em 1983, é uma empresa nacional com filiais espalhadas por toda a América Latina. Em 2005, a Microsiga decidiu implantar o CMMI na sua fábrica de software. A fábrica de software é uma área técnica dedicada ao desenvolvimento de customizações e projetos especiais ao serem agregados ao Protheus, ERP da Microsiga. A fábrica de software existe desde 1994 e conta com cerca de sessenta profissionais com muita experiência no desenvolvimento de soluções agregadas a ERP e com domínio das ferramentas de criação no ambiente Protheus. A estrutura da fábrica de software concentra-se nas funções: Vice-Presidência de Tecnologia e Sistemas, Líder (Analista de Projetos Sr.), Líder (Analista de Projetos Pl.), Líder (Analista de Processos Mt.), Coordenador de Consultoria em Soluções de Negócio, Gerente de Fábrica de Software, Coordenador de Negócios, Consultor de Negócios, Analistas de Projetos (Sr.,Pl.,Jr.,Tr.) e Estagiário. Todos os projetos da fábrica de software gerenciam os requisitos dos produtos e os acordos com fornecedores, estabelecem e mantém planos de trabalho que possibilitam o acompanhamento do projeto, além de estruturas e critérios de medições que garantam a integridade e visibilidade do processo e produto. Os objetivos da implantação do CMMI na Microsiga foram os seguintes: 1.) Aumentar a rentabilidade do network; 2.) Redução de despesas; 3.) Diminuição de retrabalhos; 4.) Redução de erros; 5.) Melhor qualidade dos produtos; 6.) Assertividade dos projetos; 7.) Maiores e melhores ofertas de produto; 8.) Redução de tempo de colocação de produtos no mercado; 9.) Motivação de processo de melhoria; 10.) Oportunidade de descrever um caminho estruturado e contínuo no desenvolvimento.

32 31 Os grandes benefícios esperados pela adoção do CMMI foram a oportunidade de possuir uma metodologia única, em que possa haver um gerenciamento único de todos os projetos, clara definição de papéis e redução de retrabalhos. Os principais desafios encontrados na implementação do CMMI foram a mudança de cultura, o envolvimento das equipes e pessoas, a capacitação das equipes, o retorno a médio e longo prazo, a adoção simultânea de novas práticas nos processos, a adequação à maior rigidez de sistemas e ferramentas, a alocação de pessoas-chave nos processos e a comunicação. Os principais subprocessos utilizados para a obtenção do nível dois foram o levantamento de necessidades do cliente com uma carta de entrega e especificação do produto, a elaboração da proposta do desenvolvimento do projeto, a alocação de recursos, a elaboração do projeto lógico, o desenvolvimento do projeto com as devidas validações, a disponibilização do ambiente de homologação e treinamento de usuários-chave, a implantação no ambiente de produção e o processo de aceite do cliente. O total de horas gastas para a implantação do CMMI foi de 4553 horas, sendo que, 800 horas foram em definições, 350 horas para a institucionalização dos novos processos com a equipe de qualidade, 1957 horas em definições e 1346 em institucionalização com a equipe da fábrica de software. As dificuldades surgidas durante o processo de implementação tiveram relação com a quebra de paradigma no que tange a importância da melhoria de processo, a institucionalização do novo processo e a aceitação de PPQA em todos os projetos. Os principais indicadores do sucesso da implementação do nível dois do CMMI na Microsiga se refletem nos benefícios alcançados pela organização como a definição clara de papéis na organização, a melhor padronização de artefatos e processo, o aumento de satisfação dos clientes, a maior confiabilidade no processo e a grande motivação profissional citada pelos colaboradores da organização.

33 32 6. Capítulo 06 - CONCLUSÃO Após analisadas as principais semelhanças entre os modelo SPICE e CMMI, verifica-se que cada modelo é melhor definido e possui um escopo que abrange, inclusive, parte do escopo trabalhado pelo outro modelo. Neste caso, o SPICE trabalha com abrangência de maior grandeza, definindo, dessa forma, atribuições que não se desenvolvem em outros modelos tais como o CMMI. O CMMI, por sua vez, como é um modelo com um alcance de menor grandeza, se comparado ao SPICE, possui uma abordagem mais clara, concisa e detalhada. Estes atributos lhe dão vantagens com relação aos custos, treinamento e aperfeiçoamento. Ao fim, a escolha de um modelo de melhoria de processo de software deve levar em consideração questões como os custos, os prazos, a viabilidade e a abrangência. Organizações podem disponibilizar maiores recursos para a implementação deste processo de melhoria e exigirem que outras atividades, mesmo que não diretamente ligadas ao desenvolvimento - mas, que sejam relevantes do desenvolvimento de software -, sejam incluídas na organização da equipe de melhorias, neste caso, a escolha do modelo SPICE seria uma opção mais viável do que a do CMMI. E, por fim, empresas de desenvolvimento de software que necessitem de melhorias nos seus processos, porém, com custos e prazos mais baixos, maior facilidade de entendimento e foco maior no desenvolvimento, possuem forte tendência a adotar o modelo CMMI. É relevante afirmar que uma organização deve procurar entender as semelhanças, diferenças, vantagens e desvantagens entre os modelos de melhoria de processo de desenvolvimento de software, não apenas verificando o CMMI e o SPICE, como também outras alternativas como o Trilium, o Software Tecnology Diagnostic, o Bootstrap, o MPS- BR, entre outros. Ou ainda, utilizando-se de um conjunto de características apresentadas por cada modelo focando as atividades que melhor representam a necessidade da organização levando em consideração a política interna, a visão, os objetivos, os clientes, entre as demais características de cada empresa.

34 33 7. Capítulo 07 REFERÊNCIAS BIBLIOGRÁFICAS PRESSMAN, Roger. Engenharia de Software: Makron, SIMPROS. VII Simpósio Internacional de Melhoria de Processos de Software, 2005 disponível em PAULK, Mark C.; KONRAD, Michel D.; GARCIA, Suzanne M., CMM Versus Spice Architectures, FELIPE, Pablo F.,CMMI e SPICE: Um estudo Comparativo na Abordagem da Engenharia de Requisitos, SALVIANO, Clênio F., Introdução a Melhoria de Processo de Software com ISSO/IEC E CMMI, Artigo CMMi.pdf, disponível em GONÇALVES, José M.; VILLAS BOAS, André. Disponível em: versão 1.2 (11/10/2001) tradução livre. SEI, Capability Maturity Model_Integration (CMMI), Version 1.1. Artigo 2000 CHAOS Report.pdf. Disponível em: Softex; MPS-BR. Melhoria de Processo do Software Brasileiro: Campinas, ISO/IEC SPICE, Software Process Assessment, Part 1: Concepts and Introductory Guide.

35 34 8. Capítulo 08 -ANEXOS 8.1. Processos, Níveis e Subníveis do SPICE CUS - Cliente-Fornecedor CUS. 1 Aquisição de produto ou serviço de software Identificar a necessidade Definir os requisitos Preparar estratégia de aquisição Preparar proposta Selecionar fornecedor CUS. 2 Estabelecimento de contrato Revisar o conteúdo do contrato antes da finalização Negociar o contrato Determinar relacionamentos com agentes independentes Determinar relacionamentos com sub-contratados. CUS. 3 Identificar necessidades do cliente Obter requisitos e requisições do cliente Entender expectativas do cliente Manter clientes informados CUS. 4 Realizar revisões e auditorias conjuntas Estabelecer revisões e auditorias conjuntas Preparar-se para as revisões Conduzir revisões gerenciais Conduzir revisões técnicas Apoiar revisões de aceitação pelo cliente Realizar garantias conjuntas do processo CUS. 5 Empacotamento, entrega e instalação de software Identificar requisitos de instalação Preparar ambiente para instalação Empacotar software Entregar software Verificar integridade do software Instalar software Providenciar procedimentos para armazenagem e manipulação CUS. 6 Suporte à operação de software Identificar riscos operacionais Realizar teste operacional Executar/operar software no ambiente

36 35 Resolver problemas operacionais Tratar requisições de usuários Documentar soluções temporárias Monitorar capacidade e serviço do sistema CUS. 7 Prover serviços ao cliente Treinar cliente Estabelecer suporte ao produto Monitorar desempenho Instalar upgrades CUS. 8 Assegurar satisfação do cliente Determinar o nível de satisfação Comparar com concorrentes Comunicar satisfação do cliente ENG Engenharia do Produto ENG.1 Desenvolver requisitos e projeto do sistema Especificar requisitos Descrever arquitetura do sistema Alocar requisitos nos elementos da arquitetura Determinar estratégia para futuras versões ENG.2 Desenvolver requisitos do software Determinar requisitos do software Analisar requisitos do software Determinar impacto no ambiente operacional Avaliar requisitos com o cliente Atualizar requisitos para próximas iterações ENG.3 Desenvolver projeto do software Desenvolver arquitetura Projetar interfaces de alto nível Desenvolver projeto detalhado Estabelecer rastreamento ENG.4 Implementar projeto de software Desenvolver e documentar unidades Desenvolver e documentar procedimentos de teste de unidade Testar cada unidade ENG.5 Integrar e testar o software Determinar estratégia de teste de regressão Construir agregados de unidades Planejar testes para agregados

37 36 Testar agregados Planejar testes do software Testar software integrado ENG.6 Integrar e testar sistema Integrar elementos do sistema Planejar testes para agregados Testar agregados Planejar testes do sistema Testar sistema integrado ENG.7 Manter sistema e software Determinar requisitos de manutenção Analisar problemas e requisições do usuário Determinar modificações para próximo upgrade Implementar e testar modificações Fazer upgrade do sistema PRO - Projeto PRO.1 Planejar o ciclo de vida do projeto Avaliar opções para desenvolvimento do produto Selecionar modelo de ciclo de vida do software Descrever atividades e tarefas Estabelecer seqüência de tarefas Documentar atividades PRO.2 Estabelecer plano de projeto Planejar estrutura do trabalho Identificar padrões de projeto Identificar facilidades especializadas Determinar estratégia de reuso Fazer estimativas do projeto Identificar riscos iniciais do projeto Identificar medidas Estabelecer cronograma Estabelecer compromissos/obrigações do projeto Documentar planos PRO.3 Formar equipes de projeto Definir equipe Prover equipes Manter interações entre equipes Gerenciar questões entre times PRO.4 Gerenciar requisitos

38 37 Obter concordância sobre requisitos Estabelecer requisitos do cliente Gerenciar alterações nos requisitos do cliente Usar requisitos Manter rastreamento PRO.5 Gerenciar qualidade Estabelecer metas de qualidade Definir métricas de qualidade Identificar atividades de qualidade Realizar atividades de qualidade Assegurar qualidade Tomar ações corretivas PRO.6 Gerenciar riscos Estabelecer escopo da gerência de riscos Identificar riscos Analisar e priorizar riscos Planejar estratégias para atenuar riscos Definir métricas de riscos Implementar estratégias de atenuação Assegurar resultados das estratégias Tomar ações corretivas PRO.7 Gerenciar recursos e cronograma Adquirir recursos Controlar progresso Conduzir revisões gerenciais Conduzir revisões técnicas Gerenciar obrigações PRO.8 Gerenciar sub-contratados Estabelecer trabalho Qualificar sub-contratados potenciais Selecionar Estabelecer e gerenciar obrigações Manter comunicação Assegurar conformidade Assegurar qualidade do sub-contratado SUP Suporte SUP.1 Desenvolver documentação Determinar requisitos da documentação Desenvolver o documento Avaliar documento