The Cots Software Obsolescence Th.docx

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.