Universidad Tecnológica del Valle del

Mezquital
T.S.U TECNOLOGIAS DE LA INFORMACION.

MEJORA PARA EL DESARROLLO DE SOFTWARE

“Caso de estudio”

Facilitador: Ing. Emiliano Bomaye Roque.

Erika Moctezuma García

4º “A”

Agosto-Diciembre2019
Contenido
Caso de Estudios ........................................................................................................................... 2
Diseñarlo y Practica....................................................................................................................... 2
Pruebas funcionales ...................................................................................................................... 5
Pasos para elaborar el plan de pruebas .................................................................................. 8
Caso de Estudios
Básicamente, un estudio de caso es un estudio en profundidad de una situación
particular en lugar de una encuesta estadística de gran alcance. Se trata de un
método utilizado para reducir un campo muy amplio de investigación hasta lograr
un tema fácilmente investigable.

Si bien no responderá a una pregunta completamente, brindará algunos indicios y

permitirá una mayor elaboración y la creación de una hipótesis sobre un tema.
El diseño de investigación de un estudio de caso también es útil para probar si las
teorías y modelos científicos realmente sirven en el mundo real. Puedes crear un
gran modelo por computadora para describir cómo funciona el ecosistema de un
estanque, pero solamente después de que lo hayas probado en un estanque de
verdad comprobarás si se trata de una simulación realista.

Para los psicólogos, antropólogos y científicos sociales ha sido considerado un

método válido de investigación durante muchos años. En ocasiones, los científicos
son culpables de quedar enterrados entre la idea general y a veces es importante
conocer los casos específicos y garantizar un enfoque más holístico de
la investigación.

Diseñarlo y Practica
La ventaja de un diseño de investigación de un estudio de caso es que puedes
centrarte en casos específicos e interesantes. Puede ser un intento de probar una
teoría con un caso típico o puede ser un tema específico que es de interés. La
investigación debe ser exhaustiva y la toma de notas debe ser meticulosa y
sistemática.

El primer fundamento del estudio de caso es el tema y la relevancia. En un estudio

de caso, estás tratando intencionalmente de aislar a un pequeño grupo de estudio,
un caso individual o una población en particular.

Por ejemplo, el análisis estadístico puede haber demostrado que el índice de

natalidad en los países africanos está aumentando, pero un estudio de caso en uno
o dos países específicos se convierte en una herramienta poderosa y enfocada para
determinar las presiones sociales y económicas que producen esto.

En el diseño de un estudio de caso, es importante planificar y diseñar cómo

abordarás el estudio y asegurarte de que toda la información recopilada sea
importante. A diferencia de un informe científico, no existe un conjunto de reglas
estrictas, por lo tanto, lo más importante es asegurarte de que el estudio esté
enfocado y sea conciso. De lo contrario, te encontrarás con una gran cantidad de
información irrelevante.
En la actualidad los dispositivos tecnológicos eléctricos y/o electrónicos, en especial
las computadoras se utilizan en un gran número de actividades para la vida del ser
humano, y en algunas áreas es un factor crítico, como ejemplo se pueden
mencionar casos como las transacciones electrónicas, negocios de la bolsa de
valores, telemedicina, transporte aéreo, estos casos son solo algunos de los
muchos en los cuales, el adecuado funcionamiento del software es vital, hay casos
muy sonados en los cuales por un “software defectuoso o en mal estado” se ha
impactado directamente al ser humano, por mencionar algunos: “El batacazo de
Wall Street ” Donde el sistema informático el 19 de Octubre 1.987 (Lunes negro) no
pudo controlar el éxodo masivo de inversionistas, generando un colapso y
saturación del mercado, situación que le costó a Wall Street 500.000 millones de
dólares; “Therac-25 ” En 1.982 salió al mercado la máquina de terapia radiactiva
canadiense Therac-25, cerca de 1.985 la maquina fallo emitiendo dosis letales de
hasta 125% más de la radiación tolerada por los pacientes, a causa de ello murieron
3 personas y 6 más quedaron gravemente afectados; El caso de la maquina
Therac-25 puede sonar demasiado fatalista, pero es un excelente ejemplo de la
importancia de diseñar sistemas pensando en el usuario y hacer las pruebas de
calidad de software necesarias; “Cernobyl ” El accidente nuclear más grande hasta
el momento de la Historia, el día 26 de Abril de 1.986, por problemas en el sistema
de control en el circuito de refrigeración en uno de los reactores, lo cual genero una
expulsión de 8 toneladas de combustible
radioactivo, las consecuencias del
accidente afecto a casi 5 millones de
habitantes y hoy en día todavía sufren las
secuelas con diferentes enfermedades.se
pueden mencionar casos en la actualidad
como el problema del software de la
embajada de Estados Unidos en
Colombia que hizo que se represara la
expedición de las Visas e inclusive
debieron cerrar por dos días la atención al
público.
Importancia de las pruebas de Software.

En un proyecto de desarrollo de software pueden aparecer errores en cualquiera de

las etapas del ciclo de vida, algunos de ellos incluso permanecen sin ser
descubiertos, de ahí la importancia de las pruebas en desarrollo de software.

Hay una gran probabilidad de que el código final tenga errores tanto de
requerimientos, como de diseño o de funcionalidad. Para identificar estos
problemas antes de que ocurran en un entorno crítico, es necesario realizar pruebas
de software, una parte muy importante del proceso, pero también muy costosa; sin
embargo, debemos en tener en cuenta que el coste debido a un fallo mientras está
el software en funcionamiento puede llegar a ser mucho mayor.

Objetivos principales al realizar pruebas:

 Detectar un error específico.

 Descubrir errores no descubiertos antes.
 Tener un buen caso de prueba.
Principios de la prueba:
• Hacer un seguimiento de las pruebas hasta
satisfacer los requisitos del cliente
• Plantear y diseñar las pruebas antes de generar el código
• Empezar las pruebas en módulos individuales y terminar
probando el sistema completo
• No son posibles las pruebas exhaustivas
• Deben realizarse por un equipo independiente al equipo de desarrollo

Tipos de pruebas

Pruebas funcionales
Una prueba funcional es una prueba basada en la ejecución, revisión y
retroalimentación de las funcionalidades previamente diseñadas para el software
(requisitos funcionales). Hay distintos tipos, entre ellas las más comunes, por
ejemplo:

 Pruebas unitarias
 Pruebas de validación
 Pruebas de integración
  Pruebas de sistema
 Pruebas de aceptación

 Pruebas de Unidad. Las pruebas unitarias tienen como objetivo verificar la

funcionalidad y estructura de cada componente individualmente una vez que
ha sido codificado.
 Pruebas de integración son aquellas que se realizan en el ámbito del
desarrollo de software una vez que se han aprobado las pruebas unitarias y
lo que prueban es que todos los elementos unitarios que componen el
software, funcionan juntos correctamente probándolos en grupo.
 Pruebas de validación en la ingeniería de software son el proceso de
revisión que verifica que el sistema de software producido que cumple con
las especificaciones y que logra su cometido.
 Prueba el sistema una vez que se han probado los componentes
individuales y se han integrado, se prueba el sistema de forma global. En
esta etapa pueden distinguirse los siguientes tipos de pruebas, cada uno con
un objetivo claramente diferenciado: Pruebas funcionales.
 Pruebas de aceptación en ingeniería de software y pruebas de software, las
pruebas de aceptación pertenecen a las últimas etapas previas a la liberación
en firme de versiones nuevas a fin de determinar si cumplen con las
necesidades y/o requerimientos de las empresas y sus usuarios.

Pruebas no funcionales
Una prueba no funcional es una prueba cuyo objetivo es la verificación de un
requisito que especifica criterios que pueden usarse para juzgar la operación de
un sistema (requisitos no funcionales) como por ejemplo la disponibilidad,
accesibilidad, usabilidad, mantenibilidad, seguridad, rendimiento. Podemos
clasificar las pruebas no funcionales según el tipo de requisito no funcional que
abarcan:

 Pruebas de seguridad
 Pruebas de Stress
 Pruebas de rendimiento
 Pruebas de instalabilidad
 Pruebas de portabilidad

Pruebas de rendimiento son las pruebas que se realizan, desde una perspectiva,
para determinar lo rápido que realiza una tarea un sistema en condiciones
particulares de trabajo.

Prueba Stress una prueba de estrés evalúa el sistema sometiéndolo a

una carga creciente hasta que este falle. Esta prueba permitirá identificar cuellos
de botella “bottleneck” y conocer que carga es la máxima admitida por la aplicación
hasta que esta empieza a tener problemas de rendimiento.

Caja blanca

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la

estructura de control del diseño procedimental para derivarlos. Mediante la prueba
de la caja blanca el ingeniero del software puede obtener casos de prueba que:

 Garanticen que se ejerciten por lo menos una vez todos los caminos
independientes de cada módulo, programa o método.
 Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
 Ejecuten todos los bucles en sus límites operacionales.
 Ejerciten las estructuras internas de datos para asegurar su validez.

Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de
pruebas más importantes que se le aplican al software, logrando como resultado
que disminuya en un gran porciento el número de errores existentes en los
sistemas y por ende una mayor calidad y confiabilidad.

Caja Negra
Las Pruebas de Caja Negra, es una técnica de pruebas de software en la cual la
funcionalidad se verifica sin tomar en cuenta la estructura interna de código,
detalles de implementación o escenarios de ejecución internos en el software.
En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas
del sistema, sin preocuparnos en tener conocimiento de la estructura interna del
programa de software. Para obtener el detalle de cuáles deben ser esas entradas
y salidas, nos basamos en los requerimientos de software y especificaciones
funcionales.
Técnicas de Pruebas de Caja Negra
 Partición de equivalencias
 Análisis de valores borde
 Tablas de decisión
 Transición entre estados
 Pruebas de casos de uso

Pasos para elaborar el plan de pruebas

 1.- Analizar los requerimientos de desarrollo de software

Para elaborar un plan de pruebas de software lo primero que debes hacer

es entender los requerimientos de usuario que componen la iteración o
proyecto, que son el sujeto de la verificación de calidad que se va a realizar.

Deberás analizar toda la información de la ingeniería de requisitos,

incluyendo la matriz de trazabilidad, especificaciones y diseño funcional,
requisitos no funcionales, casos de uso, historias de usuario (si estás
trabajando con metodologías ágiles), entre otra documentación.

 2.- Identificar las funcionalidades nuevas a probar

A partir de la documentación del análisis de requisitos y de las entrevistas

con el equipo de ingeniería de requisito y desarrollo, debes identificar e
incluir en el plan de pruebas de software la lista de las funcionalidades
(Características) totalmente nuevas.

Si estás trabajando con un sistema informático nuevo, no tendrás

 problemas en discernir, pues todas serán nuevas.

En el caso de desarrollos de software integrados a un sistema existente es

necesario revisar con los analistas de negocio y también con los arquitectos
de software las funcionalidades que forman parte del desarrollo de
software, en todas las capas de la arquitectura.

 3.- Identificar las funcionalidades de sistemas existentes que deben

probarse

Se debe identificar las funcionalidades existentes que estén siendo

impactadas por el desarrollo de alguna forma, considerando todos los
componentes afectados en todas las capas de la arquitectura de software.

Existen dos situaciones que se puede encontrar al identificar estas

funcionalidades:

 Funcionalidades modificadas de cara al usuario: Por ejemplo si una

funcionalidad está siendo modificada agregando más pantallas o cambios a
su flujo de proceso, debe ser incluida en el plan de pruebas de software.
 Funcionalidades modificadas en sus componentes internos: Son
funcionalidades no modificadas de cara al usuario, manteniendo la misma
interfaz gráfica y flujo de procesos, sin embargo, si se modifican
componentes internos que comparten con otras funcionalidades del
sistema, en las capas de lógica de negocio o acceso a datos. Estas deben
incluirse en el plan de pruebas de software para determinar a partir de ellas
pruebas de regresión a realizar.

 4.- Definir la estrategia de pruebas

Consiste básicamente en seleccionar cuáles son los tipos de pruebas de
software que se deben realizar.

Es recomendable seguir un marco de referencia para determinar los tipos

de prueba, como por ejemplo los tipos de pruebas de software definidos por
el ISTQB.

Pruebas funcionales

Se determinan los conjuntos de pruebas a realizar, correspondiente con

cada funcionalidad nueva o existente que se esté modificando.

Se tienen distintos tipos de pruebas funcionales, por ejemplo, las pruebas

de sistema (o pruebas integradas de sistemas), que se realizan después
 que el equipo de desarrollo ha integrado los componentes de distintas
capas

 5.- Definir los criterios de inicio, aceptación y suspensión de pruebas

Criterios de aceptación o rechazo:

Para definir los criterios de aceptación o rechazo, es necesario definir el

nivel de tolerancia a fallos de calidad. Si la tolerancia a fallos es muy baja
puede definirse como criterio de aceptación que el 100% de los casos de
prueba estén sin incidencias. Lograr este margen en todos los casos de
prueba principales y casos borde será muy difícil, y podría comprometer los
plazos del proyecto (incrementa los riesgos), pero asegura la calidad del
producto.
Criterios de inicio o reanudación:

Definen las condiciones que deben cumplirse para dar inicio o reanudar las
pruebas. Por ejemplo, en el caso de inicio la condición podría ser la
instalación de los componentes de software en el ambiente y que los casos
de pruebas de verificación de ambiente sean exitosos.

Criterios de suspensión:

Las condiciones van a depender de los acuerdos de nivel de servicio

(SLAs) internos de la organización y también de los acuerdos establecidos
en cada proyecto individual.

 6.- Identificar los entornos (ambientes) requeridos

Posteriormente se definen y documentan las características de los entornos
de Hardware y Software necesarios para realizar la ejecución de las
pruebas de software.

Esta información se obtiene a partir del equipo de desarrollo y de los

arquitectos de software, quienes pueden suministrar los requisitos mínimos
y óptimos para la operación del sistema.

Como mejor práctica, el ambiente de pruebas de software debería ser lo

más similar posible al ambiente de producción, sin embargo, no siempre es
posible debido a limitaciones de recursos (financieros). En estos casos
debe estudiarse cuales son los requisitos que aseguran un mínimo de
confiabilidad de estas pruebas respecto al entorno de producción.
Referencias

pasos para elaborar el plan de pruebas. (2005, 5 agosto). Recuperado 17 septiembre,

2019, de http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html

El método de estudio de caso. (2006, 20 junio). Recuperado 17 septiembre, 2019, de

https://www.redalyc.org/pdf/646/64602005.pdf