Como determinar o fim da vida útil de um aplicativo da web?[fechado]

Question

Esta questão pode trazer muitas opiniões à mesa, mas o que gostaria de obter é um conjunto de medidas que ajudem a mim e à minha empresa a determinar o fim da vida útil de um produto que vendemos.

Vendemos um sistema CMS, com este sistema criamos alguns subprodutos

• Sites
• Criador da proposta
• Rastreador de campanha de marketing

Estamos prontos para iniciar nosso planejamento rodoviário (para 2010 e 2011) e estamos tentando descobrir quando será o fim da vida útil de nossa aplicação.Alguns de vocês podem pensar que um aplicativo muito bem arquitetado (Não acho que nosso aplicativo esteja bem arquitetado) não precisa ter fim de vida, mas esse aplicativo que estamos usando tem pelo menos 6 a 7 anos e quase não tem documentação (vida real).Neste momento, apenas UMA pessoa sabe como alterar a funcionalidade principal (assustador).

Conselho por favor,

Geografia

---

Obrigado a todos!Eu realmente aprecio seus comentários, opiniões e pensamentos sobre este tópico.

Abordarei algumas das perguntas de postagem na lista abaixo

• Existe um desenvolvedor capaz de manter a funcionalidade principal do nosso produto.(único e apenas um)
• Existem dois desenvolvedores que são capazes de aumentar a funcionalidade até certo ponto.Ambos os desenvolvedores estão limitados pelas limitações do produto principal e ambos precisam trabalhar dentro desses limites.
• Uma nota muito importante.O produto que estamos a considerar colocar em fim de vida é, na sua maior parte, construído por um empreiteiro.O contratante é o único desenvolvedor capaz de manter a funcionalidade principal.Nós apenas desenvolvemos em cima da estrutura do contratante.

Continuarei adicionando respostas enquanto leio todas as respostas.

Answer 1

Como a aplicação é muito bem arquitetada, você pode não querer aposentá -lo e perder todo o investimento que fez até hoje.

Aqui estão minhas sugestões:

• Peça a um desenvolvedor júnior que se junte a este desenvolvedor atual.
• Despeje a maioria das atualizações futuras sobre o desenvolvedor júnior (com assistência do Sr. Developer)
• Peça ao desenvolvedor júnior para fazer a documentação de seu trabalho
• Peça ao Sr. Developer para revisar a documentação

Durante o período de tempo, você tem outra pessoa que pode apoiar esse aplicativo e ele também será documentado. Agora você não precisará matar seu próprio aplicativo muito bem arquitetado com suas próprias mãos.

.

Estender esta solução com a sugestão de Jefferey abaixo ("às vezes a reescrita é um bom investimento".))

Se você ainda deseja soltar o aplicativo atual e reescrevê-lo, ainda precisa documentar o sistema existente e criar requisitos para o novo sistema com base nele.

Usando a documentação do sistema atual e proposto, convém ver se pode modular com componentes de atualização (reescrita) do módulo (reescrito). Isso é possível se o aplicativo for muito bem arquitetado.

---

De acordo com seus comentários (Geo)

A organização da Geo possui um aplicativo CMS de terceiros de terceiros personalizados (com um e apenas um contrato) que implementa abaixo os requisitos de negócios e está pagando taxa de licenciamento pelo suporte e uso de seu código.

• Requisitos de negócios para CMS
• Sites
• Criador da proposta
• Rastreador de campanha de marketing

Aqui estão minhas sugestões

• Criar módulo por módulo Documento de caso de uso detalhado para este projeto. Seu desenvolvedor pode fazer isso ou seria ideal para ter um analista de negócios separado para o mesmo.
• Contrate um desenvolvedor Sr. para avaliar se o CMS de código aberto pode lidar com todos ou a maioria de seus requisitos (por exemplo, Joomla, Drupal, etc.).
• A coisa mais importante aqui seria a capacidade de migrar seus dados existentes para o novo sistema. Você pode precisar de ajuda do seu desenvolvedor de contratos existente para fazer isso.
• Pode ser necessário atualizar o processo de negócios ou o fluxo de trabalho para usar o novo sistema.
• Os módulos que não podem ser implementados usando o CMS de código aberto podem ser implementados usando o site personalizado.

Muito disso também depende da sua relação comercial com o desenvolvedor de contratos existente e o contrato de licença. O que você está enfrentando é um bloqueio de fornecedor no cenário. Você pode querer pesquisar mais soluções para eliminar esse bloqueio de fornecedores.

Answer 2

Esta é apenas a minha opinião, mas se este é um produto que você está vendendo, tudo se resume às perspectivas de negócios. Se o produto não vender, solte -o. Se o produto tiver um futuro, invista nele e faça do melhor software que puder refatorar, reescrever ou o que quer que você faça. Se você tem clientes fiéis ou uma marca forte, vale a pena proteger.

Às vezes, reescrever tudo em outra tecnologia é um bom investimento, se o software atual tiver um design bem -sucedido que possa ser copiado, possui uma marca forte e se puder ser feita corretamente.

Answer 3

O aplicativo chegou ao fim da vida no momento em que enviou sem qualquer tipo de documentação. Comece o desenvolvimento agora e você pode considerar substituir a pessoa que conhece o sistema original. Se eles passaram 6/7 anos sem criar nenhum tipo de documentação, eles não são alguém que você deseja na sua empresa.

Answer 4

O único tipo de documentação que prolongará a vida do seu sistema são as coisas que permanecem consistentes à medida que o sistema muda durante a vida, como suítes de teste, ferramentas de autodiagnóstico, comentários de código, contratos declarativos, como interfaces e documentação gerada automaticamente.

Outros artefatos de documentação gerenciados manualmente, como manuais, guias de desenvolvedores, documentos de arquitetura, formatos de dados tendem a ficar desatualizados na proporção da quantidade de documentação. Eu não contaria isso como fatores que aumentam a expectativa de vida de sua aplicação, a menos que você já tenha considerado o custo de mantê -los.

Se você não pode "pagar" a redundância do desenvolvedor para manter o aplicativo de maneira confiável, não há como manter a documentação atualizada. A falta de documentação é realmente uma dívida técnica que você decidiu, talvez inconscientemente, assumir. Se um ciclo de vida mais longo for um requisito, o custo disso deve ser considerado para atender a esse requisito.

Answer 5

Para encurtar uma longa história: estou em uma situação comparável.

• Desde que esse aplicativo seja algo como um CashCow, mas a empresa não pode pagar (ou pretender) desenvolver um novo aplicativo, ele não morrerá antes que os clientes decidam comprar um sistema mais fresco.

• Reescrever sem requisitos (documentados) é quase impossível.

• Pelo menos a experiência de departamentos especializados deve ser documentada de uma maneira útil para desenvolvimentos adicionais.

• Se você precisar manter esse aplicativo, introduza interfaces entre módulos, para reduzir a complexidade geral. Os módulos antigos, por mais que estejam, não se importem se você precisar plugin nova funcionalidade.

Answer 6

Mesmo que seja muito bem projetado e funcionando, o fato de não ter documentação e depende de uma pessoa para sua vida, significa que o produto entrou muito bem em um estado incansável. Isto não é um bom sinal. Eu concordo que o produto já passou "fim da vida" muito passado

Answer 7

Esse é o tipo de coisa que eu posso considerar ao decidir se um sistema pode estar indo "no fim da vida":

A funcionalidade que este sistema fornece disponível para os usuários finais em um formulário mais barato, mais confiável ou mais fácil de usar? Se não agora, então quando isso é provável? Este produto é, portanto, viável a longo prazo?

Isso está escrito em uma tecnologia que os clientes se afastariam, pois seria estranho interagir em seus produtos ou exigir que eles executassem plataformas "obsoletas"? Daria a um cliente em potencial a impressão de que sua empresa é significativamente Por trás do Times, por exemplo, o VB6 provavelmente ainda está bem, mesmo em 2010, mas exigir a compatibilidade do Win16 provavelmente não é.

Você pode contratar pessoas boas que conhecem a plataforma técnica subjacente a um custo razoável? Na tecnologia mais antiga, pode ser que muitas pessoas conheçam a plataforma, mas a vejam como um beco sem saída e pedirão um salário premium se sua carreira for definhar nos cromos enquanto trabalham nisso.

Se isso importa para você, a plataforma de desenvolvimento ainda é suportada pelo fornecedor? Você vai ser restringido em qual hardware ou sistema operacional você pode executá -lo se o fornecedor não estiver mais atualizando? Da mesma forma, existem orifícios de segurança na plataforma que podem precisar ser atualizados? Até produtos de código aberto de nicho podem sofrer com isso. Depois que um produto sai em desuso e os desenvolvedores principais passam para novos projetos, pode ser difícil fazer correções feitas pela comunidade.

Se for suportado, os fornecedores cobram um prêmio por apoiar uma plataforma mais antiga? Se não agora, então quanto tempo antes eles o fazem?

Quão difícil é integrar novas tecnologias para aproveitar as tendências atuais que oferecem funcionalidade enriquecida aos usuários finais para mantê-lo competitivo? Você se preocupa com isso? Pode não importar se você estiver executando um sistema fechado.

Quão difícil é lançar mudanças funcionais sem alterações extensas de "espingarda" que ondulam em todo o sistema? Isso volta a quão modular o sistema foi projetado para ser em primeiro lugar. Se você não é pior do que seus concorrentes em colocar os recursos no mercado, provavelmente você está bem.

Qual seria o custo de reescrever o sistema? Como isso se compara a quanto mais barato seria manter ou aumentar a receita de venda? Pode não ser economicamente viável fazer uma reescrita inteira. Se a plataforma de desenvolvimento for sólida, você poderá apenas tentar uma abordagem de refatoração. É aqui que ter uma boa suíte de teste e documentação ajuda.

Answer 8

Passei por um processo semelhante.Tínhamos um aplicativo da web que funcionava há quase 8 anos.Naquela época, muita manutenção foi feita, ampliando-a de maneiras que não havíamos imaginado.No entanto, o núcleo estava bom e ainda podia ser esticado.

O que nos empurrou foi o custo de manutenção.Encontrar pessoas com o conjunto certo de habilidades era fácil há 8 anos.Hoje ninguém quer trabalhar nesses ambientes;nem nós :)

Após análise, sabíamos que poderíamos substituí-lo dentro de 12 meses com funcionalidade idêntica E que esse tempo gasto seria recompensado rapidamente.

Portanto, usamos capturas de tela como nossos requisitos funcionais, renovamos a aparência e conseguimos até oferecer maior funcionalidade.Também analisamos os dados de uso para identificar peças que raramente ou nunca foram usadas e as aparamos, e concentramos mais atenção nas peças que foram usadas.

No final das contas, tivemos sucesso.Em parte porque todos na equipe eram bem versados ​​na nova tecnologia, então havia pouca necessidade de aprendizado.Outros fatores que contribuíram incluíram um design bem pensado.Acho que passamos 3 meses apenas no design antes de escrever qualquer coisa.

O último fator foi que nosso aplicativo é modular.Assim, conseguimos dividi-lo em tamanhos pequenos o suficiente para ter uma combinação de cronogramas de entrega curtos com um período de inatividade/análise entre cada entrega.Isso garantiu que estávamos no caminho certo em todas as etapas.