Cómo determinar la aplicación web final de la vida?[cerrado]

Question

Esta pregunta podría traer una gran cantidad de opiniones a la mesa, pero lo que me gustaría conseguir es un conjunto de medidas que ayuden a mí y a mi empresa determinar el final de la vida de un producto que se vende.

Vendemos un sistema CMS, con este sistema podemos crear un par de sub-productos

• Sitios web
• Propuesta Creador
• Campaña De Marketing Tracker

Estamos listos para empezar nuestro camino de una planificación (2010 y 2011) y estamos tratando de determinar cuando será el final de la vida de nuestra aplicación.Algunos de ustedes podrían pensar que una muy bien diseñada aplicación (No creo que nuestra aplicación está bien diseñada) no necesita tener un final de la vida, pero esta aplicación que estamos utilizando se remonta al menos 6-7 años y casi no tiene documentación (la vida real).En este momento sólo UNA persona sabe cómo cambiar la funcionalidad principal (de miedo).

Por favor, consejos,

Geo

---

Gracias a Todos!Realmente aprecio sus comentarios, opiniones y pensamientos sobre este tema.

Voy a hablar de algunos de los post de nuevo las preguntas de la lista de abajo

• Hay un desarrollador que es capaz de mantener el núcleo de la funcionalidad de nuestro producto.(y sólo uno)
• Hay dos desarrolladores que son capaces de aumentar la funcionalidad de un cierto punto.Tanto los desarrolladores están restringidos por las limitaciones del producto, y que ambos tienen que trabajar dentro de esos límites.
• Una nota muy importante.El producto que estamos considerando para poner fin-de-vida es para la mayoría de la parte que está siendo construida por un contratista.El contratista es el único desarrollador capaz de mantener la funcionalidad del núcleo.Sólo nos desarrollamos en la parte superior de la contratista marco.

Voy a seguir agregando respuestas mientras te leo todas las respuestas.

Answer 1

Dado que la aplicación está muy bien diseñada, es posible que no desee retirarla y perder toda la inversión que ha realizado hasta la fecha.

Aquí están mis sugerencias:

• Haga que un desarrollador junior se una a este desarrollador actual.
• Volcar la mayoría de las actualizaciones futuras sobre el desarrollador junior (con la ayuda del desarrollador de Sr.)
• Pídale al desarrollador junior que haga la documentación de su trabajo
• Pídale al desarrollador Sr. que revise la documentación

Durante el período de tiempo, tiene otra persona que puede apoyar esta aplicación y también se documentará. Ahora no necesitará matar su propia aplicación muy bien diseñada con sus propias manos.

.

Extender esta solución con la sugerencia de Jefferey a continuación ("A veces, reescribir es una buena inversión").

Si aún desea eliminar la aplicación actual y volver a escribirla, aún necesita documentar el sistema existente y crear requisitos para el nuevo sistema basado en ella.

Usando la documentación del sistema actual y propuesto, es posible que desee ver si puede modular de manera incremental por componentes de actualización del módulo (reescribir). Esto es posible si la aplicación está muy bien diseñada.

---

Según sus comentarios (Geo)

La organización de GEO tiene una aplicación CMS personalizada de terceros (con un solo desarrollador de contratos) que implementa los requisitos comerciales y está pagando la tarifa de licencia por el apoyo y el uso de su código.

• Requisitos comerciales para CMS
• Sitios web
• Creador de propuestas
• Rastreador de campaña de marketing

Aquí están mis sugerencias

• Crear módulo por módulo Documento de caso de uso detallado para este proyecto. Su desarrollador puede hacer esto o sería ideal para tener un analista de negocios separado para lo mismo.
• Contrata a un desarrollador Sr. para evaluar si los CM de código abierto pueden manejar todos o la mayoría de sus requisitos (por ejemplo, Joomla, Drupal, etc.).
• Lo más importante aquí sería la capacidad de migrar sus datos existentes al nuevo sistema. Es posible que necesite ayuda de su desarrollador de contratos existente para hacer esto.
• Es posible que deba actualizar el proceso comercial o el flujo de trabajo para usar un nuevo sistema.
• Se puede requerir módulos que no se pueden implementar utilizando CMS de código abierto que se implementen utilizando el sitio web personalizado.

Gran parte de esto también depende de su relación comercial con el desarrollador de contratos existente y el acuerdo de licencia. Lo que te enfrentas es un escenario de bloqueo de proveedores. Es posible que desee investigar más sobre soluciones para eliminar este proveedor de bloqueo en la situación.

Answer 2

Esta es solo mi opinión, pero si se trata de un producto que está vendiendo, entonces todo se reduce a las perspectivas comerciales. Si el producto no se vende, déjalo. Si el producto tiene futuro, invierta en él y conviértalo en el mejor software que pueda refactorizar, reescribir o lo que tenga que hacer. Si tiene clientes leales o una marca fuerte, entonces vale la pena protegerla.

A veces, reescribir todo en otra tecnología es una buena inversión, si el software actual tiene un diseño exitoso que se puede copiar, tiene una marca fuerte y si se puede hacer bien.

Answer 3

La aplicación llegó al final de la vida en el momento en que se envió sin ningún tipo de documentación. Comience el desarrollo ahora, y es posible que desee considerar reemplazar a la persona que conoce el sistema original. Si han pasado 6/7 años sin crear ningún tipo de documentación, no son alguien que querrá en su empresa.

Answer 4

El único tipo de documentación que extenderá la vida de su sistema son las cosas que se mantienen consistentes a medida que el sistema cambia en su vida, como suites de prueba, herramientas de autodiagnóstico, comentarios de código, contratos declarativos como interfaces y documentación generada automáticamente.

Otros artefactos de documentación administrados manualmente, como manuales, guías de desarrolladores, documentos de arquitectura, formatos de datos tienden a estar desactualizados en proporción a la cantidad de documentación. No contaría estos como factores que aumentan la esperanza de vida de su aplicación a menos que ya haya tenido en cuenta el costo de mantenerlos.

Si no puede "pagar" la redundancia del desarrollador para mantener la aplicación de manera confiable, no hay forma de que pueda permitirse mantener actualizado la documentación. La falta de documentación es realmente una deuda técnica que ha decidido, tal vez inconscientemente, asumir. Si un ciclo de vida más largo es un requisito, entonces el costo de eso debe tener en cuenta el cumplimiento de ese requisito.

Answer 5

Para hacer una historia larga: estoy en una situación comparable.

• Mientras esta aplicación sea algo así como un CashCow, pero la compañía no puede permitirse (o pretende) desarrollar una nueva aplicación, no morirá antes de que los clientes decidan comprar un sistema más fresco.

• Reescribir sin requisitos (documentados) es casi imposible.

• Al menos la experiencia de los departamentos especializados debe documentarse de una manera que sea útil para desarrollos adicionales.

• Si tiene que mantener esta aplicación, debe introducir interfaces entre módulos, para reducir la complejidad general. Tan viejos módulos, no importa cuán desordenados estén, no le importa si tiene que completar una nueva funcionalidad.

Answer 6

Incluso si está muy bien diseñado y funcionando, el hecho de que no tenga documentación y depende de una persona para su vida, significa que el producto ha entrado muy bien en un estado imposible de montaña. Esta no es una buena señal. Estoy de acuerdo en que el producto hace mucho tiempo "fin de la vida"

Answer 7

Estos son el tipo de cosas que podría considerar al decidir si un sistema podría estar "al final de la vida":

¿Está la funcionalidad que este sistema proporciona disponible para los usuarios finales en una forma más barata, más confiable o más fácil de usar? Si no ahora, ¿cuándo es probable? ¿Es este producto, por lo tanto, viable a largo plazo?

¿Está escrita en una tecnología de la que los clientes se alejarían, ya que sería incómodo interactuar en sus productos, o exigir que ejecutaran plataformas "obsoletas"? ¿Le daría a un cliente potencial la impresión de que su empresa es significativamente Detrás de The Times, por ejemplo, VB6 probablemente todavía esté bien, incluso en 2010, pero requerir compatibilidad Win16 probablemente no lo sea.

¿Puedes contratar buenas personas que conozcan la plataforma técnica subyacente a un costo razonable? En la tecnología más antigua, podría ser que hay muchas personas que conocen la plataforma, pero lo ven como un extremo muerto y solicitarán un salario premium si su carrera languidece en la crisis mientras trabajan en ello.

Si le importa, ¿la plataforma de desarrollo todavía es compatible con el proveedor? ¿Vas a estar limitado en qué hardware u sistema operativo puedes ejecutarlo si el proveedor ya no lo actualiza? Del mismo modo, ¿hay agujeros de seguridad en la plataforma que pueden necesitar actualizarse? Incluso los productos de código abierto de nicho pueden sufrir esto. Una vez que un producto sale de favor y los desarrolladores centrales se mueven a nuevos proyectos, puede ser difícil obtener correcciones realizadas por la comunidad.

Si es compatible, ¿los proveedores le cobran una prima por apoyar una plataforma más antigua? Si no ahora, ¿cuánto tiempo antes de que lo hagan?

¿Qué tan difícil es integrar nuevas tecnologías para aprovechar las tendencias actuales que ofrecen funcionalidad enriquecida a los usuarios finales para mantenerlo competitivo? ¿Te importa esto? Puede que no importe si esencialmente está ejecutando un sistema cerrado.

¿Qué tan difícil es liberar cambios funcionales sin extensos cambios de "escopeta" que se agitan en todo el sistema? Esto vuelve a cuán modular se diseñó el sistema para ser en primer lugar. Si no es peor, sus competidores para obtener funciones para el mercado, entonces probablemente esté bien.

¿Cuál sería el costo de reescribir el sistema? ¿Cómo se compara esto con cuánto más barato sería mantener o aumentar los ingresos de venta? Puede que no sea económicamente factible hacer una reescritura completa. Si la plataforma de desarrollo es sólida, entonces podría probar más un enfoque de refactorización. Aquí es donde tener una buena prueba y documentación ayuda.

Answer 8

Fui a través de un proceso similar.Tuvimos una aplicación web que habían funcionado durante casi 8 años.En ese momento una gran cantidad de mantenimiento que se hizo, que se extiende en formas que no habíamos previsto.Sin embargo, la base era buena y era todavía capaz de ser estirado.

Lo que nos empujó a más de la era del costo de mantenimiento.Encontrar a las personas con el perfil adecuado era fácil hace 8 años.Hoy en día, nadie quiere trabajar en los entornos;ni siquiera nosotros :)

Después de un análisis, sabíamos que podría sustituirlo en un plazo de 12 meses con las mismas funciones Y que este tiempo que estuve iba a pagar rápidamente.

Así, hemos utilizado las capturas de pantalla como nuestros requisitos funcionales, renovado el aspecto y la sensación, y fueron incluso capaces de ofrecer mayor funcionalidad.También nos fijamos en el uso de los datos para identificar las partes que eran rara vez o nunca se utilizan y tapizados en aquellos, y se centró más la atención en las piezas que se utilizaron.

En definitiva, hemos tenido éxito.En parte porque todo el mundo en el equipo estaba bien versado en la nueva tecnología, así que había poca necesidad de aprendizaje.Otros factores contribuyentes incluyen un bien pensado diseño.Creo que nos pasó 3 meses en el diseño antes de escribir nada.

El último factor fue que nuestra aplicación es modular.Así que hemos sido capaces de fragmentar en tamaños lo suficientemente pequeño como para tener una combinación de cortos plazos de entrega con un tiempo de inactividad / período de análisis entre cada entregable.Esto aseguró de que estábamos en el camino correcto en cada etapa.