Download - Engenharia de Software e Reversa
-
8/3/2019 Engenharia de Software e Reversa
1/171
UNIVERSIDADE FEDERAL DE SO CARLOS
CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA
PROGRAMA DE PS-GRADUAOEM CINCIA DA COMPUTAO
PRE/OO UM PROCESSO DEREENGENHARIA ORIENTADA A OBJETOS
COM NFASE NA GARANTIA DA QUALIDADE
*,=(//(6$1'5,1,/(026
Dissertao apresentada ao Programa de Ps-Graduao em
Cincia da Computao do Departamento de Computao da
Universidade Federal de So Carlos, como parte dos requisitos
para obteno do ttulo de Mestre em Cincia da Computao
Orientadora: Prof. Dr. Rosngela Aparecida Dellosso Penteado
6mR&DUORV
-
8/3/2019 Engenharia de Software e Reversa
2/171
)LFKDFDWDORJUiILFDHODERUDGDSHOR'H37GD%LEOLRWHFD&RPXQLWiULDGD8)6&DU
Lemos, Gizelle Sandrini.L557pr PRE/OO Um processo de reengenharia orientada a
objetos com nfase na garantia da qualidade / Gizelle SandriniLemos So Carlos : UFSCar, 2002.
158p.
Dissertao (Mestrado) Universidade Federal de SoCarlos, 2002.
1. Engenharia de software. 2. Reengenharia orientada aobjetos. 3. Qualidade de processos. I. Ttulo.
CDD: 005.1 (20)
-
8/3/2019 Engenharia de Software e Reversa
3/171
Dedicatria
'HGLFRHVWHWUDEDOKR
DRVPHXVSDLV
DRPHXPDULGR0iULR3UDGRHDRPHXILOKR0iULR/HPRV
-
8/3/2019 Engenharia de Software e Reversa
4/171
Agradecimentos
Prof. Dr. Rosngela A. D. Penteado pela pacincia, sugestes e orientao
indispensveis.
Ao meu marido Mrio Prado pelo companheirismo e carinho, pela dedicao junto
ao nosso filho durante esse perodo, pelas sugestes e ajuda que muito contriburam
para a concluso desse trabalho.
Ao meu filho Mrio Lemos pela pacincia e compreenso e por aceitar as vrias
negativas quanto disponibilidade de ateno.
Aos meus pais Ernani e Aparecida pelo incentivo e auxlio mesmo distncia. Aos
meus irmos Amanda e Marcos pelo apoio e carinho.
querida amiga Angelita Segovia por me ensinar a trabalhar sempre com
seriedade e confiana e por me ouvir nos momentos difceis.
s colegas Regiane Marucci e Dbora Diniz pela amizade e ajuda durante o curso.
Ao Edson Recchia e Maria ngela pela experincia, pelos conselhos e pelo
material fornecido para utilizao em meu trabalho.
Aos amigos da Associao Luz e Caridade pela fora transmitida, essencial em
meu equilbrio.
Ao querido Mestre Jesus e Deus, Pai Maior.
-
8/3/2019 Engenharia de Software e Reversa
5/171
Resumo
Este trabalho apresenta um processo, denominado PRE/OO (Processo de Reengenharia
Orientada a Objetos), que visa conduzir a reengenharia de sistemas legados
procedimentais para sistemas orientados a objetos. O processo especificado na formade sete FOXVWHUV, compostos por vinte padres, que atendem s seguintes etapas:
planejamento do processo, engenharia reversa e engenharia avante sendo dois FOXVWHUV
especialmente criados para a garantia de qualidade, aplicando-se um deles durante todo
o processo. O PRE/OO foi composto com base na evoluo do Fusion/RE utilizando a
UML para modelagem dos diagramas gerados. O processo realizado de forma
evolutiva, permitindo o retorno as etapas anteriores. Alguns dos padres de engenharia
reversa foram elaborados com base na FaPRE/OO, uma famlia de padres de
reengenharia orientada a objetos. Os FOXVWHUVde garantia da qualidade foram elaborados
a partir de KPAs do nvel 2 de maturidade do SW-CMM. O trabalho concentra-se na
aplicao da reengenharia em sistemas desenvolvidos no ambiente Delphi, que no se
beneficiam das vantagens do paradigma da orientao a objetos, inerentes linguagem
2EMHFW3DVFDO. O ambiente de programao em questo um dos mais utilizados por
empresas e profissionais, para a implementao de sistemas informatizados. Entretanto,
por sua flexibilidade e facilidade de aprendizado, diversos programadores sem
experincia nesse paradigma e, muitas vezes, acostumados programao
procedimental em linguagens como &OLSSHU ou COBOL, sub-utilizam a capacidade do
ambiente e implementam aplicaes sem o uso de seus conceitos. Como resultado so
gerados sistemas complexos, mal documentados e de difcil expanso e manuteno.
Um estudo de caso apresentado em que um sistema legado, implementado sem
caractersticas orientadas a objetos, foi submetido ao PRE/OO para exemplificar seu uso.
Como resultados obteve-se a verso re-implementada do sistema que utiliza plenamente
os conceitos da orientao a objetos e toda a documentao do mesmo.
-
8/3/2019 Engenharia de Software e Reversa
6/171
$EVWUDFW
This work presents a process, called PRE/OO (Object Oriented Reengineering
Process) which aims to help the reengineering process from procedural legacy systems to
object oriented systems. The process is specified in the form of seven clusters composed
of twenty patterns including the following phases: process planning, reverse engineering
and forward engineering. Two clusters were used for quality assurance applied during the
process. The PRE/OO is based on the Fusion/RE evolution and uses the UML for
modeling the system diagrams. The entire process is built in an evolutive context, where
the software engineer can return at any time to earlier process steps. Some reverse
engineering patterns were created based on the FaPRE/OO (an object oriented
reengineering pattern family). The quality assurance clusters were created based on the
second level KPAs in the SW-CMM. The work focus on the application of reengineering
process for systems developed in the Delphi environment which were
projected/developed without using the concepts of the Object Orientation Paradigm,
inherent in the Object Pascal language. Although the Delphi programming environment is
largely used by companies and professional developers not all of them are able to use this
features and capabilities to a full extent because they either lack the proper knowledge for
using OOP or they are still using old programming techniques (e.g. from Cobol or Clipper).
The final result are normally complex systems, with very few documentation and difficult
maintenance and expansion. A case study is presented using a legacy system, that didnot use the OOP concepts in its development. This system was submitted to the PRE/OO
process. The result was one new version of the system that complies with the OOP
concepts and its respective documentation.
-
8/3/2019 Engenharia de Software e Reversa
7/171
Sumr io
&$378/2,1752'8d2
1.1. CONSIDERAES INICIAIS ...................................................................................................... 1
1.2. CONTEXTUALIZAO E OBJETIVOS DA PESQUISA.................................................................... 2
1.3. MOTIVAO DA MONOGRAFIA ................................................................................................ 4
1.4. ORGANIZAO DA DISSERTAO ........................................................................................... 4
&$378/25(9,62%,%/,2*5),&$
2.1. CONSIDERAES INICIAIS ...................................................................................................... 5
2.2. ENGENHARIA REVERSA ......................................................................................................... 5
2.3. MTODO FUSION/RE............................................................................................................. 7
2.4. REENGENHARIA .................................................................................................................. 11
2.5. SEGMENTAO ................................................................................................................... 12
2.6. MANUTENO..................................................................................................................... 13
2.7. PADRES PARA REALIZAO DE REENGENHARIA .................................................................. 14
2.8. QUALIDADE NO PROCESSO DE SOFTWARE ........................................................................... 19
0pWRGRVGH0HOKRULDGD4XDOLGDGH
0RGHORVGH0DWXULGDGH
2.9. UML (UNIFIED MODELING LANGUAGE)................................................................................. 37
2.10.O AMBIENTE DE PROGRAMAO DELPHI .............................................................................. 38
2.11.CONSIDERAES FINAIS ..................................................................................................... 39
&$378/22352&(662'(5((1*(1+$5,$25,(17$'$$2%-(726 3.1. CONSIDERAES INICIAIS .................................................................................................... 41
3.2. O PROCESSO DE REENGENHARIA ORIENTADA A OBJETOS (PRE/OO)...................................42
3.3. PADRES DE MELHORIA DA QUALIDADE DO PRE/OO...........................................................46
3.4. PADRES DE ENGENHARIA REVERSA DO PRE/OO...............................................................62
3.5. PADRES DE ENGENHARIA AVANTE DO PRE/OO ................................................................. 88
3.6. CONSIDERAES FINAIS ..................................................................................................... 98
&$378/2(678'2'(&$62$5((1*(1+$5,$'(8062)7:$5('(/3+,
4.1. CONSIDERAES INICIAIS .................................................................................................. 100
4.2. DESCRIO DO SOFTWARE LEGADO .................................................................................. 100
4.3. PREPARAO E PLANEJAMENTO DO PROCESSO DE REENGENHARIA COM O PRE/OO ..........103
4.4. REALIZAO DA ETAPA DE ENGENHARIA REVERSA DO PRE/OO.........................................107
4.5. REALIZAO DA ETAPA DE ENGENHARIA AVANTE DO PRE/OO ...........................................130
4.6. CONSIDERAES FINAIS ................................................................................................... 136
-
8/3/2019 Engenharia de Software e Reversa
8/171
&$378/280$(67,0$7,9$'2&8672;%(1()&,23$5$2352&(662'(
5((1*(1+$5,$25,(17$'$$2%-(726
5.1. CONSIDERAES INICIAIS .................................................................................................. 138
5.2. CUSTOS X BENEFCIOS DO PLANEJAMENTO DO PROCESSO DE REENGENHARIA ORIENTADA A
OBJETOS ...................................................................................................................................... 138
5.3. CUSTOS X BENEFCIOS DA ENGENHARIA REVERSA ............................................................. 139
5.4. CUSTOS X BENEFCIOS DA ENGENHARIA AVANTE................................................................ 141
5.5. CONSIDERAES FINAIS ................................................................................................... 147
&$378/2&21&/86(6(3(563(&7,9$6)8785$6
6.1. CONCLUSES ................................................................................................................... 149
6.2. CONTRIBUIES DESTE TRABALHO .................................................................................... 151
6.3. SUGESTES PARA TRABALHOS FUTUROS........................................................................... 151
5()(51&,$6%,%/,2*5),&$6
-
8/3/2019 Engenharia de Software e Reversa
9/171
Lis ta de Figu ra s
FIGURA 2.2.1: NVEL E GRAU DE ABSTRAO NO CICLO DE VIDA DO SOFTWARE (CHIKOFSKY, 1990) ...6
FIGURA 2.3.1: ESQUEMA DO MTODO FUSION/RE (PENTEADO
., 1998A)..................................10
FIGURA 2.7.1: AGRUPAMENTO DOS QUATRO
DA LINGUAGEM DE PADRES DE DEMEYER
.(2000B) ................................................................................................................................. 15FIGURA 2.7.2: &
DA FAMLIA DE PADRES DE REENGENHARIA OO DE RECCHIA(2002A).......16
FIGURA 2.8.1: ABORDAGEM IDEAL (GREMBA, 1997) ........................................................................21
FIGURA 2.8.2: CICLO PDCA (CAMPOS, 1992) ..................................................................................22
FIGURA 2.8.3: NVEIS DE MATURIDADE DO SW-CMM (PAULK
., 1993A) ....................................27
FIGURA 2.8.4: ESTRUTURA DAS KPAS DO SW-CMM (FIORINI
., 1998) ...................................... 36
FIGURA 2.9.1: FORMAO DA UML. ADAPTADA DE (PRADO, 2001) ....................................................37
FIGURA 3.1.1: ORIGENS DO PRE/OO..................................................................................................41
FIGURA 3.2.1: VISO GERAL DOS &
DE PADRES DO PRE/OO............................................... 43
FIGURA 3.3.1: EXEMPLO DE DOCUMENTAO DO LEVANTAMENTO DE ATIVIDADES .................................49
FIGURA 3.3.2: EXEMPLO DE DOCUMENTAO DO PLANO PARA REALIZAO DA REENGENHARIA ............53
FIGURA 3.3.3: EXEMPLO DE DOCUMENTAO DA INSPEO DE ACOMPANHAMENTO DO PROCESSO.........56
FIGURA 3.3.4: LISTA DE CONTROLE DE CONFIGURAO REFERENTE AO SISTEMA DE CONTROLE DE
LOCAES DE VDEOS ................................................................................................................. 61
FIGURA 3.3.5: PRIMEIRA %
DE PROJETO REFERENTE AO SISTEMA DE CONTROLE DE LOCAES DE
VDEOS ....................................................................................................................................... 61
FIGURA 3.4.1: VISO PARCIAL DA LISTA DE PROCEDIMENTOS E FUNES PARA O SISTEMA DE LOCAES
DE VDEOS .................................................................................................................................. 65
FIGURA 3.4.2: VISO PARCIAL DA LISTA "CHAMA/CHAMADO POR" DO SISTEMA DE LOCAES DE VDEOS 68
FIGURA 3.4.3: TRECHO DE
"
SQL DO ARQUIVO DE DADOS CLIENTE E LISTA DE TABELAS E CHAVES
CORRESPONDENTE ..................................................................................................................... 71
FIGURA 3.4.4: MER REFERENTE AO SISTEMA DE LOCAES DE VDEOS ................................................71
FIGURA 3.4.5: INSPEO DE GARANTIA DA QUALIDADE REALIZADA NO MER..........................................72
FIGURA 3.4.6: CDIGO-FONTE DO PROCEDIMENTO DE LOCAO DE UM VDEO .......................................74
FIGURA 3.4.7: EXEMPLO DE UM TRECHO DA LISTA DE ANOMALIAS DO SISTEMA DE LOCAES DE VDEOS 74
FIGURA 3.4.8: VISO PARCIAL DO DIAGRAMA DE PSEUDO-CLASSES DO SISTEMA DE LOCAES DE VDEOS
.................................................................................................................................................. 76
FIGURA 3.4.9: TELA CORRESPONDENTE AO CADASTRO DE CLIENTES DO SISTEMA DE LOCAES DE VDEOS
.................................................................................................................................................. 77
FIGURA 3.4.10: DIAGRAMA DE USE CASES DO MASA RELATIVO A INTERFACE DA FIGURA 3.4.9 ............. 78
FIGURA 3.4.11: DESCRIO DO
CLIENTESBTNPRINTLOCACOESCLICK ...................................... 79
FIGURA 3.4.12: VISO PARCIAL DO DIAGRAMA DE CLASSES DO SISTEMA DE LOCAES DE VDEOS.........83
FIGURA 3.4.13: VISO PARCIAL DA LISTA DE MAPEAMENTO MASA X MAS DO SISTEMA DE LOCAES DE
VDEOS ....................................................................................................................................... 83
FIGURA 3.4.14: VISO PARCIAL DA LISTA DE CORRESPONDNCIA DE MTODOS ANMALOS................... 84
-
8/3/2019 Engenharia de Software e Reversa
10/171
FIGURA 3.4.15: VISO PARCIAL DO DIAGRAMA DE 8
& $
APS ABSTRAO NO MAS..................... 86
FIGURA 3.4.16: VISO PARCIAL DA LISTA DE MAPEAMENTO DE 8
&
...........................................86
FIGURA 3.4.17: DESCRIO DO
ATUALIZAR .......................................................................... 87
FIGURA 3.5.1: VISUALIZAO PARCIAL DO DIAGRAMA DE CLASSES DE PROJETO....................................90
FIGURA 3.5.2: DIAGRAMA DE SEQNCIA RELATIVO AO
ATUALIZAR........................................91
FIGURA 3.5.3: VISO PARCIAL DA DECLARAO DA CLASSE CLIENTE .....................................................93
FIGURA 3.5.4: IMPLEMENTAO DOS MTODOS DA CLASSE CLIENTE .....................................................93
FIGURA 3.5.5: DECLARAO DA CLASSE DE ACESSO AOS DADOS DERIVADA DA CLASSE CLIENTE..........95
FIGURA 3.5.6: COMPONENTES DE ACESSO DIRETO A DADOS QUE ORIGINARAM A INTERFACE DO SOFTWARE
LEGADO ...................................................................................................................................... 97
FIGURA 3.5.7: INTERFACE DE CLIENTES DO SISTEMA DE LOCAES DE VDEO APS A REENGENHARIA OO
.................................................................................................................................................. 97
FIGURA 4.4.1: COMPOSIO DE PARTE DA LISTA DE PROCEDIMENTOS E FUNES ..............................109
FIGURA 4.4.2: COMPOSIO DE PARTE DA LISTA "CHAMA/CHAMADO POR"..........................................111
FIGURA 4.4.3: COMPOSIO DA LISTA DE TABELAS E CHAVES ............................................................114
FIGURA 4.4.4: MODELO ENTIDADE-RELACIONAMENTO DO ESTUDO DE CASO ........................................115
FIGURA 4.4.5: COMPOSIO DA LISTA DE ANOMALIAS ........................................................................ 116
FIGURA 4.4.6: APRESENTAO DOS RELACIONAMENTOS NO DIAGRAMA DE PSEUDO-CLASSES .............118
FIGURA 4.4.7: COMPOSIO DAS PSEUDO-CLASSES........................................................................... 119
FIGURA 4.4.8: VISUALIZAO PARCIAL DO DIAGRAMA DE 8
&
PARA O ATOR CLIENTE................120
FIGURA 4.4.9: ORIGEM DO
CREDBTNPGCLICK ...................................................................... 120
FIGURA 4.4.10: DESCRIO DO
CREDBTNPGCLICK ..............................................................121
FIGURA 4.4.11: VISUALIZAO PARCIAL DA VERSO 1.0 DA LISTA DE MAPEAMENTO MASA X MAS......125
FIGURA 4.4.12: EXEMPLO DE UM PROCEDIMENTO SEM ANOMALIAS QUE FOI CONVERTIDO EM DOIS
MTODOS ................................................................................................................................. 125
FIGURA 4.4.13: EXEMPLO DE PROCEDIMENTOS SEM ANOMALIAS QUE NO FORAM CONVERTIDOS EM
MTODOS ................................................................................................................................. 126
FIGURA 4.4.14: DIAGRAMA DE CLASSES APS A ABSTRAO DO MASA..............................................126
FIGURA 4.4.15: COMPOSIO DA LISTA DE CORRESPONDNCIA DE MTODOS ANMALOS................... 127
FIGURA 4.4.16: 8
INSERIRCOR DO MAS............................................................................... 128
FIGURA 4.4.17: VISUALIZAO DA DESCRIO DO
INSERIRCOR............................................129
FIGURA 4.5.1: VISUALIZAO PARCIAL DO DIAGRAMA DE CLASSES DE PROJETO..................................131
FIGURA 4.5.2: DIAGRAMA DE SEQNCIA DO
INSERIRCOR ...................................................132FIGURA 4.5.3: DOCUMENTAO ELABORADA NA INTERFACE DA CLASSE "COR" ....................................133
FIGURA 4.5.4: VISUALIZAO PARCIAL DA DOCUMENTAO DOS MTODOS DA CLASSE "COR" ..............133
FIGURA 4.5.5: VISUALIZAO PARCIAL DA INTERFACE DA CLASSE "DBCOR".........................................134
FIGURA 4.5.6: VISUALIZAO PARCIAL DA IMPLEMENTAO DA CLASSE "DBCOR"................................134
FIGURA 4.5.7: INTERFACE LEGADA REFERENTE TELA DE CORES ....................................................... 135
FIGURA 4.5.8: INTERFACE RE-IMPLEMENTADA REFERENTE TELA DE CORES .......................................136
FIGURA 5.4.1: CDIGO-FONTE LEGADO QUE PROV A INSERO DE NOVAS QUANTIDADES EM ESTOQUE142
-
8/3/2019 Engenharia de Software e Reversa
11/171
FIGURA 5.4.2: CORRESPONDNCIA ENTRE AS OPERAES DO SOFTWARE LEGADO E OS
MTODOS/EVENTOS ORIGINADOS APS A REENGENHARIA............................................................143
FIGURA 5.4.3: CDIGO-FONTE OO QUE PROV A INSERO DE NOVAS QUANTIDADES EM ESTOQUE .....143
FIGURA 5.4.4: CDIGO-FONTE LEGADO COM REPETIO DA FUNCIONALIDADE DE LOCALIZAR UM CLIENTE
................................................................................................................................................ 144
FIGURA 5.4.5: ABAS DO AMBIENTE DELPHI COM COMPONENTES DE ACESSO DIRETO AOS DADOS .......... 145
FIGURA 5.4.6: VISUALIZAO PARCIAL DA INTERFACE DA CLASSE "DBCLIENTE"...................................145
FIGURA 5.4.7: INTERFACE ORIENTADA A OBJETOS .............................................................................. 146
-
8/3/2019 Engenharia de Software e Reversa
12/171
Lista de Qu ad ros
QUADRO 2.8.1: DOCUMENTOS QUE COMPEM O PROJETO SPICE (CORTS, 2001) ...........................24
QUADRO 2.8.2: NVEIS DE CAPACIDADE ATRIBUTOS DE PROCESSOS DO SPICE (ROUT, 1998)............26
QUADRO 2.8.3: RESULTADO DAS MODIFICAES NOS DOCUMENTOS DO SPICE (CORTS, 2001) .......26
QUADRO 2.8.4: CARACTERSTICAS DOS NVEIS DE MATURIDADE DO SW-CMM (FIORINI
., 1998) 28QUADRO 2.9.1: DIAGRAMA DEFINIDOS PELA UML................................................................................. 37
QUADRO 3.3.1: MODELO PARA A DOCUMENTAO DO LEVANTAMENTO DE ATIVIDADES ..........................48
QUADRO 3.3.2: MODELO PARA A DOCUMENTAO DO PLANO DE REENGENHARIA ..................................50
QUADRO 3.3.3: MODELO PROPOSTO PARA O REGISTRO DAS INSPEES DE ACOMPANHAMENTO DO
PROCESSO.................................................................................................................................. 55
QUADRO 3.3.4: MODELO PROPOSTO PARA A DOCUMENTAO DAS INSPEES DE GARANTIA DA QUALIDADE
.................................................................................................................................................. 57
QUADRO 3.3.5: MODELO PROPOSTO PARA O CONTROLE DE CONFIGURAO .........................................59
QUADRO 3.3.6: MODELO PROPOSTO PARA A DOCUMENTAO DAS % #
DO PROJETO ................... 60
QUADRO 3.4.1: MODELO PARA MONTAGEM DA LISTA DE PROCEDIMENTOS E FUNES ..........................65
QUADRO 3.4.2: FORMATO DA LISTA CHAMA/CHAMADO POR. ADAPTADO DE (PENTEADO, 1996A).....67
QUADRO 3.4.3: MODELO PARA DOCUMENTAO DAS TABELAS DE DADOS..............................................70
QUADRO 3.4.4: CRITRIOS PARA CLASSIFICAO DAS ANOMALIAS EM PROCEDIMENTOS E FUNES .......73
QUADRO 3.4.5: MODELO PARA CONSTRUO DA LISTA DE ANOMALIAS .................................................73
QUADRO 3.4.6: MODELO DA LISTA DE MAPEAMENTO MASA X MAS .....................................................81
QUADRO 3.4.7: MODELO PARA A LISTA DE CORRESPONDNCIA DE MTODOS ANMALOS......................82
QUADRO 3.4.8: MODELO PARA DOCUMENTAO DA LISTA DE MAPEAMENTO DOS 8
& $
................85
QUADRO 4.3.1: LEVANTAMENTO DE ATIVIDADES DO SOFTWARE LEGADO ............................................103
QUADRO 4.3.2: PLANO PARA REALIZAO DA REENGENHARIA ............................................................105
QUADRO 4.4.1: DOCUMENTO DE INSPEO DE GARANTIA DA QUALIDADE DA LISTA DE PROCEDIMENTOS E
FUNES ................................................................................................................................. 109
QUADRO 4.4.2: VISUALIZAO PARCIAL DA VERSO 1.1 DA LISTA "CHAMA/CHAMADO POR" ................112
QUADRO 4.4.4: LISTA DE CONTROLE DE CONFIGURAO REFERENTE AO PASSO DE REVITALIZAO DA
ARQUITETURA........................................................................................................................... 112
QUADRO 4.4.5: PRIMEIRA%
ESTABELECIDA DURANTE A REALIZAO DO ESTUDO DE CASO .......112
QUADRO 4.4.6: DOCUMENTO DE INSPEO DE ACOMPANHAMENTO DO PROCESSO ............................. 113
QUADRO 4.4.7: INSPEO DE ACOMPANHAMENTO DE PROCESSO REALIZADA APS O TRMINO DO MASA
................................................................................................................................................ 122
QUADRO 4.4.8: SEGUNDA %
DO ESTUDO DE CASO .................................................................. 122
QUADRO 4.4.9: VISUALIZAO PARCIAL DA LISTA DE MAPEAMENTO DE 8
& # $
............................. 128
QUADRO 4.4.10: DOCUMENTO RELATIVO TERCEIRA INSPEO DE ACOMPANHAMENTO DO PROCESSO 129
QUADRO 4.4.12: TERCEIRA %
DE PROJETO ........................................................................... 130
-
8/3/2019 Engenharia de Software e Reversa
13/171
Lis ta de Abr evia tu ra s e Sigla s
IDEAL Initiating, Diagnosing, Establishing, Acting, Learning
IEC International Engineering Consortium
IS International Standard
ISO International Organization of Standardization
KPA Key Process Area
PDCA Plan, Do, Check, Act
SEI Software Engineering Institute
SPICE Software Process Improvement and Capability dEtermination
SQL Structured Query Language
SW-CMM Capability Maturity Model for Software
UML Unified Modeling Language
-
8/3/2019 Engenharia de Software e Reversa
14/171
1
Ca ptu lo 1 .In tr odu o
&RQVLGHUDo}HV,QLFLDLV
Muitas organizaes tm enfrentado problemas com o uso e a manuteno de
sistemas de software construdos para serem executados em uma variedade de tipos de
hardware e programados em linguagens obsoletas. Com o passar do tempo, a tarefa de
realizar a manuteno torna-se mais complexa e mais cara e, ainda, esses sistemas
tornam-se cada vez mais desorganizados devido s inmeras tentativas de adaptaes e
incluses de novas funcionalidades (TILLEY, 1998). H ainda muitos softwares nessa
situao devido rpida evoluo das ferramentas, tecnologias e mtodos conseguida
pelas indstrias de computadores e empresas de tecnologia da informao (OLSEM,
1998). Sendo assim, as organizaes tm trs alternativas: manter os softwares legados
com a situao j descrita de desorganizao e custos cada vez maiores, redesenvolver
os softwares ou realizar a reengenharia tanto para aumentar sua manutenibilidade quanto
para implementa-los em um paradigma mais atual com ou sem mudana de linguagem.
No caso de manter um software legado, apenas efetuando-se as manutenes para
que o mesmo continue operando, muitos problemas podem ser citados: a alocao de
pessoal para essa tarefa que, segundo PRESSMAN (2000), pode chegar a mais de 60%
do esforo de uma organizao, alm da falta de sua documentao, comum nesses
casos e que torna ainda mais crtica a situao.
A opo pelo redesenvolvimento de um software legado tambm tem problemas
associados. O fato de que software tm as regras de negcios embutidas, que podem
no estar documentadas e a possibilidade das pessoas que as dominam no estarem
mais na empresa, faz com que o seu completo redesenvolvimento no seja confivel
(QUINAIA, 1999). Alm disso, outro problema dessa opo o custo do
redesenvolvimento global do software, geralmente muito alto, consumindo tempo e
recursos que, na maioria das vezes, as empresas no dispem (OLSEM, 1998).
A engenharia reversa e/ou reengenharia so as formas que muitas organizaes
esto buscando para manter/refazer seus softwares, livrando-se das manutenes
-
8/3/2019 Engenharia de Software e Reversa
15/171
Captulo 1. Introdu o 2
difceis e da degenerao de suas estruturas. Por esse motivo, importante que o
resultado desse processo seja confivel.
Na ltima dcada, o fator qualidade com relao ao processo de desenvolvimento
de software foi bastante estudado tendo sido elaborados vrios modelos de melhoria e
amadurecimento do mesmo, o que elevou sua capacitao para a gerao de software.Assim, no processo de reengenharia a garantia da qualidade tambm foi encarada como
mais uma etapa do processo.
Segundo CORTS (2001), a definio de um processo completo de software deve
incluir atividades de controle de projeto, garantia da qualidade, gerenciamento de
configurao, alm de ferramentas e mtodos de engenharia de software. Essa
dissertao pretende estudar e aplicar esses aspectos a um processo de reengenharia
de forma a torn-lo completo.
A definio de padres de reengenharia tm sido abordada por diversos autores
atualmente, pela necessidade da existncia de diretrizes mais consistentes para guiar na
realizao do processo.
&RQWH[WXDOL]DomRH2EMHWLYRVGD3HVTXLVD
Esse trabalho tem por objetivo definir e documentar um processo para realizao
da reengenharia de sistemas legados implementados em Delphi sem caractersticas
orientadas a objetos. Aps a reengenharia o sistema mantm a linguagem 2EMHFWPascal
utilizando, porm, os recursos orientados a objetos presentes no ambiente Delphi. O
processo est organizado na forma de padres, relacionados s etapas de engenharia
reversa e engenharia avante e, ainda, qualidade de processo. Dessa forma, o sistema
aps sua reengenharia reflete a mesma funcionalidade do legado, tendo sido aplicadas
as prticas de qualidade de processo.
O mtodo Fusion/RE (PENTEADO, 1996a) (PENTEADO HW DO ., 1996b) foielaborado para a realizao da engenharia reversa orientada a objetos em softwares
originalmente desenvolvidos de acordo com o paradigma procedimental. Mais tarde,
algumas extenses visando a realizao de reengenharia foram a ele incorporadas
(PENTEADO HWDO., 1998a), sem que muitos detalhes fossem fornecidos o que dificultou o
processo por parte dos engenheiros de software menos experientes.
-
8/3/2019 Engenharia de Software e Reversa
16/171
Captulo 1. Introdu o 3
Como primeiro passo da reengenharia, de acordo com o Fusion/RE, feita a
engenharia reversa, que identifica os componentes do software legado e os representa
em um nvel mais alto de abstrao, para fins de re-documentao ou de recuperao do
projeto (CHIKOFSKY, 1990). Aps a obteno desses modelos, em nvel de anlise,
pode ser aplicada a engenharia avante com mudana de paradigma de procedimental
para orientado a objetos, preservando a funcionalidade do software e a linguagem de
programao (PENTEADO HWDO., 1999).
Com a aplicao do Fusion/RE em sistemas legados implementados em diferentes
linguagens procedimentais notou-se que o modelo de processo utilizado, seqencial
linear, no o mais apropriado. Como o retorno a fases anteriores necessrio para que
se obtenha completamente os modelos orientados a objetos em nvel de anlise, o
modelo de processo evolutivo torna-se mais adequado. Entende-se por processo
evolutivo, aquele atravs do qual possvel retornar a passos j realizados de acordo
com a necessidade de refinamento de produtos, interagindo com outros produtos j
elaborados.
Assim, este trabalho faz a adequao dos passos do Fusion/RE ao modelo
evolutivo e utiliza os digramas UML (8QLILHG0RGHOLQJ/DQJXDJH) (QUATRANI, 1998) ao
invs dos diagramas Fusion (COLEMAN HWDO., 1994). A engenharia avante tambm
incorporada ao processo global realizado de acordo com o modelo evolutivo gerando
uma evoluo do Fusion/RE.
A qualidade de processo, comentada anteriormente, desafio tambm no processo
de reengenharia. Dessa forma, a aplicao de modelos de melhoria da qualidade,
originalmente utilizados no processo de desenvolvimento de software, em apoio ao
processo de reengenharia tambm utilizada neste trabalho, com o objetivo de tornar o
processo de reengenharia orientada a objetos mais eficiente e maduro.
Optou-se por descrever esse processo utilizando-se padres, pelo fato de tornarem
o aprendizado, pelos engenheiros de software, mais fcil dado seu formato padronizado,descrito em sees pr-definidas e j utilizado em trabalhos de vrios autores. Dessa
forma, este trabalho prope um Processo de Reengenharia Orientada a Objetos,
denominado PRE/OO, com todas as caractersticas acima descritas esperando auxiliar
engenheiros de software a realizar a reengenharia de sistemas legados, obtendo sua
completa re-estruturao, de forma facilitada.
-
8/3/2019 Engenharia de Software e Reversa
17/171
Captulo 1. Introdu o 4
Vale ressaltar que a segmentao de um software legado, reengenharia em que
preservada a linguagem de implementao, somente com adaptaes de caractersticas
orientadas a objetos, tambm pode ser realizada pelo PRE/OO. Um sistema exemplo,
implementado em Delphi, utilizado para mostrar a segmentao aplicando-se o
PRE/OO.
0RWLYDomRGD0RQRJUDILD
O desenvolvimento de software comerciais para pequenas empresas, utilizando
linguagens como &OLSSHUe Pascal, tem sido realizado pela autora deste trabalho desde o
trmino de sua graduao. A necessidade de migrar software implementados nessas
linguagens para ambientes com caractersticas orientadas a objetos, de forma facilitada,
foi um dos motivos para a realizao deste trabalho. Aliado a isso, o interesse em que
esses desenvolvimentos e migraes para outros ambientes e linguagens fossem feitos
com qualidade e com o uso adequado de ferramentas foi evidenciado. Dessa forma, o
tema de pesquisa aqui apresentado foi proposto, uma vez que h um conjunto de
sistemas que pode servir para a aplicao e avaliao do PRE/OO.
2UJDQL]DomRGD'LVVHUWDomR
Esta dissertao est organizada da seguinte forma: no Captulo 2 encontra-se o
levantamento bibliogrfico elaborado a respeito dos assuntos relevantes para a execuo
deste trabalho. No Captulo descrito o processo de reengenharia orientada a objetos
(PRE/OO), por meio de FOXVWHUV de padres; no Captulo 4 um estudo de caso
desenvolvido em Delphi sem considerar os aspectos orientados a objetos utilizado para
exemplificar a aplicao do PRE/OO. No Captulo 5 apresentam-se consideraes quanto
s estimativas de custo e esforo observadas quando da aplicao do PRE/OO e no
Captulo 6 so tecidos comentrios finais sobre o trabalho realizado e indicados trabalhos
futuros que podem dar continuidade a este.
-
8/3/2019 Engenharia de Software e Reversa
18/171
5
Cap tu lo 2.Reviso Bibliogrfica
&RQVLGHUDo}HV,QLFLDLV
Neste captulo so relatados os assuntos pertinentes pesquisa realizada
encontrados em publicaes especializadas e que se relacionam diretamente a este
trabalho. Os processos de engenharia reversa, segmentao e reengenharia, bem como
o Fusion/RE so descritos por formarem a base do trabalho. A manuteno de software
estudada para verificar como o processo de reengenharia pode auxili-la. Padres de
reengenharia so pesquisados por organizarem e facilitarem a transferncia de
conhecimento sobre o processo. A qualidade no processo de software abordada para
adapt-la ao processo de reengenharia e da UML so usados diagramas para a
documentao de modelos elaborados na reengenharia.
Na Seo 2.2 apresentado o processo de engenharia reversa. Na Seo 2.3
descrito o mtodo de engenharia reversa Fusion/RE; na Seo 2.4 apresentado o
processo de reengenharia; na Seo 2.5 a segmentao vista juntamente com alguns
estudos de caso desenvolvidos em trabalhos anteriores; na Seo 2.6 discutida a
manuteno de software e o papel da engenharia reversa e da reengenharia visando o
aumento de manutenibilidade; na Seo 2.7 so mostrados alguns trabalhos sobre
padres de reengenharia; na Seo 2.8 feita breve introduo ao ambiente de
desenvolvimento Delphi; na Seo 2.9 aborda-se a qualidade no processo de software. A
Seo 2.10 apresenta os conceitos da UML com o objetivo de ambientar o leitor aos
diagramas gerados em cada uma de suas fases e, finalmente, a Seo 2.11 apresenta as
consideraes finais.
(QJHQKDULD5HYHUVD
O termo engenharia reversa teve sua origem na anlise do hardware, em que a
prtica de extrao de projetos de produtos concludos comum, sendo aplicada para a
melhoria desses produtos e anlise de produtos de competidores (CHIKOFSKY, 1990).
Nesse contexto a engenharia reversa pode ser definida como o processo de
-
8/3/2019 Engenharia de Software e Reversa
19/171
Cap tulo 2. Revis o Bibliogr fica 6
desenvolvimento de um conjunto de especificaes para um sistema de hardware
complexo atravs do exame ordenado dos componentes do sistema (REKOFF, 1985).
Enquanto que para o hardware o objetivo tradicional da engenharia reversa
duplicar o sistema, para o software esse processo mais freqentemente utilizado para
se obter um suficiente entendimento do mesmo no nvel de desenvolvimento. Portanto,
define-se engenharia reversa para um software como o processo de anlise para
identificar seus componentes e inter-relacionamentos e criar representaes do mesmo
em outra forma ou num nvel mais alto de abstrao (CHIKOFSKY, 1990).
Abstrao pode ser definida como a tarefa de utilizar apenas assuntos relevantes
ao propsito em questo (OXFORD, 1986). Dois conceitos podem ser derivados, como
descrito a seguir e ilustrado na Figura 2.2.1.
Nvel de Abstrao: acontece entre as fases do ciclo de vida do software. Quantomais prximo se estiver da implementao, menor o nvel de abstrao e quanto
mais prximo da fase de especificao de requisitos, maior o nvel de abstrao;
Grau de Abstrao: acontece dentro de uma mesma etapa do ciclo de vida do
software. Se as informaes forem pouco detalhadas, o grau de abstrao alto. Se
as informaes forem bastante detalhadas, baixo o grau de abstrao
(CHIKOFSKY, 1990).
' ( 0 1 2 3 4 6 4 6 8 9 @ A B C D C F 2 3 1 I C Q S T U 2 3 W X Y ` Y b ( d D Y I C f ( I 3 I Y g Y7 h U i 3 2 C q b r s t u ' g t v w 8 x x y
Segundo CHIKOFSKY (1990), h duas categorias de engenharia reversa: a
redocumentao e a recuperao de projeto. A redocumentao, tambm chamada de
visualizao de cdigo, utilizada na criao de representaes a partir de informaes
obtidas apenas da anlise do cdigo fonte, com o objetivo de recuperar a documentao
-
8/3/2019 Engenharia de Software e Reversa
20/171
Cap tulo 2. Revis o Bibliogr fica 7
do software. A recuperao de projeto, tambm chamada de entendimento de programa,
utiliza alm do exame do cdigo, o conhecimento do domnio das informaes relativo ao
software e as dedues, com o objetivo de obter-se informaes com um nvel mais alto
de abstrao.
O entendimento de programas uma forma mais crtica de engenharia reversa,
pois tenta aproximar-se do raciocnio humano na busca de entendimento (QUINAIA,
1999).
Nos ltimos dez anos, as pesquisas a respeito da engenharia reversa produziram
mtodos para anlise de cdigo, incluindo decomposio de softwares, anlise das
dependncias estticas e dinmicas, uso de mtricas, alm da explorao e visualizao
do software (redocumentao). Entretanto, o cdigo do software no contm todas as
informaes necessrias sendo que o conhecimento sobre sua arquitetura e sobre o
domnio da aplicao, alm das restries implcitas que, geralmente, s existem na
mente de quem construiu e utilizou o software (WONG HWDO., 2000).
Com a engenharia reversa possvel abstrair informaes a partir do cdigo
existente e tambm do conhecimento e experincia dos usurios, produzindo
documentos consistentes com o cdigo fonte, melhorando o desenvolvimento
subseqente, facilitando a manuteno e a reengenharia. Entretanto, reprojetar e
documentar um sistema j existente tarefa bem mais difcil do que realizar um novo
projeto (PENTEADO HWDO., 1996b).
Para que as questes tcnicas relativas ao processo de engenharia reversa sejam
tratadas de forma mais efetiva, o processo deve tornar-se maduro, capaz de ser repetido,
e passvel de evoluo de modo que cada vez mais passos possam ser executados por
ferramentas automatizadas (WONG HWDO., 2000).
0pWRGR)XVLRQ5(
O Fusion/RE foi criado a partir do mtodo Fusion (COLEMAN HWDO., 1994) com o
objetivo de recuperar o projeto de softwares legados procedimentais em uma forma
orientada a objetos. Para a realizao do processo de engenharia reversa a partir desse
mtodo no h necessidade de se ter a documentao do software legado, pois
possvel recuperar o projeto atravs do cdigo fonte do software.
-
8/3/2019 Engenharia de Software e Reversa
21/171
Cap tulo 2. Revis o Bibliogr fica 8
O mtodo foi inicialmente desenvolvido consistindo de quatro passos que
correspondem fase de engenharia reversa (PENTEADO, 1996a) e, posteriormente,
mais dois passos correspondentes segmentao foram adicionados (PENTEADO HWDO.,
1998a) formando os seis passos resumidos a seguir:
1. Revitalizao da arquitetura do software legado: recuperada a documentaobsica do software, baseada na documentao disponvel a respeito do mesmo. Esse
processo pode ser conduzido de forma manual ou com o auxlio de ferramentas de
extrao. Como resultado desse passo tem-se uma lista de todos os procedimentos,
com sua descrio e hierarquia de chamadas (Lista Chama/Chamado por);
2. Recuperao do Modelo de Anlise do Sistema Atual (MASA): a partir das bases de
dados e do cdigo criado um pseudo modelo orientado a objetos do software
legado. Esse modelo pode ser entendido como uma abstrao orientada a objetos
preliminar, mesmo a implementao real tendo sido feita de acordo com o paradigma
procedimental. As estruturas de dados (seus relacionamentos e cardinalidades) so
recuperadas e modeladas como sendo pseudo-classes de objetos e os
procedimentos do cdigo legado so a base para a derivao dos mtodos. Muitos
dos procedimentos podem conter anomalias, ou seja, um mesmo procedimento pode
tratar com vrias estruturas de dados. H uma classificao para os procedimentos:
(o) observador, o procedimento ou a funo que somente consulta a estrutura de
dados,
(c) construtor, o procedimento ou a funo que altera a estrutura de dados ou
altera e consulta a estrutura de dados,
(i) implementao, o procedimento ou a funo que trata apenas de aspecto de
implementao, sem alterar ou consultar nenhuma estrutura de dados;
O sinal de + associado aos smbolos (o) ou (c), indica que o procedimento
observa e/ou consulta duas ou mais estruturas de dados. Desse modo, as
possveis classificaes para os procedimentos anmalos podem ser (o), (c), (oc),
(o+c), (oc+), (o+c+) ou (i);Aps a classificao dos procedimentos, so criados:
Modelo de Ciclo de Vida: retrata, atravs de expresses regulares, o
comportamento global do sistema,
Modelo de Operao: descreve detalhadamente cada operao do software de
forma textual,
-
8/3/2019 Engenharia de Software e Reversa
22/171
Cap tulo 2. Revis o Bibliogr fica 9
Modelo de Objetos: representa os conceitos existentes no domnio do problema e
suas relaes;
3. Criao do Modelo de Anlise do Sistema (MAS): os diagramas criados no passo
anterior so abstrados, as pseudo-classes do MASA so generalizadas e as
anomalias dos procedimentos so eliminadas, transformando um procedimentoanmalo em quantos mtodos forem necessrios;
4. Mapeamento do MAS para o MASA: so mapeados as classes, atributos e
procedimentos do MAS para os elementos correspondentes no MASA,
documentando-se inclusive as possveis incluses/excluses. Esse passo muito
importante para futuras manutenes e possvel reuso do software;
5. Elaborao do Projeto Avante: visa a elaborao dos modelos da fase de projeto
para que a engenharia avante seja feita mudando-se o paradigma de procedimental
para orientado a objetos, mantendo-se ou no a linguagem procedimental em uso. Os
diagramas gerados nesse passo so:
Grafo de Interao de Objetos: mostra quais objetos participam da execuo de
uma operao e a seqncia de troca de mensagens entre eles, sendo construdo
com base no Modelo de Operaes,
Grafos de Visibilidade: estabelecem a forma de comunicao entre as classes,
especificando a interface para troca de mensagens do sistema,
Descries de Classes: complementam o Modelo de Objetos do sistema,especificando quais os atributos de cada classe e sua interface externa,
Grafos de Herana: definem as especializaes existentes entre as classes
complementando as Descries de Classes;
6. Segmentao do Sistema: os procedimentos com anomalias so transformados em
mtodos. O cdigo examinado, dividido em mtodos e so inseridos comentrios
mostrando a correspondncia entre eles. Esse passo elaborado com base nos
diagramas do projeto avante do software.
Geralmente, aps a aplicao do mtodo Fusion/RE, percebe-se um aumento no
nmero de mtodos em relao aos procedimentos do software legado, porm esses so
sempre menores e organizados de forma a aumentar as possibilidades de reuso e
melhorar a manutenibilidade do software. Como j foi citado, a segmentao no altera a
linguagem de programao, mas o software gerado aps o processo pode, de maneira
-
8/3/2019 Engenharia de Software e Reversa
23/171
Cap tulo 2. Revis o Bibliogr fica 10
muito mais simples, ser transformado para uma linguagem orientada a objetos
(PENTEADO HWDO., 1998a).
A Figura 2.3.1 mostra os passos do mtodo Fusion/RE aps a incluso dos passos
5 e 6 referentes ao processo de engenharia avante.
' ( 0 1 2 3 4 6 6 8 9 T 1 C 3 I Y U Y I Y ' 1 T ( Y ` q @ Q u & 6 w 8 x x 3
-
8/3/2019 Engenharia de Software e Reversa
24/171
Cap tulo 2. Revis o Bibliogr fica 11
5HHQJHQKDULD
A reengenharia, segundo CHICOFSKI (1990), envolve basicamente duas etapas:
alguma forma de engenharia reversa (para se alcanar um nvel mais alto de abstrao)
e a engenharia avante ou reestruturao.
Esse processo indicado para os softwares que ainda tm alta utilidade, mas difcil
manuteno, sendo feito utilizando-se mtodos que proporcionam maior qualidade ao
software. Atualmente, o uso da orientao a objetos tem mostrado uma boa perspectiva,
tanto para o desenvolvimento do software quanto para sua posterior manuteno.
De acordo com JACOBSON (1991), a reengenharia pode ser categorizada segundo
os cenrios nos quais ocorrem a transformao de softwares procedimentais para
softwares orientados a objetos:
5HHQJHQKDULD FRPSOHWD GD WpFQLFD GH LPSOHPHQWDomR VHP DOWHUDomR GH
IXQFLRQDOLGDGH, em que o cenrio composto das seguintes etapas:
s Preparao do modelo de anlise, com base no software a ser reconstrudo;
s Mapeamento de cada objeto de anlise para a implementao do software antigo;
s Reprojeto do software utilizando-se metodologias orientadas a objetos;
5HHQJHQKDULD SDUFLDO VHP DOWHUDomR GD IXQFLRQDOLGDGH, em que o cenrio
parcialmente alterado, de modo que o software parea ser totalmente orientado a
objetos. Consiste das etapas:
s Identificao das partes do software que sero re-implementadas usando-se a
orientao a objetos;
s Preparao de um modelo de anlise das partes selecionadas anteriormente;
s Mapeamento de cada objeto modelado a partir da antiga implementao do
software;
s Execuo dos passos anteriores at a interface entre as partes mantidas e
remodeladas do software se tornarem aceitveis;s Execuo em paralelo:
- Projeto do novo software e de sua interface com o antigo software,
- Modificaes no software antigo e adio da interface com o novo software;
s Integrao e teste das partes mantidas e re-implementadas do software;
5HHQJHQKDULD FRPDOWHUDomRGD IXQFLRQDOLGDGH. Esse cenrio de um processo
normal da engenharia avante, no qual so adicionadas novas funcionalidades ao
-
8/3/2019 Engenharia de Software e Reversa
25/171
Cap tulo 2. Revis o Bibliogr fica 12
software e o mesmo re-implementado com o uso de uma tcnica orientada a
objetos. As principais etapas deste cenrio so:
s Alterao no modelo de anlise de acordo com os requisitos incorporados ao
software;
s
Reprojeto do software.
Segundo SOMMERVILLE (1995), a categorizao da reengenharia se d de acordo
com a abrangncia que esse processo ir ter com relao ao software:
&RQYHUVmRGRSURJUDPDIRQWH : a forma mais simples de reengenharia, na qual o
cdigo fonte escrito em uma linguagem traduzido para outra linguagem;
5HHVWUXWXUDomR GR SURJUDPD: aplicvel quando a estrutura do software est
corrompida dificultando seu entendimento. Por exemplo: existncia de funes
duplicadas ou nunca chamadas.
6HJPHQWDomR
Segmentao o processo de reengenharia com mudana da orientao de
procedimental para orientao a objetos, preservando-se as funcionalidades do software
e a linguagem de programao. Assim, realizada a adaptao do cdigo-fonte, de
acordo com os recursos disponveis na linguagem, de forma a implement-lo com
caractersticas orientadas a objetos (PENTEADO HWDO., 1999).
A segmentao, como visto anteriormente, pode ser conduzida seguindo-se o
Fusion/RE, sendo o ltimo passo desse mtodo. Esse passo foi subdividido em quatro
partes, executadas gradualmente e ao fim de cada uma so realizados testes funcionais
com o objetivo de garantir a preservao das funcionalidades do software (PENTEADO HW
DO., 1999). A seguir a segmentao resumidamente descrita:
1. So criadas as classes de acordo com o Modelo de Objetos obtido na terceira fase do
Fusion/RE (Obteno do MAS). Os mtodos sem anomalias so diretamenteinseridos nas classes correspondentes. Os mtodos anmalos tm escolhidas as
classes que melhor os representam e, ento, feita a insero. Alm disso, so
inseridas referncias a esses procedimentos nas classes que esses mtodos alteram
e/ou observam;
2. feita a quebra dos mtodos anmalos em vrios sendo que cada um passa a alterar
ou observar apenas uma classe, qual posteriormente associado;
-
8/3/2019 Engenharia de Software e Reversa
26/171
Cap tulo 2. Revis o Bibliogr fica 13
3. So criados os mdulos que contm as descries das classes e os prottipos de
mtodos associados a elas. Da so criados os mdulos que contm a
implementao de cada classe;
4. So criadas as classes dependentes do tipo de implementao usada, como: pilhas,
listas ou rvores.
O processo de segmentao varia de acordo com a linguagem procedimental
utilizada, em relao ao modo de implementao de suas estruturas de dados e dos
recursos computacionais a serem utilizados com o objetivo de tornar o cdigo pseudo-
orientado a objetos. A seguir, so citados dois trabalhos que mostram o processo de
segmentao e os resultados obtidos em sistemas reais (PENTEADO HW DO., 1998a)
(PENTEADO HWDO., 1998b).
O primeiro sistema, com 20000 linhas de cdigo em &OLSSHU para controle de
oficinas mecnicas e eltricas, possuia como documentao apenas a Lista
Chama/Chamado Por e a descrio das tabelas relacionais.
Nesse estudo verificou-se que algumas caractersticas do &OLSSHU dificultaram a
simulao da orientao a objetos como a falta de uma estrutura de dados que pudesse
substituir o conceito de classes. Foi, ento, realizada a simulao do conceito de classes
com a insero de todos os mtodos pertencentes a uma classe no mesmo arquivo
fsico. A ltima fase desse estudo foi a transformao do cdigo segmentado em &OLSSHU
para a linguagem Java com a ferramenta Draco-Puc.
O segundo trabalho, foi a segmentao do ambiente StatSim, um sistema com
30000 linhas de cdigo implementado em C e ;YLHZ que permite a edio e a simulao
de VWDWHFKDUWV. O processo foi realizado considerando os modelos orientados a objetos
obtidos durante a engenharia reversa.
0DQXWHQomRA manuteno de software uma das fases mais problemticas de seu ciclo de
vida, caracterizando-se por um alto custo e baixa velocidade de implementao. Porm,
uma atividade inevitvel, principalmente tratando-se de softwares teis, para os quais os
usurios constantemente solicitam mudanas e agregaes de novas funcionalidades
(BENNET HWDO, 2000).
-
8/3/2019 Engenharia de Software e Reversa
27/171
Cap tulo 2. Revis o Bibliogr fica 14
Segundo PRESSMAN (2000), pode-se classificar a manuteno de software em
quatro categorias principais:
0DQXWHQomR&RUUHWLYDalterao de um software de forma a corrigir seus defeitos e
assim garantir a continuidade de sua operao;
0DQXWHQomR $GDSWDWLYD adio ou modificao de funcionalidades um softwarepara adapt-lo s mudanas ocorridas em seu ambiente;
0DQXWHQomR (YROXWLYD incluso de novas funcionalidades ao software alm das
originais a pedido do usurio;
0DQXWHQomR 3UHYHQWLYDmudana do software para tornar sua manuteno mais
fcil (aumento da manutenibilidade).
Entre os principais fatores da dificuldade de entendimento de um software
encontram-se a parcial ou completa inexistncia de documentao e/ou sua
desatualizao. Desse modo, observa-se que a manutenibilidade de software est
fortemente relacionada com a disponibilidade de documentao atualizada sobre o
mesmo (COSTA, 1996).
A engenharia reversa e, posteriormente, a segmentao podem ser utilizadas com
grande proveito no entendimento e na re-documentao de software, de forma a
melhorar sua manutenibilidade, sendo uma forma de manuteno preventiva.
3DGU}HVSDUD5HDOL]DomRGH5HHQJHQKDULD
Segundo DEMEYER HWDO. (1999, 2000a e 2000b), os sistemas legados no esto
limitados ao paradigma procedimental e a linguagens como COBOL. Atualmente
encontram-se sistemas legados orientados a objetos implementados em C++, 6PDOOWDON
ou Java. Originalmente, a orientao a objetos prometeu a construo de sistemas mais
flexveis e de fcil evoluo. Porm, notou-se que esses sistemas legados precisam
passar pelo processo de reengenharia com o objetivo de satisfazerem novos requisitos,tornarem-se mais flexveis ou, simplesmente, seguir o projetoorientado a objetos. Dessa
forma, os autores criaram uma linguagem de padres, a qual pode ser utilizada no
somente no processo de engenharia reversa, como tambm durante a reengenharia de
sistemas como alternativa de prover a reestruturao de sistemas orientados a objetos.
Os padres apresentam o seguinte formato: 1RPH, ,QWXLWR, &RQWH[WR, 3UREOHPD,
6ROXomR, ([HPSORV, $YDOLDomR, -XVWLILFDWLYD, 3DGU}HV 5HODFLRQDGRV, 8VRV
-
8/3/2019 Engenharia de Software e Reversa
28/171
Cap tulo 2. Revis o Bibliogrfica 15
&RQKHFLGRV e &RQWH[WR 5HVXOWDQWH, os quais foram agrupados em quatro FOXVWHUV,
como mostra a Figura 2.7.1.
Cada FOXVWHUcontm padres tratando uma situao similar da engenharia reversa
e so os seguintes:
3ULPHLUR&RQWDWROs padres desse FOXVWHUdescrevem os procedimentos a serem
tomados pelo engenheiro de software no primeiro contato com o sistema legado;
(QWHQGLPHQWR,QLFLDO Os padres desse FOXVWHU descrevem como o engenheiro de
software pode obter o entendimento inicial do software, documentado principalmente
na forma de diagramas de classes;
&DSWXUD GH GHWDOKHV GRPRGHOROs padres desse FOXVWHU descrevem como o
engenheiro de software pode obter o entendimento detalhado de um particular
componente do software;
3UHSDUDomRGDUHHQJHQKDULDComo a engenharia reversa precede a reengenharia,
este FOXVWHU inclui alguns padres que auxiliam na preparao dos passos
subseqentes da engenharia avante.
' ( 0 1 2 3 4 6 6 8 9 Q 0 2 1 3 C ` U Y I Y T 1 3 U 2 Y I 3P D ( ` 0 1 3 0 C I C 3 I 2 l C T I C v & 6 q 4 y y y S
RECCHIA HW DO (2002b) criou a FaPRE/OO, uma famlia de padres para a
reengenharia orientada a objetos de sistemas legados procedimentais. Essa famlia
-
8/3/2019 Engenharia de Software e Reversa
29/171
Cap tulo 2. Revis o Bibliogr fica 16
formada por quatro FOXVWHUV cada um agrupando os padres relacionados a situaes
similares da engenharia reversa (3 FOXVWHUV) e da engenharia avante (1 FOXVWHU), descritos
a seguir e ilustrados na Figura 2.7.2.
' ( 0 1 2 3 4 6 6 4 9 n I 3 ' 3 e A D ( 3 I C 3 I 2 l C T I C C C ` 0 C ` o 3 2 ( 3 u u I C b b r s Q q 4 y y 4 3
&OXVWHU: Modelar os Dados do Legado: agrupa padres que extraem informaes
a partir dos dados e do cdigo fonte do sistema legado, de forma a conduzir as aes
do engenheiro de software durante o primeiro contato com o sistema;
&OXVWHU Modelar a Funcionalidade do Sistema: agrupa padres para obter a
funcionalidade do sistema legado, criando modelos que representam as Regras de
Negcios da Empresa e capacitando o engenheiro de software a obter um
entendimento detalhado dos componentes do sistema, aprofundando assim, sua
compreenso sobre estes;
&OXVWHUModelar o Sistema Orientado a Objetos: agrupa padres para se obter o
Diagrama de Classes e os Diagramas de Seqncia do sistema, atravs da interao
dos produtos obtidos pelos padres dos FOXVWHUV anteriores. O resultado de sua
-
8/3/2019 Engenharia de Software e Reversa
30/171
Cap tulo 2. Revis o Bibliogr fica 17
aplicao o MAS (Modelo de Analise do Sistema), modelo orientado a objetos que
serve como base ao processo de reengenharia;
&OXVWHUGerar o Sistema Orientado a Objetos: agrupa os padres de engenharia
avante, responsveis pela re-implementao do software legado a partir dos modelos
orientados a objetos gerados com a aplicao dos padres.
Segundo DUCASSE HWDO. (1998, 1999), quando um importante software legado no
pode mais evoluir naturalmente para satisfazer as mudanas nos requisitos ele,
freqentemente, submetido ao processo de reengenharia.
Os autores explicam que padres de reengenharia apresentam novas solues
para uma soluo legada recorrente que j no apropriada e descrevem como realizar
a migrao da soluo legada nova soluo. Citam, tambm, que padres de
reengenharia codificam e registram o conhecimento sobre como modificar softwares
legados: ajudam a diagnosticar problemas e identificar os pontos fracos que dificultam o
desenvolvimento adicional do sistema, alm de ajudar a encontrar solues mais
apropriadas aos novos requisitos. O formato de proposto para os padres de
reengenharia ilustrado a seguir:
1RPHGR3DGUmR Utiliza-se uma pequena sentena contendo um verbo que enfatiza
o tipo de transformao de reengenharia;
,QWXLWR Uma descrio do processo, juntamente com o resultado e por que o mesmo
desejvel;
$SOLFDELOLGDGH Indica quando o padro aplicvel ou no. Esta seo inclui:
s uma lista de sintomas: experincias na ocorrncia de reuso, manuteno ou
mudanas no sistema,
s uma lista de metas da reengenharia: qualidades aperfeioadas por meio da
aplicao do padro,
s uma lista de padres relacionados;
0RWLYDomRApresenta um exemplo concreto, o qual tem por objetivo familiarizar o
leitor para que este entenda melhor a apresentao mais abstrata do problema que
segue nas sees Estrutura e Processo. O exemplo deve explicar claramente a
estrutura do sistema de legado existente, a estrutura do sistema aps submetido ao
processo de reengenharia e a relao entre os dois, alm de descrever seu estado
antes e depois da aplicao do padro;
-
8/3/2019 Engenharia de Software e Reversa
31/171
Cap tulo 2. Revis o Bibliogr fica 18
(VWUXWXUDDescreve a estrutura do sistema antes e depois da reengenharia. So
identificados os Participantes e as Colaboraes. Nessa seo tambm so
discutidas as vantagens e desvantagens da estrutura alvo em comparao estrutura
inicial;
3URFHVVR Esta seo subdividida em trs partes: Deteco, Receita eDificuldades. Sabe-se que o cdigo, freqentemente, indica ao engenheiro de
software onde est o problema e o processo de reengenharia deve ter como objetivo
evitar que o cdigo resultante da reengenharia no obstrua o desenvolvimento
adicional. Porm, h casos em que pode ser interessante descobrir automaticamente
onde podem ser aplicados padres diferentes. A seo Deteco descreve mtodos e
ferramentas para descobrir quando o cdigo est sofrendo com problemas realmente
srios em que o processo escolhido pode ajudar a aliviar ou a resolver estes
problemas. A seo Receita diz como realizar a reengenharia e suas possveisvariantes. A seo Dificuldades discute situaes em que a reengenharia
impossvel ou sua aplicao comprometida por outros problemas existentes;
'LVFXVVmR Nesta seo, avaliada a relao entre o custo e o benefcio da
aplicao do padro. A soluo legada comentada para mostrar por que tal soluo
era boa num dado perodo de tempo mas, insuficiente ou inadequada para o
problema atual. Discute-se qual o custo para detectar este problema, sua magnitude e
o benefcio da aplicao do padro. Esta discusso deve ajudar o engenheiro de
software a decidir se a aplicao do padro ou no vivel neste caso especfico;
4XHVW}HV (VSHFtILFDV GD /LQJXDJHP Lista o que, especificamente, deve ser
solucionado para cada linguagem, verificando-se quais as dificuldades e facilidades
encontradas em cada uma.
POOLEY HWDO. (1998) apresentam a idia de padres de reengenharia de software,
adaptada a partir de padres de projeto, como forma de identificar procedimentos bem
sucedidos de projetos de reengenharia e a partir deles, criar padres disponveis para
uso em novos projetos. Segundo os autores, a vantagem da utilizao de padres dereengenharia em auxlio aplicao de metodologias, vem do fato de que em estudos
conduzidos atualmente, nos quais busca-se desenvolver metodologias de reengenharia,
a obteno de resultados tm sido extremamente dificultada pelo fato destas terem que
ser suficientemente genricas. Padres de reengenharia so propostos como maneira de
codificao e disseminao de boas prticas reengenharia de software facilitando a
compreenso e a utilizao das metodologias existentes.
-
8/3/2019 Engenharia de Software e Reversa
32/171
Cap tulo 2. Revis o Bibliogr fica 19
Segundo STEVENS HW DO. (1998), nem todos os sistemas legados so grandes
softwares desenvolvidos em COBOL. H muitos sistemas modernos originalmente bem
construdos de forma orientada a objetos ou baseados em componentes, porm de difcil
manuteno pelo fato de sua estrutura ter se tornado obscura por modificaes de vrios
anos. Nesse caso, a reengenharia pode ser uma soluo atrativa como forma de
reestruturao, mas a dificuldade em encontrar especialistas para a realizao desse
processo, dificulta a adoo dessa soluo. Segundo os autores, o desenvolvimento de
novos materiais e tcnicas poderia minimizar esse problema. Como contribuio, criaram
padres de reengenharia, que podem ser utilizados como um modo de transferir
conhecimentos dada a pouca quantidade de bibliografia nessa rea, em comparao com
as disponveis sobre o desenvolvimento de sistemas. Os padres funcionam como
unidades auxiliares na transferncia de conhecimento, por serem pequenos e especficos
a ponto da comunidade de especialistas poder valid-los efetivamente. O formato
adotado pelos autores para descrio dos padres propostos foi: 1RPH &RQWH[WR
3UREOHPD 6ROXomR H &RQVHTrQFLDV. O tamanho reduzido de cada padro torna
possvel sua utilizao em complemento s metodologias adotadas, porm no eliminam
a necessidade do uso das mesmas, mas influenciam e so influenciados por elas.
Os padres de reengenharia apresentados tm por objetivo comum o aumento da
facilidade da implementao desse processo, dada a forma padronizada e bem
documentada dos FOXVWHUV que o descrevem. Desse modo, prev-se a melhor
aplicabilidade por parte do engenheiro de software e, conseqentemente, maior
qualidade dos produtos gerados, ou seja, do software orientado a objetos resultante.
4XDOLGDGHQR3URFHVVRGH6RIWZDUH
O processo de software pode ser definido como o conjunto de ferramentas,
mtodos e prticas que so utilizados para desenvolver e manter o software e produtos
associados (FIORINI HWDO., 1998). E sob um processo bem definido que a estabilidade
no desenvolvimento do software pode ser instituda.
A capacitao em desenvolvimento de software pressupe a existncia de um
processo de software definido no qual aplicado um modelo de melhoria de processos.
O processo definido tem documentao que detalha o que feito, quando, por quem, o
que utilizado e o que produzido. A maturidade do processo indica at que ponto um
processo definido e implementado, utilizando para isso aspectos como mtricas para
verificao do controle e da eficcia.
-
8/3/2019 Engenharia de Software e Reversa
33/171
Cap tulo 2. Revis o Bibliogr fica 20
Neste sentido, a capacitao em desenvolvimento de software reflete o grau de
institucionalizao de uma infra-estrutura e da cultura relacionada aos mtodos, prticas
e procedimentos do desenvolvimento de software. Reflete, ainda, a qualidade do
processo, pois se sabe que a qualidade dos produtos de software depende diretamente
da qualidade do processo de desenvolvimento a eles associados.
PFLEEGER (1998) define qualidade a partir de como esta percebida em
diferentes perspectivas:
9LVmR 7UDQVFHQGHQWDO trata da qualidade como um conceito abstrato, que
dificilmente pode ser fixado com preciso. Qualidade representa uma caracterstica,
propriedade ou estado que torna um produto ou servio aceitvel;
9LVmRFRP%DVHQR9DORU agrega qualidade ao valor que o cliente esteja disposto a
pagar pelo produto, nesse caso, quanto maior o preo do produto, maior sua
qualidade;
9LVmR GR 8VXiULR concentra-se no usurio, tendo esse como fonte de toda a
avaliao da qualidade de um produto, a qualidade de um produto est condicionada
s vontades de seu consumidor;
9LVmR &HQWUDGD QR 3URFHVVR GH )DEULFDomR fixa-se no esforo realizado em
produzir um item de acordo com suas especificaes bsicas, determinadas durante
o projeto. Assim, se o processo de fabricao no pode desenvolver um produto
conforme suas especificaes, a qualidade estar comprometida logo no primeiro
esforo para produzi-lo.
FUGGETTA (2000) diz que os esforos necessrios para apoiar atividades de
melhoria de processo podem ser classificados como modelos de maturidade ou
estratgias de melhoria:
(VWUDWpJLDGHPHOKRULD define os passos pelos quais a melhoria pode ser obtida.
Especifica como avaliar um processo, iniciar aes corretivas e, tambm, promover
iniciativas para a implementao de novas melhorias. Um exemplo citado o IDEAL;
0RGHORGHPDWXULGDGH define o perfil ideal de um processo, ou seja, o conjunto
mnimo de exigncias que um processo deveria satisfazer para estar qualificado
dentro de um estado especfico. Como um exemplo de modelo de maturidade cita o
SW-CMM do 6RIWZDUH(QJLQHHULQJ,QVWLWXWH .
-
8/3/2019 Engenharia de Software e Reversa
34/171
Cap tulo 2. Revis o Bibliogr fica 21
Nas sees seguintes so apresentados mtodos de melhoria e estratgias de
maturidade conforme cita FUGGETTA (2000), os quais foram estudados para verificao
da possibilidade de incluso no PRE/OO.
(VWUDWpJLDVGH0HOKRULDGD4XDOLGDGH
,'($/,QLWLDWLQJ'LDJQRVLQJ(VWDEOLVKLQJ$FWLQJ/HDUQLQJ
O IDEAL prov uma forma til em passos seqenciais para o estabelecimento de
programa de melhoria bem sucedido. Seguindo suas fases, atividades e princpios, os
esforos de melhoria so beneficiados em muito (GREMBA, 1997) (McFEELEY, 1996). O
IDEAL consiste de cinco fases, visualizadas na Figura 2.8.1 e descritas a seguir:
, Inicializao: atravs de estmulos, estabelecida uma infra-estrutura visando a
melhoria dos processos;
' Diagnstico: gerado um diagnstico documentado das prticas atuais e
documentao para melhor-las;
( Estabelecimento: so estabelecidas e documentadas as estratgias e as prioridades,
so identificados os processos e os recursos necessrios e elaborado um plano de
ao para a melhoria do processo;
$ Ao: realizada a melhoria de acordo com o planejado. So definidos processos e
medies, os quais so planejados e executados;
/ Aprendizagem: so documentadas e analisadas as lies aprendidas e revista a
proposta organizacional.
' ( 0 1 2 3 4 6 6 8 9 T U 2 3 U 0 ( 3 s Q q F Q w 8 x x
-
8/3/2019 Engenharia de Software e Reversa
35/171
Cap tulo 2. Revis o Bibliogr fica 22
3'&$3ODQ'R&KHFN$FWLRQ
O PDCA uma estratgia para a resoluo de problemas agindo no auxlio do
encontro de solues atravs de um processo estruturado e ordenado, em que cada
passo depende da execuo do anterior (FAESARELLA HWDO., 1998) (McMANUS, 1996).
O ciclo PDCA tambm pode ser utilizado como auxiliar no gerenciamento da qualidade e
na verificao da aplicao dos conceitos e prticas da qualidade dentro de um
determinado contexto (CORTS, 2001). Este ciclo composto por quatro fases, as quais
so descritas a seguir e ilustradas na Figura 2.8.2:
3 Planejar: consiste em estabelecer metas sobre os resultados dos processos, as
maneiras e mtodos para atingi-las;
' Executar: trata de realizar as tarefas de acordo com o plano e coleta de dados para a
verificao do processo;
&Verificar: visa comparar os resultados alcanados com as metas planejadas;
$ Agir: objetiva atuar de forma a corrigir os desvios observados e prevenir futuras
ocorrncias.
FAESARELLA HWDO. (1998) citam o uso do PDCA na manuteno e melhoria dos
processos. Em processos no repetitivos, ele pode ser usado em melhorias do nvel de
desempenho, em que o plano consta de uma meta e um mtodo que descreve os
procedimentos necessrios para atingi-la.
' ( 0 1 2 3 4 6 6 4 9 b ( d D Y b Q q b Q u g w 8 x x 4
-
8/3/2019 Engenharia de Software e Reversa
36/171
Cap tulo 2. Revis o Bibliogr fica 23
0RGHORVGH0DWXULGDGH
Com o pressuposto de que o desenvolvimento de um software deve orientar-se
pelos princpios que regem as tcnicas e prticas de desenvolvimento de um produto,
HUMPHREY (1987a) sugere que a capacitao na produo de software busque:
processos bem definidos;
evoluo dos processos;
controle estatstico.
Segundo ROCHA HW DO (2001), para que o processo de software seja realizado
corretamente, deve apresentar:
procedimentos e mtodos que descrevam claramente a ligao entre as tarefas;
ferramentas e equipamentos para facilitar e automatizar o trabalho;
pessoas treinadas para poderem realizar as atividades.
A partir da necessidade de melhoria do processo de software foram definidos vrios
modelos e normas, entre eles podem ser citados a norma internacional NBR ISO/IEC
12207 (Tecnologia da Informao Processos de Ciclo de Vida do Software), o SPICE
6RIWZDUH3URFHVV,PSURYHPHQWDQG&DSDELOLO\G(WHUPLQDWLRQH o SW-CMM &DSDELOLW\
0DWXULW\ 0RGHO IRU 6RIWZDUH elaborado pelo SEI 6RIWZDUH (QJLQHHULQJ ,QVWLWXWH As
sees seguintes detalham os modelos e normas estudados para verificao do qualseria adaptado ao processo de reengenharia, o que resultou da escolha e uso do SW-
CMM.
,62,(&
Esta norma tem como objetivo principal auxiliar seus usurios a definir seus papis
na produo de software, atravs de processos bem definidos e de um melhor
entendimento das atividades a serem realizadas (ISO, 1995). A ISO 12207 divide os
processos relacionados ao ciclo de vida do software em trs classes de acordo com sua
natureza:
3URFHVVRV )XQGDPHQWDLV processos bsicos realizados desde a contratao do
fornecedor para a elaborao do software at sua manuteno durante o ciclo de vida:
Processo de Aquisio;
Processo de Fornecimento;
-
8/3/2019 Engenharia de Software e Reversa
37/171
Cap tulo 2. Revis o Bibliogr fica 24
Processo de Desenvolvimento;
Processo de Operao;
Processo de Manuteno;
3URFHVVRV GH $SRLR processos que auxiliam e contribuem para a qualidade do
projeto de software:
Processo de Documentao;
Processo de Gerncia de Configurao;
Processo de Garantia da Qualidade;
Processo de Verificao;
Processo de Validao;
Processo de Reviso Conjunta;
Processo de Auditoria;
Processo de Resoluo de Problemas;
3URFHVVRV 2UJDQL]DFLRQDLV processos empregados geralmente fora do domnio
dos projetos, mas que contribuem para a melhoria da organizao:
Processo de Gerncia;
Processo de Infra-Estrutura;
Processo de Melhoria;
Processo de Treinamento.
63,&(
O SPICE 6RIWZDUH3URFHVV,PSURYHPHQWDQG&DSDELOLW\G(WHUPLQDWLRQ foi lanado
com o objetivo de gerar normas para a avaliao de processos, visando a melhoria sua
contnua e a determinao de sua capacitao (ROCHA HWDO., 2001) (ROUT, 2000).
Os documentos do projeto SPICE foram organizados em um conjunto de nove
partes em forma de um relatrio tcnico ISO, sendo apenas as partes 2 e 3 normativas e
as demais apenas informativas, como mostra o Quadro 2.8.1.
z { | } | ~ z z z z z z { ~
3DUWH 'HVFULomR
1(Informativa) Contm o ponto de entrada dos documentos. Descreve aorganizao geral do SPICE.
2(Normativa) Descreve o modelo de duas dimenses, processos e suascapacidades.
-
8/3/2019 Engenharia de Software e Reversa
38/171
Cap tulo 2. Revis o Bibliogrfica 25
3(Normativa) Descreve os requisitos para a realizao de uma avaliao de formaque os resultados sejam repetveis.
4(Informativa) Fornece orientaes para a realizao de avaliaes em vrioscontextos.
5(Informativa) Ilustra um modelo de referncia detalhado para a realizao deavaliaes.
6 (Informativa) Descreve os requisitos para a qualificao de avaliadores.
7(Informativa) Apresenta orientaes no uso do modelo como guia na melhoria deprocessos.
8(Informativa) Apresenta orientaes no uso do modelo como guia em avaliaesda capacidade de um fornecedor em potencial.
9 (Informativa) Vocabulrio.
O modelo herdou da ISO 12207 a arquitetura dos processos e do ciclo de vida do
software e do SW-CMM o conceito de nveis de maturidade de processos, definindo
duas dimenses:
1. 'LPHQVmR GH 3URFHVVR corresponde definio de um conjunto de processos
fundamentais para a boa prtica da engenharia de software, sendo esse dividido em
cinco categorias de acordo com o tipo de atividade que cobre:
Cliente (CUS): tem impacto direto sobre o cliente;
Engenharia (ENG): especifica, implementa, ou mantm um sistema ou produto de
software;
Gerncia (MAN): estabelece o projeto, a coordenao e o gerenciamento dos
recursos;
Suporte (SUP): capacita e suporta a execuo de outros processos;
Organizao (ORG): estabelece as metas de negcios da organizao e o
processo de desenvolvimento, alm de avaliar os recursos que iro ajudar a
organizao a alcanar suas metas.
2. 'LPHQVmRGH&DSDFLGDGHcorresponde definio de um modelo de medio com
base na identificao de um conjunto de atributos que permite determinar a
capacidade do processo, esse modelo estabelece a escala em seis nveis (0 a 5) que
provem as definies das capacidades a eles relacionadas e o caminho para a
melhoria de qualquer processo. Cada nvel possui atributos que definem as
caractersticas do processo, os quais esto descritos no Quadro 2.8.2.
-
8/3/2019 Engenharia de Software e Reversa
39/171
Cap tulo 2. Revis o Bibliogr fica 26
z { | } | { z z z z ~ }
1tYHO 'HVFULomR $WULEXWRV
3URFHVVR
,QFRPSOHWR
O processo no est implementado, ou
falha para alcanar seus resultados. Nenhum atributo
3URFHVVR([HFXWDGR
O processo implementado e alcana
seus resultados. s Execuo de Processo
3URFHVVR
*HUHQFLDGR
O processo executado de forma
gerenciada (planejado, acompanhado,
verificado e ajustado) baseado em
objetivos definidos.
s Gerenciamento de
Performance
s Gerenciamento de
Produto de Trabalho
3URFHVVR
(VWDEHOHFLGR
O processo executado usando diretrizes
definidas baseadas nos princpios de
engenharia de software e capaz de
alcanar seus resultados.
s Definio de Processo
s Recursos de Processo
3URFHVVR3UHYLVtYHO
O processo executado de forma
consistente, dentro dos limites definidos
para alcanar seus resultados.
s Medidas de Processo
s Controle de Processo
3URFHVVR2WLPL]DGR
O processo muda dinamicamente e
adapta-se para satisfazer efetivamente as
metas de negcios projetadas.
s Mudanas de
Processo
s Melhoria Contnua
Em 1998, foi lanado um documento (SPICE, 1998) que atenuava
consideravelmente o choque com os modelos da qualidade j existentes As principais
mudanas so em relao ao volume de documentos, reduzido para cinco partes, como
mostra o Quadro 2.8.3.
z { | } | z z z z z z { ~
3DUWHV 'HVFULomR 2ULJHP
1 Conceitos e vocabulrio Antigas partes 1 e 9
2 Requisitos para a realizao de avaliaes Antigas partes 2 e 3
3 Guia para a realizao de avaliaes Antigas partes 4 e 6
4 Guia para a utilizao dos resultados de avaliaes Antigas partes 7 e 85 Modelo-exemplo para avaliaes Antiga parte 5
6:&00
Em 1987, o SEI lanou uma breve descrio de sua estrutura de maturidade de
processo (HUMPHREY, 1987a) e aps quatro anos de experincias, evoluiu essa
estrutura para o &DSDELOLW\0DWXULW\0RGHOIRU6RIWZDUH (PAULK HWDO., 1991). A evoluo
desse modelo baseou-se no conhecimento adquirido das avaliaes de processos de
-
8/3/2019 Engenharia de Software e Reversa
40/171
Cap tulo 2. Revis o Bibliogr fica 27
software e extensivo IHHGEDFN das organizaes e de rgos governamentais norte-
americanos que o utilizaram em nvel de testes (FIORINI HWDO., 1998).
A verso 1.0 de agosto de 1991 foi usada e revisada e em fevereiro de 1993 foi
lanada a verso 1.1 do SW-CMM, atualmente em uso (PAULK HWDO., 1993a) (PAULK HW
DO., 1993b). A partir da, o modelo tornou-se uma base para os programas de melhoria,
por sua posio de primeiro modelo de avaliao e capacitao definido, sendo usado
por desenvolvedores de outros modelos de melhoria (ROUT, 1998).
O SW-CMM foi desenvolvido em uma estrutura de estgios de maturidade, nveis
de melhoria crescente, visando alcanar um processo de software maduro. Cada nvel
compreende um conjunto de metas de processo que, quando satisfeitas, estabilizam um
importante componente do processo de software.
Essa estrutura est baseada nos princpios de gerncia de processos do TQM
7RWDO 4XDOLW\ 0DQDJHPHQW (DoD, 1988), que tratam da aplicao de mtodos
quantitativos e recursos humanos para melhorar:
o material e os servios fornecidos a uma organizao;
todos os processos dentro de uma organizao;
o grau de conhecimento das necessidades do cliente, agora e no futuro
(HUMPHREY, 1987b).
A Figura 2.8.3 mostra a estrutura dos nveis de maturidade do SW-CMM e o
Quadro 2.8.4, as caractersticas de cada nvel.
{ | } | z - & | ~
-
8/3/2019 Engenharia de Software e Reversa
41/171
-
8/3/2019 Engenharia de Software e Reversa
42/171
Cap tulo 2. Revis o Bibliogr fica 29
Com exceo do Nvel 1, cada nvel de maturidade composto por KPAs .H\
3URFHVV$UHDV. Essas reas-chave constituem a primeira diviso sistemtica dentro dos
nveis de maturidade, descrevendo as metas que devem ser atingidas e as questes que
devem ser tratadas para que se alcance essas metas e, com isso, o nvel de maturidade
pretendido.
A seguir so descritas as KPAs que devem ser implementadas para o alcance do
nvel 2 de maturidade (PAULK HWDO., 1993b):
*HUHQFLDPHQWR GH 5HTXLVLWRV Tem por finalidade definir de forma clara os
requisitos alocados ao software e controlar sua evoluo, de modo que sempre que
os requisitos forem alterados, os planos, os produtos de trabalho e as atividades
afetadas sejam ajustadas para se manterem consistentes. De acordo com (PAULK
HWDO., 1993b) os requisitos no se referem somente funcionalidade desejada para
o software, mas tambm s questes no funcionais, sendo definidos para o
software os UHTXLVLWRVIXQFLRQDLV, que especificam as funes que o software deve
ser capaz de executar e os UHTXLVLWRV QmRIXQFLRQDLV, acordos, restries e/ou
condies contratuais que afetam e determinam as atividades do software. Para o
Gerenciamento de Requisitos so definidas duas metas:
Meta 1:controlar e documentar os requisitos alocados e de forma a estabelecer
uma EDVHOLQH para uso gerencial;
Meta 2: manter os planos, produtos de trabalho e atividades de forma
consistente com os requisitos alocados.
De forma a documentar essa KPA, sugere-se a criao do Documento de Requisitos
Alocados em que so documentados os requisitos do software.
3ODQHMDPHQWRGR3URMHWRGH6RIWZDUH Envolve o desenvolvimento um plano para
desempenhar o trabalho, no qual so descritos, entre outros aspectos, as
responsabilidades e compromissos, as estimativas para o tamanho dos produtos de
trabalho e os recursos necessrios para todo o projeto. Para o Planejamento do
Projeto de Software so definidas trs metas:
Meta 1: documentar as estimativas a serem usadas no planejamento do projeto;
Meta 2: planejar e documentar as atividades e os compromissos do projeto;
Meta 3: obter a concordncia de todos os envolvidos no projeto com relao aos
compromissos assumidos.
$FRPSDQKDPHQWR H 6XSHUYLVmR GR 3URMHWR GH 6RIWZDUH Esta KPA tem por
finalidade verificar o progresso do projeto, comparando os resultados obtidos com o
-
8/3/2019 Engenharia de Software e Reversa
43/171
Cap tulo 2. Revis o Bibliogr fica 30
que foi documentado no Plano do Projeto (criado na KPA Planejamento do Projeto),
com relao s estimativas, aos compromissos e s atividades planejadas. Deve-se
documentar todas as diferenas encontradas, para posterior anlise e
acompanhamento at sua resoluo. Foram definidas trs metas para essa KPA:
Meta 1: acompanhar e confrontar os resultados da execuo do projeto com o
Plano do Projeto;
Meta 2: realizar aes corretivas sempre que os resultados reais se desviarem
do que foi planejado;
Meta 3: combinar as alteraes em compromissos assumidos entre todos os
envolvidos.
O SEI no especificou padres para documentao dessa KPA, mas necessria a
criao de um Relatrio de Acompanhamento para cada inspeo do progresso do
projeto. Em caso serem realizadas aes corretivas, um documento deve ser criado
citando o fato que gerou a ao corretiva, o contedo da ao corretiva, o
responsvel por sua execuo e a data de implementao da ao corretiva.
*DUDQWLD GD 4XDOLGDGH GH 6RIWZDUH Visa fornecer uma viso da eficcia dos
processos que esto sendo utilizados no projeto e dos produtos que esto sendo
gerados, o que envolve revisar e auditar os produtos de software e as atividades
para assegurar que esto em conformidade com as especificaes e planos
aprovados. So quatro as metas da KPA Garantia da Qualidade:
Meta 1: planejar as atividades de Garantia da Qualidade;
Meta 2: verificar a conformidade das atividades e dos produtos de trabalho
gerados com os procedimentos e requisitos alocados;
Meta 3: informar aos envolvidos no projeto com relao s atividades e
resultados da Garantia da Qualidade de Software;
Meta 4: notificar aos gerentes todas as no-conformidades que no possam ser
resolvidas no mbito do projeto de software.
Como na KPA Acompanhamento e Superviso do Projeto de Software, qualquer
desvio verificado nas atividades e produtos de software deve ser documentado e
tratado pela equipe de desenvolvimento de software de forma que voltem a refletir o
que foi planejado. A documentao desses desvios, contendo as aes corretivas a
serem implementadas, os responsveis pelas aes corretivas e o cronograma para
a realizao das mesmas deve ser gerada.
-
8/3/2019 Engenharia de Software e Reversa
44/171
Cap tulo 2. Revis o Bibliogr fica 31
*HUHQFLDPHQWRGH&RQILJXUDomRO propsito dessa KPA controlar as alteraes
e manter a integridade dos produtos de software gerados ao longo do ciclo de vida
do projeto. Devem ser selecionados os produtos de software que sero gerenciados,
ou seja, a configurao do software num dado momento. Os produtos de software
sob a gerncia de configurao so denominados itens de configurao. Todos os
itens de configurao so gerenciados e controlados, isso implica que existe uma
rgida disciplina com relao s alteraes feitas nesses itens, de forma a manter
conhecidas as diferenas entre cada uma de suas verses, o que motivou tais
alteraes e os responsveis pelas mesmas.
medida que o software desenvolvido, so estabelecidas EDVHOLQHV para os itens
de configurao, que servem de base para desenvolvimentos e alteraes futuras.
Cada EDVHOLQH formalmente estabelecida e documentada. O processo de
desenvolvimento de software segue ento de EDVHOLQH em EDVHOLQH, acumulando
itens de configurao novos ou revistos. As metas para o Gerenciamento de
Configurao so:
Meta 1: planejar as atividades de Gerenciamento de Configurao;
Meta 2: identificar, controlar e disponibilizar produtos de software selecionados;
Meta 3: controlar as alteraes nos produtos de software identificados;
Meta 4: informar as pessoas afetadas a respeito da situao e contedo das
EDVHOLQHV do software.
As alteraes nos itens de configurao devem ser formalizadas. Para isso, devem
existir Relatrios de Alteraes entregues ao responsvel pelo Controle de
Configurao aps as alteraes