1. ESTUDIO PRELIMINAR.

Existente Critica Nuevas soluciones u orientaciones.

Tiene una triple misin: - Estudiar la situacin actual para conocer la estructura y las funciones del organismo. - Hacer crticas si hay lugar y proponer la las soluciones !ue ser"n orientadas hacia la automati#acin. - $efinir las orientaciones nuevas !ue permitir"n decidir o no la automati#acin. El Estudio %reliminar re!uiere varias competencias para el analista programador: o &a T'cnica de gestin de %royectos (supervisar) planificar) coordinar el tra*a+o en grupo., o &a T'cnica de comunicacin (colecta de informacin) entrevistas) relacin de informes) comprender el tra*a+o del usuario., o &a T'cnica del -n"lisis (especificaciones funcionales y t'cnicas y las modelisaciones., o .tras competencias (/elacin) creatividad) an"lisis de costes) o*+etividad,

1.1. Estudio de lo existente.

-ntes de entrar al estudio preliminar se puede constituir un grupo de estudio seg0n la importancia del proyecto. Normalmente ese e!uipo est" formado por un usuario) un analista programador y un organi#ador. Tam*i'n se puede) seg0n la importancia del proyecto) esta*lecer un planning provisional) *asado en los o*+etivos o entidades manipuladas en la empresa. 1e ocupa pues de los datos y procedimientos a utili#ar. 1e de*e determinar la informacin a recoger para no llevar la colecta en desorden.

1.1.1.Determinacin de la informacin a recavar.

&as actividades (datos) entidades) relacin., &os o*+etivos (los o*+etivos de la organi#acin del proyecto., El funcionamiento (los flu+os de informacin., &os procedimientos de gestin (reglas de gestin y de organi#acin., &as estructuras y los puestos (les organigramas de organi#acin y los concernidos., &os ficheros existentes (soporte) talla, &a codificacin utili#ada (formali#ar los cdigos, &a seguridad (accesos) puestos) documentacin) ficheros., &as contiendas de funcionamiento (utilidades) periodicidad, &os medios de tratamiento.

1.1.2.Recogida de informacin.
Existen dos m'todos a seguir en la recogida de informacin: 1.1.2.1. Por evento. 1e estudia el recorrido de un evento desde su entrada en el sistema hasta su salida) determinando las tareas en cada puesto. E+emplo: 2n *ono de pedido llega al correo y pasa al responsa*le del servicio) !uien a su ve# da o no su visto *ueno3 si el visto *ueno es dado) el pedido es registrado en la secretaria y transmitido al almacenista. Esta prepara la Entrega3 prepara el 4ono de Entrega !ue enva al /esponsa*le de 1ervicio. 1e da la orden de extender una factura a la secretaria. En este m'todo se preocupa del - 56u'7 (descripcin de la accin,) - 5por !u'7 (ra#n de ser78,) - 5$nde7 (lugar de la accin,) 56ui'n7 (puestos implicados,) 5Cu"ndo7 (fecha y secuencias,) - 5Cmo7 (medio de tratamiento,) - 5Cu"ntos7 (e+emplares) n0mero de tratamientos elementales.,

-n"lisis: &a venta+a de este m'todo es !ue permite la construccin progresiva del diagrama de circulacin de informacin) su inconveniente es !ue se recorre tantas veces los puestos disponi*les.

ii

1.1.2.1.

Por puestos (extraccin)

1e hace un inventario de los puestos concernidos por la aplicacin se estudia por puestos el con+unto del tratamiento de entrada y salida) y enlaces de tratamiento efectuado. El inconveniente de este m'todo es !ue dificulta la construccin de un diagrama. T'cnicas propuestas: El 9ntervi0 (entrevista directa, %reparar el intervi0 (seg0n el punto anterior, Elegir los interlocutores. :i+ar citas.

$urante la entrevista: El presentador recuerda *revemente el o*+etivo. %edir el tiempo a consagrar %recisar si se desea tomar notas o registrar con una gra*adora) y si los resultados le ser"n transmitidos. Estar seguro de si mismo con respecto al su+eto. ;irar a los o+os al interlocutor sin instancias ni agresiones. 1a*er dar preguntas (evitar preguntas comprometedoras) *rutales y molestas, /eplicar algunas veces las respuestas del interlocutor para asegurarse de su exactitud. /espetar a tolerancia el tiempo.

-l final de la entrevista se concluye) se agradece al interlocutor y se fi+a la prxima cita si es necesario. $e vuelta) preparar el informe y enviarlo al interlocutor para pedir su confirmacin. &a o*servacin: 1e fi+amos varias veces so*re el o*+eto. %ara grandes cantidades de informacin se pueden ela*orar formularios de preguntas !ue ser"n rellenados por el usuario) a ser posi*le apoyado por un facultado de la impresa y determinar una fecha limite de entrega. 1.1.3. Anlisis de lo existente. &a informacin recavada es sometida a estudio minucioso resaltando los datos principales y la manera de tratarlos) *"sicamente en lo siguiente:

iii

1acar las reglas de gestin y diagnostico. <e+emplo: = factura concierne a = cliente y a = solo cliente3 si el importe de la factura es >? a =@.@@@ aplicar reduccin del AB 8C Tra#ar un diagrama de flu+os de informacin. Tra#ar un diagrama de circulacin de informacin.

E+emplo:

Diagrama de flujos de informacin.

iv

1.2. Modelisacin Conceptual.

1.2.1. Modelisacin Conceptual de Tratamiento (MCT.

Es un modelo de ;E/91E !ue se sit0a en el Nivel Conceptual permite un estudia del tratamiento !ue se producir" en el interior del /eal %erci*ido *a+o este alcance de detalles especiales temporales. El ;CT descri*e las acciones llevadas en la empresa por el dominio estudiado) respuestas y soluciones a las cuales de*e hacer frente y !ue +ustifica su ra#n de ser.

Conceptos utili#ados:

2n evento3 es un hecho activo !ue) solo o en com*inacin con otro) detona el tratamiento. &a sincroni#acin (s, es una condicin *ooleana de asociacin de eventos. &a operacin es un con+unto de tareas regidas por las reglas de gestin) de las cuales la e+ecucin no necesita intervencin en el transcurso del tiempo real de otros eventos. 2na regla de emisin (/=) /D) 8, es una regla !ue permite decidir los resultados de la emisin. El con+unto de las reglas de gestin de estar completo.

vi

2n resultado es lo !ue emana de una operacin. Nota: un resultado puede ser un evento u otra operacin. 1e le llama Evento 9nterno. 2n evento externo no emana de un tratamiento. 2na cadena de operaciones !ue tratan un su+eto relativamente ligado se le llama %roceso. %uede ser engendrado por varios eventos externos.

1.2.2. Mecanismo de concepcin del MCT. Tra#ar el gr"fico de flu+os y o diagrama de circulacin de informacin (un flu+o es un movimiento de informacin o documento) de un puesto a otro. Esta*lecer las reglas de gestin. /esaltar del grafico o diagrama los procesos a es!uemati#ar (una aplicacin puede estar compuesta de varios procesos,. .rdenar los flu+os del proceso. Tra#ar el ;CT de cada proceso recordando el hecho de !ue cada flu+o es un evento. 1in em*argo hay !ue eliminar los tratamientos redundantes. 9nformar la sincroni#acin a partir de las reglas de gestin.

.*servacin: %ara las grandes aplicaciones se puede ela*orar primero un ;CT glo*al (donde las operaciones son los procesos, antes de pasar al ;CT detallado. E+emplo de un ;CT: %roceso de facturacin.

vii

viii

Eerificacin del ;CT. No se pasa de un evento a otro o de una operacin a otra. 2n proceso siempre de*e ser detonado por evento externo. 2n evento externo no es resultado de una operacin externa. 2n evento interne es siempre resultado de una operacin interna. 2na sincroni#acin de*e estar siempre reali#ada. No de*e ha*er situaciones conflictivas. El ;CT no tiene un ciclo. Toda operacin del ;CT de*e ser alcan#a*le.

1.2.3. Modelizacin Conceptual de Datos (MCD). En esta modeli#acin lo !ue interesa es la sem"ntica de los datos) es decir) el sentido atri*uido a los datos en relacin a la aplicacin estudiada. El ;C$ permite al reali#ador del sistema esa sem"ntica para poder organi#ar el almacenamiento adecuado de los datos. Fa !ue cuanto me+or est'n organi#ados los datos) me+or ser" se explotacin) mas ptimos ser"n los programas !ue los manipulen) mas corto ser" el tiempo invertido en la programacin) mas slidos y mas evolutivos ser"n las aplicaciones reali#adas. .*servacin: =. &os datos) constituyendo la parte m"s esta*le del sistema) ya !ue las empresas de una misma rama de actividades manipulan los mismos datos. %or tanto pueden ha*er diferentes tratamientos seg0n sus reglas de gestin. D. En el proceso de modeli#acin se adopta el enfo!ue 4-1E $E $-T.1 como !ue varias aplicaciones necesitan los mismos datos funcionen con ellas. G. Existen varios tipos de ;odelos de datos3 a. ;odelo Her"r!uico *. ;odelo /ed c. ;odelo /elacional. El ;C$ se esta*lece a partir del /eal %erci*ido. &a fuente de inspiracin es el gr"fico de flu+o) la documentacin) las reglas de gestin) para o*tener un diccionario de datos) poner en evidencia las entidades y las relaciones) as coma las propiedades y las cardinalidades.

ix

Conceptos utili#ados:

Entidad-tipo: En una nocin concreta o a*stracta perteneciente al real perci*ido !ue se refiere a un o*+eto con relacin al cual se van a registrar los datos. 2na entidad dispone siempre de una clave (= o varios campos !ue caracteri#an un registro,. 1i la clave es %rimaria) entonces es 0nica. &a cave puede ser 1ecundaria o I9mportadaJ) (en tal caso) no es for#osamente 0nica.,

/elacin: Es un vnculo definido entre dos o m"s entidades !ue se expresan por una regla con+ugada o norma.

%ropiedad: Es un tipo de dato elemental !ue caracteri#a una entidad o una relacin) (!ue mas tarde se llamar" campo,.

Cardinalidad (m)n,: En una relacin cada Cardinalidad +uega un papel. 1e de*e esta*lecer por cada entidad el n0mero mnimo y m"ximo de ocurrencias con relacin a la clase.

Nota: - veces surgen fuerzas de una integridad funcional cuando una relacin de Cardinalidad es =----N. El conocimiento de una entidad determina el conocimiento de la otra.

E+emplo de ;C$. :ig. K

;ecanismo de modeli#acin. 1e mencionan tres t'cnicas: ;odeli#acin $irecta: (4uena para los experimentados,. $urante la exposicin de recogida de informacin se toman notas y documentos a partir de los cuales se identifican directamente las entidades y las relaciones para tra#ar directamente el ;C$. ;odeli#acin %r"ctica: 1e apoya so*re el diagrama de flu+o) la documentacin de entrada o de salida) el sentido de propiedad (detectado los sinnimos y los polimorfismos, para esta*lecer un diccionario de datos. E+emplo de un diccionario de datos. Nom*re del dato Numero de cliente %recio unitario :echa de la factura :actura pagada Nom*re sim*lico NumClient %2 :echa:actura Estado:actura Tipo -nchura L (M, N (N, $ (O, lgico /egla de c"lculo.

1e ponen de manifiesto las dependencias funcionales entre las propiedades (esta operacin es facultativa,.

xi

1e tra#a un ;C$ *ruto. Nota: En la pr"ctica es aconse+a*le limitar lo m"ximo posi*le la dimensin de las relaciones en dos) ya !ue cuanto mas grande) difcil ser" su mane+o. Eerificacin del ;C$. =. &as propiedades no de*en repetirse. D. Cada propiedad depende funcionalmente de la clave. G. 1olo de*e existir una ocurrencia en cada una de las entidades.

1.3. Critica del xistente. El estudio de la Crtica del Existente no se hace por modeli#acin) sin em*argo) permite determinar las Nuevas .rientaciones !ue ser"n tomadas en cuenta por las Nuevas 1oluciones. &as crticas dependen pues del -nalista. 1e de*en determinar las anomalas dentro del sistema existente) *uscar su puestos ($iagnosticar, a fin de esta*lecer soluciones nuevas. ;'todo: =. Tra#ar un inventario de las anomalas constatadas. %uede concernir los puestos de tra*a+o) los documentos) los circuitos de informacin. D. Esta*lecer un diagnstico por estudio) de las acusas posi*les (cualificacin del personal) mala organi#acin del tra*a+o) estrangulamiento) etc., E+emplo de anomalas: =. El control por validacin de un 4ono de pedido toma un largo tiempo. D. Este control es parcial. Causas: =. El tratamiento manual. Hace falta tiempo para informarse so*re la cuenta del cliente. D. El 1tocP no se puede consultar en el momento del control. 1.3.1. !ue"as #rientaciones. $espu's del estudio del Existente se dan orientaciones hacia las nuevas soluciones) guiados por los diagnsticos esta*lecidos. E+emplo: =. El control de un 4ono de pedido con la ayuda de un ordenador. D. &a factura de*e ser extendida por la secretaria) y la imputacin del *ono de li*ramiento por el almacenista. 1.3.2. !ue"as $oluciones. xii

1e pueden proponer varias soluciones) pero se elegir" la me+or *asando en los criterios tales como3 la simplicidad) la puesta en o*ra) la fia*ilidad y constancia) es decir) caracteri#adas por3 =. &as funciones de imputacin) las funciones de almacenamiento) las funciones de tratamiento) las funciones de difusin de salidas) los modos de tratamiento) tra#ar si es posi*le el escenario ilustrando los puestos de tra*a+o en ordenador. E+emplo de solucin: a. Tres puestos de tra*a+o ($C) 1C) -&, conectados en red local. &as consultas ser"n donde el $C ($irector Comercial,) las imputaciones de pedidos se har"n donde la 1C (1ecretaria, y la ela*oracin de las factura) donde el -& (-lmacenista., *. 2n solo puesto de tra*a+o en la 1ecretara. &as consultas se hacen para informar al $C. En caso de !ue el 4% (*ono de pedido, sea correcto) la secretaria transmite una copia al almacenista despu's de la imputacin) !uien actuali#a el stocP y emite una factura. Esta solucin parece la me+or) ya !ue es simple y menos costosa. Nota: - veces es posi*le las criticas del existente !ue engendran nuevas soluciones) donde se est' o*ligado a *uscan el ;CT o ;C$ para un ;CT o ;C$ nuevos. %ero generalmente no da el caso) su impacto permite precisar el modelo lgico u organi#acional (;.T o ;&$,.

xiii