Análise Comparativa da Aderência de Ferramentas de Apoio

à Implementação do Nível de Maturidade E do MPS.BR

Cristiane Butura

Instituto de Ciências Exatas e Geociências – Universidade de Passo Fundo (UPF)

Caixa Postal 611– 99052-900 – Passo Fundo – RS – Brasil

109175@upf.br

Resumo. Este artigo apresenta o modelo MPS.BR, o Nível F pertencente ao

modelo, juntamente com os processos e resultados esperados que fazem parte

do nível citado. Também são descritas ferramentas utilizadas e a metodologia

proposta. Após é exposta a análise de aderência realizada das ferramentas em

relação aos resultados esperados de cada processo do nível em questão. Ao

final, é possível verificar, que as ferramentas avaliadas podem auxiliar na

implementação, de forma automatizada, do Nível F.

Palavras-Chave. MPS.BR, Ferramentas, Análise Comparativa

Abstract. This article presents the MPS.BR model, the level F belonging to this

model, along with the processes and the expected results that are part of the

mentioned level. Are also described the tools used and the proposed

methodology. After that, the adherence analysis performed in the tools in

relation with the expected results of each process from the level in question is

exposed. At the end, is possible to check, that the tools evaluated may assist in

the implementation, in an automatized way, on level F.

Keywords. MPS.BR, Tools, Comparative Analysis

1. Introdução

A qualidade do software oferecido é fator determinante para garantir a competitividade

de uma organização nesse mercado, onde buscam-se soluções ágeis e confiáveis . Do

mesmo modo, existe uma constante busca por softwares cada vez mais baratos e de

maior qualidade.

No entanto, o número de empresas que produzem software sem levar em conta

sua qualidade e reais necessidades é bastante elevado. Essa problemática é oriunda da

falta de um plano sistemático para realização de tarefas, definição de objetivos, prazos e

custos.

À vista disso, a implantação de um modelo de maturidade de processos é

fundamental, uma vez que busca meios para melhorar os processos de produção de

software e suprir as exigências do cliente final. Assim sendo, o Modelo de Melhoria de

Processo de Software Brasileiro, MPS.BR, surge como um framework de apoio ao

aperfeiçoamento das práticas existentes em uma organização desenvolvedora de

software, objetivando estar de acordo com padrões de qualidade. Do mesmo modo, o

uso de ferramentas surge como alternativa para apoiar a implementação sistematizada

dos processos do MPS.BR.

Logo, o presente trabalho tem como objetivo apresentar o Nível F do MPS.BR e

realizar um estudo comparativo de aderência entre ferramentas de software livre que

apoiem a implementação desse nível de forma sistematizada e ágil com o apoio

ferramental.

Baseando-se no trabalho correlato de Yoshidome e Souza (2009), encontra-se a

realização de uma análise de aderência de ferramentas de software livre para apoiar a

implementação do processo de Gerência de Configuração. Do mesmo modo, em

Rodrigues (2009) é apresentada uma análise dos resultados esperados para o processo de

Gerência de Portfólio de Projetos e também exposto o mapeamento entre as

características das ferramentas escolhidas e os resultados esperados.

Ainda, em Carneiro e Oliveira (2011), pode-se verificar uma proposta de

implementação sistematizada do processo de Medição utilizando a ferramenta Spider-

Mplan e posterior análise de aderência dessa ferramenta ao processo em questão.

Igualmente em Rodrigo (2011) é proposto o uso de ferramentas de software livre para

auxiliar na implementação do processo de Garantia de Qualidade.

Assim, este trabalho está organizado de forma, que além da presente introdução,

no Capítulo 2 são apresentados conceitos sobre o MPS.BR, especificando sua estrutura e

apresentado o Nível F com seus processos e resultados esperados. No Capítulo 3 são

descritas as ferramentas utilizadas, elencando suas principais características. Em

seguida, no Capítulo 4 é exposta a metodologia utilizada para a análise das ferramentas.

Posteriormente, o Capítulo 5 apresenta os resultados das análises realizadas para cada

ferramenta em relação aos processos do nível em questão, e por fim, é apresentada a

conclusão do trabalho.

2. MPS.BR - Melhoria de Processo de Software Brasileiro

A melhoria de processos requer o entendimento dos processos já existentes e as

mudanças necessárias para aumentar a qualidade do produto, diminuir os custos e o

tempo de desenvolvimento (SOMMERVILLE, 2011). Do mesmo modo, a estrutura de

um modelo de melhoria de processo modifica a forma existente para desenvolvimento

de software em algo mais focado, com melhor repetibilidade e torna mais confiável a

qualidade do produto e os prazos de entrega (PRESSMAN, 2011).

Dessa maneira, um modelo de qualidade destina-se a ser um framework de boas

práticas para auxiliar na melhoria de processos de uma organização. A melhoria de

processos é uma atividade de longo prazo, pois cada uma das fases do processo de

melhoria pode durar vários meses. Também é uma atividade contínua, pois quaisquer

novos processos introduzidos alteram o ambiente de negócios e terão de evoluir para

levar em conta essas mudanças (SOMMERVILLE, 2011).

A qualidade assegurada por um modelo de processo auxilia na decisão de

escolha por um produto ou serviço. Assim, nos deparamos com o modelo de Melhoria

de Processo de Software Brasileiro, o MPS.BR, o mesmo tem como base os conceitos

de maturidade e capacidade de processo no que diz respeito a avaliação e melhoria da

qualidade e produtividade, relacionadas a software e serviços correlatos. O modelo

MPS.BR atende diversos perfis de empresas, porém seu foco é voltado para as micro,

pequenas e médias empresas (SOFTEX, 2012).

2.1. Níveis de Maturidade do MPS.BR

O MPS.BR está estruturado de forma a viabilizar que as empresas possam realizar sua

implementação de modo progressivo até obter a qualidade de software requerida. O

modelo de maturidade é dividido em níveis: A (Em Otimização), B (Gerenciado

Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido),

F (Gerenciado) e G (Parcialmente Gerenciado). Cada nível possui um conjunto de

processos, que, por sua vez, mantém um grupo de resultados esperados. Tal estrutura

permite que a organização perceba onde deve ser concentrado o esforço de melhoria

(SOFTEX, 2012).

A evolução e obtenção de determinado nível de maturidade ocorrem à medida

que o propósito dos resultados esperados de cada processo e dos atributos de processos

definidos para aquele nível são atendidos (SOFTEX, 2012). O presente trabalho partirá

do pressuposto de que o Nível G já estará implementado. Por isso será feito apenas um

detalhamento do Nível F e seus resultados esperados, objeto de estudo do presente

trabalho.

2.2. Nível F - Gerenciado

O Nível F, também conhecido como “Gerenciado”, tem por objetivo principal o apoio à

gestão do projeto no que se refere aos processos que o compõem. O mesmo é

considerado uma extensão do Nível de Maturidade G, agregando os processos

específicos de Aquisição , Gerência de Configuração, Gerência de Portfólio de Projeto,

Garantia da Qualidade e Medição (SOFTEX, 2013a).

Os processos oferecem maior visibilidade de como os artefatos são produzidos e

se estes estão de acordo com os procedimentos estabelecidos. Nesse contexto, como

ocorre com o nível G, no nível F a organização não necessita fazer uso de padrões

específicos, sendo possível a utilização de padrões próprios para o projeto. Caso existam

processos definidos e esses precisarem ser adaptados, seja qual for a alteração, a mesma

deverá ser descrita no momento do planejamento do processo (SOFTEX, 2013a).

Os processos do Nível F podem ser implementados em qualquer ordem já que

são de apoio à gestão do projeto. A necessidade de processos de apoio pode requisitar a

definição de novos papéis para efetivar as atividades de cada um dos processos. Isso não

significa que será preciso contratar novos colaboradores, às vezes, basta apenas, realocar

funções estabelecendo as novas responsabilidades (SOFTEX, 2013a). A seguir serão

descritos cada um dos processos que compõem o Nível F.

2.2.1 Aquisição (AQU)

O Processo de Aquisição se caracteriza por gerenciar a aquisição de produtos e serviços

para que estes estejam de acordo com as necessidades do adquirente. Esse processo

engloba desde o planejamento da aquisição e escolha do fornecedor até a monitoração

do contrato, processos e produto. O principal objetivo é garantir a qualidade do artefato

em questão quando este for integrado ao produto final que será entregue ao cliente. O

Processo de Aquisição, além de proporcionar uma maior assertividade na escolha do

produto terceirizado, oferece maior segurança às negociações através do gerenciamento

dos contratos e pedidos (SOFTEX, 2013a).

Os resultados que compõem o processo de aquisição são os descritos a seguir:

AQU1 – As necessidades de aquisição, as metas, os critérios de aceitação do

produto, os tipos e a estratégia de aquisição são definidos;

AQU2 – Os critérios de seleção do fornecedor são estabelecidos e usados para

avaliar os potenciais fornecedores;

AQU3 – O fornecedor é selecionado com base na avaliação das propostas e dos

critérios estabelecidos;

AQU4 – Um acordo que expresse claramente as expectativas, responsabilidades

e obrigações de ambas as partes (cliente e fornecedor) é estabelecido e negociado entre

elas;

AQU5 – Um produto que satisfaça a necessidade expressa pelo cliente é

adquirido baseado na análise dos potenciais candidatos;

AQU6 – A aquisição é monitorada de forma que as condições especificadas

sejam atendidas, tais como custo, cronograma e qualidade, gerando ações corretivas

quando necessário;

AQU7 – O produto é entregue e avaliado em relação ao acordado e os resultados

são documentados;

AQU8 – O produto adquirido é incorporado ao projeto, caso pertinente.

2.2.2 Gerência de Configuração (GCO)

O objetivo do Processo Gerência de Configuração engloba a definição e manutenção de

todos os artefatos de trabalho de um processo ou projeto e sua disponibilização para os

envolvidos (SOFTEX, 2013a).

A gerência de configuração se caracteriza por englobar todo o esforço de

gerenciamento de alterações em um sistema de software, com intuito de gerenciar

diferentes versões, controlando e auditando as alterações realizadas (PRESSMAN,

2011).

Esse processo normalmente inicia na identificação das partes que compõem o

software. Estas são chamadas de itens de configuração e representam a junção de

hardware e software (SOFTEX, 2013a). A seguir são descritos os resultados esperados

para esse processo:

GCO1 - Um Sistema de Gerência de Configuração é estabelecido e mantido;

GCO2 - Os itens de configuração são identificados com base em critérios

estabelecidos;

GCO3 - Os itens de configuração sujeitos a um controle formal são

colocados sob baseline;

GCO4 - A situação dos itens de configuração e das baselines é registrada ao

longo do tempo e disponibilizada;

GCO5 - Modificações em itens de configuração são controladas;

GCO6 - O armazenamento, o manuseio e a liberação de itens de configuração e

baselines são controlados;

GCO7 - Auditorias de configuração são realizadas objetivamente para assegurar

que as baselines e os itens de configuração estejam íntegros, completos e consistentes.

2.2.3 Gerência de Portfólio de Projetos (GPP)

O Processo de Gerência de Portfólio de Projetos destina-se a gerenciar processos que

estão no escopo estratégico da organização. Tem por objetivo direcionar os

investimentos e recursos organizacionais pertinentes, bem como definir quem irá

executar os projetos escolhidos. Esse processo engloba atividades de gerenciamento de

um conjunto de projetos de uma organização, partindo da escolha dos projetos que serão

executados, e durante sua execução, analisando se os mesmos continuam viáveis e de

acordo com os critérios pelos quais foram selecionados, podendo descartar o projeto

caso fuja das perspectivas iniciais (SOFTEX, 2013a).

Os resultados esperados que compõem o Processo de Gerência de Portfólio de

Projetos são os apresentados a seguir:

GPP1 - As oportunidades de negócio, as necessidades e os investimentos são

identificados, qualificados, priorizados e selecionados em relação aos objetivos

estratégicos da organização por meio de critérios objetivos;

GPP2 - Os recursos e orçamentos para cada projeto são identificados e alocados;

GPP3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são

estabelecidas;

GPP4 - O portfólio é monitorado em relação aos critérios que foram utilizados

para a priorização;

GPP5 - Ações para corrigir desvios no portfólio e para prevenir a repetição dos

problemas identificados são estabelecidas, implementadas e acompanhadas até a sua

conclusão;

GPP6 - Os conflitos sobre recursos entre projetos são tratados e resolvidos, de

acordo com os critérios utilizados para a priorização;

GPP7 - Projetos que atendem aos acordos e requisitos que levaram à sua

aprovação são mantidos, e os que não atendem são redirecionados ou cancelados;

GPP8 - A situação do portfólio de projetos é comunicada para as partes

interessadas, com periodicidade definida ou quando o portfólio for alterado;

2.2.4 Garantia da Qualidade (GQA)

O propósito do Processo Garantia da Qualidade se caracteriza por assegurar a

conformidade dos produtos de trabalho e execução dos processos com o planejamento

pré-definido (SOFTEX, 2013a).

Desse modo, a gerência da qualidade é uma atividade essencial em organizações

de produtos a ser usados por terceiros. Um processo de garantia de qualidade é

composto por atividades particulares e controle de qualidade, onde é fundamental seguir

efetivamente a engenharia de software. Além de gerenciar todos os produtos de

software, incluindo suas alterações, garantir a concordância com o processo de

desenvolvimento de software seguido e, por fim, a utilizar de técnicas de medição

(PRESSMAN, 2011).

Os resultados esperados que compõem esse processo são destacados a seguir:

GQA1 - A aderência dos produtos de trabalho aos padrões, procedimentos e

requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues ao

cliente e em marcos predefinidos ao longo do ciclo de vida do projeto;

GQA2 - A aderência dos processos executados às descrições de processo,

padrões e procedimentos é avaliada objetivamente;

GQA3 - Os problemas e as não-conformidades são identificados, registrados e

comunicados;

GQA4 - Ações corretivas para as não-conformidades são estabelecidas e

acompanhadas até as suas efetivas conclusões. Quando necessário, o escalonamento das

ações corretivas para níveis superiores é realizado, de forma a garantir sua solução.

2.2.5 Medição (MED)

O Processo de Medição caracteriza-se por englobar tarefas de coleta, armazenamento,

análise e descrever informações sobre produtos e processos de uma organização, com

intuito de apoiar o os objetivos da organização (SOFTEX, 2013a).

A medição de processos representa dados quantitativos acerca do processo de

software, como por exemplo, o tempo necessário para realização de tarefas. Por sua vez,

a medição de software engloba a composição de um valor numérico ou perfil para um

artefato de software, sistema ou processo. As duas definições devem ser usadas em

conjunto, uma vez que as informações obtidas sobre o produto devem ser relacionadas

com os dados coletados acerca do processo (SOMMERVILLE, 2011).

Verifica-se que o processo de medição torna-se um meio de coletar evidências

acerca do processo e do produto, a fim de possibilitar mudanças que ocasionem

melhorias para o processo e, consequentemente, para o produto. Os resultados esperados

que o compõe estão destacados a seguir:

MED1 - Objetivos de medição são estabelecidos e mantidos a partir dos

objetivos de negócio da organização e das necessidades de informação de processos

técnicos e gerenciais;

MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de

medição, é identificado e definido, priorizado, documentado, revisado e, quando

pertinente, atualizado;

MED3 - Os procedimentos para a coleta e o armazenamento de medidas são

especificados;

MED4 - Os procedimentos para a análise das medidas são especificados;

MED5 - Os dados requeridos são coletados e analisados;

MED6 - Os dados e os resultados das análises são armazenados;

MED7 - Os dados e os resultados das análises são comunicados aos interessados

e são utilizados para apoiar decisões;

O Capítulo 2 apresentou o MPS.BR em conjunto com o Nível F. Do mesmo

modo, foram apresentados os processos englobados pelo nível em questão juntamente

com seus resultados esperados.

3. Ferramentas Utilizadas

Nessa seção será realizada uma breve descrição das ferramentas analisadas em relação a

cada processo do Nível F. Deve-se considerar que foram analisadas ferramentas open

source ou gratuitas, escolhidas com base na sua especificação técnica em relação ao

escopo de cada processo e todas tiveram suas funcionalidades analisadas.

3.1. Bugzilla

A Ferramenta de bugtracking Bugzilla foi desenvolvida pela Mozilla Foudation, através

da linguagem Perl e o método CGI. O Bugzilla possui como principal objetivo facilitar

o rastreamento de bugs durante o processo de desenvolvimento de software, pois

permite gerenciar as não conformidades e alterações durante o ciclo de vida do projeto.

A versão da ferramenta Bugzilla utilizada foi a 4.5.2, disponível em

http://www.bugzilla.org.

3.2. DotProject

O Dotproject foi criado pela dotmarketing.org utilizando a linguagem PHP e utiliza

Banco de Dados Postgres ou MySQL. O mesmo caracteriza-se por ser uma ferramenta

web, que possibilita gerenciar projetos, associar usuários a tarefas de relatórios,

repositórios de arquivos, lista de contatos e fórum de discussões. Analisou-se a versão

2.1.8 do DotProject, disponível em http://www.dotproject.net.

3.3. Drupal

A ferramenta Drupal foi desenvolvida em PHP, utiliza banco de dados MySQL ou

PostgreSQL e pode rodar nos servidores Web Apache ou IIS. O Drupal é um projeto

web, que permite aos usuários, separados ou não geograficamente, compartilhar

informações, publicar e gerenciar informações. Possui recursos comuns a sistemas

gerenciadores de conteúdo. Dentre os principais módulos estão os blogs, os fóruns, as

enquetes e a possibilidade de criação de wikis. Dessa maneira, caracteriza-se por ser

uma ferramenta de apoio à colaboração entre os usuários. Utilizou-se a versão 7.27 do

Drupal, disponível em http://drupal-br.org.

3.4 Git

A ferramenta Git é um sistema de controle de versões descentralizado, possibilita

trabalhar em vários protocolos de rede (RSYNC, SSH, HTTP, HTTPS) ou utilizar um

protocolo específico. As alterações efetuadas nos itens de configuração podem ser

monitoradas com auxílio dessa ferramenta. O cliente TortoiseGit, por possuir interface

gráfica, surge como alternativa à inserção de instruções em linha de comando, e foi

utilizado em conjunto com o Git nesse trabalho. Foi utilizada a versão 1.9.0 da

ferramenta Git e 1.8.7 do TortoiseGit, as mesmas estão disponíveis, respectivamente,

em http://git-scm.com e https://code.google.com/p/tortoisegit.

3.5. Mantis

O Mantis é uma ferramenta de bugtracking, desenvolvida na linguagem PHP e faz uso

de Banco de Dados MySQL, MS SQL e PostgreSQL, sua interface é web sendo

acessado de qualquer browser. Assim, seu objetivo é prover auxílio à gerência de não

conformidades ao longo da execução de um projeto. Assim, pode-se citar como

principais funcionalidades a criação de issues, seu registro e gerenciamento. Permite

ainda a geração de gráficos e relatórios exportáveis. Foi utilizada a versão 1.2.17 do

Mantis, disponível em http://www.mantisbt.org.

3.6 Mercurial

O Mercurial se caracteriza por ser um sistema de controle de versões descentralizado,

desenvolvido na linguagem Python e executável com sistemas operacionais que sejam

compatíveis com essa linguagem. Essa ferramenta opera com protocolos SSH e HTTP.

Assim, viabiliza o desenvolvimento distribuído de forma colaborativa, sendo que todas

as modificações efetuadas são armazenadas e podem ser monitoradas. Para facilitar as

operações nos repositórios foi utilizado o cliente de interface gráfica TortoiseHG. A

versão utilizada da ferramenta Mercurial foi a 2.9.1, disponível em

http://mercurial.selenic.com. Utilizou-se a versão 2.11 do TortoiseHG, disponível em

http://tortoisehg.bitbucket.org.

3.7. OpenProj

O OpenProj destina-se ao gerenciamento de projetos, originalmente criada pela

organização Serena Software e implementada na linguagem Java para Desktop. Essa

ferramenta apresenta módulos de apoio na elaboração de controle de execução das

tarefas, monitoria de recursos humanos e materiais, descrição de cenários e identificação

de riscos. Permite também a geração de representações gráficas como Gráfico de Gantt,

WBS (Work Breakdown Structure), RBS (Resource Breakdown Structure) e CPM

(Critcal Path Method). A versão analisada do OpenProj foi a 1.4 e encontra-se em

http://openproj.org/openproj.

3.8. Redmine

O Redmine é um software web voltado para administração de projetos, desenvolvido em

Ruby on Rails, com suporte a múltiplos Bancos de Dados e com execução em qualquer

browser. Dentre as funcionalidades disponíveis estão as de manter e monitorar projetos,

tarefas e realizar sua documentação. Destacam-se as funcionalidades de criação de

notícias, wiki e fóruns, criação de calendários para gerenciamento de cronogramas e a

geração do Gráfico de Gantt. A versão do Redmine utilizada foi a 2.4.5 e encontra-se

em http://www.redmine.org.

3.9. Spider-MPlan

A Spider-Mplan foi desenvolvida pelo projeto SPIDER, pertencente à Universidade

Federal do Pará, como uma aplicação Java utilizando Banco de Dados MySQL 5.1. Essa

ferramenta é voltada ao apoio sistematizado do processo de Medição. Através dela é

possível definir, coletar, analisar e acompanhar esse processo. As medidas, nessa

ferramenta, estão associadas a objetivos pré-definidos pelo usuário. A especificação de

medidas tem como base a técnica GQM (Goal, Question, Metric). Os dados podem ser

coletados a partir de uma planilha eletrônica ou de forma manual. O plano de medição e

relatórios podem ser exportados e a visualização das análises pode ser feita através de

gráficos. Utilizou-se a versão 1.0 do Spider-Mplan, disponível em

http://www.spider.ufpa.br/projetos/spider_mplan/Spider-Mplan.pdf.

3.10. Subversion

O Subversion (SVN) é um sistema de controle de versão centralizado, mantido pela

Tigris.org. Permite trabalhar com protocolos de rede baseados em HTTP e HTTPs ou

com seu próprio protocolo. Através dessa ferramenta é possível controlar alterações

realizadas em um item de configuração. Como o Subversion não possui interface

gráfica, para esse trabalho foi utilizado em conjunto, o TortoiseSVN como alternativa a

ter de realizar todo o trabalho em linha de comando. Utilizou-se a versão 1.8.9 do

Subversion e 1.8.5 do TortoiseSVN, as mesmas encontram-se disponíveis,

respectivamente, em http://subversion.tigris.org e http://tortoisesvn.net.

3.11. Testlink

O Testlink é uma ferramenta web e implementada na linguagem PHP, integrada com

Banco de Dados PostgreSQL, MySQL e MS-QL. A ferramenta possui como objetivo

auxiliar na gestão de testes, possibilitando a criação de planos de testes, geração de

relatórios e o registro de requisitos dos projetos. A versão do Testlink utilizada foi a

1.9.10, disponível em http://testlink.org.

3.12 TikiWiki

A ferramenta TikiWiki é um software web baseado em wiki, implementado em PHP,

possibilita a criação e manutenção de conteúdo. Dentre as principais funcionalidades

estão wiki, fórum, blog e enquete que permitem a colaboração entre os envolvidos. A

versão utilizada da ferramenta TikiWiki foi a 12.0, disponível em https://info.tiki.org.

3.13. WebApsee:

A ferramenta WebApsee tem como base de implementação o protocolo Remote Method

Invocation, RMI, o mesmo é disponibilizado na linguagem Java pela Sun. A WebApsee

é um ambiente voltado para organizações de desenvolvimento de software que permite o

gerenciamento de processos. Esse ambiente é formado por três módulos, Agenda, Server

e Manager_Console. A agenda contém as atividades a serem realizadas, o Server é onde

os processos são executados e o Manager_Console onde é feito todo o gerenciamento de

processos. A versão da ferramenta WebApsee utilizada foi a 1.5, disponível em

http://www3.ufpa.br/webapse.

No Capítulo 3 foram elencadas as ferramentas utilizadas para o desenvolvimento

do presente trabalho bem como suas principais características técnicas, tendo por

objetivo prover uma noção sobre para qual área determinada ferramenta é direcionada.

4. Metodologia

A elaboração do presente trabalho se deu por meio de várias etapas. Inicialmente a

realização de um estudo do MPS.BR e posteriormente dos processos que compõem

apenas o Nível F. Em seguida, realizou-se o levantamento de ferramentas open source

ou gratuitas, tanto web quanto desktop, para prover auxílio sistematizado à

implementação do Nível F . E por fim, o mapeamento dos resultados esperados para

cada processo em relação às funcionalidades disponíveis em cada ferramenta.

Com base nos trabalhos correlatos foram escolhidas as ferramentas que

poderiam ser utilizadas nesse trabalho, as demais foram selecionadas de acordo com sua

especificação técnica em relação ao escopo dos processos do Nível F. As ferramentas

tiveram suas funcionalidades analisadas e comparadas aos resultados esperados de cada

processo, utilizando como base o Guia de Implementação Parte 2 do MPS.BR.

Tendo conhecimento dos módulos disponíveis em cada ferramenta, a análise da

aderência ao que é proposto nos resultados especificados foi realizada com auxílio do

Guia de Avaliação do MPS.BR. O mesmo define os graus de aderência conforme o que

segue: Totalmente Implementado(T), Largamente Implementado (L), Parcialmente

Implementado (P), Não Implementado (N), Não Avaliado (NA) e Fora do Escopo (F).

Por último, com base no grau de aderência alcançado para cada ferramenta,

pode-se especificar qual melhor se adapta ao propósito de auxiliar a execução de cada

processo do Nível F .

5. Análise de Aderência

A seguir será apresentada uma análise comparativa das ferramentas eleitas em relação

aos resultados esperados de cada processo do Nível F.

5.1. Análise de Aderência das Ferramentas para o Processo de Aquisição (AQU)

Para o processo de Aquisição foram consideradas as ferramentas Drupal, Redmine e

TikiWiki. Os resultados esperados AQU5 e AQU8 foram considerados Fora do Escopo,

pois não necessitam de apoio sistematizado para sua implementação.

A implementação dos resultados AQU1, AQU2 e AQU3 refere-se,

respectivamente, à especificação de todos os pontos que envolvem o processo de

aquisição, definição de critérios para seleção de potenciais fornecedores e à escolha do

fornecedor. Nas três ferramentas eleitas é possível a construção de fóruns, blogs e wiki,

sendo que a TikiWiki disponibiliza a criação de enquetes para questionamentos sobre o

andamento do processo, destacando-se das demais. Assim, a ferramenta TikiWiki

obteve grau de aderência Totalmente Implementado e as ferramentas Redmine e Drupal

Largamente Implementado.

As ferramentas analisadas comportam-se de maneira semelhante para os

resultados esperados AQU4, o qual engloba a especificação de um acordo entre cliente e

fornecedor, e AQU7, que abrange a atividade de avaliação do produto em relação ao

acordo firmado. Para contemplar esses dois resultados, utilizam-se as funcionalidades de

fóruns e wiki disponíveis nas três ferramentas, atribuindo-se o nível de aderência

Totalmente Implementado para as mesmas.

Considerando o resultado AQU6, as ferramentas Redmine e TikiWiki

apresentaram funcionamento equivalente, oferecendo para a monitoração da aquisição,

blogs, fóruns, wiki e calendário. As mesmas mostraram-se aderentes, sendo qualificadas

como Totalmente Implementadas para o resultado esperado em questão. O Drupal, por

sua vez, não disponibiliza a criação de calendário para elaboração de um cronograma de

implementação do processo, sua aderência foi parcial e por esse motivo caracterizado

como Parcialmente Implementado.

Com base no escopo dos resultados esperados apresentados e na análise de

aderência das ferramentas a esses resultados, que pode ser verificada na Figura 1,

percebe-se que as ferramentas Drupal e Redmine possuem comportamento idêntico,

com exceção para o resultado AQU6. A ferramenta TikiWiki obteve um grau de

aderência superior para todos os resultados, sendo caracterizada como Totalmente

Implementada.

Figura 1. Aderência das ferramentas ao Processo de Aquisição

Fonte. Primária

Por fim, pode-se inferir que a ferramenta TikiWiki é a mais indicada para apoiar

o processo de Aquisição, uma vez que suas funcionalidades estão melhor relacionadas

ao desenvolvimento colaborativo de software.

5.2. Análise de Aderência das Ferramentas para o Processo de Gerência de

Configuração (GCO)

Foram utilizadas as ferramentas Git, Mercurial e Subversion para o Processo de

Gerência de Configuração. Apenas não foi analisado o resultado esperado GCO7,

considerado Fora do Escopo, pois o mesmo engloba atividades de auditoria, não sendo

necessário o uso de ferramentas de apoio.

Ressalta-se que para facilitar a interação com os sistemas de controle de versão

foram utilizadas interfaces gráficas em conjunto com os mesmos. Assim, juntamente

com a ferramenta Git, foi utilizado o TortoiseGit, com o Mercurial, o TortoiseHG e com

o Subversion, o TortoiseSVN.

O atendimento aos resultados GCO1, GCO2 e GCO3, envolve, respectivamente,

a definição de um sistema de configuração, identificação dos itens de configuração e

inserção dos itens em baselines. As ferramentas Git, Mercurial e Subversion obtiveram

aderência equivalente. Permitindo a manutenção de uma estrutura de pastas e

versionamento de arquivos ou diretórios. A utilização dos recursos branches1 e tags

2

viabilizam o desenvolvimento paralelo e a identificação única para cada item de

configuração. Isto posto, afirma-se que as ferramentas analisadas atingiram grau de

aderência Totalmente implementado.

As três ferramentas apresentaram-se de forma semelhante para os resultados

esperados GCO4 e GCO5. O primeiro, engloba o registro da evolução de itens de

configuração e baselines; o segundo, diz respeito ao controle de mudanças. As

funcionalidades de Logs, Diff3 e Blame

4 possibilitam o gerenciamento de todas as

alterações, assim auxiliam na implementação de ambos os resultados. Com isso, as

ferramentas Git, Mercurial e Subversion apresentam-se aderentes aos resultados em

questão e por isso caracterizadas como Totalmente implementadas.

O resultado GCO6 diz respeito ao controle de acesso e alterações no repositório.

As ferramentas Git, Mercurial e Subversion utilizam os protocolos SSH e HTTP e

possibilitam a criação de permissões para diferentes tipos de usuários, sendo atribuídas

para todo o diretório ou para arquivos específicos deste. Assim, obteve-se o nível de

aderência Totalmente Implementado para as ferramentas em questão.

Em suma, tomando como referência a análise realizada de aderência das

ferramentas em relação a cada resultado esperado, pode-se afirmar que todas obtiveram

grau de implementação Totalmente Implementado para o processo em questão. Nesse

caso não se faz necessário uso de uma representação gráfica para exemplificar o

resultado obtido, já que o mesmo foi exatamente igual para todas as ferramentas.

Apesar do fato de que as três ferramentas analisadas obtiveram o mesmo grau de

implementação, recomenda-se o uso do Subversion juntamente com o TortoiseSVN,

que dentre as três, é a que possui menor complexidade no aprendizado.

5.3. Análise de Aderência das Ferramentas para o Processo de Gerência de

Portfólio de Projetos (GPP)

Considerou-se para o Processo de Gerência de Portfólio de Projetos as ferramentas

DotProject, OpenProj e Redmine. Devido ao fato de não requerer o apoio sistematizado

para implementação, os resultados esperados GPP5, GPP6 e GPP8 não fizeram parte da

análise, sendo classificados como Fora do Escopo.

O resultado esperado GPP1 engloba a identificação de oportunidades e sua

priorização em relação aos objetivos estratégicos da organização. As ferramentas

DotProject e OpenProj possibilitam o cadastro de novos projetos, sendo possível

1 Armazena versões de desenvolvimento paralelo

2 Marca um ponto estável do desenvolvimento

3 Apresenta as diferenças entre duas revisões

4 Disponibiliza informações das revisões linha por linha

registrar o status atual e definir sua prioridade. Essas ferramentas foram consideradas

como Totalmente Implementadas. O Redmine, diferente das demais, possui apenas dois

status que podem ser atribuídos e não possui módulo para registro de prioridade, sendo

assim caracterizado como Largamente Implementado.

A implementação do resultado GPP2 envolve a identificação e alocação dos

recursos para cada projeto. Os módulos disponíveis no DotProject, OpenProj e Redmine

permitem armazenar informações sobre o orçamento juntamente com os recursos

humanos para cada projeto, sendo avaliadas como Totalmente Implementadas.

As ferramentas analisadas portaram-se de modo similar para o resultado GPP3,

que requer a definição do responsável por gerenciar o projeto. Todas permitem definir a

pessoa responsável por cada projeto, sendo qualificadas como Totalmente

Implementadas.

O escopo do resultado GPP4 engloba atividades de atualização, repriorização e

reavaliação de orçamento com base nos requisitos utilizados para priorização inicial. As

ferramentas apontadas possibilitam modificar o status atual do projeto, contudo, a

alteração de prioridade está disponível apenas nas ferramentas DotProject e OpenProj. À

vista disso, as mesmas foram conceituadas como Totalmente Implementadas, e o

Redmine como Parcialmente Implementado.

O resultado GPP7 compreende o controle sobre os projetos. Os que estão de

acordo com os requisitos iniciais são mantidos e os demais redirecionados ou

cancelados. Para esse resultado, as ferramentas DotProject e OpenProj possibilitam

redirecionar os projetos conforme sua situação atual, sendo conceituadas como

Totalmente Implementadas. O Redmine, por sua vez, possibilita apenas alterar o status

para aberto ou fechado, ou então criar campos específicos para isso, sendo assim,

considerado como Parcialmente Implementado.

Conforme análise de aderência das ferramentas em relação a cada resultado

esperado, representada na Figura 3, nota-se que as ferramentas mais aderentes foram a

DotProject e OpenProj, sendo caracterizadas como Totalmente Implementadas.

Figura 3. Aderência das ferramentas ao Processo de Gerência de Portfólio de

Projetos

Fonte. Primária

Diante do exposto, cabe ressaltar que as ferramentas DotProject e OpenProj

possuem as funcionalidades necessárias e são as mais indicadas para auxiliar na

implementação do processo em questão . Contemplam desde a criação de novos projetos,

definição de recursos até a monitoria em relação a alteração de status ou não viabilidade

de um projeto atual.

5.4. Análise de Aderência das Ferramentas para o Processo de Garantia da

Qualidade (GQA)

Dos quatros resultados esperados que compõem o Processo de Garantia de Qualidade,

os resultados GQA1 e GQA2 foram considerados como Fora do Escopo por tratarem de

atividades de monitoria. Para os demais resultados, utilizou-se as ferramentas Bugzilla,

Mantis e Testlink.

Para o resultado esperado GQA3, que trata da identificação e documentação de

problemas e não conformidades, as ferramentas Bugzilla e Mantis comportaram-se de

modo equivalente. Ambas permitem que ao identificar um defeito seja feita a

documentação do mesmo, por isso alcançaram grau de aderência Totalmente

Implementado. O Testlink não possui módulos que permitam a implementação desse

resultado, assim recebeu o conceito de Não Implementado.

O resultado GQA4 contempla a definição de ações corretivas para as não

conformidades e acompanhamento dessas ações até sua conclusão. Nesse caso, as

ferramentas Bugzilla e Mantis permitem atribuir um status para a não conformidade, e

direcioná-la a um responsável por sua correção. O Mantis se sobressai, pois permite

também documentar todo o fluxo de status percorrido pela não conformidade. Isto

posto, considera-se a ferramenta Bugzilla com nível de aderência Largamente

Implementado e o Mantis com Totalmente Implementado. A ferramenta Testlink foi

caracterizada como Não Implementada por não compreender as funcionalidades

necessárias para esse processo.

A análise realizada para cada ferramenta em relação aos resultados esperados é

apresentada na Figura 4. Nota-se que a ferramenta Testlink não possui as

funcionalidades necessárias para atender os resultados esperados. Por outro lado, o

Mantis se difere da ferramenta Bugzilla apresentando maior nível de aderência para o

resultado GQA4, assim ao Mantis aplica-se o conceito Totalmente Implementado.

Figura 4. Aderência das ferramentas ao Processo de Garantia da Qualidade

Fonte. Primária

Em conformidade com o especificado, assegura-se que a ferramenta Mantis é

mais indicada para auxiliar na implementação do processo em questão. A mesma

permite a documentação detalhada de uma não conformidade e ações para sua correção,

sendo que todo o fluxo é mantido e pode ser visualizado.

5.5. Análise de Aderência das Ferramentas para o Processo de Medição (MED)

Para o Processo de Medição foram consideradas, diferente dos demais, apenas duas

ferramentas, uma vez que a ferramenta Spider-MPlan foi desenvolvida para atender os

resultados esperados do processo em questão e os atendeu por completo. A outra

ferramenta avaliada foi a WebApsee.

O escopo do resultado esperado MED1 diz respeito à definição e manutenção

dos objetivos da medição. Tal especificação é contemplada na ferramenta Spider-MPlan

através da definição do propósito da medição e elaboração de uma lista das informações

que devem ser obtidas, o que a caracteriza com grau de aderência Totalmente

Implementado.

O resultado MED2 requer a identificação, priorização e documentação de um

conjunto de medidas, orientado pelos objetivos de medição. O resultado é atendido

pelas ferramentas analisadas que permitem a identificação e documentação das métricas

que serão utilizadas. As mesmas são aderentes ao resultado e classificadas como

Totalmente Implementadas.

A ferramenta Spider-MPlan mostrou-se aderente ao resultado MED3, onde são

especificados os procedimentos para coleta e armazenamento das medidas. A mesma

possibilita registrar o tipo da coleta, a medida utilizada, instruções, a periodicidade e o

responsável pela coleta. Assim sendo, atribuiu-se o grau de aderência Totalmente

Implementado para essa ferramenta.

A implementação do resultados esperados MED4 e MED5 diz respeito,

respectivamente, a especificação de procedimentos para a análise das medidas e a coleta

e análise dos dados requeridos. A ferramenta Spider-MPlan permite a documentação dos

procedimentos de análise e coleta. Após a coleta realizada é possível descrever a forma

de apresentação dos resultados, o indicador de análise e o critério de decisão com intuito

de analisar os dados gerados. Logo, conceituou-se a ferramenta Spider-Mplan como

Totalmente Implementada.

As ferramentas Spider-MPlan e WebApsee apresentaram-se de forma positiva

em relação ao resultado MED6, o qual requer o armazenamento dos dados e resultados

das análises. A primeira, possibilita armazenar tudo que é registrado sobre as medidas e

acompanhar a aprovação, coleta e análise. A segunda, armazenar as métricas coletadas,

o componente que foi mensurado, a unidade da métrica, o valor e o período mensurado.

Portanto, ambas obtiveram grau de aderência Totalmente Implementado.

Para o resultado MED7 é preciso comunicar os dados e resultados aos

interessados, na Spider-MPlan é possível registrar os resultados provenientes e listar os

usuários que terão acesso a esses resultados. Essa ferramenta atingiu nível de aderência

Totalmente Implementado para esse processo.

Atribuiu-se o conceito Não Implementado para a ferramenta WebApsee em

relação aos resultados esperados MED1, MED3, MED4, MED5 e MED7, por não

possuir as funcionalidades necessárias para implementação dos mesmos.

Em conjunto com o que foi descrito, a Figura 5, exemplifica o grau de aderência

das ferramentas em relação aos resultados esperados. A mesma permite observar que, ao

contrário da ferramenta WebApse, a Spider-Mplan atende por completo todos os

resultados, sendo atribuído grau de aderência Totalmente Implementado para a mesma.

Figura 5. Aderência das ferramentas ao Processo de Medição

Fonte. Primária

Por fim, recomenda-se a utilização da ferramenta Spider-Mplan para auxiliar na

execução do processo de Medição. A mesma possui os módulos necessários para

contemplar todos os resultados esperados do processo citado.

6. Conclusão

De acordo com a proposta do MPS.BR de auxiliar na garantia da qualidade no

desenvolvimento de software, o presente trabalho buscou elencar ferramentas de

software livre, que dentre suas funcionalidades, atendessem os objetivos dos resultados

esperados do Nível F.

Com base na análise realizada, afirma-se que para o processo de Aquisição a

ferramenta TikiWiki mostrou maior aderência por possuir um ambiente mais

colaborativo para o desenvolvimento de software. Para o processo de Gerência de

Configuração, embora todas as analisadas tenham se mostrado aderentes, recomenda-se

a utilização do Subversion em conjunto com o TortoiseSVN, uma vez que possui

melhor usabilidade que as demais.

As ferramentas DotProject e Openproj obtiveram o mesmo grau de aderência,

sendo as mais recomendadas para o processo de Gerência de Portfólio de Projetos,

devido ao fato de possuírem funcionalidades que contemplam a maioria dos resultados

esperados para esse processo.

Para o processo de Garantia da Qualidade, o Mantis revelou-se mais aderente

em relação as demais ferramentas avaliadas, visto que permite o gerenciamento de todo

o fluxo de uma não conformidade. Por fim, para o processo de Medição, a ferramenta

Spider-Mplan obteve aderência superior, uma vez que foi desenvolvida especificamente

para esse processo atendendo todos os resultados esperados.

Com este estudo, afirma-se que a utilização das ferramentas TikiWiki,

Subversion, DotProject, OpenProj, Mantis e Spider-Mplan podem contribuir para a

implementação dos processos do Nível F. As mesmas auxiliam em tarefas rotineiras e

na organização dos processos. Cabe ressaltar que dificilmente uma ferramenta se

adequará por completo às necessidades de uma organização e ao mesmo tempo as

especificações do MPS.BR, salvo se for desenvolvida exclusivamente para atender essas

duas situações.

Dessa forma, este trabalho possibilita que empresas possam se basear nas

análises aqui realizadas e utilizar as ferramentas citadas como apoio à implementação do

Nível F.

Como trabalhos futuros, pretende-se elaborar um repositório com as ferramentas

analisadas nesse trabalho, com intuito de facilitar as buscas possibilitando que empresas

interessadas as utilizem para se adequar ao que o Nível F do MPS.BR propõe.

Referências Bibliográficas

Carneiro, S. N., Oliveira, S. R. B. Uma Implementação do Processo de Medição usando

a Spider-MPlan In: IX Encontro Anual de Computação, 2011, Catalão. ENACOMP. ,

2011. Disponível em http://www.spider.ufpa.br.

Pressman, Roger S. (2011). Engenharia de Software: Uma abordagem profissional. 7 ed.

McGraw-Hill.

Rodrigo Barbalho. Uma proposta de Implementação do Processo de Garantia da

Qualidade usando Ferramentas de Software Livre. 2011. Curso (Ciência da

Computação) - Universidade Federal do Pará. Disponível em

http://www.spider.ufpa.br.

Rodrigues Junior, P. F. S (2009) “Uma Proposta de Apoio Sistematizado à Gerência de

Portfólio do MPS.BR”, Trabalho de Conclusão de Curso - Faculdade de Computação

– ICEN/UFPA, Orientador Prof. Sandro Bezerra, Belém-PA. Disponível em

http://www.spider.ufpa.br.

Softex - Associação para Promoção da Excelência do Software Brasileiro (2012).

“MPS.BR – Melhoria de Processo de Software Brasileiro, Guia Geral de Software”.

Disponível em www.softex.br.

Softex - Associação para Promoção da Excelência do Software Brasileiro (2013a).

“MPS.BR – Melhoria de Processo de Software Brasileiro, Guia de Implementação –

Parte 2”. Disponível em www.softex.br.

Softex - Associação para Promoção da Excelência do Software Brasileiro (2013b).

“MPS.BR – Melhoria de Processo de Software Brasileiro, Guia de Avaliação”.

Disponível em www.softex.br.

Sommerville, Ian (2011). Engenharia de Software. 9 ed. Pearson Education BR.

Yoshidome, E. Y. C., Souza, M. R de A. (2009) “Uma Proposta de Apoio Sistematizado

à Gerência de Configuração do MPS.BR Utilizando Ferramentas de Software Livre”,

Trabalho de Conclusão de Curso – Faculdade de Computação – ICEN/UFPA,

Orientador Prof. Sandro Bezerra, Belém-PA. Disponível em

http://www.spider.ufpa.br.