¿Qué saber sobre la calidad general del software?

 A lo largo de todo el proceso de creación del software, tenemos una serie de atributos a tener en cuenta.

ISO 9126

Costos de calidad reales:

  • En fase inicial del proyecto: 130€ estimados de costo.
  • En fase de post-producción (comercial/prod): Alrededor de 7k €.


¿Cómo se logra la calidad del Software?

Métodos de ingeniería del software: Análisis de requisitos del producto, diseño adecuado y con dimensiones adecuadas, atributos y factores de calidad que determinan la calidad del mismo proyecto bien estudiados.

Técnicas de administración de proyectos:

  • Estimaciones para cumplir las fechas.
  • Dependencias de las actividades programadas.
  • Planificación del riesgo: ¿Qué puede salir mal? ¿Qué planes hay para combatir incendios? ¿Planes de contingencia?
En 1986 falleció un paciente al que se le quemó la cabeza mediante un software médico de radiación, las causas que se detectaron a posteriori databan de un error 54, detectado por un físico y una médico.
Las causas del error constaban de:
- Código fuente del sistema.
- Diseño del software erróneo.
- Código fuente viejo reutilizado con tal de ahorrar.
- Sin sistema mecánico de protección.
- Software ineficiente.

Estos accidentes demostraron lo indispensable de buenas prácticas de programación. Actualmente los aceleradores lineales son sometidos a pruebas muy importantes de programación y software. Por ello es importante, ir al detalle con ojo crítico y atención.

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