modernizaçãode software: indicadoresdograude degradação cristina pereira.pdfplano de medição...

Pontifícia Universidade Católica de São Paulo PUC-SP

Marcela Cristina Pereira

Modernização de Software: Indicadores do Grau deDegradação

São Paulo2017

Pontifícia Universidade Católica de São Paulo PUC-SP


Modernização de Software: Indicadores do Grau deDegradação

Dissertação apresentada à Banca Examina-dora da Pontífica Universidade Católica deSão Paulo, como exigência parcial para ob-tenção do título de MESTRE em Tecnologiasda Inteligência e Design Digital, na área deconcentração de Processos Cognitivos e Am-bientes Digitais, na linha de pesquisa de Mo-delagem de Sistemas de Software, sob a ori-entação do Prof. Dr. Ítalo Santiago Vega.

São Paulo2017


Modernização de Software: Indicadores do Grau de Degradação

Orientador

Professor

Professor

Agradecimentos

À Elaine Martins que me incentivou a entrar no mestrado quando o planoainda era muito inicial.A todas pessoas do meu trabalho que foram flexíveis quanto aos meus horáriospara que eu pudesse estudar.Aos meus amigos, César, Marcos e Marcele por entenderem minha ausênciaem muitos momentos importantes.A todas as pessoas que escutaram minhas ideias e leram o que eu escrevi, meauxiliando com suas opiniões.Ao meu orientador, Professor Ítalo Santiago Vega, por toda paciência e dedi-cação para que eu pudesse elaborar meu tema de pesquisa.À Edna Conti pela atenção e paciência dispensada com as minhas inúmerasperguntas.

ResumoMuitos sistemas de software utilizados pelas empresas tem como objetivo apoiar suas ati-vidades. Este apoio pode acontecer através de controles e/ou realização dos processos denegócio da empresa. Este tipo de software mecaniza atividades humanas e está inseridono meio ao qual modela. Como o ambiente organizacional é mutável, a aplicação precisaser alterada de acordo com as novas necessidades da empresa. Porém, estas alteraçõessão responsáveis pela degradação do software porque o torna cada vez mais complexo. Acomplexidade é limitadora para que novas modificações sejam realizadas sem existiremcustos e riscos elevados para a organização até que seja inviável manter o sistema de soft-ware. Existem abordagens, chamadas de modernização, que podem prolongar o tempo deuso do software até sua substituição. A pesquisa utiliza os conceitos de evolução, degra-dação e modernização de software para propor indicadores baseados nas necessidades doprocesso de negócio atendido pelo software para identificar o momento que a organizaçãoprecisa realizar ações para prolongar o tempo de uso da aplicação.

Palavras-chave: degradação de software, indicadores de degradação de software, evolu-ção de software, modernização de software

AbstractMany softwares, which are using by the companies, have the objective to support theirbusiness activities. This kind of support happens by means of processes controls and/oraccomplishment of business processes. The software used in the companies executes hu-mans being activities and it stays in the same environment of the business process. How-ever, the environment is not static, the software application needs change according thecompany needs. The software changings are necessary by his useful life and for by hisdegradation too, because the business process representation inside the software becomesmore complex. The complexity is one of the limitation to change the software with-out high cost and risks for organization until the impossibility of the his maintenance.There are many approaches to extend the use time of software until his replacing in thecompany. This research uses concepts like evolution, modernization and degradation ofsoftware with the objective to discuss and offer indicators metrics based in needs of busi-ness processes. The objective is identify which moment the company should makes planto do the modernization approaches for extend the time of software useful.

Keywords: software degratation,metrics of software degratation, software evolution,software modernization

Prefácio

Durante a elaboração do pré projeto de pesquisa, a percepção inicial era que exis-tia uma lacuna imensa na comunicação entre as áreas de negócio e desenvolvimento desoftware sobre as novas funcionalidades que deveriam ser implantadas na aplicação. Comousuária de software, minha experiência era de frequentemente receber as funcionalidadeem desacordo com as solicitações, além de existir atrasos nas entregas e o surgimentos denovos defeitos em funcionalidades que não deveriam ser alteradas. Enquanto elaborava opré projeto de pesquisa, vivenciava a substituição de um sistema de software que atendiavários processos dentro de uma organização altamente dependente dos seus softwares paraa entrega do seu produto aos clientes.

Esta substituição do software legado por outro novo foi um dos motivadores doestudo. Na prática, a lógica do negócio era mantida, porque o produto final permaneciaigual mesmo com a mudança do software. Acreditava-se que a lógica dos processamentosrealizados pela aplicação legada seria mantida. Naquele momento, a preocupação eracomo migrar os dados de uma aplicação para a outra devido aos inúmeros problemas deintegridade que isso poderia trazer para a informação. Ainda não se havia estudado osconceitos de modelagem das entidades do software e as ideias tinham como base conheci-mentos empíricos, como por exemplo, a dificuldade em encaixar as informações existentesno novo modelo de negócio que que deu base para o desenvolvimento do novo software.

Os estudos iniciais estavam focados em mecanismos automatizados de migraçãode dados de um software para o outro. Durante a leitura dos artigos, para justificar asubstituição do software e consequentemente a necessidade de migração de dados, foramsurgindo conceitos relacionados a modernização do software. Isso aconteceu porque amigração de dados era uma das abordagens de modernização que poderia estender o tempode uso da aplicação. Outras abordagens discutiam sobre a migração das funcionalidadesdo software e justificavam sua existência devido a degradação do software.

Durante dois anos, a pesquisa foi relacionando conceitos como: os tipos de softwa-res definidos por Lehman, as leis de evolução, ciclo de vida e a modernização de software.Com isso, a hipótese inicial, que os problemas nas alterações do software eram exclu-sivamente por falha de entendimento do desenvolvedor da aplicação, foi desfeita. Comtodo material estudado, foi possível entender que o software irá se degradar devido asinúmeras manutenções que ele passa durante o seu tempo de uso. Este entendimento fezcom que a pesquisa buscasse maneiras de identificar os efeitos da degradação do softwarena realização dos processos de negócio da empresa.

Com todos os conceitos estudados e tendo vivenciado o projeto de substituição de

um sistema de software, a elaboração do texto focou-se em demonstrar porque a construçãode indicadores sobre a degradação da aplicação é importante para decidir qual ação demodernização será realizada no software de acordo com o objetivo organizacional.

Lista de tabelas

Tabela 1 – Diferenças de preocupações entre manutenção e evolução de software . 20Tabela 2 – Leis de Lehman (GODFREY; GERMAN, 2014) . . . . . . . . . . . . . 23Tabela 3 – Abordagens de modernização de software(COMELLA-DORDA et al.,

2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Tabela 4 – Produto x Atributos de Software . . . . . . . . . . . . . . . . . . . . . 36Tabela 5 – Elaboração de Objetivos GQM . . . . . . . . . . . . . . . . . . . . . . 37Tabela 6 – Elementos do componentes GQM+Strategies . . . . . . . . . . . . . . . 39Tabela 7 – Elaboração dos objetivos organizacionais . . . . . . . . . . . . . . . . . 40Tabela 8 – Exemplo da elaboração do objetivo de negócio . . . . . . . . . . . . . . 48Tabela 9 – Elaboração de Objetivos GQM . . . . . . . . . . . . . . . . . . . . . . 48

Lista de ilustrações

Figura 1 – GQM+Strategies — Objetivo do negócio e objetivo do software . . . . 14Figura 2 – Interação entre o software e processos de negócios . . . . . . . . . . . 15Figura 3 – Ciclo de vida do software e-type de Lehman (1980) . . . . . . . . . . . 19Figura 4 – E-program ou E-type de Lehman (1980) . . . . . . . . . . . . . . . . . 19Figura 5 – Ambiente organizacional utilizando vários sistemas de software para a

realização do produto final . . . . . . . . . . . . . . . . . . . . . . . . . 22Figura 6 – Ciclo de vida do software — Modelo de Estágio . . . . . . . . . . . . . 25Figura 7 – Modernização do software degradado para utilizá-lo como parte de

uma aplicação nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 8 – Processo de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 9 – Linha do tempo com as métricas de software desenvolvidas de Timóteo

et al. (2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 10 – Grafo Riguzzi (1996) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figura 11 – Estrutura de Hierarquia do modelo GQM . . . . . . . . . . . . . . . . 37Figura 12 – Metamodelo - componentes do GQM+Strategies . . . . . . . . . . . . . 39Figura 13 – Abordagem GQM+Strategies de Basili V. e Rombach (2014) . . . . . 44Figura 14 – Objetivos de medição com métricas de processos, produtos e software . 45Figura 15 – Construção do plano de medição . . . . . . . . . . . . . . . . . . . . . 50Figura 16 – Exemplo da elaboração do plano de medição . . . . . . . . . . . . . . . 52Figura 17 – Exemplo da elaboração do plano de medição . . . . . . . . . . . . . . . 53

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1 Contexto da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Questão e hipótese do problema . . . . . . . . . . . . . . . . . . . . . 131.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 EVOLUÇÃO, DEGRADAÇÃO E MODERNIZAÇÃO DE SOFTWARE 182.1 Tipos de Softwares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Evolução do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Leis de Lehman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4 Ciclo de Vida do Software . . . . . . . . . . . . . . . . . . . . . . . . . 242.5 Modernização de Software . . . . . . . . . . . . . . . . . . . . . . . . 252.6 Considerações Finais sobre o Capítulo . . . . . . . . . . . . . . . . . . 28

3 MÉTRICAS DE PROCESSOS E DE SOFTWARE, GQM E GQM+STRATEGIES 303.1 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.1 Métricas de Processo de Negócio . . . . . . . . . . . . . . . . . . . . . . . 313.1.2 Métricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2 GQM - (Goal, Question and Metric) . . . . . . . . . . . . . . . . . . 363.3 GQM+Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4 Considerações Finais sobre o Capítulo . . . . . . . . . . . . . . . . . . 40

4 INDICADORES DE DEGRADAÇÃO DO SOFTWARE . . . . . . . 424.1 Comportamento do processo de negócio versus o software . . . . . 424.2 Plano de Medição com base na abordagem GQM+Strategies . . . . 434.3 Implantação de ações de modernização do software de acordo com

o resultado das métricas definidas . . . . . . . . . . . . . . . . . . . . 464.4 Exemplo de Elaboração do Plano de Medição com base na aborda-

gem GQM+Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Considerações Finais sobre o Capítulo . . . . . . . . . . . . . . . . . . 54

5 CONCLUSÃO E PESQUISAS FUTURAS . . . . . . . . . . . . . . . 56

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

11

1 Introdução

1.1 Contexto da pesquisaO uso de sistemas de software pelas empresas é relativamente novo se comparado

com invenções como o automóvel ou o avião. A sua utilização iniciou-se entre o finalda década de 40 e início de 50. Apesar de ser recente, inúmeras mudanças aconteceramno campo de desenvolvimento de software, tais como, evolução das linguagens de pro-gramação, mudanças de paradigmas de desenvolvimento (SEBESTA, 2003) e criação deabordagens de projeto de software.

Ao longo do tempo, as aplicações de software (sistemas de software e aplicações desoftware serão utilizados como sinônimo) ocuparam um papel cada vez mais importantedentro das empresas porque apoiam uma grande parte ou quase a totalidade dos processosde negócio. Muitas organizações tem suas atividades totalmente dependentes do software,como o mercado financeiro, e a entrega do produto final não pode ser feita de formamanual, devido aos inúmeros processamentos necessários que não são conhecidos na suatotalidade pelos funcionários da organização.

As empresas utilizam softwares que são incorporados ao meio que modelam, ouseja, as atividades para realizar o processo de negócio são descritas dentro da aplica-ção. Qualquer alteração na maneira de realizar o processo exige mudanças no software.Alterações na aplicação também afetam a maneira como as atividades são executadasporque modificam a percepção dos usuários em relação as suas atividades e criam novasnecessidades no seu trabalho. Também há o refinamento das necessidades que já foramatendidas, como melhoria de performance.

Os softwares utilizados pelas organizações foram classificados por Lehman (1980)como e-type. Como essas aplicações estão incorporadas (embedded) ao mundo que mo-delam, elas sempre evoluem com o meio na qual estão inseridas, ao mesmo tempo, issotambém é responsável pela sua degradação. Neste contexto, a noção de degradação dosoftware é utilizada para designar a dificuldade em desenvolver novas funcionalidades oumodificar as existentes de acordo com as necessidades do ambiente. Ela está relacionada aincapacidade de estender funções dentro de um prazo e risco aceitável para a organização.

Existem várias causas para que aconteça degradação do programa, uma delas éa arquitetura da aplicação não ter sido desenhada com pontos flexíveis suficientes parasuportar as transformações no processo de negócio, ou o processo negócio ainda não estarbem definido enquanto o software é especificado e construído. Para a adequação dosoftware a necessidades dos usuários podem acontecer quebras arquiteturais durante o

CAPÍTULO 1. INTRODUÇÃO 12

desenvolvimento de novas funcionalidades. Isso acumulado ao longo do tempo, dificulta amanutenção da aplicação porque não é possível identificar todos os seus processamentose interdependências. Nessas condições, a manutenção no software pode ocasionar oefeito cascata que provoca erros em outras funcionalidades que não foram conscientementemodificadas pelos desenvolvedores.

Parnas (1994) discute a degradação do software fazendo um comparativo com oenvelhecimento humano, em que ações podem ser realizadas para adiar o envelhecimento,mas ele é inevitável. De acordo com o artigo, duas situações são responsáveis pela degrada-ção do software. A primeira está relacionada com as falhas em fazer alterações necessáriasna aplicação e a segunda é o resultado colateral das modificações realizadas (introdução denovos defeitos e quebra de regras arquiteturais). Cada manutenção da aplicação aumentaa complexidade do código-fonte, devido as novas funcionalidades implantadas.

Muitos autores chamam o software degradado de software legado (ou legado).Nesta condição, o legado é considerado um programa crítico para a organização que nãopossui documentação atualizada e as regras de negócio estão incorporadas ao código-fonte do software de tal maneira que não é possível reconhece-las dentro da aplicação(PENTEADO; MASIERO; PRADO, 1998), (COMELLA-DORDA et al., 2000), (ZOU;KONTOGIANNIS, 2003), (SAHRAOUI, 2005) e (SALVATIERRA et al., 2012).

A substituição do sistema de software nessa condição é uma alternativa. Mas elanão acontece de maneira rápida, além de ser cara. Caso o programa esteja num grau dedegradação grande (caixa preta, na qual apenas entradas e saídas são conhecidas), mui-tos esforços serão necessários para identificar quais processamentos são realizados pelosoftware degradado dentro de todos os cenários existentes. Além do mais, ao alterar amodelagem das entidades do legado em relação ao software que está sendo construído,a organização enfrentará dificuldades com a migração das informações existentes. Maisesforços podem ser necessários durante a substituição do software devido ao processa-mento paralelo das duas aplicações (a degradada e a que será utilizada), por um tempodeterminado para garantir a integridade no processamento de todos os cenários de negócioexistentes(BRODIE; STONEBRAKER, 1993). Manter a aplicação legada por mais tempopermite a organização planejar com mais tranquilidade a substituição do seu software.

Porém, quando o legado está degradado é difícil recuperá-lo o suficiente para quemudanças necessárias no negócio sejam realizadas de maneira rápida, com custo baixo epouco risco. De acordo com Bennett e Rajlich (2000a), a reengenharia do software é umasolução, porém realizá-la na aplicação por completo pode ser inviável devido ao prazo,custo envolvido e complexidade do software. Para diminuir custos e tempo, a reengenhariapode ser realizada em pontos específicos ou outras ações podem ser realizadas com objetivode atuar na diminuição temporária do efeito da degradação no programa.

Essas ações são classificadas como modernização do software. De acordo com


Comella-Dorda et al. (2000), a modernização compreende mais modificações que a ma-nutenção (realizada para implantar novas funcionalidades e corrigir defeito) de software.Apesar das mudanças serem grandes, a maior parte da aplicação é mantida. Dentre asabordagens de modernização estão: mudanças de interface, encapsulamento da lógica,alteração da integração com outros sistemas de software, migração do código-fonte parao paradigma orientado a objetos e utilização de uma arquitetura SOA (Service-OrientedArchitecture) (COMELLA-DORDA et al., 2000), (ZOU; KONTOGIANNIS, 2003), (SAH-RAOUI, 2005), (SALVATIERRA et al., 2012).

A abordagem de modernização a ser utilizada deve considerar mais do que ques-tões técnicas Khadka et al. (2015), e envolver a estratégia organizacional. Não é inte-ressante para a empresa alterar as interfaces de usuário da aplicação se o problema queela precisa resolver está relacionado a manutenibilidade do programa. Por isso, a mo-dernização deve ser realizada quando o resultado for resolver uma necessidade real daempresa, considerando riscos, custos e prazos em relação aos requisitos que são atendidospelo software degradado.

Para determinar quais abordagens de modernização serão empregadas e em qualmomento realizá-las, a empresa precisa ter informações sobre os requisitos do negócio,as suas necessidades não atendidas e as consequências disso. Por isso, é importantediscutir um processo de medição que tenha indicadores mistos (que envolvam os objetivosorganizacionais, de negócios e os relacionados ao software), para a tomada de decisãosobre quando e qual abordagem de modernização de software deve ser realizada.

1.2 Questão e hipótese do problemaEsta pesquisa discute exclusivamente software classificados como e-type utilizados

pelas empresas para realização dos seus processos de negócios. Esse tipo de software émodificado com o passar do tempo para que atenda as novas necessidades do processode negócio. Há uma transformação da aplicação. A representação existente dentro dosoftware torna-se cada vez mais complexa devido as inúmeras mudanças de requisitos.Com o aumento da complexidade do software as manutenções na aplicação tornam-secada vez mais difíceis, custosas e arriscadas. Qualquer mudança que parece ser simplespode ocasionar defeitos em outras funcionalidades da aplicação. Além do mais, a cadamudança no software, novos defeitos são introduzidos.

Tudo isso ocasiona a degradação do software, ou seja, não é possível estender suasfuncionalidades de acordo com as necessidades da organização e os processamentos daaplicação podem apresentar falhas se comparados com as especificações realizadas pelosusuários do software.

É possível aumentar o tempo de uso do software através de ações de moderniza-


ção. Determinar que ações realizar e quando isso deve acontecer é a busca do seguintequestionamento:quando ações de modernização devem ser realizadas num software queatende processos de negócio, considerando a estratégia da organização?

O questionamento proposto deve ser respondido utilizando a abordagemGQM+Strategies(GQM - Goals, Questions and Metrics) (BASILI et al., 2007), na qual é possível mensurara tensão que a ausência e falhas de funcionalidades no software causam nos processosnegócios. A abordagem GQM+Strategies foi escolhida porque relaciona a estratégia or-ganizacional com os níveis tático e operacional . A figura 1 mostra como a abordagemdeve ser utilizada.

Figura 1 – GQM+Strategies — Objetivo do negócio e objetivo do software

O objetivo é definir as métricas relacionadas ao software provenientes das questõesque foram construídas com base na estratégia da empresa. Como são tratado sistemasde software degradados, procura-se encontrar dados que indiquem uma tensão entre osrequisitos do processo de negócio e o software. É esta tensão que mostrará a necessidadeda modernização no software, porque o desempenho da aplicação afeta o processo denegócio e consequentemente a estratégia da empresa. A figura 2 ilustra a interação entreos requisitos do software e o processo de negócio.

A medição deve englobar também processos de negócios que foram adaptados deacordo com os comportamentos possíveis do software, ou seja, atividades que são realiza-


das porque devido a degradação do software não foi possível implementá-las completa-mente na aplicação. Um exemplo disso são controles paralelos realizados em planilhas.

Figura 2 – Interação entre o software e processos de negócios

Com a aplicação da abordagem GQM+Strategies, busca-se uma orientação sobrequais informações devem ser coletadas, uma vez que, as métricas são definidas com basenas questões elaboradas para atender os objetivos definidos em determinado nível (estra-tégico, tático e operacional).


1.3 Objetivos

1.3.1 Objetivo Geral

Utilizar os conceitos sobre degradação e evolução de software para discutir umplano de medição referente a tensão do software versus a realização dos processos denegócios. Esse plano de medição deve estar alinhado com a estratégia organizacionale auxiliar na tomada de decisão sobre a realização de abordagens de modernização nosoftware.

1.3.2 Objetivos Específicos

1 Entender os conceitos relacionados a degradação e evolução de software e-type.

2 Pesquisar as abordagens de modernização existente e quais os objetivos da execuçãodelas.

3 Elaborar um exemplo de plano de medição utilizando a abordagemGQM+Strategies quetraga resultados sobre as limitações e riscos dos processos de negócios ocasionadospelo software.

4 Apresentar um exemplo de como relacionar os dados obtidos no plano de medição coma técnica de modernização que pode ser executada de acordo com o objetivo daempresa.

1.4 Metodologia

1o Estudar e relacionar os conceitos de evolução de software que inclui as leis de Lehmane os estágios de vida do software desenvolvido por Bennett.

2o Buscar estudos sobre experimentos realizados para prolongar o uso do software dentrodas organizações.

3o Relacionar os conceitos de evolução de softwaree os objetivos das abordagens de mo-dernização de software para determinar quando elas devem ser executadas.

4o Delimitar o que deve ser medido para verificar se o software está degradado em relaçãoao uso que ele tem.

5o Demonstrar com a estratégia da organização deve ser considerada para classificar ograu de degradação do software.


6o Elaborar um exemplo de plano de medição utilizando os conceitos de degradação desoftware, a elaboração de métricas relacionadas com estratégia organizacional e aabordagem de modernização que pode reverter a degradação ou prolongar o uso dosoftware de acordo com a necessidade da empresa.

1.5 Estrutura da DissertaçãoA dissertação está estruturada em cinco capítulos.

Capítulo 1 - Introdução — Este capítulo apresentou o escopo e todo o contextoda pesquisa. Foram apresentados também a questão de pesquisa que será desenvolvidano estudo, a abordagem empregada e o objetivo principal do trabalho. O capítulo finalizacom a apresentação da estrutura da dissertação e o seu conteúdo.

Capítulo 2 - Evolução, Degradação e Modernização de Software — Nestecapítulo é construída a argumentação que software do tipo e-type, (LEHMAN, 1980),são degradados devido a inúmeras mudanças que são realizadas neles para adequação anecessidades do meio que estão incorporados. A discussão considera o ambiente no qual aaplicação está inserida e como isso pode ser um amplificador da complexidade do software.O capítulo também descreve algumas abordagens sobre modernização de software quepodem prolongar o uso da aplicação até que um novo software seja implantado para asubstituição do software degradado.

Capítulo 3 - Métricas de Processos de Negócios e Softwares, GQM eGQM+Strategies — Este capítulo, inicialmente, apresenta conceitos e exemplos demétricas de processos de negócio e software. Esses conceitos auxiliam na discussão dasabordagens GQM e GQM+Strategies que relacionam objetivos específicos aos dados co-letados. O objetivo deste capítulo é discutir quando degradação do softwareé descoberta.A proposta é utilizar indicadores elaborados com base na estratégia organizacional.

Capítulo 4 - Indicadores de Degradação do Software — Este capítulotraz a contribuição da pesquisa. São descritas métricas que indicam se a degradação dosoftware utilizado pela empresa é suportável para os processos de negócios. O objetivoé que essas métricas direcionem a organização na realização de ações que prolonguem ouso do software na empresa até que aplicação seja substituída. São elaborados exemplosde indicadores do grau de degradação do software.

Capítulo 5 - Conclusão e Pesquisas Futuras — O capítulo organiza os dife-rentes resultados e os seus efeitos em uma empreitada de modernização. Neste capítulotambém são indicados possíveis desdobramentos que essa pesquisa pode ter em trabalhosfuturos.

18

2 Evolução, Degradação e Modernização deSoftware

Neste capítulo são apresentados conceitos de evolução, ciclo de vida de software eleis de Lehman. O objetivo é construir uma argumentação que demonstre que sistemasde software classificados como e-type, irão ficar cada vez mais complexos e se degradarãocom o passar do tempo. Isso acontece devido as inúmeras manutenções que são necessáriaspara adaptá-los ao meio que estão inseridos. Essa degradação pode ser amenizada por umtempo limitado caso ações de modernização sejam realizadas no software para prolongaro tempo de uso da aplicação.

2.1 Tipos de SoftwaresOs softwares podem ser classificados em três tipos: o S-Type derivado de uma

especificação (specification). A exatidão do resultado do processamento do software érealizada através da comparação com a especificação. Qualquer alteração na especificaçãosignifica que um novo software deve ser desenvolvido; o P-Type que tem o resultado doprocessamento validado com o contexto do mundo real (real world problem solution). Oproblema especificado é preciso porém a aceitabilidade do resultado está condicionadoa comparações com o mundo real. As alterações no software estão condicionadas apercepção do analista que está modelando a aplicação, porque o problema é estático; eo E-Type que mecaniza atividades humanas e está incorporado (embedded) ao meio quemodela (LEHMAN, 1980).

Os softwares do tipo e-type são modificados pelo meio e ao serem alterados pararealizar os processos de negócio também são responsáveis por modificar o ambiente queestão inseridos. A solução do problema que esse tipo de software modela tem que ser al-terada, porque o problema está sempre em modificação. As mudanças ocorrem por causados inúmeros agentes, como usuários, legislação, concorrências, clientes entre outros, deacordo com as necessidades do meio. O resultado do processamento do software é com-parado com as mudanças que foram solicitadas pelos usuários da aplicação. A figura 3representa o ciclo básico dos softwares e-type. Nesta figura é possível identificar a aplica-ção incorporada ao meio que está modelando. A figura 4 mostra o processo de modificaçãodo software de acordo com o ambiente e a comparação das mudanças solicitadas com oresultado do processamento da aplicação.

Capítulo 2. Evolução, Degradação e Modernização de Software 19

Figura 3 – Ciclo de vida do software e-type de Lehman (1980)

Figura 4 – E-program ou E-type de Lehman (1980)

Por causa das inúmeras mudanças, a aplicação e-type passa pelo processo de evo-lução que a adapta para o meio que é utilizada. Essa adaptação ocasiona a transformação


do software dentro de um período de tempo.

2.2 Evolução do SoftwareMuitas alterações são realizadas no software durante o seu tempo de uso. Es-

tas mudanças são chamadas de manutenção e foram classificadas por Lientz e Swanson(1980 apud GODFREY; GERMAN, 2008) nas seguintes categorias: (i) corretiva, que sãomudanças para corrigirem defeitos no código-fonte; (ii) adaptativas, são realizadas paraque o software possa funcionar dentro de uma nova infraestrutura técnicas; (iii) perfec-tiva, na qual se enquadra qualquer alteração para melhorar as funcionalidades existentes,aumentar a performance, adicionar novas características ou melhorar a documentaçãoexistente; e (iv) preventiva, que são mudanças para facilitar manutenções futura comoa reorganização das dependências internas para melhoria do acoplamento e coesão dosoftware.

A evolução do software é a transformação do modelo da aplicação dentro de umperíodo de tempo devido a inúmeras manutenções realizadas na aplicação. Na evoluçãodo software estão todas as mudanças relacionadas a inclusão de novas características,correções de defeitos e adaptações para o uso em outras plataformas tecnológicas. Asmanutenções no software fazem com aplicação evolua para se adaptar ao meio que estáem constante mudança. Na tabela 1 Godfrey e German (2008) compara as diferençasentre as preocupações das manutenção e da evolução de software.

Tabela 1 – Diferenças de preocupações entre manutenção e evolução de software

Manutenção EvoluçãoO que deve ser feitos depois? (quaisitens devem ser corrigidos ou melhora-dos)

Quão rápido um software cresce antesde ficar resistente a mudanças?

Qual é o risco da manutenção? Como as fronteiras internas desapare-cem com o tempo?

Como validar a manutenção realizada? Quais são as diferenças das métricas en-tre software com o código aberto e osdesenvolvidos de maneira industrial?

De acordo com a tabela 1 de Godfrey e German (2008), na evolução do soft-ware existe a preocupação com a perda de extensibilidade (resistência a mudanças edesaparecimento das fronteiras internas). A extensibilidade da aplicação é a responsávelpela adaptação do software as necessidades da empresa.

A extensibilidade do software diminui por vários fatores. Aqui, trataremos oaumento da complexidade da aplicação com fator fundamental para a resistência do soft-ware a novas mudanças. Conforme a complexidade da representação do processo negócio


dentro software aumenta, as manutenções são mais arriscadas, caras e demoradas. Vi-saggio (2001) trata inúmeros fatores que aumentam a complexidade do software com opassar do tempo, como a duplicação de código-fonte, a obsolescência de algumas funci-onalidades que não são removidas da aplicação, falta de documentação do software eoutros fatores.

Na realização de mudanças num software que está muito complexo, a funcionali-dade desenvolvida pode atender apenas parcialmente os usuários de negócio que acabamadaptando sua maneira de trabalhar ao software e criando atividades desnecessárias den-tro da realização do processo de negócio porque não é possível fazer de maneira diferente.O software torna-se um limitador e direcionador das atividades manuais existentes narealização do processo de negócio. Novos defeitos também pode ser introduzidos na apli-cação e funcionalidades que existiam anteriormente param de funcionar ou são realizadasde maneira parcial. Existe também o alto acoplamento dentro do software, que tem comoconsequência propagar efeitos negativos em funcionalidades que não foram alteradas du-rante uma determinada manutenção (efeito cascata).

Em algumas organizações, mais de um software é utilizado para a realização detodos os processos de negócios. Estes softwares se comunicam entre si e qualquer alteraçãonuma aplicação pode afetar as demais, o que aumenta a complexidade na manutenção dosoftware e torna mais arriscada e cara qualquer modificação que precise ser realizada. Afigura 5 ilustra um ambiente organizacional no qual mais de um software é responsávelpelo processamento dos dados que irão compor o produto final. As setas cinzas significamtrocas entre os sistemas de software. Essa interação pode ser a entrega do dado para acontinuidade da computação, ou a consulta para verificar e controlar a integridade dainformação. Qualquer mudança no processamento de um determinado software podeafetar o processamento de outro software. O ambiente faz com o que seja mais difícil lidarcom a complexidade da aplicação.

A transformação necessária do software para que não aconteça sua obsolescênciatambém é responsável por degradar a aplicação. Essa degradação dentro da evoluçãodo softwarepode ser observada nas leis de Lehman que descrevem o comportamento dealterações do software e-type ao longo do seu período de uso.


Figura 5 – Ambiente organizacional utilizando vários sistemas de software para a reali-zação do produto final

2.3 Leis de LehmanAs leis de Evolução de Software, ou leis de Lehman, são o resultado de observações

dos dados coletados sobre as mudanças realizadas no software OS360 durante vinte anos(LEHMAN, 1996). Estas leis foram elaboradas entre 1976 e 1996 e são apresentadasna tabela 2. As leis se inter relacionam e ajudam a explicar o que acontece com osoftware durante o seu período de uso.


Tabela 2 – Leis de Lehman (GODFREY; GERMAN, 2014)

Leis DescriçãoMudança Contínua O sistema de softwaretorna-se progressivamente menos

satisfatório com o passar do tempo, ao menos que, osw seja continuamente adaptado as novas necessidades

Aumento da Complexidade Um sistema de software torna-se progressivamente maiscomplexo com o passar do tempo, ao menos que, um tra-balho explícito seja feito para reduzir sua complexidade

Auto Regulação O processo de evolução de software é auto regulado,com a distribuição próxima ao normal dos artefatos deprodutos e processos que são produzidos

Conservação da Estabili-dade Organizacional

A média da taxa de atividade global eficaz na evolu-ção de um software não muda com o passar do tempo.A quantidade de trabalho executada em cada versão équase a mesma

Conservação da Familiari-dade

A quantidade de conteúdo novo em cada versão sucessivado software tende a ser constante ou diminuir com opassar do tempo.

Crescimento Contínuo A quantidade funcionalidades dentro de um software irácrescer com o passar do tempo a fim de atender seususuários

Declínio da Qualidade Será percebido um declínio de qualidade no sistema desoftware com o passar do tempo, ao menos que, o de-senho seja rigorosamente mantido e adaptado a novasrestrições operacionais

Sistema de Feedback O processo de evolução do software é formado por ele-mentos multi-loop, multi-agentes, e multi-níveis. O feed-back dos usuários é um fator importante para alteraçõesrealizadas no software

A lei da Mudança Contínua acontece porque com o passar do tempo existe um des-casamento entre o software e o domínio operacional. A discussão sobre isso é realizada nalei do Sistema de Feedback que apresenta como o processo de alteração no software acon-tece de acordo com diversos elementos do meio que a aplicação está inserida. A lei daComplexidade Crescente acontece devido às inúmeras mudanças necessárias no software eque são discutidas nas leis da Mudança Contínua e Crescimento Contínuo. As interaçõese dependências do software crescem de uma maneira não estruturada levando-o a suaentropia (grandeza que mensura o grau de irreversibilidade de desordem do software),Lehman (1996).

Na lei da Auto Regulação as decisões sobre os novos desenvolvimentos no soft-ware são realizadas pela gerência da organização com base no contexto existente nomeio que a aplicação está inserida. Essas decisões são responsáveis pela maneira comoo software irá evoluir. A lei da Auto Regulação é influenciada pela lei da EstabilidadeOrganizacional, porque outros fatores atuam no desenvolvimento do softwarecomo mão


de obra capacitada e quantidade de pessoas envolvidas no projeto. Esses fatores tambémsão determinantes na quantidade de desenvolvimento eficaz do software. O resultado detodas essas forças somadas cria uma estabilidade na taxa de evolução da aplicação.

Na lei da Conservação da Familiaridade, o que determina o desenvolvimento eficazdo software é a definição dos objetivos da aplicação e a familiaridade entre os itens queserão construídos. Isso acontece porque o número de alterações influencia na complexidadedo software. A taxa de desenvolvimento do projeto e sua qualidade também é influenciadapela aquisição de conhecimento das informações sobre o que precisa ser implantado. Porisso, quanto mais funcionalidade desenvolvidas que não estão conectadas em relação afamiliaridade, mais conhecimento deverá ser adquirido e maior será a complexidade doque deve ser implantado.

Ao aumentar a complexidade do software, mais defeitos são introduzidos na apli-cação durante novos desenvolvimentos ou manutenções corretivas da aplicação. As alte-rações no software ficam mais caras e arriscadas e o usuário final tem a sensação que osoftware já não é mais suficiente para atender suas necessidade, conforme descrito na leido Declínio de Qualidade.

O efeitos dessas leis podem ser observados dentro do ciclo de vida do software.Neste trabalho será utilizado o Modelo de Estágio de Benett, Rajlich e Wilde (2000)que discute a degradação do software como algo inevitável durante o seu período deuso devido as inúmeras manutenções que o software precisa ter para continuar útil narealização do processo de negócio.

2.4 Ciclo de Vida do SoftwareNos estudos de Benett, Rajlich e Wilde (2000), Bennett e Rajlich (2000a) e Bennett

e Rajlich (2000b) é apresentado o ciclo de vida do software dividido em quatro estágios,chamado de Modelo de Estágios. Esses estágios são denominados como: (i) desenvolvi-mento inicial, no qual se inicia a concepção do software e tem o seu final bem demarcado.Ele acontece quando a primeira versão do software é utilizada pelos usuários, após o testede aceitação; (ii) evolução, neste estágio acontece o crescimento do softwareem relaçãoas funcionalidades que não foram entregues inicialmente porque ficaram foram do escopoou novas necessidades que foram criadas. Não há uma definição clara de quando estágioé encerrado. A palavra evolução dentro do ciclo de vida de Modelo de Estágio tem umconceito diferente do que foi apresentado durante o trabalho; (iii) serviço, neste estágioas alterações no software são menores devido falta de extensibilidade na aplicação pro-vocada pela degradação resultante nas inúmeras manutenções; (iv) substituição, quandonão é mais possível modificar o software e sua troca é inevitável. A figura 6 mostra asfases do Modelo de Estágio.


Figura 6 – Ciclo de vida do software — Modelo de Estágio

Durante os estágios as manutenções no software vão se tornando mais caras ecom maior risco. É no estágio de serviço que as modificações no software começama ser evitadas porque qualquer alteração pode ocasionar diversos problemas devido acomplexidade da aplicação. A entrada neste estágio é silencioso. Quando os sintomasaparecem, o software já está dentro do estágio de serviço. A lacuna entre as necessidadesdo negócio e o resultado entregue pelo processamento do software aumenta.

É no estágio de serviço que deve existir a preocupação em realizar ações paraaumentar o tempo de uso da aplicação. Ações de modernização de software podemauxiliar a organização a estender o tempo de uso do seu software . O efeito obtido épaliativo mas pode auxiliar a empresa até o momento da substituição do software poruma nova aplicação.

2.5 Modernização de SoftwareA modernização de software compreende abordagens que tem como objetivo pro-

longar o tempo de uso da aplicação. Comella-Dorda et al. (2000) define modernizaçãocomo um processo intermediário entre a manutenção e a substituição do software , porquemantém boa parte do software legado. A modernização é uma mudança isolada (não háuma transformação num período de tempo) dentro da evolução do software que reverteou diminui os efeitos da degradação devido a complexidade da aplicação.

Este trabalho define a modernização de software como qualquer ação realizadaque tenha como objetivo prolongar o tempo de uso do software . Essas ações podem es-


tar relacionadas com restruturação do software, melhorias funcionais, encapsulamento deinterface e outras ações que modifiquem o software legado permitindo que a organizaçãoconsiga utilizá-lo por um tempo maior que o previsto inicialmente.

Para enfrentar a complexidade da aplicação por meio da modernização de soft-ware podem ser adotadas as abordagens de caixa preta ou caixa branca (COMELLA-DORDA et al., 2000) e (MALINOVA, 2010). Dependendo das características, comple-xidade, degradação que o software se encontra e os objetivos da organização, as duasabordagens podem ser realizadas em partes distintas do software.

Na caixa preta, os processamentos internos do software não são conhecidos. Énecessário ter conhecimento do comportamento externo do software. As análises acon-tecem nas entradas e saídas da aplicação e também pode ser utilizada a interface doprograma para entendimento do que é processado. Geralmente são utilizados os méto-dos de encapsulamento (wrapping) para realizar a modernização no software legado. Noencapsulamento (wrapping) são construídas interfaces novas que exibem o conteúdo pro-cessado pelo sistema de software existente. A figura 7 mostra um software degradadoque é encapsulado e a saída gerada é utilizada como entrada de outra aplicação.

Figura 7 – Modernização do software degradado para utilizá-lo como parte de uma apli-cação nova

Na modernização de caixa branca o software deve ser entendido internamente.Neste tipo de modernização são utilizadas técnicas de reengenharia de software. A reenge-nharia do software consiste em examinar, entender e alterar a aplicação para reconstruí-lade uma nova forma (SNEED, 2008). De acordo com Pressman (2011), dentro da reenge-nharia de software são realizadas atividades de análise do inventário, reestruturação dos


documentos, engenharia reversa, restruturação do código-fonte, restruturação dos dadose engenharia direta.

Para Comella-Dorda et al. (2000), na modernização de caixa branca a enge-nharia reversa e amplamente utilizada. Essa atividade consiste em "desmontar"o soft-ware para conhecer todas suas características, como código-fonte, componentes, inter-relacionamentos e outros artefatos da aplicação. O objetivo é elaborar uma representaçãoem um nível mais alto de abstração para auxiliar na examinação do software.

Existem várias abordagens de modernização de software que podem ser realiza-das isoladamente ou de maneira conjunta de acordo com as necessidades da organização.Comella-Dorda et al. (2000), agrupou as atividades de modernização em 3 grupos: inter-face do usuário (pessoas e software), dado e funcional.

Na modernização da interface do usuário (user interface - UI) a usabilidade soft-ware é melhorada. Este tipo de abordagem é utilizado quando é necessário aumentar asatisfação de quem usa o software, porém ela deixa a aplicação mais inflexível para futurasmanutenções (COMELLA-DORDA et al., 2000).

Na modernização de dados, existem abordagens de encapsulamento que permitemque o acesso dos dados seja realizado através de protocolos ou interfaces diferentes das queforam projetadas inicialmente. O objetivo é melhorar a conectividade entre os softwares epermitir a integração do dado do software legado dentro de infraestruturas técnicas maisatuais.

A modernização funcional consiste em encapsular o software legado, toda a apli-cação ou parte dela. As abordagens da modernização funcional são mais complexas que asdemais e podem ter um tempo maior de implantação. Um dos objetivos das abordagensda modernização funcional é dar extensibilidade ao software e facilitar sua manutenção.Porém, existe o risco software, ao final do processo, ficar tão complexo quanto ele erainicialmente, se as ações de modernização não forem bem gerenciadas (BRODIE; STO-NEBRAKER, 1993).

De acordo com as características, grau de degradação e objetivos organizacionais asabordagens de modernização devem ser realizadas no software. A escolha da abordagemde modernização do softwareconsidera uma conjuntura de valores, que transcendem aparte técnica (KHADKA et al., 2014). Existem alguns exemplos na literatura acadêmicade como podem ser definidos quais ações devem ser realizadas. A pesquisa de Brodie eStonebraker (1993) apresenta um estudo de caso no qual a modernização do software érealizada se o processo não ultrapassar o prazo de um ano e trouxer ganhos financeiros(menor custo de manutenção) para a empresa. Comella-Dorda et al. (2000) apresenta atabela 3 com as forças e fraquezas de cada abordagem.


Tabela 3 – Abordagens de modernização de software(COMELLA-DORDA et al., 2000)

Artefato Mo-dernizado

Alvo Forças Fraquezas

Screen Scraping Interface dousuário baseadaem texto

Interfacedo usuáriográfica ouweb

Custo, time tomarket e suportede internet

Falta de flexibi-lidade e impactolimitado na ma-nutenibilidade

Banco de Dadoscom Gateway

Protocolo deacesso proprie-tário

Protocolo deacesso padro-nizado

Custo, Fer-ramentas deSuporte

Impacto li-mitado namanutenibili-dade

Integração XML Protocolo deacesso proprie-tário

ServidorXML

Flexibilidade Evolução da tec-nologia

Replicação doBanco de Dados

Banco de dadoscentralizado

Banco de da-dos replicado,distribuído

Performance,confiabilidade

Falta de coerên-cia de dados,aplicável paraum problemaespecífico

Integração GCI Dado do main-frame ou serviçoTM

páginas emHTML

Custo e suportede internet

Falta de flexibili-dade e aplicabili-dade

EncapsulamentoOrientado aObjetos

Qualquer partedo software

Modelo deorientação aobjetos

Flexibilidade Custo

Encapsulamentopor Componen-tes

Qualquer partedo software

Modelo deComponentes

Flexibilidade eserviços integra-dos

Custo

Independente do custo e esforço para realizar qualquer ação de modernização dosoftware, seu resultado será temporário, por isso a substituição do software é algo ine-vitável. Isso acontece porque o software continuará a se transformar durante e após asações de modernização, o que aumentará sua complexidade e dificultará a extensibilidadeda aplicação.

2.6 Considerações Finais sobre o CapítuloO software se transforma com o passar do tempo por causa das inúmeras ma-

nutenções que são realizadas na aplicação. Essa transformação é responsável por suadegradação a tal ponto que o software torna-se obsoleto para a empresa.

Para utilizar o software o maior tempo possível, existem abordagens de moderni-zação que podem prolongar o tempo de uso da aplicação. Essas abordagens tem objetivosespecíficos e devem ser escolhidas de acordo com o grau de degradação do software e a


estratégia da organização.

A organização deve identificar qual é o momento correto para realizar as açõesde modernização no software. Por isso, no capítulo 3 serão discutidas métricas que po-dem auxiliar a empresa na identificação do momento e de qual ação de modernização desoftware deve ser realizada de acordo com as suas necessidades e estratégias.

30

3 Métricas de Processos e de Software, GQMe GQM+Strategies

Neste capítulo são apresentados os conceitos de métricas de processos e de soft-ware. Também são discutidas as abordagens GQM e GQM+Strategiesutilizadas para aelaboração do plano de medição. Por fim, todos os conceitos apresentados são relacio-nados entre si. O propósito é demonstrar a lógica utilizada na junção do que é descritodurante o capítulo.

3.1 MétricasAs métricas são números obtidos através medições sobre um determinado objeto.

Esse objeto pode ser produto (artefatos, entregáveis ou documentos produzidos), processo(atividades normalmente associadas com o tempo) e/ou recurso (usados pelo processo paraproduzir suas saídas).

Ao analisar os números coletados é possível realizar ações para melhorar o plane-jamento da realização do produto ou processo, definir a alocação de recursos, avaliar aprodutividade, identificar precocemente problemas potencias e diminuir a imprevisibili-dade de alguma característica indesejada do objeto medido.

As métricas podem ser usadas como fotografias do momento atual, que permi-tem avaliar os efeitos de alguma ação realizada no passado ou entender as característicaspresentes para decidir se são necessárias realizar alterações no objeto. Elas também sãocoletadas e analisadas com o objetivo de prever tendências, comportamentos ou caracterís-ticas indesejadas que podem acontecer no futuro. Essas previsões podem estar associadasa inferências, como, a realização da ação A fará com que a ação B também aconteça.

Tanto processos de negócios como sistemas de software possuem métricas espe-cíficas. As métricas relacionadas aos processos de negócio geralmente são referentes aoatendimento dos requisitos dos seus clientes, como prazos, custos de produção (que afetao custo de venda), qualidade na entrega entre outros fatores perceptíveis pela organiza-ção e seus clientes. Muitas métricas de software demonstram a dificuldade para novosdesenvolvimento (funcionalidade que o software não possui) e manutenção da aplicaçãoexistente (como correções de defeitos de requisitos ou implantação).

O comportamento do processo de negócio está relacionado ao software que oatende. Caso o resultado do processamento do software não seja satisfatório de acordocom as necessidades do processo de negocio, a empresa não conseguira atender seus re-

Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 31

quisitos relacionados a prazo, custo ou qualidade. As limitações existentes para modificaro software serão refletidas em limitações para alterar o processo de negócio e produto.

Antes de entender como pode existir uma relação entre as métricas de processode negócio e as de software é necessário discuti-las separadamente. Os tópicos seguintesapresentam o conceitos dessas métricas e suas aplicações.

3.1.1 Métricas de Processo de Negócio

O processo de negócio é um conjunto de atividades que transformam matéria-prima (entradas) em produtos mais elaborados (saídas). As entradas e saídas podemser objetos físicos ou informações. A figura 8 ilustra o conceito de processo de negócioutilizado nesta pesquisa.

Figura 8 – Processo de Negócio

As saídas do processo de negócio precisam satisfazer todos os stakeholders (par-tes interessadas, como clientes, fornecedores,a empresa, legislação entre outros). Estasatisfação está relacionada com diversos fatores como prazos, custos e atendimento dosrequisitos planejados para o produto. Para gerenciar o desempenho do processo de ne-gócio e verificar se ele e o produto atendem as necessidades definidas é necessário criarmedições que possam verificar o planejado versus o realizado.


As métricas são elaboradas para medição de características específicas do processode negócio/produto ou estão relacionadas com métricas de outros níveis organizacionais(estratégico, tático e operacional). As métricas como número de vendas, lucro obtido enível de satisfação do cliente são relacionadas com o desempenho do processo negóciomesmo não estando diretamente ligada a realização dele, são medições indiretas. Pararelacionar as métricas indiretas ao processo de negócio é necessário elaborar outras mé-tricas que ajudem a traduzir as medições indiretas em números diretamente relacionadosa realização do processo de negócio.

A metodologia Balanced Scorecard (BSC), (KAPLAN; NORTON, 2001) e (KA-PLAN, 2010) é utilizada na elaboração dos planos de medição para os processos de negó-cios. A construção do plano de medição relaciona as métricas que estão sendo elaboradascom o objetivo estratégico que deve ser alcançado. Existem outras abordagens que ana-lisam o processo de negócio de uma forma mais ampla, como a Gestão de QualidadeTotal ou Total Quality Management (TQM), que tem como objetivo entregar produtosde qualidade. Os objetivos são atingidos através do envolvimento de toda a organizaçãoe stakeholders. A medição é fundamental para verificar se o planejamento para os proces-sos de negócios e produtos estão sendo cumpridos e se as tendências de comportamentodos produtos e processos estão conforme o planejado. Caso os requisitos definidos, tantopara o produto quanto para o processo de negócio, não sejam cumpridos, são realizadasações para alinhar o comportamento medido com o que foi planejado (JOINER, 2006) e(GHARAKHANI HOSSEIN RAHMATI; FARAHMANDIAN, 2013).

Quando a realização do processo de negócio é dependente do software, o compor-tamento da aplicação influencia nos resultados das medições definidas para processos denegócios e produto. Não é possível realizar modificações nos processos organizacionaiscaso o software não seja modificado. Conhecer a capacidade de extensão das funciona-lidades da aplicação é fundamental para planejar mudanças nos processos de negócio daorganização. A extensibilidade da aplicação deve ser medida junto com as necessidadesde mudanças dos processos de negócios e produtos. Por isso, as métricas de software sãofundamentais para entender o quanto a aplicação é capaz de suportar os processos denegócios que ela atende.

3.1.2 Métricas de Software

Existem várias pesquisas sobre métricas de software. Timóteo et al. (2008) ilustraisso com a figura 9, na qual são retratadas as datas que algumas métricas foram propostas.De acordo com este estudo, antes de 1991 as métricas de software basearam se na comple-xidade da aplicação, após essa data, a preocupação foi construir mecanismos para medircaracterísticas específicas do software desenvolvidos sobre o paradigma de orientação aoobjeto.


Figura 9 – Linha do tempo com as métricas de software desenvolvidas de Timóteo et al.(2008)

Medir a complexidade do software é importante. De acordo com Riguzzi (1996),os resultados das métricas são determinados pela complexidade da aplicação. Quantomais o complexo estiver o software, mais tempo será necessário para realizar as mudançasdesejadas. As Métricas como Linhas de Código (LOC), Halstead e McCabe (conhecidatambém como Complexidade Ciclomática) auxiliam na medida de tamanho e complexi-dade do software.

De acordo com Riguzzi (1996), as métricas Linhas de Código (LOC) são as maissimples que existem. Porém, mesmo com tanta simplicidade, ainda existem pontos não de-


terminados nessa métrica, como a contagem dos comentários no código-fonte da aplicação.Outro ponto é que algumas linguagens de programação permitem mais que uma instruçãona mesma linha e há dúvidas se mesmo assim devem ser contadas linhas ou instruções docódigo-fonte do software. Ao utilizar as métricas LOC não é possível determinar qual é aqualidade do código-fonte e consequentemente a complexidade do software fica limitadoao tamanho da aplicação.

As métricas de Halstead são baseadas na suposição que o software é composto deoperandos (variáveis e constantes existente no software) e operadores (símbolos ou com-binações de símbolos que influenciam no valor de um operando). O número de operandose operadores idênticos e repetidos determinam atributos como tamanho do software (so-matória do total de vezes que operandos e operadores aparecem no software), volume(número de bits necessários para representar a aplicação) e esforço de programação (RI-GUZZI, 1996).

A complexidade do software é a preocupação das métricas de McCabe (RIGUZZI,1996). As medições são realizadas através de um grafo de fluxo de controle que mede aquantidade de caminhos independentes dentro do grafo (MCCABE, 1976). As métricasde McCabe são desenvolvidas através de caminhos básicos dentro do software que quandocombinados irão gerar todos os caminhos possíveis dentro da aplicação. A figura 10 ilustraos caminhos dentro de um software utilizando o grafo de controle.

Figura 10 – Grafo Riguzzi (1996)


No grafo da figura 10 existe apenas um nó de entrada (1) e um nó de saída(7). Cada nó representa um bloco de código-fonte que tem fluxo sequencial, com isso épossível observar os caminhos aceg, acfh, bdeg e bdfh. Ao aplicar os cálculos propostospor McCabe (1976) é possível saber quantos caminhos são independentes e quantos sãocombinações lineares. A estratégia da métrica é medir a complexidade do software pelonúmero de caminho linearmente independentes. Quanto maior o número de caminhos,mais complexo será o software.

As métricas elaboradas para softwares desenvolvidos sob o paradigma de orien-tação ao objeto tem como um dos objetivos verificar o quanto o projeto da aplicaçãoutiliza as abstrações do paradigma, como, herança, reuso, encapsulamento entre outrascaracterísticas. O resultado dos cálculos mostra a complexidade em realizar manutençõesno software.

As métricas para design orientado a objetos ((Metrics for Object Oriented Design- MOOD), elaboradas por Brito e Abreu e Carapuca (1994), tem como objetivo identi-ficar a qualidade do software através de medições quantitativas relacionadas ao uso dasabstrações. Isso porque, o uso das abstrações do paradigma de orientação ao objeto estárelacionado a qualidade interna do software. No cálculo é utilizado o range de 0 (totalausência) a 1 (máxima presença). Ao utilizar esse intervalo de valores, o resultado obtidoindepende do tamanho do software avaliado.

As métricas MOODs são compostas pelas medições: (1) Fator de Ocultação doMétodo (MHF); (2) Fator de Ocultação de Atributo (AIF), tanto a métrica AIF quantoMHF medem o nível de encapsulamento; (3) Fator de Herança de Método (MIF), (4) Fatorde Herança de Atributo (AIF), assim como a métrica MIF, a AIF mede o uso da herança;(4)Fator de Acoplamento (COF), mede o nível de acoplamento; (5)Fator Polimorfismo(PF), mede a utilização de polimorfismo; e (6)Fator de Reuso (RF), avalia o reuso dasclasses por meio de herança.

As métricas desenvolvidas por Chidamber e Kemerer (1994) (métricas de CK),foram proposta com base nos conceitos teóricos de medições e ontologia de objetos. Comos resultados das medições: (1) Métodos Ponderados por Classe (WMC); (2) Profundi-dade de Herança (DIT); (3) Número de Filhos (NOC), (4) Acoplamento entre Classes deObjetos (CBO), (5) Respostas para uma Classe (RF) e (6) Falta de Coesão dos Méto-dos (LCOM), é possível determinar a dificuldade em fazer manutenção no software deacordo com a sua complexidade de desenvolvimento e testes e possibilidade de reuso doscomponentes do software.

Outas métricas foram desenvolvidas para indicar a qualidade do desenho (de-sign)de um software. Estas métricas medem atributos internos (relacionado diretamentecom atributo) da aplicação e através disso é possível determinar quais os atributos exter-nos (relação entre atributo e meio), estão relacionados (RIGUZZI, 1996).


Tabela 4 – Produto x Atributos de Software

Produto Atributo interno Atributo externoRequisitos Tamanho, reuso, modulari-

dade, redundância e funcio-nalidade

Entendibilidade e estabili-dade

Especificação Tamanho, reuso, modulari-dade, redundância e funcio-nalidade

Entendibilidade e manute-nibilidade

Desenho Tamanho, reuso, modulari-dade, acoplamento e coesão

Compreensibilidade e ma-nutenibilidade

Código Tamanho, reuso, modulari-dade, acoplamento, coesãoe complexidade do fluxo decontrole

Confiabilidade, usabilidade,reusabilidade e manutenibi-lidade

Conjunto de Testes Tamanho e nível de cober-tura

Confiabilidade no produtoentregue

Os atributos externos estão mais relacionados com a parte gerencial do software,são medidas indiretas da aplicação. Para medir um atributo externo, primeiro deve serdefinido qual é o seu significado e depois relacionado os atributos internos ao externo como objetivo de definir as medições necessárias. A tabela 4 exemplifica o relacionamentoentre os atributos internos e externos sobre qualidade do software. Neste caso, a qualidadeestá relacionada a capacidade de estender as funcionalidade da aplicação.

A lógica da tabela 4 pode ser utilizada de uma maneira mais ampla. É possívelrelacionar os atributos externos do software aos atributos do negócio que são afetadospela aplicação. Ao realizar uma relação mais ampla, é possível criar os vínculos comobjetivos da empresa. Para entender melhor como pode acontecer esse relacionamento,os próximos assuntos abordados são GQM e sua evolução, GQM+Strategies.

3.2 GQM - (Goal, Question and Metric)A abordagem GQM foi descrita inicialmente em Basili e Weiss (1984). Ela foi

desenvolvida para avaliar os defeitos de software num conjunto de projetos na NASA,Estados Unidos. Mais tarde, o GQM foi adotado para outros projetos (BASILI; CALDI-ERA; ROMBACH, 1994) e o modelo continuou sendo desenvolvido, avaliado e aplicadocom outros focos que vão além do software e envolvem objetivos da organização (BASILI;SHULL; LANUBILE, 1999), (MENDONçA; BASILI, 2000).

O GQM auxilia definir, formalizar e interpretar os objetivos operacionais. Naaplicação da abordagem é elaborado um conjunto de métricas a partir de questões querespondem os objetivos, ou seja, as métricas são construídas de maneira top-down (de cimapara baixo) (BASILI; SHULL; LANUBILE, 1999). Assim, as métricas estão vinculadas


com os objetivos que devem ser alcançados e isso ajuda a não coletar dados desnecessáriospara as análises que devem ser realizadas (MENDONçA; BASILI, 2000). A figura 11ilustra como a abordagem é aplicada.

Figura 11 – Estrutura de Hierarquia do modelo GQM

O nível conceitual é definido de acordo com os elementos: qualidade, ponto devista e ambiente. O objetivo pode estar relacionado a produto, processos e recursos. Paraque seja possível elaborar as questões concisas, os objetivos devem ser construídos demaneira clara, por isso, o modelo da tabela 5 deve ser utilizado na escrita dos objetivos.

As questões são elaboradas para descrever a avaliação do objeto que está sendomedido. Para responder as questões, são definidas métricas e um conjunto de dadosé coletado para cada questão. As respostas são quantitativas e as métricas podem serobjetivas (dependem apenas do objeto que está sendo medido) ou subjetivas (dependemdo objeto e contexto). As questões podem ser utilizadas para definir métricas de outrosobjetivos assim como, métricas podem ser repetidas para responder questões diferentes.

Tabela 5 – Elaboração de Objetivos GQM

Elementos DescriçãoObjeto O que deve ser examinado, pode ser produto, processo

ou recursoPropósito Por que o objeto deve ser examinado, o que é?, avaliar (o

que é bom?), predizer (pode ser estimado alguma coisano futuro?), controle (pode ser manipulado eventos?) emelhorar (pode ser melhorado o evento?)

Foco Atributo que deve ser examinado, na visão de algumaspecto do objeto em estudo

Perspectiva Perspectiva da examinação, de uma pessoa ou necessi-dade de informação

Contexto Contexto do escopo da examinação, descrição do ambi-ente no qual a medida é realizada

Ambiente Meio no qual a medida é realizada

A realização da abordagem é composta por 4 fases que são: (i)definição, (ii)planejamento,


(iii)operação e (iv)interpretação. Os resultados obtidos através das métricas devem seranalisados para verificar aderência em relação aos objetivos traçados. Pode acontecer queas métricas elaboradas não sejam adequadas para indicar se o objetivo foi alcançado. Oplano de medição deve ser refinado para fornecer as respostas corretas de acordo com osobjetivos definidos.

O GQM vincula objetivos, questões e métricas, contudo seu relacionamento ficaapenas nos objetivos definidos para medição. A abordagem GQM não vincula explicita-mente os objetivos de medição com os objetivos estratégicos da empresa. A abordagemGQM+Strategies é uma maneira de vincular: os objetivos estratégicos, as medições de-finidas para o processo de negócio e o software usado para realizá-lo.

3.3 GQM+StrategiesO GQM+Strategies é evolução da abordagem GQM. O intuito é alinhar, de ma-

neira explícita os objetivo organizacionais, estratégias e suposições com os objetivos domodelo de medição do software (BASILI et al., 2007) e (BASILI et al., 2014). Issoporque, quando um empresa tem os processos de negócios altamente dependentes do soft-ware, o gerenciamento da organização está diretamente vinculado aos resultados obtidosdo processamento da aplicação (BASILI et al., 2014).

A elaboração do plano de medição é similar utilizando as abordagens GQM eGQM+Strategies. O objetivo de medição, construído no nível conceitual, é operacionali-zado através das questões que são respondidas pelas métricas. A análise dos resultadosdireciona a tomada das decisões pela empresa. Esta análise também é importante por-que verifica o quanto as métricas estão alinhadas com os objetivos de medição. Caso asmétricas não sejam adequadas (não respondam as questões), novas medições devem serelaboradas.

A diferença das abordagens existe porque na abordagem GQM+Strategies obje-tivo de um determinado nível se relaciona com o objetivo do nível abaixo. Para que avinculação seja realizada 8 elementos se inter-relacionam. A figura 12 ilustra como oselementos estão conectados e a tabela 6 descreve cada um deles.


Figura 12 – Metamodelo - componentes do GQM+Strategies

Ao determinar e definir quais são os objetivos do negócio, a organização precisaformalizar suas motivações e necessidades. Também é construído o racional que utiliza osfatores externos e suposições na formulação dos objetivos que precisam ser explicitados.Para que nenhum ponto seja omitido, a abordagem GQM+Strategies utiliza o templateda tabela 7 na descrição dos objetivos da organização.

Tabela 6 – Elementos do componentes GQM+Strategies

Elementos DescriçãoObjetivos organizacionais Objetivos que a organização deseja executar para alcan-

çar o resultados dos seus planos no nível mais alto daempresa

Fatores de contexto Variáveis ambientais que representam o ambiente orga-nizacional e afetam o tipo do modelo de medição e osdados que podem ser usados

Suposições Estimam incertezas que podem afetar a interpretaçãodos dados

Decisões estratégicas Um conjunto de abordagens possíveis para o alcance deum objetivo

Atividades estratégicas Um conjunto de atividade para ajudar a alcançar a es-tratégia definida

Objetivos do nível maisbaixo

Um conjunto de objetivos num determinado nível quefaz parte de um objetivo num nível mais alto. Comopor exemplo, o objeto de um projeto que é parte deuma estratégia da organização

Elemento Goal+Strategies Um único objetivo derivado da estratégia, dos fatores decontexto e suposições

Modelo de Interpretação(Grafo GQM)

Desdobramento em objetivos questões e métricas do ob-jetivo que está num nível mais alto


Tabela 7 – Elaboração de objetivos organizacionais elaborado com base noGQM+Strategies

Item DescriçãoAtividade Atividade básica que deve ser executada para alcançar

o objetivoFoco O principal foco do objetivo de negócioObjeto O objeto que está sendo consideradoGrandeza (Grau) A quantificação do objetivo demonstrado por uma gran-

dezaPrazo Prazo que a grandeza deve ser alcançadaEscopo O escopo do objetivoRestrições/ Limitações Restrições que podem limitar o atingimento do objetivoRelação com outros objeti-vos

Relação potencial com outros (complementares ou con-correntes) objetivos

Depois que os objetivos da organização estão definidos, considerando os fatores decontexto e suposições, a organização deve elaborar uma lista de estratégias para alcançaras necessidades identificadas. Na elaboração das decisões estratégicas também devemser considerados os fatores externos e suposições que restringem as ações que poderiamser realizadas. Com as decisões estratégicas é possível definir as atividades que serãorealizadas.

Para avaliar a efetividade das atividades estratégicas é elaborado o plano de medi-ção. Na elaboração do plano é utilizado o template GQM (objeto, propósito, foco, pontode vista e ambiente). As questões, métricas e critérios de avaliação são desenvolvidos combase nos objetivos definidos. O modelo de interpretação torna possível agregar e inter-pretar os resultado das medições. Os resultados obtidos neste ponto estão relacionado auma visão mais alto nível dos processos operacionais, como o retorno do investimento deum projeto.

A medida que a organização elabora outros objetivos para os níveis mais abaixo,todos os templates da abordagem GQM+Strategies são utilizados novamente para cons-truir as decisões, atividades estratégicas e plano de medição. Seguindo a abordagemGQM+Strategies os objetivos estarão vinculados em diversos níveis organizacionais equalquer ação realizada no software deverá ter o efeito refletido no processo de negócioe consequentemente na estratégia da empresa.

3.4 Considerações Finais sobre o CapítuloExistem inúmeras pesquisas sobre métricas de software que indicam a complexi-

dade e/ou a qualidade do desenho dos softwares construídos sob o paradigma de orien-tação ao objeto. Os resultados das métricas mostram os esforços necessários para alterar


as funcionalidades da aplicação. Ao utilizar a abordagem GQM+Strategies é possívelelaborar o plano de medição seguindo determinados passos e considerando todo o con-texto da empresa, incluindo o software. A análise dos resultados obtidos das métricasdirecionam a empresa quanto as decisões relacionadas aos seus sistemas de software combase em todo o contexto organizacional. Estas decisões podem estar relacionadas a açõesde modernização e substituição do software.

42

4 Indicadores de Degradação do Software

Este capítulo apresenta como a abordagem GQM+Strategiesé utilizada para ela-borar o plano de medição que demonstre a degradação do software. Algumas das mediçõesestão relacionadas ao efeito da degradação do software na realização dos processos denegócio. Como a degradação do software foi definida anteriormente de acordo com oatendimento dos requisitos de negócio, o objetivo é relacionar o comportamento do soft-ware com os resultados dos indicadores do processo de negócio e das características doproduto. De uma maneira mais ampla, o comportamento do software é determinantepara a realização dos objetivos organizacionais, uma vez que, ele molda o funcionamentodo processo de negócio e consequentemente a característica do produto. Por isso, asmétricas apresentadas são relacionadas com os objetivos da organização.

4.1 Comportamento do processo de negócio versus o softwareO software e-type é determinante no comportamento do processo de negócio,

conforme descrito em 2.1. Isso acontece porque a realização do processo de negócio édependente do software. Ao alterar a forma de processar qualquer informação o soft-ware também precisa ser modificado. Contudo, mudanças na aplicação não são tãorápidas quanto as alterações no processo de negócio. As mudanças no software exigemum planejamento do que deve ser alterado na aplicação, análise de quais cenários serãoimpactados e verificação se as funcionalidades foram implantadas conforme a nova ne-cessidade para a realização do processo de negócio. As verificações são necessárias paragarantir que as mudanças foram realizadas dentro do esperado e não há impactos emoutras partes do software e processos de negócios que utilizam as saídas da aplicação quefoi modificada.

O software utilizado nos ambientes que várias aplicações estão interconectadas,tem a modificação mais complexa. Qualquer alteração no software pode afetar o proces-samento de outra aplicação que utiliza as informações do software modificado. Isso podeacontecer devido ao desconhecimento de todas as interconexões entre processos e sistemasde software no planejamento de mudança da aplicação.

Quando o software está no estágio de serviço, apresentado por Benett, Rajliche Wilde (2000), Bennett e Rajlich (2000a) e Bennett e Rajlich (2000b), as alteraçõescostumam ficar cada vez mais complexas e consequentemente demoradas para serem en-tregues, devido a dificuldade em realizá-las, o alto custo e o risco envolvido. Algumasvezes, a funcionalidade é implementada parcialmente por motivos que podem estar relaci-onados a dificuldade no desenvolvimento, tempo previsto para implementação menor que

Capítulo 4. Indicadores de Degradação do Software 43

o necessário ou reprovação na verificações realizadas para garantir que a funcionalidaderealmente foi implantada como foi projetada. Quando uma funcionalidade é implemen-tada parcialmente, todo o ambiente que o software está inserido (pessoas, produtos eoutros softwares) tem impacto. A não implementação da funcionalidade também influen-cia outros softwares que estão interconectados porque deixa de entregar algum resultadopara a continuidade da realização do produto final.

Logo, a degradação do software está relacionada com o não atendimento a ne-cessidades do negócio. Porém, se o software não for alterado conforme a necessidade daempresa, não será possível fazer alguns processamentos de dados para a realização do pro-duto. Determinadas características não serão realizadas ou ter um risco alto na realizaçãodo processo de negócio devido as inúmeras intervenções no banco de dados para corrigir asinformações que foram processadas de maneira incorreta ao especificado. Tudo isso temefeito no atingimento dos objetivos da organização. Se a empresa não consegue atenderas necessidades dos seus stakeholders isso é refletido na realização das suas estratégias.

Para saber quais são as necessidades que devem ser atendidas, a empresa devedefinir seus objetivos no nível organizacional. Essa definição permite adotar estratégiase elaborar os objetivos em níveis menores (como tático e operacional). O atingimentodo conjunto de objetivos em níveis mais baixos será responsável pelo alcance do objetivomaior que é definido no nível estratégico da empresa. Ao explicitar as dependências entreos diversos desempenhos dos processos de negócios é possível definir a contribuição decada elemento dentro da empresa para o atingimento do objetivo organizacional. Nautilização da abordagem GQM+Strategies os objetivos organizacionais e estratégias sãoexplicitadas. Também é possível construir a dependência dos objetivos elaborados pararealizar o que foi proposto pela organização.

4.2 Plano de Medição com base na abordagem GQM+StrategiesConforme descrito no item 3.3, a abordagem GQM+Strategiestem como intuito

explicitar os objetivos organizacionais e vincula-los com as métricas definidas para cadaparte da empresa. A vinculação é fundamental no atingimento da meta que foi definidapara o objetivo organizacional porque mostra as interdependências dentro da empresa equais pontos devem ter mais atenção.

Ao elaborar o plano de medição com base na abordagem GQM+Strategies a orga-nização definirá explicitamente o seu objetivo organizacional, atribuindo a meta que deveser alcançada. A meta é o estado futuro que a organização quer alcançar (BASILI V.;ROMBACH, 2014). A estratégia adotada deve responder a pergunta: Como o objetivopode ser alcançado? Durante a elaboração destes elementos são considerados os fatoresambientais e suposições que afetam o atingimento da meta proposta pela organização. A


importância em considerar os fatores de contexto e suposições é criar objetivos organiza-cionais e estratégias factíveis dentro de todo o contexto que a empresa está inserida.

O objetivo organizacional e a estratégia são refinados para níveis mais próximos dooperacional da organização. Novamente fatores de contexto e suposições são consideradosna definição das metas e ações que serão realizadas para o alcance destas metas. Emqualquer nível, os objetivos organizacionais podem ser vinculados a objetivos de medição.Este segundo, será responsável pelas questões e métricas definidas no modelo de interpre-tação, mostrado na figura 12. Na figura 13 é ilustrada a abordagem GQM+Strategies ea elaboração do modelo de interpretação com base nos objetivos organizacionais.

Figura 13 – Abordagem GQM+Strategies de Basili V. e Rombach (2014)

Ao definir os objetivos de medição, a empresa deve considerar métricas que demos-trem a interferência do software na realização do processo de negócio. Como o processo denegócio é altamente dependente do software , vários elementos na realização do processoe características do produto podem ser considerados. Entre estes elementos, estão: prazode entrega; confiabilidade do produto final e custo para a realização do produto (treina-mento de usuários, reprocessamentos dos dados, atividades necessárias por limitação dosoftware, como controles paralelos, etc). O custo para a realização do produto deve consi-derar todos os custos do software, tanto sua manutenção como o impacto que a aplicaçãocausa na entrega do produto final. A figura 14 ilustra como métricas de software sãoutilizadas em questões relacionadas a processos de negócios e produtos.


Figura 14 – Objetivos de medição com métricas de processos, produtos e software

Ao tratar as manutenções constantes no software do tipo e-type como projeto,questões relacionadas a mudanças no produto devem considerar métricas de software.Essas métricas estão também relacionadas com o custo para mudança da aplicação, o custoe efeito para a empresa caso a mudança não seja realizada conforme o planejado (tantoa funcionalidade quanto o prazo definido), a dificuldade em alterar o software devido aoseu tamanho e complexidade (podem ser utilizadas métricas como LOC, CK, MOOD eoutras). Dependendo do grau de degradação que o software está, algumas mudanças serãoevitadas pela empresa e outras soluções poderão ser implantadas, como o desenvolvimentode uma aplicação específica para o processamento de alguma informação.

Algumas métricas são definidas para verificar os impactos das mudanças. Essasmedições podem estar relacionadas com a utilização e/ou satisfação da nova implantaçãoversus a expectativa que havia sobre o que foi implantado. Está expectativa pode estarrelacionada com ganhos financeiros, agilidade na realização do processo de negócio, etc.

O custo deve ser incluído nas métricas, como por exemplo, o valor (monetário)que deixou de ser gasto ou o ganho com a nova implantação. As métricas relacionadasdiretamente ao software verificam se novos defeitos foram introduzidos na aplicação, seexistiram problemas em funcionalidades do software que não deveriam ter sido alterada,se os requisitos não funcionais foram atendidos, se outros software dentro da empresaforam afetados pela mudança, além de, outras medidas consideradas importantes pelaorganização.

Nas atividades rotineiras para a realização do processo de negócio, as métricasrelacionadas ao software podem medir o custo e o efeito das intervenções necessárias


nos resultados dos processamentos de dados da aplicação. Estas intervenções acontecem,muitas vezes, por falta de funcionalidades na aplicação, por isso, elas precisam ser reali-zadas diretamente (via script) no banco de dados do software (se a funcionalidade nãoé implantada por causa de alguma limitação do software, essa métrica pode ser conside-rada também em outros objetivos de medição vinculados a projetos). Ao alterar qualquerinformação diretamente no banco de dados do software há o risco de ocorrer efeitos in-desejados em outras partes do processo de negócio e/ou outros softwares que utilizam ainformação.

Outras métricas referentes a tensão do software versus a realização do processo denegócio incluem: (i) indisponibilidade da aplicação, (ii) falta de confiabilidade na informa-ção entregue, (iii) alto tempo necessário para a realização das atividades, (iv) retrabalhosno processo de negócio e (v) quantidade de incidentes provocados em outros processos denegócios e softwares. A empresa pode medir o efeito de qualquer acontecimento indesejadona realização de suas atividades e produto.

A análise do resultado da medição é a responsável pelas decisões em relação aosoftware. Contudo, ter apenas métricas não é o suficiente. Devem ser definidos quais sãoos valores aceitáveis dos indicadores. Esta definição ajudará a organização decidir sobreas ações que devem ser realizadas para cumprir os objetivo organizacional definidos pelaempresa. Como o software é fundamental na realização do processo de negócio, a açãorealizada pode ser diretamente na aplicação, como a sua modernização ou substituição.

4.3 Implantação de ações de modernização do software de acordocom o resultado das métricas definidasOs sistemas de software e-type se transformam de acordo com a sua utilização,

descrito em 2.2. Essa transformação pode ser explicada pelas Leis de Lehman apresen-tadas em 2.3. Conforme a aplicação se transforma, ela também se degrada, o que tornaas manutenções mais caras, demoradas e arriscadas, conforme 2.4. A substituição dosoftware pode ser uma solução para a empresa, porém, ela é cara e demorada, por isso,enquanto a substituição não acontece, a organização pode realizar ações de modernizaçãopara aumentar o tempo de utilização do software, conforme descrito em 2.5.

Apesar das ações de modernização terem o objetivo de aumentar o tempo de usoda aplicação, elas podem atuar em causas e efeitos diferentes. Por isso, para decidir quaisações devem ser realizadas, a empresa precisa definir qual é o efeito no processo de negóciocausado pelo software que deve ser modificado e qual ação atuará nesse efeito (essa soluçãopode ser total ou parcial). O passo inicial para identificar que o software está degradadoé medir as lacunas existentes entre o processo de negócio e a aplicação. Essas lacunasacontecem porque não é possível modificar o software de acordo com as necessidades da


organização. São as necessidades da organização em relação ao software que definirãoquais são as ações de modernização que deverão ser realizadas.

Ao utilizar métricas de software que os resultados indiquem o impacto da aplica-ção na realização do processo de negócio é possível identificar a influência do software noatingimento dos objetivos organizacionais. Os valores definidos no modelo de interpre-tação permitem que a organização decida quando o comportamento do software é umproblema para a empresa. A partir das análises realizadas com base no resultados damedição, busca-se uma maneira de reverter os efeitos indesejados que o software causanos processos de negócios.

As ações de modernização do software são uma maneira de reverter, por um tempodeterminado, os efeitos do software degradado. No item 2.5 é possível verificar algumasabordagens existentes. A tabela 3 no capítulo 2 descreve exemplos das forças e fraquezasnas abordagens de modernização de software.

Qualquer ação de modernização deve ter como base a resolução de problemas iden-tificados nos resultados das métricas. Isso porque, se o software é fundamental para arealização dos processos de negócio, seu comportamento influencia no atendimento dosobjetivos organizacionais. Abaixo é descrito um exemplo de com a utilização da aborda-gem GQM+Strategies para a construção de indicadores de degradação de software e aescolha da ação de modernização que deve ser realizada.

4.4 Exemplo de Elaboração do Plano de Medição com base naabordagem GQM+StrategiesNa elaboração do exemplo do plano de medição com base na abordagemGQM+Strategies se-

rão utilizados exemplos fictícios de objetivos organizacionais, fatores de contexto, suposi-ções, decisões e atividades estratégicas e modelo de interpretação

A empresa pode ter como objetivo organizacional aumentar seu resultado líquidoem 10%. Para isso, uma das decisões estratégicas adotada é atender as necessidades dosclientes em relação ao produto entregue pela organização, fazendo alterações no produtosempre que solicitado. Na realização do produto final, a empresa utiliza alguns sistemas desoftware, por isso, novas características do produto precisam de alterações nos softwares.

Para explicitar o objetivo organizacional são utilizados todos os elementos existen-tes na abordagem GQM+Strategiesconforme tabela 8 para garantir que todos os elementosnecessários foram definidos na descrição do que deve ser alcançado pela organização.


Tabela 8 – Exemplo da elaboração do objetivo de negócio com base na abordagemGQM+Strategies

Item DescriçãoAtividade aumentarFoco resultado líquidoObjeto produtos e processos de negócio relacionados direta-

mente a realização do produtoGrandeza (Grau) 10%Prazo 1 anoEscopo implantar novas funcionalidade no softwareRestrições/ Limitações impossibilidade de modificar os sistemas de softwarepor

diversos motivosRelação com outros objeti-vos

aumento da satisfação do cliente em relação ao produto

Ao atender as necessidades dos clientes, o software deverá ser modificado. Con-tudo pode acontecer das novas funcionalidades: (i)não serem implantadas num tempohábil suficiente para satisfazer os clientes; (ii)serem caras e (iii)trazerem um alto riscopara o software, como o surgimento de novos defeitos. Para verificar o atendimento asnecessidades dos clientes, o modelo de interpretação é elaborado considerando objetivoscomo: (1) avaliar a quantidade de funcionalidades planejadas versus implantadas; (2)avaliar o custo para a implantação das novas funcionalidades; (3) avaliar quantidade defuncionalidades implantadas dentro do prazo previsto e (4) avaliar a qualidade do soft-ware após as novas implantações.

A tabela 9 ilustra a elaboração do objetivo (1) avaliar a quantidade de funcio-nalidades planejadas versus implantadas. O detalhamento na elaboração do objetivo demedição é responsável pela construção de perguntas mais diretas para a definição dasmétricas.

Tabela 9 – Elaboração de Objetivos GQM

Elementos DescriçãoObjeto quantidade de funcionalidades implantadas versus pla-

nejadasPropósito verificar quantas funcionalidades foram implantadas do

total de planejadas para analisar a capacidade de exten-sibilidade do software

Foco capacidade de extensibilidade do softwarePerspectiva área usuáriaContexto todos os pedidos de alteração realizadas pela área usuá-

ria e aceitos pela área de TIAmbiente software utilizado para a realização dos processos de

negócios


Após a definição dos objetivos, as perguntas que darão origem para as métricassão elaboradas. Utilizando como exemplo o objetivo (1) avaliar a quantidade de funcio-nalidades planejadas versus implantadas, as seguintes perguntas podem ser elaboradas:(a) Quantas funcionalidades foram planejados e quantos foram implantadas totalmente?(b) Quantas funcionalidades foram planejadas e quantos foram implantadas parcialmentee atendem as necessidades dos clientes? (c) Quantas funcionalidades foram planejados equantas foram implantadas parcialmente e não atendem as necessidades dos clientes? (d)Quantas funcionalidades foram planejadas e quantos não foram implantadas? As pergun-tas devem auxiliar na definição de métricas as quais os resultados permitam uma análisesobre o atingimento do objetivo.

Cada pergunta elaborada deve ser respondida através de métricas diretas ou in-diretas. Uma pergunta pode estar relacionada com uma única métrica ou com várias.Também pode acontecer dos resultados das métricas definidas serem utilizados para res-ponder perguntas diferentes. Assim como as métricas, as perguntas também podem serassociadas a objetivos diferentes.

Utilizando a pergunta (a) Quantas funcionalidades foram planejadas e quantasforam implantados totalmente? são definidas as seguinte métricas: (i) número de fun-cionalidades implantadas dentro do prazo acordado com cliente e (ii) número de funci-onalidades implantadas fora do prazo acordado com o cliente. Outras definições podemser realizadas quando for feita a medição, como a classificação da complexidade de cadafuncionalidade que deve ser implantada ou o valor agregado que cada uma trará ao pro-duto que é entregue ao cliente. Estas segregações auxiliam a organização na definição dovalores aceitáveis para cada métrica. Ao definir os valores aceitáveis, a degradação dosoftware pode ser percebida quanto o resultado da métrica está fora do que foi definidopela empresa.

Os resultados das métricas são comparados com valores considerados aceitáveispela empresa. Nessa comparação, a organização pode verificar quanto o software impactaseus processos de negócios e determinar quais valores são aceitáveis antes de decidir sobrea modernização ou substituição do software. Por exemplo, ao determinar a métrica (i)número de funcionalidades implantadas dentro do prazo acordado com cliente, pode serdefinido que o resultado aceitável deve corresponder a no mínimo 80% das solicitações.Caso a empresa esteja atingindo um valor inferior ao definido, deve ser entendida a causado problema. As ações serão realizadas com base na causa encontrada através das análisesda organização.

As métricas indiretas também são utilizadas para responder a pergunta (a) Quan-tas funcionalidades foram planejadas e quantas foram implantadas totalmente? Estasmétricas podem considerar apenas o sistema de software, como o tamanho da aplicação,a quantidade de código-fonte não utilizado, qualidade do design do software e aderência


da aplicação ao modelo de orientação ao objeto. As métricas relacionadas diretamenteao software ajudarão a verificar se os atrasos na entrega estão relacionados fortementecom a dificuldade em modificar a aplicação. A figura 15 ilustra o início da elaboração dasmétricas.

Figura 15 – Construção do plano de medição

O exemplo descrito acima está relacionado com modificações no software. Outrosfatores ligados com as atividades rotineiras na realização do processo de negócio podem serutilizados para a elaboração dos objetivos que identifiquem a degradação do software nouso diário. Por exemplo, para atingir o objetivo aumentar o resultado líquido em 10%, umadas decisões estratégicas da empresa pode ser diminuir o custo na realização dos processosde negócio. Um dos objetivos para diminuir custos é avaliar a quantidade de retrabalhoexistente no processo de negócio para a realização do produto. Relacionado a esse objetivo,pode ser elaborada a seguinte questão: quantas intervenções são necessárias fazer no bancode dados da aplicação para corrigir o processamento dos dados? Para responder essaperguntas as seguintes métricas podem ser utilizadas: (1) número intervenções urgentes;(2) número de intervenções planejadas; (3) custo total das intervenções urgentes realizadasno mês e (4) custo total das intervenções planejadas realizadas no mês.


O impacto em outros sistemas de software e processos de negócios também podemser avaliados de acordo com o objetivo e questão elaborada. Para o objetivo organizacionalde aumentar o resultado líquido em 10% pode ser utilizado o objetivo diminuir o númerode incidentes. A questão: quantos incidentes aconteceram em outros softwares e processosde negócios após uma determinada intervenção no software que está sendo avaliado? podeter associada as seguintes métricas: (1) número de incidentes em outros softwares comclassificação alta (2) número de incidentes em outros softwares que afetaram diretamenteo cliente e (3) valor da perda financeira por incidente. As figuras 16 e 17 sintetizam oselementos dos exemplos utilizados.


Figura 16 – Exemplo da elaboração do plano de medição


Figura 17 – Exemplo da elaboração do plano de medição

Os valores obtidos nos indicadores devem ser comparados com os valores definidoscomo aceitáveis pela empresa. Os valores determinados pela organização como aceitáveismostrarão o quanto é possível sustentar o sistema de software utilizado para a realizaçãodos processos de negócios. Por exemplo, pode ser considerado que a empresa não con-segue atender 50% dos pedidos dos seus clientes devido a impossibilidade de modificaro software que está degradado após inúmeras manutenções. Para resolver ou diminuiresse percentual, a empresa pode realizar ações de modernização da lógica como o encap-


sulamento do software, que permitirá uma maior manutenibilidade, conforme citado natabela 3.

Qualquer decisão sobre qual ação realizar para aumentar o tempo de utilizaçãodo software deve considerar o indicador que não está sendo atendido de acordo com oscritérios da empresa. A ação que será realizada deve ter como propósito diminuir ouacabar com algum efeito negativo provocado pelo software no processo de negócio. Orefinamentos dos objetivos de medição, questões e métricas acontecerá quando a empresacomparar os resultados obtidos após a implantação de determinadas ações.

O encapsulamento da lógica do software pode não atender a expectativa da or-ganização em aumentar a extensibilidade da aplicação para atender os pedidos dos seusclientes. Isso será percebido com os resultados obtidos dos indicadores que continuarão aser utilizados pela empresa. Outras ações podem ser necessárias e elas serão realizadasde acordo com as análises dos resultados dos indicadores.

Em algum momento, a empresa conclui que não é o atendimento aos pedidosdos seus clientes sobre novas funcionalidades que aumentará o seu resultado líquido em10%, mas que existe a necessidade de diminuir seu custo operacional. Se o sistema desoftware traz um custo elevado para a realização do processo negócio, as ações de mo-dernização devem ser realizadas para diminuir esse custo. Essas ações serão escolhidasconforme o problema apresentado e as características do software que causam o efeito quea empresa quer diminuir. Por isso, qualquer ação de modernização realizada na aplicaçãodeve considerar sempre as necessidades dos processos de negócios que são atendidos pelaaplicação.

4.5 Considerações Finais sobre o CapítuloOs sistemas de software e-type precisam ser alterados conforme são utilizado pela

organização. Estas alterações transformam o software numa aplicação diferente do queela foi planejada inicialmente. A transformação do software é chamada de evoluçãopor Godfrey e German (2014). A evolução, neste caso, está relacionada a adaptação daaplicação as necessidades do meio que ela está inserida. Como o ambiente é mutável, osoftware também precisa ser modificado para acompanhar esta mutação.

As alterações no software, pautadas pelos processos de negócios, deixam a apli-cação cada vez mais complexa. A dificuldade em modificar o software aumenta a cadamanutenção, seja para implantar novas funcionalidades ou corrigir alguns defeitos existen-tes. Em algum momento, devido a grande complexidade do software e a impossibilidadede modificá-lo, o seu uso não será mais possível para a organização, ao menos que duranteo período de degradação do software seja realizada alguma ação para estender seu tempode uso. Neste trabalho, estas ações foram chamadas de modernização de software.


Quando a organização percebe que o software não atende seu processo de negócio,seja em relação a novas funcionalidades, performance ou tempo necessário para alteração,a aplicação já está no estágio de serviço definido por Benett, Rajlich e Wilde (2000),Bennett e Rajlich (2000a) e Bennett e Rajlich (2000b). Caso não existam indicadoressobre a relação do software com o processo de negócio, a percepção pode ser apenas umaintuição, sem justificativas exatas.

Por isso, ao definir métricas para a realização dos processos de negócios (suapertinência em relação aos objetivos da empresa) é necessário incluir métricas relacionadasao sistema de software. As métricas do software mostrarão o quanto a aplicação auxiliaou atrapalha a organização no atingimentos dos seu objetivos estratégicos. Caso a análisedos resultados da métricas demonstrem que o software está gerando efeitos negativospara a empresa, é possível justificar investimentos na aplicação que ajudarão a sanar odiminuir os problemas do software.

A utilização da abordagem GQM+Strategies foi apresentada porque ela é umamaneira de conectar os objetivos da organização com as estratégias que serão realizadas, osobjetivos de medição junto com suas questões e métricas. Desta forma, é possível construiruma relação de causa e efeito entre as atividades da organização e verificar como cadaelemento dentro da empresa contribui com os seus objetivos macros, inclusive o software.A elaboração de um plano de medição com base na abordagem GQM+Strategies não é asolução para a empresa, mas vai ajudá-la a definir a adoção de determinadas estratégiaspara o alcance dos seus objetivos.

56

5 Conclusão e Pesquisas Futuras

Esta pesquisa teve como propósito atingir o seguinte objetivo: utilizar os conceitossobre degradação e evolução de software para discutir um plano de medição referente atensão do software versus a realização dos processos de negócios. Esse plano de mediçãodeve estar alinhado com a estratégia organizacional e auxiliar na tomada de decisão sobrea realização de abordagens de modernização no software.

Para elaborar o plano de medição, primeiro foi definido qual é o tipo de soft-ware que a pesquisa discutiria. Ao determinar o tipo da aplicação, houve a necessidadede estudar seu comportamento, que incluiu o processo de evolução e consequentementea degradação do software. Como ainda não existe uma maneira de definir o momentoexato que o software irá se degradar, a pesquisa focou em relacionar a degradação dosoftware ao impacto que ele tem no processo de negócio que atende.

Por isso, na elaboração do plano de medição foram consideradas, principalmente,as limitações que o software impõe a realização do processo de negócio. Como o processode negócio está vinculado a estratégia da empresa, ao relacionar os indicadores de degra-dação do software ao processo de negócio que ele realiza, suas métricas também estarãorelacionadas a estratégia da organização. Com isso, qualquer ação de modernização ado-tada para estender o tempo de uso da aplicação, estará diretamente relacionada com aestratégia da empresa para realizar seu objetivo organizacional.

Para alcançar o objetivo principal da pesquisa, houve o estudo de diversos con-ceitos relacionados ao software. Primeiro, estudou-se o ciclo de vida do software e-type,que abrangeu desde a concepção até a substituição do software. Depois, pesquisou-seações de modernização de software que são realizadas para prolongar o tempo de usoda aplicação. Por fim, concluiu-se que ao determinar qual a abordagem de modernizaçãodeve ser realizada é necessário saber qual é o efeito indesejado do software que precisaser mitigado. Para ilustrar toda a discussão, foi apresentado um exemplo da elaboraçãodo plano de medição relacionados aos objetivos organizacionais.

Contudo, não houve tempo hábil de aplicar o resultado do estudo numa organiza-ção. Por isso, não é possível discutir sua efetividade, as dificuldades em elaborar o planode medição e a identificação de elementos faltantes para determinar os indicadores dedegradação do software.

A grande contribuição desta pesquisa foi relacionar diversos conceitos de software,entender sua degradação e como isso impacta os processo de negócio que a aplicaçãoatende. O resultado da pesquisa, possibilita que outros estudos sejam realizados paradiscutir o aumento da complexidade do software, devido as inúmeras mudanças, nos am-

Capítulo 5. Conclusão e Pesquisas Futuras 57

bientes organizacionais, assim como, a complexidade criada dentro desses ambientes queutilizam mais de um software para a realização dos seus processos de negócios.

Assim a pesquisa é finalizada, apresentando um modelo de medição que identifiquea degradação do software com as seguinte bases: o tipo de software utilizado pelasempresas; a evolução do software de acordo com as necessidades do meio; o aumentoda complexidade e a degradação da aplicação e a necessidade de definir as ações queaumentarão o tempo de uso do software de acordo com os objetivos do processo denegócio e da empresa como um todo.

58

Referências

BASILI, V.; CALDIERA, G.; ROMBACH, H. D. Goal question metric paradigm.Encyclopedia of Software Engineering, 1994.

BASILI, V. et al. Gqm+strategies - aligning business strategies with softwaremeasurement. Proceedings - 1st International Symposium on Empirical SoftwareEngineering and Measurement, ESEM 2007, p. 488–490, 2007.

BASILI, V. R. et al. Gqm+strategies: A comprehensive methodology for aligningbusiness strategies with software measurement. CoRR, abs/1402.0292, 2014.

BASILI, V. R.; SHULL, F.; LANUBILE, F. Building knowledge through families ofexperiments. IEEE Transactions on Software Engineering, v. 25, n. 4, p. 456–473, Jul1999. ISSN 0098-5589.

BASILI, V. R.; WEISS, D. M. A methodology for collecting valid software engineeringdata. IEEE Trans. Software Eng., v. 10, n. 6, p. 728–738, 1984.

BASILI V., T. A. K. M. H. J. S. C. M. J.; ROMBACH, D. Aligning OrganizationsThrough Measurement The GQM+Strategies Approach. [S.l.]: Springer, 2014.

BENETT, K. H.; RAJLICH, V. T.; WILDE, N. Software evolution and staged model ofsoftware lifecycle. In: . [S.l.: s.n.], 2000.

BENNETT, K. H.; RAJLICH, V. T. Software maintenance and evolution: A roadmap.In: Proceedings of the Conference on The Future of Software Engineering. New York,NY, USA: ACM, 2000. (ICSE ’00), p. 73–87. ISBN 1-58113-253-0. Disponível em:<http://doi.acm.org/10.1145/336512.336534>.

BENNETT, K. H.; RAJLICH, V. T. Software maintenance and evolution: A roadmap.In: Proceedings of the Conference on The Future of Software Engineering. New York,NY, USA: ACM, 2000. (ICSE ’00), p. 73–87. ISBN 1-58113-253-0.

Brito e Abreu, F.; CARAPUCA, R. Object-oriented software engineering: Measuringand controlling the development process. In: Proc. Int’l Conf. Software Quality (QSIC).[S.l.: s.n.], 1994.

BRODIE, M. L.; STONEBRAKER, M. R. DARWIN : on the incrementalmigration of legacy information systems. [S.l.], 1993. Disponível em: <http://opac.inria.fr/record=b1032315>.

CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented design.IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 20, n. 6, p. 476–493,jun. 1994. ISSN 0098-5589. Disponível em: <http://dx.doi.org/10.1109/32.295895>.

COMELLA-DORDA, S. et al. A Survey of Legacy System Modernization Approaches.Pittsburgh, PA, 2000. Disponível em: <http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5093>.

http://doi.acm.org/10.1145/336512.336534

http://opac.inria.fr/record=b1032315

http://opac.inria.fr/record=b1032315

http://dx.doi.org/10.1109/32.295895

http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5093

http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5093

Referências 59

GHARAKHANI HOSSEIN RAHMATI, M. R. F. D.; FARAHMANDIAN, A. Totalquality management and organizational performance. American Journal of IndustrialEngineering, 2013.

GODFREY, M. W.; GERMAN, D. M. The past, present, and future of softwareevolution. In: IEEE. Frontiers of Software Maintenance track, IEEE Intl. Conf. onSoftware Maintenance (ICSM). [S.l.], 2008. p. 129–138.

GODFREY, M. W.; GERMAN, D. M. On the evolution of lehman’s laws. Journalof Software: Evolution and Process, v. 26, n. 7, p. 613–619, 2014. ISSN 2047-7481.Disponível em: <http://dx.doi.org/10.1002/smr.1636>.

JOINER, T. A. Total quality management and performance - the role of organizationsupport and co-worker support. International Journal of Quality & ReliabilityManagement, 2006.

KAPLAN, R. S. Conceptual foundations of the balanced scorecard. Harvard BusinessSchool, 2010.

KAPLAN, R. S.; NORTON, D. P. Transforming the balanced scorecard from performancemeasurement to strategic management. Accounting Horizons, 2001.

KHADKA, R. et al. How do professionals perceive legacy systems and softwaremodernization? In: Proceedings of the 36th International Conference on SoftwareEngineering. New York, NY, USA: ACM, 2014. (ICSE 2014), p. 36–47. ISBN978-1-4503-2756-5. Disponível em: <http://doi.acm.org/10.1145/2568225.2568318>.

KHADKA, R. et al. Does software modernization deliver what it aimed for? A postmodernization analysis of five software modernization case studies. In: ICSME. [S.l.]:IEEE, 2015. p. 477–486.

LEHMAN, M. M. Programs, life cycles, and laws of software evolution. Proc. IEEE,v. 68, n. 9, p. 1060–1076, September 1980.

LEHMAN, M. M. Laws of software evolution revisited. In: Proceedings of the 5thEuropean Workshop on Software Process Technology. London, UK, UK: Springer-Verlag, 1996. (EWSPT ’96), p. 108–124. ISBN 3-540-61771-X. Disponível em:<http://dl.acm.org/citation.cfm?id=646195.681473>.

LIENTZ, B. P.; SWANSON, E. B. Software Maintenance Management. Boston, MA,USA: Addison-Wesley Longman Publishing Co., Inc., 1980. ISBN 0201042053.

MALINOVA, A. Anna malinova. SCIENTIFICS WORKS, n. 37, 2010.

MCCABE. A complexity measure. IEEE Transactions on Software Engineering, v. 2, p.308–320, 1976.

MENDONçA, M. G.; BASILI, V. R. Validation of an approach for improving existingmeasurement frameworks. IEEE Transactions on Software Engineering, IEEE ComputerSociety, Los Alamitos, CA, USA, v. 26, n. 6, p. 484–499, 2000. ISSN 0098-5589.

PARNAS, D. L. Software aging. In: Proceedings of the 16th InternationalConference on Software Engineering. Los Alamitos, CA, USA: IEEE ComputerSociety Press, 1994. (ICSE ’94), p. 279–287. ISBN 0-8186-5855-X. Disponível em:<http://dl.acm.org/citation.cfm?id=257734.257788>.

http://dx.doi.org/10.1002/smr.1636

http://doi.acm.org/10.1145/2568225.2568318

http://dl.acm.org/citation.cfm?id=646195.681473

http://dl.acm.org/citation.cfm?id=257734.257788

Referências 60

PENTEADO, R.; MASIERO, P. C.; PRADO, A. F. do. Reengineering of LegacySystems Based on Transformation Using the Object-Oriented Paradigm. In: Proceedingsof the Fifth Working Conference on Reverse Engineering. [S.l.]: IEEE Computer Society,1998. p. 144–153.

PRESSMAN, R. S. Engenharia de Software - Uma Abordagem Profissional. 7. ed. [S.l.]:McGrawHill, 2011.

RIGUZZI, F. A Survey of Software Metrics. [S.l.], 1996.

SAHRAOUI, H. Coping with legacy system migration complexity. In: Proceedings ofthe 10th IEEE International Conference on Engineering of Complex Computer Systems.Washington, DC, USA: IEEE Computer Society, 2005. (ICECCS ’05), p. 600–609. ISBN0-7695-2284-X. Disponível em: <http://dx.doi.org/10.1109/ICECCS.2005.29>.

SALVATIERRA, G. et al. Towards a computer assisted approach for migrating legacysystems to soa. In: MURGANTE, B. et al. (Ed.). ICCSA (4). Springer, 2012. (LectureNotes in Computer Science, v. 7336), p. 484–497. ISBN 978-3-642-31127-7. Disponívelem: <http://dblp.uni-trier.de/db/conf/iccsa/iccsa2012-4.html#SalvatierraMCZ12>.

SEBESTA, R. Conceitos de Linguagens de Programacao. BOOKMAN COMPANHIAED, 2003. ISBN 9788536301716. Disponível em: <https://books.google.com.br/books?id=b0tcn\_uPLoAC>.

SNEED, H. M. 20 years of software-reengineering: A résumé. In: 10th WorkshopSoftware Reengineering, 5-7 May 2008, Bad Honnef. [s.n.], 2008. p. 115–124. Disponívelem: <http://subs.emis.de/LNI/Proceedings/Proceedings126/article2091.html>.

TIMóTEO, A. L. et al. Software metrics : A survey. Advanced Studies and Systems,2008.

VISAGGIO, G. Ageing of a data-intensive legacy system: symptoms and remedies.Journal of Software Maintenance, v. 13, n. 5, p. 281–308, 2001. Disponível em:<http://dblp.uni-trier.de/db/journals/smr/smr13.html#Visaggio01>.

ZOU, Y.; KONTOGIANNIS, K. Incremental transformation of procedural systems toobject oriented platforms. In: 27th International Computer Software and ApplicationsConference (COMPSAC 2003): Design and Assessment of Trustworthy Software-BasedSystems, 3-6 November 2003, Dallas, TX, USA, Proceedings. [s.n.], 2003. p. 290–295.Disponível em: <http://dx.doi.org/10.1109/CMPSAC.2003.1245356>.

http://dx.doi.org/10.1109/ICECCS.2005.29

http://dblp.uni-trier.de/db/conf/iccsa/iccsa2012-4.html#SalvatierraMCZ12

https://books.google.com.br/books?id=b0tcn\_uPLoAC

https://books.google.com.br/books?id=b0tcn\_uPLoAC

http://subs.emis.de/LNI/Proceedings/Proceedings126/article2091.html

http://dblp.uni-trier.de/db/journals/smr/smr13.html#Visaggio01

http://dx.doi.org/10.1109/CMPSAC.2003.1245356

modernizaçãode software: indicadoresdograude degradação cristina pereira.pdfplano de medição...

Documents