ESTUDIO DE CASO

FASE 1 – PRELIMINAR

PRECIOUS JEWELS DIAMOND CENTERS

Precious Jewels Diamond Centers es una joyería especializada en diamantes y otras piedras

preciosas, que realiza encargos seleccionados por y para sus clientes. Las piedras preciosas se

engastan en anillos, pendientes y otras joyas. Precious Jewels también actúa como agente

comercial, y suministra piedras preciosas a otras joyerías y tiendas poseedoras de la oportuna

licencia. El envío de estas piedras preciosas se hace según aceptación previa. Las tiendas tienen

la opción de adquirir1as o de devolver1as.

Escena: Frank Bumside, un consultor de sistemas que trabaja para Precious Jewels, mantiene

una reunión con Jeff Kassels, vicepresidente de la empresa. Ambos discuten la posibilidad de

que Frank sea contratado por esta empresa para encargarse del desarrollo de mejoras en los

sistemas de información de sus microcomputadores IBM y Compaq.

Jeff: ¿Por dónde empiezo? Veamos, hace dos años decidimos comprar dos

microcomputadores. Por recomendación de la tienda de informática, también

adquirimos algunos paquetes de software.

Frank: ¿Qué paquetes?

Jeff: Excel, Paradox y Word para Windows. Por desgracia, no teníamos la formación

suficiente para aprovecharlos debidamente, en especial el de base de datos Paradox. Así

que contratamos a algunos estudiantes que sabían algo de computadores; tú

probablemente dirás que eran principiantes. Es verdad que no tenían mucha

experiencia.

Frank: ¿Y qué sucedió?

Jeff: Escribieron algunos programas en Paradox y varías macros en Excel para la gestión de

ventas y el control de inventarios. Aparentemente, los programas funcionaban.

Introdujimos gran cantidad de datos en el sistema, y obtuvimos varios informes. Más

tarde nos dimos cuenta de que necesitábamos hacer más informes y consultas.

Intentamos generarlas nosotros mismos, pero no conocíamos el funcionamiento del

gestor de informes de Paradox. Los estudiantes ya no estaban disponibles, de forma que

contratamos a una mujer que se encargó de hacer los programas en Paradox. Pero no

fue capaz de generar informes a partir de los datos. Yo sé que los datos están ahí,

porque nosotros los pusimos y porque aparecen en los informes originales. No puedo

comprender cómo es posible poder meter los datos y luego no ser capaces de volver a

recuperar1os.

Frank: No es un hecho infrecuente. Es, en realidad, bastante habitual. Los analistas sin

experiencia -mejor dicho, incluso muchos analistas ya experimentados- suelen diseñar

sistemas que responden a las necesidades del momento. Pero con ello cometen un fallo,

porque no se dan cuenta de que, más adelante, puede ser difícil o incluso imposible

adaptar la estructura de los datos almacenados ante el cambio permanente de las

situaciones y las necesidades. Probablemente, estos datos tienen una mala organización.

Los archivos informáticos deficientemente diseñados no son muy diferentes de los

archivos manuales mal diseñados.

Jeff: Aún no te he contado todo. Cada vez aparecen más problemas con los datos que están

dentro del sistema. Examinando los informes originales, puede verse que registros que

deberían haber sido borrados hace tiempo aún existen. Por ejemplo, he encontrado

registros de órdenes de compra de piedras preciosas que fueron saldadas y pagadas hace

un año. Para empeorar las cosas, también he visto registros para los que no he sido

capaz de encontrar una orden de compra. Necesito esa orden de compra para comparar

mis valoraciones y precios con las valoraciones y precios que cargué a mis

proveedores.

Frank: Es una situación típica de una base de datos mal diseñada. Antes de construir una base

de datos, hay que invertir mucho esfuerzo en comprender sus datos y las complejas

relaciones de empresa que se dan entre los diferentes conjuntos de datos. Hay que

intentar comprender cuándo es necesario crear los datos, cuándo hay que cambiarlos y

cuándo deben borrarse o mantenerse. Por ejemplo, supongo que tienes datos de tus

clientes. Seguro que nunca me pedirás que borrara clientes que tuvieran una facturación

importante, ¿no es así? Estudiando tus datos, podría llegar a conocer sus valores, sus

requisitos, sus necesidades y sus limitaciones acordes con las normas.

Jeff: ¿Puedo añadir nuevos campos a archivos ya existentes? La segunda consultora me dijo

que para ello tendría que reescribir muchos de los programas existentes.

Frank: Por desgracia, probablemente tiene razón. Mira, los archivos de datos están ligados

demasiado estrechamente a los programas que los usan. Los programas esperan datos

de archivos específicos. Si ahora te das cuenta de que necesitas datos que están en otros

archivos diferentes, habrá que modificar los programas originales para poder así reflejar

la nueva situación.

Jeff: ¿Me estás diciendo que es algo inevitable cuando se usan computadores? Si es así, me

parece que voy replantearme la idea desde el principio.

Frank: ¡Ni mucho menos! Los datos pueden estructurarse independientemente de los

programas que los usan. Es posible, y bastante fácil, reducir al mínimo la probabilidad

de tener que hacer modificaciones generales en los programas.

Jeff: Bien, ¿Pero cómo resolver este problema? Estoy sacando informes del sistema que

muestran datos que no coinciden entre sí. No entiendo cómo ha podido suceder.

Frank: Es otro fallo de diseño de la base de datos. Sospecho que muchos atributos de datos

están guardados de forma redundante en diferentes archivos. Cuando se guardan datos

en más de un sitio, aumenta la posibilidad de que se modifiquen en un lugar y se olvide

hacerla en otros. En consecuencia, pueden producirse conflictos entre los datos en

informes generados a partir de archivos diferentes. La redundancia de datos debería

reducirse al mínimo siempre que sea posible,

Jeff: Es muy interesante. Cuando diseñaron nuestro sistema, los estudiantes simplemente

tomaron asiento y empezaron a dibujar una especie de diagrama de flujo basado en los

informes que necesitábamos. Nunca tuvieron en cuenta la posibilidad de partir de los

datos en bruto.

Frank: Si piensas en ello, tiene bastante sentido. Si pudiera llegar a entender tus datos, ayudará

a mantener el control de dichos datos, capturarlos y organizarlos en una forma más

flexible y adaptable, verías que obtendríamos dos ventajas principales. Primero, que

serán capaces de generar los informes que precisan, y segundo, que siempre podrán

crear nuevos informes cuando lo necesiten. Después de todo, los datos habrían sido

capturados y almacenados en un formato flexible. Creo que aún podemos arreglar este

sistema. ¡Dame la oportunidad redemostrarte cómo!

FASE 2 – ANALISIS Y PROBLEMAS DETECTADOS

Se orienta a los estudiantes para que desarrollen posibles soluciones frente al caso y las

preguntas orientadas por responder frente al caso, posteriormente de la discusión se deben sacar

de los grupos de trabajo las mejores respuestas para posteriormente en mesa redonda con todo el

grupo se puedan socializar y llegar a un consenso.

Preguntas para discutir

1. ¿En qué se diferencia el enfoque de Frank para identificar las necesidades, del clásico

planteamiento “dime qué salidas quieres”?

2. En su opinión, ¿qué ventajas pueden obtenerse si se estudian los datos antes que las

necesidades de las salidas de un sistema y los requisitos de sus tratamientos?

3. Desde su punto de vista, ¿por qué los consultores -y muchos analistas con experiencia-

ignoran con tanta frecuencia, o no consideran del modo adecuado, las implicaciones futuras

de los sistemas que diseñan?

4. Identificar los problemas presentados en el caso identificando procesos que se pueden

mejorar y realizar en Modelo de bases de datos adecuado.

5. Con lo anterior mencionado proponga una solución tecnológica para la empresa, que de una

solución eficiente, eficaz y de calidad a todos los procesos y problemas de la misma.

FASE 3 – SOLUCIONES, CONCLUCIONES Y RECOMENDACIONES

Debido a que es trabajo colaborativo se debe hacer una buena consulta sobre los conceptos

debatidos y aquellos que salen de la actividad, de los cuales los más relevantes deben ser: bases

de datos, incluyendo los cuatro niveles de normalización y el desarrollo de un modelo entidad

relación adecuado para dar una solución inicial, lo que luego llevara a dar un mejor diagnóstico

y algunas recomendaciones de la actividad.

Se debe buscar identificar siempre las fuentes primarias de la cual se está extrayendo la

información y como esta incide en el normal desempeño de los procesos de la empresa.

Se debe buscar que la empresa pueda orientar y organizar las áreas involucradas en la misma

para que manejen la misma información y que se puedan organizar

Finalmente con todas las opiniones y los acuerdos por parte de todo el grupo se dan

recomendaciones de solución al problema planteado con el objetivo de llegar a acuerdos

fundamentados en los conceptos técnicos teóricos, orientando las acciones a desarrollar en el

desempeño que nos permitan llegar a una solución con un producto más real y que resuelva las

necesidades de la empresa, sea con un software nuevo o con el arreglo del existente.

RUBRICA DE EVALUACIÓN.

INDICADORES

Criterios Superior– 100% Básico – 50% Bajo 1 – 0%

Ideas y

Contenido

El escrito es claro,

enfocado e

interesante. Mantiene

la atención del lector.

El tema o historia

central se enriquece

con anécdotas,

conocimientos

técnicos y detalles

relevantes.

El escrito es claro y

enfocado; sin embargo, el

resultado general puede no

captar la atención. Hay un

intento por sustentarlo,

pero puede ser limitado,

irreal, muy general o fuera

de contexto

El escrito esta desordenado

carece de una idea central o

propósito. El lector se ve

forzado a hacer inferencias

basándose en detalles muy

incompletos.

Organización La organización

resalta y focaliza la

idea o tema central.

El orden, la estructura

o la presentación

compromete y mueve

al lector a lo largo del

texto.

El lector puede inferir lo

que va a suceder en la

historia, pero en general,

la organización puede ser

en algunos casos

inefectiva o muy obvia.

La organización es casual y

desarticulada. La escritura

carece de dirección, con

ideas, detalles o eventos que

se encadenan unos con otros

atropelladamente.

Manejo

Conceptual.

El problema aparece

directamente al lector

en forma directa,

expresiva y que lo

compromete con el

relato. El escritor se

involucra

abiertamente con el

texto y lo escribe para

ser leído.

El escritor parece sincero,

pero no está

completamente

involucrado en el tema. Se

deben hacer ajustes

conceptuales. El resultado

es ameno, aceptable y a

veces directo, pero no

compromete.

El escritor parece

completamente indiferente,

no involucrado o

desapasionado. Como

resultado, la escritura es

plana, sin vida, rígida o

mecánica. Y dependiendo

del tema, resulta

abiertamente técnica o

incoherente.

Resolución de

los problemas

y/o preguntas.

Las palabras

transmiten el mensaje

propuesto en forma

interesante, natural y

precisa, suscita el

debate y búsqueda de

soluciones a la luz de

los conocimientos del

lector. La escritura es

completa y concisa.

El lenguaje es totalmente

corriente, pero transmite el

mensaje. Es funcional,

aunque carece de

efectividad.

Frecuentemente, el

escritor decide por

comodidad o facilidad de

manejo, producir una

especie de “documento

genérico”, colmado de

frases y palabras

familiares.

El escritor hace esfuerzos

con un vocabulario

limitado, buscando a ciegas

las palabras que transmitan

el significado.

Frecuentemente, el lenguaje

es tan vago y abstracto o tan

redundante y carente de

detalles, que solamente el

mensaje más amplio y

general llega a la audiencia.