¿Cuánto tiempo y esfuerzo debe gastar en un proyecto de compatibilidad con versiones anteriores? [cerrado]

Question

Dado que cada proyecto de software sólo tiene tantos programador horas dedicadas a la misma, cuánto tendrían que gastar en asegurándose de que el producto es compatible con las versiones anteriores? En realidad hay varios puntos a considerar:

• ¿La edad del software afecta a su decisión? Tendrá que invertir menos tiempo en la compatibilidad hacia atrás cuando el programa es más reciente?
• ¿Es la decisión basada únicamente en el número de clientes con copias instaladas?
• ¿Haces un esfuerzo activo para producir formatos de código y de archivo que soporta los cambios futuros?
• Cuando estás desarrollando v1.0, ¿Trata de construida para que sea más fácil para v2.0 para ser compatible con v1.0? (Dejar campos "reservados" es un ejemplo.)
• ¿Cómo se decide que "No, no vamos a apoyar eso más" en funciones?

Answer 1

La base de clientes es clave en la determinación de si debe o no apoyar problema de compatibilidad hacia atrás grande.

Básicamente, es necesario evaluar que al igual que cualquier otro requisitos no funcionales es necesario implementar, y es necesario especificar cuidadosamente lo que está incluido en un "hacia atrás compatibilidad" característica :

• compatibilidad API . Esto significa que las versiones posteriores de una biblioteca proporcionan la misma API que hacen versiones anteriores, por lo que los programas escritos en contra de la versión anterior todavía será capaz de compilar y ejecutar con la nueva versión. Además de tener que salir alrededor de las mismas funciones, esto también implica que todas estas funciones hacen lo mismo en la versión más reciente que lo hicieron en los más viejos
• interfaz binaria de aplicación, o ABI, compatibilidad . Esto significa que la compatibilidad hacia atrás se conserva en el nivel del código objeto binario producido al compilar la biblioteca.
  Por lo general hay cierto solapamiento entre el API y la compatibilidad ABI, pero hay diferencias importantes. Para mantener la compatibilidad ABI, todo lo que tiene que hacer es asegurarse de que su programa exporta la totalidad de los mismos símbolos.
  Esto significa que todas las mismas funciones y objetos globalmente accesibles necesita estar allí, por lo que los programas vinculados con la versión previa todavía será capaz de funcionar con la nueva versión.
  Es posible mantener la compatibilidad ABI, mientras que romper la compatibilidad API . En el código C, deje símbolos en los archivos de C, pero sacarlos de las cabeceras públicas, tan nuevo código que intenta acceder a los símbolos dejará de recopilar, mientras que el código de edad que los usuarios compilado con la versión anterior continuará funcionando
• cliente-servidor de protocolo de compatibilidad . Esto significa que un cliente que utiliza la versión del protocolo de red proporcionada en las versiones anteriores va a seguir funcionando cuando se enfrentan a un nuevo servidor, y que los programas de clientes nuevos seguirá trabajando con un servidor antiguo.
• formato de datos de compatibilidad . Las nuevas versiones del código deben ser capaces de trabajar con archivos de datos escritos por versiones más antiguas, y viceversa. Lo ideal sería que también debe ser capaz de construir una cierta compatibilidad hacia adelante en formatos de datos. Si sus rutinas de administración de archivos pueden ignorar y preservar los campos no reconocidos, a continuación, la nueva funcionalidad puede modificar los formatos de datos de manera que no se rompen las versiones anteriores. Este es uno de los tipos más importantes de compatibilidad, simplemente porque los usuarios se vuelven muy molestos cuando se instala una nueva versión de un programa y de repente no pueden acceder a sus datos antiguos.

Si se combinan los criterios anteriores (la naturaleza de la compatibilidad con versiones anteriores) con la naturaleza de su base de clientes, puede decidir que:

• Si sus clientes son internos a su empresa, la necesidad es menor, y 2.0 puede romper funciones importantes.

• Si sus clientes son externos, un 2.0 todavía se puede romper cosas, pero es posible que necesite proporcionar migración guía

• En el otro extremo, si sus clientes son los de todo el mundo, como ya mencionado en este SO pregunta sobre java , que puede terminar de aportar nuevas funcionalidades sin tener que deprecating los viejos! O incluso preservar FALLOS de sus productos antiguos , ya que las aplicaciones del cliente depende de esos bichos !!

---

• ¿La edad del software afecta a su decisión? Tendrá que invertir menos tiempo en la compatibilidad hacia atrás cuando el programa esmás reciente?
  Creo que esto tiene que ver con lo que ya está desplegado: un programa reciente tendrá que lidiar con menos necesidades de compatibilidad hacia atrás que uno que es de alrededor de 20 años

.

• ¿Es la decisión basada únicamente en el número de clientes con copias instaladas?
  Se debe basarse en un modelo de negocio: (¿debido a todas las nuevas características brillantes que trae) que hace su migración - - si es necesario debido a la falta de compatibilidad con versiones anteriores es capaz de ser "vendido" eficazmente a sus clientes

• ¿Haces un esfuerzo activo para producir formatos de código y de archivo que soporta los cambios futuros?
  Tratar de predecir "el cambio futuro" puede ser muy contraproducente y rápidamente limítrofe a YAGNI (usted no va a necesitarlo.): Un buen conjunto de herramientas de migración puede ser mucho más eficaz

• Cuando estás desarrollando v1.0, ¿Trata de construida para que sea más fácil para v2.0 para ser compatible con v1.0? (Dejando los campos "reservados" es un ejemplo.)
  Para los aplicaciones que he trabajado, no. A paralelo Run es nuestra manera de asegurar una compatibilidad hacia atrás "funcional". Pero eso no es una solución universal.

• ¿Cómo se decide que "No, no vamos a apoyar eso más" en funciones?
  Una vez más, por aplicaciones internas, el proceso de decisión puede ser muy diferente que para un desplegado externamente uno. Si una característica no aporta ningún valor añadido para el negocio, una tarea "coherencia" interna está configurado para comprobar con todas las demás aplicaciones internas del coste de su migración (es decir, "no usar más esta característica"). La misma tarea es mucho más difícil de hacer con los clientes fuera de su organización.

Answer 2

Cuanto más su sistema se utiliza día a día, más debe centrarse en ella.

Cuanto más su sistema está profundamente arraigada en los procesos centrales de sus clientes, más se debe centrar en él.

Cuanto más su sistema tiene competidores, más debe centrarse en ella.

Los más usuarios que utilizan versiones más antiguas, más se deberían centrarse en ella.

El más complejo y más profundo de buy-in no es para un cliente a su sistema, en términos de qué tan grande de un impacto que su software ha en su negocio, más se debe centrarse en la compatibilidad hacia atrás.

Si no puede ayudarles a lo largo a través de nuevas versiones y precios atractivos, etc., podría valer la pena considerar el riesgo de obligar a todo el mundo.

Al igual que Vista o Office 2007. Aquellos eran fenomenales en mí ayudar a Apple.

Answer 3

Mi opinión sobre la compatibilidad del software:

1.) Si es un producto ampliamente utilizado ya por muchos clientes, entonces se aseguraría de que la nueva versión de este producto sigue utilizando el mismo "código de base" (Código que logra la funcionalidad básica de la aplicación en desarrollo) . Las nuevas características deben tenerse en cuenta en esta base de código o construidos en la parte superior de esta base de código con el menor cambio necesario en el entorno de ejecución de esta aplicación como sea posible. Usted no quiere que sus usuarios existentes realizan muchos cambios en sus instalaciones existentes. Así que es un equilibrio entre el apoyo a una nueva funcionalidad y renovación en el proceso de instalación y el uso existente para el cliente.

2.) En un nuevo producto, si es posible identificar todas las características posibles de esa aplicación justo en el comienzo, incluso antes de v1.0 está fuera. Identificar qué características u van a enviar en v1.0. y cuáles serían mantenidos para versiones posteriores. Siempre que sea posible mantener estas "características" de tiempo posteriores en cuenta al diseño, la implementación del código, la finalización de la salida del / de la aplicación para acomodar características en futuras versiones. p.ej. Deja elementos adicionales / campos de bits en sus estructuras de datos.

-AD.

Answer 4

Una gran cantidad. Si no desea molestar a cada uno de sus clientes más fieles!

Answer 5

Mi experiencia es con los sistemas de retráctil complejas con relativamente pocos (100 - 5000). Los usuarios Comercialización a menudo tiene un Obligatorio actitud de la compatibilidad hacia atrás sin una apreciación completa de los costes del ciclo de vida. Por ejemplo, el ahorro para el mantenimiento de los errores en su sistema para la actual base de usuarios pueden fácilmente ser pequeños comparados con los gastos de apoyo para los nuevos usuarios durante la vida útil del sistema.