¿Volver a escribir el acceso adp/sqlserver a C# .net?

Question

Soy una persona no técnica y tengo una pequeña compañía que ha estado apoyando el software de mi empresa por varios años. La solución funciona bien y las permutaciones de la solución han sido con el proveedor actual de servicios de TI por más de 15 años. Recientemente obtuve una firma de TI más establecida para realizar una auditoría general sobre el software. La solución actual usa acceso como interfaz con sqlserver 2005 como base de datos. La empresa que realizó la auditoría presentó una lista de fallas, entre otras, de que la tecnología está desactualizada, la solución no es escalable, mal diseño, interfaces no amigables, tablas no normalizadas, tablas no tienen integridad referencial, no usan estándares adecuados de codificación y nombrando convenciones, sin seguridad de la aplicación, solo seguridad de la base de datos, etc. La firma que realizó la auditoría propuso que la solución debe ser reescrita y ofrecida para hacerlo. El actual proveedor de servicios conoce algunos de los hallazgos, pero me asegura que representa muy poco o ningún riesgo para mi negocio. Volver a escribir la aplicación costará mucho dinero. Estoy en una situación difícil y agradecería algún consejo técnico. Básicamente necesito saber si mi negocio corre el riesgo de funcionar con la tecnología actual. Tengo un máximo de 70 usuarios simultáneos trabajando en el sistema en un momento dado

Answer 1

Bueno, si usted valora el word de Joel, diría que de hecho está arriesgando mucho aquí.

Reescribir cosas fue y nunca será una cosa segura para una empresa.

Answer 2

Las sugerencias que ofrece la "empresa de TI más establecida" son bastante comunes para los proyectos de servidor de acceso/sql. La sugerencia casi siempre es volver a escribirlos como aplicaciones web.

Hice esto el año pasado: tomé una aplicación MS Access front-end/SQL Server y reescribí la parte de acceso como un sitio web C#/ASP.Net. Disfrutamos de un mejor rendimiento y más flexibilidad como resultado del cambio, pero el viejo front end había existido lo suficiente como para que nunca recuperamos toda la funcionalidad que solíamos tener antes de la reescritura.

Si actualmente está viendo 70 usuarios concurrentes, y ninguno de ellos está experimentando problemas de rendimiento, y su red corporativa es lo suficientemente segura, entonces puede perder más reescribiendo la aplicación, al menos en términos de funcionalidad. Por otro lado, esta puede ser una buena oportunidad para evaluar "lo que funciona" y "lo que podría funcionar mejor" y mejorar los flujos de trabajo.

El excelente uso de estándares de codificación no se traduce necesariamente en una excelente aplicación.

Answer 3

Antes de ir a ver su problema desde la perspectiva técnica, debe evaluar cuán importante es la aplicación para su negocio. Parece que tienes una aplicación en funcionamiento. Si ofrece un comportamiento constante Y no necesita actualizaciones/nuevos desarrollos, puede dejarlo en paz. A los desarrolladores de software nos encanta quejarse del código de los demás, reescribir el trabajo de otros con soluciones "elegantes". Eso significa dinero.

Sin embargo, usted tiene una inversión que puede necesitar mantenimiento, y cuando tiene el código subyacente y la base de datos en desorganización, incurrirá en un costo mayor porque la aplicación no se presta a ser modificada. Deberá tener una idea de la cantidad de cambio que necesita para respaldar. Dado que ha estado en producción durante 15 años, ha tenido una buena carrera, por lo que no tiene mucho riesgo allí.

Hacer una reescritura le costará, porque necesita recrear lo que hace la aplicación, y dado que la base de datos y el programa de soporte parecen estar "des-normalizados" y desestructurados, va a ser un gran esfuerzo. Existen ventajas de tener un modelo de base de datos limpio porque será más fácil hacer informes, exportar a Excel, etc. Y si desea modificarlo, será más fácil para los desarrolladores decidir qué hacer.

Gastar dinero para obtener lo que ya tiene requiere que desafíe a la empresa a detallar los beneficios adicionales que recibirá. ¿Estos beneficios van más allá de lo que obtendrás hoy, y esta empresa cumplirá sus promesas? ¿Su empresa estará mejor si la base de datos está "normalizada" pero no recibe otro beneficio que el que le ofrece la aplicación actual? Tenga esto en cuenta antes de dar el salto a una nueva plataforma.

Answer 4

Para reducirlo a términos simples, hágase las siguientes preguntas:

1. ¿Está teniendo problemas con el software actualmente? ¿Los usuarios se están quejando de la interfaz de usuario o es particularmente difícil para los nuevos usuarios recoger el software cuando lo usan? ¿Se están perdiendo o corrompiendo datos en algún momento o tiene problemas para recuperar informes de la base de datos?

2. ¿Actualmente o en el futuro es probable que necesite modificaciones? Si su software está mal escrito, las modificaciones serán más costosas y tendrán más probabilidades de romper la aplicación y causar un tiempo de inactividad en general.

Si la respuesta a ambas preguntas es no, entonces probablemente no necesite volver a escribir el software. Debe recordar que los buenos desarrolladores de software ven software mal escrito y desean volver a escribirlo correctamente, y además, hay dinero para ellos en el desarrollo del software, por lo que su visión no es totalmente imparcial.

Como otros han dicho, volver a escribir un sistema tiene su propia cuota de riesgos: los viejos errores que se arreglaron hace mucho tiempo pueden volver a aparecer, se pueden introducir nuevos errores, los desarrolladores del nuevo sistema pueden no entiende el punto y hace que el sistema sea menos útil que el sistema anterior.

Si hay problemas con el sistema actual, puede valer la pena considerar que el sistema sea reescrito por desarrolladores competentes. Sin embargo, si opta por seguir esta ruta, asegúrese de obtener comentarios de sus usuarios actuales, especialmente el usuarios "expertos" o "poderosos", para garantizar que el sistema cumpla con todos sus requisitos.

Answer 5

Soluciona los problemas en la aplicación existente. Será mucho más barato, se puede hacer de forma incremental y, si se realiza correctamente, dará como resultado una aplicación más fácil de mantener.

La sugerencia de reemplazar el extremo frontal de ADP me suena a puro prejuicio/ignorancia; no venden el desarrollo de acceso, por lo que quieren compilarte una aplicación completamente nueva.

Por otro lado, el consejo sobre el backend suena como algo que no debe esperar para solucionar (aunque podría requerir mucho trabajo, ya que los datos existentes probablemente no se ajustarán a RI).

Los problemas de front end y back-end son dos problemas independientes y se pueden manejar de forma independiente (aunque es posible que la aplicación deba actualizarse para reflejar los cambios en RI; imposible de evaluar sin una evaluación caso por caso).

Contrataría un desarrollador competente de Access con experiencia ADP para manejar el proyecto. Esto será mucho más barato que la reescritura completa y no sacrificará ninguna funcionalidad, ni volverá a introducir errores que ya se han abordado en su aplicación actual. También se puede hacer de forma incremental (dependiendo de cuáles sean los problemas y cómo se deben resolver).

Answer 6

Respuesta simple ... La mayoría de los "riesgos" de utilizar Access se superan mediante el uso de SQL Server como servidor. Ya dijiste que tu solución actual funciona.

Por lo tanto, se reduce a sus planes para el futuro. Si a su aplicación actual no le falta ninguna funcionalidad que no pueda proporcionarse a través del acceso, simplemente me quedaré con lo que tiene. Si necesita nuevas características, consideraría algunas cosas.

1. ¿Son algo que el acceso no puede proporcionar o que funciona bien (por ejemplo, soluciones orientadas a Internet)?
2. ¿Cuál es el beneficio potencial cosechado por tener las nuevas características?
3. ¿Cuál es el costo potencial incurrido por no que tiene las nuevas características?
4. ¿Puedes poner una cifra en dólares en 1 & 2?
5. ¿Cuánto desarrollar la solución en Access?
6. ¿Cuánto hay que desarrollar la solución en C#

En otras palabras, siempre hago las CBA :) Mejor aún, no es el propietario CBA, a continuación, pedir a ambas compañías para ofrecerle una, y comparar por diversión. En el peor de los casos, puede hacer que su empresa actual reduzca su precio para retenerlo como cliente.

Answer 7

¿Qué provocó la auditoría? ¿Su solución aborda este problema?

Vamos a hacer los cálculos: Personas: 70 Promedio . Horas El uso de software/Día: 2 (Conservador) Salario/Hora: $ 8,00 (Realmente Conservador) días laborales/Año: 250 (Tomó a cabo los fines de semana & vacaciones/enfermos)

El costo de la mano de obra mediante la aplicación: 70 * 2 * 8 * 250 = $ 280,000/Año (Podría ir más de 500K)

¿Cuánta mejora puede obtener? 5%, 10%, 25% ¿Cuánto costará la nueva aplicación? 50K, 100K, 200K

Si puede ahorrar esta vez, ¿sus usuarios estarán libres para realizar actividades generadoras de ingresos o tendrán más tiempo para navegar por la web? Es posible que desee crear algún factor de eficiencia del trabajador: 90%, 75%