CALIDAD EN EL DESARROLLO DE SOFTWARE

ACTIVIDAD 3

La empresa SoftSena, especializada en desarrollo de software, ha sido requerida por

una clínica de salud, la cual ha presentado el requerimiento de desarrollar un sistema de
información tradicional (de escritorio), donde se registren los medicamentos
entregados a los pacientes, los formulados por los médicos y los que se compran a
los proveedores.

De igual forma la empresa requiere conocer el estado de inventario de los

medicamentos por laboratorio. El sistema debe permitir generar todos los reportes
necesarios de acuerdo a los requerimientos diarios, semanales y mensuales. Por tal
motivo, se solicita la asesoría de un profesional en este campo.

El grupo técnico para la construcción del proyecto ya está conformado. Sin embargo, se
enfrenta a la decisión de escoger el modelo de software que orientará el diseño y
construcción y a su vez, las pruebas a aplicar, según el modelo del ciclo de vida del
software escogido.

1. Evidencie el modelo, según el ciclo de vida escogido.

El modelo escogido fue el Modelo extreme Programming (XP) porque es una

metodología ágil, se basa en realimentación continua entre el cliente y el equipo de
desarrollo, comunicación continua entre todos los participantes, simplicidad en las
soluciones implementadas y facilidad para enfrentar los cambios.

Esta metodología nos permitirá desarrollar el software que necesita la entidad

hospitalaria, y que por estar enfocada en la parte de salud denota una gran
responsabilidad por ende la Metodología XP, nos brindará las herramientas necearías
para conseguir los mejores resultados con la calidad que amerita.
 Metodología XP – Programación Extrema

Diseño simple Tarjetas

CRC
Historias del usuario

Valores PLANIFICACIÓ DISEÑO

Criterios de pruebas de adaptación N
Pruebas unitarias Soluciones en Punto
Plan de iteración Integración Continua
Rediseño Prototipos

CODIFICACIÓ
LANZAMIENT PRUEBAS
N
O Programación por parejas
Incremento del software Velocidad Pruebas de adaptación
calculada del proyecto

Para cumplir con los requerimientos establecidos se realizará un sistema de escritorio,

dividido en módulos llamado “Sistema de Información de Salud” (SIS), que permitan
dividir las tareas a realizar y que a su vez puedan ejecutarse de forma individual pero
que trabajen de forma integrada basados e la misma información. El primer módulo será
el de administración, Contratación, Medicamentos e Insumos, Proveedores, Historia
Clínica y Enfermería. Todos estos módulos manejaran la información de una base de
datos integrada llamada BDSIS y una BD de pruebas llamada PBDSIS.

2. Determine alcance de la prueba.

Para el plan de pruebas de este proyecto se pretende detectar errores desde el mismo
inicio del desarrollo y secuencialmente retroalimentar e ir resolviéndolos, aplicando
todas las pruebas en cada una d las fases.
La prueba de software tiene limitantes, tanto teóricos como prácticos. Desde el punto de
vista teórico, la prueba es un problema que llamamos no-decidible; esto implica, grosso
modo, que no podemos escribir un programa que pruebe los programas sin intervención
humana. Sin embargo, como mencionábamos anteriormente, la prueba sí es
automatizable en muchos aspectos.
Desde el punto de vista práctico, la cantidad de posibilidades para probar
exhaustivamente un sistema es sencillamente inmanejable; es necesario entonces utilizar
técnicas adecuadas para maximizar la cantidad de fallas importantes encontradas con los
recursos asignados. A continuación, mostraremos un resumen de pruebas.

Módulos a ser Probados Módulos:

Administración

Contratación Medicamentos e Insumos

Proveedores Historia Clínica Enfermeria.

Objetivos de la Prueba Visualización de datos ingresados o
modificados. La operación de los servicios
confeccionados para dar respuesta a los productos del
sistema SIS.

Las respuestas y realización de las transacciones de

cada módulo.

Que los estados de las actividades y documentos

generados en el sistema se reflejen de acuerdo a la
secuencia lógica

requerida por el usuario.

La secuencia lógica de las funcionalidades y

transacciones.
Detalles de Orden de Los módulos para su primera ejecución se debe Abrir
ejecución de los módulos el módulo de:

1. Administración

2. Contratación

3. Proveedores

4. Medicamentos e insumos

Seguidamente podrá abrir cualquiera de los módulos

en el orden que lo desee.
 Historia Clínica y Enfermería

Después de la primera ejecución, los módulos podrán

actuar de forma individual sin ningún problema sin
dejar de estar integrados en un mismo sistema
Responsabilidad de la Las pruebas son responsabilidad del Testing
Prueba Operacional del equipo de proyecto, quien en conjunto
con el usuario deben seleccionar las pruebas que
aseguren la efectividad del sistema.

3. Relacione los tipos de prueba a aplicar.

Continuamente se han de efectuar una serie de pruebas automatizadas en base a los

requisitos del cliente para comprobar que todo funcione correctamente. Éstas han de
hacerse de forma periódica y automática.

Con las planificaciones comentadas anteriormente se incluyen las entregas al final de

cada iteración, éstas serán siempre con el software probado y funcionando
correctamente y será facilitado al cliente, que puede utilizarlo para cualquier propósito,
incluso para el usuario final. Los tipos de pruebas a realizar son:

 Pruebas de unidad: En las pruebas de unidad o unitarias, se evalúa el

funcionamiento individual de cada módulo, escribiendo casos de prueba

Para cada funcionalidad o método en el módulo, de forma que se determine

La integridad del mismo (Mayorga & Arce, 2013, p.32).

 Pruebas de integración: Las pruebas de integración pretenden verificar que el

conjunto de los módulos de un sistema funciona adecuadamente Mayorga y
Arce, 2013). Están orientadas a: 1. Identificar errores introducidos por la
combinación de programas probados unitariamente; 2. Verificar que las
interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan
correctamente; 3. Probar que las especificaciones de diseño sean alcanzadas y 4.
Determinar el enfoque para avanzar desde un nivel de integración de los
componentes siguientes (Abad, 2005).
 Prueba de humo: Su propósito se focaliza en probar el sistema constantemente
buscando que saque “humo” o falle. En algunos proyectos, este tipo de prueba
va junto con las pruebas funcionales. Permite detectar problemas que por lo
regular no son detectados en las pruebas normales. Algunas veces, si las pruebas
ocurren en etapas tardías, esta será una forma de garantizar el buen desarrollo.
Las pruebas de humo no son exhaustivas, pero van de extremo a extremo de la
aplicación (Abad, 2005).

 Pruebas de validación a sistemas a la medida Abad (2005), comenta que

deberá presentarse un listado de pruebas de validación a aplicaciones a sistemas
a la medida, las cuales están orientadas a la validación del funcionamiento de
software a la medida del modelo de negocio.

 Prueba de GUI o interfaz: Por medio de esta prueba se verifica la interacción

del usuario con el software. El objetivo será asegurar que la interfaz presente una
adecuada navegación por medio de diferentes funcionalidades. Además, permite
asegurar que los objetos de la interfaz que se van a adoptar, se encuentren dentro
de estándares de la industria. Prueba de configuración: Con este tipo de pruebas
se puede verificar la operación del sistema en diferentes configuraciones de
hardware y software. Las especificaciones para las estaciones de trabajo, equipos
de red y servidores, pueden presentar variaciones en la mayoría de los ambientes
de producción.

 Prueba de estilo: Comprueba que la aplicación sigue los estándares de estilo

propios del cliente, tales como el formato de las ventanas, colores corporativos,
tipos de letra, entre otros.

 Prueba de aceptación: Esta prueba está destinada a confirmar que el producto

está listo para el uso operativo, Suele ser un subconjunto de las pruebas de
sistema y se ejecuta antes de que la aplicación se instale dentro de un ambiente
de producción. Su ejecución se realiza por parte del cliente, o por un especialista
de la aplicación.

 Prueba de instalación: Está orientada a verificar y validar que el sistema se

instale apropiadamente en cada computador de cliente, bajo estas condiciones:

 Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el

sistema.
  Actualizar máquinas previamente instaladas con el sistema.

 Instalar versiones viejas en máquinas previamente instaladas con el sistema.

Prueba funcional: Prueba orientada a garantizar el análisis apropiado de los requisitos

funcionales, incluyendo la navegación, entrada de datos, procesamiento y obtención de
resultados. En tal sentido, este tipo de pruebas se focalizan en los requisitos funcionales,
pueden estar basadas directamente en los casos de uso, funciones y reglas del negocio.

Prueba de documentación: y procedimiento Se focaliza en evaluar la exactitud y

claridad de la documentación del usuario y determina si el manual de procedimientos
trabajará correctamente como parte integral del sistema.

Prueba de usabilidad: Su objeto está orientado a determinar la usabilidad del sistema.

En tal sentido, busca medir qué tan fácil el usuario podrá usar y entender la aplicación,
tratando de identificar las áreas de diseño que dificultan el uso del sistema por parte del
usuario.

Prueba de campo: Esta prueba está orientada a ejecutar el sistema en un ambiente real
para encontrar errores y validar el producto contra sus especificaciones originales. En
tal sentido, determina las pruebas de sistema que serán corridas para validar el sistema
en producción.

4. Analice estrategias de pruebas.

Se requiere certificar por parte del equipo de desarrollo y por parte del usuario al
producto SIS – Sistema de Información en Salud, en dos etapas, que administre y
gestione los Medicamentos e insumos aplicados a los pacientes. Por ende, se debe
verificar:

 1ra. Etapa: Que las funcionalidades de los módulos de Administración,

Contratación, Proveedores y Medicamentos e Insumos que son los que

Deben ser ejecutados en su orden para ir alimentándolos con la información

Necesaria para el funcionamiento de los demás módulos

 2da. Etapa: Que las funcionalidades integradas de los módulos sean capaces de
funcionar individualmente y cumplir los requerimientos.

Conjuntamente los sub-objetivos para los 6 módulos se resumen de la siguiente forma:

 La creación e ingreso, edición y actualización de los datos de la entidad

(Razón social, identificación, código de habilitación, etc). ✓ La creación, ingreso,

edición, modificación y eliminación de usuarios, prestadores, estancias, pacientes, etc

La creación, ingreso, edición, modificación y eliminación de medicamentos e Insumos.

 la visualización, modificación y eliminación del datos administrativos y

actividades se generen su estado correspondiente en el sistema.

Será necesario indicar como objetivo realizar las pruebas de los módulos para la gestión
y administración de los Medicamentos e insumos aplicados a los pacientes.
Esto se refiere a verificar y validar los resultados o salidas generados. Un objetivo
importante es la utilización de técnicas formales de prueba del software

Especificación: Este tipo de prueba incluye probar la aplicación en contra de la

documentación que se hizo antes, por ejemplo, que los procesos concuerden con los
algoritmos hechos a papel, o que la aplicación tenga todas las funciones que se habían
planeado.

Usabilidad: Este tipo de prueba se refiere a asegurar de que la interfaz de usuario (o

GUI) sea intuitiva, amigable y funcione correctamente.
Unidad: Este tipo de prueba solo aplica a proyectos grandes. Se divide el proyecto a
unidades y cada unidad es sometida a prueba individualmente.

Integración: Prueba varias unidades juntas para asegurar que funcionen bien. También
se asegura de que las nuevas aplicaciones se integren con aplicaciones antiguas o
aplicaciones complementarias.

Regresión: Esta prueba incluye todas las pruebas anteriores en caso de que se le haga
algún cambio a algún modulo después de haber sido puesto en ambiente de producción.

Verificación y validación: La prueba del software es un elemento de un tema más

amplio que suele denominarse verificación y validación.
 Verificación: Es el conjunto de tareas que garantizan que el software implementa
correctamente una función específica
¿Estamos construyendo el producto correctamente?
 Validación: Es un conjunto diferente de actividades que aseguran que el software
que se construye sigue los requerimientos del cliente ¿Estamos construyendo el
producto correcto?

La prueba alfa: es conducida por Un administrador del sistema, un Médico, una

enfermera y un paciente en el lugar de desarrollo. Se usa el software de manera natural,
con el encargado de desarrollo “mirando por encima del hombro” del usuario” y
registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno
controlado, que simule la implementación del sw.

La prueba beta: se lleva a cabo en uno o más lugares de clientes por los usuarios
finales del software. A diferencia de la prueba alfa, el encargado de desarrollo,
normalmente, no está presente. La prueba beta es una aplicación “en vivo” del software
(En la entidad hospitalaria) en un entorno que no puede ser controlado por el equipo de
desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra y
los informa a intervalos regulares. Como resultado, el equipo de desarrollo lleva a cabo
modificaciones y así prepara una versión del producto para toda la base de clientes.

5. Exponga criterios de salida y los aspectos anexos que considere necesario

tener en cuenta.
Entre las partes involucradas en el proceso, se define de manera formal, bajo qué
condiciones se puede considerar que una actividad de pruebas fue finalizada. Los
criterios de salida se deben definir para cada nivel de pruebas a ejecutar. Algunos
ejemplos de criterios de salida que pueden ser utilizados son: porcentaje de
funcionalidades de alto riesgo probadas con éxito, número defectos críticos y/o mayores
aceptados, etc.
Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una
estimación de tiempos, los roles y/o recursos que harán parte del proceso, la preparación
del entorno de pruebas, cronograma base, etc.

Orden de ejecución de pruebas

Las pruebas se llevarán a cabo de la siguiente forma:

Secuencias de pasos para la Configuración

1. Configuración de los Equipos Cliente y del Servidor de Aplicación de escritorio

y de Base de Datos.

Secuencias de pasos para la generación de archivos para los 6 módulos. 1. Ejecución de

proceso (manual) de generación de archivos de entrada con la información de la entidad,
contratación, proveedores, medicamentos e insumos, pacientes y usuarios para alimentar
al sistema SIS y la base de datos BDSIS.
Secuencias de pasos para la generación de datos para los 6 módulos.

1. Ejecución del proceso (manual) de generación de datos, donde las tablas y

campos a utilizar serán llenados manualmente (Datos de la entidad, Proveedores,
usuarios y Contratos) en forma masiva (pacientes).