Manutenção de software artigo final

Prévia do material em texto

�PAGE �102�
S. Sandri, J. Stolfi, L.Velho
Manutenção de Software
Otávio A. T. Julian – Renato de A. Barzan
Curso de Tecnólogo em Gestão de Tecnologia da Informação – Faculdade de Tecnologia (FATEC) – Campus de Campinas
13083-045 – Campinas – SP– Brasil
otaviojulian@hotmail.com, ren.barzan@gmail.com 
�
Abstract. Software maintenance is roughly the modification of a software product after delivery to correct faults and improve performance. A common thought is that maintenance merely involves fixing defects. However, there is a study indicating that around 80% of the maintenance effort is for non-corrective actions. This study is perpetuated when users submit problem reports that can be considered, in reality, system enhancements. More recent studies put the bug-fixing proportion closer to only 21%.
Resumo. A manutenção de software é, de modo grosseiro, a modificação de um produto de software após a entrega deste, para corrigir falhas e melhorar a performance. Um pensamento comum é que a manutenção simplesmente envolve arrumar defeitos. No entanto, existe um estudo que indica que por volta de 80% do empenho para manutenção é para ações não-corretivas. Esse estudo é alimentado quando usuários submetem relatórios de problemas que podem ser consideradas, na realidade, melhorias para o sistema. Estudos mais recentes colocam a proporção de correção de bugs mais perto de apenas 21%.
1. Introdução
	Este artigo visa contemplar desde a história da manutenção de software e dos conceitos básicos da mesma, até o que acontece no processo de manutenção. Assim como qualquer disciplina, é importante ter uma base teórica do conteúdo, a fim de entender do que ela trata e poder prosseguir com a disciplina. Na primeira parte deste seminário, serão abordados os conceitos básicos da manutenção de software.	
2. História da manutenção de software
2.1 História das leis de Lehman
	A manutenção de software e a evolução de sistemas foram abordadas pela primeira vez por Meir M. Lehman (professor da escola de ciência da computação, da universidade de Middlesex, Londres) em 1969. Após um período de aproximadamente 20 anos de estudos, em 1997 sua pesquisa foi transformada nas “Leis de Lehman sobre a evolução de software”, que evidenciam o fato de a manutenção ser evolucionária, ou seja, evoluem com o tempo. As leis também mostram como decisões de manutenção são auxiliadas pelo entendimento do que acontece com o software ao longo do tempo e também que conforme um sistema evolui, sua complexidade o acompanha.
2.1.1 As oito leis
	Segue abaixo um breve resumo das oito leis criadas por Lehman:	
 Mudança contínua:
 “Um sistema de informação que é usado deve ser continuamente adaptado, caso contrário se torna progressivamente menos satisfatório”.
 Um software não adaptado continuamente torna-se, aos poucos, insatisfatório. Se o ambiente em que ele foi implementado sofre alguma alteração, o sistema deve acompanha-lo e ser melhorado.
 Complexidade crescente:
 “À medida que um programa é alterado, sua complexidade cresce a menos que um trabalho seja feito para mantê-la ou diminuí-la”.
 Deve existir um esforço para que a complexidade de um software não aumente progressivamente. Portanto, devem-se tomar medidas para reduzir ou manter a complexidade de um sistema.
 Autorregulação:
 “O processo de evolução de software é autorregulado próximo à distribuição normal com relação às medidas de produtos e atributos de processos”.
 O grupo de manutenção deve estabelecer uma dinâmica que fará com que o esforço incremental gasto em cada nova versão permaneça constante durante a vida do sistema.
 Conservação da estabilidade organizacional (taxa constante do trabalho):
 “A taxa de atividade global efetiva média em um sistema em evolução é constante sobre o tempo de vida do produto”.
 A velocidade da atividade global de um software em evolução deve manter-se invariável durante o ciclo de vida do mesmo.
 Conservação de familiaridade: 
 “Durante a vida produtiva de um programa em evolução, o índice de alterações em versões sucessivas é estatisticamente invariante”.
 A taxa de mudanças de um software em evolução tende a ser proporcional à habilidade da equipe. A taxa de evolução do produto está ligada ao grau de familiaridade dentre os profissionais que o mantém.
 Crescimento Contínuo: 
		 “O conteúdo funcional de um programa deve ser continuamente aumentado para manter a satisfação do usuário durante seu tempo de vida”.
 Todo projeto de software inicial não consegue incluir tudo o que for necessário, portanto precisará ser progressivamente aumentado. Todo software deve ter um crescimento contínuo do conteúdo funcional, a fim de manter a satisfação dos clientes.
 Qualidade decrescente:
 “Programas apresentarão qualidade decrescente a menos que sejam rigorosamente mantidos e adaptados às mudanças no ambiente operacional”.
 Softwares desenvolvidos se depreciam gradativamente se não receberam as mudanças necessárias para se adaptar ao ambiente operacional em que está incluído.
 Sistema de feedback:
 “Processos de programação de software constituem sistemas de multi-loop, multi-level e devem ser tratados como tais para serem modificados e melhorados com sucesso”.
 O sistema de evolução de software constitui um sistema complexo, constantemente alimentado por retorno de seus usuários. A vida útil de um software consiste em um ciclo bem estabelecido de retornos positivos e negativos dos usuários, ou seja, a longo prazo, a taxa de evolução de um sistema será estabelecida pela quantidade de retornos negativos versus a quantidade de retornos positivos.
2.2 O estudo de Lientz e Swanson
	No final dos anos 70, Lientz e Swanson conduziram um grande estudo de levantamento de 487 organizações de TI. Entre as maiores descobertas incluíam que as equipes de desenvolvimento de sistemas gastavam por volta de metade de seu tempo em manutenção. Quanto maior a empresa, mais tempo era gasto em manutenção. 
	Swanson inicialmente definiu três categorias de manutenção: corretiva, adaptativa e perfectiva. No entanto, essas categorias foram atualizadas e a ISO/IEC 14764 apresenta as quatro categorias de manutenção:
 Corretiva;
 Adaptativa;
 Perfectiva;
 Preventiva.
	O “maintenance effort” foi dividido da seguinte maneira, de acordo com as novas 4 categorias:
 Manutenção corretiva: 21,7%
 Consertos de emergência: 12,4%
 Depuração de rotina: 9,3%
 Manutenção adaptativa: 23,6%
 Acomodar mudanças à entrada de dados e arquivos: 17,4%
 Acomodar mudanças ao hardware e software: 6,2%
 Manutenção perfectiva: 51,3%
 Melhorias ao cliente: 41,8%
 Aperfeiçoamento das documentações: 5,5%
 Otimização: 4%
 Manutenção preventiva: 3,4%
	O estudo mostra que cerca de 75% das manutenções são dos tipos adaptativa e perfectiva e que a manutenção de problemas de fato cobre apenas os 25% restantes.
3. A Importância da Manutenção de Software 
	Os principais problemas de manutenção de software são ambos gerenciais e técnicas. Os maiores problemas da parte gerencial são: alinhamento com as prioridades do cliente; levantamento de funcionários; quais organizações efetuam a manutenção; e a estimativa de custos. Os maiores problemas da parte técnica são: conhecimento limitado; e a análise de impacto;
	A manutenção de software é uma atividade muito abrangente que inclui correção	 de erros, melhoramento das capacidades, a eliminação de capacidades obsoletas e otimização. Como mudanças são inevitáveis, os mecanismos têm de ser desenvolvidos para ser avaliado, controlando e fazendo modificações.
	Portanto, qualquer tipo de trabalho feito após o término do desenvolvimento de um software é considerado manutenção. O propósito dela é manter o valor do sistema ao longo do tempo. O valor pode ser melhorado através do aumento da quantidade de clientes, alcançandorequisitos adicionais, tornando-o mais fácil de usar (user friendly) , mais eficiente e implementando novas tecnologias. A manutenção pode durar 20 anos ou até mais, enquanto que o desenvolvimento normalmente dura 1 ou 2 anos.
4. Planejamento da manutenção de software
	Uma das partes mais importantes de um sistema é a da manutenção, portanto é imprescindível a preparação de um plano de manutenção durante o desenvolvimento do software. O plano deve especificar como os usuários vão requisitar modificações ou reportar problemas, incluindo também uma estimativa dos custos e recursos que serão utilizados para a manutenção. Uma nova decisão deve ser endereçada ao desenvolvimento de cada novo aspecto do software e de seus objetivos de qualidade. 
	A manutenção de software, que pode durar décadas, pede um plano de ação efetivo que pode traçar o escopo do tipo de manutenção, o que deverá ser feito após o envio do sistema, a designação de quem vai providenciar a manutenção e uma estimativa do custo para manter o programa vivo.
	A aplicação de normas adequadas é a parte difícil desde o início da engenharia de software, pois não tem importâncias definidas pelo cliente interessado em questão.
5. Processos de manutenção de software
	Pode-se dividir o processo de manutenção em seis etapas:
 O processo de implementação contém preparação do software e atividades de transição, como a concepção e criação de um plano de manutenção; a preparação para lidar com problemas identificados durante o desenvolvimento; e o acompanhamento do gerenciamento da configuração do produto;
 O processo de análise do “problema e modificação”, que é executada no momento que a aplicação vira responsabilidade do grupo de manutenção. O programador de manutenção deve analisar cada requisito do cliente, confirma-lo (reproduzindo a situação) e checar a validade dele, investigá-lo e propor uma solução (se necessária), documentar o pedido e a proposta de solução e por fim obter as autorizações necessárias para aplicar as modificações;
 O processo da implementação da modificação em questão;
 O processo de aceitação da modificação, através da confirmação de que aquilo que foi alterado atende os requisitos, de modo a confirmar que a modificação providenciou uma solução;
 Se o software precisar ser migrado para outra plataforma, o processo de migração é aplicado, designando a tarefa a um time de manutenção. Esse processo não é um processo que acontece diariamente;
 Por fim, aposentar um software é o último processo da manutenção, mas obviamente também não acontece diariamente.
	Existem também alguns processos, atividades e práticas que são exclusivas dos mantenedores (pessoas que preservam o software), como por exemplo:
 Processo de Transição: uma sequência de atividades controlada e coordenada em que um sistema é transferido progressivamente do desenvolvedor ao mantenedor;
 Service Legal Agreements (SLAs) ou Acordos de Serviço Legal: contratos de manutenção legal negociados pelos mantenedores;
 Pedidos de modificação e help desk de relatórios de problemas: um processo para lidar com problemas, utilizado pelos mantenedores para priorizar, documentar e encaminhar os pedidos que recebem.	
6. Considerações finais
	Com base na pesquisa realizada por Lientz e Swanson, pode-se inferir que a manutenção de software, nos dias atuais, é voltada mais ao aperfeiçoamento de um software do que à manutenção do mesmo, uma vez que os “reparos” requisitados pelo usuário na maioria das vezes se tratam da adição de um novo componente ao sistema, ou do aperfeiçoamento de um componente já existente.
	Pode-se inferir também que as leis de Lehman, apesar de serem relativamente antigas, continuam muito atuais. Um plano de manutenção desenvolvido com base nas oito leis criadas por ele e sua equipe, constitui em um sistema bem elaborado e eficaz. 
	Dito isso, a manutenção de software em sua essência passa a ser uma das fases mais duradouras e importantes do processo de criação de um software, pois seu planejamento começa antes da distribuição do produto e continua ativa anos após o seu envio ao cliente.
Referências 
"ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance". Iso.org. 2011-12-17.
Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE;
"E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, 1976".
Jones C., The Economics of software maintenance in the twenty first century. compaid.com. <acessado em 20-03-2016>
PRESSMAN, R. S., 1995. Engenharia de Software. Makron Books. São Paulo. Brasil.
SOMMERVILLE, I. Engenharia de Software. 8th ed., Addison-Wesley, 2007. CHRISTIAN, R. Caracterização de um Modelo de Processo para Projetos de Software, 2001.
Proceedings of the XII SIBGRAPI (October 1999) 101-104
Proceedings of the XII SIBGRAPI (October 1999)