Estendendo o OpenUP para Atender as Áreas de Processo Relacionadas a Garantia da Qualidade e Medição do CMMI-DEV Nível 2 Murilo Ybanez Secretaria da Fazenda do Estado do Ceará - Sefaz-CE José Maria Monteiro Universidade Federal do Ceará - UFC Resumo Este artigo apresenta uma extensão do processo ágil OpenUP aderente às áreas de processo Garantia da Qualidade do Processo e do Produto e Medição e Análise do CMMI- DEV Nível 2. O estudo desenvolvido realiza inicialmente um mapeamento entre o OpenUP e estas duas áreas de processo. Os resultados da análise realizada indicam que o OpenUP não atende às exigências presentes no modelo CMMI-DEV para as duas áreas de processo estudadas. A partir desta constatação, sugere-se a adição de alguns papéis, tarefas e artefatos visando deixar o OpenUP compatível com as áreas de processo Garantia da Qualidade do Processo e do Produto e Medição e Análise do CMMI-DEV, sem, no entanto, comprometer seus princípios ágeis. Além disso, este trabalho relata os resultados da utilização da abordagem proposta em uma instituição governamental. I. INTRODUÇÃO Na economia moderna, é freqüentemente difícil prever como um sistema de software irá evoluir com o passar do tempo. Condições de mercado mudam rapidamente, as necessidades dos usuários evoluem e novas ameaças de competição emergem sem alerta. Neste contexto, os métodos ágeis representam uma estratégia para atender à dinâmica dos projetos atuais. As metodologias ágeis surgiram com a preocupação de acomodar melhor as modificações, possibilitando às equipes reagir rapidamente quando mudanças são necessárias. Nos últimos anos, métodos ágeis como o XP (extreme Programming) [3], Scrum [15] e Crystal [5] passaram a ser usados em empresas, universidades e agências governamentais [7]. Por outro lado, os modelos de capacidade de maturidade, como o CMMI (Capability Maturity Model Integration) [6], constituem uma estratégia bastante utilizada pelas empresas de software para melhorar sua visibilidade internacional e, conseqüentemente, poder concorrer em um mercado globalizado, além de aperfeiçoar efetivamente seus processos de software. Contudo, atualmente, organizações que empregaram um grande esforço na melhoria dos seus processos com base no CMMI, agora acreditam também que os métodos ágeis possam prover incrementos de melhorias [11]. Neste sentido, a combinação das metodologias ágeis com modelos de maturidade de software começa a ser investigada [9], [4], [19], [14], [13], [11], [6]. Apesar da existência de características distintas entre os métodos ágeis e o modelo CMMI, ambos possuem planos específicos para o desenvolvimento de software e buscam o melhor para que a organização produza software com qualidade [11]. Em [6] os autores argumentam que, apesar de existir uma grande controvérsia entre a compatibilidade dos métodos ágeis e o CMMI, eles não são mutuamente exclusivos. Inserido neste contexto de controvérsias e compatibilidades entre CMMI e métodos ágeis, este trabalho apresenta uma extensão do método ágil OpenUP aderente às áreas de processo Garantia da Qualidade do Processo e do Produto (GQPP) e Medição e Análise (MA) do CMMI-DEV Nível 2. O estudo desenvolvido realiza inicialmente um mapeamento entre o OpenUP e estas duas áreas de processo, avaliando o atendimento das práticas específicas do modelo. A partir desta avaliação, sugere-se a adição de alguns papéis, tarefas e artefatos visando deixar o OpenUP compatível com as áreas de processo GQPP e MA do CMMI-DEV, sem, no entanto, perder seus princípios ágeis. A extensão proposta para o OpenUP tem por objetivo auxiliar as organizações que têm o desejo de adotar uma metodologia ágil e que esteja compatível com as práticas do CMMI-DEV. A abordagem proposta foi aplicada em dois projetos reais de uma instituição governamental, a SEFAZ-CE. O restante deste artigo está organizado da seguinte forma: a seção 2 apresenta os principais conceitos utilizados neste trabalho, na seção 3 são discutidos os trabalhos relacionados, a seção 4 analisa a aderência do OpenUP às disciplinas GQPP e MA, na seção 5 é discutida a abordagem proposta, a seção 6 analisa os impactos das alterações propostas na agilidade do OpenUP, na seção 7 apresentamos um estudo de caso e a seção 8 conclui este trabalho. II. CONCEITOS BÁSICOS Nesta seção, apresentaremos uma visão geral das metodologias ágeis, do processo ágil OpenUp e do CMMI. A. Metodologias Ágeis O termo Metodologias Ágeis tornou-se popular em 2001 quando dezessete especialistas em processos de desenvolvimento de software representando os métodos Scrum [15], XP [3] e outros, estabeleceram princípios comuns compartilhados por todos esses métodos. Foi então criada a Aliança Ágil e estabelecido o Manifesto Ágil [2].
B. OpenUP O OpenUP (Open Unified Process) é um projeto opensource, atualmente mantido pelo Projeto Eclipse, que define um framework de processo de desenvolvimento de software [8]. O OpenUp foi inicialmente desenvolvido pela IBM com base no RUP (Rational Unified Process) e no XP, tendo como principal objetivo reunir as melhores características de cada uma dessas abordagens. Assim, este processo unificado aplica uma abordagem iterativa e incremental dentro de um ciclo de vida estruturado. Contudo, abraça uma filosofia ágil que foca na natureza colaborativa do desenvolvimento de software. Além disso, é um processo que pode ser estendido para direcionar uma grande variedade de tipos de projeto. Vale ressaltar também que o OpenUP tenta seguir a linha pragmática de não ignorar a considerável adoção do RUP pelo mercado, e, portanto, ele tenta ser um caminho de migração para metodologias ágeis, preservando alguns formalismos, principalmente no que diz respeito a documentação de requisitos e arquitetura. O OpenUP é modelado através da ferramenta EPF Composer (Eclipse Process Framework). O EPF Composer é uma ferramenta open-source, amparada pela fundação Eclipse, que possibilita o gerenciamento de processos e tem como principais características um fácil aprendizado, métodos simples de autoria, customização e criação de processos, além da geração automática da documentação do processo definido. Esta documentação consiste em um web site o qual é composto por cinco elementos básicos: Produto de Trabalho: são os artefatos produzidos; Tarefa: como executar o trabalho; Papel: quem executa o trabalho; Processo: são usados para definir os fluxos de trabalho; Diretriz: templates, checklists, exemplos, guias, conceitos, dentre outros. C. CMMI O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Software Engineering (SW), por exemplo). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativa, integrando diferentes modelos e disciplinas [6]. A versão atual do CMMI (versão 1.2) apresenta dois modelos: CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao processo de desenvolvimento de produtos e serviços. CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se aos processos de aquisição e terceirização de bens e serviços. O modelo CMMI v1.2 (CMMI-DEV) está estruturado em 5 níveis de maturidade, contendo 22 áreas de processo (Process Area - PAs), as quais são divididas em 4 categorias: Gerenciamento de projetos, Gerenciamento de processos, Engenharia e Suporte. III. TRABALHOS RELACIONADOS No trabalho apresentado em [19] é realizada uma análise do método ágil Scrum em relação às áreas de processo Gerenciamento de Requisitos e Desenvolvimento de Requisitos do modelo CMMI. As exigências não atendidas pelo Scrum são destacadas e algumas soluções são propostas. Em [11], [12], os autores apresentam uma abordagem do método ágil Scrum compatível com áreas de Gerenciamento de Projetos do CMMI. A abordagem proposta foi aplicada em uma organização de inovação e pesquisa no desenvolvimento de projetos de software. Em [18], é apresentada uma extensão do XP com o objetivo de incorporar práticas de engenharia de requisitos. Três modificações são propostas: 1) utilizar um documento de requisitos, o qual é gerenciado pelos papéis testador e analista; 2) alterar o Jogo do Planejamento a fim de permitir mais de um representante do cliente; e 3) inserir uma fase de engenharia de requisitos, no início do projeto, a fim de possibilitar uma visão mais ampla do sistema a ser desenvolvido. Além disso, os autores argumentam que as modificações propostas são simples e metodologia proposta é quase tão leve quanto o XP original. O artigo descrito em [4] apresenta a análise da aplicação de práticas de XP em equipes avaliadas oficialmente em SW-CMMI nível 2, destacando as vantagens e dificuldades desta abordagem. Em [14] são apresentas sugestões de modificações necessárias para que uma organização que utilize XP como metodologia de desenvolvimento possa se adequar ao nível G ou F do Modelo de Melhoria do Processo de Software Brasileiro (M.BR). O estudo discutido em [17], mostra uma experiência em que uma empresa se submete às certificações CMM nível 2 e ISO9001 usando XP e Scrum. Nesta experiência as contribuições destes dois métodos ágeis são combinadas: XP foi utilizado nos processos técnicos, enquanto Scrum foi utilizado para apoiar as questões organizacionais e de gestão. O trabalho apresentado em [1] explora a possibilidade de companhias de software de obter uma certificação CMMI de seus processos através da aplicação de práticas ágeis. Em [13] é apresentado uma abordagem para o desenvolvimento de software ágil que é compatível com CMMI. Além disso, o artigo descreve como a abordagem proposta foi utilizada com o propósito de incrementar o processo de desenvolvimento de software em três estudos de caso. O artigo descrito em [10] apresenta o projeto de um repositório de medições que possibilita o monitoramento e a melhoria contínua do desempenho de processos de desenvolvimento de software baseados no método ágil Scrum. Uma adaptação do OpenUP para atender aos requisitos do Nível F do M.BR é apresentada em [9]. Contudo, nenhuma iniciativa foi encontrada no sentido de adaptar o OpenUP para atender aos requisitos do CMMI. Assim, este artigo estende os trabalhos anteriores ao propor uma extensão do OpenUP compatível com as áreas de processo GQPP e MA do CMMI- DEV nível 2, contribuindo para o estado da arte na integração de métodos ágeis e modelos de maturidade de software.
IV. UMA ANÁLISE DO OPENUP SEGUNDO AS ÁREAS DE PROCESSO GARANTIA DA QUALIDADE E MEDIÇÃO DO CMMI-DEV NÍVEL 2 O método ágil OpenUP foi avaliado segundo as perspectivas do modelo CMMI, somente nas áreas de processo GQPP e MA pertencentes ao nível 2 deste mesmo modelo. Para cada uma destas áreas de processo foi realizada uma análise detalhada comparando suas metas e práticas específicas contra as disciplinas, papéis, tarefas e artefatos do OpenUP. Em seguida, atribuiu-se um valor para cada uma destas metas e práticas específicas a fim de classificar o nível de adequação do OpenUP à estas metas e práticas. A Tabela I apresenta os critérios utilizados nesta classificação. A seguir, são apresentados, para cada área de processo investigada, os resultados gerais da análise realizada enfatizando os pontos nos quais o OpenUP atende ou não práticas do CMMI-DEV. A. Análise da Área de Processo Garantia da Qualidade do Processo e do Produto (GQPP) O objetivo da Garantia da Qualidade do Processo e do Produto é fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. Esta área de processo suporta a entrega de produtos e serviços de alta qualidade, fornecendo, à equipe do projeto e gerentes de todos os níveis, a visibilidade apropriada e o feedback sobre os processos e produtos de trabalho associados durante todo o ciclo de vida do projeto [16]. No OpenUP a qualidade dos produtos de software é alcançada através de um conjunto de práticas relacionadas à disciplina de Teste, como por exemplo: desenvolvimento guiado por testes, programação em pares, refactoring, código coletivo, código padronizado, design simples e integração contínua. O desenvolvimento guiado por testes defende que os desenvolvedores escrevam testes automatizados para cada funcionalidade antes de codificá-las. Fazendo isso, eles aprofundam o entendimento das necessidades do cliente (o que aprimora a análise) e passam a contar com uma massa de testes que pode ser utilizada a qualquer momento para validar todo o sistema. A programação em pares permite que o código seja revisado permanentemente, enquanto é construído. Além de contribuir para que a implementação sela mais simples e eficaz, já que os desenvolvedores se complementam e têm mais oportunidades de gerar soluções inovadoras. O refactoring é o ato de alterar o código sem afetar a funcionalidade que ele implementa. Ele é utilizado para que o sistema possa evoluir de forma incremental, tornando o software mais simples de ser manipulado. A propriedade coletiva do código fornece maior agilidade ao processo e cria mais um mecanismo de revisão e verificação do código. Os padrões de codificação tornam o sistema mais homogêneo e permite que qualquer manutenção futura seja efetuada mais rapidamente. A prática do design simples leva o desenvolvedor a optar pela simplicidade ao invés de criar generalizações dentro do código com o objetivo de prepará-lo para possíveis necessidades futuras, pois para isso existem o refactoring, os testes e outras práticas. A integração contínua assegura que sempre que uma nova funcionalidade é incorporada ao sistema as funcionalidades anteriormente implementadas são checadas (através dos testes automatizados) a fim de descobrir eventuais defeitos, facilitando e acelerando a correção destes possíveis erros. Contudo, o OpenUP não possui práticas voltadas para a garantia da qualidade do processo. Assim, o monitoramento e a avaliação da aderência das atividades e produtos de trabalho produzidos ao processo definido não constituem objeto de nenhuma disciplina do OpenUP. Assim, podemos concluir que o OpenUP não atende às metas e práticas da área de processo Garantia da Qualidade do Processo e do Produto, como sumarizado na tabela II. B. Análise da Área de Processo Medição e Análise (MA) O objetivo das Medições e Análises é desenvolver e sustentar a capacidade de medições que é utilizada para suportar as necessidades de gerenciamento de informações [16]. A medição permite prever e monitorar custos e prazos, além de controlar a qualidade do processo, melhorando a compreensão e a validação do mesmo. O OpenUP baseia-se na idéia de estimativa ágil, a qual é construída a partir de três conceitos principais: Estimativa de tamanho: fornece uma estimativa de alto nível para o tamanho de um item de trabalho, normalmente medida usando uma unidade neutra ( pontos, por exemplo); Velocidade: diz-nos quantos pontos a equipe de projeto pode entregar em uma iteração; Estimativa de esforço: traduz o tamanho (medido em pontos) para uma estimativa de esforço detalhada usando normalmente as unidades de Dias Reais ou Horas Reais. A estimativa de esforço indica quanto tempo os membros da equipe necessitarão para completar os itens de trabalho. A estimativa de tamanho ágil é realizada normalmente usando uma medida relativa chamada pontos. A equipe decide quão grande um ponto é, e baseado nesse tamanho, determina quantos pontos cada item de trabalho tem. Para fazer a estimativa rapidamente, geralmente utiliza-se pontos cheios (1, 2, 3, 5, 8) e uma técnica denominada Planning Poker. A velocidade é uma importante métrica usada para o planejamento da iteração. Ela indica quantos pontos são entregues em uma iteração por uma determina equipe em um projeto. Por exemplo, uma equipe planejou fazer 20 pontos na primeira iteração. Ao final da iteração, eles observam que entregaram somente 14 pontos, então sua velocidade foi 14. Espera-se que a velocidade mude de iteração para iteração. Porém, no geral, a velocidade normalmente aumenta durante o projeto à medida que a equipe melhora suas habilidades e se torna mais coesa. A estimativa de esforço traduz o tamanho (medido em pontos) para uma estimativa de esforço detalhada usando normalmente as unidades de Dias Reais ou de Horas Reais. À medida que você planeja uma iteração será necessário dividir um item de trabalho em tarefas menores. Os membros da equipe são convidados a prontificarem-se para a realização
Sigla Classificação Critério NS Não Satisfeito Não há evidências da prática no OpenUP. Parcialmente Satisfeito Há evidências da prática no OpenUP, embora a prática não esteja plenamente atendida. S Satisfeita A prática está totalmente atendida no OpenUP. Tabela I CRITÉRIOS PARA CLASSIFICAÇÃO DAS ÁREAS DE PROCESSO. Meta Específica Prática Específica Classif. SG 1 Avaliar Objetivamente Processos e Produtos SP 1.1-1 Avaliar Objetivamente os Proces- NS de Trabalho sos SP 1.2-1 Avaliar Objetivamente os Produtos NS de Trabalho e Serviços SG 2 Fornecer um Entendimento Objetivo SP 2.1-1 Comunicar e Assegurar a NS Resolução das Questões de Não Conformidades SP 2.2-1 Estabelecer Registros NS Tabela II CLASSIFICAÇÃO DA ÁREA DE PROCESSO GARANTIA DA QUALIDADE DO PROCESSO E PRODUTO. das tarefas e, em seguida, detalham a estimativa de esforço real, medida em horas ou dias, para as suas tarefas. Todavia, o OpenUP não estabelece como especificar, coletar, armazenar, analisar outras medidas, bem como não define como comunicar os resultados obtidos. Assim, podemos concluir que o OpenUP não atende às metas e práticas da área de processo Medição e Análise, como sumarizado na tabela III. V. UMA EXTENSÃO DO OPENUP SEGUNDO AS ÁREAS DE PROCESSO GARANTIA DA QUALIDADE E MEDIÇÃO DO CMMI-DEV NÍVEL 2 Esta seção discute as adaptações realizadas no OpenUP com a finalidade de solucionar os problemas de aderência identificados. Essas customizações se deram nos seguintes aspectos: disciplinas, papéis, tarefas, produtos de trabalho, processos e diretrizes. A seguir, descreve-se as alterações mais relevantes. A. Disciplinas Duas novas disciplinas foram adicionadas ao OpenUP. São elas: Garantia da Qualidade do Processo e do Produto (GQPP) e Medição e Análise (MA). B. Papéis Na disciplina GQPP dois novos papéis foram adicionados: Gerente de Garantia de Qualidade de Software (GGQS) e Consultor Garantia de Qualidade de Software (CGQS). O Gerente de GQS é responsável pelo planejamento e acompanhamento das atividades relacionadas à garantia da qualidade de software. Já o Consultor de Garantia de Qualidade de Software conduz as atividades relacionadas à garantia da qualidade dos produtos e dos processos de software. Na disciplina MA dois novos papéis também foram adicionados: o Gerente de Medição e Análise (GMA) e o Consultor de Medição e Análise (CMA). O Gerente de Medição e Análise é responsável pelo planejamento e acompanhamento das atividades relacionadas à medição e análise no seu âmbito de atuação. Já o Consultor de Medição e Análise conduz as atividades relacionadas a medição e análise dos produtos e processos de software. C. Tarefas Na disciplina de GQPP três novas tarefas foram adicionadas. São elas: Planejar e Acompanhar Auditorias de GQS: Esta atividade compreende o planejamento e acompanhamento das auditorias de GQS para um determinado projeto, o que envolve especificar os objetivos, as tarefas de GQS a serem realizadas, os padrões, os procedimentos, a estrutura organizacional e os mecanismos de auditoria que serão utilizados em um determinado projeto. Executar Auditoria: Esta atividade compreende a execução de uma auditoria de GQS em um determinado projeto, tendo por objetivo assegurar que o processo definido seja seguido. Avaliar Auditoria: Esta tarefa compreende a análise das auditorias realizadas. Na disciplina MA três novas tarefas foram adicionadas. São elas: Planejar Medição: Uma tarefa colaborativa que descreve como o projeto que se inicia será medido e acompanhado. Tem por objetivo definir as metas de medição, as métricas associadas e as métricas primitivas a serem coletadas no projeto para monitorar seu andamento. Executar Medições: Esta atividade tem por objetivo realizar os procedimentos necessários para a coleta e validação das medições, conforme descrito no Plano de Medição e Análise (PMA). Inclui também o armazenamento dos resultados para posterior análise.
Meta Específica Prática Específica Classif. SG 1 Alinhar as Atividades de MA SP 1.1-1 Estabelecer Objetivos de Medições NS SP 1.2-1 Especificar Medidas SP 1.3-1 Especificar Procedimentos de Coleta e Armazenagem de Dados SP 1.4-1 Especificar Procedimento de Análises SG 2 Fornecer Resultados de Medição SP 2.1-1 Coletar Dados de Medições SP 2.2-1 Analisar Dados de Medições SP 2.3-1 Armazenar Dados e Resultados SP 2.4-1 Comunicar Resultados Tabela III CLASSIFICAÇÃO DA ÁREA DE PROCESSO MEDIÇÃO E ANÁLISE. Avaliar Medições: Esta atividade tem por objetivo analisar os dados coletados e apresentar as conclusões obtidas. D. Produtos de Trabalho Na disciplina GQPP três novos produtos de trabalho foram adicionados. São eles: Plano de Garantia da Qualidade de Software (PGQS): Este plano oferece uma visão clara de como a qualidade do produto, dos artefatos e do processo será garantida. A finalidade deste plano é especificar os objetivos, as tarefas de GQS a serem realizadas, os padrões, os procedimentos a estrutura organizacional e os mecanismos de auditoria. Registros de Qualidade (RQ): Consiste em um repositório (planilha) utilizado para armazenar as não-conformidades encontradas e os acordos firmados para a resolução destes problemas. Relatório de Garantia da Qualidade de Software (RGQS): Este artefato tem por objetivo fornecer uma visão da qualidade do software em desenvolvimento, dos artefatos gerados e das atividades executadas. Na disciplina MA três novos produtos de trabalho foram adicionados. São eles: Plano de Medição e Análise (PMA): Plano contendo as necessidades de informação e seu desdobramento em objetivos de medição. Este plano especifica quais métricas primitivas devem ser coletadas e quais devem ser calculadas durante o projeto para monitorar o andamento, com base em um conjunto de metas de projeto especificadas. Repositório de Medições (RM): Repositório (planilha) contendo as medições realizadas. Este artefato contém uma base história das medições realizadas, incluindo: data, projeto, métrica, valor medido/calculado, valor esperado e técnica utilizada na medição. Relatório de Medição e Análise (RMA): Relatório contendo a análise das medições executadas. O RMA apresenta os resultados das medições efetuadas e realiza uma análise crítica de cada uma das métricas coletadas e das metas de medição definidas PMA, buscando identificar tendências e oportunidades de melhoria no processo de desenvolvimento definido. A Tabela IV sumariza a customização do OpenUP realizada com a finalidade de se obter um processo ao mesmo tempo ágil e aderente às disciplinas GGPP e MA do CMMI-DEV Nível 2. VI. IMPACTOS DAS ALTERAÇÕES NA AGILIDADE DO PROCESSO Com a finalidade de assegurar a manutenção da agilidade do processo OpenUP sugerimos que a adição das duas novas disciplinas (GQPP e MA) seja realizada utilizando-se uma estrutura matricial onde a organização mantém uma única equipe de Garantia da Qualidade do Processo e do Produto para todos os projetos. Assim, a responsabilidade pelas tarefas desta disciplina não recaem sobre o time de desenvolvimento, mas sobre uma equipe corporativa especializada, o que reduz o impacto das alterações sobre os desenvolvedores. Por este mesmo motivo, esta estratégia deve ser utilizada também para a disciplina Medição e Análise. VII. ESTUDO DE CASO: A APLICAÇÃO DA ABORDAGEM PROPOSTA NA SEFAZ-CE A proposta de extensão do OpenUP efoi inicialmente aplicada em dois projetos reais de desenvolvimento de software na Secretaria da Fazenda do Estado do Ceará (Sefaz-CE). Os dois projetos estudados são similares em termos de plataforma tecnológica (Java/Struts), no tempo estimado para a sua execução (4 meses), na duração das iterações (30 dias), bem como no tamanho da equipe (4 analistas/desenvolvedores). Além disso, em ambos os projetos as equipes são experientes na plataforma tecnológica utilizada, porém esta é a primeira experiência das equipes com a utilização de métodos ágeis. Várias lições puderam se aprendidas pelas equipes de desenvolvimento, dentre as quais se pode destacar: A primeira auditoria de qualidade, denominada de préavaliação informal, teve por objetivo preparar a equipe para o processo de garantia da qualidade. Além disso, as auditorias focaram no atendimentos dos conceitos e das práticas ágeis, verificando, por exemplo, se código executável estava sendo entregue ao final de cada iteração. Estas iniciativas reduziram substancialmente as resistências das equipes em relação às auditorias de qualidade. A simples existência de uma auditoria de GQS gerou o compromisso da equipe com a aderência das atividades realizadas e dos artefatos gerados ao processo definido.
Disciplina Tarefas Produtos de Trabalho (Artefatos) Garantia da Qual. de Software Planejar e Acompanhar Auditorias Plano de GQS (PGQS) de GQS Executar Auditoria de GQS Registros de Qualidade (RQ) Avaliar Auditoria de GQS Relatório de GQS (RGQS) Medição e Análise Planejar Medição Plano de MA (PMA) Executar Medições Repositório de Medições (RM) Avaliar Medições Relatório de MA (RMA) Tabela IV CUSTOMIZAÇÃO DO OPENUP ADERENTE AO CMMI-DEV NÍVEL 2. Além disso, contribui para a internalização dos princípios e práticas adotadas. Como conseqüência, a quantidade de não-conformidades caiu substancialmente a partir da quarta iteração. Código executável foi entregue ao cliente logo na segunda iteração. Além disso, a velocidade da equipe aumentou substancialmente a partir da quarta iteração. A implantação da disciplina de MA mostrou que coletar e analisar indicadores não gera sobrecarga para a equipe de desenvolvimento e que a existência de métricas auxilia a identificação de impedimentos, podendo ajudar no planejamento da equipe. A adaptação proposta não afetou a agilidade do OpenUP uma vez que as novas tarefas e artefatos não são alocadas para a equipe de desenvolvimento. A precisão foi uma das dificuldades encontradas pelas equipes. Contudo, à medida que o time foi se sentindo mais confortável com as técnicas ágeis as estimativas tornaram-se mais precisas. VIII. CONCLUSÕES Este artigo apresentou uma extensão do processo ágil OpenUP aderente às áreas de processo GQPP e MA do CMMI- DEV. Inicialmente, analisamos a aderência do OpenUP às áreas de processo GQPP e MA do CMMI-DEV. O resultado deste estudo indicou que OpenUP não atende às exigências do modelo CMMI. Para cada meta específica do CMMI-DEV que não era inteiramente atendida pelo OpenUP destacamos os motivos e os problemas identificados. Em seguida, sugerimos a adição de alguns papéis, tarefas e artefatos com o objetivo de fazer com que as áreas de processo GQPP e MA do CMMI- DEV Nível 2 passassem a ser atendidas pelo processo proposto. Finalmente, discutimos os impactos desta customização sobre a agilidade do processo e apresentamos os resultados da utilização da abordagem proposta em dois projetos reais de uma instituição governamental, a SEFAZ-CE. Os resultados da experiência realizada mostraram que, apesar do CMMI-DEV e do OpenUP possuírem fundamentos inicialmente pensados como divergentes, eles puderam ser utilizados em conjunto. Como trabalho futuro, pretendemos realizar uma avaliação oficial da maturidade da organização, a fim de termos uma comprovação da aderência do processo de software definido às áreas de processo GQPP e MA do CMMI. REFERÊNCIAS [1] J. A. H. Alegria and M. C. Bastarrica. Implementing cmmi using a combination of agile methods. CLEI Electron Journal, 2006. [2] T. A. Alliance. Agile manifesto. 2001. Disponível em http://agilemanifesto.org/. [3] K. Beck. Extreme Programming Explained. Addison-Wesley, 1999. [4] C. Cardoso. Aplicando práticas de extreme programming (xp) em equipes sw-cmm nível 2. In VI Simpósio Internacional de Melhoria de Processos de Software (SIMPROS 2004), 2004. [5] A. Cockburn. Agile Software Development. Addison=Wesley, 2002. [6] H. Glazer, J. Dalton, D. Anderson, M. Konrad, and S. Shrum. Cmmi or agile: Why not embrace both! Technical report, Software Engineering Institute (SEI), 2008. [7] A. Goldman, F. Kon, P. J. S. Silva, and J. W. Yoder. Being extreme in the classroom: Experiences in teaching xp. Journal of the Brazilian Computer Society, 10(2):1 17, 2004. [8] O. Group. Open unified process. 2009. http://www.epfwiki.net/wikis/openuppt/. [9] M. V. Guimarães. Adaptação do openup para atender aos requisitos do nível f do mps.br. In Proceedings of the Simpósio Internacional de Melhoria de Processos de Software (SIMPROS 2007), 2007. [10] V. Mahnic and N. Zabkar. Introducing cmmi measurement and analysis practices into scrum-based software development process. International Journal of Mathematics and Computers in Simulation, 2007. [11] A. Marçal, B. Freitas, F. Soares, T. Maciel, and A. Belchior. Estendendo o scrum segundo as Áreas de processo de gerenciamento de projetos do cmmi. CLEI Electronic Journal, 2007. [12] A. S. C. Marcal, F. S. F. Soares, and A. D. Belchior. Mapping cmmi project management process areas to scrum practices. In SEW 07: Proceedings of the 31st IEEE Software Engineering Workshop, pages 13 22, Washington, DC, USA, 2007. IEEE Computer Society. [13] M. Pikkarainen and A. Mäntyniemi. An approach for using cmmi in agile software development assessments: Experiences from three case studies. In Proceedings of the SPICE Conference, 2006. [14] C. Santana, A. Timóteo, and A. Vasconcelos. Mapeamento do modelo de melhoria do processo de software brasileiro (mps.br) para empresas que utilizam extreme programming (xp) como metodologia de desenvolvimento. In V Simpósio Brasileiro de Qualidade de Software (SBQS 2006), 2006. [15] K. Schwaber and M. Beedle. Agile Software Development with Scrum. Prentice-Hall, 2002. [16] S. E. I. (SEI). Cmmi for development. 2009. http://www.sei.cmu.edu/cmmi. [17] C. Vriens. Certifying for cmm level 2 and iso9001 with xp@scrum. Agile Development Conference/Australasian Database Conference, 0:120, 2003. [18] D. M. Woit. Requirements interaction management in an extreme programming environment: a case study. In ICSE 05: Proceedings of the 27th international conference on Software engineering, pages 489 494, New York, NY, USA, 2005. ACM. [19] A. L. Zanatta and P. Vilain. Uma análise do método ágil scrum conforme abordagem nas áreas de processo gerenciamento e desenvolvimento de requisitos do cmmi. In Proceedings of the Workshop em Engenharia de Requisitos (WER 05), pages 209 220, 2005.