ferramenta de apoio À gerÊncia de requisitos baseada...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO – BACHARELADO
FERRAMENTA DE APOIO À GERÊNCIA DE REQUISITOS
BASEADA NO MODELO CMMI
MARIANE MEISEN
BLUMENAU 2005
2005/1-38
MARIANE MEISEN
FERRAMENTA DE APOIO À GERÊNCIA DE REQUISITOS
BASEADA NO MODELO CMMI
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação — Bacharelado.
Prof. Everaldo Artur Grahl - Orientador
BLUMENAU 2005
2005/1-38
FERRAMENTA DE APOIO À GERÊNCIA DE REQUISITOS
BASEADA NO MODELO CMMI
Por
MARIANE MEISEN
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Nome Everaldo Artur Grahl – Orientador, FURB
______________________________________________________ Membro: Prof.(a) Fabiane Barreto Vavassori Benitti – FURB
______________________________________________________ Membro: Prof.(a) Ana Lúcia Anacleto Reis – FURB
Blumenau, 06 de julho de 2005
Aos meus pais, Adelino e Albertina Meisen, pelo incentivo, e aos meus amigos pelo apoio durante a realização deste trabalho.
AGRADECIMENTOS
À Deus, pela minha vida.
À minha família, pelo incentivo e apoio.
Ao meu namorado Fernando, pela compreensão e paciência durante o desenvolvimento
deste trabalho.
Aos meus amigos, pelo apoio, e por estarem sempre ao meu lado.
Ao meu orientador, Everaldo A. Grahl, por ter me aceitado como orientando e pelo
incentivo e ajuda dedicada a este trabalho.
Os amigos verdadeiros são como o Sol, não precisamos vê-lo todos os dias para saber que ele existe.
Autor Desconhecido
RESUMO
Este trabalho consiste no desenvolvimento de uma ferramenta para auxiliar gerentes de projeto e analistas de sistemas na gerência dos requisitos de seus projetos. O foco principal da ferramenta está em atender algumas das recomendações do modelo CMMI nos níveis 2 e 3, no que se refere a gerência de requisitos. Para a implementação utilizou-se o Java Server Pages e o framework Struts. A ferramenta atende o CMMI através do registro de stakeholders, plano de gerência de requisitos, histórico de mudanças, indicadores de estabilidade e cadastros básicos para a gerência de requisitos dos projetos.
Palavras-chave: CMMI. Gerência de requisitos.
ABSTRACT
This work consists at the development of a tool to help project managers and system analysts on requirements management of their projects. The tool main focus is to implement some recommendations of the CMMI model about requirements management at levels 2 and 3. For the implementation was used the java server pages and the struts framework. The tool attends the CMMI allowing the stakeholders registration, requirements management policy, change historic, stability appointment and the basic registrations for the projects requirements management.
Key-Words: CMMI. Requirements management.
LISTA DE ILUSTRAÇÕES
Figura 1 – Representação dos níveis do CMMI...................................................................14
Figura 2 – Processo de Gerência de Requisitos ...................................................................17
Figura 3 – Representação dos Modelos do CMMI ..............................................................21
Quadro 1 – Métricas relativas à estabilidade............................................................................24
Figura 4 – Relação entre Casos de Uso e Atores do Sistema...............................................36
Figura 5 – Diagrama de Classe ............................................................................................43
Figura 6 – Diagrama das Classes Business e Cursor ...........................................................44
Figura 7 – Diagrama de Seqüência ......................................................................................45
Figura 8 – Rastreabilidade entre requisitos e casos de uso ..................................................46
Quadro 2 – Exemplo de um ActionForm .................................................................................49
Quadro 3 – Parte do arquivo ApplicationResources.properties do sistema .............................49
Quadro 4 – Parte do arquivo struts-config.xml ........................................................................50
Quadro 5 – Estudo de Caso ......................................................................................................51
Figura 9 – Tela de Autenticação ..........................................................................................52
Figura 10 – Tela inicial do módulo Administrativo ............................................................53
Figura 11 – Cadastro inicial de Projeto ...............................................................................54
Figura 12 – Tela de Cadastro de Usuários...........................................................................55
Figura 13 – Página inicial do módulo gerencial ..................................................................56
Figura 14 – Tela de cadastro de atributos............................................................................57
Figura 15 – Tela de cadastro de valores dos atributos.........................................................57
Figura 16 – Tela de cadastro de tipo de requisito................................................................58
Figura 17 – Tela de cadastro de vínculos ............................................................................59
Figura 18 – Tela de manutenção de projeto.........................................................................59
Figura 19 – Tela de cadastro da política de gerência de requisitos .....................................60
Figura 20 – Tela de manutenção de acessos........................................................................61
Figura 21 – Tela de associação dos atributos ao tipo de requisito.......................................62
Figura 22 – Tela de solicitação de relatórios .......................................................................62
Figura 23 – Tela de alteração de senha................................................................................63
Figura 24 – Tela inicial do módulo analítico.......................................................................64
Figura 25 – Tela de cadastro de stakeholders......................................................................65
Figura 26 – Tela de cadastro de entrevistas.........................................................................66
Figura 27 – Tela de manutenção do glossário .....................................................................66
Figura 28 – Tela de cadastro de requisitos ..........................................................................67
Figura 29 – Tela de cadastro de requisitos (2).....................................................................68
Figura 30 – Tela de cadastro das dependências do requisito...............................................68
Figura 31 – Tela de cadastro das solicitações de alteração dos requisitos ..........................69
Figura 32 – Tela de alteração das solicitações de alteração dos requisitos .........................70
Figura 33 – Matriz de Rastreabilidade do Requisito a ser alterado.....................................70
Figura 34 – Tela de execução de relatórios .........................................................................71
Figura 35 – Lista de Requisitos ...........................................................................................72
Figura 36 – Indicadores .......................................................................................................72
Figura 37 – Histórico de Solicitações de Alteração.............................................................73
Figura 38 – Política de Gerência de requisitos ....................................................................74
Figura 39 – Documento de requisitos..................................................................................75
Quadro 6 – Relação entre CMMI e a ferramenta desenvolvida ...............................................76
LISTA DE SIGLAS
API – Application Programming Interface
ASF – Apache Software Foundation
CASE – Computer Aided Software Engineering
CMM – Capability Maturity Model
CMMI – Capability Maturity Model Integration
CMMI-SE/SW - Capability Maturity Model Integration System/Software Engineering
EJB – Entreprise Java Beans
GOAL – Goal Question Metric
HTML – Hipertext Markup Language
IPD/CMM – Integrated Product Development Capability Maturity Model
ISO – International Standards Organization
ISO/IEC – International Standards Organization/International Electrotechnical Commission
JDBC – Java Data Base Conectivity
JSP - Java Server Pages
MVC - Model-View-Controller
PHP – Personal Home Page
RH – Recursos Humanos
SEI – Software Engineering Institute
UML - Unified Modeling Language
XML – Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................13
1.1 OBJETIVOS......................................................................................................................14
1.2 ESTRUTURA....................................................................................................................15
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................16
2.1 GERÊNCIA DE REQUISITOS ........................................................................................16
2.2 CMMI................................................................................................................................18
2.2.1 Áreas Chaves...................................................................................................................22
2.3 INDICADORES................................................................................................................23
2.3.1 Indicadores de Estabilidade.............................................................................................24
2.3.2 Indicadores de Rastreabilidade .......................................................................................25
2.4 FRAMEWORK STRUTS .................................................................................................26
2.4.1 Componentes Model........................................................................................................27
2.4.2 Componentes View..........................................................................................................27
2.4.3 Componentes Controller.................................................................................................29
2.5 TRABALHOS CORRELATOS........................................................................................30
3 DESENVOLVIMENTO DO TRABALHO.....................................................................32
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA ...............................................................32
3.2 ESPECIFICAÇÃO ............................................................................................................34
3.2.1 Diagrama de Casos de Uso .............................................................................................35
3.2.1.1 Criar projeto..................................................................................................................35
3.2.1.2 Manter usuários ............................................................................................................35
3.2.1.3 Manter política de gerência ..........................................................................................35
3.2.1.4 Manter tipos de requisitos.............................................................................................37
3.2.1.5 Manter atributos............................................................................................................37
3.2.1.6 Manter vínculos ............................................................................................................37
3.2.1.7 Manter projeto ..............................................................................................................37
3.2.1.8 Liberar acesso ao projeto ..............................................................................................38
3.2.1.9 Manter glossário ...........................................................................................................38
3.2.1.10 Manter requisitos ...................................................................................................38
3.2.1.11 Manter solicitação de alteração .............................................................................38
3.2.1.12 Gerar relatório de requisitos ..................................................................................39
3.2.1.13 Gerar matriz de rastreabilidade..............................................................................39
3.2.1.14 Visualizar indicadores ...........................................................................................39
3.2.1.15 Manter dependências .............................................................................................39
3.2.1.16 Cadastrar Stakeholders ..........................................................................................40
3.2.1.17 Manter entrevistas..................................................................................................40
3.2.1.18 Visualizar histórico das alterações.........................................................................40
3.2.2 Diagrama de Classes .......................................................................................................40
3.2.3 Diagrama de Seqüência...................................................................................................44
3.2.4 Ferramenta utilizada na especificação do trabalho .........................................................45
3.2.4.1 Enterprise Architect ......................................................................................................45
3.3 IMPLEMENTAÇÃO ........................................................................................................47
3.3.1 Técnicas e ferramentas utilizadas....................................................................................47
3.3.1.1 Plataforma Eclipse ........................................................................................................47
3.3.1.1.1 Plugin MyEclipse.....................................................................................................48
3.3.1.2 Framewok Struts...........................................................................................................48
3.3.2 Operacionalidade da implementação ..............................................................................50
3.3.2.1 Módulo Administrativo ................................................................................................51
3.3.2.2 Módulo Gerencial .........................................................................................................55
3.3.2.3 Módulo Analítico..........................................................................................................63
3.4 RESULTADOS E DISCUSSÃO ......................................................................................76
4 CONCLUSÕES..................................................................................................................78
4.1 EXTENSÕES ....................................................................................................................79
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................80
APÊNDICE A – Código fonte de uma tela JSP...................................................................82
APÊNDICE B – Dicionário de dados....................................................................................85
13
1 INTRODUÇÃO
Desenvolver produtos de software com qualidade nem sempre é uma tarefa muito
simples. Segundo Sommerville (2003, p. 117), em grandes sistemas de software os requisitos
estão constantemente sendo modificados, uma vez que esses sistemas são desenvolvidos para
lidar com problemas ‘intrincados’. O problema não pode ser inteiramente definido e os
requisitos são necessariamente incompletos. Durante o processo de software, a compreensão
sobre o problema está constantemente se modificando, e essas mudanças se refletem
diretamente nos requisitos.
Considerando a constante mudança dos requisitos de um software, existem hoje no
mercado várias ferramentas de apoio à gerência de requisitos. Entre as quais encontram-se o
Requisite Pro (IBM, 2003) e o Caliber (BORLAND CORPORATION, 2003). De forma geral,
estas ferramentas são completas, porém de alto custo1, o que as torna muitas vezes inviável.
Atualmente as empresas de software estão mudando suas formas de trabalho, para
alcançar os diversos níveis da certificação Capability Maturity Model Integration (CMMI).
Como mostra a Figura 1, o CMMI foi definido em cinco níveis de maturidade: Executado,
Gerenciado, Definido, Gerenciado Quantitativamente e Otimização. Os níveis 2 e 3 estão
diretamente relacionados com o gerenciamento de requisitos.
No nível Gerenciado, uma das áreas chave é a de Gerência de Requisitos, cuja função é
gerenciar os requisitos do projeto e identificar inconsistências entre os requisitos e os planos
do projeto. A área chave do nível Definido, que tem relação com a gerência de requisitos, é o
Desenvolvimento de Requisitos, que tem o propósito de produzir e analisar os requisitos de
cliente, produto e componentes de produto.
1 Por exemplo, a ferramenta Requisite Pro tem um custo de 2.120,00 dólares (IBM, 2003).
14
Fonte: adaptado de Volpe, Jomori e Zabeu (2003, p. 12)
Figura 1 – Representação dos níveis do CMMI
Para atender as recomendações previstas no CMMI mostra-se fundamental a utilização
de ferramentas de apoio. Aqui o foco será o estudo da área de Requisitos e criação de uma
ferramenta de fácil acesso e adoção.
1.1 OBJETIVOS
O objetivo deste trabalho é desenvolver uma ferramenta de apoio à gerência de
requisitos.
Os objetivos específicos do trabalho são:
a) atender as recomendações das áreas chaves Gerência de Requisitos (nível 2) e
Desenvolvimento de Requisitos (nível 3) do modelo CMMI;
b) permitir a gerência dos requisitos desde o seu cadastramento até a análise do
impacto de determinadas mudanças.
15
1.2 ESTRUTURA
O trabalho está dividido em quatro capítulos, cuja descrição segue.
O primeiro capítulo faz uma introdução, abordando de maneira macro o trabalho, sua
relevância, objetivo e o contexto no qual está inserido.
O segundo capítulo fundamenta teoricamente o trabalho, através de uma revisão
bibliográfica sobre Gerência de Requisitos, CMMI, Indicadores e Framework Struts.
O terceiro capítulo trata sobre a especificação e implementação da ferramenta, através
de seus requisitos, diagramas de casos de uso, descrição dos casos de uso primários,
arquitetura do software, diagrama de classes e diagrama de seqüência.
Por fim, tem-se a conclusão, focando os resultados do trabalho e as limitações da
ferramenta.
16
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são apresentados os principais conceitos abordados no trabalho,
incluindo gerência de requisitos, o modelo CMMI, indicadores e o framework Struts.
2.1 GERÊNCIA DE REQUISITOS
Segundo Sommerville (2003, p. 118), o gerenciamento de requisitos é o processo de
compreender e controlar as mudanças nos requisitos dos sistemas. O processo de
gerenciamento de requisitos é realizado em conjunto com outros processos da engenharia de
requisitos. Os processos de planejamento e levantamento inicial de requisitos devem iniciar ao
mesmo tempo, e o gerenciamento ativo dos requisitos inicia a partir do momento em que um
esboço da versão do documento de requisitos esteja disponível.
Segundo Oberg et al. (2001 p. 4), gerenciamento de requisitos pode ser definido como
um processo que estabelece e mantém a concordância entre o cliente e os desenvolvedores
durante as alterações dos requisitos do projeto, aproximando sistematicamente a elicitação,
organização e documentação dos requisitos de software. Além disso, a gerência de requisitos
controla também a evolução dos requisitos do sistema durante o seu desenvolvimento, seja na
constatação de novas necessidades, seja por constatação de deficiência nos requisitos
registrados até o momento.
Para Hazan (2003 p. 33), a gerência de requisitos é um processo que se desenvolve em
paralelo a elicitação, modelagem e análise dos requisitos, conforme Figura 2.
17
Fonte: Hazan (2003 p. 33) Figura 2 – Processo de Gerência de Requisitos
As principais preocupações da gerência de requisitos são: gerenciar mudanças nos
requisitos acordados; gerenciar os relacionamentos entre os requisitos; gerenciar as
dependências entre o documento de requisitos e outros documentos produzidos ao longo do
processo. Estas preocupações da gerência de requisitos visam apoiar a identificação, controle
e rastreamento dos requisitos, bem como o tratamento das mudanças dos requisitos. É
possível analisar os impactos que uma determinada mudança, em um requisito, pode causar
nos demais requisitos do sistema, uma vez que se tem mapeado suas dependências.
Durante o desenvolvimento da definição dos requisitos, tem-se uma melhor
compreensão das necessidades dos usuários, causando modificações nos requisitos.
Segundo Sommerville (2003, p. 118), considerando uma perspectiva de evolução, os
requisitos são divididos em duas classes:
a) requisitos permanentes: são os requisitos relativamente estáveis, que derivam da
atividade principal da organização e que se relacionam diretamente com o domínio
do sistema.
b) requisitos voláteis: são os requisitos que vão se modificar durante o
desenvolvimento do sistema ou depois que o sistema estiver em operação.
De acordo com, Sommerville (2003, p. 119), o primeiro estágio essencial ao processo
de gerenciamento de requisitos, que é muito dispendioso, é planejar, e para cada projeto, este
estágio de planejamento estabelece o nível de detalhes exigido para o gerenciamento dos
Gerência
Elicitação
Modelagem
Análise
Validação Verificação
18
requisitos. Existem muitas relações entre requisitos e outros requisitos e o projeto do sistema.
Há também elos entre os requisitos e as razões básicas da proposição desses requisitos. Ao
serem propostas modificações, é necessário analisar o impacto dessas mudanças sobre os
outros requisitos e o projeto do sistema. A facilidade de rastreamento é uma propriedade geral
de uma especificação de requisito, que reflete a facilidade de se encontrar requisitos
relacionados.
A matriz de rastreabilidade é uma ferramenta que proporciona viabilidade ao
rastreamento e ao relacionamento dentro e entre os requisitos. Segundo Hazan e Leite (2003,
p. 12), a rastreabilidade facilita a comunicação entre as pessoas envolvidas no projeto,
reduzindo os problemas decorrentes de falhas de comunicação. Os módulos que aparecem
com mais freqüência na matriz de rastreabilidade podem ser alvos para serem desenvolvidos
inicialmente e realizar-se um exame cuidadoso nos testes.
2.2 CMMI
Segundo Marciniuk (2000 apud THEILACKER Jr 2000), a partir de 1991, com a
publicação do modelo CMM para software pelo SEI, outros modelos CMM foram publicados
para outras disciplinas, incluindo engenharia de sistemas, aquisição de software,
gerenciamento de RH e desenvolvimento integrado de produto e processo. Estes modelos se
apresentaram bastantes úteis para as organizações, porém a proliferação dos mesmos trouxe
algumas conseqüências negativas. Entre elas destaca-se o fato de que muitos desses modelos
se sobrepõem ou até mesmo se contradizem; suas diferenças tornam-nos difíceis e caros de
serem utilizados concorrentemente. Tais diferenças, incluindo arquitetura, conteúdo e
abordagem têm limitado a habilidade das organizações em desenvolver com sucesso seus
programas de melhoria.
19
Devido a estes e outros fatores, foi desenvolvido o modelo CMMI-SE/SW. O CMMI-
SE/SW não é apenas uma reunião dos modelos CMM existentes, mas sim um framework que
acomoda diferentes disciplinas e é flexível de forma a suportar duas representações diferentes
(de estágios e contínuo), que será explicada mais à frente ainda nesta seção.
O propósito do modelo CMMI é apresentar recomendações para melhorar os processos
organizacionais e a habilidade de gerenciar o desenvolvimento e a manutenção dos produtos
de software, através da verificação do status da melhoria de processos, do estabelecimento de
prioridades para melhoria e da implementação desses processos.
O projeto foi construído para atingir um conjunto inicial de modelos que cobrem três
disciplinas: engenharia de software, engenharia de sistemas e desenvolvimento integrado de
produto e processo. Conforme Masters (2000 apud THEILACKER Jr 2000), os modelos
existentes escolhidos para serem utilizados como fonte primária para o conjunto inicial de
modelos CMMI são SW-CMM v2.0 draft C, IPD-CMM v0.98, cada qual cobrindo uma das
disciplinas citadas anteriormente.
Segundo Volpe, Jomori e Zabeu (2003, p. 14), os principais objetivos do CMMI são:
a) redução de custo na implementação de melhoria de processo multidisciplinar
baseado em modelo;
b) eliminação de inconsistências e diminuição das duplicações;
c) aumento da claridade e compreensão do modelo, através de uma terminologia
comum, estilo consistente, regras de construção uniformes e componentes comuns;
d) necessidade de assegurar aos produtos desenvolvidos a consistência com a norma
ISO 15504.
Com isso, os principais objetivos apontados são uma eficiente e efetiva avaliação e
melhoria através da disciplina de múltiplos processos em uma organização, custos de
treinamento e avaliação reduzidos, uma visão comum e integrada de melhoria para todos os
20
elementos de uma organização.
Conforme Masters (2000 apud THEILACKER Jr 2000), uma organização possui duas
abordagens para alcançar a melhoria de processo: capacitação de processo e/ou maturidade
organizacional. O modelo CMMI suporta a capacitação de processo através de uma
representação contínua e a maturidade da organização através de uma representação por
estágios.
A representação por estágios é uma evolução do modelo CMM e tem seu enfoque na
melhoria do processo de forma estruturada. Nesta representação, as áreas de processo foram
divididas em cinco níveis de maturidade.
Segundo Volpe, Jomori e Zabeu (2003, p. 18), a representação contínua está alinhada a
norma ISO/IEC 15504 devido à organização idêntica das áreas de processo, que estão
divididas em quatro categorias: Gerência de Processo, Gerência de Projeto, Engenharia e
Suporte. Esta representação visa melhorar o desempenho em várias áreas de acordo com o
objetivo de negócio da organização. Seis níveis de capacidade são utilizados para medir as
melhorias.
A figura 3 apresenta a estrutura do modelo CMMI, para ambas as representações
suportadas: estágios e contínua.
Cada nível de maturidade do modelo CMMI, com exceção do primeiro, é constituído
por várias áreas-chave de processo. A definição de cada área-chave está organizada em cinco
seções denominadas características comuns. As características comuns contêm práticas-chave
que descrevem a infra-estrutura ou atividades para se atingir as metas de cada área-
chave.(SEI, 2003)
Segundo THEILACHER Jr(2000, p. 25), as áreas-chave de processo constituem a
primeira divisão sistemática dentro dos níveis de maturidade. Identificam um grupo de
atividades relacionadas, que, quando executadas em conjunto satisfazem um grupo de metas
21
relevantes para a melhoria da capacitação do processo. Para que uma determinada área-chave
de processo seja alcançada, as práticas-chave que descrevem atividades ou infra-estrutura
precisam estar em uso rotineiro.
Como este trabalho teve seu foco direcionado ao desenvolvimento de uma ferramenta
de Gerência de Requisitos procurando atender as especificações do modelo CMMI na área de
Gerência, optou-se pela representação por estágios do modelo CMMI para aprofundar os
estudos.
Fonte: adaptado de Porro (2002, p. 8) Figura 3 – Representação dos Modelos do CMMI
A representação por estágios do CMMI está dividida em cinco níveis de maturidade
como segue:
a) nível 1: Executado – Inicial;
b) nível 2: Gerenciado - Gerenciamento Básico de Projeto;
c) nível 3: Definido - Padronização de Processo;
d) nível 4: Gerenciado Quantitativamente;
e) nível 5: Otimização - Melhoria Contínua de Processo.
Cada nível de maturidade está divido em várias áreas chaves. Sendo que duas áreas
Estágios Contínua
Área de Processo
Nív
el d
e C
apac
idad
e
22
chaves desta representação do modelo CMMI estão diretamente relacionadas à Gerência de
Requisitos que são: a área de gerência de requisitos e a área de desenvolvimento de requisitos.
A gerência de requisitos é uma área do nível Gerenciado. Para alcançar esta área é necessário
que os requisitos sejam gerenciados e as inconsistências com planos de projeto e produtos de
trabalho sejam identificadas. A área de desenvolvimento de requisitos é uma subdivisão do
nível Definido, cuja meta é desenvolver requisitos de clientes, desenvolver requisitos de
produtos, analisar e validar os requisitos.
2.2.1 Áreas Chaves
São apresentadas a seguir as duas áreas chaves do CMMI relacionadas diretamente ao
tema deste trabalho. O intuito destas duas áreas de processo, gerenciamento de requisitos e
desenvolvimento de requisitos, é possibilitar que o conjunto de requisitos alcançado atenda as
necessidades do cliente, permitindo ainda que sejam gerenciáveis, possibilitando assim uma
diminuição nos riscos de desenvolvimento.
O propósito da área de Gerência de Requisitos é gerenciar os requisitos dos produtos
do projeto e seus componentes e identificar inconsistências entre os requisitos, os planos de
projeto e os produtos de trabalho. O objetivo específico é gerenciar requisitos, para isso o
projeto deve manter um conjunto de requisitos atualizados e aprovados (SEI, 2003). As
práticas a serem seguidas nesta área são:
a) obter um entendimento dos requisitos: desenvolver um entendimento do
significado dos requisitos com os fornecedores;
b) obter comprometimento com requisitos: obter um comprometimento dos
participantes do projeto com os requisitos acordados;
c) gerenciar mudanças de requisitos: gerenciar as mudanças de requisitos, conforme
23
estes evoluam no decorrer do projeto;
d) manter rastreabilidade bi-direcional de requisitos;
e) identificar inconsistências entre artefatos do projeto e requisitos.
O propósito da área-chave Desenvolvimento de Requisitos é produzir e analisar os
requisitos de cliente, produto, e componentes de produto (SEI, 2003).
Esta área-chave possui três objetivos específicos como segue:
a) desenvolver requisitos de cliente: necessidades de stakeholder, expectativas,
constrangimentos e interfaces são coletadas e traduzidas em requisitos de cliente;
b) desenvolver requisitos de produto: requisitos de clientes são refinados e elaborados
para desenvolver os requisitos de produto e componentes de produto durante o
ciclo de vida do produto;
c) analisar e validar os requisitos: os requisitos são analisados e validados, e uma
definição da funcionalidade exigida é desenvolvida.
2.3 INDICADORES
Segundo Hazan e Leite (2003, p. 5), um indicador é um dado numérico, expresso em
uma unidade de medida, ao qual se atribui uma meta e que é trazido periodicamente à atenção
dos gestores dos processos, com a finalidade de apoiá-los na avaliação do desempenho.
Deve-se selecionar um conjunto de métricas pequeno e equilibrado, que irá ajudar a
organização a acompanhar o progresso na direção de seus objetivos. O método Goal Question
Metric (GOAL), é utilizado para definir as métricas apropriadas aos seus objetivos.
Segundo Hazan e Leite (2003, p. 8), a aplicação do método GOAL inicia-se com a
seleção de alguns objetivos de medição. As fontes para os objetivos podem ser necessidades
gerenciais, técnicas, de projeto, de produto, ou de implementação do processo. Declaram-se
24
os objetivos de modo que sejam quantificáveis e mensuráveis. Depois, para cada objetivo,
identificam-se as perguntas que precisam ser respondidas para determinar se o objetivo está
sendo alcançado. Finalmente, identificam-se as métricas que ajudam a responder cada
pergunta.
A seguir são descritos os indicadores de estabilidade e rastreabilidade, que foram
implementados neste projeto.
2.3.1 Indicadores de Estabilidade
Mudanças em requisitos ocorrem enquanto os requisitos estão sendo elicitados,
analisados e após o sistema ter sido implantando. Com isso, uma boa prática é a antecipação
das mudanças de requisitos, que envolve classificar os requisitos para identificar os mais
voláteis e prever possíveis mudanças. Estas informações são úteis para projetar o sistema de
forma que os requisitos sejam implementados com independência de componentes, para
minimizar a influência das mudanças no sistema.
Os principais objetivos, perguntas e métricas relativas à estabilidade de requisitos são
os descritos no Quadro 1.
Fonte: Porro (2002, p. 8) Quadro 1 – Métricas relativas à estabilidade
25
Segundo Hazan e Leite (2003, p. 10), em um sistema de indicadores é essencial que os
indicadores sejam relacionados para o fornecimento de subsídios para a tomada de decisões
baseadas em dados integrados. O Indicador de Estabilidade deve ser correlacionado com os
indicadores de tamanho, de esforço, de custo e de cronograma, pois os mesmos apóiam o
Planejamento e o Acompanhamento do Projeto, visto que a implementação dos requisitos
modificados influencia no tamanho do projeto, demanda esforço, e conseqüentemente possui
tempo de cronograma e custos adicionais.
2.3.2 Indicadores de Rastreabilidade
Segundo Hazan e Leite (2003, p. 11), a rastreabilidade fornece uma assistência
fundamental ao entendimento dos relacionamentos que existem entre os requisitos.
Na evolução do sistema a rastreabilidade apóia a referência cruzada entre as
especificações de requisitos e as de projeto. Os rastros ajudam na identificação do tamanho da
mudança solicitada. Quando mudanças nos requisitos emergirem, uma análise de impactos
deve ser executada, visando verificar a viabilidade de implementação.
Segundo Hazan e Leite (2003, p. 14), a matriz de rastreabilidade é uma ferramenta que
proporciona visibilidade ao rastreamento e ao relacionamento dentro e entre os requisitos,
desenho, código e casos de teste. A rastreabilidade facilita a comunicação entre as pessoas
envolvidas no projeto, reduzindo os problemas decorrentes de falhas na comunicação. Os
módulos que aparecem com mais freqüência na matriz de rastreabilidade podem ser alvos
para serem desenvolvidos inicialmente e realizar-se um exame cuidadoso nos testes.
26
2.4 FRAMEWORK STRUTS
Segundo Cavaness (2003, p. 11) framework é um conjunto de classes e interfaces que
cooperam para resolver um tipo de problema de software. Um framework, em geral, apresenta
as seguintes características:
a) é composto por múltiplas classes ou componentes, cada um devendo prover uma
abstração de um conceito particular;
b) define como essas abstrações trabalham juntas para resolver um problema;
c) seus componentes são reusáveis;
d) organiza padrões em alto nível;
e) um bom framework deve prover um comportamento genérico que diversas
aplicações fazem uso.
O framework Struts, recebeu este nome para lembrar das bases que mantêm as casas,
prédios, pontes e na verdade, as pessoas mesmo quando estão com pernas de pau. Ao elevar
as estruturas físicas, os engenheiros da construção usam suportes para fornecer sustentação
para cada piso de um prédio. Do mesmo modo, os engenheiros de software usam o Struts para
suportar cada camada de uma aplicação comercial.
Segundo Husted (2004, p. 4), o Struts é mantido pela Apache Software Foundation
(ASF) como parte de seu projeto Jakarta. A base de código inicial do Struts foi desenvolvida
entre maio de 2000 e junho de 2001 quando a versão 1.0 foi lançada. Sua base de código é
gerenciada por uma equipe voluntária de “Membros”.
O Struts é um software de fonte aberta que ajuda os desenvolvedores a construírem aplicações web rápida e facilmente. O Struts conta com tecnologias padrões – como o JavaBeans, servlets Java e JavaServer Pages (JSP). Adotando uma abordagem baseada em padrões e do tipo “preencha as lacunas” para o desenvolvimento do software, o Struts pode aliviar grande parte do trabalho pesado e demorado que vem com todo projeto novo. (HUSTED, 2004, p. 4).
O Struts favorece o desenvolvimento de aplicações seguindo o paradigma
27
Model/View/Controller (MVC). Ele fornece um componente Controller e se integra a outras
tecnologias para oferecer suporte aos componentes Model (como JDBC, EJB’s, etc.), e View
(como JSP, etc.).
Segundo Husted (2004, p. 29), o controlador Struts é um conjunto de componentes que
permitem aos desenvolvedores definir exatamente como sua aplicação interage com o usuário.
A seguir é apresentado o que o Struts oferece para camada do MVC.
2.4.1 Componentes Model
Os componentes Model englobam dois conceitos: a lógica de negócio da aplicação e
seu estado. As tecnologias utilizadas nessa camada, além do Struts, são JavaBeans, e
freqüentemente, Enterprise JavaBeans e JDBC.
Segundo Husted (2004, p. 35), o Struts oferece para esta camada os chamados
ActionForm beans, ou, mais comumente chamados, form-beans. Form-beans são classes Java
que estendem ActionForm e se integram a um formulário de entrada de dados em sua
aplicação. O conceito dos form-beans é simples: são JavaBeans que contém uma propriedade
para cada campo de seus formulários HTML, com seus respectivos métodos getters e setters.
Os form-beans não implementam qualquer método, exceto reset e validate, servindo para
limpar o conteúdo do formulário e validar seus dados, respectivamente.
Através de outras tecnologias, como, Enterprise JavaBeans e JDBC, por exemplo,
deverá ser construída a lógica de negócio da aplicação.
2.4.2 Componentes View
Os componentes View representam a visão da aplicação, ou seja, a maneira como o
28
sistema interage com o usuário. A tecnologia mais comumente utilizada nessa camada é Java
Server Pages.
Nessa camada, o Struts oferece suporte a dois importantes aspectos:
internacionalização e construção de interfaces JSP através de custom tag’s.
Para permitir a internacionalização, é necessário que se crie, sob o diretório WEB-
INF/resources da aplicação, um arquivo chamado ApplicationResources.properties, que
conterá mensagens para a linguagem padrão do seu servidor. As mensagens são colocadas nos
arquivos através de strings simples, como:
app.cliente.nome=Nome do cliente
Para possibilitar que se crie mensagens em outras linguagens, é necessário criar o
arquivo ApplicationResources_xxx.properties, onde xxx será o nome ISO da linguagem a ser
utilizada.
Segundo Cavaness (2003, p. 15), outro importante recurso é a disponibilidade de
custom tag’s do Struts, que permitirá, além da utilização dos arquivos de internacionalização,
uma série de funcionalidades, que, na grande maioria dos casos, dispensará a utilização de
código Java dentro da página (aliás, esse é um dos objetivos da arquitetura MVC, pois o fluxo
de controle e lógica de negócio da aplicação não devem estar na camada de visão). Além
disso, a extensibilidade de Java permite que o próprio desenvolvedor crie suas próprias
custom tag’s, que, aliás, é uma tarefa bastante simples.
As custom tag’s do Struts são divididas em quatro bibliotecas:
a) html: a biblioteca de tags struts fornece um conjunto de 20 tags para ajudar a
preencher previamente os controles html e os elementos afins;
b) logic: são geralmente usadas para fornecer versões alternativas das mesmas
páginas de apresentação;
c) bean: permite a criação e manipulação de JavaBeans dentro da página;
29
d) extensões de tags: as tags são escritas em java usando a API de extensão de tags.
As classes designadas para analisar uma tag no formato XML e usar as
propriedades da tag como parâmetros para os métodos da classe. Ou seja, as
extensões de tags permitem que se chamem métodos java utilizando sintaxe xml.
Para utilizar as tags, é preciso seguir 3 etapas: Adicionar os arquivos JAR e TLD,
atualizar o web.xml e importar a biblioteca para a página jsp que irá utilizá-la.
2.4.3 Componentes Controller
Segundo Cavaness (2003, p. 18), os componentes Controller são responsáveis pelo
fluxo da aplicação. O principal componente Controller do Struts é a ActionServet, que é uma
extensão de Servlet, exercendo o papel de controlador principal da aplicação. Sua principal
função é fazer o mapeamento das requisições do servidor.
Para isso, é necessário criar um arquivo de configuração, denominado struts-
config.xml, que é usado para mapear a navegação da aplicação. Depois disso, deverão ser
criadas as classes Action (que são extensões da classe Action do Struts), que conterão as ações
a serem executadas a cada requisição. O objetivo da classe Action é processar a requisição e
retornar um objeto da classe ActionForward que identifica para qual componente de visão
(normalmente uma página JSP) será gerada a resposta. As classes Action são compostas de
um único método, com a assinatura public ActionForward execute(ActionMapping mapping,
ActionForm form, HttpServletRequest request, HttpServletResponse response) throws
IOException, ServletException, que será invocado quando a ActionServlet receber a
requisição e processá-la.
30
2.5 TRABALHOS CORRELATOS
Foram analisados três trabalhos correlatos: o primeiro cujo objetivo foi desenvolver
uma ferramenta de apoio aos processos da engenharia de requisitos, o segundo, um Trabalho
de Conclusão de Curso cujo objetivo foi desenvolver uma ferramenta de gerência de
requisitos, e o terceiro apresenta uma análise de uma organização de software utilizando
CMMI/SEI v1.0.
No primeiro trabalho citado, Zanrolenci e Burnett (2004) desenvolveram uma
ferramenta de apoio aos processos da engenharia de requisitos, nas fases de projetos, cujo
objetivo principal é identificar os requisitos e referenciá-los em todas as fases dos processos
de requisitos.
Outro trabalho de desenvolvimento relacionado à gerência de requisitos é descrito em
Marquardt (2004), que apresenta a implementação de uma ferramenta utilizando a linguagem
Personal Home Page (PHP) com o intuito de auxiliar os desenvolvedores de sistemas a
gerenciar os requisitos de software, a partir das atividades típicas de gerenciamento de
requisitos. Porém, o foco de aplicação da ferramenta foi essencialmente acadêmico. Neste
trabalho não foram enfatizados requisitos, como a política de gerência, nem aprofundados
aspectos de rastreabilidade. Esta ferramenta serviu como base para o desenvolvimento do
presente trabalho, sendo que a ferramenta desenvolvida neste trabalho será adequada ao
modelo CMMI e terá uma ênfase maior no aspecto de rastreabilidade e análise de impacto.
O terceiro trabalho fez a análise de uma organização de software utilizando o modelo
CMMI/SEI v1.0. Para auxiliar na análise foi desenvolvida uma ferramenta informatizada,
facilitando a coleta das respostas e emitindo relatórios sobre os resultados e níveis de
atendimentos das metas e áreas-chave de processo (THEILACKER Jr, 2000).
31
Todos os três trabalhos pesquisados foram úteis no desenvolvimento da ferramenta.
Além disso, permitiram um melhor entendimento das funcionalidades básicas de
gerenciamento de requisitos e da estrutura do modelo CMMI.
32
3 DESENVOLVIMENTO DO TRABALHO
Neste capítulo é apresentado o desenvolvimento da ferramenta de Gerência de
Requisitos incluindo os requisitos, a especificação, a implementação e os resultados.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA
A ferramenta desenvolvida deverá auxiliar gerentes de projeto e analistas a gerenciar
os requisitos de software, a partir das atividades típicas de gerenciamento de requisitos. O
foco da aplicação é atender algumas exigências do CMMI relacionadas a esta área.
Os requisitos funcionais apresentam as principais características da camada de negócio
da ferramenta. São requisitos funcionais da ferramenta:
a) criar projetos: o sistema deve permitir a criação do projeto;
b) manter usuários: o sistema deve permitir a inclusão/alteração/exclusão de usuários;
c) manter tipos de requisitos: o sistema deve permitir a inclusão/alteração/exclusão
de tipos de requisitos que serão utilizados nos projetos;
d) manter atributos: o sistema deve permitir a inclusão/alteração/exclusão de atributos
que serão associados aos tipos de requisitos;
e) manter vínculos: o sistema deve permitir a inclusão/alteração/exclusão de vínculos
entre os tipos de requisitos;
f) manter projetos: o sistema deve permitir a inclusão/alteração/exclusão dos projetos
previamente criados;
g) registrar uma política para gerência de requisitos: o sistema deve permitir a criação
de um documento que descreva as regras de gerência de requisitos da empresa,
para que todos os usuários tenham acesso;
33
h) manter acessos: o sistema deve permitir a inclusão/alteração/exclusão de acessos
de escrita ou leitura aos analistas;
i) manter glossário: o sistema deve permitir a inclusão/alteração/exclusão do
glossário dos projetos;
j) manter requisitos: o sistema deve permitir a inclusão/alteração/exclusão dos
requisitos dos projetos ;
k) registrar alterações dos requisitos: o sistema deve permitir a
inclusão/alteração/exclusão de solicitações de alteração para os requisitos;
l) registrar e representar a relação de dependência entre os requisitos: o sistema deve
gerar uma matriz de rastreabilidade para representar a relação de depenência;
m) permitir visualização do impacto de alterações no requisitos: o sistema deve
apresentar o requisito a ser alterado e os requisitos que tem dependência do
mesmo;
n) disponibilizar a rastreabilidade do requisito;
o) gerar indicadores, para verificar a volatilidade dos requisitos.
Durante o levantamento dos requisitos funcionais, percebeu-se uma distinção nas
atividades desenvolvidas pelo gerente do projeto durante o gerenciamento dos requisitos das
atividades desenvolvidas pelo analista, gerando a necessidade de dividir a ferramenta em
módulos.
Um módulo principal denominado “Administrativo” será utilizado pela pessoa
responsável pela ferramenta. Essa será a única pessoa com permissão para fazer o cadastro
inicial dos projetos e o cadastro de novos usuários.
Um segundo módulo denominado “Gerencial”, será utilizado pelos gerentes de
projetos, que são definidos pelo Administrador ao cadastrar um projeto novo. Os gerentes são
os responsáveis por manter os cadastros de Tipos de Requisitos, Atributos, Vínculos e por
34
manter os projetos dos quais são responsáveis cadastrando uma Política de Gerência de
Requisitos para cada projeto e associando os vínculos, previamente cadastrados, que deseja
utilizar no projeto. O gerente deve ainda, configurar os acessos dos analistas nos projetos,
liberando acesso de leitura ou escrita. O gerente também pode visualizar os indicadores do
projeto, para verificar a volatilidade dos requisitos em um determinado período.
O terceiro módulo denominado “Analítico” será utilizado pelos analistas, ficando sob
responsabilidade deste, o cadastro do Glossário do projeto e o cadastro e manutenção dos
Requisitos e suas dependências. Neste módulo, pode-se emitir um relatório para analisar o
impacto das alterações dos requisitos, visualizar a rastreabilidade ou ainda listar os requisitos
de um projeto.
Os requisitos não-funcionais da ferramenta são:
a) utilizar linguagem Java Server Pages (JSP) e o framework Struts para o
desenvolvimento;
b) disponibilizar o sistema através da Web;
c) utilizar banco de dados MySQL, para armazenar as informações referentes aos
projetos e requisitos;
d) permitir privilégios diferenciados entre os usuários, para cada projeto
(administrador, leitura/alteração, somente leitura);
e) atender as recomendações do CMMI (nível 2 e 3).
3.2 ESPECIFICAÇÃO
A especificação da ferramenta foi baseada na UML, que segundo Sintes (2002, p.178)
é uma linguagem de modelagem padrão, que consiste em várias notações gráficas que podem
ser utilizadas para descrever a arquitetura inteira de um software.
35
3.2.1 Diagrama de Casos de Uso
Os casos de uso representam a interação do usuário com o sistema, destacando as
ações que serão realizadas. A seguir, os casos de uso do sistema são detalhados. A Figura 4
demonstra o diagrama dos casos de uso do sistema.
3.2.1.1 Criar projeto
O administrador irá cadastrar um projeto informando uma sigla e nome para o novo
projeto e indicando um usuário previamente cadastrado como gerente do projeto.
3.2.1.2 Manter usuários
O administrador poderá cadastrar um novo usuário, informando nome, login, senha
inicial e indicando se este usuário também será administrador do sistema. O administrador
poderá ainda consultar, alterar ou excluir usuários já cadastrados no sistema.
3.2.1.3 Manter política de gerência
O gerente do projeto poderá cadastrar a política de gerência de requisitos do seu
projeto, para possível consulta dos analistas.
36
Figura 4– Relação entre Casos de Uso e Atores do Sistema
37
3.2.1.4 Manter tipos de requisitos
O Gerente de projeto poderá fazer o cadastro dos tipos de requisitos, informando nome
e tag. O gerente poderá ainda consultar os tipos de requisitos cadastrados e alterar/excluir os
tipos que ainda não estiverem associados a um requisito.
3.2.1.5 Manter atributos
O gerente poderá cadastrar novos atributos informando, nome do atributo e tipo (texto,
lista de valores). O gerente poderá ainda consultar os atributos cadastrados e alterar/excluir
atributos ainda não associados a requisitos do projeto.
3.2.1.6 Manter vínculos
O gerente poderá cadastrar tipos de vínculos que serão disponibilizados para os
projetos. Para isso, o gerente deve selecionar um tipo de requisito origem e o tipo de requisito
destino. O gerente poderá listar os vínculos cadastrados e alterar/excluir vínculos ainda não
associados a projetos.
3.2.1.7 Manter projeto
O gerente poderá alterar a sigla ou nome dos projetos aos quais está associado como
Gerente, e deverá fazer a associação dos vínculos que deseja liberar para estes projetos e
informar a produtividade do mesmo. Poderá também consultar ou excluir os projetos sob sua
responsabilidade.
38
3.2.1.8 Liberar acesso ao projeto
O Gerente deverá liberar acesso aos analistas previamente cadastrados pelo
Administrador do sistema, aos seus projetos. Pode ser liberado acesso de leitura ou escrita.
3.2.1.9 Manter glossário
O analista poderá cadastrar novas palavras no glossário, informando a palavra e sua
respectiva descrição. O mesmo poderá ainda alterar, consultar e excluir palavras do glossário.
Este cadastro é feito por projeto.
3.2.1.10 Manter requisitos
Após o gerente ter liberado acesso a um determinado projeto ao Analista, o mesmo
poderá consultar/incluir/alterar/excluir requisitos deste projeto, sendo que para incluir um
novo requisito deverá informar, nome do requisito, seu tipo (a partir de uma lista pré-definida
pelo gerente), seus atributos (pré-definidos pelo gerente), e alguns indicadores para futuras
consultas. Para alterar ou excluir um requisito é necessário que tenha uma solicitação de
alteração em aberto para este requisito. Todas as solicitações de alteração são guardadas para
atender o Gerenciamento de Mudanças.
3.2.1.11 Manter solicitação de alteração
O analista poderá incluir uma nova solicitação de alteração, gerar a matriz de
rastreabilidade para verificar o impacto da alteração, aprovando ou rejeitando a solicitação.
39
Caso a solicitação seja aprovada, o mesmo poderá fazer a alteração no requisito e encerrar a
solicitação. Caso seja reprovada a solicitação será automaticamente encerrada.
3.2.1.12 Gerar relatório de requisitos
O analista informa o projeto do qual deseja visualizar as informações e uma listagem
com a última versão dos requisitos é gerada.
3.2.1.13 Gerar matriz de rastreabilidade
O analista informa o projeto do qual deseja visualizar as informações e uma listagem
com os requisitos e seus vínculos será apresentada.
3.2.1.14 Visualizar indicadores
O analista poderá visualizar os indicadores do projeto com relação aos percentuais de
alteração dos requisitos em um determinado período.
3.2.1.15 Manter dependências
Com base nos vínculos pré-cadastrados o analista poderá inserir / alterar / consultar /
excluir as dependências existentes entre os requisitos do projeto.
40
3.2.1.16 Cadastrar Stakeholders
O analista poderá cadastrar os stakeholders dos projeto.
3.2.1.17 Manter entrevistas
O analista poderá manter as entrevistas feitas com os stakeholders dos projetos.
3.2.1.18 Visualizar histórico das alterações
O analista poderá visualizar as solicitações de alteração cadastradas para um
determinado projeto.
3.2.2 Diagrama de Classes
Em um sistema com programação orientada a objetos, as classes podem ser
consideradas o menor conjunto de informações que formam o grande sistema. O diagrama de
classes demonstra uma visão lógica de como as classes do sistema estão associadas. Também
é função do diagrama de classes demonstrar os atributos e métodos das classes do sistema.
A Figura 5 demonstra o diagrama das classes do sistema numa camada voltada ao
negócio da solução, abstraindo classes supérfluas para a camada de negócio, que seriam as
classes Action utilizadas para as telas, e o Apêndice B apresenta uma breve descrição dos
atributos de cada classe.
A classe “Usuario” é a classe inicial do sistema responsável por armazenar os usuários
que terão acesso ao sistema e os usuários que serão gerentes dos projetos.
41
A classe “Acesso” é referenciada pela classe projeto, e é responsável por controlar as
permissões de acessos dos usuários ao sistema.
A classe “Projeto” é a classe principal do sistema, a partir desta são referenciadas as
classes Acesso, Requisito e Vinculo. É responsável por armazenar as informações básicas
diretamente ligadas ao cadastro do projeto, uma listagem do Glossário do projeto, outra
listagem com os requisitos associados a cada projeto cadastrado, uma listagem dos vínculos
liberados pelos gerentes para cada projeto e uma listagem com os acessos dos usuários aos
projetos.
A classe “Vínculo” responsável por armazenar as informações dos vínculos
disponíveis no sistema para serem associados aos projetos.
A classe “Tipo Requisito” responsável por armazenar os tipos de requisitos que podem
ser utilizados para a criação de requisitos ou de vínculos.
A classe “Requisito” responsável por armazenar e manipular as informações dos
requisitos.
A classe “Atributo” responsável por armazenar e manipular as informações dos
atributos.
A classe “AssocAtributoRequisito” tem como objetivo armazenar o relacionamento
entre a classe Atributo e a classe Requisito, além do valor atribuído ao atributo em cada
relacionamento.
A classe “SolicitacaoAlteracao” tem como objetivo armazenar para histórico todas as
solicitações de alteração feitas para cada requisito.
A classe “Stakeholder” responsável por armazenar os stakeholders envolvidos em cada
projeto.
A classe “Entrevista” responsável por armazenar as entrevistar feitas com os
stakeholders para o levantamento inicial do problema a ser definido.
42
Além das classes demonstradas na camada de negócio utilizaram-se classes que
supriram algumas necessidades para se chegar ao resultado final. Na Figura 6, pode-se notar
um diagrama de classes demonstrando duas classes que implementam os métodos
relacionados a regras de negócio e consulta a base de dados. Foi necessária esta separação nas
classes devido á utilização do modelo MVC.
A classe GeralBusiness, é responsável pelas regras de negócio do sistema, ligando as
telas a base de dados. Nenhuma classe da área de visão acessa as classes de modelo sem
passar pela classe de negócio.
A classe GeralCursor, é responsável por executar as consultas de dados e retornar o
resultado para a classe de negócio, quando necessário, ou diretamente para a classe de visão.
43
Figura 5– Diagrama de Classe
44
Figura 6– Diagrama das Classes Business e Cursor
3.2.3 Diagrama de Seqüência
O diagrama de seqüência definido pela UML, também conhecido por realização de
caso de uso, tem a função de demonstrar como as instâncias de classe interagem entre si
relatando a troca de mensagem entre elas. Este tipo de diagrama faz parte da visão dinâmica
do projeto.
Por influência da modelagem ágil, procurando trazer resultados positivos e não
supérfluos, aplicou-se o diagrama de seqüência para exemplificar o funcionamento de uma
das telas do sistema, cadastrar requisito. A Figura 7 representa o diagrama de seqüência para
45
explicar o funcionamento da tela e cadastrar requisitos.
Figura 7– Diagrama de Seqüência
3.2.4 Ferramenta utilizada na especificação do trabalho
Para a especificação da ferramenta foi utilizada a ferramenta CASE Enterprise
Architect, descrita a seguir:
3.2.4.1 Enterprise Architect
O Enterprise Architect é uma ferramenta CASE para modelagem, construção e
manutenção de sistemas baseada na UML (SPARX, 2004).
Com o uso do Enterprise Architect foi possível dividir todo o projeto em três
principais visões:
46
a) visão de caso de uso;
b) visão lógica do projeto;
c) visão dinâmica do projeto.
A visão de caso de uso foi utilizada para controlar os requisitos do sistema, separando-
os em requisitos funcionais e não-funcionais. A partir dos requisitos, a ferramenta possibilitou
a criação dos casos de uso, destacando e classificando os atores relacionados. A Figura 8
demonstra um diagrama gerado pela ferramenta, que controla o requisito e o caso de uso que
trata o requisito.
Figura 8 – Rastreabilidade entre requisitos e casos de uso
A visão lógica do projeto foi utilizada para manter as classes modeladas e os
diagramas de classes. A ferramenta permitiu a geração de código fonte em Java.
47
A visão dinâmica teve como objetivo a utilização de um diagrama de seqüência para
descrever a troca de mensagens para um caso de uso.
3.3 IMPLEMENTAÇÃO
As seções seguintes descrevem as ferramentas e técnicas utilizadas para o
desenvolvimento do trabalho e a operacionalidade do sistema.
3.3.1 Técnicas e ferramentas utilizadas
Para a fase de desenvolvimento do sistema utilizaram-se ferramentas que muito
auxiliaram no decorrer do trabalho, mantendo todas as informações organizadas e
consistentes.
A seguir são descritas as funcionalidades utilizadas de cada ferramenta utilizada no
desenvolvimento do trabalho e algumas técnicas de desenvolvimento.
3.3.1.1 Plataforma Eclipse
Eclipse é um ambiente de desenvolvimento integrado e extensível que possibilitou a
codificação Java e JSP do sistema. Controle de projetos, compilação, depuração e execução
de programas Java são alguns de seus recursos.
Segundo Lozano (2003, p. 3), o eclipse foi criado pela IBM e é mantido pelo Eclipse
Consortium do qual fazem parte Nokia, Oracle, Red Hat, Borland e outras empresas do setor,
e é baseado em uma arquitetura de plugins.
Esta característica extensível da ferramenta possibilitou a instalação de plugins que
48
auxiliaram em atividades específicas dentro do desenvolvimento do trabalho. A seguir é
descrito o plugin utilizado no trabalho.
3.3.1.1.1 Plugin MyEclipse
MyEclipse é uma solução de plugin do Eclipse para aplicações Web, J2EE, JSP, XML,
Struts, JSF e Hibernate, é também uma inovação por oferecer recursos para os
desenvolvedores Java e J2EE.
Para este trabalho optou-se por este plugin, pois o mesmo tem recursos para JSP e
Struts.
3.3.1.2 Framewok Struts
Considerando que o Struts favorece o desenvolvimento de aplicações com o paradigma
MVC, a ferramenta desenvolvida neste trabalho seguiu este paradigma. A seguir são descritas
como foram implementadas as camadas do modelo MVC.
Na camada modelo, o Struts oferece os ActionForm que são JavaBeans que contém
uma propriedade para cada campo do formulário HTML, com seus respectivos métodos
getters e setters. O Quadro 2 demonstra um ActionForm utilizado na ferramenta.
Na camada de visão, o Struts oferece suporte a dois importantes aspectos:
internacionalização através do arquivo ApplicationResources.properties, que contém as
mensagens na linguagem padrão da aplicação, conforme Quadro 3, e a construção de
interfaces JSP através de custom tag’s. O Apêndice A demonstra como estas tag’s foram
utilizadas nesta implementação através do código fonte da tela de cadastro de usuários.
49
<form-bean name="InserirAlterarUsuarioForm" type="org.apache.struts.validator.DynaValidatorForm" dynamic="true" > <form-property name="codUsuar" type="java.lang.String" /> <form-property name="nomUsuar" type="java.lang.String" /> <form-property name="nomContaUsuar" type="java.lang.String" /> <form-property name="dscSenha" type="java.lang.String" /> <form-property name="dscSenhaConfirm" type="java.lang.String" /> <form-property name="dscSenhaNova" type="java.lang.String" /> <form-property name="flgAdmin" type="java.lang.String" /> <form-property name="dscAcao" type="java.lang.String" /> <form-property name="modulo" type="java.lang.String" /> <form-property name="usuario" type="br.com.requisiteWEB.model.bean.Usuario" /> </form-bean>
Quadro 2 – Exemplo de um ActionForm
usuario.msg.sucesso=Usuário {0} com sucesso. projeto.msg.sucesso=Projeto {0} com sucesso. tipoRequisito.msg.sucesso=Tipo Requisito {0} com su cesso. atributo.msg.sucesso=Atributo {0} com sucesso. vinculo.msg.sucesso=Vinculo {0} com sucesso. acesso.msg.sucesso=Acesso {0} com sucesso. politica.msg.sucesso=Politica {0} com sucesso. glossario.msg.sucesso=Glossario {0} com sucesso. senha.msg.sucesso=Senha {0} com sucesso. requisito.msg.sucesso=Requisito {0} com sucesso. solicitacao.msg.sucesso=Solicitação {0} com sucesso . senhaNovaConfirm=Senha nova e confirmação de senha diferentes ! senhaAtual=Senha atual inválida ! usuarioInvalido=Usuário inválido ! senhaNovaAtual=Senha Nova igual a senha Atual !
Quadro 3 – Parte do arquivo ApplicationResources.properties do sistema
Na camada de controle o principal componente do Struts é o ActionServlet, que tem
como função principal fazer o mapeamento das requisições do servidor. Para isso, foi
necessária a criação do arquivo struts-config.xml que é utilizado para mapear a navegação da
aplicação. O Quadro 4 demonstra o mapeamento dentro do struts-config de uma das
funcionalidades do sistema.
50
<!-- Inicio Definições das Actions de Usuario --> <action name="InserirAlterarUsuarioForm" path="/inserirUsuario" parameter="dscAcao" type="br.com.requisiteWEB.actions.UsuarioAction" input="/htdocs/programas/rw0001pi.jsp" scope="request" > <forward name="sucesso" path="/htdocs/programas/rw0001pa.jsp" contextRelative="true" />
<forward name="falha" path="/htdocs/programas/rw0001pi.jsp" contextRelative="true" />
</action> <action name="InserirAlterarUsuarioForm" path="/editarUsuario" parameter="dscAcao" type="br.com.requisiteWEB.actions.UsuarioAction" validate="false" scope="request" > <forward name="sucesso" path="/htdocs/programas/rw0001pa.jsp" contextRelative="true" /> <forward name="falha" path="/navegacao.do?target=editarUsuario" /> </action> <!-- Fim Definições das Actions de Usuario -->
Quadro 4 – Parte do arquivo struts-config.xml
3.3.2 Operacionalidade da implementação
Como visto nas seções anteriores, foi necessário dividir a ferramenta em três módulos.
Com isso é apresentada a seguir uma descrição detalhada das funcionalidades de cada
módulo, utilizando-se como exemplo um estudo de caso hipotético, de um sistema de reserva
de laboratórios, conforme Quadro 5, criado pelo professor na disciplina de Requisitos de
Software.
51
Os professores do campus IV da FURB usam os laboratórios de informática para ministrar algumas de suas aulas. Mas, para utilizar um laboratório, eles deve solicitar ao coordenador do curso que reserve um laboratório para seu horário. Ao reservar um laboratório, o coordenador leva em consideração outros fatores além da disponibilidade de um laboratório em determinado horário. É verificado também se o laboratório já possui instalado os softwares que serão utilizados pela disciplina. Além disso, os laboratórios com maior número de computadores são destinados preferencialmente às turmas com maior número de alunos. Há também disciplinas que possuem horário fixos em laboratórios, ou seja, as aulas são totalmente feitas em laboratório durante todo o semestre. Isto significa que determinados laboratórios em determinados horários já estão reservados para o professor. O coordenador também mantém registros destas disciplinas fixas em laboratórios para não reservar estes laboratórios para outros professores. As informações como o código da disciplina, dia da semana e horário, o professor e a sala da aula todas contidas no banco de dados do NI. Quando ocorre conflito, ou seja, um professor deseja reservar um laboratório já reservado por outro professor, este deve negociar com o professor para disponibilizar o laboratório.Se estes entraram em acordo e o professor ceder a reserva, o coordenador deve ser comunicado para atualizar seus registros. O coordenador matém todos os registros de reservas efetuadas em uma planilha eletrônica que contém o dia da reserva, o horário, nome do professor, disciplina e laboratório reservado. Através desta planilha, é feito todo o controle de reservas de laboratório, o que torna o processo lento, pois os professores precisam contatar o coordenador do curso para reservar um laboratório. Esta planilha de reservas fica disponível ao bolsista que controla as chaves e acessos dos laboratórios. O bolsista, antes de entregar a chavo ao professor, verifica na planilha se este reservou o laboratório, e então libera o laboratório para uso do professor. Para agilizar este processo, pretende-se desenvolver um sistema onde, tanto o controle realizado pelo coordenador do curso, como as reservas efetuadas pelos professores serão realizadas pela internet.
Quadro 5 – Estudo de Caso
A página inicial do sistema é a página de autenticação do usuário, conforme a Figura 9.
Nesta página deve-se informar a chave de acesso ao sistema, a senha e validar as informações
através do botão “Conectar”. Se a autenticação do usuário for bem sucedida, o usuário será
encaminhado para a página principal do sistema de acordo com o seu perfil de acesso.
3.3.2.1 Módulo Administrativo
Após autenticar o acesso, caso o usuário tenha perfil de Administrador, é apresentada a
página principal do módulo Administrativo, conforme Figura 10. A partir desta tela, o
administrador tem acesso a todas as funcionalidades deste módulo. As opções disponíveis no
52
menu são:
a) Projeto: cadastro inicial e listagem dos projetos;
b) Usuário: gerenciamento e listagem dos usuários.
Figura 9 – Tela de Autenticação
53
Figura 10 – Tela inicial do módulo Administrativo
Selecionando-se a opção Projeto do menu é apresentada a tela de cadastro inicial do
sistema, conforme Figura 11.
54
Figura 11 – Cadastro inicial de Projeto
Selecionando-se a opção Usuário do menu é apresentada a tela de cadastro de
Usuários, conforme Figura 12.
O Administrador do sistema pode acessar os outros módulos do sistema, clicando nos
botões apresentados no rodapé das páginas. Ao clicar no botão Gerencial o usuário será
encaminhado para a tela inicial deste módulo e clicando no botão Análise para a tela inicial
deste. Com isso o administrador terá acesso a outras funcionalidades do sistema, uma vez que
o menu está divido de acordo com o acesso de cada módulo. As funcionalidades do módulo
Gerencial e Analítico são descritas nas próximas seções.
55
Figura 12 – Tela de Cadastro de Usuários
3.3.2.2 Módulo Gerencial
Após autenticar o usuário, caso este tenha perfil de gerente, ou seja, esteja associado
como gerente de algum projeto pré-cadastrado pelo administrador, é apresentada a página
inicial deste módulo conforme Figura 13. A partir desta página o gerente tem acesso a todas
as funcionalidades deste módulo. As opções disponíveis no menu principal são:
a) atributos: manutenção dos atributos;
b) tipo de requisitos: manutenção dos tipos de requisitos ;
c) vínculos: manutenção dos vínculos entre tipos de requisitos;
d) projeto: alteração do cadastro inicial do projeto e associação dos vínculos;
e) acessos: manutenção dos acessos aos projetos sob responsabilidade do gerente;
f) atributos por tipo requisito: associação dos atributos aos tipos de requisitos e ao
56
projeto;
g) relatórios: parâmetros para execução dos relatórios do sistema;
h) senha: alteração da senha do usuário conectado ao sistema.
Figura 13 – Página inicial do módulo gerencial
Na opção Atributos, o gerente poderá fazer o cadastro dos atributos que pretende
utilizar nos requisitos. Estes atributos poderão ser utilizados em qualquer projeto cadastrado
no sistema, desde que associados a um tipo de requisito e ao projeto. Para isso o gerente será
encaminhado para tela conforme Figura 14. Caso o gerente cadastre um atributo do tipo “Lista
de Valores” o mesmo será encaminhado para a tela de cadastro dos valores da lista, conforme
Figura 15.
Selecionando a opção Tipo de Requisitos, o gerente será encaminhado para a tela de
cadastro, conforme Figura 16, onde o mesmo deverá cadastrar os possíveis tipos de requisitos
necessários para o seu projeto.
57
Figura 14 – Tela de cadastro de atributos
Figura 15 – Tela de cadastro de valores dos atributos
58
Figura 16 – Tela de cadastro de tipo de requisito
Selecionando a opção Vínculos o Gerente, será encaminhado para tela, conforme
Figura 17, onde poderá cadastrar os vínculos, ou seja, dependências entre tipos de requisitos
que serão associados ao projeto posteriormente. Sendo que os tipos de requisitos devem ter
sido previamente cadastrados conforme será descrito a seguir.
Na opção Projeto, o gerente será encaminhado para a tela de manutenção de Projeto,
conforme Figura 18. Nesta tela o usuário poderá escolher o projeto que deseja fazer alterações
desde que seja o gerente do mesmo, e associar os vínculos que deseja liberar para serem
utilizados neste projeto.
59
Figura 17 – Tela de cadastro de vínculos
Figura 18 – Tela de manutenção de projeto
60
Ao selecionar a opção política da tela de manutenção de projeto, será encaminhado
para tela de cadastro da política de gerência de requisitos, conforme Figura 19. Nesta tela o
gerente deverá informar os seguintes itens relacionados à política de gerência de requisitos:
finalidade do documento, escopo, organização e responsabilidades, ferramentas, ambiente e
infra do sistema a ser desenvolvido neste projeto e descrever o gerenciamento de mudanças de
requisitos.
Figura 19 – Tela de cadastro da política de gerência de requisitos
Ao selecionar a opção Acessos, o gerente será encaminhado para uma tela de
manutenção de acessos, conforme Figura 20. Nesta tela o gerente deverá selecionar o projeto
e o usuário ao qual deseja liberar acesso, este pode ser de leitura ou escrita.
61
Figura 20 – Tela de manutenção de acessos
Ao selecionar a opção atributo por tipo requisito o gerente será encaminhado para a
associação dos atributos aos tipos de requisitos, e estes ao projeto, conforme Figura 21. O
analista só conseguirá cadastrar os requisitos de acordo com esta associação previamente
cadastrada.
Ao selecionar a opção relatório o gerente será encaminhado para a tela de solicitação
de relatórios, conforme Figura 22, onde poderá optar pelo relatório que deseja executar, sendo
que a obrigatoriedade dos parâmetros depende do relatório selecionado.
62
Figura 21 – Tela de associação dos atributos ao tipo de requisito
Figura 22 – Tela de solicitação de relatórios
63
O resultado da execução dos relatórios será demonstrado no módulo Analítico, após a
criação dos requisitos, caso o gerente execute o relatório neste momento, será exibida uma
tela informando a inexistência de dados.
Ao selecionar a última opção deste módulo, o gerente será encaminhado para a tela de
alteração de senha, conforme Figura 23. Sendo que é considerada a chave do usuário
conectado ao sistema para a alteração de senha.
Figura 23 – Tela de alteração de senha
3.3.2.3 Módulo Analítico
Após autenticar o usuário, caso este tenha perfil de analista, ou seja, esteja no cadastro
de usuários, porém não seja administrador e não esteja associado a nenhum projeto como
gerente, o mesmo será encaminhado para a página inicial deste módulo conforme figura 24. A
64
partir desta página o analista tem acesso a todas as funcionalidades deste módulo. As opções
disponíveis no menu principal são:
a) stakeholders: manutenção dos stakeholders do projeto;
b) entrevistas: cadastro das entrevistas dos analistas com os stakeholders;
c) glossário: manutenção do glossário dos projetos;
d) requisitos: manutenção dos requisitos dos projetos;
e) solicitação de alteração: cadastros das solicitações de alteração para os requisitos;
f) relatórios: solicitação para execução dos relatórios disponíveis;
g) senha: alteração da senha do usuário conectado ao sistema.
Figura 24 – Tela inicial do módulo analítico
Ao selecionar a opção Stakeholders o usuário será encaminhado para tela de
manutenção dos stakeholders, conforme Figura 25, onde deve selecionar o projeto ao qual
deseja fazer os cadastros dos stakeholders.
65
Figura 25 – Tela de cadastro de stakeholders
Ao selecionar a opção Entrevistas o usuário será encaminhado para tela de cadastro das
entrevistas realizadas com os stakeholders, conforme Figura 26 onde deve selecionar o
projeto ao qual diz respeito à entrevista e o stakeholder que esta sendo entrevistado. Nesta tela
o analista poderá cadastrar as seguintes informações: quais os problemas do usuário, a
descrição do usuário com relação ao problema, o entendimento do analista com relação a
descrição do usuário, quais as expectativas do usuário com relação a confiabilidade e ao
desempenho do sistema a ser desenvolvido e um resumo do analista com relação a entrevista
em geral.
Ao selecionar a opção Glossário o usuário será encaminhado para tela de manutenção
das palavras do glossário, conforme Figura 27, onde deve selecionar o projeto ao qual deseja
fazer as manutenções.
66
Figura 26 – Tela de cadastro de entrevistas
Figura 27 – Tela de manutenção do glossário
67
Ao selecionar a opção Requisitos o usuário será encaminhado para tela de manutenção
de Requisitos, conforme Figura 28 e Figura 29. Nesta tela o usuário poderá cadastrar os
requisitos do projeto ao qual tem acesso para “escrita”, ou alterar as informações do requisito
caso tenha uma solicitação de alteração em aberto para o mesmo. O campo volátil é um
atributo dos requisitos que serve apenas para informação dos analistas. Com esta informação
eles podem avaliar se o projeto poderá ter muitas alterações ou não dependendo do índice de
requisitos voláteis.
Figura 28 – Tela de cadastro de requisitos
Ao cadastrar um requisito o usuário é encaminhado para a tela de alteração de
requisitos, onde poderá cadastrar as dependências do mesmo, conforme figura 30.
68
Figura 29 – Tela de cadastro de requisitos (2)
Figura 30 – Tela de cadastro das dependências do requisito
69
Ao selecionar a opção de Solicitação de Alteração, o usuário será encaminhado para
tela de cadastro da solicitação, conforme Figura 31, na qual deverá informar os dados da
solicitação, e caso a mesma seja aprovada o mesmo possa fazer as alterações no requisito.
Após cadastrar a solicitação de alteração o usuário pode visualizar a matriz de rastreabilidade
para verificar o impacto da alteração, conforme Figura 32.
Figura 31 – Tela de cadastro das solicitações de alteração dos requisitos
Ao clicar no botão de Visualizar Impacto o usuário será encaminhado para a tela de
resultado da matriz de rastreabilidade, conforme Figura 33.
70
Figura 32 – Tela de alteração das solicitações de alteração dos requisitos
Figura 33 – Matriz de Rastreabilidade do Requisito a ser alterado
71
Ao selecionar a opção relatório o gerente será encaminhado para a tela de solicitação
de relatórios, conforme Figura 34, onde poderá optar pelo relatório que deseja executar, sendo
que a obrigatoriedade dos parâmetros depende do relatório selecionado.
Figura 34 – Tela de execução de relatórios
Ao executar o relatório “Listagem dos Requisitos” o usuário é encaminhado para a tela
de resultado conforme Figura 35.
Ao executar o relatório “Rastreabilidade” o usuário é encaminhado para a tela de
resultado conforme mostrado anteriormente, porém com todos os requisitos do projeto.
Ao executar o relatório “Indicadores” o usuário é encaminhado para a tela de resultado
conforme Figura 36. Neste caso como todos os requisitos do projeto foram criados no período
indicado tem-se um percentual de inclusão de 100%, tem-se apenas uma solicitação de
alteração e conseqüente uma alteração de requisito neste período o que representa um
percentual de 2,44% e não teve nenhuma exclusão neste período.
Ao executar o relatório “Histórico das Alterações” o usuário é encaminhado para a tela
72
de resultado conforme Figura 37.
Figura 35 – Lista de Requisitos
Figura 36 – Indicadores
73
Figura 37 – Histórico de Solicitações de Alteração
Ao executar o relatório “Política de Gerência” o usuário é encaminhado para a tela de
resultado conforme Figura 38.
Ao executar o relatório “Documento de Requisitos” o usuário é encaminhado para a
tela de resultado conforme Figura 39.
A opção senha é a mesma do módulo Gerencial.
74
Figura 38 – Política de Gerência de requisitos
75
Figura 39 – Documento de requisitos
76
3.4 RESULTADOS E DISCUSSÃO
A etapa de testes do trabalho tratou de avaliar as classes do sistema em separado com a
utilização de testes de unidade. Não foi possível a execução dos testes de aceitação com os
alunos da disciplina de gerência de requisitos, ficando estes testes limitados a avaliação dos
casos de uso do sistema.
A seguir é apresentado o Quadro 6 confrontando as exigências do modelo CMMI com
os itens implementados neste trabalho. Como critério de avaliação foi utilizado “Atende”,
“Atende Parcialmente” e “Não Atende”. Sendo que cada item é detalhado a seguir.
Práticas Específicas - CMMI Ferramenta
Obter um entendimento dos requisitos Atende
Obter comprometimento com os requisitos Atende
Gerenciar mudanças de Requisitos Atende
Manter rastreabilidade bidirecional de requisitos Atende
Identificar inconsistências entre artefatos do projeto e requisitos Não Atende
Desenvolver requisitos de cliente Atende
Desenvolver requisitos de produto Atende
Analisar e Validar os requisitos Atende Parcialmente
Quadro 6 – Relação entre CMMI e a ferramenta desenvolvida
Obter um entendimento dos requisitos foi atendido através da implementação do
cadastro dos stakeholder, definindo assim os canais ou fontes oficiais dos quais são recebidos
os requisitos, e através do documento de gerenciamento das entrevistas com os stakeholder,
onde o analista pode colocar o seu entendimento sobre o requisito solicitado, e ter um parecer
do stakeholder.
77
Obter comprometimento com requisitos foi atendido através da avaliação de impacto
das mudanças e através do comprometimento junto a política de gerência cadastrada para cada
projeto.
A gerencia das mudanças de requisitos foi atendida através do status do requisito, do
histórico das solicitações de alteração de requisitos, da classificação do requisito quando a
volatibilidade e análise de impacto.
A manutenção da rastreabilidade bidirecional de requisitos foi atendida através da
matriz de rastreabilidade, que apresenta se o requisito já foi desenvolvido, se o mesmo está
pendente de análise, ou seja, algum requisito do qual depende foi alterado, e as suas
dependências.
O item de identificação das inconsistências entre artefatos de projeto e requisitos não
foi atendido pela ferramenta desenvolvida, pois o foco da ferramenta era trabalhar apenas com
os requisitos e não com os demais artefatos de projeto.
Os itens relacionados ao desenvolvimento dos requisitos de cliente e de produto foram
atendidos através do documento de gerenciamento das entrevistas com os stakeholders. Onde
o analista poderá cadastrar as expectativas e necessidades do usuário.
O item de Análise e validação dos requisitos foi atendida parcialmente através do
cadastro dos requisitos do projeto onde o analista pode aprovar ou não o mesmo, para ser
completamente atendida a ferramenta deveria ter um check-list para validação de padrões nos
requisitos levantados.
Após as análises feitas, dentro da expectativa sobre o que foi proposto, percebeu-se
que o objetivo foi alcançado.
78
4 CONCLUSÕES
A ferramenta especificada cumpriu os requisitos levantados, garantindo assim uma
solução que permite aos analistas de sistemas gerenciar os requisitos de projeto desde o seu
levantamento até o histórico de suas alterações.
Os objetivos do trabalho foram atendidos. A ferramenta atende parcialmente as
recomendações do modelo CMMI nas áreas 2 e 3 relacionadas a gerência de requisitos. Para
atender este objetivo foi implementado plano de gerência de requisitos, cadastro de
stakeholders, entrevistas com os stakeholders, entre outros. E a ferramenta permite a gerência
dos requisitos desde o seu cadastramento até a análise de impacto de determinadas mudanças,
como determinava o segundo objetivo do trabalho.
A tecnologia JSP e o framework Struts foram importantes durante o desenvolvimento
deste trabalho, para que fosse possível implementar a ferramenta ser utilizada via WEB.
Com relação à ferramenta desenvolvida em Marquardt (2004), que foi base para o
desenvolvimento deste trabalho, pode-se destacar os incrementos realizados neste novo
trabalho como o controle de alterações, através das solicitações de alteração, as métricas e o
levantamento de Stakeholders.
A ferramenta apresenta algumas limitações: com relação a controle de acesso que
poderia ser implementado por tela, hoje o controle é feito por projeto. A validação dos
requisitos poderia ser feita através de um check-list, a ferramenta atual apenas permite ao
analista alterar o status do requisito para aceito, porém a validação do mesmo não é feita pelo
sistema.. Os relatórios são gerados apenas na tela dificultando sua visualização e impressão. A
entrevista com os stakeholders poderia ser gerada dinamicamente de acordo com perguntas
cadastradas pelos gerentes de projeto ou pelos próprios analistas, hoje as informações que o
analista tem para preencher são fixas.
79
4.1 EXTENSÕES
Sugere-se como trabalhos futuros a implementação de um check-list para validação dos
requisitos e de uma forma de identificação das inconsistências entre artefatos de projeto e
requisitos, para atender todas as exigências do CMMI.
Sugere-se ainda uma melhoria na geração dos relatórios para que os mesmo possam ser
gerados em arquivos texto, facilitando a impressão das informações pelo usuário.
80
REFERÊNCIAS BIBLIOGRÁFICAS
BORLAND CORPORATION. CaliberRM : collaborative requirements management system. [S.l.], 2003. Disponível em: <http://www.borland.com/caliber/ </horde/util/go.php?url=http%3A%2F%2Fwww.borland.com%2Fcaliber%2F&Horde=508b1ba1c6d2077db320441cd86fb042>>. Acesso em: 30 set. 2004.
CAVANESS, Chuck. Programming jakarta struts. Beijing: O Reilly, 2003. xvii, 441 p., il.
HAZAN, Claudia. Implantação de um processo de gestão de requisitos seguindo o CMMI. Rio de Janeiro: Departamento de Informática – PUC, 2003.
HAZAN, Claudia; LEITE, Julio César Sampaio do Prado. Indicadores para a gerência de requisitos. Rio de Janeiro: Departamento de Informática – PUC, 2003.
HUSTED, Ted. Struts em ação. Tradução Eveline Vieira Machado. São Paulo: Ciência Moderna, 2004. xxviii, 604 p., il.
IBM. Rational requisite pro. [S.l.], 2003. Disponível em: <http://www-306.ibm.com/software/awdtools/reqpro/ </horde/util/go.php?url=http%3A%2F%2Fwww-306.ibm.com%2Fsoftware%2Fawdtools%2Freqpro%2F&Horde=508b1ba1c6d2077db320441cd86fb042>>. Acesso em: 30 set. 2004.
LOZANO, Fernando. Desenvolvimento Web com Eclipse. Rio de Janeiro, 2004. Disponível em: <http://www.lozano.eti.br/palestras/web-eclipse.pdf>. Acesso em: 01 jun. 2005.
MARQUARDT, Luciano. Ferramenta web para gerenciamento de requisitos de software. 2004. 86 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
OBERG, Roger et al. Applying requirements management with use cases. Alabama, 2001. Disponível em: <http://cs.ua.edu/SEL/Other%20material/applying%20requirements%20management%20with%20use%20cases.pdf>. Acesso em: 20 mar. 2005.
PORRO, Simon.CMMI SE/SW/IPPD/A: staged, continuous, constageduous. Amsterdan, 2002. Disponível em: < http://www.spipartners.nl/data/CMM-CMMI-SPIder.PDF>. Acesso em: 05 mar. 2005.
SINTES, Anthony. Aprenda programação orientada a objetos em 21 dias. Tradução João Eduardo Nóbrega Tortello. São Paulo: Pearson Education do Brasil, 2002. 693p, il.
81
SOFTWARE ENGINEERING INSTITUTE. CMMI-SE/SW V1.02. Pittsburgh, PA: Carnegie Mellon University, 2003.
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison-Wesley, 2003.
SPARX SYSTEMS. Enterprise architect. [S.l.], 2004. Disponível em <http://www.sparxsystems.com.au/>. Acesso em: 15 maio. 2005.
THEILACKER Jr, Uno. Análise de uma organização de software utilizando o modelo CMMI/SEI v1.0 . 2000. 7 f. Relatório de Estágio Supervisionado (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
VOLPE, Renato Luiz Della; JOMORI, Sergio Massao; ZABEU, Ana Cecília Peixoto. CMM – CMMI: principais conceitos, diferenças e correlações. Belo Horizonte, out. 2003. Disponível em: <http://www.spin-bh.com.br/apresentacoes/spin21.pdf>. Acesso em: 25 set. 2004.
ZANLORENCI, Edna Pacheco; BURNETT, Robert Carlisle. Ferramenta de apoio aos processos da engenharia de requisitos, nas fases de projeto. Paraná, 2004. Disponível em: < http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER00/zanlorenci.pdf>. Acesso em: 30 set. 2004.
82
APÊNDICE A – Código fonte de uma tela JSP
<%-- imports das tags struts --%> <%@ taglib uri ="struts-bean" prefix ="bean" %> <%@ taglib uri ="struts-html" prefix ="html" %> <%@ taglib uri ="struts-logic" prefix ="logic" %> <%@ taglib uri ="struts-tiles" prefix ="tiles" %> <html:html > < HEAD> <html:base /> <title >RW0005PI</ title > <%-- Includes dos arquivos javascript e css --%> <bean:message key ="global.js.funcoes" /> <bean:message key ="global.js.popupModal" /> <bean:message key ="global.css.estiloCss" /> <script language ="JavaScript" > </ script > </ HEAD> <%@ include file ="../inc/cabecalho.jspf" %> <tr > <%-- Include do Menu Lateral --%> <%@ include file ="../inc/menuLateral.jspf" %> <td align ="" valign ="top" colspan ="" width ="610" height ="" nowrap > <table width ="610" height ="" border ="0" cellpadding ="0" cellspacing ="0" > <%@ include file ="../inc/menu.jspf" %> <tr > <TABLE border ="0" cellspacing ="0" width ="610" height ="" align ="" > <tr class ="" height ="2" > <td class ="" bgcolor ="" colspan ="9" width ="" height ="" nowrap ></ td > </ tr > <tr class ="" height ="2" > <TD></ TD> <td class ="td-11" colspan ="100%" width ="" height ="" nowrap ></ td > </ tr > <TR class ="" > <TD> </ TD> <td width ="400" colspan ="" > <LABEL class ="ft-01" > <A class ="href-02" h ref ="../../navegacao.do?target=telaPrincipal" > Home </ A> >> Cadastros >> Política de Gerência (Inclusão) </ LABEL> </ td > <TD align ="right" bgcolor ="" colspan ="" width ="" height ="" nowrap > <TABLE border ="0" cellspacing ="0" cellpadding ="0" height ="" > <TR class ="" > <TD align ="right" colspan ="" width ="" height ="" nowrap > <INPUT type ="button" value ="Consultar" class ="bt-02" disabled > </ TD> <TD align ="right" bgcolor ="" colspan ="" width ="1" height ="" nowrap > </ TD> <TD align ="right" class ="" bgcolor ="" colspan ="" width ="" height ="" nowrap > <INPUT type ="button" value ="Inserir" class ="bt-02" title ="Inserir" disabled > </ TD> <TD align ="right" bgcolor ="" colspan ="" width ="1" height ="" nowrap > </ TD> <TD align ="right" bgcolor ="" colspan ="" width ="" height ="" nowrap > <INPUT type ="button " value ="Voltar" class ="bt-02" title ="Voltar" disabled > </ TD> <TD align ="right" bgcolor ="" colspan ="" width ="1" height ="" nowrap > </ TD> <TD align ="right" bgcolor ="" colspan ="" width ="" height ="" nowrap > <INPUT type ="button" name="AJUDA" value ="Ajuda" class ="bt-01" title ="Ajuda" > </ TD> </ TR> </ TABLE> </ TD> </ tr > < tr > <td ></ td >
83
</ TR> <tr class ="" height ="2" > <TD></ TD> <td class ="td-11" bgcolor ="" colspan ="100%" width ="" height ="" nowrap ></ td > </ tr > <tr > <td > </ td > <td align ="left" class ="" bgcolor ="" colspan ="100%" width ="" height ="" nowrap > <table border ="0" cellspacing ="0" cellpadding ="0" width ="" height ="284" align ="" > <html:form action ="/inserirAlterarPolitica" > <html:hidden property ="dscAcao" value ="inserirAlterarPolitica" /> <tr > <td nowrap ><span class ="style8" >Cadastrar Política de Gerência de Requisitos </ span > </ td > </ tr > <%-- include do bloco de mensagens --%> <%@include file ="../inc/mensagens.jspf" %> <tr > <td > <table > <tr > <td width ="55" ><strong >Projeto </ strong >: </ td > <td > <html:text property ="nomProj" maxlength ="8" size ="12" disabled ="true" /> <html:hidden property ="sigProj" /> </ td > <TD align ="" class ="" bgcolor ="" colspan ="" width ="" height ="" nowrap > <INPUT type ="button" name="LISTAR" value ="Lista" class ="bt-01" onClick ="chamaLov('LovForm','listarProjetos','listarProjeto s','InserirAlterarProjetoForm')" title ="Selecionar projeto" > </ TD> </ tr > </ table > </ td > </ tr > <tr > <td > <table > <tr > <td width ="" valign ="top" ><strong >Política de Gerência </ strong >: </ td > <td > <html:textarea property ="dscPolitica" cols ="50" rows ="7" ></ html:textarea > </ td > </ tr > </ table > </ td > </ tr > <tr > <td > </ td > </ tr > <tr > <td align ="center" > <table width ="610" border ="0" cellspacing ="0" cellpadding ="0" > <tr align ="center" valign ="middle" > <td width ="" align ="right" > <html:submit styleClass ="bt-01" titleKey ="global.hint.salvar" > Salvar </ html:submit > </ td > <td width ="" align ="left" > <html:button property ="" styleClass ="bt-01" onclick ="confirmaCancelar(this.form)" titleKey ="global.label.cancelar" > Cancelar </ html:button > </ td > </ tr > </ table > </ td > </ tr > <tr > <td > </ td > </ tr > <TR class ="" height ="2" > <TD class ="td-11" bgcolor ="" colspan ="100%" width ="" height ="" nowrap ></ TD> </ TR> <%@ include file ="../inc/rodape.jspf" %>
84
</ html:form > </ table > </ td > </ tr > < TR class ="" height ="2" > <TD></ TD> <TD class ="td-11" bgcolor ="" colspan ="100%" width ="" height ="" nowrap ></ TD> </ TR> </ table > </ tr > </ table > </ td > </ tr > </ table > < html:form action ="/editarLogin" > <html:hidden property ="dscAcao" value ="editarLogin" /> <html:hidden property ="modulo" /> </ html:form > <html:form action ="/listarUsuarios.do" target ="popup" > <html:hidden property ="dscAcao" value ="" /> <html:hidden property ="dscAction" value ="" /> <html:hidden property ="formOrigem" value ="" /> <html:hidden property ="indExecutar" value ="true" /> <html:hidden property ="p_parametro" value ="" /> <html:hidden property ="p_parametro0" value ="" /> <html:hidden property ="p_parametro1" value ="" /> <html:hidden property ="p_parametro2" value ="" /> <html:hidden property ="p_parametro3" value ="" /> </ html:form > </ body > </ html:html >
85
APÊNDICE B – Dicionário de dados
Classe Usuário
Atributos Descrição
private Long codUsuar Código seqüencial para identificação do usuário.
private String nomUsuar Nome completo do usuário. private String nomContaUsuar Chave de acesso do usuário ao sistema. private String dscSenha Senha de acesso ao sistema. private String flgAdmin Identificar de usuário administrador do
sistema. Classe Acesso
Atributos Descrição
private String flgLeitura Identificador de acesso de leitura ao sistema.
private String flgEscrita Identificador de acesso de escrita ao sistema.
Classe Projeto
Atributos Descrição
private String sigProj Sigla para identificação do projeto. private String nomProj Nome completo do projeto. private String dscPolítica Descrição da política de gerência de
requisitos do projeto. private HashMap glossario Lista de termos e descrições
relacionadas ao projeto. private Long codUsuar Usuário associado como gerente do
projeto. Classe Vínculo
Atributos Descrição
private Long codVinculo Código seqüencial de identificação do vínculo.
private String codTipoOrigem Código do tipo de requisito origem no vínculo.
private String codTipoDestino Código do tipo de requisito destino no vínculo.
86
Classe Tipo Requisito
Atributos Descrição
private String codTipo Tag de identificação do tipo de requisito.
private String nomTipo Nome completo do tipo. Classe Requisito
Atributos Descrição
private Long codRequisito Código seqüencial de identificação do requisito.
private String nomRequisito Nome do requisito. private String dscObjetivo Objetivo do requisito no projeto. private String flgSituacao Situação do requisito pode ser:
aprovado, reprovado ou em análise. private String flgVolatil Indicador de volatilidade do requisito. private Date datInclusao Data da criação do requisito. private Date datAlteracao Data de alteração do requisito para
histórico. Classe Atributo
Atributos Descrição
private Long codAtributo Código seqüencial de identificação do atributo.
private String nomAtributo Nome do atributo. private String codTipoAtributo Identificação do tipo de atributo: lista de
valores, texto ou arquivo. Classe AssocAtributoRequisito
Atributos Descrição
private String dscValor Valor do atributo para um determinado projeto e requisito.
87
Classe SolicitacaoAlteracao
Atributos Descrição
private Long codSolicitacao Código seqüencial de identificação da solicitação de alteração.
private Date datSolicitacao Data da criação da solicitação. private String dscAlteracao Descrição da alteração a ser feita no
requisito. private String dscMotivo Motivo da alteração. private String dscSolicitante Quem solicitou a alteração. private String flgAprovRejeit Identificador de solicitação: aprovada,
rejeitada ou em análise. private String datFechamento Data de fechamento da solicitação.
Classe Stakeholder
Atributos Descrição
private Long codStakeholder Código seqüencial de identificação do stakeholder.
private String nomStakeholder Nome complete do stakeholder. private String dscCargo Cargo que ocupa na empresa. private String dscResponsabilidade Responsabilidades do stakeholder na
sua função. private String dscEducacional Nível educacional. private String dscComput Descrição sobre seu entendimento em
computação. Classe Entrevista
Atributos Descrição
private Long codEntrevista Código seqüencial de identificação da entrevista.
private String dscProblemas Descrição dos problemas a serem resolvidos.
private String dscUsuario Descrição do usuário com relação aos problemas apresentados.
private String dscEntendAnalista Entendimento do Analista com relação a descrição do usuário.
private String dscConfiabilidade Nível de confiabilidade esperada pelo usuário.
private String dscDesempenho Nível de desempenho esperado pelo usuário.
private String dscResumo Resumo as entrevista.