UNIVERSIDADE DO VALE DO ITAJA CENTRO DE CINCIAS TECNOLGICAS DA TERRA E DO MAR

CURSO DE CINCIA DA COMPUTAO

PROTTIPO DE UMA FERRAMENTA PARA SUPORTAR A GERNCIA DE PEDIDOS DE MUDANA EM UM PROJETO DE SOFTWARE

rea de Engenharia de Software

por

Jos Paulo Lckmann Martins

Marcello Thiry, Dr. Eng. Orientador

So Jos (SC), Agosto de 2007

UNIVERSIDADE DO VALE DO ITAJA CENTRO DE CINCIAS TECNOLGICAS DA TERRA E DO MAR

CURSO DE CINCIA DA COMPUTAO

PROTTIPO DE UMA FERRAMENTA PARA SUPORTAR A GERNCIA DE PEDIDOS DE MUDANA EM UM PROJETO DE SOFTWARE

rea de Engenharia de Software

por

Jos Paulo Lckmann Martins

Relatrio apresentado Banca Examinadora do Trabalho de Concluso do Curso de Cincia da Computao para anlise e aprovao. Orientador: Marcello Thiry, Dr. Eng.

So Jos (SC), Agosto de 2007

ii

SUMRIO

LISTA DE ABREVIATURAS.................................................................iv LISTA DE FIGURAS................................................................................v LISTA DE TABELAS ............................................................................ vii LISTA DE EQUAES ....................................................................... viii RESUMO...................................................................................................ix ABSTRACT ...............................................................................................x 1 INTRODUO.....................................................................................1 1.1 CONTEXTUALIZAO ...................................................................................1 1.2 PROBLEMA ........................................................................................................3 1.3 OBJETIVOS.........................................................................................................3 1.3.1 Objetivo Geral ...................................................................................................3 1.3.2 Objetivos Especficos.........................................................................................4 1.3.3 Escopo e delimitao do trabalho ....................................................................4 1.4 JUSTIFICATIVA ................................................................................................4 1.5 ASPECTOS METODOLGICOS ....................................................................6 1.5.1 Metodologia........................................................................................................6 1.5.2 Plano de Trabalho .............................................................................................7 1.6 ESTRUTURA DO TRABALHO........................................................................7

2 MANUTENO DE SOFTWARE.....................................................9 2.1 INTRODUO....................................................................................................9 2.2 DOCUMENTAO..........................................................................................13 2.3 CLASSIFICAO ............................................................................................15 2.4 RISCOS...............................................................................................................16 2.5 GERNCIA DE MANUTENO...................................................................18 2.6 ISO/IEC 15504 ...................................................................................................25 2.7 CMMI..................................................................................................................27

3 FERRAMENTAS PARA GERENCIAR PEDIDOS DE MUDANA NO SOFTWARE .....................................................................................29 3.1 FERRAMENTAS LEVANTADAS E ANALISADAS ...................................35 3.1.1 Defect Tracker .................................................................................................35 3.1.2 Fast BugTrack .................................................................................................42 3.1.3 TestTrack Pro..................................................................................................49 3.1.4 Resumo das Ferramentas ...............................................................................55 3.1.5 Funcionalidades das ferramentas avaliadas .................................................56 3.2 AVALIAO DAS FERRAMENTAS............................................................58 3.3 CONCLUSO DO CAPTULO.......................................................................58

iii

4 MDULO DE GERNCIA DE MUDANA...................................60 4.1 TECNOLOGIA UTILIZADA ..........................................................................60 4.1.1 Ferramentas Utilizadas...................................................................................60 4.1.2 Framework SPRING.......................................................................................61 4.1.3 Framework Hibernate ....................................................................................63 4.2 PADRES DE PROJETOS ADOTADOS......................................................69 4.2.1 Front Controller ..............................................................................................69 4.2.2 View Helper .....................................................................................................69 4.2.3 Composite View ...............................................................................................71 4.2.4 Business Delegate.............................................................................................73 4.2.5 Data Access Object..........................................................................................75 4.2.6 Business Object................................................................................................75 4.2.7 Transfer Object ...............................................................................................75 4.2.8 Dispatcher ........................................................................................................77 4.3 MODELAGEM DO MDULO DE GERNCIA DE MANUTENO.....77 4.3.1 Processo de Desenvolvimento.........................................................................77 4.3.2 Requisitos do mdulo de gerncia de solicitaes de mudana. .................77 4.4 MDULO DE GERNCIA DE MANUTENO.........................................80 4.4.1 Cadastro de solicitao de mudana no software. .......................................81 4.4.2 Edio da solicitao de mudana de software. ...........................................85 4.4.3 Visualizao resumida da solicitao. ...........................................................90 4.5 INTEGRAO COM O PLACES ..................................................................91 4.5.1 PLACES sem o mdulo ..................................................................................92 4.5.2 Avaliao do Mdulo de Gerncia de Mudana ..........................................92 4.5.3 Comparao entre verses do PLACES .......................................................94

5 CONCLUSO .....................................................................................96 5.1 TRABALHOS FUTURO ..................................................................................97

REFERNCIAS BIBLIOGRFICAS...................................................99 6 ASSINATURAS.................................................................................120

iv

LISTA DE ABREVIATURAS

CMM Capability Maturity Model CMMI Capability Maturity Model Integration CMMI-SW Capability Maturity Model Integration for Software CMMI-SE/SW Capability Maturity Model Integration System Engineering/Software

Engineering IEC Commission Electrotechnique Internationale IEEE The Institute of Eletrical and Electronics Enginners. ISO International Organization for Standardization JSP Java Server Pages JVM Java Virtual Machine LQPS Laboratrio de Qualidade e Produtividade de Software MPS.BR Melhoria de Processo do Software Brasileiro MVC Model-View-Controller PLACES Plataforma Colaborativa para Engenharia de Software via Web RAD Rapid Application Development REF Requisito Funcional RNF Requisito No Funcional SEI Software Engineering Institute SW-CMM Capability Maturity Model for Software

v

LISTA DE FIGURAS

Figura 1. Estrutura do padro internacional ISO/IEC 12207. ........................................................... 12 Figura 2. Formulrio de pedido de mudana. .................................................................................... 19 Figura 3. Diagrama de gerncia no processo de mudana. ............................................................... 21 Figura 4. Dimenso de capacidade X processo ................................................................................. 26 Figura 5. Defect Tracker.................................................................................................................... 36 Figura 6. Baseline do Defect Tracker................................................................................................ 37 Figura 7. Cadastro de Testes no Defect Tracker ............................................................................... 39 Figura 8. Edio de artefatos no Defect Tracker ............................................................................... 40 Figura 9. Criao de grupos no Defect Tracker................................................................................. 41 Figura 10. Fast BugTrack .................................................................................................................. 43 Figura 11. Menu principal do Fast BugTrack.................................................................................... 44 Figura 12. Lista de Prioridades do Fast BugTrack ............................................................................ 46 Figura 13. Lista de Status do Fast BugTrack..................................................................................... 47 Figura 14. Cadastro de usurios no Fast BugTrack........................................................................... 48 Figura 15. Baseline do Test Track Pro. ............................................................................................. 51 Figura 16. E-Mail do Test Track Pro................................................................................................. 52 Figura 17. Cadastro de Solicitao no TestTrack Pro ....................................................................... 53 Figura 18. Estrutura do Framework Spring. ...................................................................................... 61 Figura 19. Arquivo de Configurao do Spring. ............................................................................... 63 Figura 20. Arquivo de configurao do hibernate. ............................................................................ 64 Figura 21. Estrutura do Framework Hibernate. ................................................................................. 65 Figura 22. Exemplo de HQL. ............................................................................................................ 66 Figura 23. Arquivo de mapeamento objeto-relacional do hibernate................................................. 67 Figura 24. Arquivo hibernate.cfg.xml ............................................................................................... 68 Figura 25. Classe View Helper.......................................................................................................... 70 Figura 26. Arquivo exibeTipoClassificacao.tag ................................................................................ 72 Figura 27. Parte da pgina viewSolicitacao.jsp................................................................................. 72 Figura 28. Classe ControladorSolicitacao.java.................................................................................. 74 Figura 29. Implementao da Classe SolicitacaoMudancaTO.java .................................................. 76 Figura 30. Modelo do banco de dados............................................................................................... 80 Figura 31. Tela de Projetos do PLACES........................................................................................... 81 Figura 32. Tela de listagem das manutenes cadastradas no PLACES........................................... 82 Figura 33. Tela de cadastro de solicitaes no PLACES. ................................................................. 82 Figura 34. Diagrama de Seqncia Cadastro de Solicitaes. .......................................................... 85 Figura 35. Tela de edio das solicitaes cadastradas no PLACES. ............................................... 87 Figura 36. Diagrama de Seqncia da edio da solicitao............................................................. 88 Figura 37. Diagrama de Seqncia de Vinculao de Artefatos ....................................................... 89 Figura 38. Tela de visualizao da solicitao cadastrada no PLACES. .......................................... 90 Figura 39. Diagrama de Seqncia de Informaes da Solicitao .................................................. 91 Figura 40. Tela Sobre do PLACES com mdulo de Gerncia de mudana no Software. ................ 95 Figura 41. Tela de instalao do JAVA........................................................................................... 104 Figura 42. Tela de personalizao da instalao do JAVA. ............................................................ 104 Figura 43. Tela de configurao das ferramentas do JAVA............................................................ 105 Figura 44. Tela de configurao do browser. .................................................................................. 105 Figura 45. Tela de finalizao da instalao.................................................................................... 106 Figura 46. Configurao das variveis de Ambiente 1.................................................................... 106

vi

Figura 47. Configurao das variveis de Ambiente 2.................................................................... 107 Figura 48. Configuraes das variveis de Ambiente 3. ................................................................. 107 Figura 49. Configurao das variveis de Ambiente 4.................................................................... 108 Figura 50. Configurao da varivel PATH 1................................................................................. 108 Figura 51. Configurao da varivel PATH 2................................................................................. 108 Figura 52. Criar a varivel JAVA_HOME 1................................................................................... 109 Figura 53. Criar a varivel JAVA_HOME 2................................................................................... 109 Figura 54. Tela de incio da instalao do Tomcat.......................................................................... 110 Figura 55. Termo de licena do Tomcat.......................................................................................... 110 Figura 56. Configurao do Tomcat................................................................................................ 110 Figura 57. Configurao do local de instalao do Tomcat 1. ........................................................ 111 Figura 58. Tela de configurao do Tomcat 2................................................................................. 111 Figura 59. Tela de configurao do Java no Tomcat....................................................................... 111 Figura 60. Tela de trmino da instalao do Tomcat. ..................................................................... 112 Figura 61. Pgina principal do Tomcat. .......................................................................................... 112 Figura 62. Incio da instalao do MySQL...................................................................................... 113 Figura 63. Tela de informao do MySQL...................................................................................... 113 Figura 64. Escolha do diretrio do MySQL. ................................................................................... 113 Figura 65. Configurao do MySQL............................................................................................... 114 Figura 66. Trmino da instalao do MySQL. ................................................................................ 114 Figura 67. Executar o MySQL. ....................................................................................................... 114 Figura 68. Executar o Driver ODBC do MySQL............................................................................ 115 Figura 69. Licena do driver ODBC do MySQL. ........................................................................... 115 Figura 70. Tela de boas vindas do ODBC MySQL......................................................................... 115 Figura 71. Tela de confirmao. ...................................................................................................... 116 Figura 72. Tela de finalizao da instalao do ODBC MySQL. ................................................... 116 Figura 73. Adicionando a fonte de dados MySQL.......................................................................... 116 Figura 74. Adicionando a fonte de dados MySQL 2....................................................................... 117 Figura 75. Adicionando a fonte de dados MySQL 3....................................................................... 117 Figura 76. Tela inicial do Netbeans................................................................................................. 118 Figura 77. Tela de licena do Netbeans........................................................................................... 118 Figura 78. Local de instalao do Netbeans. ................................................................................... 118 Figura 79. Configurao do JAVA.................................................................................................. 119 Figura 80. Configurao do JAVA.................................................................................................. 119 Figura 81. Tela de finalizao da instalao do NetBeans. ............................................................. 119

vii

LISTA DE TABELAS

Tabela 1. Documentao essencial para manuteno na abordagem estruturada. ............................ 14 Tabela 2. Fatores de risco classificados como mais importantes. ..................................................... 17 Tabela 3. Valor de atendimento do critrio com a ferramenta. ......................................................... 30 Tabela 4. Graus de importncia dos Critrios ................................................................................... 34 Tabela 5. Avaliao do Defect Tracker. ............................................................................................ 42 Tabela 6. Avaliao do Fast BugTrack. ............................................................................................ 49 Tabela 7. Avaliao da ferramenta TestTrack Pro. ........................................................................... 55 Tabela 8. Funcionalidades das Ferramentas. ..................................................................................... 57 Tabela 9. Resultado da Avaliao das Ferramentas. ......................................................................... 58

viii

LISTA DE EQUAES

Equao 1 .......................................................................................................................................... 30

ix

RESUMO

MARTINS, Jos Paulo Lckmann. Prottipo de uma ferramenta para suportar a gerncia de pedidos de mudana em um projeto de software. So Jos, 2007. no f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao)Centro de Cincias Tecnolgicas da Terra e do Mar, Universidade do Vale do Itaja, So Jos, 2007.

A busca pela qualidade no processo de software, leva as empresas a buscarem um aperfeioamento no processo de desenvolvimento de software. Alm da qualidade assegurada durante o desenvolvimento, desejado que a qualidade seja mantida durante o processo de manuteno do software, pois dependendo da empresa, o processo de manuteno pode ser uma das principais atividades da empresa. Da mesma forma, a proposta desta ferramenta tem uma preocupao em estar alinhada ao modelo de melhoria de processos CMMI (Capability Maturity Model Integration) e da norma ISO/IEC 15504. Neste sentido, procurou-se estudar sobre os padres de projetos e normas a fim de identificar prticas relevantes no processo de manuteno. Sendo assim, buscou-se mapear das normas e padres de projetos, as prticas que influenciam diretamente o processo de manuteno e como poderia auxiliar o processo, evitando falhas e diminuindo os riscos envolvidos no projeto. Para apoiar a proposta da ferramenta e verificar seu alinhamento com o modelo de melhoria, so avaliadas trs ferramentas comerciais. Por meio de normas e padres de projeto, os processos tendem a serem executados com o objetivo de minimizar parcial ou totalmente os problemas encontrados no processo de gerncia de manuteno de software. Neste sentido, este trabalho apresenta uma proposta de ferramenta para apoiar o processo de gerncia de manutenes, que desenvolvida como um mdulo da plataforma PLACES. A ferramenta desenvolvida foi integrada a plataforma PLACES (Plataforma Colaborativa para engenharia de Software via Web), tendo como objetivo disponibilizar o mdulo de gerncia de solicitaes de mudana. O foco deste trabalho a criao de um mdulo de gerncia de pedidos de solicitao de mudana de software no PLACES, para que oferea recursos para apoiar o processo de gerncia de manutenes.

Palavras-chave: Gerncia de Manuteno. CMMI. ISO/IEC 15504.

x

ABSTRACT

The search for the quality in the software process, takes the companies to search a perfectioning in the process of software development. Beyond the quality assured during the development, it is desired that the quality is kept during the process of maintenance of software, therefore depending on the company, the maintenance process can be one of the main activities of the company. In the same way, the proposal of this tool has a concern in being lined up to the model of improvement of processes CMMI (Capability Maturity Model Integration) and of norm ISO/IEC 15504. In this direction, it was looked to study on the standards of projects and norms in order to identify practical excellent in the maintenance process. Being thus, one searched to study of the norms and standards of projects, the practical ones that they influence the maintenance process directly and as could assist the process, preventing imperfections and diminishing the involved risks in the project. To support the proposal of the tool and to verify its alignment with the improvement model, three commercial tools are evaluated. By means of norms and standards of project, the processes tend to be executed with the objective to total minimize partial or the problems found in the process of management of software maintenance. In this direction, this work presents a tool proposal to support the process of management of maintenances that is developed as a module of platform PLACES. The developed tool was integrated platform PLACES (Collaborate Platform for engineering of Software saw Web), having as objective to available the module of management of change requests. The focus of this work is the creation of a module of management of order of request of change of software in the PLACES, so that it offers resources to support the process of management of maintenances.

Keywords: Management of Maintenance. CMMI. ISO/IEC 15504.

1 INTRODUO

1.1 CONTEXTUALIZAO

As organizaes que desenvolvem softwares esto buscando qualidade em seus produtos. O

crescimento das empresas que desconhecem, por exemplo, a norma NBR ISO/IEC 12207 sobre

processos de ciclo de vida de software diminuiu de 75% das empresas em 1997 para 19% das

empresas em 2004 (MCT, 2005). A busca pela qualidade nos processos, resultou na criao de

normas e modelos especficos para o desenvolvimento de softwares. As normas mais conhecidas e

utilizadas atualmente pelas organizaes brasileiras so as normas ISO 9000, NBR ISO/IEC 12207,

a ISO/IEC 15504 (MCT, 2005), e o modelo CMMI. Atualmente, existe ainda o MPS.BR (SOFTEX,

2006), desenvolvido pelo Softex para atender a demanda de micro e pequenas empresas.

O ciclo de vida do software baseado no processo de desenvolvimento do software o qual

definido por um conjunto de atividades e tarefas. A manuteno do software fundamental para

manter o software funcionando de acordo com o esperado. Para isto, a gerncia de solicitaes de

mudana de software deve ter um tratamento adequado, pois dependendo da empresa, a manuteno

de softwares, pode ser o principal produto dentro da empresa.

A forma como a manuteno executada, vem sendo aprimorada por meio da adoo de

mtodos da engenharia de software, os quais permitem a efetiva documentao do software.

Segundo SOUZA (2005), o excesso ou a falta da documentao pode ser prejudicial ao ciclo de

vida do software. A falta de documentao pode ser prejudicial, pois omite informaes necessrias

para se entender requisitos, funcionalidades do sistema, modelo de dados, entre outras informaes

relevantes ao se efetuar uma mudana no software. O excesso de documentao, tambm pode ser

prejudicial, pois podem levar a equipe de manuteno dvida quanto a certas funcionalidades do

sistema, requisitos ou outros artefatos do sistema. O excesso de documentao, tambm pode ser

prejudicial por impor ao mantenedor do software, a alterao de uma grande quantidade de

documentos para apenas uma solicitao de modificao no software.

As manutenes podem adquirir uma classificao quando a mesma cadastrada no sistema.

A classificao do tipo de manuteno fundamental para o processo, pois desta classificao

poder ser dada certa prioridade ao pedido de mudana. Assim, os pedidos de mudana no software

devem ser avaliados e posteriormente classificados. Deve-se observar que as solicitaes de

mudanas precisam ser previamente classificadas por critrios definidos pela equipe de manuteno

2

para que se defina a real necessidade da solicitao. Os critrios definidos devem avaliar os

impactos da mudana no software; avaliar os riscos, a qualidade do software, o tempo necessrio

para se efetuar a mudana, bem como o custo que a mudana afetar no projeto.

A falta de uma ferramenta de gerncia de mudana de software, dificulta a rpida interao

com os interessados no software em construo ou em manuteno. Alm disso, os interessados

tero tambm maior dificuldade de acompanhar o processo de atendimento aos pedidos realizados.

A melhoria no processo de manuteno visa manter a rastreabilidade de pedidos de manuteno e

oferecer o acompanhamento pelo cliente at a solicitao ser atendida ou no. O amadurecimento

das empresas de desenvolvimento de software leva a utilizao de ferramentas que auxiliem na

adoo de normas e padres criados com o objetivo de melhorar o processo de desenvolvimento de

software.

Organizaes de pequeno e mdio porte podem utilizar ferramentas de solues free. A

adoo de uma ferramenta free poder ser customizada para a utilizao na organizao, permitindo

que a ferramenta se adapte a organizao, ou se for necessrio, a organizao ir se adaptar a

mesma. Seguindo este conceito, sero avaliadas neste trabalho principalmente, ferramentas de

cdigo aberto.

As ferramentas de cdigo aberto que auxiliam o processo de manuteno, em sua grande

maioria, no fazem associaes aos artefatos utilizados no processo de desenvolvimento. A falta

desta associao entre os artefatos e a fase de manuteno pode ser profundamente prejudicial ao

ciclo de vida do software. Segundo pesquisa realizada por SOUZA (2005, p.6), a documentao do

software considerada o conjunto de artefatos mais importantes no processo de manuteno, sendo

dada a grande importncia para o Cdigo Fonte e os comentrios dos mesmos.

Dentro deste contexto, a ferramenta a ser desenvolvida, visa o gerenciamento dos pedidos de

mudana de software, assim como a associao dos artefatos que foram utilizados no processo de

desenvolvimento, com o pedido de mudana no software, tendo como objetivo o auxlio no

processo de mudana de software. A ferramenta dever ser capaz de gerenciar os pedidos de

mudana, bem como classificar e planejar a gerncia dos mesmos, distribuio das atividades e

acompanhamento dos pedidos solicitados.

Esta ferramenta de gerncia de pedidos de mudana, estar integrada plataforma PLACES

(Plataforma Colaborativa para Engenharia de Software via Web), que est sendo desenvolvida para

3

suportar um ambiente colaborativo para a engenharia de software via web (MORETTO, 2005). Este

trabalho procura contribuir com um novo mdulo do PLACES, disponibilizando um prottipo para

uma ferramenta de gerncia de manuteno.

A maioria das ferramentas de manuteno de softwares, foram desenvolvidas apenas com o

objetivo de efetuarem a gerncia manuteno. A ferramenta dever estar integrada com a

plataforma PLACES, visando assim uma melhor integrao dos processos de desenvolvimento e

manuteno, assim como a adoo da Norma 15504 e reas de processo do CMMI como

acompanhamento, planejamento e gerncia de requisitos, sero fundamentais para o

desenvolvimento da ferramenta. O CMMI um modelo de capacidade e maturidade integrada ao

desenvolvimento de software.

1.2 PROBLEMA

Grande parte das ferramentas de manuteno de softwares disponveis no mercado, no

possuem integrao com a fase de desenvolvimento do software. Desta forma, as ferramentas

perdem o conhecimento agregado durante a fase de desenvolvimento para a fase de manuteno do

sistema. Por sua vez, grande parte das ferramentas disponveis no mercado no esto agregadas em

conformidades com normas e modelos de processo de manuteno de software. Portanto esta

ferramenta vem a ser aplicada em organizaes que desejam melhorar o processo de qualidade e

gerenciamento dos pedidos de mudana de software onde o conhecimento e o controle de mudanas

efetuadas durante o processo de desenvolvimento e manuteno sero controladas e monitoradas.

1.3 OBJETIVOS

1.3.1 Objetivo Geral

Desenvolver um prottipo de uma ferramenta que gerencie os pedidos de mudana em um

projeto de software, alinhada s prticas da rea de gerncia de requisitos do modelo CMMI e

resultados esperados das reas de processos da Norma ISO/IEC 15504, de acordo com os requisitos

que sero levantados durante a elaborao deste trabalho.

4

1.3.2 Objetivos Especficos

Mapear as reas de pedido de alterao de software da ISO/IEC 15504 e do CMMI-

SE/SW que atendem as necessidades de uma ferramenta de gerncia de pedidos de

mudana, no software que poder ser implementada no prottipo a ser desenvolvido.

Avaliar ferramentas atuais do mercado que gerenciam pedidos de mudana de softwares.

Estabelecer um mapeamento das ferramentas avaliadas com as necessidades de uma

ferramenta de gerncia de mudana de software.

Desenvolver um prottipo da ferramenta de gerncia de mudana de software com base

nos requisitos levantados.

Avaliar o comportamento da ferramenta, permitindo uma primeira validao e

identificao dos pontos fortes e fracos de acordo com os critrios estabelecidos para a

avaliao das ferramentas.

1.3.3 Escopo e delimitao do trabalho

Este trabalho se limitar ao desenvolvimento de um prottipo para gerncia de pedidos de

mudana de software que ser agregado plataforma colaborativa PLACES. O prottipo dever

auxiliar na gerncia de solicitaes de mudana, no planejamento e acompanhamento das

manutenes solicitadas. O prottipo dever atender ao processo de pedido de mudana de software

da ISO/IEC 15504 e estar de acordo com algumas prticas do CMMI das reas de processo

Gerncia de Requisitos, Planejamento de Projeto, Monitoramento e Controle de Projeto, que sero

identificadas ao longo da execuo deste trabalho.

No constitui objeto de estudo, a linguagem e tecnologia a serem trabalhadas, pois estas j

esto definidas pela plataforma PLACES. Tambm no faro parte do escopo deste trabalho, a

customizao e adaptao da ferramenta a cada tipo de organizao.

1.4 JUSTIFICATIVA

A manuteno hoje fornece um caminho vital para a empresa de software, sendo

fundamental para a vida da mesma (POLO, et al, 2003, p.1). Com o objetivo de melhorar este

processo dentro de empresas de desenvolvimento de software, este trabalho visa atender o

gerenciamento dos pedidos de mudana de software, integrando ao PLACES um mdulo de

manuteno, que dever auxiliar a Plataforma Colaborativa no cadastramento e gerenciamento dos

5

pedidos de mudana de software. Com o mdulo de gerncia de pedidos de alterao de software

ser possvel manter uma rastreabilidade do pedido desde o momento em que o pedido for

cadastrado no sistema, at a concluso do mesmo.

O sistema dever permitir que o pedido cadastrado seja interligado com os artefatos do

sistema que foram utilizados durante a fase de desenvolvimento do projeto. Espera-se com isto que

a documentao do software se mantenha atualizada, pois ser possvel a atualizao da

documentao conforme forem sendo feitos os pedidos de mudana no software. A documentao

estando atualizada de acordo com o software facilita a deteco de futuras manutenes e correes,

evitando tambm o re-trabalho no processo de manuteno.

Para se efetuar uma mudana no sistema, necessrio possuir um controlador de mudana,

que quem vai definir os processos pelos quais a solicitao dever passar (CISCO, 2002, p.6).

Este controlador, em muitos casos, uma pessoa que efetua a manuteno no sistema e que fica

responsvel pela distribuio e classificao das tarefas. Com a utilizao de uma ferramenta, este

processo agregar mais valor, pois estar unindo o conhecimento com os artefatos que ajudaro no

entendimento e planejamento da solicitao.

Existem atualmente algumas ferramentas de gerncia de pedidos de mudana de software,

tais como: Bugzilla (BUGZILLA, 2006), Problem Tracker (PROBLEM TRACKER, 2006), Defect

Tracker (DEFECT TRACKER, 2006), Fast Bug Track (FAST BUG TRACK, 2006), entre outros;

sendo que grande parte destas ferramentas foram desenvolvidas apenas para serem executadas

durante o processo de manuteno. A falta de integrao com o processo de desenvolvimento, vem

a dificultar a gerncia dos pedidos de mudana do software. Com este trabalho, ser desenvolvido

um prottipo de uma ferramenta de manuteno, onde algumas prticas que sero identificadas do

CMMI, sero implementadas no prottipo, assim como os mtodos da ISO/IEC 15504, que esto

ligados ao processo de pedidos de mudana de software, adquirindo uma maior qualidade no

processo. O modelo CMMI no possui uma rea de processo especfica para a manuteno, por isto

ser utilizada principalmente a norma ISO/IEC 15504 algumas prticas do CMMI que se encaixam

na rea de pedidos de mudana de software.

6

1.5 ASPECTOS METODOLGICOS

1.5.1 Metodologia

Os objetivos da pesquisa podem ser classificados de 3 formas: exploratria, descritiva e

explicativa (ANDRADE, 1999, p.106). Seguindo esta classificao, este trabalho utilizar uma

pesquisa com objetivos exploratrios, a fim de proporcionar o conhecimento necessrio para dar

maior familiaridade com o problema, para se formular hipteses para a soluo do problema e

alcanar os objetivos esperados (ANDRADE, 1999, p.106). Desta forma, este trabalho ir por meio

de trabalhos sobre manuteno de software, da norma ISO/IEC 12207 e do modelo CMMI, buscar o

conhecimento necessrio para o desenvolvimento do tema do projeto.

A pesquisa exploratria se dar na busca por informaes e pesquisas realizadas de acordo

com a rea em que esto sendo coletadas informaes. A busca por informaes ser de maneira

bibliogrfica que consistir em levantamento e anlise de produes humanas em livros (RUIZ,

1996), artigos e Internet, de acordo com o assunto que foi assumido neste trabalho. Contudo, sero

levantadas pesquisas realizadas em engenharia de software sobre o processo de manuteno, para

por meio desta busca, avaliar a coerncia, efetuando definies sobre a manuteno de software,

sempre tentando buscar informaes a mais atualizadas possvel.

A base conceitual do sistema ser elaborada por meio do mtodo indutivo, onde com a

interpretao dos fatos, utilizando um raciocnio do particular para o geral, far com que se chegue

aos seus significados, onde das constataes particulares que chegamos s teorias e leis gerais

(ANDRADE, 1999). Com a constatao de fatos, se far necessrio efetuar a anlise para que seja

possvel definir como e quando as prticas do modelo CMMI e as normas da ISO/IEC 12207

passaro a se tornar requisitos da ferramenta. A induo possibilitar o desenvolvimento de

enunciados gerais sobre as observaes acumuladas de casos especficos ou proposies que

possam ter validades universais (OLIVEIRA, 2001, p.60).

O desenvolvimento do trabalho seguir uma metodologia experimental, onde sero

analisadas e levantadas as funcionalidades necessrias para a elaborao da ferramenta, de acordo

com o que foi definido nos objetivos especficos deste trabalho. Esta metodologia experimental ser

empregada principalmente na concepo do sistema, onde sero levantados os requisitos de acordo

com o que foi estudado e com o que ser avaliado nas ferramentas de gerncia de manuteno de

softwares.

7

1.5.2 Plano de Trabalho

1. Estudar a prtica de manuteno de softwares e como ela organizada dentro das

empresas. (Objetivo 1);

2. Estudar a definio do processo de manuteno de software da norma ISO/IEC 15504.

(Objetivo 1);

3. Identificar as prticas do modelo CMMI-SE/SW, que se encaixam com o processo de

manuteno de software, identificadas no item 1. (Objetivo 1);

4. Levantar e analisar as ferramentas atuais de manuteno de software, do mercado.

Analisar os pontos fortes e fracos das ferramentas analisadas. (Objetivo 2);

5. Identificar os requisitos da ferramenta que podero ser implementadas no prottipo a ser

desenvolvido. (Objetivo 3);

6. Efetuar a anlise do prottipo de manuteno, de acordo com o que foi definido no item

4. (Objetivo 4);

7. Elaborar documentao de anlise do prottipo de acordo com o que foi analisado no

item 6. (Objetivo 4);

8. Codificar o prottipo de acordo com o que foi definido no item 5. (Objetivo 4);

9. Observar o comportamento da ferramenta desenvolvida, a fim de avaliar os pontos fortes

e fracos do prottipo. (Objetivo 5).

1.6 ESTRUTURA DO TRABALHO

O trabalho est organizado em 5 captulos correlacionados, iniciando com esta introduo

sobre o tema proposto, onde foi apresentado o tema a ser abordado, por meio de sua

contextualizao. Depois, foram estabelecidos os resultados esperados por meio da definio de

seus objetivos. As limitaes do trabalho foram descritas, permitindo uma viso mais clara do

escopo proposto. Tambm foram abordadas a justificativa e a metodologia a ser empregada, onde

foram definidos o plano de trabalho e os prazos para a execuo deste plano.

Este captulo apresentou o tema a ser abordado por meio de sua contextualizao. Depois,

foram estabelecidos os resultados esperados por meio da definio de seus objetivos. As limitaes

do trabalho foram descritas, permitindo uma viso mais clara do escopo proposto. Tambm foram

8

abordadas a justificativa e a metodologia a ser empregada, onde foram definidos o plano de trabalho

e os prazos para a execuo deste plano.

O segundo captulo aborda itens sobre manuteno e o que se pode trazer das normas

vigentes para o processo de manuteno de software. So apresentadas as normas e como elas

podem contribuir na elaborao do projeto

O terceiro captulo apresenta trs ferramentas de manuteno de software. feita uma

avaliao sobre as ferramentas analisadas para auxiliar na definio das caractersticas que sero

implementadas no prottipo.

Por fim, o quarto captulo apresenta a proposta do prottipo que ser construdo para

gerenciar as solicitaes de mudanas no software, integrando este mdulo de manuteno com o

projeto PLACES.

2 MANUTENO DE SOFTWARE

2.1 INTRODUO

Todos os softwares possuem um ciclo de vida definido. O ciclo de vida definido desde o

seu planejamento at a descontinuao do software sendo composto por processos, que so

subdividos em atividades e cada atividade subdividida em tarefas ISO/IEC 12207 (1998, p.6).

Ainda de acordo com a ISO/IEC 12207 (1998, p.6), o ciclo de vida dividido em grupos de

processos: processos fundamentais, apoio e organizacionais. A figura 1 representa a diviso dos

processos em grupos, de acordo com a ISO/IEC 12207 (1998). Por sua vez o ciclo de vida segundo

a IEEE representado por um perodo de tempo que se inicia quando um software-produto

concebido e que finaliza quando o software no est mais disponvel para uso.

Na ISO/IEC 12207, o grupo de processos fundamentais dividido de acordo com o quadro

1.

Quadro 1. Processos fundamentais do ciclo de vida de Software.

Processo Definio Aquisio Definio da necessidade de adquirir um software (produto ou servio),

pedido de proposta, seleo de fornecedor, gerncia da aquisio e aceitao do software.

Fornecimento Preparar uma proposta, assinatura de contrato, determinao dos recursos necessrios, plano de projeto e entrega do software.

Desenvolvimento

Anlise de requisitos, projeto, codificao, integrao, testes, instalao e aceitao do software.

Operao Operao do software e suporte operacional aos usurios. Manuteno Define as atividades de quem faz a manuteno do software, como a

organizao deve fornecer os servios de manuteno, gerenciando as modificaes dos produtos do software mantendo o software operacional. Este processo inclui a migrao e a retirada do software.

Fonte: ISO/IEC 12207 (1998).

Os processos fundamentais, de acordo com o quadro 1, servem para gerar os produtos de

software, constituindo o ciclo de vida do software.

Os processos de apoio servem para auxiliar outros processos, visando principalmente

qualidade e o sucesso do projeto. Os processos de apoio so divididos em Documentao, Gerncia

10

de Configurao, Garantia da Qualidade, Verificao, Validao, Reviso Conjunta, Auditoria e

Resoluo de Problemas. Estes processos e as suas descries esto detalhados no quadro 2.

Quadro 2. Processos de apoio do ciclo de vida de Software.

Processo Definio Documentao A documentao o registro de informaes produzidas por um processo ou

atividade. Inclui planejamento, projeto, desenvolvimento, produo, edio, distribuio e manuteno dos documentos necessrios a gerentes, engenheiros e usurios do software.

Gerncia de Configurao

Define as atividades para a aplicao de procedimentos administrativos e tcnicos por todo o ciclo de vida de software, destinado a: identificar e definir os itens de software em um sistema e estabelecer suas linhas bsicas; Controlar as modificaes e liberaes dos itens; Registrar e apresentar a situao dos itens e dos pedidos de modificao; Garantir a consistncia e a correo dos itens; e controlar o armazenamento, a manipulao e a distribuio dos itens.

Garantia da Qualidade

Garante que os processos e produtos de software estejam em conformidade com os requisitos e os planos estabelecidos.

Verificao Determina se os produtos de software de uma atividade atendem completamente aos requisitos ou condies impostas a eles.

Validao Determina se os requisitos e o produto final atendem ao uso especfico proposto.

Reviso Conjunta

Define as atividades para avaliar a situao e produtos de uma atividade de um projeto, se apropriado. As revises conjuntas so feitas tanto nos nveis de gerenciamento do projeto, como nos nveis tcnicos e so executadas durante a vigncia do contrato.

Auditoria Determina adequao aos requisitos, planos e contrato, quando apropriado. Resoluo de Problemas

Analisar a resoluo dos problemas de qualquer natureza ou fonte, descobertos durante a execuo do desenvolvimento, operao, manuteno ou outros processos.

Fonte: ISO/IEC 12207 (1998).

Os processos organizacionais tm como objetivo garantir e melhorar continuamente os

processos organizacionais dentro da organizao. Estes processos esto divididos em Gerncia,

Infra-estrutura, Melhoria e Treinamento. Estes processos e as suas descries esto detalhados no

quadro 3.

11

Quadro 3. Processos Organizacionais do ciclo de vida de Software.

Processo Definio Gerncia Define as atividades genricas que podem ser empregadas por quaisquer das

partes que tm que gerenciar seu(s) respectivo(s) processo(s). O gerente responsvel pelo gerenciamento do produto, gerenciamento de projeto e gerenciamento de tarefa dos processos aplicveis, tais como: aquisio, fornecimento, desenvolvimento, operao, manuteno ou processos de apoio.

Infra-estrutura

Fornecimento de recursos para outros processos. Inclui: hardware, software, ferramentas, tcnicas, padres de desenvolvimento, operao ou manuteno.

Melhoria Atividades para estabelecer, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software.

Treinamento Define as atividades para prover e manter pessoal treinado.

Fonte: ISO/IEC 12207 (1998).

A norma ISO/IEC 12207 constituda por um conjunto de processos, atividades e tarefas e

podem ser adaptados de acordo com o projeto de software. Estes processos podem ser classificados

em trs tipos: fundamental, apoio e organizacional, conforme ilustra a figura 1

12

Figura 1. Estrutura do padro internacional ISO/IEC 12207.

Fonte: ISO/IEC 12207 (1998).

A manuteno de software uma importante atividade dentro do ciclo de vida do software.

Para que a qualidade do software se perpetue durante os ciclos de manuteno, necessrio que se

estabelea um processo de como ser realizada a manuteno no software. Grande parte das

empresas brasileiras conhecem e adotam processos da engenharia de software, no processo de

desenvolvimento e manuteno dos softwares (MCT, 2001). Sendo que dentre as prticas de

13

engenharia de software que so mais adotadas pelas empresas, esto o controle de verso do

produto, especificao de programas, especificao de projetos, especificao de requisitos e

modelagem de dados, todos com mais de 60% de adoo dentro das empresas de software (MCT,

2001). A aplicao de um processo visa manter um padro dentro da empresa. A expectativa da

empresa, ao aplicar um padro no processo de manuteno, manter a qualidade do software

quando o software precisar passar por manutenes.

A aplicao isolada de uma norma, tanto de qualidade quanto de padronizao de processos,

no determinar se um software ir ter uma vida til maior ou menor do que foi estipulada. A

determinao da vida til de um software de acordo com a qual foi projetada, muitas vezes,

influenciada pela forma de como o projeto foi desenvolvido, e principalmente, de como

gerenciado e efetuado o pedido de mudana no software. Segundo a IEEE (1998, p.1), a fase de

manuteno do software deve ser iniciada no planejamento do projeto. A finalidade do

planejamento do projeto estabelecer e manter os planos que definem as atividades do projeto (SEI,

2006, p. 190). Este planejamento deve ser atualizado medida que o projeto executado, pois

podero ocorrer alteraes de escopo, requisitos, oramento, cronograma, estimativas, entre outros.

Neste sentido, vrios fatores podem influenciar na determinao da vida til do software. Alguns

dos fatores mais relevantes esto na documentao do software, gerncia dos riscos em um pedido

de mudana e nas limitaes do processo de manuteno.

2.2 DOCUMENTAO

A documentao em um ambiente de desenvolvimento bastante varivel, pois composta

por uma grande quantidade de artefatos. Pode-se listar como exemplo de documentao de um

software o cdigo-fonte, comentrios no cdigo fonte, requisitos do sistema, dicionrio de dados,

manual do usurio, entre outros. Sendo assim, a documentao torna-se uma importante fonte de

conhecimento no processo de desenvolvimento do software, que serve como referncia, tanto para a

equipe do projeto como para o usurio final. No contexto deste trabalho, ser discutida apenas, a

documentao levantada no processo de desenvolvimento do software e no processo de manuteno

do software.

A documentao tem um efeito significativo no entendimento do programa (HCI, 2006).

por meio da documentao em que, parte ou todo o conhecimento adquirido do processo de

desenvolvimento, ser passado para a equipe de manuteno. Neste sentido, a documentao base

para o processo de manuteno.

14

Segundo pesquisa realizada por SOUZA (2005, p.5), por meio de questionrio com

profissionais com experincia em manuteno de software, realizada sobre documentao essencial

para manuteno na abordagem estruturada, alguns artefatos considerados importantes so pouco

utilizados e outros artefatos considerados pouco importantes, so mais utilizados no processo de

manuteno. Percebe-se ainda pelos resultados da pesquisa na Tabela 1, que existem artefatos

criados que so pouco utilizados no processo de manuteno, e artefatos que so bastante utilizados

que no so criados, podendo vir a dificultar no entendimento do sistema.

Tabela 1. Documentao essencial para manuteno na abordagem estruturada.

Abordagem Estruturada Importncia Uso

Artefatos Sem Importncia

Pouco Importante

Importante

Muito Importante

Uso Existncia

Cdigo Fonte 0,0% 0,0% 6,2% 93,8% 100% 100% Comentrios do Cdigo Fonte

0,0% 7,6% 15,2% 77,3% 100% 100%

Modelo Lgico de Dados

0,0% 4,7% 23,4% 71,9% 100% 85,7%

Descrio dos Requisitos

4,8% 11,1% 23,8% 60,3% 40,0%

71,4%

Modelo Fsico de Dados

0,0% 3,1% 37,5% 59,4% 85,7%

100%

Lista de Requisitos

9,7% 12,9% 25,8% 51,6% 40,0%

71,4%

Dicionrio de Dados

1,6% 17,5% 33,3% 47,6% 85,7%

100%

Modelo Conceitual de Dados

6,5% 12,9% 35,5% 45,2% 40,0%

71,4%

Fonte: SOUZA (2005).

Ao ser solicitado um pedido de mudana no software, este pedido deve ser encaminhado

para a unidade competente dentro da organizao, sendo em sua maioria encaminhada para a equipe

de suporte ou de manuteno de sistemas, que dever contar com o processo de como o pedido

atendido. Uma das primeiras tarefas a serem efetuadas, quando for solicitado um pedido de

mudana no software, o planejamento. Nesta fase ser realizado o detalhamento dos processos que

sero executados. Segundo CISCO (2006), o processo de planejamento da mudana, dever

15

identificar os requisitos de hardware e partes do software, verificar o oramento, identificar os

recursos humanos, criar a documentao de mudana e rever os aspectos tcnicos da mudana e do

processo da mudana. importante avaliar o tempo, custo e o escopo da solicitao para que no

afete a qualidade desejada no sistema. Alm disso, necessrio classificar o tipo de alterao que

vai ser efetuada, para assim definir a importncia do pedido frente equipe de manuteno.

2.3 CLASSIFICAO

O pedido de mudana solicitado pode ser classificado, segundo a IEEE (1998, p. 5), como

corretivo, adaptativo, preventivo e emergencial. Cada tipo de classificao possui um grau de

importncia e de prioridade em que precisa ser atendido. Uma solicitao emergencial geralmente

tem prioridade maior do que uma correo preventiva. Um exemplo de como distinguir o grau de

importncia dentro das manutenes, a forma de como este problema/falha pode afetar na

organizao. Um defeito/falha encontrado na gerao de valores das folhas de pagamento de uma

empresa, pode ser considerado emergencial, pois poder causar prejuzos de grandes propores

para a organizao que utiliza o software, devendo este defeito/falha ser corrigido o mais breve

possvel. Entretanto, uma falha encontrada em um relatrio, aonde foi trocado o campo hora para

minutos, em que visivelmente diagnosticado, pode ser considerado apenas corretivo, pois mesmo

com a falha, o sistema continua rodando e o relatrio pode ser arrumado de forma manual.

A manuteno corretiva uma manuteno feita aps a descoberta de alguma falha no

sistema aps sua entrega. Uma manuteno emergencial uma manuteno corretiva, com a

diferena de que precisa ser feita com rapidez para manter o software operacional. A manuteno

adaptativa aquela efetuada para que o sistema se adapte a algum novo ambiente. Esta manuteno

ocorre quando existe troca de hardware, sistema operacional, entre outros. A manuteno

preventiva executada para melhorar o desempenho do software ou a prpria manutenibilidade do

software, como exemplo, a refatorao do cdigo. A refatorao do cdigo uma alterao feita na

estrutura interna do software para torn-lo mais fcil de ser entendido e menos custoso de ser

modificado, sem alterar seu comportamento observvel (FOWLER, 2004, p.52).

Propor um modelo de processo genrico para todas as categorias da manuteno, como

prope a IEEE, no ajuda a adquirir uma compreenso profunda de cada categoria da manuteno.

No oferece a visibilidade requerida para cada tipo de pedido de mudana no software. Cobrir um

domnio to extenso por um mesmo modelo de processo conduz a muitas inconsistncias e

perguntas no respondidas (POLO, et al, 2003, p.35). Ainda segundo POLO (2003, p.36), uma das

16

medidas para se resolver este impasse seria criar para cada categoria de manuteno, o seu modelo

de processo. Este modelo de processo seria mais especializado, o que levaria a uma maior

compreenso na classificao da manuteno e nos objetivos da classificao.

Quando feito um pedido de mudana do tipo emergencial, imperativo manter a mudana

no software com a integridade da documentao (CISCO, 2006). Para que isto seja resolvido, estas

mudanas emergenciais devem ter uma tarefa de ps-documentao, que seria a alterao da

documentao aps a mudana no software ter sido efetuada. Contudo, deve-se avaliar antes de ser

realizada a mudana no software, o risco que esta pode causar.

Ao se realizar um pedido de mudana no software, o usurio espera que o problema/falha no

sistema, que ele encontrou, seja resolvido o mais breve possvel. Esta espera do usurio para que a

sua solicitao seja atendida, pode vir a no satisfaz-lo, pois em alguns casos um mdulo

utilizado por somente um usurio e o que leva a apenas um usurio a solicitar a mudana. Sendo o

pedido feito por somente um usurio a um problema/falha, pode levar a equipe de manuteno a

deixar este pedido pendente e atender outras solicitaes, que afetem uma quantidade maior de

usurios. Ao se fazer uma anlise entre efetuar a mudana versus custo da manuteno, definida

na maioria das situaes, que se o custo for muito alto para uma pequena mudana, no realizada

a devida manuteno (POLO, 2003, p. 36). Sendo assim, as manutenes, na maioria dos casos, so

realizadas somente quando encontrada uma quantidade equivalente de mudanas versus custo.

Ao ser analisado um pedido de mudana no software, deve-se verificar o impacto que a

mudana no software pode representar para a empresa, pois em alguns casos as solicitaes de

mudana esto ligadas a interesses particulares de algum colaborador da empresa. Destaca-se que,

pode acontecer que um colaborador da empresa possa estar querendo que o software no faa o seu

trabalho ou esteja querendo maior autonomia dentro da empresa (BACA, 2005, p. 50). Portanto,

importante conhecer o real motivo da mudana no software para que no seja realizada alguma

mudana que atenda apenas aos interesses pessoais de algum colaborador da empresa.

2.4 RISCOS

As mudanas na manuteno de software, podem representar desde muitos at nenhum risco

para o software, variando esta classificao de acordo com a probabilidade e impacto na

manuteno em geral. A cada pedido de mudana solicitado, deve-se avaliar o risco que esta

mudana representa para o software. Os fatores de risco que so estatisticamente significativos

17

podem ser usados para se tomar decises sobre o risco de se executar mudanas no software ou no

(POLO, 2003, p. 197). Para se avaliar o risco que a mudana representa para o software

necessrio conhecer os fatores de risco. Um fator de risco um elemento que tenha o potencial de

afetar o sucesso ou a falha do projeto (DIR, 2005).

A tabela 2 mostra uma pesquisa realizada por WEBSTER (2004), demonstrando os fatores

de risco de maior importncia, com o respectivo grau de importncia dado pelos mantenedores de

software. O grau de importncia dado de acordo com o impacto e a probabilidade do risco ocorrer.

Com este resultado pode-se observar que a maioria dos riscos, poderia ser evitada, se executado um

planejamento do projeto. O levantamento de riscos, segundo o CMMI, (SEI, 2005) deve ser

efetuado durante o planejamento e conforme forem sendo detectados os riscos envolvidos no

projeto. Alguns dos fatores de risco da tabela 2 podem ser amenizados na manuteno com a

utilizao de ferramentas como o Bugzilla, Fast BugTrack, Defect Tracker, entre outros que

auxiliam na fase de manuteno.

Tabela 2. Fatores de risco classificados como mais importantes.

Grau de Importncia Fatores de Risco Alto Mdio Baixo

Pouca ou nenhuma documentao. 16 1 0 Oramento Insuficiente ou Instvel. 12 4 1 Entendimento limitado do sistema a ser mantido. 12 4 1 Fluxo contnuo de mudanas de requisitos (requisitos instveis). 11 6 0 Baixa qualidade no sistema a ser mantido. 10 7 0

Fonte: WEBSTER (2004).

A falta de documentao pode representar um risco para os projetos de software,

principalmente na fase de manuteno. Ningum pode garantir que o conhecimento, que est na

cabea dos programadores experientes, permanecer vivo na equipe quando esta for dissolvida

(SOUZA, 2005, p. 2). Portanto, torna-se interessante a utilizao de uma ferramenta que auxilie no

manuseio desta documentao. Grande parte das ferramentas disponveis de uso focado somente

no processo de manuteno, que deixam falhas por no agregar ferramenta, o conhecimento

adquirido e trabalhado durante o processo de desenvolvimento.

18

2.5 GERNCIA DE MANUTENO

Para organizar os pedidos de mudana e criar um processo de manuteno, as normas de

padres criados, seguem algumas caractersticas em comum, e em alguns aspectos, uma norma

complementa outra norma. As normas informam os passos pelo qual um pedido de manuteno

deve passar, a partir do momento em que foi cadastrado, porm, no informa quais informaes

devem ser cadastradas para auxiliar a equipe de manuteno a encontrar e efetuar a mudana ou

correo no software. Quando um pedido de mudana feito para a equipe de manuteno, este

deve conter algumas informaes fundamentais para o cadastro do pedido. As informaes

cadastradas servem como base para o pedido para que o mesmo passe pelo processo de manuteno.

O pedido de mudana de software precisa ser documentado. A documentao deste pedido

de grande importncia, pois por meio deste pedido que ser feito anlise do problema. Segundo

BACA (2005, pg.91) o pedido de mudana no software deve conter as informaes contidas na

figura 2.

19

ID: 091405-03

Seo 1: Solicitante Preenche. Nome do Projeto: PLACES Data: 31072006 Solicitante: Richard Gerente do Projeto: Luis Moretto Descrio da Solicitao:

Alterar fonte do cadastro de usurios.

Razes da Solicitao: Fonte excessivamente pequena, o que est dificultando aos usurios o preenchimento do mesmo.

Riscos se no implementado:

Cadastro mal preenchido ou preenchido incorretamente, o que afetar nas informaes geradas posteriormente pelo sistema.

Seo 2: Gerente do Projeto preenche. Esforo necessrio requisitado:

2 Horas Durao da mudana:

1 Hora

Recursos necessrios: - Um Designer - Um analista de sistemas. -

Dependncias:

Custo adicional necessrio:

R$ 200,00 Contratos afetados:

PLACES / PLATIC

Riscos se Implementado:

Gerao de informaes inconsistentes na base de dados, o que afetar a localizao da pessoa cadastrada, bem como a inconsistncia em relatrios.

Impactos triplos afetados:

Melhoria na qualidade do cadastro.

Recomendaes do Gerente do projeto:

Executar a mudana com prioridade mdia.

Assinatura do Gerente do projeto:

Luis Moretto Data: 03082006

Seo 3: Patrocinador Executivo preenche. Recomendaes do Patrocinador Executivo:

Aprovado, a mudana pode ser executada.

Assinatura do patrocinador executivo:

Jos Paulo Data: 04082006

Disposio: [ ] Negado [X] Aprovado

Incluir na Verso/Data:

1.3.0.35

Figura 2. Formulrio de pedido de mudana.

Fonte: BACA (2005).

O formulrio da figura 2 possui campos importantes como: Nome do Projeto, nmero do

pedido, razo do pedido, riscos da solicitao. Observa-se que sero comentadas apenas as

informaes consideradas mais relevantes, pois se considera estes campos fundamentais em um

sistema de solicitaes de mudana no software.

20

O nome do projeto base para a gerncia de projetos, pois pelo nome que ir se identificar

os projetos. O Nmero do pedido um identificador nico, por onde se devem enumerar os

pedidos. Para este item interessante no utilizar um nmero seqencial, mas sim a data mais um

nmero, que representa a quantidade de nmeros efetuados no dia, como por exemplo, o quinto

pedido realizado dia nove de maio de dois mil e seis: 060509-5. Outro exemplo seria rever todos os

pedidos selecionados por um certo perodo de tempo, onde com esta estrutura de nmero de pedido,

seria mais fcil de ser realizada a seleo das solicitaes. A organizao dos pedidos tambm

estaria mais clara, pois poderia ser possvel saber a quanto tempo o pedido j foi solicitado para a

equipe responsvel pela manuteno do sistema. A descrio do pedido deve conter a informao

detalhada do pedido que est sendo feito. Esta descrio precisa ser robusta o suficiente para que

no sejam necessrias vrias reunies com o solicitante do pedido para entender o que o solicitante

deseja que seja efetuado.

A Razo do Pedido, deve ser o ponto que o solicitante usa para convencer quem estiver

analisando a solicitao do por qu a mudana precisa ser realizada. A anlise dos riscos, se no

implementada, ser um dos fatores que ajudar o gerente do projeto a decidir se a mudana deve ou

no ser executada. Os riscos, se identificados, sero uma informao que vir da equipe de

manuteno, a qual, aps fazer a anlise de risco, ir informar se existe algum risco, se o pedido for

implementado. Nos impactos triplos da mudana, avaliado o impacto gerado ao longo do tempo,

custo, e escopo, influenciando na qualidade definida do software.

Segundo BACA (2005), a solicitao de um pedido de mudana pode seguir o fluxo de

atividades conforme a figura 3. Este fluxo serve como exemplo de um ciclo de vida do projeto, ao

se aplicar as atividades da figura 3. Aps a concluso de um fluxo, o software ter uma nova verso

do sistema. O ciclo de vida sugerido por BACA (2005, p.60), mostra que um pedido quando

solicitado no deve ser atendido imediatamente. Deve haver um acmulo de pedidos para que haja

as mudanas no software. A primeira anlise a ser efetuada em um pedido ser sobre os impactos no

escopo do projeto, tempo necessrio para a modificao e oramento, vindo a afetar diretamente na

qualidade definida ao software.

21

Figura 3. Diagrama de gerncia no processo de mudana.

Fonte: BACA (2005).

Ao receber uma solicitao de mudana, esta deve passar por um processo de avaliao para

averiguar se a solicitao deve ou no ser executada. Segundo BACA (2005), deve ser avaliado se

vale ou no a pena alterar o sistema, para apenas uma mudana. Sendo assim, interessante que

haja um acmulo de pedidos para que se inicie o processo de manuteno.

Algum cadastra uma mudana no projeto.

A equipe rev o

pedido de mudana.

Verificar o esforo necessrio para fazer a

mudana.

Acumular solicitaes de mudana.

Determinar o impacto no plano de projeto e

nos requisitos.

Impactos triplos de mudana?

O controle de mudana revisa

a mudana.

Notificar a equipe e o solicitante que o pedido foi negado.

Aprovado a mudana?

Aprovado a mudana nos

impactos triplos?

Realinhar os impactos triplos

do projeto.

Atualizar o plano de projeto e os requisitos do produto e resinconizar.

Notificar a equipe e o solicitante.

Sim

Sim

Sim

No

No

No

22

Tendo as modificaes definidas, devem-se avaliar os impactos que as modificaes iro

causar ao projeto. Se as modificaes no afetarem a qualidade do sistema, o pacote de

modificaes deve seguir para o prximo passo, seno a solicitao deve ser revista e controlada.

Caso seja aceita a modificao devem-se reavaliar os itens de tempo, custo, escopo e qualidade do

projeto e dar continuidade ao processo de modificao do software.

As modificaes no afetando o sistema nos itens de tempo, custo, escopo e qualidade,

devem ser aprovadas. Caso aprovadas as mudanas, deve-se dar incio as modificaes. Entretanto,

se no for aprovada a mudana, a solicitao deve ser justificada pelo fato de no ter sido aprovada.

O solicitante da mudana deve ser notificado da no aceitao da solicitao, junto com a

justificativa da no aceitao da mudana.

As normas ISO/IEC e a IEEE adotam atividades/fases que o pedido de mudana deve ter,

para se executar uma mudana no software. Estas atividades/fases definidas por cada norma, tm

como objetivo executar o processo de mudana no software preservando a integridade do software.

Os processos incluem desde a chegada do pedido de mudana, at a retirada do software

modificado, como pode ser conferido no quadro 4 sobre Fases da Manuteno.

Quadro 4. Fases da Manuteno.

ISO/IEC 12207 ISO/IEC 15504 IEEE 1219-1998 Implementao do processo. Determinar os requisitos da

manuteno. Identificao, classificao e priorizao do Problema / Modificao.

Problema e anlise da modificao.

Desenvolver a estratgia da manuteno.

Anlise.

Implementao da modificao.

Analisar problemas de usurio e impactos.

Projeto.

Reviso/Aceitao da manuteno.

Determinar modificaes para prxima atualizao.

Implementao.

Migrao. Implementar e testar as modificaes.

Regresso/sistema testes.

Aposentadoria do software. Atualizar o sistema. Aceitao dos testes.

Retirar o sistema do usurio. Entrega.

Fonte: IEEE 1219 (1998), ISO/IEC 15504 (1998), ISO/IEC 12207 (1998).

Segundo o quadro 4, as normas seguem um padro discreto, com algumas variaes quanto

s fases que precisam ser desenvolvidas durante o processo de manuteno do software.

23

Para a ISO/IEC 12207 a primeira atividade no processo de manuteno, a implementao

do processo. A implementao do processo dividida em tarefas, as quais levam o responsvel pelo

processo de manuteno, a criar planos de como o software ser modificado, de como ser

executado o processo de manuteno, alterao na documentao e correo dos problemas

encontrados, feedback para os usurios do sistema e implementao de um processo de gerncia de

configurao. Entretanto, a primeira fase da ISO/IEC 15504 a determinao dos requisitos que

sero alterados durante o processo de manuteno. Por sua vez a IEEE 1219 (1998), determina que

nesta primeira fase deve acontecer a identificao da modificao, avaliao do problema/requisito,

a classificao, a sua priorizao inicial, verificao dos dados e estimar os recursos que sero

necessrios para se executar a modificao.

Torna-se relevante ressaltar que a primeira atividade da ISO/IEC 12207 uma atividade de

organizao de como o processo de manuteno deve ser executado. Para tanto, o processo de

manuteno, ao ser executado, j deve estar elaborado e com os processos definidos.

Aps as etapas iniciais das normas, inicia-se o processo de anlise da modificao. Segundo

a ISO/IEC 12207, algumas tarefas atribudas a esta fase, so as mesmas atribudas primeira fase

da IEEE 1219. Por sua vez, atribuda a esta fase, est validao do pedido de mudana, estimativa

de recursos e documentao do projeto e do sistema. Destaca-se que nesta etapa ser criada toda a

estrutura necessria para dar suporte a modificao. Sero definidas as estratgias, os testes, o plano

de implementao da modificao, os recursos humanos e materiais necessrios, identificados os

riscos, avaliados o impacto da modificao e assegurado a qualidade do software que est sendo

modificado.

Aps efetuada a anlise da modificao e ser aprovada, ser executada a implementao da

modificao. Antes disto, segundo Baca (2005), necessrio que haja um nmero suficiente de

modificaes a serem efetuadas para que a modificao seja realizada no software. Para isto podem

ser criadas baselines. As baselines so configuraes formalmente aprovadas, que servem de

referncia para o desenvolvimento posterior do sistema. Estes pontos de referncia servem para

identificar uma verso do sistema ou at mesmo os itens que compem o sistema.

A implementao a fase na qual ser colocado em prtica, o resultado da fase de anlise.

Nesta fase ser necessria toda a documentao existente e necessria para alterar o software.

interessante nesta fase a criao de baselines para o controle do que est sendo modificado e se o

que est sendo modificado est conforme o planejamento da solicitao. Nesta fase sero

24

executados alguns subprocessos como: a codificao e os testes de unidade, integrao, anlise de

riscos e reviso dos testes (IEEE 1219, 1998).

A codificao a modificao no cdigo fonte e os testes de unidade so os testes efetuados

nos pontos onde esto sendo executadas as modificaes no cdigo fonte para a verificao de se o

que est sendo modificado ou criado est conforme o que foi definido e documentado na fase de

anlise da solicitao. A integrao a unio do que est ou foi modificado com o sistema. A

anlise e a reviso dos riscos devem ser executadas durante todo o ciclo de vida do software, sendo

executado periodicamente, conforme forem sendo detectados riscos (SEI, 2005; IEEE 1219, 1998,

p. 13).

Aps ter sido implementado, o software deve passar por testes. Estes testes devem verificar

se o software foi modificado corretamente, conforme o especificado nos artefatos de documentao.

No quadro 5 seguem itens importantes que devem ser averiguados na fase de testes do sistema.

Quadro 5. Testes do Sistema.

1. Verificar se foi introduzido alguma falha no sistema que no existia antes da modificao.

2. Verificar se os requisitos foram alterados corretamente. 3. Verificar se a documentao est de acordo com o software. 4. Verificar a documentao do Software. 5. Verificar se as modificaes esto de acordo com o manual do usurio. 6. Testes de Interface. 7. Funcionalidades do sistema.

Fonte: IEEE 1219 (1998), ISO/IEC 15504 (1998), ISO/IEC 12207 (1998).

Os testes efetuados durante a implementao no devem interferir nos testes do sistema e

nem constituir relatrio final de testes. Segundo a IEEE 1219 (1998, p.14) os testes devem ser

executados pelo cliente, pelo usurio do sistema que utilizar a parte do sistema que foi modificada

ou por terceiros, indicados pelo cliente.

Aps a execuo dos testes, os mesmos devem passar por uma avaliao que determinar se

as modificaes foram aceitas ou no. Caso as modificaes no tenham sido satisfatrias, ser

necessrio, encaminhar para a gerncia do projeto o que no foi aceito na fase de testes. Caso as

modificaes forem satisfatrias, dever ser determinado prxima baseline do sistema.

Para a execuo da migrao do sistema, devem ser executadas algumas tarefas, que esto

listadas no quadro 6, que tem como objetivo, colocar uma nova verso do sistema no ar, sem que

25

seja comprometida a qualidade, as funcionalidades do sistema e que a verso do sistema seja

colocada no ar sem afetar negativamente a empresa.

Quadro 6. Migrao do Sistema.

1. Treinamento do usurio do sistema. 2. Opes de sustentao. 3. Notificar o usurio das modificaes. 4. Retirada do sistema atual. 5. Criar backup do sistema. 6. Descrio das modificaes. 7. Desenvolver ferramentas para a migrao.

Fonte: IEEE 1219 (1998), ISO/IEC 15504 (1998), ISO/IEC 12207 (1998).

Para a retirada do sistema antigo, a equipe de manuteno dever executar algumas tarefas,

para que se obtenha o controle do software, pois caso tenha que se utilizar algum artefato ou algo

que seja necessrio se restaurar do sistema antigo, seja possvel. Portanto, uma das tarefas que

devem ser executadas o arquivamento do software, bem como os documentos associados a tal

verso do sistema (ISO/IEC 12207, 1998, p.26).

Torna-se relevante ressaltar que outras atividades, como suporte temporrio, bem como a

cpia dos dados, converso dos dados para o novo modelo, so tarefas que tambm devem ser

executadas nesta fase do processo.

Nas prximas sees sero analisadas as normas ISO/IEC 15504 e o modelo de processo do

CMMI-SE/SW e as reas de processo que interferem diretamente no processo de manuteno de

software.

2.6 ISO/IEC 15504

A norma ISO/IEC 15504 tambm conhecida por SPICE (Software Process Improvement and

Capability Determination) e seu Modelo de Avaliao de Processo de Software 15504, foram

criados para avaliar os processos de software com dois objetivos: a melhoria de processos e a

determinao da capacidade de processos de uma unidade organizacional (SOFTEX, 2005).

A norma internacional ISO/IEC 15504 para avaliao de processos, pode ser aplicada para

empresas de qualquer natureza e tamanho, e apesar de projetada para avaliao de processos, pode

tambm ser utilizada como uma referncia para a melhoria de processos de softwares.

26

A ISO/IEC 15504 presta-se realizao de avaliaes dos processos de software com dois

objetivos: melhoria dos processos e determinao da capacidade dos processos (von

WANGENHEIM, 2004, p. 2).

O modelo de representao da ISO/IEC 15504 um modelo bidimensional que descreve em

processos e em nveis de capacidade dos processos. A dimenso de processos define os processos a

serem avaliados. Nesta dimenso fornecido um modelo de referncia de processo, que define

modelo de avaliao de processo. A dimenso em nveis de capacidade de processo dividida em

seis nveis. Cada nvel representa a capacidade que a organizao tem na execuo do processo. Os

seis nveis de capacidade so seqenciais e acumulativos, sendo: incompleto, executado,

gerenciado, estabelecido, previsvel e em otimizao. A norma ainda define um processo de

manuteno do sistema e do software.

A dimenso de capacidade dos processos contm nove atributos de processo que so

agrupados nos seis nveis de capacidade. Os atributos definem uma escala de capacidade que so

aplicados em todos os processos selecionados (von WANGENHEIM, 2004).

Figura 4. Dimenso de capacidade X processo

Fonte: von WANGENHEIM (2004)

O processo de manuteno segundo a ISO/IEC 15504 determinado por prticas que devem ser

seguidas. O processo inicia-se pela determinao dos requisitos que sero alterados e afetados com

o pedido de manuteno. Aps a determinao dos requisitos ser necessrio definir uma estratgia

de como ser feita alterao no software. analisado o impacto que a alterao poder causar no

27

software, pois a alterao poder vir a ter que alterar outros atributos do sistema que no foram

solicitados, bem como sistema operacional, requisitos e interfaces (ISO/IEC 15504, 1998).

determinada uma baseline para que a alterao entre em funcionamento. executada a alterao

no projeto, e elaborado testes aps a implementao, para verificar se o software atende as

especificaes dos requisitos. Aps o software ser alterado, verifica-se se ser necessrio realizar

alguma atualizao e oferecer algum treinamento de atualizao. Para se realizar a atualizao do

produto precisa ser feito um cronograma, pois dependendo da atualizao recebida pelo software,

poder ser necessrio atualizar os sistemas que rodam em paralelo (ISO/IEC 15504, 1998).

O processo de manuteno do sistema e do software baseado no processo de operao, suporte ao

cliente e na resoluo do problema e do processo. Com a utilizao das prticas especificadas por

estes processos se chegar ao resultado esperado pelo processo de manuteno de sistemas, definido

pela ISO/IEC 15504.

Os resultados da utilizao do modelo de processo para a manuteno, sero vistos atravs

dos resultados aonde sero definidas estratgias para o controle de modificaes, controle e

aposentadoria de componentes. Atualizaes dos processos acontecero, conforme forem feitas s

atualizaes no software, os componentes sero controlados e testados, sendo migrados para o

cliente as atualizaes de forma controlada e organizada.

2.7 CMMI

O CMMI-SE/SW, definido pelo SEI (Software Engineering Institute), organizao

responsvel pela publicao do modelo CMMI, surgiu para resolver o problema na utilizao de

vrios modelos, resultado da evoluo do SW-CMM. O modelo CMMI-SE/SW/IPPD/SS teve a sua

verso 1.1 lanada em 2002 (SEI, 2005), que define duas representaes de modelos de maturidade:

em estgios e contnua. A representao em estgios similar ao modelo de maturidade definido

pelo CMM, e a representao contnua, introduz o conceito de nvel de capacidade, sendo mais

alinhada com a norma ISO/IEC 15504. Segundo o SEI (2005), o CMMI-SE/SW pode ser utilizado

como modelo para melhoria dos processos de uma organizao e como guia para alcanar um

modelo de processo.

Existem duas formas de representao do CMMI-SE/SW: a contnua e em estgios. A

representao escolhida para este projeto a contnua, por permitir comparaes de resultados entre

reas de processo, entre organizaes e principalmente por ter recursos de fceis comparaes da

28

melhoria de processo norma ISO/IEC 15504, por que as reas de processo so similares a

ISO/IEC 15504 (SEI, 2005).

O modelo de processo CMMI-SE/SW, definido pela SEI, organizado em reas de

processo. Cada rea de processo possui um propsito especfico e genrico, e prticas especficas e

genricas. Apesar de o modelo abranger quase todas as reas de processo de desenvolvimento

dentro de uma organizao, o modelo no descreve um modelo de processo para a rea de

manuteno de software.

As reas de processo que sero abrangidas por este trabalho sero: a gerncia de requisitos,

gerncia de configuraes e planejamento do projeto.

O processo de gerncia de requisitos a rea responsvel pelo gerenciamento de requisitos

que tem por finalidade identificar inconsistncias entre os produtos do trabalho dos requisitos que

foram planejados para o projeto (SEI, 2005). Uma das funes executadas no processo de

manuteno a alterao de requisitos, que podem ter surgido de vrias formas, entre elas est

evoluo do software e requisitos no levantados no processo de anlise. As modificaes advindas

do processo de manuteno devem em sua grande maioria passar por um levantamento de

requisitos. Ao se efetuar alguma alterao no software, dever verificar se o requisito alterado

interferiu ou no em outro requisito.

O processo de gerncia de configuraes a rea de processo responsvel por manter o

controle dos itens de configurao. Os itens da configurao so os produtos do trabalho do projeto

(SEI, 2005). A gerncia de configuraes determina linhas bases que tornam possvel se rastrear um

pedido de software. Por exemplo: uma determinada verso do sistema, determinando o que foi

pedido para ser alterado e o que foi alterado no software. Com a gerncia de configuraes,

possvel se determinar s verses do software, estabelecendo um controle entre o desenvolvimento e

o usurio final.

O processo de planejamento do projeto a rea de processo responsvel por definir os

planos do projeto, que serviro de base para o projeto de software. Este planejamento deve ser

atualizado medida que o projeto vai sendo executado, pois podero ocorrer alteraes de escopo,

requisitos, oramento, cronograma, estimativas, entre outros (SEI, 2005). Dentro deste aspecto, o

planejamento dever ser realizado, atribuindo estimativas e planejando o projeto de acordo com o

que foi acordado.

29

3 FERRAMENTAS PARA GERENCIAR PEDIDOS DE MUDANA

NO SOFTWARE

Neste captulo sero analisadas apenas 3 ferramentas disponveis no mercado, que tenham

como objetivo, o gerenciamento de pedidos de mudana no software. As ferramentas sero

analisadas por critrios estabelecidos neste trabalho, que estejam de acordo com funcionalidades

necessrias, bem como prticas levantadas pelo modelo CMMI e pela norma ISO/IEC 15504. Foi

dada preferncia para ferramentas de cdigo aberto e distribudas.

Dentre as caractersticas importantes que devem ser observadas nestas ferramentas esto:

facilidades de uso, facilidade de instalao, se a ferramenta necessita ser instalada, grau de

usabilidade, facilidade de manuteno e se permite comunicao entre os integrantes do projeto e

do cliente.

Dentre as funcionalidades que a ferramenta deve permitir esto: classificao dos pedidos

em tipos, que pode ser de acordo com a norma ISO/IEC 15504 (1998, p.24), que classifica em

corretivo, melhoria, preventivo ou adaptao a um novo ambiente, cadastramento de riscos no

decorrer do processo de modificao do software, definies de prioridades e gerncia da equipe de

manuteno nas tarefas que devem ser efetuadas. Portanto, os critrios escolhidos para serem

avaliados, sero catalogados com o seu grau de importncia, motivao e da sua definio e

objetivo.

Para gerenciar os pedidos de manuteno, a ferramenta precisa ser preferencialmente

colaborativa, para que todos os integrantes deste processo sejam avisados das tarefas que devem ser

feitas.

O objetivo de se executar a avaliao de ferramentas de solicitao de mudana no software,

de auxiliar na definio dos requisitos necessrios para a ferramenta que ser prototipada. Sero

levantados os critrios a serem analisados nas ferramentas. Os critrios avaliados devem estar de

acordo com algumas caractersticas importantes das ferramentas e funcionalidades que podem ou

no estar de acordo com a norma ISO/IEC 15504 e com o modelo CMMI. Estes critrios possuem

um peso especfico, que demonstra o grau de importncia no processo de manuteno e na

usabilidade da ferramenta. A especificao de cada grau de importncia definida no quadro 7.

30

Quadro 7. Graus de importncia utilizados nos critrios.

Grau Significado do grau de importncia 1 O critrio tem pouca importncia em uma ferramenta de manuteno. 2 O critrio interessante, mas no fundamental. 3 O critrio desejvel em uma ferramenta de manuteno. 4 O critrio muito desejvel em uma ferramenta de manuteno. 5 O critrio obrigatrio em uma ferramenta de manuteno.

Fonte: MORETTO (2005).

Alm do grau de importncia, cada critrio deve receber tambm uma valorizao que

indicar o grau de atendimento da ferramenta que est sendo avaliada com relao ao critrio. Os

valores possveis variam de 0 a 2, onde o valor 0 indica a ausncia do atendimento do critrio e 2

indica o atendimento completo do critrio, conforme pode ser verificado na tabela 3.

Tabela 3. Valor de atendimento do critrio com a ferramenta.

Valor Valor de Atendimento 0 No Atende. 1 Atende Parcialmente. 2 Atende Completamente.

Onde: n = nmero de critrios (11) Grau = grau de importncia definido para o critrio Valor = valor dado pelo avaliador ferramenta em um determinado critrio

Fonte: MORETTO (2005).

Equao 1

Ser apresentada agora a descrio de cada um dos critrios com o seu respectivo Grau,

Objetivo e Motivao. O grau a importncia que o critrio tem para com o software. O campo

objetivo deve descrever o que significa o critrio e o campo Motivao o que leva ao item estar

incorporado no modelo de avaliao. A motivao neste caso vai principalmente ser causada pela

31

Norma ISO/IEC 15504 e pelo Modelo CMMI. A descrio de cada um dos critrios apresentada

nos quadros que foram elaborados de acordo com o que foi estudado no captulo 2 e analisados de

acordo com as ferramentas que foram analisadas.

Critrio 01: A ferramenta colaborativa? Grau: 4 Objetivo: Ao se possuir uma ferramenta colaborativa, deseja-se adquirir uma maior agilidade no processo de solicitao, atendimento, acompanhamento e gerenciamento dos pedidos realizados. Motivao: Ao se optar por uma ferramenta colaborativa, estar se procurando agilizar o processo de manuteno, e consequentemente obter um maior controle dos pedidos realizados. Com uma ferramenta deste tipo, no necessrio ter toda a equipe de manuteno em apenas 1 local. O grau atribudo a este critrio se deve ao fato de que, caso este critrio seja alcanado, possvel se possuir clulas de manuteno em qualquer lugar, que possua acesso web, no necessitando que toda a equipe de manuteno esteja num mesmo local para se comunicar e delegar tarefas.

Critrio 02: Permite a criao de baselines para o projeto? Grau: 4 Objetivo: O sistema deve permitir a criao de baselines, responsveis pela determinao das configuraes do sistema. As baselines servem para identificar uma verso do sistema e os itens que compem o sistema. Motivao: Permitir a criao de baselines leva o projeto a ter um controle de verso mais apurado, ao qual ser mais fcil identificar os artefatos e as suas verses utilizadas em uma determinada verso do sistema. A baseline serve como base para o desenvolvimento de produtos do trabalho (SEI, 2005). Entre os produtos do trabalho esto: artefatos como Cdigo, Com