Hoje, os militares adquirem, testam e distribuem os Sistemas de Sistemas (SoS) misturando

produtos COTS e não-COTS. Contado em décadas, o ciclo de desenvolvimento e o ciclo de vida

desses sistemas militares exigem manutenção e suporte que excedem o suporte típico do
fornecedor de COTS. Em muitos casos, o setor comercial considera esses produtos COTS
obsoletos antes de seu primeiro uso operacional em qualquer sistema de armas. Ao contrário
dos fornecedores de hardware, os fornecedores de software comercial geralmente atualizam
ou atualizam seus produtos anualmente, forçando os integradores a reavaliar ou reestruturar
vários aspectos do SoS para manter a interoperabilidade com as tecnologias atuais. O software
comercial usado por contratados de defesa e ambientes de engenharia para gerenciar a
integração e o desenvolvimento de código também sofre com a obsolescência comercial,
resultando em mudanças não planejadas no conjunto de ferramentas de engenharia no ciclo
de desenvolvimento, colhendo desafios adicionais em soluções previamente compiladas e
integradas. Os impactos negativos da perda de funcionalidade do sistema e do gasto
significativo de esforços de integração de engenharia de sistemas adicionais não planejados,
devido à obsolescência do produto, causam estresse em muitos projetos de desenvolvimento.
A obsolescência de software geralmente tem como alvo programas com ciclos de vida longos,
abrangendo várias plataformas, usando diversos componentes comerciais e de software e
hardware especificados pelo governo. Em última análise, o problema de obsolescência do
software COTS exige desesperadamente tanta atenção quanto os produtos de hardware COTS.

COTS software obsolescence defined

Os aplicativos de software se tornam obsoletos quando são retirados do uso e retirados do

mercado devido a avanços tecnológicos, diminuição da popularidade do produto ou outros
fatores de mercado. Os fornecedores não podem mais vender ou oferecer suporte a licenças
para versões mais antigas do aplicativo. A obsolescência também pode ocorrer no estágio
dentro do ciclo de vida do marketing, quando o produto de software é completamente
funcional, mas não mais útil, ou desejado, embora ainda esteja em boas condições de
funcionamento. As aquisições corporativas também influenciam a obsolescência à medida que
fornecedores de software comercial combinam, integram ou eliminam produtos concorrentes.
Todos esses fatores resultam em um produto de software que não tem mais a mesma
funcionalidade, carece de manutenção e atualizações e impede o licenciamento de uma versão
mais antiga do aplicativo de software necessário para suportar o sistema legado.

3. Técnico, funcional e logístico obsolescência

O avanço tecnológico acaba forçando um produto a entrar em estado de obsolescência

funcional e logística. A obsolescência funcional mantém um alto nível de relevância para
sistemas com um design longo e um conceito de vida longa - como os aplicativos de software
que suportam uma rede de sistemas a bordo de navios da Marinha. Componentes e software,
embora tecnologicamente obsoletos no mercado comercial comum, ainda não são
considerados funcionalmente obsoletos porque ainda são funcionais e úteis. Ao projetar um
grande sistema de sistemas em um período de alguns anos, as soluções de engenharia
originais projetadas para compatibilidade com forças centradas na rede e arquiteturas abertas
podem em breve indicar incompatibilidades com padrões ou sistemas em evolução dentro de
um curto período, mesmo antes da capacidade operacional inicial (COI). É evidente que o
ritmo acelerado da tecnologia impulsiona a obsolescência tecnológica e a necessidade de um
apoio prolongado aos sistemas militares atrasa a obsolescência funcional contra os desejos do
mercado. O coração do problema da obsolescência reside nos objetivos opostos das forças que
impulsionam o mercado e no longo design e nos ciclos de vida dos sistemas militares.

The inability to expand licensing agreements or procure older versions of software forces a
COTS application into a state of logistical obsolescence. If at least one license of the software is
purchased, the user is granted legal rights to use the software within the terms of the
agreement (which may last forever or for a specified time frame). Once developed and sold,
software easily replicates and installs on as many systems as stated in the licensing agreement.
Because software is intellectual property, only legal constraints or embedded licensing keys in
the software program bind its use by the number of authorized licenses. Many licensing
agreements allow repeated installations and multiple users, however with a constrained
licensing agreement on legacy software, and an inflexible vendor refusing to sell additional
licenses to use older versions of their intellectual property, the COTS software may be
considered legally “unprocurable”. Software License downgrades may help to manage the
logistical obsolescence problem, whereas combating functional and technological
obsolescence require more complex methods for proper risk management and mitigation. This
paper discusses downgrading and other specific methods later.

A incapacidade de expandir acordos de licenciamento ou adquirir versões mais antigas de

software força um aplicativo COTS a um estado de obsolescência logística. Se pelo menos uma
licença do software for adquirida, o usuário terá direitos legais para usar o software dentro dos
termos do contrato (que pode durar para sempre ou por um período de tempo especificado).
Uma vez desenvolvido e vendido, o software replica facilmente e instala em tantos sistemas
quanto o estabelecido no contrato de licenciamento. Como o software é propriedade
intelectual, apenas restrições legais ou chaves de licenciamento embutidas no programa
vinculam seu uso pelo número de licenças autorizadas. Muitos contratos de licenciamento
permitem instalações repetidas e vários usuários, mas com um contrato de licenciamento
restrito em software legado e um fornecedor inflexível que se recusa a vender licenças
adicionais para usar versões mais antigas de sua propriedade intelectual, o software COTS
pode ser considerado legalmente “improcurável”. Os downgrades de licenças de software
podem ajudar a gerenciar o problema de obsolescência logística, enquanto o combate à
obsolescência funcional e tecnológica requer métodos mais complexos para o gerenciamento
e a mitigação de riscos adequados. Este artigo discute o downgrade e outros métodos
específicos posteriormente.

Exemplo real Ao usar compiladores comerciais, sistemas operacionais, código-fonte aberto,

ferramentas de banco de dados e outros produtos, as conseqüências da obsolescência do
software afetam o ambiente de desenvolvimento de software. O suporte do fornecedor
diminui com versões mais antigas de produtos. Falhas críticas ocorrem quando o código
antigo não é compilado com a nova versão do compilador ou quando os módulos da
biblioteca de códigos mudam entre as versões dos compiladores. Novamente, todo esse
trabalho requer investigação adicional, solução de problemas, remoção e reintegração.
Exemplos comuns de requisitos de recursos adicionais e não planejados cobrados de um
programa resultante de obsolescência são frequentes, mas não documentados com
frequência. Um exemplo não é planejar e orçar adequadamente tarefas para remover o
componente obsoleto e selecionar e integrar o novo componente na arquitetura. Por
exemplo, depois de mudar um grande fornecedor comercial de servidores de computador e
acompanhar o software de gerenciamento de rede, o gerenciamento precisa financiar o
trabalho de seleção e integração de software. Se não for planejado adequadamente, isso
pode custar à equipe de integração (composta por contratados do governo e da defesa)
muitos meses de esforços de coordenação e reinserção.
Experience documented in the software journal, Crosstalk, shows that the selection process
for one major product can require 3-6 months of time using multiple engineers, programmers,
access to sophisticated suites of hardware and software environments, and will likely entail the
purchase of vendor-provided training classes [4]. “Technical Papers from NDI/COTS Support
Strategies as a Function of DoD Acquisition Reform Symposium” documented examples
(selecting the wrong COTS application framework for databases and database drivers in order
to access database information) resulting in a three month schedule slip and loss of five staff
months [5]. Additional, similar undocumented examples permeate the Defense community
and have caused significant slips in the development schedule, from one to five staff months of
additional effort for problem resolution. The unfortunate dilemma is that the organizations are
not maintaining a collection of costs associated with obsolescence events, which makes it
extremely difficult to measure the overall consequences of not developing software
obsolescence management strategies Unfortunately, the data and supporting evidence
illustrating the seriousness of the software obsolescence problem are inadvertently buried
beneath hardware obsolescence data, software defect data, or program schedule slips and
additional resource requirements. Various representatives in the software community,
although passionate about the topic, claim that few people recognize or dedicate time to
unravel the obsolescence web and collect and share software obsolescence data within the
DoD. In my thesis, I recommend metrics and a metrics collection program to support the
software obsolescence dilemma [1].
A experiência documentada na revista de software, Crosstalk, mostra que o processo de
seleção de um grande produto pode exigir de três a seis meses usando vários engenheiros,
programadores, acesso a suítes sofisticadas de ambientes de hardware e software e
provavelmente implicará a compra de um fornecedor. - aulas de treinamento [4]. “Artigos
técnicos de estratégias de suporte do NDI / COTS como uma função do Simpósio de Reforma
de Aquisição do DoD” documentou exemplos (selecionando a estrutura de aplicativo COTS
errada para bancos de dados e drivers de banco de dados para acessar informações do banco
de dados) resultando em um escorregão de três meses e perda de cinco meses de pessoal
[5]. Outros exemplos indocumentados similares permeiam a comunidade de Defesa e
causaram escorregamentos significativos no cronograma de desenvolvimento, de um a cinco
meses de trabalho adicional para resolução de problemas. O lamentável dilema é que as
organizações não mantêm uma coleção de custos associados a eventos de obsolescência, o
que torna extremamente difícil medir as conseqüências gerais de não desenvolver
estratégias de gerenciamento de obsolescência de software Infelizmente, os dados e
evidências que ilustram a gravidade da obsolescência do software Os problemas são
inadvertidamente enterrados sob dados de obsolescência de hardware, dados de defeitos de
software ou escorregões de programação de programa e requisitos de recursos adicionais.
Vários representantes da comunidade de software, embora entusiasmados com o assunto,
afirmam que poucas pessoas reconhecem ou dedicam tempo para desvendar a
obsolescência da web e coletar e compartilhar dados de obsolescência de software dentro
do DoD. Em minha tese, eu recomendo métricas e um programa de coleta de métricas para
suportar o dilema da obsolescência do software [1].

No one is managing the software obsolescence problem

No decorrer deste estudo, inúmeras entrevistas e pesquisas indicaram que a obsolescência do

software era um problema significativo, carente de atenção. No entanto, quando questionados
sobre suas estratégias e práticas para evitá-lo ou planejá-lo, a maioria das organizações relatou
com relutância a aplicação de um estilo de gerenciamento reativo. Para combater os impactos
negativos da obsolescência de software em seus projetos, os gerentes técnicos podem incluir
esforços adicionais de integração ou comunicação com fornecedores para resolver problemas
de software conforme descobertos. Minha pesquisa revelou total desconhecimento de
qualquer estratégia do DoD focada no problema de obsolescência de software ou uma agência
que coleta dados sobre produtos de software para avaliar a gravidade de tal problema. Eu
verifiquei essa descoberta com a comunidade de hardware e software. NSWC / Crane é
fretado como o ponto focal do NAVSEA para estratégias de obsolescência de hardware,
estudos, projeções futuras e serviços de mitigação. Um componente importante de seu
trabalho inclui a criação e manutenção de um grande banco de dados de componentes de
hardware e informações de fornecedores para auxiliar na projeção de obsolescência de
hardware e na aquisição de peças sobressalentes ou equivalentes quando um componente de
hardware se torna improcurável. As discussões com representantes da Crane nos últimos anos
indicam continuamente que uma função semelhante para o software proporcionaria
benefícios significativos para o desenvolvimento de roteiros tecnológicos e o combate ao
retrabalho imprevisível causado por software obsoleto [6]. A comunidade de software não tem
função semelhante? O Instituto de Engenharia de Software trabalha com o DoD e conduz um
portfólio de processos coordenados para auxiliar profissionais e engenheiros de aquisição de
defesa na seleção e integração de itens comerciais. Dois de seus projetos incluem a iniciativa
Sistemas Baseados em COTS (CBS) e sua Iniciativa de Integração de Sistemas Intensivos em
Software (ISIS). O ISIS pretende abordar a integração do sistema de software e desenvolver
processos para melhorar a interoperabilidade do sistema de sistemas. Essas iniciativas, no
entanto, não abordam especificamente como evitar ou aliviar o problema de obsolescência de
software. Patricia Oberndorf e Lisa Brownsword, ambos autores credíveis no tópico de
software COTS e membros da equipe técnica sênior da SEI, confirmaram a necessidade de uma
organização, patrocinada pelo DOD, focada no combate à obsolescência de software que é tão
formal e madura quanto a estratégias de obsolescência de hardware. [7 e 8].

6. Brief overview of options for managing software obsolescence

As estratégias de gerenciamento de obsolescência de software diferem das soluções de

hardware. As organizações não podem extrair soluções de gerenciamento e mitigação de
manufatura da caixa de ferramentas de hardware e aplicá-las com sucesso ao dilema da
obsolescência do software. Provavelmente, a abordagem mais usada para lidar com a
obsolescência de software é fazer o downgrade da licença de software. Implementar padrões
abertos de arquitetura e injetar soluções de middleware são outras opções esperançosas.
Outras abordagens incluem o uso de wrappers, gateways, APIs (Application Programming
Interfaces) e produtos de software de código aberto para o desenvolvimento de aplicativos.
Breves descrições dessas estratégias estão incluídas abaixo, mas considerando a quantidade
irrisória de coleta de dados dedicada ao rastreamento da obsolescência de software, temos
poucos dados disponíveis para quantificá-los como estratégias eficazes de mitigação. A
pesquisa e a experiência contínuas que aplicam essas estratégias especificamente para
combater nosso problema de software e o foco contínuo no problema de software ajudarão a
validar essas soluções e oferecerão soluções confirmadas para o crescente dilema de
obsolescência de software.