´ Estendendo o OpenUP para Atender as Areas de Processo Relacionadas a Garantia da Qualidade e Medic¸a˜ o do CMMI-DEV N´ıvel 2 Murilo Ybanez

Jos´e Maria Monteiro

Secretaria da Fazenda do Estado do Cear´a - Sefaz-CE

Universidade Federal do Cear´a - UFC

Resumo—Este artigo apresenta uma extens˜ao do processo a´ gil OpenUP aderente a` s a´ reas de processo Garantia da Qualidade do Processo e do Produto e Medic¸a˜ o e An´alise do CMMIDEV N´ıvel 2. O estudo desenvolvido realiza inicialmente um mapeamento entre o OpenUP e estas duas a´ reas de processo. Os resultados da an´alise realizada indicam que o OpenUP n˜ao atende a` s exigˆencias presentes no modelo CMMI-DEV para as duas a´ reas de processo estudadas. A partir desta constatac¸a˜ o, sugere-se a adic¸a˜ o de alguns pap´eis, tarefas e artefatos visando deixar o OpenUP compat´ıvel com as a´ reas de processo Garantia da Qualidade do Processo e do Produto e Medic¸a˜ o e An´alise do CMMI-DEV, sem, no entanto, comprometer seus princ´ıpios a´ geis. Al´em disso, este trabalho relata os resultados da utilizac¸a˜ o da abordagem proposta em uma instituic¸a˜ o governamental.

˜ I. I NTRODUC¸ AO Na economia moderna, e´ freq¨uentemente dif´ıcil prever como um sistema de software ir´a evoluir com o passar do tempo. Condic¸o˜ es de mercado mudam rapidamente, as necessidades dos usu´arios evoluem e novas ameac¸as de competic¸a˜ o emergem sem alerta. Neste contexto, os m´etodos a´ geis representam uma estrat´egia para atender a` dinˆamica dos projetos atuais. As metodologias a´ geis surgiram com a preocupac¸a˜ o de acomodar melhor as modificac¸o˜ es, possibilitando a` s equipes reagir rapidamente quando mudanc¸as s˜ao necess´arias. Nos u´ ltimos anos, m´etodos a´ geis como o XP (eXtreme Programming) [3], Scrum [15] e Crystal [5] passaram a ser usados em empresas, universidades e agˆencias governamentais [7]. Por outro lado, os modelos de capacidade de maturidade, como o CMMI (Capability Maturity Model Integration) [6], constituem uma estrat´egia bastante utilizada pelas empresas de software para melhorar sua visibilidade internacional e, conseq¨uentemente, poder concorrer em um mercado globalizado, al´em de aperfeic¸oar efetivamente seus processos de software. Contudo, atualmente, organizac¸o˜ es que empregaram um grande esforc¸o na melhoria dos seus processos com base no CMMI, agora acreditam tamb´em que os m´etodos a´ geis possam prover incrementos de melhorias [11]. Neste sentido, a combinac¸a˜ o das metodologias a´ geis com modelos de maturidade de software comec¸a a ser investigada [9], [4], [19], [14], [13], [11], [6]. Apesar da existˆencia de caracter´ısticas distintas entre os m´etodos a´ geis e o modelo CMMI, ambos possuem planos espec´ıficos para o desenvolvimento de software e buscam o melhor para que a organizac¸a˜ o

produza software com qualidade [11]. Em [6] os autores argumentam que, apesar de existir uma grande controv´ersia entre a compatibilidade dos m´etodos a´ geis e o CMMI, eles n˜ao s˜ao mutuamente exclusivos. Inserido neste contexto de controv´ersias e compatibilidades entre CMMI e m´etodos a´ geis, este trabalho apresenta uma extens˜ao do m´etodo a´ gil OpenUP aderente a` s a´ reas de processo Garantia da Qualidade do Processo e do Produto (GQPP) e Medic¸a˜ o e An´alise (MA) do CMMI-DEV N´ıvel 2. O estudo desenvolvido realiza inicialmente um mapeamento entre o OpenUP e estas duas a´ reas de processo, avaliando o atendimento das pr´aticas espec´ıficas do modelo. A partir desta avaliac¸a˜ o, sugere-se a adic¸a˜ o de alguns pap´eis, tarefas e artefatos visando deixar o OpenUP compat´ıvel com as a´ reas de processo GQPP e MA do CMMI-DEV, sem, no entanto, perder seus princ´ıpios a´ geis. A extens˜ao proposta para o OpenUP tem por objetivo auxiliar as organizac¸o˜ es que tˆem o desejo de adotar uma metodologia a´ gil e que esteja compat´ıvel com as pr´aticas do CMMI-DEV. A abordagem proposta foi aplicada em dois projetos reais de uma instituic¸a˜ o governamental, a SEFAZ-CE. O restante deste artigo est´a organizado da seguinte forma: a sec¸a˜ o 2 apresenta os principais conceitos utilizados neste trabalho, na sec¸a˜ o 3 s˜ao discutidos os trabalhos relacionados, a sec¸a˜ o 4 analisa a aderˆencia do OpenUP a` s disciplinas GQPP e MA, na sec¸a˜ o 5 e´ discutida a abordagem proposta, a sec¸a˜ o 6 analisa os impactos das alterac¸o˜ es propostas na agilidade do OpenUP, na sec¸a˜ o 7 apresentamos um estudo de caso e a sec¸a˜ o 8 conclui este trabalho. ´ II. C ONCEITOS B ASICOS Nesta sec¸a˜ o, apresentaremos uma vis˜ao geral das metodologias a´ geis, do processo a´ gil OpenUp e do CMMI. ´ A. Metodologias Ageis ´ O termo “Metodologias Ageis” tornou-se popular em 2001 quando dezessete especialistas em processos de desenvolvimento de software representando os m´etodos Scrum [15], XP [3] e outros, estabeleceram princ´ıpios comuns compartilhados ´ por todos esses m´etodos. Foi ent˜ao criada a Alianc¸a Agil e ´ estabelecido o “Manifesto Agil” [2].

B. OpenUP O OpenUP (Open Unified Process) e´ 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, abrac¸a uma filosofia a´ gil que foca na natureza colaborativa do desenvolvimento de software. Al´em disso, e´ um processo que pode ser estendido para direcionar uma grande variedade de tipos de projeto. Vale ressaltar tamb´em que o OpenUP tenta seguir a linha pragm´atica de n˜ao ignorar a consider´avel adoc¸a˜ o do RUP pelo mercado, e, portanto, ele tenta ser um caminho de migrac¸a˜ o para metodologias a´ geis, preservando alguns formalismos, principalmente no que diz respeito a documentac¸a˜ o de requisitos e arquitetura. O OpenUP e´ modelado atrav´es da ferramenta EPF Composer (Eclipse Process Framework). O EPF Composer e´ uma ferramenta open-source, amparada pela fundac¸a˜ o Eclipse, que possibilita o gerenciamento de processos e tem como principais caracter´ısticas um f´acil aprendizado, m´etodos simples de autoria, customizac¸a˜ o e criac¸a˜ o de processos, al´em da gerac¸a˜ o autom´atica da documentac¸a˜ o do processo definido. Esta documentac¸a˜ o consiste em um web site o qual e´ composto por cinco elementos b´asicos: • Produto de Trabalho: s˜ ao os artefatos produzidos; • Tarefa: como executar o trabalho; • Papel: quem executa o trabalho; • Processo: s˜ ao usados para definir os fluxos de trabalho; • Diretriz: templates, checklists, exemplos, guias, conceitos, dentre outros. C. CMMI O CMMI (Capability Maturity Model Integration) e´ um modelo de referˆencia que cont´em pr´aticas (Gen´ericas ou Espec´ıficas) necess´arias a` maturidade em disciplinas espec´ıficas (Software Engineering (SW), por exemplo). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI e´ uma evoluc¸a˜ o do CMM e procura estabelecer um modelo u´ nico para o processo de melhoria corporativa, integrando diferentes modelos e disciplinas [6]. A vers˜ao atual do CMMI (vers˜ao 1.2) apresenta dois modelos: • CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao processo de desenvolvimento de produtos e servic¸os. • CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se aos processos de aquisic¸a˜ o e terceirizac¸a˜ o de bens e servic¸os. O modelo CMMI v1.2 (CMMI-DEV) est´a estruturado em 5 n´ıveis de maturidade, contendo 22 a´ reas de processo (Process Area - PAs), as quais s˜ao divididas em 4 categorias: Gerenciamento de projetos, Gerenciamento de processos, Engenharia e Suporte.

III. T RABALHOS R ELACIONADOS No trabalho apresentado em [19] e´ realizada uma an´alise do m´etodo a´ gil Scrum em relac¸a˜ o a` s a´ reas de processo Gerenciamento de Requisitos e Desenvolvimento de Requisitos do modelo CMMI. As exigˆencias n˜ao atendidas pelo Scrum s˜ao destacadas e algumas soluc¸o˜ es s˜ao propostas. Em [11], [12], os autores apresentam uma abordagem do m´etodo a´ gil Scrum compat´ıvel com a´ reas de Gerenciamento de Projetos do CMMI. A abordagem proposta foi aplicada em uma organizac¸a˜ o de inovac¸a˜ o e pesquisa no desenvolvimento de projetos de software. Em [18], e´ apresentada uma extens˜ao do XP com o objetivo de incorporar pr´aticas de engenharia de requisitos. Trˆes modificac¸o˜ es s˜ao propostas: 1) utilizar um documento de requisitos, o qual e´ gerenciado pelos pap´eis 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˜ao mais ampla do sistema a ser desenvolvido. Al´em disso, os autores argumentam que as modificac¸o˜ es propostas s˜ao simples e metodologia proposta e´ quase t˜ao leve quanto o XP original. O artigo descrito em [4] apresenta a an´alise da aplicac¸a˜ o de pr´aticas de XP em equipes avaliadas oficialmente em SW-CMMI n´ıvel 2, destacando as vantagens e dificuldades desta abordagem. Em [14] s˜ao apresentas sugest˜oes de modificac¸o˜ es necess´arias para que uma organizac¸a˜ 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 (MPS.BR). O estudo discutido em [17], mostra uma experiˆencia em que uma empresa se submete a` s certificac¸o˜ es CMM n´ıvel 2 e ISO9001 usando XP e Scrum. Nesta experiˆencia as contribuic¸o˜ es destes dois m´etodos a´ geis s˜ao combinadas: XP foi utilizado nos processos t´ecnicos, enquanto Scrum foi utilizado para apoiar as quest˜oes organizacionais e de gest˜ao. O trabalho apresentado em [1] explora a possibilidade de companhias de software de obter uma certificac¸a˜ o CMMI de seus processos atrav´es da aplicac¸a˜ o de pr´aticas a´ geis. Em [13] e´ apresentado uma abordagem para o desenvolvimento de software a´ gil que e´ compat´ıvel com CMMI. Al´em disso, o artigo descreve como a abordagem proposta foi utilizada com o prop´osito de incrementar o processo de desenvolvimento de software em trˆes estudos de caso. O artigo descrito em [10] apresenta o projeto de um reposit´orio de medic¸o˜ es que possibilita o monitoramento e a melhoria cont´ınua do desempenho de processos de desenvolvimento de software baseados no m´etodo a´ gil Scrum. Uma adaptac¸a˜ o do OpenUP para atender aos requisitos do N´ıvel F do MPS.BR e´ 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˜ao do OpenUP compat´ıvel com as a´ reas de processo GQPP e MA do CMMIDEV n´ıvel 2, contribuindo para o estado da arte na integrac¸a˜ o de m´etodos a´ geis e modelos de maturidade de software.

´ REAS DE ´ IV. U MA A N ALISE DO O PEN UP SEGUNDO AS A ˜ DO P ROCESSO G ARANTIA DA Q UALIDADE E M EDIC¸ AO CMMI-DEV N´I VEL 2 O m´etodo a´ gil OpenUP foi avaliado segundo as perspectivas do modelo CMMI, somente nas a´ reas de processo GQPP e MA pertencentes ao n´ıvel 2 deste mesmo modelo. Para cada uma destas a´ reas de processo foi realizada uma an´alise detalhada comparando suas metas e pr´aticas espec´ıficas contra as disciplinas, pap´eis, tarefas e artefatos do OpenUP. Em seguida, atribuiu-se um valor para cada uma destas metas e pr´aticas espec´ıficas a fim de classificar o n´ıvel de adequac¸a˜ o do OpenUP a` estas metas e pr´aticas. A Tabela I apresenta os crit´erios utilizados nesta classificac¸a˜ o. A seguir, s˜ao apresentados, para cada a´ rea de processo investigada, os resultados gerais da an´alise realizada enfatizando os pontos nos quais o OpenUP atende ou n˜ao pr´aticas do CMMI-DEV. ´ A. An´alise da Area de Processo Garantia da Qualidade do Processo e do Produto (GQPP) O objetivo da Garantia da Qualidade do Processo e do Produto e´ fornecer a` equipe e a` gerˆencia um entendimento objetivo dos processos e seus produtos de trabalho associados. Esta a´ rea de processo suporta a entrega de produtos e servic¸os de alta qualidade, fornecendo, a` 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 e´ alcanc¸ada atrav´es de um conjunto de pr´aticas relacionadas a` disciplina de Teste, como por exemplo: desenvolvimento guiado por testes, programac¸a˜ o em pares, refactoring, c´odigo coletivo, c´odigo padronizado, design simples e integrac¸a˜ o cont´ınua. O desenvolvimento guiado por testes defende que os desenvolvedores escrevam testes automatizados para cada funcionalidade antes de codific´a-las. Fazendo isso, eles aprofundam o entendimento das necessidades do cliente (o que aprimora a an´alise) e passam a contar com uma massa de testes que pode ser utilizada a qualquer momento para validar todo o sistema. A programac¸a˜ o em pares permite que o c´odigo seja revisado permanentemente, enquanto e´ constru´ıdo. Al´em de contribuir para que a implementac¸a˜ o sela mais simples e eficaz, j´a que os desenvolvedores se complementam e tˆem mais oportunidades de gerar soluc¸o˜ es inovadoras. O refactoring e´ o ato de alterar o c´odigo sem afetar a funcionalidade que ele implementa. Ele e´ utilizado para que o sistema possa evoluir de forma incremental, tornando o software mais simples de ser manipulado. A propriedade coletiva do c´odigo fornece maior agilidade ao processo e cria mais um mecanismo de revis˜ao e verificac¸a˜ o do c´odigo. Os padr˜oes de codificac¸a˜ o tornam o sistema mais homogˆeneo e permite que qualquer manutenc¸a˜ o futura seja efetuada mais rapidamente. A pr´atica do design simples leva o desenvolvedor a optar pela simplicidade ao inv´es de criar generalizac¸o˜ es dentro do c´odigo com o objetivo de prepar´a-lo para poss´ıveis necessidades futuras, pois para isso existem o refactoring, os testes e outras pr´aticas.

A integrac¸a˜ o cont´ınua assegura que sempre que uma nova funcionalidade e´ incorporada ao sistema as funcionalidades anteriormente implementadas s˜ao checadas (atrav´es dos testes automatizados) a fim de descobrir eventuais defeitos, facilitando e acelerando a correc¸a˜ o destes poss´ıveis erros. Contudo, o OpenUP n˜ao possui pr´aticas voltadas para a garantia da qualidade do processo. Assim, o monitoramento e a avaliac¸a˜ o da aderˆencia das atividades e produtos de trabalho produzidos ao processo definido n˜ao constituem objeto de nenhuma disciplina do OpenUP. Assim, podemos concluir que o OpenUP n˜ao atende a` s metas e pr´aticas da a´ rea de processo Garantia da Qualidade do Processo e do Produto, como sumarizado na tabela II. ´ B. An´alise da Area de Processo Medic¸a˜ o e An´alise (MA) O objetivo das Medic¸o˜ es e An´alises e´ desenvolver e sustentar a capacidade de medic¸o˜ es que e´ utilizada para suportar as necessidades de gerenciamento de informac¸o˜ es [16]. A medic¸a˜ o permite prever e monitorar custos e prazos, al´em de controlar a qualidade do processo, melhorando a compreens˜ao e a validac¸a˜ o do mesmo. O OpenUP baseia-se na id´eia de estimativa a´ gil, a qual e´ constru´ıda a partir de trˆes 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 iterac¸a˜ o; • Estimativa de esforc ¸ o: traduz o tamanho (medido em pontos) para uma estimativa de esforc¸o detalhada usando normalmente as unidades de Dias Reais ou Horas Reais. A estimativa de esforc¸o indica quanto tempo os membros da equipe necessitar˜ao para completar os itens de trabalho. A estimativa de tamanho a´ gil e´ realizada normalmente usando uma medida relativa chamada pontos. A equipe decide qu˜ao grande um ponto e´ , 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´ecnica denominada Planning Poker. A velocidade e´ uma importante m´etrica usada para o planejamento da iterac¸a˜ o. Ela indica quantos pontos s˜ao entregues em uma iterac¸a˜ o por uma determina equipe em um projeto. Por exemplo, uma equipe planejou fazer 20 pontos na primeira iterac¸a˜ o. Ao final da iterac¸a˜ o, eles observam que entregaram somente 14 pontos, ent˜ao sua velocidade foi 14. Espera-se que a velocidade mude de iterac¸a˜ o para iterac¸a˜ o. Por´em, no geral, a velocidade normalmente aumenta durante o projeto a` medida que a equipe melhora suas habilidades e se torna mais coesa. A estimativa de esforc¸o traduz o tamanho (medido em pontos) para uma estimativa de esforc¸o detalhada usando ` normalmente as unidades de Dias Reais ou de Horas Reais. A medida que vocˆe planeja uma iterac¸a˜ o ser´a necess´ario dividir um item de trabalho em tarefas menores. Os membros da equipe s˜ao convidados a prontificarem-se para a realizac¸a˜ o

Sigla NS PS

Classificac¸a˜ o N˜ao Satisfeito Parcialmente Satisfeito

S

Satisfeita

Crit´erio N˜ao h´a evidˆencias da pr´atica no OpenUP. H´a evidˆencias da pr´atica no OpenUP, embora a pr´atica n˜ao esteja plenamente atendida. A pr´atica est´a totalmente atendida no OpenUP.

Tabela I ´ REAS DE P ROCESSO . ˜ DAS A C RIT E´ RIOS PARA C LASSIFICAC¸ AO

Meta Espec´ıfica SG 1 Avaliar Objetivamente Processos e Produtos de Trabalho

SG 2 Fornecer um Entendimento Objetivo

Pr´atica Espec´ıfica SP 1.1-1 Avaliar Objetivamente os Processos SP 1.2-1 Avaliar Objetivamente os Produtos de Trabalho e Servic¸os SP 2.1-1 Comunicar e Assegurar a Resoluc¸a˜ o das Quest˜oes de N˜ao Conformidades SP 2.2-1 Estabelecer Registros

Classif. NS NS NS NS

Tabela II ´ REA DE P ROCESSO G ARANTIA DA Q UALIDADE DO P ROCESSO E P RODUTO . ˜ DA A C LASSIFICAC¸ AO

das tarefas e, em seguida, detalham a estimativa de esforc¸o real, medida em horas ou dias, para as suas tarefas. Todavia, o OpenUP n˜ao estabelece como especificar, coletar, armazenar, analisar outras medidas, bem como n˜ao define como comunicar os resultados obtidos. Assim, podemos concluir que o OpenUP n˜ao atende a` s metas e pr´aticas da a´ rea de processo Medic¸a˜ o e An´alise, como sumarizado na tabela III.

An´alise e´ respons´avel pelo planejamento e acompanhamento das atividades relacionadas a` medic¸a˜ o e an´alise no seu aˆ mbito de atuac¸a˜ o. J´a o Consultor de Medic¸a˜ o e An´alise conduz as atividades relacionadas a medic¸a˜ o e an´alise dos produtos e processos de software.

´ REAS DE ˜ DO O PEN UP SEGUNDO AS A V. U MA E XTENS AO ˜ DO P ROCESSO G ARANTIA DA Q UALIDADE E M EDIC¸ AO CMMI-DEV N´I VEL 2

Na disciplina de GQPP trˆes novas tarefas foram adicionadas. S˜ao 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˜oes, os procedimentos, a estrutura organizacional e os mecanismos de auditoria que ser˜ao utilizados em um determinado projeto. • Executar Auditoria: Esta atividade compreende a execuc¸a˜ 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´ alise das auditorias realizadas. Na disciplina MA trˆes novas tarefas foram adicionadas. S˜ao elas: • Planejar Medic ¸ a˜ o: Uma tarefa colaborativa que descreve como o projeto que se inicia ser´a medido e acompanhado. Tem por objetivo definir as metas de medic¸a˜ o, as m´etricas associadas e as m´etricas primitivas a serem coletadas no projeto para monitorar seu andamento. • Executar Medic ¸ o˜ es: Esta atividade tem por objetivo realizar os procedimentos necess´arios para a coleta e validac¸a˜ o das medic¸o˜ es, conforme descrito no Plano de Medic¸a˜ o e An´alise (PMA). Inclui tamb´em o armazenamento dos resultados para posterior an´alise.

Esta sec¸a˜ o discute as adaptac¸o˜ es realizadas no OpenUP com a finalidade de solucionar os problemas de aderˆencia identificados. Essas customizac¸o˜ es se deram nos seguintes aspectos: disciplinas, pap´eis, tarefas, produtos de trabalho, processos e diretrizes. A seguir, descreve-se as alterac¸o˜ es mais relevantes. A. Disciplinas Duas novas disciplinas foram adicionadas ao OpenUP. S˜ao elas: Garantia da Qualidade do Processo e do Produto (GQPP) e Medic¸a˜ o e An´alise (MA). B. Pap´eis Na disciplina GQPP dois novos pap´eis foram adicionados: Gerente de Garantia de Qualidade de Software (GGQS) e Consultor Garantia de Qualidade de Software (CGQS). O Gerente de GQS e´ respons´avel pelo planejamento e acompanhamento das atividades relacionadas a` garantia da qualidade de software. J´a o Consultor de Garantia de Qualidade de Software conduz as atividades relacionadas a` garantia da qualidade dos produtos e dos processos de software. Na disciplina MA dois novos pap´eis tamb´em foram adicionados: o Gerente de Medic¸a˜ o e An´alise (GMA) e o Consultor de Medic¸a˜ o e An´alise (CMA). O Gerente de Medic¸a˜ o e

C. Tarefas

Meta Espec´ıfica SG 1 Alinhar as Atividades de MA

SG 2 Fornecer Resultados de Medic¸a˜ o

Pr´atica Espec´ıfica SP 1.1-1 Estabelecer Objetivos de Medic¸o˜ es 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´alises SP 2.1-1 Coletar Dados de Medic¸o˜ es SP 2.2-1 Analisar Dados de Medic¸o˜ es SP 2.3-1 Armazenar Dados e Resultados SP 2.4-1 Comunicar Resultados

Classif. NS PS PS PS PS PS PS PS

Tabela III ´ REA DE P ROCESSO M EDIC¸ AO ˜ DA A ˜ E A N ALISE ´ C LASSIFICAC¸ AO .

•

Avaliar Medic¸o˜ es: Esta atividade tem por objetivo analisar os dados coletados e apresentar as conclus˜oes obtidas.

D. Produtos de Trabalho Na disciplina GQPP trˆes novos produtos de trabalho foram adicionados. S˜ao eles: • Plano de Garantia da Qualidade de Software (PGQS): Este plano oferece uma vis˜ao clara de como a qualidade do produto, dos artefatos e do processo ser´a garantida. A finalidade deste plano e´ especificar os objetivos, as tarefas de GQS a serem realizadas, os padr˜oes, os procedimentos a estrutura organizacional e os mecanismos de auditoria. • Registros de Qualidade (RQ): Consiste em um reposit´ orio (planilha) utilizado para armazenar as n˜ao-conformidades encontradas e os acordos firmados para a resoluc¸a˜ o destes problemas. • Relat´ orio de Garantia da Qualidade de Software (RGQS): Este artefato tem por objetivo fornecer uma vis˜ao da qualidade do software em desenvolvimento, dos artefatos gerados e das atividades executadas. Na disciplina MA trˆes novos produtos de trabalho foram adicionados. S˜ao eles: • Plano de Medic ¸ a˜ o e An´alise (PMA): Plano contendo as necessidades de informac¸a˜ o e seu desdobramento em objetivos de medic¸a˜ o. Este plano especifica quais m´etricas 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´ orio de Medic¸o˜ es (RM): Reposit´orio (planilha) contendo as medic¸o˜ es realizadas. Este artefato cont´em uma base hist´oria das medic¸o˜ es realizadas, incluindo: data, projeto, m´etrica, valor medido/calculado, valor esperado e t´ecnica utilizada na medic¸a˜ o. • Relat´ orio de Medic¸a˜ o e An´alise (RMA): Relat´orio contendo a an´alise das medic¸o˜ es executadas. O RMA apresenta os resultados das medic¸o˜ es efetuadas e realiza uma an´alise cr´ıtica de cada uma das m´etricas coletadas e das metas de medic¸a˜ o definidas PMA, buscando identificar tendˆencias e oportunidades de melhoria no processo de desenvolvimento definido. A Tabela IV sumariza a customizac¸a˜ o do OpenUP realizada com a finalidade de se obter um processo ao mesmo tempo

a´ gil e aderente a` s disciplinas GGPP e MA do CMMI-DEV N´ıvel 2. ˜ NA AGILIDADE DO VI. I MPACTOS DAS A LTERAC¸ OES P ROCESSO Com a finalidade de assegurar a manutenc¸a˜ o da agilidade do processo OpenUP sugerimos que a adic¸a˜ o das duas novas disciplinas (GQPP e MA) seja realizada utilizando-se uma estrutura matricial onde a organizac¸a˜ o mant´em uma u´ nica equipe de Garantia da Qualidade do Processo e do Produto para todos os projetos. Assim, a responsabilidade pelas tarefas desta disciplina n˜ao recaem sobre o time de desenvolvimento, mas sobre uma equipe corporativa especializada, o que reduz o impacto das alterac¸o˜ es sobre os desenvolvedores. Por este mesmo motivo, esta estrat´egia deve ser utilizada tamb´em para a disciplina Medic¸a˜ o e An´alise. ˜ DA A BORDAGEM VII. E STUDO DE C ASO : A A PLICAC¸ AO P ROPOSTA NA S EFAZ -CE A proposta de extens˜ao do OpenUP efoi inicialmente aplicada em dois projetos reais de desenvolvimento de software na Secretaria da Fazenda do Estado do Cear´a (Sefaz-CE). Os dois projetos estudados s˜ao similares em termos de plataforma tecnol´ogica (Java/Struts), no tempo estimado para a sua execuc¸a˜ o (4 meses), na durac¸a˜ o das iterac¸o˜ es (30 dias), bem como no tamanho da equipe (4 analistas/desenvolvedores). Al´em disso, em ambos os projetos as equipes s˜ao experientes na plataforma tecnol´ogica utilizada, por´em esta e´ a primeira experiˆencia das equipes com a utilizac¸a˜ o de m´etodos a´ geis. V´arias lic¸o˜ es puderam se aprendidas pelas equipes de desenvolvimento, dentre as quais se pode destacar: • A primeira auditoria de qualidade, denominada de pr´ eavaliac¸a˜ o informal, teve por objetivo preparar a equipe para o processo de garantia da qualidade. Al´em disso, as auditorias focaram no atendimentos dos conceitos e das pr´aticas a´ geis, verificando, por exemplo, se c´odigo execut´avel estava sendo entregue ao final de cada iterac¸a˜ o. Estas iniciativas reduziram substancialmente as resistˆencias das equipes em relac¸a˜ o a` s auditorias de qualidade. • A simples existˆ encia de uma auditoria de GQS gerou o compromisso da equipe com a aderˆencia das atividades realizadas e dos artefatos gerados ao processo definido.

Disciplina Garantia da Qual. de Software

Medic¸a˜ o e An´alise

Tarefas Planejar e Acompanhar Auditorias de GQS Executar Auditoria de GQS Avaliar Auditoria de GQS Planejar Medic¸a˜ o Executar Medic¸o˜ es Avaliar Medic¸o˜ es

Produtos de Trabalho (Artefatos) Plano de GQS (PGQS) Registros de Qualidade (RQ) Relat´orio de GQS (RGQS) Plano de MA (PMA) Reposit´orio de Medic¸o˜ es (RM) Relat´orio de MA (RMA)

Tabela IV ˜ DO O PEN UP A DERENTE AO CMMI-DEV N´I VEL 2. C USTOMIZAC¸ AO

•

•

•

•

Al´em disso, contribui para a internalizac¸a˜ o dos princ´ıpios e pr´aticas adotadas. Como conseq¨ueˆ ncia, a quantidade de n˜ao-conformidades caiu substancialmente a partir da quarta iterac¸a˜ o. C´odigo execut´avel foi entregue ao cliente logo na segunda iterac¸a˜ o. Al´em disso, a velocidade da equipe aumentou substancialmente a partir da quarta iterac¸a˜ o. A implantac¸a˜ o da disciplina de MA mostrou que coletar e analisar indicadores n˜ao gera sobrecarga para a equipe de desenvolvimento e que a existˆencia de m´etricas auxilia a identificac¸a˜ o de impedimentos, podendo ajudar no planejamento da equipe. A adaptac¸a˜ o proposta n˜ao afetou a agilidade do OpenUP uma vez que as novas tarefas e artefatos n˜ao s˜ao alocadas para a equipe de desenvolvimento. A precis˜ao foi uma das dificuldades encontradas pelas equipes. Contudo, a` medida que o time foi se sentindo mais confort´avel com as t´ecnicas a´ geis as estimativas tornaram-se mais precisas. ˜ VIII. C ONCLUS OES

Este artigo apresentou uma extens˜ao do processo a´ gil OpenUP aderente a` s a´ reas de processo GQPP e MA do CMMIDEV. Inicialmente, analisamos a aderˆencia do OpenUP a` s a´ reas de processo GQPP e MA do CMMI-DEV. O resultado deste estudo indicou que OpenUP n˜ao atende a` s exigˆencias do modelo CMMI. Para cada meta espec´ıfica do CMMI-DEV que n˜ao era inteiramente atendida pelo OpenUP destacamos os motivos e os problemas identificados. Em seguida, sugerimos a adic¸a˜ o de alguns pap´eis, tarefas e artefatos com o objetivo de fazer com que as a´ reas de processo GQPP e MA do CMMIDEV N´ıvel 2 passassem a ser atendidas pelo processo proposto. Finalmente, discutimos os impactos desta customizac¸a˜ o sobre a agilidade do processo e apresentamos os resultados da utilizac¸a˜ o da abordagem proposta em dois projetos reais de uma instituic¸a˜ o governamental, a SEFAZ-CE. Os resultados da experiˆencia 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 avaliac¸a˜ o oficial da maturidade da organizac¸a˜ o, a fim de termos uma comprovac¸a˜ o da aderˆencia do processo de software definido a` s a´ reas de processo GQPP e MA do CMMI.

R EFER Eˆ 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´aticas de extreme programming (xp) em equipes sw-cmm n´ıvel 2. In VI Simp´osio 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˜aes. Adaptac¸a˜ o do openup para atender aos requisitos do n´ıvel f do mps.br. In Proceedings of the Simp´osio 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. Marc¸al, B. Freitas, F. Soares, T. Maciel, and A. Belchior. Estendendo ´ o scrum segundo as Areas 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¨antyniemi. 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´oteo, 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´osio 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´alise do m´etodo a´ gil scrum conforme abordagem nas a´ 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.