u proposta de apoio sistematizado À erÊncia de...

UNIVERSIDADE FEDERAL DO PARÁ

INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO TRABALHO DE CONCLUSÃO DE CURSO

Alexandre Brito Cardias Júnior

Luciana Neves Bentes

UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE REQUISITOS DO MPS.BR

Trabalho de Conclusão de Curso para obtenção do grau de Bacharel em Sistemas de Informação

Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira

Belém 2009

UNIVERSIDADE FEDERAL DO PARÁ

INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO TRABALHO DE CONCLUSÃO DE CURSO



UMA PROPOSTA DE APOIO SISTEMATIZADO À

GERÊNCIA DE REQUISITOS DO MPS.BR

Data da defesa: 16/12/2009

Conceito: ____________

Banca Examinadora

Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA – Orientador

Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA – Membro

Prof. M.Sc. Alfredo Braga Furtado Faculdade de Computação/UFPA – Membro

Belém 2009

À Deus, a Seu filho Jesus Cristo e Sua Mãe Nossa Senhora de Nazaré, por ter abençoado nossos caminhos.

AGRADECIMENTOS

À Deus. À minha mãe, que por ser professora me possibilitou estudar em uma

boa escola, sempre me mostrou o caminho certo. Ao meu pai, sempre me deu

forças. Aos meus irmãos, Leo e Gabi por aguentarem a luz do quarto acessa

durante as noites de estudos e trabalhos. À minha família, mesmo às vezes longe,

sempre torceram pelo meu sucesso. A minha namorada Lu, companheira, pessoa

que sempre torceu pelo meu sucesso, esteve ao meu lado me acalmando, por seu

carinho. Amo muito vocês!

Ao professor-orientador Sandro, que possibilitou a produção dessa pesquisa e

sempre orientou para o sucesso da mesma. Ao pessoal do projeto SPIDER, por

levantar críticas construtivas.

Aos amigos que torceram pelo meu sucesso. A todos.


Agradeço primeiramente à Deus que me deu forças para persistir e alcançar

meus objetivos. À minha mãe Lucia, que sempre me incentivou e lutou para que eu

prosseguisse com meus estudos. Ao meu pai Irineu, que da mesma forma me

incentivou e lutou para que eu tivesse uma educação de qualidade. À minha irmã

Thatiana, pela alegria de me ver fazendo aquilo que sempre sonhei. Ao meu

namorado Alexandre pelo companheirismo e paciência que sempre dedicou a mim,

me incentivando e acalmando para que juntos alcançássemos nossos objetivos.

Agradeço também à dedicação e compromisso do nosso orientador, Sandro,

que não mede esforços para partilhar o seu conhecimento. Aos integrantes do

projeto SPIDER, pelas críticas construtivas que ajudaram para que este trabalho

fosse realizado da melhor maneira possível.

Cada noite na sala de aula... cada madrugada sem dormir estudando,

fazendo trabalhos, escrevendo TCC valeram à pena! Agradeço a todos aqueles que

torceram pelo meu sucesso.


“É muito melhor arriscar coisas grandiosas, alcançar triunfos e glórias, mesmo expondo-se à derrota, do que formar fila com os pobres de espírito que nem gozam muito nem sofrem muito, porque vivem nessa penumbra cinzenta que não conhece vitória nem derrota.”

Theodore Rosevelt

RESUMO

As exigências do mercado intensificam a busca por qualidade no

desenvolvimento de software e fazem com que cada vez mais empresas adotem

modelos de qualidade visando à melhoria dos seus processos de software e

consequentemente do seu produto final. Dentre as áreas da disciplina de

Engenharia de Software, está a Qualidade de Software que permeia todo este

processo de adoção de práticas que visem à garantia da qualidade no

desenvolvimento de software. Este trabalho se propõe a apresentar ferramentas de

software livre analisando-as do ponto de vista da implementação do processo

Gerência de Requisitos do modelo para Melhoria do Processo de Software

Brasileiro, MPS.BR.

PALAVRAS-CHAVE: Gerência de Requisitos, Qualidade do Software, MPS.BR,

Ferramentas de Software Livre.

ABSTRACT

The market’s demands intensify the search for quality in software development

and, as a result, it makes that even more companies adopt models in order to

improve their software processes and, consequently, their final product. Among the

areas of the discipline of Software Engineering is the Quality of Software that

permeates the whole process of adopting practices aimed at quality assurance in

software development. This work presents free software tools, analyzing them from

the point of view of the MPS.BR model.

KEYWORDS: Requirements Management, Software Quality, MPS.BR, Free Software Tools.

SUMÁRIO

1 Introdução .................................................................................................................... 14

1.1 Contexto do Trabalho .............................................................................................. 14

1.2 Justificativa ............................................................................................................... 14

1.3 Motivação ................................................................................................................. 14

1.4 Objetivos ................................................................................................................. 15

1.5 Metodologia .............................................................................................................. 15

1.6 Estrutura ................................................................................................................... 16

2 Uma Visão Geral do MPS.BR ...................................................................................... 17

2.1 MPS.BR: Uma Visão Geral ....................................................................................... 17

2.2 A Estrutura do MPS.BR ............................................................................................ 18

2.2.1 Modelo de Referência .......................................................................................... 18

2.2.1 Método de Avaliação ............................................................................................ 19

2.2.3 Modelo de Negócio ............................................................................................... 20

2.3 Considerações Finais ............................................................................................... 21

3 Processo de Gerência de Requisitos (GRE) ................................................................. 22

3.1 O que é gerenciar requisito, independente do MPS.BR ............................................ 22

3.2 O que é gerenciar requisito no contexto do MPS.BR ................................................ 25

3.3 Crítica dos Resultados Esperados de Maneira Contextualizada ............................... 25


4 Proposta de Apoio Sistematizado ................................................................................. 29

4.1 Projeto SPIDER ........................................................................................................ 29

4.2 Ferramentas de Software Livre para Apoio ao Processo Gerência de Requisitos .... 30

4.2.1 OSRMT ............................................................................................................... 31

4.2.2 XUSE .................................................................................................................. 31

4.2.3 TRUC .................................................................................................................. 32

4.2.4 Controla .............................................................................................................. 32

4.2.5 WebRequisites .................................................................................................... 32

4.2.6 Jeremia - Requirement Management System ..................................................... 33

4.2.7 REM – Requirements Management .................................................................... 33

4.3 Ferramentas de Apoio para a Metodologia Proposta ................................................ 33

4.3.1 Spider-CL ............................................................................................................ 34

4.3.2 dotProject ............................................................................................................ 35

4.3.3 Trac ..................................................................................................................... 35

4.3.4 Mantis ................................................................................................................. 35

4.4 Mapeamento da Ferramenta aos Resultados Esperados ........................................ 35

4.4.1 GRE 1: OSRMT e Spider-CL .......................................................................... 37

4.4.2 GRE 2: OSRMT e dotProject .......................................................................... 39

4.4.3 GRE 3: OSRMT .............................................................................................. 40

4.4.4 GRE 4: OSRMT e Mantis ou Trac ................................................................... 41

4.4.4 GRE 5: Mantis ou Trac ................................................................................... 44


5 Metodologia para a Implementação do Processo de Gerência de Requisitos .............. 46

5.1 Instalação das Ferramentas de Apoio ...................................................................... 46

5.1.1 Instalação/ Configuração da Ferramenta OSRMT ................................................ 46

5.1.1.1 Requerimentos da Ferramenta .................................................................. 46

5.1.1.2 Instalação e Configuração da Ferramenta ................................................. 47

5.1.2 Instalação/ Configuração da Ferramenta Spider-CL ............................................ 47



5.1.3 Instalação/ Configuração da Ferramenta dotProject ............................................ 48



5.1.4 Instalação/ Configuração da Ferramenta Mantis................................................. 49



5.1.5 Instalação/ Configuração da Ferramenta Trac ..................................................... 50



5.2 Implementação do Resultado Esperado GRE1 ....................................................... 51

5.3 Implementação do Resultado Esperado GRE2 ........................................................ 61




5.7 Considerações Finais .............................................................................................. 71

6 Conclusão .................................................................................................................... 72

6.2 Resultados Obtidos ................................................................................................. 72

6.3 Trabalhos Futuros .................................................................................................... 73

6.4 Lições Aprendidas ................................................................................................... 73

Referências Bibliográficas ................................................................................................... 75

LISTA DE FIGURAS

Figura 2.1: Níveis de Maturidade do MR-MPS ................................................................. 19

Figura 3.1: Evolução de Requisitos [Sommerville, 2007] .................................................. 23

Figura 3.2: Gerenciamento de mudanças de requisitos [Sommerville, 2007].................... 24

Figura 4.1: Identificação do Fornecedor de Requisitos...................................................... 37

Figura 4.2: Histórico do requisito....................................................................................... 38

Figura 4.3: Checklist aplicado............................................................................................ 39

Figura 4.4: Comprometimento com a equipe técnica........................................................ 40

Figura 4.5: Matriz de Rastreabilidade................................................................................ 41

Figura 4.6: Análise de Impacto........................................................................................... 41

Figura 4.7: Revisões registradas no OSRMT..................................................................... 42

Figura 4.8: Identificação da Revisão no Mantis................................................................. 43

Figura 4.9: Relacionamento entre issues de ocorrências e issues de revisão.................. 43

Figura 4.10: Histórico de mudanças das issues................................................................ 44

Figura 5.1: Tela de login da ferramenta OSRMT............................................................... 52

Figura 5.2: Caminho para criar o perfil de Fornecedor de Requisitos............................... 52

Figura 5.3: Tela Select a reference a table........................................................................ 53

Figura 5.4: Tela Position..................................................................................................... 53

Figura 5.5: Tela de inclusão do perfil FornecedorRequisitos............................................. 54

Figura 5.6: Caminho para alterar perfil FornecedorRequisitos.......................................... 54

Figura 5.7: Acessos default do perfil cadastrado............................................................... 55

Figura 5.8: Tela para inclusão de usuários........................................................................ 56

Figura 5.9: Tela de primeiro login do perfil criado.............................................................. 57

Figura 5.10: Tela da visão do perfil FornecedorRequisitos................................................ 57

Figura 5.11: Tela de cadastro de status............................................................................. 58

Figura 5.12: Cadastro de critérios ..................................................................................... 59

Figura 5.13: Cadastro de checklist..................................................................................... 60

Figura 5.14: Requisito sendo alterado para o status de Entendido e checklist anexado... 61

Figura 5.15: Criar relatório de requisitos............................................................................ 62

Figura 5.16: Criação do fórum........................................................................................... 62

Figura 5.17: Criação do tópico........................................................................................... 63

Figura 5.18: Caminho para executar a rastreabilidade...................................................... 63

Figura 5.19: Tela para estabelecer o rastreio..................................................................... 64

Figura 5.20: Tela para visualizar a matriz de rastreabilidade............................................. 65

Figura 5.21: Registro de Revisões no OSRMT.................................................................. 66

Figura 5.22: Adição da categoria indicadora do processo de GRE no Mantis................... 67

Figura 5.23: Rastreabilidade no Mantis............................................................................. 67

Figura 5.24: Adição da categoria indicadora do processo de GRE no Trac...................... 68

Figura 5.25: Campos Blocked By e Blocking..................................................................... 69

Figura 5.26: Ticket de revisão cadastrado com as ocorrências......................................... 70

Figura 5.27: Ocorrências registradas no Trac.................................................................... 70

Figura 5.28: Histórico de mudança no ticket...................................................................... 71

Lista de Tabelas

Tabela 4.1: Mapeamento dos Resultados Esperados com as ferramentas....................... 36

Tabela 5.1: Permissões adicionadas ao perfil Fornecedor de Requisitos.......................... 55

14

1 INTRODUÇÃO

Será apresentada neste capítulo a contextualização do trabalho, a justificativa,

motivação, os objetivos, a metodologia que foi utilizada, e uma descrição da estrutura deste

trabalho.

1.1 Contexto do Trabalho

A qualidade tornou-se um diferencial no mercado, e não é diferente no desenvolvimento

de software, pois ela está diretamente ligada à satisfação do cliente e ao atendimento dos

requisitos desse software. Assim, faz-se necessário ambientar-se de tal maneira que se possa

criar produtos de qualidade. Sob o ponto de vista da ciência da computação, a Qualidade de

Software no contexto da Engenharia de Software, é responsável por criar esses ambientes

orientados por modelos de qualidade.

O modelo para Melhoria do Processo de Software Brasileiro – MPS.BR [SOFTEX,

2009a], em uma de suas áreas de processo, Gerência de Requisitos (GRE), é responsável por

auxiliar a equipe do projeto a fazer com que os requisitos necessários ao desenvolvimento do

software sejam atendidos. E é no contexto deste modelo e da Qualidade de Software que será

tratado este trabalho.

1.2 Justificativa

Como justificativa para esse trabalho busca-se com a sistematização do processo que as

empresas ao utilizarem o MPS.BR como modelo para desenvolver software, agilizem seus

projetos, sem prejuízo na qualidade do processo, pois essa é uma solução que visa

principalmente a diminuição do tempo aliado à aderência aos resultados esperados do

processo Gerência de Requisitos do MPS.BR.

1.3 Motivação

Cada vez mais a qualidade se torna um diferencial na aceitação e projeção de empresas

desenvolvedoras de software no mercado. O MPS.BR oferece uma metodologia para

implementar processos que sejam aderentes a modelos de qualidade. Dessa maneira, a

implementação do Processo de Gerência de Requisitos a partir do uso de Ferramentas de

Software Livre visa à diminuição de custo, esforço e tempo, pois são não-proprietárias e não

15

pagas (custos); diminuem a ampla necessidade de documentação (esforço); e possibilitam a

agilidade do processo (tempo).

Além disso, um grande motivador para o desenvolvimento deste trabalho foi a

oportunidade de poder aplicar os conhecimentos adquiridos durante o percurso acadêmico na

área de Qualidade de Software, área que desperta grande interesse e fascínio.

1.4 Objetivos

O objetivo geral deste trabalho é apresentar uma análise crítica de ferramentas de

software livre voltadas para o gerenciamento de requisitos, tornando-as aderentes ao processo

Gerência de Requisitos do nível de maturidade G (Parcialmente Gerenciado) do modelo

MPS.BR, alcançando a sistematização do processo e, consequentemente, a qualidade

organizacional. Aliada à motivação inicial de diminuir custo, pois não será necessária a

aquisição de ferramentas proprietárias atingindo assim o público alvo do modelo que é

voltado para pequenas e médias empresas; esforço e tempo, pois a utilização de software

diminui substancialmente a documentação produzida.

Como objetivos específicos destacam-se: o entendimento do programa MPS.BR; o

entendimento da implementação do processo de Gerência de Requisitos; estudo das

ferramentas de software livre que dêem suporte à implementação do processo Gerência de

Requisitos do MPS.BR; mapeamento das ferramentas de Software Livre; análise crítica das

ferramentas; apresentação das possíveis soluções para os resultados esperados não atendidos

nas ferramentas; e desenvolvimento de uma metodologia para o uso da ferramenta para a

implementação do processo de GRE.

1.5 Metodologia

Como metodologia para a realização do trabalho, pesquisas e reuniões foram realizadas

visando o melhor entendimento sobre Gerência de Requisitos e o MPS.BR, além da utilização

das ferramentas para que os objetivos pudessem ser alcançados.

As reuniões foram um meio para que o entendimento sobre a pesquisa feita pudesse ser

debatido e assim informações fossem somadas ou pesquisadas posteriormente, para que o

trabalho pudesse ser melhor executado.

16

1.6 Estrutura

O trabalho está estruturado da seguinte forma:

Capítulo 2 – Uma Visão Geral do MPS.BR. Fará um breve estudo sobre o modelo,

mostrando sua estrutura, descrevendo o Modelo de Referência, sobre o Método de Avaliação

e o Modelo de Negócio.

Capítulo 3 – Processo de Gerência de Requisitos (GRE). Tratará a gerência de

requisitos de forma geral e no contexto do MPS.BR. Fará uma análise dos resultados

esperados do processo do MPS.BR.

Capítulo 4 – Proposta de Apoio Sistematizado. Descreve sucintamente o projeto

SPIDER [Oliveira, 2008]. Apresenta ferramentas para suporte à Gerência de Requisitos,

posteriormente as ferramentas selecionadas para o apoio sistêmico. O mapeamento para que

os resultados esperados sejam contemplados pelas ferramentas é apresentado.

Capítulo 5 – Metodologia Para a Implementação do Processo de Gerência de

Requisitos. É apresentado como instalar as ferramentas selecionadas e o que deve ser

configurado e acessado, para que estas dêem suporte a implementação dos resultados

esperados do processo.

Capítulo 6 – Conclusão. Destinado aos resultados obtidos, trabalhos futuros e lições

aprendidas.

17

2 UMA VISÃO GERAL DO MPS.BR

Neste capítulo será apresentada uma visão geral do Modelo MPS.BR [SOFTEX,

2009a]. A Seção 2.1 descreverá o surgimento do modelo, as instituições que o compõe, a base

técnica bem como seus objetivos. A Seção 2.2 apresentará a estrutura do MPS descrita com

mais detalhes nas Seções 2.2.1 que trata do Modelo de Referência; 2.2.2 Método de Avaliação

e 2.2.3 descreve o Modelo de Negócio. Por fim, a Seção 2.3 é destinada as considerações

finais do capítulo.

2.1 MPS.BR: Uma Visão Geral

O projeto Melhoria do Processo de Software Brasileiro (MPS.BR), iniciou-se em 2003 e

tem como propósito a Melhoria de Processos de Software em empresas brasileiras, visando

atingir, principalmente, as micro, pequenas e médias empresas (PME), a um custo acessível.

Apesar do foco principal ser as PME, o modelo MPS é adequado a implementações e

avaliações de processos de software em grandes organizações privadas e governamentais

[Weber et al, 2004].

O programa é composto por sete instituições brasileiras, sendo três instituições de

ensino, pesquisa e centros tecnológicos (COPPE/UFRJ, CESAR, CenPRA); uma sociedade de

economia mista, a Companhia de Informática do Paraná (CELEPAR), hospedeira do

Subcomitê de Software da Associação Brasileira de Normas Técnicas (ABNT); e duas

organizações não-governamentais integrantes do Programa SOFTEX (Sociedade Núcleo de

Apoio à Produção e Exportação de Software do Rio de Janeiro – RIOSOFT e Sociedade

Núcleo SOFTEX 2000 de Campinas). Desde o início do projeto, a COPPE/UFRJ convidou a

Universidade Católica de Brasília (UCB) para ser sua parceira no projeto, que assim se uniu

ao grupo. Os participantes do programa atuam sob a coordenação da Sociedade SOFTEX

(Sociedade para Promoção da Excelência do Software Brasileiro) [Weber et al, 2004].

Como objetivo principal o programa visa definir e implementar o Modelo de Referência

para melhoria de processo de software (MR-MPS) em empresas brasileiras. E como objetivos

secundários propagar em diversas regiões no país: a capacitação no uso do modelo (cursos de

Introdução ao MR-MPS e cursos de provas para Consultores de Implementação e Avaliadores

do modelo); a implementação e avaliação do modelo com foco em grupos de empresas; e o

credenciamento de instituições implementadoras e/ou avaliadoras do modelo.

18

A base técnica para a definição do modelo MPS é composta pelas normas ISO/IEC

12207:2008 [ISO/IEC, 2008] e ISO/IEC 15504 [ISO/IEC, 2004] para a melhoria e avaliação

de processo de software e o modelo de referência que foi definido em conformidade com o

CMMI-DEV® (Capability Maturity Model Integration for Development) [SEI, 2006]. A

norma ISO/IEC 12207:2008, estabelece uma arquitetura comum para o ciclo de vida de

processos de software com uma terminologia bem definida, a norma ISO/IEC 15504 destina-

se à realização de avaliações de processos de software, objetivando a melhoria de processos e

a determinação da capacidade de processos de uma unidade organizacional. O CMMI surgiu

para resolver o problema de se usar diversos CMMs® do modelo SW-CMM® (Software

Capability Maturity Model) [SEI, 2006].

2.2 A Estrutura do MPS.BR

O modelo MPS está dividido em três componentes: Modelo de Referência (MR-MPS),

Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS), e cada um destes

componentes é descrito através de guias e/ou documentos do projeto.

2.2.1 Modelo de Referência

O Modelo de Referência do MPS é composto por três guias: o Guia Geral que contém

uma definição geral do modelo; o Guia de Aquisição que contém boas práticas para a

aquisição de software e serviços correlatos; e o Guia de Implementação que sugere formas de

implementar cada um dos níveis de maturidade do MR-MPS, sendo composto por uma série

de dez documentos [SOFTEX, 2009a].

O MR-MPS define níveis de maturidade que são uma combinação entre processos e sua

capacidade, estes níveis são sequenciais e cumulativos. Maturidade representa os estágios de

melhoria da implementação de processos na organização, e capacidade quer dizer o grau de

refinamento e institucionalização com que o processo é executado. Os níveis do MR-MPS são

sete: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente

Definido), E (Parcialmente Definido), F (Gerenciado), G (Parcialmente Gerenciado), estes

níveis evoluem do nível G ao A. Para que se obtenha um determinado nível de maturidade é

necessário que os propósitos e todos os resultados esperados do processo e os resultados

esperados dos atributos do processo daquele nível sejam atendidos [SOFTEX, 2009a]. A

Figura 2.1 mostra os sete níveis de maturidade e seus respectivos processos.

19

Figura 2.1 – Níveis de Maturidade do MR-MPS [SOFTEX, 2009a]

2.2.2 Método de Avaliação

O Método de Avaliação é composto pelo Guia de Avaliação baseado na norma ISO/IEC

15504, em que descreve o processo e o método de avaliação MA-MPS. O objetivo do método

de avaliação é verificar a maturidade de uma unidade organizacional, que significa a parte de

uma organização que será avaliada, na execução dos seus processos de software [SOFTEX,

2009a].

20

Para o sucesso da execução do processo de avaliação são necessários o

comprometimento do patrocinador, este pode ser um representante da alta gerência da unidade

organizacional a ser avaliada, ou de uma outra organização que solicita a avaliação da unidade

organizacional por uma terceira parte para fins de contrato [SOFTEX, 2009b]. Para garantir

que os objetivos sejam alcançados, tal comprometimento também diz respeito aos recursos

necessários, tempo e pessoal; motivação, deixando claro que o foco é o processo e não o

desempenho individual; fornecimento de feedback, ajuda a assegurar que a avaliação seja

significativa para a unidade organizacional; confidencialidade, essencial para que nenhum

entrevistado se sinta ameaçado e todos se expressem livremente; percepção dos benefícios, o

processo de avaliação resultará em benefícios que ajudarão direta ou indiretamente a unidade

organizacional; credibilidade, todos os interessados devem acreditar que a avaliação trará

resultado representativo, e que os avaliadores a experiência e competência para realizar a

avaliação.

Uma avaliação seguindo o MA-MPS tem validade de 3 (três) anos a contar da data em

que a avaliação final foi concluída na unidade organizacional avaliada [SOFTEX, 2009b].

O processo de avaliação possui quatro subprocessos, onde consistem em: contratar a

avaliação; preparar a avaliação; realizar a avaliação final; e documentar os resultados da

avaliação. Tem-se por resultados os dados obtidos que caracterizam os processos de software

da organização/unidade organizacional; o grau em que os resultados esperados são alcançados

e os processos atingem o seu propósito; o nível de maturidade MR-MPS à

organização/unidade organizacional [SOFTEX, 2009b].

2.2.3 Modelo de Negócio

O Modelo de Negócio descreve regras de negócio para implementação e define duas

situações [Weber et al, 2004]:

• Modelo de Negócio Específico (MNE): implementação do modelo de

referência de forma personalizada para uma empresa;

• Modelo de Negócio Cooperado (MNC): é realizado de forma cooperada entre

várias empresas e representa um custo mais acessível às micro, pequenas e

médias empresas por dividir proporcionalmente parte dos custos entre as

21

empresas para a implementação do modelo de referência, além da possibilidade

de se obter outras fontes de financiamento.

No Modelo de Negócio Específico, a empresa interessada negocia e assina um contrato

específico com uma das Instituições Implementadoras (II) credenciadas e para a avaliação a

empresa deve também negociar e assinar um contrato específico com uma das Instituições

Avaliadoras (IA) credenciadas, não podendo ser a mesma Instituição que implementou o MPS

na empresa. O contrato e os resultados da implementação e/ou avaliação são informados pela

II ou IA para a entidade SOFTEX. No Modelo de Negócio Cooperado, um grupo de empresas

irá negociar e assinar um contrato com uma Instituição Implementadora e sempre que

pertinente, um contrato será assinado com uma Instituição Organizadora de Grupos de

Empresas (IOGE) para cada grupo de empresas. Para a avaliação a IOGE negocia e assina

contrato com uma ou mais Instituições Avaliadoras, não podendo ser a mesma que

implementou o MR-MPS nas empresas nem a que organizou o grupo [SOFTEX, 2008a].

A implementação do MR-MPS e avaliações, só poderão ser realizadas através de

instituições credenciadas no Fórum de Credenciamento e Controle (FCC) do projeto. Um

convênio será assinado quando a Sociedade SOFTEX credenciar uma instituição.

2.3 Considerações Finais

Este capítulo apresentou como funciona o Modelo MPS.BR, descrevendo seu propósito,

objetivos e sua estrutura através do Modelo de Referência, Método de Avaliação e Modelo de

Negócio, servindo de base para o entendimento da proposta deste trabalho.

No capítulo seguinte será abordada a área de processo foco deste trabalho, gerência de

requisitos, inter-relacionando este entendimento inicial com a área de processo

especificamente, para que dessa maneira o objetivo deste trabalho possa ser alcançado.

22

3 PROCESSO DE GERÊNCIA DE REQUISITOS (GRE)

Neste capítulo será apresentado o processo de Gerência de Requisitos (GRE). A Seção

3.1 descreverá o processo de Gerência de Requisitos no âmbito geral; a Seção 3.2 apresentará

o processo Gerência de Requisitos no contexto do modelo MPS.BR; a Seção 3.3 é destinada à

crítica dos resultados esperados do MPS.BR de maneira contextualizada; e na Seção 3.4 serão

feitas as considerações finais do capítulo.

3.1 O que é gerenciar requisito, independente do MPS.BR

A gerência de requisitos é uma subárea da disciplina Engenharia de Requisitos e,

segundo Pressman (2006), a gerência de requisitos é um conjunto de atividades que ajudam a

equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos em

qualquer época, à medida que o projeto prossegue.

Antes de detalhar o que é gerenciar requisitos, é importante destacar o que vem a ser

requisito. Requisito é uma característica do sistema ou a descrição de algo que o sistema é

capaz de realizar, para atingir seus objetivos [Pfleeger, 2004]. Existem duas denominações

para os requisitos [Sommerville, 2007]:

• Requisitos do Usuário: são declarações em linguagem natural e em diagramas, dos

serviços que se espera que o sistema proporcione e das restrições com as quais deve

funcionar. Servem para designar requisitos de alto nível;

• Requisitos do Sistema: estabelecem com detalhe das funções, serviços e restrições

do sistema. Deve-se definir exatamente o que vai ser implementado.

Tradicionalmente, os requisitos de software são classificados em funcionais e não-

funcionais. Requisitos funcionais são declarações de serviços desejados no software, como ele

deve reagir a entradas específicas e como deve se comportar em situações particulares.

Requisitos não-funcionais são restrições de serviços ou funções oferecidos pelo sistema e são

frequentemente aplicados a todo o sistema.

Segundo Sommerville (2007), a gestão de requisitos é um processo de compreender e

controlar as mudanças dos requisitos de sistema. Esse processo inclui o planejamento de

gerenciamento, no qual políticas e procedimentos de gerenciamento de requisitos são

23

projetados e o gerenciamento de mudanças, no qual as mudanças de requisitos propostas

devem ser analisadas e seu impacto deve ser avaliado.

Para que o gerenciamento de requisitos ocorra é necessário que haja um planejamento

desse gerenciamento. Durante esse período é necessário que haja [Sommerville, 2007]:

• Identificação de requisitos: todo requisito deve possuir uma identificação única

para que este possa ser relacionado com outros requisitos e possa ser usado nas

avaliações de rastreabilidade;

• Processo de gerenciamento de mudanças: consiste em um conjunto de atividades

que avaliam o impacto e o custo das mudanças;

• Políticas de rastreabilidade: definem o relacionamento entre requisitos e entre

requisitos e o projeto do sistema;

• Apoio de ferramentas CASE: as ferramentas que podem ser utilizadas variam desde

sistemas especializados no gerenciamento de requisitos até planilhas e sistemas

simples de banco de dados.

Em um sistema em desenvolvimento os requisitos do software podem mudar por

diversos motivos. Essas mudanças podem ser propostas pelos usuários à medida que a

definição dos requisitos se desenvolve. A Figura 3.1 exemplifica a evolução nos requisitos.

Figura 3.1 – Evolução de Requisitos [Sommerville, 2007]

24

Para todas as mudanças propostas nos requisitos, o gerenciamento de mudanças deve

ser aplicado de tal forma que todas as propostas de mudança sejam tratadas consistentemente

e as mudanças no documento de requisitos sejam feitas de maneira controlada [Sommerville,

2007]. A Figura 3.2 apresenta o gerenciamento de mudanças de requisitos. Os três principais

estágios em um processo de gerenciamento de mudanças estão descritos abaixo:

• Análise do problema e especificação da mudança: durante esse estágio é

identificado um problema de requisitos, ou mesmo uma proposta específica de

mudança. Com isso o problema ou a proposta de mudança é analisada para

verificação de sua validade;

• Análise de mudança e estimativa de custo: a análise da mudança é realizada

avaliando o efeito da mudança proposta. A estimativa do custo para realizar a

mudança é feita com base nas modificações no documento de requisitos;

• Implementação da mudança: acontece quando o documento de requisitos é

alterado, ou mesmo o projeto e a implementação de sistema.

Figura 3.2 – Gerenciamento de mudanças de requisitos [Sommerville, 2007]

Pressman (2006) e Sommerville (2007) concordam com a utilização de ferramentas

para apoio à gerência de requisitos. Esse apoio é necessário para o armazenamento de

requisitos, que devem ser mantidos em um repositório de dados seguro e gerenciado;

gerenciamento de mudanças e gerenciamento de rastreabilidade, que permite que requisitos

relacionados sejam obtidos [Sommerville, 2007].

25

3.2 O que é gerenciar requisito no contexto do MPS.BR

Tendo a base sobre como gerenciar requisitos, agora será tratado a gerência de

requisitos no contexto do MPS.BR para que se possa fazer um estudo e crítica e, futuramente,

como pode ser implementado.

Para ser entendido o processo Gerência de Requisitos no MPS.BR, é preciso entender

como o modelo trata requisito, e para isso é usada a definição de Dorfmann e Thayer (1990),

onde requisito de software representa a capacidade requerida pelo usuário que deve ser

encontrada ou possuída por um determinado produto ou componente de produto para resolver

um problema ou alcançar um objetivo ou para satisfazer a um contrato, a um padrão, a uma

especificação ou a outros documentos formalmente impostos [SOFTEX, 2009c].

Tendo-se como premissa o entendimento sobre requisito do modelo MPS.BR, o

principal objetivo da Gerência de Requisitos é controlar a evolução dos requisitos. O processo

Gerência de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto,

incluindo requisitos funcionais e não-funcionais, bem como os requisitos impostos ao projeto

pela organização [SOFTEX, 2009c]. Então, o processo de Gerência de Requisitos não coleta,

não desenvolve e não detalha requisitos, apenas acompanha e administra as inconsistências e

mudanças que um requisito pode gerar, verificando até onde vai o impacto da mudança:

planos do projeto, estimativas de tempo e custo e recursos humanos.

Assim, pode ser definido o propósito da Gerência de Requisitos como gerenciar os

requisitos do produto e dos componentes do produto do projeto e identificar inconsistências

entre os requisitos, os planos do projeto e os produtos de trabalho do projeto [SOFTEX,

2009c].

3.3 Crítica dos Resultados Esperados de Maneira Contextualizada

O primeiro resultado esperado (RE) do processo de gerência de requisitos do MPS.BR,

GRE1, trata do acordo sobre os requisitos por todos os interessados, ocorrendo de forma

objetiva. Para isso a parte requisitante (cliente) precisa ter uma pessoa responsável que será a

ponte, a ligação com a equipe do projeto. Somente essa pessoa que concentra tudo o que o

cliente deseja pode expor os requisitos, assim como solicitar modificações.

Espera-se para o acordo com os requisitos, que para esses sejam atribuídos o status de

Entendido que identifica que para os interessados tudo está verbalmente correto, ou seja,

26

termos e expressões utilizadas não irão interferir no prosseguimento do projeto. Além desse

primeiro status, é esperado o status de Avaliado, onde deve demonstrar que tecnicamente, no

que diz respeito à completitude, corretude, clareza, ambiguidade, identificação única,

testabilidade, ou outros critérios objetivos que a equipe e/ou cliente achar pertinente, o

requisito pode ser continuado. Ainda para o GRE1 o status de Aceito deve ser obtido junto

aos fornecedores de requisitos onde será evidenciado que o cliente está de acordo com a

continuidade do requisito.

É importante ressaltar que para o papel de concentrador, como foi citado, deve ser

cadastrado no plano do projeto uma pessoa como Fornecedor de Requisitos e a forma como a

comunicação será feita; para os status de acordo dos interessados os critérios devem ser

previamente definidos. E com isso o resultado esperado é contemplado onde os requisitos são

entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios

objetivos [SOFTEX, 2009c].

O segundo resultado esperado GRE2, em que o comprometimento da equipe técnica

com os requisitos aprovados é obtido, tem como objetivo fazer com que a equipe se

comprometa explicitamente com os requisitos, pois este resultado foi introduzido a partir da

atualização do Guia Geral 2009. Anteriormente esse comprometimento era realizado de forma

mais restrita de acordo com o resultado esperado de gerência de projetos GPR12 – O plano

do projeto é revisado com todos os interessados e o compromisso com ele é obtido. Este

resultado deve obter o comprometimento com todos os interessados no projeto, realizando

negociações para a resolução de conflitos que poderiam envolver inclusive requisitos. Este

resultado esperado de gerência de projetos continua na atualização 2009, porém o acréscimo

do RE GRE2 enfatiza a importância de se obter um comprometimento formal da equipe

técnica com os requisitos aprovados.

Como mudanças nos requisitos aprovados pelos fornecedores de requisitos podem

ocorrer, um novo comprometimento da equipe técnica junto aos requisitos que foram

modificados é necessário. Esses requisitos modificados devem ser novamente aprovados a

partir de critérios objetivos de acordo com GRE1, para somente assim a equipe se

comprometer.

O resultado esperado GRE3 prevê: a rastreabilidade horizontal, ou seja, no mesmo

“nível” onde somente componentes de mesma grandeza podem ser mapeados, por exemplo

27

requisito com requisito, caso de uso com caso de uso; e a rastreabilidade vertical onde

componentes de “níveis” diferentes, importante para a análise de impacto, podem ser

mapeados, por exemplo requisito com caso de uso, caso de uso com documento de risco. A

rastreabilidade bidirecional pode ser contemplada por uma matriz de rastreabilidade, onde é

possível mostrar diversas dependências.

Uma boa escolha de um mecanismo de rastreabilidade (estabelecida) é essencial, pois o

resultado esperado acaba por influenciar em outros, ressaltando a importância de manter essa

rastreabilidade, pois o mapeamento deve mostrar a realidade do projeto para que assim se

tenha uma melhor gerência de requisitos, além de poder ter uma melhor visão dos possíveis

impactos.

O quarto resultado esperado GRE4, onde revisões em planos e produtos de trabalho

do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos

requisitos, sugere que sejam realizadas revisões com o objetivo de identificar inconsistências

entre os requisitos e os produtos de trabalho. Ações corretivas nas inconsistências

identificadas devem ser acompanhadas até que sejam resolvidas [SOFTEX, 2009c].

Quando há mudanças nos requisitos é preciso examinar se ocorreram inconsistências

nos demais artefatos devido às alterações realizadas.

Alguns exemplos de revisões com esse objetivo são revisões de monitoração e controle

do projeto e inspeções baseadas em critérios explícitos para identificar inconsistências entre

os planos, atividades e produtos com os requisitos e com mudanças nesses requisitos

[SOFTEX, 2009c].

O quinto resultado esperado, GRE5, tem como objetivo gerenciar as mudanças

ocorridas ao longo do projeto. Essas mudanças podem ocorrer em diferentes níveis de

abstração dos requisitos e não apenas nos requisitos de cliente. Além disso, novos requisitos

podem ser incorporados, outros podem ser retirados do projeto ou mesmo os requisitos já

existentes podem mudar.

Este resultado esperado traduz a importância de se manter um mecanismo de

rastreabilidade, pois facilita na visualização da análise de impacto, para as decisões tomadas

acerca das necessidades de mudanças. O gerenciamento inclui manter um histórico das

decisões em relação aos requisitos e o registro dessas necessidades de mudanças.

28


Neste capítulo foi tratado o Processo Gerência de Requisitos de maneira geral sem a

visão sobre nenhum modelo e a partir do modelo MPS.BR, mostrando como este modelo

descreve o processo Gerência de Requisitos, além de fazer uma crítica aos seus resultados

esperados através da descrição de seus objetivos e o que é necessário para alcançá-los.

No capítulo seguinte será mostrado o mapeamento dos resultados esperados do processo

gerência de requisitos com as ferramentas propostas para apoio à implementação deste

processo.

29

4 PROPOSTA DE APOIO SISTEMATIZADO

Neste capítulo será apresentada a proposta do apoio sistematizado, objetivo principal

deste trabalho, tendo-se como pressupostos uma visão sobre o programa MPS.BR; um estudo

sobre o processo de Gerência de Requisitos em um âmbito geral e de forma contextualizada

com o programa MPS.BR; e a análise crítica dos resultados esperados do processo de

Gerência de Requisitos do MPS.BR.

Tais passos foram importantes para ter o entendimento do que é necessário, em relação

a evidências, para o atendimento aos resultados esperados e assim apresentar a proposta da

implementação do processo gerência de requisitos de forma sistêmica.

Neste capítulo serão apresentadas as Seções: 4.1 - referente à descrição do projeto

SPIDER; 4.2 - apresenta ferramentas livres disponíveis para o apoio ao processo de Gerência

de Requisitos; 4.3 - descreve as ferramentas propostas para o apoio sistematizado à

implementação do processo de Gerência de Requisitos do MPS.BR; a Seção 4.4 apresenta o

mapeamento das operações/serviços das ferramentas junto aos resultados esperados; e

finalmente na Seção 4.5 serão feitas as considerações finais do capítulo.

4.1 Projeto SPIDER

A proposta deste trabalho é um subprojeto de um projeto chamado SPIDER – Uma

Proposta de Solução Sistêmica de um SUITE de Ferramentas de Software Livre de apoio à

implementação do modelo MPS.BR [Oliveira, 2008], que está vinculado ao Instituto de

Ciências Exatas e Naturais (ICEN) da Universidade Federal do Pará (UFPA) e possui como

instituições participantes o Centro de Informática (CIN) da Universidade Federal de

Pernambuco (UFPE) e o Departamento de Estatística e Informática (DEINFO) da

Universidade Federal Rural de Pernambuco (UFRPE).

O projeto começou ser executado em Janeiro de 2009 e possui como pesquisadores

alunos de graduação e pós-graduação responsáveis pela gestão técnica de uma etapa do

projeto, sob a coordenação de um professor Doutor. Um cronograma com reuniões semanais é

estabelecido a cada semestre contendo o dia das apresentações dos resultados das pesquisas de

cada participante. Nessas apresentações os resultados são apresentados e discutidos com a

equipe do projeto.

30

O desenvolvimento do projeto se justifica, dentre outros motivos, devido a

Recomendação do Tribunal de Contas da União (TCU) de 2007 na adoção do modelo

MPS.BR como elemento de pontuação diferenciada para a contratação de produtos e serviços

na área de software; e pela redução substancial na duração de uma implementação quando

uma organização adota o uso de ferramentas que apóiem o processo de desenvolvimento de

software [Oliveira, 2008].

Este projeto tem como objetivos fazer um levantamento de ferramentas de software

livre que possibilitem a criação de produtos de trabalhos que evidenciem a implementação dos

resultados esperados descritos nas áreas de processo do modelo MPS.BR. A partir deste

levantamento especificar e desenvolver um SUITE de ferramentas com a finalidade de

agregar as funções/operações disponíveis, propiciando dessa maneira um uso direcionado para

à implementação destas áreas de processo.

A escolha de ferramentas de software livre se justifica pela necessidade de não adquirir

ferramentas proprietárias para o desenvolvimento de software, além de possibilitar a

customização de acordo com a política organizacional, facilitando ainda mais a adoção do

modelo por pequenas e médias empresas por descartar o ônus financeiro que uma licença

representa.

Dentre algumas de suas metas estão a formação e qualificação de recursos humanos da

região, na área de Qualidade do Processo de Software, a partir das recomendações do modelo

MPS.BR e do SUITE desenvolvido; a participação efetiva da comunidade acadêmica para a

melhoria dos processos e produtos organizacionais; e a disseminação de programas de

melhoria de qualidade de software em empresas locais [Oliveira, 2008].

Após a definição das ferramentas a das propostas das equipes, será realizado um estudo

de caso com o objetivo de validar o modelo concebido e, se necessário, ajustes serão feitos.

Com isso pretende-se aplicar a(s) solução(ões) proposta(s) ao longo do desenvolvimento de

um projeto de software, em uma fábrica de software, com o propósito de avaliar a

implementação do programa de qualidade [Oliveira, 2008].

4.2 Ferramentas de Software Livre para Apoio ao Processo Gerência de

Requisitos

As ferramentas pesquisadas para a área de Gerência de Requisitos não suprem de forma

satisfatória os requisitos necessários para a implementação total do processo, seguindo as

31

recomendações do MPS.BR. Existem poucas ferramentas conhecidas e difundidas. Observou-

se que algumas dessas ferramentas surgiram como trabalho de graduação ou pós-graduação

em algumas Universidades e se encontram em um estágio de desenvolvimento, em que

melhorias ainda são necessárias.

Vale ressaltar que, para este trabalho, o foco da pesquisa concentrou-se no atendimento

dos resultados esperados do MPS.BR.

Abaixo se encontram as ferramentas pesquisadas, citando suas principais características,

fornecedor, versão, linguagem de desenvolvimento e uma breve descrição acerca do histórico

de desenvolvimento da ferramenta.

4.2.1 OSRMT

A ferramenta OSRMT (Open Source Requirements Management Tools), (disponível em

http://sourceforge.net/projects/osrmt/), é uma ferramenta projetada para auxiliar na gerência

de requisitos. Está licenciada sobre os termos da GPL (General Public License), sendo,

portanto, uma ferramenta free e de código fonte aberto. Foi desenvolvida em Java, permitindo

a utilização em modo servidor e modo cliente. Sua versão mais atual é a 1.5 patch 2.

A ferramenta possibilita o cadastro de artefatos como, requisitos, características,

código-fonte, casos de teste, etc. Para cada requisito é possível o cadastro de autor, casos de

uso, status, versão, além de manter um histórico a cerca das modificações sofridas. Uma

característica importante é a visualização das dependências entre artefatos através da matriz

de rastreabilidade e do gráfico de análise de impacto.

4.2.2 XUSE

Xuse (disponível em http://xuse.sourceforge.net/index.html) foi desenvolvida por uma

equipe no XML Solutions Ltd (www.xml-solutions.com) e visa definir um modelo de dados

XML que vai permitir a captação e gestão de requisitos de software. Sua versão mais atual é a

00.02.00, no entanto uma construção provisória de 00.03.00 já foi publicada. Algumas das

principais funcionalidades estão listadas a seguir:

• Identificação de requisitos;

• Cadastro de casos de uso;

32

• Suporta o formato XML padrão para importação e exportação de requisitos;

• Mantém o relacionamento entre itens do modelo de requisitos, podendo derivar

dependências mais complexas;

• Armazenamento de dados em XML, sendo, portanto de fácil controle de versão

em repositórios como o CVS.

4.2.3 TRUC

Truc – Tracking Requirements & Use Cases, é uma ferramenta baseada na web,

desenvolvida na linguagem PHP, para acompanhamento de requisitos e casos de uso. Está

licenciado sobre os termos da GPL (General Public License) e sua versão mais recente é

0.12.0.

Entre as principais funcionalidades desta ferramenta são identificados: controle de

versões, discussões, histórico de caso de uso, envio de arquivos e atribuição de requisitos e

casos de uso para comunicados e filtragem de todos os campos.

4.2.4 Controla

O controla (disponível em http://www.cientec.net/scripts/controla/download.asp), é uma

ferramenta que tem como objetivo apoiar as atividades inerentes ao processo de

desenvolvimento de software. Foi desenvolvida por Clayton Vieira Fraga Filho como trabalho

final do curso de Bacharelado em Sistemas de Informação da Faculdade de Viçosa. Este

aplicativo free foi desenvolvido na linguagem Delphi 7 e sua versão mais recente disponível é

a 1.3.

A ferramenta permite o gerenciamento de requisitos, utilizando como base uma breve

descrição, data de criação, estabilidade, prioridade, autor, responsável pela aprovação, além

de manter um histórico de cada requisito. Dentre algumas de suas principais funcionalidades,

estão: gerenciamento de casos de uso; gerenciamento de casos de teste e erros; planejamento

de liberações; gerenciamento de implementações; controle de dependência entre

implementações; matriz de rastreabilidade; registro de métricas para todos os artefatos;

controle de versão.

33

4.2.5 WebRequisites

A ferramenta WebRequisites é um software baseado na web e desenvolvido em PHP. A

ferramenta foi desenvolvida para gestão de requisitos e casos de uso. Permite o controle de

versões e os compara, gerando um diff entre eles, além de gerar a matriz de rastreabilidade e

análise de impacto, casos de teste e outros atributos relevantes.

O software foi desenvolvido por Vilson Cristiano Gartner, como parte do curso em

Sistemas de Informação e está sendo melhorada no seu curso de mestrado. A única versão do

software é a 1.0 e encontra-se disponível em http://sourceforge.net/projects/webrequisites/.

4.2.6 Jeremia – Requirement Management System

A ferramenta Jeremia (disponível em http://sourceforge.net/projects/jeremia/files/) foi

desenvolvida para auxiliar no gerenciamento de requisitos. Com a ferramenta é possível

identificar, analisar e classificar os requisitos. A ferramenta possibilita ainda fazer o rastreio

de mudanças de requisitos.

4.2.7 REM – Requirements Management

A ferramenta REM – Requirements Management é gratuita e experimental, concebida

para apoiar os requisitos na fase de Engenharia de um projeto de desenvolvimento de software

de acordo com a metodologia definida por Amador Durán em sua tese de Doutorado na

Universidade de Sevilla.

Encontra-se disponível no site (http://www.lsi.us.es/descargas/descarga_programas.php

?id=3) na página da Universidade, a versão 1.2.2 da ferramenta REM, tendo como pré-

requisitos o Internet Explorer 6 e biblioteca DAO 3.5. Estando disponível para as plataformas

Windows 95/98/ME/NE/2000/XP.

4.3 Ferramentas de Apoio para a Metodologia Proposta

Após o levantamento das ferramentas existentes para apoio ao processo Gerência de

Requisitos, foi escolhida a ferramenta OSRMT por apresentar funcionalidades importantes

para o processo de GRE, devido possuir mais tempo de uso e aceitação no mercado conforme

pesquisa realizada em blogs e fóruns, além de ser open source, garantindo assim

customizações para atender as especificidades do processo organizacional de diferentes

organizações.

34

O desenvolvimento da metodologia proposta tem como objetivo tornar o processo

Gerência de Requisitos totalmente implementado, de acordo com as exigências do modelo. A

análise isolada da ferramenta OSRMT não possibilitou essa implementação, devido restrições

em suas funcionalidades, daí a necessidade de utilizá-la em conjunto com outras ferramentas

para contemplar os resultados esperados de forma satisfatória.

Para que a metodologia fosse totalmente aderente aos resultados esperados, foi

necessária a adoção de quatro ferramentas: OSRMT, Spider-CL, dotproject, Mantis ou Trac.

Foram analisadas duas ferramentas de bugtracking, Mantis e Trac, devido ambas

apresentarem características semelhantes desejadas e por estarem dentro do escopo do projeto

SPIDER.

4.3.1 Spider-CL

A ferramenta Spider-CL foi desenvolvida no contexto do projeto SPIDER, com o

objetivo de desenvolver e publicar checklists compostos por critérios objetivos. Um checklist

é uma lista de produtos ou qualidades que devem ser avaliados em um determinado ativo de

uma organização, sendo que apenas um desses atributos possui uma lista de possíveis valores

que o mesmo pode receber e apenas um desses valores contidos nessa lista pode ser marcado

[Barros, 2009].

A Spider-CL foi desenvolvida em Java e acessível a partir de um navegador web comum.

A interface foi desenvolvida utilizando componentes gráficos convencionais como caixas de

textos, tabelas, listas e botões. Dentre as principais funcionalidades, estão:

• É uma ferramenta gratuita;

• É portável, devido ser desenvolvida como uma aplicação para o servidor Tomcat,

podendo ser executada em qualquer servidor capaz de executar o Tomcat 6.0 e

MySQL 5.1;

• Possui uma interface simples de utilizar;

• Pode ser usada para o desenvolvimento de qualquer tipo de checklist objetivo;

• Possui controle de acesso e mantém registro de todas as utilizações de cada checklist;

• Possibilita exportar os checklists preenchidos no formato PDF.

35

4.3.2 dotProject

A ferramenta dotProject é um sistema para gerenciamento de projetos, uma aplicação

web independente de sistema operacional e instalação do lado cliente, pois seu acesso é via

navegador, sendo executado em um servidor.

A ferramenta dotProject foi desenvolvida em PHP utilizando banco dados MySQL. Está

disponível em http://sourceforge.net/projects/dotproject/ na versão 2.1.2. Algumas das

funcionalidades são um modo fácil de informar usuários de suas associações e tarefas por e-

mail; fóruns relacionados a projetos; e repositório de arquivos relacionados a projetos.

4.3.3 Trac

Trac é uma ferramenta de interface web para controle de mudanças em projetos de

desenvolvimento de software. Foi desenvolvida em Phyton, é open source e sua versão mais

recente é a 0.11.5, além de possuir integração com o Subversion, ferramenta de controle de

versão.

É baseado em Wiki, ou seja, seu principal objetivo é tornar a edição de texto fácil,

servindo como um elemento de documentação colaborativa do projeto, provocando uma

maior interação entre os membros do projeto. Uma funcionalidade importante é o Timeline

que fornece uma visão histórica do projeto, listando todos os eventos que ocorreram em

ordem cronológica.

4.3.4 Mantis

Mantis Bug Tracker (BT) é uma ferramenta web de bugtracking desenvolvida em PHP

funcionando com diversos bancos de dados entre eles: MySQL e PostgreSQL. É possível

obter a ferramenta a partir do endereço http://www.mantisbt.org/.

A ferramenta foi desenvolvida para dar apoio ao controle de modificações,

contextualizado no processo de Gerência de Configuração, tendo como características a

criação e gerenciamento do ciclo de vida de issues, que são problemas identificados nos

produtos de trabalho. Sua versão mais recente é a 1.1.8.

4.4 Mapeamento da Ferramenta aos Resultados Esperados

O mapeamento terá como pressuposto a Crítica dos Resultados Esperados de Maneira

Contextualizada que foi feita no Capítulo 3 deste trabalho na Seção 3.3, onde foi mostrado um

36

Tabela 4.1 – Mapeamento dos Resultados Esperados com as ferramentas

entendimento de como o resultado esperado pode ser implementado, e será feita com a

ferramenta OSRMT, que é a base para o apoio sistematizado do processo Gerência de

Requisitos do MPS.BR. Além de ser mostrado, quando necessário, o que foi acrescentado

para implementar os resultados esperados deste processo.

Serão usadas as nomenclaturas: Totalmente Implementado, quando a operação/ serviço

da ferramenta é julgado adequado para a implementação do resultado esperado e não há Ponto

Fraco; Parcialmente Implementado, quando a operação/ serviço da ferramenta é julgado

adequado para a implementação do resultado esperado,porém um ou mais Pontos Fracos são

relatados; Não Implementado, quando a operação/ serviço da ferramenta não é julgado

adequado para a implementação do resultado esperado. Tais definições foram criadas no

projeto SPIDER.

Assim, serão analisadas inicialmente as operações/ serviços da ferramenta OSRMT com

o intuito de verificar se é possível atender completamente, (Totalmente Implementado); se

atende parcialmente, (Parcialmente Implementado); ou se não atende, (Não Implementado);

ao resultado esperado do processo Gerência de Requisitos do modelo MPS.BR. Caso a

ferramenta não atenda totalmente será mostrado a integração feita com as outras ferramentas

de apoio para que o resultado esperado seja Totalmente Implementado. O resultado deste

mapeamento pode ser visualizado na Tabela 4.1.

37

4.4.1 GRE 1: OSRMT e Spider-CL

Para o GRE1, onde os requisitos são entendidos, avaliados e aceitos junto aos

fornecedores de requisitos, utilizando critérios objetivos, foi visto que se faz necessário

identificar o Fornecedor de Requisitos e atribuir os status de entendido, avaliado e aceito,

utilizando-se de critérios objetivos.

Para atender ao resultado esperado, a ferramenta OSRMT possibilita a criação de perfis,

assim é possível ser identificado o perfil de Fornecedor de Requisitos, que será a pessoa que

atribuirá os status de entendido e aceito aos requisitos, bem como fornecer esses requisitos

disponibilizados pelos interessados do projeto para a equipe técnica. Essa identificação poderá

ser evidenciada na tela Select user da ferramenta, onde cada usuário é mostrado com o seu

perfil como pode ser visto na Figura 4.1.

Figura 4.1 – Identificação do Fornecedor de Requisitos

Para a manutenção dos status de Entendido, Avaliado e Aceito, a ferramenta possibilita

criar status novos para todos os requisitos que serão registrados. Assim os status podem ser

atribuídos, sendo comprovado que os status Entendido e Aceito foram de autoria do

Fornecedor de Requisitos no guia History do artefato Requirement como mostra a Figura 4.2.

38

Figura 4.2 – Histórico do requisito

Foi discutido, ainda, que para a atribuição dos status deverão ser utilizados critérios

objetivos, isto é, os critérios não podem mudar durante o projeto e devem ser claros, sendo

previamente estabelecidos. O Guia de Implementação do MPS.BR sugere que seja utilizado

um checklist. Como a ferramenta OSRMT não implementa, pois não apresenta suporte a

checklists, a solução encontrada foi integrar a ferramenta Spider-CL, que possibilita o registro

e manutenção de checklists de critérios objetivos, utilizado neste contexto para a avaliação

dos requisitos. A Spider-CL possibilita ainda gerar um relatório no formato PDF para

evidenciar a aplicação dos critérios.

Uma vez que o checklist foi definido, não será possível fazer modificações, atendendo,

dessa maneira, a exigência do modelo MPS.BR em se utilizar critérios objetivos, como pode

ser visto na Figura 4.3.

Então, para implementar totalmente o resultado esperado GRE1 é necessário agregar ao

apoio sistematizado do processo de Gerência de Requisitos a ferramenta Spider-CL.

39

Figura 4.3 – Checklist aplicado

4.4.2 GRE 2: OSRMT e dotProject

Para atender o resultado esperado GRE2, o Gerente de Requisitos, Analista de

Requisitos ou pessoa responsável, deve gerar um relatório na ferramenta OSRMT na

operação/serviço Report em que constam o nome, versão, status, prioridade e descrição dos

requisitos a serem obtido o comprometimento. Este relatório servirá para a equipe técnica

saber com quais requisitos estará se comprometendo.

Como a ferramenta OSRMT não possui um mecanismo onde é possível registrar esse

comprometimento, foi necessária a utilização da ferramenta dotProject que está dentro do

escopo do projeto SPIDER. Nessa ferramenta é possível criar fóruns com o objetivo de obter

esse comprometimento. Parte-se do pressuposto de que o projeto está registrado no

dotProject, sendo necessário anexar o relatório gerado pela ferramenta OSRMT com os

requisitos e um pacote (.zip; .rar) com os checklists de cada requisito que foi aplicado no

referente status na ferramenta Spider-CL. Sendo assim, um fórum deve ser criado. Sugere-se

o nome do fórum como sendo “Requisitos”. Dentro desse fórum vários tópicos devem ser

instanciados, para comprometimento de cada status (Entendido, Avaliado, Aceito),

referenciando na mensagem do tópico os identificadores dos requisitos funcionais registrado

40

na ferramenta OSRMT, a ser obtido o comprometimento, como segue RF01, RF02, RF03.

Um exemplo para obtenção desse comprometimento e do formato do tópico do fórum pode

ser visualizado na Figura 4.4. A sugestão para o nome do tópico tem o objetivo de facilitar a

identificação dos arquivos e do status a se comprometer. O nome do tópico segue o seguinte

formato:

STATUS#DATA_CRIAÇÃO_TÓPICO#RELATORIO_DE_REQUISITOS#CHECKLIST

Figura 4.4 – Comprometimento com a equipe técnica

4.4.3 GRE 3: OSRMT

Este resultado esperado é alcançado através de algum mecanismo de rastreabilidade. A

ferramenta OSRMT contempla de forma satisfatória este resultado através da Matriz de

Rastreabilidade e Análise de impacto, importante mecanismo de visualização da(s)

dependência(s) entre os artefatos. A OSRMT possibilita estabelecer o rastreio bidirecional, ou

seja, rastreabilidade horizontal e vertical. Um exemplo da matriz de rastreabilidade pode ser

visualizada na Figura 4.5 e a análise de impacto na Figura 4.6.

41

Figura 4.5 – Matriz de Rastreabilidade

Figura 4.6 – Análise de Impacto

4.4.4 GRE 4: OSRMT e Mantis ou Trac

No GRE4 faz-se necessária a realização de revisões em planos e produtos de trabalho

do projeto, visando identificar e corrigir inconsistências em relação aos requisitos. Se

inconsistências forem identificadas devem ser registradas [SOFTEX, 2009c].

Na ferramenta OSRMT as revisões serão registradas em Feature, funcionalidade que

permite registrar características do projeto. Nessa funcionalidade deverá ser anexado o

relatório gerado na ferramenta OSRMT contendo os requisitos. Para todas as revisões

realizadas em relação a este relatório algumas informações referentes à data de realização da

42

revisão, descrição e ocorrências (problemas/melhorias), se ocorrer, deverão ser detalhadas,

como pode ser visto na Figura 4.7.

Figura 4.7 – Revisões registradas no OSRMT

Após a definição da revisão no OSRMT, as informações levantadas devem ser passadas

para a ferramenta de controle de mudança, Mantis ou Trac, a fim de realizar o devido

tratamento e identificação dos problemas/melhorias.

Na ferramenta Mantis cada revisão constituirá de um conjunto de problemas/melhorias

a ser tratado, e sendo assim cada revisão é registrada na ferramenta como um issue

(problema), em que o campo category indicará que pertence ao processo de Gerência de

Requisitos, esta identificação deverá ser adicionada à ferramenta. A revisão registrada será

nomeada com um identificador no formato:

[IDENTIFICADOR_DA_REVISÃO]#[NOME_DO_DOCUMENTO_DE REFERÊNCIA]

, sendo um identificador único e de fácil entendimento, como pode ser visualizado na

Figura 4.8.

Para cada ocorrência listada na revisão, deve ser criado um issue homônimo ao

problema/melhoria, contendo descrição específica para aquela ocorrência, bem como a

estratégia de resolução do problema/melhoria. Os issues gerados a partir das ocorrências são

conectados ao issue referente à sua revisão, através da funcionalidade Relationships

43

Figura 4.9 – Relacionamento entre issues de ocorrências e issues de revisão

(relacionamento entre issues), de forma que o issue da revisão será “pai” dos issues de

ocorrências, como poder visualizado na Figura 4.9.

Figura 4.8 – Identificação da Revisão no Mantis

Na ferramenta Trac os problemas/melhorias identificados na ferramenta OSRMT serão

registrados como um Ticket, funcionalidade responsável pelo registro de mudanças. Apesar de

não possuir o mecanismo de relacionar os tickets por padrão, a instalação de um plugin

(MasterTickets), permite que ocorrências sejam registradas em uma relação de

Bloqueante/Bloqueadas (blocked or blocked by), permitindo a idéia de hierarquia entre

revisões e suas ocorrências, sendo o campo Component responsável pela identificação que o

ticket pertence ao processo gerência de requisitos. Assim como mencionado no Mantis esta

identificação deverá ser adicionada à ferramenta.

44

É importante destacar que ambas as ferramentas, Mantis e Trac, implementam

totalmente este resultado esperado juntamente como o OSRMT, ficando a critério da empresa

a escolha por qual ferramenta de bugtracking utilizar.

4.4.5 GRE 5: Mantis ou Trac

O resultado esperado, GRE5, requer acompanhar as mudanças nos requisitos, o que

envolve controlar a evolução da resolução de ocorrências identificadas no resultado esperado

anterior. É importante para o gerenciamento, que um histórico seja mantido em relação aos

requisitos, evidenciando dessa maneira a evolução das mudanças.

Na ferramenta Mantis, os issues gerados contam com um ciclo de vida próprio, baseado

em uma série de estados em que um issue pode se enquadrar até ser fechado. Os estados são

alterados conforme ações são tomadas para resolver o problema/melhoria.

Com base nos estados dos issues, pode-se definir um histórico de alterações, visualizado

na Figura 4.10, que a ferramenta Mantis disponibiliza para cada issue. Além de apresentar

estados no histórico, a ferramenta também exibe os detalhes sobre responsáveis (quem criou,

a quem foi apontado), exibe notas que podem ser adicionadas explicando ações tomadas na

resolução do problema/melhoria, data de cada modificação no issue.

Figura 4.10 – Histórico de Mudanças das issues

Na ferramenta Trac é possível controlar e acompanhar os problemas/melhorias através

dos estados dos tickets, que evidenciam o ciclo de vida desde o seu registro até a sua completa

resolução, além de ser possível disponibilizar relatórios com este mesmo propósito.

O Trac disponibiliza, ainda, o histórico de mudanças em cada ticket (Change History)

importante neste contexto, pois permite a visualização de todas alterações ocorridas nos

ticktes.

45

Assim como no resultado esperado anterior, as duas ferramentas, Mantis e Trac,

implementam totalmente o resultado esperado.


Neste capítulo foi apresentado o projeto de pesquisa SPIDER, que engloba o trabalho

aqui apresentado de apoio sistematizado ao processo Gerência de Requisitos do MPS.BR, as

ferramentas free disponíveis para atender a este processo e as ferramentas selecionadas para o

apoio sistêmico. Foi apresentado, ainda, o mapeamento da ferramenta OSRMT junto aos

resultados esperados, bem como a adição de outras ferramentas para a total implementação do

processo Gerência de Requisitos.

A partir desse mapeamento, será apresentado no capítulo seguinte em forma de manual,

todos os passos necessários em relação à utilização das ferramentas propostas para o alcance

dos objetivos dos resultados esperados para a implementação do processo Gerência de

Requisitos do MPS.BR.

46

5 METODOLOGIA PARA A IMPLEMENTAÇÃO DO PROCESSO DE GERÊNCIA DE

REQUISITOS

Neste capítulo serão apresentados os passos que foram especificados como necessários

para que as ferramentas pudessem atender aos resultados esperados do processo Gerência de

Requisitos, tendo como base o mapeamento das ferramentas de apoio. Importante destacar

que um artigo contendo informações sobre esta metodologia foi submetido para o evento

Workshop on Requirement Engineering – WER 2010 [Cardias Júnior et al, 2009].

Na Seção 5.1 serão mostradas informações sobre a instalação das ferramentas de apoio

OSRMT, Spider-CL, dotProject, Mantis e Trac. Na Seção 5.2 será apresentada a política de

uso para a implementação do resultado esperado GRE1 com o uso das ferramentas de apoio;

na Seção 5.3 para a implementação do resultado esperado GRE2; na Seção 5.4 para a

implementação do GRE3; na Seção 5.5 será mostrado os passos necessários para a

implementação do GRE4; na Seção 5.6 para a implementação do GRE5; e finalmente na

Seção 5.7 as considerações finais do capítulo.

5.1 Instalação das Ferramentas de Apoio

Nesta Seção serão demonstradas a instalação e configuração das ferramentas de apoio

para a implementação dos resultados esperados do processo de GRE. Para cada ferramenta de

apoio ao processo serão citados os requisitos necessários para a sua instalação.

5.1.1 Instalação/Configuração da Ferramenta OSRMT

A ferramenta OSRMT no contexto da metodologia proposta tem como finalidade

gerenciar requisitos durante o desenvolvimento de software. O objetivo é fazer com que

auxilie na implementação dos resultados esperados, exercendo papel principal para o alcance

dos objetivos dos resultados esperados, bem como no apoio em conjunto com outras

ferramentas utilizadas.

5.1.1.1 Requerimentos da Ferramenta

Máquina Virtual Java (http://www.java.com/pt_BR/download/index.jsp) instalada.

Como a instalação desta máquina não é objeto deste estudo, para maiores informações acessar

o site da Sun (http://www.sun.com/java/).

47

5.1.1.2 Instalação e Configuração da Ferramenta

Para instalar a ferramenta OSRMT é necessário ter a máquina virtual Java instalada.

Após baixar o arquivo compactado no site sourceforge, será necessário descompactar o

arquivo, que será reconhecido como um executável Java, e executá-lo. A instalação é de fácil

entendimento e intuitiva.

5.1.2 Instalação/Configuração da Ferramenta Spider-CL

A ferramenta Spider-CL é utilizada neste contexto para a aprovação dos requisitos

com base em critérios objetivos, através do registro e manutenção dos checklists. Um

diferencial para este processo é a possibilidade de gerar um arquivo no formato PDF que será

anexado na ferramenta OSRMT, comprovando dessa maneira que os requisitos foram

avaliados com base em critérios objetivos.


Para a instalação do Spider-CL é necessário que o computador possua o servidor

Tomcat 6.0 (http://tomcat.apache.org) ou versão superior instalado e o banco de dados

MySQL 5.1 (http://www.mysql.com). Os requisitos de hardware não são relevantes uma vez

que se trata uma aplicação simples e que executa em qualquer máquina capaz de satisfazer os

requisitos do Tomcat e do MySQL. Para acessar a interface web da ferramenta é necessário

um navegador que interprete JavaScript. Recomenda-se a utilização do navegador Mozilla

Firefox 2.0 ou uma versão superior [Barros, 2009].


Primeiramente deve ser instalado na máquina que hospedará a ferramenta o servidor

Tomcat. Nessa mesma também deve ser instalado o MySQL [Barros, 2009].

Antes de publicar a ferramenta no servidor é necessário antes configurar o MySQL.

Para que a ferramenta acesse o MySQL deverá ser criado um banco chamado “spider_cl”.

Para isso pode-se executar o comando:

CREATE DATABASE spider_cl;

Depois disso deve ser criado um usuário chamado “spider_cl” e cuja senha seja

“spider_cl”. Esse usuário deve ter permissões para criar tabelas e alterar o conteúdo delas

dentro do banco “spider_cl”. Para isso pode-se executar o comando:

48

GRANT ALL PRIVILEGES ON spider_cl.* TO 'spider_cl'@'localhost' IDENTIFIED

BY 'spider_cl';

O banco de dados deve estar acessível localmente pela porta 3306. Ou seja, o mesmo

deverá estar acessível pela url: localhost:3306/spider_cl. Após todas essas etapas de

configuração do banco é só publicar o arquivo WAR da ferramenta no Tomcat. Após a

conclusão desse procedimento a ferramenta já estará pronta para o uso. Ou seja, não é

necessário executar nenhum script no MySQL para criar as tabelas ou para inserir o usuário

default inicial [Barros, 2009].

Para utilizar a ferramenta basta autenticar-se com o usuário “admin” e senha nula, ou

seja, a senha é “ ”. Esse usuário possui privilégios para realizar todas as operações dentro da

ferramenta [Barros, 2009].

5.1.3 Instalação/Configuração da Ferramenta dotProject

A ferramenta dotProject será usada na implementação do resultado esperado GRE2,

para que o comprometimento com a equipe técnica seja obtido. A finalidade é fazer com que a

equipe técnica se comprometa com os requisitos através de um fórum que deverá ser criado

para esta finalidade. Dessa maneira ficará registrado na ferramenta através do login do usuário

que cada membro do projeto se comprometeu ou não com os requisitos.


A ferramenta deve ser instalada em um servidor com suporte a PHP (4.1.x ou

superior) MySQL (3.23.51 ou posterior). Um exemplo de servidor seria o Apache (4.3.5 ou

superior). É necessário ainda um browser com suporte a Javascript, bem como a criação de

um banco de dados e um usuário com permissão administrativa.

Para maiores informações acesse o site da ferramenta PHP, http://www.php.net/;

MySQL, http://www.mysql.com/; e Apache, http://httpd.apache.org/.


Deve-se descompactar a pasta do dotProject no servidor. Para instalar a ferramenta

deve-se acessar o endereço do servidor onde foi descompactado, se instalado localmente

http://127.0.0.1/dotproject, aparecerá um link para prosseguir. Será carregada a tela de

instalação do dotProject (http://localhost/dotproject/install/index.php).

49

No próximo passo devem ser informados o nome do banco criado ou que será criado,

o nome e senha do usuário com permissão no banco, nos campo Database Name, Database

User Name e Database User Password respectivamente. Outros campos também são

solicitados, mas serão alterados apenas esses.

No campo Database Name será mostrado como default o valor dotProject, deve-se

informar o nome do campo para acesso ou para ser criado. Em Database User Name informe

o nome do usuário com acesso administrativo ao banco de dados. E em Database User

Password informar a senha desse usuário. Clicar no botão install bd e write cfq e aguardar a

confirmação.

5.1.4 Instalação/Configuração da Ferramenta Mantis

O Mantis no contexto da implementação do processo Gerência de Requisitos será

utilizado para o registro de mudanças e/ou problemas/melhorias, identificados nas revisões e

consequentemente o gerenciamento desses registros através do acompanhamento dos estados

dos issues. A ferramenta será utilizada em conjunto com o OSRMT para a implementação do

resultado esperado GRE4 e isolada para a implementação do GRE5.


Para instalar o Mantis será necessária a instalação do PHP 4.3.0 ou versão superior;

Mysql database 4.1.1 ou versão superior; e de um Web Server, no caso para este trabalho foi

utilizado o Apache.

Para maiores informações acesse o site da ferramenta PHP, http://www.php.net/;

MySQL, http://www.mysql.com/; e Apache, http://httpd.apache.org/.


Deve-se descompactar a pasta do Mantis no servidor, é interessante renomear a pasta,

pois a mesma apresenta uma definição extensa. Para instalar a ferramenta deve-se acessar o

endereço do servidor onde foi descompactado, se instalado localmente

http://127.0.0.1/mantisrenomeada, aparecerá um link para prosseguir. Será carregada a tela de

instalação do Mantis (http://localhost/mantis/admin/install.php).

Preencher os campos os campos Username (for Database), Password (for Database) e

Admin Username (to create Database) e Admin Password (to create Database) com as

50

informações do administrador do banco de dados. Clicar no botão Install/Upgrade Database

para concluir a instalação.

5.1.5 Instalação/Configuração da Ferramenta Trac

O Trac assim como o Mantis fará o registro e acompanhamento de mudanças e/ou

problemas/melhorias identificadas nas revisões, tornando-se assim uma segunda opção para a

implementação do resultado esperado GRE4 e GRE5. As duas ferramentas implementam de

forma satisfatória estes resultados esperados.


É necessário a instalação das seguintes ferramentas: Python-2.6.4 disponível em

(http://www.python.org/); Setuptools-0.6c11 disponível em

(http://pypi.python.org/pypi/setuptools#downloads); Genshi-0.5.1 disponível em

(http://genshi.edgewall.org/).


Para instalar o Trac basta executar o arquivo da ferramenta e em seguida os seguintes

comandos devem ser digitados no prompt de comando:

C:\Python26\Scripts e pressionar a tecla Enter e em seguida digitar:

easy_install Trac e pressionar a tecla Enter

Deve-se verificar se mensagens de erro aparecem. Em seguida será necessário criar o

ambiente Trac. No prompt de comando, digitar:

mkdir C:\trac e pressionar a tecla Enter

cd C:\Python26\Scripts e pressionar a tecla Enter

trac-admin \trac initenv e pressionar a tecla Enter

Digitar o nome do seu projeto e pressionar a tecla Enter

Pressionar a tecla Enter três vezes

tracd --port 8000 C:\trac

No navegador digitar: http://localhost:8000, o nome do projeto irá aparecer. Para

utilizar a ferramenta a partir de agora, basta clicar no nome do projeto.

51

Para que a ferramenta permita gerenciar contas de usuários, como por exemplo,

registrar ou excluir contas, pode ser instalado o plugin Account Manager. Para isso basta fazer

o download e descompactar o arquivo na pasta de plugins do trac localizado em C:\trac e

digitar no prompt de comando:

cd C:\Python26\Scripts

easy_install C:\trac\plugins\accountmanagerplugin/0.11

Com a ferramenta configurada faz-se necessário a instalação do plugin Master Tickets

que será responsável pela idéia de hierarquia entre tickets. Após o download do plugin,

descompactar o arquivo localizado em C:\trac\plugins. No prompt de comando digitar:


easy_install C:\trac\plugins\masterticketsplugin\0.11

Após a instalação do plugin será necessário atualizar a instalação. No prompt de comando

digitar:


trac-admin c:\trac upgrade

5.2 Implementação do Resultado Esperado GRE1

Será mostrado como (1) criar e configurar o perfil de Fornecedor de requisitos; (2) criar

os status de Entendido, Avaliado e Aceito. Será mostrado ainda o que deve ser feito na

ferramenta Spider-CL para atender a utilização de checklists para os critérios objetivos.

Para criar o perfil de Fornecedor de Requisitos, deve-se efetuar login na ferramenta

OSRMT com um perfil de ADMIN (login: DEMO e senha: demo, perfil cadastrado como

default na ferramenta), como mostra a Figura 5.1.

52

Figura 5.1 - Tela de login da ferramenta OSRMT

No menu superior selecionar opção System, e em seguida selecionar a opção

Reference...

Figura 5.2 - Caminho para criar o perfil de Fornecedor de Requisitos.

Na janela Select a reference table selecionar na coluna Group o item Position e clicar

no botão Next> .

53

Figura 5.3 - Tela Select a reference a table.

Serão mostrados os perfis que já estão cadastrados, para incluir o perfil clicar no botão

Add Row.

Figura 5.4 - Tela Position.

Deverão ser preenchidos os campos Display, Display code indicando o perfil de

fornecedor de requisitos e o campo Description com uma breve descrição sobre esta função,

54

como pode ser visualizado na Figura 5.5. Como exemplo para este trabalho será usado a

denominação “FornecedorRequisitos”.

Figura 5.5 - Tela de inclusão do perfil FornecedorRequisitos

Após o registro do perfil, devem ser efetuadas as mudanças para que um usuário com

este perfil tenha acesso somente aos requisitos. Para isso deve-se acessar no menu superior a

opção Admin e depois selecionar Positions.

Figura 5.6 - Caminho para alterar perfil FornecedorRequisitos

55

Deverá ser configurado os acessos do perfil FornecedorRequisitos, quando

selecionado o perfil e após ser clicado o botão Next>, serão mostrados os acessos default,

como pode ser visto na Figura 5.7.

Figura 5.7 - Acessos default do perfil cadastrado.

O perfil FornecedorRequisitos deverá ter permissão de abrir os projetos cadastrados e

os requisitos para poder atribuir os status a eles. Para isso deverá ser dado os acessos abaixo

relacionados na Tabela 5.1.

Tabela 5.1 – Permissões adicionadas ao perfil Fornecedor de Requisitos

Level View Artifact Application Read Only

Requirement Form: Artifact 0

Requirement Columns : Artifact

Search

0

Marketing Menu: Main 0

Toolbar: Main 0

Columns: Report List

Após a alteração, usuários poderão ser cadastrados com perfil

“FornecedorRequisitos”, para isso deve-se acessar o menu superior Admin selecionando

56

Users..., na tela Select User clicar no botão Add Row, a tela para o cadastro de usuários pode

ser visualizada na Figura 5.8.

Figura 5.8 - Tela para inclusão de usuários.

Será usado como exemplo para o nome do Fornecedor de Requisitos o nome “Teste

Fornecedor”, então no campo Last Name: será preenchido por Fornecedor, o campo First

Name: por Teste, em Username: colocar testeFornecedor, será o login na ferramenta para este

exemplo, em Position: informar o perfil criado FornecedorRequisitos. O botão Change

password... deverá ser clicado e uma senha inicial deverá ser dada ao usuário para que possa

efetuar login, quando for a primeira vez será solicitado que altere a senha, como mostra a

Figura 5.9.

57

Figura 5.9 - Tela de primeiro login do perfil criado.

Como o perfil foi alterado, tem-se uma visão apenas do necessário para o atendimento

do resultado esperado com relação ao Fornecedor de Requisitos, como mostra a Figura 5.10.

Figura 5.10 - Tela da visão do perfil FornecedorRequisitos.

Deve-se fazer o cadastro dos status Entendido, Avaliado e Aceito. Para isso deve-se

acessar o menu superior Admin e selecionar Reference..., na janela Select a reference table

selecionar Status e clicar no botão Next>, na janela Select a reference item: Status, clicar no

botão Add Row, como visto na Figura 5.11. Nos campos Display: e Display code: preencher

58

com o status, selecionar em App type a opção Requirement para que o status esteja disponível

somente no artefato Requisitos, e em Description preencher com uma descrição sucinta, por

exemplo: O requisito foi Entendido.

Figura 5.11 - Tela de cadastro de status.

Para avaliar os requisitos com base em critérios objetivos, é necessário fazer uso da

ferramenta Spider-CL. Para criar um novo checklist é necessário cadastrar os critérios com

que os requisitos serão avaliados, uma vez definidos, estes critérios não poderão mudar. A

ferramenta Spider-CL é bastante intuitiva, então, para cadastrar um novo critério, basta

selecionar a opção “Cadastrar Critério” e registrar este critério com suas alternativas, “sim”

ou “não”, conforme visto na Figura 5.12.

59

Figura 5.12 – Cadastro de critérios

Para criar um checklist, basta selecionar a opção “Novo Checklist” e preencher o

Nome e descrição do checklist a ser aplicado, pesquisar os critérios e arrastá-los até o campo

“Lista de critérios do Checklist”. O procedimento para cadastrar o(s) usuário(s) que

poderá(ão) aplicar o checklist é o mesmo dos critérios, pesquisar e arrastar até o campo “Lista

de usuários que podem acessar o checklist”, e por fim salvar o checklist. A tela para o

cadastro de checklist pode ser visualizada na Figura 5.13.

Com o checklist definido, agora é só fazer uso do mesmo através da opção “Aplicar

Checklist”, selecionando pelo nome que foi cadastrado. Vale ressaltar que para cada resposta

negativa o campo “Descrição” deverá ser preenchido.

Para salvar o checklist no formato PDF que será anexado na ferramenta OSRMT,

basta selecionar a opção “Visualizar Checklist”, escolher o checklist desejado e clicar no

botão Baixar PDF.

60

Figura 5.13 – Cadastro de Checklist

Então para os status de Entendido, Avaliado e Aceito um checklist deverá ser aplicado

e posteriormente anexado no formato PDF ao correspondente requisito na ferramenta

OSRMT. Deve-se abrir um projeto pelo menu superior File e selecionar Open...(Ctrl+o). No

caso do FornecedorRequisitos ao efetuar o login serão mostrados apenas Requirement

(requisitos) na coluna esquerda, onde aparecem os Artifact da ferramenta, um requisito deve

ser aberto para ser modificado.

61

Figura 5.14 - Requisito sendo alterado para o status de Entendido e checklist anexado.

Posteriormente para ser comprovada a interação com o fornecedor de requisitos o guia

History deverá ser consultado contemplando assim o resultado esperado GRE1.


Para atender o resultado esperado GRE2 o Gerente de Requisitos, Analista de

Requisitos ou pessoa responsável, deve gerar um relatório na ferramenta OSRMT em que

constam o nome, versão, status, prioridade e descrição dos requisitos a ser obtido o

comprometimento. Para que o relatório com os requisitos seja gerado na ferramenta OSRMT,

é necessário acessar a operação/ serviço Reports no menu superior Tools. Na janela que foi

aberta selecionar a opção Artifact Detail e clicar em Next, selecionando em seguida o projeto

a que pertence o requisito e clicar no botão PDF para que o relatório seja gerado, conforme

pode ser visto na Figura 5.15.

62

Figura 5.15 – Gerar relatório de requisitos

Deverá ser anexado na ferramenta dotProject, além deste relatório de requisitos um

arquivo no formato .zip ou .rar, contendo os checklists que foram aplicados para o status que

se deseja obter o comprometimento.

Na ferramenta dotProject, o projeto deve ser selecionado e o fórum deve ser criado na

operação/ serviço new forum, como pode ser visto na Figura 5.16, e a partir disso os tópicos

devem ser instanciados conforme a necessidade para a obtenção do comprometimento na

operação/ serviço da ferramenta start a new topic, evidenciado na Figura 5.17.

Figura 5.16 – Criação do fórum

63

O nome do tópico segue o seguinte formato:

[STATUS]#[DATA_CRIAÇÃO_TÓPICO]#[RELATORIO_DE_ESPECIFICAÇÃO_DE_RE

QUISITOS#RELATÓRIO_CHECKLISTS], a sugestão para esse nome tem o objetivo de

facilitar a identificação dos arquivos e do status com o qual a equipe deve se comprometer.

Figura 5.17 – Criação do tópico


O resultado esperado será implementado totalmente, para isso após os requisitos serem

cadastrados na ferramenta, deve ser acessado o menu superior View e selecionado a opção

Traceability..., conforme visto na Figura 5.18.

Figura 5.18 - Caminho para executar a rastreabilidade.

64

Deve-se configurar para ser trabalhado com os requisitos, para isso deve-se acessar o

menu superior Edit e selecionar Criteria..., na tela seguinte no campo Artifact selecionar

Requeriment. Verificar se no lado direito é o projeto em questão, caso não seja deverá ser

aberto pelo menu superior File em Open product (Ctrl+O), na tela Open Product selecionar o

projeto. Esse serviço poderá ser utilizado quando houver rastreabilidade horizontal ou

vertical, como visto na Figura 5.19.

Figura 5.19 - Tela para estabelecer o rastreio.

Para o rastreio deve-se selecionar o requisito do lado esquerdo, no lado direito

selecionar o outro requisito (rastreabilidade horizontal) ou outro produto de trabalho

(rastreabilidade vertical). Para que o da esquerda influencie no da direita, ou seja, se aquele

mudar este deverá ser ajustado, acessar o menu superior Edit e selecionar Trace left to

right(Shift+F2), caso contrário selecionar Trace right to left (Shift+F2).

Para verificar a matriz de rastreabilidade acessar o menu superior Tools e selecionar

Trace..., aparecerá uma tela Columns : Traceability. Para visualizar a matriz nos campos

Trace From e Trace To selecionar os produtos de trabalho e no campo Trace Type selecionar

Traceability Matrix e por fim clicar no botão Apply, como visto na Figura 5.20.

65

Figura 5.20 - Tela para visualizar a matriz de rastreabilidade.

Para verificar a análise de impacto, acessar um produto de trabalho selecionando-o na

esquerda, acessar o menu superior Tools e selecionar Trace impacto..., na tela Change

Impacto será mostrado os produtos impactados e os que impactam no produto selecionado.


Para a implementação deste resultado esperado será necessária a utilização da

ferramenta OSRMT e de uma ferramenta de bugtracking, Mantis ou Trac. A escolha da

ferramenta fica à critério da organização, pois ambas pertencem ao escopo do projeto

SPIDER e atendem de forma satisfatória àquilo que se propõe.

Na ferramenta OSRMT as revisões serão registradas na funcionalidade Feature. Nessa

funcionalidade deverá ser anexado o relatório gerado na ferramenta OSRMT contendo os

requisitos, como visto na Figura 5.21.

66

Figura 5.21 – Registro de Revisões no OSRMT

O procedimento para gerar este relatório é o mesmo descrito no GRE2 como segue:

acessar a operação/ serviço Reports no menu superior Tools. Na janela que foi aberta

selecionar a opção Artifact Detail e clicar em Next, selecionando em seguida o projeto a que

pertence o requisito e clicar no botão PDF para que o relatório seja gerado.

Na ferramenta Mantis para registrar uma issue (problema/melhoria), deverá ser

selecionado a opção Report Issue no menu superior. O campo category na tela de registro

indicará que pertence ao processo de gerência de requisitos. Para adicionar esta categoria

deve-se selecionar o projeto, clicar no menu superior Manage e no menu inferior Manage

Projects, selecionar o projeto e no campo Categories digitar o indicador, por exemplo:

Gerência de Requisitos ou GRE, e por fim clicar no botão Add Category, como mostra a

Figura 5.22.

67

Figura 5.22 – Adição da categoria indicativa do processo de GRE no Mantis

Para que o relacionamento seja estabelecido é necessário que a issue da revisão e da(s)

ocorrência(s) já esteja(m) cadastrada(s). Para fazer este relacionamento, basta clicar no ID da

issue de revisão e no campo Realationships inserir o identificador da ocorrência e clicar no

botão Add. O relacionamento também pode ser estabelecido de maneira inversa clicando no

ID da ocorrência e no campo Relationships selecionar em Current issue a opção child of e

inserir o ID da revisão e por fim clicar no botão Add, como pode ser visto na Figura 5.23.

Figura 5.23 – Relacionamento entre issues no Mantis

Na ferramenta Trac os problemas/melhorias identificados na ferramenta OSRMT

serão registrados como um Ticket, para acessar esta funcionalidade basta clicar na opção New

Ticket no menu superior. O nome do problema/ melhoria segue o mesmo formato descrito

para o Mantis: [IDENTIFICADOR_DA_REVISÃO]#[NOME_DO_DOCUMENTO_DE_

68

REFERÊNCIA], e deverá ser adicionado no campo Sumary. O campo component identificará

que o ticket pertence ao processo gerência de requisitos e deverá ser adicionado da seguinte

forma: clicar no botão Admin, menu superior e na opção components adicionar o nome para

identificar que o processo pertence ao processo gerência de requisitos, por exemplo, GRE,

como pode ser visto na Figura 5.24. Em Ticket Types, pode ser adicionado o tipo “Melhoria”,

para retratar quando uma ocorrência deste tipo for cadastrada.

Figura 5.24 – Adição da categoria indicativa do processo de GRE no Trac

Com a instalação do plugin Master Tickets, é possível estabelecer uma idéia de

hierarquia entre as revisões e as ocorrências. Esse mecanismo tem o mesmo objetivo do

Relationships no Mantis, ou seja, estabelecer um mecanismo para relacionar as ocorrências

detectadas em uma determinada revisão. Então no cadastro de um ticket de ocorrência deve-se

inserir no campo “Blocking” o número do ticket de revisão que já foi previamente cadastrado,

ou de maneira inversa, após o cadastro da revisão e das ocorrências, selecionar o ticket de

revisão e inserir o número dos tickets de ocorrências no campo “Blocked By”, como pode ser

visto na Figura 5.25.

69

Figura 5.25 – Campos Blocked By e Blocking

Um exemplo da utilização do plugin Master Tickets pode ser visto na Figura 5.26, em

que as ocorrências registradas no Trac, Figura 5.27, aparecem inseridas no campo Bolcked By

do ticket de revisão.

70

Figura 5.26 – Ticket de revisão cadastrado com as ocorrências

Figura 5.27 – Ocorrências registradas no Trac


As mudanças podem ser gerenciadas através da manutenção do histórico de mudanças

que a issue ou ticket sofreu. Tanto para a ferramenta Mantis quanto para a ferramenta Trac, as

mudanças podem ser acompanhadas acessando a issue ou o ticket de ocorrência, pois cada um

71

exibe o ciclo de vida desde o seu registro até o seu fechamento. Um exemplo do histórico das

mudanças ocorridas em um ticket pode ser visto na Figura 5.28.

Figura 5.28 – Histórico de mudança no ticket


Neste capítulo foi mostrado o manual para implementação dos resultados esperados do

processo Gerência de Requisitos e ainda os requisitos necessários para instalar/configurar as

ferramentas de apoio, e assim poder contemplá-lo. Através da descrição da política de uso, ou

seja, do que é necessário a uma organização utilizar nas operações/ serviços das ferramentas,

foram evidenciados quais seriam os passos para poder satisfazer aos resultados esperados.

É importante ressaltar que o trabalho é uma proposta de sistematização, não eximindo a

organização da interação humana, como reuniões e negociações, partes fundamentais para que

o processo possa ser executado.

No capítulo seguinte será feita a conclusão deste trabalho, mostrando um resumo de

todo o processo de pesquisa e elaboração, além de descrever os ganhos obtidos através do que

foi produzido e os trabalhos futuros para a continuação/aprimoramento desta proposta

72

6 CONCLUSÃO

A Gerência de Requisitos se constitui num dos mais importantes processos no

desenvolvimento de software devido à influência que exerce nas demais áreas de processo.

Requisitos mal gerenciados podem, por exemplo, resultar em não cumprimento do

cronograma do projeto, falhas nas estimativas, entre outras consequências, gerando impacto

direto no produto final e, consequentemente, a insatisfação do cliente.

Este estudo se traduz numa importante alternativa para organizações interessadas em

implementar o processo de GRE visando alcançar o nível de maturidade G através da

avaliação do MPS.BR, principalmente as pequenas e médias empresas que não possuem

recursos para a aquisição de ferramentas proprietárias.

Vale ressaltar que devido a dificuldade de encontrar ferramentas livres para a Gerência

de Requisitos que contemplem de modo satisfatório os resultados esperados do modelo

MPS.BR, é importante destacar que a análise das ferramentas apresentadas neste trabalho é

apenas uma proposta para implementar o processo de GRE, podendo cada organização

adaptá-la conforme sua realidade.

Importante mencionar que a metodologia discutida neste trabalho não propõe a

definição e institucionalização de um processo organizacional de Gerência de Requisitos e

nem substitui este processo, entende-se que a metodologia agrega facilidades na execução do

processo a partir do uso de ativos organizacionais na forma de ferramentas de software livre.

6.1 Resultados Obtidos

Durante a realização da pesquisa diversos insumos foram produzidos propiciando dessa

maneira a elaboração deste trabalho. Dentre alguns resultados estão:

• relatórios iniciais da pesquisa com as ferramentas de software livre encontradas para

o gerenciamento de requisitos e relatório com a escolha da ferramenta que seria

usada no sub-projeto do SPIDER, destacando as razões pela escolha bem como as

principais funcionalidades da ferramenta;

• em seguida foi realizado o preenchimento de duas tabelas contendo na primeira o

mapeamento das funcionalidades da ferramenta OSRMT com os resultados

73

esperados do modelo MPS.BR e na segunda a proposta de solução para àqueles

resultados não atendidos;

• a elaboração de um Manual de Implementação para o processo de Gerência de

Requisitos que auxiliará empresas interessadas em implementar este processo;

• e por fim a escrita de um artigo científico sob o título “Uma Análise Avaliativa de

Ferramentas de Software Livre no Contexto da Implementação do Processo de

Gerência de Requisitos do MPS.BR”, submetido ao evento Workshop on

Requirements Engineering – WER 2010.

6.2 Trabalhos Futuros

Como trabalhos futuros destacam-se:

• a integração das ferramentas propostas dentro do escopo do projeto SPIDER de

desenvolvimento de um SUITE, para centralizar as operações e serviços das

ferramentas, dinamizando ainda mais o processo;

• o desenvolvimento de um estudo de caso para coletar informações a respeito dos

benefícios e/ou dificuldades relatadas objetivando o aprimoramento da metodologia

proposta;

• e escrita de um novo artigo a ser submetido no IX Simpósio Brasileiro de Qualidade

de Software (SBQS 2010).

6.3 Lições Aprendidas

A elaboração deste trabalho proporcionou a ampliação do conhecimento em Qualidade

de Software, entendendo a sua importância através do modelo MPS.BR. O estudo deste

modelo e as diversas discussões nas reuniões do projeto SPIDER propiciaram o

amadurecimento do conhecimento já obtido em sala de aula, despertando inclusive, o

interesse em se aprofundar ainda mais no assunto, através de cursos oficiais em MPS.BR.

Além do conhecimento obtido não só pelo estudo e pelas pesquisas realizadas, mas

também pela interação com o coordenador do projeto e demais integrantes que enriqueceram

e contribuíram na elaboração do trabalho através da troca de experiências e opiniões, a

74

participação em um projeto de pesquisa possibilitou a experiência da pesquisa acadêmica bem

como da elaboração de artigo científico.

75

Referências Bibliográficas

[Barros, 2009] BARROS, Renan S., Manual do Usuário – SPIDER CL – Versão 1.2, julho de

2009.

[Cardias Júnior et al, 2009] CARDIAS, Alexandre B. et al, Uma Análise Avaliativa de

Ferramentas de Software Livre no Contexto da Implementação do Processo de Gerência de

Requisitos do MPS.BR, artigo submetido ao evento Workshop on Requirement Engineering –

WER 2010 .

[ISO/IEC, 2004] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/

INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-1: Information

Technology – Process Assessment – Part 1 – Concepts and Vocabulary, Geneve: ISO, 2004.

[ISO/IEC, 2008] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/

INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 12207 Systems and

software engineering – Software life cycle process, Geneve: ISO, 2008.

[Oliveira, 2008] OLIVEIRA, Sandro R. B., SPIDER – Uma Proposta de Ferramentas de

Software Livre de Apoio à Implementação do MPS.BR, Projeto de Pesquisa Submetido e

Aprovado pelo Instituto de Ciências Exatas e Naturais da UFPA, Belém-PA, 2008.

[Pfleeger, 2004] PFLEEGER, Shari L. Engenharia de Software: teoria e prática, 2 ed. – São

Paulo: Prentice Hall.

[Pressman, 2006] PRESSMAN, Roger S., Engenharia de Software, 6º ed. São Paulo:

MCGRAW-Hill.

[SEI, 2006] SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-

DEV), Version 1.2, Technical Report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software

Engineering Institute, Carnegie Mellon University, 2006.

76

[SOFTEX, 2008a] SOFTEX, Sociedade para Promoção da Excelência do Software Brasileiro,

Modelo de Negócio para Melhoria de Processo de Software (MN-MPS): resumo executivo,

v180208.

[SOFTEX, 2009a] SOFTEX, Sociedade para Promoção da Excelência do Software Brasileiro,

MPS.BR – Melhoria de Processo de Software Brasileiro. Guia Geral, maio 2009.

[SOFTEX, 2009b] SOFTEX, Sociedade para Promoção da Excelência do Software Brasileiro,

Guia de Avaliação, maio 2009 atualizado em agosto de 2009.

[SOFTEX, 2009c] SOFTEX, Sociedade para Promoção da Excelência do Software Brasileiro,

Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-

MPS.BR, maio de 2009.

[Sommerville, 2007] SOMMERVILLE, Ian. Engenharia de Software, 8º ed. São Paulo:

Pearson Addison-Wesley.

[Weber et al, 2004] WEBER, Kival C. et al, Modelo de Referência para Melhoria de Processo

de Software: uma abordagem brasileira, Conferência Latinoamericana de Informática – CLEI,

Arequipa Peru, 2004.

u proposta de apoio sistematizado À erÊncia de...

Documents