Causa y efecto

1. Identificar el problema. El problema (el efecto generalmente está en la forma de una

característica de calidad) es algo que queremos mejorar o controlar.

El problema deberá ser específico y concreto: incumplimiento con las citas para

instalación, cantidades inexacta en la facturación, errores técnicos en las cuentas de

proveedores, errores de proveedores. Esto causará que el número de elementos en el

Diagrama sea muy alto (consultar la ilustración).

2. Registrar la frase que resume el problema. Escribir el problema identificado en la parte

extrema derecha del papel y dejar espacio para el resto del Diagrama hacia la izquierda.

Dibujar una caja alrededor de la frase que identifica el problema (algo que se denomina

algunas veces como la cabeza del pescado).

3. Dibujar y marcar las espinas principales. Las espinas principales representan el input

principal/ categorías de recursos o factores causales. No existen reglas sobre qué

categorías o causas se deben utilizar, pero las más comunes utilizadas por los equipos son

los materiales, métodos, máquinas, personas, y/o el medio. Dibujar una caja alrededor de

cada título. El título de un grupo para su Diagrama de Causa y Efecto puede ser diferente

a los títulos tradicionales; esta flexibilidad es apropiada y se invita a considerarla.

4. Realizar una lluvia de ideas de las causas del problema. Este es el paso más importante

en la construcción de un Diagrama de Causa y Efecto. Las ideas generadas en este paso

guiarán la selección de las causas de raíz. Es importante que solamente causas, y no

soluciones del problema sean identificadas. Para asegurar que su equipo está al nivel

apropiado de profundidad, se deberá hacer continuamente la pregunta Por Qué para cada

una de las causas iniciales mencionadas. Si surge una idea que se ajuste mejor en otra

categoría, no discuta la categoría, simplemente escriba la idea. El propósito de la

herramienta es estimular ideas, no desarrollar una lista que esté perfectamente

clasificada.

5. Identificar los candidatos para la “causa más probable”. Las causas seleccionadas por el

equipo son opiniones y deben ser verificadas con más datos. Todas las causas en el

Diagrama no necesariamente están relacionadas de cerca con el problema; el equipo

deberá reducir su análisis a las causas más probables. Encerrar en un círculo la causa(s)

más probable seleccionada por el equipo o marcarla con un asterisco.

 POCA SEÑALIZACION
FALTA DE DENTRO DEL ALMACEN
INFORMACION DEL
PERSONAL

OPERACIONES DEL
ALMACEN ERRATICAS

PROCESOS POCO
TIEMPOS LARGOS CLAROS
DE ESPERA
2. Diagrama de flujo:

El diagrama de flujo o diagrama de actividades es la representación gráfica del algoritmo o

proceso. Se utiliza en disciplinas como programación, economía, procesos

industriales y psicología cognitiva.

En Lenguaje Unificado de Modelado (UML), es un diagrama de actividades que representa

los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema.
Un diagrama de actividades muestra el flujo de control general.

En SysML el diagrama ha sido extendido para indicar flujos entre pasos que mueven elementos

físicos (p. ej., gasolina) o energía (p. ej., presión). Los cambios adicionales permiten al diagrama
soportar mejor flujos de comportamiento y datos continuos.

Estos diagramas utilizan símbolos con significados definidos que representan los pasos del

algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio
y de fin del proceso.
Diagrama de Flujo Aplicado a la Implementación del Software dentro de la Empresa.

INICIO

PROCESO DE
INTERNAMIENTO DE
PRODUCTOS

SE
IMPLEMENTO
SISTEMA
AGROLIVO

 Respuestas rápidas a requerimientos

del almacén
 Control de los Productos (aceitunas,
materia prima, insumo, etc.)
 Balances Reportes inmediatos.
 Demora en atención a proveedores y clientes.
 Constantes actualización de inventario de
forma manual, pérdida de tiempo de RRHH.
 Informes, balances y reportes duplicados,
imprecisos y con cifras erróneas.

 Imagen de la Empresa fortalecida al

contar con Sistemas que Brinden
información precisa y de forma rápida.
 Consolidado de información financiera
en el momento para la toma de
decisiones.
 Imagen poco atractiva para Clientes y
Proveedores.
 Problemas con las Finanzas Consolidadas de
la Empresa.
 Falta de información para la toma de
Información.

FIN
3. Checklist:

El checklist es una herramienta que se presenta en forma de preguntas que se responden de forma

binaria: lo tiene o no lo tiene, sí o no, si es necesario se puede habilitar un apartado de

comentarios.

La lista de verificación es una de las formas más objetivas de valorar el estado de aquello que se

somete a control. El carácter cerrado de las respuestas proporciona esta objetividad, pero también

elimina información que puede ser útil porque no recoge todos los matices, detalles y
singularidades.

El checklist se puede utilizar para evaluación, control, análisis y verificación. En el caso del
proyecto Nueva Cepa se implementará en la evaluación de los proveedores, para realizar controles

de los insumos adquiridos (si cumplen con los requisitos solicitados) y en los controles durante el
proceso de producción del vino.

A continuación se presenta la lista modelo a emplear en el control de calidad de la uva durante el

proceso de recepción.

Las “listas de control”, “listas de chequeo”, “check-lists” u “hojas de verificación”, son formatos

creados para realizar actividades repetitivas, controlar el cumplimiento de una lista de requisitos

o recolectar datos ordenadamente y de forma sistemática. Se usan para hacer comprobaciones

sistemáticas de actividades o productos asegurándose de que el trabajador o inspector no se

olvida de nada importante.

Los usos principales de los checklist son los siguientes:

 Realización de actividades en las que es importante que no se olvide ningún paso y/o

deben hacerse las tareas con un orden establecido.

 Realización de inspecciones donde se debe dejar constancia de cuáles han sido los puntos

inspeccionados.

 Verificar o examinar artículos.

 Examinar o analizar la localización de defectos. Verificar las causas de los defectos.

 Verificación y análisis de operaciones.

 Recopilar datos para su futuro análisis.
En definitiva, estas listas suelen ser utilizadas para la realización de comprobaciones rutinarias y

para asegurar que al operario o el encargado de dichas comprobaciones no se le pasa nada por
alto, además de para la simple obtención de datos.

La ventaja de los checklist es que, además de sistematizar las actividades a realizar, una vez

rellenados sirven como registro, que podrá ser revisado posteriormente para tener constancia de
las actividades que se realizaron en un momento dado.

Es importante que las listas de control queden claramente establecidas e incluyan todos los

aspectos que puedan aportar datos de interés para la organización. Es por ello preciso que quede
correctamente recogido en la lista de control:

 Qué tiene que controlarse o chequearse.

 Cuál es el criterio de conformidad o no conformidad (qué es lo correcto y qué lo incorrecto).

 Cada cuánto se inspecciona: frecuencia de control o chequeo.

 Quién realiza el chequeo y cuáles son los procedimientos aplicables.

Conviene, por último, que se disponga de un apartado de observaciones con el fin de poder obtener
información previa sobre posibles motivos que han causado la disconformidad.

Por otro lado, si vamos a usar los check lists para la obtención de datos, también se pueden utilizar

para construir gráficas o diagramas para controlar la evolución de una característica o actividad.

También se utilizan para reportar diariamente el estado de las operaciones y poder evaluar la

tendencia y/o dispersión de la producción, sin que sea necesaria la realización de estadísticas o
gráficas de mayor complejidad.
4.- PRUEBAS DE SOFTWARE

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas

cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto
a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software.

Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier

momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así

como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las
actividades de desarrollo.

 Pruebas estáticas

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código.

Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo de seguir los
flujos de la aplicación.

 Pruebas dinámicas

Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.

Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor

amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible medir con

mayor precisión el comportamiento de la aplicación desarrollada.

5.- CAJA BLANCA

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas

estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está

fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos valores de entrada
para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se
devuelven los valores de salida adecuados.

Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las
pruebas también deberán rediseñarse.

Aunque las pruebas de caja blanca son aplicables a varios niveles (unidad, integración y sistema),

habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de

ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden probar los

flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de
sistema.

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos

de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes,
pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Las principales técnicas de diseño de pruebas de caja blanca son:

 Pruebas de flujo de control

 Pruebas de flujo de datos

 Pruebas de bifurcación (branch testing)

 Pruebas de caminos básicos

6.- CAJA NEGRA

En teoría de sistemas y física, se denomina Caja Negra a aquel elemento que es estudiado desde

el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en

cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma

de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían

ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por

tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir,
su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.
7.- PRUEBAS UNITARIAS

En programación, una prueba unitaria es una forma de comprobar el correcto funcionamiento de

una unidad de código. Por ejemplo en diseño estructurado o en diseño funcional una función o un

procedimiento, en diseño orientado a objetos una clase. Esto sirve para asegurar que cada unidad

funcione correctamente y eficientemente por separado. Además de verificar que el código hace lo

que tiene que hacer, verificamos que sea correcto el nombre, los nombres y tipos de los

parámetros, el tipo de lo que se devuelve, que si el estado inicial es válido entonces el estado final
es válido

La idea es escribir casos de prueba para cada función no trivial o método en el módulo, de forma

que cada caso sea independiente del resto. Luego, con las Pruebas de Integración, se podrá
asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

Características

Para que una prueba unitaria tenga la calidad suficiente se deben cumplir los siguientes requisitos:

 Automatizable

No debería requerirse una intervención manual. Esto es especialmente útil

para integración continúa.

 Completas

Deben cubrir la mayor cantidad de código.

 Repetibles o Reutilizables

No se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil
para integración continua.

 Independientes

La ejecución de una prueba no debe afectar a la ejecución de otra.

 Profesionales
 Las pruebas deben ser consideradas igual que el código, con la misma profesionalidad,
documentación, etc.

Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o
de lo contrario las pruebas pierden parte de su función.

Ventajas

El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes

individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer.
Estas pruebas aisladas proporcionan cinco ventajas básicas:

 Fomentan el cambio

Las pruebas unitarias facilitan que el programador cambie el código para mejorar su

estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer

pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido
errores.

 Simplifica la integración

Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que

el código está funcionando correctamente. De esta manera se facilitan las pruebas de

integración.

 Documenta el código

Las propias pruebas son documentación del código puesto que ahí se puede ver cómo
utilizarlo.

 Separación de la interfaz y la implementación

Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son

las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro,

a veces usando objetos mock(mock object) para simular el comportamiento de objetos

complejos.

 Los errores están más acotados y son más fáciles de localizar

 Dado que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones

Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del

código. Algunos enfoques se basan en la generación aleatoria de objetos para amplificar el alcance

de las pruebas de unidad.1 Esta técnica se conoce como testing aleatorio (RT, por random testing).

Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de

integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su

conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede

recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si
se usan en conjunto con otras pruebas de software.