FERRAMENTA DE APOIO À GERÊNCIA DE REQUISITOS BASEADA NO MODELO CMMI

Transcrição

1 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 /1-38

2 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 /1-38

3 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: Membro: Membro: Prof. Nome Everaldo Artur Grahl Orientador, FURB Prof.(a) Fabiane Barreto Vavassori Benitti FURB Prof.(a) Ana Lúcia Anacleto Reis FURB Blumenau, 06 de julho de 2005

4 Aos meus pais, Adelino e Albertina Meisen, pelo incentivo, e aos meus amigos pelo apoio durante a realização deste trabalho.

5 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.

6 Os amigos verdadeiros são como o Sol, não precisamos vê-lo todos os dias para saber que ele existe. Autor Desconhecido

7 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.

8 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.

9 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

10 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

11 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

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS ESTRUTURA FUNDAMENTAÇÃO TEÓRICA GERÊNCIA DE REQUISITOS CMMI Áreas Chaves INDICADORES Indicadores de Estabilidade Indicadores de Rastreabilidade FRAMEWORK STRUTS Componentes Model Componentes View Componentes Controller TRABALHOS CORRELATOS DESENVOLVIMENTO DO TRABALHO REQUISITOS PRINCIPAIS DO PROBLEMA ESPECIFICAÇÃO Diagrama de Casos de Uso Criar projeto Manter usuários Manter política de gerência Manter tipos de requisitos Manter atributos Manter vínculos Manter projeto Liberar acesso ao projeto Manter glossário Manter requisitos Manter solicitação de alteração Gerar relatório de requisitos...39

13 Gerar matriz de rastreabilidade Visualizar indicadores Manter dependências Cadastrar Stakeholders Manter entrevistas Visualizar histórico das alterações Diagrama de Classes Diagrama de Seqüência Ferramenta utilizada na especificação do trabalho Enterprise Architect IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Plataforma Eclipse Plugin MyEclipse Framewok Struts Operacionalidade da implementação Módulo Administrativo Módulo Gerencial Módulo Analítico RESULTADOS E DISCUSSÃO CONCLUSÕES 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

14 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 custo 1, 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).

15 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.

16 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.

17 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.

18 17 Elicitação Modelagem Análise G e r ê n c i a 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. Validação Verificação 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

19 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.

20 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 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

21 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 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 áreachave.(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

22 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. Estágios Contínua Nível de Capacidade Área de Processo Fonte: adaptado de Porro (2002, p. 8) Figura 3 Representação dos Modelos do CMMI como segue: A representação por estágios do CMMI está dividida em cinco níveis de maturidade 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

23 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 Á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

24 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

25 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 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

26 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 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.

27 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

28 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 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 Componentes View Os componentes View representam a visão da aplicação, ou seja, a maneira como o

29 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;

30 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 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 strutsconfig.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.

31 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).

32 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.

33 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;

34 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

35 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.

36 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 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 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 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.

37 Figura 4 Relação entre Casos de Uso e Atores do Sistema 36

38 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 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 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 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.

39 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 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 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 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.

40 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 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 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 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 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.

41 Cadastrar Stakeholders O analista poderá cadastrar os stakeholders dos projeto Manter entrevistas O analista poderá manter as entrevistas feitas com os stakeholders dos projetos Visualizar histórico das alterações O analista poderá visualizar as solicitações de alteração cadastradas para um determinado projeto 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.

42 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.

43 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.

44 Figura 5 Diagrama de Classe 43

45 44 Figura 6 Diagrama das Classes Business e Cursor 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

46 45 explicar o funcionamento da tela e cadastrar requisitos. Figura 7 Diagrama de Seqüência Ferramenta utilizada na especificação do trabalho Para a especificação da ferramenta foi utilizada a ferramenta CASE Enterprise Architect, descrita a seguir: 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:

47 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, separandoos 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.

48 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 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 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