Análise Comparativa da Aderência de Ferramentas de Apoio
à Implementação do Nível de Maturidade E do MPS.BR
Cristiane Butu...
uso de ferramentas surge como alternativa para apoiar a implementação sistematizada
dos processos do MPS.BR.
Logo, o prese...
MPS.BR atende diversos perfis de empresas, porém seu foco é voltado para as micro,
pequenas e médias empresas (SOFTEX, 201...
produto terceirizado, oferece maior segurança às negociações através do gerenciamento
dos contratos e pedidos (SOFTEX, 201...
GCO5 - Modificações em itens de configuração são controladas;
GCO6 - O armazenamento, o manuseio e a liberação de itens de...
composto por atividades particulares e controle de qualidade, onde é fundamental seguir
efetivamente a engenharia de softw...
MED6 - Os dados e os resultados das análises são armazenados;
MED7 - Os dados e os resultados das análises são comunicados...
ferramenta Git e 1.8.7 do TortoiseGit, as mesmas estão disponíveis, respectivamente,
em http://git-scm.com e https://code....
possível definir, coletar, analisar e acompanhar esse processo. As medidas, nessa
ferramenta, estão associadas a objetivos...
4. Metodologia
A elaboração do presente trabalho se deu por meio de várias etapas. Inicialmente a
realização de um estudo ...
Considerando o resultado AQU6, as ferramentas Redmine e TikiWiki
apresentaram funcionamento equivalente, oferecendo para a...
O atendimento aos resultados GCO1, GCO2 e GCO3, envolve, respectivamente,
a definição de um sistema de configuração, ident...
registrar o status atual e definir sua prioridade. Essas ferramentas foram consideradas
como Totalmente Implementadas. O R...
Figura 3. Aderência das ferramentas ao Processo de Gerência de Portfólio de
Projetos
Fonte. Primária
Diante do exposto, ca...
caracterizada como Não Implementada por não compreender as funcionalidades
necessárias para esse processo.
A análise reali...
A ferramenta Spider-MPlan mostrou-se aderente ao resultado MED3, onde são
especificados os procedimentos para coleta e arm...
Figura 5. Aderência das ferramentas ao Processo de Medição
Fonte. Primária
Por fim, recomenda-se a utilização da ferrament...
implementação dos processos do Nível F. As mesmas auxiliam em tarefas rotineiras e
na organização dos processos. Cabe ress...
Próximos SlideShares
Carregando em…5
×

Análise comparativa da aderência de ferramentas de apoio

130 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
130
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Análise comparativa da aderência de ferramentas de apoio

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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;
  5. 5. 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 é
  6. 6. 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;
  7. 7. 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
  8. 8. 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 é
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. 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 tags2 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 Blame4 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
  13. 13. 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.
  14. 14. 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
  15. 15. 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.
  16. 16. 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.
  17. 17. 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
  18. 18. 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.

×