Metodologa e Ingeniera de Software I

Caso Estudio Prctico

PCTECNO S.A.
1. Introduccin
1.1. Descripcin General de la Empresa
PCTECNO S.A. es una empresa de venta y montaje de ordenadores (PCs). Desde su creacin en 1995 su
volumen de trabajo ha crecido de forma considerable. En los primeros tiempos construan computadoras para
vender a particulares y pequeas empresas, pero actualmente construyen PCs que posteriormente sern
vendidos en grandes superficies comerciales distribuidas por todo el pas. Su volumen de fabricacin actual es
de unos 600 PCs por semana.
La empresa posee un almacn en el que guarda la gran cantidad de componentes (tarjetas, HDDs, cajas, etc.)
que proceden de pedidos a los fabricantes de Hardware. La gestin de este almacn es la parte ms compleja
del sistema.
Por un lado, se realizan pedidos de componentes a proveedores (fabricantes como Quantum, Creative, etc) que
cuando se reciben se dan de entrada en el almacn. Por otro lado, los componentes almacenados se utilizarn
en la construccin de PCs. Estos PCs son ensamblados por los operarios de la empresa, que trabajan en los
talleres. Los PCs, a su vez, sern almacenados para su posterior distribucin y venta (al por mayor,
exclusivamente).
El almacn se encuentra a unos 15 Km. de los talleres de ensamblaje, lo cual supone un inconveniente tanto a la
hora de comunicarse como a la de trasladar los componentes y los PCs ya construidos.
1.2. Organizacin de la empresa
La empresa se compone de los siguientes departamentos:
- Direccin: Toma las decisiones principales que afectan al funcionamiento de la empresa.
- Departamento de Compras: Trata con los proveedores y realiza los pedidos. Est situado en las oficinas
principales de la empresa.
- Departamento de Ventas: Trata con los clientes y recibe sus pedidos. Est situado en las oficinas principales de
la empresa.
- Almacn: Guarda los componentes y los PCs. Est situado a 15 Km. de las oficinas principales de la empresa.
- Talleres: Lugar donde los operarios ensamblan los ordenadores. Est situado en el mismo edificio que las
oficinas principales de la empresa.
2. Obtencin de Requerimientos del Sistema
2.1. Planteamiento del Sistema
Para automatizar la gestin comercializacin, la empresa a decidido desarrollar el Sistema Informtico
denominado TecnoComercial. Su funcionamiento y requerimientos se describen a continuacin:
Gestin de Pedidos de Clientes
Situacin actual
Los clientes de la empresa son, en general, grandes empresas. Actualmente, la lista de clientes se maneja de
forma semi-manual, por medio de hojas de clculo. Cuando se recibe un pedido (normalmente por correo
convencional, pero tambin a travs del telfono o el fax) el Departamento de Ventas se pone en contacto con el
responsable del almacn. ste confirma si hay o no existencias de los PCs solicitados por el cliente. Este ltimo
proceso est sujeto a muchos errores y problemas, pues el almacn no funciona con la rapidez y precisin que
seran deseables. Finalmente, el responsable del almacn se encarga de gestionar el envo de los PCs al cliente,
por medio de las camionetas propiedad de la empresa.

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

Los pedidos que hacen los clientes (grandes superficies) no son de uno o dos PCs sino de lotes de entre 20 y
100 ordenadores, segn la temporada. Por ello la empresa dispone de una flotilla de camiones y camionetas
para realizar el transporte de los PCs desde el almacn hasta el lugar solicitado por el cliente.
Las configuraciones bsicas de los PCs son impuestas por la direccin de la empresa, y los clientes solicitan
PCs de acuerdo con estas configuraciones prefijadas (o sea, no se hacen PCs a medida del cliente). Para cada
configuracin, se establecen una serie de parmetros bsicos (tipo CPU, velocidad CPU, capacidad RAM,
capacidad disco, etc.). Evidentemente, esto complica el proceso, pues a la hora de responder a los pedidos,
debera contarse con existencias suficientes de los componentes requeridos. Igualmente, el almacenaje de los
PCs debera realizarse segn configuraciones similares, para evitar bsquedas prolongadas por el almacn
hasta dar con los PCs requeridos.
El principal problema del mtodo de trabajo actual es que muchas veces no se puede responder a los pedidos
de los clientes debido a mltiples razones, como pueden ser las siguientes:
- No se conoce con total precisin la disponibilidad de ordenadores en el almacn.
- Los constructores de ordenadores no pueden prometer con exactitud cuantos ordenadores estarn listos para
una determinada fecha, porque, entre otras cosas, no conocen con precisin la disponibilidad de componentes
en el almacn.
- Actualmente, la comunicacin con el almacn deja mucho que desear, pues se utiliza el fax y el telfono.
Requisitos
El sistema deber proporcionar la operacin de creacin de pedidos de clientes (alta de pedidos) y su
facturacin correspondiente. Durante la creacin de pedidos, se desea que el sistema proporcione informacin
actualizada acerca de los PCs que se encuentran en el almacn, diciendo qu PCs se encuentran reservados
para su venta y cuales no.
Se desea tambin poder predecir con cierta exactitud la satisfaccin de los pedidos realizados por los clientes.
Por ejemplo, si un determinado cliente solicita 70 PCs y stos no se encuentran en existencias, mediante la
informacin que proporcione el sistema debera ser posible determinar si disponemos de material suficiente o no
para construir los 70 PCs. Si se dispone de este material, entonces dicho pedido podr ser servido al cabo de un
tiempo y los componentes afectados podran ser marcados como "reservados" (para que no sean utilizados en la
construccin de otro PC). Si no se dispone del material, el cliente debera reducir el nmero de PCs de su
pedido.
El jefe de ventas requiere que le llegue la informacin diaria de los pedidos realizados y la facturacin realizada.
La gerencia requiere que le lleguen informes semanalmente sobre los pedidos y el nivel de ventas realizadas por
el rea.
Gestin del Almacn
Situacin actual
La gestin actual del almacn resulta extremadamente ineficiente y esto afecta absolutamente a todas las reas
de la empresa. Algunas de las carencias detectadas son:
- Debido a la distancia y a los problemas de comunicacin con el almacn (por telfono), no es posible conocer,
con detalle y en tiempo real, el stock actual del almacn. Como consecuencia, no es posible predecir con
exactitud si se podrn dar salida a los pedidos pendientes de servir.
- La ubicacin en el almacn de los componentes y de los PCs no se encuentra optimizada. De hecho,
actualmente se encuentran mezclados componentes con PCs a lo largo y a lo ancho del almacn, con las
consiguientes ineficiencias que se producen tanto en el proceso de recepcin de mercancas como en su
posterior envo.
- Existen numerosos tiempos no productivos debido a la falta de automatizacin del proceso de solicitud de
reposiciones de material. Igualmente, los empleados encargados del montaje de los ordenadores no reciben
puntualmente la informacin relacionada con la disponibilidad de materiales, provocando retrasos innecesarios
en su trabajo (a veces, con graves repercusiones, pues los clientes estn esperando algn pedido)
- Se producen demasiados errores relacionados con la ubicacin de los componentes y de los productos (PCs)
en el almacn.

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

- La carencia de informacin en tiempo real provoca que a veces se consideren como ocupados algunos sitios
(huecos) libres, y viceversa, provocndose as inexactitudes acerca de la capacidad actual del almacn.
Requisitos
Con la construccin del nuevo sistema se pretende solucionar, dentro de lo posible, los problemas descritos. La
implantacin del sistema nuevo exigir, no obstante, una nueva estructuracin de la superficie del almacn. En
concreto, el almacn se dividir en dos secciones: una para almacenar componentes y otra para almacenar los
PCs ya construidos. La seccin de componentes se dividir en zonas, y cada zona almacenar exclusivamente
un tipo de componentes (tarjetas grficas, placas base, etc.). La seccin de PCs se dividir en zonas
correspondientes a distintos equipos (una zona para equipos basados en Pentium III 400, otra para los basados
en Pentium III 500, etc.).
Tanto para componentes como para PCs, cada zona se dividir en columnas y las columnas se dividen en
alturas. La combinacin de una seccin, una zona, una columna y una altura se denomina "hueco", y puede
estar vaco o contener uno o varios objetos (componentes o PCs, segn el caso). En las recepciones de material
(si se quiere que esta organizacin del almacn sirva realmente para algo) los componentes recibidos sern
adecuadamente etiquetados y almacenados en su lugar correspondiente. Se darn de alta en el sistema,
indicando tipo de componente, fecha de llegada y ubicacin en el almacn, entre otros datos. El sistema
proporcionar a los empleados del almacn la informacin acerca de qu huecos se encuentran libres segn el
tipo de componente que se vaya a almacenar.
La jefatura requiere que se le informe diariamente sobre las diferentes salidas de productos (por envos) y
entradas (por recepciones de los pedidos de compra) del almacn.
Gestin de Envos
Situacin actual
Igualmente, el proceso de agrupacin de mercancas (PCs) para ser enviadas a un cliente, no est libre
de errores e ineficiencias. Por un lado, se necesitan agrupar juntos una serie de ordenadores (20 como
mnimo, pero a veces 250 o 300) para cargarlos en los camiones. Este proceso se vera optimizado si
los ordenadores estuvieran situados cerca del muelle de carga del almacn, lo cual no siempre es as.
Lo que resulta ms grave es que se cometen muchos errores debido a que la configuracin de los
ordenadores solicitados no es la misma que la de los ordenadores enviados. Esto provoca que muchos
envos sean rechazados por el cliente.
Requisitos
El sistema deber responder a consultas acerca de qu PCs en stock corresponden a un
determinado pedido de un cliente y emitir la correspondiente gua de remisin referente al pedido del
cliente a entregar. La gua debe registrar el medio de transporte y fecha con el cual se enva.
Gestin de Compras a Proveedores
Situacin actual
Los proveedores de la empresa son conocidos fabricantes de Hardware, a quienes se les compran versiones
OEM (Original Equipment Manufacturer) de sus productos. Lo ms complejo de la gestin de pedidos es la
coordinacin entre unos pedidos y otros: No tiene sentido, por ejemplo, realizar pedidos de forma que se
acumulen N tarjetas grficas por un lado y N/20 placas base por otro. Lo ideal es que siempre se disponga en el
almacn de cantidades equilibradas de componentes. Por esta razn, la coordinacin entre el Departamento de
Compras y la gestin del almacn es crucial.
Actualmente lo que se hace es intentar comprobar el stock existente de un determinado componente antes de
pedir otra cantidad. En primer lugar, el operario que necesita el material se pone en contacto con el responsable
del almacn para que ste compruebe las existencias de los componentes que el operario necesita. La
comprobacin de las existencias es absolutamente manual. El responsable del almacn mantiene una lista (en
una hoja de clculo) de los componentes existentes, pero hay tantos errores e inconsistencias que cada mes es
necesario reinventariar todo (lo cual es una tarea engorrosa, que consume demasiado tiempo, y tampoco est
libre de errores). Adems, la comunicacin con el almacn es por fax o por telfono, lo cual no siempre es

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

demasiado eficiente. A veces, un operario se ha visto obligado a retrasar su trabajo en espera de un componente
que necesitaba, cuando en realidad dicho componente se encontraba en el almacn.
En el supuesto de que los componentes solicitados por el operario no se encuentren en el almacn, el operario
se pondr en contacto con la Direccin de Compras, y sta realizar el pedido al proveedor correspondiente. La
Direccin de Compras mantiene una pequea base de datos de proveedores, y los pedidos los realiza por medio
de un procesador de textos. A veces se ha enviado el mismo pedido dos veces a un proveedor, pues casi no hay
control de qu pedidos han sido, o no, realizados.
Requisitos
Los pedidos a proveedores se introducirn a travs del sistema, para su registro y posterior emisin. Esto implica
que el sistema debe proporcionar ayuda en las siguientes tareas:
- Registro de proveedores
- Registro de pedidos de compra
Durante la creacin de pedidos de compra, el sistema proporcionar informacin sobre la cantidad de
componentes en stock, con idea de realizar pedidos ajustados a las necesidades futuras de fabricacin. De cara
a planificar la construccin de PCs, adems, no se debe tan slo proporcionar informacin acerca de qu
componentes se encuentran en el almacn, sino tambin qu componentes se espera recibir en un determinado
plazo de tiempo.
La jefatura requiere mensualmente el nivel de compras realizadas por proveedor.
Recepcin de Mercancas
Situacin actual
El proceso de recepcin de la mercanca solicitada a los proveedores es, actualmente, muy deficiente.
Se supone que cuando se reciben los componentes solicitados, deberan ser almacenados en sus
lugares correspondientes. Actualmente esto no se hace as, pues ni siquiera la superficie del almacn se
halla lo suficientemente ordenada en secciones para distintos tipos de componentes y/o PCs ya
construidos. A veces, en una tarde, se reciben tres o cuatro pedidos a la vez, con lo cual, lo que se hace
actualmente es almacenarlos en el primer sitio a la vista.
Esto provoca, a la larga, una irregular distribucin de los componentes por todo el almacn, con
inmensas dificultades a la hora de intentar localizarlos.
Requisitos
Se espera que el sistema proporcione informacin actualizada acerca de la ocupacin real del almacn
y de los pedidos que se espera recibir. Esto permitira a los empleados del almacn planificar por
adelantado las recepciones, de forma que los componentes recibidos queden adecuadamente
clasificados.
2.2. Funciones de Alto Nivel del Sistema
As pues, las funciones de alto nivel del sistema TECNO Comercial, que en este caso pueden ser consideradas
subsistemas, son las siguientes en su primera versin:

Gestin de Pedidos de Clientes

- Atencin de pedidos
- Facturacin de pedidos
- Envo a clientes
Gestin de Almacn
- Manejo de inventario
- Recepcin de mercadera
- Distribucin de productos en almacn
Gestin de Compras a Proveedores

2.3. Modelamiento Funcional DFDs

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

2.3.1.

Modelo de Contexto

Esquema Pictogrfico del Sistema

Tabla de Eventos del Sistema

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

Diagrama de Contexto

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

2.3.2.

Diagrama Cero

2.3.3.

Diagrama por Niveles

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

1. Gestionar Ventas

2. Realizar Envos

3. Gestionar Almacn

4. Realizar Compras

5. Preparar Informes de Gestin

2.4. Diccionario de Datos (DD)

Ing. Christian Araujo Gonzlez

Metodologa e Ingeniera de Software I

2.4.1.

Flujos de Datos
De Entrada
Datos de pedido =
Datos de pago =
Datos recepcin pedido =
Datos transporte =

De Salida
De las tcnicas de recopilacin: revisin de documentos se puede tener el sgte documento:

Factura = nro_factura + fecha + nom_clte + direc_clte + ruc +

cantidad + sub_total } + total + igv + total_pagar

{ cod_prod + desc_prod+ Precio_unit +

Pedido concretado =
Gua de remisin =
Informe atencin pedido =

2.4.2.

Ficheros
Facturas = { nro_factura + fecha + nom_clte + direc_clte + ruc + {cod_prod + desc_prod+ Precio_unit +
cantidad + sub_total } + total + igv + total_pagar }
Pedidos =
Productos =
Componentes =
Pedidos Compra =

Ing. Christian Araujo Gonzlez

10

Metodologa e Ingeniera de Software I

2.4.3.

Procesos Elementales

1. Gestionar Ventas
1.1. Concretar pedido cliente
Inicio
RECIBIR datos pedido (codigo_dado y cantidad_dada)
MIENTRAS no sea final del fichero DE productos
SI datos pedido (codigo_dado) = codigo_producto DE productos
RECUPERAR datos del producto DE productos
SINO mensaje: " producto no existe"
MIENTRAS no sea final del fichero DE configuraciones
SI datos pedido (codigo_dado) = codigo_producto DE configuraciones
RECUPERAR datos de configuracion DE configuraciuones
SINO mensaje: " Del producto no existe configuracion"
GUARDAR datos pedido EN pedidos
EMITIR datos pedido COMO pedido concretado
Fin.
1.2. Preparar informacin de atencin pedido

1.3. Facturar pedidos

1.4. Preparar informe pedidos realizados

1.5. Preparar informe de facturacin.

1.6. Actualizar configuraciones de producto

1.6.1. Determinar tipo actualizacin
Inicio
RECIBIR datos configuracin
Opcion = opcion de datos configuracion
SI opcion DE datos configuracion ES Registro
ENVIAR datos configuracion a registro
SI opcion DE datos configuracion ES Modificacion
ENVIAR datos configuracion a cambio
SI opcion DE datos configuracion ES Eliminar
ENVIAR datos configuracion a eliminar
Fin.
1.6.2.

Registrar una configuracin

Inicio
RECIBIR datos configuracion para registro
REGISTRAR datos configuracin para registro
MOVER al final DE configuraciones
GRABAR datos configuracion para registro EN configuraciones
Fin.

Ing. Christian Araujo Gonzlez

11

Metodologa e Ingeniera de Software I

1.6.3.

Modificar una configuracion

Inicio
RECIBIR datos configuracion para cambio
MIENTRAS diferente Final Archivo DE configuraciones
SI datos configuracion para cambio (codigo_cambio) = codigo_configuracion
EDITAR datos configuracion DEL codigo_configuracion
SINO
EMITIR mensaje:" Dato Configuracion NO existe "
GRABAR configuracion para cambio EN configuraciones
Fin.

1.6.4.

2.

3.

4.

5.

Eliminar una configuracin.

Realizar Envos
2.1.
2.2.

Gestionar Almacn
3.1.
3.2.

Realizar Compras
4.1.
4.2.

Preparar Informes de gestin

5.1.
5.2.

2.5. Modelamiento de Datos

Hacer algunas normalizaciones de los FLUJOS DE DATOS DE SALIDA y FICHEROS
Tomamos:
Factura = nro_factura + fecha + nom_clte + direc_clte + ruc +
cantidad + sub_total } + total + igv + total_pagar

{ cod_prod + desc_prod+ Precio_unit +

normalizarlo a la 3FN:
Paso 1:
Determinar claves o identificadores
Factura = nro_factura + fecha + nom_clte + direc_clte + ruc +
cantidad + sub_total } + total + igv + total_pagar

Ing. Christian Araujo Gonzlez

{ cod_prod + desc_prod+ Precio_unit +

12

Metodologa e Ingeniera de Software I

Paso 2:
Eliminar los atributos calculables
Factura = nro_factura + fecha + nom_clte + direc_clte + ruc +
cantidad }

{ cod_prod + desc_prod+ Precio_unit +

Paso 3:
Realizar la 1FN (eliminar grupos repetitivos)
Factura = nro_factura + fecha + nom_clte + direc_clte + ruc + { cod_prod + desc_prod+ Precio_unit +
cantidad }
Sale:
R1 = nro_factura + fecha + nom_clte + direc_clte + ruc
R2 = nro_factura + cod_prod + desc_prod+ Precio_unit + cantidad
Los nombres cambia a:
Factura = nro_factura + fecha + nom_clte + direc_clte + ruc
Detalle Factura = nro_factura + cod_prod + desc_prod+ Precio_unit + cantidad
Paso 4:
Realizar la 2FN (eliminar dependencia funcional)
Factura = nro_factura + fecha + nom_clte + direc_clte + ruc (esta en 2FN)
Detalle Factura = nro_factura + cod_prod + desc_prod+ Precio_unit + cantidad
Sale:
Detalle Factura 1 = nro_factura + cod_prod + cantidad
Detalle Factura 2 = nro_factura + cod_prod + desc_prod+ Precio_unit
Los nombres cambia a:
Detalle Factura = nro_factura + cod_prod + cantidad
Producto = cod_prod + desc_prod+ Precio_unit
Paso 5:
Realizar la 3FN (eliminar dependencia transitiva)
Factura = nro_factura + fecha + nom_clte + direc_clte + ruc
Sale:
Factura 1 = nro_factura + fecha
Factura 2 = nom_clte + direc_clte + ruc (podemos agregar cod_clte)
Factura 2 = cod_clte + nom_clte + direc_clte + ruc
Los nombres cambia a:
Factura = nro_factura + fecha
Cliente = cod_clte + nom_clte + direc_clte + ruc

Ing. Christian Araujo Gonzlez

13

Metodologa e Ingeniera de Software I

queda:
Factura = nro_factura + fecha
Cliente = cod_clte + nom_clte + direc_clte + ruc
Detalle Factura = nro_factura + cod_prod + cantidad
Producto = cod_prod + desc_prod+ Precio_unit
Su DER es:

Tomamos :
Pedido, su DER sale:

Hecho todos integrarlos en un solo DER.

Ing. Christian Araujo Gonzlez

14

Metodologa e Ingeniera de Software I

Anexos
Documentacin recopilada:

Ing. Christian Araujo Gonzlez

15

Metodologa e Ingeniera de Software I

Ing. Christian Araujo Gonzlez

16