157

Modelo de Referncia de Gerncia de Configurao para um

Processo gil de Reengenharia baseado em Framework
Marliane Aldivina Oliveira Ferreira, Maria Istela Cagnin
UNIVEM Centro Universitrio Eurpides de Marlia
Marlia, So Paulo, Brasil, Caixa Postal 2041, CEP 17525-901
marlianeferreira@gmail.com, istela@univem.edu.br
Abstract. Configuration Management (CM) is one of the manners to guarantee
software quality. Several quality models which concern about CM have been
considered, among them it is distinguished the MR.MPS reference model.
However, there is a lack in literature related to reference models in
reengineering context. Under this perspective, this paper aims to define a CM
reference model, called MR.GC-PARFAIT, for the PARFAIT reengineering
agile process. The model has been defined by means of three stages (to select
essential CM activities, to select essential CM artifacts and to establish
reference model applicability in PARFAIT activities), this being so the method
GQM has been used in the two first stages. Reference model documentation is
based on documentation structure of RUP (Rational Unified Process) and it is
presented in this paper.
Resumo. Gerncia de Configurao (GC) uma das maneiras de garantir a
qualidade do software. Diversos modelos de qualidade que se preocupam com
GC tm sido propostos, dentre eles destaca-se o modelo de referncia MR-
MPS. No entanto, h carncia na literatura relacionada a modelos de
referncia no contexto de reengenharia. Sob essa perspectiva, este artigo tem
como objetivo definir um modelo de referncia de GC, denominado MR.GC-
PARFAIT, para o processo gil de reengenharia PARFAIT. O modelo foi
definido por meio de trs etapas (selecionar as atividades essenciais de GC,
selecionar os artefatos essenciais de GC e estabelecer a aplicabilidade do
modelo nas atividades do PARFAIT), sendo que nas duas primeiras etapas
empregou-se o mtodo GQM. A documentao do modelo baseada na
estrutura da documentao do RUP (Rational Unified Process) e est
apresentada neste artigo.
1. Introduo
Solicitaes de mudanas durante o ciclo de vida do software so inevitveis. Uma das
maneiras de permitir que tais mudanas ocorram sem alterar a qualidade presente no
software por meio do emprego da Gerncia de Configurao (GC) (Pressman, 2002),
que tem como principal objetivo controlar as mudanas e as verses do software
(Sommerville, 2003). Isso no diferente durante o desenvolvimento e a reengenharia
incremental, pois verses do novo sistema e do sistema alvo, respectivamente, so
liberadas a cada iterao do processo. A problemtica se torna maior quando se utiliza
frameworks (Fayad et al., 1999) como apoio computacional do processo para gerar o

VI Simpsio Brasileiro de Qualidade de Software

158

sistema, uma vez que necessrio controlar tanto as verses dos frameworks como
tambm a dos sistemas gerados.
No contexto de processos de reengenharia baseados em frameworks, tem-se o
processo PARFAIT (Processo gil de Reengenharia baseado em Framework no
domnio de sistemas de Informao com tcnicas de VV&T) (Cagnin et al., 2003), que
trata implicitamente as atividades de GC.
Sob a perspectiva de modelos de referncia que abordam a GC tem-se o Modelo
de Referncia para Melhoria do Processo de Software (MR-MPS) (Softex, 2006). No
entanto, at o momento no foi encontrado um modelo de referncia na literatura
pesquisada especfico para a atividade de GC no contexto de processos de reengenharia
baseados em frameworks.
Diante do exposto, observou-se a necessidade de criar um modelo de referncia
para tratar de maneira sistemtica a GC do PARFAIT, o qual est apresentado
detalhadamente neste artigo. Uma vez que o PARFAIT caracterizado como um
processo gil, devem-se tomar precaues durante a definio desse modelo para no
prejudicar a sua agilidade. Este artigo est organizado em seis sees: na Seo 2
apresenta-se uma viso geral do processo PARFAIT para o entendimento da
aplicabilidade do modelo de referncia definido. Na Seo 3 aborda-se a preparao
para a definio do modelo de referncia, que composta por trs etapas (seleo das
atividades de GC para compor o modelo, seleo dos artefatos de GC e aplicabilidade
das atividades selecionadas de GC nas atividades do PARFAIT). Na Seo 4 apresenta-
se a documentao do modelo de referncia, denominado MR.GC-PARFAIT. Na Seo
5 apresenta-se como trabalho correlato o modelo de referncia MR-MPS sob a
perspectiva de GC. E, finalmente, na Seo 6 discutem-se as concluses obtidas e
sugestes de trabalhos futuros.
2. PARFAIT: Processo gil de Reengenharia baseado em Framework
PARFAIT (Cagnin et al., 2003) um processo gil, incremental e iterativo, que visa
migrar sistemas legados procedimentais para o paradigma orientado a objetos. Esse
processo um dos recursos disponveis no Arcabouo de Reengenharia gil (ARA),
que possibilita a reengenharia gil baseada em linguagens de padres de anlise
(Appleton, 1997), para apoiar o entendimento do domnio do sistema legado, e em
frameworks (Fayad et al., 1999), para apoiar a gerao do sistema alvo.
O ARA oferece apoio na criao de uma verso do sistema alvo o mais rpido
possvel, 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 com o apoio de critrios de
teste funcional (Myers, 2004) que so executados no sistema legado para apoiar a
engenharia reversa no entendimento das funcionalidades e na identificao de regras de
negcio e, posteriormente, no sistema alvo para valid-lo. Salienta-se que as
funcionalidades presentes no sistema legado podem ser evoludas de acordo com as
necessidades dos usurios.

VI Simpsio Brasileiro de Qualidade de Software

159

No PARFAIT h reso em vrios nveis de abstrao (anlise, projeto,
implementao, teste e manuteno), que proporcionado indiretamente pelo arcabouo
ARA, como discutido por Cagnin (2005).
A documentao de todas as atividades do PARFAIT baseada no formato da
documentao do RUP (Rational Unified Process) (Kruchten, 2001), mas no contexto
de reengenharia. Este formato composto por fases (Concepo, Elaborao,
Construo e Transio), atividades, passos, artefatos desenvolvidos, apoio
computacional, diretrizes, entre outros. A modelagem dos diagramas feita em UML
(Unified Modelling Language).
Deve-se ressaltar que no final da iterao de cada fase do processo existe um
marco de referncia que tem como objetivo observar o cumprimento do plano de projeto
estabelecido na Fase de Concepo e estabelecer a viabilidade de dar continuidade ou
no ao projeto (Cagnin, 2003).
PARFAIT trata apenas de alguns itens da GC de forma manual, assim observou-
se neste artigo 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 do PARFAIT se
preocupar 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.
3. Preparao para a Definio do Modelo de Referncia de GC do
PARFAIT
A elaborao do modelo de referncia foi obtida por meio de trs etapas, de acordo com
a Figura 1: as atividades e os artefatos de GC (Sommerville, 2003) essenciais para
compor o modelo de referncia proposto foram selecionados nas etapas um e dois,
respectivamente. Posteriormente, na etapa trs, identificou-se a aplicabilidade das
atividades de GC, selecionadas para o modelo de referncia, nas atividades do
PARFAIT. Ressalta-se que as etapas foram realizadas incrementalmente com o intuito
de refinar o modelo de referncia durante sua definio.
Para apoiar as duas primeiras etapas empregou-se o mtodo GQM (Goal
Question Metric) (Basili et al., 1994). O mtodo GQM tratou de forma quantitativa a
seleo das atividades e dos artefatos de GC nas duas primeiras etapas, por meio de um
plano de mensurao com a utilizao de questes apropriadas e com a aplicao da
mtrica Grau de Importncia, definida em Ferreira e Cagnin (2006). Essa mtrica tem
como objetivo auxiliar na seleo das atividades e dos artefatos de GC essenciais para o
processo PARFAIT, de acordo com a importncia desses, sem afetar a agilidade de tal

VI Simpsio Brasileiro de Qualidade de Software

160

processo. Salienta-se que devido a isso, somente os principais objetivos da GC so
atendidos pelo modelo de referncia proposto.
Os possveis valores resultantes aps a aplicao da mtrica Grau de
Importncia so: grau 5 - extremamente importante (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% a 20%) e grau 1 - sem importncia (de 19% a 0%). A
definio do percentual durante a aplicao da mtrica baseada na resposta das
questes formuladas durante a aplicao do GQM. Os resultados das etapas um e dois
so detalhados em Ferreira e Cagnin (2006).













Figura 1 Viso geral da definio do MR.GC-PARFAIT
Para apoiar a terceira etapa foi realizada uma anlise da documentao do
processo PARFAIT a fim de selecionar as atividades desse processo que devem ser
submetidas a GC com apoio do MR.GC-PARFAIT (apresentado na prxima seo). 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 est apresentado no Quadro 1. Neste quadro est
estabelecida a relao entre as atividades do processo PARFAIT, as atividades de GC
1 Etapa - Selecionar as
atividades essenciais de GC
para o MR.GC-PARFAIT
2 Etapa- Selecionar os
artefatos essenciais de GC
para o MR.GC-PARFAIT
3 Etapa - Identificar a
aplicabilidade das atividades
de GC nas atividades do
PARFAIT
MR.GC-PARFAIT








Identificar os artefatos, Criar um
repositrio de configurao, Gerenciar
as mudanas, Gerenciar as verses e
Definir a ferramenta de apoio a GC
Listagem dos itens de configurao,
Formulrio de controle de mudanas e
Documentao das verses (baselines)

VI Simpsio Brasileiro de Qualidade de Software

161

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.
Quadro 1 - Atividades do PARFAIT x Atividades de GC
Atividades do PARFAIT Atividades de GC
Justificativa da Execuo das Atividades
de GC
Familiarizar-se com o domnio
do Framework
Nenhuma
Esta atividade do PARFAIT no
obrigatria e no incremental, assim no
apresentou necessidade de ser gerenciada.
Identificar os artefatos
Definir a ferramenta de apoio
Criar um repositrio
Observar o domnio do sistema
legado em relao ao do
Framework
Gerenciar as Verses
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).
Confrontar as caractersticas
no funcionais do Framework
x sistema legado
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Elaborar o Planejamento do
Projeto de reengenharia
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 3.
Desenvolver o diagrama de
casos de uso e elaborar os
casos de teste
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Desenvolver o diagrama de
classes do sistema alvo
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Documentar as modificaes
realizadas no diagrama de
classes
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Documentar as regras de
negcio do sistema
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Gerenciar as Mudanas
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2. Criar o sistema alvo no
paradigma orientado a objeto
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Executar os casos de teste no
sistema alvo
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Gerenciar as Mudanas
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.
Adaptar o sistema alvo
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Elaborar o manual do usurio
do sistema alvo
Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Converter a base de dados do
sistema legado
-
No satisfaz nenhum critrio, pois no possui
artefato para ser gerenciado
Testar o sistema alvo Gerenciar as Verses
Esta atividade do PARFAIT satisfaz os
critrios 1 e 2.
Treinar os usurios finais -
No satisfaz nenhum critrio pois no possui
artefato para ser gerenciado
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

VI Simpsio Brasileiro de Qualidade de Software

162

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 framework 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.
4. MR.GC-PARFAIT: Modelo de Referncia de GC do PARFAIT
O formato da documentao do MR.GC-PARFAIT definido neste artigo 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.GC-PARFAIT. 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 a GC. A
no obrigatoriedade da execuo da atividade Definir a ferramenta de apoio est
relacionada a 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.
4.1. 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.
- 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;

VI Simpsio Brasileiro de Qualidade de Software

163

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 X
1
? 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 2, 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.
Quadro 2 - Listagem dos Itens de Configurao do PARFAIT
Itens de Configurao do PARFAIT
Documento de aceitao do framework
Documento de requisitos
Planejamento do projeto de reengenharia
Documentao dos casos de teste
Diagrama de Classes do sistema
Diagrama de Casos 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
4.2. 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
Cada artefato produzido pelo PARFAIT.

VI Simpsio Brasileiro de Qualidade de Software

164

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.
4.3. 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.
4.4. Atividade Gerenciar as Mudanas (Obrigatria)
- Objetivo: Esta atividade empregada somente quando existir a necessidade de
mudanas no sistema alvo ou no framework, para 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 e no framework devem ser
sempre documentadas por meio do formulrio de controle de mudanas, apresentados
respectivamente nos Quadros 3 e 4. As solicitaes de mudanas no sistema alvo sero
aprovadas ou no pelo gerente de configurao, de acordo com a complexidade das

VI Simpsio Brasileiro de Qualidade de Software

165

mesmas. Para analisar tal complexidade devem-se 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 Frameworks (PREF) (Cagnin et al., 2004b). As mudanas no framework
so efetuadas tambm com o apoio desse processo.
Quadro 3 - Gabarito do Formulrio de Controle de Mudanas no Sistema Alvo
Formulrio de Controle de Mudanas no Sistema Alvo
N da solicitao: <n da solicitao da mudana> Projeto: <nome do projeto>
Data da solicitao: <dd/mm/aa> Tempo estimado para a execuo da mudana <hh:mm>
Sistema alvo: <nome do sistema alvo> 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 Solicitao de mudana NO
APROVADA
Implementar a mudana com apoio
do Framework:
- por meio de nova instanciao do frame-
work (nesse caso o framework fornece a
mudana desejada, parcialmente ou
comple-tamente)
Implementar a
mudana manual-
mente:
- por meio de um
ambiente de
programao
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 4 - Gabarito do Formulrio de Controle de Mudanas no Framework
Formulrio de Controle de Mudanas no Framework
N da solicitao: <n da solicitao da mudana> Projeto: <nome do projeto>
Data da solicitao: <dd/mm/aa> Tempo estimado para a execuo da mudana <hh:mm>
Framework: <nome do framework>
Verso do framework: <nmero correspondente da verso do framework>
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 Solicitao de mudana NO APROVADA
Implementar
a mudana no
framework
No implementar a
mudana no
framework
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>


VI Simpsio Brasileiro de Qualidade de Software

166

4.5. 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 Quadros 5 e 6, 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 7. 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.






VI Simpsio Brasileiro de Qualidade de Software

167

Quadro 5 - Gabarito da Documentao das Verses do Sistema Alvo
Documentao das Verses do Sistema Alvo
Documentao da Verso <nmero da verso do sistema> do Sistema Alvo <nome do sistema alvo>
Projeto Data de criao do formulrio
<nome do projeto> <dd/mm/aa hh:mm>
Verso do framework utilizada
<nmero de verso do framework >
Variabilidades funcionais do framework
reutilizadas
Variabilidades No-Funcionais do framework
reutilizadas
<lista dos nomes das variabilidades funcionais> < lista dos nomes das variabilidades no-funcionais>
Requisitos funcionais do sistema no
reutilizados do framework
Requisitos no-funcionais do sistema no reutilizados
do framework
<lista dos nomes dos requisitos funcionais > <lista dos nomes dos requisitos no-funcionais>
Quadro 6 - Gabarito da Documentao das Verses do Framework
Documentao das Verses do Framework
Documentao da Verso <nmero da verso do Framework > do Framework <nome do Framework >
Plataforma Data de criao do formulrio
<nome da plataforma utilizada> <dd/mm/aa hh:mm>
Domnio Linguagem de programao
<nome do domnio coberto pelo framework> <nome da linguagem de programao utilizada>
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>
Variabilidades funcionais Variabilidades no-funcionais
<lista dos nomes das variabilidades funcionais> <lista dos nomes das variabilidades no-funcionais>
Quadro 7 - Gabarito da Documentao das Verses dos demais Itens de
Configurao
Documentao das Verses dos Demais Itens de Configurao
Nome do Projeto Data de criao do formulrio
<nome do projeto> <dd/mm/aa hh:mm>
Data de criao ou
atualizao do item
Nome dos itens de
configurao
Verso Nmero da iterao Nome da atividade
do PARFAIT
... ... ... ... ...
5. Trabalhos Relacionados
O projeto Melhoria de Processo de Software Brasileiro (MPS.BR) (Softex, 2006) criou
o modelo de referncia MR-MPS que tem como objetivo adaptar realidade brasileira,
modelos existentes para melhoria de processos de software, como CMMI (SEI, 2001),
ISO/IEC 12207 (1998) e ISO/IEC 15504 (1999), a um custo acessvel para as empresas
de desenvolvimento de software. Com isso, tais empresas podero aumentar sua
competitividade no mercado nacional e internacional.
A GC se encontra no nvel F dos nveis de maturidade do modelo MR.MPS. O
propsito desse modelo sob a perspectiva de GC estabelecer e manter a integridade
dos artefatos. Os objetivos de GC apresentados no modelo MPS.BR so divididos em
quatorze: 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 submet-los a
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

VI Simpsio Brasileiro de Qualidade de Software

168

criao ou a liberao das baselines pela GC; 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, 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.
Apesar desse modelo de referncia tratar da GC, no voltado para o contexto
de reengenharia baseada em framework e tambm no apresenta detalhes de como
executar cada atividade proposta. Assim, o modelo MR.MPS apresentou-se como um
guia sobre o que deve ser feito e no como.
Diante do exposto, observou-se carncia na literatura de modelos de referncia
para o contexto de reengenharia, mais especificamente, para apoiar a GC. Essa carncia
aliada a problemtica de controle de verses de framework e dos sistemas gerados e da
necessidade desse controle no PARFAIT motivou a definio do MR.GC-PARFAIT.
6. Concluso e Trabalhos Futuros
O modelo MR.GC-PARFAIT foi proposto com o intuito de explicitar as atividades de
GC durante a aplicao do processo PARFAIT. Para compor tal modelo sem afetar a
agilidade desse processo, foi realizado um estudo quantitativo a fim de selecionar as
atividades e artefatos de GC adequadamente (Ferreira e Cagnin, 2006). Para analisar o
modelo definido neste artigo, ser conduzido um estudo de caso planejado de
reengenharia, de acordo com Wholin et al. (2000). O objetivo de tal estudo analisar se
tal modelo no afeta a agilidade do processo e se apia efetivamente o controle de
verses do framework e dos sistemas gerados, mantendo a integridade dos mesmos.
Adicionalmente, nesse estudo de caso, ser analisada a necessidade de outras atividades
no modelo de referncia proposto e at mesmo a adequao de algumas das atividades
apresentadas.
O maior desafio encontrado neste trabalho foi a elaborao da documentao do
MR.GC-PARFAIT. 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. Conclui-se que
este modelo est voltado exclusivamente para o processo PARFAIT, mas isso no
impede de ser adaptado para outros processos de reengenharia.
Referncias
Appleton, B. (1997). Patterns and software: Essential concepts and terminology.
http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html, Janeiro/2006.
Basili, V.R.; Caldiera, G.; Rombach, H.D. (1994). Goal Question Metric paradigm.
Encyclopedia of Software Engineering, John Wiley & Sons.
Cagnin, M. I.; Maldonado, J. C.; Germano, F. S.; Penteado, R. D. (2003). PARFAIT:
Towards a Framework-based Agile Reengineering Process. In: I Agile Development
Conference, Salt Lake City, UTHA. IEEE.

VI Simpsio Brasileiro de Qualidade de Software

169

Cagnin, M. I.; Maldonado, J. C.; Germano, F. S.; Penteado, R. D.; Braga, R. T. (2004a).
GREN-WizardVersionControl: Uma Ferramenta de Apoio ao Controle de Verso das
Aplicaes Criadas pelo Framework GREN. In: Sesso de Ferramentas do XVIII
Simpsio Brasileiro de Engenharia de Software, Braslia, DF.
Cagnin, M. I.; Maldonado, J. C.; Masiero, P. C.; Penteado, R. D.; Braga, R. T. (2004b).
An Evolution Process for Application Frameworks. In: I Workshop de Manuteno
Moderna de Software, em conjunto com o XVIII Simpsio Brasileiro de Engenharia
de Software, Braslia, DF, CD-ROM, 8 p., 2004.
Cagnin, M. I. (2005). PARFAIT: uma contribuio para a reengenharia de software
baseada em linguagem de padres e frameworks. Tese de doutorado do Instituto de
Cincias Matemticas e de Computao ICMC/USP, So Carlos.
Fayad, M., Schmidt, D., Johnson, R. (1999). Building Application Frameworks: Object-
Oriented Foundations of Framework Design. John Wiley & Sons, September.
Ferreira, M.A.O.; Cagnin, M.I. (2006). Proposta de um Modelo de Referncia de
Gerncia de Configurao para um Processo de Reengenharia baseado em
Framework. In: III Simpsio Brasileiro de Sistemas de Informao, Curitiba-PR.
ISO/IEC 12207 (1998). Tecnologia de Informao - Processos de ciclo de vida de
software. ABNT - Associao brasileira de normas tcnicas Rio de Janeiro: ABNT.
ISO/IEC 15504 5 (1999). Information Technology Software process assessment
Part 5: An assessment model and indicator guidance. ISO/IEC - International
Standard Organization and International Electritechnical Commission.
Kruchten, P. (2000). The Rational Unified Process and Introduction Second Edition.
Addison Wesley Longman: NJ.
Myers, G. J. (2004). The art of software testing. Second Edition. Wiley.
Pressman, R. S. (2002). Engenharia de Software. 5 ed., Rio de Janeiro: McGraw-Hill.
SEI - Software Engineering Institute. (2006). Capability Maturity Model Integration
(CMMI
SM
). Version 1.1, 2001, http://www.sei.cmu.edu/cmmi/models/model-
components-word.html, Fevereiro.
Softex (2006). MPS.BR Melhoria de Processo do Software Brasileiro (Guia Geral
Verso 1.0). http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.1.pdf,
Janeiro.
Sommerville, I. (2003). Engenharia de Software. 6 ed., So Paulo: Addison Wesley.
Wholin, C., Runeson, P., Hst, M., Ohlsson, M. C., Regnell, B., e Wessln, A. (2000).
Experimentation in Software Engineering: an Introduction. Kluwer Academic
Publishers.