Evolução e Manutenção do Software

Eliane Martins - Instituto de Computação - UNICAMP

Evolução e Manutenção do

Software

Evolução e Manutenção do

Software

Nov/2009

2Eliane Martins - Instituto de Computação - UNICAMP

TópicosTópicos

• Evolução ou manutenção

• Manutenção de Software

• Tipos de manutenção

• Dificuldades

• Manutenibilidade


ReferênciasReferências

E.Martins. “Manutenção e Ferramentas CASE”, notas de curso, 1998

I.Sommerville. “Sw Engineering”, 6ª ed, 2001, cap27

R.S.Pressman. “Sw Engineering: a Practitioner’s Approach”. McGraw-Hill, 3ª ed, 1992.

T.Pigoski. “Practical Software Maintenance”, 1997, John Wiley.

W.P.Paula Fº. “Engenharia de Software: Fundamentos, Métodos e Padrões”. Livros Técnicos e Científicos Editora, 2001.

N.F.Schneidewind. “The State of Sw Maintenance”. IEEE Trans on Sw Eng, SE-13, nº3, mar/87, pp303-310.

K.Bennett. “Sw Evolution: Past, Present and Future”. Information and Software Technology, nº38, 1996, pp673-680.


Evolução ou Manutenção?Evolução ou Manutenção?

“Grandes sistemas de software nunca são completados; eles simplesmente continuam evoluindo” [Lehman]

– Porquê ?

para preservar o valor do software


Sobre o valor do softwareSobre o valor do software

• Sw tem valor quando atende aos requisitos




• Valor do sw devido a falhas mudanças nos requisitos

tempo




é fácil de entender e de usar






complexidade

tempo





é eficiente





é eficiente


complexidade

ineficiência

tempo





é eficiente

usa tecnologia atual





é eficiente



complexidade

ineficiência

tecnologia obsoleta

tempo





é eficiente



complexidade

ineficiência

tecnologia obsoleta

tempo

alterações


Dinâmica da evolução do sw(Leis de Lehman)


Modificações contínuas • modificações são inevitáveis para

que um sw continue útil




Modificações contínuas

Complexidade crescente

• modificações são inevitáveis para

que um sw continue útil• modificações aumentam a

complexidade do sw complexidade nº falhas

tempo

taxa

de

falh

as

hw

mortalidadeinfantil desgaste









tempo

taxa

de

falh

as

ideal

sw

tempo

taxa

de

falh

as

hw










tempo

taxa

de

falh

as

hw


tempo

taxa

de

falh

as

ideal

real

sw

alteração






Evolução de programas grandes (processo auto-regulador)



complexidade do sw

• atributos tais como tamanho, tempo entre versões e nº falhas variam pouco de uma versão para outra







Estabilidade organizacional (saturação)



complexidade do sw

• atributos tais como tamanho, tempo entre versões e nº defeitos variam pouco de uma versão para outra

• taxa de desenvolvimento é constante e independe dos recursos alocados







Estabilidade organizacional (saturação)

Conservação da familiaridade



complexidade do sw

• atributos tais como tamanho, tempo entre versões e nº defeitos variam pouco de uma versão para outra

• taxa de desenvolvimento é constante e independe dos recursos alocados

• modificações a cada versão são praticamente constantes (modificações incrementais)


TópicosTópicos




• Dificuldades



ManutençãoManutenção

• Definição– é o processo de modificação de um produto após a

entrega

• Tipos– corretiva

– adaptativa

– perfectiva


Custos com manutençãoCustos com manutenção

40

55

75

90

0

10

20

30

40

50

60

70

80

90

início anos70

início anos80

final anos80

início anos90 Dados de 1990


Distribuição dos custos de manutençãoDistribuição dos custos de manutenção

emergenciais12%

rotineiras9%

melhorias usuários

43%

adaptação dos dados

17%mudanças hw,

S.Op.6%

melhorias código

4%outras

3%melhorias doc6%

Internet, maio/2002


Distribuição dos custos por categoriaDistribuição dos custos por categoria

corretiva17%

adaptativa18%

perfectiva65%

Dados de 1990


TópicosTópicos




• Dificuldades



Porquê os custos são altos?Porquê os custos são altos?

• Fatores:

– usuário

– contrato

– equipe de desenvolvimento

– sistema

– produto



• Fatores:

– usuário

– contrato


– sistema

– produto

Pouco treinamentoMudança de objetivos:

necessidades do usuário evoluem;novos usuários



• Fatores:

– usuário

– contrato


– sistema

– produto

Contrato manutenção separado do contrato de desenvolvimento, podendo inclusive ser dado a outra empresa

pouco incentivo para produção de sw fácil de manter



• Fatores:

– usuário

– contrato


– sistema

– produto

ausência dos desenvolvedoresfalta de tempofalta de motivaçãofalta de experiência



• Fatores:

– usuário

– contrato


– sistema

– produto

domínio da aplicaçãodependência do ambiente externoinstabilidade do hwalterações sem controle



• Fatores:

– usuário

– contrato


– sistema

– produto

idadequalidade da documentaçãoestilo de programaçãoacoplamento entre os móduloslinguagem de programaçãoV&V deficiente


Como reduzir custosComo reduzir custos

• Diretrizes gerenciais– como planejar a manutenção

– como motivar a equipe

• Diretrizes técnicas:– melhorar a manutenibilidade

• durante o desenvolvimento: processo visando manutenibilidade

• durante a manutenção: manutenção preventiva (reengenharia)

– definir processo de manutenção


Diretrizes gerenciais (1)Diretrizes gerenciais (1)

• Envolver a equipe de manutenção no desenvolvimento• Usar padrões tanto no desenvolvimento quanto na

manutenção• Fazer rodízio do pessoal entre desenvolvimento e

manutenção• Ter acesso à documentação ainda durante o desenvolvimento• Dispor das ferramentas CASE usadas durante

desenvolvimento• Manter contato entre usuários e equipe de manutenção• Fazer controle de configuração• Padronizar pedidos de alterações [McClure]



• Associar objetivos do software com metas da empresa

• Associar ganhos de manutenção com o desempenho da empresa

• Integrar as equipes de desenvolvimento e manutenção

• Alocar verba para manutenção preventiva (reengenharia)

• Envolver equipe de manutenção na criação de padrões de desenvolvimento, revisões, preparação de testes

• Mudar imagem negativa associada à manutenção

[Boehm]



• Escolher equipe qualificada

• Garantir boa qualidade do sistema:– bem estruturado

– fácil de entender

• Usar linguagens de programação padronizadas

• Usar sistemas operacionais padronizados

• Padronizar a documentação

• Disponibilizar casos de teste

• Tornar possível o rastreamento de requisitos[Pressman]


TópicosTópicos




• Dificuldades



ManutenibilidadeManutenibilidade

• Algumas definições– Facilidade com que um sistema ou componente de

software pode ser modificado para se corrigir falhas, melhorar desempenho (ou outros atributos), ou ser adaptado a mudanças no ambiente; (IEEE 610.12, 1990)

– Facilidade para corrigir um sw, quando possui falhas ou deficiências, e também para expandir ou contrair o sw para satisfazer a novos requisitos (Martin e McClure 1983)

– Conjunto de atributos relativos ao esforço necessário para se realizar modificações em um sw (ISO/IEC 8402 1986)


ConsideraçõesConsiderações

• Todos os sistemas são igualmente fáceis de manter ? Porque não ?– Sistemas não são desenvolvidos visando manutenibilidade

– manutenibilidade deve ser uma das metas do desenvolvimento

• Que critérios usar para determinar se um sw é fácil de manter ou não ?

• É possível estimar o grau de manutenibilidade de um sw ?


O que afeta a manutenibilidadeO que afeta a manutenibilidade

• Processo de desenvolvimento

• Documentação

• Qualidade do sw

• Disponibilidade dos testes

• Disponibilidade das ferramentas de desenvolvimento

• Controle de alterações




• Documentação

• Qualidade do sw




Manutenibilidade deve ser considerada ao longo de todo desenvolvimento.Pb.: como convencer gerentes de que manutenibilidade ganhos




• Documentação

• Qualidade do sw




documentação desatualizada, incompleta ou inexistente custo com manutenção (47% - 62% tempo para compreensão de programas e documentos) [Pigosrki 1996]




• Documentação

• Qualidade do sw




qualidade custo com manutenção Aspectos de qualidade:- estrutura do sw- estilo de programação- sistemática de V&V




• Documentação

• Qualidade do sw



• Controle de alteraçõesFacilita realização de testes, em especial os de regressão




• Documentação

• Qualidade do sw



• Controle de alteraçõesFacilita realização modificações, permitindo atualizar:- modelos de análise e projeto; documentação- código fonte (existência do compilador)- testes, entre outros


Como estimar manutenibilidadeComo estimar manutenibilidade

• Manutenibilidade pode ser medida• Diversas métricas propostas:

– padrão IEEE

– outras


MétricasMétricas

• Permitem determinar quão fácil é manter um sw

• manutenibilidade pode ser caracterizada pelos seguintes sub-fatores (IEEE 1061 1992):– corrigibilidade: medida do esforço necessário para corrigir erros

e lidar com as reclamações dos usuários

– expansibilidade: medida do esforço necessário para melhorar ou modificar as funções do sw

– testabilidade: medida do esforço necessário para testar o sw


MétricasMétricas

• corrigibilidade • tempo de fechamento

• tempo para isolar/corrigir a falha

• tamanho da interface

• taxa de falhas

• previsão de recursos

• previsão de esforço

• produtividade

Contagemde falhas

esforço

Subfator tipo de métrica métrica


MétricasMétricas

• testabilidade • cobertura do código

• cobertura dos requisitos

• grau de completeza do plano de testes



• produtividade

cobertura

esforço



MétricasMétricas

• expansibilidade • esforço para modificação

• tamanho da modificação

• taxa de modificação

• contagem de modificações



• produtividade

modificações

esforço



Outras métricasOutras métricas

• Diversos autores (academia e indústria):– Schneidewind 1987

– Lewis e Henry 1989

– Oman 1991

entre outros


Métrica baseada na estruturaMétrica baseada na estrutura

• Proposta por Lewis e Henry 1989

• Permite avaliar a manutenibilidade ao longo do ciclo de vida

• Medida varia conforme o tipo de sistema:– Procedimental

– OO


Modularidade para sistemas procedimentais

Modularidade para sistemas procedimentais

nº de procedimentosMproc =

KLOCS

[Peters e Pedrycz 2001]

Programa LOC nº funções M ProgA 1000 2 0,002 ProgB 1000 12 0,012

Exemplo:


Modularidade para sistemas OOModularidade para sistemas OO

nº de métodos da classeMclasse =

KLOCS

nº médio de métodos por classeMsist =

nº médio de KLOCS por classe



LegibilidadeLegibilidade

• Legibilidade:– de documentos:

– de código:

L = | 0,295 id - 0,499 LOC + 0,13 c

nº de palavrasFOG = 0,4 + % de palavras com ( 3+) sílabas nº de sentenças

complexidade ciclomática

comprimento médio dos identificadores



Ferramentas de Auxílio - ExemplosFerramentas de Auxílio - Exemplos

• RSM– Resource Standard Metrics (C, C++, Java)

– obtenção de métricas: LOCs, complexidade cilcomática, nº de parâmetros em função, ...

– Análise estática do código: linhas muito longas, nomes de variáveis, constantes, construções dependentes do compilador, ...

• Aristotle– análise estática do programa:

• análise de dependências de controle

• análise de fluxo de dados, entre outras

• ...


Recomendações finaisRecomendações finais

• Quais as recomendações para se obter uma boa manutenibilidade?– Revisões

– Uso de princípios da engenharia de sw (ex.: abstração de dados, ocultação da informação, ...)

– Comentários no programa contendo informações úteis

– Evitar práticas nocivas de programação

– Aplicar convenções de codificação

– Reengenharia do sw


Reengenharia do SoftwareReengenharia do Software


Reengenharia de SoftwareReengenharia de Software

Reorganização e modificação do sw com o objetivo de melhorar sua manutenibilidade

• Atividade denominada também de manutenção preventiva ou ainda, rejuvenescimento do sw.


Re-engenharia: porquê?Re-engenharia: porquê?

• Para aumentar a sobrevida de sistemas legados:– Em 1990 foi estimada a existência de 120 milhões de LOCs, a

maioria em Cobol e Fortran • a estruturação dos programas é muito baixa

• a documentação dos sistemas é pouca ou inexistente

– Apesar de muitos desses programas já terem sido substituídos, ainda restam muitos em uso ...

• Em 2005: por volta de 200 bilhões de LOC em Cobol, com uma redução da ordem de dezenas de milhares por ano

– ... e novos programas são desenvolvidos, usando processos ágeis de desenvolvimento, nos quais estruturação e documentação não são a principal preocupação


Engenharia Progressiva e ReengenhariaEngenharia Progressiva e Reengenharia

Especificação do Sistema

Projeto e Implementação

Novo sistema

Engenharia Progressiva

SistemaAntigo

Compreensão e Transformação

SistemaMelhorado

Reengenharia


AtividadesAtividades

• Engenharia reversa• Conversão de código• Reestruturação dos dados• Reestruturação do código• Remodularização do código Refatoração


Engenharia ReversaEngenharia Reversa

• Consiste em analisar o código com o objetivo de obter o projeto e especificação do sistema– para obter a especificação é necessária intervenção manual

• Cria banco de dados com informações sobre o sistema

• É mais eficaz quando feita com auxílio de ferramentas: engenharia reversa, análise estática, referências cruzadas, navegadores de programas (program browsers) ...


Engenharia reversa de código - exemploEngenharia reversa de código - exemplo

program X;var …function F1(..): tipo;…procedure P2(…);begin… = … F1(…) …;end;procedure P1(…);begin … P2(…);…end;

Descrição da função F1(…):Parâmetros de entrada:Parâmetros de saída:

Valor de retorno:O quê faz a função:

function F1( .): tipo;


Engenharia reversa de código - exemploEngenharia reversa de código - exemplo

program X;var …function F1(..): tipo;…procedure P2(…);begin… = … F1(…) …;end;procedure P1(…);begin … P2(…);…end;

X

P2

P1

F1

…

function F1( .): tipo;


Procedimento (exemplo)Procedimento (exemplo)

Código fonte

original

Transformação Código XML

Biblioteca dedados XML

Transformação XML UML

(XMI)

Baseia-se em conjunto de regras para o mapeamento de elementos da linguagem A (representados em XML) para elementos da UML

DiagramasUML


Conversão de códigoConversão de código

Código original

Identificar diferenças

entre as linguagens

Projetar um tradutor

Converter automaticamente

Ajustar manualmente

Código original Código convertido


ExemploExemplo

Processo de conversão com XML

Código fonte

original

Transformação Código XML

Biblioteca dedados XML

Transformação XML Código

Código fonte

convertido


Re-estruturação dos dadosRe-estruturação dos dados

• O que é– processo de analisar e reorganizar estruturas de dados

(eventualmente, os valores dos dados) de um programa

• Objetivo– melhorar compreensão dos dados usados pelo programa

– facilitar o controle dos dados


Problemas com dados legadosProblemas com dados legados

• Nomeação dos dados– dados têm nomes difíceis de entender

– dados podem ter nomes diferentes em ao longo das diferentes partes do sistema

• Tamanho de campos– o mesmo item pode ter tamanhos diferentes em diferentes partes do sistema

• Organização dos registros– registros que representam a mesma entidade podem ter formatos diferentes

ao longo do sistema

• Constantes embutidas

• Inexistência de um dicionário de dados

• Inconsistência dos dados


Inconsistência dos Dados (1)Inconsistência dos Dados (1)

• Valores default inconsistentes– programas diferentes atribuem valores diferentes ao mesmo item

de dados

• Unidades inconsistentes– a mesma informação é representada usando unidades diferentes

(ex.: peso em libras ou kg)

• Regras de validação inconsistentes– regras de validação diferentes podem fazer com que dados aceitos

por um programa sejam rejeitados por outros


Inconsistência dos Dados (2)Inconsistência dos Dados (2)

• Convenções de representação inconsistente– diferenças na convenção usada para representar os dados (ex.:

alguns programas podem assumir que dados iniciados com maiúsculas representam endereço)

• Uso inconsistente de valores negativos:– alguns programas podem rejeitar tais valores, outros aceitá-los

como válidos e outros ainda podem não reconhecê-los como sendo negativos e convertê-los errôneamente para positivo


Reestruturação de códigoReestruturação de código

• Com a manutenção a estrutura do código vai sendo corrompida, o que dificulta o entendimento e futuras alterações.

• O código pode ser reestruturado, automaticamente, para eliminar desvios incondicionais (goto):– Bohm e Jacopini mostraram, em 1966, que programas podem ser

escritos usando-se somente construções do tipo seqüência, seleção (if-the-else, case) e repetição (while-repeat-for)

• Condições também podem ser simplificadas, o que facilita o seu entendimento


Código espagueteCódigo espaguete

Start: get (time_on, time_off, time, setting, temp, switch)if switch = off goto Off if switch = on goto Ongoto Cntrld

Off: if heating_status = on goto Sw_offgoto Loop

On: if heating_status = off goto Sw_ongoto Loop

Cntrld: if time = time_on goto Onif time = time_off goto Offif time < time_on goto Startif time > time_off goto Startif temp > setting goto Offif temp < setting goto On

Sw_off: heating_status := offgoto Switch

Sw_on: heating_status := onSwitch: Switch_heating ( )Loop: goto Start


Código estruturadoCódigo estruturado

loop-- get: atribui valores para variáveis conforme-- o ambiente do sistemaget (time_on, time_off, time, setting, temp, switch)case switch of when On if heating_status = off then

Switch_Heating ( ); heating_status := On; end_if; when Controlled if time time_on and time time_off then

if temp > setting and heating_status = On thenSwitch_heating ( ); heating_status := Off;

elsif temp < setting and heating_status = Off thenSwitch_heating ( ); heating_status := On;

end_if; end_if; end_case;end loop;


Simplificação de condiçõesSimplificação de condições

-- Condição complexa:

if not (A > B and (C < D or not ( E > F) ) )...

-- Condição simplificada:

if (A <= B and (C>= D or E > F)...


Re-modularização de códigoRe-modularização de código

• O que é:– Processo de reorganização de um programa de forma que partes

relacionadas sejam colocadas em um mesmo módulo

• Porquê?– Componentes relacionados ficam dispersos pelo programa

• Como?– Geralmente é manual: inspeção e re-edição do código, mas já

existem ferramentas que apoiam partes do processo

– Refatoração


RefatoraçãoRefatoração

Ver slides


ExercíciosExercícios

• Para os programas dados a seguir, responda:– O que fazem os programas?

– Quanto tempo levou para entendê-los?

– Qual o grau de modularidade dos programas?

– Qual a legibilidade?

– Que sugestões voce daria para melhorar a manutenibilidade deles?


Programa 1 Programa 1

Entradas: t, i, cSaídas: ac, loccm := 1;f := Tam;ac := falso;while cm f and not ac do m := (cm + f) / 2; if c > t [m] then cm := m + 1 else if c = t [m] then ac := verdade; loc := m else f := m - 1end while;


Programa 2Programa 2Entradas: x1, x2, x3: inteiros; x4: charSaídas: w, x1if x1 > x2 then w := 100 else w := 10;while x1 > x3 do x3 := x3 * w end while;case x4 “A” - “J”: w := 10 “K” - “T”: w := 20 “U” - “Z”: w := 30end case;

if x2 > x1 and x2 < x3 and x4 = “S” then w := 10 else w := 20;if x1 < w or x2 < w then write w else write x1;

Evolução e Manutenção do Software

Documents

Transcript of Evolução e Manutenção do Software