Signs of Dying Software

Question

¿Cuáles son las señales de que el software está muriendo?

---

¿Cómo un desarrollador encuentra que las advertencias tempranas para salvar una pieza de software no se mueren?

Desde la perspectiva del usuario, creo que es bastante claro: lo que no pueden usar de manera eficiente, lo arruinarán.

Aparte de esto, el software puede morir debido a su código: la arquitectura, el estilo de codificación, el tamaño de la base de código, la organización de la base de código y la calidad de los programadores.

Quiero saber cómo escuchar los signos de un software que se está muriendo y tomar medidas correctivas. ¿Algún software de ejemplos famosos está muerto porque ningún desarrollador escuchó los signos? ¿Hay algún ejemplo de software de muerte que se está guardando?

Answer 1

Cualquiera de los siguientes son una clara indicación de que el sistema está en la lista de especies en peligro de extinción:

• punto único de error permitido de existir (sólo una persona lo entiende)
• Los recursos no son asignados por la gestión para reparar defectos
• No hay desarrollo activo durante seis meses
• Sin ciclo de liberación en un año
• productos de proveedores subyacentes/bibliotecas salen de apoyo
• Recursos retirados de un proyecto y no sustituyen más de dos veces en un cuarto
• cambios ambientales (mayor volumen de usuarios, por ejemplo) no se rehabiliten
• El rendimiento no se mide y puesta a punto no se produce de forma regular (rendimiento se degrada)
• cambios de infraestructura se avecina (OS, DB, HARDWARE)
• Los usuarios han creado arounds de trabajo debido a los defectos, frustraciones o errores en su sistema
• base de usuarios está cayendo

Maneras de mantener un proyecto vital:

• involucrar a su gestión abierta y directamente
• tasas Informe de defectos de forma precisa y cuantificarlos en términos de coste de gestión
• automatizar tanto de la construcción, prueba, embalaje y despliegue ciclos como se puede
• modularizar el sistema tanto como sea posible
• Tener métricas claras en su lugar y ajustar el applicaiton si es necesario
• entender lo que sus usuarios encontrar más críticos y satisfacer esas necesidades

En las bibliotecas sofware que vienen detrás de los muertos que tendría que dar el primer lugar de cinta a Objective-C.

Answer 2

Inserta la broma malhumorada de Windows aquí.

En realidad, hay varios signos:

• aumentar defecto tasa de llegada
• alto costo por defecto reparado
• alto costo por nueva característica

Todo esto sugiere mayor entropía en el código, es decir, una baja relación señal/ruido.

Hay una serie de formas de atacar esto; probablemente el más efectivo es identificar módulos que tienen altas tasas de defectos; los defectos tienden a tener una distribución de Pareto, es decir, el 20 por ciento de los módulos representan el 80 por ciento de los defectos. Usted construye un marco de prueba para estos módulos y los vuelve a implementar desde una página limpia, construyendo buenas pruebas (usando marcos de pruebas unitarias, etc., según corresponda) y luego volviéndolos a integrar en el sistema general.

Answer 3

No arreglando errores críticos pronto. Supongamos que envía una nueva versión que tiene un error que afecta al 10% de los usuarios. Si no lo arregla de inmediato y envía una versión fija, estos usuarios no podrán usar completamente el programa y buscarán un reemplazo. Cuando finalmente envía la versión fija con retraso, se han ido.

Answer 4

La única medida que cuenta es la que se deriva de la "perspectiva del usuario" a la que hace referencia anteriormente.

Los candidatos más probables son: 1. Solicitud de
apoyo aumenta, y
2. disminuciones en las ventas.

Answer 5

Cuando los desarrolladores están poniendo excusas _NOT_ para tocar o apoyar el software.

Answer 6

Lea este blog de Jeff Atwood (uno de los creadores de este sitio). Una lectura maravillosa sobre un software en extinción.

http://www.codinghorror.com/blog/archives/001252.html

Answer 7

creo que el software de morir a causa de las "razones técnicas" internas que parecen tener en cuenta es relativamente raro. Realmente no puedo pensar en ningún ejemplo; tal vez Delphi (aunque eso no está muerto, solo está gravemente enfermo).

parece mucho más común para el software que se mueren a causa

• El hardware o sistema operativo subyacente se vuelve obsoleto y el software deja de hacer la transición (WordPerfect, Lotus 1-2-3)
• Un producto de la competencia ofrece características superiores, mientras que el líder del mercado se estanca debido a la complacencia (Amiga)
• el software se vuelve obsoleto a través de "cambios de paradigma" (Encarta)

Si bien es probable que los dos primeros puntos a menudo se deba en parte a problemas de calidad (lo que hace que sea demasiado lento y costoso para reaccionar a los cambios del mercado), este último no lo es.