Solución de software de los años 2000, ¿debería intentar parchear o rehacer todo?

Me enviaron a discutir un sistema que cierta compañía está usando actualmente y qué se debe hacer con él.

La compañía fabrica varias pantallas de cartón. Este sistema fue desarrollado para realizar un seguimiento de los clientes, pedidos y precios. Han sucedido muchas cosas desde que se creó el sistema y el sistema ahora está, como lo describió el gerente, " bloqueado " y " problemático ", lo que traduzco como "no dinámico" e "inestable".

Alguna información sobre el sistema

• Fue desarrollado alrededor del año 2000
• Sistema bastante pequeño, 2-5 usuarios, 6 formularios, ~ 8 tablas con cantidades promedio de datos
• Construido en Visual Basic temprano, formularios creados con el diseño de arrastrar y soltar La interfaz es básicamente una ventana con un menú y algunas formas.
• Utiliza la base de datos MSSQL (servidor SQL2005) para almacenar datos y el controlador ODBC para consultar, los datos se migraron de Excel antes de este sistema, y ​​antes de Excel se manejó, calculó y escribió a mano y en papel.
• Los usuarios trabajan en el entorno de Microsoft XP (y hasta)

Su principal problema es que ya no pueden ajustar y calcular precios, no pueden agregar nuevos tipos de cajas de cartón, etc., porque no pueden (o más bien, no saben cómo) tocar los datos en el servidor.

Sugerí 3 posibles soluciones

1. Intentar parchear el sistema actual
2. Cree una nueva interfaz nueva (preferiblemente entorno similar, basado en VB.net o VB)
3. Devuélvalo a una solución de Excel, considerando que es un sistema tan pequeño

Puede haber más opciones, pero estas son las que se me ocurren.

Mis preguntas son

• ¿Qué debería recomendar y por qué?
• ¿Cuáles son o podrían ser los pros y los contras de estas alternativas?
• ¿Hay otras alternativas (posiblemente mejores)?

Algo con solo 6 formularios y tal debería ser fácil de reconstruir en un marco más moderno. He trabajado con la migración de proyectos VB6 que tenían alrededor de 200 formularios junto con docenas de clases y tablas de bases de datos. No parece que estés mirando algo tan desordenado, pero la apariencia puede ser engañosa.

Tendría que analizar el código, la base de datos y los requisitos comerciales para decir si sería mejor reescribir o refactorizar la base de código existente. Dado lo que has dicho, me inclinaría hacia una reescritura. Pero, podría haber dificultades ocultas que no ves en este momento.

Tengo un consejo ligeramente diferente la mayoría de las respuestas hasta ahora.

Intentar parchear el sistema actual

Al menos, aprendería el sistema actual lo suficientemente bien como para explicarle al cliente cómo usarlo. Me tomaría este tiempo para explicar las fallas en su sistema actual, evitar palabras negativas, simplemente decirles lo que no puede hacer, incluso si se corrigieron todos los errores conocidos.

Cree una nueva interfaz nueva (preferiblemente entorno similar, basado en VB.net o VB)

Después de haber aprendido todo lo que pueda con su configuración actual. Bríndeles opciones, si puede abordar sus preocupaciones con su sistema actual, realmente no hay nada de malo en su sistema actual. La única preocupación, por supuesto, es que el soporte de Visual Basic 6 podría no existir en 5 años.

Otra preocupación es la forma en que se comunica con la base de datos. Microsoft se está deshaciendo lentamente de algunas de las formas más antiguas de comunicarse con sus productos de base de datos (Access, MSSQL), por lo que la forma en que interactúa con esos productos determinará si la solución se puede usar en Windows 9 y Windows 10 en el futuro.

Esta respuesta depende completamente del hecho de que tienen la fuente de la aplicación en sí. Si no tienen la fuente, será difícil abordar sus inquietudes, corregir los principales errores actuales o incluso convertirla en una herramienta que realmente puedan usar.

No creo que haya nada "incorrecto" con una aplicación de Visual Basic 6, además del hecho, su soporte para futuras versiones es desconocido. Incluso hoy en día con los sistemas operativos Windows 7 y 64 bits, es cada vez más difícil de soportar. Esta es una de las principales razones por las que reescribir en un lenguaje moderno con el soporte adecuado de 64 bits podría ser una buena idea.

Si no tienen la fuente en ese momento, una reescritura es realmente su única solución.

Reescribir la interfaz es una excelente opción, dado que el sistema es relativamente pequeño. Las ventajas son:

1. Estabilidad mejorada (¡suponiendo que lo haga bien!)
2. Mantenimiento mejorado
3. Interfaz moderna

La principal desventaja es que probablemente costará un poco más que piratear el código existente.

También tendería a reescribir, pero debes estar 100% seguro de que entiendes completamente la funcionalidad actual, así como cualquier funcionalidad que esté rota, faltante o inadecuada. Los dos últimos son importantes, ya que mencionó ajustar y calcular los precios. ¿Entiendes completamente las consecuencias de agregar esta función?

Una vez trabajé en lo que se suponía que era un "sitio web", pero en realidad me hice cargo de una herramienta de estilo CRM basada en Access personalizada de finales de la década de 1990 y la introduje en el mundo moderno basado en la web. El desarrollador original se había ido hace mucho tiempo, la base de datos había sido modificada innumerables veces, la documentación original estaba desactualizada y nadie entendía realmente cómo funcionaba el sistema. Pero ellos sabían cómo usarlo, solo. Probablemente el 80% del presupuesto para este proyecto se destinó a tres cosas:

• reunir requisitos
• entender el sistema actual
• proponiendo un esquema de base de datos significativo sobre cómo pretendían usar el software

¡El proyecto, financieramente, no fue un éxito!

Otra opción podría ser un compromiso entre reescribir todo y piratear la aplicación existente.

Bríndeles la nueva funcionalidad en una nueva aplicación creada desde cero.

Potencialmente, esto podría ser más fácil de hacer y no costará tanto como una reescritura completa.

Una vez que esto se haya hecho y estén contentos de poder agregar / actualizar datos, se abre la puerta de entrada, una fase dos podría estar reemplazando la funcionalidad existente en la nueva aplicación.

Este podría ser un enfoque más apetecible.

Las reescrituras a menudo tienden a quedarse sin presupuesto ... Mal.

Pero tener un esqueleto moderno para la aplicación puede ser una buena inversión, especialmente si nadie sabe cómo funciona el sistema antiguo y si las cosas se rompen tan pronto como empiezas a tocarlas.

Además, VB6 es malo para el soporte. Cuando necesite encontrar especialistas en 10 años, será bastante problemático.