FUNDAO DE ENSINO EURPIDES SOARES DA ROCHA CENTRO UNIVERSITRIO EURPIDES DE MARLIA UNIVEM PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO

MARLIANE ALDIVINA OLIVEIRA FERREIRA

MR.GC-PARFAIT: Modelo de Referncia para a Atividade de Gerncia de Configurao do PARFAIT

MARLIA 2007

MARLIANE ALDIVINA OLIVEIRA FERREIRA

MR.GC-PARFAIT: Modelo de Referncia para a Atividade de Gerncia de Configurao do PARFAIT

Dissertao apresentada ao Programa de Mestrado do Centro Universitrio Eurpides de Marlia, mantido pela Fundao de Ensino Eurpides Soares da Rocha, para obteno do ttulo de Mestre em Cincia da Computao (rea de Concentrao: Engenharia de Software). Orientadora: Profa. Dra. Maria Istela Cagnin Machado

MARLIA 2007

Dedico esta dissertao a Deus.

AGRADECIMENTOS

Agradeo a Deus pela sabedoria e pela oportunidade desse aprendizado. minha querida orientadora Dra. Maria Istela Cagnin Machado pela pacincia, dedicao e delicadeza nas orientaes. Aos meus professores pelo ensinamento. Aos meus pais pelo apoio, incentivo e confiana. minha irm Marlette pela ajuda e colaborao durante este trabalho. Ao meu irmo, minha cunhada e aos meus sobrinhos que souberam entender a minha ausncia. Ao meu namorado que conviveu e incentivou toda essa jornada. Aos meus amigos do mestrado Ana Claudia, Fabrcio, Ivair, Jos Ivo, Juliana, Laurindo, Marco, Silvia, Srgio, Richard e Vnia pelo companheirismo, pelos momentos felizes e de descontrao vividos. Aos meus amigos que estiveram me apoiando e compreenderam a minha ausncia. A todas as pessoas que ajudaram direta ou indiretamente na realizao deste sonho.

As reticncias so os trs primeiros passos do pensamento que continua por conta prpria o seu caminho(MRIO QUINTANA). No existe um caminho para a felicidade. A felicidade o caminho(GANDHI). Nunca ande pelo caminho traado, pois ele conduz somente at onde os outros foram(GRAHAM BELL). Digno de admirao aquele que tendo tropeado ao dar o primeiro passo, levanta-se e segue em frente(CARLOS FOX).

FERREIRA, Marliane Aldivina Oliveira. MR.GC-PARFAIT: Um Modelo de Referncia para a Atividade de Gerncia de Configurao do PARFAIT. 130 f. Dissertao (Mestrado em Cincia da Computao) - Centro Universitrio Eurpides de Marlia, Fundao de Ensino Eurpides Soares da Rocha, Marlia, 2007.

RESUMO

A Gerncia de Configurao (GC) de vital importncia para garantir a qualidade do software, pois auxilia o seu desenvolvimento apoiando o controle das mudanas e das verses dos artefatos elaborados. A busca pela qualidade no diferente no contexto de processos de reengenharia de software, no entanto h carncia no tratamento de GC nesses processos. PARFAIT um processo gil de reengenharia baseado em framework que tambm no fornece tratamento da GC de forma explcita e, devido sua caracterstica incremental, verses do sistema alvo so liberadas a cada iterao do processo. A problemtica do controle de verses quando se utiliza framework como apoio computacional, como o caso do processo PARFAIT, se torna maior uma vez que necessrio controlar tanto as verses do framework quanto as verses do sistema alvo. Assim, este trabalho tem como objetivo estabelecer um modelo de referncia para a atividade de GC do PARFAIT, tomando como base as normas e os modelos de maturidade existentes. Um estudo de caso de reengenharia de um sistema legado, utilizando o processo PARFAIT e o modelo de referncia proposto, conduzido a fim de analisar se tal modelo no afeta a agilidade do processo e se apia efetivamente o controle de verses do framework e do sistema alvo, mantendo a integridade dos mesmos.

Palavras-chaves: Gerncia de Configurao, Qualidade de Processo, Reengenharia gil e PARFAIT.

FERREIRA, Marliane Aldivina Oliveira. MR.GC-PARFAIT: A reference model of the activity of Configuration Management of the PARFAIT. 130 f. Dissertao (Mestrado em Cincia da Computao) - Centro Universitrio Eurpides de Marlia, Fundao de Ensino Eurpides Soares da Rocha, Marlia, 2007.

ABSTRACT

Configuration Management (CM) is too important in order to guarantee software quality, because it helps its development by supporting change control and elaborated artifacts versions. Searching for quality is not different in context of software reengineering processes, however there is a lack in CM treatment in these processes. PARFAIT is an agile reengineering process based on framework which does not supply CM treatment in an explicit way either and, due to its incremental characteristic, target system versions are delivered to each process iteration. Version control problematic becomes greater when it is used framework as computational support, as it is PARFAIT process case, since it is necessary to control as the framework versions as the target system ones. Thus, this work has as aim to establish a reference model for PARFAIT CM activity, by taking as base norms and existing maturity models. A reengineering case study of a legacy system, using PARFAIT process and the reference model proposed, is lead in order to analyze if such a model does not affect the process agility and to check if it supports effectively versions control of framework and target system, by keeping their integrity.

Keywords: Configuration Management, Process Quality, Agile Reengineering and PARFAIT.

LISTA DE FIGURAS

Figura 1 - Modelo de processo de desenvolvimento incremental .....................................................22 Figura 2 - Viso geral do PARFAIT..................................................................................................28 Figura 3 - Procedimentos que ocorrem no repositrio .....................................................................41 Figura 4 - Estrutura de derivao de verses ...................................................................................45 Figura 5 Grafo de controle de verso de framework e dos sistemas gerados................................47 Figura 6 - Viso geral da definio do MR.GC-PARFAIT ...............................................................68 Figura 7 Mtodo GQM ...................................................................................................................69 Figura 8 Esquema do repositrio .................................................................................................100 Figura 9 Diagrama de Caso de Uso..............................................................................................122 Figura 10 Diagrama de Classes ...................................................................................................123

LISTA DE QUADROS

Quadro 1 - Atividades de gerenciamento de configurao ...............................................................39 Quadro 2 - Consultas tpicas no repositrio de baseline ..................................................................40 Quadro 3 - Modelo do formulrio de solicitao de mudanas ........................................................42 Quadro 4 - Modelo de formulrio de solicitao de mudana..........................................................43 Quadro 5 Documentao no cdigo fonte das mudanas ocorridas..............................................43 Quadro 6 - Tcnicas para a identificao dos artefatos ...................................................................44 Quadro 7 - Fatores que determinam uma estratgia de release .......................................................45 Quadro 8 - Relatrios de gerncia de configurao .........................................................................46 Quadro 9 - Comparao das ferramentas de GC..............................................................................52 Quadro 10 - Metas e prticas da rea de processo GC do CMMI....................................................55 Quadro 11 - Comparao normas/modelos estudados......................................................................64 Quadro 12 Identificao das atividades de GC atendidas em cada norma/modelo ......................65 Quadro 13 Artefatos de GC elaborados pelas ativ. de GC encontradas nas normas/modelos......65 Quadro 14 Plano de mensurao GQM das atividades de GC......................................................71 Quadro 15 - Resultado da questo 1 .................................................................................................71 Quadro 16 Resultado da questo 2.................................................................................................72 Quadro 18 Resultado da questo 3.................................................................................................73 Quadro 17 Justificativas das prticas geis ...................................................................................75 Quadro 19 - Resultados da mdia ponderada das mtricas das atividades de GC ..........................76 Quadro 20 Plano de mensurao GQM dos artefatos elaborados pelas atividades de GC ..........77 Quadro 21 - Resultados da questo 4................................................................................................78 Quadro 22 Resultado da questo 5.................................................................................................78

Quadro 23 Justificativas das prticas geis ...................................................................................79 Quadro 24 - Resultados da mdia ponderada das mtricas dos artefatos de GC.............................79 Quadro 25 - Atividades do PARFAIT versus atividades de GC ........................................................81 Quadro 26 Resumo da documentao do MR.GC-PARFAIT.........................................................82 Quadro 27 - Gabarito da documentao das verses do sistema alvo .............................................84 Quadro 28 - Gabarito da documentao das verses do framework ................................................84 Quadro 29 - Gabarito da documentao das verses dos itens de configurao .............................85 Quadro 30 - Gabarito do formulrio de controle de mudanas no sistema alvo..............................86 Quadro 31 - Gabarito do formulrio de controle de mudanas no framework ................................86 Quadro 32 Gabarito do formulrio de controle de mudanas dos demais itens de configurao.87 Quadro 33 - Dados coletados durante o estudo de caso ...................................................................99 Quadro 34 - Listagem dos itens de configurao do PARFAIT ......................................................115 Quadro 35 - Gabarito da documentao das verses do sistema alvo ...........................................118 Quadro 36 - Gabarito da documentao das verses do framework ..............................................118 Quadro 37 - Gabarito da documentao das verses dos itens de configurao ...........................119 Quadro 38 - Gabarito do formulrio de controle de mudanas no sistema alvo............................120 Quadro 39 - Gabarito do formulrio de controle de mudanas no framework ..............................120 Quadro 40 Gabarito do form de controle de mudanas dos demais itens de configurao ........121 Quadro 41 Casos de teste genricos do Padro 1........................................................................125 Quadro 42 - Casos de teste genricos do Padro 2 ........................................................................126 Quadro 43 - Casos de teste genricos do Padro 4 ........................................................................130

LISTA DE TABELAS

Tabela 1 - Tempo gasto em cada iterao das atividades do PARFAIT e do MR.GC-PARFAIT.....94 Tabela 2 Casos de testes gerais ......................................................................................................97 Tabela 3 - Classes de equivalncia criadas para os tipos de dados especiais do GREN .................97 Tabela 4 Requisitos de teste criados para os tipos de dados especiais do GREN .........................98 Tabela 5 - Comparao do tempo gasto no estudo de caso ..............................................................99

LISTA DE ABREVIATURAS E SIGLAS

ARA CELEPAR CenPRA CESAR CMM CMMI COPPE/UFRJ CRF CVS FaPRE/OO GC GG GP GQM HTML IEEE IPD-CMM ISO LPA MA-MPS MAS MASA MCT MPS.BR MR-MPS

Arcabouo de Reengenharia gil Companhia de Informtica do Paran Centro de Pesquisa Renato Archer Centro de Estudos e Sistemas Avanados de Recife Capability Maturity Model Capability Maturity Model Integration Departamento de Computao da Universidade Federal do Rio de Janeiro Chance Request Form Concurrent Versions System Famlia de Padres de Reengenharia Orientada a Objeto Gerncia de Configurao Generic Goal Generic Practice Goal Question Metric HyperText Markup Language Institute of Electrical and Electronics Engineers Integrated Product Development Capability Maturity Model International Standards Organization Linguagem de Padres de Anlise Mtodo de Avaliao do MPS.BR Modelo de Anlise do Sistema Modelo de Anlise do Sistema Atual Ministrio da Comunicao e Tecnologia Melhoria de Processo do Software Brasileiro Modelo de Negcio do MPS.BR

MR.GC-PARFAIT Modelo de Referncia para a atividade de Gerncia de Configurao do PARFAIT OO Orientao a Objetos

PARFAIT

Processo gil de Reengenharia baseado em Framework no domnio de sistemas de Informao com tcnicas de VV&T

PREF PMBOK PMI PMQ PRE/OO RCS RIOSOF

Processo de Evoluo de Framework Project Management Body of Knowledge Project Management Institute Project Management Quarterly Processo de Reengenharia Orientada a Objeto Revision Control System Sociedade Ncleo de Apoio Produo e Exportao de Software do Rio de Janeiro

RUP SECM SEPIN SG SOFTEX SP SW-CMM TR UML VV&T

Rational Unified Process Systems Engineering Capability Model Secretaria de Poltica de Informtica do Ministrio da Cincia e Tecnologia Specific Goal Associao para Promoo da Excelncia do Software Brasileiro Specific Practice Capability Maturity Model for Software Teste de Regresso Unified Modeling Language Verificao, Validao e Teste

SUMRIO

1 INTRODUO .............................................................................................................................16 1.1 CONTEXTO ..................................................................................................................................16 1.2 MOTIVAO ................................................................................................................................17 1.3 OBJETIVOS ..................................................................................................................................18 1.4 ORGANIZAO DO TRABALHO ....................................................................................................18 2 PROCESSO DE SOFTWARE ......................................................................................................20 2.1 CONSIDERAES INICIAIS ...........................................................................................................20 2.2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE........................................................................20 2.2.1 Processos de Reengenharia de Software ................................................................................22 2.2.1.1 Processo de Reengenharia Orientada a Objeto (PRE/OO).............................................23 2.2.1.2 Processo gil de Reengenharia baseado em Framework no domnio de sistemas de Informao com tcnicas de VV&T (PARFAIT) ..........................................................25 2.2.1.3 Processo de Reengenharia Baseado em Componente Distribudo (PRBCD) ................30 2.3 CONSIDERAES FINAIS ..............................................................................................................32 3 QUALIDADE DE SOFTWARE DO PONTO DE VISTA DE GERNCIA DE CONFIGURAO ..........................................................................................................................34 3.1 CONSIDERAES INICIAIS ...........................................................................................................34 3.2 QUALIDADE DE SOFTWARE ..........................................................................................................34 3.3 GERNCIA DE CONFIGURAO DE SOFTWARE..............................................................................36 3.3.1 Conceitos importantes de GC ................................................................................................38 3.3.2 Atividades de Gerncia de Configurao...............................................................................39 3.3.2.1 Identificar os itens de configurao................................................................................40 3.3.2.2 Criar um repositrio .......................................................................................................40 3.3.2.3 Gerenciar mudanas .......................................................................................................41 3.3.2.4 Gerenciar as verses .......................................................................................................44 3.3.2.5 Gerenciamento de releases .............................................................................................45 3.3.2.6 Implantao de Gerncia de Configurao.....................................................................46 3.3.3 Problemtica de GC na reengenharia baseada em framework ...............................................46

3.3.4 Trabalho correlato ..................................................................................................................47 3.4 FERRAMENTAS DE APOIO GC ...................................................................................................48 3.4.1 Revision Control System (RCS) .............................................................................................49 3.4.2 Concurrent Versions System (CVS).......................................................................................50 3.4.3 GNU Arch ..............................................................................................................................51 3.4.4 Subversion ..............................................................................................................................51 3.4.5 Comparao das ferramentas de GC ......................................................................................52 3.5 CONSIDERAES FINAIS ..............................................................................................................53 4 NORMAS E MODELOS DE QUALIDADE DE SOFTWARE .................................................54 4.1 CONSIDERAES INICIAIS ...........................................................................................................54 4.2 CMMI SOB A PERSPECTIVA DA GERNCIA DE CONFIGURAO ...................................................54 4.3 NBR ISO/IEC 12207 SOB A PERSPECTIVA DA GERNCIA DE CONFIGURAO ............................57 4.4 ISO/IEC 15504 SOB A PERSPECTIVA DA GERNCIA DE CONFIGURAO .....................................58 4.5 ISO/IEC 10007 - SISTEMAS DE GESTO DA QUALIDADE DIRETRIZES PARA A GESTO DE CONFIGURAO ................................................................................................................................59 4.6 MR-MPS SOB A PERSPECTIVA DA GERNCIA DE CONFIGURAO ..............................................61 4.7 PMBOK SOB A PERSPECTIVA DA GERNCIA DE CONFIGURAO ................................................62 4.8 COMPARAO DAS NORMAS E MODELOS DE MATURIDADE ESTUDADOS....................................63 4.9 CONSIDERAES FINAIS ..............................................................................................................66 5 MR.GC-PARFAIT: MODELO DE REFERNCIA DE GC DO PARFAIT ..........................67 5.1 CONSIDERAES INICIAIS ...........................................................................................................67 5.2 ETAPAS PARA DEFINIO DO MR.GC-PARFAIT .......................................................................67 5.2.1 1 Etapa: Selecionar as Atividades Essenciais de GC............................................................69 5.2.2 2 Etapa: Selecionar os Artefatos Essenciais de GC ..............................................................76 5.2.3 3 Etapa: Identificar a Aplicabilidade das Atividades Essenciais de GC nas Atividades do PARFAIT .......................................................................................................................................80 5.3 4 ETAPA: ELABORAR A DOCUMENTAO DO MR.GC-PARFAIT ..............................................81 5.3.1 Atividade: Gerenciar as Verses (Obrigatria)......................................................................82 5.3.2 Atividade Gerenciar as Mudanas (Obrigatria) ...................................................................85 5.4 CONSIDERAES FINAIS ..............................................................................................................87 6 ESTUDO DE CASO: PARFAIT E MR.GC-PARFAIT ............................................................89

6.1 CONSIDERAES INICIAIS ............................................................................................................89 6.2 PLANEJAMENTO DO ESTUDO DE CASO PARA AVALIAR O MR.GC-PARFAIT..............................89 6.2.1 Definio ................................................................................................................................89 6.2.2 Planejamento ..........................................................................................................................91 6.3 OPERAO ..................................................................................................................................93 6.3.1 Criao dos Casos de Teste Genricos ..................................................................................96 6.3.2 Anlise e Interpretao dos Resultados .................................................................................98 6.3.3 Discusso ...............................................................................................................................99 6.4 CONSIDERAES FINAIS ............................................................................................................101 7 CONCLUSES............................................................................................................................102 7.1 LIMITAES ..............................................................................................................................103 7.2 SUGESTES DE TRABALHOS FUTUROS.......................................................................................103 REFERNCIAS .............................................................................................................................105 APNDICE A.................................................................................................................................113 APNDICE B .................................................................................................................................122 APNDICE C.................................................................................................................................124

INTRODUO

1.1 Contexto

O progresso da Engenharia de Software carrega consigo a preocupao com a incorporao da qualidade no desenvolvimento, proporcionando uma melhoria no produto final entregue aos usurios. Para garantir essa qualidade durante o ciclo de vida do software so empregadas diversas atividades de apoio, dentre elas destaca-se a Gerncia de Configurao (GC) (SOMMERVILLE, 2003; PRESSMAN, 2006) que ser tratada neste trabalho. Constata-se que mudanas no software so inevitveis durante e aps o seu desenvolvimento, as quais podem ser classificadas em quatro tipos: adaptativa, perfectiva, corretiva e preventiva. Na primeira, o sistema alvo adaptado a novas tecnologias tanto de software quanto hardware. Na segunda, novas funcionalidades relacionadas s regras de negcio ou s mudanas nas polticas governamentais so adicionadas. Na terceira, erros ocorridos durante o desenvolvimento ou nas mudanas realizadas posteriormente so corrigidos. Na quarta, melhorias no sistema com o intuito de facilitar futuras correes e aumentar a confiabilidade so providas. Assim, a GC empregada como atividade de apoio, cuja responsabilidade est presente na identificao, na documentao, no armazenamento, no controle e no relato das mudanas ocorridas nos artefatos elaborados durante e depois do desenvolvimento do sistema (CUNHA et al., 2004; PRESSMAN, 2006). Apesar da importncia de GC, poucas empresas a utilizam devido ao custo, tempo e a ausncia de profissionais qualificados (PRESSMAN, 2006). A importncia da qualidade tambm no diferente no contexto de reengenharia gil, que entrega uma verso do sistema alvo funcionando adequadamente o mais rpido possvel. Para que isso ocorra, o usurio participa ativamente durante todo o projeto, que realizado de forma incremental. Casos de testes funcionais so utilizados para apoiar o entendimento do sistema legado1 e so empregados posteriormente para testar o sistema alvo (novo sistema) (CAGNIN, 2005a). A reengenharia reimplementa o sistema legado levando em considerao as funcionalidades

um sistema desatualizado que pode no ter ou ter apenas uma parte da documentao adequada para a manuteno. Esse sistema permanece em uso pela dificuldade de substitu-lo e de modific-lo, bem como do custo em transform-lo em um novo sistema (sistema alvo) (CAGNIN, 2005; ESPINDOLA et al., 2004).

17

e as regras de negcio nele contidas (SOMMERVILLE, 2003; PRESSMAN, 2006), podendo incorporar novas funcionalidades de acordo com as necessidades dos usurios. Pode-se observar a carncia na literatura da atividade de GC em processos de reengenharia (CAGNIN, 2005a; LEMOS et al., 2003; FONTANETTE et al., 2002a), pois, como no desenvolvimento de software, necessrio se preocupar com o controle sistemtico das modificaes que devem ser realizadas durante a reengenharia, a fim de produzir um sistema alvo com qualidade. Ressalta-se ainda a problemtica no controle de verso em processos geis de reengenharia baseados em framework2, uma vez que necessrio controlar as mudanas e as verses tanto no framework quanto nos sistemas gerados por ele. Salienta-se que, como a arquitetura do sistema gerado passa a englobar o prprio framework (ARIMOTO et al., 2007), modificaes sem precauo no framework podem prejudicar o comportamento dos sistemas gerados, fazendo com que os mesmos deixem de fornecer o comportamento desejado. Para apoiar a atividade de GC tanto no desenvolvimento quanto na reengenharia de software imprescindvel a utilizao de ferramentas especficas, como o caso da Revision Control System (RCS) (TICHY, 1997), da Concurrent Versions System (CVS) (XIMBIOT, 2005), da GNU Arch (TOSUN, 2004) e da Subversion (COLLINS-SUSSMAN et al., 2006).

1.2 Motivao

A GC um dos itens principais que levam garantia da qualidade de software por meio do controle das mudanas e das verses dos artefatos. O PARFAIT (Processo gil de Reengenharia baseado em FrAmework no domnio de sistemas de Informao com tcnicas de verificao, validao & Teste) (CAGNIN, 2005a) um processo gil de reengenharia que contm algumas diretrizes que tratam da GC, no entanto, no possui atividades especficas de GC. Essa carncia foi observada durante alguns estudos de caso utilizando tal processo (CAGNIN et al., 2004; CAGNIN et al., 2003b). Assim, necessrio minimizar essa carncia sem afetar a agilidade do processo, de acordo com o tratamento de GC provido pelas normas e modelos de qualidade existentes na

Permite o desenvolvimento de sistemas poupando tempo e esforo, por meio do reso de diretrizes durante toda a fase do desenvolvimento de software.

18

literatura. O PARFAIT utiliza framework, portanto, necessrio um tratamento especial das atividades de GC, levando-se em considerao que, alm de gerenciar as verses dos artefatos produzidos durante a reengenharia, devem-se gerenciar as verses do framework e as verses do sistema gerado a partir dele.

1.3 Objetivos

Este trabalho tem como objetivo elaborar um modelo de referncia para a atividade de GC do PARFAIT, sob a perspectiva dos diferentes modelos e normas de maturidade de software existentes, por exemplo, ISO/IEC 12207 (1998), ISO/IEC 15504 (1999), ISO/IEC 10007 (2005), ISO/IEC TR 15846 (1998), CMMI (SEI, 2001), MR-MPS (SOFTEX, 2005) e PMBOK (PMI, 2004). Para isso observada a ocorrncia das atividades de GC em cada norma/modelo, com o apoio do Goal Question Metric GQM (BASILI et al., 1994), a fim de definir as melhores prticas para o PARFAIT, sem afetar a sua agilidade. Para avaliar o modelo de referncia definido conduzido um estudo de caso de reengenharia, a fim de observar se afeta a agilidade do processo PARFAIT e se mantm a integridade das verses do framework e do sistema alvo. Salienta-se que o processo PARFAIT emprega atividades de VV&T para o entendimento das funcionalidades do sistema legado e, posteriormente, as utiliza no sistema alvo a fim de valid-lo e de verificar se o mesmo possui comportamento similar ao do sistema legado. Deve-se levar em considerao que, alm destas normas e modelos estudados ainda existem algumas que tratam da GC como o caso da ISO/IEC 15846 (1998), que apresenta um relatrio tcnico definido pela norma ISO/IEC 12207, da IEEE Std 828 (1998), que apresenta os artefatos que devem ser abordados pela GC e da IEEE 1042 (1986), que apresenta um guia de apoio para a aplicao da GC. No entanto, tais normas no sero tratadas neste trabalho.

1.4 Organizao do Trabalho

Este trabalho est organizado em sete captulos e trs apndices, como descritos a seguir.

19

O presente captulo contextualizou a importncia da gerncia de configurao como atividade de apoio tanto no desenvolvimento como na reengenharia, e delimitou a problemtica existente no controle de verses durante a reengenharia gil baseada em framework. No Captulo 2 apresentam-se conceitos e a importncia de processos de software, tanto para o desenvolvimento quanto para a reengenharia. Tambm se confere um enfoque especial ao processo gil de reengenharia PARFAIT, que de interesse deste trabalho. No Captulo 3 so abordados os conceitos para o entendimento de gerncia de configurao, as atividades principais para execut-la e algumas ferramentas de apoio encontradas na literatura. No Captulo 4 apresenta-se a descrio de algumas normas e modelos de maturidade encontrados na literatura sob a perspectiva da atividade de GC. No Captulo 5 observado o procedimento adotado na escolha das atividades e dos artefatos essenciais de GC para o PARFAIT com o apoio do mtodo GQM (Goal Question Metric) e da mtrica grau de importncia criada nesta dissertao. A partir desta seleo compe-se o modelo de referncia denominado MR.GC-PARFAIT, proposto neste trabalho, apresentando um detalhamento das atividades de GC estabelecidas para esse modelo e a aplicabilidade das mesmas no PARFAIT. O Captulo 6 consiste da conduo de um estudo de caso quantitativo de um sistema legado para analisar a viabilidade do emprego do MR.GC-PARFAIT, em conjunto com o processo PARFAIT, e verificar se tal modelo no afeta a agilidade desse processo e se a integridade dos artefatos produzidos mantida. Adicionalmente, apresenta-se a melhoria de uma abordagem de reso de teste existente, denominada ARTe, que foi obtida com a criao de casos de teste genricos. Finalmente, no Captulo 7 encontram-se as concluses do trabalho realizado, destacando-se as suas limitaes e perspectivas de trabalhos futuros. No Apndice A so apresentadas a documentao completa do modelo MR.GC-PARFAIT, contendo a descrio das atividades de GC e da aplicabilidade das mesmas nas atividades do PARFAIT. No Apndice B apresenta-se a verso final do diagrama de casos de uso e do diagrama de classe criados no estudo de caso conduzido neste trabalho. O Apndice C rene os casos de teste genricos criados neste trabalho e que foram incorporados abordagem ARTe, aumentando o seu potencial de apoio ao reso de teste.

PROCESSO DE SOFTWARE

2.1 Consideraes Iniciais

Neste captulo encontra-se o embasamento terico relacionado a processos de software para a compreenso deste trabalho. Na Seo 2.2 so apresentados os conceitos de processo de desenvolvimento e de reengenharia de software. Alm disso, so abordados alguns processos de reengenharia, destacando a carncia existente no tratamento de Gerncia de Configurao por tais processos. E, finalmente, na Seo 2.3 so apresentadas as consideraes finais deste captulo.

2.2 Processo de Desenvolvimento de Software

O processo de desenvolvimento de software possui vrias definies na literatura. Para Pfleeger (2004), chamado de ciclo de vida do software que descreve a produo de um software desde o surgimento da proposta de desenvolvimento at o seu desuso. J Sommerville (2003) define processo de desenvolvimento de software como um agregado de atividades e de resultados que ir proporcionar a produo do software. Pressman (2006) descreve como um procedimento que elabora o software, incluindo os mtodos, as tcnicas e as ferramentas de apoio. Peters; Pedrycz (2001) definem o processo de desenvolvimento de software como uma seqncia de etapas com feedback que resultam na produo e na evoluo do software. Segundo Fuggeta (1997 apud FIORINI, 2001), trata-se de um conjunto coerente de polticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que so necessrios para conceber, desenvolver, entregar e manter um produto de software. Assim, o ciclo de vida examina, entende, controla, aprimora e padroniza as atividades de desenvolvimento do software. A vantagem de se empregar um processo padronizado a reduo de tempo referente ao treinamento e ao compartilhamento das experincias que contribuem para o aprendizado (PFLEEGER, 2004; SOMMERVILLE, 2003). Pressman (2006), Sommerville (2003) e Pfleeger (2004) descrevem as principais atividades que compem um processo de software: especificao

21

dos requisitos; projeto de desenvolvimento; implementao das funcionalidades dos requisitos; verificao; validao e teste (VV&T), bem como manuteno do mesmo. A melhoria no processo de desenvolvimento de software tem sido alvo de pesquisas dentro da Engenharia de Software e visa aprimorar as tcnicas e os modelos utilizados. Para alcanar essa melhoria, as atividades dos processos so executadas com o emprego de padres e de diretrizes, com base nas normas ISO/IEC 15504 (1999), ISO/IEC 12207 (1998), ISO/IEC 10007 (2005) e nos modelos CMMI (SEI, 2001), MR-MPS (SOFTEX, 2005) e PMBOK (PMI, 2004) que foram estudados neste trabalho para apoiar a definio do modelo de referncia proposto e so apresentados no Captulo 3 sob a perspectiva de GC. Os padres aplicados no processo indicam como um modelo de processo deve ser seguido durante todo o desenvolvimento do software; desta forma, oferece uma soluo para resolver os problemas que so encontrados, possibilitando compartilhar as experincias dos desenvolvedores com o auxlio de uma documentao (PFLEEGER, 2004). Os modelos de processo de desenvolvimento de software vieram suprir a necessidade de auxiliar a criao do software. Com o emprego desses modelos pode-se desenvolver um software com qualidade. Nesta seo apresentado o modelo de processo incremental, que de interesse deste trabalho por ser utilizado pelo PARFAIT. O modelo de processo de desenvolvimento incremental foi sugerido por Mills et al. (1980 apud SOMMERVILLE, 2003) e apresenta uma seqncia linear das atividades a cada incremento do modelo, alm disso, proporciona a participao direta do usurio na indicao de quais funcionalidades tm prioridade de desenvolvimento (SOMMERVILLE, 2003). As atividades que compem cada incremento so: anlise, projeto, implementao e teste, como ilustrado na Figura 1. As vantagens apresentadas por este modelo, alm de ser incremental e iterativo, so: oferecer uma viso antecipada dos riscos; facilitar a criao de medidas para control-los ou elimin-los; facilitar as alteraes futuras; bem como possuir um conjunto de regras que auxilia o controle dessas alteraes. Entre as desvantagens destaca-se que o incremento deve ser relativamente pequeno (SOMMERVILLE, 2003; PRESSMAN, 2006). No desenvolvimento e na reengenharia incremental deve haver controle de verso em cada incremento. Visando facilitar esse controle e proporcionar a integrao das verses produzidas em cada incremento para compor o produto final, emprega-se a GC que discutida no Captulo 3.

22

Funcionalidades W X Y Z
Usurio

Incremento 1
Anlise Projeto Implementao Teste

Incremento 2
Anlise Projeto Implementao Teste

Incremento 3
Anlise Projeto Implementao Teste

Figura 1 - Modelo de processo de desenvolvimento incremental (adaptado de PRESSMAN, 2006)

2.2.1 Processos de Reengenharia de Software

Salienta-se que processos de software tambm so importantes no contexto de reengenharia, pois apiam a migrao de um sistema existente, denominado sistema legado (obsoleto), para um novo sistema, denominado sistema alvo. Em geral os sistemas legados esto em uso h muito tempo e as constantes atividades de manuteno neles realizadas podem colaborar para a degradao do cdigo fonte e para a desatualizao da documentao. Isso faz com que novas atividades de manuteno se tornem inviveis ou at mesmo impossveis de serem conduzidas, pois a nica documentao existente o prprio cdigo fonte desestruturado (POSTEMA; SCHIMIDT, 1998). Portanto, o sistema legado necessita ser evoludo para adequar-se tanto s necessidades dos usurios e clientes quanto s de hardware e de software. Existem vrias definies de reengenharia, entretanto, a mais utilizada a de Chikofsky e Cross (1990), que definiram termos relacionados: engenharia avante, engenharia reversa, reestruturao e reengenharia, descritos a seguir. A engenharia avante consiste na transferncia das abstraes, dos modelos lgicos e do projeto do sistema para uma implementao fsica. Enquanto que a engenharia reversa refere-se a um processo de anlise do sistema legado, que identifica seus componentes, seus relacionamentos e os apresenta em um nvel mais alto de abstrao. A engenharia reversa pode ser classificada como redocumentao e recuperao do projeto.

23

A redocumentao consiste em criar ou revisar uma representao da abstrao semntica do sistema, como por exemplo, o fluxo de dados e de controle, o diagrama de entidades e relacionamentos (DER) e a listagem de referncia cruzada dos elementos do cdigo fonte. A recuperao do projeto identifica no sistema as abstraes de alto nvel, isto , o domnio do conhecimento e das informaes externas e daquelas obtidas diretamente pela anlise do sistema, a fim de fornecer completo entendimento sobre o qu o sistema faz, como ele faz e por que ele faz de uma determinada maneira. A reestruturao consiste na transformao da representao do software para outra no mesmo nvel de abstrao, preservando o seu comportamento externo, isto , a sua funcionalidade e semntica. A reestruturao pode ser denominada, tambm, de refatorao (FOWLER et al., 1999). A reengenharia conhecida tambm como renovao e consiste na anlise e alterao do sistema para reconstru-lo em uma nova forma. Geralmente inclui engenharia reversa seguida por engenharia avante ou reestruturao. Os principais objetivos da reengenharia foram apresentados por Sneed; Nyary (1995 apud CAGNIN, 2005a) e constituem-se de: melhoria da manutenibilidade do sistema; migrao do sistema; uso de novas tecnologias para alcanar a confiabilidade e preparao do sistema para aumentar a sua funcionalidade. Dentre as definies apresentadas, a de reengenharia de interesse deste trabalho. Desta forma, alguns processos de reengenharia sero apresentados com maiores detalhes neste captulo. A seguir encontram-se dois processos (PRE/OO e PARFAIT) que utilizam a GC parcialmente durante a reengenharia e um outro (PRBCD) que no emprega essa atividade de apoio.

2.2.1.1

Processo de Reengenharia Orientada a Objeto (PRE/OO)

O PRE/OO uma evoluo da famlia de padres de reengenharia denominada FaPRE/OO (RECCHIA et al., 2002) e permite a reengenharia de sistemas legados desenvolvidos em Delphi procedimental para o paradigma orientado a objetos na linguagem Object Pascal (BORLAND, 2000) com o apoio do ambiente Delphi. As adaptaes realizadas no FaPRE/OO para permitir essa evoluo ocorrem nos seguintes padres: reconstruir a arquitetura do sistema legado; recuperar o

24

Modelo de Anlise do Sistema Atual (MASA)3 e criar o Modelo de Anlise do Sistema (MAS)4. Sendo assim, deve-se mapear o MAS para o MASA, elaborar o projeto avante e particionar o sistema. A Unified Modeling Language (UML) (BOOCH et al., 2000) foi utilizada no PRE/OO para representar a documentao do sistema alvo (LEMOS et al., 2003). PRE/OO composto por sete grupos de padres de reengenharia, os quais foram divididos em padres para a melhoria da qualidade do processo de reengenharia orientada a objetos (grupos 1 e 2) e padres para a conduo da reengenharia orientada a objetos (grupos 3 a 7). A melhoria da qualidade do processo considerada pelos grupos 1 e 2 foi baseada no nvel 2 de maturidade do Capability Maturity Model (CMM) (SEI, 2001). Os demais grupos tomaram como base o mtodo de engenharia reversa Fusion/RE (PENTEADO, 1996) e os padres da FaPRE/OO. O primeiro grupo de padres tem como objetivo preparar e planejar o processo de reengenharia, ou seja, determinar quais artefatos sero desenvolvidos e planejar as atividades de reengenharia a serem executadas. O segundo grupo de padres visa melhoria da qualidade do processo de reengenharia, mantendo e acompanhando o processo com as inspees de garantia de qualidade e com o controle da configurao, que estabelece e mantm a integridade dos artefatos elaborados. Dentre as atividades de GC foram empregadas trs neste processo: 1) identificar os itens de configurao; 2) documentar todas as mudanas dos itens de configurao com o auxlio de um cabealho que disponibiliza as seguintes informaes: o responsvel pela mudana, a data, o nome do item de configurao, a descrio da mudana, a verso e a origem (ou seja, passo do processo em que a verso do artefato foi produzida); e 3) estabelecer a criao de uma baseline ao final da execuo de cada passo do processo (LEMOS et al., 2003). Assim, foi constatada a presena destas atividades de GC, no entanto, ainda h necessidade de um aprimoramento do processo PRE/OO nesse sentido. O terceiro grupo de padres cria a arquitetura do sistema legado com a elaborao da documentao dos procedimentos e funcionalidades do sistema legado, obtendo o entendimento desses. O quarto grupo modela os dados do sistema legado com a construo do Diagrama de Entidades e Relacionamentos (DER), relaciona as anomalias referentes aos dados identificados e cria uma viso Orientada a Objetos (OO) desses dados. Alm disso, cria o diagrama de casos de uso do MASA contendo a descrio das funcionalidades e do comportamento do sistema legado

3 4

Sistema legado. Sistema alvo.

25

(LEMOS et al., 2003). Salienta-se que as anomalias so identificadas segundo quatro critrios: 1) procedimento ou funo que observa a tabela de dados; 2) procedimento ou funo que altera a tabela de dados; 3) procedimento ou funo relacionado a implementao; e 4) procedimento ou funo que observa e/ou altera duas ou mais tabelas de dados. O quinto grupo apia a elaborao de um Modelo de Anlise do Sistema alvo (MAS) com a abstrao do diagrama de pseudo-classes, a criao do diagrama de casos de uso do MAS baseado na viso OO do sistema legado e a descrio dos casos de uso do MAS a partir da reespecificao das descries do sistema legado, mas com alterao na abstrao (LEMOS et al., 2003). O sexto grupo de padres visa construir um projeto avante que contm a elaborao do diagrama de classe e do diagrama de seqncia. Esse ltimo ir documentar a lgica do negcio do sistema legado (LEMOS et al., 2003). O stimo grupo tem como objetivo implementar as classes, resultantes da aplicao dos padres anteriores, bem como as regras de negcio, o encapsulamento dos mtodos de acesso aos dados e a interface grfica do sistema alvo (LEMOS et al., 2003).

2.2.1.2

Processo gil de Reengenharia baseado em Framework no domnio de sistemas de Informao com tcnicas de VV&T (PARFAIT)

O PARFAIT (CAGNIN et al., 2003a) um processo gil, incremental e iterativo, que visa migrar sistemas legados procedimentais para o paradigma orientado a objetos. Ele um dos recursos do Arcabouo de Reengenharia gil (ARA) que apia a reengenharia gil baseada em linguagens de padres (APPLETON, 1997) e frameworks (FAYAD et al., 1999). Framework considerado uma aplicao semicompleta, com componentes estticos e dinmicos que com sua instanciao geram aplicaes especficas a um domnio para o usurio (FAYAD et al., 1999). A Linguagem de Padres de Anlise (LPA) utilizada pelo PARFAIT como apoio no entendimento do domnio do sistema legado e na documentao orientada a objetos desse sistema. A LPA consiste de um conjunto de informaes sobre as decises tomadas com a ajuda das regras e das diretrizes que sero transferidas por meio destas experincias adquiridas pelo desenvolvedor na soluo de problemas encontrados no recorrer da anlise (APPLETON, 1997).

26

A justificativa de utilizao de framework pelo ARA, consequentemente pelo PARFAIT, o apoio que este oferece na criao de uma verso do sistema alvo o mais rpido possvel. O ARA conta tambm com a participao dos clientes durante todo o projeto de reengenharia para validar os artefatos produzidos, e tambm utiliza reengenharia guiada por teste. Nessa ltima prtica, casos de teste so criados por meio de critrios de teste funcionais (MYERS, 2004) e so executados no sistema legado para apoiar a engenharia reversa no entendimento das funcionalidades e na identificao de regras de negcio e, posteriormente, so utilizados para validar o sistema alvo. Salienta-se que as funcionalidades presentes no sistema legado podem ser evoludas de acordo com as necessidades dos usurios. Por ser considerado gil, o PARFAIT utiliza diversas prticas de mtodos geis, como por exemplo: verses pequenas, clientes presentes, testes constantes, jogo do planejamento, programao em pares, propriedade coletiva do cdigo, integrao contnua, metfora e 40 horas semanais. Alm das prticas geis, o PARFAIT tambm trata da Modelagem gil (MA) (AMBELER, 2004) que, de acordo com CAGNIN (2005a), tem como objetivo principal, no contexto do PARFAIT, documentar o sistema legado com agilidade, promovendo o entendimento e facilitando a comunicao entre os engenheiros de software. Para isso, o processo PARFAIT fornece gabaritos dos artefatos que devem ser produzidos durante a reengenharia para reduzir o tempo de criao da documentao; motiva a participao dos usurios na validao dos artefatos; permite que os requisitos sofram modificaes quando necessrio; motiva a construo de um modelo simplificado e de fcil entendimento; constri a documentao do sistema de maneira iterativa e incremental, levando em considerao as necessidades e prioridades do usurio; e cria diversos tipos de modelos para tratar de cada particularidade do sistema legado, de acordo com as necessidades do projeto, sendo que alguns so opcionais. A Modelagem gil (MA) contribui para o emprego de um conjunto de prticas que gera uma documentao e uma modelagem eficaz, entretanto no descreve os procedimentos detalhados, mas oferece indicaes de como modelar de maneira eficiente, pois mistura as prticas simples de modelagem com os artefatos essenciais de modelagem de software (AMBLER, 2004). No PARFAIT h reso em vrios nveis de abstrao (anlise, projeto, implementao, teste e manuteno), que proporcionado indiretamente pelo arcabouo ARA. Detalhes sobre o PARFAIT so obtidos em CAGNIN (2005a).

27

A documentao de todas as atividades do PARFAIT foi baseada no formato da documentao do Rational Unified Process (RUP) (KRUCHTEN, 2000), mas no contexto de reengenharia. Este formato composto por fases, marcos de referncia, atividades, passos, papis, artefatos de entrada e de sada, disciplinas, gabaritos, diretrizes e guia de ferramenta de apoio computacional. A modelagem dos diagramas feita em UML. As fases do PARFAIT se dividem em: Concepo, Elaborao, Construo e Transio (CAGNIN, 2005a), como ilustrado na Figura 2. A Fase de Concepo contm atividades que visam: a) familiarizar o engenheiro de software com o domnio do framework disponvel; b) identificar o domnio do sistema legado; c) comparar o domnio do sistema legado em relao ao domnio do framework disponvel, para que este possa ser utilizado como apoio computacional; e d) elaborar o planejamento de reengenharia baseado no conhecimento adquirido em projetos anteriores com caractersticas similares, estabelecendo os riscos, o custo e o tempo que sero gastos no projeto de reengenharia. Na elaborao do cronograma, aconselha-se considerar pares de profissionais trabalhando em conjunto, no mximo, 40 horas semanais. Ainda como parte do planejamento do projeto de reengenharia, o responsvel pela reengenharia deve estabelecer quais artefatos sero submetidos ao controle de verso (itens de configurao). A Fase de Elaborao contm atividades que: a) criam e executam os casos de teste funcionais no sistema legado para a sua compreenso, elaborando os diagramas de casos de uso; b) criam o diagrama de classes do sistema legado no paradigma OO com o emprego de padres da linguagem de padres de anlise; e c) documentam as regras de negcio identificadas no sistema legado. Ainda no contexto das atividades da Fase de Elaborao, ressalta-se que toda classe e relacionamento representados no diagrama de classes, mas no reutilizados dos padres de anlise da linguagem de padres, so documentados em um artefato especfico. Esse artefato utilizado na prxima fase, durante a execuo da atividade que adapta o sistema alvo em relao ao sistema legado, pois o sistema gerado a partir da instanciao do framework fornece apenas as funcionalidades cobertas pelo domnio da linguagem de padres de anlise. A atividade de adaptar o sistema alvo tambm se baseia na documentao das regras de negcio do sistema legado que, em geral, no so fornecidas pelo framework.

28

Figura 2 - Viso geral do PARFAIT (CAGNIN, 2005a)

29

A Fase de Construo possui atividades que tm por objetivo: a) instanciar o framework, promovendo o desenvolvimento de uma verso do sistema alvo o mais rpido possvel; b) executar os casos de teste funcionais no sistema alvo, criados na Fase de Elaborao, para verificar a compatibilidade funcional do sistema alvo em relao ao sistema legado, permitindo identificar os requisitos e as regras de negcio do sistema legado que no foram cobertos pelo framework; e c) adaptar o sistema alvo para torn-lo funcionalmente semelhante ao legado. Na Fase de Transio as atividades tm por finalidade: a) gerar o manual do usurio do sistema; b) substituir a base de dados do sistema legado para a do sistema alvo; c) treinar os usurios, caso seja necessrio; e d) avaliar a maturidade do sistema alvo, executando todos os casos de teste documentados e observando a sua cobertura, caso seja de interesse. Deve-se ressaltar que em cada fase apresentada anteriormente h um marco de referncia que visa observar o cumprimento do projeto estabelecido na Fase de Concepo e pode estabelecer a continuidade ou no do projeto (CAGNIN, 2003). O PARFAIT trata apenas de alguns itens da GC de forma manual, assim, observou-se a necessidade de aperfeio-lo sob essa perspectiva. Dentre os itens de GC tratados pelo PARFAIT tem-se o controle de adaptaes implementadas manualmente no cdigo fonte das verses do sistema alvo. Essas adaptaes so realizadas em cada iterao do processo, a fim de tornar o sistema alvo funcionalmente equivalente ao sistema legado. Sem esse controle, essas adaptaes so perdidas em subseqentes instanciaes do framework. Quando o framework GREN utilizado como apoio computacional do PARFAIT, a ferramenta GRENWizardVersionControl (CAGNIN et al., 2004a) empregada para permitir esse controle. Apesar de o PARFAIT preocupar-se com a identificao dos itens de configurao logo no incio da aplicao do processo e ressaltar a importncia de controlar as verses de todos os artefatos produzidos durante a reengenharia, no mostra como aplicar a GC de maneira sistemtica. Durante o uso do PARFAIT evolues podem ser necessrias no framework para que o mesmo possa apoiar mais efetivamente a reengenharia. Para isso, sugere-se o uso do Processo de Evoluo de Framework (PREF) que pode ser executado em paralelo ao PARFAIT e utiliza um histrico de requisitos funcionais e no funcionais de sistemas que no foram cobertos pelo domnio do framework para decidir se deve ou no conduzir a evoluo do framework (CAGNIN et al., 2004a). Entre as atividades apresentadas pelo PREF destaca-se a oitava atividade, que foi utilizada como base para apoiar o desenvolvimento deste trabalho. Esta atividade denominada Tratar do Gerenciamento de Controle de Configurao, que deve ser executada com certo cuidado, pois

30

evolues em framework podem mudar o seu projeto e, conseqentemente, o dos sistemas gerados a partir da instanciao deles levando tais sistemas a deixarem de fornecer o comportamento desejado. necessrio estabelecer quando ser feita uma determinada alterao, definir em quais verses do framework esta manuteno ser introduzida, especificar se os sistemas gerados pelo framework devem ou no ser modificados para incorporar a evoluo do framework. CAGNIN (2005a) ressalta que a GC no contexto de framework similar a outro software, mas pode se tornar mais complexa devido a inmeras verses do framework e ferramentas de apoio a ele associadas. Alm disso, a GC deve ser aplicada tanto no framework quanto nas verses dos sistemas criados a partir dele. Ressalta-se, ainda, o emprego da Abordagem de Reso de Teste (ARTe) proposta por Cagnin et al. (2004). Esta abordagem tem como objetivo associar requisitos de teste a linguagens de padres (LP) a fim de permitir o reso no somente dos padres, mas tambm dos requisitos de teste. A ARTe um dos recursos disponveis no ARA, e vem suprir a necessidade de otimizar as atividades de VV&T do PARFAIT. Tal abordagem composta de duas etapas: na primeira so definidos os requisitos de teste funcional para cada padro da LP com o apoio dos critrios de teste Particionamento de Equivalncia e Anlise de Valor Limite (MYERS, 2004); na segunda etapa, tm-se diretrizes para possibilitar o reso tanto dos requisitos de teste definidos quanto das classes de equivalncia criadas quando do uso dos padres. Estudos de caso conduzidos (CAGNIN, 2005a) com e sem a abordagem ARTe mostraram uma reduo de mais de 50% do tempo da reengenharia quando os requisitos de teste so reutilizados.

2.2.1.3

Processo de Reengenharia Baseado em Componente Distribudo (PRBCD)

Fontanette et al. (2002a, 2002b, 2002c) tm empregado a reengenharia com o apoio do mtodo Catalysis (2006), que baseado em Componentes Distribudos, dos diagramas da UML, da ferramenta MVCASE (PRADO; LUCRCIO, 2001) e do Sistema Transformacional Draco (GARCIA et al., 2002). Os princpios adotados por Fontanette et al. (2002a) foram: abstrao, preciso e componentes plug-in. A abstrao auxilia na busca das caractersticas indispensveis ao sistema; a preciso tem como finalidade encontrar erros e problemas na modelagem; e os componentes

31

plug-in possibilitam a reutilizao dos mesmos durante a reengenharia (FONTANETTE et al., 2002a, 2002b, 2002c). Este processo utiliza o modelo de desenvolvimento espiral cuja principal caracterstica consiste de uma seqncia de atividades que possui um retorno, em loop, para a prxima atividade (PFLEEGER, 2004; SOMMERVILLE, 2003). Catalysis trata-se de um mtodo de desenvolvimento de software baseado em componentes distribudos. composto pelos seguintes nveis lgicos: domnio do problema, especificao dos componentes e projeto interno dos componentes. Estes nveis correspondem s seguintes atividades que fazem parte deste processo: identificao dos requisitos, especificao, projeto e implementao (FONTANETTE et al., 2002a, 2002b, 2002c). O nvel domnio do problema encontra os requisitos, determina solues para os problemas e identifica tipos de objetos e aes, possibilitando diferentes combinaes e vises por rea de negcio. O nvel especificao dos componentes identifica, determina o comportamento e a responsabilidade dos componentes. Este nvel contm o aprimoramento dos modelos de negcio e do domnio do problema. J o nvel projeto interno dos componentes se restringe ao meio fsico, isto , aos requisitos no-funcionais e s distribuies fsicas (FONTANETTE et al., 2002a). O Sistema Transformacional Draco (STD) empregado em conjunto com o Catalysis com a finalidade de construir um software por transformao orientada a domnio, segundo o paradigma Draco que divido em trs partes: linguagem (apresenta as especificaes do domnio e gera automaticamente a representao interna dos programas com as definies da gramtica da linguagem, denominada Draco Systax Abstract Tree (DAST)); prettyprinter (transforma a DAST em texto na linguagem de domnio); e transformadores (mapeiam as estruturas sintticas de uma determinada linguagem para outras estruturas e so responsveis pela automao do processo de reconstruo do software) (FONTANETTE et al., 2002a, 2002b). Para realizar a reengenharia de software com o apoio das transformaes empregam-se quatro passos: organizar cdigo do sistema legado, recuperar projeto, reprojetar e reimplementar (PENTEADO, 1996). No passo organizar cdigo do sistema legado utiliza-se o Draco e as tcnicas de Engenharia Reversa, que organizam as declaraes e os comandos do cdigo fonte do sistema legado sem prejudicar sua semntica e lgica. O passo recuperar projeto parte do cdigo do sistema legado, organizado anteriormente, e com o auxlio do Draco, gera as especificaes em UML do projeto do sistema legado e as

32

armazena em descries em Modeling Domain Language (MDL). Alm disso, criam-se prottipos das respectivas classes na linguagem Java (FONTANETTE et al., 2002a, 2002c). O passo reprojetar tem o apoio da ferramenta MVCASE, desenvolvendo o reprojeto orientado a componentes distribudos do projeto recuperado a partir do cdigo do sistema legado. Neste passo utiliza-se o mtodo Catalysis no domnio do problema, na especificao dos componentes e no projeto interno dos componentes (FONTANETTE et al., 2002a, 2002b). O passo reimplementar pode gerar automaticamente o cdigo do sistema alvo de duas maneiras: a) transformando as especificaes em MDL com o apoio do Draco; ou b) transformando os modelos de objetos e componentes de reprojeto com o apoio da ferramenta MVCASE (FONTANETTE et al., 2002a). Deve-se destacar que este processo no emprega atividades de GC e, portanto, nota-se a necessidade de aperfeioar tais atividades para atender aos processos de reengenharia de software, auxiliando o controle e a integridade dos artefatos gerados.

2.3 Consideraes Finais

Neste captulo foram apresentados os conceitos bsicos sobre processo de software no desenvolvimento e na reengenharia. Foram mostrados alguns processos de reengenharia, dando nfase ao processo PARFAIT, que de interesse deste trabalho. Devido a isso, apresentou-se uma breve descrio desse processo, destacando os objetivos de cada uma de suas atividades. Alm disso, ressaltou-se a deficincia desse processo em tratar da Gerncia de Configurao de forma sistemtica. Como o PARFAIT baseado em framework, necessrio aplicar a GC no somente nos artefatos produzidos durante o uso do processo como tambm no framework, utilizado como apoio computacional pelo processo. Observou-se que existem poucos processos de reengenharia presentes na literatura que aplicam a GC. Dentre os processos de reengenharia estudados, dois aplicam a GC (PRE/OO e PARFAIT), mas nenhum deles a considera de maneira sistematizada. Sob essa perspectiva, notouse a necessidade de incorporar a GC de forma sistemtica em processos de reengenharia, como o caso do PARFAIT, pois a GC um dos elementos importantes para a garantia da qualidade do software, no somente resultante do desenvolvimento como tambm da reengenharia.

33

No prximo captulo aborda-se detalhadamente a GC, dada a importncia neste trabalho do conhecimento sobre as atividades de GC, bem como dos artefatos que devem ser produzidos. Adicionalmente, discute-se a problemtica da GC na reengenharia baseada em framework e citamse algumas ferramentas existentes de controle de verso.

QUALIDADE DE SOFTWARE DO PONTO DE VISTA DE GERNCIA DE CONFIGURAO

3.1 Consideraes Iniciais

Este captulo apresenta os principais aspectos relacionados Qualidade de Software, com nfase na Gerncia de Configurao e algumas ferramentas open-source de apoio, ao controle de verses existente na literatura. Na Seo 3.2 apresenta-se o conceito de Qualidade de Software com os padres e diretrizes que so seguidos para garantir a qualidade no desenvolvimento. Na Seo 3.3 abordam-se os conceitos de Gerncia de Configurao, os passos que so seguidos para gerenciar as mudanas nos artefatos criados e para controlar as verses e os mesmos. Na Seo 3.4 descrevem-se algumas ferramentas existentes de apoio Gerncia de Configurao, mais especificamente o controle de verses, e faz-se um estudo comparativo dessas ferramentas.

3.2 Qualidade de Software

Pressman (2006) descreve qualidade como um procedimento para garantir a satisfao de padres de desenvolvimento de software, aplicando mtodos, ferramentas, revises, testes e controle de mudanas de seus artefatos. J Tsukumo et al. (1997) apresentam a qualidade como a satisfao das necessidades dos requisitos explcitos e implcitos, ou seja, os requisitos informados e os necessrios. Natali; Falbo (2004) citam a grande dificuldade em alcanar a qualidade no desenvolvimento de software, ou seja, seguir o uso de padres de desenvolvimento, localizar a causa das imperfeies e modific-las. Para isto, necessrio um planejamento para avaliar a qualidade durante todo o desenvolvimento do software, estabelecendo como o projeto deve ser executado, controlado e avaliado pelo gerente do projeto. Ele deve ter em mente qual a prioridade do uso de ferramentas para o apoio no gerenciamento do desenvolvimento que indique o que avaliar, quando deve ser avaliado, quem ser responsvel pela avaliao. Finalmente, quando todas

35

essas questes so respondidas tm-se as diretrizes no desenvolvimento de software com a eficincia e com o conhecimento adquirido no decorrer do tempo, que pode diminuir os erros posteriores, criando um software com qualidade. A qualidade no processo de desenvolvimento obtida com o emprego de diretrizes em todo o ciclo de vida do software, de estruturas das organizaes que desenvolvem o software e de atividades de suporte, que fornecem apoio durante todo o desenvolvimento. Constata-se que a qualidade do produto depende diretamente da qualidade do processo de desenvolvimento, verificando se o produto atende aos requisitos definidos com o emprego de uma avaliao sistemtica que oferece apoio para determinar as etapas a serem seguidas para essa avaliao de qualidade, como pode ser o caso da ISO/IEC 14598-55 (TSUKUMO et al., 1997). O engenheiro de software tem um papel importante na garantia da qualidade, pois deve garantir o controle do processo de desenvolvimento com o emprego de revises e testes. O grupo de Garantia da Qualidade do Software (SQA) auxilia a produo de um software por meio do planejamento das atividades, do emprego de padres de desenvolvimento, da satisfao dos usurios, da documentao e da manuteno (PRESSMAN, 2006). Jomori et al. (2004) afirmam que as empresas buscam a qualidade no desenvolvimento do software mediante o planejamento das atividades de desenvolvimento, assim, minimizam o nmero de defeitos e de falhas. J SantAnna et al. (2002) destacam que a melhoria da qualidade e da confiabilidade do software pode reduzir custo e alcanar o aumento da produtividade nas organizaes modernas. Outro ponto marcante pelo emprego da qualidade na reengenharia, pois a reengenharia transforma o sistema legado em um novo sistema evoludo tecnologicamente e pronto para ser utilizado pelo cliente. A padronizao na criao da documentao e a possvel reutilizao do cdigo no desenvolvimento do novo sistema possibilitam a diminuio do tempo, do custo e o aumento da qualidade. Deve-se acrescentar a Validao, a Verificao e o Teste (VV&T) nos artefatos produzidos durante a reengenharia para tambm garantir a qualidade no sistema alvo (CAGNIN, 2005a). Na reengenharia baseada em framework, devido problemtica anteriormente mencionada, as atividades de GC devem ser mais criteriosas, pois o framework tambm sofre mudanas que

ISO/IEC 14598-5, International Standard. Information Techonology - Software product evaluation Part 5: Process for evaluators, 1996.

36

podem comprometer o comportamento dos sistemas gerados anteriormente com o apoio do framework. Para garantir a qualidade do software tanto no desenvolvimento quanto na reengenharia apresentam-se algumas atividades de apoio que devem ser aplicadas durante todo o ciclo de vida do software, como o caso da Gerncia de Requisitos (HAZAN; LEITE, 2003; ESPINDOLA et al., 2005; PRESSMAN, 2006), da Gerncia de Projeto (SOMMERVILLE, 2003; PRESSMAN, 2006) e da Gerncia de Configurao. A Gerncia de Configurao de interesse deste trabalho por ser responsvel pelo controle das mudanas ocorridas nos artefatos de software, e pelo controle das suas verses, como exposto na seo a seguir (PRESSMAN, 2006; SOMMERVILLE, 2003).

3.3 Gerncia de Configurao de Software

A Gerncia de Configurao (GC) identifica e controla a integridade, o armazenamento de todos os artefatos criados no desenvolvimento do software e expe as modificaes sofridas em cada verso do software e em seus respectivos artefatos. Alm disso, facilita o controle das verses dos artefatos, pois vrias verses podem estar em operao com diferentes configuraes de hardware (PRESSMAN, 2006). As principais atividades da GC, de acordo com Sommerville (2003), so: identificar os artefatos; criar um repositrio de configurao; gerenciar as mudanas; gerenciar as verses; gerenciar as releases; efetuar revises de GC; e definir a ferramenta de apoio GC. Sommerville (2003) e Pressman (2006) apresentam a GC como responsvel por controlar as mudanas no ciclo de vida do software, desde o seu desenvolvimento at a sua manuteno, pois a necessidade de adaptao inevitvel. Assim, a GC descrita como uma gerncia que identifica, documenta, armazena, controla e relata as modificaes ocorridas nos artefatos (IEEE, 1990 apud LOPES et al., 2005). A necessidade de manuteno indiscutvel durante a vida do sistema, seja para se adequar plataforma e ao hardware, seja para corrigir os erros e mesmo para atender s necessidades do cliente. A fim de garantir a qualidade, aplica-se a padronizao nos artefatos e o uso de ferramentas

37

para auxiliar tanto na organizao quanto no desempenho da manuteno do sistema (SOMMERVILLE, 2003; PRESSMAN, 2006; ROCHA et al., 2001). Para realizar a manuteno so delegados alguns cargos (CUNHA et al., 2004): gerente do projeto: decide e distribui as atividades do projeto; engenheiro de software: implementa e faz a manuteno em todos os artefatos; comit de controle de configurao: define o nmero de pessoas, conforme o grau de complexidade, geralmente formado pelo gerente de projeto e os responsveis por cada mdulo de desenvolvimento; bibliotecrio: controla todos os artefatos armazenados; responsvel pelo gerenciamento de configurao: efetua todo o controle de mudanas nos artefatos com o auxlio de ferramenta; comit de engenharia de processo: coordena o processo de desenvolvimento; auditor: aplica os critrios de qualidade de software no projeto; comit de garantia de qualidade: determina quais os critrios de aprovao sero empregados em todos os artefatos mantidos, possibilitando a criao da baseline (Seo 3.3.1). Observa-se que a grande dificuldade em aplicar a GC est relacionada ao custo com equipamentos destinados apenas a essa atividade, com os programas especficos e com os encarregados aptos para exercer este controle de mudanas; cultura da empresa na resistncia em seguir regras e padres; ao aumento da formalidade e burocracia com a solicitao de autorizaes de mudanas com o emprego de formulrios; falta de conhecimento de GC; e ausncia ou pouco comprometimento presentes na empresa em desenvolver as atividades relacionadas GC (OLIVEIRA et al., 2001). A principal vantagem em se aplicar a GC, apontada por Pressman (2006), poder facilitar o aumento da produtividade e a diminuio dos erros com o gerenciamento dos artefatos, por meio da organizao, a qual favorece a localizao de um determinado artefato que ser reutilizado ou at mesmo modificado. Assim, a GC existe para facilitar o controle das verses e de seus respectivos artefatos, durante todo o ciclo de vida do software. Sommerville (2003) descreve a economia de tempo, durante e depois do desenvolvimento incremental, como a facilidade de gerar e obter verses diferentes de um mesmo produto, por meio de um histrico do artefato. O auxlio da GC no controle dos artefatos se torna rpido e preciso com o uso de ferramentas, sem as quais a aplicao de GC se tornaria impossvel podendo gerar questes

38

de dificuldade de controlar vrios artefatos com tempo e custo baixos (PRESSMAN, 2006; ROCHA et al., 2001).

3.3.1 Conceitos importantes de GC

Os conceitos de GC, descritos nesta seo, visam esclarecer a citao dos termos empregados nesta dissertao. artefatos ou itens de configurao: so todas as documentaes produzidas durante o desenvolvimento do software, por exemplo, documentos de requisitos, modelos de dados, modelos de anlise, modelos de projeto, cdigo fonte, executvel, etc. (ROCHA et al., 2001; CUNHA et al., 2004). baseline: apontada como um artefato utilizado como base para o desenvolvimento futuro, podendo ser alterado somente com o emprego do controle de mudana. Determina-se que este controle revise e aprove esta baseline, que alocada em um repositrio para manter a integridade dos dados (PRESSMAN, 2006; ROCHA et al., 2001; CUNHA et al., 2004; OLIVEIRA et al., 2001) e a conformidade com os requisitos do projeto (BERSOFF, 1984). Peters; Pedrycz (2001) descrevem baseline como um artefato que j tenha sido revisado e aprovado. A definio de baseline apresentada por Leite (et al., 1997 apud FIORINI; LEITE, 1998) determina um conjunto de artefatos aceitos e controlados que poder ser utilizado posteriormente, sendo que sua evoluo obtida com as alteraes, mediante uma solicitao e aprovao prvia. repositrio: armazena os artefatos estabelecendo a criao da baseline, registra as informaes e apia a avaliao do impacto que as mudanas podem causar no sistema. O procedimento utilizado o check-in/check-out. Isto , quando h necessidade de alterao de alguma baseline, uma cpia do artefato disponibilizada na rea de trabalho do desenvolvedor (check-out), e aps o trmino da alterao do artefato este restitudo no repositrio (check-in), em seguida, uma nova baseline deve ser traada. O responsvel pela GC define os procedimentos para registrar e recuperar os artefatos solicitados (SOMMERVILLE, 2003).

39

verses: so variaes distintas de um mesmo software que podem ser determinadas por diferentes funcionalidades, desempenhos ou por uma diferente configurao de software ou de hardware. Caso sofram pequenas mudanas podem ser chamadas de variantes da verso original. Um sistema variante possui um conjunto de atributos e de alguns elementos que sofreram modificaes, formando uma nova verso (SOMMERVILLE, 2003; PRESSMAN, 2006). release: uma verso previamente distribuda aos clientes (SOMMERVILLE, 2003; OLIVEIRA et al., 2001).

3.3.2 Atividades de Gerncia de Configurao

Sommerville (2003) e Rocha et al. (2001) estabelecem o planejamento de GC por meio de padres e procedimentos que podem ser aplicados em quaisquer empresas, podendo ser adaptados, se necessrio. No Quadro 1 encontram-se as atividades de GC que consistem, principalmente, em definir e identificar quais artefatos gerenciar; em criar um repositrio que mantenha e garanta a integridade das baselines; em definir quais os procedimentos sero adotados para que ocorra a mudana nos artefatos, como garantir o controle das verses e releases, quais procedimentos devem ser adotados para se implantar a GC; e em definir qual ferramenta se enquadra melhor dentro das expectativas esperadas (SOMMERVILLE, 2003).

Atividades de GC 1 Identificar os itens de configurao 2 Criar um repositrio de configurao 3 Gerenciar as mudanas

Objetivo Definir e identificar quais os artefatos que sero gerenciados. Armazenar e manter as baselines. Informar quais documentos e autorizaes so necessrios para que a mudana ocorra.

4 - Gerenciar as verses 5 Gerenciar as releases 6 Efetuar revises de GC 7 Definir a ferramenta de apoio GC

Garantir o controle das verses. Garantir o controle das releases. Determinar quais procedimentos sero adotados para implantar a GC. Definir qual ferramenta adequada ao controle de mudanas no sistema.

Quadro 1 - Atividades de gerenciamento de configurao (SOMMERVILLE, 2003)

40

3.3.2.1

Identificar os itens de configurao

Retomando a definio de itens de configurao, anteriormente apresentada na Seo 3.3.1, que se refere a todo tipo de documentao que possa servir para consultas futuras, deve-se ter cautela na identificao de quais os itens de configurao so importantes para todo o ciclo de desenvolvimento do software (SOMMERVILLE, 2003; PRESSMAN, 2006). Para melhor identificar tais itens de configurao, Pressman (2006), Sommerville (2003) e Rocha et al. (2001) sugerem a necessidade de determinar quais documentos devem ser controlados, investigar os planos de projeto, as especificaes, os projetos, os programas, os conjuntos de dados de teste e analisar todos os documentos necessrios para realizar a modificao do software. O cuidado na evoluo dos artefatos deve ser levado em conta, podendo criar um histrico desta evoluo.

3.3.2.2

Criar um repositrio

O repositrio armazena as informaes sobre todos os artefatos, como j foi abordado na Seo 3.3.1, referenciando a verso do sistema, organizando e delimitando os tipos de consultas e descrevendo quais consultas podem ser feitas no repositrio sobre uma determinada verso do software, como mostrado no Quadro 2.

Tipos de consultas realizadas no repositrio 1 Quais clientes receberam uma determinada verso do sistema? 2 Quais hardwares e sistemas operacionais so especficos para uma determinada verso? 3 Quantas e quais as datas das verses criadas? 4 Se um componente for modificado, quais verses podem ser afetadas? 5 Quantas solicitaes de mudanas podem ser realizadas para uma determinada verso? 6 Quantos defeitos uma verso especfica contm? Quadro 2 - Consultas tpicas no repositrio de baseline (adaptado de SOMMERVILLE, 2003)

41

Para melhor entender os procedimentos ocorridos no repositrio apresenta-se a Figura 3, a qual ilustra um conjunto de Tarefas de Engenharia de Software que desenvolve os artefatos que sofrem as revises tcnicas e formais, isto , os artefatos so validados, verificados e testados garantindo a sua consistncia e integridade. Aps a aprovao de cada artefato, feito o check-in e o seu armazenamento no repositrio, criando uma baseline. Existe tambm a recuperao de uma baseline por meio do check-out. O histrico das baselines permite estabelecer a finalidade de cada uma e reutiliz-la para a criao de uma nova verso tanto do artefato quanto do software.

Repositrio
Artefatos
aprovados Tarefas de Engenharia de Software armazenados

Artefatos

Revises tcnicas formais

Check-In
Artefatos Artefatos

Extrado Controle de GC

Artefatos

Check-Out

Baseline: Especificao do sistema Requisitos do software Especificao de projeto Cdigo-fonte Planos de teste procedimentos / Dados Sistema em condies de operao

Figura 3 - Procedimentos que ocorrem no repositrio (PRESSMAN, 2006)

3.3.2.3

Gerenciar mudanas

Inicialmente ser necessrio delegar a responsabilidade a um determinado encarregado (podendo ser o engenheiro de software) para o preenchimento do formulrio de solicitao de mudanas (CRF - chance request form), apresentado no Quadro 3, que apresenta e registra a modificao requerida no sistema. Nesse quadro consta tambm o custo da mudana, a data da solicitao da mudana para a submisso ao comit de controle de mudanas, a deciso tomada por esse comit, bem como a data dessa deciso, a implementao da mudana (se for o caso), as datas de submisso efetuada para a garantia de qualidade e para a GC. Aps a solicitao ponderado e decidido pelo comit de garantia da qualidade ou pelo gerente de projeto se tal mudana deve ser

42

atendida ou no, sendo a deciso determinada por uma anlise de impacto6. Se a solicitao no for atendida, ento o motivo deve ser encaminhado ao responsvel que fez a requisio da modificao (SOMMERVILLE, 2003; CUNHA et al., 2004).

Formulrio de Solicitao de Mudanas

Projeto: Nome do projeto Nmero: Nmero da verso Requisitante da Mudana: Nome do requisitante Data: data da solicitao Mudana solicitada: nome do arquivo que contm o artefato que ser modificado

Analista da Mudana: Nome do responsvel pela mudana Artefatos afetados: Nome dos artefatos que sero afetados pelas mudanas Artefatos associados: Nome dos artefatos associados a mudanas, mas no modificados Avaliao da mudana: grau de dificuldade de implementao e o que mudana requerida precisa Prioridade de mudanas: grau de prioridade da mudana

Implementao da mudana: Esforo estimado: tempo estimado Data para comit de controle de mudanas: data da submisso Data da deciso do comit de controle de mudanas: data do resultado da submisso Deciso do comit de controle de mudanas: deciso tomada

Data da submisso do comit de garantia da qualidade: data do teste Data de submisso a GC: data do resultado da GC Deciso do comit de garantia da qualidade: verifica e descreve se a modificao foi implementada corretamente

Quadro 3 - Modelo do formulrio de solicitao de mudanas (adaptado de SOMMERVILLE, 2003)

O comit de controle de configurao e o responsvel pela GC devem observar a necessidade de modificar os outros artefatos presentes na mesma verso do sistema e levantar o custo real para a mudana (SOMMERVILLE, 2003; PRESSMAN, 2006; CUNHA et al., 2004). Peters; Pedrycz (2001) apresentam um modelo, mais sucinto (Quadro 4), contendo apenas as principais caractersticas tratadas pelo modelo descrito por Sommerville (2003) (Quadro 3). Entretanto, com acrscimo de algumas caractersticas, como a opo que registra a aprovao ou no do pedido de mudana, ilustrada mais claramente, o custo/economia que a mudana ir proporcionar e a prioridade da mudana. Caso o registro das mudanas e dos problemas seja armazenado diariamente pela empresa desenvolvedora, apenas os componentes e os mdulos individuais sero afetados, isto , mantm-se um registro das mudanas sofridas por cada componente, realizando uma documentao padronizada no incio do cdigo fonte, como segue o modelo apresentado no Quadro 5. Caso as

A anlise de impacto oferece um entendimento das implicaes que uma determinada mudana pode proporcionar no software (LEE, 1998).

43

mudanas sejam feitas em mdulos, por diferentes desenvolvedores, tambm existe a necessidade de serem controladas (SOMMERVILLE, 2003).

Proposta de alterao

Data da submisso __/__/__ Prioridade

Nmero do formulrio Tipo

Nome e endereo da organizao que a originou Baseline afetada pela alterao: Descrio da alterao: Necessidade de alterao:

Projetos afetados pela alterao:

Programao estimada de entrega: __/__/__ Aprovada Desaprovada Assinatura:

Custo/ economia estimada pela alterao: Data da deciso: __/__/__

Quadro 4 - Modelo de formulrio de solicitao de mudana (adaptado de PETERS; PEDRYCZ, 2001)

// Nome do Projeto // // local que est o artefato //Objeto: nome do artefato //Autor: nome do desenvolvedor //Data da criao: data da criao do artefato //Histrico de Alteraes // //Verso Modificador Data data // N verso responsvel

Mudana o que mudou

Razo razo da mudana

Quadro 5 Documentao no cdigo fonte das mudanas ocorridas (adaptado de SOMMERVILLE, 2003)

Alm de planejar e controlar as mudanas, necessrio testar o artefato modificado. Assim, o teste de software se tornou de grande importncia na identificao e eliminao de erros, especialmente na fase de manuteno do software (ROCHA et al., 2001). Dessa forma, o Teste de Regresso (TR) foi criado para ser empregado exclusivamente nesta fase, com a reutilizao do conjunto de casos de teste j aplicado na verso anterior para observar se novos erros no foram introduzidos na verso atual do software, diminuindo custo e tempo associados. Caso esta reutilizao seja insuficiente, aconselha-se empregar novos casos de teste para verificar as modificaes aplicadas na verso atual do sistema (MARTIMIANO, 1999).

44

3.3.2.4

Gerenciar as verses

Como j foi apresentado na Seo 3.3.1, as verses so variaes de um mesmo software. As mudanas ocorridas na vida do software podem gerar problemas, caso no sejam gerenciadas. Deste modo, a atividade de gerenciamento de verses identifica e segue todo o processo de desenvolvimento de diferentes variantes de um determinado sistema. A liberao da nova verso deve ser realizada pela equipe de GC, a qual deve manter a qualidade do repositrio de dados (SOMMERVILLE, 2003; PRESSMAN, 2006). Para ajudar neste gerenciamento necessrio identificar os artefatos gerados para cada verso, facilitando a recuperao de uma determinada verso. Para auxiliar nessa identificao so empregadas trs tcnicas, as quais se encontram descritas no Quadro 6.

Tcnica 1 Numerao das verses 2 Identificao baseada em atributos

Descrio distribuir um nmero especfico e exclusivo de verso aos artefatos. determinar nome diferente aos artefatos em cada verso e um conjunto de atributos distintos para cada verso do artefato.

3 Identificao orientada a mudanas

tambm idealizada na identificao baseada em atributos, mas associa ao nome do artefato as mudanas efetuadas.

Quadro 6 - Tcnicas para a identificao dos artefatos (SOMMERVILLE, 2003)

Na numerao de verso (tcnica 1) deve-se constar o nome do componente ou do sistema acrescido de um nmero referente verso. A derivao de uma verso para outra pode fazer parte de uma verso anterior. Na Figura 4 ilustra-se uma estrutura com o controle das verses e suas respectivas evolues (SOMMERVILLE, 2003). Pode-se constatar nesta figura que a verso V1.0 ir derivar a V1.1 que, por sua vez, poder dar origem s verses V1.1b e V1.2, e a verso V1.1a derivar por sua vez a verso V2.0, e assim por diante. A identificao baseada em atributos (tcnica 2) localiza as verses que possuem o mesmo conjunto de atributos, como por exemplo, verses de cada componente, verso criada em um intervalo de data e verso para uma determinada plataforma. A identificao orientada mudana (tcnica 3) possui a facilidade de recuperao de uma determinada verso, pois utiliza a numerao simples no sistema, requer conhecimento de quais os atributos contidos e aplicao separadamente do gerenciamento de mudanas para descobrir as verses e as respectivas mudanas ocorridas (OLIVEIRA et al., 2001; SOMMERVILLE, 2003).

45

V1.1b

V1.1.1

V1.0

V1.1

V1.2

V2.0

V2.1

V2.2

V1.1a

Figura 4 - Estrutura de derivao de verses (SOMMERVILLE, 2003)

3.3.2.5

Gerenciamento de releases

Como definido anteriormente na Seo 3.3.1, as releases so verses do sistema distribudas aos clientes. Pode conter um arquivo descrevendo a configurao para a sua instalao, arquivos de dados utilizados para o bom funcionamento do sistema, documentao eletrnica apresentando o sistema e a embalagem e a publicidade relacionada release. A distribuio feita pelos gerentes de release, levando em considerao que uma nova release no deve depender da verso atual, pois o usurio pode migrar ou no para a nova release (OLIVEIRA et al., 2001; SOMMERVILLE, 2003). O Quadro 7 aponta alguns fatores que podem influenciar a criao de uma nova release. A documentao produzida no desenvolvimento da release extremamente eficaz, pois pode ser empregada no cdigo-fonte, no sistema operacional, em todos os dados, nos arquivos de configurao, nas bibliotecas, nos compiladores, nas ferramentas e nas plataformas devem possuir as mudanas ocorridas na release (SOMMERVILLE, 2003).

Fator Qualidade tcnica do sistema Quinta lei de Lehman Competio Requisitos de mercado Propostas de mudanas do cliente

Descrio Em caso de defeitos muito srios ser indispensvel a utilizao de uma release de correo, mas se os defeitos forem pequenos um patch pode ser distribudo. Com o aumento de funcionalidade em uma release, uma release pode ser seguida de uma outra release de correo. Se o concorrente disponibilizar uma outra verso com alguma funcionalidade, pode ser inevitvel a criao de uma nova release. A data de lanamento de determinada release nova ser definida pelo pessoal do marketing. Caso o cliente tenha solicitado algumas mudanas, deve-se esperar a release com as modificaes requisitadas.

Quadro 7 - Fatores que determinam uma estratgia de release (SOMMERVILLE, 2003)

46

3.3.2.6

Implantao de Gerncia de Configurao

Para melhor administrar o gerenciamento dos artefatos so emitidos relatrios durante todo o processo de desenvolvimento que podero versar sobre as baselines ou sobre qualquer tipo de artefato. Entre os relatrios apresentados destacam-se os citados no Quadro 8, de acordo com Cunha et al.(2004). As revises so fundamentais nesta atividade, pois apresentam o desempenho dos artefatos referente ao seu objetivo proposto. Assim, devem ser empregadas as revises tcnicas e as auditorias. A primeira prope a melhoria do artefato que sofreu modificao, por meio de avaliaes de efeitos colaterais e omisses. J nas auditorias, a reviso formal efetuada com o emprego da avaliao de algumas caractersticas se a modificao foi feita em conformidade com o que foi proposto, se necessitar de adaptao dos outros artefatos, se o processo e os padres foram atendidos e se as especificaes para o registro das modificaes foram adequadamente preenchidas e atualizadas (PRESSMAN, 2006).

Relatrios Relatrio de artefatos Relatrio de mudanas Relatrio de baseline Relatrio de projeto

Descrio Descreve a respectiva verso e as especificaes do artefato Estabelece as solicitaes e a idealizao das mudanas sugeridas Descreve todos os artefatos que compem a baseline Especifica qual baseline constitui uma determinada verso

Quadro 8 - Relatrios de gerncia de configurao (CUNHA et al., 2004)

3.3.3 Problemtica de GC na reengenharia baseada em framework

A GC se torna essencial tanto no desenvolvimento quanto na reengenharia de software incremental, principalmente quando essa ltima emprega o uso de framework como apoio computacional para a gerao do sistema alvo. Ressalta-se que, se um determinado sistema alvo desenvolvido com o emprego de um framework, o mesmo se torna dependente dessa tecnologia de reso, pois a arquitetura do sistema passa a englobar o prprio framework (ARIMOTO et al., 2007). Assim, as mudanas no framework podem prejudicar o comportamento do sistema alvo na prxima instanciao do framework, caso alguma funcionalidade j existente no framework tenha sido modificada (CAGNIN, 2005a).

47

Dentro desse contexto, como podem haver evolues e modificaes tanto no framework quanto no sistema alvo, gerando diferentes verses desses softwares, deve-se ter um controle de verses que gerencie a verso do framework que est relacionada com cada verso do sistema. Devido a isso, preciso tomar alguns cuidados na evoluo do framework com o emprego da anlise de impacto, verificando quais artefatos sero afetados por tal mudana, bem como o grau de prioridade da solicitao de mudana e o tempo que ser gasto. Na Figura 5 encontra-se um exemplo de vrias verses de um determinado framework e as verses dos sistemas gerados a partir dele. Com isso, possvel observar em quais verses dos sistemas as mudanas em determinada verso do framework podem causar impacto. A primeira verso V 1.1 do framework gerou as verses V 4.0 e V 4.1 do sistema. A prxima verso do framework (V 1.2) gerou a verso V 4.2 do sistema, assim, pode-se observar que, apesar do sistema ter sido gerado novamente em outra verso do framework, o seu comportamento no foi prejudicado, pois as classes do framework utilizadas apresentavam o mesmo comportamento que a verso anterior do framework.

Sistema V 4.0 Sistema V 1.0 Sistema V 1.1

Sistema V 4.1

Framework V 1.1 Framework V 1.0 Sistema V 4.2 Sistema V 5.0 Sistema V 6.0

Legenda: criado por evoludo para

Framework V 1.2 Figura 5 Grafo de controle de verso de framework e dos sistemas gerados (adaptado de CAGNIN, 2005a)

3.3.4 Trabalho correlato

Dentre os trabalhos apresentados na literatura que se preocupam com a GC, destaca-se o de Murta e Werner (2007) uma vez que trata de GC no contexto de componentes, que como

48

frameworks, tambm uma tcnica que possibilita o reso de software e necessita de precaues durante o controle de verses. A abordagem de GC no desenvolvimento baseado em componentes (Murta e Werner, 2007) possui o diferencial em delegar a responsabilidade de implementao das solicitaes de mudanas. A preocupao dessa abordagem est em evitar a introduo de defeitos durante mudanas dos componentes que podem afetar todos os sistemas que reutilizam os componentes modificados (MURTA; WERNER, 2007). Para permitir isso, a abordagem conta com uma ferramenta especfica denominada Odyssey-CCS, que controla as modificaes e coleta as informaes dos colaboradores (pessoas que participam do controle de modificao), proporcionando uma comunicao e coordenao do trabalho e mantendo informaes sobre as modificaes realizadas nos componentes (LOPES et al., 2005). Por meio da ferramenta Odyssey-CCS so realizadas as seguintes atividades: a) modelagem de um processo de controle de mudanas para cada software produzido na empresa, efetuada pelo gerente de configurao; b) definio de quais informaes necessitam ser coletadas durante o controle de mudanas, efetuado pelo gerente de configurao, para que os colaboradores realizem as atividades e tomem as decises necessrias; c) atribuio de responsabilidades, efetuada pelo gerente de configurao, designando os papis modelados no processo para os colaboradores, identificao do momento de realizar a coleta da informao, por meio de uma associao de formulrios a produtos modelados no processo; d) verificao, efetuada pelos colaboradores, de quais atividades e decises encontram-se pendentes para execuo; e) execuo de uma determinada atividade ou deciso, que estava pendente, pelo colaborador, a fim de que outras pessoas que desempenhem a mesma funo tenham conhecimento deste fato; f) aps execuo das atividades e decises, os colaboradores devem fornecer informaes pertinentes para que aja compreenso sobre tal procedimento futuramente (LOPES et al., 2005).

3.4 Ferramentas de apoio GC

As ferramentas devem apoiar as atividades de GC com a finalidade de armazenar, gerenciar, controlar e manter a integridade dos artefatos. O apoio de ferramentas se tornou essencial pela rapidez em executar o controle das verses, pela reduo do custo e o aumento do desempenho

49

das equipes de desenvolvimento. Alm disso, facilita o acesso s informaes necessrias sobre as verses e garante a integridade dos artefatos por meio do controle de solicitaes de mudanas. Deve-se ressaltar a variedade de ferramentas open-source que podem atender totalmente ou parcialmente s necessidades de GC, dentre elas destacam-se: a RCS (TICHY, 1997), a CVS (XIMBIOT, 2005), a Arch (KRAUSE, 2002) e a Subversion (COLLINS-SUSSMAN et al., 2006), que sero apresentadas a seguir.

3.4.1 Revision Control System (RCS)

A ferramenta RCS foi umas das pioneiras no controle de verses. O seu desenvolvimento foi realizado por meio de comandos Unix e muitas de suas funcionalidades vm sendo empregadas para apoiar o desenvolvimento de outras ferramentas de controle de verso, como por exemplo, a CVS e a Subversion (TICHY, 1997; ASKLUND; MAGNUSSON, 2001 apud QUADROS, 2005). Esta ferramenta est diretamente relacionada s tarefas de controle de verso, as quais so feitas por branches (ramos). Define-se um ramo para cada verso modificada, por exemplo, caso ocorra uma modificao de determinado artefato por dois desenvolvedores, so criadas duas verses distintas com a mesma raiz ou arquivo inicial. O merge agrupa as verses respeitando a estrutura, apresentando na raiz a verso original e, em seguida, as derivadas desta (TICHY, 1997; SILVA, 2002). O armazenamento das verses dos documentos com extenso .txt realizado em formato de rvore, sendo que o primeiro arquivo se encontra na raiz e os demais que se apresentarem na seqncia so considerados as modificaes ou evolues deste arquivo inicial (TICHY, 1997). A RCS estabelece a integridade dos artefatos, tanto no armazenamento quanto na permisso da modificao. No armazenamento feita uma cpia da verso que ser modificada na rea de trabalho do desenvolvedor com o uso do comando check-out. Depois deste procedimento, a verso do artefato bloqueada no repositrio para que no ocorram vrias mudanas no artefato ao mesmo tempo. Aps a modificao e aprovao do artefato, executado o comando check-in. Neste instante, a ferramenta identifica o arquivo modificado e define uma nova verso que pode ser disponibilizada aos demais desenvolvedores, mantendo apenas as linhas que possuem caracteres diferentes da verso anterior deste artefato. Com isto, emprega-se o conceito de delta (TICHY, 1997; SILVA, 2002).

50

As revises so realizadas e armazenadas em rvore no repositrio, como ocorre com as verses. Os documentos criados nas revises so: a reviso atual e as revises das verses anteriores (TICHY, 1997). O histrico das mudanas gerado automaticamente com apoio dos critrios, os quais podem estar relacionados data de criao, ao nome do desenvolvedor e ao nome de uma determinada verso ou at mesmo de uma determinada caracterstica da verso (TICHY, 1997; SILVA, 2002). As permisses so tratadas de acordo com o login de acesso. Os usurios annimos tm acesso sem restrio. Os usurios com restries devem informar a senha de acesso aos artefatos contidos no repositrio.

3.4.2 Concurrent Versions System (CVS)

A ferramenta CVS se aplica em diversas plataformas e tem como objetivo controlar as verses adequadamente (XIMBIOT, 2005). Segundo Silva (2002), a ferramenta CVS pode ser considerada uma interface entre a ferramenta RCS e o usurio, pois contm as mesmas caractersticas apresentadas por essa ferramenta (ramos e merges), mas com algumas funcionalidades a mais, como a programao paralela simultnea de diversos programadores em uma mesma verso do artefato e o tratamento das permisses com restries de login igualmente apresentado na RCS. A disposio dos artefatos encontra-se hierarquicamente dentro de um nico repositrio, com o emprego do comando import. Pode-se criar um ramo no tronco principal, em que armazenado o artefato original, assim qualquer alterao feita neste artefato ir prover uma nova verso. Nesse caso realizado um merge (agrupamento dos artefatos) e, em seguida, adicionado um novo lugar na rvore, partindo da verso original. A criao de lugares na rvore deve dispor de um nome simblico que est associado ao diretrio e aos arquivos dentro do repositrio (SILVA, 2002; XIMBIOT, 2005). A CVS cumpre as principais funes de controle de verses, seja no armazenamento, seja nas modificaes dos artefatos contidos no seu repositrio. A identificao feita por um determinado nmero chamado reviso, que contm a modificao, o seu autor, a data, o tamanho,

51

entre outros dados, de acordo com o critrio da empresa (BRUCKER et al., 2002; CAETANO, 2004). O comando check-out apresenta as mesmas caractersticas da ferramenta RCS, isto , cria uma cpia do artefato na rea de trabalho do desenvolvedor. Em seguida, emprega-se o comando commit, correspondente ao comando check-in do RCS. O comando commit verifica e armazena o artefato no repositrio, registrando sua evoluo (SILVA, 2002). A integridade dos artefatos garantida com o controle dos acessos e das modificaes, que contm os mesmos procedimentos apresentados pela RCS (CAETANO, 2004). Deve-se ressaltar que o armazenamento das verses apresenta economia de espao, pois armazena apenas as diferenas apresentas em cada verso (SILVA, 2002), como ocorre na RCS.

3.4.3 GNU Arch

A ferramenta Arch tem a finalidade de controlar as verses que ainda esto em desenvolvimento (KRAUSE, 2002). Esta ferramenta possui similaridade com a ferramenta CVS, levando em considerao a organizao e o controle das verses, encontra-se disposta em rvore conforme apresentado nas ferramentas comentadas anteriormente, com algumas vantagens, como: a) as permisses so tratadas tanto com restries quanto com perfis (que no eram tratadas nas demais ferramentas); b) o registro das mudanas nos artefatos, que podem ser do tipo de reorganizao e renomeao de um determinado artefato; c) a associao de um conjunto de mudanas com uma descrio exata do que foi alterado; e d) a distribuio dos repositrios favorece o merge, como ocorre com a ferramenta RCS. Um ponto fraco encontrado em Arch que seu emprego no se estende para todas as plataformas, apenas Linux (TOSUN, 2004).

3.4.4 Subversion

A ferramenta Subversion objetiva o controle de verso dos sistemas. Como foi constatado na maioria das ferramentas supracitadas, esta tambm emprega as funcionalidades dos comandos e de armazenamento (commit e check-out). Essas similaridades facilitam a migrao para esta

52

ferramenta com pouco esforo. A Subversion pode se adaptar a todas as plataformas e as permisses podem ser com e sem restries, sendo que no primeiro caso utiliza-se perfil (COLLINSSUSSMAN et al., 2006). A diferena encontrada nesta ferramenta est no seu armazenamento, pois no considera apenas o artefato, mas tambm os diretrios, cpias e renomeaes das verses (COLLINSSUSSMAN et al., 2006). Como ocorre com as demais ferramentas, a Subversion armazena apenas as diferenas entre as verses.

3.4.5 Comparao das ferramentas de GC

Para analisar qual ferramenta se adequa melhor s necessidades previstas neste trabalho, que visa ao controle das verses dos artefatos produzidos durante a reengenharia baseada em framework, so apresentadas no Quadro 9 algumas das principais caractersticas encontradas nessas ferramentas.

Ferramentas RCS Caractersticas Mudana de localizao nos artefatos e nos diretrios Migrao para outras ferramentas Revises No suporta essa mudana gerando quebra de histrico No d suporte Ocorre a quebra do histrico em duas partes Ocorre a renomeao das verses Ocorre a renomeao das verses CVS Arch Subversion

No d suporte

Documentao

Caractersticas em comum

Plataforma

Armazena apenas a ltima na ntegra e as antigas apenas as diferenas Pouca documentao, restringindo a tutoriais existentes Possui cdigo-fonte e licena livre Comandos similares aos de outras ferramentas Unix

Armazena apenas a ltima na ntegra e as antigas apenas as diferenas Vrias documentaes dispostas em livros e tutorias em vrias lnguas Possui cdigo-fonte e licena livre Utiliza-se de alguns comandos aplicados na ferramenta RCS e a criao do commit Windows, Unix E Linux

Aceita a importao dos arquivos gerados pela ferramenta CVS Realiza-se com restries aplicadas em perfis Pouca documentao, restringindo a tutoriais existentes Possuem cdigofonte e licena livre Utiliza-se dos comandos existentes na CVS Linux

Aceita a importao dos arquivos gerados pela ferramenta CVS Realiza-se com restries aplicadas em perfis

Pouca documentao, restringindo a tutoriais existentes Possui cdigo-fonte e licena livre Utiliza-se dos comandos existentes na CVS Windows, Unix E Linux

Quadro 9 - Comparao das ferramentas de GC

53

Devido as caractersticas encontradas nas ferramentas de controle de verso estudadas neste trabalho, foi selecionada a Subversion principalmente devido ao tratamento dado por ela com relao ao repositrio, isto , possibilita a renomeao e a importao de arquivos de outras ferramentas de controle de verso. Essa caracterstica ainda no foi implantada na CVS.

3.5 Consideraes Finais

Neste captulo foram apresentadas as atividades adotadas pela GC a fim de garantir a qualidade no desenvolvimento do software. Assim, foram descritas resumidamente a definio de qualidade de software, dando maior nfase Gerncia de Configurao, descrevendo os passos para administrar e controlar os artefatos, as verses e as releases. A Gerncia de Configurao deve ser considerada, principalmente no desenvolvimento e na reengenharia incremental, uma vez que verses do sistema (novo ou alvo, respectivamente) so produzidas a cada iterao do processo. No contexto de reengenharia baseada em framework essa gerncia deve ser aplicada com cautela, pois necessrio controlar tanto as verses geradas do sistema alvo quanto as verses do framework, bem como a dependncia entre ambas uma vez que mudanas efetuadas no framework podem alterar o comportamento dos sistemas gerados, fazendo com que os mesmos forneam comportamento indesejvel. Para apoiar mais efetivamente o controle de verso foram apresentadas algumas ferramentas open-source, bem como uma comparao das mesmas a fim de auxiliar na escolha daquela que melhor atenda s necessidades do projeto, que foi a Subversion. No prximo captulo so apresentadas as normas e os modelos de maturidade estudados, do ponto de vista de GC, para apoiar a definio do modelo de referncia proposto neste trabalho.

NORMAS E MODELOS DE QUALIDADE DE SOFTWARE

4.1 Consideraes Iniciais

So abordados neste captulo as normas e os modelos de qualidade, pois proporcionam um alicerce para a identificao das atividades de GC do modelo de referncia de GC proposto para o PARFAIT. Na Seo 4.2 apresenta-se, especificamente, como a atividade de GC tratada no CMMI; na Seo 4.3 aborda-se a GC na ISO/IEC 12207; na Seo 4.4 ilustra-se a GC segundo a ISO/IEC 15504; na Seo 4.5 expe-se uma descrio da norma ISO/IEC 10007, que tem em seu foco a atividade de GC; na Seo 4.6 aborda-se como o modelo MR-MPS trata a atividade de GC; e na Seo 4.7 apresenta-se o tratamento de GC pelo modelo PMBOK. Na Seo 4.8 faz-se uma comparao entre as normas e os modelos estudados neste captulo e, na Seo 4.9, encontram-se as consideraes finais deste captulo.

4.2 CMMI sob a perspectiva da Gerncia de Configurao

O Capability Maturity Model Integration (CMMI) um modelo que focaliza o desenvolvimento integrado do produto e do processo. Esse modelo se originou do aperfeioamento do Capability Maturity Model (CMM) (PAULK, 1993; HUMPHREY et al., 1991) que o modelo de avaliao da maturidade dos processos de software, desenvolvido por pesquisadores do Software Engineering Institute (SEI)7 da Universidade Carnegie Mellon. A GC apresentada no CMMI, especificamente no nvel 2 de maturidade, como prtica genrica. Os controles gerenciais e tcnicos da GC so apresentados rigorosamente na seleo dos itens de configurao, que contm a baseline e sua integridade, no controle das mudanas dos artefatos, no estabelecimento das diretrizes para o desenvolvimento do produto com gerenciamento,

http://www.sei.cmu.edu/

55

na confiabilidade e nas atividades de configurao para o desenvolvedor e para o usurio (SEI, 2001). No CMMI as prticas especficas aplicadas na GC so: identificar os itens de configurao e transform-los em baselines, controlar as modificaes dos itens de configurao e estabelecer a integridade das baselines (SEI 2001). As metas genricas (GG- Generic Goal) e especficas (SG Specific Goal), bem como as prticas genricas (GP - Generic Practire) e especficas (SP - Specific Practire) encontram-se descritas no Quadro 10.

Metas SG 1 estabelecer baselines

Prticas SP 1.1 identificar itens de configuraes SP 1.2 estabelecer um sistema de gerenciamento de configuraes SP 1.3 criar ou liberar baselines

SG 2 rastrear e controlar alteraes

SP 2.1 rastrear solicitaes de mudanas SP 2.2 controlar itens de configuraes

SG 3 estabelecer as integridades

SP 3.1 estabelecer os registros de gerenciamento de configuraes SP 3.2 executar auditorias de configuraes

GG 1 executar os objetivos especficos GG 2 instituir um processo controlado

GP 1.1 executar as prticas bsicas GP 2.1 estabelecer uma poltica organizacional GP 2.2 planejar o processo GP 2.3 fornecer recursos GP 2.4 atribuir responsabilidades GP 2.5 treinar as pessoas GP 2.6 gerenciar configuraes GP 2.7 identificar e envolver os stakeholders relevantes GP 2.8 monitorar e controlar o processo GP 2.9 avaliar objetivamente a aderncia GP 2.10 revisar o status com o nvel mais alto de gerncia

GG 3 instituir um processo definido

GP 3.1 estabelecer um processo definido GP 3.2 coletar informaes de melhorias

GG 4 instituir um processo quantitativamente controlado GG 5 instituir um processo otimizado

GG 4.1 controlar com tcnicas estatsticas

GG 5.1 empregar a melhoria contnua

Quadro 10 - Metas e prticas da rea de processo GC do CMMI (SEI, 2001)

56

Para melhor entendimento do Quadro 10, segue uma breve explicao das metas apresentadas. Ao estabelecer as Metas Especficas (SG) define-se o status de aprovao da mudana, mantm-se os artefatos e as verses corretas com o auxlio de auditorias. Em SG 1 (Meta Especfica 1) pode-se estabelecer, criar e disponibilizar as baselines somente aps a identificao dos itens de configurao, isto , todos os artefatos necessrios para a criao e para a especificao do software que compem a baseline devem ser identificados primeiramente. Dentre os itens de configurao destacam-se: o projeto, a descrio do processo de GC, os planos, os procedimentos de teste, as ferramentas de apoio, o cdigo fonte especificado tanto pela linguagem quanto pela extenso do arquivo. Assim, necessrio gerenciar o armazenamento, a solicitao, a recuperao e a alterao dos artefatos, sem esquecer de fornecer os relatrios desse gerenciamento, o backup e, quando houver necessidade, as revises de GC . A SG 2 (Meta Especfica 2) rastreia as solicitaes e o controle das alteraes nos itens de configurao, possibilitando o registro tanto dos novos quanto dos velhos artefatos, e analisa o impacto que pode ser gerado com a mudana. Como pode ser o caso de uma alterao ocorrida em um determinado artefato, que pode afetar outros artefatos, resultando em custo monetrio e investimento alm do esperado. A SG 3 (Meta Especfica 3) especifica as diferenas de cada baseline alterada, sua respectiva verso e apresenta um histrico de revises: dos itens de configurao, de solicitaes de mudanas, do status e das diferenas entre as verses e das baselines. Na GG 1 (Meta Genrica 1) so produzidos os artefatos e os servios previstos durante a aplicao do processo. Na GG 2 (Meta Genrica 2) estabelecida e mantida a poltica organizacional que planeja, executa e controla a GC. No controle das alteraes das baselines e da sua integridade executa-se o plano do processo de GC, fornecem-se os recursos necessrios para desenvolver o produto e prover os servios, como por exemplo, as ferramentas para apoiar a administrao das mudanas ocorridas nos artefatos, e delegam-se a responsabilidade e a autoridade para executar o processo de GC. Ainda preciso: treinar as pessoas tanto na execuo quanto no suporte do processo de GC em cada mudana ocorrida, nas responsabilidades, nos padres, nos procedimentos, nos mtodos e no repositrio das baselines; gerenciar as configuraes com as listas de acesso, com os relatrios de status de mudanas e com as baselines arquivadas no repositrio; e identificar e comprometer os interessados em analisar o impacto das mudanas e em estabelecer as baselines ao rever os resultados das auditorias de GC.

57

A GG2 tambm realiza as seguintes atividades: controla a quantidade de mudanas e de auditorias dos itens de configurao, e se no contm erros; avalia o objetivo referente s ligaes do processo de GC com padres e procedimentos que estabelecem e mantm os baselines; rastreia e controla as mudanas; revisa as atividades, os status e os resultados apresentados no processo de GC. A GG 3 (Meta Genrica 3) estabelece oficialmente um processo definido de GC e coleta as informaes sobre os resultados, as medidas, o planejamento e a execuo do processo para melhorias futuras. Em GG 4 (Meta Genrica 4) o processo controlado com o emprego de tcnicas estatsticas ou quantitativas, o artefato e o desempenho do processo so mensurados e controlados em todo o projeto. J em GG 5 (Meta Genrica 5) emprega-se a melhoria contnua do desempenho do processo com iniciativas incrementais e inovadoras.

4.3 NBR ISO/IEC 12207 sob a perspectiva da Gerncia de Configurao

A norma ISO/IEC 12207 (Information technology - Software Life Cycle Process) foi desenvolvida em 1995, pela International Organization for Standardization (ISO) e pelo International Electrotechnical Commission (IEC), sofreu alterao em 1998 e se encontra atualmente no Brasil, sob o cuidado da Associao Brasileira de Normas Tcnicas (ABNT), com a denominao NBR ISO/IEC 12207 (Tecnologia da Informao - Processos de Ciclo de Vida do Software). A norma NBR ISO/IEC 12207 (1998) tem como principal ponto positivo uma estrutura comum de processos de ciclo de vida, que auxiliam as empresas nos negcios relacionados aos produtos de software, tornando eficaz o desenvolvimento e a manuteno do software. Esta norma se adapta s necessidades da empresa desenvolvedora e se destaca por ser a pioneira em apresentar os processos e as tarefas que podem ser empregadas durante o ciclo de vida do software para garantir a melhoria do mesmo. A GC vista pela NBR ISO/IEC 12207 e contm detalhes com a descrio das atividades que apiam a empresa ao desenvolver essa prtica.

58

As atividades exclusivas de GC esto relacionadas implementao do processo, identificao da configurao, ao controle da configurao, ao relato da situao da configurao, avaliao da configurao e gerncia de liberao e distribuio, como se apresenta a seguir (NBR ISO/IEC 12207, 1998). A atividade implementao do processo cria um plano de GC que descreve as atividades de GC, os procedimentos, o cronograma e o responsvel por executar estas atividades. A atividade identificao da configurao consiste em identificar e controlar os artefatos e as suas verses. Todos os itens de configurao devem apresentar a documentao que estabelece a baseline, as referncias de verso e quaisquer detalhes que ajudem na sua identificao. A atividade controle da configurao executa as tarefas de: identificar e registrar os pedidos de alterao; avaliar as alteraes; aprovar ou no o pedido; e implementar, verificar e liberar os itens de software que foram alterados. Sem se esquecer dos registros de auditoria que controlam os acessos aos artefatos gerando confiana, segurana e proteo aos mesmos. Com o emprego da atividade relato da situao da configurao so descritos os relatrios e os registros da situao do histrico de todos os artefatos controlados e as baselines. Este relatrio deve conter o nmero de alteraes, as ltimas verses, os identificadores, a quantidade de liberaes e as comparaes empregadas nos artefatos. Na avaliao da configurao ocorre a determinao e a garantia de qualidade dos artefatos, referente s funcionalidades dos requisitos. Na gerncia de liberao e distribuio disponibilizam-se os produtos e a documentao que so gerenciados formalmente com a utilizao de cpias de segurana do cdigo e da documentao. A proteo dos artefatos outro fator importante na manipulao, no armazenamento, no empacotamento e na distribuio, segundo a poltica da empresa.

4.4 ISO/IEC 15504 sob a perspectiva da Gerncia de Configurao

A norma ISO/IEC 15504, conhecida tambm como SPICE, foi criada em 1999 com o apoio do grupo de trabalho dedicado ao campo de Tecnologia da Informao e Engenharia de

59

Software8(ISO/IEC TR 15504, 1999). Esta norma composta por nove partes cujo objetivo elaborar um guia de orientao que examine e avalie o software, promovendo uma melhoria contnua dos processos. A GC encontra-se na quinta parte da norma, com a denominao de suporte. Essa parte contm processos dentre os quais se destacam aqueles que tratam de GC: Criar uma estratgia de GC para desenvolver todas as atividades, Estabelecer o emprego de padres, de procedimentos e de ferramentas, Identificar os artefatos que foram armazenados em repositrios, Controlar as modificaes com o formulrio de solicitao de mudanas e de autorizao, Gerenciar o histrico do artefato com um nvel de detalhes aceitvel, caso seja necessrio recuperar e garantir a integridade do artefato, Administrar a liberao de uma determinada verso somente aps reviso e autorizao.

4.5 ISO/IEC 10007 - Sistemas de Gesto da Qualidade Diretrizes para a Gesto de Configurao

A norma ISO/IEC 10007 (Sistemas de Gesto da Qualidade Diretrizes para a Gesto de Configurao) foi elaborada pelo Comit Brasileiro da Qualidade (ABNT/CB-25) e pela Comisso de Estudo de Sistema de Gesto de Qualidade, e se encontra na segunda edio. Esta norma tem como objetivo fornecer um guia com diretrizes para a atividade de GC, cujo enfoque est voltado principalmente para o ciclo de vida do produto, atendendo aos requisitos de identificao e de rastreabilidade dos artefatos (ISO/IEC 10007, 2005). Assim, a ISO/IEC 10007 empregada para estimular o uso de GC no planejamento, na identificao, no controle das alteraes, na situao de configurao e nas auditorias (ISO/IEC

WG10 - composto por 13 pases: Austrlia, Brasil, Canad, Frana, Alemanha, Israel, Itlia, Japo, frica do Sul, Espanha, Sucia, Inglaterra e Estados Unidos.

60

10007, 2005). Salienta-se que esta norma utiliza como apoio a ISO/IEC 9001 (2000) e a ISO/IEC 9004 (2000). As responsabilidades apresentadas nesta norma consistem em delegar: as

responsabilidades e as autoridades tanto na implementao quanto na verificao do processo de GC; a autoridade pela disposio, ou seja, verificar se as alteraes propostas so necessrias e aceitveis, se essas possuem uma documentao adequada e se as mesmas so planejadas satisfatoriamente. O processo de GC, por sua vez, pode ser dividido em seis partes, iniciando-se pelas generalidades e finalizando em auditoria de configurao, como se apresenta a seguir (ISO/IEC 10007, 2005): 1 Parte: denominada de generalidade que enfoca os requisitos do cliente do produto final e todo contexto de execuo, detalhando o plano de GC por completo com a descrio dos procedimentos especficos e a extenso de sua aplicao durante todo o ciclo de vida; 2 Parte: se encontra o planejamento que coordena todas as atividades de gesto de configurao, com uma documentao devidamente aprovada, que descreve os procedimentos relevantes, as responsabilidades e os profissionais incumbidos na execuo de GC; 3 Parte: apresenta a identificao de configurao que seleciona os artefatos necessrios com o emprego dos critrios de seleo relacionados aos requisitos, segurana e ao risco, tecnologia do projeto, interface com os artefatos e ao suporte; 4 Parte: engloba o controle de alteraes que possibilita a solicitao das alteraes com a verificao do seu impacto, a anlise de sua aprovao e, em seguida, o seu gerenciamento. A documentao deve ter um nvel de detalhe adequado, isto , com numeraes, com uma breve descrio da justificativa e registro da alterao e com reviso, facilitando a rastreabilidade dos artefatos; 5 Parte: emprega a contabilizao da situao da configurao que impulsiona o registro das informaes importantes do artefato, por exemplo, o nmero de identificao da verso, a data efetiva da liberao da verso, a situao da reviso, o histrico do artefato, enfim melhora o rastreamento, mantendo a integridade do artefato;

61

6 Parte: contm a auditoria de configurao que deve ser aplicada nas revises para favorecer a verificao dos requisitos, se estes foram atingidos nos artefatos.

4.6 MR-MPS sob a perspectiva da Gerncia de Configurao

O projeto Melhoria do Processo de Software Brasileiro (MPS.BR) se encontra em desenvolvimento desde 2003, em conjunto com a Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), a Sociedade Ncleo de Apoio Produo e Exportao de Software do Rio de Janeiro (RIOSOFT), o Programa de Engenharia de Sistemas e o Departamento de Computao da Universidade Federal do Rio de Janeiro (COPPE/UFRJ), o Centro de Estudos e Sistemas Avanados de Recife (CESAR), o Centro de Pesquisa Renato Archer (CenPRA) e a Companhia de Informtica do Paran (CELEPAR) (SOFTEX, 2005), e tem por objetivo possibilitar que empresas de software de pequeno e mdio porte obtenham certificao baseada em normas internacionais a um custo acessvel. O MPS.BR um projeto que criou o modelo de referncia MR-MPS que visa a maturidade e capacidade de processo para a avaliao e melhoria da qualidade e produtividade de produtos de software e servios correlatos, adequando-o realidade brasileira tanto relacionada ao custo quanto ao desenvolvimento, com o auxlio de padres internacionais, sendo inspirado no modelo CMMI (SEI, 2001) e nas normas ISO/IEC 12207 (1998) e ISO/IEC 15504 (1999). Os 14 objetivos de GC apresentados no modelo MR-MPS (SOFTEX, 2005) so os seguintes: 1. Selecionar os artefatos com o emprego de critrios documentados. 2. Delegar responsabilidades para o desenvolvimento de cada artefato e baseline. 3. Identificar, armazenar, testar, revisar, alterar, definir, manter os artefatos e submetlos baseline. 4. Instituir uma poltica de GC que controle os diferentes nveis, que possua um armazenamento dos artefatos para posteriormente serem recuperados, bem como uma solicitao de mudanas. 5. Preservar todos os artefatos de GC. 6. Autorizar a criao ou a liberao das baselines pela GC.

62

7. Controlar as modificaes e as liberaes dos artefatos. 8. Disponibilizar as modificaes e as liberaes dos artefatos. 9. Registrar, relatar e analisar o impacto das solicitaes de mudanas que os artefatos podem sofrer e sua situao. 10.Assegurar com as revises, que as mudanas ocorridas nas baselines no sofram efeitos inesperados. 11.Adicionar os artefatos no repositrio, j aprovados e devidamente controlados; 12.Assegurar a consistncia e a completeza dos artefatos. 13.Controlar o armazenamento, o manuseio e a liberao dos artefatos. 14.Estabelecer e manter a integridade das baselines, com os registros e a auditoria de GC.

4.7 PMBOK sob a perspectiva da Gerncia de Configurao

O Project Management Body of Knowledge (PMBOK) um conjunto de conhecimento em Gerenciamento de Projetos, criado inicialmente em 1969 pelo Project Management Institute (PMI), no Estado da Pensilvnia, EUA. A primeira publicao do boletim Project Management Quarterly (PMQ) ocorreu nos anos 70, contudo deve-se ressaltar que no final desta dcada o PMBOK j possua 2000 afiliados em todo o mundo (PMI, 2006). O principal objetivo do PMBOK fornecer uma viso geral dos conhecimentos de Gerncia de Projeto. A GC se encontra na rea de conhecimento de Gerenciamento de Integrao de Projeto, que possui processos imprescindveis para a coordenao de todos os elementos que constituem o projeto e composta por: gerenciamento das mudanas, revises e aprovaes das mudanas, perfil do mantenedor para a autorizao e mtodo para validar as mudanas (LIMA, 2004; PMI, 2004). O controle das atividades de mudanas desempenhadas em GC documentado formalmente com superviso tanto tcnica quanto administrativa. Essas atividades podem ser divididas em controlar, verificar, registrar e relatar as mudanas ocorridas na elaborao do artefato e de suas caractersticas. Ressalta-se que o controle de mudanas possui uma preocupao na aprovao das mudanas para manter o artefato ntegro (PMI, 2004).

63

O processo de controle integrado de mudana essencial pela dificuldade de executar na ntegra o plano do projeto. Suas atividades so: indicar se uma determinada mudana ocorreu ou precisa ocorrer; controlar as aprovaes das mudanas que sero implementadas e identificar todos os fatores que dificultaram esse controle; revisar e aprovar as mudanas com o histrico das mudanas; gerenciar as baselines, mantendo a integridade e a documentao quando solicitada; revisar e aprovar as aes corretivas e preventivas; gerenciar as atualizaes de custo, do cronograma, do oramento e dos riscos das mudanas; documentar o impacto das mudanas; validar as mudanas; e garantir a qualidade do projeto com base nos relatrios de qualidade. Assim, o PMBOK oferece um processo eficaz, eficiente e padronizado para gerenciar as mudanas no projeto, que facilita a identificao dos artefatos. Entre seus objetivos destacam-se o processo para identificao e solicitao das mudanas nas baselines, a melhoria contnua e a validao das mudanas do projeto, conforme o seu impacto, e o registro das mudanas sofridas por meio de histricos.

4.8 Comparao das Normas e Modelos de Maturidade Estudados

Pode ser constatado no estudo das normas e modelos de maturidade, efetuado neste trabalho, que a maioria deles considera como base a norma ISO/IEC 12207 ou o modelo de maturidade CMM (SOFTEX, 2005; SEI, 2001). No Quadro 11 encontra-se uma breve comparao entre normas/modelos que aplicam GC, apresentando o objetivo, a abordagem utilizada, se possuem flexibilidade em algum aspecto, se foram baseados em outras normas, quais caractersticas gerais e especficas de GC possuem e a locao de GC. Relata-se que os dois ltimos itens apresentados so de relevncia para este trabalho. Destacam-se no Quadro 11 as caractersticas de GC, isto , como a GC tratada e tambm a sua devida localizao da GC nas normas e nos modelos de maturidade abordados no estudo realizado. No Quadro 12 trata da identificao de cada atividade de GC que produz algum artefato relevante nas normas e nos modelos de maturidade estudados, destaca-se neste quadro a atividade

64

de GC Gerenciar as mudanas nas verses e releases, pois de suma importncia GC e deve ser realizada com cautela.

ISO/IEC 12207

ISO/IEC 15504

ISO/IEC 10007

CMMI

MR-MPS

PMBOK

Apoiar todo o ciclo de vida do artefato, apresentando diretrizes para prover a melhoria.

Avaliar os processos e determinar a capacitao, promovendo a melhoria contnua.

Oferecer diretriz para todas as atividades de GC.

Empregar o desenvolvimento integrado ao produto e ao processo.

Avaliar e melhorar a qualidade na produtividade dos servios empregados no software. Dispe de nveis de maturidade para avaliar os processos e as capacidades correspondentes a cada nvel.

Fornecer uma viso geral dos conhecimentos de gerncia de projeto. Oferece nove reas de conhecimento, descrevendo o emprego das atividades para aplicar a GC. Pode apoiar-se em outras normas e adaptar-se as necessidades da empresa.

Abordagem

Objetivo

Oferece apoio ao desenvolvimento e manuteno do software.

Dispe de nveis de capacitao para avaliar os processos.

Oferece apoio na execuo das atividades de GC.

Oferece nveis de maturidade para a avaliao dos processos.

Pode-se adaptar conforme a necessidade da empresa.

Podem-se definir quais processos e prticas so empregados conforme a necessidade da empresa.

Esta norma especfica para atividade de GC.

Os nveis so a base do modelo, porm no podem ser alterados e sua representao feita por estgio e contnua. Norma internacional, possui uma aplicao flexvel, por se apresentar em nveis.

Caractersticas gerais

Flexibilidade

Dispe de nveis voltados realidade das empresas brasileiras.

Norma internacional, possui detalhes de como aplic-la.

Norma internacional, estabelece diretriz para melhoria contnua.

Norma brasileira, descreve todos os passos das atividades de GC.

Modelo de melhoria de processo do software brasileiro.

Modelo de melhoria de gerenciamento de projeto internacional.

Caractersticas de GC

No apresenta em detalhes como executar a GC, apenas cita as atividades.

Apresenta dificuldade em se aplicar a GC, pois apenas cita as atividades.

No apresenta modelos dos formulrios e documentao necessrios GC.

Apresenta apenas o que deve ser feito e no os detalhes de como alcanar a GC.

Apresenta apenas o que deve ser feito e no os detalhes de como alcanar a GC.

No trata com detalhes a GC e voltada gerncia de projeto.

Possuem participao ou indicao de outra norma

Pioneira

ISO/IEC 12207

ISO/IEC 9001 E ISO/IEC 9004

CMM

ISO/IEC 12207, ISO/IEC 15504 E CMMI

SECM, SW-CMM, IPD-CMM

Processo de apoio

5 Parte

Nvel 2

Nvel F

rea de gerenciamento de integrao de projeto

Localizao da GC

Quadro 11 - Comparao normas/modelos estudados (adaptado de TSUKUMO et al., 1997)

65

Normas e modelos de Maturidade Atividades de GC Identificar os itens de configurao

ISO/IEC 12207

ISO/IEC 15504

ISO/IEC 10007

CMMI

MR-MPS

PMBOK

Gerenciar as mudanas nas verses e releases

Implantao de GC

Atividade de identificao da configurao Atividade de controle de mudana e Atividade de relato da situao da configurao. Atividade de gerncia de liberao e distribuio

Processo de identificar os artefatos

Processo de controle de mudana

Parte 3 identificao de configurao Parte 4 controle de alteraes Parte 5 contabilizao da situao da configurao Parte 6 auditoria de configurao

Meta Especfica 1

Objetivo 1, 2 e 3

Atividade de identificar e controlar Atividade de revisar, aprovar e manter as baselines; Atividade de gerenciamento, controle e documentao Atividade de revisar, aprovar, e liberar

Meta Especfica 2 Meta Genrica 2

Objetivo 6, 7, 8, 9,10 e 11

Processo de liberao de verso

Meta Genrica 2

Objetivo 12, 13 e 14

Quadro 12 Identificao das atividades de GC atendidas em cada norma/modelo

J no Quadro 13 informa os artefatos que so elaborados durante a execuo das principais atividades de GC atendidas pelas normas e pelos modelos de maturidade estudados. Salienta-se que apenas as atividades em que elaborado algum tipo de documentao relacionada GC so consideradas nesse quadro.

Normas e modelos de maturidades Atividades de GC Identificar os itens de configurao

ISO/IEC 12207

ISO/IEC 15504

ISO/IEC 10007

CMMI

MR-MPS

PMBOK

Documentao da baseline, referncia a verso e detalhes que podem ajudar na sua identificao Formulrio de solicitao de mudana, documentao das auditorias e histrico dos artefatos Documentao formal e cpias de segurana

Documentao da baseline

Documentao da baseline

Relatrio de gerenciamento dos artefatos e revises Relatrio de status de mudana, lista de acesso em as baselines, documentao de auditorias e histrico dos artefatos Documento de revises das atividades de GC

Documentao da baseline

Documentao da baseline

Gerenciar as mudanas, as verses e as releases

Formulrio de solicitao de mudana, histrico dos artefatos

Formulrio de solicitao de mudana, documentao das auditorias e histrico dos artefatos Documento de revises das atividades de GC

Formulrio de solicitao de mudana; histrico dos artefatos

Formulrio de solicitao de mudana; histrico dos artefatos

Implantao de GC

Documento de revises das atividades de GC

Documento de revises das atividades de GC

Documento de revises das atividades de GC

Quadro 13 Artefatos de GC elaborados pelas principais atividades de GC encontradas nas normas/modelos

66

4.9 Consideraes Finais

Este captulo abordou as diretrizes de algumas normas e modelos de maturidade que apiam a execuo da GC. Entre essas, se destacou a norma NBR ISO/IEC 10007, que por ser uma norma especfica para o tratamento da GC, apresenta mais detalhes do que as demais normas e modelos de maturidade estudados. No entanto, no fornece gabaritos de formulrios que devem ser elaborados durante a aplicao da GC. Deve-se levar em considerao neste trabalho, que por se tratar de um modelo de referncia de GC de um processo gil baseado em framework devem-se tomar certas precaues, pois o processo no pode perder a sua caracterstica gil e tambm necessrio controlar as verses e as mudanas tanto do framework quanto do sistema alvo. Para definir o modelo de referncia proposto, considerando a problemtica j exposta, no prximo captulo so analisadas as normas e os modelos de maturidade, com o apoio do mtodo Goal Question Metric (GQM) (BASILI et al., 1994), para selecionar as atividades e os artefatos essenciais de GC para compor tal modelo.

MR.GC-PARFAIT: MODELO DE REFERNCIA DE GC DO PARFAIT

5.1 Consideraes Iniciais

Neste captulo apresentam-se a concepo e a documentao parcial do modelo de referncia proposto. Na Seo 5.2 apresentam-se as etapas seguidas para definir as atividades e os artefatos de GC do modelo de referncia, bem como a aplicabilidade das atividades desse modelo nas atividades do PARFAIT. Mais especificamente, na Seo 5.2.1 mostra-se a primeira etapa que seleciona as atividades essenciais de GC para que no haja perda da agilidade do PARFAIT. A Seo 5.2.2, indica a segunda etapa que seleciona os artefatos essenciais de GC para garantir a integridade dos artefatos produzidos pelo PARFAIT, com a mesma preocupao da etapa anterior, ou seja, sem afetar as prticas de modelagem gil utilizadas pelo processo. A Seo 5.2.3 mostra a terceira etapa com a identificao da aplicabilidade das atividades e dos artefatos essenciais de GC nas atividades do PARFAIT. Na Seo 5.3 apresenta-se a quarta etapa que mostra parte da documentao do modelo de referncia proposto, baseada na estrutura da documentao do RUP (Rational Unified Process), contendo a indicao da aplicao de cada atividade de GC do modelo no PARFAIT. Na Seo 5.4 encontram-se as consideraes finais deste captulo.

5.2 Etapas para definio do MR.GC-PARFAIT

Para criar o modelo de referncia da atividade de GC do processo PARFAIT, denominado MR.GC-PARFAIT (FERREIRA; CAGNIN, 2007), foram selecionadas inicialmente apenas as atividades e os artefatos essenciais de GC presentes nas normas e nos modelos de maturidade estudados, sem afetar a aplicabilidade das prticas de modelagem gil definidas na proposio desse processo. Para isso, foram seguidas duas etapas distintas, conforme revela a Figura 6: a primeira etapa trata da seleo das atividades de GC e a segunda trata da seleo dos artefatos. Para a seleo dos artefatos, foram considerados aqueles produzidos nas atividades selecionadas. Posteriormente, foi realizada uma terceira etapa, que identificou em que momento da execuo do PARFAIT as

68

atividades de GC selecionadas deveriam ser aplicadas. E, por fim, na quarta etapa a documentao do modelo de referncia foi elaborada. Todas as etapas foram realizadas de maneira incremental, a fim de refinar o modelo de referncia, conforme ilustrado na Figura 6.

MR.GC-PARFAIT
Atividades selecionadas 1 Etapa: Selecionar as atividades essenciais de GC para o MR.GC-PARFAIT Atividades de GC Identificar os artefatos, criar um repositrio de configurao, gerenciar as mudanas, gerenciar as verses e definir a ferramenta de apoio GC Artefatos de GC Listagem dos itens de configurao, formulrio de controle de mudanas e documentao das verses (baselines)

2 Etapa: Selecionar os artefatos essenciais de GC para o MR.GC-PARFAIT

Aplicabilidade de GC no PARFAIT 3 Etapa: Identificar a aplicabilidade das atividades de GC nas atividades do PARFAIT

Documentao do MR.GC-PARFAIT 4 Etapa: Elaborar a documentao do MR.GC-PARFAIT

Figura 6 - Viso geral da definio do MR.GC-PARFAIT

69

5.2.1 1 Etapa: Selecionar as Atividades Essenciais de GC

Nesta etapa realizou-se a seleo das atividades essenciais de GC para o MR.GCPARFAIT, levando-se em considerao a problemtica do controle de verses na reengenharia baseada em framework, discutida na Seo 3.3.3, bem como a permanncia da agilidade do processo PARFAIT. Para apoiar a anlise quantitativa e objetiva das normas e dos modelos de maturidade a fim de selecionar as atividades essenciais de GC empregou-se o mtodo de mensurao Goal Question Metric (GQM) (BASILI et al., 1994). Esse mtodo foi inicialmente desenvolvido para avaliar defeitos em projetos desenvolvidos pela NASA, na dcada de 80 e, posteriormente, foi estendido para um contexto mais amplo. Assim, esse mtodo orientado a objetivo/meta cuja aplicao feita por meio da coleta de dados, com um objetivo especfico predeterminado. Os passos adotados por este mtodo so estabelecidos de cima para baixo pelos objetivos/metas, questes e mtricas, sendo o resultado interpretado de baixo para cima, a fim de alcanar a meta proposta por este modelo (SOLINGEN; BERGHOUT, 1999), como ilustrado na Figura 7.

Metas

Questes

Mtricas

Figura 7 Mtodo GQM (SOLINGEN; BERGHOUT, 1999)

Segundo Gresse (1996), os objetivos/metas que devem ser alcanados com a aplicao do GQM apresentam-se em cinco maneiras distintas: objetivo do estudo (conjunto de metas relacionadas ao processo ou ao produto); propsito (que determina, caracteriza, melhora e controla questes de relevncia fundamental); foco da qualidade (meta relacionada qualidade); ponto de vista (meta relacionada satisfao a quem interessa os resultados almejados); e ambiente (contexto relacionado interpretao dos resultados).

70

As questes no GQM esto relacionadas diretamente ao objetivo proposto. J as mtricas alcanam as questes por meio dos resultados coletados de maneira quantitativa, visando obter as informaes necessrias para atender ao objetivo proposto. Para apoiar a aplicao do GQM neste trabalho, foi estabelecida uma mtrica, denominada Grau de Importncia (FERREIRA; CAGNIN, 2006). O objetivo dessa mtrica quantificar a importncia dos elementos em um determinado contexto. No caso deste trabalho observou-se o percentual de ocorrncia das atividades e dos artefatos de GC nas normas e modelos de maturidade estudados para compor o modelo de referncia MR.GC-PARFAIT. Para estabelecer o grau de importncia, necessrio utilizar a seguinte escala: grau 5 (extremamente importante): percentual de ocorrncia de 100% a 80%; grau 4 (importante): de 79% a 60%; grau 3 (importncia moderada): de 59% a 40%; grau 2 (pouco importante): de 39% 20%; grau 1 (sem importncia): de 19% a 0%. Dando incio aplicao do GQM para apoiar a seleo das atividades para compor o modelo de referncia, foram observados os seguintes dados: a ocorrncia das atividades de GC, definidas por Sommerville (2003), nas normas e nos modelos de maturidade estudados (CMMI, ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 10007, PMBOK, MR-MPS); o percentual das prticas de modelagem gil consideradas pelo PARFAIT (documente de maneira gil, organize uma participao ativa dos clientes, atualize apenas quando necessrio, crie contedo simples, modele incrementalmente, crie diversos modelos em paralelo), que no so prejudicadas por cada atividade de GC; e o percentual de apoio dessas atividades de GC no controle de verses tanto do framework quanto do sistema alvo, conforme apresentado no Quadro 14. Considerando a questo 1 elaborada com a aplicao do GQM (Quadro 14), observou-se a ocorrncia de cada atividade de GC, definida por Sommerville (2003), em cada norma e modelo de maturidade, conforme apresentado nas colunas dois a sete do Quadro 15. A partir disso, aplicou-se a mtrica 1, obtendo-se o percentual de ocorrncia. Exemplificando, a atividade identificar os artefatos (1) est presente em todas as normas e modelos de maturidade. Assim, o valor da mtrica 1 para essa atividade de 100%. Posteriormente, estabeleceu-se o grau de importncia (mtrica 1.1) a partir do resultado obtido na mtrica 1. Nesse caso, o resultado da mtrica 1.1 para a atividade de GC identificar os artefatos de 5 (extremamente importante).

71

Objetivo: Analisar as atividades de GC dos modelos de maturidade CMMI, ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 10007, PMBOK e MR-MPS com o propsito de selecionar as atividades essenciais de GC para o PARFAIT sem afetar sua agilidade e apoiar o controle das verses tanto do framework quanto das geradas a partir dele, do ponto de vista de GC de Software, no contexto de processos de reengenharia. Questo 1: A atividade X9 est presente na maioria das normas e modelos de maturidade? Mtrica 1: Percentual de ocorrncia da atividade X nas normas e modelos de maturidade. Mtrica 1.1: Valor do grau de importncia. Questo 2: A agilidade do PARFAIT no prejudicada pela atividade X? Mtrica 2: Percentual das prticas geis, atendidas pelo PARFAIT, que no so prejudicadas pela atividade X. Mtrica 2.1: Valor do grau de importncia. Questo 3: A atividade X apia o controle das verses do framework e das aplicaes geradas a partir dele? Mtrica 3: Percentual de apoio do controle de verses presente na atividade X. Mtrica 3.1: Valor do grau de importncia. Mtrica 3.2: Mdia ponderada do grau de importncia obtido nas mtricas 1.1, 2.1 e 3.1 ... Quadro 14 Plano de mensurao GQM das atividades de GC

Atividades de GC 1 - Identificar os itens de configurao 2 - Criar um repositrio de configurao 3 - Gerenciar as mudanas 4 - Gerenciar as verses 5 - Gerenciar as releases 6 - Efetuar as revises de GC 7 - Definir a ferramenta de apoio GC

CMMI

ISO/IEC 12207 -

Atividades de GC - Questo 1 ISO/IEC ISO/IEC PMBOK 15504 10007

MRMPS

Mtrica 1

Mtrica 1.1

100%

100% 100% 100% 50%

5 5 5 3 3 5

50% 100%

Quadro 15 - Resultado da questo 1

Com relao questo 2 foi observado se cada prtica de modelagem gil atendida pelo PARFAIT no prejudicada de alguma maneira pelas atividades de GC de Sommerville (2003), conforme apresentado nas colunas dois a sete do Quadro 16. Com isso, aplicou-se a mtrica 2,

Cada atividade de GC considerada por Sommerville (2003): 1) identificar os artefatos, 2) criar um repositrio de configurao, 3) gerenciar as mudanas, 4) gerenciar as verses, 5) gerenciar as releases, 6) efetuar as revises de GC e 7) definir a ferramenta de apoio GC.

72

obtendo-se o percentual das prticas de modelagem gil que no so prejudicadas. Exemplificando, as atividades de GC gerenciar as releases (5) e efetuar as revises de GC (6) prejudicam metade das prticas de modelagem gil atendidas pelo PARFAIT, ou seja, as prticas de modelagem gil crie apenas documentos extremamente necessrios, atualize apenas quando necessrio e crie contedo simples. Tais prticas so prejudicadas uma vez que tais atividades produzem documentao importante, mas no essencial para o controle de verses exigido pelo PARFAIT. Em seguida, obteve-se o grau de importncia (mtrica 2.1) com valor 3 (importncia moderada) a partir do resultado obtido na mtrica 2.

Atividades de GC - Questo 2 Atividade de GC 1 - Identificar os itens de configurao 2 - Criar um repositrio de configurao 3 - Gerenciar as mudanas 4 - Gerenciar as verses 5 - Gerenciar as releases 6 Efetuar as revises de GC 7 Definir a ferramenta de apoio GC Crie apenas documentos extremamente necessrios Organize uma participao ativa dos clientes Atualize apenas quando necessrio Crie contedo simples Modele incrementalmente Crie diversos modelos em paralelo Mtrica 2 Mtrica 2.1

100%

100% 100% 100% 50% 50% 100%

5 5 5 3 3 5

Quadro 16 Resultado da questo 2

No Quadro 18 verificou-se se cada atividade de GC interfere de alguma maneira, nas prticas de modelagem gil presentes no PARFAIT. Considerando a atividade de GC identificar os itens de configurao observou-se que a mesma no interfere na prtica gil crie apenas documentos extremamente necessrios, pois essencial identificar logo no comeo quais artefatos sero elaborados no projeto de reengenharia. J, com relao a prtica organize uma participao ativa dos clientes, o cliente pode validar os artefatos que sero submetidos a GC podendo acrescentar ou retirar algum, caso seja necessrio. Na prtica atualize apenas quando necessrio caso ocorram mudanas ser necessrio atualizar esta listagem de itens de configurao. Na prtica crie contedo simples, o gabarito desta atividade pode na forma de check-list, assim fica a critrio do engenheiro de software decidir para cada projeto empregar ou no GC em cada artefato. Na prtica modele incrementalmente, a identificao dos itens de configurao no ir prejudicar em

73

tal prtica. J na prtica crie diversos modelos em paralelo, como esta identificao uma sugesto, no interferir na criao de outra lista ou no acrscimo ou retirada de alguma das opes sugeridas. J na questo 3 (Quadro 14), verificou-se se cada atividade de GC apia ou no o controle de verso tanto do framework quanto do sistema alvo, conforme apresentado nas colunas dois e trs do Quadro 18. Adicionalmente, analisou-se se cada atividade de GC apia o controle de dependncia de verses entre o framework e o sistema alvo, conforme ilustrado na coluna quatro do Quadro 18. Exemplificando, a atividade criar um repositrio de configurao (2) apia o controle de verses do sistema alvo, o controle de verses do framework e a dependncia entre as verses dos mesmos. Ressalta-se que o apio da dependncia entre as verses tanto do framework quanto do sistema alvo possvel por meio de uma seqncia de pastas dentro do repositrio da ferramenta de controle de verso Subversion (Seo 6.3.3). As demais atividades no apiam a dependncia entre framework e o sistema alvo. Assim, o valor da mtrica 3 para a atividade Criar um repositrio de configurao de 100%. Posteriormente, estabeleceu-se o grau de importncia com o emprego da mtrica 3.1, a partir do resultado obtido na mtrica 3. Para a atividade gerenciar as verses (4) o valor obtido da mtrica 3.1 de 4.

Atividades de GC 1 - Identificar os itens de configurao 2 - Criar um repositrio de configurao 3 - Gerenciar as mudanas 4 - Gerenciar as verses 5 - Gerenciar as releases 6 - Efetuar as revises de GC 7 - Definir a ferramenta de apoio GC

Apia o controle de verso do framework

Atividades de GC - Questo 3 Apia o controle de Apia a dependncia verso do sistema entre framework e alvo sistema alvo -

Mtrica 3 67%

Mtrica 3.1 4

100% 67% 67% 67% 67% 67%

5 4 4 4 4 4

Quadro 17 Resultado da questo 3

Atividade de GC

1 Identificar os itens de configurao

Crie apenas documentos extremamente necessrios A elaborao da listagem dos itens de configurao se tornou essencial logo no comeo do projeto de reengenharia, pois os artefatos sero considerados e transformados em baselines, assim no prejudica tal prtica gil A criao do repositrio se tornou de vital importncia quando se trata de gerenciar com qualidade os artefatos produzidos durante o projeto de reengenharia, assim no prejudica tal prtica gil Tal atividade extremamente necessria por documentar por meio de gabaritos as mudanas ocorridas nos itens de configurao elaborados durante o projeto de reengenharia e no prejudica tal prtica gil

Organize uma participao ativa dos clientes

Atualize apenas quando necessrio Caso as mudanas ocorram, ser necessrio atualizar o gabarito dos itens de configurao, assim esta atividade no prejudica tal prtica gil Devido ao uso da ferramenta Subversion, caso seja necessrio existe a possibilidade de mudar o nome, o local do repositrio, acrescentar ou retirar algum item de configurao, assim no prejudica tal prtica gil

Crie contedo simples Esta atividade sugere um gabarito simples dos possveis artefatos que sero submetidos a GC, ficaria a critrio de cada projeto empregar ou no os artefatos sugeridos, assim no prejudica tal prtica gil O repositrio apresentase de maneira simples e satisfatria para conduo do projeto de reengenharia, assim no prejudica tal prtica gil O gerenciamento ser realizado por meio dos gabaritos sugeridos por tal atividade de GC, que se apresenta de maneira simples e de rpido preenchimento, assim no prejudica tal prtica gil

Modele incrementalmente

A participao dos clientes pode validar, acrescentar ou retirar algum dos artefatos que sero submetidos a GC, assim no prejudica tal prtica gil

Tal prtica no ser prejudicada por tal atividade, pois realizada apenas uma vez

Crie diversos modelos em paralelo Devido o gabarito ser uma sugesto no interferir a criao de outra ou at mesmo acrescentar ou retirar alguma das opes sugeridas, assim no prejudica tal prtica gil O repositrio ser criado apenas uma vez, no ser necessrio ter vrios modelos e no prejudica tal prtica gil

2 - Criar um repositrio de configurao

As participaes dos clientes podem de uma maneira ou de outra influenciar a criao do repositrio que ter particularidades prprias de cada projeto de reengenharia, assim no prejudica tal prtica gil

Tal prtica no ser prejudicada por tal atividade, devido ser realizada apenas uma vez O desenvolvimento do projeto ser incrementalmente implementado de acordo com a necessidade imposta por tal projeto, assim tal atividade no prejudica esta prtica gil Os artefatos so criados incrementalmente, sendo que as verses dos mesmos podem ser atualizadas a qualquer momento do projeto de reengenharia, assim no prejudica tal prtica gil Tal atividade ser realizada apenas quando o sistema ser entregue ao cliente, assim no possuir nenhuma modelagem incremental

3Gerenciar as mudanas

Por meio da solicitao de mudanas necessrias ou solicitadas pelo cliente que se gerencia tal mudana que no prejudica tal prtica gil

O gerenciamento da mudana s ser realizado caso seja necessrio, assim no prejudica tal prtica gil

Caso seja necessrio poder criar verses diferentes devido a uma solicitao de um cliente, assim no prejudica tal prtica gil

4Gerenciar as verses

A documentao criada pelo gerenciamento das verses extremamente necessria para controlar melhor as verses de cada artefato, assim no prejudica tal prtica gil

Cada verso do sistema pode possuir alguma particularidade diferente ou exclusiva para um determinado cliente. Por meio deste gerenciamento ser de fcil localizao e acesso a tal verso, assim no prejudica tal prtica gil

A documentao do gerenciamento de verso s ser atualizada quando necessrio, assim no prejudica essa prtica gil

O gabarito desta atividade se apresenta simples e de fcil preenchimento, assim no prejudica tal prtica gil

Devido s diversas particulares que cada verso do sistema possa ter, assim tal atividade no prejudica tal prtica gil devido principalmente ao gerenciamento proporcionado por esta atividade

5Gerenciar as releases

A documentao criada nesta atividade repetida, devido ser a mesma apresentada na atividade Gerenciar as verses, assim se tornou invivel armazen-la no repositrio e assim prejudica tal prtica gil

Se cada verso possui alguma particularidade especial para um determinado cliente isso depende principalmente da participao do cliente, assim no prejudica tal prtica gil

A atualizao da documentao criada nesta atividade ser a mesma apresentada pela atividade Gerenciar as verses, assim prejudica tal prtica gil por apresentar uma documentao duplicada

O contedo desta atividade no ser complexo, pois seria a mesma da atividade Gerenciar as verses e isso no prejudicaria tal prtica

Tal atividade criar vrias releases e no prejudicar tal prtica gil

75

6 Efetuar as revises de GC

Esta atividade apresentar vrias documentaes que no sero extremamente necessrias, assim tal prtica ser prejudicada por tal atividade Esta atividade no cria documentao, assim no prejudica tal prtica gil

A validao pelo o usurio das revises pode auxiliar esta atividade, assim tal prtica gil no ser prejudicada A participao do cliente pode facilitar a escolha da ferramenta empregada na GC, assim no prejudica tal prtica gil

Atualizar esta atividade pode prejudicar a agilidade por apresentar vrios documentos, assim pode prejudicar tal prtica gil

Esta atividade apresenta documentao complexa, assim prejudica tal prtica gil

Esta atividade criar vrias documentaes e pode ser realizada incrementalmente, assim no prejudica tal prtica gil Esta atividade no cria documentao, assim no prejudica tal prtica gil

Esta atividade cria vrias documentaes, mas caso for necessrio pode criar outros modelos, assim no prejudica tal prtica gil Esta atividade no cria documentao, assim no prejudica tal prtica gil

7 Definir a ferramenta de apoio GC

Esta atividade realizada uma nica vez, assim no prejudica tal prtica gil

Esta atividade no cria documentao, assim no prejudica tal prtica gil

Quadro 18 Justificativas das prticas geis

Dando prosseguimento primeira etapa, foi estabelecida a mtrica 3.2, que trata da mdia ponderada dos resultados obtidos com a aplicao das mtricas 1.1, 2.1 e 3.1, Quadro 19. A partir do resultado obtido no Quadro 19, observou-se que as atividades 1 (identificar os artefatos), 2 (criar um repositrio de configurao), 3 (gerenciar as mudanas), 4 (gerenciar as verses) e 7 (definir a ferramenta de apoio GC) so consideradas essenciais para a GC e devem estar presentes no MR.GC-PARFAIT.

Atividades de GC
1 - Identificar os itens de configurao 2 - Criar um repositrio de configurao 3 - Gerenciar as mudanas 4 - Gerenciar as verses 5 - Gerenciar as releases 6 - Efetuar as revises de GC 7 - Definir a ferramenta de apoio GC

Mtrica 1.1 5 5 5 5 3 3 5

Mtrica 2.1 5 5 5 5 3 3 5

Mtrica 3.1 4 5 4 4 4 4 4

Mtrica 3.2 4,7 5 5 4,7 5 4,7 5 3,4 3 3,4 3 4,7 5

Quadro 19 - Resultados da mdia ponderada das mtricas das atividades de GC

5.2.2 2 Etapa: Selecionar os Artefatos Essenciais de GC

A segunda etapa foi iniciada com o resultado obtido na seleo das atividades essenciais de GC com grau de importncia 510 para compor o modelo MR.GC-PARFAIT, realizada na etapa anterior. Para iniciar esta etapa, optou-se tambm pela utilizao do mtodo Goal Question Metric (GQM) para identificar quais artefatos presentes nas atividades selecionadas so relevantes para serem incorporados ao modelo de referncia, conforme apresentado no Quadro 20. Para isso, foi analisado o percentual de ocorrncia de cada artefato produzido pelas atividades de GC

10

Atividades de GC selecionadas: Identificar os artefatos; Criar um repositrio de configurao; Gerenciar as mudanas; Gerenciar as Verses; Definir a ferramenta de apoio GC.

77

selecionadas, nas normas e modelos de maturidade. Adicionalmente, analisou-se tambm o percentual das prticas de modelagem gil que no so prejudicadas pelos artefatos.

Objetivo: Analisar os artefatos das atividades essenciais de GC, presentes nos modelos de maturidade CMMI, ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 10007, PMBOK e MR-MPS com o propsito de selecionar os artefatos essenciais de GC para o PARFAIT, sem afetar sua agilidade, e apoiar o controle das verses tanto do framework quanto das aplicaes geradas parte dele do ponto de vista de GC de Software, no contexto de processos de reengenharia. Questo 4: O artefato Y11 est presente na maioria das normas e modelos de maturidade? Mtrica 4: Percentual de ocorrncia do artefato Y nas normas e modelos de maturidade. Mtrica 4.1: Valor do grau de importncia. Questo 5: A agilidade do PARFAIT no prejudicada pelo artefato Y? Mtrica 5: Percentual das prticas de Modelagem gil atendidas pelo PARFAIT, que no so prejudiciais pelo artefato Y. Mtrica 5.1: Valor do grau de importncia. Mtrica 5.2: Mdia ponderada do grau de importncia obtido nas mtricas 4.1 e 5.1 ... Quadro 20 Plano de mensurao GQM dos artefatos elaborados pelas atividades de GC

Considerando a questo 4, elaborada com a aplicao do GQM (Quadro 20), observou-se a ocorrncia de cada artefato de GC em cada norma e modelo de maturidade estudado, conforme apresentado no Quadro 21. A partir disso, aplicou-se a mtrica 4, obtendo o percentual de ocorrncia. Como pode ser visto no Quadro 20, todos os artefatos elaborados nas atividades de GC selecionadas esto presentes em todas as normas e modelos de maturidade. Assim, o valor da mtrica 4 de 100%. Em seguida, estabeleceu-se o grau de importncia (mtrica 4.1), obtendo-se 5 (extremamente importante) como resultado. Com relao questo 5, foi verificado se cada prtica de modelagem gil atendida pelo PARFAIT no prejudicada pelos artefatos de GC. Com isso, aplicou-se a mtrica 5 obtendo-se o percentual das prticas geis que no so prejudicadas pelos artefatos, conforme apresentado nas colunas dois a sete do Quadro 22. Observa-se que todos os artefatos no prejudicam nenhuma prtica de modelagem gil atendida pelo PARFAIT, ou seja, o valor da mtrica 5 de 100% para todos os artefatos. Em seguida, obteve-se o grau de importncia 5 (extremamente importante) (mtrica 5.1) a partir do resultado da mtrica 5.

11

Documento da baseline, formulrio de controle de mudana e histrico dos artefatos.

78

Artefato 1 - Documento da baseline 2 - Formulrio de controle de mudana 3 - Histrico dos artefatos

CMMI

ISO/IEC 12207

Artefatos de GC Questo 4 ISO/IEC ISO/IEC PMBOK 15504 10007

MRMPS

Mtrica 4 100% 100% 100%

Mtrica 4.1 5 5 5

Quadro 21 - Resultados da questo 4

Artefatos de GC Questo 5 Crie apenas documentos extremament e necessrios Organize uma participao ativa dos clientes Atualize apenas quando necessrio Crie contedo simples Modele incremental -mente Crie diversos modelos em paralelo Mtrica 5 100% Mtrica 5.1 5

Artefato

1Documento da baseline 2Formulrio de controle de mudana 3 - Histrico dos artefatos

100%

100%

Quadro 22 Resultado da questo 5

No Quadro 23 verificou-se se cada artefato criado pelas atividades selecionadas na etapa anterior interfere, de alguma maneira, nas prticas de modelagem gil presentes no PARFAIT. Considerando o artefato de GC documento da baseline (1) observou-se que o mesmo no interfere na prtica gil crie apenas documentos extremamente necessrios, pois essencial documentar a baseline logo no incio para facilitar a elaborao do projeto de reengenharia. J, com relao a prtica organize uma participao ativa dos clientes, o cliente pode validar tal documentao podendo acrescentar ou alterar alguma informao, caso seja necessrio. Na prtica gil atualize apenas quando necessrio observou-se que caso seja necessrio realizar algumas mudanas, a documentao da baseline dever ser atualizada e tal procedimento no ir prejudicar tal prtica gil. Na prtica gil crie contedo simples notou-se que a utilizao de um gabarito da documentao da baseline poder facilitar o preenchimento e simplificar tal documentao, assim no ir prejudicar tal prtica gil. Na prtica gil modele incrementalmente, a documentao da baseline no ir prejudicar tal prtica pois a documentao poder ser criada ou evoluda de acordo com a evoluo de um determinado artefato, j com relao a prtica gil crie diversos modelos

79

em paralelo como a documentao da baseline sugerida, fica a critrio do gerente do projeto de reengenharia alter-la ou criar um modelo especfico ou mais apropriado necessidade do projeto.

Artefato

1Documento da baseline

Crie apenas documentos extremamente necessrios O gabarito produzido extremamente necessria para controlar melhor as verses de cada artefato, assim no prejudica tal prtica gil O gabarito produzido extremamente necessria para controlar melhor as mudanas de cada artefato, assim no prejudica tal prtica gil O gabarito produzido extremamente necessria para controlar o histrico dos artefatos, assim no prejudica tal prtica gil

Organize uma participao ativa dos clientes O gabarito produzido pode ter alguma caracterstica exclusiva para um determinado cliente, assim no prejudica tal prtica gil O gabarito produzido pode ter alguma caracterstica exclusiva para um determinado cliente, assim no prejudica tal prtica gil O gabarito produzido pode ter alguma caracterstica exclusiva para um determinado cliente, assim no prejudica tal prtica gil

Atualize apenas quando necessrio O gabarito produzido pode ser atualizado quando necessrio, assim no prejudica tal prtica gil O gabarito produzido por esse artefato pode ser atualizada quando necessrio, assim no prejudica tal prtica gil O gabarito produzido por esse artefato pode ser atualizada quando necessrio, assim no prejudica tal prtica gil

Crie contedo simples

Modele incrementalmente O gabarito pode ser produzido incrementalmente caso necessrio, assim no prejudica tal prtica gil O gabarito pode ser produzido incrementalmente caso necessrio, assim no prejudica tal prtica gil O gabarito pode ser produzido incrementalmente caso necessrio, assim no prejudica tal prtica gil

Crie diversos modelos em paralelo O gabarito produzido pode ser criado em paralelo caso necessrio, assim no prejudica tal prtica gil O gabarito produzido pode ser criado em paralelo caso necessrio, assim no prejudica tal prtica gil O gabarito produzido pode ser criado em paralelo caso necessrio, assim no prejudica tal prtica gil

O contedo criado por tal gabarito ser simples e no prejudica tal prtica gil

2Formulrio de controle de mudana

O contedo criado por tal gabarito ser simples e no prejudica tal prtica gil

3 - Histrico dos artefatos

O contedo criado por tal gabarito ser simples e no prejudica tal prtica gil

Quadro 23 Justificativas das prticas geis

Dando continuidade segunda etapa, foi estabelecida a mtrica 5.2, que trata da mdia ponderada dos resultados obtidos com a aplicao das mtricas 4.1 e 5.1, conforme apresentado no Quadro 24. A partir disso, observou-se que todos os artefatos de GC foram considerados como sendo essenciais e que devem compor o modelo de referncia do PARFAIT.

Atividade de GC 1 - Documento da baseline 2 - Formulrio de controle de mudana 3 - Histrico dos artefatos

Mtrica 4.1 5 5 5

Mtrica 5.1 5 5 5

Mtrica 5.2 5 5 5

Quadro 24 - Resultados da mdia ponderada das mtricas dos artefatos de GC

80

5.2.3 3 Etapa: Identificar a Aplicabilidade das Atividades Essenciais de GC nas Atividades do PARFAIT

Ao concluir as etapas um e dois, observou-se a necessidade de identificar a aplicabilidade das atividades de GC selecionadas para o modelo de referncia, nas atividades do PARFAIT. Para apoiar esta terceira etapa, foi realizada uma anlise da documentao do processo PARFAIT a fim de selecionar as suas atividades que devero ser submetidas GC com o apoio do MR.GCPARFAIT. A anlise realizada foi baseada em trs critrios: 1) se determinada atividade do processo incremental (conseqentemente, os artefatos so elaborados inicialmente e posteriormente refinados); 2) se determinada atividade do processo produz artefatos relevantes para conduzir a reengenharia e que devem ser submetidos ao gerenciamento de configurao; e 3) se os artefatos produzidos em uma determinada atividade no incremental so atualizados em outras atividades ou nos marcos de referncia. O resultado da anlise realizada (Quadro 25) apresenta-se uma sugesto das atividades de GC que devem ser adotadas durante a aplicao do MR.GC-PARFAIT no PARFAIT, entretanto a sua real aplicabilidade deve ser analisada de acordo com as necessidades do projeto de reengenharia. Neste quadro est estabelecida a relao entre as atividades do processo PARFAIT, as atividades de GC selecionadas para o modelo de referncia deste processo e a justificativa do emprego das atividades de GC em uma determinada atividade do PARFAIT, de acordo com os critrios citados anteriormente. Ressalta-se que a atividade de GC gerenciar mudanas foi necessria na atividade do PARFAIT Criar o sistema alvo no paradigma orientado a objeto, por ser considerada crtica (uma vez que, caso seja realizada alguma mudana indesejada no sistema alvo, pode comprometer o sucesso da reengenharia) e por utilizar framework (sendo necessrio analisar a verso do mesmo a ser utilizada para criar novas verses do sistema alvo). Caso seja utilizada uma verso do framework diferente daquela utilizada em iteraes anteriores desta atividade, necessrio verificar se a verso no afetar o comportamento do sistema alvo. J a atividade de GC gerenciar as verses est presente em todas as atividades do PARFAIT que compem o modelo de referncia, pois em cada uma destas atividades elaborado algum artefato relevante, que necessite deste controle.

81

Atividades do PARFAIT Familiarizar-se com o domnio do framework Observar o domnio do sistema legado em relao ao do framework Confrontar as caractersticas no funcionais do framework x sistema legado Elaborar o Planejamento do Projeto de reengenharia Desenvolver o diagrama de casos de uso e elaborar os casos de teste Desenvolver o diagrama de classes do sistema alvo Documentar as modificaes realizadas no diagrama de classes Documentar as regras de negcio do sistema Criar o sistema alvo no paradigma orientado a objeto Executar os casos de teste no sistema alvo

Atividades de GC Nenhuma Identificar os itens de configurao Definir a ferramenta de apoio Criar um repositrio Gerenciar as Verses Gerenciar as Verses Gerenciar as Verses Gerenciar as Mudanas

Justificativa da Execuo das Atividades de GC Esta atividade do PARFAIT no obrigatria e no incremental, assim no apresentou necessidade de ser gerenciada. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. A ordem das atividades de GC foi determinada de acordo com os artefatos de entrada necessrios para a execuo de cada atividade (pr-requisito). Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 3.

Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Gerenciar as Verses Gerenciar as Verses Gerenciar as Verses Gerenciar as Verses Gerenciar as Mudanas Gerenciar as Verses Gerenciar as Verses Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Alm disso, no passo Executar o sistema alvo concomitantemente com o sistema legado desta atividade do PARFAIT necessrio analisar se as mudanas solicitadas pelos usurios so importantes e devem ser efetuadas no sistema alvo. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. Esta atividade do PARFAIT satisfaz os critrios 1 e 2. No satisfaz nenhum critrio, pois no possui artefato para ser gerenciado Esta atividade do PARFAIT satisfaz os critrios 1 e 2. No satisfaz nenhum critrio, pois no possui artefato para ser gerenciado

Adaptar o sistema alvo

Gerenciar as Mudanas

Gerenciar as Verses Elaborar o manual do usurio do sistema alvo Converter a base de dados do sistema legado Testar o sistema alvo Treinar os usurios finais Gerenciar as Verses Gerenciar as Verses -

Quadro 25 - Atividades do PARFAIT versus atividades de GC

5.3 4 Etapa: Elaborar a documentao do MR.GC-PARFAIT

O formato da documentao do MR.GC-PARFAIT (FERREIRA; CAGNIN, 2007) definido neste estudo segue aquele utilizado no RUP: atividade, objetivo, artefatos de entrada e de

82

sada, apoio computacional, passos e gabaritos. Alm disso, um item foi adicionado na documentao, que aplicao no PARFAIT, ou seja, em que momento do processo PARFAIT (atividade) determinada atividade de GC do modelo de referncia deve ser executada. Sugere-se que o responsvel pela reengenharia determine um membro da equipe como gerente de configurao, que deve ter conhecimento e habilidade de executar as atividades impostas pelo MR.GC-PARFAIT. Um breve resumo da documentao do MR.GC-PARFAIT est presente no Quadro 26, apresentando o objetivo de cada atividade de GC, os artefatos elaborados e a aplicabilidade de tal atividade no PARFAIT.
Atividade de GC Identificar os itens de configurao Definir a ferramenta de apoio Criar um repositrio de configurao Objetivo Selecionar os artefatos do PARFAIT que devero ser submetidos GC Definir a ferramenta que melhor apie a GC Armazenar os itens de configurao no repositrio da ferramenta de controle de verso Artefatos Produzidos Listagem dos itens de configurao Aplicabilidade no PARFAIT Atividade: Observar o domnio do sistema legado em relao ao framework Atividade: Observar o domnio do sistema legado em relao ao framework Atividade: Observar o domnio do sistema legado em relao ao framework

Repositrio criado

Gerenciar as verses

Gerenciar as verses do framework, do sistema alvo e dos demais itens de configurao

Documentao das verses do framework, do sistema alvo e dos demais itens de configurao Formulrio de controle de mudanas do framework e do sistema alvo

Fase de Elaborao e Construo Atividades: Observar o domnio do sistema legado em relao ao do framework; Confrontar as caractersticas no funcionais do Framework x sistema legado; Elaborar o planejamento do projeto de reengenharia; elaborar o manual do usurio do sistema alvo; Testar o sistema alvo. Atividades: - Criar o sistema alvo no paradigma orientado a objetos e adaptar o sistema alvo.

Gerenciar as mudanas

Gerenciar as mudanas no framework e no sistema alvo

Quadro 26 Resumo da documentao do MR.GC-PARFAIT

Nas subsees a seguir mostra-se a documentao completa de apenas duas das atividades de GC que compem o MR.GC-PARFAIT que so: gerenciar as verses e gerenciar as mudanas. A documentao das demais atividades desse modelo de referncia encontra-se no Apndice A.

5.3.1 Atividade: Gerenciar as Verses (Obrigatria)

Objetivo: Nesta atividade so gerenciadas as verses do framework, as verses do sistema alvo gerado a partir de tal framework, bem como as verses dos demais itens de configurao. Essa

83

atividade conduzida pelos envolvidos no projeto de reengenharia. Especificamente para o caso das verses do framework so documentadas as particularidades apresentadas em cada verso, como por exemplo, plataforma, necessidades de hardware e software, linguagem de programao, entre outras. Aplicao no PARFAIT: em todas as atividades das fases de Elaborao e Construo e em algumas da fase de Concepo e Transio: Observar o domnio do sistema legado em relao ao do framework (Fase de Concepo); Confrontar as caractersticas no funcionais do Framework x sistema legado (Fase de Concepo); Elaborar o planejamento do projeto de reengenharia (Fase de Concepo); Elaborar o manual do usurio do sistema alvo (Fase de Transio); Testar o sistema alvo (Fase de Transio). Artefatos de entrada: Documentao das particularidades das verses do framework e dos sistemas gerados, bem como a dos demais itens de configurao. Apoio computacional: Editor de texto e ferramenta de controle de verso. Artefatos de sada: Documentao das verses do framework, do sistema alvo, dos demais itens de configurao (baseline). Passos: 1. Documentar de forma detalhada as peculiaridades apresentadas em cada verso do framework e do sistema alvo gerado, a partir do mesmo e em cada verso dos demais itens de configurao; 2. Armazenar a verso do item de configurao no repositrio da ferramenta de controle de verso. Gabaritos: Nesta atividade foram desenvolvidos gabaritos para documentar as verses dos itens de configurao. Para documentar as verses do sistema alvo e do framework foram criados formulrios especficos, apresentados no Quadro 27 e no Quadro 28, respectivamente. Para documentar as verses dos demais itens de configurao selecionados na atividade Identificar os itens de configurao necessrio utilizar o formulrio apresentado no Quadro 29. Salienta-se que sero documentadas apenas as verses dos itens de configurao que se tornarem baseline. Alm de informaes especficas sobre a verso, necessrio registrar tambm o nmero da iterao do projeto de reengenharia que o item de configurao foi criado e/ou modificado, bem como o nome da atividade em que isso ocorreu.

84

Documentao das Verses do Sistema Alvo Documentao da Verso <nmero da verso do sistema> do Sistema Alvo <nome do sistema alvo> Projeto <nome do projeto> Data de criao do formulrio <dd/mm/aa hh:mm>

Verso do framework utilizada <nmero de verso do framework > Variabilidades funcionais do framework reutilizadas <lista dos nomes das variabilidades funcionais> Variabilidades No-Funcionais do framework reutilizadas < lista dos nomes das variabilidades no-funcionais>

Requisitos funcionais do sistema no reutilizados do framework <lista dos nomes dos requisitos funcionais >

Requisitos no-funcionais do sistema no reutilizados do framework <lista dos nomes dos requisitos no-funcionais>

Quadro 27 - Gabarito da documentao das verses do sistema alvo

Documentao das Verses do Framework Documentao da Verso <nmero da verso do framework > do framework <nome do framework > Plataforma <nome da plataforma utilizada> Domnio <nome do domnio coberto pelo framework> Recursos de hardware e software requeridos <por exemplo, ambiente de desenvolvimento, verso do compilador da linguagem de programao, sistema gerenciador de banco de dados (SGBD), verso do SGBD> Data de criao do formulrio <dd/mm/aa hh:mm> Linguagem de programao <nome da linguagem de programao utilizada>

Variabilidades funcionais <lista dos nomes das variabilidades funcionais>

Variabilidades no-funcionais <lista dos nomes das variabilidades no-funcionais>

Quadro 28 - Gabarito da documentao das verses do framework

85

Documentao das Verses dos demais Itens de Configurao Nome do Projeto <nome do projeto> Data de criao ou atualizao do item <dd/mm/aa> Nome dos itens de configurao <nome do item de configurao> Data de criao do formulrio <dd/mm/aa hh:mm> Verso <verso do item de configurao> Nmero da iterao <nmero da iterao do sistema alvo> Nome da atividade do PARFAIT <nome da atividade do PARFAIT que esta o item de configurao>

Quadro 29 - Gabarito da documentao das verses dos itens de configurao

5.3.2 Atividade Gerenciar as Mudanas (Obrigatria)

Objetivo: Esta atividade empregada somente quando existir a necessidade de mudanas no sistema alvo ou no framework, que sejam tomadas as medidas necessrias para que ocorram as mudanas sem prejudicar a integridade das baselines desses itens de configurao. Aplicao no PARFAIT: Nas atividades Criar o sistema alvo no paradigma orientado a objetos (Fase construo) e Adaptar o sistema alvo (Fase de construo). Artefatos de entrada: Formulrios de controle de mudanas do framework e do sistema alvo Apoio computacional: Editor de texto e ferramenta de controle de verso. Artefatos de sada: Formulrios de controle de mudanas do framework e do sistema alvo devidamente preenchidos e aprovados/reprovados. Passos: 1. Identificar as mudanas necessrias. 2. Preencher os formulrios de controle de mudanas do framework (caso seja necessrio) e do sistema alvo (caso seja necessrio). 3. Aprovar ou reprovar as mudanas. 4. Realizar as mudanas e executar a atividade Gerenciar as Verses. Gabarito: As solicitaes de mudanas no sistema alvo, no framework e nos demais itens de configurao devem ser sempre documentadas por meio do formulrio de controle de mudanas, apresentado respectivamente no Quadro 30, no Quadro 31 e no Quadro 32. As solicitaes de mudanas no sistema alvo sero aprovadas ou no pelo gerente de configurao, de acordo com a complexidade das mesmas.

86

Formulrio de Controle de Mudanas no Sistema Alvo N da solicitao: <n da solicitao da mudana> Data da solicitao: <dd/mm/aa> Sistema alvo: <nome do sistema alvo> Projeto: <nome do projeto> Tempo estimado para a execuo da mudana <hh:mm> Verso do sistema alvo: <nmero correspondente da verso do sistema alvo que necessita sofrer mudanas> Tipo de mudana: Perfectiva Corretiva Adaptativa Preventiva

Mudana solicitada: <breve descrio da mudana> Artefatos afetados pela mudana solicitada: <lista dos nomes dos artefatos que sero afetados e que sofrero mudanas>

Solicitao de mudana APROVADA Implementar a mudana com apoio do framework: - por meio de nova instanciao do framework (nesse caso o framework fornece a mudana desejada, parcialmente ou completamente) Implementar a mudana manualmente: - por meio de um ambiente de programao

Solicitao de mudana NO APROVADA Retornar ao solicitante um parecer sobre o motivo da no aprovao da solicitao <motivo que levou a inviabilidade das mudanas>

Comentrios Adicionais: < breve descrio, se necessrio>

Quadro 30 - Gabarito do formulrio de controle de mudanas no sistema alvo

Formulrio de Controle de Mudanas no Framework N da solicitao: <n da solicitao da mudana> Data da solicitao: <dd/mm/aa> Framework: <nome do framework> Verso do framework: <nmero correspondente da verso do framework> Tipo de mudana: Perfectiva Corretiva Adaptativa Preventiva Projeto: <nome do projeto> Tempo estimado para a execuo da mudana <hh:mm>

Mudana solicitada: <breve descrio da mudana> Artefatos afetados pela mudana solicitada: <lista dos nomes dos artefatos que sero afetados e que sofrero mudanas>

Solicitao de mudana APROVADA Implementar a mudana no framework

Solicitao de mudana NO APROVADA Retornar ao solicitante um parecer sobre o motivo da no aprovao da solicitao <motivo que levou a inviabilidade das mudanas>

Comentrios Adicionais: < breve descrio, se necessrio>

Quadro 31 - Gabarito do formulrio de controle de mudanas no framework

87

Formulrio de Controle de Mudanas dos demais Itens de Configurao N da solicitao: <n da solicitao da mudana> Data da solicitao: <dd/mm/aa> Nome Artefato: <nome do artefato> Tipo de mudana: Perfectiva Corretiva Projeto: <nome do projeto> Tempo estimado para a execuo da mudana <hh:mm> Verso do Artefato: <verso do artefato> Adaptativa Preventiva

Mudana solicitada: <breve descrio da mudana> Artefatos afetados pela mudana solicitada: <lista dos nomes dos artefatos que sero afetados e que sofrero mudanas>

Solicitao de mudana APROVADA Comentrios Adicionais: < breve descrio, se necessrio>

Solicitao de mudana NO APROVADA

Quadro 32 Gabarito do formulrio de controle de mudanas dos demais itens de configurao

Para analisar tal complexidade preciso levar em considerao quais artefatos sero afetados pela mudana e se os mesmos necessitam de adaptaes ou correes. No caso do PARFAIT com o apoio computacional do framework GREN, a implementao das adaptaes (mudanas) realizadas manualmente no cdigo fonte do sistema alvo feita com o apoio da ferramenta GRENWizardVersionControl a fim de que tais adaptaes no sejam perdidas nas prximas instanciaes do framework. As solicitaes de mudanas no framework sero aprovadas ou no de acordo com uma anlise, que verifica se uma mudana pertinente ou no ao domnio do framework. Essa anlise est fora do escopo deste trabalho e feita com o apoio do Processo de Evoluo de Framework (PREF) (CAGNIN et al., 2004b). As mudanas no framework so efetuadas tambm com o apoio desse processo.

5.4 Consideraes Finais

Neste captulo foram selecionadas as atividades e os artefatos essenciais de GC para compor o modelo de referncia definido neste trabalho, baseando-se em diversas normas e modelos de maturidade existentes com o emprego do mtodo de mensurao GQM, a fim de selecionar quantitativamente as atividades e os artefatos, sem afetar a agilidade do processo de reengenharia

88

PARFAIT. Para apoiar esta seleo foi definida neste trabalho uma mtrica, denominada grau de importncia, para ser utilizada durante a aplicao do GQM. Levando-se em considerao que o PARFAIT utiliza apoio computacional de framework, foi necessrio se preocupar tambm tanto com a gerncia de configurao do framework utilizado pelo processo quanto com a do sistema alvo. Aps a seleo das atividades e artefatos de GC do modelo de referncia, observou-se a necessidade de identificar a aplicabilidade destas atividades nas atividades do PARFAIT. Para isso, foi feita uma anlise objetiva da documentao das atividades do PARFAIT com base em alguns critrios estabelecidos. Posteriormente, deu-se incio elaborao da documentao do modelo de referncia de GC para o processo PARFAIT, que o principal resultado desta dissertao. Tal documentao apresentou as atividades de GC, detalhando como e quando elas devem ser executadas em conjunto com as atividades do PARFAIT para controlar tanto as verses do framework quanto as do sistema alvo. O maior desafio encontrado neste trabalho foi a elaborao da documentao do MR.GCPARFAIT. Ressalta-se que no foi encontrado nenhum modelo de referncia na literatura que descrevesse com detalhes os procedimentos adotados pela GC em processos de reengenharia e nem em processos geis de reengenharia. Para analisar se o MR.GC-PARFAIT apresentado neste captulo satisfaz o que foi proposto, ser conduzido no prximo captulo um estudo de caso quantitativo de um sistema legado em conjunto com o processo PARFAIT, a fim de obter resultados dos benefcios do seu uso.

ESTUDO DE CASO: PARFAIT E MR.GC-PARFAIT

6.1 Consideraes iniciais

Neste captulo abordar-se- como foi conduzido o estudo de caso quantitativo para avaliar o MR.GC-PARFAIT. Na Seo 6.2 deste captulo apresenta-se o planejamento do estudo de caso; na Seo 6.3 descreve-se como o estudo de caso foi executado, apresentando tambm a anlise e a interpretao dos resultados obtidos, bem como uma discusso das dificuldades enfrentadas. Na Seo 6.4 encontram-se as consideraes finais deste captulo.

6.2 Planejamento do Estudo de Caso para avaliar o MR.GC-PARFAIT

Esse planejamento, definido e documentado de acordo com o formato proposto por Wholin et al. (2000), visa observar o uso do modelo de referncia MR.GC-PARFAIT, na reengenharia de um sistema legado, utilizando o processo PARFAIT, a fim de analisar se tal modelo no afeta a agilidade do processo e se apia efetivamente o controle de verses do framework, utilizado como apoio computacional, e do sistema alvo gerado por tal framework, mantendo a integridade dos mesmos. A fase do planejamento tem como objetivo identificar o que deve ser observado do MR.GC-PARFAIT, estabelecer as hipteses para analisar o modelo de referncia proposto e a sua aplicabilidade na reengenharia gil de software.

6.2.1 Definio

Objeto de estudo: Modelo de referncia da atividade de GC do PARFAIT (MR.GC-PARFAIT).

90

Objetivo: Conduzir um estudo de caso no contexto de reengenharia gil de software para analisar o emprego do MR.GC-PARFAIT sem afetar a agilidade do processo PARFAIT.

Foco qualitativo: Produo da documentao de GC necessria sem afetar a agilidade do PARFAIT e controle de verso do framework e das verses do sistema alvo visando manter a integridade dos mesmos.

Perspectiva: A perspectiva do estudo de caso baseia-se na utilizao do MR.GC-PARFAIT.

Contexto: O estudo de caso ser conduzido pela prpria autora do modelo de referncia. O material necessrio para o estudo consiste em: documentao da abordagem ARTe (CAGNIN et al., 2004) que apia na atividade de teste, da LPA GRN (BRAGA, 2002a) que auxilia no entendimento do sistema legado e na documentao na anlise orientada a objeto; dos requisitos de teste dos padres da LPA GRN (CHAN; CAGNIN, 2004) que apia o reso na atividade de teste e na criao de casos de teste genricos; do framework GREN (BRAGA, 2003) que apia na gerao automtica do sistema alvo por meio da ferramenta de instanciao GREN-Wizard (BRAGA, 2002b; 2002c); da ferramenta de controle de verses GREN-WizardVersion Control (CAGNIN, 2004b) que apia no controle das verses do sistema alvo; manuais do SGBD MySQL(2007)12 que apia no entendimento do banco de dados do framework, da linguagem de programao Smalltalk que possibilita as adaptaes no sistema alvo, do modelo de referncia da atividade de GC que apia a atividade de GC e da ferramenta Subversion que apia o controle de verso dos itens de configurao. O estudo de caso baseia-se na reengenharia de um sistema legado de biblioteca universitria, que controla o emprstimo e a devoluo de livros, foi desenvolvido em Clipper e possui aproximadamente 6 KLOC.

12

http://dev.mysql.com/doc/refman/4.1/pt/

91

6.2.2

Planejamento

Seleo do Contexto: Para a execuo do estudo de caso foi elaborado um formulrio para anotar o tempo gasto na execuo de cada atividade do processo de reengenharia PARFAIT e do modelo de referncia. A autora do modelo de referncia possui algum conhecimento na utilizao dos recursos e ferramentas necessrios para a conduo do estudo, contudo receber um treinamento antes de executar essa tarefa. Esse estudo ser realizado no contexto especfico do domnio de Engenharia de Software. Formulao das hipteses: Nulas:

1. A documentao de GC elaborada pela aplicao do MR.GC-PARFAIT no afeta a agilidade do PARFAIT. 2. A integridade do framework e do sistema alvo garantida pelo controle de verses do MR.GC-PARFAIT. Alternativas:

1. A documentao de GC elaborada pela aplicao do MR.GC-PARFAIT afeta a agilidade do PARFAIT. 2. A integridade do framework e do sistema alvo no garantida pelo controle de verses do MR.GC-PARFAIT.

Seleo das variveis:

Variveis independentes (variveis de entrada): o conhecimento emprico adquirido pela participante referente aos recursos necessrios para a realizao do estudo de caso (uso do framework GREN, da linguagem de padres GRN, da ferramenta de instanciao GREN-Wizard e da ferramenta de controle de verses GREN-

92

WizardVersionControl, do SGBD MySQL, da linguagem de programao Smalltalk, dos critrios de teste funcional Particionamento de Equivalncia e Anlise do Valor Limite, da abordagem ARTe, do MR.GC-PARFAIT, da ferramenta Subversion e do domnio de softwares de locao) ajuda no desempenho e no uso do processo e do modelo de referncia. Variveis dependentes (variveis de sada ou resposta): formulrio de tempo gasto no estudo de caso em cada atividade do PARFAIT e em cada atividade de GC do MR.GC-PARFAIT.

Seleo dos indivduos: A tcnica de amostragem empregada neste estudo de caso a por convenincia efetuada pela prpria autora do modelo.

Projeto do estudo de caso: O estudo de caso definido como um objeto nico, por se tratar de apenas um nico participante e de um nico estudo de caso.

Instrumentao: Para realizar o estudo de caso necessita-se que a participante possua conhecimento: na documentao do modelo de referncia MR.GC-PARFAIT; na documentao da LPA GRN e do framework GREN, manual da linguagem de programao Smalltalk; na documentao da abordagem ARTe; na documentao dos requisitos de teste da LPA GRN; nos critrios de teste funcionais Particionamento de Equivalncia e Anlise do Valor Limite, da ferramenta de instanciao GREN-Wizard, da ferramenta para controle de verses GRENWizardVersionControl e da ferramenta Subversion.

Avaliao da validade: A avaliao dos resultados obtidos apresenta ameaas referentes: validade de concluso, pois depende do conhecimento emprico adquirido pelo engenheiro de software nos recursos necessrios para realizar o estudo de caso; validade interna que est relacionada experincia da prpria autora do MR.GC-PARFAIT em utiliz-lo com certa facilidade, aumentando o desempenho do estudo de caso; validade de construo, sendo necessria a conduo de outros estudos de casos com grau de complexidade maior e realizados por outros profissionais visando observar a dificuldade e benefcios alcanados; e validade externa que apresenta-se em adaptar este modelo de referncia para outros processos de reengenharia baseados em framework.

93

6.3 Operao

Execuo: O estudo de caso foi realizado em duas etapas. Na primeira etapa estabeleceu-se a comparao do domnio do sistema legado com o do framework disponvel, sendo constatada a viabilidade em realizar o projeto de reengenharia. Na segunda etapa, o projeto de reengenharia foi dividido em trs iteraes. Na primeira iterao os casos de teste para apoiar a execuo do sistema legado foram criados a partir da documentao disponvel dos requisitos de teste dos padres da GRN. Para reduzir ainda mais o tempo de VV&T com a utilizao da abordagem ARTe, a criao dos casos de teste foi efetuada de maneira genrica, conforme descrito na Seo 6.3.1. Em seguida, foram utilizados os padres 1 e 2 da LPA GRN (padres Identificar o Recurso e Quantificar o Recurso, respectivamente) para documentar as funcionalidades do sistema alvo, priorizadas para a primeira iterao, que tratam dos seguintes cadastros: Livro, Editora, Assunto, rea, Autor e Exemplar. Posteriormente, dando prosseguimento execuo das atividades do PARFAIT, o framework GREN foi instanciado e a primeira verso do sistema alvo foi gerada e submetida aos testes funcionais, criados anteriormente, e ao teste de aceitao em conjunto com o usurio do sistema legado. Foram efetuadas adaptaes na interface GUI (Graphical User Interface) desta primeira verso do sistema alvo, relacionadas ao dimensionamento das telas e alterao dos nomes de alguns campos a fim de adequ-los funcionalmente ao sistema legado. A ferramenta GREN-WizardVersion Control foi utilizada para armazenar as adaptaes realizadas nesta primeira iterao. As atividades de GC foram executadas em todas as iteraes do processo PARFAIT de acordo com o modelo de referncia MR.GC-PARFAIT, sendo o controle de verso apoiado pela ferramenta Subversion. Ressalta-se que, durante o uso do MR.GC-PARFAIT na primeira iterao, observou-se necessidade de acrescentar o diagrama de casos de uso para ser submetido GC, pois no havia sido considerado na concepo do modelo de referncia. O estudo de caso foi conduzido sem horrios contnuos. Na Tabela 1 apresenta-se a relao da seqncia das atividades executadas em cada iterao do projeto de reengenharia, a estimativa de tempo de cada atividade foi baseada em um estudo de caso de reengenharia j conduzido com o apoio da abordagem ARTe e sem o uso do MR.GC-PARFAIT (CAGNIN, 2005a), e o tempo realmente gasto em cada iterao neste estudo de caso. Como no estudo de caso relatado em Cagnin

94

(2005a), a atividade do PARFAIT que trata da criao do manual do usurio tambm no foi efetuada.

Tabela 1 - Tempo gasto em cada iterao das atividades do PARFAIT e do MR.GC-PARFAIT

Tempo gasto em horas/minutos por cada atividade Seqncia das atividades Atividades 1 5 6 7 8 9 10 11 12 3 4 1 2 13 14 15 16 18 19 17 20 21 22 23 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 2 3 3 4 5 6 7 8 -1 2 9 10 11 12 13 14 15 16 17 18 Observar o domnio do sistema legado em relao ao do framework Definir a ferramenta de apoio Criar um repositrio Gerenciar as Verses Confrontar as caractersticas no funcionais do framework x sistema legado Gerenciar as Verses Elaborar o Planejamento do Projeto de reengenharia Gerenciar as Verses Desenvolver o diagrama de casos de uso e elaborar os casos de teste Gerenciar as Verses Desenvolver o diagrama de classes do sistema alvo Gerenciar as Verses Documentar as modificaes realizadas no diagrama de classes Gerenciar as Verses Documentar as regras de negcio do sistema Gerenciar as Verses Criar o sistema alvo no paradigma OO Gerenciar as mudanas Gerenciar as Verses Executar os casos de teste no sistema alvo Gerenciar as Verses Adaptar o sistema alvo Gerenciar as mudanas Gerenciar as Verses Testar o sistema alvo Gerenciar as Verses TOTAL DE TEMPO TOTAL DE TEMPO GASTO COM O MR.GC-PARFAIT 1 Iterao T. Estimado 02:00 00:20 00:20 00:30 00:20 00:30 00:15 00:30 30:00 00:30 08:00 00:30 01:20 00:30 00:20 00:30 03:00 00:30 03:00 00:30 00:30 01:30 00:30 53:55 T. Gasto 02:10 00:30 00:45 00:05 00:20 00:05 00:25 00:05 25:20 00:05 04:00 00:05 00:30 00:05 00:30 00:10 02:00 00:05 02:00 00:10 00:15 00:45 00:05 40:20 02:30 2 Iterao T. Estimado 01:00 00:30 00:20 00:30 00:15 00:30 98:00 00:30 06:00 00:30 01:00 00:30 00:30 00:30 00:30 04:00 00:30 07:00 00:30 00:30 02:00 00:30 127:35 T. Gasto 33:45 00:05 03:10 00:05 00:27 00:05 00:20 00:10 00:20 01:40 00:10 03:55 00:20 00:30 00:55 00:05 46:07 01:45 3 Iterao T. Estimado 01:00 00:30 00:20 00:30 00:15 00:30 126:00 00:30 4:00 00:30 01:00 00:30 1:30 00:30 00:45 00:30 00:30 1:30 00:30 08:00 00:30 00:30 01:30 00:30 151:50 T. Gasto 10:25 00:05 02:40 00:05 00:10 00:05 00:10 00:10 00:20 00:10 00:05 00:30 01:00 00:10 00:10 01:00 00:10 17:15 1:10

95

O tempo total gasto na primeira iterao foi de 40h20, das quais 02h30 foram gastas na execuo das atividades de GC; 15h55 foram gastas na documentao do sistema alvo (atividades Observar o domnio do sistema legado em relao ao do framework, Elaborar o planejamento do projeto de reengenharia, Desenvolver o diagrama de casos de uso e elaborar os casos de teste13, Desenvolver o diagrama de classes do sistema alvo, Documentar as modificaes realizadas no diagrama de classes e Adaptar o sistema alvo); e 21h05 foram gastas nas atividades de VV&T (atividades Desenvolver o diagrama de casos de uso e elaborar os casos de teste14, Executar os casos de teste no sistema alvo e Testar o sistema alvo). Na segunda iterao foi utilizado o padro 4 da LPA GRN (padro Alocar Recurso), documentando assim os cadastros de Aluno e de Curso, bem como o Emprstimo de Livros. Para implementar esses requisitos uma nova instanciao do framework GREN foi efetuada, obtendo-se uma outra verso do sistema alvo. Nesta segunda iterao, durante a demonstrao do sistema alvo para o usurio, foi solicitada a implementao de duas regras de negcio que no estavam presentes no sistema legado. A primeira trata do perodo de devoluo do livro (sete dias para professores e trs dias para os demais leitores) e a segunda trata da cobrana de taxa de multa de R$ 1,00 para cada dia de atraso na devoluo do livro. O tempo gasto na segunda iterao foi de 46h07 (Tabela 1), das quais 01h45 foram gastas na execuo das atividades de GC; 11h17 foram despendidas na documentao do sistema alvo (atividades Desenvolver o diagrama de casos de uso e elaborar os casos de teste, Desenvolver o diagrama de classes do sistema alvo, Documentar as modificaes realizadas no diagrama de classes e Adaptar o sistema alvo); e 32h35 nas atividades de VV&T (atividades Desenvolver o diagrama de casos de uso e elaborar os casos de teste, Executar os casos de teste no sistema alvo e Testar o sistema alvo). Na terceira iterao foram criados os relatrios pertinentes ao sistema alvo, os quais foram herdados do framework, e foi implementada apenas a regra de negcio referente taxa de multa, tambm herdada do framework. Entretanto, a outra regra no foi incorporada ao sistema alvo devido falta de tempo. Ressalta-se que essa deciso tomada no prejudicar os resultados deste estudo de caso, pois, considerando o tempo gasto para implementar tal regra no outro estudo de caso (CAGNIN, 2005a), que foi de 05h40, seria gasto neste estudo de caso apenas 5,46% a mais do

13 14

O tempo para a elaborao dos casos de teste no foi considerado. O tempo para desenvolver o diagrama de caso de uso no foi considerado.

96

tempo total gasto na reengenharia (103h42 + 05h40), como est apresentado no anterior estudo de caso, no prejudicando dessa forma os resultados obtidos. Salienta-se que tais resultados sero utilizados para analisar, especialmente, o impacto do uso do modelo proposto neste trabalho sem afetar a agilidade do PARFAIT. O tempo total gasto na terceira iterao foi de 17h15, sendo que 01h10 foi o tempo gasto com a aplicao do MR.GC-PARFAIT.

6.3.1 Criao dos Casos de Teste Genricos

Durante a aplicao das diretrizes da abordagem ARTe para o reso dos requisitos de teste disponveis, observou-se a necessidade de aprimor-la para proporcionar um melhor desempenho na sua execuo, no intuito de reduzir ainda mais o tempo de VV&T. Para isso, foram criados casos de teste genricos a partir dos requisitos de teste disponveis nos padres 1, 2 e 4 da LPA GRN, utilizados no estudo de caso, conforme apresentado na Tabela 2. No caso do atributo descrio, que consta no padro 1, foram criados casos de teste genricos para diferentes tamanhos de descries. Adicionalmente, foram elaboradas classes de equivalncia para os tipos de dados especiais do GREN (lista a partir de uma classe15, lista discreta16 e lista multivalorada17) (BRAGA, 2002c). Exemplificando as classes de equivalncia vlidas criadas, tem-se que um atributo do tipo de dado especial lista multivalorada pode ter mais do que um valor no duplicado, conforme apresentado na Tabela 3. Requisitos de teste foram criados a partir das classes de equivalncia elaboradas e esto disponveis para serem reutilizados (Tabela 2).

15 16 17

O valor do atributo do tipo lista a partir de uma classe proveniente de um objeto de outra classe. O valor do atributo do tipo lista discreta proveniente de uma lista de valores pr-definidos. Os valores do atributo do tipo lista multivalorada so provenientes de objetos de outra classe.

97

Tabela 2 Casos de testes gerais

Id. Requisito de teste Casos ARTe teste CT13 RT30 CT14 RT30/RT266/RT267 CT15 RT30 CT16 RT30 CT17 RT30 CT68 RT2007 ... CT69 CT70 CT71 CT72 CT73 CT76 CT77 ... RT2008 RT2009 RT2002 RT2000 Lista Multivalorada RT2001 Lista Multivalorada RT2005 RT2006 Lista Discreta Lista Discreta Valor A + Valor B Valor A Vazio Dados de entrada Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Lista a partir de uma classe ... Lista a partir de uma classe Lista a partir de uma classe Lista Multivalorada AA AA AA AA AA Valor A ... Valor B Vazio Vazio Valor A Sada esperada Sucesso: <= 60 caracteres Sucesso:< = 40 caracteres Sucesso: <= 30 caracteres Sucesso: <= 25 caracteres Sucesso: <= 20 caracteres Sucesso na verificao: permite continuar com a ao ... Erro: valor no cadastrado Erro Erro: no permitido continuar com a ao Sucesso na verificao: permite continuar com a ao Sucesso na verificao: permite continuar com a ao Sucesso na verificao: permite continuar com a ao Erro

A Tabela 4 contm: o tipo de dado especial; o nmero da classe de equivalncia base para a criao do requisito de teste (Tabela 3); a especificao do requisito de teste; a condio verificada por esse requisito de teste; e o retorno esperado. Exemplificando, o requisito de teste 2001 refere-se insero e alterao de atributos do tipo lista multivalorada e tem como especificao atribuir dois ou mais valores distintos ao atributo para que a insero ou a alterao seja efetuada com sucesso. Posteriormente, para reduzir o tempo futuro de criao de casos de teste, foram elaborados tambm casos de teste genricos a partir dos requisitos de teste criados para os tipos especiais do GREN, conforme ilustrados na Tabela 4 (a partir da linha 6).

Tabela 3 - Classes de equivalncia criadas para os tipos de dados especiais do GREN

Tipo de dado especial Lista Multivalorada Lista Discreta Lista a partir de uma Classe Classes Vlidas quantidade de valores >= 1 (1166) Valores no duplicados (1168) quantidade de valor = 1 (1170) quantidade de valor = 1 (1173) idCode cadastrado (1175) Classes Invlidas quantidade de valores = 0 (1167) valores duplicados (1169) quantidade de valor > 1 (1171) quantidade de valor = 0 (1172) quantidade de valor = 0 (1174) idCode no cadastrado (1176)

98

Tabela 4 Requisitos de teste criados para os tipos de dados especiais do GREN

Cd. do Req. Teste Tipo de dado especial Classes de Equivalncia Utilizadas Especificao do Requisito de Teste Condio Verificada Retorno Esperado

Lista RT 2000 Multivalorada Lista RT 2001 Multivalorada Lista RT 2002 Multivalorada RT 2003 RT 2004 Lista Discreta Lista Discreta Lista a partir de uma classe Lista a partir de uma classe

1166, 1168

1169 1167 1170, 1171 1172 1173, 1175

Atributo = valor determinar 1 valor A determinar 2 ou mais valores Atributo = valor diferentes A e valor B sem valores determinar 1 valor "Vazio" determinar 1 IdCode j cadastrado determinar 1 IdCode no cadastrado "Vazio" valor A "Vazio" Valor 1

Sucesso na verificao, permitindo continuar com a ao Sucesso na verificao, permitindo continuar com a ao Erro: falha na verificao, no permitindo continuar com a ao Sucesso na verificao, permitindo continuar com a ao Erro: falha na verificao, no permitindo continuar com a ao Sucesso na verificao, permitindo continuar com a ao Sucesso na verificao, permitindo continuar com a ao

RT 2005 RT 2006

1174

Valor 3

6.3.2 Anlise e Interpretao dos Resultados

O estudo da LPA GRN e a documentao do framework GREN auxiliaram na conduo do estudo de caso, pois fornecem diversos exemplos prticos que facilitaram o uso dessas tcnicas no projeto de reengenharia. O tempo gasto no estudo de caso apresentado por Cagnin (2005a) que utilizou o PARFAIT sem o modelo de referncia proposto neste trabalho foi de 328h40. J no estudo de caso de reengenharia, conduzido neste trabalho utilizando o PARFAIT e o MR.GC-PARFAIT, o tempo gasto foi de 103h42, perfazendo uma reduo de 68,5%. Essa reduo de tempo da reengenharia justificada principalmente pela criao de casos de teste genricos, considerando um aperfeioamento da abordagem ARTe, uma vez que houve reduo de 71,5% de tempo nas atividades do PARFAIT relacionadas VV&T, conforme apresentado na segunda linha da Tabela 5. O tempo total gasto com as atividades do MR.GCPARFAIT foi de 05h25, representando apenas 5,07% do tempo total da reengenharia. O valor desse percentual considerado baixo em relao aos benefcios obtidos com o uso do modelo de referncia.

99

Tabela 5 - Comparao do tempo gasto no estudo de caso

Tempo da reengenharia das atividades VV&T das atividades de GC Estudo de caso sem o MR.GC-PARFAIT e sem os casos de teste genricos 328h40 267h30 Estudo de caso com o MR.GC-PARFAIT e com os casos de teste genricos 103h42 76h20

68,5% 71,5%
05h25

A partir dos dados coletados durante a conduo do estudo de caso, foi possvel responder as hipteses nulas identificadas durante o planejamento do estudo de caso. No Quadro 33 apresentase cada uma das respostas e uma breve justificativa.
Respostas das hipteses nulas 1. A documentao de GC elaborada pela aplicao do MR.GC-PARFAIT no afeta a agilidade do PARFAIT? Resultado: Sim. A documentao de GC elaborada no afeta a agilidade do PARFAIT, tanto do ponto de vista das prticas de modelagem gil tratadas pelo PARFAIT quanto do tempo gasto para elabor-la. A documentao do MR.GC-PARFAIT se apresentou simples, clara e de fcil aplicao. Justificativa: O tempo gasto com o modelo MR.GC-PARFAIT correspondeu a apenas 5,07% (05h25) de todo tempo gasto no projeto de reengenharia (103h42). 2. A integridade do framework e do sistema alvo garantida pelo controle de verses do MR.GC-PARFAIT? Resultado: Sim. A integridade tanto do framework quanto do sistema alvo foi garantida com o emprego do controle de verses e de mudanas do MR.GC-PARFAIT. Justificativa: Por meio do controle de verso e de mudanas tanto do framework quanto do sistema alvo manteve-se a integridade dos mesmos com o emprego dos gabaritos pertencentes ao modelo.

Quadro 33 - Dados coletados durante o estudo de caso

6.3.3 Discusso

Alm da anlise quantitativa dos resultados obtidos com o estudo de caso conduzido apresentada na Tabela 1 e na Tabela 5, foram coletadas tambm informaes relacionadas experincia e ao uso das tcnicas e ferramentas utilizadas durante o estudo de caso com a autora do modelo (participante do estudo de caso). Foram relatadas algumas dificuldades no aprendizado de LPA GRN, alm da elaborao da documentao durante a execuo de cada atividade do PARFAIT.

100

Observou-se, alm disso, a necessidade de adaptar a abordagem ARTe para permitir tambm o reso de casos de teste, pois o tempo gasto para a criao dos testes com o apoio dessa abordagem ainda era relativamente significativo (em torno de 68% do tempo total gasto na reengenharia) e o entendimento da sua documentao para a criao dos casos de teste era de certa forma difcil. A criao de casos de teste genricos possibilitou uma considervel reduo de tempo, conforme relatado na seo anterior, e uma maior flexibilidade nos casos de teste desenvolvidos. Entre os pontos favorveis destacam-se o emprego do framework GREN em conjunto com a GRN que permitiram a criao de verses do sistema alvo o mais rpido possvel, o uso do PARFAIT e da abordagem ARTe que otimizaram, de maneira considervel, o projeto de reengenharia. Deve ser levado em considerao que os frozen spots impostos pelo framework fizeram com que diversas informaes pertencentes ao domnio, mas no ao sistema legado, tivessem que ser consideradas no sistema alvo. Destaca-se, ainda, que o MR.GC-PARFAIT apresentou-se eficaz no que foi proposto, uma vez que gasto-se pouco tempo para aplic-lo quando comparado aos benefcios providos por ele, como o caso do controle de mudanas e de verses tanto do framework quanto do sistema alvo. Para observar a eficincia do MR.GC-PARFAIT necessrio efetuar a conduo de um outro estudo de caso com um participante que no tenha sido influenciado pela sua definio, o que ocorreu com o estudo de caso conduzido neste trabalho. Ressalta-se, igualmente, que apesar da ferramenta de controle de verso Subversion no possuir uma opo especfica para controlar as verses do framework, foi adaptada uma seqncia de pastas dentro do repositrio que possibilitou tal procedimento. Exemplificando, na Figura 8 apresenta-se a criao das pastas para o armazenamento da verso 13 (im 13) do framework GREN, bem como das verses dos sistemas gerados, como o caso do BibNew, que possui a base de dados, o cdigo fonte, os diagramas e a documentao pertencente ao projeto de reengenharia.

Figura 8 Esquema do repositrio

101

6.4 Consideraes finais

Neste captulo apresentou-se, com detalhes, a execuo de um estudo de caso de reengenharia, planejado de acordo com Wholin et al. (2000), utilizando o processo PARFAIT e o modelo de referncia MR.GC-PARFAIT. Alguns dos resultados quantitativos obtidos mostraram que o tempo de aplicabilidade do MR.GC-PARFAIT em conjunto com o PARFAIT relativamente baixo, no interferindo significativamente no tempo total da reengenharia. Alm disso, possvel recuperar, em qualquer momento da reengenharia, uma determinada verso do sistema alvo e da verso correspondente do framework utilizada para apoiar na criao de tal sistema, bem como aceitar ou no solicitaes de mudanas tanto no framework quanto no sistema alvo. Assim, vlido afirmar que o modelo proposto minimiza a problemtica existente de GC durante a reengenharia baseada em framework. Ressalta-se que a abordagem de teste ARTe foi aprimorada neste estudo de caso, possibilitando um melhor desempenho durante o seu uso, considerando a reduo de tempo com o reso dos casos de teste genricos criados neste trabalho. A concluso, as limitaes do trabalho e as sugestes de trabalhos futuros so apresentadas no prximo captulo.

CONCLUSES

Neste trabalho foi definido o modelo de referncia MR.GC-PARFAIT (Captulo 5) com base nas diretrizes de GC de algumas normas e modelos de maturidade. Esse modelo tem como objetivo incorporar sistematicamente a GC no processo gil de reengenharia PARFAIT, fornecendo documentao bsica das atividades essenciais de GC que devem ser executadas em projetos de reengenharia com o apoio desse processo. Mais especificamente, o modelo de referncia fornece: uma descrio dos passos de cada atividade; os artefatos que devem ser elaborados e o modo de elaborao (gabaritos); o apoio computacional que pode ser utilizado para apoiar cada atividade; e em quais atividades do PARFAIT cada atividade do modelo deve ser executada. Para avaliar o MR.GC-PARFAIT, foi conduzido um estudo de caso planejado de reengenharia de um sistema legado (Captulo 6), utilizando-se o processo PARFAIT e o framework GREN como apoio computacional. A partir da interpretao dos resultados obtidos nesse estudo de caso, observou-se que pouco tempo foi gasto com a aplicao do MR.GC-PARFAIT comparado aos benefcios obtidos com o mesmo, ou seja, apenas 5,07% do tempo total da reengenharia foi gasto para a execuo das atividades de GC do modelo de referncia. Outra contribuio importante deste trabalho est relacionada definio dos gabaritos que devem ser elaborados durante a execuo das atividades de GC do modelo MR.GC-PARFAIT. Adicionalmente, este trabalho contribuiu para a adaptao da abordagem de teste ARTe com relao criao de casos de testes genricos, baseados nos requisitos de teste disponveis dos padres da LPA GRN. A partir do reso dos casos de teste genricos durante o estudo de caso conduzido observou-se que houve reduo significativa no tempo das atividades de VV&T do PARFAIT, ou seja, aproximadamente 71,5%. Ressalta-se ainda que o MR.GC-PARFAIT trata de dez dos quatorze objetivos de GC considerados pelo modelo de referncia MR-MPS. Tal modelo foi desenvolvido pela Softex cuja finalidade adaptar normas e modelos de maturidade existentes na literatura realidade das pequenas e mdias empresas de desenvolvimento de software brasileiras. Os demais objetivos no so considerados pelo modelo MR.GC-PARFAIT, pois prejudicariam a agilidade do processo PARFAIT. Os objetivos do MR.MPS que so tambm tratados pelo MR.GC-PARFAIT encontramse elencados a seguir: selecionar os artefatos com o emprego de critrios documentados; identificar, armazenar, testar, revisar, alterar, definir, manter os artefatos e submet-los

103

baseline; instruir uma poltica de GC que controle os diferentes nveis, que possua um armazenamento dos artefatos para posteriormente serem recuperados, bem como uma solicitao de mudanas; preservar todos os artefatos de GC; autorizar a criao ou a liberao das baselines pela GC; controlar as modificaes e as liberaes dos artefatos; disponibilizar as modificaes e liberaes dos artefatos; adicionar os artefatos no repositrio, j aprovados e devidamente controlados; assegurar a consistncia e a completeza dos artefatos; e controlar o armazenamento, o manuseio e a liberao dos artefatos.

7.1 Limitaes

Uma das limitaes deste trabalho refere-se ao fato de que o modelo MR.GC-PARFAIT especfico para o processo PARFAIT. Mas isso no impede que tal modelo seja adaptado a outros processos ou generalizado para qualquer processo de reengenharia baseado em framework. Com relao s hipteses nulas levantadas no planejamento do estudo de caso conduzido, as mesmas avaliam apenas alguns aspectos do modelo MR.GC-PARFAIT, como o caso do controle de verso do framework e do sistema alvo, da permanncia da agilidade do PARFAIT, bem como da integridade dos artefatos produzidos. Entretanto, interessante observar outros aspectos do modelo de referncia a fim de confirmar a sua viabilidade. Ressalta-se que o estudo de caso foi conduzido em ambiente acadmico, pela prpria autora do modelo e utilizou um sistema legado de pequeno porte. Tudo isso pode ter influenciado nos resultados obtidos. Assim, sugere-se a conduo de outros estudos de caso com outros participantes e em ambiente industrial.

7.2 Sugestes de Trabalhos Futuros

Para dar continuidade ao trabalho realizado, so sugeridos os seguintes trabalhos futuros: Conduzir um estudo de caso planejado de reengenharia objetivando analisar a eficincia e eficcia do MR.GC-PARFAIT em um ambiente industrial.

104

Conduzir estudos de caso planejados de reengenharia de sistemas legados de pequeno e mdio porte para verificar se os resultados observados no estudo de caso conduzido neste trabalho relacionados ao MR.GC-PARFAIT e a criao dos casos de teste genricos so mantidos. Adaptar o MR.GC-PARFAIT para atender a outros processos baseados em framework, tanto no contexto de desenvolvimento quanto no de reengenharia. Definir um meta-modelo para armazenar as informaes relevantes do controle de GC do modelo de referncia proposto para apoiar o desenvolvimento de uma ferramenta especfica de automatizao do uso de tal modelo; Desenvolver uma ferramenta que apie o controle de verso e de mudanas, tanto do framework quanto das verses geradas do sistema alvo.

REFERNCIAS AMBLER, S.W. Modelagem gil: Prticas eficazes para a Programao eXtrema e o Processo Unificado. Porto Alegre: Bookman, 2004.

ANSI/IEEE Std-828, 1998, IEEE Standard for Software Configuration Management Plans.

APPLETON, B. Patterns and software: Essential concepts and terminology. 1997. Disponvel em: <http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html>. Acesso em: Janeiro/2006

ARIMOTO, M. M.; CAMARGO, V.V.; CAGNIN, M. I. Uma Ferramenta de Controle de Verses de Frameworks. In: CLEI - LATIN-AMERICAN CONFERENCE OF INFORMATICS. Proceedings So Jos, Costa Rica, 2007. [aceito para publicao].

ASKLUND, U.; MAGNUSSON, B. Fine Grained Version Control of Configuration in COOP/Orm. In: SCM - SYMPOSIUM ON CONFIGURATION MANAGEMENT. Proceedings Disponvel em: <http://citeseer.nj.nec.com/magnusson 96fine.html>. Acesso em: 10/02/2006.

BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. Goal Question Metric paradigm. In: ENCYCLOPEDIA of Software Engineering. John Wiley & Sons, 1994.

BERSOFF, E. H. Elements of Software Configuration Management. IEEE Trans SE, V10, N1, 1984.

BRAGA, R. T. V; GERMANO, F. S. R.; MASIERO, C. M. GRN: Uma Linguagem de Padres para Gesto de Recursos de Negcio, documentao da LPA GRN, ICMC - Universidade de So Paulo, 2002a.

BRAGA, R. T. V. GREN-WIZARD User Guide, verso 1.0, documentao do Framework GREN, 2002b

BRAGA, R. T. V. Manual de Instanciao do Framework GREN, verso 2.0, ferramenta de instanciao GREN-Wizard, 2002c

BRAGA, R. T. V.; MASIERO, P. C. GREN-Wizard: A Tool to Instantiate the GREN Framework. In: SIMPSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, XVI. Gramado-RS. Sesso de Ferramentas do SBES - Caderno de Ferramentas - Anais do SBES. Gramado-RS, p. 408-413, 2002d.

106

BRAGA, T. V. Um Processo para Construo e Instanciao de Frameworks baseados em uma linguagem de Padres para um Domnio Especfico. Tese (Doutorado em Computao) Instituto de Cincias Matemticas e de Computao, Universidade de So Paulo, So Carlos, SP, 2003.

BOOCH, G., RUMBAUGH, J., JACOBSON, I. UML: Guia do Usurio, O mais avanado tutorial sobre Unified Modeling Language. Rio de Janeiro: Campus, 2000.

BORLAND, I. N. C. Borland Delphi for Windows 95/NT. Version 5.0: Object pascal language guide. Scotts Valley, CA: Borland, 2000. BRUCKER, A. D.; RITTINGER, F.; WOLFF, B. The CVS-Server Case Study, FM-TOOLS, Augsburg, 2002. Disponvel em: <http://www.brucker.ch/bibliography/download/2002/fmtools_ CVS_02.pdf>. Acesso em: 20/02/2006.

CAGNIN, M. I. PARFAIT: uma contribuio para a reengenharia de software baseada em linguagem de padres e Framework. Tese (Doutorado em Cincias de Computao e Matemtica Computacional) - Instituto de Cincias Matemticas e de Computao, Universidade de So Paulo, So Carlos, 2005a.

CAGNIN, M. I.; MALDONADO, J. C.; MASIERO, P. C.; PENTEADO, R. D.; BRAGA, R. T. An Evolution Process for Application Framework. In: WMSWM - WORKSHOP DE MANUTENO MODERNA DE SOFTWARE, I. Em conjunto com o XVIII Simpsio Brasileiro de Engenharia de Software. Anais... Braslia, DF, CD-ROM, 8 p. 2004a.

CAGNIN, M. I.; MALDONADO, J. C.; CHAN, A.; PENTEADO, R. D.; GERMANO, F. S. Reso na Atividade de Teste para Reduzir Custo e Esforo de VV&T no Desenvolvimento e na Reengenharia de Software. In: SBES - SIMPSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, XVIII. Anais... Braslia, DF, p. 71-85, 2004b.

CAGNIN, M. I.; MALDONADO, J. C.; GERMANO, F. S.; PENTEADO, R. D. PARFAIT: Towards a Framework-based agile reengineering process. In: ADC'2003 - AGILE DEVELOPMENT CONFERENCE. Proceedings Salt Lake City, UTHA, USA: IEEE, p. 22-31, 2003a.

CAGNIN, M. I.; MALDONADO, J. C.; GERMANO, F. S.; CHAN, A.; PENTEADO, R. D. Um Estudo de Caso de Reengenharia usando o Processo PARFAIT. In: SDMS'2003 - SIMPSIO

107

DE DESENVOLVIMENTO E MANUTENO DE SOFTWARE DA MARINHA. Anais... Rio de Janeiro, RF, CD-ROM, 2003b.

CAGNIN, M. I.; MALDONADO, J. C.; GERMANO, F. S.; PENTEADO, R. D.; BRAGA, R. T. GREN-WizardVersionControl: Uma Ferramenta de Apoio ao Controle de Verso das Aplicaes Criadas pelo Framework GREN. In: SIMPSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, XVIII. Sesso de Ferramentas'2004. Anais... Braslia, DF, CD-ROM, p. 74-78, 2004c.

CAGNIN, M. I.; MALDONADO, J. C. Documentao do PARFAIT: Um Processo gil de Reengenharia baseado em Framework. Documentao do PARFAIT do Instituto de Cincias Matemticas e de Computao ICMC/USP, So Carlos, 2005b.

CHAN, A.; CAGNIN, M. I. Documentao dos Requisitos de Teste dos Padres da Linguagem de Padro de Anlise GRN. Documento de trabalho, ICMC-USP - Instituto de Cincias Matemticas e de Computao, Universidade de So Paulo, 2004.

CHIKOFSKY, E. J.; CROSS II, J. H. Reverse engineering and design recovery: A taxonomy. IEEE Software, 7(1):1317, 1990.

COLLINS-SUSSMAN, B.; FITZPATRICK, B. W.; PILATO, C. M. Version Control with Subversion, para Subversion 1.2. 2006. Disponvel em: <http://svnbook.red-bean.com/nightly/ pt_BR/svn-book.html>. Acesso em: 15/02/2006.

CUNHA, J. R. D.; PRADO, A. F.; SANTOS, A. C.; SOUZA NETO, R. M. Uma abordagem para o Processo de Gerenciamento de Configurao de Software. RESI Revista eletrnica de Sistema de Informao, Universidade Federal de So Carlos, So Carlos-SP, 2004. Disponvel em: <http://www.presidentekennedy.br/resi/edicao04/artigo05.pdf>. Acesso em: 20/12/2005.

ESPINDOLA, R. S.; LOPES, L.; PRIKLADNICKI, R.; AUDY, J. L. N. Uma Abordagem baseada em Gesto do Conhecimento para Gerncia de Requisitos em Desenvolvimento Distribudo de Software. In: WER05 - WORKSHOP EM ENGENHARIA DE REQUISITOS. Anais Portugal, p. 87-99, 2005.

FAYAD, M. E..; SCHMIDT, D.; JOHNSON, R. Building Application Framework: ObjectOriented Foundations of Framework Design. First ed. John Wiley & Sons, September 1999.

108

FERREIRA, M. A. O.; CAGNIN, M. I. Proposta de um Modelo de Referncia de Gerncia de Configurao para um Processo de Reengenharia baseado em Framework. In: SBSI SIMPSIO BRASILEIRO DE SISTEMA DE INFORMAO. Anais... Curitiba, CD-ROM, 2006.

FERREIRA, M. A. O.; CAGNIN, M. I. Modelo de Referncia de Gerncia de Configurao para um Processo gil de Reengenharia baseado em Framework. In: SBQS - SIMPSIO BRASILEIRO DE QUALIDADE DE SOFTWARE. Anais... Porto de Galinhas, p. 157-169, 2007.

FIORINI, S. T. Arquitetura para a Reutilizao de Processo de Software. Tese (Doutorado em Informtica) - Pontifcia Universidade Catlica do Rio de Janeiro, Rio de Janeiro, 2001. Disponvel em: <htttp://www-di.inf.puc-rio.br/~julio/tese-soeli.pdf>. Acesso em: 10/02/2006.

FIORINI, S. T.; LEITE, J. C. S. P. Organizando Processos de Requisitos. In: WER98 WORKSHOP EM ENGENHARIA DE REQUISITOS. Anais... Maring, p. 1-8, 1998.

FONTANETTE, V; GARCIA, V. C.; BOSSONARO, A. A.; PEREZ, A. B.; PRADO, A. F. Reengenharia de Software usando Transformaes (RST). In: SECOND IBERO-AMERICAN SYMPOSIUM ON SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING. Anais Salvador, 2002a.

FONTANETTE, V; GARCIA, V. C.; BOSSONARO, A. A.; PEREZ, A. B.; PRADO, A. F. Reengenharia de Sistemas Legados Baseada em Componentes usando Transformaes, In: WORKSHOP CHILENO DE INGENIERA DE SOFTWARE, II. Anais... Chile, 2002b.

FONTANETTE, V; GARCIA, V.C.; BOSSONARO, A. A.; PEREZ, A.B.; PRADO, A. F. Reprojeto de Sistemas Legados Baseada em Componentes de Software, In: CLEI - LATINAMERICAN CONFERENCE OF INFORMATICS. Proceedings... Uruguai, 2002c.

GARCIA, V. C.; FONTANETTE, V.; BOSSONARO, A.; PEREZ, A. B.; PRADO, A. F. DDE Draco Domain Editor. In: SBES - SIMPSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, XVI. Anais... Gramado, p. 378-383, 2002.

HAZAN, C.; LEITE, J. C. S. P. Indicadores para a Gerncia de Requisitos, In: WER03 WORKSHOP EM ENGENHARIA DE REQUISITOS. Anais... Piracicaba, p. 285-301, 2003.

HUMPHREY, W. S.; KITSON, D. H.; GALE, J. A comparison of U.S. and Japanese software process maturity. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 13. Proceedings Austin, Texas, United States, 1991.

109

IEEE, Std 610.12 - IEEE Standard Glossary of Software Engineering Terminology. Institute of Electrical and Electronics Engineers, 1990.

ISO/IEC 10007 Sistemas de Gesto da Qualidade Diretrizes para a Gesto de Configurao. ABNT - Associao Brasileira de Normas Tcnicas. Rio de Janeiro: ABNT, 2005. ISO/IEC 12207 - Tecnologia de Informao - Processos de ciclo de vida de software. ABNT Associao Brasileira de Normas Tcnicas. Rio de Janeiro: ABNT, 1998.

ISO/IEC TR 15504 5: Information Technology Software process assessment Part 5: An assessment model and indicator guidance. ISO/IEC - International Standard Organization and International Electritechnical Commission, 1999.

ISO/IEC 9001 Sistema de Gesto da Qualidade Requisitos. ABNT - Associao Brasileira de Normas Tcnicas. Rio de Janeiro: ABNT, 2000.

ISO/IEC 9004 Sistema de Gesto da Qualidade Diretrizes para a melhoria de desempenho, ABNT - Associao Brasileira de Normas Tcnicas. Rio de Janeiro: ABNT, 2000.

JOMORI, S. M.; VOLPE, R. L. D.; ZABEU, A. C. P. Qualidade de software. Revista TECHOJE, (IETEC - Instituto de Educao Tecnolgica), ano XIII. Disponvel em: <http://www.ietec.com.br/ ietec/techoje/techoje/tecnologiadainformacao/2004/07/01/2004_07_01_0001.2xt/-template_ interna>, 2004. Acesso em: 10/12/2005.

KRAUSE, R. An Introduction to the arch Version Control System. Linux Journal, 2002. Disponvel em: <http://www.linuxjournal.com/article/5928>. Acesso em: 10/02/2006.

KRUCHTEN, P. The Rational Unified Process and Introduction Second Edition. NJ: Addison Wesley Longman, 2000.

LEITE, J. C. S. P.; ROSSI, G; BALAGUER, F.; MAIORANA, V.; KAPLAN, G., HADAD, G.; OLIVEROS, A. Enhancing a Requirements Baseline with Scenarios, Requirements Engineering. London: Springer-Verlag, 1997. Disponvel em: < www-di.inf.puc-rio.br/~julio/Slctpub/baseline. pdf >. Acesso em: 20/12/2005.

LEMOS, G. S.; RECCHIA, E. L.; PENTEADO, R. D.; BRAGA, R. T. V. Padres de Reengenharia Auxiliados por Diretrizes de Qualidade de Software. In: SUGARLOAF PLOP THE SECOND LATIN AMERICAN CONFERENCE ON PATTERN LANGUAGES OF PROGRAMMING. Anais Pernambuco, 25 p., 2003.

110

LIMA, P. S. B.; Proposta de um modelo simplificado de aquisio de software para pequenas empresas. Dissertao (Mestrado em Engenharia de Eletricidade) - Escola Politcnica, Universidade de So Paulo, So Paulo, 2004. Disponvel em: <http://www.pcs.usp.br/~lucia/ teses/PauloLima.pdf>. Acesso em: 20/12/2005.

LOPES, L. G.; MURTA, L.; WERNER, C. Controle de mudanas em Software no Desenvolvimento Baseado em Componentes. In: WMSWM 2005 - WORKSHOP DE MANUTENO DE SOFTWARE MODERNA. Anais... Manaus, 16 p., 2005.

MARTIMIANO, L. A. F. Estudo de Tcnicas de Teste de Regresso Baseado em Mutao Seletiva. Dissertao (Mestrado em Cincia de Computao e Matemtica Computacional) Instituto de Cincias Matemticas e de Computao, Universidade de So Paulo, So Carlos, So Carlos, 1999.

MILLS, H.D., ONEILL, D. et al. The Management of Software Engineering. IBM Sys. J., 24(2), p. 414477, 1980.

MYERS, G. J. The art of software testing. Second Edition. Wiley, 2004.

MySQL. Manual de Referncia do MySQL 4.1. 2007. Disponvel em: <http://dev.mysql.com/ doc/refman/4.1/pt/>. Acesso em: 10/02/2007.

NATALI, A. C. C.; FALBO, R. de A. Gerncia de Conhecimento de Qualidade de Software. Resi Revista Eletrnica de Sistema de Informao, Universidade Federal do Esprito Santo, 2004. Disponvel em: <http://www.inf.ufes.br/~falbo/download/pub/ Jiisic2002paper33.pdf>. Acesso em: 10/12/2005.

OLIVEIRA, A. A. A. C. P.; PRIMO, F. F., CRUZ, J. L.; MARTINO, W. R. Gerncia de Configurao de Software Evoluo de Software sob Controle. Instituto Nacional de Tecnologia de Informao ITI, rgo do Ministrio da Cincia e Tecnologia, 2001.

PAULK, M. C. Capability maturity model for software version 11 Technical Report 93-TR-24, CMU/SEI, 1993.

PENTEADO, R. A. D. Um Mtodo para a Engenharia Reversa Orienta a Objetos. Tese (Doutorado em Fsica Computacional) - Instituto de Fsica, Universidade de So Paulo, So Carlos, 1996.

111

PETERS, J. F.; PEDRYCZ, W. Engenharia de Software. 3. reimp. Rio de Janeiro: Elsevier, 2001.

PMI - Project Management Institute. Sobre PMI Histria. Disponvel: <http://www.pmisc. org.br/portugues/introducao.htm>. Acesso em: em 10/03/2006.

PMI - Project Management Institute. Um Guia do Conjunto de Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 3. ed. Four Campus Boulevard, Newtown Square, PA 19073-3299, EUA, 2004.

PRESSMAN, R. S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2006.

RECCHIA, E. L.; PENTEADO, R. FaPRE/OO: Uma Famlia de Padres para Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais. In: SUGARLOAF PLOP - THE SECOND LATIN AMERICAN CONFERENCE ON PATTERN LANGUAGES OF PROGRAMMING. Anais Rio de Janeiro, 2002.

ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de Software. So Paulo: Prentice Hall, 2001.

SANTANNA, N.; CEREJA JUNIOR, M. G. BORREGO FILHO, L. F.; LUQUE, L.; CASILLO, B. H. e-WebProject Um ambiente integrado para apoio ao desenvolvimento e gesto de projetos de Software. In: CONGRESSO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE, XII. Anais... Curitiba, p. 1-11, 2002. SEI - Software Engineering Institute, Capability Maturity Model Integration (CMMISM), Version 1.1, 2001. Disponvel em: <http://www.sei.cmu.edu/CMMI/ models/model-componentsword.html>. Acesso em: 10/02/2006.

SILVA, F. A. RCS e CVS: Ferramentas para Versionamento de Arquivos. Instituto de Informtica da Universidade Federal do Rio Grande do Sul, RS, 2002. Disponvel em: <http://www.inf.ufrgs.br/~clesio/cmp151/cmp15120021/artigo_fabricio.pdf>. Acesso em: 20/02/06.

SNEED, H. M., NYARY, E. Extracting object-oriented specification from procedurally oriented programs. In: WCRE 1995, WORKING CONFERENCE ON REVERSE ENGINEERING, 2. Proceedings... Toronto-Canad, 1995.

SOFTEX, MPS.BR Melhoria de Processo do Software Brasileiro (Guia Geral Verso 1.0), 2005. Disponvel em: <http://www.inf.ufes.br/~falbo/download/aulas/es-m/2005-2/Texto14.pdf>. Acesso em: 10/02/2006.

112

SOLINGEN, R. V., BERGHOUT, E. The Goal Question Metric Method A practical Guide for Quality Improvement of Software Development. Londres: McGraw-Hill International, 1999.

SOMMERVILLE, I. Engenharia de Software. 6. ed. So Paulo: Addison Wesley, 2003.

TICHY, W. F. RCS - A System for Version Control. The Revision Control System, Edition 1.1 RCS Version 5.7, 1997. Disponvel em: <http://cs1.bradley.edu/~alp/ teaching/RCS.pdf>. Acesso em: 10/02/2006.

TOSUN, F. Evaluating Software Configuration Management tools for Opticon Sensors Europe B.V. Masters Thesis (Software Engineering from the UVA) - Universiteit Van Amsterdam, Amasterdam, 2004.

TSUKUMO, A.; RGO, C. M.; SALVIANO, C. F.; AZEVEDO, G.F.; MENEGHETTI, L. K.; COSTA, M. C. C.; CARVALHO, M. B.; COLOMBO, R. M. T. Qualidade de Software: Vises de Produto e Processo de Software. In: SBC - ESCOLA DE INFORMTICA DA SOCIEDADE BRASILEIRA DE COMPUTAO REGIONAL DE SO PAULO, II. Anais... Piracicaba, p. 173189, 1997.

WHOLIN, C.; RUNESON, P.; HOST, M.; OHLSSON, M. C.; REGNELL, B.; WESSLN, A. Experimentation in Software Engineering: an Introduction. Kluwer Academic Publishers, 2000.

XIMBIOT, Version Management with CVS, <http://ximbiot.com/CVS/manual/>. Acesso em: 27/02/2006.

2005.

Disponvel

em:

APNDICE A

Neste apndice ser apresentado o propsito da elaborao deste documento, o pbico alvo que ir utiliz-lo, o escopo, a padronizao e a documentao completa do modelo de referncia MR.GC-PARFAIT.

Propsito

Este documento fornece uma viso dos procedimentos necessrios para implantar a GC durante o uso do processo gil de reengenharia PARFAIT, visando controlar as mudanas que ocorrero tanto no framework quanto nas aplicaes derivadas do mesmo.

Pblico Alvo

Os interessados diretamente neste documento so todas as pessoas envolvidas no projeto de reengenharia utilizando o processo PARFAIT.

Escopo

Neste documento est detalhado todo o procedimento adotado para estabelecer as atividades de GC no PARFAIT.

Padronizao Todo artefato elaborado durante o projeto de reengenharia deve ser nomeado da seguinte maneira: <NOME_PROJETO>.<nome_artefato>.<data_da_criao>.[<descrio>]. Sendo: <NOME_PROJETO>: descrio do nome do projeto em letras maisculas; <nome_artefato>: descrio do nome do artefato; <data_da_criao>: registro da criao do artefato no formato DDMMAA, HH:MM;

114

<descrio>:

breve descrio opcional do artefato, devendo conter caracteres

maisculos e no acentuados (A-Z), nmeros (0-9), hfen (-) e sublinhado (_). Notas: a quantidade de caracteres utilizada no deve ultrapassar 50 unidades.

Documentao completa do MR.GC-PARFAIT

O formato da documentao do MR.GC-PARFAIT (FERREIRA; CAGNIN, 2007) definido neste trabalho segue aquele utilizado no RUP: atividade, objetivo, artefatos de entrada e de sada, apoio computacional, passos e gabaritos. Alm disso, um item foi adicionado na documentao, que aplicao no PARFAIT, ou seja, em que momento do processo PARFAIT (atividade) determinada atividade de GC do modelo de referncia deve ser executada. Sugere-se que o responsvel pela reengenharia determine um membro da equipe como gerente de configurao, que deve ter conhecimento e habilidade de executar as atividades impostas pelo MR.GC-PARFAIT. Nas subsees a seguir so apresentadas as atividades do modelo MR.GCPARFAIT. A execuo das atividades Identificar os itens de configurao e Definir a ferramenta de apoio no so obrigatrias. Pois, para a atividade Identificar os itens de configurao, MR.GC-PARFAIT sugere uma listagem dos itens de configurao do PARFAIT que devem ser submetidos GC. A no obrigatoriedade da execuo da atividade Definir a ferramenta de apoio est relacionada familiaridade do responsvel com determinada ferramenta de controle de verso. Nas subsees a seguir apresenta-se a documentao completa das atividades do modelo de referncia proposto.

Atividade: Identificar os itens de configurao (No Obrigatria)

Objetivo: Nesta atividade necessrio selecionar apenas os artefatos do PARFAIT que devem ser submetidos ao gerenciamento de configurao. Para facilitar o uso do modelo de referncia criado e a no execuo desta atividade, sugerida uma listagem dos artefatos que devem ser gerenciados. Aplicao no PARFAIT: Na atividade Observar o domnio do sistema legado em relao ao do framework (Fase de Concepo). Artefatos de entrada: Documentao do PARFAIT. Apoio computacional: Editor de texto. Artefatos de sada: Listagem dos itens de configurao do PARFAIT.

115

Passos: 1. Listar todos os artefatos do PARFAIT e elenc-los de acordo com o seu grau de importncia (aplicar mtrica Grau de Importncia) para documentar e conduzir a reengenharia. 2. Analisar a lista de artefatos priorizados, de acordo com o grau de importncia. 3. Listar os artefatos que devem ser submetidos ao gerenciamento de configurao.

Gabarito: Para selecionar quais artefatos produzidos pelo PARFAIT devem ser considerados no gerenciamento de configurao com o apoio do modelo de referncia proposto utilizou-se o GQM. A abrangncia da mtrica Grau de Importncia foi reduzida para simplificar a seleo: grau 3 extremamente importante (100% a 67%), grau 2 importncia moderada (66% a 34%) e grau 1 pouco importante (33% a 0%). O estabelecimento do grau de importncia para cada artefato do PARFAIT resultante da resposta da seguinte questo formulada com a aplicao do GQM: a agilidade do PARFAIT no prejudicada pelo gerenciamento do artefato X18 Para apoiar a definio do percentual, tem-se a mtrica intermediria: percentual de necessidade da utilizao do artefato X para criar o sistema alvo a partir da instanciao do framework. O resultado obtido est apresentado no Quadro 34 A1, que mostra a listagem dos artefatos elaborados durante o uso do PARFAIT com grau de importncia igual a 3, ou seja, artefatos extremamente importantes e que devem ser gerenciados pelo modelo proposto.

Artefatos desenvolvidos Documento de aceitao do framework Documento de requisitos Planejamento do projeto de reengenharia Documentao dos casos de teste Diagrama de Classes do sistema Digrama de Caso de Uso Quadro das adaptaes no diagrama de classes no cobertas pela linguagem de padres Quadro dos requisitos da linguagem de padres que no se adaptam completamente aos do sistema legado Documentao de regra do negcio Sistema alvo no paradigma orientado a objeto Documentao de casos de teste adequados ao sistema alvo Formulrio de planejamento das adaptaes Manual do usurio Sistema alvo no paradigma orientado a objetos liberado para uso Quadro 34 - Listagem dos itens de configurao do PARFAIT

18

Cada artefato produzido pelo PARFAIT.

116

Atividade: Definir a Ferramenta de Apoio (No obrigatria)

Objetivo: Nesta atividade define-se a ferramenta que melhor apia a GC, devendo ser adequada s necessidades impostas tanto para controlar as verses do framework quanto para controlar as verses dos sistemas gerados. Aplicao no PARFAIT: Na atividade Observar o domnio do sistema legado em relao ao do framework (Fase de Concepo). Artefatos de entrada: Documentao das caractersticas de ferramentas de GC. Apoio computacional: Editor de texto. Artefatos de sada: Ferramenta que melhor se adequou s necessidades impostas. Passos: 1. Observar e analisar, dentre as ferramentas encontradas, os pontos positivos e negativos de cada uma, levando em considerao o controle de verso tanto do framework quanto do sistema alvo. 2. Escolher a ferramenta de GC mais apropriada.

Atividade: Criar um repositrio de Configurao (Obrigatria)

Objetivo: Aps a definio dos artefatos na atividade Identificar os itens de configurao, estes sero armazenados e gerenciados em um repositrio de configurao com o apoio da ferramenta de controle de verso selecionada. Aplicao no PARFAIT: Na atividade: Observar o domnio do sistema legado em relao ao do framework (Fase de concepo). Artefatos de entrada: Artefatos selecionados na atividade Identificar os itens de configurao. Apoio computacional: Ferramenta de controle de verso. Artefatos de sada: Repositrio criado. Passo: 1. Criar o repositrio na ferramenta de controle de verso selecionada.

117

Atividade: Gerenciar as Verses (Obrigatria)

Objetivo: Nesta atividade so gerenciadas as verses do framework, as verses do sistema alvo gerado a partir de tal framework, bem como as verses dos demais itens de configurao. Essa atividade conduzida pelos envolvidos no projeto de reengenharia. Especificamente para o caso das verses do framework so documentadas as particularidades apresentadas em cada verso, como por exemplo, plataforma, necessidades de hardware e software, linguagem de programao, entre outras. Aplicao no PARFAIT: em todas as atividades das fases de Elaborao e Construo e em algumas atividades da fase de Concepo e Transio: Observar o domnio do sistema legado em relao ao do framework (Fase de Concepo); Confrontar as caractersticas no funcionais do Framework x sistema legado (Fase de Concepo); Elaborar o planejamento do projeto de reengenharia (Fase de Concepo); Elaborar o manual do usurio do sistema alvo (Fase de Transio); Testar o sistema alvo (Fase de Transio). Artefatos de entrada: Documentao das particularidades das verses do framework e dos sistemas gerados, bem como a dos demais itens de configurao. Apoio computacional: Editor de texto e ferramenta de controle de verso. Artefatos de sada: Documentao das verses do framework, do sistema alvo, dos demais itens de configurao (baseline). Passos: 1. Documentar de forma detalhada as peculiaridades apresentadas em cada verso do framework, em cada verso do sistema alvo gerado a partir do mesmo e em cada verso dos demais itens de configurao. 2. Armazenar a verso do item de configurao no repositrio da ferramenta de controle de verso.

Gabaritos: Nesta atividade foram desenvolvidos gabaritos para documentar as verses dos itens de configurao. Para documentar as verses do sistema alvo e do framework foram criados formulrios especficos, apresentados nos Quadro 35 e Quadro 36, respectivamente. Para documentar as verses dos demais itens de configurao selecionados na atividade Identificar os itens de configurao necessrio utilizar o formulrio apresentado no Quadro 37 . Salienta-se que sero documentadas apenas as verses dos itens de configurao que se tornarem baseline. Alm de

118

informaes especficas sobre a verso, necessrio registrar tambm o nmero da iterao do projeto de reengenharia que o item de configurao foi criado e/ou modificado, bem como o nome da atividade em que isso ocorreu.

Documentao das Verses do Sistema Alvo Documentao da Verso <nmero da verso do sistema> do Sistema Alvo <nome do sistema alvo> Projeto <nome do projeto> Data de criao do formulrio <dd/mm/aa hh:mm>

Verso do framework utilizada <nmero de verso do framework > Variabilidades funcionais do framework reutilizadas <lista dos nomes das variabilidades funcionais> Variabilidades No-Funcionais do framework reutilizadas < lista dos nomes das variabilidades no-funcionais>

Requisitos funcionais do sistema no reutilizados do framework <lista dos nomes dos requisitos funcionais >

Requisitos no-funcionais do sistema no reutilizados do framework <lista dos nomes dos requisitos no-funcionais>

Quadro 35 - Gabarito da documentao das verses do sistema alvo

Documentao das Verses do Framework Documentao da Verso <nmero da verso do framework > do framework <nome do framework > Plataforma <nome da plataforma utilizada> Domnio <nome do domnio coberto pelo framework> Recursos de hardware e software requeridos <por exemplo, ambiente de desenvolvimento, verso do compilador da linguagem de programao, sistema gerenciador de banco de dados (SGBD), verso do SGBD> Data de criao do formulrio <dd/mm/aa hh:mm> Linguagem de programao <nome da linguagem de programao utilizada>

Variabilidades funcionais <lista dos nomes das variabilidades funcionais>

Variabilidades no-funcionais <lista dos nomes das variabilidades no-funcionais>

Quadro 36 - Gabarito da documentao das verses do framework

119

Documentao das Verses dos Demais Itens de Configurao Nome do Projeto <nome do projeto> Data de criao ou atualizao do item ... ... Nome dos itens de configurao ... ... ... Data de criao do formulrio <dd/mm/aa hh:mm> Verso Nmero da iterao Nome da atividade do PARFAIT

Quadro 37 - Gabarito da documentao das verses dos itens de configurao

Atividade Gerenciar as Mudanas (Obrigatria)

Objetivo: Esta atividade empregada somente quando existir a necessidade de mudanas no sistema alvo ou no framework, que sejam tomadas as medidas necessrias para que ocorram as mudanas sem prejudicar a integridade das baselines desses itens de configurao. Aplicao no PARFAIT: Nas atividades Criar o sistema alvo no paradigma orientado a objetos (Fase construo) e Adaptar o sistema alvo (Fase de construo). Artefatos de entrada: Formulrios de controle de mudanas do framework e do sistema alvo Apoio computacional: Editor de texto e ferramenta de controle de verso. Artefatos de sada: Formulrios de controle de mudanas do framework e do sistema alvo devidamente preenchidos e aprovados/reprovados. Passos: 5. Identificar as mudanas necessrias. 6. Preencher os formulrios de controle de mudanas do framework (caso seja necessrio) e do sistema alvo (caso seja necessrio). 7. Aprovar ou reprovar as mudanas. 8. Realizar as mudanas e executar a atividade Gerenciar as Verses. Gabarito: As solicitaes de mudanas no sistema alvo, no framework e nos demais itens de configurao devem ser sempre documentadas por meio do formulrio de controle de mudanas, apresentado respectivamente no Quadro 30, no Quadro 31 e no Quadro 32. As solicitaes de mudanas no sistema alvo sero aprovadas ou no pelo gerente de configurao, de acordo com a complexidade das mesmas.

120

Formulrio de Controle de Mudanas no Sistema Alvo N da solicitao: <n da solicitao da mudana> Data da solicitao: <dd/mm/aa> Sistema alvo: <nome do sistema alvo> Projeto: <nome do projeto> Tempo estimado para a execuo da mudana <hh:mm> Verso do sistema alvo: <nmero correspondente da verso do sistema alvo que necessita sofrer mudanas> Tipo de mudana: Perfectiva Corretiva Adaptativa Preventiva

Mudana solicitada: <breve descrio da mudana> Artefatos afetados pela mudana solicitada: <lista dos nomes dos artefatos que sero afetados e que sofrero mudanas>

Solicitao de mudana APROVADA Implementar a mudana com apoio do framework: - por meio de nova instanciao do framework (nesse caso o framework fornece a mudana desejada, parcialmente ou completamente) Implementar a mudana manualmente: - por meio de um ambiente de programao

Solicitao de mudana NO APROVADA Retornar ao solicitante um parecer sobre o motivo da no aprovao da solicitao <motivo que levou a inviabilidade das mudanas>

Comentrios Adicionais: < breve descrio, se necessrio>

Quadro 38 - Gabarito do formulrio de controle de mudanas no sistema alvo

Formulrio de Controle de Mudanas no Framework N da solicitao: <n da solicitao da mudana> Data da solicitao: <dd/mm/aa> Framework: <nome do framework> Verso do framework: <nmero correspondente da verso do framework> Tipo de mudana: Perfectiva Corretiva Adaptativa Preventiva Projeto: <nome do projeto> Tempo estimado para a execuo da mudana <hh:mm>

Mudana solicitada: <breve descrio da mudana> Artefatos afetados pela mudana solicitada: <lista dos nomes dos artefatos que sero afetados e que sofrero mudanas>

Solicitao de mudana APROVADA Implementar a mudana no framework

Solicitao de mudana NO APROVADA Retornar ao solicitante um parecer sobre o motivo da no aprovao da solicitao <motivo que levou a inviabilidade das mudanas>

Comentrios Adicionais: < breve descrio, se necessrio>

Quadro 39 - Gabarito do formulrio de controle de mudanas no framework

121

Formulrio de Controle de Mudanas dos demais Itens de Configurao N da solicitao: <n da solicitao da mudana> Data da solicitao: <dd/mm/aa> Nome Artefato: <nome do artefato> Tipo de mudana: Perfectiva Corretiva Projeto: <nome do projeto> Tempo estimado para a execuo da mudana <hh:mm> Verso do Artefato: <verso do artefato> Adaptativa Preventiva

Mudana solicitada: <breve descrio da mudana> Artefatos afetados pela mudana solicitada: <lista dos nomes dos artefatos que sero afetados e que sofrero mudanas>

Solicitao de mudana APROVADA Comentrios Adicionais: < breve descrio, se necessrio>

Solicitao de mudana NO APROVADA

Quadro 40 Gabarito do formulrio de controle de mudanas dos demais itens de configurao

Para analisar tal complexidade preciso levar em considerao quais artefatos sero afetados pela mudana e se os mesmos necessitam de adaptaes ou correes. No caso do PARFAIT com o apoio computacional do framework GREN, a implementao das adaptaes (mudanas) realizadas manualmente no cdigo fonte do sistema alvo feita com o apoio da ferramenta GRENWizardVersionControl a fim de que tais adaptaes no sejam perdidas nas prximas instanciaes do framework. As solicitaes de mudanas no framework sero aprovadas ou no de acordo com uma anlise, que verifica se uma mudana pertinente ou no ao domnio do framework. Essa anlise est fora do escopo deste trabalho e feita com o apoio do Processo de Evoluo de Framework (PREF) (CAGNIN et al., 2004b). As mudanas no framework so efetuadas tambm com o apoio desse processo.

APNDICE B

Neste apndice apresentam-se os diagramas elaborados durante o estudo de caso (Captulo 6) realizado neste trabalho.

Figura 9 Diagrama de Caso de Uso

123

Figura 10 Diagrama de Classes

124

APNDICE C

Neste apndice apresentam-se os casos de teste genricos dos padres 1, 2 e 4 da LPA criados para aprimorar a abordagem de teste ARTe.
Id. casos de teste CT1 CT2 CT3 CT4 CT5 CT6 CT7 CT8 CT9 CT10 CT11 CT12 CT13 CT14 CT15 CT16 CT17 CT18 CT19 CT20 CT21 CT22 CT23 CT24 CT25 CT26 CT27 CT28 CT29 CT30 CT31 CT32 CT33 CT34 CT35

Ao Alterao Alterao Alterao Alterao Alterao Alterao Remoo Remoo Remoo Remoo Remoo Remoo Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero

Req teste ARTe RT14 / RT259 RT15 / RT260 RT16 / RT261 RT17 RT18 / RT263 RT19 / RT264 RT23 RT24 RT25 RT26 RT27 / RT262 RT28 RT30 RT30 / RT266 / RT267 RT30 RT30 RT30 RT31 RT31 RT31 RT31 RT31 RT32 RT32 / RT273 / RT268 RT32 RT32 RT32 RT33 RT33 / RT269 /RT 272 / RT 271 RT33 RT33 RT33 RT34 RT34 / RT276 / RT270 RT34

Dados de Entrada Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 aa 0 8 8 7x1 -2 x 0 1 6 7x9 -3 AA AA AA AA AA 61 x A 41 x A 31 x A 26 x A 21 x A Vazio Vazio Vazio Vazio Vazio AA AA AA AA AA 1111 1111 1111

Sada Esperada Erro: cdigo deve ser numrico Erro Sucesso Cdigo duplicado Erro: a quantidade de caracteres excede a expectativa Erro: cdigo tem de ser >= 0 Erro: caracteres invlidos Erro: numero no existente Sucesso Sucesso Erro: cdigo inexistente Erro: cdigo tem de ser >= 0 Sucesso: <= 60 caracteres Sucesso:< = 40 caracteres Sucesso: <= 30 caracteres Sucesso: <= 25 caracteres Sucesso: <= 20 caracteres Erro: a cima de 60 caracteres Erro: a cima de 40 caracteres Erro: a cima de 30 caracteres Erro: a cima de 25 caracteres Erro: a cima de 20 caracteres No continua o cadastro No continua o cadastro No continua o cadastro No continua o cadastro No continua o cadastro Sucesso: esta Descrio j foi includa deseja continuar? S/N Sucesso: esta Descrio j foi includa deseja continuar? S/N Sucesso: esta Descrio j foi includa deseja continuar? S/N Sucesso: esta Descrio j foi includa deseja continuar? S/N Sucesso: esta Descrio j foi includa deseja continuar? S/N Sucesso Sucesso Sucesso

125

CT36 CT37 CT38 CT39 CT40 CT41 CT42 CT43 CT44 CT45 CT46 CT47 CT48 CT49 CT50 CT51 CT52 CT53 CT54 CT55 CT56 CT57 CT58 CT59 CT60 CT61 CT62 CT63 CT64 CT65 CT66 CT67 CT68 CT69 CT70 CT71 CT72 CT73 CT74 CT75

Insero Insero Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Insero/Alterao Insero/Alterao Insero/Alterao Insero/Alterao Insero/Alterao Insero/Alterao Insero/Alterao Insero/Alterao

RT34 RT34 RT35 RT35 / RT 275 RT34 RT34 RT34 RT36 RT36 RT36 RT36 RT36 RT37 RT37 RT37 RT37 RT37 RT38 RT38 RT38 RT38 RT38 RT39 RT39 / RT 274 RT39 RT39 RT39 RT40 RT40 RT40 RT40 RT40 RT2007 RT2008 RT2009 RT2002 RT2000 RT2001 RT2005 RT2006

Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Descrio 60 Descrio 40 Descrio 30 Descrio 25 Descrio 20 Lista a partir de uma classe Lista a partir de uma classe Lista a partir de uma classe Lista Multivalorada Lista Multivalorada Lista Multivalorada Lista Discreta Lista Discreta

1111 1111 5xb 5xb 5xb 5xb 5xb 61 x b 41 x b 31 x b 26 x b 21 x b Vazio Vazio Vazio Vazio Vazio 5 x b = 10 x a 5 x b = 10 x a 5 x b = 10 x a 5 x b = 10 x a 5 x b = 10 x a 5xb=5xb 5xb=5xb 5xb=5xb 5xb=5xb 5xb=5xb 423 423 423 423 423 Valor A Valor B Vazio Vazio Valor A Valor A + Valor B Valor A "Vazio"

Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso Erro: capacidade de ate 60 caracteres Erro: capacidade de ate 40 caracteres Erro: capacidade de ate 30 caracteres Erro: capacidade de ate 25 caracteres Erro: capacidade de ate 20 caracteres No continua o cadastro No continua o cadastro No continua o cadastro No continua o cadastro No continua o cadastro Sucesso: este item j foi includo deseja continuar? S/N Sucesso: este item j foi includo deseja continuar? S/N Sucesso: este item j foi includo deseja continuar? S/N Sucesso: este item j foi includo deseja continuar? S/N Sucesso: este item j foi includo deseja continuar? S/N Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso Sucesso na verificao: permite continuar com a ao Erro: Valor no cadastrado Erro Erro: no permitido continuar com a ao Sucesso na verificao: permite continuar com a ao Sucesso na verificao: permite continuar com a ao Sucesso na verificao: permite continuar com a ao Erro

Quadro 41 Casos de teste genricos do Padro 1

126

Id. casos de teste CT76 CT77 CT78 CT79 CT80 CT81 CT80 CT81 CT83 CT84 CT85 CT86 CT87 CT88 CT89 CT90 CT91 CT92 CT93 CT94 CT95 CT96 CT97 CT98 CT99 CT100 CT101 CT102 CT103 CT104 CT105 CT106 CT107 CT108 CT109 CT110 CT111 CT112

Ao Insero Alterao Alterao Alterao Alterao Alterao Alterao Alterao Remoo Remoo Remoo Remoo Remoo Remoo Insero Insero Insero Insero Insero Alterao Alterao Alterao Alterao Alterao Alterao Insero Insero Insero Insero Insero Alterao Alterao Alterao Alterao Alterao Alterao Insero/Alterao Insero/Alterao

Req teste ARTe RT330/RT360 RT331 RT332/RT333 RT334/ RT358 RT335/ RT355 RT336 RT356 RT357 RT340 RT341 RT342 RT343 RT344 RT346 RT361 RT362 RT363 RT364 RT365 RT367 RT368 RT366 RT369 RT370 RT371 RT372 RT373 RT374 RT375 RT376 RT377 RT378 RT379 RT380 RT381 RT382 RT2005 RT2006

Dados de Entrada Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Localizao Localizao Localizao Localizao Localizao Localizao Localizao Localizao Localizao Localizao Localizao Status Status Status Status Status Status Status Status Status Status Status Lista Discreta Lista Discreta aa 0 8 8 7x1 -2 "Vazio" 9 ==9 X 0 1 6 x1 7x9 -3 AA 36 x A Vazio AA 1111 36 x b Vazio 5 x b = 10 x a 5xb=5xb AA 111 1 3 2 "Vazio" A 3 1 2 "Vazio" A 2 para 2 Valor A "Vazio"

Sada Esperada Erro: cdigo deve ser numrico Erro Sucesso Cdigo duplicado Erro: a quantidade de caracteres excede a expectativa Erro: cdigo tem de ser >= 0 Erro Sucesso Erro: caracteres invlidos Erro: numero no existente Sucesso Sucesso Erro: cdigo inexistente Erro: cdigo tem de ser >= 0 Sucesso: <= 35 caracteres Erro: a cima de 35 caracteres No continua o cadastro Sucesso: <= 35 caracteres, mesmo que duplicado Sucesso Erro: capacidade de ate 35 caracteres No continua o cadastro Aviso: este item j foi includo deseja continuar? S/N Sucesso Sucesso: localizao j cadastrada Sucesso Sucesso: valor A ou B Erro: caracteres invlidos Sucesso Erro Erro Erro: caracteres invlidos Sucesso: valor A ou B Sucesso: valor A ou B Erro Erro Sucesso Sucesso na verificao: permite continuar com a ao Erro

Quadro 42 - Casos de teste genricos do Padro 2

127

Id. casos de teste CT113 CT114 CT115 CT116 CT117 CT118 CT119 CT120 CT121 CT122 CT123 CT124 CT125 CT126 CT127 CT128 CT129 CT130 CT131 CT132 CT133 CT134 CT135 CT136 CT137 CT138 CT139 CT140 CT141 CT142 CT143 CT144 CT145 CT146 CT147 CT148 CT149

Ao Alterao Alterao Alterao Alterao Alterao Remoo Remoo Remoo Remoo Remoo Remoo Remoo Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Insero Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao

Req teste ARTe RT887 RT888 RT889 RT890 RT892 RT896 RT897 RT898 RT899 RT900 RT901 RT902 RT903 RT904 RT905 RT906 RT907 RT908 RT909 RT910 RT911 RT912 RT913 RT915 RT917 RT918 RT920 RT921 RT922 RT923 RT924/ RT941 RT925 RT926 RT927 RT928 RT929 RT930

Dados de Entrada Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Cdigo Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada aa 0 1 6x1 7x1 x 0 1 6x1 7x9 -3 2 10/5/2007 10/10/2007 18/7/2007 x/07/07 01/x/07 01/07/xx 00/00/00 00/01/2007 01/00/2007 1/12/0000 32/12/2007 10/13/2007 10/08/0090 10/10/3000 29/2/2004 29/02/2007 10/5/2007 10/10/2007 18/7/2007 x/07/07 01/x/07 01/07/xx 00/00/00 00/01/2007 01/00/2007

Sada Esperada Erro: Cdigo deve ser numrico Erro Sucesso Sucesso Erro: a quantidade de caracteres excede a expectativa Erro: caracteres invlidos Erro: numero no existente Sucesso Sucesso Erro: Cdigo inexistente Erro: Cdigo tem de ser >= 0 Erro: cdigo com relacionamento pendente Sucesso: Data Entrada < Data Entrada atual Erro: Data Entrada > Data Entrada atual Sucesso: Data Entrada = Data Entrada atual Erro: dia no numrico Erro: ms no numrico Erro: ano no numrico Erro Erro: dia vazio Erro: ms vazio Erro: ano vazio Erro: dia != do esperado Erro: ms != do esperado Erro Erro Sucesso: ano bissexto Erro: ano no bissexto Sucesso: Data Entrada < Data Entrada atual Erro: Data Entrada > Data Entrada atual Sucesso: Data Entrada = Data Entrada atual Erro: dia no numrico Erro: ms no numrico Erro: ano no numrico Erro Erro: dia vazio Erro: ms vazio

128

CT150 CT151 CT152 CT153 CT154 CT155 CT156 CT157 CT158 CT159 CT160 CT161 CT162 CT163 CT164 CT165 CT166 CT167 CT168 CT169 CT170 CT171 CT172 CT173 CT174 CT175 CT176 CT177 CT178 CT179 CT180 CT181 CT182 CT183 CT184 CT185 CT186

Alterao Alterao Alterao Alterao Alterao Alterao Alterao Insero Insero Insero Insero Insero Alterao Alterao Alterao Alterao Alterao Insero Insero Insero Insero Insero Alterao Alterao Alterao Alterao Alterao Alterao Insero Insero Insero Insero Insero Insero Insero Insero Insero

RT931 RT932 RT934 RT936 RT937 RT939 RT940 RT942 RT943 RT944 RT945 RT946 RT947 RT948 RT949 RT951 RT952 RT953 RT954 RT955 RT956 RT957 RT958 RT959 RT960 RT961 RT962 RT963 RT1118/ RT1161 RT1119/ RT1162 RT1120/ RT1163 RT1121/ RT1164 RT1123/ RT1166 RT1124/ RT1167 RT1125/ RT1168 RT1126/ RT1169 RT1127/ RT1170

Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Data Entrada Observao Observao Observao Observao Observao Observao Observao Observao Observao Observao Status Status Status Status Status Status Status Status Status Status Status Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno

1/12/0000 32/12/2007 10/13/2007 10/08/0090 10/10/3000 29/2/2004 29/02/2007 AA 61 x A "Vazio" AA 111 BB 61 x B "Vazio" AA 111 1 3 2 "Vazio" A 1 mudar para 2 3 22 "Vazio" A 2 para 2 10/5/2007 25/7/2007 18/7/2007 19/7/2007 x/07/07 01/x/07 01/07/xx 00/00/00 00/01/2007

Erro: ano vazio Erro: dia != do esperado Erro: ms != do esperado Erro Erro Sucesso: ano bissexto Erro: ano no bissexto Sucesso Erro: tamanho excede o permitido Sucesso: apesar de estar vazio Sucesso: este item j foi includo deseja continuar? S/N Sucesso: apenas de constar apenas nmeros Sucesso Erro: tamanho excede o permitido Sucesso: apesar de estar vazio Sucesso: este item j foi includo deseja continuar? S/N Sucesso: apenas de constar apenas nmeros Sucesso: valor A ou B Erro: caracteres invlidos Sucesso Erro Erro Sucesso: valor != da atual Erro: caracteres invlidos Erro Erro Erro Sucesso Erro: Data Chegada < Data atual Sucesso: Data Chegada > Data atual Sucesso: Data Chegada = Data atual Sucesso: Data Chegada = Data atual Erro: dia no numrico Erro: ms no numrico Erro: ano no numrico Erro Erro: dia vazio

129

CT187 CT188 CT189 CT190 CT191 CT192 CT193 CT194 CT195 CT196 CT197 CT198 CT199 CT200 CT201 CT202 CT203 CT204 CT205 CT206 CT207 CT208 CT209 CT210 CT211 CT212 CT213 CT214 CT215 CT216 CT217 CT218 CT219 CT220 CT221

Insero Insero Insero Insero Insero Insero Insero Insero Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Alterao Insero Insero Insero Insero Insero Insero Insero Insero Alterao

RT1128/ RT1171 RT1129/ RT1172 RT1130/RT 1173 RT1132/ RT1175 RT1134/ RT1177 RT1135/ RT1178 RT1137/ RT1180 RT1138/ RT1181 RT1139/ RT1183 RT1140/ RT1184 RT1141/ RT1185 RT1142/ RT1186 RT1144/ RT1188 RT1145/ RT1189 RT1146/ RT1190 RT1147/ RT1191 RT1148/ RT1192 RT1149/ RT1193 RT1150/ RT1194 RT1151/ RT1195 RT1153/ RT1197 RT1155/ RT1199 RT1156/ RT1200 RT1158/ RT1202 RT1159/ RT1203 RT1160/ RT1204 RT1182/ RT1204 RT1003 RT1004 RT1005 RT1006 RT1007 RT1008 RT1009 RT1010

Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Chegada/ Data Retorno Data Retorno Destino Destino Destino Destino Destino Destino Destino Destino

01/00/2007 1/12/0000 32/12/2007 10/13/2007 10/08/0090 10/10/3000 29/2/2004 29/02/2007 25/07/2007 para 28/072007 18/07/07 para 17/07/2007 18/7/2007 22/7/2007 x/07/07 01/x/07 01/07/xx 00/00/00 00/01/2007 01/00/2007 1/12/0000 32/12/2007 10/13/2007 10/08/0090 10/10/3000 29/2/2004 29/02/2007 28/07/07 para 18/07/07 1/1/1901 A 0 1111 6x1 5 7x1 -1 1 para 1

Erro: ms vazio Erro: ano vazio Erro: dia != do esperado Erro: ms != do esperado Erro Erro Sucesso: ano bissexto Erro: ano no bissexto Sucesso: Data Chegada > Data atual Erro: Data Chegada < Data atual Sucesso: Data Chegada = Data atual Sucesso Erro: dia no numrico Erro: ms no numrico Erro: ano no numrico Erro Erro: dia vazio Erro: ms vazio Erro: ano vazio Erro: dia != do esperado Erro: ms != do esperado Erro Erro Sucesso: ano bissexto Erro: ano no bissexto Sucesso Sucesso Erro: Destino do tipo numrico Erro Sucesso Sucesso Sucesso: Destino = ao ultimo cadastrado Erro: excede a quantidade permitida Erro: Destino >=1 Sucesso: mudar para o mesmo valor

130

CT222

Insero

RT1434

CT223

Insero

RT1435

Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel Cdigo do Recurso Instanciavel

Sucesso cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status disponvel Erro: cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status retirado Sucesso cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status disponvel Erro: cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status retirado Erro: cdigo no cadastrado Erro cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status disponvel Erro: cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status retirado Sucesso cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status livro j retira e devolvido Sucesso: cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status retirado Erro: cdigo no cadastrado Sucesso: cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status retirado Erro: cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status livro j retira e devolvido Erro: cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status retirado Erro cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status disponvel Erro: cdigo no cadastrado Sucesso: cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status retirado Erro: cdigo do exemplar cadastrado na tabela livro e cadastrado no exemplar e status livro j retira e devolvido Erro: cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status retirado Erro cdigo do exemplar no cadastrado na tabela livro e cadastrado no exemplar e status disponvel Erro: cdigo no cadastrado

CT224

Insero

RT1436

CT225

Insero

RT1437

CT226

Insero

RT1438

CT227

Alterao

RT1439

CT228

Alterao

RT1440

CT229

Alterao

RT1441

CT230

Alterao

RT1442

CT231

Alterao

RT1443

CT232

Insero

RT1444

CT233

Insero

RT1445

CT234

Insero

RT1446

CT235

Insero

RT1447

CT236

Insero

RT1448

CT237

Alterao

RT1449

CT238

Alterao

RT1450

CT239

Alterao

RT1451

CT240

Alterao

RT1452

CT241

Alterao

RT1453

Quadro 43 - Casos de teste genricos do Padro 4