engenharia de software - edição 26

www.infnet.edu.br - [email protected] - Central de Atendimento: (21) 2122-8800

E D U C A Ç Ã O S U P E R I O R O R I E N T A D A A O M E R C A D O

PÓS-GRADUAÇÃO

Engenharia de Software: Desenvolvimento Java

Engenharia de Software: Desenvolvimento .NET

GRADUAÇÃO

Engenharia de ComputaçãoAnálise e Desenv. de Sistemas

FORMAÇÕES

Desenvolvedor Java

Desenv. Java: Sist. Distribuídos

Gestor de TI

Desenvolvedor Web .NET 2008

MCITP Server Administrator

SQL Server 2008

Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti

A Escola Superior da Tecnologia da Informação oferece as melhores opções em cursos, formações, graduações e pós-graduações para profissionais de desenvolvimento e programação.

São programas voltados para a formação de profissionais de elite, com aulas 100% práticas, corpo docente atuante no mercado, acesso à mais atualizada biblioteca de TI do Rio, laboratórios equipados com tecnologia de ponta, salas de estudo e exames.

r/esti

TURMASNO RIO DEJANEIRO

Modéstia à parte, suamelhor opção para

se destacar no mercado!

Corpo Editorial

ColaboradoresRodrigo Oliveira Spí[email protected]

Marco Antônio Pereira AraújoEduardo Oliveira Spínola

Capa e DiagramaçãoRomulo Araujo - [email protected]

Coordenação GeralDaniella Costa - [email protected]

Revisor e SupervisorThiago Vincenzo - [email protected]

Na Webwww.devmedia.com.br/esmag

Ano 3 - 26ª Edição - 2010 Impresso no Brasil

Ao final dos anos 90, como reação às formas tradicionais de desenvolvimento de

software, que baseado em estudos realizados pela indústria e academia foi apon-

tada como a principal responsável por falhas encontradas em projetos de softwa-

re, acompanhamos o surgimento de várias metodologias ágeis, como: Adaptive Software

Development, Crystal, Dynamic Systems Development, eXtreme Programming (XP), Featu-

re Driven Development (FDD) e Scrum.

Neste sentido, organizações que procuram melhoria em seus processos de produção

através de modelos e frameworks como Capabitity Model Integration (CMMI), Control

Objectives for Information and related Technology (COBIT), Information Technology In-

frastructure Library (ITIL), entre outros, agora também acreditam que introduzir conceitos

ágeis em seus processos de desenvolvimento, buscando um equilíbrio entre agilidade e

maturidade, é uma alternativa capaz de promover a melhoria da qualidade dos seus pro-

dutos e, consequentemente, aumento da competitividade no mercado.

Segundo o Softex, alcançar competitividade pela qualidade para as empresas de softwa-

re implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos,

como dos processos de produção e distribuição de software. Desta forma, assim como

para outros setores, qualidade é fator crítico de sucesso para a indústria de software.

O desenvolvimento ágil e os modelos e padrões de qualidade de software tradicionais

são vistos frequentemente como contraditórios, pois se tem o raciocínio que os modelos

são muito burocráticos, enquanto que o desenvolvimento ágil é ad-hoc. Na verdade exis-

tem desafios na integração entre os dois, embora o esforço possa valer a pena, pois ao final

pode-se obter qualidade no produto através da união de maturidade e agilidade.

Neste contexto, a Engenharia de Software Magazine destaca nesta edição a matéria “

Extensão do Scrum segundo o MPS.BR nível G” cujo o objetivo é propor uma estratégia para

extensão do Scrum segundo as áreas de processo do guia MPS.BR nível G. Este estudo se

inicia com o mapeamento entre o Scrum e o MPS.BR através de uma avaliação dos resultados

esperados do guia segundo as práticas do Scrum. A partir deste mapeamento, uma extensão

do Scrum é realizada através da adição de práticas complementares para satisfazer o guia. Ao

final, é gerado um novo processo de desenvolvimento para uma fábrica de software.

Além desta matéria, esta edição traz mais cinco artigos:

• Lidando com o risco nas corporações

• Extração de métricas em software orientado a objetos

• Análise de dependências entre práticas específicas do nível 2 do CMMI

• Integração das ferramentas Trac e Subversion

• Auditoria de Sistemas Baseada em Riscos

Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spínola [email protected] em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo minis-trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.

Marco Antônio Pereira Araújo - Editor([email protected])Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.

Eduardo Oliveira Spínola([email protected]) É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-gazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).

Apoio

Atendimento ao Leitor

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.

Se você tiver algum problema no recebimento do seu exemplar ou precisar de

algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de

bancas de jornal, entre outros, entre em contato com:

Cristiany Queiróz– Atendimento ao Leitorwww.devmedia.com.br/mancad(21) 2220-5338

Kaline DolabellaGerente de Marketing e [email protected](21) 2220-5338

Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato com:

Kaline [email protected]

Fale com o Editor!

É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo

você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a

vontade para entrar em contato com os editores e dar a sua sugestão!

Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,

entre em contato com os editores, informando o título e mini-resumo do tema que você

gostaria de publicar:

Rodrigo Oliveira Spínola - Colaborador

[email protected]

EDITORIAL

ÍNDICE

Por trás do obvio

06 - Lidando com o risco nas corporaçõesGlênio Cabral

Agilidade

07 - Extensão do Scrum segundo o MPS.BR nível GFernando Szimanski, Jones Oliveira de Albuquerque e Felipe Furtado

Engenharia

15 - Extração de métricas em software orientado a objetosBruno Góis Borges

35 - Análise de dependências entre práticas específicas do nível 2 do CMMI Thiago Salhab Alves e Paulo C. Barreto da Silva

Desenvolvimento

41 - Integração das ferramentas Trac e SubversionDaves Marcio Silva Martins, Tadeu Moreira de Classe, Eduardo Leandro Pinto Dornelas e Guilherme de Jorge Palmeira

Tipo: Processo Título: Introdução a Modelos de Ciclo de Vida – Parte 1 Autor: Rodrigo Oliveira SpínolaMini-Resumo: Perceber que atividades fazem parte do processo de engenharia de software é o primeiro passo para concretizá-lo, mas é também importante perceber como as atividades do processo se relacionam umas com as outras para que se torne visível todo o processo de desenvolvimento. Neste sentido, o termo modelo de ciclo de vida é utilizado para descrever um modelo que visa descrever um grupo de atividades e a forma como elas se relacionam. Este é o tema desta série de 3 vídeo aulas. Nesta primeira, conheceremos algumas definições sobre modelos de ciclo de vida e conheceremos o ciclo de vida em cascata atentando para suas vantagens e desvantagens.

Tipo: Processo Título: Introdução a Modelos de Ciclo de Vida – Parte 2 Autor: Rodrigo Oliveira SpínolaMini-Resumo: Perceber que atividades fazem parte do processo de engenharia de software é o primeiro passo para concretizá-lo, mas é também importante perceber como as atividades do processo se relacionam umas com as outras para que se torne visível todo o processo de desenvolvimento. Neste sentido, o termo modelo de ciclo de vida é utilizado para descrever um modelo que visa descrever um grupo de atividades e a forma como elas se relacionam. Este é o tema desta série de 3 vídeo aulas. Nesta segunda aula, conheceremos os modelos de ciclo de vida em V e o interativo.

Tipo: Processo Título: Introdução a Modelos de Ciclo de Vida – Parte 3

Autor: Rodrigo Oliveira SpínolaMini-Resumo: Perceber que atividades fazem parte do processo de engenharia de software é o primeiro passo para concretizá-lo, mas é também importante perceber como as atividades do processo se relacionam umas com as outras para que se torne visível todo o processo de desenvolvimento. Neste sentido, o termo modelo de ciclo de vida é utilizado para descrever um modelo que visa descrever um grupo de atividades e a forma como elas se relacionam. Este é o tema desta série de 3 vídeo aulas. Nesta terceira parte, conheceremos os modelos de ciclo de vida evolutivo, RAD, prototipação e espiral.

Tipo: Processo Título: Atividades do Desenvolvimento de Software – Parte 1 Autor: Rodrigo Oliveira SpínolaMini-Resumo: Esta vídeo aula apresenta algumas das principais atividades execu-tadas ao longo do desenvolvimento de projetos de software. Nesta primeira parte conheceremos as atividades: elicitação de requisitos, análise de requisitos, projeto de arquitetura do sistema e projeto de software.

Tipo: Processo Título: Atividades do Desenvolvimento de Software – Parte 2 Autor: Rodrigo Oliveira SpínolaMini-Resumo: Esta vídeo aula apresenta algumas das principais atividades executadas ao longo do desenvolvimento de projetos de software. Nesta segunda parte conhe-ceremos as atividades: implementação do software, integração de software, teste de software, integração de sistema, teste de sistema e implantação do software.

4 Engenharia de Software Magazine

Caro Leitor, Para esta edição, temos um conjunto de 5 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia de Software Magazine e certamente trarão uma significa-tiva contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:

Edição 05 - Engenharia de Software Magazine 5

6 Engenharia de Software - Lidando com o risco nas corporações

Lidando com o risco nas corporações

Pos trás do Óbvio

Alguém já disse que, para morrer, basta estar vivo. Seja quem for que tenha dito isso, afirmou uma grande e fúnebre verdade. Mortos não costumam morrer, porque

já estão mortos. A eles cabe apenas permanecer em seu estado de sono profundo. Apenas os vivos podem um dia dar adeus à existência e descansar em paz.

Embora a morte seja o fim do ciclo de vida de todos os seres vivos, permanecer vivo é uma obsessão instintiva de todo aquele que respira. Por isso desenvolvemos estratégias para prorrogar ao máximo o nosso encontro com a morte, identificando e evitando os caminhos que podem nos levar mais cedo para o mundo do além. Assim, cada vez que vamos ao médico fazer exames de rotina, que mudamos a nossa alimentação para uma dieta mais saudável e que cuidamos mais de nós mesmos, estamos iden-tificando e avaliando riscos que podem nos levar a situações indesejáveis.

Da mesma forma que para morrer basta estar vivo, o simples fato de uma atividade ou rotina existir abre um leque de possibi-lidades para a ocorrência de eventos prejudiciais ao sucesso. Por isso, administrar riscos numa corporação é como fazer exames de rotina. O objetivo principal é garantir a sobrevivência. O en-graçado é que da mesma forma que muitas pessoas não gostam de fazer exames preventivos por diversas razões, alguns gestores insistem em adotar uma postura incompetente diante dos riscos que envolvem suas atividades. Mas o que é ser incompetente na administração desses riscos?

Primeiro, é achar que nunca vai adoecer. O maior erro de alguém que deseja ter uma vida saudável é pensar que por ter uma saúde “inabalável”, nunca irá pegar uma gripe, uma virose ou coisa parecida. Ledo engano. Muitas das variáveis internas e externas que envolvem nossas organizações são como vírus que vivem assediando empresas com sistemas imunológicos fragiliza-dos pela atitude desleixada e prepotente da auto-suficiência. Por isso, estar atendo aos riscos é, antes de mais nada, uma postura de humildade.

Glênio [email protected]

É Administrador de Empresas, pós-graduado em Gestão de Pessoas e mú-sico. Idealizador do site de educação infantil www.novainfancia.com.br.

Segundo, é desconhecer a própria realidade doméstica. Há casos de gestores que desconhecem as particularidades de seu próprio empreendimento. Informações como riscos inerentes ao negócio, riscos que envolvem os fornecedores, os consumidores e os concorrentes são essenciais para o bom andamento das atividades organizacionais. Uma pessoa que não está informada de sua própria condição física corre o risco de estar abrigando uma grave enfermidade dentro de si, desconhecendo-a por completo. Assim também se dá com a corporação que não está devidamente inteirada de suas próprias singularidades.

Terceiro, é arriscar-se em mares proibidos. Uma pessoa que é diabética e desconhece isso por não ter o hábito de fazer exames periódicos, acaba consumindo alimentos proibidos para o seu quadro clínico. Assim também ocorre com uma organização que não está atenta aos ambientes micro e macro, e que por isso muitas vezes adota estratégias e metas desaconselháveis para a sua realidade.

Alguém já disse que, para morrer, basta estar vivo. Seja quem for que tenha dito isso, afirmou uma grande e fúnebre verdade. No entanto, muitas pessoas que já não estão mais entre nós, con-tinuam vivas através das organizações que idealizaram e ajuda-ram a fundar, e que hoje são referenciais na arte de administrar imprevistos. Chegamos então a uma bombástica conclusão: uma boa administração de riscos pode gerar uma certa imortalidade. Por que não?

Dê seu feedback sobre esta edição!

A Engenharia de Software Magazine tem que ser feita ao seu gosto.Para isso, precisamos saber o que você, leitor, acha da revista!Dê seu voto sobre este artigo, através do link:

www.devmedia.com.br/esmag/feedback

Dê

seu Feedback

sob

re esta edição


Fernando [email protected]

Possui graduação em Processamento de Dados (UNOPAR, 2002), Pós-graduação em Melhoria em Processo de Software (UFLA, 2006) e Mestrado em Engenharia de Sofware (CESAR.EDU, 2009). Atualmente é professor e coordenador de estágio do Centro Universitá-rio UNIRG e Gerente de Projetos da Criativa Tecnologia. Tem experiência na área de Enge-nharia de Software, com ênfase em Modelos e Padrões de Melhoria no Processo de Software, Metodologias Ágeis e Gestão de Projetos.

Jones Oliveira de [email protected]

Possui graduação em Ciência da Computa-ção (UFPE, 1994), mestrado em Ciências da Computação (UFPE, 1997) e doutorado em Ciências da Computação (UFMG, 2002). Atu-almente é Professor Adjunto da Universidade Federal Rural de Pernambuco e colaborador ad hoc do C.E.S.A.R. – Centro de Estudos e Sis-temas Avançados do Recife. Tem experiência na área de Ciência da Computação, foi diretor de empresa e atua na área de Engenharia de Software e Modelagem Matemática, atuando principalmente nas seguintes linhas: enge-nharia de software, processo de software, qualidade de software, matemática com-putacional, epidemiologia computacional e modelagem de sistemas.

Felipe [email protected]

É graduado em Engenharia Mecânica pela UFPE, especialista em Tecnologias da Informação pelo Centro de Informática da UFPE e mestre em Ci-ência da Computação na área de produtividade de software também pela UFPE. Com 14 anos na área de desenvolvimento de software, atual-mente é doutorando e coordenador da garantia da qualidade de software e do SEPG (Software Engineering Process Group) no C.E.S.A.R. É Scrum Master desde 2007 e possui experiência na defi-nição e implantação de processos aderentes ao CMMI e em avaliações SCAMPI, com participação em avaliações Classe A CMMI níveis 2 e 3.

De que se trata o artigo?Este artigo apresenta a extensão da metodologia ágil Scrum para as áreas de processo do MPS.BR nível G aplicada em uma pequena fábrica de software.

Para que serve?A extensão realizada neste trabalho pode contribuir de forma relevante para organizações que têm o propósi-to de adotar práticas ágeis no seu processo de software mantendo a compatibilidade com o MPS.BR nível G.

Em que situação o tema é útil?Introduzir conceitos ágeis em processos de software buscando um equilíbrio entre agilidade e maturida-de é uma alternativa capaz de promover a melhoria da qualidade dos produtos e, consequentemente, aumento da competitividade no mercado.

Extensão do Scrum segundo o MPS.BR nível GImplementando agilidade e maturidade em uma fábrica de software

Ao final dos anos 90, como rea-ção às formas tradicionais de desenvolvimento de software,

que baseado em estudos realizados pela indústria e academia [12], foi apontada como a principal responsável por falhas encontradas em projetos de software, acompanhamos o surgimento de várias metodologias ágeis, como: Adaptive Software Development, Crystal, Dynamic Systems Development, eXtreme Program-ming (XP), Feature Driven Development (FDD) e Scrum [4].

As metodologias ágeis são uma coleção de diferentes técnicas (ou práticas), que utilizam os mesmos valores e princípios básicos, tais como ciclos iterativos, en-trega rápida de software funcionando e simplicidade, conforme está definido no Manifesto para Desenvolvimento Ágil [2].

Neste sentido, organizações que pro-curam melhoria em seus processos de

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

8 Engenharia de Software Magazine - Extensão do Scrum segundo o MPS.BR nível G

produção através de modelos e frameworks como Capabitity Model Integration (CMMI), Control Objectives for Information and related Technology (COBIT), Information Technology Infrastructure Library (ITIL), entre outros, agora também acreditam que intro-duzir conceitos ágeis em seus processos de desenvolvimento, buscando um equilíbrio entre agilidade e maturidade, é uma alternativa capaz de promover a melhoria da qualidade dos seus produtos e, consequentemente, aumento da competitivi-dade no mercado [9].

Segundo o [Softex 2007], alcançar competitividade pela qua-lidade para as empresas de software implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. Desta forma, assim como para outros setores, qualidade é fator crítico de sucesso para a indústria de software.

O desenvolvimento ágil e os modelos e padrões de qualida-de de software tradicionais são vistos frequentemente como contraditórios, pois se tem o raciocínio que os modelos são muito burocráticos, enquanto que o desenvolvimento ágil é ad-hoc [6]. Na verdade existem desafios na integração entre os dois, embora o esforço possa valer a pena, pois ao final pode-se obter qualidade no produto através da união de maturidade e agilidade.

Nessa direção, [Chin 2004] afirma que, se por um lado o excesso de formalidade e estruturação tende a inibir e limitar as equipes, por outro, a liberalidade caótica e informal, despro-vida de processos, pode fazer com que os objetivos do projeto nunca sejam atingidos.

Inserido neste contexto, este trabalho tem o objetivo de propor uma estratégia para extensão do Scrum segundo as áreas de processo do guia MPS.BR nível G. Este estudo se inicia com o mapeamento entre o Scrum e o MPS.BR através de uma avalia-ção dos resultados esperados do guia segundo as práticas do Scrum. A partir deste mapeamento, uma extensão do Scrum é realizada através da adição de práticas complementares para satisfazer o guia. Ao final, é gerado um novo processo de desenvolvimento para uma fábrica de software.

O MPS.BRO MPS.BR tem como objetivo definir um modelo de melhoria

e avaliação de processo de software, preferencialmente para as micro, pequenas e médias empresas, para satisfazer as suas necessidades de negócio e também ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software [11].

O Modelo de Referência MR-MPS define sete níveis de matu-ridade, que são uma combinação entre processos e capacidade de processos, tais como: A (Em Otimização); B (Gerenciado Quantitativamente); C (Definido); D (Largamente Definido); E (Parcialmente Definido); F (Gerenciado); G (Parcialmente Gerenciado). Para cada um destes sete níveis de maturidade foi atribuído um perfil de processos e de capacidade de pro-cessos que indicam onde a organização tem que concentrar o esforço para melhoria de forma a atender os objetivos de negócio [11].

O nível G de maturidade do MPS.BR (Parcialmente Geren-ciado) é composto pelos processos de Gerência de Projetos e Gerência de Requisitos satisfazendo os atributos de processo AP 1.1 e AP 2.1.

O processo de Gestão de Projetos (GPR) é composto por dezessete resultados esperados e tem o propósito de estabe-lecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempe-nho do projeto [11].

O processo de Gerência de Requisitos (GRE) é composto por cinco resultados esperados. O seu propósito é gerenciar os re-quisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto [11].

O ScrumA metodologia ágil Scrum foi criada em 1996 por Ken Schwaber

e Jeff Sutherland, e destaca-se das demais metodologias ágeis pela maior ênfase dada ao gerenciamento do projeto [10].

Trata-se de uma abordagem empírica focada nas pessoas para ambientes em que os requisitos surgem e mudam rapidamente, resultando em uma abordagem que reintroduz as ideias de flexibilidade, adaptabilidade e produtividade [3]. Ela se ba-seia em princípios como: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas. As iterações são divididas em intervalos de tempos de, no máximo 30 dias, também chamadas de Sprints.

Papéis e responsabilidadesO Scrum define para sua estrutura iterativa incremental três

papéis principais [10]:• Scrum Master: gerencia o processo, ensinando o Scrum a todos os envolvidos no projeto e implementando o Scrum de modo que o mesmo esteja adequado à cultura da organização; deve garantir que todos sigam as regras e práticas do Scrum; e é responsável por remover os impedimentos do projeto [10]. Ele é o líder e facilitador entre o Team e o Product Owner;• Product Owner: é o responsável pelo retorno sobre o investi-mento (ROI), ou seja, seu foco é na parte comercial do produto. Ele é o representante de todos os stakeholders e os representa na priorização do Backlog e questões de requisitos. Esta pessoa deve estar à disposição da equipe em qualquer momento, mas sobretudo durante o Sprint Planning Meeting e Sprint Review Meeting [13];• Team: é um grupo de pessoas com diferentes habilidades necessárias para transformar requisitos em um incremento po-tencialmente “entregável”. Para tanto, geralmente são uma mescla de analistas, designers, gerentes de qualidade, desenvolvedores, etc. A equipe tem a autoridade de decidir, quando necessário, as ações que serão realizadas e priorizá-las organizando-as em Sprints. Effort estimation, Sprint Backlog, revisões de product Backlog List e sugestões de impedimentos para serem removidos do projeto também são atividades do time [13].


MEtoDoLoGIAS ÁGEIS

As fases do ScrumO ciclo de desenvolvimento do Scrum é baseado em três fases

principais [1], conforme ilustra a Figura 1:• PRE-GAME: dividida em duas subfases, Planejamento e Staging. A subfase Planejamento tem por objetivo estabelecer a visão do projeto e expectativas, garantindo recursos para a sua execução. A subfase Staging tem por objetivo avaliar as várias dimensões do projeto criando itens adicionais ao Product Backlog relacionados com o tipo do sistema, time, ambiente de desenvolvimento e tipo de aplicação;• GAME: consiste de múltiplas Sprints para o desenvolvimen-to dos incrementos de funcionalidades do produto. Onde o time analisa a situação atual do produto, avaliando quais mudanças devem ser implementadas, procedendo ao final com o desenvolvimento através de etapas de análise, projeto, implementação, testes e documentação de mudanças;• POST-GAME: fase de fechamento, que tem por objetivo pre-parar o produto para o seu lançamento. Isto inclui atividades de integração, análise, documentação do usuário, treinamento e preparação do material de marketing.

Figura 1. Fases do Scrum

Fluxo do ScrumUm projeto se inicia com a visão do produto que será desen-

volvido [10], com a lista das características do produto estabe-lecidas pelo cliente, além de algumas premissas e restrições. Em seguida, o Product Backlog é criado contendo a lista de todos os requisitos funcionais e não funcionais. O Product Backlog é então priorizado pelo Product Owner e dividido em Releases.

No Scrum, são realizadas iterações chamadas de Sprints. Se-gundo [Schwaber 2008], cada Sprint inicia-se com uma reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o Time decidem em conjunto o que deverá ser imple-mentado, ou seja, quais unidades de trabalho serão incluídas nas iterações de Sprint (Selected Backlog). A reunião é dividida em duas partes. Na primeira parte (Sprint Planning 1), o Pro-duct Owner apresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados. O time então define colaborativamente o que poderá entrar no desenvolvimento da próxima Sprint, considerando sua capacidade de produção. Na segunda parte (Sprint Planning 2), o time planeja seu traba-lho, definindo o Sprint Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas no Product

Backlog. Nas primeiras Sprints, é realizada a maioria dos traba-lhos de arquitetura e de infraestrutura. A lista de tarefas pode ser modificada ao longo da Sprint pelo time e as tarefas podem variar entre 4 a 16 horas para a sua conclusão.

Na execução das Sprints, diariamente o time faz uma reunião de 15 minutos para acompanhar o progresso do trabalho e agendar outras reuniões necessárias. Ao final da Sprint, é re-alizada a reunião de revisão (Sprint Review Meeting) para que o time apresente o resultado alcançado na iteração ao Product Owner. Neste momento as funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida o Scrum Master conduz a reunião de retrospectiva (Sprint Retros-pective Meeting), com o objetivo de melhorar o processo/time e/ou produto para a próxima Sprint.

O monitoramento do progresso do projeto é realizado através de gráficos de acompanhamento (Burndown Charts). Eles são um excelente mecanismo para visualizar a correlação entre a quantidade de trabalho a ser realizada (em qualquer ponto) e o progresso do time do projeto para reduzir este trabalho [8].

A Figura 2 demonstra detalhadamente o fluxo de desenvol-vimento do Scrum.

Figura 2. Fluxo do Scrum (Fonte: Adaptação de [7])

Mapeando o Scrum para as áreas de processo do MPS.BR nível G

Para cada área de processo do MPS.BR nível G foi realizada uma análise detalhada entre os resultados esperados do MPS.BR e as práticas encontradas no Scrum, classificando cada resultado esperado de acordo com os critérios estabelecidos na Tabela 1.

Para avaliar o processo segundo o método de avaliação do MPS.BR (MA-MPS), o processo de desenvolvimento da orga-nização é avaliado baseado em evidências (diretas e indiretas) de um conjunto de atividades e tarefas para atingir este pro-pósito. Portanto, estes aspectos não foram considerados no escopo deste trabalho, pois o mapeamento foi realizado com


o objetivo somente de tornar a organização aderente ao guia e não para fins de certificação.

Classificação Critério

NS Não Satisfeito Não há evidências da prática na metodologia

PS Parcialmente SatisfeitoHá evidências da prática na metodologia, embora a prática não

esteja plenamente atendida.

S Satisfeito A prática está totalmente atendida na Metodologia.

tabela 1. Critérios para classificação das áreas de processO

Após a realização da classificação, conforme os critérios acima estabelecidos, foram calculados os percentuais de satisfação de cada área de processo entre os critérios definidos, tomando como base o número total de resultados esperados de cada área.

Para o processo de desenvolvimento de software de uma organização estar totalmente aderente ao nível G do MPS.BR, é necessário também atender aos atributos de processo AP 1.1 e AP 2.1 no que se refere aos resultados esperados RAP1 a RAP8. Por essa razão, também foi realizado o mapeamento entre os atributos de processo acima relacionados e o novo processo de software da empresa em questão.

O mapeamento detalhado apresentando os pontos que o Scrum satisfaz ou não os resultados esperados do MPS.BR nível G (Gestão de projetos e Gerenciamento de requisitos) pode ser encontrado em [15].

Os resumos das análises para os processos de Gestão de Projetos (GPR) Gerenciamento de Requisitos (GRE) são apre-sentados nas Tabelas 2 e 3, respectivamente.

MPS.BR – Nível G SCRUM

Área de Processo Abrev. Objetivos Classificação Resumo das Práticas

Gest

ão d

e Pr

ojet

os

(GPR

)

GPR1 Escopo do trabalho Satisfeito Elaboração da Visão do Produto e Definição dos Itens de Backlog (IBL)

GPR2 Dimensionamento de tarefas e produtos de trabalho Parcialmente Satisfeito Estimativas através de Story Points

GPR3 Modelo e as fases do ciclo de vida do projeto Satisfeito Iterativo incremental. Fases: Pregame, Game e Postgame

GPR4Estimativa de esforço e o custo baseado em dados históricos ou

referências técnicasParcialmente Satisfeito

Retorno sobre o Investimento (ROI), Estimativas através de Story Points e

divisão de IBLs em tarefas

GPR5 O orçamento e o cronograma do projeto Parcialmente Satisfeito Planejamento de Sprints e Estimativas através de Story Points

GPR6 Riscos do projeto Satisfeito Daily Meetings, Impediment Backlog e responsabilidades do Scrum Master

GPR7 Planejamento de recursos humanos SatisfeitoDefinição dos Recursos humanos (Time, Product Owner, Scrum Master)

baseado no perfil

GPR8 Planejamento das tarefas, os recursos e o ambiente de trabalho Satisfeito Itens adicionais ao Product Backlog e Tarefas da Sprint (Task)

GPR9Planejamento de dados relevantes do projeto

(armazenamento, privacidade e segurança)Não Satisfeito Prática não mencionada no Scrum

GPR10 Planos para a execução do projeto Satisfeito Visão do Produto, Product Backlog, Sprint Backlog, Sprint planning 1 e 2 e Daily meeting

GPR11 Avaliação de viabilidade de atingir as metas do projeto SatisfeitoSprint Planning (1 e 2) e Definição do objetivo da iteração na elaboração do

Sprint Backlog

GPR12 Revisão e compromisso com o Plano do Projeto Satisfeito Sprint Planning (1 e 2) e Daily meeting

GPR13 Monitoramento do progresso do projeto Satisfeito Product Burndown, Sprint Burndown, Daily Review e Retrospective Meeting

GPR14Gerenciamento do envolvimento das partes interessadas no

projeto Satisfeito Daily Scrum Meeting, Sprint Review Meeting e Sprint Retrospective Meeting

GPR15Revisões são realizadas em marcos do projeto e conforme

estabelecido no planejamentoSatisfeito Sprint Review Meeting

GPR16 Identificação e registros de problemas Satisfeito Daily Scrum Meeting e Impediment Backlog

GPR17 Ações para corrigir e prevenir desvios em relação ao planejado Satisfeito Daily Scrum Meeting, Impediment Backlog e Retrospective Meeting

tabela 2. Resumo do mapeamento entre Scrum e a área de GPR

MPS.BR - Nível G SCRUM

Área de Processo Abrev. Objetivos Classificação Resumo das Práticas

Gere

ncia

men

to d

e Re

quis

itos

(GRE

)

GRE1 Entendimento dos requisitos Satisfeito Visão do produto, Definição de itens de Backlog e Elaboração das tarefas da Sprint

GRE2 Aprovação de requisitos SatisfeitoAprovação de requisitos através do Business Value (BV), Priorização de requisitos (ROI) e

Sprint Planning (1 e 2)

GRE3A rastreabilidade bidirecional entre os

requisitos e os produtos de trabalhoNão Satisfeito Prática não mencionada no Scrum

GRE4Revisões em planos e produtos de trabalho

do projetoSatisfeito Daily Scrum Meeting e Sprint Review Meeting

GRE5 Gerenciamento de mudanças nos requisitos Satisfeito Sprint Planning (1 e 2), Daily Scrum Meeting e Sprint Review Meeting

tabela 3. Resumo do mapeamento entre Scrum e a área GRE


MEtoDoLoGIAS ÁGEIS

Resultado do mapeamentoEste comparativo entre o Scrum e as áreas de processo do

MPS.BR nível G teve por objetivo mapear o alinhamento e a conformidade entre eles. A partir deste mapeamento desco-brimos que o Scrum não satisfaz totalmente o nível G do MPS.BR, conforme apresentado na Figura 3.

0%

20%

40%

60%

80%

Satisfeito 76% 80%

ParcialmenteSatisfeito

18% 0%

Não Satisfeito 6% 20%

GPR GRE

Figura 3. Resultado Geral da Avaliação

Este resultado se deve a alguns fatores, tais como:• Lacunas na definição de um método apropriado de comple-xidade ou tamanho para estimativas, impactando diretamen-te no resultado esperado GPR2 e indiretamente no GPR5;• Ausência de utilização de dados históricos organizacionais ou referências técnicas para definição de esforço e custo de um projeto, afetando o resultado esperado GPR4;• Ausência de definição de privacidade e segurança no aces-so às informações do projeto, comprometendo totalmente o GPR9;• Ausência de rastreabilidade entre os requisitos e produtos de trabalho, afetando diretamente o GRE3.

Portanto, para implementação de um processo aderente às práticas definidas nas áreas de processo do nível G do MPS.BR, foi necessário complementar o Scrum com práticas adicionais conforme visto na próxima seção.

Estendendo o Scrum para o MPS.BR nível GBaseado no resultado geral do comparativo entre o Scrum

e as áreas de processo do MPS.BR nível G, para as lacunas encontradas (itens “Parcialmente Satisfeito” e “Não satisfei-to”), soluções complementares foram adicionadas ao processo, conforme descrição abaixo.

GAP1 – Lacunas na definição de um método apropriado de complexidade ou tamanho para as tarefas e os produtos de trabalho do projeto, impactando diretamente o GPR2.

Para realização da estimativa das tarefas foi indicado o uso da técnica Story Points com Planning Poker.

A ideia do Planning Poker [Mountain Goat Software 2008] é pontuar os itens de Backlog, onde cada membro da equipe possui um conjunto de cartas numeradas com a sequência de Fibonacci. Inicialmente escolhe-se a funcionalidade de

menor complexidade e atribui a ela a pontuação 2 (dois) para servir como referência. A partir deste item de backlog são realizadas estimativas relativas para os demais itens. Caso haja divergências entre as cartas mostradas, as pessoas que atribuíram o menor e o maior valor explicam o motivo que os levaram a tal estimativa. É importante que o Scrum Master esteja envolvido como mediador para gerenciar conflitos.

GAP2 – Ausência de estimativa do esforço e o custo para a execução das tarefas e dos produtos de trabalho com base em dados históricos ou referências técnicas.

O Scrum não menciona a utilização de dados históricos organizacionais, ou seja, ele somente define a utilização de dados de Sprints anteriores para o mesmo projeto. Portanto, para definição dos custos e esforço serão analisados dados históricos organizacionais mantidos através de um documen-to que contempla informações de projetos anteriores.

GAP3 – Ausência de definição do orçamento.Para definição do orçamento será utilizada a política de

negociação da empresa em questão. Este documento fornece orientações sobre os procedimentos a serem observados na negociação dos projetos de software da empresa no tocante às regras em relação às pessoas, condutas, vedações, divulgação de informações e violações.

GAP4 – Ausência de privacidade e segurança no acesso às informações.

A proposta é armazenar as informações coletadas no projeto utilizando a política de segurança, acesso e armazenamento das informações de projetos. Este documento define a estra-tégia para implementação nos projetos da empresa no que se refere à infraestrutura (confiabilidade, segurança e estabilida-de) e nível operacional (níveis de usuários, responsabilidades, limites e controle de versões).

GAP5 – Ausência de rastreabilidade entre os requisitos e produtos de trabalho.

Para a rastreabilidade vertical cada item de Backlog (IBL) será inicialmente identificado, então, na criação do Sprint Backlog cada tarefa estará associada a um IBL e os artefatos de enge-nharia estarão associados ao IBL correspondente. Portanto, a rastreabilidade vertical pode ser distribuída em cada artefato gerado, como por exemplo, o código implementado.

Adaptando a extensão no processo de uma Fábrica de Software

Para validação deste trabalho, foi implementada a extensão proposta na CRIATIVA Tecnologia, que é uma empresa de tecnologia que cria produtos e serviços utilizando Tecno-logia da Informação (TI). Atualmente a empresa conta com cerca de trinta colaboradores, atendendo diversos clientes e atuando em três áreas de negócio: fábrica de software, trei-namentos e prestação de serviços técnicos em equipamentos eletrônicos.


Histórico de melhoria de processos da CRIATIVAOs trabalhos em melhoria de processo de software na CRIA-

TIVA iniciaram cerca de três anos após a sua fundação (2003), onde após um crescimento significativo de sua base de clientes, a empresa começou a apresentar diversos problemas relacionados ao processo de produção de software. Baseado neste contexto, foi realizada a modelagem de um processo de desenvolvimento baseado no guia MPS.BR nível G [14], onde no período inicial pode-se notar melhorias. Entretanto, após alguns meses de uti-lização, alguns fatores impactaram negativamente na empresa em relação ao processo que foi definido, tais como: dificuldade em seguir o processo, produção de artefatos desnecessários, desmotivação dos colaboradores, entre outros.

Em seguida foi proposto o desenvolvimento de um novo processo de software que proporcionasse maturidade para a organização e que ao mesmo tempo tivesse seu foco nos prin-cípios do manifesto ágil.

O novo processo de software da CRIATIVA TecnologiaA partir de uma perspectiva de gerenciamento e baseado no

ciclo de desenvolvimento iterativo e incremental definido por [10] para o framework Scrum, chegou-se a um processo com-posto por três fases: Pregame, Game e Postgame, apoiadas por atividades de Monitoramento e Controle, conforme ilustrado na Figura 4.

Figura 4. Processo de Software Macro da CRIATIVA Tecnologia

Com o objetivo de proporcionar o entendimento para os colaboradores da empresa em questão, para todas as fases deste novo processo foram descritas suas etapas, objetivos, conceitos chave e quadros de estruturação de cada atividade com seus respectivos papéis, entradas, saídas e artefatos.

Fase PREGAME: Esta fase tem como objetivos delimitar o escopo do projeto, verificar a viabilidade econômica e elimi-nar riscos a partir de uma arquitetura estável. A mesma foi dividida em duas subfases: Planning e Staging, o seu fluxo de atividades é apresentado na Figura 5.

Conceitos chave da subfase PlanningEsta é uma fase inicial que tem seu início através da criação

da Visão do Produto, acessível por todos e de responsabilidade do Product Owner.

O Product Backlog é outro artefato de responsabilidade do Product Owner (PO), mas também é atualizado pelo time, em comum acordo com o PO. Pode conter requisitos funcionais e não funcionais.

Conceitos chave da subfase StagingEsta subfase é uma continuação da subfase inicial Planning, mas

com o foco voltado à definição de algumas atividades, como: organização da infraestrutura para desenvolvimento do projeto, definição da arquitetura, definição do plano de comunicação, elaboração do Release Plan e realização da reunião de kick-off.

Fase GAME: esta fase (Figura 6) tem como objetivo criar releases do produto podendo obter versões funcionais do sof-tware. Nesta direção, o time realiza algumas atividades como: dividir os Itens de Backlog (IBL) que foram selecionados para a Sprint em tarefas, realizar estimativas, priorizar e analisar a viabilidade dos IBLs. Durante as reuniões diárias, as tarefas são selecionadas por cada membro do time. Desta forma, espera-se que o compromisso da equipe seja obtido e todos sigam para o desenvolvimento de uma parte do produto com base na arquitetura definida, enfatizando o gerenciamento de custos, recursos e qualidade.

Conceitos chave da fase GameEsta fase se inicia com as reuniões da Sprint que são divididas

em dois níveis, Sprint Planning 1 e Sprint Planning 2. A Sprint Planning 1 é uma reunião que tem por objetivo a verificação de dados históricos organizacionais, priorização de IBL da Sprint, seleção dos IBLs que irão compor a Sprint e elaboração da Sprint Backlog. A Sprint Planning 2 é a segunda reunião de planejamento com participação do time e do Scrum Master para realização de atividades como: definição de tarefas (Task) necessárias para realização da Sprint, divisão das tarefas da Sprint entre a equipe, análise da capacidade produtiva da equipe e atualização do Task Board.

Ao final das Sprint Planning 1 e 2, a obtenção de compro-misso e revisões no planejamento foram realizadas por todos os envolvidos. A partir disso é executada a Sprint, que consiste no desenvolvimento das tarefas definidas para cada IBL, com o objetivo de obter um produto potencialmente entregável.

Figura 5. Fase PREGAME


MEtoDoLoGIAS ÁGEIS

Durante a execução da Sprint é realizada a atividade Daily Scrum, que é uma reunião diária onde o time monitora o progresso da execução das atividades e procura identificar os impedimentos encontrados.

Posteriormente, o Scrum Master trabalha no sentido de elaborar ações para resolver tais impedimentos e dissemi-nar a solução para o time. Atualizações na Sprint Backlog e Product Backlog são realizadas para controlar o progresso das Sprints.

Fase POSTGAME: esta fase (Figura 7) tem como objetivos apresentar o produto ao cliente para validação, realizar uma reunião para melhoria do processo e avaliar a capacidade produtiva do time.

Conceitos chave da fase POSTGAME A reunião de revisão da Sprint, chamada de Sprint Review

Meeting, fornece algumas visões para todos os envolvidos, tais como: visibilidade se a meta da Sprint foi alcançada, apresentação de resultados, inspeção de funcionalidades para possíveis mudanças e adaptações, e a reunião de retrospectiva (Sprint Retrospective Meeting).

Ao final desta fase, caso haja nova Sprint, ou seja, caso ainda exista a necessidade de serem desenvolvidas outras funcionalidades, novos ciclos são realizados iniciando-se pela fase GAME.

Ao final, informações coletadas no projeto são armazenadas para utilização em projetos futuros formando a base de dados de histórico organizacional.

Estudo de CasoVisando avaliar os efeitos da aplicação da extensão proposta

neste artigo, foi realizado o estudo de caso na empresa em questão em projetos de software selecionados com base na semelhança das características de domínio, escopo, arquite-tura, tempo, custo e equipe.

A definição das métricas para realização de um compa-rativo entre o processo de software anterior e o novo pro-cesso foi baseada nos fatores que mais estavam impactando

Figura 6. Fase GAME

negativamente nos projetos, como entregas no prazo, satis-fação do cliente e quantidade de bugs.

Figura 7. Fase POSTGAME

Como resultado da avaliação da métrica entregas no prazo, foi possível observar que, apesar do time não ter conseguido completar 100% das tarefas que foram atribuídas à iteração, pode-se observar um aumento de 42,5% de entregas no prazo.

Para medir a satisfação dos clientes, foi aplicado um ques-tionário em relação a diversos aspectos, entre eles: comunica-ção, qualidade do produto, gerenciamento de mudanças, en-tregas no prazo, dentre outros. Para avaliar o processo foram utilizados três indicadores (“Atende Totalmente”, “Atende Parcialmente” e “Não atende”), sendo que para cada questão, o questionário disponibilizou orientações de como ela deveria ser avaliada. Foi possível observar que o projeto que utilizou o novo processo de desenvolvimento obteve aumento de 57,14% das respostas “atendem totalmente” no questionário, proporcionando uma grande redução nos valores para as respostas que atendem parcialmente (46,39%) e manutenção da ausência de respostas que não atendem o cliente.

Para medir a quantidade de Bugs, foram coletados os dados na ferramenta Bug Tracker da empresa, e pôde-se observar que o Projeto que utilizou o novo processo teve um número menor de Bugs que o processo anterior (equivalente a 75%).

Através das métricas apresentadas anteriormente, pode-se observar que há indícios de sucesso no uso conjunto do modelo de maturidade MPS.BR com a metodologia ágil Scrum.

Alguns aspectos nos projetos que utilizaram o novo processo podem ser ressaltados:


• O quadro de tarefas (Taskboard) proporcionou uma grande visibilidade do andamento das tarefas;• A participação da equipe nas decisões do projeto proporcio-nou comprometimento e motivação na realização das tarefas diárias;• Através das reuniões diárias pôde-se monitorar a produção do time, promover feedback e remover impedimentos que poderiam atrasar o bom andamento do desenvolvimento da Sprint.

A medição de entregas no prazo proporcionou a visibilidade da performance da empresa no cumprimento dos prazos esta-belecidos, aumentando a eficiência em projetos futuros devido ao ajuste realizado na capacidade de produção do time (Velocity) a cada novo ciclo iterativo do novo processo (Sprint).

A satisfação dos clientes é uma forma de identificar a qualidade do software que foi produzido, que por sua vez é auxiliada por um processo de desenvolvimento eficaz.

Ao identificar a satisfação dos clientes da empresa em questão, observa-se que após a implementação deste novo processo, eles estão apresentando um nível mais alto de satisfação comparado ao processo anterior, o que significa que a CRIATIVA obteve efeitos positivos no seu novo processo de desenvolvimento. No entanto, podem-se observar situações onde a empresa deve melhorar ainda mais a qualidade dos serviços prestados, tais como:• Melhoria na qualidade do produto: Apesar da diminuição na quantidade de bugs na fase de desenvolvimento, durante os testes de aceitação foram registradas solicitações de mudanças;• Cumprimento dos prazos: Apesar de ter melhorado a taxa de entrega, ainda pode ser observado falha no cumprimento dos prazos acordados.

A medição da quantidade de bugs na ferramenta Bug Tracker proporcionou grande visibilidade e acompanhamento da solução dos mesmos ao final de cada iteração dos projetos. Devido à par-ticipação constante do Scrum Master, proximidade dos membros do time e colaboração do cliente, o número de bugs diminuiu consideravelmente.

ConclusãoEste trabalho apresentou a extensão do framework Scrum para

as áreas de processo de Gestão de Projetos e Gerenciamento de Requisitos contempladas no MPS.BR nível G.

No mapeamento entre o Scrum e o guia MPS.BR nível G, desco-briu-se que ele não cobre totalmente os resultados esperados do guia, mas pode ser um ponto de partida, pois proporciona uma base fundamental para empresas que estão iniciando a melhoria de processos, principalmente as que dispõem de poucos recursos como as micro e pequenas empresas.

Visto que após o mapeamento ainda restaram alguns resultados esperados do MPS.BR não cobertos plenamente pelas práticas do Scrum, outras alternativas foram pesquisadas e relacionadas na extensão proposta neste projeto para adaptação do processo de uma fábrica de software.

A extensão relacionada ao gerenciamento de requisitos atra-vés de abordagens ágeis foi uma forma alternativa e eficaz de

gerenciar requisitos e solicitações de mudanças durante o desen-volvimento do projeto, evitando o retrabalho.

A extensão relacionada à gestão ágil de projetos foi uma alterna-tiva capaz de gerar inovação, diminuição do tempo de entrega dos projetos, desenvolvimento de produtos de trabalho que agregam valor real para o cliente e resultados para a empresa.

O novo processo proposto demonstrou um avanço inicial no sucesso de um projeto de software desenvolvido pela empresa, mas como se encontra ainda em fase de implantação, o monito-ramento se faz necessário para obtenção da melhoria contínua e obtenção de melhores resultados.




Dê

seu Feedback

sob

re esta edição

1. Adm, Advanced Development Methods. (2003). Scrum Methodology – Incremental, Iterative

Software. Development from Agile Processes.

2. Beck, K., et al. (2001). “Manifesto for Agile Software Development.” Manifesto for Agile Software

Development. http://www.agilemanifesto.org (acesso em 22 de Março de 2008).

3. Beedle, M., and Schawaber, K. (2002). Agile Software Development With Scrum. New Jersey, Books.

4. Boehm, B. (2006). “A View of 20th and 21st Century Software Engineering.” ICSE06. Shanghai,

China, ACM.

5. Chin, G. (2004). Agile Project Management: How to Succeed in the Face of Changing Project

Requirements. New York, Amacon.

6. Davis, C, et al. (2004). An Agile Approach to Achieving CMMI. http://www.agiletek.com/images/

AgileTek/pdf/an_agile_approach_to_achieving_cmmi.pdf (acesso em 27 de Dezembro de 2008).

7. Gloger, B. (2008) “Scrum Glossary - Sprint It.” Sprint It. http://sprint-runner.com (acesso em 15 de

Junho de 2008).

8. Marçal, A. S. (2007). Estendendo o SCRUM segundo as Áreas de Processo de Gerenciamento de

Projetos do CMMI. Recife.

9. Playfair, K (2008). “When ‘General Agile’ Isn’t Enough - Why Scrum Wins in the Enterprise.” Agile

Journal. http://www.agilejournal.com/content/view/808/111/ (acesso em 29 de Dezembro de 2008).

10. Schwaber, K. (2008). Agile Project Management With Scrum. Redmond, Microsoft Press.

11. Softex. MPS.BR (2007), Melhoria de Processo de Software Brasileiro - Guia Geral V1.2. Rio de

Janeiro, Softex.

12. Standish, The Standish Group International. (2004).. “The Chaos Report.” Standish Group. secure.

standishgroup.com/reports/reports.php?rid=500.

13. Szalvay, V. (2007). “Glossary of Scrum Terms.” http://www.scrumalliance.org/articles/39-glossary-

of-scrum-terms#1121 (acesso em 25 de mAIO de 2008).

14. Szimanski, F. (2006). Implementando MPS.BR nível G na melhoria do processo de software em

uma pequena empresa. Simpósio Mineiro de Sistemas de Informação. Lavras, UFLA.

15. Szimanski, F. (2009). Extensão do Scrum segundo as áreas de processo do MPS.BR nível G.

Dissertação de mestrado. Recife, CESAR.

Referências


Bruno Góis [email protected]

É arquiteto de sistemas e trabalha com desenvolvimento de software a mais de 12 anos. Bacharel em ciência da computação e pós-graduado em desenvolvimento web pela FURB e FFM - Blumenau. É consultor em engenharia de software.

De que se trata o artigo?Este artigo pretende contribuir para a análise da quali-dade e complexidade do código OO, assim como auxi-liar no entendimento dos benefícios das métricas.

Para que serve?A gerência de um produto de software atinge um de-terminado estado de qualidade e precisão se existirem medidas que tornem possível a administração através dos aspectos do sistema. A métrica de software é uma medida de propriedades do sistema que podem ser definidas como caminhos para determinar quantitati-vamente a dimensão em que o produto, a sequencia e o projeto de software têm certas características.

Em que situação o tema é útil?Para gerenciar produtividade e qualidade é ne-cessário saber se ambas estão melhorando ou piorando. Isto implica na necessidade de métricas que indiquem as inclinações do desenvolvimento de sistema

Extração de métricas em software orientado a objetos

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Para gerenciar produtividade e qualidade é necessário saber se ambas estão melhorando ou pio-

rando. Isto implica na necessidade de métricas que indiquem as inclinações do desenvolvimento de sistema. Assim, a gerência de um produto de software atinge um determinado estado de qua-lidade e precisão se existirem medidas que tornem possível a administração através dos aspectos do sistema. A métrica de software é uma medida de propriedades do sistema que podem ser definidas como caminhos para determi-nar quantitativamente a dimensão em que o produto, a sequencia e o projeto de software têm certas características.

Neste contexto, o processo de software estará sob controle se for adotada uma política de coleta de dados e documen-tação durante o desenvolvimento do projeto. O objetivo da mensuração é abastecer engenheiros e gerentes de

16 Engenharia de Software Magazine - Extração de métricas em software orientado a objetos

produtos com um grupo de informações palpáveis para se projetar, gerenciar, controlar, estimar e melhorar os projetos com maior eficácia [20]. Segundo Côrtes e Chiossi (2001), quan-do são calculadas métricas, pretende-se obter dados que irão proporcionar opções para uma melhoria. Este é o objetivo da métrica de software, o estudo dos fatores que influenciam o rendimento através da qualificação dos projetos de desenvol-vimento de software.

Entre as principais inquietações nas fábricas de software encontra-se a possibilidade de se criar um sistema de uma maneira mais rápida e a um custo mais baixo. As práticas ba-seadas em objetos tendem a simplificar o projeto de softwares complexos. Para Amber (1998), as organizações escolhem a orientação a objetos (OO) porque querem dar às suas aplica-ções mais qualidade, as quais querem implementar sistemas seguros, com um menor custo e menor tempo.

Este artigo pretende contribuir para a análise da qualidade e complexidade do código OO, assim como auxiliar no entendi-mento dos benefícios das métricas. Para isso, será apresentado o desenvolvimento de uma ferramenta capaz de efetuar a coleta de métricas de software OO a partir da análise de códigos fontes escrita em linguagem C# e Java.

Origem do Sistema MétricoAs métricas originaram-se da execução prática de avaliação

para quantificar indicadores sobre o processo de desenvolvi-mento de um sistema, sendo adotados a partir de 1970. Existem quatro tendências desta área que são:a) Medida da complexidade do código: criada em meados de 1970, os conjuntos métricos foram fáceis de atingir desde que fossem calculados pelo próprio código automatizado;b) Estimativa do custo de um projeto de software: esta técnica foi desenvolvida em meados de 1970, estimando o trabalho e o tempo gasto para se desenvolver um software, baseando-se além de outros fatores, no número de linhas de código utili-zados na implementação do sistema;c) Garantia da qualidade do software: a melhoria destas técnicas teve maior repercussão entre os anos de 1970 e 1980, dando-se destaque à identificação de informações faltantes, durante as etapas do ciclo de vida do software;d) Processo de desenvolvimento do software: o projeto de software ganhou importância e complexidade, sendo que a necessidade de se administrar este processo foi emergencial. O processo incluiu a definição do ciclo de vida do software através da definição da seqüência das fases do desenvolvi-mento, dando mais destaque ao gerenciamento e controle de recursos deste projeto.

A partir do aparecimento destas tendências, os desenvolve-dores de sistema começaram a usar métricas no propósito de adequar o processo de desenvolvimento de software.

Importância das MediçõesSe não é conhecida a complexidade de um software não se

pode saber o caminho a seguir e nem mesmo o que fazer para

solucionar um problema. Uma das maneiras de se controlar o desenvolvimento de um sistema é a utilização da medição de software. As métricas podem medir cada estágio do desen-volvimento e diversos aspectos do produto. Métricas ajudam a compreender o processo utilizado para a implementação de um sistema. De acordo com Pressman, o processo é medido com o propósito de melhorá-lo e o produto é mensurado com o intuito de ampliar sua qualidade.

Medidas são necessárias para examinar a qualidade e o rendi-mento do processo de desenvolvimento e manutenção do produto de software implementado. Assim, “as empresas devem estabele-cer métricas apropriadas e manter procedimentos para monitorar e medir as características de suas operações que possam causar impacto significativo na qualidade de seus produtos” [5].

Objetivos da utilização de métricasA utilidade das métricas deve ser traçada desde o início da

implantação de métricas para avaliação de software. Há várias características importantes associadas com o emprego das mé-tricas de software. Sua escolha requer alguns pré-requisitos:a) Os objetivos que se pretende atingir com a utilização das métricas;b) As métricas devem ser simples de atender e de serem utili-zadas para verificar atendimentos de objetivos e para subsidiar processos de tomadas de decisão;c) As métricas devem ser objetivas, visando reduzir ou mini-mizar a influência do julgamento pessoal na coleta, cálculo e análise dos resultados.

Para Ambler (1998), as métricas podem ser utilizadas para:a) Estimar projetos: baseado em experiências anteriores pode-se utilizar métricas para estimar o tempo, o esforço e o custo de um projeto;b) Selecionar as ferramentas;c) Melhorar a abordagem de desenvolvimento.

Em uma organização que se dedica ao desenvolvimento de software, seja como atividade-fim seja como de suporte para uma empresa, há vários objetivos que se busca atingir, depen-dendo do estágio de maturidade em que se encontram essas atividades. Alguns dos objetivos perseguidos geralmente se enquadram na seguinte relação:a) Melhorar a qualidade do planejamento do projeto;b) Melhorar a qualidade do processo de desenvolvimento;c) Melhorar a qualidade do produto resultante do processo;d) Aumentar a satisfação dos usuários e clientes do software;e) Reduzir os custos de retrabalho no processo;f) Reduzir os custos de falhas externas;g) Aumentar a produtividade do desenvolvimento;h) Aperfeiçoar continuamente os métodos de gestão do projeto;i) Aperfeiçoar continuamente o processo e o produto;j) Avaliar o impacto de atributos no processo de desenvolvi-mento, tais como novas ferramentas;k) Determinar tendências relativas a certos atributos do processo.


MEDIção

Um dos aspectos que deve ser observado quando da imple-mentação de iniciativas de utilização de métricas é quanto a sua utilidade no contexto de um projeto ou do ambiente como todo, além dos tipos e categorias de métricas, usuários das métricas, pessoas para as quais os resultados das métricas são destinados e os seus níveis de aplicação.

O processo de medição e avaliação requer um mecanismo para determinar quais os dados que devem ser coletados e como os dados coletados devem ser interpretados [7]. O proces-so requer um mecanismo organizado para a determinação do objetivo da medição. A definição de tal objetivo abre caminho para algumas perguntas que definem um conjunto específico de dados a serem coletados. Os objetivos da medição e da avaliação são consequências das necessidades da empresa, que podem ser a necessidade de avaliar determinada tecnologia, a necessidade de entender melhor a utilização dos recursos para melhorar a estimativa de custo, a necessidade de avaliar a qua-lidade do produto para poder determinar sua implementação ou a necessidade de avaliar as vantagens e desvantagens de um projeto de pesquisa.

Assim, o objetivo primário de se realizar medições no de-senvolvimento de software é obter níveis cada vez maiores de qualidade, considerando o projeto, o processo e o produto, visando à satisfação plena dos clientes ou usuários a um custo economicamente compatível.

Métricas tradicionaisA partir de agora serão apresentados alguns exemplos de

métricas tradicionais.

Constructive Const ModelO modelo COCOMO é calculado a partir do número de

linhas de código fonte entregue ao usuário [7]. Este modelo foi desenvolvido por Barry Boehm e resulta em estimativas de esforço, prazo, custo e tamanho da equipe para um pro-jeto de software. O COCOMO é um conjunto de submodelos hierárquicos, que pode ser dividido em submodelos básicos, intermediários ou detalhados.

Linhas de CódigoO modelo LOC, é a técnica de estimativa mais antiga. Ela

pode ser aplicada para estimar o custo do software ou para especificar igualdade de analogia. Há muitas discussões e especulações sobre esta técnica. Primeiramente, a definição de linhas de código não é muito clara.

Um exemplo simples seria o caso de ser colocado ou não um comentário ou uma linha em branco como LOC. Alguns autores consideram estes comentários, no entanto, outros não. No caso de programas recursivos, essa técnica falha, porque a recursividade torna o programa mais curto. O sistema LOC é uma técnica genérica e superficial [11].

Outro problema da técnica LOC é que esta técnica é forte-mente ligada à linguagem de programação utilizada, impos-sibilitando a utilização de dados históricos para projetos que não utilizam a mesma linguagem.

As vantagens do uso de LOC são [7]:a) É fácil de ser obtido;b) É utilizado por muitos modelos de estimativa de software como valor básico de entrada;c) Existe farta literatura e dados sobre este sistema de métrica.

As desvantagens são:a) Dependência de linguagem: não é possível comparar di-retamente projetos que foram desenvolvidos em linguagens diferentes. Como exemplo, pode-se verifica a quantidade de tempo gasto para gerar uma instrução em uma linguagem de alto nível comparado com uma linguagem de baixo nível;b) Penalizam programas bem projetados: quando um progra-ma é bem projetado o mesmo utiliza poucos comandos para execução de uma tarefa;c) Difíceis de estimar no início do projeto de software: é praticamente impossível estimar o LOC necessário para um sistema saindo da fase de levantamento de requisitos ou da fase de modelagem.

Com estas colocações, nota-se que a métrica LOC não é uma métrica a ser utilizada por si só, ela deveria ser utilizada em conjunto com outras métricas, efetuando um comparativo de resultados. Deste modo, uma métrica poderia completar a outra, fornecendo informações que são pertinentes às características de cada uma.

Medida de Ciência do SoftwareHalstead identificou a Ciência de Software – originalmente

chamada de Física do Software – como uma das primeiras manifestações sobre métrica de código baseada num modelo de complexidade do software [18]. A idéia principal deste modelo é a compreensão de que software é um processo de manipulação mental dos símbolos de seus programas.

Estes símbolos podem ser caracterizados como operadores (em um programa executável verbos como: IF, DIV, READ, ELSE e os operadores propriamente ditos) ou operandos (variáveis e constantes), visto que a divisão de um programa pode ser considerada como uma seqüência de operadores associados a operandos.

Para Shepperd (1993), a ciência do software atraiu consideravel-mente o interesse das pessoas em meados de 1970 por ser uma novidade na metrificação do software. Além disso, as entradas básicas do software são todas facilmente extraídas. Após o entusiasmo inicial da ciência do software, foram encontrados sérios problemas. Os motivos podem ser relatados em função da dificuldade que os pesquisadores encontraram na comparação dos trabalhos e evolução da métrica. Outro motivo seria a não associação correta entre o esforço requerido para manipulação do programa e o tempo exigido para conceber o programa e também por tratar um sistema como um simples módulo.

Métrica da complexidade ciclomáticaEste método foi proposto por McCabe, que estava particular-

mente interessado em descobrir o número de caminhos criado


pelos fluxos de controle em um módulo do software, desde que fosse relacionada à dificuldade de teste e na melhor maneira de dividir software em módulos.

A idéia é desenhar num grafo a sequencia que um pro-grama pode tomar com todos os possíveis caminhos. A complexidade calculada fornecerá um número designando o quão complexo é um programa (ou seqüência).

Para possibilitar o cálculo desta métrica, os programas são inicialmente representados por grafos dirigidos represen-tando o fluxo de controle. De um grafo G, pode ser extraída a complexidade ciclomática v(G). O número de caminhos dentro de um grafo pode ser dado como: o conjunto mínimo de caminhos os quais podem ser utilizados para a constru-ção de outros caminhos através do grafo. A complexidade ciclomática é também equivalente ao número de decisões adicionais dentro de um programa:

v(G) = E – n + 2,onde, E: é o número de arestas.N: é o número de nós.

A visão simplificada da métrica de McCabe pode ser ques-tionada em vários pontos. Primeiro, ele tinha uma preocu-pação especial com os programas escritos em Fortran, onde o mapeamento do código-fonte, para um grafo de fluxo do programa era bem definido, sendo que isto não seria o caso de outras linguagens como Ada. A segunda oposição é que v(G) = 1 seria verdadeiro em uma sequencia linear de código de qualquer tamanho. Consequentemente, a medição não é sensível à complexidade, contribuindo assim na formação de declarações de sequencia lineares.

A complexidade ciclomática é sensível ao número de sub-rotinas dentro de um programa, por este motivo, McCabe sugere que este aspecto seja tratado como componentes não relacionados dentro de um grafo de controle [19]. Este ponto teria um resultado interessante, pois aumentaria a complexi-dade do programa globalmente, visto que ele é dividido em vários módulos que se imagina serem sempre simples.

A Figura 1 demonstra um exemplo de complexidade ciclo-mática que ilustra o fluxo do grafo gerado para os caminhos entre 1 e 9.

Métricas para Orientação a ObjetosEmbora exista farta literatura sobre como aplicar os métodos

OO, a maioria não apresenta detalhes relativos à qualidade. A razão é simples: o desenvolvimento de software utilizando esse enfoque ainda não dispõe de métricas precisas e bem entendidas que possam ser utilizadas para avaliar produtos e processos de desenvolvimento nesta abordagem.

Muitas métricas já foram desenvolvidas para gerações pas-sadas de tecnologia e, em muitos casos, são usadas até para desenvolvimento OO, porém não são muito coerentes, pois a diferença com sistemas tradicionais é muito grande.

Nesse sentido, o desenvolvimento de software utilizando o paradigma de OO surge como uma possibilidade para a me-lhoria da qualidade e produtividade, pois permite modelar o problema em termos de objetos capazes de diminuir a distância entre o problema do mundo real e sua abstração.

A OO requer uma abordagem diferente tanto no desenvolvi-mento do projeto quanto na implementação do mesmo, como também nas métricas de software, visto que usa objetos e não blocos de construção fundamentais [17]. Dadas as diferenças entre as duas visões, é comum constatar que as métricas de software desenvolvidas para serem aplicadas aos métodos tradicionais de desenvolvimento não são facilmente mapeadas para os conceitos OO.

Existem várias propostas para métricas OO que levam em consideração as características básicas e interações do siste-ma como: número de classes; número de métodos; linhas de código por método; profundidade máxima da hierarquia de classes; a relação existente entre métodos públicos e privados; entre outros. Tais métricas baseiam-se na análise detalhada do projeto.

As métricas OO podem ser separadas em duas categorias: medidas relacionadas com processos e relacionadas com produtos [10]. As métricas relacionadas com processo são utilizadas para mensurar o processo e o status do processo de desenvolvimento do sistema, consistem em medir coisas tais como: cronogramas ou números de falhas encontradas durante o processo de testes.

Para aprender a manipular e administrar um processo de desenvolvimento OO é importante iniciar a coleta de dados destas medições tão metodicamente quanto possível. A seguir alguns exemplos de métricas relacionadas com processo:a) Tempo total de desenvolvimento;b) Tempo de desenvolvimento em cada processo e subprocesso;c) Tempo utilizado modificando modelos de processos anteriores;d) Tempo gasto em todos os tipos de subprocessos como: es-pecificação dos casos de uso, desenho do bloco, teste do bloco e do caso de uso para cada objeto;e) Número de diferentes tipos de falhas encontrados durante revisões;f) Número de mudanças propostas nos modelos anteriores;g) Custo da garantia de qualidade;h) Custo para introduzir novas ferramentas e processo de desenvolvimento.Figura 1. Exemplo de cálculo de complexidade ciclomática


MEDIção

Estas medições podem formar uma base para o planeja-mento do desenvolvimento de projetos futuros. Por exemplo, conhecendo o tempo médio gasto para especificar todos os casos de uso. Estas medições, entretanto deveriam sempre vir acompanhadas por uma indicação de exatidão da medição (tal como desvio padrão), caso contrário, não se tem senso de exatidão da previsão. Deve-se observar também que estas medições podem variar muito entre diferentes processos, organizações, aplicação e equipe. Portanto, é perigoso tirar conclusões genéricas sobre dados existentes sem considerar as circunstâncias.

As métricas relacionadas com produtos são aquelas que são utilizadas para controlar a qualidade do produto final. Elas tradicionalmente são aplicadas ao sistema ainda em constru-ção para mensurar sua complexidade e prever propriedades do produto final.

Medidas tradicionais de produtos podem ser utilizadas para algumas aplicações OO [10]. Entretanto, a métrica mais comum, linhas de código, é a menos interessante para sistemas OO, pois às vezes o menor código escrito é o mais reutilizado e, muitas vezes dá maior qualidade ao produto.

A seguir serão exemplificadas algumas métricas para OO. Estas métricas estão relacionadas em três categorias: métricas de análise, projeto e construção. Estas medidas podem ser utili-zadas para auxiliar a melhorar os esforços de desenvolvimento [1]. Elas podem identificar áreas com problemas na aplicação antes que elas apareçam como um erro detectado pelo usuá-rio. As métricas de projetos e construção além de mensurar aspectos importantes do sistema, são fáceis de automatizar, tornando-as mais fáceis de coletar.

A Figura 2 demonstra um exemplo de diagrama de classes que ilustra algumas medidas explicadas em seguida. Este dia-grama de classes define criação de pessoas: uma pessoa pode ser do tipo cliente ou funcionário, por sua vez o funcionário pode ser do tipo horista, diarista ou mensalista; um funcioná-rio tem um cargo e deve estar em um departamento.

cd Data Model

Departamento

- Descricao: String- Chefia: FuncionarioMensalista

Cargo

- Descricao: String- TitulacaoMinima: String

Pessoa

- Nome: String- Sexo: String- DataNascimento: TDateTime

Cliente

- CPF: String

Funcionario

- Salario: Real- Alocacao: Departamento- CargoAtual: Cargo

+ CalcularSalario()+ ObterSalario() : Real

FuncionarioHorista

- ValorHora: Real- NumeroDias: Integer- NumeroHorasDia: Integer

+ CalcularSalario()

FuncionarioDiarista

- ValorDia: Real- NumeroDias: Integer

+ CalcularSalario()

FuncionarioMensalista

- ValorMes: Real- Encargos: Real

+ CalcularEncargos()+ CalcularSalario()

-Chefia

-CargoAtual

-Alocacao

Figura 2. Exemplo de diagrama de classes

Faz sentido adicionar um peso às métricas das classes para produzir uma medida de complexidade do sistema. A maioria das medidas examina atributos em termos dos conceitos de

OO como herança, polimorfismo e encapsulamento. Para tanto, seria necessário coletar um número significativo de contagens, ou seja, seria necessário tomar valores de vários projetos e dimensioná-los selecionando as classes, os métodos e os atri-butos desejáveis para medir o tamanho e a complexidade de um novo software.

Métricas segundo Chidamber e KemererChidamber e Kemerer (1994, p. 41) propuseram seis métricas

para o cálculo de complexidade de sistema OO. As métricas chamadas de CK são ótimas referências para análise quan-titativa, objetivando a concentração de testes em classes que possivelmente contêm maior número de defeitos. A seguir uma descrição de cada métrica:a) WMC: cálculo do número de serviços por classe. Um alto WMC mostra que a classe tende a se tornar específica e seus serviços possuem características que atendem a necessidades individuais, restringindo sua reutilização. O número de serviços mostra ainda qual o nível de esforço deve ser despendido para o teste da complexidade da classe (ver Figura 3);

Atributo1Metodo_XMetodo_YMetodo_Z

Metodo_XMetodo_YMetodo_Z




WMC (X) = 3= WMC (X) = 3=

Figura 3. Exemplo da métrica WMC

b) DIT: é o número máximo de superclasses posicionadas hierarquicamente acima da classe em questão. Um DIT ele-vado mostra que muitas das características da classe foram adquiridas por herança e são comuns a outras classes. Isso mostra que as superclasses contêm um alto nível de abstração, o que significa que elas estão possivelmente preparadas para possibilitar uma boa reutilização. Em contrapartida, DIT pode indicar que a classe herda muitos serviços, aumentando a sua complexidade (ver Figura 4);

A

B

D

CDIT (C) = 2DIT (C) = 2

A

B D

EC

DIT (E) = 2DIT (E) = 2

Figura 4. Exemplo da métrica DIT

c) NOC: número de subclasses posicionadas imediatamente abaixo da superclasse em questão ou filhos diretos. Um NOC elevado indica um baixo nível de abstração, pois uma super-classe com muitos filhos tende a conter poucas características comuns a todas as subclasses. Um alto número de filhos diretos também pode indicar problemas estruturais, uma vez que as subclasses podem não se adequar à abstração implícita da classe pai (ver Figura 5);


d) CBO: mostra qual é o nível de acoplamento entre as classes da aplicação. Quanto maior a ligação entre elas, menor a pos-sibilidade de reutilização, pois a classe torna-se dependente de outras classes para cumprir suas obrigações. Portanto o CBO está diretamente legado ao nível de reaproveitamento. Um alto acoplamento indica uma baixa independência de classe, o que aumenta consideravelmente a complexidade e, em consequência, o esforço de teste (ver Figura 6);

Chegada de Chegada de mensagem mensagem

para o para o objeto Xobjeto X

CBO (X) = 2CBO (X) = 2

Figura 6. Exemplo da métrica CBO

e) LCOM: número de acesso a um ou mais atributos em comum pelos serviços da própria classe. Dessa forma, os ser-viços tornam-se ligados pelos atributos, podendo indicar que foram mal projetados, pois apresentam baixa coesão. Uma das principais características do software OO é apresentar uma alta coesão nos métodos, o que garante que esses exerçam sua função adequadamente. Portanto é importante manter o LCOM da classe baixo (ver Figura 7);

Figura 7. Exemplo da métrica LCOM

f) RFC: indica a capacidade de resposta que a classe tem ao receber mensagens de seus objetos. Uma maior capacidade de resposta requer uma estrutura de classe projetada para

A

B

D

C

NOC (A) = 1NOC (A) = 1

A

B D

EC

NOC (B) = 2NOC (B) = 2

F

Figura 5. Exemplo da métrica NOC

atender a essa particularidade gerando uma maior com-plexidade, tornando necessário um maior esforço de teste (ver Figura 8).

Figura 8. Exemplo da métrica RFC

Conhecidas as métricas, temos na Tabela 1 o resultado do cál-culo das métricas OO para o modelo de classes da Figura 2.

Classe WCT DIT NOC CBO RFC LCOM

Pessoa 0 0 2 0 0 0

Cliente 0 1 0 0 0 0

Funcionário 2 1 3 2 2 0

Cargo 0 0 0 0 0 0

FuncionarioHorista 1 2 0 0 1 0

FuncionarioMensalista 2 2 0 0 2 1

FuncionarioDiarista 1 2 0 0 1 0

Departamento 0 0 0 2 0 0

tabela 1. Exemplo de calculo do modelo de CK para Figura 2

Métricas segundo Lorenz e KiddUma outra proposta de métricas OO foi criada por Lorenz e

Kidd tem como base o cálculo quantitativo de alguns aspectos fundamentais da OO, como os atributos e serviços, herança, coesão e acoplamento. Não diferindo das métricas de CK no foco, mas sim em sua metodologia de calculo. Abaixo segue a descrição de cada métrica definida:a) CS: número de serviços e atributos locais e herdados de su-perclasses. Os serviços e atributos públicos das classes localiza-das hierarquicamente acima e os da própria classe em questão compõe o CS. Um grande CS torna a classe muito específica, pois sua estrutura atende a particularidades, o que restringe a reutilização, requerendo ainda maior esforço de testes, já que a classe se torna mais complexa (ver Figura 9);


MEDIção

b) NOO: os métodos definidos nas superclasses são herdados pelas subclasses, mas, quando esses não atendem à necessi-dade individual da subclasse, podem ser redefinidos, ferindo assim a abstração implícita na superclasse. Um alto índice de NOO indica um problema estrutural. Se muitas subclasses têm serviços redefinidos, as subclasses possivelmente estão hierarquicamente mal projetadas (ver Figura 10);

Atributo1

Metodo_YMetodo_Z

Metodo_X

Metodo_X

NOO (XE) = 1

Figura 10. Exemplo da métrica NOO

c) NOA: se a classe contém um alto número de operações e atributos privados, ela torna-se muito específica, diminuindo as possibilidades de reaproveitamento. Pode-se dizer que um alto NOA pode indicar uma falha de modelo. Muitas particu-laridades mostram que a classe não está bem posicionada na hierarquia, já que suas características principais deveriam estar implícitas nos seus ancestrais (ver Figura 11);

d) SI: número de serviços adicionados, eliminados ou rede-finidos. Indica o nível de especialização das classes ou as alterações efetuadas para atender à necessidade individual daquela classe (ver Figura 12).

Conhecidas as métricas, temos na Tabela 2 o resultado do cál-culo das métricas OO para o modelo de classes da Figura 2.

CS (LCOM) = 3CS (LCOM) = 3

cd Diagrama de Classes

Metricas

- FValor: int

+ SetValor(int) : void+ GetValor() : int

LCOM

- Codigo: int

Figura 9. Exemplo da métrica CS

Atributo1

Metodo_YMetodo_Z

Metodo_X

NOA (XE) = 2Metodo_AMetodo_BMetodo_AMetodo_B

Figura 11. Exemplo da métrica NOA

Uma técnica muito interessante consiste em pesquisar intui-tivamente o acoplamento e a coesão [11]. Um recurso bastante utilizado é por meio de gráficos que demonstram ao analisador a complexidade estrutural do produto e facilitam a identificação de gargalos. A Figura 13 é um modelo tridimensional da estrutura de uma classe. Os cubos são atributos, acessados por métodos representados por esferas. Imediatamente é percebido acopla-mento ou não entre os métodos do objeto, suas dependências e oportunidades de particionamento da classe em subclasses.

Outro recurso em forma de gráfico muito interessante é o pro-posto por Kiviat, que auxilia no reconhecimento de problemas

SI = [NOO x DIT] / nº total de métodos da classe

Atributo1

Metodo_YMetodo_Z

Metodo_X

Metodo_AMetodo_B

Metodo_XMetodo_AMetodo_BMetodo_AMetodo_B

Metodo_X

X

XE

D

C

X

XE

D

CDIT (XE) = 1DIT (XE) = 1NOO (XE) = 1NOO (XE) = 1

SI (XE) = 1 xx

WMC (XE) = 3WMC (XE) = 3

SI (XE) = 0.3333SI (XE) = 0.3333

1 // 3

Figura 12. Exemplo da métrica SI

Classe CS NOO NOA SI

Pessoa 3 0 3 0

Cliente 1 0 1 0

Funcionário 5 0 3 0

Cargo 2 0 2 0

FuncionarioHorista 6 1 3 0

FuncionarioMensalista 6 1 2 0

FuncionarioDiarista 5 1 2 0

Departamento 2 0 2 0

tabela 2. Exemplo de calculo do modelo de LK para Figura 2


de performance, é um gráfico circular em que as métricas são plotadas sobre retas radiais. Neste modelo, tem-se cada mé-trica representada. A linha vermelha é o limite determinado de acordo com os valores informados para cada métrica, antes da execução do cálculo. Os pontos vermelhos são as métricas que foram violadas. Os verdes significam que os valores máximos definidos na métrica estão de acordo com o que foi calculado. Se houver ponto azul, o valor mínimo estabelecido para métrica não foi atingido. Na Figura 14 é apresentado um exemplo do gráfico de Kiviat.

Figura 13. Visualização da estrutura de uma classe

Figura 14. Exemplo do gráfico de Kiviat

Ferramentas sobre Métricas Orientadas a ObjetosNesta seção serão apresentadas três ferramentas relacionadas

a métricas OO.

JMetric - Java Metrics AnalyserO JMetric propõem a coleta de métricas OO, o projeto foi

iniciado em abril de 1998 como parte de uma pesquisa refe-rente a ferramentas de medição de métricas em software OO. A equipe de desenvolvimento concluiu com a pesquisa que as ferramentas disponíveis para o propósito não eram boas. Então o JMetric começou a ser desenvolvida pela Univer-sidade tecnológica de Swinburne para coletar métricas em projetos Java. A ferramenta é open-source e continua sendo melhorada. Ao iniciar o JMetric é apresentada a tela principal (Figura 15).

Figura 15. Tela principal do JMetric

Para efetuar o cálculo das métricas do sistema o usuário deverá selecionar um projeto. Deverá ser adicionado um ar-quivo escrito em Java. Após adicionar o arquivo, é apresentada uma árvore com a estrutura das classes, neste casso o objeto TokenUtils(Figura 16).

Figura 16. Árvore com a estrutura da(s) classe(s)

Após a escolha do arquivo para o cálculo, é necessário sele-cionar a opção de calcular (Figura 17).

Figura 17. Calcular as métricas JMetrics

Após calcular as medidas, pose-se exibir de duas maneiras, tabelas e gráficos, de acordo com a documentação do projeto. Portanto, a exibição em forma de tabela não foi possível, pois a ferramenta não apresentou nenhum resultado conforme o gráfico demonstrado na Figura 18.


MEDIção

Ferramenta para cálculo de métricas em Softwares Orien-tados a Objetos codificados em Delphi

Em Seibt (2001) é descrito um protótipo de uma ferramenta para cálculo de métricas em software orientado a objetos. O protótipo é capaz de analisar o código fonte de um projeto OO em Delphi, extraindo as classes, seus métodos e atributos para posterior cálculo de métricas para software OO. A ferramenta permite calcular dezenove métricas de projeto e de construção, entre estas, profundidade da árvore de herança e métodos ponderados por classe.

Métricas para Programação Orientada a ObjetosEm Cardoso (1999) é descrito o software implementado para

facilitar o cálculo de métricas em sistemas OO. O sistema analisa o código fonte de projetos em Delphi e fornece cálculos de métricas como contagem de métodos, classes sucessoras, ascendentes e descendentes específicas para OO.

Desenvolvimento da ferramentaA partir de agora apresentaremos como uma ferramenta que

possibilita analisar código fonte OO em C# e Java e fornecer algumas das métricas estudadas foi construída.

Requisitos principais do problema a ser trabalhadoO objetivo do desenvolvimento foi disponibilizar uma

ferramenta capaz de calcular métricas pré-definidas a partir da análise de código fonte de projetos codificados em C# e Java. As informações para cálculo das métricas são coletadas através da extração das classes, métodos e de seus atributos através da análise dos arquivos de um projeto em C# e Java, exemplificada na Figura 19. Após a coleta destes dados são calculadas as métricas estudadas.

Para extrair e identificar as informações do código fonte, os dados das classes, foram utilizadas o Scanner e o Parser gerados pela ferramenta CocoR for C#. O Scanner separa os Tokenz e o Parser verifica a sintaxe do projeto.

Métricas selecionadasAs métricas de projeto e de construção são as mais indicadas

para se obter através da análise do código fonte, pois a maioria das informações necessárias para o cálculo destas métricas pode ser obtida através de análise automática do código fonte. As métricas a seguir foram as implementadas pelo software:• Número de serviços por classe;• Número máximo de superclasses;

Figura 18. Demonstração do gráfico do JMetric

• Número de subclasses;• Nível de acoplamento entre as classes;• Número de acesso a um ou mais atributos em comum pelos serviços da própria classe;• Capacidade de resposta da classe;• Número de serviços e atributos locais e herdados;• Métodos definidos nas superclasses herdados pelas subclasses;• Número de operações e atributos privados;• Número de serviços adicionados.

Figura 19. Esquema de funcionamento do protótipo

Especificação do SoftwarePara a especificação do software foi utilizada a UML, que é

apresentado através do diagrama de caso de uso, diagrama de classes e do diagrama de sequencia. Estes diagramas se-rão apresentados a seguir e foram construídos na ferramenta Enterpreise Architect.

Diagrama de Caso de UsoA ferramenta criada tem por objetivo facilitar a coleta de

métricas em códigos fontes. A Figura 20 exibe o diagrama de casos de uso da ferramenta. A Tabela 3 descreve os casos de uso exibidos na Figura 20, que se refere à iteração do arquiteto com os casos de uso.

Diagrama de ClassesNo desenvolvimento do software foram identificadas 53

classes. Destas serão exemplificadas métodos e atributos públicos de vinte e sete classes (Figura 21) que são utilizadas para armazenar as informações coletadas do código fonte e posteriormente auxiliar na obtenção das métricas. As outras vinte e seis classes estão dividias entre interfaces e auxiliares, não influenciam na exemplificação do funcionamento da ferramenta.

A classe ColetaMetricas é responsável por iniciar a análise do código fonte dos arquivos do projeto selecionado e a partir desta análise alimentar a classe ColetaMetricas, com objetos Classe, que por sua vez será composta com as classes Atribu-tos, Servicos e Assinatura. A Tabela 4 descreve os métodos da classe ColetaMetricas.


ud Diagrama de Caso de Uso

Arquiteto

5 - Calcular métricas

3 - Selecionar métricas

6 - Salv ar projeto

7 - Abrir projeto

2 - Selecionar arquiv os

indiv iduais

4 - Definir limites de algumas

métricas

1 - Selecionar arquiv o de projeto

Figura 20. Diagrama de caso de uso

Figura 21. Diagrama de classes

Caso de Uso Descrição

Selecionar arquivos de projeto Permite ao arquiteto de software escolher o projeto que será

analisado, que pode ser um escrito em C# ou Java.

Seleciona arquivos individuais Permite ao arquiteto de software selecionar arquivos

individualmente para uma análise específica de um arquivo

escrito em Java ou C#.

Selecionar métricas Permite ao arquiteto de software escolher as métricas que serão

calculadas.

Salvar projeto Permite ao arquiteto de software gravar o resultado do cálculo

das métricas.

Abrir projeto Permite ao arquiteto de software carregar um projeto gravado

anteriormente.

Definir limites de algumas

métricas

Permite ao arquiteto de software definir o limite mínimo e

máximo que uma determinada métrica pode atingir.

Calcular métricas Permite ao arquiteto de software calcular as métricas a partir das

informações selecionadas anteriormente.

tabela 3. Descrição dos casos de uso do ambiente de coleta de métricas

Métodos Descrição

ColetaMetricas() Operação responsável pela criação da classe.

AddClasse() Adiciona uma nova classe para coleta das métricas.

GetClasse() Retorna um objeto Classe.

Coletar() Operação responsável por iniciar a análise do código fonte para extração dos

dados do projeto para posterior cálculo das métricas.

tabela 4. Descrição dos métodos da classe ColetaMetricas


MEDIção

A classe Scanner é a que auxilia na análise do código fonte. A mesma faz uma busca e extração de identificadores, sím-bolos especiais e palavras reservadas. A Tabela 5 descreve os métodos e atributos da classe Scanner.


SetColetaMetricas() Informa para a classe Scanner o objeto ColetaMetricas descrito anteriormente.

GetColetaMetricas() Retorna um objeto ColetaMetricas.

LoadFile() Responsável por carregar o arquivo a ser analisado.

Scan() Operação responsável por pegar o próximo símbolo para a análise.

Peek() Avança para o próximo símbolo.

ResetPeek() Certifica-se de que o Peek() comece pela posição atual da busca.

Atributos Descrição

AddClass Armazena se foi adicionado uma classe.

tabela 5. Descrição dos métodos da classe Scanner

A classe ScannerCS é uma extensão da classe Scanner, e tem a função de analisar do código fonte escrito em C#. A Tabela 6 descreve os métodos da classe ScannerCS.


ScannerCS(string) Operação responsável pela criação da classe, informando o caminho do

arquivo que será analisado.

ScannerCS(Stream) Operação responsável pela criação da classe, informando o arquivo já

carregado que será analisado.

tabela 6. Descrição dos métodos da classe ScannerCS

A classe ScannerJava é uma extensão da classe Scanner, e auxilia na análise do código fonte escrito em Java. A Tabela 7 descreve os métodos da classe ScannerJava.


ScannerJava(string) Operação responsável pela criação da classe, informando o caminho do

arquivo que será analisado.

ScannerCS(Stream) Operação responsável pela criação da classe, informando o arquivo já

carregado que será analisado.

tabela 7. Descrição dos métodos da classe ScannerJava

A classe Parser é responsável pela análise léxica e sintática do código fonte. A Tabela 8 descreve o método da classe Parser.


Error() Operação responsável pelo disparo da mensagem de erro caso o parsing

retorne algum erro.

tabela 8. Descrição dos métodos da classe Parser

A classe ParserCS é uma extensão da classe Parser, e auxilia na análise léxica e sintática do código fonte escrito em C#. A Tabela 9 descreve o método da classe ParserCS.

A classe ParserJava é uma extensão da classe Parser, e auxilia na análise léxica e sintática do código fonte escrito em Java. A Tabela 10 descreve o método da classe ParserJava.


ParserJava() Operação responsável pela criação da classe e iniciar a análise.

tabela 10. Descrição dos métodos da classe ParserJava

A classe Errors é responsável pela notificação dos erros en-contrados na análise do código fonte. A Tabela 11 descreve os métodos da classe Errors.


SynErr() Operação responsável pela notificação dos erros sintáticos.

SemErr() Operação responsável pela notificação dos erros semânticos em uma

futura implementação.

Error() Operação responsável pela notificação de erros diversos como arquivo

corrompido.

tabela 11. Descrição dos métodos da classe Errors

A classe ErrorsCS é uma extensão da classe Errors, e auxilia nos erros da análise do código fonte escrito em C#. A Tabela 12 descreve os métodos da classe ErrorsCS.


SynErr() Operação responsável pela notificação dos erros sintáticos do código fonte C#.

tabela 12. Descrição dos métodos da classe ErrorsCS

A classe ErrorsJava é uma extensão da classe Errors, e auxilia nos erros da análise do código fonte escrito em Java. A Tabela 13 descreve o método da classe ErrorsJava.


SynErr() Operação responsável pela notificação dos erros sintáticos do código fonte Java.

tabela 13. Descrição dos métodos da classe ErrorsJava

A classe Classe contém as informações das classes encontra-das no projeto analisado, sempre que uma classe é encontrada, um objeto Classe é instanciado a partir do método AddClasse() da classe ColetaMetricas (Listagem 1). A Tabela 14 descreve os métodos e atributos da classe Classe.


ParserCS() Operação responsável pela criação da classe e iniciar a análise.

tabela 9. Descrição dos métodos da classe ParserCS


SetSuper() Informa para o objeto Classe qual é a classe antecessora da mesma.

GetSuper() Retorna a descrição da classe antecessora.

SetAbstract() Informar se a classe é abstrata ou não.

SetAbstract() Retorna se a classe é abstrata ou não.


Assinatura Contém o nome da classe.

Atributos Contém os atributos da classe.

Serviço Contém os serviços ou métodos da classe.

CK Contém as métricas previstas por Chidamber e Kemerer.

LK Contém as métricas previstas por Lorenz e Kidd.

tabela 14. Descrição dos métodos da classe Classe


A classe Atributo contém as informações dos atributos das classes encontradas no projeto analisado. A Tabela 15 descreve os métodos da classe Atributos.


SetAtributo() Adiciona um atributo no objeto Atributo.

GetAtributo() Retorna a descrição do atributo solicitado.

tabela 15. Descrição dos métodos da classe Atributos

Já a classe Servico contém as informações dos serviços ou métodos das classes encontradas no projeto analisado. A Tabela 16 descreve os métodos da classe Servico.


SetServico() Adiciona um serviço no objeto Serviço.

GetServico() Retorna a descrição do serviço solicitado.

tabela 16. Descrição dos métodos da classe Servico

A classe Assinatura é responsável por definir a descrição de outras classes. A Tabela 17 descreve os métodos da classe Assinatura.


SetAssinatura() Informa para o objeto Assinatura a descrição da mesma.

GetAssinatura() Retorna a descrição do objeto Assinatura.

tabela 17. Descrição dos métodos da classe Assinatura

A classe CK contém as informações das métricas previstas por Chidamber e Kemerer descritas anteriormente neste artigo. A Tabela 18 descreve os atributos da classe CK.


WMC Contém o objeto de métrica WMC.

CBO Contém o objeto de métrica CBO.

RFC Contém o objeto de métrica RFC.

LCOM Contém o objeto de métrica LCOM.

NOC Contém o objeto de métrica NOC.

DIT Contém o objeto de métrica DIT.

tabela 18. Descrição dos atributos da classe CK

A classe LK contém as informações das métricas previstas por Lorenz e Kidd apresentadas anteriormente neste artigo. A Tabela 19 descreve os atributos da classe LK.

Listagem 1. Instancia um objeto de Classe

public void AddClasse(string prClasse){ Classe classe = new Classe(); classe.Assinatura.SetAssinatura(prClasse); Classes.Add(prClasse.ToUppper(), classe);}

A classe Metricas contém as informações referentes à quan-tidade calculada da métrica. A Tabela 20 descreve os métodos da classe Metrica.


SetValor() Informar para o objeto Metricas o valor calculado.

GetValor() Retorna o valor calculado.

tabela 20. Descrição dos métodos da classe Metricas

As classes WMC, CBO, RFC, LCOM, NOC, DIT, SI, NOA, CS e NOO são extensões da classe Métricas descrita na Tabela 20, dando um destaque para as classes DIT e NOO que especiali-zaram o construtor da classe Metricas. As Tabelas 21 e 22 des-crevem os métodos das classes DIT e NOO respectivamente.


DIT() Operação responsável pela criação da classe.

tabela 21. Descrição dos métodos da classe DIT


NOO() Operação responsável pela criação da classe.

tabela 22. Descrição dos métodos da classe NOO

Diagrama de AtividadeNa Figura 22 é apresentado o diagrama de atividades, que

representa os passos para a realização do cálculo das métricas. A Tabela 23 descreve as atividades deste processo.

Atividades Descrição

Seleciona opção inicial O arquiteto de software escolhe criar um novo projeto ou

abrir um projeto existente.

Preencher dados do projeto O arquiteto de software preenche os dados referentes ao

projeto criado.

Selecionar projeto / arquivo(s) para o

cálculo das métricas

O arquiteto de software escolhe um projeto escrito em

C# ou Java para a coleta das métricas.

Selecionar métricas a serem coletadas O arquiteto de software define dentre as métricas

propostas, as que serão coletadas.

Definir limites para cada métrica O arquiteto de software informa o limite mínimo e

máximo que uma determinada métrica pode atingir.

Calcular métricas O arquiteto de software executa o cálculo das métricas.

tabela 23. Descrição das atividades do processo de coleta das métricas

ImplementaçãoConsiderações sobre as técnicas utilizadas para implemen-

tação do software, bem como a forma de operação do mesmo, serão apresentadas nesta seção.


CS Contém o objeto de métrica CS.

NOA Contém o objeto de métrica NOA.

SI Contém o objeto de métrica SI.

NOO Contém o objeto de métrica NOO.

tabela 19. Descrição dos atributos da classe LK


MEDIção

Figura 22. Diagrama de atividades do processo de coleta das métricas

No construtor da classe ColetaMetricas, é atribuído dentre outros parâmetros, a lista de arquivos e o tipo do projeto a ser coletada as métricas conforme pode ser observado na Listagem 2.

O processo de coleta de medidas é iniciado através do método Coletar() da classe ColetaMetricas. Este método não recebe parâmetro porque no construtor da classe já foram passadas todas as informações necessárias para a coleta das métricas.

O método Coletar() faz um laço sobre a lista de arqui-vos informado no construtor da classe ColetaMetricas no

parâmetro prListaArquivos que foi atribuído ao atributo FlistaArquivos (Listagem 2). A cada iteração do procedi-mento Coletar() é chamado o método parse() que carrega o arquivo informado no parâmetro do mesmo (Listagem 3), e é iniciado o processo de análise léxica e sintática do texto do arquivo segundo gramática definida.

O método parse() instancia as classes o atributo parser e scanner (Listagem 3) de acordo com o atributo Ftype-Project informado no construtor da classe ColetaMetricas (Listagem 2).

Caso o processo de parsing ocorra sem nenhum erro, o atributo Classes que está definido na classe ColetaMetricas (Listagem 4) conterá as métricas coletadas do projeto.

Listagem 2. Atribuindo a lista de arquivos para coleta das métricas e o tipo

do projeto

public ColetaMetricas(CheckedListBox prListFiles, ArrayLista prListaArquivos, DataSet prDataSet, byte prTypeProject) { FListaArquivos = prListaARquivos; FListaFiles = prListaFiles; FDataSet = prDataSet; FTypeProject = prTypeProject; }

public void Coletar(){ for (int i = 0; i < FListFiles.Items.Count; i++) { this.parse(FListaArquivos[i].ToString().Replace(“’\’”,”\\”).ToString() + “\\” + FListFiles.Items[i].ToSting()); }}

Listagem 3. Executando o analisador léxico e sintático no arquivo informado

private void parse(string s) { fstream = File.Open(s, FileMode.Open, FileAccess.Read, FileShare.Read); switch (FTypeProject) { case 0: //C# scanner = new ScannerCS(s); parser = new ParserCS(scanner); break; case 1: //Java scanner = new ScannerJava(s); parser = new ParserJava(Scanner); break; } scanner.SetColetaMetricas(this); parser.Parse(); // Analisa o código

}

Listagem 4. Definição do atributos da classe ColetaMetricas

public class ColetaMetricas { private ArrayLista FListaArquivos; private CheckedListBox FListFiles; private FileStream fstream; private Scanner scanner; private Parser parser; private Hashtable Classes = new Hashtable(); private DataSet FDataSet; private byte FTypeProject;


Se existirem erros durante a análise léxica e sintática do texto do arquivo, estes erros são informados conforme o código ilus-trado na Listagem 5. Neste caso, nenhuma métrica é coletada e, portanto, não serão exibidas as medidas do projeto.

A gramática ilustrada nas Listagens 6 e 7 ajudou na cons-trução do analisador para a coleta das métricas. Ela identifi-ca em uma classe informações como a declaração, estrutura, declaração da estrutura, métodos e atributos.

Técnicas e ferramentas utilizadasO software foi implementado no ambiente de desenvolvimen-

to Microsoft Visual C# 2005 Express Edition, utilizando a OO

ClassDeclaration= “class” ident [“extends” Type] [“implements” TypeList] ClassBody.

ClassBody=’{‘{ClassBodyDeclaration} ‘}’.

ClassBodyDeclaration=’;’|[“static”] (Block|[Modifier1 {Modifier} ] MemberDec1.

MemberDec1=IF(identAndLPar()) ident ConstructorDeclaratorRest| MethodOrFiedlDec1| “void” ident VoidMethodDeclaratorRest| ClassDeclaration| InterfaceDeclaration.

MethodOrFieldDec1= Type ident MethodOrFieldRest.

MethodOrFieldRest= VariableDeclaratorsRest ‘;’| MethodoDeclaratorRest.

VariableDeclaratorsRest= VariableDeclaratorRest {‘,’VariableDeclarator}.

ArrayInitializer= ‘}’[VariableInitializer {IF(commaAndNoRBrace()) ‘,’VariableInitializer}] [‘,’]’}’.

MethodoDeclaratorRest= FormalParameters BracketOpt [“throws”QualidentList] (Block | ‘;’).

VoidMethodDeclaratorRest= FormalParameters [“throws”QualidentList] (Bloch | ‘;’).

ConstructorDeclaratorRest= FormalParameters [“throws”QualidentList] Block

FormalParameters=’(‘[Formal Parameter {‘,’FormalParameter}]’)’

Listagem 6. Gramática da classe para linguagem Java

public void SynErr(int line, int col, int n){ string s; switch (n) { case 0: s = “EOF expected”; break; case 1: s = “ident expected”; break; case 2: s = “intCon expected”; break; case 3: s = “realCon expected”; break; case 4: s = “charCon expected”; break; case 5: s = “stringCon expected”; break; case 6:

s = “abstract expected”; break; case 7: s = “as expected”; break; case 8: s = “base expected”; break; case 9: s = “bool expected”; break; case 10: s = “break expected”; break; case 11: s = “byte expected”; break; case 12: s = “case expected”; break; . . .

Listagem 5. Tratamento de erro

para o desenvolvimento do projeto. Para geração do analisador léxico e sintático foi utilizado o Coco/R for C#, o que facilitou bastante para que fosse dada total atenção à coleta de métricas. Já a geração das palavras reservadas e da lista de tokens foi gerada a partir da gramática do C# e Java (Listagens 6 e 7). Para a geração do gráfico foi utilizada a biblioteca GDI+ que está disponível no C# e para elaboração da ajuda foi utilizado o HelpNDoc.

OperaçãoA partir de agora serão apresentadas as telas do software com

suas respectivas funcionalidades. Com o intuito de facilitar a


MEDIção

demonstração e compreensão, será realizada a coleta das mé-tricas de um projeto C# a partir do código fonte das classes da Figura 2 que contém as classes Pessoa, Cliente, Funcionario, Cargo, Departamento, FuncionarioMensalista, Funcionario-Horista e FuncionarioDiarista.

Dessa forma, ao iniciar o sistema será apresentada a tela principal do programa ao usuário como ilustra a Figura 23. A ferramenta conta com opções de menu, barra de atalho e local destinado a projetos.

Figura 23. Tela principal do software

Para iniciar um novo projeto no sistema o arquiteto de sof-tware deverá selecionar a opção “Novo Projeto...” ou clicar em “Projeto...” conforme a Figura 24.

Para efetuar o cálculo das métricas de um sistema o arquiteto de software deverá selecionar um projeto. Esta seleção pode ser de duas formas. A primeira é selecionar um novo projeto para coleta de métricas. Após a escolha, a guia “Projeto” é

apresentada para o preenchimento dos dados do projeto como pode ser visto na Figura 25.

Figura 24. Criação de um novo projeto no Visual Métrica

Figura 25. Guia de informação dos dados do projeto

NamespaceMemberDeclaration (.Modifiers m = new Modifiers(this);.)=

“namespace” ident {“.” ident}“{“{ IF (IsExternaAliasDirective()) ExternAliasDirective} { UsingDirective } {NamespaceMemberDeclaration} “}”[“;”]| {Attributes} ModifierList<m> TypeDeclaration<m>.

TypeDeclaration<Modifiers m> (. TypeKind dummy; .)=([“partial”]( (. m.Check(Modifier.classes);.)“class” ident [TypeParameterList][“:”TypeName {“,”TypeName}]{TypeParameterConstraintsClause} StructBody [“;”]| (. m.Check(Modifier.nonClassTypes); .)“struct” ident [TypeParameterList][“:” TypeName {“,”TypeName}]{TypeParameterConstraintsClause} StructBody [“;”]| (. m.Check(Modifier.nonClassTypes); .)“interface” ident [TypeParameterList][“:” TypeName {“,”TypeName}]

{TypeParameterConstraintsClause}“{“{InterfaceMemberDeclaration} “}”[“;”])| (. m.Check(Modifier.nonClassTypes); .)“enum” ident [“:” InteggralType] EnumBody [“;”]| (. m.Check(Modifier.nonClassTypes); .)“delegate”Type<out dummy, true> ident [ TypeParameterList ]“(“[FormalParameterList] “)”{TypeParameterConstraintsClause } “;”).

ClassBase=“:” ClassType {“,” TypeName}.ClassBody=“{“{ { Attributes }ModifierList<m>ClassMemberDeclaracion<m>}“}”

Listagem 7. Gramática da classe para linguagem C#


Figura 28. Tela de seleção de projetos salvo anteriormente

Após informar os dados do projeto, deverá ser selecionado o projeto ou o(s) arquivo(s) para o cálculo das métricas. Na janela ao lado dos dados do projeto, encontra-se uma outra janela com o título “Selecionar Projeto”. Para escolher um projeto basta clicar no ícone que representa uma lupa e será apresentada uma caixa de diálogo para abrir um arquivo (as extensões dos arquivos a serem aberto são referentes a projeto C#, arquivos individuais do C# e arquivos do Java consecutivamente, “.vc-proj”, “.cs”, “.java”) conforme Figura 26.

Figura 26. Tela de abertura do projeto para análise

Após a escolha do projeto a ser analisado, é listado o(s) arquivo(s) na janela “Selecionar Projeto” conforme a Figura 27.

Figura 27. Lista dos arquivos referentes ao projeto selecionado

Com todos os dados do projeto preenchidos e o projeto esco-lhido, deverá ser selecionada a guia “Métrica” para a escolha das medidas que serão calculadas para o projeto conforme visto na Figura 28.

Outra funcionalidade muito interessante da ferramenta é a possibilidade de definir limite máximo e mínimo de algumas métricas. Esta parametrização é por projeto e influencia dire-tamente o resultado do cálculo. Ao navegar pelas métricas, a descrição da mesma é apresentada na parte inferior da tela na janela Descrição como pode ser visto na Figura 29.

Após a definição de todos os parâmetros do projeto, informações referentes ao mesmo, métricas a serem calculadas e os limites das métricas, deverão ser calculadas as medidas deste código conforme ilustrada na Figura 30.

Durante o cálculo das métricas, algumas informações são atua-lizadas na tela como qual o arquivo que está sendo analisado no momento e uma barra de progressão para informar o percentual do que já foi calculada conforme ilustrada na Figura 31.

Após o cálculo das métricas os resultados são apresentados como mostra as Figuras 32 e 33. Estas telas listam todas as métri-cas selecionadas e calculadas para cada classe do projeto.

Outra opção interessante desta ferramenta é a possibilidade de analisar os resultados obtidos do cálculo com o auxílio do gráfico proposto por Kiviat. Para analisar a classe escolhida basta clicar com o botão direito do mouse na grade dos resultados em cima da classe e será exibida a opção de gráfico conforme é ilustrado na Figura 34.

O gráfico será gerado com base nas informações calculas para a classe selecionada, respeitando os limites escolhidos na Figura 29. Esta opção propõe uma visualização dos dados de uma maneira mais intuitiva e não só com valores em grade que pode se tornar confuso e pouco apresentável. As métricas que influenciam no gráfico são: WMC, DIT, NOO, CBO e LCOM. A Figura 35 demonstra os dados em forma de gráfico exemplificado anteriormente neste artigo.

Figura 29. Tela de parametrização de limite máximo e mínimo por métrica


MEDIção

Depois de analisar um projeto, o arquiteto de software pode salvar suas informações em disco. Para isto basta escolher a opção Arquivo e em seguida Salvar (Figura 36). Em seguida é apresentada a tela para escolha do nome que será salvo, o projeto e o seu diretório (Figura 37).

Outra maneira de escolher um projeto para o cálculo dessas me-didas é abrir um projeto analisado previamente e armazenado em disco. Para tanto, o arquiteto de software deve selecionar a opção Abrir na barra de atalho ou no menu escolher Arquivo e posterior-mente Abrir Projeto. Ainda existe a opção de utilizar as teclas de atalho CTRL+SHIFT+O. O sistema mostrará a tela da Figura 38, que permite a escolha de um projeto salvo anteriormente.

Com o intuito de demonstrar o funcionamento da ferramen-ta em um projeto escrito em Java, será realizada a coleta das métricas das classes da Figura 39.

Figura 35. Gráfico de Kiviat

Figura 30. Tela para o cálculo das métricas

Figura 31. Tela com informações durante o cálculo

Figura 32. Resultado do cálculo segundo Chidamber e Kemerer

Figura 33. Resultado do cálculo segundo Lorenz e Kidd

Figura 34. Opção de análise com o gráfico de Kiviat


Figura 36. Tela de opções do projeto

Figura 37. Tela para escolher o nome do projeto a ser salvo

Figura 38. Tela de seleção de projeto salvo anteriormente

Os passos são similares ao demonstrado nas telas anteriores. Os resultados do cálculo são apresentados nas Figuras 40 e 41.

O protótipo implementado ainda dispõe do recurso de ajuda, podendo ser acessado pelo menu do sistema Figura 42 ou pela tecla de atalho “F1”.

A ajuda do sistema é disponibilizada no formato HTML e tem um menu com as opções no lado esquerdo do vídeo e as informa-ções do outro lado. A Figura 43 exemplifica a ajuda do sistema.

cd Classe Exemplo Protótipo

Telefone

- NomeUsuario: string- EnderecoInstalacao: string- DataInstalacao: Date

+ getValorBasico() : float

TelefoneResidencial

- ConexaoInternet: Boolean


TelefoneComercial

- QtdeRamais: int


Figura 39. Exemplo para demonstração (Fonte: Hugo e Hübner)

Figura 40. Resultado do cálculo segundo Chidamber e Kemerer Java

Figura 41. Resultado do cálculo segundo Lorenz e Kidd Java

Resultados e discussõesA Tabela 24 traz um comparativo entre quatro ferramentas

de coleta de métricas em software OO, e tem o objetivo de demonstrar algumas das métricas calculadas por essas ferra-mentas, linguagens suportadas e demonstrativo de resultados em forma de gráfico.


MEDIção

Figura 43. Tela de ajuda do sistema

Figura 42. Opção de ajuda do protótipo

Ferramenta Métrica Linguagem Gráfico

WM

C

DIT

NOC

CBO

LCOM

RFC

CS NOO

NOA

SI C# Java

Delp

hi

Visual Métrica X X X X X X X X X X X X X

JMetric X X X X X X X X

Protótipo Seibt (2001) X X X X X X X X X X X

Protótipo Cardoso (1999) X X X X X X

tabela 24. Comparativo entre as ferramentas


Pode-se perceber neste comparativo que a ferramenta Visual Métrica cujo desenvolvimento foi apresentado neste artigo possui funcionalidades mais abrangentes que outras de pro-posta semelhante.

ConclusõesNeste artigo apresentamos um conjunto de conceitos asso-

ciados a métricas de software. Além disso, apresentamos o desenvolvimento de uma ferramenta para coleta de métricas em software OO escritos em C# e Java. A ferramenta calcula dez métricas previstas por CK e LK.

A utilização da ferramenta CocoR for C# para a construção do analisador léxico e sintático foi importante, pois como foi uma ferramenta de fácil aprendizado, acelerou e simplificou

o processo de desenvolvimento do analisador. As utiliza-ções da ferramenta Microsoft Visual C# Express Edition e Enterprise Architect também auxiliaram consideravelmente no desenvolvimento. Para a implementação da classe de coleta de métricas foram necessários estudos detalhados da estrutura das classes C# e Java.

1. AMBER, Scott W. Análise e projeto orientado a objeto: seu guia para desenvolver sistemas robustos com tecnologia de objetos. Tradução Oswaldo Zanelli. Rio de Janeiro: Infobook, 1998.

2. ARTHUR, Lowell J. Melhorando a qualidade de software: um guia para o TQM. Rio de Janeiro. Infobook, 1994.

3. CARDOSO, Eduardo J. Métricas para programação orientada a objetos. 1999. 45 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Universidade Regional de Blumenau, Blumenau.

4. CORDEIRO, Marco A. Métricas de software. Curitiba, 2000. Disponível em: <http://www.pr.gov.br/batebyte/edicoes/2000/bb101/metricas.htm>. Acesso em: 12 nov. 2005.

5. CÔRTES, Mario L.; CHIOSSI, Thelma C. S. Modelos de qualidade de software. Campinas: Editora da UNICAMP, 2001.

6. DEMARCO, Tom. Controle de projetos de software: gerenciamento, avaliação, estimativa. Rio de Janeiro: Campus, 1989.

7. FUNCK, Mônica Andréa. Estudo e aplicação das métricas da qualidade do processo de desenvolvimento de aplicações em banco de dados. 1995. 104 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

8. GUSTAFSON, David A. Teoria e problema de engenharia de software. São Paulo: Bookman, 2003.

9. HÜBNER Jomi F.; HUGO Marcel. Prática de laboratório – lista 4. Blumenau, 2003. Disponível em: <http://www.inf.furb.br/~poo/listas/poo-praticaLab4.pdf>. Acesso em: 3 nov. 2006.

10. JACOBSON, Ivar et al. Object oriented software engineering: a use case driven approach Wokingham: Addison Wesley, 1992.

11. KOSCIANSKI, Andre; SOARES, Michel dos S. Qualidade de software:Aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo: Novatec, 2006.

12. LORENZ, Mark; KIDD, Jeff. Object-oriented software metrics: a practical guide. New Jersey: PTR Prenticel Hall, 1994.

13. MOLLER, Kurt. H., PAULISH, Daniel J. Software metrics: a practitioneris guide to improved product development. Los Alamitos: IEEE, 1993.

14. POSSAMAI, Roque César. Ferramenta de análise de estruturas básicas em linguagem Pascal para o fornecimento de métricas. 2000. 71 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

15. PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995.

16. ROCHA, Ana R.; MOLDONADO, José C.; WEBER, Kival C. Qualidade de software: teoria e prática. São Paulo: Prentice Hall, 2001.

17. ROSENBERG, Linda. Applying and interpreting object oriented metrics. Utah, abr. 1998. Disponível em: <http://satc.gsfc.nasa.gov/support/STC_APR98/apply_oo apply_oo.html>. Acesso em: 07 jun. 2006

18. SEIBT, Patrícia R. R. S. Ferramenta para cálculo de métricas em softwares orientados a objetos codificados em Delphi. 2001. 86 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Universidade Regional de Blumenau, Blumenau.

19. SHEPPERD, Martin. Foundation of software measurement. New York: Prentice Hall, 1995.

20. TONINI, Antonio C. Métricas de software. [S.l.], 2004. Disponível em: <http://www.spin.org.br/Pdf/metricas%202.ppt>. Acesso em: 12 nov. 2005.

Referências bibliográficas




Dê

seu Feedback

sob

re esta edição


Paulo C. Barreto da [email protected]

Graduado em Análise de Sistemas pelo Centro Universitário Salesiano de São Paulo (2003) e Pós-graduado pela Universidade Estadual de Campinas - UNICAMP - na área de Orientação a Objetos (2005). Professor da Anhanguera Educacional SA e Analista de Sistemas na Pa-pirus Indústria de Papel SA. Possui experiência de 11 anos na área de Ciência da Computa-ção, com ênfase em Sistemas de Informação, atuando principalmente nos seguintes temas: análise de sistemas, programação orientada a objetos, programação estruturada, desen-volvimento de sistemas, UML (Linguagem de Modelagem Unificada), gestão de projetos, linguagem de programação C e Java.

Thiago Salhab [email protected]

Graduado em Ciência da Computação pela Universidade Metodista de Piracicaba - UNI-MEP (2004) e Mestre em Ciência da Computa-ção pela Universidade Metodista de Piracica-ba - UNIMEP (2008). Professor e Coordenador do curso de Ciência da Computação da Facul-dade Anhanguera de Santa Bárbara. Possui seis anos de experiência na área de Ciência da Computação com ênfase em Engenharia de Software.

De que se trata o artigo?Este artigo apresenta uma análise sobre as dependên-cias entre práticas específicas para as sete áreas de processo do nível 2 de maturidade do CMMI.

Para que serve?Serve como guia para a melhoria de processos na orga-nização e também da habilidade dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção dos produtos ou serviços.

Em que situação o tema é útil?Como modelo de capacitação e maturidade do pro-cesso e como ferramenta de acuidade da qualidade do desenvolvimento, podendo ser utilizada por equipes e organizações desenvolvedoras de sof-tware que pretendem avaliar seus processos frente ao CMMI.

Análise de dependências entre práticas específicas do nível 2 do CMMI

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Equipes e organizações desen-volvedoras de software muitas vezes adotam diferentes práticas

de desenvolvimento, criando o que se costuma chamar de processos ad hoc de desenvolvimento de software. Infeliz-mente esses processos ad hoc costumam ser pouco controlados, não passíveis de repetição e altamente dependentes da capacidade individual de cada membro da equipe.

Desde a década de 1990, vários modelos de maturidade de processos vêm sendo propostos com o objetivo de auxiliar na melhoria da qualidade dos processos de software adotados pelas organizações [3]. Entre eles podemos citar os modelos CMM [5], Spice – ISO/IEC 15504 [2], CMMI [1] e mais recentemente, no Brasil, o MPS-BR [4]. Atualmente as organiza-ções que desenvolvem software estão atentas às necessidades da adoção de processos de desenvolvimento de sof-tware melhor definidos, e observam-se movimentos dessas organizações em

busca de certificações de qualidade de processos de software, notadamente as certificações CMMI de nível 2.

Neste sentido, o objetivo deste artigo é apresentar o resultado de uma análise ampla sob o CMMI que foi realizada para determinar possíveis dependências entre as práticas específicas em uma mesma área de processo. Para isso, foram

36 Engenharia de Software Magazine - Análise de dependências entre práticas específicas do nível 2 do CMMI

analisadas as sete áreas de processo do nível 2 de maturidade. As motivações para a análise se devem ao fato das organizações e equipes de desenvolvimento, que fazem o uso do CMMI para avaliação de seus processos, não encontrarem no documento oficial uma descrição clara e objetiva de possíveis relações de dependências entre práticas específicas dentro de uma mesma área de processo (o documento apenas sugere uma consulta de áreas de processos relacionadas para mais informações). A comprovação das dependências é de grande importância para um método de auto-avaliação de processos de software, pois sabendo quais as práticas que possuem dependentes, uma maior atenção na classificação dessas práticas deverá ser adotada e eventuais falhas na classificação podem ser identificadas e corrigidas.

Com o resultado das análises de dependências e estudos dos principais modelos de avaliação integrados ao CMMI (ARC V1.2 (Appraisal Requirements for CMMI)), e do método de avaliação SCAMPI A (Standard CMMI Appraisal Method for Process Improvement), foi desenvolvido um método de auto-avaliação de processos de software, apoiado por um protótipo da ferramenta MAPSw, apresentando-se como um instrumento que oferecerá auxílio às organizações e às equipes de desen-volvimento de software na melhoria de seus processos frente ao CMMI nível 2 de maturidade, bem como na obtenção de certificação CMMI em um futuro próximo.

As principais motivações para o desenvolvimento deste mé-todo se devem à escassez de métodos de auto-avaliação para CMMI e pela dificuldade encontrada pelas organizações e equipes de desenvolvimento em interpretar e utilizar correta-mente os documentos de avaliação (ARC e SCAMPI A), pois são muito extensos, passíveis de má interpretação e apresentados em inglês. Dessa forma, o método e a ferramenta desenvolvi-dos dão suporte à verificação de dependências entre práticas, auxiliando o usuário a identificar em que pontos devem ser melhorados e a minimizar possíveis falhas de avaliação.

O restante deste artigo está organizado da seguinte forma: na seção CMMI são apresentados seus principais compo-nentes e áreas de processo; na seção Modelos de Avaliação Integrados ao CMMI são apresentados o ARC e SCAMPI, que são os principais modelos de Avaliação; na seção Análise das Dependências entre Práticas Específicas é apresentada uma análise sobre as dependências entre práticas específicas das áreas de processos do nível 2; na seção MAPSw: Método de Auto-Avaliação de Processos de Software é apresentado o método de auto-avaliação que dá suporte a análise de depen-dências entre práticas; e na última seção são apresentadas as conclusões deste artigo.

CMMICapability Maturity Model Integration for Development versão

1.2 (2006) é uma atualização do CMMI versão 1.1 (2002) desen-volvido no SEI (Software Engineering Institute) e patrocinado pelo Departamento de Defesa dos Estados Unidos e filiado à Universidade Carnegie Mellon. O objetivo principal do CMMI foi integrar vários modelos disponíveis, que dificultavam e

apresentavam alto custo de implantação. Os principais com-ponentes do CMMI são:• Áreas de processo: conjunto de práticas que quando exe-cutadas, satisfazem a um conjunto de metas consideradas importantes para obter melhoria significativa;• Metas específicas: aplicam-se a uma área de processo e descrevem o que deve ser executado para satisfazer a área de processo. São componentes requeridos do modelo e utilizados nas avaliações para ajudar a determinar se uma área de pro-cesso está satisfeita;• Práticas específicas: são atividades importantes para conse-guir a meta específica associada. São componentes esperados do modelo;• Metas genéricas: são consideradas genéricas pois aparecem em várias áreas de processo. São componentes requeridos do modelo e usados nas avaliações para determinar se uma área de processo está satisfeita;• Práticas genéricas: asseguram que os processos associados com a área de processo sejam eficazes e duradouros. São com-ponentes esperados do modelo;• Produtos típicos do trabalho: listam exemplos de saída de práticas específicas. Esses exemplos são chamados produtos típicos de trabalho porque há frequentemente outros produtos de trabalho que são efetivos, mas não listados. São componen-tes informativos do modelo.

As áreas de processo do nível 2 de maturidade do modelo CMMI são [1]:• Gerência de Requisitos;• Planejamento do Projeto;• Monitoramento e Controle do Projeto;• Gerência de Acordo com Fornecedores;• Medição e Análise;• Garantia da Qualidade do Produto e Processo;• Gerência de Configuração.

Cada área de processo possui metas específicas e genéricas com suas respectivas práticas específicas e genéricas, e cada prática apresenta produtos típicos de trabalho que são exem-plos de saída da implementação da prática.

Para algumas práticas específicas, o CMMI apenas solicita a consulta de áreas de processos relacionadas. Em nenhum momento uma relação de dependência entre áreas de processo, metas e práticas é apresentada, sendo apresentadas apenas as descrições das mesmas. Assim, o estudo das possíveis dependências foi realizado e é descrito na seção Análise das Dependências entre Práticas Específicas.

Modelos de Avaliação Integrados ao CMMIOs principais modelos usados para avaliação de processos

de software integrados ao CMMI são o ARC (Appraisal Requi-rements for CMMI) versão 1.2 e o SCAMPI A (Standard CMMI Appraisal Method for Process Improvement) versão 1.2.

O ARC define os requisitos considerados essenciais para métodos de avaliação que pretendem ser usados com o CMMI.


PRoCESSo

Os requisitos são alocados em cada classe, baseado nos atributos associados com essa classe. Assim, um método de avaliação pode ser declarado para ser um ARC classe A, B ou C. Nem todos os méto-dos de avaliação CMMI são esperados de estar em total conformidade com o ARC, isto é, satisfazer cada requisito ARC.

Os métodos da classe A devem satisfazer todos os requisitos ARC e até o presente momento, são os únicos métodos considerados apropriados para fornecer avaliação. Um exemplo do método da clas-se A é o SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Os requisitos incluem seções de: Responsabilidade; Documentação do Método de Avaliação; Planejamento e Preparação para a Avaliação; Coleção dos Dados da Avaliação; Consolidação dos Dados e Validação; Avaliações e Relatório de Resultados.

O SCAMPI A foi desenvolvido para prover pontu-ações para modelos CMMI. É aplicado a uma vasta escala de modos de avaliação, incluindo melhoria de processo interno e determinação de capacidade externa [7].

Ele satisfaz todos os requisitos do Appraisal Requirements for CMMI (ARC) para o método de avaliação Classe A. O Documento de Definição do Método Classe A SCAMPI v1.2 descreve os requisitos, atividades e práticas associadas com cada processo que compõe o método. A Tabela 1 apresenta a sua Metodologia, dividida em três fases, cada fase com seus respectivos processos

Análise das Dependências entre Práticas Específicas

O levantamento das dependências iniciou-se pelas análises dos produtos típicos de trabalho das práticas específicas, buscando verificar se al-guma dependência entre eles era encontrada. Pela verificação constataram-se dependências entre os produtos típicos de trabalho de práticas de uma mesma área de processo e, consequentemente, a dependência entre as práticas que as possuem.

A Tabela 2 apresenta a análise realizada para as práticas específicas da área de processo Garantia da Qualidade do Produto e do Processo. Todas as sete áreas de processo também foram verificadas de forma semelhante. A análise foi realizada comparando os produtos típicos de trabalho de uma prática com as outras, dentro da mesma área de processo. Assim, determinaram-se as depen-dências existentes. A coluna Prática Analisada apresenta as práticas que serão analisadas em busca de dependências. Se houver dependências, a coluna Dependências apresenta a prática da qual se depende. A coluna Produtos Típicos de

Trabalho Analisados apresenta os produtos típicos de trabalho das prá-ticas analisadas em busca de dependências. Se houver dependências, a coluna Dependências apresenta o produto típico de trabalho que se depende. É importante ressaltar que essa análise foi feita com base em estudos no CMMI, sendo que diferentes analistas poderiam sugerir novas dependências ou discordar de algumas propostas.

A Figura 1 apresenta um gráfico com a relação de dependência entre as prá-ticas específicas nas sete áreas de processo para o nível 2 de maturidade.

Fase Processo

A: Planejar e preparar para avaliação A.1 Análise de requisitos

A.2 Desenvolvimento do plano de avaliação

A.3 Selecionar e preparar a equipe

A.4 Obter e fazer inventário das evidências

A.5 Preparar para conduzir a avaliação

B: Conduzir a avaliação B.1 Preparar os participantes

B.2 Examinar as evidências objetivas

B.3 Documentar as evidências objetivas

B.4 Verificar as evidências objetivas

B.5 Validar os encontros preliminares

B.6 Gerar os resultados da avaliação

C: Relatar resultados C.1 Entrar os resultados da avaliação

C.2 Pacotes e recursos de avaliação arquivados

tabela 1. Metodologia do SCAMPI A


Objetivo Específico: SG2 Prover Introspecção Objetiva

Prática analisada Dependências Produtos Típicos de Trabalho Analisado Dependências

SP1.1 Comunicar e assegurar resolução

de questões de não conformidade

SP1.1 Objetivamente avaliar processos PTT1. Relatório de ação corretiva (SP1.1) PTT3. Ações corretivas

(SP1.2) PTT3. Ações corretivas

SP1.2 Objetivamente avaliar produtos de trabalho e

serviços PTT2. Relatório de avaliação Não há dependências

PTT3. Tendências de Qualidade Não há dependências

SP2.2 Estabelecer registros SP2.1 Comunicar e assegurar resolução de questões de

não conformidade

PTT1. Registros de avaliação (SP2.1) PTT2. Relatório de avaliação

PTT3. Relatório de status de ações corretivas (SP2.1) PTT1. Relatório de ações corretivas

PTT4. Relatórios de tendências de qualidade (SP2.1) PTT3. Tendências de qualidade

PTT2. Relatórios de garantia da qualidade Não há dependências

tabela 2. Dependências entre Práticas Específicas – Garantia da Qualidade do Produto e do Processo

Figura 1. Relação de Dependência entre práticas específicas em áreas de processo para o nível 2 de maturidade

De acordo com a Figura 1, a quantidade de relações de dependências entre práticas é bem significante para todas as áreas de processo. Para a área de processo Planejamento do Projeto, por exemplo, há 14 práticas específicas e pela análise de dependências entre práticas, 24 relações de dependências foram encontradas. É de extrema importância a identificação dessas relações em uma auto-avaliação.

O gráfico apresenta dois conceitos de classificação de dependência: dependência fraca e forte. Uma dependência forte ocorre se a prática específica dependente ficar muito prejudicada (inviável ou quase inviável de se realizar) quan-do a prática específica da qual ela depende estiver ausente ou com classificação ruim. Uma dependência fraca ocorre se a prática específica dependente ficar pouco prejudicada, mesmo quando a prática específica da qual ela depende estiver ausente ou com avaliação ruim.

Como exemplo de análise, verificando as informações do gráfico, a área de processo Gerência de Requisitos possui duas relações de dependências fracas e cinco relações de dependências fortes. As relações de dependências fortes foram:• SP1.2 Obter Compromisso com os Requisitos depende fortemente de SP1.1 Obter uma Compreensão dos Requisitos, pois para se ter compromissos documentados dos requisitos deve-se ter um conjunto de requisitos acordados;• SP1.3 Gerenciar Mudanças de Requisitos depende forte-mente de SP1.1 Obter uma Compreensão dos Requisitos, pois para se ter uma base de dados dos requisitos deve-se ter requisitos acordados;

• SP1.4 Manter Rastreabilidade Bidirecional de Requisitos de-pende fortemente de SP1.3 Gerenciar Mudanças de Requisitos, pois para se ter uma matriz de rastreabilidade de requisitos deve-se ter a base de dados dos requisitos;• SP1.5 Identificar Inconsistências entre trabalho de projeto e requisitos depende fortemente de SP1.3 Gerenciar Mudanças de Requisitos, pois para se identificar inconsistências entre trabalho de projeto e requisitos deve-se ter a base de dados dos requisitos;• SP1.5 Identificar Inconsistências entre trabalho de projeto e requisitos depende fortemente de SP1.4 Manter Rastreabilidade Bidirecional de Requisitos, pois para se identificar inconsistên-cias entre trabalho de projeto e requisitos (tomar ações correti-vas) deve-se ter uma matriz de rastreabilidade.

As relações de dependências fracas encontradas foram:• SP1.3 Gerenciar Mudanças de Requisitos depende fracamente de SP1.2 Obter Compromisso com os Requisitos, pois para se ter uma base de dados dos requisitos é ideal ter compromissos com os requisitos documentados;• SP1.4 Manter Rastreabilidade Bidirecional de Requisitos depende fracamente de SP1.1 Obter uma Compreensão dos Requisitos, pois para se ter uma matriz de rastreabilidade de requisitos é ideal ter um conjunto de requisitos acordados.

Pelo estudo das dependências entre as práticas, observou-se que:• A classificação de uma prática que possui dependente(s) influenciará diretamente na classificação da(s) prática(s) dependente(s);• Na relação de dependência, a classificação de uma prática de-pendente deve ser igual ou inferior à classificação da(s) prática(s) da qual se depende;• Na relação de dependência de práticas específicas, a ausência ou ponto fraco encontrado em evidência(s) objetiva(s) de uma prática, que possui dependente(s), fará com que a prática de-pendente também possua uma ausência, ou ponto fraco na(s) evidência(s) objetiva(s).

Através das verificações das dependências entre práticas e das observações encontradas durante o estudo comparativo,


PRoCESSo

foi possível a criação de regras que pudessem ser incluídas no método de auto-avaliação MAPSw que estava sendo proposto, tornando assim o método mais confiável. A próxima seção apresenta o método de auto-avaliação com suas três fases e a inclusão na Fase III do método, a descrição de como proceder com a verificação para consistências entre práticas (análise de dependência).

MAPSw: Método de Auto-Avaliação de Processos de Software

Para a construção do MAPSw (ver Nota 1), foi realizado um estudo amplo para identificar possíveis dependências entre as práticas específicas em uma mesma área de processo e analisadas as sete áreas de processo do nível 2 de maturidade do CMMI.

O MAPSw é um método de auto-avaliação de processos de software, especificamente para avaliação do nível 2 de maturidade de processos, conforme o modelo CMMI. O método de auto-avaliação tem o suporte de uma ferra-menta, em fase de protótipo, desenvolvida em Java, com o IDE NetBeans 5.0 e o SGBD Firebird 2.0, visando facilitar e direcionar a auto-avaliação de processos de software. As relações de dependências entre práticas específicas apre-sentadas anteriormente foram incluídas no método MAPSw e no protótipo.

O método de avaliação SCAMPI A foi determinado como base para a construção do MAPSw, pois é um método que satisfaz todos os requisitos da classe A do ARC, e utilizado para prover pontuações. Os objetivos do MAPSw são:• Ser utilizado por pequenas organizações ou pequenas equipes de desenvolvimento para uma auto-avaliação de seus processos de software;• Ajudar organizações a identificar o estado atual de seus processos;• Servir como plano de melhoria de processo de desenvol-vimento de software;• Apresentar baixo custo para a organização usuária;• Ser confiável e simples;• Permitir tempo flexível de aplicação (a organização deter-minará o tempo das atividades da avaliação);• Não influenciar no fluxo das atividades diárias da organi-zação (a organização não receberá avaliadores externos);• Servir como base para próximas avaliações (certificações oficiais).

O MAPSw apresenta três fases, conforme a Tabela 3.Para a Fase I, a avaliação deve ser preparada buscando

definir os objetivos e o escopo organizacional, isto é, definir o(s) projeto(s) que efetivamente represente(m) a utilização do processo da organização ou equipe de desenvolvimento avaliada. A equipe deve ser preparada determinando o co-ordenador da avaliação (membro com maior conhecimento sobre o escopo da organização e CMMI) e os membros da equipe (pessoas motivadas, responsáveis e com conheci-mento dos projetos da organização).

Para a Fase II, a avaliação deve ser conduzida pelo coorde-nador e demais membros da equipe que utilizam o protótipo da ferramenta MAPSw e classificam as evidências objetivas encontradas em:• Artefato direto: resultados diretos da implementação da prática. Exemplos: Plano de Projeto, Medidas de Performance de Projeto, etc.;• Artefato indireto: indicativo da execução da prática. Exem-plos: Ata de Reuniões, Revisões, Relatórios, etc.;• Afirmação: provas escritas ou orais confirmando ou su-portando a implementação da prática. Exemplos: Entrevistas, Questionários, etc.; • Não possui Evidência: quando nenhum artefato, afirmação ou qualquer tipo de evidência sobre a implementação da prática for encontrado;• Ponto Fraco Encontrado: quando existe artefato ou afirmação que apresenta alguma fraqueza.

Fase I – Preparar para Avaliação

A. Preparar Avaliação

A.1 Definir os Objetivos da Avaliação

A.2. Determinar o Escopo Organizacional da Avaliação

A.3. Preparar Equipe de Avaliação

A.3.1. Identificar o Coordenador da Avaliação

A.3.2. Selecionar os Membros da Equipe de Avaliação

A.3.3. Orientar a Equipe de Avaliação

A.4. Obter Evidências Objetivas

A.5. Validar Evidências Objetivas

Fase II – Avaliação

B. Conduzir Avaliação

B.1. Classificar as Evidências Objetivas

B.2. Realizar Processo de Classificação

B.2.1. Classificar as Práticas Específicas e Genéricas

B.2.2. Classificar Metas Específicas e Genéricas

B.2.3. Classificar Áreas de Processo

B.2.4. Classificar Nível de Maturidade

Fase III – Resultados

C. Relatar Resultados

C.1. Verificar consistência entre as práticas (análise de dependências)

C.2. Entregar Descobertas Finais

C.3. Planejar Próximos Passos

tabela 3. Fases e Procedimentos do MAPSw

A classificação das metas específicas e genéricas são realiza-das automaticamente utilizando as seguintes regras:• Não Pontuada: se há práticas associadas à meta especí-fica ou genérica que foram classificadas como Ainda Não Implementada;

N o t a d o D e v M a n 1

MAPSw – Método de Auto-Avaliação de Processos de Software baseado no CMMI-DEV, ARC e SCAMPI A, e que dá suporte a análise de dependências entre práticas.


• Satisfeita: se todas as práticas associadas à meta específica ou genérica foram classificadas como Largamente Implementada ou Completamente Implementada;• Não Satisfeita: qualquer outra classificação que não seja Não Pontuada ou Satisfeita.

Com a classificação das metas específicas e genéricas, determina-se a classificação das Áreas de Processo de acordo com as seguintes regras:• Satisfeita: se, e somente se, todas as metas genéricas e espe-cíficas são classificadas como Satisfeita;• Não Satisfeita: uma ou mais metas são classificadas como Não Satisfeita;• Não Aplicável: quando a área de processo for considerada fora do escopo de trabalho da unidade organizacional;• Não Classificada: se uma das metas for classificada como Não Pontuada, e nenhuma das metas foi classificada como Não Satisfeita.

O nível de maturidade é determinado pela classificação das áreas de processo. A organização avaliada contempla o nível 2 de maturidade se todas as sete áreas de processo forem classificadas como Satisfeita ou Não Aplicável.

Para a Fase III, o objetivo é verificar as dependências entre as práticas específicas, emitir diagnóstico final da avaliação e dar condições para que a equipe de avaliação planeje suas ações futuras. A verificação de dependências entre práticas, apresentada anteriormente, foi incluída no MAPSw e na ferra-menta de suporte, sendo um diferencial importante em relação às demais ferramentas existentes. A verificação de consistência entre práticas deve ser realizada pelas seguintes análises:• Analisar as classificações das práticas específicas que possuem dependentes e a classificação das práticas dependentes;• A classificação de uma prática dependente deve ser igual ou inferior à classificação da prática da qual se depende;• Caso a classificação de uma prática dependente seja superior à classificação da prática da qual se depende, deve-se reavaliar a classificação da prática dependente.

ConclusãoCom a verificação de dependências entre práticas especí-

ficas em áreas de processo do nível 2 de maturidade CMMI e a elaboração do método de auto-avaliação de processos de software, uma nova contribuição para a área de Qualidade de Software e Melhoria de Processos de Software pôde ser agregada. Com a verificação das dependências entre práticas,

IDE NetBeanshttp:// netbeans.org/

Software Engineering Institute – CMMIhttp:// http://www.sei.cmu.edu/cmmi/

Links

1. CMMI Product Team.: CMMI for Development, Version 1.2, Carnegie Mellon University. http://

www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf, (2006)

2. Côrtes, M. L. e Chiossi, T. C. S.: Modelos de Qualidade de Software, Editora Unicamp, (2001)

3. Guerrero, F. and Eterovic, Y.: Adopting the SW-CMM in a Small IT Organization, IEEE

Software, (2004)

4. MPS-Br.: Melhoria do Processo de Software Brasileiro, Notas de Apresentação do “Workshop

do Projeto melhoria de processo do software Brasileiro (mps BR)”, Campinas, (2004)

5. Paulk, M.C., Curtis, B., Chrissis, M.B., Weber., C.W.: Capability Maturity ModelSM for Software,

Version 1.1, Carnegie Mellon University. http://www.sei.cmu.edu/pub/documents/93.reports/

pdf/tr24.93.pdf, (1993)

6. Scampi Upgrade Team.: Appraisal Requirements for CMMI, Version 1.2, Carnegie Mellon

University, (2006a)

7. Scampi Upgrade Team.: Standard CMMI Appraisal Method for Process Improvement (SCAMPI)

A, Version 1.2: Method Definition Document, Carnegie Mellon University, (2006b)

Referências Bibliográficas

a auto-avaliação se torna mais “segura”, pois as classificações das práticas passam para uma análise de consistência, isto é, são submetidas à análise de dependências. Eventuais falhas nas classificações das práticas, principalmente entre práticas dependentes e das quais se depende, podem ser verificadas com o auxílio do MAPSw e da ferramenta de apoio, garantindo assim as classificações das metas e áreas de processo.

Futuras verificações de dependências devem ser realizadas para verificar a dependência entre práticas de áreas de processos diferentes, dentro de um mesmo nível, bem como a análise de dependência para níveis superiores (3, 4 e 5) do CMMI.




Dê

seu Feedback

sob

re esta edição


Tadeu Moreira de Classe [email protected]

Graduando no Curso Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora. Técnico em Informática Industrial pelo Colégio Técnico Universitário (CTU/UFJF). Programador Pleno da empresa de softwares jurídicos Novaprolink de Juiz de Fora/MG.

Guilherme de Jorge Palmeira [email protected]

Graduando no curso de Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora. Atu-almente estagiando como programador de JSF na empresa INFOBICAS.

Daves Marcio Silva Martins [email protected]

É desenvolvedor Java desde 2000, com ampla experiência em aplicações Win32, Web e Celu-lar. Graduado em Informática pela UFJF, com Especialização em Banco de Dados pelo Centro de Ensino Superior de Juiz de Fora, Mestrado em Computação de Alto Desempenho pela UFRJ e Doutorando na UFJF. Atualmente é professor universitário em diversas instituições, em cusos de Sistemas de Informação, Analista de Sistema na UFJF, e atua como consultor, pesquisador e desenvolvedor de aplicações Java, sobretudo na plataforma J2EE para Web, e J2ME, sendo espe-cialista em aplicações Web.

Eduardo Leandro Pinto Dornelas [email protected]

Graduando em Sistemas de Informação pelo Centro de Ensino Superior de Juiz de Fora. Técnico de Informática pelo Colégio Técnico Pio XII. Atuou como analista de suporte pela COCA-COLA FEMSA MG. Atualmente é Analista Field Services pela HP Enterprise Services.

De que se trata o artigo?Apresenta a integração do sistema de controle de mudanças Trac e com o sistema de controle de versão Subversion (SVN).

Para que serve?Exemplificar ao leitor como é feita a integração do Trac com o SVN, mostrando os passos para essa configuração.

Em que situação o tema é útil?Durante o processo de desenvolvimento de um projeto, no qual há necessidade de controlar suas etapas, mudanças e sugestões, obtendo um deta-lhamento completo de suas versões.

Integração das ferramentas Trac e SubversionTrabalhe na prática com um sistema de controle de mudanças integrado a um de controle de versão

Controlar mudanças em projetos como inserções, alterações de código fonte e exclusões de do-

cumentos, é uma tarefa difícil devido ao grande volume de informação e comple-xidade de softwares que o mercado vem exigindo às empresas.

Muitas soluções para essas dificulda-des foram desenvolvidas ao longo dos anos, como o CVS (Concurrent Version System - Sistemas de Versões Concorren-tes) o qual permite o versionamento de projetos. Esses projetos, então armaze-nados em servidores, são utilizados por clientes que se conectam e copiam todo o conteúdo para as suas máquinas a fim de realizarem alterações ou melhorias.

Tudo evolui e com o CVS não foi di-ferente. Este abriu espaço para o SVN (Subversion), que trabalha da mesma forma que o anterior, porém, com diver-sas correções e melhorias.

Com a evolução tecnológica, existe também a necessidade de controlar as mudanças ocorridas durante o desen-volvimento de um projeto. Para essa gerência de mudanças existem diversas ferramentas como Mantis, Bugzilla, Trac (foco deste artigo), dentre outros. Esses

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software

42 Engenharia de Software Magazine - Integração das ferramentas Trac e Subversion

softwares permitem a criação e o gerenciamento de tarefas que podem ser correção de defeitos, implementação de melhorias, e/ou implementação de novas funcionalidades.

Assim, esses sistemas permitem um registro da evolução do projeto bem como permitem um controle de mudanças ocor-ridas ao longo das versões do sistema. É importante atentar para o fato de que estes programas tendem a se tornar ainda mais úteis quando conseguem ser integrados aos sistemas de controle de versão, pois assim, há o controle das versões, alterações e melhorias de todo o projeto.

Softwares de controle de mudança de projetos ajudam na melhoria da qualidade do produto por permitirem manter um registro de toda mudança ocorrida, acompanhando a evolução do projeto e documentando o que é realizado através da participação da equipe de desenvolvimento. Neste sentido, este artigo apresenta a integração do sistema de controle de mudanças Trac e com o sistema de controle de versão Subver-sion (SVN).

O Subversion (SVN)O Subversion é um sistema de controle de versão de código

aberto que surgiu para competir com o CVS, mantendo a metodologia existente, porém corrigindo erros e falhas. O sistema faz a gerência de arquivos e diretórios, juntamente com as modificações realizadas, permitindo que um usuário recupere versões antigas de dados ou apenas visualize e se informe a partir de um histórico de atualizações.

O sistema é utilizado em rede, fazendo com que diversos clientes copiem toda a estrutura de diretório que se encontra em um repositório de dados no servidor. Qualquer usuário que tenha permissão pode ler ou gravar dados do repositório (Figura 1). Porém, diferente dos servidores de arquivos co-muns, o SVN se lembra das alterações realizadas permitindo assim o versionamento do projeto.

Figura 1. Sistema cliente/servidor

Com o uso do Subversion, os usuários podem trabalhar ao mesmo tempo em arquivos iguais salvando suas alterações. Em sistemas onde não há um repositório para os dados, não é possível duas ou mais pessoas trabalharem ao mesmo tempo no mesmo arquivo e gravarem o seu trabalho, pois isso pode

ocasionar perdas de informações ou até mesmo corromper o documento.

Utilizando o SVN, pelo fato de existir um repositório para os dados e existirem cópias dele em cada máquina cliente, as alterações simultâneas em arquivos se torna possível. Ao final de cada alteração o usuário pode “subir” o documento de volta ao repositório pela operação de commit do sistema, o qual permite fazer o merge, a união dos dados alterados para dentro do documento no servidor, como podemos ver esquematizado na Figura 2.

Figura 2. Esquema Lógico de um Sistema de Controle de Versão

Assim não haverá perda alguma de dados desde que o pro-cedimento de união dos documentos seja feito de maneira correta. Será gerada então uma nova versão do repositório o qual poderá ser novamente copiada, ou melhor, atualizada para as máquinas clientes através do comando update do SVN.

Tortoise SVNO TortoiseSVN é uma ferramenta livre e de código fonte

aberto com a função de ser um cliente para o sistema de con-trole de versão Subversion. Isto é, ele monitora em tempo real um repositório de dados local verificando se existe alguma coisa alterada, diferente do repositório de dados encontrado no servidor, marcando com diferentes ícones as modificações encontradas dentro da pasta.

Ele conta com uma série de funcionalidades além de uma interface gráfica integrada com o Windows provendo as fun-ções do sistema de controle de versão como se fossem menus do Explorer, conforme mostra a Figura 3.

O cliente também possui a sobreposição de ícones, onde cada arquivo ou diretório é marcado com um pequeno ícone que permite rapidamente saber a situação de cada um em relação


DESENvoLvIMENto

ao repositório de dados, conforme exibido na Figura 4. Além disso, possui todos os comandos do Subversion dentro de seus próprios menus, podendo ser exibidos relatórios para o controle de versões, janelas de autenticação de usuário, telas de atualizações, submissões e uniões de código, enfim, utilidades para o controle de versão.

Figura 3. TortoiseSVN integrado com o Explorer do Windows

Figura 4. Ícones do TortoiseSVN

O TracO Trac é uma ferramenta open source que roda em ambiente

Web, escrito em Python, sob a licença GPL, para rastreamento de mudanças em projetos de desenvolvimento de software, o qual visa facilitar algumas atividades corriqueiras na Gerência de Configuração de Software.

O projeto Trac teve início em 2003, inspirado no CVSTrac, o mesmo desenvolvido e mantido pela empresa Edgewall Software e por colaboradores da comunidade open source. Da mesma forma que o Subversion, a ferramenta vem conquistando

popularidade e é usada em diversas empresas para gerenciar di-ferentes projetos. O objetivo do controle de mudanças é registrar o porquê das alterações ocorreram no projeto. No Trac, a central do controle de mudanças é o ticket e os seguintes serviços são oferecidos: Controle de Mudanças; Wiki para documentação colaborativa e referência cruzada; Integração com o Subversion; Acompanhamento da evolução do projeto; Linha do tempo e diversas outras funcionalidades que visam facilitar o controle de mudanças de um projeto.

O ticket é usado para registrar defeitos, pedidos de melhoria e tarefas de projeto, ou seja, relatórios de bugs, requisição de carac-terísticas e suporte de publicação do software e tarefas do projeto, sendo possível obter diversas informações sobre o andamento e evolução do mesmo. Todos os tickets podem ser editados, anota-dos, associados, priorizados e discutidos a qualquer momento.

No projeto Trac, utiliza-se os comentários do ticket para discutir publicações e tarefas. Isso permite entender mais facilmente a motivação por trás de um design ou a escolha da implementação.

Integração do Trac com o SubversionPara que seja feita a integração, parte-se do princípio que

já exista o SVN e o TortoiseSVN instalados, um repositório criado e o Trac configurado para acessar esta mesma base de dados. No caso deste exemplo, o repositório será o MyProject. Vamos agora passo a passo entender como esta integração pode ser realizada:

1. Inicia-se criando os dois usuários no VisualSVN mostrados na Figura 5, o admin e o user, os quais respectivamente serão administrador do Trac e um usuário normal, com as senhas admin e user;

Figura 5. Usuários do VisualSVN

2. Em seguida deve-se configurar para que o usuário admin seja o administrador do sistema Trac, onde poderá realizar as configurações para que o TortoiseSVN consiga enxergar os ti-ckets. Dentro do prompt de comando do Windows deve-se digitar as linhas de comandos mostradas na Listagem 1. Os detalhes de cada um destes comandos estão explicados na Tabela 1.

3. No browser, deve-se digitar o endereço: http://localhost/trac/MyProject. Será exigido o usuário e senha. Entrando com o usuário user e o usuário admin, pode-se perceber a diferença entre os menus do programa para o usuário administrador e para o usuário comum (Figura 6).


4. Agora entre no Trac como administrador do sistema. Para isso, deve-se entrar na aba “Admin” para acessar as configu-rações de administradores do programa. Ao lado esquerdo da tela, pode ser visto um outro menu chamado Administration. Clicando na opção Plugins, será mostrada uma tela com todos os plugins instalados no sistema. Para que se consiga fazer uma integração com o Tortoise, deve-se baixar e instalar (opção install plugin) a extensão Trac XML-RPC Plugin, o qual fará com que os servidores Trac consigam ser vistos pelos programas clientes SVN.

5. Deve-se baixar também um programa de auxílio ao Trac chamado TracExplorer, o qual permite a visualização extena dos servidores Trac, dentro dos clientes SVN. Sua instalação é simples. Depois de feito o download do pacote, é so executar a instalação e avançar até o final.

6. Com o Trac configurado, pode-se configurar o Tortoise para as conexões. Em alguma pasta do projeto que esteja versiona-do com o repositório MyProject, clica-se com o botão direito e seleciona-se a opção Settings no Tortoise, onde será exibida a tela de configuração do cliente. Navega-se até a opção Issue Tracker Integration e depois clica-se no botão “Add...”.

Será apresentada uma tela onde deve ser informado o di-retório local de projeto (Working Copy Path) e Parâmetros de configuração do Trac (Parameters), clicando na opção Options para configurá-los. Na tela que surgir, seleciona-se a opção Add New Trac Server para cadastrar o local onde está o sistema de controle de mudanças (Figura 7), onde devem ser informados o endereço do servidor, o usuário e a senha, através da seleção da opção Basic Autentication. Avançando, será configurado o servidor do Trac para aquela cópia do repositório.

Listagem 1. Criação do usuário adminitrador do Trac.

cd\“C:\PythonServer\trac\python\python.exe” “C:\PythonServer\trac\python\scripts\trac-admin-script.py” “C:\Trac\MyProject” permission add jaum TRAC_ADMIN

Código Explicação Caso geral

cd\ Diretório principal cd\

“C:\PythonServer\trac\

python\python.exe”

Vai para o diretório do executável do Python “C:\<diretorio_python>\python.exe”

“C:\PythonServer\trac\

python\scripts\

trac-admin-script.py”

Vai para a pasta scripts do python, associnado o aquivo trac-admin “C:\<diretorio_python>\scripts\

trac-admin-script.py”

“C:\Trac\MyProject” Diretório do Trac “C:\Trac\<repositorio>”

permission add jaum TRAC_ADMIN Permissão de administrador ao usuário permission add <nome_usuario_svn> TRAC_ADMIN

tabela 1. Codificação dos códigos de criação do usuário administrador do Trac

Figura 6. Menu de administrador e menu de usuário no Trac

Configurado o servidor, dentro da árvore de tickets, entra-se em Active tickets e depois em Next, onde será exibida a tela mostrada na Figura 8. Clicando-se em Select all e depois em Finish, será dada permissão para que possam ser realizadas as operações selecionadas do Trac de dentro do Tortoise.

7. Com o Tortoise configurado para aquela cópia do repo-sitório, só falta configurar as opções de comitt para aquela pasta. Novamente clica-se com o botão direito no diretório local do projeto e em propriedades. Dentro dela procura-se a aba Subversion e depois o botão “Properties...”. Assim aparecerá a tela de configuração do Subversion, onde se pode adicionar as propriedades descritas na Tabela 2, se-lecionando o botão New...

8. A configuração do Tortoise com o Trac está completa, agora é preciso configurar o arquivo post-commit que fica dentro da pasta do repositório de dados. Para isso, deve-se copiar os arquivos trac-post-commit-hook e trac-post-commit-hook.cmd que ficam no diretório de instalação do Trac para a pasta de script

Figura 7. Configuração do Trac dentro do TortoiseSVN


DESENvoLvIMENto

Figura 8. Configuração de Tickets para o Trac no Tortoise

Propriedade Valor

bugtraq:append True

bugtraq:label Tícket Nº:

bugtraq:logregex ([Cc]lose[sd]?|[Ff]ix(e?[ds])?|[Rr]e(fs)?|[Rr]e(ferences)?|

[Aa]ddresses|[Ss]ee)\s(#|ticket:)(\d+)(((,\s)|(\s&\s)|(\sand\s))(#|ticket:)(\d+))*

(\d+)

bugtraq:message Ticket: %BUGID%

bugtraq:url http://localhost/trac/MyProject/ticket/%BUGID%

bugtraq:warnifnoissue True

webviewer:pathrevision http://localhost/trac/MyProjectr/browser/%PATH%?rev=%REVISION%

webviewer:revision http://localhost/trac/MyProject/changeset/%REVISION%

tabela 2. Propriedades do diretório de trabalho no TortoiseSVN

do diretório que fica o executável do Python. Na pasta hooks do repositório MyProject, deve-se trocar a extensão do arquivo post-commit para post-commit.bat. Então, deve-se apagar todo o conteúdo que se encontra dentro do arquivo e digitar o que está descrito na Listagem 2. Deve-se trocar os caminhos do comando de acordo com a necessidade e diretórios de insta-lação do Python.

Listagem 2. Post-commit.bat.

cd \cd C:\PythonServer\trac\python\ScriptsC:\PythonServer\trac\python\python.exe trac-post-commit-hook -p “C:\trac\MyProject” -r %2

9. Seguindo esses passos, o Trac, o Subversion e o Tortoise estão configurados e prontos para o uso.

Para exemplificar essa integração com o Trac, será aberto um novo ticket no sistema como se fosse uma correção de bug (Figura 9). Na abertura do ticket é informado o título e a descrição do problema, versão do sofware, responsável, e outras informações importantes.

Figura 9. Criação de tickets do Trac

Suponhamos que o erro esteja corrigido, então pode-se realizar o commit para o repositório SVN para versionar o código fonte do projeto. Ao clicar na opção SVN Commit... do Tortoise, o usuário encontra uma tela diferente da padrão do cliente. Nessa tela se encontra o botão Choose tickets, onde será exibida o TracExplorer (Figura 10), no qual é possível selecio-nar qual o ticket que aquela correção será responsável, e que tipo de operação foi resolvida. A correção é então realizada no repositório e foi gerada uma nova revisão do projeto.

Figura 10. Commit do Tortoise e o TracExplorer mostrando as operações do ticket

Novamente no Trac, no menu Time Line (uma linha do tempo com tudo que foi realizado no repositório), pode-se ver as operações que acabaram de ser realizadas ou um histórico de tudo que já aconteceu. Seleciona-se o registo de ticket mais atual e, após o carregamento da tela, vê-se o status do mesmo juntamente com seu histório de atualização (Figura 11).

Figura 11. Ticket fechado e histório de alterações

ConclusãoEste artigo apresentou a como integrar um sistema de con-

trole de mudança (Trac) com o Subversion e seu cliente, o TortoiseSNV.

Com o uso de interações entres esses softwares, um projeto poderá ser melhor controlado. Isto poderá trazer economia de tempo, e delegações de responsabilidade, onde qualquer alteração feita em um projeto por determinado usuário é salva nas alterações dos tickets abertos do Trac.

Projeto Trachttp://trac.edgewall.org/

Subverionhttp://subversion.tigris.org/

VisualSVNhttp://www.visualsvn.com/server/download/

VisualSVN e Trachttp://www.visualsvn.com/server/trac/

TortoiseSVNhttp://tortoisesvn.tigris.org/

TracExplorerhttp://sourceforge.net/apps/trac/vstrac/wiki

Trac XMP-RPChttp://code.google.com/p/cubeon/downloads/detail?name=TracXMLRPC-1.5.0-py2.5.egg

Links

SUSSMAN, Ben Collins Brian W. Fitzpatrick, C. Michael Pilato. Controle de Versão com Subversion. California - EUA: Creative Commons, 2007.

KÜNG , Stefan, Lübbe Onken, e Simon Large. TortoiseSVN: Um aplicativo do Subversion para Windows. 2010.

Referências


A Engenharia de Software Magazine tem que ser feita ao seu gosto.Para isso, precisamos saber o que você, leitor, acha da revista!Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback

Dê

seu Feedback

sob

re esta edição


DESENvoLvIMENto

engenharia de software - edição 26

Documents