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


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)


3/171

Dedicatria

'HGLFRHVWHWUDEDOKR

DRVPHXVSDLV

DRPHXPDULGR0iULR3UDGRHDRPHXILOKR0iULR/HPRV


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.


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.


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.


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


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


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


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


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


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


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


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


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


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.


16/171


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.


17/171


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.


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


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


20/171


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.


21/171


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,


22/171


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


23/171


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


24/171


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


25/171


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;


26/171


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


27/171


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


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


29/171


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


30/171


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;


31/171


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


32/171


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.


33/171


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 .


34/171


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


35/171


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


36/171


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;


37/171


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.


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.


39/171


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


40/171


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 - & | ~


41/171


42/171


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


43/171


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.


44/171


*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

engenharia de software e reversa

Documents