Nombre: Carlos Andres Babativa Linares.

Cedula de Ciudadanía: 1023919521 de Bogotá D.C.

Análisis y Desarrollo de Sistemas de Información.

Foro Pruebas SW Instrumentos Calidad.

1. ¿Conoce al menos dos casos donde el software haya fallado y esta falla haya cobrado

vidas o haya ocurrido un desastre informático? Sustente la respuesta a través de un blog y

comparta con sus compañeros.

R/TA: A). Entre 1975 y 1987, uno de los fallos más grande de software, fue el del

acelerador lineal médico modelo Therac-25. Esta máquina se utilizaba para tratar pacientes

con cáncer con radioterapia. Cuando de exponía a los pacientes al haz de alta intensidad sin

la protección intermedia de la placa metálica, causando una exposición a dosis letales de

radiación (100 veces mayores de lo esperado) y acabando con la vida de estos meses más

tarde. os anteriores modelos tenían un control mecánico y por hardware que detectaba si

estaba o no puesta la placa impidiendo activar el haz de alta intensidad si no era así, cosa

que no ocurrió con este modelo. Las conclusiones de las investigaciones realizadas sobre el

asunto fueron que, más que un error del software en concreto, lo que llevó a esta situación

fue un mal diseño del software y unas prácticas de desarrollo inadecuadas.

B). El 25 de febrero de 1991, durante la Guerra del Golfo, el sistema de defensa antimisiles

estadounidenses Patriot en Dhahran (Arabia Saudita) no pudo seguir e interceptar un misil

entrante de tipo Scud. El 'software' funcionaba con retraso y no seguía el lanzamiento de

misiles en tiempo real, según el informe de la Oficina de Responsabilidad Gubernamental

de EE.UU. El impacto del Scud iraquí contra un cuartel del Ejército de EE.UU. mató a 28

norteamericanos y dejó a otros cientos heridos.

2. ¿Porque cree usted que son importantes las pruebas de software del sistema de

información y el aseguramiento de la calidad? Sustente la respuesta.

R/TA: Los Productos Software, sistemas y/o aplicaciones son creadas, desarrolladas e

implementadas por seres humanos y por ende en cualquiera de sus etapas de creación se

puede presentar una equivocación, al generarse esa “Equivocación” se puede conllevar a un

defecto en el software, por ejemplo, mala digitación, distracción al codificar, mala

elaboración de un documento entre otras. Si no se ha identificado ese defecto y el software

o la aplicación se ejecuta, hay un alto riesgo de que la aplicación no haga lo que debería

hacer o el objeto para lo cual fue creada, es decir se genera un fallo o desperfecto, lo que

podría generar una catástrofe o grandes pérdidas de dinero.

3. ¿Cómo elaborar unas buenas pruebas de software y asegurar la calidad del mismo?

Sustente la respuesta.

R/TA: Se debe buscar y seleccionar un conjunto de casos de prueba que tengan la mayor

probabilidad de detectar el mayor número posible de errores y fallos, minimizando los

recursos empleados para ello. Para lo cual se puede tener en cuenta lo siguiente.

Aplicar análisis de valor límite, diseñar casos con la técnica de participación de

equivalencia, utilizar la técnica de conjetura de error, combinado entradas y usando casos

típicos de error y utilizar técnicas de caja blanca.

También se pueden utilizar diversos formatos para el diseño de los casos de prueba, los

cuales

deben incluir entre otros:

 Identificación del caso de prueba, Caso de uso a probar, Datos de entrada, salidas

esperadas. secuencia de pasos a seguir, estado, fecha y hora de realización.

4. ¿Qué debe tener en cuenta para elaborar las pruebas del software que hace parte de un

sistema de información? Sustente la respuesta.

R/TA: Para elaborar las pruebas de software de deben definir los aspectos de los módulos y

las funcionalidades sujetas a verificación tipos de pruebas, entornos, recursos asignados,

entre otros aspectos, por medio de un método que tenga una mejora continua.

Algunos de los pasos que considero que de deben tener en cuenta para la elaboración de un

plan de pruebas son:

I. Analizar los requerimientos de desarrollo del sistema de información.

II. Identificar las funcionalidades a probar.

III. Definir estrategias para implementar las pruebas.

IV. Definir los criterios de inicio, aceptación y suspensión de las pruebas.

V. Identificar los ambientes requeridos.

VI. Determinar las necesidades del personal y generar la respectiva capacitación.

VII. Establecer la metodología y procedimiento para las pruebas.

VIII. Elaborar la planificación de las pruebas.

IX. Identificar los riegos y generar planes de respuesta a las fallas encontradas.