PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU EM
GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA
INFORMAÇÃO
Mestrado
AVALIAÇÃO PRÓ-ATIVA DA DETERIORAÇÃO DE
SISTEMAS DE INFORMAÇÃO POR MEIO DE MEDIDAS
DE GESTÃO
Autor: André Luiz Pimentel Queiroz
Orientadores: Profª Drª Káthia Marçal de Oliveira
Prof. Dr Nicolas Anquetil
AVALIAÇÃO PRÓ-ATIVA DA DETERIORAÇÃO DE SISTEMAS DE INFORMAÇÃO POR MEIO DE MEDIDAS DE GESTÃO
Brasília 2008
Dissertação apresentada ao programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília como requisito parcial para obtenção do Título de Mestre.
Orientadora: Profª. Dra. Káthia Marçal de Oliveira
Ficha elaborada pela Coordenação de Processamento do Acervo do SIBI – UCB.
Q3a Queiroz, André Luiz Pimentel.
Avaliação pró-ativa da deterioração de sistemas de informação por meio de medidas de gestão / André Luiz Pimentel Queiroz. – 2008. 183 f.: il. ; 30 cm.
Dissertação (mestrado) – Universidade Católica de Brasília, 2008. Orientador: Káthia Marçal de Oliveira.
Co-orientador: Nicolas Anquetil.
1. Sistemas de recuperação da informação – Administração. 2. Sistemas de informação gerencial – Avaliação – Deterioração. 3. Gestão do conhecimento. I. Oliveira, Kathia Marçal de, orient. II. Anquetil, Nicolas, co-orient. III. Título.
Nunca consegui esquecer aqueles olhos. Os olhos de Ana. O que foram aqueles olhos?...
Em especial a Deus, por mais uma conquista.
Aos orientadores, Prof. Dra. Káthia Marçal de Oliveira e Prof. Dr. Nicolas Anquetil, por dedicarem sua competência à execução deste estudo.
À minha família, pelo apoio e amor incondicionais.
À Ana, pelo conforto nos momentos de ansiedade, as inúmeras revisões e seu sorriso.
Aos professores e colegas do MGCTI, pela sempre proveitosa troca de idéias.
Pedras no caminho? Guardo todas, um
dia vou construir um castelo...
Com a atual importância dos sistemas de informação para as organizações em geral, questões relacionadas à sua modernização tem recebido maior atenção e relevância. Muitos métodos foram propostos para apoiar uma organização na escolha da melhor alternativa para modernização de um sistema, entretanto, esses métodos não abordam esta questão sobre a ótica da pró-atividade, ou seja, não buscam fornecer informações necessárias para a identificação precoce da deterioração destas aplicações. Esse trabalho apresenta uma abordagem, baseada em medidas de gestão, para apoiar a monitoração contínua da deterioração de um sistema, permitindo ao gestor realizar ações de ajuste o mais cedo possível. Esta abordagem foi definida utilizando o método de medição GQM (
Goal-Question-Metric), baseada em conceitos identificados na literatura e levou em consideração a
opinião de gestores de sistemas. Aplicação prática em diferentes sistemas de uma grande empresa mostrou a viabilidade de coleta das medidas, indicando os sistemas em deterioração, podendo favorecer a atuação pró-ativa dos gestores.
With the current importance of information systems for organizations in general, issues related to its modernization has received more attention and importance. Many methods have been proposed to support an organization to choose the best alternative for upgrading a system, however, these methods do not address this issue on the view of pro-activity, i.e. not seek to provide the necessary information for the early identification of the deterioration of these applications. This paper presents an approach, based on management measures to support the continuous monitoring of a system’s deterioration, allowing managers to perform corrective actions as soon as possible. This approach was defined using the method of measurement GQM (Goal-Question-Metric), based on concepts identified in the literature and took into account the opinion of system’s managers. Practical application in different systems of a large company showed the feasibility of collecting the measures, indicating the systems in deterioration and may encourage pro-active performance of managers.
Figura 1 - GQM - Hierarquia entre Objetivos, Questões e Medidas. ...34
Figura 2 - Abstract sheet ...35
Figura 3 - Portfolio de Aplicações (SNEED, 1995) ...51
Figura 4 - Visão geral do método SABA (BENNETT, RAMAGE e MUNRO, 1998)...55
Figura 5 - Atividades do Método de Avaliação (RANSOM, SOMMERVILLE, WARREN,1998) ...56
Figura 6 - Fórmula para cálculo de valor de qualidade (VISAGGIO, 2000)...59
Figura 7 - GQM - Níveis Conceitual e Operacional ...75
Figura 8 - Seleção das Medidas Analisadas ...89
Figura 9 - Painel Consolidado das Medidas ...108
Figura 10 - Painel Detalhado das Medidas (Questão Q1)...111
Figura 11 – Painel Consolidado de medidas - sistema S1 ...116
Figura 12 - Q1 - Painel detalhado de medidas para o sistema S1 ...121
Figura 13 - Q2 - Painel detalhado de medidas para o sistema S1 ...123
Figura 14 - Q3 - Painel detalhado de medidas para o sistema S1 ...124
Figura 15 - Painel Consolidado de Medidas - sistema S2...127
Figura 16 - Q1 - Painel detalhado de medidas para o sistema S2 ...131
Figura 17 - Q2 - Painel detalhado de medidas para o sistema S2 ...134
Figura 18 - Q3 - Painel detalhado de medidas para o sistema S2 ...135
Figura 19 - Painel Consolidado de Medidas - sistema S3...137
Figura 20 - Q1 - Painel detalhado de medidas para o sistema S3 ...142
Figura 21 - Q2 - Painel detalhado de medidas para o sistema S3 ...144
Quadro 1 - Exemplos de Atributos internos e externos ...25
Quadro 2 - Componentes da medição de software (FENTON, PFLEEGER,1997) ...26
Quadro 3 - Características e Sub-características da ISO 9126-1...36
Quadro 4 - Medidas externas de manutenibilidade (ISO/IEC 9126-2, 2002) ...38
Quadro 5 - Medidas internas de manutenibilidade (ISO/IEC 9126-3, 2002) ...40
Quadro 6 - Estratégias de Evolução (WARREN e RANSOM , 2002)...50
Quadro 7 - Fórmulas de Cálculo de Benefícios...54
Quadro 8 - Exemplo de medidas de qualidade e respectivos baselines. ...58
Quadro 9 - Subconjunto das medidas propostas por De Lucia, Fasolino e Pompella ...61
Quadro 10 - Quadrante da Análise de Portfolio (Lucia, Fasolino e Pompella, 2001) 62 Quadro 11 - Modelo de qualidade utilizado no framework de avaliação (AVERSANO et al, 2004) ...63
Quadro 12 - Exemplo de critiquing table (AVERSANO et al, 2004) ...65
Quadro 13 - Resumo dos aspectos de desempenho e seus indicadores (HARRIS, McROY, 2006)...66
Quadro 14 - Conceitos e ações recomendadas. ...67
Quadro 15 - Instrumento para avaliação da Complexidade de sistemas (HARRIS e MCROY, 2007)...69
Quadro 16 - Objetivo definido...73
Quadro 17 - Premissas para a Seleção das Medidas ...77
Quadro 18 - Subconjunto de Medidas de Qualidade Técnica ...79
Quadro 19 - Subconjunto de Medidas de Valor de Negócio ...82
Quadro 20 - Demais Medidas Propostas nos Métodos de Apoio à Decisão ...83
Quadro 21 - Exemplo da Avaliação das Medidas...88
Quadro 22 - Abstraction Sheet: monitorar deterioração do sistema...90
Quadro 23 - Detalhamento das necessidades citadas pelos gestores...92
Quadro 24 - Relação entre as Medidas e Questões da Abordagem ...96
Quadro 25 - Medidas Definidas para a Questão 1 ...97
Quadro 26 - Medidas Definidas para a Questão 2 ...100
1 INTRODUÇÃO ...15
1.1 Motivação e contexto... 15
1.2 Objetivos e suposições ... 18
1.2.1 Objetivo Geral ... 18
1.2.2 Objetivos Específicos... 18
1.3 Metodologia ... 19
1.3.1 Classificação da Pesquisa ... 19
1.3.2 Suposições... 20
1.3.3 Coleta de Dados ... 20
1.4 Organização do trabalho ... 21
2 MEDIÇÃO ...22
2.1 Introdução... 22
2.2 Definições ... 23
2.2.1 Atributos ... 24
2.2.2 Entidades ... 25
2.2.3 Escala ... 27
2.2.4 Medição objetiva e subjetiva... 28
2.2.5 Medidas x Métricas x Indicadores ... 29
2.3 Abordagens de medição... 31
2.3.1 Abordagem GQM (Goal-Question-Metric) ... 33
2.4 Medição da manutenibilidade na ISO/IEC 9126 ... 36
2.5 Considerações finais do capítulo... 42
3 MODERNIZAÇÃO DE SISTEMAS...43
3.1 Introdução... 43
3.2 Deterioração de sistemas... 44
3.3 Sistemas legados ... 46
3.4 Estratégias de modernização de sistemas... 48
3.5 Métodos de modernização de sistemas ... 50
3.5.1 Método proposto por Sneed ... 50
3.5.2 Método SABA... 54
3.5.3 Método proposto por Ransom, Sommerville e Warren ... 56
3.5.4 Método proposto por Visaggio... 58
3.5.5 Método proposto por De Lucia, Fasolino e Pompella... 60
3.5.6 Método proposto por Aversano et al... 62
3.5.7 Método proposto por Harris e McRoy... 66
3.5.8 Medição nos Métodos de Modernização ... 67
4.1 Introdução... 71
4.2 Definição das medidas ... 72
4.2.1 Definição do Objetivo... 72
4.2.2 Seleção das Medidas... 75
4.2.3 Especificação das Medidas ... 96
4.3 Procedimento de análise das medidas ... 105
4.4 Forma de apresentação das medidas ... 108
4.5 Considerações finais do capítulo... 111
5 APLICAÇÃO PRÁTICA DA ABORDAGEM ...113
5.1 Introdução... 113
5.2 Sistema S1 ... 114
5.2.1 Painel Consolidado ... 115
5.2.2 Painel Detalhado... 120
5.3 Sistema S2 ... 126
5.3.1 Painel Consolidado ... 126
5.3.2 Painel Detalhado... 131
5.4 Sistema S3 ... 136
5.4.1 Painel Consolidado ... 137
5.4.2 Painel Detalhado... 141
5.5 Considerações finais do capítulo... 147
6 CONCLUSÃO E PERSPECTIVAS FUTURAS ...149
6.1 Contribuições ... 152
6.2 Limitações... 153
6.3 Trabalhos futuros... 153
7 REFERÊNCIAS...155
8 APÊNCIDE A – MEDIDAS DUPLICADAS ...163
1 INTRODUÇÃO
1.1 Motivação e contexto
De acordo com a primeira lei de Lehman (LEHMAN et al., 1997), a lei da
mudança contínua, um sistema ou software em operação deve sofrer constante
evolução ou ficará desatualizado com relação aos novos requisitos de negócio do mundo real, tornando-se, então, obsoleto.
Estas atividades, necessárias para manter um sistema atualizado, são conhecidas por Manutenção de Software. Segundo Martin e McClure (1983),
manutenção de software são as modificações que tem de ser feitas em uma
aplicação após sua disponibilização para os seus usuários. von Mayrhauser (1990) acrescenta: “manutenção compreende a vida de um sistema desde o início de sua operação até sua retirada do ambiente de operação”.
Um breve histórico dos estudos realizados a respeito do tamanho desta fase no ciclo de vida de um sistema, indica que, com relação ao custo total, o seu percentual vem crescendo: passou de 50-75% nos anos 80 e 90 (SOMMERVILLE, 1995 p.660; LIENTZ, SWANSON, 1980; MCKEE, 1984), para algo em torno de 90% nos dias atuais (GLASS, 2003; SEACORD, PLAKOSH, LEWIS, 2003).
Na literatura, vários modelos e ferramentas de apoio e suporte a decisão sobre a modernização de sistemas legados foram apresentados (SNEED, 1995; RANSOM, SOMMERVILLE e WARREN, 1998; VISAGGIO, 2000; DE LUCIA, FASOLINO, POMPELLA, 2001; AVERSANO et al, 2004; HARRIS e McROY, 2007).
Sneed (1995), uma das publicações mais relevantes na discussão sobre estes métodos, propõe um conjunto de passos, que incluem mensurar a qualidade técnica e o valor de negócio, e que tem por objetivo avaliar se o método de reengenharia é a melhor alternativa para a modernização de aplicações. Ainda sobre a reengenharia de sistemas, Ransom, Sommerville e Warren (1998) também se baseiam em medidas que representem a qualidade técnica e o valor de negócio da aplicação para determinar a estratégia de evolução das aplicações.
Com o objetivo de detalhar a especificação das medidas utilizadas nestes modelos, Visaggio (2000) estende as pesquisas publicadas até o momento, propondo não só um conjunto de medidas de qualidade técnica e de valor de negócio, mas também, os passos para o cálculo destas medidas de avaliação. Entretanto, este modelo requer um grande esforço de tempo e recursos, uma vez que toda a sua análise está baseada na decomposição dos sistemas em componentes e na posterior avaliação e definição da melhor estratégia de evolução a ser implementada para cada componente identificado.
A estratégia de avaliar cada componente de um sistema também foi adotada por De Lucia, Fasolino e Pompella (2001) e Aversano et al (2004). Em ambos os
não satisfatórios. De acordo com estes modelos, cada estratégia de modernização de sistemas legados está relacionada com a melhoria da qualidade de uma ou mais métricas avaliadas.
Pesquisas posteriores conduzidas por Koskinen et al (2004) e Koskinen et al
(2005) com especialistas da área de manutenção de sistemas, apontam como as principais necessidades para este tema: o suporte metodológico geral, a sistematização do processo, a disponibilização de métodos de estimativa de benefícios, mais informações sobre as opções que devem ser consideradas e um
check list de ações a serem desenvolvidas. Destacam, ainda, a pouca
disponibilidade de ferramentas para a identificação precoce de necessidades de modernização de sistemas, ou seja, os métodos existentes são normalmente utilizados quando já se possui a percepção de que alguma ação deve ser executada para modernização de um sistema, sendo, portanto, uma forma reativa de lidar com o problema.
A importância da pró-atividade nos métodos de suporte à decisão sobre a modernização de sistemas destaca-se diante dos atuais níveis de utilização e relevância destes ativos nas organizações. Esta pró-atividade concretiza-se através da detecção precoce da deterioração dos sistemas de informação, da otimização do uso destes recursos e da possibilidade do tratamento de problemas em seus estágios iniciais. Para Lyons (1981, apud Miller e Morley, 1996), a deterioração dos
sistemas resulta da inabilidade do sistema em modernizar-se para atender às mudanças nos processos de negócio das organizações.
identificação precoce de problemas de desempenho de aplicações. Ainda assim, este trabalho além de não fornecer o processo de como estes indicadores devem ser apurados, também não apresenta uma lista exaustiva de critérios a serem considerados.
Neste contexto, percebe-se a importância de buscar soluções que, associadas aos métodos de suporte a decisão já existentes, apresentem características pró-ativas para a identificação da necessidade de modernização das aplicações, visando otimizar a sua utilização pelas organizações.
Este trabalho buscará, portanto, responder à seguinte questão: Como avaliar um sistema de forma a apoiar a decisão pró-ativa sobre a sua modernização?.
1.2 Objetivos e suposições
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é desenvolver uma abordagem para a monitoração contínua de um sistema em operação, com medidas de gestão úteis à identificação precoce da sua deterioração.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho de pesquisa são:
• Identificar abordagens de avaliação de sistemas que tenham por objetivo apoiar a tomada de decisão a respeito da modernização de sistemas;
• Especificar os elementos monitoráveis, incluído suas definições e procedimentos para coleta;
• Definir procedimentos de análise destas informações;
• Definir ferramenta de apresentação da abordagem; e
• Avaliar o uso da abordagem na monitoração de sistemas de uma organização.
1.3 Metodologia
1.3.1 Classificação da Pesquisa
MORESI (2003, p. 11 - 14) apresenta quatro classificações possíveis para uma pesquisa: quanto a sua natureza, abordagem, fins e meios. Assim, quanto a sua natureza esta pesquisa é classificada como aplicada por objetivar contribuir para a qualidade da gestão de sistemas de informação.
Do ponto de vista da sua abordagem esta pesquisa é categorizada como qualitativa, pois dados subjetivos – medidas qualitativas dos sistemas avaliados - serão coletados e interpretados. Para os fins, esta é do tipo metodológica, pois visa construir um instrumento de captação da realidade – medidas de sistemas de informação em operação.
A partir desses dados, definida a abordagem, esta foi avaliada através de pesquisa de campo, com sua aplicação na monitoração de sistemas reais em operação.
1.3.2 Suposições
Este trabalho de pesquisa apresenta as seguintes suposições:
• Um conjunto de medidas de gestão pode ser definido visando monitorar a deterioração de um sistema de informação em uso na organização; e
• A monitoração contínua e a identificação precoce da deterioração dos sistemas favorecem a atuação pró-ativa dos gestores visando à evolução destes sistemas.
1.3.3 Coleta de Dados
Os instrumentos definidos a partir do referencial teórico para a monitoração de sistemas, visando identificar a sua deterioração, foram validados e aplicados em uma grande organização nacional.
1.4 Organização do trabalho
O trabalho está dividido em 6 capítulos, incluindo este de introdução. O capítulo 2 irá apresentar os conceitos relacionados com a medição de software, seus fundamentos teóricos e abordagens existentes para um programa de medição. Adicionalmente, será apresentado um modelo de qualidade de produto de software, a norma ISO/IEC 9126.
O capítulo 3 discutirá os conceitos envolvidos com a deterioração de sistemas, as definições existentes sobre sistemas legados e os fundamentos teóricos relacionados com a modernização de sistemas. Serão apresentados, também, alguns modelos de apoio à decisão sobre a modernização de sistemas identificados na literatura.
O capítulo 4 apresentará a abordagem proposta neste estudo, a partir das bases teóricas discutidas nos capítulos 2 e 3. Serão descritos o processo de construção da abordagem, suas medidas de gestão e as ferramentas utilizadas na apresentação do monitoramento da deterioração dos sistemas.
2 MEDIÇÃO
2.1 Introdução
Para Fenton (1994) o conceito genérico de medição está relacionado com “o processo pelo qual números ou símbolos são designados a atributos de entidades do mundo real, de tal forma que possam descrevê-los de acordo com regras definidas”. Stevens (1995) sugere que esta medição precisa ser útil, confiável, oportuna, simples e direta.
Especificamente, dentro da engenharia de software, a medição de sistemas
tem recebido grande destaque ao longo dos anos. Para García et al (2006), a
medição de sistemas (software measurement), ao possibilitar o destaque de áreas
problemáticas, desempenha um importante papel na engenharia de software,
permitindo o entendimento e aprimoramento de projetos de manutenção e desenvolvimento de sistemas e na avaliação e sustento da sua qualidade.
Na visão de Fenton e Neil (2000), a medição na engenharia de software é um
termo coletivo utilizado para descrever uma grande variedade de atividades relacionadas com a utilização de medidas de software, compreendendo a produção
de números que caracterizem as propriedades do código do sistema e, também, modelos que auxiliem no prognóstico dos seus requisitos e sua qualidade.
Ainda sobre os seus benefícios, Briand, Morasca e Basili (2002) destacam que as medidas de software podem ajudar a resolver alguns dos principais
Entretanto, alguns problemas afetam as iniciativas que visam estabelecer um programa de medição de software. A despeito dos estudos conduzidos sobre o
assunto, Briand, Morasca e Basili (2002) consideram que a medição de software
ainda sofre com os problemas típicos de uma jovem disciplina, com destaque para (i) a falta de definição de medidas dentro de um contexto de quais são os objetivos estabelecidos para a medição na organização, (ii) as medidas definidas não levam em consideração o ambiente ou contexto no qual serão avaliadas e (iii) um grande número de medidas nunca passaram por um processo de validação.
Mesmo estudos mais recentes, como o de Garcia et al (2006) destacam que
embora os esforços desenvolvidos em novos projetos de pesquisa e na busca por uma padronização internacional tenham evoluído na última década, a medição de
software ainda está em uma fase em que as terminologias, princípios, e métodos
ainda estão sendo definidos e consolidados, não existindo um consenso com relação aos seus conceitos e termos utilizados.
O objetivo deste capítulo é apresentar os fundamentos teóricos relacionados com a medição de software, incluindo as discussões sobre a padronização de seus
conceitos e as abordagens existentes para o estabelecimento de um programa de medidas. Será apresentado, também, um modelo de qualidade de produto de software, a norma ISO/IEC 9126.
2.2 Definições
De acordo com García et al (2006), os padrões internacionais e as
envolvidos na definição de medidas de software, como medida, escala, etc. No segundo grupo, estão as publicações que possuem como discussão central a medição de processos e produtos, seus resultados e formas de análise. Por fim, o terceiro grupo está relacionado com o estabelecimento de objetivos, escopo e metas envolvidas no processo de medição de software.
Nesta seção, os elementos que constituem o assunto principal dos dois primeiros grupos serão discutidos, enquanto que os conceitos relacionados com o terceiro grupo serão apresentados na seção 2.3 deste capítulo.
2.2.1 Atributos
A norma internacional ISO/IEC FDIS 15939 (2002) provê a definição de termos relacionados com medição, comumente utilizados na indústria de software e tem por objetivo definir as atividades e ações necessárias para identificar, definir, selecionar, aplicar e melhorar a medição de software. De acordo com esta norma, um atributo é “a propriedade ou característica de uma entidade que pode ser distinguida quantitativamente ou qualitativamente por humanos ou interpretações automatizadas” (ISO/IEC FDIS 15939, 2002).
Para Fenton e Pfleeger (1997, p.74), os atributos podem ser de dois tipos:
• Atributos Internos – são aqueles que podem ser medidos puramente em termos da entidade que representa, ou seja, pode ser medido examinando a entidade, independentemente de seu comportamento; e
O Quadro 1 tem por objetivo facilitar o entendimento da diferença entre estes dois tipos de atributos e foi elaborado com base nos exemplos descritos em Fenton e Pfleeger (1997, p.74).
Quadro 1 - Exemplos de Atributos internos e externos
Tipo de
Atributo Exemplo Explicação
Tamanho do Sistema Considerando que pode ser apurado em termos de linhas de código, sua medição independe da execução do sistema.
Interno
Complexidade Considerando que pode ser apurado em termos da quantidade de pontos de decisão do código, sua medição independe da execução do sistema.
Número de Falhas Somente pode ser apurado com a execução do programa.
Externo
Tempo de Resposta De forma semelhante, somente pode ser apurado com a execução do sistema.
Neste exemplo, o atributo “Tamanho do Sistema” foi considerado como do tipo interno de um sistema, pois, sua apuração independe do comportamento deste sistema, podendo ser medido através do tamanho do seu código fonte. Por outro lado, o “Tempo de resposta” tem a sua apuração vinculada com a execução do sistema e, portanto, é considerado um atributo externo.
2.2.2 Entidades
De acordo com a norma ISO/IEC FDIS 15939 (2002), uma entidade é o objeto alvo da caracterização dos atributos pela medição. Fenton (1994) acrescenta que na engenharia de software, existe o interesse em três classes de entidades:
• Processos – quaisquer atividades relacionadas com sistemas;
• Produtos – quaisquer artefatos, entregas ou documentos resultantes da execução dos processos; e
Com o objetivo de ilustrar a relação entre as entidades e atributos, o Quadro 1 é uma adaptação da versão elaborada por Fenton e Pfleeger (1997, p.76).
Quadro 2 - Componentes da medição de software (FENTON, PFLEEGER,1997)
Entidades Atributos
Internos Externos
Produtos
Especificação Tempo, esforço, modularidade. Compreensibilidade.
Código Complexidade do algoritmo, pontos de controle. Usabilidade, manutenibilidade, confiabilidade.
Processos Construção da especificação
Tempo, esforço, número de requisitos
de mudança. Qualidade, custo.
Fase de testes Tempo. Custo, estabilidade.
Recursos
Equipe Idade, custo. Produtividade, experiência.
Equipamentos
(Hardware) Custo, tamanho de memória. Confiabilidade.
Neste exemplo, para a entidade do tipo produto “Especificação”, o atributo “modularidade” é considerado como interno já que esta avaliação pode ser realizada mesmo sem a sua utilização. Para esta mesma entidade, o atributo externo considerado foi a “compreensibilidade”, que de forma geral, possui a sua apuração relacionada com o uso da especificação.
A “Fase de testes”, entidade do tipo processo possui como exemplo de atributo interno, o tempo decorrido nesta fase. Como atributo externo, a estabilidade do sistema testado, que somente pode ser verificado com o andamento dos testes.
2.2.3 Escala
A norma ISO/IEC FDIS 15939 (2002) define a escala como “um conjunto ordenado de valores, contínuos ou discretos, ou um conjunto de categorias nas quais os atributos são mapeados”.
A depender do relacionamento entres estes valores na escala, esta pode ser dividida em quatro tipos, de acordo com a norma ISO/IEC FDIS 15939 (2002):
• Nominal – tem por principal característica a medição por categorias, sem a indicação de uma ordem entre elas. Como exemplo, uma categorização das falhas de um sistema com base na sua localização, ou seja, falhas de código, de arquitetura ou especificação. Não existe uma relação de ordem entre estas categorias, entretanto, o conjunto de falhas pode ser classificado em uma destas categorias (Fenton e Pfleeger , 1997, p.47);
• Ordinal – é frequentemente utilizada quando se deseja dar uma ordem às informações da escala nominal. Como exemplo, pode-se categorizar a complexidade de uma determinada rotina de um sistema e ao mesmo tempo, dar uma noção de ordem entre estas categorias, como “Trivial”, “Simples”, “Moderada”, “Complexa” e “Incompreensível” (Fenton e Pfleeger , 1997, p.48);
5, como elementos caracterizadores da complexidade. Assim, 1 pode ser “trivial”, 2 igual a “Simples” e assim sucessivamente, até 5 significando “Incompreensível” (Fenton e Pfleeger , 1997, p.50); e
• Razão (proporção) – é a medição que preserva o mapeamento de ordem e tamanho de intervalo e acrescenta a idéia de proporção entre as entidades. Como exemplo, a relação entre o número de falhas e o total de linhas de código de uma rotina (Fenton e Pfleeger , 1997, p.52).
Fenton e Pfleeger (1997) acrescentam um outro tipo de escala ao conjunto discutido na ISO/IEC FDIS 15939 (2002). Trata-se da escala Absoluta, onde o atributo representa sempre o número de ocorrências de uma característica na entidade. Como exemplo, o número de falhas de um sistema durante sua fase de testes.
2.2.4 Medição objetiva e subjetiva
A norma ISO/IEC FDIS 15939 (2002) classifica o processo de medição em dois tipos, objetiva e subjetiva, a depender da natureza das operações envolvidas para quantificar um atributo. A medição objetiva é definida como uma quantificação baseada em números, enquanto que a medição subjetiva está baseada na quantificação envolvendo o julgamento humano.
Sobre o tratamento desta imprecisão, Park, Goethert e Florac (1996) recomendam o empenho na utilização contínua de modelos, ferramentas e treinamento visando melhorar a consistência com a qual as medidas são apuradas.
McGarry et al (2001, p.21) acrescentam que as medições objetivas
geralmente permitem maiores precisão e possibilidade de repetição, sendo quando possível, o método preferencial.
2.2.5 Medidas x Métricas x Indicadores
Na visão de García et al (2006) as definições envolvendo os conceitos de
métrica e medida são hoje um dos pontos de maior controvérsia entre os especialistas em medição de software.
Na norma ISO/IEC 14598 (2003), métrica é definida como “o resultado da combinação da escala com o método de medição”, enquanto que medida é “o resultado de uma medição”. Para García et al (2006) estas definições, bastante
próximas, ilustram os problemas na definição destes conceitos nos modelos e normas atuais.
Em outras definições, como a norma ISO/IEC 9126-1 (2002), o termo medida é definido como sendo o número ou categoria associado a um atributo de uma entidade através de uma medição. A ISO/IEC FDIS 15939 (2002) define medida como a variável para a qual um valor é estabelecido como resultado de uma medição.
componente, ou processo possui de um dado atributo. García et al (2006)
complementam que formalmente, uma métrica é uma função que mede a distância entre duas entidades e por esta razão, é definida de acordo com as propriedades precisas e matemáticas.
Sobre a definição de indicadores, as publicações convergem, com pouca variação, para as definições utilizadas na norma ISO/IEC 14598 (2003) e ISO/IEC FDIS 15939 (2002).
Entretanto, “apesar de em ambas as normas este termo parece representar o mesmo conceito, as definições dadas ainda assim divergem” (GARCÍA et al, 2006).
Respectivamente, estas normas definem indicadores como, “uma medida que pode ser utilizada para estimar o valor de uma outra medida” e “como uma medida que provê uma estimativa de um atributo específico originado de um modelo com respeito a necessidades de informação definidas”.
Na proposta de uma taxonomia para a medição de software, García et al,
(2006) definem indicador como uma medida derivada de outras medidas utilizando um modelo de análise como forma de avaliação. Para o padrão IEEE 610.12 (1990), o termo indicador representa uma variável que pode ser atribuída a um estado, pré-definido, baseado no resultado de um processo ou na ocorrência de uma condição específica.
2.3 Abordagens de medição
Na visão de Gopal et al (2002), com o crescimento da indústria, a utilização
da medição está cada vez mais sendo considerada como uma parte vital da engenharia de software. Para García et al (2007) a medição pode ajudar no
tratamento de problemas críticos do desenvolvimento e manutenção de software,
facilitando a tomada de decisões.
Entretanto, apesar do valor percebido das iniciativas de medição, estudos a respeito da utilização de programas de medidas de software apontam para a
dificuldade de obter o sucesso desejado com estas iniciativas. O estudo realizado por Hetzel (1990), aponta que menos de 10% da indústria classificava seu programa de medidas como de sucesso. Pesquisas conduzidas por Fenic (1990) apontam que 2/3 (dois terços) dos programas de medição não sobrevivem ao segundo ano de uso.
Para Schalken e Vliet (2008), muitas das sugestões propostas na literatura com o objetivo de aumentar o sucesso da medição de software dizem respeito à
utilização de uma abordagem orientada a objetivos na seleção das medidas. Rifkin (2001) acrescenta, na mesma linha, que é fundamental o entendimento dos objetivos estratégicos da organização antes de iniciar na prática um programa de medidas de software.
Rombach (1994), o GQ(i)M (Goal-Driven Software Measurement), proposto Park,
Goethert e Florac (1996) e o PSM (Practical Software Measurement), desenvolvido
por McGarry et al (2001).
Para Abib e Kirner (1999), o propósito principal do GQM é servir como uma ferramenta de suporte na elaboração e implementação de um programa de medição definido para avaliar aspectos de qualidade do processo e produtos de software. De
forma geral, esta abordagem possui como passos a definição dos objetivos da medição, a especificação de questões que enderecem estes objetivos e finalmente, a identificação de medidas que visem responder a estas questões.
De acordo com Park, Goethert e Florac (1996), o GQ(i)M está baseado em dez passos. São eles: (i) Identificar os objetivos de negócio, (ii) Identificar o que se quer saber ou aprender, (iii) Identificar sub-objetivos, (iv) Identificar entidades e atributos relacionados aos sub-objetivos, (v) Formalizar objetivos de medição, (vi) Identificar questões quantificáveis e os indicadores relacionados que serão usados para ajudar a alcançar os objetivos de medição, (vii) Identificar elementos de dados que serão coletados para construir os indicadores que ajudarão a responder às questões, (viii) Definir medidas a serem usadas e tornar essas medições operacionais, (ix) Identificar as ações a serem tomadas para implementar essas medições e (x) Preparar um plano para implementar as medições.
O PSM visa auxiliar os gerentes de projetos a obter informações objetivas sobre os projetos em andamento, para que estes atinjam suas metas estabelecidas de prazo, custo e qualidade. Para McGarry et al (2001), o PSM endereça o
desenvolvimento de uma estrutura de informações de medição de projetos, utilizando um “Modelo de Informações para Medição” (Measurement Information
relaciona com as necessidades de informação dos seus gestores e um “Modelo de Processo de Medição” (Measurement Process Model), composto das fases de
planejamento da medição, execução da medição, avaliação da medição e estabelecimento e manutenção do compromisso do programa de medição.
Neste estudo, a abordagem GQM é utilizada como instrumento auxiliar na definição das medidas de gestão úteis à monitoração da deterioração de sistemas (ver capítulo 4). A seguir, os conceitos da abordagem GQM serão apresentados.
2.3.1 Abordagem GQM (Goal-Question-Metric)
Na visão de Basili e Rombach (1994), para que uma organização possa medir de maneira eficiente, ela deve primeiro especificar os objetivos para si e seus projetos, associar estes objetivos a dados que possam defini-los operacionalmente, e por fim, prover um framework para auxiliar na interpretação destes dados com
relação aos objetivos definidos.
Para Abib e Kirner (1999), o principal propósito do GQM é servir como suporte na elaboração e implementação de programas de medição definidos para avaliar aspectos de qualidade de processos e produtos de software.
De acordo com estes autores, o GQM é uma estrutura hierárquica que trabalha com três níveis, a saber:
• Conceitual - neste nível ocorre a definição dos objetivos da medição;
• Operacional - definição das questões que visam definir e quantificar os objetivos especificados no nível anterior; e
A Figura 1 ilustra o fluxo de utilização do GQM, desde os objetivos definidos (nível conceitual) até as medidas selecionadas (nível quantitativo).
Objetivo 1 Objetivo 2
Questão 1.1 Questão 1.2 Questão 2.1
Medida M1 Medida M2 Medida M3 Medida M4
Nível Conceitual
Nível Operacional
Nível Quantitativo
Figura 1 - GQM - Hierarquia entre Objetivos, Questões e Medidas.
Soligen e Berghout (1999) propõem o seguinte processo para a utilização da abordagem GQM:
• Planejamento – está é a fase responsável pela mobilização da equipe que participará do GQM, seleção da área que se deseja melhorar, identificação dos projetos que farão parte da aplicação do método e treinamento da equipe nos conceitos necessários para a aplicação do GQM;
• Definição – nesta fase são definidos os objetivos do GQM, as questões a serem respondidas, identificação e refinamento das medidas;
• Coletade dados - nesta fase os dados são coletados, com base nas medidas definidas na fase anterior; e
Como ferramenta de apoio às reuniões que ocorrem na etapa de definição de objetivos, questões e medidas, utiliza-se os abstraction sheets. Para Briand,
Differding e Rombach (1997), o abstraction sheet é um instrumento de suporte à
interação entre os responsáveis pela medição, sendo utilizado como instrumento de registro e aquisição de conhecimento. A Figura 2 apresenta a estrutura do
abstraction sheet, de acordo com a proposta de Soligen e Berghout (1999):
• Foco da qualidade – onde são registradas as possíveis medidas para o objeto em estudo;
• Linha de base (baselines) – representam as expectativas em relação aos possíveis valores relacionados às medidas;
• Fatores de variação – identificação de quais fatores podem influenciar as medidas a serem coletadas; e
• Impacto nas linhas de base (baselines) – registros de como os fatores de variação influenciam as medições realizadas e os tipos de dependência que existem entre as medidas e estes fatores de variação.
Impacto nas linhas de base
Linha de base
Fatores de variação Foco da qualidade
Ponto de vista Foco da
qualidade Propósito
Objeto
Impacto nas linhas de base
Linha de base
Fatores de variação Foco da qualidade
Ponto de vista Foco da
qualidade Propósito
Objeto
2.4 Medição da manutenibilidade na ISO/IEC 9126
A norma ISO/IEC 9126 prevê a definição de características e o processo de avaliação de qualidade dos produtos de software, durante todo o seu ciclo de vida. Seus conceitos estão estruturados em quatro documentos. O primeiro destes documentos é o ISO/IEC 9126-1 (2002), que define as características consideradas na avaliação da qualidade de software e como estas características são decompostas em sub-características. O Quadro 3 apresenta a relação de características e respectivas sub-características descritas na norma ISO/IEC 9126-1 (2002).
Quadro 3 - Características e Sub-características da ISO 9126-1
Característica de
qualidade Sub-característica
FUNCIONALIDADE Conjunto de atributos que evidenciam a existência de um conjunto de funções e suas propriedades especificadas.
• Adequação
• Acurácia
• Interoperabilidade
• Conformidade
• Segurança de acesso
• Conformidade relacionada à funcionalidade
CONFIABILIDADE
Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido.
• Maturidade
• Tolerância à falhas
• Recuperabilidade
• Conformidade relacionada à confiabilidade
USABILIDADE Conjunto de atributos que evidenciam o esforço necessário para poder-se
utilizar o software, bem como o julgamento individual deste uso, por um conjunto implícito ou explícito de usuários.
• Inteligibilidade
• Apreensibilidade
• Operacionalidade
• Conformidade relacionada à usabilidade
EFICIÊNCIA Conjunto de atributos que evidenciam o relacionamento entre o nível de
desempenho do software e a quantidade de recursos usados, sob condições estabelecidas.
• Comportamento em relação ao tempo
• Comportamento em relação aos recursos
• Conformidade relacionada à eficiência
PORTABILIDADE Conjunto de atributos que evidenciam a capacidade do software em ser
Quadro 3 (cont.) - Características e Sub-características da ISO 9126-1
Característica de
qualidade Sub-característica
• Adaptabilidade
• Capacidade para ser instalado
• Conformidade
• Capacidade para substituir
• Conformidade relacionada à usabilidade
MANUTENIBILIDADE Conjunto de atributos que evidenciam o esforço necessário para fazer
modificações especificadas no software.
• Analisabilidade
• Modificabilidade
• Estabilidade
• Testabilidade
• Conformidade relacionada à manutenibilidade
Complementando a definição de manutenibilidade apresentada pela norma
ISO/IEC 9126-1 (2002), o padrão IEEE Std 610.12 (1990), acrescenta o conceito da manutenibilidade como “a facilidade com a qual um sistema, ou seus componentes, podem ser modificados para a correção de falhas, para a melhoria de desempenho ou outros atributos e para adaptar-se a um ambiente de mudanças”.
As medidas de qualidade de produto de software que quantificam as
características e sub-características definidas no documento ISO/IEC 9126-1 (2002) estão descritas nos outros três documentos da norma.
O segundo documento, que define as medidas externas para avaliação das características de qualidade de produto de software é a norma ISO/IEC 9126-2. As
medidas externas definidas nesta norma referem-se aos atributos do tipo externos, apresentados na seção 2.2.1, e estão relacionadas com o comportamento do sistema. De acordo com ISO/IEC 9126-2 (2002), as medidas externas, somente podem ser utilizadas durante a fase de testes do sistema ou durante sua fase de utilização, portanto, a medição é realizada quando da execução do software no seu
manutenibilidade definidas na norma ISO/IEC 9126-2 (2002), as questões que estas medidas visam responder e suas respectivas fórmulas de cálculo.
Quadro 4 - Medidas externas de manutenibilidade (ISO/IEC 9126-2, 2002)
Atributos Questões Fórmula
Capacidade de Análise Rastreabilidade
de Auditoria • O usuário pode identificar qual operação específica causou a falha?
• O mantenedor consegue identificar
facilmente qual operação causou a falha?
X= A / B
A= número de dados efetivamente gravados durante a operação. B= número de dados previstos para serem gravados suficientes para monitorar o status do software durante a operação.
Suporte a função
de diagnóstico • Quão capazes são as funções de diagnóstico no suporte a análise causal?
• O usuário pode identificar qual
operação específica causou a falha?
X= A / B
A= número de falhas que o mantenedor pode detectar.
B= número total de falhas.
Capacidade Análise de Falhas
• O usuário pode identificar qual
operação específica causou a falha?
• O mantenedor consegue identificar
facilmente a causa da falha?
X= 1- A / B
A= número de falhas com causas não identificadas
B= número total de falhas. Eficiência da
Análise de Falhas
• O usuário pode identificar causa da
falha?
• O mantenedor consegue identificar
facilmente a causa da falha?
• Quão fácil é a análise da causa da
falha?
X= Somatório (T) / N T = Tout – Tin
Tout = tempo de diagnóstico da causa da falha
Tin = tempo que o relatório de falha é recebido
N= número de falhas Capacidade de
Monitoração de Status
• O usuário pode identificar causa da
falha utilizando dados monitorados durante a operação do sistema?
• O mantenedor pode identificar causa da
falha utilizando dados monitorados durante a operação do sistema?
X= 1- A / B
A= número de casos que mantenedores (ou usuários) não conseguiram obter dados de monitoração
B= número de casos em que
mantenedores (ou usuários) tentaram obter dados de monitoração.
Capacidade de Mudança Eficiência do
ciclo de mudanças
• A resolução dos problemas ocorre em
um período de tempo aceitável do pondo de vista do usuário?
Tempo médio: Tav= soma(Tu) / N Tu= Trc - Tsn
Tsn= tempo no qual o usuário envia o requisito de alteração no sistema Trc= tempo no qual o usuário recebe nova release do sistema
N= número de releases Tempo de
implementação de falhas
• O mantenedor facilmente modifica o
sistema para resolver alguma falha?
Tempo médio: Tav= soma(Tm) / N Tm= Tout - Tin
Tout= tempo no qual as causas das falhas são removidas do sistema. Tin= tempo no qual as causas das falhas são descobertas.
Quadro 4 (cont.) - Medidas externas de manutenibilidade (ISO/IEC 9126-2, 2002)
Atributos Questões Fórmula
Complexidade de
modificação • O mantenedor facilmente modifica o sistema para resolver algum problema?
T= soma(A/B) / N
A= tempo de trabalho gasto na mudança B= tamanho da mudança
N= número de mudanças Modificação
parametrizada • O usuário ou o mantenedor facilmente modifica parâmetros para alterar o sistema e resolver os problemas?
X=1- A / B
A= número de casos em que o
mantenedor falha em modificar o sistema utilizando parâmetros.
B= número de casos em que o mantenedor consegue modificar o sistema utilizando parâmetros. Capacidade de
controle às mudanças do sistema
• O usuário consegue facilmente
identificar uma nova versão do sistema?
• O mantenedor facilmente modifica o
sistema para resolver algum problema?
X= A / B
A= número de registros de mudança gravados
B= número de registros de mudança planejados
Estabilidade % de sucesso
das mudanças • O usuário pode utilizar o sistema sem interrupções após uma manutenção?
• O mantenedor consegue mitigar as
falhas causadas por efeitos colaterais de manutenções?
X = { (Na / Ta) / (Nb / Tb) }
Na = número de casos em que usuários encontram falhas durante operação após uma modificação
Nb = número de casos em que usuários encontram falhas durante operação antes de uma modificação
Ta = tempo após modificação Tb = tempo antes da modificação Localização do
impacto das mudanças
• O usuário pode utilizar o sistema sem
interrupções após uma manutenção?
• O mantenedor consegue mitigar as
falhas causadas por efeitos colaterais de manutenções?
X= A / N
A= número de falhas novas após modificação
N= número de falhas resolvidas
Testabilidade Disponibilidade de função de teste
• O usuário ou mantenedor consegue,
facilmente, executar testes
operacionais sem a necessidade de preparação de recursos adicionais.
X= A / B
A= número de casos em que são
utilizadas as funções de teste disponíveis B= número de casos possíveis de utilização.
Eficiência do
re-teste • O usuário ou mantenedor consegue, facilmente, executar testes operacionais e determinar se o sistema está pronto para entrar em produção?
X= Soma(T) / N
T= tempo de teste para assegurar que a falha está resolvida.
N= número de falhas resolvidas. Restartabilidade
do Teste • Após manutenção, o usuário e o mantenedor conseguem facilmente realizar teste operacional utilizando pontos de checagem?
X= A / B
A= número de casos em que pausa e recomeçam os testes em pontos de checagem
B= número de casos identificados de pausas nos testes
Conformidade relacionada à Manutenibilidade
Conformidade • Quão conforme é a manutenibilidade do
produto a regulamentos, normas e convenções?
X = 1- A / B
A= número de itens de conformidade especificados e não implementados durante teste.
O terceiro documento é a norma ISO/IEC 9126-3, que define as medidas internas de qualidade de produto de software. Estas medidas internas referem-se a
atributos do tipo internos, apresentados na seção 2.2.1, e estão relacionadas com o sistema em si. De acordo com ISO/IEC 9126-3 (2002), as medidas internas devem ser aplicadas aos produtos de software não executáveis, durante a fase de desenvolvimento. Desta forma, estas medidas permitem identificar problemas de qualidade nos estágios iniciais da etapa de desenvolvimento dos produtos, possibilitando a execução de ações corretivas o mais cedo possível. O Quadro 5 apresenta as medidas internas de manutenibilidade definidas na norma ISO/IEC 9126-3 (2002).
Quadro 5 - Medidas internas de manutenibilidade (ISO/IEC 9126-3, 2002)
Atributos Questões Fórmula
Capacidade de Análise Registro de
atividades • Quão completa está o registro do status do sistema? X=A/B A= número de registros de dados
implementados.
B= número de registros de dados a implementar conforme especificação. Disponibilidade
da função de diagnóstico
• Quão completa está a disponibilização
da função de diagnóstico? X=A/B A= número de funções de diagnóstico
implementadas
B= número de funções de diagnóstico necessárias
Capacidade de Mudança Capacidade de
registro de mudanças
• As mudanças na especificação e nos
programas são registradas adequadamente no código com comentários?
X=A/B
A= número de mudanças registradas no código
B= número total de funções modificadas com relação ao código original
Estabilidade Impacto de
Quadro 5 (cont.) - Medidas internas de manutenibilidade (ISO/IEC 9126-3, 2002)
Atributos Questões Fórmula
Localização de impacto da modificação
• Quão grande é o impacto da
modificação no software? X=A/B A= número de variáveis afetadas pela
modificação
B= número total de variáveis Testabilidade
Completude da função de testes “built-in”
• Quão completa é a capacidade do teste
“built-in”? X=A/B A= número de funções de teste “
built-in” implementadas
B= número de funções de teste “built-in” especificadas
Autonomia da
testabilidade • Quão independentemente o pode ser testado? software X=A/B A= número de dependências de outros sistemas simuladas
B= número total de dependencias de teste de outros sistemas
Capacidade de observação do progresso do teste
• Quão completo é demonstrado o
resultado dos testes durante sua execução?
X=A/B
A= número de pontos de verificação implementados como especificado B= número de pontos de verificação especificados
Conformidade relacionada à Manutenibilidade
Conformidade • Quão conforme é a manutenibilidade do
produto a regulamentos, normas e convenções?
X=A/B
A= número de itens implementados relacionados com a conformidade da manutenibilidade
B= número total de itens de conformidade
O quarto e último documento, a norma ISO/IEC 9126-4, define as medidas de qualidade em uso do software responsáveis pela avaliação dos efeitos da utilização
2.5 Considerações finais do capítulo
Neste capítulo foram discutidos os principais fundamentos teóricos da medição de sistemas, incluindo as iniciativas que visam padronizar as terminologias utilizadas na engenharia de software. Foram definidos os conceitos que serão utilizados na abordagem proposta neste estudo, bem como, apresentada abordagem de medição baseada nos objetivos da organização, o GQM. Por fim, foram apresentados os elementos principais de uma norma de medição da qualidade de produtos de software, a norma ISO/IEC 9126.
Como definido no capítulo 1, a proposta deste estudo é monitorar a deterioração de sistemas em operação nas organizações. Assim, de acordo com os tipos de medidas (externo, interno e de qualidade de uso) descritos nos documentos da norma ISO/IEC 9126, neste estudo foram consideradas somente as medidas externas descritas na norma ISO/IEC 9126-2 (2002).
Especificamente, levando em consideração as características e sub-características descritas no Quadro 3 e o objetivo específico de monitorar a deterioração dos sistemas em operação, serão consideradas as medidas externas relacionadas com a avaliação da característica da “Manutenibilidade” dos sistemas, conforme apresentadas no Quadro 4.
3 MODERNIZAÇÃO DE SISTEMAS
3.1 Introdução
De Lucia, Fasolino e Pompella (2006) classificam as manutenções de sistemas em basicamente dois tipos: manutenção ordinária e manutenção extra-ordinária. As manutenções ordinárias “são as intervenções realizadas de maneira reativa com o objetivo de manter o sistema em operação” (DE LUCIA, FASOLINO, POMPELLA, 2006). Estão incluídas neste grupo, as intervenções corretivas, relacionadas à retificação de falhas no código, e as pequenas adaptativas, aplicadas quando mudanças no ambiente externo implicam em alterações no sistema.
O segundo grupo diz respeito às intervenções cujo tamanho, impacto e risco requerem um processo específico e uma equipe dedicada para sua execução. Podem ser resumidas em: (i) melhorias, que incluem as intervenções com o objetivo de aprimorar um ou mais indicadores de desempenho de uma aplicação, (ii) as grandes adaptativas, manutenções que possuem um impacto em quase a totalidade da aplicação e (iii) a transformação, que tem por objetivo adaptar o sistema para uma plataforma tecnologicamente diferente e impactam no gerenciamento e operação dos sistemas.
Para Koskinen et al (2004), as modernizações são as manutenções mais
críticas sobre o ponto de vista técnico, humano e econômico, pois, significam grandes mudanças nos sistemas, tipicamente devido às mudanças tecnológicas ou a grandes mudanças nos processos de negócio.
Entretanto, mesmo levando-se em conta os substanciais riscos tecnológicos e financeiros envolvidos na modernização de sistemas, Wallace, Clements e Wallnau (1996) defendem que uma iniciativa de modernização prudente e a atualização tecnológica podem incrementar a capacidade do sistema de várias formas. Segundo os autores, esta modernização pode trazer como conseqüências a melhoria no desempenho do sistema, a disponibilidade de novas funcionalidades, a melhora na sua capacidade de modificação e, ainda, possibilitar o desenvolvimento de novas integrações com outros importantes sistemas da organização.
O objetivo deste capítulo é apresentar os fundamentos teóricos sobre a modernização de sistemas, incluindo as estratégias e os métodos de apoio à decisão propostos na literatura. Estes métodos serão a base inicial para a definição do conjunto de medidas a ser considerado no objetivo da abordagem deste estudo.
Nas próximas seções, os principais conceitos relacionados com a deterioração de sistemas e as definições para sistemas legados serão apresentados e discutidos como forma de contextualizar a necessidade de modernização dos sistemas.
3.2 Deterioração de sistemas
Para Lehman et al (1997), a qualidade de um sistema ou software em
rigorosamente mantido e adaptado para as mudanças operacionais em seu ambiente. Este enunciado é conhecido como a sétima lei de Lehman, a lei do Declínio da Qualidade (Declining Quality).
De acordo com Jermakovics, Scotto e Succi (2007), o declínio da qualidade de um sistema representa somente parte das conseqüências da sua evolução: “o problema real surge quando se torna cada vez mais difícil atender a requisitos de modificações nos sistemas”.
O aumento na dificuldade em modificar um sistema é a idéia principal em que se baseiam alguns autores para definir conceitos semelhantes. Jermakovics, Scotto e Succi (2007) definem que a Deterioração de Software (software deterioration)
ocorre quando um sistema torna-se cada vez pior em sua estrutura, levando a um declínio de sua qualidade e no aumento do tempo para satisfazer a novos requisitos de negócio.
Gurp e Bosch (2002) concluem como inevitável a ocorrência da Erosão do Design (Desing Erosion) de sistemas submetidos à pressão de modificações ao
longo do tempo. Para Parnas (1994) o Envelhecimento do Sistema (Software Aging)
pode ser causado por dois motivos: pela falha em modificar um sistema visando atender a novos requisitos de negócio e como resultado de mudanças contínuas. Eick et al (2001), concluem que a Decadência do Código (Code Decay) contribui
para a manutenção torne-se mais difícil e cara.
Para Cimitile, Fasolino e Lanubile (2001), a deterioração de software expressa
manutenções passadas; e (iii) degradação da capacidade de modificação, como resultado do fato de que um código degradado não é bem entendido nem bem documentado.
Entretanto, para Kajko-Mattsson (2000) a degradação do desempenho está associada à operação contínua de um sistema e é identificada como o envelhecimento do processo de operação deste software (software process
execution ageing). A degradação do código e da documentação de um sistema em
evolução é que está relacionada com o envelhecimento do software como produto
(software product ageing).
A partir das definições acima, pode-se afirmar que para os gestores de TI de organizações que utilizam sistemas de informação como base para automação de seus processos operacionais, a deterioração destes sistemas se materializa no declínio da capacidade em manter e evoluir um sistema ao longo do seu ciclo de vida, no conseqüente aumento dos custos de sua operação e na dificuldade em satisfazer de maneira consistente às expectativas e novos requisitos das áreas de negócio.
3.3 Sistemas legados
Complementando a primeira lei de Lehman (Lehman et al., 1997), lei da
mudança contínua, a segunda lei, a do aumento da complexidade, observa que a estrutura de um sistema em evolução será comprometida a não ser que ações remediadoras sejam regularmente executadas.
sistemas legados são aplicações de missão crítica desenvolvidas em algum momento no passado, e que sofreram alterações ao longo do tempo, mas sem que ações remediadoras sistemáticas fossem realizadas.
De acordo com Brooke e Ramage (2001), estes sistemas são “percebidos pelo negócio como críticos para sua operação e ainda, difíceis de modificar sem que uma grande quantidade de recursos (tempo, pessoas, etc.) seja utilizada”. Esta é a mesma linha adotada por Seacord, Plakosh e Lewis (2003), ao defender que um
software torna-se legado quando ele começa a resistir à modificação e mudanças,
embora o conhecimento embutido neste sistema seja um importante ativo para a organização.
Outras definições apontam para os problemas técnicos que caracterizam estes sistemas, como tamanho fora dos padrões, documentação desatualizada, o uso de linguagens obsoletas e uma infra-estrutura degradada (KOSKINEN et al,
2005; BENNETT, RAMAGE, MUNRO, 1999; WARREN, RANSOM, 2002).
Além dos problemas percebidos nas definições acima, outra preocupação sobre os sistemas legados diz respeito à sua evolução ou modernização. Para De Lucia, Fasolino e Pompella (2006), o real desafio dos sistemas legados está em encontrar soluções de qualidade e financeiramente eficientes para a evolução destes sistemas, tornando-os assim aptos a atender novos requisitos de negócio.
Na visão de Comella-Dorda et al (2003), a evolução destes sistemas torna-se
Com relação à escolha da melhor estratégia de modernização a ser adotada, Saarelainnen et al (2006) acrescentam que “o importante papel dos sistemas
legados e os grandes custos causados pela sua manutenção e evolução requerem que as decisões a respeito destes sistemas sejam bem pensadas, eticamente defendíveis, entendidas e baseadas em fatos”.
Na próxima seção, as estratégias de modernização de sistemas descritas na literatura serão discutidas.
3.4 Estratégias de modernização de sistemas
De forma geral, a modernização implica em grandes mudanças nos sistemas. Para Koskinen et al (2005), estas modificações devem levar em consideração novas
tecnologias e a maturação dos processos de negócio e são frequentemente as intervenções mais difíceis sob o aspecto tecnológico e mais críticas economicamente.
Benett, Ramage e Munro (1999) definem 6 tipos de estratégias envolvendo a evolução dos sistemas legados:
• Descartar (Discard) – envolve a substituição de todo o sistema por uma nova solução;
• Empacotar (Wrap) – consiste em encapsular as interfaces dos sistemas em objetos;
• Terceirizar (Outsource) – passar para um terceiro a responsabilidade por manter o sistema;
• Manter (Carry on) – representa a continuidade da manutenção do sistema;
• Engenharia Reversa (Reverse Engineering) – envolve a descoberta de artefatos reutilizáveis dentro do sistema e sua utilização para re-implementá-lo.
Um conjunto maior de opções é discutido em Aversano et al (2004). Neste
trabalho, os autores discutem as seguintes estratégias: Engenharia Reversa, Redocumentação, Re-formatação, Reestruturação do Controle, Reestruturação dos dados, Modularização, Gerenciamento da Segurança, Migração da interface com o usuário, Migração da Linguagem, Migração da Plataforma, Migração de Arquitetura, Reengenharia, Encapsulamento, Manutenção Evolutiva e Manutenção Corretiva.
Para De Lucia, Fasolino e Pompella (2001), a lista de alternativas inclui: Evolução, Grande Manutenção Adaptativa, Engenharia Reversa, Reestruturação e Modularização e Transformação. Entretanto, para estes autores as possibilidades de modernização apresentadas no modelo indicam, a “grosso modo”, apenas diretrizes para a evolução dos sistemas. De acordo com os autores, faz-se necessário uma especificação precisa e um maior detalhamento sobre estas alternativas.
Quadro 6 - Estratégias de Evolução (WARREN e RANSOM , 2002)
Estratégias de Evolução
Manutenção Contínua (Continued Mainternance)
A implementação de mudanças em um sistema, sem modificações radicais em sua estrutura.
Renovação (Revamp) A transformação de um sistema pela modificação ou substituição de sua interface com usuário.
Reestruturação (Restructure) A transformação da estrutura interna do sistema, sem modificações na sua interface externa.
Re-arquitetura (Rearchiteture) A transformação do sistema pela sua migração para uma infra-estrutura tecnológica diferente.
Redesenho com reuso (Redesing with reuse)
A transformação do sistema pelo seu re-desenvolvimento utilizando alguns componentes do sistema legado.
Substituição (Replace) Substituição total do sistema
3.5 Métodos de modernização de sistemas
Como indicado na seção anterior, na literatura foram identificadas publicações que tem por objetivo propor métodos de suporte à decisão sobre qual estratégia de evolução deve ser utilizada para a modernização de sistemas legados. A seguir, alguns destes modelos são apresentados.
3.5.1 Método proposto por Sneed
Sneed (1995) propõe um processo, que se inicia com a avaliação do sistema legado e termina com a negociação de contratos com prestadores de serviço. Este processo tem por objetivo avaliar se o método de reengenharia é a melhor alternativa para a modernização de aplicações.
De acordo com o autor, a reengenharia de software é “a renovação de programas e outros artefatos de software, de forma que a funcionalidade permaneça basicamente a mesma, mas sua forma é alterada”.
