Pontifícia Universidade Católica de São Paulo PUC-SP Marcela Cristina Pereira Modernização de Software: Indicadores do Grau de Degradação São Paulo 2017
Pontifícia Universidade Católica de São Paulo PUC-SP Marcela Cristina Pereira Modernização de Software: Indicadores do Grau de Degradação Dissertação apresentada à Banca Examinadora da Pontífica Universidade Católica de São Paulo, como exigência parcial para obtenção do título de MESTRE em Tecnologias da Inteligência e Design Digital, na área de concentração de Processos Cognitivos e Ambientes Digitais, na linha de pesquisa de Modelagem de Sistemas de Software, sob a orientação do Prof. Dr. Ítalo Santiago Vega. São Paulo 2017
Marcela Cristina Pereira 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 plano ainda era muito inicial. A todas pessoas do meu trabalho que foram flexíveis quanto aos meus horários para que eu pudesse estudar. Aos meus amigos, César, Marcos e Marcele por entenderem minha ausência em muitos momentos importantes. A todas as pessoas que escutaram minhas ideias e leram o que eu escrevi, me auxiliando com suas opiniões. Ao meu orientador, Professor Ítalo Santiago Vega, por toda paciência e dedicação para que eu pudesse elaborar meu tema de pesquisa. À Edna Conti pela atenção e paciência dispensada com as minhas inúmeras perguntas.
Resumo Muitos sistemas de software utilizados pelas empresas tem como objetivo apoiar suas atividades. Este apoio pode acontecer através de controles e/ou realização dos processos de negócio da empresa. Este tipo de software mecaniza atividades humanas e está inserido no meio ao qual modela. Como o ambiente organizacional é mutável, a aplicação precisa ser alterada de acordo com as novas necessidades da empresa. Porém, estas alterações são responsáveis pela degradação do software porque o torna cada vez mais complexo. A complexidade é limitadora para que novas modificações sejam realizadas sem existirem custos e riscos elevados para a organização até que seja inviável manter o sistema de software. Existem abordagens, chamadas de modernização, que podem prolongar o tempo de uso do software até sua substituição. A pesquisa utiliza os conceitos de evolução, degradação e modernização de software para propor indicadores baseados nas necessidades do processo de negócio atendido pelo software para identificar o momento que a organização precisa 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
Abstract Many softwares, which are using by the companies, have the objective to support their business activities. This kind of support happens by means of processes controls and/or accomplishment of business processes. The software used in the companies executes humans being activities and it stays in the same environment of the business process. However, the environment is not static, the software application needs change according the company needs. The software changings are necessary by his useful life and for by his degradation too, because the business process representation inside the software becomes more complex. The complexity is one of the limitation to change the software without 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 the company. This research uses concepts like evolution, modernization and degradation of software with the objective to discuss and offer indicators metrics based in needs of business processes. The objective is identify which moment the company should makes plan to do the modernization approaches for extend the time of software useful. Keywords: software modernization software degratation,metrics of software degratation, software evolution,
Prefácio Durante a elaboração do pré projeto de pesquisa, a percepção inicial era que existia uma lacuna imensa na comunicação entre as áreas de negócio e desenvolvimento de software sobre as novas funcionalidades que deveriam ser implantadas na aplicação. Como usuária de software, minha experiência era de frequentemente receber as funcionalidade em desacordo com as solicitações, além de existir atrasos nas entregas e o surgimentos de novos defeitos em funcionalidades que não deveriam ser alteradas. Enquanto elaborava o pré projeto de pesquisa, vivenciava a substituição de um sistema de software que atendia vários processos dentro de uma organização altamente dependente dos seus softwares para a entrega do seu produto aos clientes. Esta substituição do software legado por outro novo foi um dos motivadores do estudo. Na prática, a lógica do negócio era mantida, porque o produto final permanecia igual mesmo com a mudança do software. Acreditava-se que a lógica dos processamentos realizados pela aplicação legada seria mantida. Naquele momento, a preocupação era como migrar os dados de uma aplicação para a outra devido aos inúmeros problemas de integridade que isso poderia trazer para a informação. Ainda não se havia estudado os conceitos de modelagem das entidades do software e as ideias tinham como base conhecimentos empíricos, como por exemplo, a dificuldade em encaixar as informações existentes no 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ção de dados de um software para o outro. Durante a leitura dos artigos, para justificar a substituição do software e consequentemente a necessidade de migração de dados, foram surgindo conceitos relacionados a modernização do software. Isso aconteceu porque a migração de dados era uma das abordagens de modernização que poderia estender o tempo de uso da aplicação. Outras abordagens discutiam sobre a migração das funcionalidades do software e justificavam sua existência devido a degradação do software. Durante dois anos, a pesquisa foi relacionando conceitos como: os tipos de softwares 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 exclusivamente por falha de entendimento do desenvolvedor da aplicação, foi desfeita. Com todo material estudado, foi possível entender que o software irá se degradar devido as inúmeras manutenções que ele passa durante o seu tempo de uso. Este entendimento fez com que a pesquisa buscasse maneiras de identificar os efeitos da degradação do software na 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ção de indicadores sobre a degradação da aplicação é importante para decidir qual ação de modernizaçã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. 20 Tabela 2 Leis de Lehman (GODFREY; GERMAN, 2014)............. 23 Tabela 3 Abordagens de modernização de software(comella-dorda et al., 2000).................................... 28 Tabela 4 Produto x Atributos de Software..................... 36 Tabela 5 Elaboração de Objetivos GQM...................... 37 Tabela 6 Elementos do componentes GQM+Strategies............... 39 Tabela 7 Elaboração dos objetivos organizacionais................. 40 Tabela 8 Exemplo da elaboração do objetivo de negócio.............. 48 Tabela 9 Elaboração de Objetivos GQM...................... 48
Lista de ilustrações Figura 1 GQM+Strategies Objetivo do negócio e objetivo do software.... 14 Figura 2 Interação entre o software e processos de negócios........... 15 Figura 3 Ciclo de vida do software e-type de Lehman (1980)........... 19 Figura 4 E-program ou E-type de Lehman (1980)................. 19 Figura 5 Ambiente organizacional utilizando vários sistemas de software para a realização do produto final......................... 22 Figura 6 Ciclo de vida do software Modelo de Estágio............. 25 Figura 7 Modernização do software degradado para utilizá-lo como parte de uma aplicação nova............................. 26 Figura 8 Processo de Negócio............................ 31 Figura 9 Linha do tempo com as métricas de software desenvolvidas de Timóteo et al. (2008)................................. 33 Figura 10 Grafo Riguzzi (1996)............................ 34 Figura 11 Estrutura de Hierarquia do modelo GQM................ 37 Figura 12 Metamodelo - componentes do GQM+Strategies............. 39 Figura 13 Abordagem GQM+Strategies de Basili V. e Rombach (2014)..... 44 Figura 14 Objetivos de medição com métricas de processos, produtos e software. 45 Figura 15 Construção do plano de medição..................... 50 Figura 16 Exemplo da elaboração do plano de medição............... 52 Figura 17 Exemplo da elaboração do plano de medição............... 53
Sumário 1 INTRODUÇÃO............................. 11 1.1 Contexto da pesquisa........................... 11 1.2 Questão e hipótese do problema..................... 13 1.3 Objetivos.................................. 16 1.3.1 Objetivo Geral................................ 16 1.3.2 Objetivos Específicos............................. 16 1.4 Metodologia................................. 16 1.5 Estrutura da Dissertação......................... 17 2 EVOLUÇÃO, DEGRADAÇÃO E MODERNIZAÇÃO DE SOFTWARE 18 2.1 Tipos de Softwares............................. 18 2.2 Evolução do Software........................... 20 2.3 Leis de Lehman............................... 22 2.4 Ciclo de Vida do Software......................... 24 2.5 Modernização de Software........................ 25 2.6 Considerações Finais sobre o Capítulo.................. 28 3 MÉTRICAS DE PROCESSOS E DE SOFTWARE, GQM E GQM+STRATEGIES 30 3.1 Métricas................................... 30 3.1.1 Métricas de Processo de Negócio....................... 31 3.1.2 Métricas de Software............................. 32 3.2 GQM - (Goal, Question and Metric).................. 36 3.3 GQM+Strategies.............................. 38 3.4 Considerações Finais sobre o Capítulo.................. 40 4 INDICADORES DE DEGRADAÇÃO DO SOFTWARE....... 42 4.1 Comportamento do processo de negócio versus o software..... 42 4.2 Plano de Medição com base na abordagem GQM+Strategies.... 43 4.3 Implantação de ações de modernização do software de acordo com o resultado das métricas definidas.................... 46 4.4 Exemplo de Elaboração do Plano de Medição com base na abordagem GQM+Strategies........................... 47 4.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 pesquisa O 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 final da década de 40 e início de 50. Apesar de ser recente, inúmeras mudanças aconteceram no campo de desenvolvimento de software, tais como, evolução das linguagens de programação, mudanças de paradigmas de desenvolvimento (SEBESTA, 2003) e criação de abordagens de projeto de software. Ao longo do tempo, as aplicações de software (sistemas de software e aplicações de software serão utilizados como sinônimo) ocuparam um papel cada vez mais importante dentro das empresas porque apoiam uma grande parte ou quase a totalidade dos processos de 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 forma manual, devido aos inúmeros processamentos necessários que não são conhecidos na sua totalidade pelos funcionários da organização. As empresas utilizam softwares que são incorporados ao meio que modelam, ou seja, 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 executadas porque modificam a percepção dos usuários em relação as suas atividades e criam novas necessidades no seu trabalho. Também há o refinamento das necessidades que já foram atendidas, 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 modelam, elas sempre evoluem com o meio na qual estão inseridas, ao mesmo tempo, isso também é responsável pela sua degradação. Neste contexto, a noção de degradação do software é utilizada para designar a dificuldade em desenvolver novas funcionalidades ou modificar as existentes de acordo com as necessidades do ambiente. Ela está relacionada a incapacidade 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 para suportar as transformações no processo de negócio, ou o processo negócio ainda não estar bem definido enquanto o software é especificado e construído. Para a adequação do software 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 a manutenção da aplicação porque não é possível identificar todos os seus processamentos e interdependências. Nessas condições, a manutenção no software pode ocasionar o efeito cascata que provoca erros em outras funcionalidades que não foram conscientemente modificadas pelos desenvolvedores. Parnas (1994) discute a degradação do software fazendo um comparativo com o envelhecimento 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árias na aplicação e a segunda é o resultado colateral das modificações realizadas (introdução de novos defeitos e quebra de regras arquiteturais). Cada manutenção da aplicação aumenta a 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ão possui documentação atualizada e as regras de negócio estão incorporadas ao códigofonte 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 ela não acontece de maneira rápida, além de ser cara. Caso o programa esteja num grau de degradação grande (caixa preta, na qual apenas entradas e saídas são conhecidas), muitos esforços serão necessários para identificar quais processamentos são realizados pelo software degradado dentro de todos os cenários existentes. Além do mais, ao alterar a modelagem 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. Mais esforços podem ser necessários durante a substituição do software devido ao processamento paralelo das duas aplicações (a degradada e a que será utilizada), por um tempo determinado para garantir a integridade no processamento de todos os cenários de negócio existentes(brodie; STONEBRAKER, 1993). Manter a aplicação legada por mais tempo permite 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 que mudanças necessárias no negócio sejam realizadas de maneira rápida, com custo baixo e pouco risco. De acordo com Bennett e Rajlich (2000a), a reengenharia do software é uma soluçã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 reengenharia pode ser realizada em pontos específicos ou outras ações podem ser realizadas com objetivo de 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
CAPÍTULO 1. INTRODUÇÃO 13 Comella-Dorda et al. (2000), a modernização compreende mais modificações que a manutençã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 as abordagens 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 para o paradigma orientado a objetos e utilização de uma arquitetura SOA (Service-Oriented Architecture) (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 questões técnicas Khadka et al. (2015), e envolver a estratégia organizacional. Não é interessante para a empresa alterar as interfaces de usuário da aplicação se o problema que ela precisa resolver está relacionado a manutenibilidade do programa. Por isso, a modernização deve ser realizada quando o resultado for resolver uma necessidade real da empresa, considerando riscos, custos e prazos em relação aos requisitos que são atendidos pelo software degradado. Para determinar quais abordagens de modernização serão empregadas e em qual momento 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, é importante discutir um processo de medição que tenha indicadores mistos (que envolvam os objetivos organizacionais, de negócios e os relacionados ao software), para a tomada de decisão sobre quando e qual abordagem de modernização de software deve ser realizada. 1.2 Questão e hipótese do problema Esta 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 processo de negócio. Há uma transformação da aplicação. A representação existente dentro do software 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-se cada vez mais difíceis, custosas e arriscadas. Qualquer mudança que parece ser simples pode ocasionar defeitos em outras funcionalidades da aplicação. Além do mais, a cada mudança no software, novos defeitos são introduzidos. Tudo isso ocasiona a degradação do software, ou seja, não é possível estender suas funcionalidades de acordo com as necessidades da organização e os processamentos da aplicação podem apresentar falhas se comparados com as especificações realizadas pelos usuários do software. É possível aumentar o tempo de uso do software através de ações de moderniza-
CAPÍTULO 1. INTRODUÇÃO 14 ção. Determinar que ações realizar e quando isso deve acontecer é a busca do seguinte questionamento:quando ações de modernização devem ser realizadas num software que atende processos de negócio, considerando a estratégia da organização? O questionamento proposto deve ser respondido utilizando a abordagem GQM+Strategies (GQM - Goals, Questions and Metrics) (BASILI et al., 2007), na qual é possível mensurar a tensão que a ausência e falhas de funcionalidades no software causam nos processos negócios. A abordagem GQM+Strategies foi escolhida porque relaciona a estratégia organizacional com os níveis tático e operacional. A figura 1 mostra como a abordagem deve 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ões que foram construídas com base na estratégia da empresa. Como são tratado sistemas de software degradados, procura-se encontrar dados que indiquem uma tensão entre os requisitos do processo de negócio e o software. É esta tensão que mostrará a necessidade da modernização no software, porque o desempenho da aplicação afeta o processo de negócio e consequentemente a estratégia da empresa. A figura 2 ilustra a interação entre os requisitos do software e o processo de negócio. A medição deve englobar também processos de negócios que foram adaptados de acordo com os comportamentos possíveis do software, ou seja, atividades que são realiza-
CAPÍTULO 1. INTRODUÇÃO 15 das porque devido a degradação do software não foi possível implementá-las completamente 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 sobre quais informações devem ser coletadas, uma vez que, as métricas são definidas com base nas questões elaboradas para atender os objetivos definidos em determinado nível (estratégico, tático e operacional).
CAPÍTULO 1. INTRODUÇÃO 16 1.3 Objetivos 1.3.1 Objetivo Geral Utilizar os conceitos sobre degradação e evolução de software para discutir um plano de medição referente a tensão do software versus a realização dos processos de negócios. Esse plano de medição deve estar alinhado com a estratégia organizacional e auxiliar na tomada de decisão sobre a realização de abordagens de modernização no software. 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ção delas. 3 Elaborar um exemplo de plano de medição utilizando a abordagem GQM+Strategies que traga resultados sobre as limitações e riscos dos processos de negócios ocasionados pelo software. 4 Apresentar um exemplo de como relacionar os dados obtidos no plano de medição com a técnica de modernização que pode ser executada de acordo com o objetivo da empresa. 1.4 Metodologia 1 o Estudar e relacionar os conceitos de evolução de software que inclui as leis de Lehman e os estágios de vida do software desenvolvido por Bennett. 2 o Buscar estudos sobre experimentos realizados para prolongar o uso do software dentro das organizações. 3 o Relacionar os conceitos de evolução de softwaree os objetivos das abordagens de modernização de software para determinar quando elas devem ser executadas. 4 o Delimitar o que deve ser medido para verificar se o software está degradado em relação ao uso que ele tem. 5 o Demonstrar com a estratégia da organização deve ser considerada para classificar o grau de degradação do software.
CAPÍTULO 1. INTRODUÇÃO 17 6 o Elaborar um exemplo de plano de medição utilizando os conceitos de degradação de software, a elaboração de métricas relacionadas com estratégia organizacional e a abordagem de modernização que pode reverter a degradação ou prolongar o uso do software de acordo com a necessidade da empresa. 1.5 Estrutura da Dissertação A dissertação está estruturada em cinco capítulos. Capítulo 1 - Introdução Este capítulo apresentou o escopo e todo o contexto da pesquisa. Foram apresentados também a questão de pesquisa que será desenvolvida no estudo, a abordagem empregada e o objetivo principal do trabalho. O capítulo finaliza com 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 Neste capí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 a necessidades do meio que estão incorporados. A discussão considera o ambiente no qual a aplicaçã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 que podem prolongar o uso da aplicação até que um novo software seja implantado para a substituição do software degradado. Capítulo 3 - Métricas de Processos de Negócios e Softwares, GQM e GQM+Strategies Este capítulo, inicialmente, apresenta conceitos e exemplos de métricas de processos de negócio e software. Esses conceitos auxiliam na discussão das abordagens GQM e GQM+Strategies que relacionam objetivos específicos aos dados coletados. 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ítulo traz a contribuição da pesquisa. São descritas métricas que indicam se a degradação do software 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 o uso do software na empresa até que aplicação seja substituída. São elaborados exemplos de indicadores do grau de degradação do software. Capítulo 5 - Conclusão e Pesquisas Futuras O capítulo organiza os diferentes resultados e os seus efeitos em uma empreitada de modernização. Neste capítulo também são indicados possíveis desdobramentos que essa pesquisa pode ter em trabalhos futuros.
18 2 Evolução, Degradação e Modernização de Software Neste capítulo são apresentados conceitos de evolução, ciclo de vida de software e leis de Lehman. O objetivo é construir uma argumentação que demonstre que sistemas de software classificados como e-type, irão ficar cada vez mais complexos e se degradarão com o passar do tempo. Isso acontece devido as inúmeras manutenções que são necessárias para adaptá-los ao meio que estão inseridos. Essa degradação pode ser amenizada por um tempo limitado caso ações de modernização sejam realizadas no software para prolongar o tempo de uso da aplicação. 2.1 Tipos de Softwares Os 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ção significa que um novo software deve ser desenvolvido; o P-Type que tem o resultado do processamento validado com o contexto do mundo real (real world problem solution). O problema especificado é preciso porém a aceitabilidade do resultado está condicionado a comparações com o mundo real. As alterações no software estão condicionadas a percepção do analista que está modelando a aplicação, porque o problema é estático; e o E-Type que mecaniza atividades humanas e está incorporado (embedded) ao meio que modela (LEHMAN, 1980). Os softwares do tipo e-type são modificados pelo meio e ao serem alterados para realizar os processos de negócio também são responsáveis por modificar o ambiente que estão inseridos. A solução do problema que esse tipo de software modela tem que ser alterada, porque o problema está sempre em modificação. As mudanças ocorrem por causa dos inúmeros agentes, como usuários, legislação, concorrências, clientes entre outros, de acordo com as necessidades do meio. O resultado do processamento do software é comparado com as mudanças que foram solicitadas pelos usuários da aplicação. A figura 3 representa 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ção do software de acordo com o ambiente e a comparação das mudanças solicitadas com o resultado 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 evolução que a adapta para o meio que é utilizada. Essa adaptação ocasiona a transformação
Capítulo 2. Evolução, Degradação e Modernização de Software 20 do software dentro de um período de tempo. 2.2 Evolução do Software Muitas alterações são realizadas no software durante o seu tempo de uso. Estas 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ão mudanças para corrigirem defeitos no código-fonte; (ii) adaptativas, são realizadas para que o software possa funcionar dentro de uma nova infraestrutura técnicas; (iii) perfectiva, na qual se enquadra qualquer alteração para melhorar as funcionalidades existentes, aumentar a performance, adicionar novas características ou melhorar a documentação existente; e (iv) preventiva, que são mudanças para facilitar manutenções futura como a reorganização das dependências internas para melhoria do acoplamento e coesão do software. A evolução do software é a transformação do modelo da aplicação dentro de um período de tempo devido a inúmeras manutenções realizadas na aplicação. Na evolução do 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. As manutençõ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ças entre 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 O que deve ser feitos depois? (quais itens devem ser corrigidos ou melhorados) Qual é o risco da manutenção? Como validar a manutenção realizada? Evolução Quão rápido um software cresce antes de ficar resistente a mudanças? Como as fronteiras internas desaparecem com o tempo? Quais são as diferenças das métricas entre software com o código aberto e os desenvolvidos de maneira industrial? De acordo com a tabela 1 de Godfrey e German (2008), na evolução do software existe a preocupação com a perda de extensibilidade (resistência a mudanças e desaparecimento das fronteiras internas). A extensibilidade da aplicação é a responsável pela adaptação do software as necessidades da empresa. A extensibilidade do software diminui por vários fatores. Aqui, trataremos o aumento da complexidade da aplicação com fator fundamental para a resistência do software a novas mudanças. Conforme a complexidade da representação do processo negócio
Capítulo 2. Evolução, Degradação e Modernização de Software 21 dentro software aumenta, as manutenções são mais arriscadas, caras e demoradas. Visaggio (2001) trata inúmeros fatores que aumentam a complexidade do software com o passar do tempo, como a duplicação de código-fonte, a obsolescência de algumas funcionalidades que não são removidas da aplicação, falta de documentação do software e outros fatores. Na realização de mudanças num software que está muito complexo, a funcionalidade desenvolvida pode atender apenas parcialmente os usuários de negócio que acabam adaptando sua maneira de trabalhar ao software e criando atividades desnecessárias dentro 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 na realização do processo de negócio. Novos defeitos também pode ser introduzidos na aplicação e funcionalidades que existiam anteriormente param de funcionar ou são realizadas de maneira parcial. Existe também o alto acoplamento dentro do software, que tem como consequência propagar efeitos negativos em funcionalidades que não foram alteradas durante uma determinada manutenção (efeito cascata). Em algumas organizações, mais de um software é utilizado para a realização de todos os processos de negócios. Estes softwares se comunicam entre si e qualquer alteração numa aplicação pode afetar as demais, o que aumenta a complexidade na manutenção do software e torna mais arriscada e cara qualquer modificação que precise ser realizada. A figura 5 ilustra um ambiente organizacional no qual mais de um software é responsável pelo processamento dos dados que irão compor o produto final. As setas cinzas significam trocas entre os sistemas de software. Essa interação pode ser a entrega do dado para a continuidade da computação, ou a consulta para verificar e controlar a integridade da informação. Qualquer mudança no processamento de um determinado software pode afetar o processamento de outro software. O ambiente faz com o que seja mais difícil lidar com a complexidade da aplicação. A transformação necessária do software para que não aconteça sua obsolescência também é responsável por degradar a aplicação. Essa degradação dentro da evolução do softwarepode ser observada nas leis de Lehman que descrevem o comportamento de alterações do software e-type ao longo do seu período de uso.
Capítulo 2. Evolução, Degradação e Modernização de Software 22 para a reali- Figura 5 Ambiente organizacional utilizando vários sistemas de software zação do produto final 2.3 Leis de Lehman As 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 apresentadas na tabela 2. As leis se inter relacionam e ajudam a explicar o que acontece com o software durante o seu período de uso.
Capítulo 2. Evolução, Degradação e Modernização de Software 23 Leis Mudança Contínua Tabela 2 Leis de Lehman (GODFREY; GERMAN, 2014) Aumento da Complexidade Descrição O sistema de softwaretorna-se progressivamente menos satisfatório com o passar do tempo, ao menos que, o sw seja continuamente adaptado as novas necessidades Um sistema de software torna-se progressivamente mais complexo com o passar do tempo, ao menos que, um trabalho 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 de produtos e processos que são produzidos Conservação da Estabilidade Organizacional Conservação da Familiaridade Crescimento Contínuo Declínio da Qualidade Sistema de Feedback 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 A quantidade de conteúdo novo em cada versão sucessiva do software tende a ser constante ou diminuir com o passar do tempo. A quantidade funcionalidades dentro de um software irá crescer com o passar do tempo a fim de atender seus usuários Será percebido um declínio de qualidade no sistema de software com o passar do tempo, ao menos que, o desenho seja rigorosamente mantido e adaptado a novas restrições operacionais O processo de evolução do software é formado por elementos multi-loop, multi-agentes, e multi-níveis. O feedback dos usuários é um fator importante para alterações realizadas no software A lei da Mudança Contínua acontece porque com o passar do tempo existe um descasamento entre o software e o domínio operacional. A discussão sobre isso é realizada na lei do Sistema de Feedback que apresenta como o processo de alteração no software acontece de acordo com diversos elementos do meio que a aplicação está inserida. A lei da Complexidade Crescente acontece devido às inúmeras mudanças necessárias no software e que são discutidas nas leis da Mudança Contínua e Crescimento Contínuo. As interações e dependências do software crescem de uma maneira não estruturada levando-o a sua entropia (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 software são realizadas pela gerência da organização com base no contexto existente no meio que a aplicação está inserida. Essas decisões são responsáveis pela maneira como o software irá evoluir. A lei da Auto Regulação é influenciada pela lei da Estabilidade Organizacional, porque outros fatores atuam no desenvolvimento do softwarecomo mão
Capítulo 2. Evolução, Degradação e Modernização de Software 24 de obra capacitada e quantidade de pessoas envolvidas no projeto. Esses fatores também são determinantes na quantidade de desenvolvimento eficaz do software. O resultado de todas 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 eficaz do software é a definição dos objetivos da aplicação e a familiaridade entre os itens que serão construídos. Isso acontece porque o número de alterações influencia na complexidade do software. A taxa de desenvolvimento do projeto e sua qualidade também é influenciada pela aquisição de conhecimento das informações sobre o que precisa ser implantado. Por isso, quanto mais funcionalidade desenvolvidas que não estão conectadas em relação a familiaridade, mais conhecimento deverá ser adquirido e maior será a complexidade do que deve ser implantado. Ao aumentar a complexidade do software, mais defeitos são introduzidos na aplicação durante novos desenvolvimentos ou manutenções corretivas da aplicação. As alterações no software ficam mais caras e arriscadas e o usuário final tem a sensação que o software já não é mais suficiente para atender suas necessidade, conforme descrito na lei do 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 de uso devido as inúmeras manutenções que o software precisa ter para continuar útil na realização do processo de negócio. 2.4 Ciclo de Vida do Software Nos 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) desenvolvimento 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 teste de aceitação; (ii) evolução, neste estágio acontece o crescimento do softwareem relação as funcionalidades que não foram entregues inicialmente porque ficaram foram do escopo ou 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 um conceito diferente do que foi apresentado durante o trabalho; (iii) serviço, neste estágio as alterações no software são menores devido falta de extensibilidade na aplicação provocada pela degradação resultante nas inúmeras manutenções; (iv) substituição, quando não é mais possível modificar o software e sua troca é inevitável. A figura 6 mostra as fases do Modelo de Estágio.
Capítulo 2. Evolução, Degradação e Modernização de Software 25 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 e com maior risco. É no estágio de serviço que as modificações no software começam a ser evitadas porque qualquer alteração pode ocasionar diversos problemas devido a complexidade da aplicação. A entrada neste estágio é silencioso. Quando os sintomas aparecem, o software já está dentro do estágio de serviço. A lacuna entre as necessidades do 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 para aumentar o tempo de uso da aplicação. Ações de modernização de software podem auxiliar 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 por uma nova aplicação. 2.5 Modernização de Software A modernização de software compreende abordagens que tem como objetivo prolongar o tempo de uso da aplicação. Comella-Dorda et al. (2000) define modernização como um processo intermediário entre a manutenção e a substituição do software, porque manté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 reverte ou diminui os efeitos da degradação devido a complexidade da aplicação. Este trabalho define a modernização de software como qualquer ação realizada que tenha como objetivo prolongar o tempo de uso do software. Essas ações podem es-
Capítulo 2. Evolução, Degradação e Modernização de Software 26 tar relacionadas com restruturação do software, melhorias funcionais, encapsulamento de interface e outras ações que modifiquem o software legado permitindo que a organização consiga utilizá-lo por um tempo maior que o previsto inicialmente. Para enfrentar a complexidade da aplicação por meio da modernização de software podem ser adotadas as abordagens de caixa preta ou caixa branca (COMELLA- DORDA et al., 2000) e (MALINOVA, 2010). Dependendo das características, complexidade, degradação que o software se encontra e os objetivos da organização, as duas abordagens 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 acontecem nas entradas e saídas da aplicação e também pode ser utilizada a interface do programa para entendimento do que é processado. Geralmente são utilizados os métodos de encapsulamento (wrapping) para realizar a modernização no software legado. No encapsulamento (wrapping) são construídas interfaces novas que exibem o conteúdo processado pelo sistema de software existente. A figura 7 mostra um software degradado que é 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 aplicaçã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 reengenharia do software consiste em examinar, entender e alterar a aplicação para reconstruí-la de uma nova forma (SNEED, 2008). De acordo com Pressman (2011), dentro da reengenharia de software são realizadas atividades de análise do inventário, reestruturação dos
Capítulo 2. Evolução, Degradação e Modernização de Software 27 documentos, engenharia reversa, restruturação do código-fonte, restruturação dos dados e engenharia direta. Para Comella-Dorda et al. (2000), na modernização de caixa branca a engenharia reversa e amplamente utilizada. Essa atividade consiste em "desmontar"o software para conhecer todas suas características, como código-fonte, componentes, interrelacionamentos e outros artefatos da aplicação. O objetivo é elaborar uma representação em 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 realizadas 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: interface do usuário (pessoas e software), dado e funcional. Na modernização da interface do usuário (user interface - UI) a usabilidade software é melhorada. Este tipo de abordagem é utilizado quando é necessário aumentar a satisfação de quem usa o software, porém ela deixa a aplicação mais inflexível para futuras manutenções (COMELLA-DORDA et al., 2000). Na modernização de dados, existem abordagens de encapsulamento que permitem que o acesso dos dados seja realizado através de protocolos ou interfaces diferentes das que foram projetadas inicialmente. O objetivo é melhorar a conectividade entre os softwares e permitir a integração do dado do software legado dentro de infraestruturas técnicas mais atuais. A modernização funcional consiste em encapsular o software legado, toda a aplicação ou parte dela. As abordagens da modernização funcional são mais complexas que as demais e podem ter um tempo maior de implantação. Um dos objetivos das abordagens da 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 era inicialmente, 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 as abordagens de modernização devem ser realizadas no software. A escolha da abordagem de modernização do softwareconsidera uma conjuntura de valores, que transcendem a parte técnica (KHADKA et al., 2014). Existem alguns exemplos na literatura acadêmica de como podem ser definidos quais ações devem ser realizadas. A pesquisa de Brodie e Stonebraker (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 a tabela 3 com as forças e fraquezas de cada abordagem.
Capítulo 2. Evolução, Degradação e Modernização de Software 28 Tabela 3 Abordagens de modernização de software(comella-dorda et al., 2000) Artefato Modernizado Screen Scraping Interface do usuário baseada em texto Banco de Dados com Gateway Protocolo de acesso proprietário Integração XML Protocolo de acesso proprietário Replicação do Banco de dados Banco de Dados centralizado Integração GCI Falta de coerência de dados, aplicável para um problema específico Falta de flexibilidade e aplicabilidade Custo Encapsulamento Orientado a Objetos Encapsulamento por Componentes Dado do mainframe ou serviço TM Qualquer parte do software Qualquer parte do software Alvo Forças Fraquezas Servidor XML Banco de dados replicado, distribuído páginas HTML em Modelo de orientação a objetos Modelo de Componentes Custo, time to market e suporte de internet Fer- de Custo, ramentas Suporte Flexibilidade Performance, confiabilidade Interface do usuário gráfica ou web Protocolo de acesso padronizado Custo e suporte de internet Flexibilidade Flexibilidade e serviços integrados Falta de flexibilidade e impacto limitado na manutenibilidade Impacto limitado na manutenibilidade Evolução da tecnologia Custo Independente do custo e esforço para realizar qualquer ação de modernização do software, seu resultado será temporário, por isso a substituição do software é algo inevitável. Isso acontece porque o software continuará a se transformar durante e após as ações de modernização, o que aumentará sua complexidade e dificultará a extensibilidade da aplicação. 2.6 Considerações Finais sobre o Capítulo O software se transforma com o passar do tempo por causa das inúmeras manutenções que são realizadas na aplicação. Essa transformação é responsável por sua degradaçã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 modernização que podem prolongar o tempo de uso da aplicação. Essas abordagens tem objetivos específicos e devem ser escolhidas de acordo com o grau de degradação do software e a
Capítulo 2. Evolução, Degradação e Modernização de Software 29 estratégia da organização. A organização deve identificar qual é o momento correto para realizar as ações de modernização no software. Por isso, no capítulo 3 serão discutidas métricas que podem auxiliar a empresa na identificação do momento e de qual ação de modernização de software deve ser realizada de acordo com as suas necessidades e estratégias.
30 3 Métricas de Processos e de Software, GQM e GQM+Strategies Neste capítulo são apresentados os conceitos de métricas de processos e de software. Também são discutidas as abordagens GQM e GQM+Strategiesutilizadas para a elaboração do plano de medição. Por fim, todos os conceitos apresentados são relacionados entre si. O propósito é demonstrar a lógica utilizada na junção do que é descrito durante o capítulo. 3.1 Métricas As 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 para produzir suas saídas). Ao analisar os números coletados é possível realizar ações para melhorar o planejamento da realização do produto ou processo, definir a alocação de recursos, avaliar a produtividade, identificar precocemente problemas potencias e diminuir a imprevisibilidade de alguma característica indesejada do objeto medido. As métricas podem ser usadas como fotografias do momento atual, que permitem avaliar os efeitos de alguma ação realizada no passado ou entender as características presentes para decidir se são necessárias realizar alterações no objeto. Elas também são coletadas e analisadas com o objetivo de prever tendências, comportamentos ou características indesejadas que podem acontecer no futuro. Essas previsões podem estar associadas a 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 específicas. As métricas relacionadas aos processos de negócio geralmente são referentes ao atendimento dos requisitos dos seus clientes, como prazos, custos de produção (que afeta o 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 novos desenvolvimento (funcionalidade que o software não possui) e manutenção da aplicação existente (como correções de defeitos de requisitos ou implantação). O comportamento do processo de negócio está relacionado ao software que o atende. Caso o resultado do processamento do software não seja satisfatório de acordo com 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 modificar o 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 processo de negócio e as de software é necessário discuti-las separadamente. Os tópicos seguintes apresentam 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ériaprima (entradas) em produtos mais elaborados (saídas). As entradas e saídas podem ser objetos físicos ou informações. A figura 8 ilustra o conceito de processo de negócio utilizado nesta pesquisa. Figura 8 Processo de Negócio As saídas do processo de negócio precisam satisfazer todos os stakeholders (partes interessadas, como clientes, fornecedores,a empresa, legislação entre outros). Esta satisfação está relacionada com diversos fatores como prazos, custos e atendimento dos requisitos planejados para o produto. Para gerenciar o desempenho do processo de negócio e verificar se ele e o produto atendem as necessidades definidas é necessário criar medições que possam verificar o planejado versus o realizado.
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 32 As métricas são elaboradas para medição de características específicas do processo de 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 e nível de satisfação do cliente são relacionadas com o desempenho do processo negócio mesmo não estando diretamente ligada a realização dele, são medições indiretas. Para relacionar 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 relacionados a 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 elaboradas com o objetivo estratégico que deve ser alcançado. Existem outras abordagens que analisam o processo de negócio de uma forma mais ampla, como a Gestão de Qualidade Total ou Total Quality Management (TQM), que tem como objetivo entregar produtos de qualidade. Os objetivos são atingidos através do envolvimento de toda a organização e stakeholders. A medição é fundamental para verificar se o planejamento para os processos de negócios e produtos estão sendo cumpridos e se as tendências de comportamento dos produtos e processos estão conforme o planejado. Caso os requisitos definidos, tanto para o produto quanto para o processo de negócio, não sejam cumpridos, são realizadas açõ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 comportamento da aplicação influencia nos resultados das medições definidas para processos de negócios e produto. Não é possível realizar modificações nos processos organizacionais caso o software não seja modificado. Conhecer a capacidade de extensão das funcionalidades da aplicação é fundamental para planejar mudanças nos processos de negócio da organização. A extensibilidade da aplicação deve ser medida junto com as necessidades de mudanças dos processos de negócios e produtos. Por isso, as métricas de software são fundamentais para entender o quanto a aplicação é capaz de suportar os processos de negó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) ilustra isso 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 complexidade da aplicação, após essa data, a preocupação foi construir mecanismos para medir características específicas do software desenvolvidos sobre o paradigma de orientação ao objeto.
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 33 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. Quanto mais o complexo estiver o software, mais tempo será necessário para realizar as mudanças desejadas. As Métricas como Linhas de Código (LOC), Halstead e McCabe (conhecida também como Complexidade Ciclomática) auxiliam na medida de tamanho e complexidade do software. De acordo com Riguzzi (1996), as métricas Linhas de Código (LOC) são as mais simples que existem. Porém, mesmo com tanta simplicidade, ainda existem pontos não de-
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 34 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ção na mesma linha e há dúvidas se mesmo assim devem ser contadas linhas ou instruções do código-fonte do software. Ao utilizar as métricas LOC não é possível determinar qual é a qualidade do código-fonte e consequentemente a complexidade do software fica limitado ao tamanho da aplicação. As métricas de Halstead são baseadas na suposição que o software é composto de operandos (variáveis e constantes existente no software) e operadores (símbolos ou combinações de símbolos que influenciam no valor de um operando). O número de operandos e operadores idênticos e repetidos determinam atributos como tamanho do software (somató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 a quantidade de caminhos independentes dentro do grafo (MCCABE, 1976). As métricas de McCabe são desenvolvidas através de caminhos básicos dentro do software que quando combinados irão gerar todos os caminhos possíveis dentro da aplicação. A figura 10 ilustra os caminhos dentro de um software utilizando o grafo de controle. Figura 10 Grafo Riguzzi (1996)
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 35 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 propostos por McCabe (1976) é possível saber quantos caminhos são independentes e quantos são combinações lineares. A estratégia da métrica é medir a complexidade do software pelo nú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 orientação ao objeto tem como um dos objetivos verificar o quanto o projeto da aplicação utiliza as abstrações do paradigma, como, herança, reuso, encapsulamento entre outras características. O resultado dos cálculos mostra a complexidade em realizar manutenções no 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 identificar a qualidade do software através de medições quantitativas relacionadas ao uso das abstraçõ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 (total ausência) a 1 (máxima presença). Ao utilizar esse intervalo de valores, o resultado obtido independe do tamanho do software avaliado. As métricas MOODs são compostas pelas medições: (1) Fator de Ocultação do Método (MHF); (2) Fator de Ocultação de Atributo (AIF), tanto a métrica AIF quanto MHF medem o nível de encapsulamento; (3) Fator de Herança de Método (MIF), (4) Fator de 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 das classes 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. Com os resultados das medições: (1) Métodos Ponderados por Classe (WMC); (2) Profundidade de Herança (DIT); (3) Número de Filhos (NOC), (4) Acoplamento entre Classes de Objetos (CBO), (5) Respostas para uma Classe (RF) e (6) Falta de Coesão dos Métodos (LCOM), é possível determinar a dificuldade em fazer manutenção no software de acordo com a sua complexidade de desenvolvimento e testes e possibilidade de reuso dos componentes do software. Outas métricas foram desenvolvidas para indicar a qualidade do desenho (design)de um software. Estas métricas medem atributos internos (relacionado diretamente com atributo) da aplicação e através disso é possível determinar quais os atributos externos (relação entre atributo e meio), estão relacionados (RIGUZZI, 1996).
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 36 Tabela 4 Produto x Atributos de Software Produto Atributo interno Atributo externo Requisitos Tamanho, reuso, modularidade, redundância e funcionalidade Especificação Desenho Código Conjunto de Testes Tamanho, reuso, modularidade, redundância e funcionalidade Tamanho, reuso, modularidade, acoplamento e coesão Tamanho, reuso, modularidade, acoplamento, coesão e complexidade do fluxo de controle Tamanho e nível de cobertura Entendibilidade e estabilidade Entendibilidade e manutenibilidade Compreensibilidade e manutenibilidade Confiabilidade, usabilidade, reusabilidade e manutenibilidade Confiabilidade no produto entregue 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 ser definido qual é o seu significado e depois relacionado os atributos internos ao externo com o objetivo de definir as medições necessárias. A tabela 4 exemplifica o relacionamento entre os atributos internos e externos sobre qualidade do software. Neste caso, a qualidade está 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ível relacionar os atributos externos do software aos atributos do negócio que são afetados pela aplicação. Ao realizar uma relação mais ampla, é possível criar os vínculos com objetivos 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 aplicado com 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. Na aplicação da abordagem é elaborado um conjunto de métricas a partir de questões que respondem os objetivos, ou seja, as métricas são construídas de maneira top-down (de cima para baixo) (BASILI; SHULL; LANUBILE, 1999). Assim, as métricas estão vinculadas
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 37 com os objetivos que devem ser alcançados e isso ajuda a não coletar dados desnecessários para as análises que devem ser realizadas (MENDONçA; BASILI, 2000). A figura 11 ilustra como a abordagem é aplicada. Figura 11 Estrutura de Hierarquia do modelo GQM O nível conceitual é definido de acordo com os elementos: qualidade, ponto de vista e ambiente. O objetivo pode estar relacionado a produto, processos e recursos. Para que seja possível elaborar as questões concisas, os objetivos devem ser construídos de maneira clara, por isso, o modelo da tabela 5 deve ser utilizado na escrita dos objetivos. medido. As questões são elaboradas para descrever a avaliação do objeto que está sendo 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 ser objetivas (dependem apenas do objeto que está sendo medido) ou subjetivas (dependem do objeto e contexto). As questões podem ser utilizadas para definir métricas de outros objetivos assim como, métricas podem ser repetidas para responder questões diferentes. Elementos Objeto Tabela 5 Elaboração de Objetivos GQM Descrição O que deve ser examinado, pode ser produto, processo ou recurso Propósito Por que o objeto deve ser examinado, o que é?, avaliar (o que é bom?), predizer (pode ser estimado alguma coisa no futuro?), controle (pode ser manipulado eventos?) e melhorar (pode ser melhorado o evento?) Foco Perspectiva Contexto Ambiente Atributo que deve ser examinado, na visão de algum aspecto do objeto em estudo Perspectiva da examinação, de uma pessoa ou necessidade de informação Contexto do escopo da examinação, descrição do ambiente no qual a medida é realizada Meio no qual a medida é realizada A realização da abordagem é composta por 4 fases que são: (i)definição, (ii)planejamento,
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 38 (iii)operação e (iv)interpretação. Os resultados obtidos através das métricas devem ser analisados para verificar aderência em relação aos objetivos traçados. Pode acontecer que as métricas elaboradas não sejam adequadas para indicar se o objetivo foi alcançado. O plano de medição deve ser refinado para fornecer as respostas corretas de acordo com os objetivos definidos. O GQM vincula objetivos, questões e métricas, contudo seu relacionamento fica apenas nos objetivos definidos para medição. A abordagem GQM não vincula explicitamente os objetivos de medição com os objetivos estratégicos da empresa. A abordagem GQM+Strategies é uma maneira de vincular: os objetivos estratégicos, as medições definidas para o processo de negócio e o software usado para realizá-lo. 3.3 GQM+Strategies O GQM+Strategies é evolução da abordagem GQM. O intuito é alinhar, de maneira explícita os objetivo organizacionais, estratégias e suposições com os objetivos do modelo de medição do software (BASILI et al., 2007) e (BASILI et al., 2014). Isso porque, quando um empresa tem os processos de negócios altamente dependentes do software, o gerenciamento da organização está diretamente vinculado aos resultados obtidos do processamento da aplicação (BASILI et al., 2014). A elaboração do plano de medição é similar utilizando as abordagens GQM e GQM+Strategies. O objetivo de medição, construído no nível conceitual, é operacionalizado através das questões que são respondidas pelas métricas. A análise dos resultados direciona a tomada das decisões pela empresa. Esta análise também é importante porque verifica o quanto as métricas estão alinhadas com os objetivos de medição. Caso as métricas não sejam adequadas (não respondam as questões), novas medições devem ser elaboradas. A diferença das abordagens existe porque na abordagem GQM+Strategies objetivo de um determinado nível se relaciona com o objetivo do nível abaixo. Para que a vinculação seja realizada 8 elementos se inter-relacionam. A figura 12 ilustra como os elementos estão conectados e a tabela 6 descreve cada um deles.
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 39 Figura 12 Metamodelo - componentes do GQM+Strategies Ao determinar e definir quais são os objetivos do negócio, a organização precisa formalizar suas motivações e necessidades. Também é construído o racional que utiliza os fatores 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 template da tabela 7 na descrição dos objetivos da organização. Elementos Objetivos organizacionais Fatores de contexto Suposições Decisões estratégicas Atividades estratégicas Objetivos do nível mais baixo Elemento Goal+Strategies Modelo de Interpretação (Grafo GQM) Tabela 6 Elementos do componentes GQM+Strategies Descrição Objetivos que a organização deseja executar para alcançar o resultados dos seus planos no nível mais alto da empresa Variáveis ambientais que representam o ambiente organizacional e afetam o tipo do modelo de medição e os dados que podem ser usados Estimam incertezas que podem afetar a interpretação dos dados Um conjunto de abordagens possíveis para o alcance de um objetivo Um conjunto de atividade para ajudar a alcançar a estratégia definida Um conjunto de objetivos num determinado nível que faz parte de um objetivo num nível mais alto. Como por exemplo, o objeto de um projeto que é parte de uma estratégia da organização Um único objetivo derivado da estratégia, dos fatores de contexto e suposições Desdobramento em objetivos questões e métricas do objetivo que está num nível mais alto
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 40 Tabela 7 Elaboração de objetivos organizacionais elaborado com base no GQM+Strategies Item Atividade Foco Objeto Grandeza (Grau) Prazo Escopo Restrições/ Limitações Relação com outros objetivos Descrição Atividade básica que deve ser executada para alcançar o objetivo O principal foco do objetivo de negócio O objeto que está sendo considerado A quantificação do objetivo demonstrado por uma grandeza Prazo que a grandeza deve ser alcançada O escopo do objetivo Restrições que podem limitar o atingimento do objetivo Relação potencial com outros (complementares ou concorrentes) objetivos Depois que os objetivos da organização estão definidos, considerando os fatores de contexto e suposições, a organização deve elaborar uma lista de estratégias para alcançar as necessidades identificadas. Na elaboração das decisões estratégicas também devem ser considerados os fatores externos e suposições que restringem as ações que poderiam ser realizadas. Com as decisões estratégicas é possível definir as atividades que serão realizadas. 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, ponto de vista e ambiente). As questões, métricas e critérios de avaliação são desenvolvidos com base nos objetivos definidos. O modelo de interpretação torna possível agregar e interpretar os resultado das medições. Os resultados obtidos neste ponto estão relacionado a uma visão mais alto nível dos processos operacionais, como o retorno do investimento de um 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 construir as decisões, atividades estratégicas e plano de medição. Seguindo a abordagem GQM+Strategies os objetivos estarão vinculados em diversos níveis organizacionais e qualquer ação realizada no software deverá ter o efeito refletido no processo de negócio e consequentemente na estratégia da empresa. 3.4 Considerações Finais sobre o Capítulo Existem inúmeras pesquisas sobre métricas de software que indicam a complexidade e/ou a qualidade do desenho dos softwares construídos sob o paradigma de orientação ao objeto. Os resultados das métricas mostram os esforços necessários para alterar
Capítulo 3. Métricas de Processos e de Software, GQM e GQM+Strategies 41 as funcionalidades da aplicação. Ao utilizar a abordagem GQM+Strategies é possível elaborar o plano de medição seguindo determinados passos e considerando todo o contexto da empresa, incluindo o software. A análise dos resultados obtidos das métricas direcionam a empresa quanto as decisões relacionadas aos seus sistemas de software com base em todo o contexto organizacional. Estas decisões podem estar relacionadas a ações de 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 elaborar o plano de medição que demonstre a degradação do software. Algumas das medições estão relacionadas ao efeito da degradação do software na realização dos processos de negócio. Como a degradação do software foi definida anteriormente de acordo com o atendimento dos requisitos de negócio, o objetivo é relacionar o comportamento do software com os resultados dos indicadores do processo de negócio e das características do produto. De uma maneira mais ampla, o comportamento do software é determinante para a realização dos objetivos organizacionais, uma vez que, ele molda o funcionamento do processo de negócio e consequentemente a característica do produto. Por isso, as métricas apresentadas são relacionadas com os objetivos da organização. 4.1 Comportamento do processo de negócio versus o software O 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 software também precisa ser modificado. Contudo, mudanças na aplicação não são tão rápidas quanto as alterações no processo de negócio. As mudanças no software exigem um planejamento do que deve ser alterado na aplicação, análise de quais cenários serão impactados e verificação se as funcionalidades foram implantadas conforme a nova necessidade para a realização do processo de negócio. As verificações são necessárias para garantir que as mudanças foram realizadas dentro do esperado e não há impactos em outras partes do software e processos de negócios que utilizam as saídas da aplicação que foi 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 processamento de outra aplicação que utiliza as informações do software modificado. Isso pode acontecer devido ao desconhecimento de todas as interconexões entre processos e sistemas de software no planejamento de mudança da aplicação. Quando o software está no estágio de serviço, apresentado por Benett, Rajlich e Wilde (2000), Bennett e Rajlich (2000a) e Bennett e Rajlich (2000b), as alterações costumam ficar cada vez mais complexas e consequentemente demoradas para serem entregues, devido a dificuldade em realizá-las, o alto custo e o risco envolvido. Algumas vezes, a funcionalidade é implementada parcialmente por motivos que podem estar relacionados 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 funcionalidade realmente foi implantada como foi projetada. Quando uma funcionalidade é implementada parcialmente, todo o ambiente que o software está inserido (pessoas, produtos e outros softwares) tem impacto. A não implementação da funcionalidade também influencia outros softwares que estão interconectados porque deixa de entregar algum resultado para a continuidade da realização do produto final. Logo, a degradação do software está relacionada com o não atendimento a necessidades do negócio. Porém, se o software não for alterado conforme a necessidade da empresa, não será possível fazer alguns processamentos de dados para a realização do produto. Determinadas características não serão realizadas ou ter um risco alto na realização do processo de negócio devido as inúmeras intervenções no banco de dados para corrigir as informações que foram processadas de maneira incorreta ao especificado. Tudo isso tem efeito no atingimento dos objetivos da organização. Se a empresa não consegue atender as 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 deve definir seus objetivos no nível organizacional. Essa definição permite adotar estratégias e elaborar os objetivos em níveis menores (como tático e operacional). O atingimento do conjunto de objetivos em níveis mais baixos será responsável pelo alcance do objetivo maior que é definido no nível estratégico da empresa. Ao explicitar as dependências entre os diversos desempenhos dos processos de negócios é possível definir a contribuição de cada elemento dentro da empresa para o atingimento do objetivo organizacional. Na utilização da abordagem GQM+Strategies os objetivos organizacionais e estratégias são explicitadas. Também é possível construir a dependência dos objetivos elaborados para realizar o que foi proposto pela organização. 4.2 Plano de Medição com base na abordagem GQM+Strategies Conforme descrito no item 3.3, a abordagem GQM+Strategiestem como intuito explicitar os objetivos organizacionais e vincula-los com as métricas definidas para cada parte da empresa. A vinculação é fundamental no atingimento da meta que foi definida para o objetivo organizacional porque mostra as interdependências dentro da empresa e quais pontos devem ter mais atenção. Ao elaborar o plano de medição com base na abordagem GQM+Strategies a organização definirá explicitamente o seu objetivo organizacional, atribuindo a meta que deve ser 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 objetivo pode ser alcançado? Durante a elaboração destes elementos são considerados os fatores ambientais e suposições que afetam o atingimento da meta proposta pela organização. A
Capítulo 4. Indicadores de Degradação do Software 44 importância em considerar os fatores de contexto e suposições é criar objetivos organizacionais 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 do operacional da organização. Novamente fatores de contexto e suposições são considerados na definição das metas e ações que serão realizadas para o alcance destas metas. Em qualquer 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 interpretação, mostrado na figura 12. Na figura 13 é ilustrada a abordagem GQM+Strategies e a 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 demostrem a interferência do software na realização do processo de negócio. Como o processo de negócio é altamente dependente do software, vários elementos na realização do processo e características do produto podem ser considerados. Entre estes elementos, estão: prazo de entrega; confiabilidade do produto final e custo para a realização do produto (treinamento de usuários, reprocessamentos dos dados, atividades necessárias por limitação do software, como controles paralelos, etc). O custo para a realização do produto deve considerar todos os custos do software, tanto sua manutenção como o impacto que a aplicação causa na entrega do produto final. A figura 14 ilustra como métricas de software são utilizadas em questões relacionadas a processos de negócios e produtos.
Capítulo 4. Indicadores de Degradação do Software 45 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 custo e efeito para a empresa caso a mudança não seja realizada conforme o planejado (tanto a funcionalidade quanto o prazo definido), a dificuldade em alterar o software devido ao seu tamanho e complexidade (podem ser utilizadas métricas como LOC, CK, MOOD e outras). Dependendo do grau de degradação que o software está, algumas mudanças serão evitadas pela empresa e outras soluções poderão ser implantadas, como o desenvolvimento de 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. Essas medições podem estar relacionadas com a utilização e/ou satisfação da nova implantação versus a expectativa que havia sobre o que foi implantado. Está expectativa pode estar relacionada 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 relacionadas diretamente ao software verificam se novos defeitos foram introduzidos na aplicação, se existiram 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 empresa foram afetados pela mudança, além de, outras medidas consideradas importantes pela organização. Nas atividades rotineiras para a realização do processo de negócio, as métricas relacionadas ao software podem medir o custo e o efeito das intervenções necessárias