segunda-feira, 26 de novembro de 2012

Software tem prazo de validade?

Outro dia, tomando um chope com amigos, um gaiato me fez essa pergunta. A princípio, considerei que ele estava apenas brincando, porém, em seguida ele emendou: um software feito há mais de 30 anos ainda pode ser considerado útil? Então, percebi que realmente é uma questão interessante.





Obsolescência

Para começar a discutir se software tem ou não prazo de validade, eu pesquisei na Wikipedia o conceito de “Obsolescência”:

“Obsolescência é a condição que ocorre a um produto ou serviço que deixa de ser útil, mesmo estando em perfeito estado de funcionamento, devido ao surgimento de um produto tecnologicamente mais avançado.”

Eu concordo com a afirmação de que ela ocorre quando um produto ou serviço deixa de ser util. Porém, tenho dúvidas quanto ao motivo sugerido “devido ao surgimento de um produto tecnologicamente mais avançado”. Sem dúvida, isto pode ser verdade em outros segmentos industriais, porém, em software não é, necessariamente, o único (ou o principal) motivo para obsolescência.

Meu filho Tiago, que é analista de sistemas e está se tornando piloto comercial, me disse que a obsolescência de um avião está mais relacionada ao seu processo de manutenção do que à sua idade de fabricação. Nós vemos aí aviões com 20 ou 30 anos de fabricação ainda operantes. Volta e meia eu viajo em aviões com mais de 30 anos de estrada, sem problema algum.

A própria Wikipedia lança alguns motivos mais relevantes para a obsolescência:
  • Quando um novo produto ou tecnologia mais funcional, toma o lugar do antigo (por exemplo, do telégrafo para o telefone, do disquete de 5 1/4" para o de 3 1/2", do celular analógico para o digital etc).
  • Quando o produto se torna inútil devido a mudanças em outros produtos. Por exemplo, os relhos tornaram-se obsoletos quando as pessoas começaram a andar em automóveis, em vez de charretes.
  • Quando as peças de reposição se tornam tão dispendiosas que se torna mais interessante comprar um produto novo.
  • Quando a baixa qualidade dos materiais encurta o tempo de vida do produto.
  • Quando partes essenciais não estão mais disponíveis para viabilizar a fabricação de um item. O gerenciamento deste tipo de obsolescência é necessário se uma disponibilidade de longa duração do produto for necessária.

É claro que nem todos se aplicam diretamente a um produto de software, mas, certamente, a vida útil de um software acaba quando ele se torna obsoleto, embora isto não signifique que ele deixará de ser utilizado.

Eu tenho visto vários produtos de software, claramente obsoletos, ainda em produção, sendo executados e mantidos na base do SDS (Só Deus Sabe...). E por que? Por que alguns softwares claramente obsoletos continuam na ativa?

Para começar, o investimento de capital na compra (ou desenvolvimento) de um software é geralmente muito alto. Além do investimento em serviço (mão de obra de desenvolvimento), existe o investimento em bens, como: servidores, infraestrutura e periféricos. Além disto, existe um outro investimento que, geralmente, não é contabilizado: a adaptação da Empresa. Os funcionários foram capacitados no uso do software, os setores se acostumaram ao seu fluxo de dados e a empresa passou a depender tanto daquele software específico, que qualquer alteração em sua rotina poderá gerar risco e custos.

É por isso que vemos programadores fazendo “boca a boca” em softwares moribundos, já na UTI, ao invés de criarem seus substitutos.

Problemas da velhice

A “velhice” de um software é caracterizada por alguns sintomas, muitos dos quais são parecidos com os que a Wikipedia relacionou. Entre eles estão:

  • Dificuldade de conseguir recursos para manutenção ou evolução. Sejam recursos tecnológicos, como: versões de sistemas operacionais, versões de ambientes ou linguagens (IDE) ou recursos humanos, como: programadores que saibam trabalhar com aquele ambiente;
  • Dificuldade crescente de realizar pequenas manutenções (“Brittleness”). Qualquer manutenção no software, por menor que seja, gera manutenções “em cascata” por várias partes do código, aumentando o risco de problemas e o custo;
  • O software está limitando a flexibilidade da Empresa. Devido às suas características (e custo), o software não permite que a Empresa evolua ou se adapte a novas condições de mercado;
  • Custo de execução e manutenção muito alto, com relação a outros softwares mais modernos;

Quando um ou mais destes sintomas se tornam críticos, é necessário investir em melhorias, seja adquirindo (ou desenvolvendo) um novo software, ou mesmo fazendo um “retrofit” no software original.

Porém, há um fator que geralmente impede tentativas de melhoria: o humano! Um conhecido meu tem uma empresa de software. Ele tem dois produtos, que “aluga” para alguns clientes fiéis. Já faz mais de 30 anos que ele tem os mesmos clientes. A princípio, parece ser uma relação saudável, porém, quando sabemos que os dois produtos são feitos em linguagens e plataformas ultrapassadas, cujos fornecedores não atualizam e nem suportam mais as ferramentas, vemos que há um grande problema. Como os clientes dependem do fornecedor, há uma “reserva de mercado” que proporciona um rendimento constante. Logo, não há interesse em “modernizar” os sistemas.

E isso acontece também quando a Empresa desenvolve seus próprios softwares.

Mas existe uma métrica para avaliar quando um software está próximo de sua obsolescência? Sim: o TCO!

Custo Total de Propriedade (TCO – Total Cost of Ownership)

O conceito de TCO, segundo a Wikipedia:

“TCO (Total cost of ownership) ou custo total da posse, é uma estimativa financeira projetada para consumidores e gerentes de empresas a avaliar os custos diretos e indiretos relacionados à compra de todo o investimento importante, tal como softwares e hardwares, além do gasto inerente de tais produtos para mantê-los em funcionamento, ou seja, os gastos para que se continue proprietário daquilo que foi adquirido.”

Quando o TCO de um produto de software aumenta proporcionalmente aos valores de períodos anteriores, pode significar que ele atingiu sua obsolescência. Note que o TCO engloba vários componentes, entre eles:
  • Aquisição (ou desenvolvimento);
  • Manutenção (baseada em expectativas e contas reais);
  • Produção (quanto custa para mantê-lo em funcionamento, quanto ele participa dos custos do DataCenter);

Além do TCO, há uma métrica financeira muito importante a ser considerada: O ROI (Return Of Investment) ou Retorno do Investimento. Mais uma vez, de acordo com a Wikipedia:

Em finanças, retorno sobre investimento (em inglês, return on investment ou ROI), também chamado taxa de retorno (em inglês, rate of return ou ROR), taxa de lucro ou simplesmente retorno, é a relação entre o dinheiro ganho ou perdido através de um investimento, e o montante de dinheiro investido.
Existem três formulações possíveis de taxa de retorno, são elas:
  • retorno efetivo;
  • retorno exigido e;
  • retorno previsto.
O retorno efetivo serve como medida de avaliação do desempenho de um investimento, aferido a posteriori. O retorno previsto serve como medida ex ante do desempenho de um investimento; é a sua taxa implícita ou interna de retorno, aquela que iguala o valor do investimento do seu preço ou custo.

Quando os clientes de TI começaram a pensar em TCO e ROI, surgiu a necessidade de adotar uma disciplina ou estratégia de gestão para ativos de TI, como softwares.

CoBIT - Control Objectives for Information and related Technology


O CoBIT (Objetivos de controle para informação e tecnologias relacionadas) é uma prática que visa casar as duas métricas em TI: TCO e ROI. Outra vez, segundo a Wikipedia:

COBIT®, do inglês, Control Objectives for Information and related Technology, é um guia de boas práticas apresentado como framework, dirigido para a gestão de tecnologia de informação (TI). Mantido pelo ISACA (Information Systems Audit and Control Association), possui uma série de recursos que podem servir como um modelo de referência para gestão da TI, incluindo um sumário executivo, um framework, objetivos de controle, mapas de auditoria, ferramentas para a sua implementação e principalmente, um guia com técnicas de gerenciamento. Especialistas em gestão e institutos independentes recomendam o uso do CobiT como meio para otimizar os investimentos de TI, melhorando o retorno sobre o investimento (ROI) percebido, fornecendo métricas para avaliação dos resultados (Key Performance Indicators KPI, Key Goal Indicators KGI e Critical Success Factors CSF).

A ideia por trás do Cobit é encarar os ativos de TI da mesma forma que os ativos financeiros e não financeiros de uma Empresa. Assim como um banco avalia sua carteira de investimentos, sejam eles financeiros ou de ações, uma empresa deveria avaliar sua carteira ou “portfólio” de investimentos em TI.

É necessário acompanhar o TCO e o ROI de cada software, seja adquirido ou desenvolvido internamente, e avaliar quando suas taxas atingem determinados limiares. Por exemplo, quando o ROI estimado de um software não está acontecendo, ou quando o TCO saiu do limite projetado, algum problema sério deve ser analisado e resolvido.

Quando o ROI efetivo de um investimento é alcançado, significa que ele “já se pagou”, ou seja, as previsões se concretizaram. Neste momento, deve-se acompanhar atentamente o TCO para saber se ele ainda está válido, o que vai gerar um lucro inesperado, com a continuidade de sua vida útil.

Gestão de Portfólio de TI é exatamente isso: acompanhar o TCO e ROI de cada investimento feito, avaliando quando é o melhor momento de realizar novos investimentos para garantir a “lucratividade” dos investimentos de TI da Empresa.

Neste momento, o meu ébrio amigo (aquele, do início deste artigo) me perguntou: mas tem alguma coisa que possamos fazer para prolongar a vida útil de um software?

Softwares duradouros

Eu não gosto do verbo “prolongar”, pois ele pode indicar que estamos tentando dar “sobrevida” a um software moribundo. Eu prefiro adotar medidas proativas, durante o desenvolvimento do software, para aumentar sua vida útil.

Para isto, devemos voltar aos três sintomas de “velhice” do software e analisar medidas proativas para evitar ou postergar o problema.

Dificuldade de conseguir recursos para manutenção ou evolução

Isto é causado por escolhas inadequadas da arquitetura tecnológica do software. É claro que, algumas vezes, o próprio cliente não dá muita escolha, por estar comprometido com determinados fornecedores e plataformas. Essa “síndrome do comprometimento” é terrível! Por exemplo, o cliente bate o pé e diz que tem que ser feito em determinada plataforma, por que é a que os programadores dele conhecem, ou por que todos os outros softwares foram feitos nela.

Porém, é nosso papel como engenheiros de software sempre alertarmos nossos clientes dos riscos que estão correndo, oferecendo alternativas de mitigação para possíveis problemas decorrentes de uso de plataformas mais modernas.

Boas maneiras de evitar este problema são:
  • Se ater a padrões de mercado. Busque soluções que sigam padrões consagrados de mercado, porém que ainda estejam em utilização;
  • Pesquise a popularidade. Sites como o TIOBE (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html), dão uma indicação das linguagens de programação mais populares;
  • Evite versões antigas. É muito comum o medo de atualização. Procure sempre utilizar as versões mais modernas;
  • Busque linguagens e soluções multiplataformas, que possuam boa portabilidade;

Dificuldade crescente de realizar pequenas manutenções (“Brittleness”)

O brittleness é um termo que veio da metalurgia, referente à fragilidade de alguns materiais, que podem se quebrar sem absorver grandes quantidades de energia. Em engenharia de software, o Brittleness é decorrente do crescimento desordenado do software, seja em quantidade de linhas ou de usuários, aplicados sobre uma base mal estruturada.

Seu sintoma é a complicação (em termos de prazo, custo e risco) crescente frente a pequenas manutenções.

Por que isso acontece? Por que o software foi construído com uma estrutura muito rígida, com alto acoplamento entre seus componentes e, consequentemente, baixa coesão interna. Com o passar do tempo, as alterações vão se tornando mais e mais complexas, aumentando o TCO do software.

Muitas vezes um software bem estruturado pode sofrer de “britleness”, devido à “manutenção destrutiva”, feita sem critérios e por pessoas descomprometidas com a qualidade de software. Existe um antipattern que descreve isso: “Junkyard coding”.

Ao projetarmos um novo software, devemos sempre seguir alguns princípios básicos de projeto orientado a objetos, como:

  • “Single Responsability Principle” (princípio da responsabilidade única): Cada classe deve ter uma única responsabilidade, já que cada responsabilidade é um foco de mudanças.
  • “Interface Segregation Principle” (princípio da segregação de interfaces): Este princípio diz que a dependência de uma classe para outra deve ser baseada na menor interface possível.
  • “Dependency Inversion Principle” (princípio da inversão de dependência): Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações;

Com estas medidas, aumentamos a Manutenibilidade e Testabilidade do software. E devemos recorrer a refactorings constantes, de modo a manter o código legível e bem estruturado.

Porém, como meu amigo perguntou, existe uma maneira de prolongar a vida útil de um software, que é o “retrofit”, também conhecido como “Reengenharia de Software”. É um refactoring gigantesco, em nível macro, tentando aproveitar o máximo do que foi implementado. É uma alternativa de alto custo e risco, cujos TCO e ROI devem ser avaliados antes de tomar uma decisão.

O software está limitando a flexibilidade da Empresa

Isto pode ser decorrente de baixa flexibilidade do software. Geralmente, é também um sintoma de que a Manutenibilidade é ruim. Se aplicarmos as medidas certas, citadas anteriormente, certamente aumentaremos a flexibilidade.

Porém, o problema pode ser anterior à construção. Requisitos mal coletados e mal geridos podem criar este tipo de problema. Neste caso, mesmo o software mais bem construído será incapaz de resistir.

Uma boa medida para evitar este problema é a prototipação. Também não gosto muito deste termo, preferindo chamar de “provas de conceito de requisitos”. Construímos pequenas versões (descartáveis) e fazemos provas com os usuários. O objetivo é avaliar se os requisitos estão adequados e alinhados com a estratégia da empresa. Uma boa gestão de TI ajuda a alinhar os requisitos com os objetivos e com a estratégia competitiva da Empresa.

Custo de execução e manutenção muito alto

Eu também não gosto de afirmações “fuzzy”... O que quer dizer “alto”? Comparado com o quê? Geralmente é falta de estudo de TCO e de ROI. Porém, quando temos estas métricas e notamos que o custo está extrapolando os limites, pode ser um indicativo de que a vida útil do software está se aproximando do fim.

Também pode ter outras causas, como: falta de análise de “Acordos de Nível Operacional” e “Acordos de Nível de Serviço”. Pode ser que os clientes e o pessoal de infra não tenham sido alertados quanto a estes níveis, considerando “caro” ou “lento” o que deveria ser normal. Igualmente, o pessoal de infra de TI deveria se preparar melhor para absorver a execução dos softwares contratados pela Empresa.

As únicas medidas proativas que podem ser tomadas são:
  • Transparência. Deixar claros os riscos e custos da solução de software;
  • Realizar testes de carga, com dados misturados, considerando diferentes períodos de “pico”;
  • Projetar os custos de manutenção e execução, realizar estudos comparativos e criar um quadro evolutivo de TCO;

Conclusão

Software tem vida útil sim. Nenhum software deve ser pensado como eterno. A tecnologia da informação muda a cada minuto, logo, devemos considerar isso ao projetar um novo software.

Porém, existem medidas proativas que podem ser tomadas para evitar a obsolescência prematura do software, como essas que discutimos aqui.

E você, o que acha?

Autor: Cleuton Sampaio.