Introdução à Engenharia de
Software – Aula 11
Roteiro
●Mutabilidade de Software
●Importância da Evolução
●A Dinâmica da Evolução
●Manutenção de Software
●Manutenibilidade
●Desenvolvimento x Manutenção
●Predição do Grau de Manutenção
●Processo de Evolução
●
Reengenharia
Reengenharia x Engenharia Custos da Reengenharia
Mutabilidade de Software
●
Depois de implantado software tende a mudar
Uma das características essenciais de software é a mutabilidade, segundo Brooks [Brooks 1995]
●
As razões para estas mudanças envolvem...
Novos requisitos
Mudanças em requisitos existentes Correção de erros
Adaptação a novas plataformas
Importância da Evolução
●
Organizações investem muito no desenvolvimento de
um software
●
Muitos destes sistemas são críticos para o negócio da
organização
●
Estes sistemas precisam ser mantidos e evoluídos
●Exemplos
Sistema de controle de vôos Sistema de controle bancário
A Dinâmica da Evolução
●
Existem algumas leis que regem a evolução de
software...
● Conhecidas como leis de Lehman
●
Mudança contínua
Um programa que é usado em um ambiente real necessariamente mudará ou se tornará progressivamente menos útil em tal ambiente
●
Constante aumento de complexidade
Conforme um software evolui, sua estrutura tende a ficar mais complexa → “degradação”
A Dinâmica da Evolução
●
Evolução de software de grande porte
A evolução é um processo que se auto-regula. Atributos como tamanho, tempo entre releases, e o número de erros reportados tende a ser invariante entre cada release
●
Estabilidade organizacional
Durante o ciclo de vida de um software, seu grau de desenvolvimento é aproximadamente constante e independente dos recursos devotados para seu desenvolvimento
A Dinâmica da Evolução
●
Conservação da familiaridade
Durante o ciclo de vida de um software, a mudança incremental em cada release é aproximadamente constante
●
Crescimento contínuo
Deve-se aumentar continuamente a funcionalidade oferecida por sistemas para manter a satisfação do usuário
●
Declínio da qualidade
A qualidade dos sistemas parecerá diminuir a menos que sejam adaptados a mudanças em seus ambientes operacionais
Manutenção de Software
●
Qual
a
diferença
entre
manutenção e evolução?
●
Tipos de manutenção de software
Corretiva
● Emergencial
Preventiva Adaptativa
Manutenibilidade
Manutenibilidade
●
O que significa mesmo?
“Capacidade do produto de software de ser modificado. Modificações podem incluir correções, melhorias ou adaptações do software a mudanças no ambiente, e nos requisitos e em especificações funcionais” [ISO/IEC 9126-1]
●
Qual a importância de fazer design pensando na
manutenção?
Manutenção Desenvolvimento
Sistema 1
Desenvolvimento x Manutenção
●
Estabilidade da equipe e responsabilidade contratual
Nem sempre a equipe que desenvolveu é a que manterá Nem sempre a organização que desenvolveu é a que manterá
Falta de incentivo para desenvolver software manutenível “Economia” no desenvolvimento
●
Habilidades da equipe
Inexperiência com o domínio de aplicação
Manutenção é vista como menos desafiadora
Sistemas antigos foram desenvolvidos em linguagens que muitas vezes já são obsoletas
Problemas de se ver desenvolvimento como atividade separada da manutenção!
Desenvolvimento x Manutenção
●
Exemplos de princípios POG associados a manutenção
Deixe o amanhã para amanhã - Muitos programadores
atrasam projetos alegando que a demora de uma implementação para seguirem regras de design patterns ou comentários que ajudarão a outros entender melhor o código. Deixe o amanhã para o otário programador seguinte.
Comentários são para amadores - Um desenvolvedor
deve ser treinado para ser fluente na linguagem de programação usada sem precisar de comentários, independente da conseqüente ruína de sua vida social. Isso também é conhecido como sétimo sentido.
Desenvolvimento x Manutenção
●
Mais exemplos de princípios POG associados a
manutenção
Eficiência primeiro - Evite escrever em várias linhas o
que pode ser feito em uma.
1337 h4x0r5 dud3 lol - Quanto mais ilegível, mais
respeitado o código é. Conseqüentemente menos alterado ele é, e mais estável o sistema fica, garantindo a empregabilidade do gambiarrizador.
Desenvolvimento x Manutenção
●
Idade e estrutura do software
A mudança tende a degradar a estrutura do software
Otimização geralmente visa outras características no lugar da manutenibilidade
Documentação pode não existir ou ser desatualizada
Desenvolvimento de sistemas antigos pode não ter feito uso de boas práticas
● Exemplo: Gerência de Configuração
Existem técnicas para lidar com esta “degradação”...
Predição do Grau de Manutenção
Quais partes do sistema possivelmente serão
mais afetadas por pedidos de mudança?
Quantos pedidos de mudança podem
ser esperados?
Quais partes do sistema serão mais caras de se
manter?
Quais serão os custos de manutenção deste
sistema?
Quais são os custos de manutenção deste sistema
no ano seguinte? Prever mudanças no sistema Prever custos de manutenção Prever custos manutenibilidade
Predição do Grau de Manutenção
●
Prever o grau de mudanças que serão solicitadas
envolve entender o relacionamento do software com seu
ambiente
Número e complexidade de interfaces do sistema Número de requisitos inerentemente voláteis
Processos de negócio para os quais o sistema é usado
●
Métricas de manutenibilidade
Número de requisições de manutenção corretiva Tempo médio requerido para análise de impacto
Tempo médio requerido para implementar um pedido de mudança
Processo de Evolução
Pedido de
Mudança Análise deImpacto Planejamentode Releases Implementaçãoda Mudança Release doSistema
Reparo de
Erro Adaptação dePlataforma Reparo de
Processo de Evolução
●
Pedidos de mudança podem ter que ser atendidos
urgentemente em alguns casos
Se uma falha grave de sistema ocorrer
● A fim de permitir a operação normal ser retomada
Se mudanças no ambiente operacional tiverem impacto inesperado na operação normal do sistema
Processo de Evolução
●
Estas mudanças emergenciais podem inibir a análise
inicial de impacto
A mudança deve ser implementada rapidamente!
●
Riscos associados a este comportamento
Desatualização da documentação Uso de gambiarras
Reengenharia
●
A reengenharia de software envolve tornar sistemas
legados mais manuteníveis
O objetivo é tornar estes sistemas mais fáceis de serem modificados
●
Pode envolver...
Re-documentar o sistema
Organizar e reestruturar o sistema
Traduzir o sistema para uma linguagem mais moderna Modificar e atualizar as estruturas e valores de dados
●
Um ponto importante é que a funcionalidade não é
Reengenharia
●
Possíveis atividades de reengenharia são:
Tradução do código-fonte Engenharia reversa
Melhoria da estrutura do software Modularização do software
Reengenharia x Engenharia
Especificação do Sistema Design e Implementação Novo Sistema Sistema Reengenheirado Compreensão e Transformação Sistema Existente Engenharia Direta Reengenharia de Software ●Vantagens da reengenharia
Menores riscos Menores custosCustos da Reengenharia
●
Os principais fatores que afetam o custo de fazer
reengenharia são:
A qualidade do software original
A disponibilidade de ferramentas para apoiar A extensão da conversão de dados necessária
A disponibilidade de especialistas que conheçam o sistema
Evolução de Sistemas Legados
●
Sistema legado → sistema antigo, mas que ainda
fornece serviços essenciais para uma organização
●
Estratégias para evolução de sistemas legados
Descartar o sistema completamente
Deixar o sistema inalterado e continuar com a manutenção regular
Fazer reengenharia do sistema para melhorar sua manutenibilidade
Substituir todo ou partes do sistema com um novo sistema
●
Equilíbrio entre o valor do sistema para o negócio e sua
Evolução de Sistemas Legados
●
Estudo de caso: Sistema de Gerenciamento de
Tripulação da Comair (empresa aérea americana)
Desenvolvido por uma empresa chamada SBS
●
Quando Eric Bardes entrou para a área de TI da
empresa em 1997, a primeira reunião que participou era
para discutir a substituição do sistema
O sistema já estava na empresa há 11 anos
Era escrito em Fortran (que ninguém na empresa dominava mais)
Era o único sistema que ainda rodava na plataforma IBM AIX
Evolução de Sistemas Legados
●
A SBS tentou vender um outro software que haviam
desenvolvido
Um dos supervisores não gostava deste software
Resolveram esperar por um substituto melhor, afinal...
● Todos usuários já estavam adaptados ao uso do sistema
existente
● Muitos dos processos de negócio da empresa haviam
sido gerados a partir do sistema existente
●
Esperaram...
No meio do caminho aconteceram várias ocorrências que desviaram a atenção da substituição do sistema
Evolução de Sistemas Legados
●
Mas a substituição não ocorreu a tempo de evitar
perdas
O sistema legado falhou na época dos feriados de Natal Parou toda a companhia aérea
Houve cancelamentos e atrasos de cerca de 3900 vôos Afetou mais de 200.000 passageiros
Prejuízos de cerca de $20 milhões + danos à imagem da empresa + investigação do Departamento de Transportes
Evolução de Sistemas Legados
●
“Chances are, the whole mess could have been
avoided if Comair or Delta had done a comprehensive
analysis of the risk that this critical system posed to the
airline’s daily operations and had taken steps to
mitigate that risk”
●
“But a look inside Comair reveals that senior executives
there did not consider a replacement system an
urgent priority, and IT did little to disrupt that sense
of complacency”
Evolução de Sistemas Legados
Alto valor para o negócio
Baixa qualidade Alto valor para o negócio Alta qualidade
Baixo valor para o negócio Alta qualidade
Baixo valor para o negócio Baixa qualidade Qualidade do sistema V alo r de Ne góc io
Evolução de Sistemas Legados
Alto valor para o negócio
Baixa qualidade Alto valor para o negócio Alta qualidade
Baixo valor para o negócio Alta qualidade
Baixo valor para o negócio Baixa qualidade Qualidade do sistema V alo r de Ne góc io Manter o sistema em operação! Manter o sistema em operação? Você que sabe! Descartar!
Fazer
reengenharia ou substituir!
Evolução de Sistemas Legados
●
Questões a considerar para determinar o valor de
negócio de um sistema:
Uso do sistema
Processos de negócio apoiados Confiabilidade do sistema
Os resultados/saídas do sistema
●
Questões a considerar para determinar a qualidade de
sistema envolvem:
O ambiente em que o sistema opera As características do sistema
Evolução de Sistemas Legados
●
Fatores do ambiente que afetam a avaliação de
qualidade
Estabilidade do fornecedor (mantenedor do software) Taxa de falhas do hardware e do software de apoio Idade do hardware e do software de apoio
Desempenho do sistema
Requisitos e custo de suporte
Custos de manutenção de hardware e de software de apoio
Interoperabilidade
● Exs.: compiladores que não funcionam com as versões
atuais do Sistema Operacional; necessidade de emular hardware
Evolução de Sistemas Legados
●
Características do sistema que afetam a avaliação de
qualidade
Compreensibilidade do sistema
Documentação completa, consistente e atualizada Existência de um modelo de dados do sistema
Consistência dos dados e pouca ou nenhuma duplicação Desempenho do sistema adequado
Linguagem de programação
Gerência de configuração dos itens que compõem o sistema
Dados de teste disponíveis
Evolução de Sistemas Legados
●
Exemplos de indicadores da qualidade de um sistema
Número de requisições de mudança no sistema Número de interfaces com o usuário
Referências
Sommerville, I. (2007) Software Engineering. Oitava Edição. Addison-Wesley
Brooks Jr, F. P. (1995) The Mythical Man-Month: Essays on Software Engineering. Edição de Aniversário. Addison-Wesley
http://desciclo.pedia.ws/wiki/POG
http://www.cio.com/article/112103/Comair_s_Christmas_Disaster_ Bound_To_Fail?page=1
