¿Cuándo se termina de desarrollar un software?

 La respuesta correcta a esta pregunta pueden ser varias, pero aquí ponemos 3:

1. Nunca. 

Muchos software llevan años y años y años desde su salida, si triunfaron, entonces se seguirán perfeccionando para servir cuanto más y mejor. Y la idea de los mismos es continuar actualizándose de forma constante, así es el funcionamiento de la tecnología en general como ciencia. 

Por ejemplo, podemos fijarnos en los software de mensajería, o bien en los de modelaje 3D, consolas que van actualizándose, etc.

2. Hasta que se acabe el dinero / capital a invertir / malos negocios.

Gran parte de la tecnología que no triunfa, o no tiene un marketing lo suficientemente relevante como para llegar a mucha gente, acaba obsoleta por la falta de beneficios. 

Puede salir una app o proyecto que posee una idea de base muy buena, por ejemplo: VR Hotel, u otras. 

3. Decisión de la empresa.

La empresa que decide terminar un proyecto puede tener varias razones.

Continuar con nuevos proyectos y evolucionar el nombre de un proyecto, adoptando un nuevo nombre.

Fecha final de un proyecto que tiene una utilidad específica (CardioShape).


Comentarios

Publicar un comentario

Entradas populares de este blog

Ciclo de vida del defecto

 New > Assigned > Open > Fixed > Re-Test > Closed. Se abre el bug, se asigna a un lead, el lead lo asigna a un desarrollador, el desarrollador decide si lo soluciona, o bien, si lo deja pasar. Se manda para Re-testear desde dev a qa para verificarlo (estilo regresion), y si se ha solucionado, finalmente se pasa a closed/cerrado. Si se cierra entonces no se vuelve a reproducir más. A no ser que aparezca en nuevas actualizaciones. Hay que tener en cuenta que, al abrir el bug, el mismo puede aparecer duplicated /duplicado si se ha subido dos veces.  También puede rejected /rechazarse por alguna razón desde el departamento de desarrollo, pero si el QA considera que es un defecto, puede volver a reabrirlo y mandarlo de vuelta a desarrollo. Deferred , significa que el desarrollador lo rechaza, pero por alguna razón en concreto, por ejemplo, porque es un error que se conoce desde desarrollo y se va a solucionar para nuevas versiones (se usa muy poco, ya que el QA no ...
Leer más

¿Cómo integramos el software?

Para integrar pruebas en metodologías de software testing, podemos: Integrar componentes, para la creación de la batería de pruebas. Establecer una estrategia de integración de dichas pruebas para la batería de pruebas. Preparación del ambiente de prueba con un servidor y herramienta. Como por ejemplo, Qase. Establecer pruebas para cada actualización, por ejemplo los Test Run y basarnos en Test Plans. Además, existen otras 2 formas de integración del software. Pruebas Big-bang , llamadas así porque basa las pruebas en diferentes módulos o áreas dentro del proyecto. Por ejemplo, en LMDance, podría basarse en áreas de HUD/UI, o bien creación de perfiles, o bien Gameplay, o pruebas de conexiones.  Estas pruebas Big-bang, hacen hincapié en áreas independientes, como las ya mencionadas en el párrafo anterior. Por ello probamos el programa de manera completa e íntegra.  Pruebas Acendentes/descentes , más organizadas porque no van por áreas sueltas, sino que se prueba el software apa...
Leer más

Principios en pruebas de Software.

- Uno de los principios elementales del software testing, es que las pruebas muestran la cantidad de errores posibles, la cantidad de defectos. Pero no su ausencia.  Por ejemplo, para Samsung, el galaxy note 7 tuvo que ser retirado del mercado debido a que éste se incendiaba o explotaba tras cargarse durante varias horas. - Las pruebas exhaustivas son imposibles de realizar, o bien no existen. Un claro ejemplo, en cualquier proyecto de CHESS / ajedrez, habrían de realizarse infinitas pruebas respecto a los posibles movimientos.  Según IBM, corregir un defecto encontrado en post-producción, costará 30 veces más que en su etapa temprana. - Probar en la proporción adecuada, teniendo en cuenta la regla 80-20, el 80% de los fallos se podrían encontrar en un 20% de modos. - Cuidado con la paradoja del pesticida.  - Las pruebas dependen del contexto: No es lo mismo realizar pruebas que tiendan a perder vidas humanas, software médico, o económico, que probar una web que registre ...
Leer más