Soluzione software degli anni 2000, dovrei provare a patchare o rifare il tutto?

Sono stato inviato per discutere di un sistema che una determinata azienda sta attualmente utilizzando e cosa dovrebbe essere fatto con esso.

L'azienda produce vari espositori in cartone. Questo sistema è stato sviluppato per tenere traccia di clienti, ordini e prezzi. Sono successe molte cose da quando il sistema è stato creato e il sistema è ora, come descritto dal gestore, " bloccato " e " problematico ", che traduco come "non dinamico" e "instabile".

Alcune informazioni sul sistema

• È stato sviluppato intorno all'anno 2000
• Sistema abbastanza piccolo, 2-5 utenti, 6 moduli, ~ 8 tabelle con quantità medie di dati
• Costruito su Visual Basic, moduli creati con il trascinamento della selezione. L'interfaccia è fondamentalmente solo una finestra con un menu e alcuni moduli
• Utilizza il database MSSQL (server SQL2005) per archiviare dati e driver ODBC per eseguire query, i dati sono stati migrati da Excel prima di questo sistema e prima di Excel venivano gestiti, calcolati e scritti a mano e su carta
• Gli utenti lavorano in ambiente Microsoft XP (e versioni successive)

Il loro problema principale è che non possono più aggiustare e calcolare i prezzi, non possono più aggiungere nuovi tipi di cartone ecc. Correttamente perché non possono (o meglio, non sanno come) toccare i dati sul server.

Ho suggerito 3 possibili soluzioni

1. Tentativo di correggere il sistema corrente
2. Crea una nuova interfaccia nuova (preferibilmente ambiente simile, basato su VB.net o VB)
3. Riportalo a una soluzione Excel, considerando che è un sistema così piccolo

Potrebbero esserci più opzioni, ma queste sono quelle a cui potrei pensare.

Le mie domande sono

• Cosa dovrei raccomandare e perché?
• Quali sono o potrebbero essere i pro e i contro di queste alternative?
• Ci sono altre (forse migliori) alternative?

Qualcosa con solo 6 forme e simili dovrebbe essere facile da ricostruire su un quadro più moderno. Ho lavorato con la migrazione di progetti VB6 che avevano circa 200 moduli insieme a dozzine di classi e tabelle di database. Non sembra che tu stia guardando qualcosa di così disordinato, ma l'aspetto può essere ingannevole.

Dovrei analizzare il codice, il database e i requisiti aziendali per dire se la riscrittura o il refactoring della base di codice esistente sarebbe la cosa migliore. Dato quello che hai detto, mi spingerei verso una riscrittura. Ma potrebbero esserci difficoltà nascoste che non vedi in questo momento.

Finora ho ricevuto consigli leggermente diversi sulla maggior parte delle risposte.

Tentativo di correggere il sistema corrente

Almeno imparerei abbastanza bene l'attuale sistema per spiegare al cliente come usarlo. Vorrei prendere questo tempo per spiegare i difetti nel loro sistema attuale, evitare parole negative, dire loro cosa non può fare anche se tutti i bug noti sono stati corretti.

Crea una nuova interfaccia nuova (preferibilmente ambiente simile, basato su VB.net o VB)

Dopo aver appreso tutto ciò che puoi con la loro configurazione attuale. Fornisci loro delle opzioni, se puoi affrontare le loro preoccupazioni con il loro sistema attuale, non c'è davvero nulla di sbagliato nel loro sistema attuale. L'unica preoccupazione ovviamente è che il supporto di Visual Basic 6 potrebbe non esistere tra 5 anni.

Un'altra preoccupazione è il modo in cui comunica con il database. Microsoft sta lentamente eliminando alcuni dei modi più vecchi di comunicare con i suoi prodotti di database (Access, MSSQL), quindi il modo in cui interagirai con tali prodotti determinerà se la soluzione può essere utilizzata su Windows 9 e Windows 10 in futuro.

Questa risposta dipende interamente dal fatto che hanno l'origine dell'applicazione stessa. Se non hanno la fonte, sarà difficile rispondere alle loro preoccupazioni, correggere gli attuali bug principali o persino renderlo uno strumento che possono effettivamente utilizzare.

Non credo che ci sia qualcosa di "sbagliato" in un'applicazione Visual Basic 6, a parte il fatto che il suo supporto per le versioni future è sconosciuto. Ancora oggi con Windows 7 e sistemi operativi a 64 bit diventa sempre più difficile da supportare. Questo è uno dei motivi principali per cui una riscrittura in un linguaggio moderno con un adeguato supporto a 64 bit potrebbe essere una buona idea.

Se a quel punto non hanno la fonte, la riscrittura è davvero la loro unica soluzione.

Riscrivere l'interfaccia è un'opzione eccellente, dato che il sistema è relativamente piccolo. I vantaggi sono -

1. Stabilità migliorata (supponendo che tu lo faccia bene!)
2. Manutenibilità migliorata
3. Interfaccia moderna

Lo svantaggio principale è che probabilmente costerà ancora un po 'di più rispetto all'hacking del codice esistente.

Tenderei anche a riscrivere, ma devi essere sicuro al 100% di comprendere appieno la funzionalità corrente e qualsiasi funzionalità che è rotta, mancante o inadeguata. Gli ultimi due sono importanti quando hai menzionato l'adeguamento e il calcolo dei prezzi. Comprendi appieno le conseguenze dell'aggiunta di questa funzione?

Una volta ho lavorato su quello che doveva essere un "sito Web", ma in realtà stavo rilevando uno strumento di stile CRM basato su Access personalizzato dalla fine degli anni '90 e portandolo nel moderno mondo basato sul web. Lo sviluppatore originale era scomparso da tempo, il Database era stato modificato mille volte, la documentazione originale era quindi obsoleta e nessuno capiva davvero come funzionasse il sistema. Ma sapevano come usarlo, giusto. Probabilmente l'80% del budget per questo progetto è andato su tre cose:

• requisiti di raccolta
• comprendere il sistema attuale
• elaborare uno schema di database significativo per come intendevano utilizzare il software

Il progetto non è stato, finanziariamente, un successo!

Un'altra opzione potrebbe essere un compromesso tra la riscrittura dell'intero e l'hacking dell'app esistente.

Dai loro la nuova funzionalità in una nuova applicazione creata da zero.

Questo potrebbe essere potenzialmente più facile da fare e non costa quanto una riscrittura completa.

Una volta che questo è stato fatto e sono felici di poter aggiungere / aggiornare i dati, si apre la strada a una fase due che potrebbe sostituire la funzionalità esistente nella nuova app.

Questo potrebbe essere un approccio più appetibile.

Le riscritture hanno spesso la tendenza a rimanere senza budget ... Malamente.

Ma avere uno scheletro moderno per l'applicazione, potrebbe essere un buon investimento, specialmente se nessuno sa come funziona il vecchio sistema e se le cose si rompono non appena inizi a toccarle.

Inoltre, VB6 non è valido per il supporto. Quando avrai bisogno di trovare specialisti tra 10 anni, sarà piuttosto problematico.