Solução de software dos anos 2000, devo tentar corrigir ou refazer a coisa toda?

Fui enviado para discutir um sistema que uma certa empresa está usando no momento e o que deve ser feito com ele.

A empresa fabrica vários displays de papelão. Este sistema foi desenvolvido para acompanhar clientes, pedidos e preços. Muitas coisas aconteceram desde que o sistema foi criado e o sistema está agora, como o gerente descreveu, " bloqueado " e " problemático ", que eu traduzo como "não dinâmico" e "instável".

Algumas informações sobre o sistema

• Foi desenvolvido por volta do ano 2000
• Sistema razoavelmente pequeno, 2-5 usuários, 6 formulários, ~ 8 tabelas com quantidades médias de dados
• Criado no Visual Basic inicial, formulários criados com o design de arrastar e soltar. Interface é basicamente apenas uma janela com um menu e algumas formas
• Utiliza o banco de dados MSSQL (servidor SQL2005) para armazenar dados e o driver ODBC para consulta, os dados foram migrados do Excel antes deste sistema e antes do Excel foram manipulados, calculados e escritos à mão e em papel
• Os usuários trabalham no ambiente Microsoft XP (ou superior)

O principal problema deles é que eles não podem ajustar e calcular preços, não podem adicionar novos tipos de caixas, etc., corretamente, mais porque não podem (ou melhor, não sabem como) tocar nos dados no servidor.

Sugeri 3 soluções possíveis

1. Tentativa de corrigir o sistema atual
2. Crie uma nova interface nova (de preferência ambiente semelhante, baseado em VB.net ou VB)
3. Traga de volta para uma solução do Excel, considerando que é um sistema tão pequeno

Pode haver mais opções, mas essas são as que eu poderia pensar.

Minhas perguntas são

• O que devo recomendar e por quê?
• Quais são ou podem ser os prós e os contras dessas alternativas?
• Existem outras alternativas (possivelmente melhores)?

Algo com apenas 6 formulários deve ser fácil de reconstruir em uma estrutura mais moderna. Trabalhei na migração de projetos VB6 que tinham cerca de 200 formulários, além de dezenas de classes e tabelas de banco de dados. Não parece que você está vendo algo tão bagunçado, mas a aparência pode enganar.

Eu precisaria analisar o código, o banco de dados e os requisitos de negócios para dizer se seria melhor reescrever ou refatorar a base de códigos existente. Dado o que você disse, eu me inclinaria para uma reescrita. Mas, pode haver dificuldades ocultas que você não vê no momento.

Tenho conselhos um pouco diferentes na maioria das respostas até agora.

Tentativa de corrigir o sistema atual

Pelo menos eu aprenderia o sistema atual o suficiente para explicar ao cliente como usá-lo. Eu levaria esse tempo para explicar as falhas em seu sistema atual, evitar palavras negativas, apenas dizer o que elas não podem fazer, mesmo que todos os erros conhecidos tenham sido corrigidos.

Crie uma nova interface nova (de preferência ambiente semelhante, baseado em VB.net ou VB)

Depois de aprender tudo o que puder com a configuração atual. Forneça opções a eles, se você puder resolver as preocupações deles com o sistema atual, realmente não há nada de errado com o sistema atual. A única preocupação, é claro, é que o suporte ao Visual Basic 6 possa não existir em 5 anos.

Outra preocupação é a maneira como ele se comunica com o banco de dados. A Microsoft está lentamente se livrando de algumas das maneiras mais antigas de se comunicar com seus produtos de banco de dados (Access, MSSQL), para que a maneira como você interaja com esses produtos determine se a solução pode ser usada no Windows 9 e no Windows 10 no futuro.

Essa resposta depende inteiramente do fato de eles terem a fonte do próprio aplicativo. Se eles não tiverem a fonte, será difícil abordar suas preocupações, corrigir os principais erros atuais ou torná-la uma ferramenta que eles possam realmente usar.

Eu não acho que exista algo "errado" em um aplicativo Visual Basic 6, além do fato de que seu suporte para versões futuras é desconhecido. Ainda hoje, com os sistemas operacionais Windows 7 e 64 bits, está ficando cada vez mais difícil oferecer suporte. Esse é um dos principais motivos pelos quais uma reescrita em uma linguagem moderna com suporte adequado de 64 bits pode ser uma boa idéia.

Se eles não tiverem a fonte nesse ponto, uma reescrita é realmente a única solução.

Reescrever a interface é uma excelente opção, pois o sistema é relativamente pequeno. As vantagens são -

1. Estabilidade aprimorada (supondo que você faça bem!)
2. Manutenção melhorada
3. Interface moderna

A principal desvantagem é que provavelmente ainda custará um pouco mais do que invadir o código existente.

Eu também tenderia a reescrever, mas você precisa ter 100% de certeza de entender completamente a funcionalidade atual, bem como qualquer funcionalidade que esteja quebrada, ausente ou inadequada. Os dois últimos são importantes, como você mencionou, ajustando e calculando preços. Você entende completamente as consequências de adicionar esse recurso?

Certa vez, trabalhei no que era suposto ser um "site", mas na verdade estava assumindo uma ferramenta de estilo CRM baseada em Access personalizada do final dos anos 90 e trazendo-a para o mundo moderno, baseado na Web. O desenvolvedor original já havia desaparecido há muito tempo, o banco de dados havia sido modificado inúmeras vezes, a documentação original estava desatualizada e ninguém realmente entendia como o sistema funcionava. Mas eles sabiam como usá-lo, apenas. Provavelmente 80% do orçamento deste projeto foi de três coisas:

• reunindo requisitos
• compreendendo o sistema atual
• criando um esquema de banco de dados significativo sobre como eles pretendiam usar o software

O projeto, financeiramente, não foi um sucesso!

Outra opção pode ser um compromisso entre reescrever tudo e invadir o aplicativo existente.

Dê a eles a nova funcionalidade em um novo aplicativo criado do zero.

Isso pode ser mais fácil de fazer e não custa tanto quanto uma reescrita completa.

Uma vez feito isso e eles estão felizes por poderem adicionar / atualizar dados, ele abre o caminho para que uma fase dois possa substituir a funcionalidade existente no novo aplicativo.

Essa pode ser uma abordagem mais palatável.

As reescritas geralmente tendem a ficar sem orçamento ... Mal.

Mas ter um esqueleto moderno para o aplicativo pode ser um bom investimento, especialmente se ninguém souber quantos sistemas antigos funcionam e se as coisas quebram assim que você começa a tocá-los.

Além disso, o VB6 é ruim para suporte. Quando você precisar encontrar especialistas em 10 anos, isso será bastante problemático.