Análise comparativa da aderência de ferramentas de apoio
-
Upload
cristiane-butura -
Category
Documents
-
view
130 -
download
2
Transcript of Análise comparativa da aderência de ferramentas de apoio
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
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.