Tesis La Automatizacion de Los Procesos de Produccion en La Empresa

5/8/2018 Tesis La Automatizacion de Los Procesos de Produccion en La Empresa

1/73

SIEFREN RAIMUNDO MENDEZ PANAME~rO

LA AUTOMATIZACION DE LOS PROCESOS DEPRODUCCION EN LA EMPRESA

---- universidad -FRANCISCO MARROQUINFacultad de Ingenierfa de Sistemas,Informatica y Ciencias de la Cornputaclon

GUATEMALA, 2001


2/73

ESTA TESIS FUE ELABORADA POR EL AUTORCOMO REQUISITO PREVI0 A OPTAR EL TiTULODE LICENOADO EN ADMINISTRAOON DESISTEMASDE INFORMAOON

GUATEMALA, OCfUBRE DE 2001


3/73

UNlVERSIDAD FRANCISCO MARROQUINFACULTAD DE INGENIERIA DE SISTEMAS,INFORMATICA Y CIENCIAS DE LA COMPUTACION

Guatemala, 10 de Mayo de 1999

SenorS ie fr en R ai mu nd o M en de z P an am en oPresente.-

E st im ad o s en or M en de z:

Tengo mucho gusto en informarle que ha sido autorizadosu punto de Tesis, prevf,o a optar al grado academi.co deLicenciado en Administracibn de Sistemas de Informacibn,cuyo titulo es "La Automatizacibn de los Procesos de Pro-duccibn en la Bmpr e sa'".Al mismo tiempo Ie informo que ha sido aprobada la desig-nacibn de la Ingeniera Deiffy Morales de Lima como aseso-ra de su trabajo de graduBcibn.

Atentamente,

FACULTAD DE INGENIERIA DE SISTEMAS,INFORMATICA Y CIENCIAS DE LA COMPUTACION

Calle Dr. Eduardo Suger Cofiiio (7a. calle), Edificio Dr. Manuel F. Ayau, FISICCZona 10, Guatemala, Centro America

Telefonos 362-2723 331-4948 - Fax: 331-1645


4/73

Guatemala, 12 de octubre de 2001

DoctorEduardo Suger COMODecano de la Facultad de IngenieriaDe Sistemas, Informatica y Ciencias de la Computaci6n

Estimado Doctor Suger:De acuerdo a la supervision y revision final del trabajo de tesis ,,; La

automatizaci6n de los procesos de producci6n en Ia empresa" , desarrolladapOt: Siefren Raimundo Mendez Panameiio , considero que cumple con losrequisitos exigidos por esta Facultad.

Por 1 0 anteriormente expuesto, someto a usted, en mi calidad de asesor, elpresente trabajo para su aprobaci6n.

Atentamente,


5/73

UNIVERSIDAD FRANCISCO MARROQUINFACULTAD DE INGENIERIA DE SISTEMAS,INFORMATICA Y CIENCIAS DE LA COMPUTACION

Guatemala , 12 de O ctubre de 2001

DoctorE duardo S ug er C ojiiioDecano de l a Facu lt ad de Ingenieriade Sistemas. Informatica y Cienciasde fa C om pu tacio nDo cto r S ug er :P or este medio , me permito comunicarle que le i fa tests de el alum na StefrenRaimundo M endez Panameiio , came I-593264, titu lada "LA AUTOM Al1ZAC ION D E

LOS PROCESOS DE PROD uceION EN LA FMPRESA ", a se so ra da p ar e l In ge nie raDeiffy Ama rilis M o ra les F lo resDespues de r ev is ar la d e ten id ameme y de hacer las recomendaciones pettinentes, enm i calidod de revisor a de r ed ac cio n ; e sttlo y ortog ro fia , le com unico que dtcha tesisllena los requisito s que exig e taUniverstdad:M e suscribo del Senor D ecano , com o su atenta y s eg ur a s er vid or a.

AJlllbv

c.c.Archivo


6/73

UNIVERSIDAD FRANCISCO MARROQUINFACULTAD DE INGENIERIA DE SISTEMAS,INFORMATICA Y CIENCIAS DE LA COMPUTACION

Guatemala, 12 de octubre de 2001

SenorSiefren Raymundo Mendez PanamefioPresenteEstimado senor Mendez:Tengo mucho gusto en informarle que, despues de haber revisado su trabajo de Tesis, cuyo tituloes "La Automatizacien de los Procesos de Produccion en la Empresa", y de haber obtenidoel dictamen del asesor espeeifieo, autorizo la publicacion del mismo.Aproveeho la oportunidad para felieitarlo por el magnifico trabajo realizado, el eual es deindiscutible beneficio para el desarrollo de las Ciencias de Computaci6n en Guatemala.

Atentamente,TAD DE INGENIERIA DE SISTEMAS,CA Y CIENCIAS DE LA COMPUTACION

ESC/edec.-

7a. avenida final (Calle Dr. Eduardo Suger Cofifio). Zona 10, Edificio Dr. Manuel F. Ayau. Guatemala. CPlanta FISICC: 331-4948' 362-2725 331-4807 360-1893 332-2033 .. Fax: 331-1645


7/73

Dedicado aDiosa mi esposa Maria Hortensia

a mis hijos Mario Fernando y SiefrenJosue


8/73

OBJETIVOS

E l presente trabajo tiene como objeto el llevar los conocmuentosnecesanos para que el empresario 0 estudiante de carreras deingenierias 1 0 utilice como un manual de referencia en laimplementaci6n de la automatizaci6n en los procesos de producci6nen los medios industriales yempresariales.

Que el estudiante de las carreras de Ingenieria y Licenciatura enAdministraci6n de Sistemas de Informaci6n posean una herramientade consulta bibliogcifica.

Demostrar que los conocimientos adquiridos en la carrera deLicenciatura en Administraci6n de Sistemas de Informaci6n sonaplicables en la industria y la empresa.


9/73

INDICEPagina

IntroduccionCapitulo I1. La empresa 41.1 Tipos de empresas 41.2 Sistemas de produccion 5

1.2.1 Sistema de distr ibucion 51.2.2 Sistema de produccion-distribucion de gran volumen 51.2.3 Sistema de intermitente 51.2.4 Sistema de proyecto en gran escala 61.2.5 Intercambio de costo 6

1.3 Disefio del producto y seleccion del proceso 61.3.1 Proceso 61.3.2 Planificacion de la produccion 71.3.3 Retroalimentacion 71.3.4 Control de posicion 71.3.5 Control de contomo 81.3.6 Procesos quimicos 81.3.7 Procesos para modificar, configurar 0vaciar 81.3.8 Proceso de transportacion 91.3.9 Los procesos de oficina y los sistemas de informacion 9

Capitulo II2. Formas de efectuar los anllisis de requerimientos 102.1 Determinacion de requerimientos 102.2 Planificacion del anllisis de requerimientos en un problema

espacio temporal 112.2.1 Identificacion yanllisis de los requerimientos de in-

tegracion en problemas espacio-temporales 112.2.1.1. Anllisis de aplicaciones espacio-temporales 112.2.1.2.Categorizacion de planificaciones espacio-

temporales 112.2.1.3. Caracterizaci6n de los sistemas de software

y tecno logias existentes 122.2.1.4. Definici6n yespecificaci6n de los requeri-

mientos de integraci6n en la s diferentescategor ias de planificaciones espacio -temporales 12

2.2.2 Disefio de metodologias de integraci6n y sistemasDe software heterogeneo en dominios espacio-temporales 122.2.2.1.Anllisis de esfuerzos exitosos de integracion en

diferentes disciplinas 0dominios 122.2.2.2.Definici6n y evaluacion de modelos 0estrategiasde integracion 13

2.2.2.3.Selecci6n de un modelo 0estrategia de integracionmediante la evaluaci6n de prototipos 13

2.2.2.4.Diseiio de la estructura de la metodologia ydefinicion de sus etapas, fases,pasos y actividades 13

2.2.2.5.Diseiio de tecnicas de integracion para el apoyo al a s distintas fases y pasos de la metodologia 14


10/73

2.2.3 Desarrollo de sistemas de apoyo a 1aintegracion de softwareheterogeneo 142.2.3.1.Especificacion y disefio de 1aarquitectura del sistema

integrador de software heterogeneo 142.2.3.2.Diseno del sistema integrador de software hetero-

geneo 152.2.3.3.O:>dificacion de componentes del sistema integra-

dor de software heterogeneo 152.2.3.4.Pruebas del software desarrollado 15

2.2.4 Aplicacion de los resultados a casos rea1esy analisis deresultados obtenidos 162.2.4.1.Seleccion definitiva de casos reales de aplicacion 162.2.4.2.O:>nstruccion de las aplicaciones se1eccionadas

usando el sistema de software heterogeneo 162.2.4.3.Evaluacion de resultados 162.2.4.4.Finalizacion del plan de trabajo 16

2.3 Metodo de agruparniento de procesos padre - hijo 172.4 Procesos lineales 192.5 Analisis de eventos 192.6 Analisis de requerimientos organizacionales 20Capi tu lo III

3. Automatizacion de los procesos, metodo de seleccion si es adminis-trativo 233.1 Ciclo de vida clasico del desarrollo de sistemas 23

3.1.2 Investigacion preliminar 233.1.3 Aprobacicn de la solicitud 243.1.4 Determinacion de los requerimientos del sistema 243.1.5 Disefio del sistema 243.1.6 Desarrollo del software 243.1.7 Prueba de sistemas 253.1.8 Implantacion y evaluacion 25

3.2 Odo de vida, un enfoque diferente 253.2.1 Concepto de ciclo de vida 253.2.2 EI cicIo de vida en cascada 263.2.3 EI modelo contractual 353.2.4 Uso de tecnicas de cuarta generaci6n 373.2.5 Construccion de prototipos 423.2.6 El modelo en espiral 473.2.7 Vision generica de la ingenieria del software 503.2.8 Ingenieria inversa y reingenieria del software 55Capi tu lo IV

4. La automatizaci6n de los procesos de producci6n, metodo deseleccion si es industrial 594.1 Automatizaci6n 594.2 Sistemas integrados de producci6n 594.3 Rob6tica industrial 594.4 Maquinas de control numerico 604.5 Control auto mat i co de la produccion 60

Glosario 62Bibliografia 63


11/73

INTRODUCCION

Los procesos de produccion abarcan todo el espectro, desde laslabores totalmente manuales, pasando por los sistemas hombre-rnaquina,hasta los procesos automaticos donde la mano de obra es indirecta 0 consistesolo en ejercer vigilancia. Las labores manuales , por 10 general combinadascon la ayuda mecanica, realizan todavia una buena parte de la actividadproductiva. El disefio de las labores manuales y de las fases manuales 0 devigilancia de 1a operaciones automaticas son elementos que contemp1a estetrabajo.

Las operaciones manua1es, as! como las que realizan con las lineasde ensamble, la s oficinas, los supermercados y otros, contemplan procesosproductivos. Todo 10 anterior nos indica que 1a naturaleza basica delprocesamiento es de transformacion; es decir, ocurre algo que , en cualquierforma, cambia aquello con 10 cual se trabaja. De modo general, dichatransformacion puede ser un cambio en la composicion quimica, unaalteracion de la forma bas ica que puede afiadir 0 quitar partes ( como ocurreen el ensamble), cambiar la ubicacion del objeto procesado (como ocurre enla transportacion), alimentar 0 alterar los sistemas de informacion ( comoocurre en la s operaciones de oficina) 0 comprobar la exactitud de otrosprocesos ( como en la s operaciones de inspeccion), todo esto es parte de losprocesos de produccion que todos los dias deben ser evaluados para laobtencion de resultados que penniten la toma de decisiones de parte delempresario para saber los indicadores de rentabilidad de la misma.

En este trabajo se describen las herramientas minimas que todoempresario debe conocer para aplicar a su empresa la automatizacion de losprocesos que se llevan acabo en su negocio y para llevarlos a unarentabilidad superior a 1a que tiene actualmente, iniciando con temas


12/73

2La Automatizacion de los Procesos de Produccion en 1aEmpresa

informativos, selectivos y de aplicacion, El objetivo final de este trabajo esque el empresario tenga un manual de referencia, donde encuentre losmetodos y la informacion de como el puede automatizar su empresa, conelementos sencillos de cornprension hasta metodos mas formales e inclusivecon una planificacion estrategica para el desarrollo de los analisis derequerimientos de un sistema, ya sea administrativo 0 de manufactura.Tambien esta enfocado al estudiante de las carreras de Licenciatura enSistemas e Ingenierias en Electronica y Sistemas como un documento dereferencia bibliografica para los cursos de automatizacion de oficinas, analisisydiseiio de sistemas.


13/73

3La Automatizaci6n de los Procesos de Producci6n en la Empresa

OBJETIVOS

E l presente trabajo tiene como objeto llevar los conocimientosnecesanos para que el empresario 0 estudiante de carreras deingenierias 1 0 utilice como un manual de referencia en laimplementacion de la automatizacion en los procesos de produccionen los medios industriales yempresariales.

Que el estudiante de las carreras de Ingenieria y Licenciatura enAdministracion de Sistemas de Informacion posean una fuente deconsulta bibliografica,

Demostrar que los conocimientos adquiridos en la carrera deLicenciatura en Administracion de Sistemas de Informacion sonaplicables en la industria y la empresa.


14/73

4La Automatizaci6n de los Procesos de Producci6n en 1aErnpresa

CAPiTULO I

1. LA EMPRESAEs una entidad juridica que realiza actividades econ6micas

gracias a las aportaciones de capital de personas ajenas a la actividadde la empresa, los accionistas.1

1.1. Tipos de empresas Empresa publica, entidad institucional con personalidad

juridica propia, constituida con capital de titularidad estatalen su totalidad 0 de modo parcial, cuya finalidad es larealizaci6n de actividades productivas 0 la prestaci6n de unservicio en regimen de derecho privado. 2

Empresa privada, entidad que desempefia una actividadecon6mica dentro del sector privado (que se distingue delsector publico). La empresa privada yel sector privado sonterminos que se pueden emplear de una formaindiferenciada. El factor que distingue ambos terminos esque el sector privado se refiere a la totalidad del segmentode la economia que no pertenece al Estado, y la empresa

1"Empresa," Enciclopedia Microsoft Encarta 2000. 1993-1999Microsoft Corporation. Reservados todos los derechos.

2"Empresa publica," Enciclopedia Microsoft Encarta 2000. 1993-1999 Microsoft Corporation. Reservados todos los derechos.


15/73

5La Automatizacion de los Procesos de Produccion en la Ernpresa

privada se refiere de un modo mas concreto a una empresaindividual que corresponde a dicho sector-'.

1.2 Sistemas de producci6n1.2.1 Sistema de dis tribuc i6n. Este sistema lleva a cabo la

distribucion fisica de informacion y productos. Los sistemasde distribucion se encuentran ubicados entre las funciones defabricacion y e l consumidor. La administracion del sistema dedistribucion se centra en la de inventario y se ocupaprincipalmente de la ubicacion estrategica de las existenciasen relacion con el mercado y con l a s fuentes deabastecimiento.

1.2.2 Sistema de producci6n-distribuci6n de gran volumen. Laadicion de un sistema de produccion al sistema dedistribucion cambia e l enfoque y complica enormemente losproblemas administrativos. El sistema bajo control de laadministracion depende del sistema de producci6n y abarcahasta cierto punto e l sistema de distribuci6n, segun el tipo deorganizacion. En algunos casos puede abarcar la totalidad delsistema de distribucion, Una de la s grandes ventajas delacoplamiento de los sistemas de produccion y distribuci6nconsiste en que los inventarios constituyen un medioaltemativo importante para absorber la s fluctuaciones de 1ademanda.

1.2.3 Sistema intennitente. A diferencia del sistema de granvo1umen, e1sistema intermitente 10adapta todo a la necesidadbasica de conservar un "inventario" de instalaciones y

3"Empresa privada," Enciclopedia Microsoft Encarta 2000. 1993-1999 Microsoft Corporation. Reservados todos los derechos.


16/73


recursos humanos que pueda satisfacer los requisites de unademanda que varia en terminos de disefio, estilo y tecnologiapor cada cliente 0 pedido. A este sistema se le llamaclasicamente taller.

1.2.4 Sistema de proyecto en gran escala. El modelo estructuralde un sistema de proyecto en gran escala es muy parecido aldel taller. La diferencia esta en la gran complejidad y en lasamplias demoras que causa la coordinacion dentro de unsistema de proyectos en gran escala.

1.2.5 Intercambios de costo. Los facto res del costo que semodifican en funcion de cierta decision siguen patronesdistintos, de manera que la mejor solucion rara vez implica lareduccion del minimo de un solo factor del costo a expensasde todos los dernas. Esto quiere decir que los administradoresde la produccion deben establecer los niveles apropiados deintercambio entre diversos factores del costo, entre los cualesfiguran los siguientes: costo de desperdicios, costos depedidos atrasados, costo por agotamiento, costo de tiempoextra, costo de contrataciones y despidos y otros.

1.3 Disefio del producto y seleccion de procesos:1.3.1 Proceso. Todo proceso implica alguna clase de

transformacion, Este es fundamental para la administracionde la produccion, Cuando se piensa en los procesos, existe latendencia a hacerlo en terminos limitados; es decir, se piensaen aquellos que modifican, configuran 0 plasman; pero elconcepto es un poco mas amplio. Un proceso puede cambiarla ubicacion del objeto que se procesa, proporcionar 0


17/73

7La Automatizacion de los Procesos de Produccion en la Empresa

modificar informacion y comprobar la exactitud de cualquierotro proceso.

1.3.2 Planificacion de la produccion. El costo minimo deproduccion de un articulo 1 0 determina su planificacion, Si eldisefio del producto y la planificacion de su proceso se lleva acabo en forma independiente, se reducira en gran medida l aprobabilidad que ambos resulten optimos, Cuando se realizaconscientemente un esfuerzo para unir los dos procesos, setiene 1 0 que se conoce como planificacion de la produccion,El concepto del disefio del objeto desde el punto de vista delas posibilidades para producirlo, desernpefia una funcion, lacual es importante para obtener los costos minimos deproduccion.

1.3.3 Retroalimentacion, El concepto de retroalimentaci6n esfundamental no solo para la automatizacion sino tambienpara los sistemas de control general. Para completar uncircuito de retroalimentacion se necesita una unidad sensoraque mida los resultados de 10 que se desea controlar, as!como un medio para comparar los resultados rea1es con losque se buscan. La diferencia se comunica a un ente que tomadecisiones, quien a su vez interpreta e1 error y ordena unacorreccion de la magnitud y direcci6n apropiadas para que losresultados se vue1van a ajustar a los estandares.

1.3.4 Control de posicion. Esto significa la aplicaci6n delconcepto de retroalirnentaci6n al control de las maquinas


18/73


herramienta. EI concepto del control de posicion esfundamental para la automatizaci6n. EI control de laherramienta se efectua en dos dimensiones, con el fin deponerla en posici6n en cualquier momento por medio de unasecuencia de operaciones.

1.3.5 Control de contomo. Como ocurre con el control deposicion , el de contorno es fundamental para laautomatizaci6n y aplica el concepto de retroalimentaci6n. Esmas complejo, porque ademas de la posicion se debeespecificar tambien el curso real que debe seguir laherramienta. La programaci6n requerida es mas complicadaque el caso del control de posici6n, porque algunas veceshay que especificar curvas y superficies.

1.3.6 Procesos quimicos, Son comunes en las industrias delpetr6leo, de los plasticos, del acero y del aluminio, siendointernos sus cambios en sus composiciones. Es imposiblegeneralizar en poco tiempo acerca de la naturaleza y elalcance del procesamiento quimico . Industrialmente, estosprocesos se efectuan en lotes yen forma continua.

1.3.7 Procesos para modificar , configurar 0 vaciar. Losprocesos m a s comunes de esta clase se encuentran en lasindustrias del moldeado y maquinado de metales, del trabajoen madera y del moldeado y vaciado de plasticos,


19/73


1.3.8 Procesos de transportaci6n. La transformaci6n que ocurreen un proceso de transportaci6n es de lugar. Es decir que pormedio de este proceso se le da a la pieza 0 producto unservicio de ubicaci6n.

1.3.9 Los procesos de oficina y los sistemas de infonnaci6n.Mientras los procesos de indole mecanica se encargan delcambio de las formas, los procesos de oficina transforman lainformacion. El volumen de la actividad adrninistrativa hacrecido hasta e l punto que, en algunos paises, el numero deoficinistas es mayor que el de los obreros. Estas actividadesse llevan acabo aplicando una amplia gama de tecnicas, quevan desde e l trabajo puramente manual, pasando por todoslos grados de mecanizacion, hasta el sistema integrado deprocesarniento de datos, que es el compendio de laautomatizacion, El disefio de 1 0 procesado en los sistemas deinformacion depende de la naturaleza del propio sistema y desu grado de mecanizac ion , Aunque la tecnologia actualpermite que en menor grado se ejecuten procesos rnanuales.


20/73


CAPITULO II

2. FORMAS DE EFECUT ARREQUERIMIENTOS.2.1 Determinacion de requerimientos. Es el estudio de un

LOS ANALISIS DE

sistema para conocer como trabaja y donde es necesarioefectuar mejoras 0 la modificacion del proceso 4 Unrequerimiento es una caracteristica que debe incluirse en unonuevo 0 bien modificarse en un existente. Esta puede ser lainclusi6n de una determinada forma para capturar 0 procesardatos, producir informacion, controlar una actividad en unproceso de produccion de cualquier tipo. De esta forma ladeterminacion de requerimientos vincula el estudio de unsistema existente para su transformacion 0 creacion. Ladeterminacion de requerimientos involucra tres actividades: Anticipacion de requerimientos. Prever las caracterfsticas

del sistema con base en 1 a experiencia previa. Investigacion de requennuentos. Estudio de

documentacion del sistema actual. Especificacion de requennuentos. Datos obtenidos

durante la recopilacion de hechos analizados paradeterminar la especificacion de los requerimientos, es decirla descripci6n de las caracterfsticas del nuevo sistema 0delos procesos a transformar. Este comprende tres partesque se relacionan entre si : a) Analisis de datos basados enhechos reales para examinar el grade de desempefio y si

4 James A. Senn. Analisis y diseiio de sistemas de informacion. (Mexico: McGRAW-HILL, 1,993), p.122.


21/73


cumple con las demandas de la organizaci6n. b)Identificaci6n de requennuentos esenciales, siendo lascaracteristicas que deben incluirse en el proceso atransformarse y los detalies de operaci6n de sudesempefio. c) Selecci6n de estrategias para satisfacer losrequenrruentos, que son los metodos utilizados paraidentificarlos y escogerlos dependiendo del tipo deempresa y/o industria donde se realiza la investigaci6n.

2.2 Planificacion del analisis de requerimientos en unproblema espacio- temporal.2.2.1 Identificacion y analisis de los requerimientos de

integracion en problemas espacio-temporales.2.2.1.1.- Analisis de aplicaciones espacro-temporales.

Consiste en el analisis de las caracteristicasgenerales de un conjunto de casos de estudio espacio-temporales reales que se dan en la industria yen lasempresas.

2.2.1.2.- Categorizacion de aplicaciones espacio-temporales.

En base al analisis previo de la s aplicacionesespacio-temporales se ham una identificaci6n de otrasaplicaciones presentes en la industria y ernpresas.Estas aplicaciones seran luego clasificadas en base asus caracteristicas con el fin de establecer unacategorizaci6n de elias.


22/73


2.2.1.3.- Caracterizacion de los sistemas desoftware y tecnologias existentes.

En este paso se realizara un analisis de lasdiferentes tecnologias y sistemas de softwareempleados en aplicaciones espacio-temporales en laempresa. Ello permitira establecer, con precision ydetalle, la plataforma de hardware y software que seutilizaraen el desarrollo de las fases posterioresy quese ajustana losprocesos de produccion.2.2.1.4.- Definicion y especificacion de losrequerimientos de integracion en las diferentescategorlas de aplicaciones espacio-temporales.

Con el fin de establecer con precision lasnecesidades de datos, informacion, conocimiento ycontrol, presentes en aplicacionesespacio-temporales,se hace en este paso una especificaciondetallada delos requerimientos de este tipo de aplicaciones0 delos procesos.2.2.2. Diseiio de metodologias de integracion ysistemas de software heterogeneo en dominiosespacio- temporales.2.2.2.1.- Analisis de esfuerzos exitosos deintegracion en diferentes disciplinas 0dominios.

En este paso se realizara una investigaci6ndocumental de la literatura existente relacionada con


23/73


el problema de integracion en diferentes contextos dela ingenieria, la computacion y disciplinas afines a laempresa 0 la industria.

2.2.2.2.- Definicion y evaluacion de modelos 0estrategias de integracion,

En base en los resultados del paso 2.2.2.1, serealizara la definicion de los diferentes modelos 0estrategias de integraci6n que se han empleado 0 sepodrian emplear en la solucion del problema deintegracion de software heterogeneo para laautomatizacion del proceso.

2.2.2.3.- Seleccion de un modelo 0 estrategia deintegracion mediante la evaluacion de prototipos.

La elaboracion de prototipos de softwarepermitira establecer un marco de comparaci6n paralos diferentes modelos establecidos en el paso 2.22.3 yfacilitara la seleccion de aquel que se empleara en elproceso de integracion de software heterogeneo 0 enel proceso en aplicaciones espacio-temporales.

2.2.2.4.- Diseiio de la estructura de la metodologiay definicion de sus etapas, fases, pa~sos yactividades.

En este paso se evaluaran diferentesmetodologias, existentes en la literatura, relacionadasdirectamente con el problema de integraci6n del


24/73


proceso a automatizar, Basado en dicha evaluaci6n, sedisefiara una metodologia propia aplicable al problemade la integraci6n de sistemas para el procesamiento dedatos, informaci6n, conocimiento y control enaplicaciones espacio-temporales.

2.2.2.5.- Diseiio de tecnicas de integracion para alapoyo a las distintas fases y pasos de lametodologia.

Una metodologia emplea, generalmente, unconjunto de tecnicas que facilitan la ejecuci6n de susfases, pasos yactividades. En esta fase, se analizaranlas tecnicas presentadas en la literatura para este fin, yse seleccionaran 0 disefiaran aquellas que seannecesarias para apoyar la aplicaci6n de la metodologiaelaborada en el paso 2.2.2.4.

2.2.3. Desarrollo de sistemas de apoyo a laintegracion de software heterogeneo.

2.2.3.1.- Especificacion y diseiio de la arquitecturadel Sistema Integrador de Software Heterogeneo,

Utilizando la metodologla elaborada en la fasede forrnas de efectuar los anllisis de requerimientos,en conjunto con los metodos y tecnicas de laIngenieria de Software Orientado a Objetos, seespecifica y diseiia la arquitectura del SistemaIntegrador de Software Heterogeneo correspondientea la capa de integraci6n.


25/73


2.2.3.2.- Diseiio detallado del sistema integradorde software heterogeneo,

El disefio detallado de cada componente de laarquitectura del Sistema Integrador se ejecuta en estepaso. Se establece, en particular, los detalles del disefiode: ( 1 ) el lenguaje de definici6n y manipulacionintegrada de datos, conocimiento y control, (2 ) lainterfaz usuario-sistema, ( 3 ) la base de datos delsistema y ( 4 ) los componentes programados.2.2.3.3.- Codificacion de componentes del sistemaintegrador de software heterogeneo.

Cada componente identificado y disefiado enel paso 2.2.3.2, sera codificado en el lenguaje deprogramaci6n establecido en base a los resultados dela s fases 1y 2 para su acoplarniento en el proceso.2.2.3.4.- Pruebas del software desarrollado.

Cada componente de software del sistematecnicas y herrarnientas de la Ingenieria de SoftwareOrientada a l proceso a automatizar . La verificaci6nse basad en los requerimientos definidos en la fase 1.


26/73


2.2.4. Aplicacion de los resultados a casos reales yanalisis de resultados obtenidos.2.2.4.1.- Seleccion definitiva de casos reales deaplicaci6n.

A traves de las relaciones con los sectoresindustrial y empresas, se estableceran los casosespedficos de aplicaci6n del Sistema Integrador deSoftware Heterogeneo. Se seleccionaran, en principio,dos aplicaciones del conjunto de categories deproblemas identificados yanalizados en la fase 1.

2.2.4.2.-Construccion de las aplicacionesseleccionadas usando el Sistema de Integracionde Software Heterogeneo,

El Sistema Integrador de SoftwareHeterogeneo sera validado a traves de su aplicacion ala soluci6n d e problemas en la s dos aplicacionesseleccionadas anterionnente.

2.2.4.3.- Evaluaci6n de resultados.

El Sistema Integrador d e SoftwareHeterogeneo, la metodologfa de integraci6n y dernasresultados obtenidos a 1 0 largo del plan de trabajoseran evaluados en base a un conjunto de criteriosestablecidos en esta fase. La evaluaci6n final del plande trabajo, el alcance de sus objetivos y los logrosobtenidos cerraran la labor de investigaci6n realizada.


27/73

La Automatizaci6n de los Procesos de Producci6n en la Empresa17

2.2.4.4.-Finalizaci6n del plan de trabajo.

2.3 Metodo de agrupamiento de procesos padre -hijo.

Metodo consiste en laueidentificacion de los procesos principales loscuales tienen procesos dependientes. Elanalisis de estos procesos principales permitela evaluacion del rendimiento de lasactividades que estos anteceden e identifican sies necesaria la reestructuracion de estos 0sumodificacion, En la figura 2.2 se observa unejemplo de como se elaboracomponentes que se utilizan.

y los

Los elementos que se utilizan en losdiagramas de proceso son:

~ Flujo de datosD Enti.dad0 ProcesoArchivo


28/73


ENTIDADEXTERNA

1 SISTEMA ENTIDAD0 EXTERN A

PROCESO 3ENTIDADEXTERNA

2 r-- f-----

ENTIDAD ( Pro ce- 1 ( Proce- I ENTIDEXTERNA so a aa so bbb EXTE1 J 34 , t4 ,A1m ....... I

~,1 JENTIDAD Proce- . r Pro ce-so soEXTERN A ccc ~ ddd2 )

ADRNA

Figura 2.1 ejemplo de un proceso

El elemento de flujo de datos se utiliza paraenlazar las entidades extemas con los procesoso archivos. Las entidades sirven para indicarlos elementos de entrada a l sistema y losarchivos son lugares donde se almacenainformaci6n 0 se reqruere los procesos loscuales son elementos del sistema que puedenser independientes 0 dependientes.


29/73


ENTIDAD ENTIDADEXfERNA EXfERNAI -- 2SISITMA0

PROCESO

I :ElLJ

Figura 2.2

Proceso lineal

2.4 Procesos lineales.Estos procesos son secuenciales y cada actividad esdependiente de la anterior, ver Fig. 2.2.

2.5 Analisis de eventos.

Es la observacion de los procesos deproducci6n en tiempo real que permiten recabarinformaci6n para la elaboraci6n de la tabla de eventos.La tabla de eventos es un listado de actividades que se


30/73

La Autornatizacion de los Procesos de Produccion en la Empresa20

realizan en uno 0 m a s procesos que permite efectuarlas relaciones Fig. 2.3

r - E V E N T O! "AcnVI iSADi ' "IIACTIVIDAD2-! !r--:-===--:-=-'- """'--'_" i''''--'''''''';:::O''---'''''-'''''''''~'''-'-''''' i '-::::' :=-~'-"-~-' '' '' ' ' -"-~-"-- iACTIVIDAD ... T. PROCESO ..

I ACTIVJDAD n

. . . . f T I E M P O , , . . . . . . . . I P R O C E S O I, .".-""""., ,~:"".. '-' ' '--' '-'' ' ' .''PRO(:E SO;iiI

f"""""---:::Tc-:2"'"'~'''''-'~-''~--'' ' ' 'PR6(:ESO~

,. i

rTn

Fig. 2.3 Cuadro de eventos con sus tiempos yprocesos.

En esta tabla se colocan los eventos(actividades) con el tiempo de ejecuci6n en elproceso, con esta informaci6n se tiene el resumen delas actividades que se vinculan con uno 0 vanosprocesos que m a s adelante se pueden crearmecanismos para tener un mejor rendimiento y si esnecesario la automatizaci6n de estas actividades:.

2.6 Analisis de requerimientos organizacionales.

Es la estructura organizacional de la empresaque es utilizada para conocer la misi6n y visi6n de lamisma, relacionandolos con la eficiencia de losprocesos que esta utiliza para alcanzar sus objetivosempresariales.


31/73


Para ello es necesario efectuar los siguientes pasos:

Descripciones de las actividades que serealizan en la empresa y la agrupaci6n deestas en grupos de trabajo 0 enprocedimiento.

Cantidades de trabajo que efectuan losprocesos, actividades 0 procedimientosanteriormente descritos.

Mecanismos de procesos, actividades 0procedimientos que utilizan. Estos puedenser finos, gruesos secuenciales,independientes 0dependientes.

Informaci6n financiera, relacionada a laproductividad y eficiencia econ6mica de laempresa.

Con la informaci6n anterior se logra obtener unpanorama global de la empresa pudiendodesarrollarse los diagramas ffsicos y logicos ,

Diagrama de flujo logico, es enfocadoen el negocio y la manera en que operael negocio", No le interesa la maneraque el sistema esta construido. En vezde ello, describe los eventos delnegoclO que suceden y los datos

5 Kendall & Kendall, Analisis y disefio de sistemas, (Mexico, Editorial. Prentice Hall1,998), p.254.


32/73


requeridos y producidos por cadaevento.

Diagrama Iisico, muestra como sed.irnplernentado el sistema, incluyendoel software y hardware, archivos ypersonas involucradas en el si terna".

En toda empresa existe la parteadrninistrativa, la cual es la que rnanipulala mayo r i a de la informaci6n. Elabora todotrabajo requerido por la gerencia, estadocumentaci6n generalmente es utilizadapara apoyar 1 a toma de decisiones. Es devital irnportancia efectuar u n a na lisis deltipo de informaci6n que estos procesosadministrativos rnanipulan para aurnentarel rendirniento y 1 a confiabilidad de la1l11Sma.

6 Kendall & Kendall, Analisis y disefio de sistemas, (Mexico, Editorial. Prentice Hall1,998), p.255.


33/73

23La Automatizaci6n de los Procesos de Producci6n en 1aEmpresa

CAPITULO III

3. AUTOMATIZACION DE LOS PROCESOS, METODO DESELECCION SI ES ADMINISTRATIVO.

3.1 Cicio de vida clasico del desarrollo de sistemas.Es el conjunto de actividades que los analistas, diseiiadores y

usuarios realizan para desarrollar e implantar un sistema deinformaci6n. Este metodo es el clasico, En la mayor parte de lassituaciones dentro de una empresa todas las actividades estan muyrelacionadas, en general son inseparables, y quiza sea diflcildeterminar el orden de los pasos que se siguen para efectuarlas. Lasdiversas partes del proyecto pueden encontrarse al mismo tiernpo endistintas fases del desarrollo, algunos componentes en la fase deanalisis rnientras que otros en etapas avanzadas de disefio, Estemetodo para su desarrollo de sistemas consta de las siguientesactividades:

Investigaci6n preliminar Determinaci6n de los requerimientos del sistema Disefio del sistema Desarrollo de software Prueba de los sistemas Implantaci6n yevaluaci6n.

3.1.2 Investigacion preliminar.3.1.2.1 Aclaracion de la solicitud. En esta se examina la

solicitud para determinar can precisi6n 1 0 que sesolicita.

3.1.2.2 Estudio de factibilidad. Este consta de tresfactibilidades: tecnica, econ6rnica y operacional.


34/73

La Automatizacion de los Procesos de Produccion en la Ernpresa24

3.1.2.3

3.1.2.4

3.1.2.5

Tecnica. Involucra la existencia de equipo, si 1 0 hay,de 1 0 contrario se efectua un proceso de analisis delexistente en el mercado para su compra.Econ6mica. Indica si la inversi6n del sistema aimplementar es rentable para la empresa. En ella setoman factores propios financieros de la empresacomo 1 0 son: los costos, los cuales seran cubiertospor los beneficios del sistema a corto 0 largo plazo.Operacional. Esta fase indica si e l sistema adesarrollar 0 implantar es aceptado por losempleados y se podra capacitar con los elementosnecesanos.

3.1.3 Aprobaci6n de la solicitud.Actividad en la que se decide SI un proyecto es

deseable yfactible, entonces es aprobado.3.1.4 Determinacion de los requerimientos del sistema.

Actividad que toma los parametres a seguir en eldesarrollo del sistema ( ver analisis y determinacion derequerimientos capitulo II).

3.1.5 Disefio del sistema.El disefio de un sistema de informacion produce los

detalles que establecen la fonna en la que el sistema cumplinicon los requerimientos identificados en la etapa del analisis,esta etapa es conocida como e 1 disefio logico ,

3.1.6 Desarrollo del software.Este puede ser de dos formas: el desarrollado a la medida quees elaborado por programadores espedficos 0 softwarecomprado que se instala y modifica a las necesidades del


35/73

25La Autornatizaci6n de los Procesos de Producci6n en la Ernpresa

usuario. En esta aetividad se debe eseribir los manuales deusuario, tecnico y de fallas.

3.1.7 Prueba de sistemas.Es el ernpleo del sistema elaborado durante una etapa

de prueba para asegurarse que no existan fallas, es deeir quefuneione de aeuerdo con las espeeificaciones yen la forma enque los usuarios esperan que 1 0 haga. Alimentando el sistemacon datos de prueba yanalizando los resultados.

3.1.8 Implantacion y evaluacion,L a irnplantaci6n es el proceso de verificar e instalar

nuevo equipo, entrenar a los usuarios , instalar llaaplicaci6n yconstruir todos los archivos de datos necesarios para su usoen el sistema. L a evaluaci6n es por etapas hasta que pasa eltiempo de prueba establecido por el usuario y desarrollador.

3.2 CicIo de vida un enfoque diferente.El enfoque actual del cido de vida permite trabajarlo desde un

punto de vista similar al c l a si co , c ompon iendose de las siguientesI caractensncas:

3.2.1. Concepto de cicIo de vida.Por cido de vida, se entiende la sucesion de etapas

por las que pasa el software desde que un nuevo proyectoes concebido hasta que se deja de usar.

Cada una de estas etapas lleva asociada una seriede tareas que deben realizarse, y una serie de documentos


36/73


(en sentido amplio: software) que seran la salida de cadauna de estas fases y serviran de entrada en la faseslgmente.

Existen diversos modelos de cido de vida.Dive rsas formas de ver el proceso de desarrollo desoftware, y cada uno de ellos esta asociado a unparadigma de la ingenieria del software, es decir, a unaserie de metodos, herramientas y procedimientos quedebe usar a 1 0 largo de un proyecto. A continuaci6n sedescriben algunos modelos principales de cido de vidaque se pueden utilizar en la automatizaci6n de losprocedimientos administrativos, estos se desarrollancomo informaci6n para el empresario y que este puedadecidir cual se acopla a sus requerimientos .

La elecci6n de un paradigma u otro se realiza deacuerdo con la naturaleza del proyecto y de la aplicaci6n;los metodos a usar y los controles y entregas requeridos.

3.2.2. El cicIo de vida en cascada ( 0 cicIo de vida clasico),Este paradigma es e l m a s antiguo de los

empleados en la Ingenieria de software (IS) y sedesarroll6 a partir del ciclo convencional de unaingenieria, No hay que olvidar que la IS surgi6 comocopia de otras ingenierias, especialmente de las delhardware, para dar soluci6n a los problemas mascomunes que aparedan al desarrollar sistemas desoftware complejos.


37/73

La Automatizaci6n de los Procesos de Producci6n en la Empresa27

Ingenieria delSistema

Es un ciclo de vida en sentido amplio, queincluye no solo las etapas de ingenieria sino toda lavida del producto: las pruebas, el uso (la vida util delsoftware) y el mantenimiento, hasta que llega elmomento de sustituirlo (Figura3. 2.1)

Utllizecien J

Figura 3. 2.1. Gdo de vida en cascada.

E l cido de vida en cascada exige un enfoquesistematico y secuencial del desarrollo de software,que comienza en el n ivel de 1 a ingenieria de sistemas yavanza a traves de fases secuenciales sucesivas. Estasfases son la s siguientes:

Ingenierfa y analisis de l s is tema .El software es siempre parte de un sistema

mayor, por 1 0 que siempre va a interrelacionarsecon otros elementos, ya sea hardware, maquinas 0personas. Por esto, el primer paso del cido de vida


38/73

28La Automatizaci6n de los Procesos de Producci6n en 1aEmpresa

de un proyecto consiste en un analisis de lascaracteristicas yel comportamiento del sistema delcual el software va a formar parte. En el caso de. ..que se qmera construir un sistema nuevo, porejemplo un sistema de control, se debe analizarlos requisitos y la funci6n del sistema, y luego seasigna un subconjunto de estos requisitos alsoftware. En el caso de un sistema ya existente(suponer, por ejemplo, que se quiera automatizaruna empresa) es necesano analizar elfuncionamiento de la misma, - las operaciones quese llevan a cabo en ella -, y asignar al softwareaquellas funciones que se automatizara,

La ingenieria del sistema comprende, portanto, los requisitos globales a nivel del sistema, as!como una cierta cantidad d e analisis y de disefio anivel superior.

Ana lis is de requ is ito s d e l sof tware ,El analisis de requisitos debe ser m a s

detallado para aquellos componentes del sistemaque se necesite implementar mediante software.El ingeniero del software debe comprender cualesson los datos que se van a manejar, cual es lafunci6n que tiene que cumplir el software, cualesson las interfaces requeridas y cual es elrendimiento que se espera lograr.


39/73


Los requisites, tanto del sistema como delsoftware deben documentarse y revisarse con elcliente.

Diseiio.

El disefio se aplica a cuatro caracteristicasdistintas del software: la estructura de los datos, laarquitectura de las aplicaciones, la estructuraintema de los programas y las interfaces.

El disefio es el proceso que traduce losrequisitos en una representaci6n del software deforma que pueda conocerse la arquitectura,funcionalidad e incluso la calidad del mismo antesde com.enzar la codificaci6n.

El disefio debe docum.entarse y formarparte de la configuraci6n del software (el controlde configuraciones es 1 0 que permite realizarcambios en el software de forma controlada y notraumatica para el cliente).

Codificaci6n.

La codificaci6n consiste en la traducci6ndel disefio a un formato que sea legible para lamaquina, Si el disefio es 1 0 suficientementedetallado, 1 a codificaci6n es relativamente sencilla,y puede hacerse - al menos en parte - de formaautomatica, usando generadores de c6digo.


40/73


Se observa que estas pnmeras fases delciclo de vida consisten basicamente en unatraducci6n en el analisis del sistema, los requisites,la funci6n y la estructura de este se traducen a undocumento. El analisis del sistema que estaformado en parte por diagramas y en parte pordescripciones en lenguaje natural. En el analisis derequisites se profundiza en el estudio delcomponente software del sistema yesto se traducea un documento, tambien formado por diagramasy descripciones en lenguaje natural. En el disefio,los requisites del software se traducen a una seriede diagramas que representan la estructura delsistema software, de sus datos, de sus programas yde sus interfaces. Por Ultimo, en la codificaci6n setraducen estos diagramas de disefio a un lenguajefuente, que luego se traduce - se compila - paraobtener un programa ejecutable.

Prueba.Teniendo el programa ejecutable,

comienza la fase de pruebas. El objetivo escomprobar que no se hayan producido errores enalguna de las fases de traduccion anteriores,especialmente en la codificaci6n. Para ello debenprobarse todas las sentencias, no s610 los casosnormales y todos los m6dulos que forman partedel sistema.


41/73

31La Autornatizacion de los Procesos de Prcduccion en la Empresa

Utilizaci6n.Superada la fase de pruebas, el software se

entrega al cliente y comienza la vida util delmismo. La fase de utilizacion se encubre con lasposteriores ( el mantenimiento y la sustituci6n) yse mantiene hasta que el software es reemplazadopor otro, se deja de utilizar.

Mantenimiento.El software sufrira cambios a 1 0 largo de su

vida util, Estos cambios pueden ser de bido a trescausas:

Que, durante la utilizacion, el clientedetecte errores en el software: los erroreslatentes.

Que se produzcan cambios en alguno delos componentes del sistema informatico:por ejemplo cambios en la maquina , en elsistema operativo 0 en los perifericos.

Que el cliente requiera modificacionesfuncionales (normalmente ampliaciones)no contempladas en el proyecto.


42/73


En cualquier caso, el mantenimientosupone volver arras en el cido de vida, a lasetapas de codificaci6n, disefio 0 analisisdependiendo de la magnitud del cambio.

El modelo en cascada, a pesar de serlineal, connene flujos que perrmten laregresi6n. As1, desde el manterumiento sevuelve al analisis, el diseiio a la codificaci6n, ytambien desde cualquier fase se puede volver ala anterior si se detectan fallos. Estasregresiones no son controladas, ni quedanexplicitas en el modelo, y este es uno de losproblemas que presenta este paradigma

Sustitucion.La vida del software no es ilimitada y

cualquier aplicaci6n, por buena que sea, acaba porser sustituida por otra mas amplia, rapida y facilde usar.

La sustituci6n de un software que estafuncionando por otro que acaba de serdesarrol1ado, es una tarea que debe planificarsecuidadosamente y que debe llevarse a cabo deforma organizada. Es conveniente realizarla porfases, si esto es posible, no sustituyendo todas lasaplicaciones de una sola vez , puesto que lasustituci6n lleva normalmente un aumento detrabajo para los usuarios, que deben disciplinarsea las nuevas aplicaciones, y a quienes 1 0implementan y adernas deben corregir los


43/73


errores que surjan, Es necesario hacer un trasvasede la informaci6n que maneja el sistema viejo a laestructura y el formato requerido por el nuevo.Ademas, es conveniente mantener los dossistemas funcionando en paralelo durante alguntiempo para comprobar que el sistema nuevofuncione correctamente y para asegurar elfuncionamiento normal de 1 a empresa aun en elcaso de que el sistema nuevo falle y tenga quevolver a alguna de las fases de desarrollo.

La sustitucion implica el desarrollo deprogramas para la interconexi6n de ambossistemas, el antiguo y el nuevo, y para trasvasar lainformaci6n entre ambos, evitando 1 a duplicaci6ndel trabajo de las personas encargadas del procesode datos, durante el tiempo en que ambos sistemasfuncionen en paralelo.El ciclo de vida en cascada es el paradigmamas antiguo, mas conocido y m as ampliamenteusado en 1 a IS . No obstante, ha sufrido diversascriticas, debido a los problemas que se plante an alintentar aplicarlo a determinadas situaciones.Entre estos problemas estan.

Los proyectos no siguen un ciclo de vidaestrictamente secuencial como propone elmodelo. Siempre hay interacciones. El ejemplom a s tipico es la fase de mantenimiento, queimplica siempre volver a alguna de las fases


44/73


anteriores, pero tambien es muy frecuente enque una fase, por ejemplo el disefio, sedetecten errores que obliguen a volver a la faseanterior, el analisis ,

Es difkil que se puedan establecer inicialmentetodos los requisitos del sistema. Normalmentelos clientes no tienen conocimiento de laimportancia de la fase de analisis 0 bien no sehan pensado en todos los detalles que se debey se necesite hacerle al software. Los requisitosse van aclarando y refinando a 1 0 largo de todoel proyecto, segUn se plantean dudas concretasen e l disefio 0 la codificacion, Sin embargo, elciclo de vida clasico requiere la definicioninicial de todos los requisitos y no es facilacomodar en el las incertidumbres que suelenexistir a 1 cornienzo de todos los proyectos. Hasta que se llega a la fase final del desarrollo,la codificaci6n no se dispone de una versionoperativa del programa. Como la mayor partede los errores se detectan cuando el clientepuede probar el programa no se detectan hastael final del proyecto, cuando son m a s costososde corregir y m a s rapidos (con m a s presiones)hay razones por 1 0 que el programa se debeponer definitivamente en marcha.Todos estos problemas son reales, pero de

todas formas es mucho mejor desarrollar software


45/73


siguiendo el modelo de cido de vida en cascada quehacerlo sin ningun tipo de gulas. Adernas, este modelodescribe una serie de pasos genericos que sonaplicables a cualquier otro paradigma.

3.2.3 El modelo contractual.

El modelo de cido de vida en cascada, no indicanada sobre la relaci6n entre las diversas partesinvolucradas en el desarrollo de software, ni sobre losdocumentos que sirven de entrada y salida de cada una delas fases del proceso. Por ello, se ha propuesto el modelocontractual, que no es mas que una extension masdetallada del modelo clasico (ver Fig. 3.2.2. El modelocontractual) .

En este modelo, cada fase de desarrollo, ya sea elanalisis, el disefio, la implementaci6n y otros, soncontempladas como el sujeto de un contrato entre dospartes, llamadas respectivamente el proveedor y el cliente.La finalizaci6n de cada fase se produce con 1 a firma, porparte del cliente y del proveedor, de lUI documentocontractual, (en sentido amplio, software) producido porel proveedor a partir de una solicitud de servicios que elcliente ha facilitado a l inicio de la fase.

En cada fase existen: un proveedor y un cliente.El cliente realiza una peticion de servicios, expresando susnecesidades. A partir de esta peticion, e 1 proveedorredacta un contrato de servicio, cuyos detalles se discutencon e 1 cliente. Finalmente, se firma el contrato y se pasa a


46/73


la fase siguiente, en la que el proveedor se convierte encliente (en una especie de subcontratacion),Asi, en la fase de analisis, el cliente que ha encargado e lproyecto actua de cliente yel analista actua de proveedor,y esta fase tennina con un acuerdo de ambos respecto ala especificacion del sistema, redactada a partir de ladefinicion informal de requisitos realizada por el cliente,es satisfactoria y puede servir de contrato para formalizarla transaccion entre ambos.

En la fase de diseiio, e l analista actua de cliente, yproporciona como petici6n de servicio la especificacion,A su vez, esta fase acaba cuando el diseiio realizado por eldisefiador es aceptado como satisfactorio y conforme conlos terminos del contrato, por el analista.

El modelo contractual, tiene la ventaja de dar unmayor rigor a la transici6n entre cada una de las fases delcido de vida y permite detenninar quien es el respons ableen caso de que surjan problemas. As1, el diente esrespons able de los incrementos de costa producidos porun cambio en los requisitos, pues se pretende realizar unservicio que no estaba previsto en el contrato, y elproveedor es responsable d e los gastos ocasionados (0 deaceptar una disminuci6n en el precio) si e l productofinalmente entregado no cumple todas las condiciones delcontrato, es decir, si contiene errores.


47/73


3.2.4 Uso de tecnicas de cuarta generaci6n.

Por tecnicas de cuarta generaci6n se entiende unconjunto muy diverso de metodos y herramientas quetienen por objeto facilitar el desarrollo de software. Perotodos ellos tienen algo en cornun: facilitan al quedesarrolla el software, especificar algunas caracteristicasdel mismo a alto nivel. Luego, la herramienta generaautomaticamente el c6digo fuente a partir de estaespecificaci6n.

Los tipos m a s habituales de generadores dec6digo cubren uno 0varios de los siguientes aspectos:

Acceso a bases de datos utilizando lenguajes deconsulta de alto nivel (derivados normalmente deSQL). Con ello no es necesario conocer la estructurade los ficheros 0tablas ni de sus indices,

Generaci6n de c6digo. A partir de unaespecificaci6n de los requisitos se generaautomaticamente toda la aplicaci6n.

Generaci6n de pantallas. Penniten disefiar lapantalla dibujindola directam.ente, incluyendo ademasel control del cursor y la gesti6n de errores de losdatos de entrada.

Gesti6n de entomos graficos, Generaci6n de infonnes. (de forma similar a laspantallas) .Esta generaci6n automatics permite reducir la

duraci6n de las fases del ciclo de vida clasico, especialmente la


48/73


fase de codificaci6n, quedando el ciclo de vida segun se indicaen la figura 3. 2.3.

AI igual que en otros paradigmas, el proceso comienzacon la recolecci6n de requisitos, que pueden ser traducidosdirectamente a c6digo fuente, usando un generador de c6digo.Sin embargo el problema es el mismo que se plantea en elciclo de vida clasico, es difkil establecer todos los requisitosdesde el comienzo. El cliente puede no estar seguro de 1 0 quenecesita, aunque 1 0 sepa; puede ser dificil expresarlo de laforma en que precisa la herramienta de cuarta generaci6n parapoder entenderla.

Si la especificaci6n es pequefia, se puede pasardirectamente del analisis de requisitos a la generaci6nautomatics de c6digo, sin realizar ningun tipo de disefio, Perosi la aplicaci6n es grande, se produciran los mismosproblemas no usando tecnicas de cuarta generaci6n quepueden ser: mala calidad, dificultad de mantenimiento y pocaaceptaci6n por parte del cliente. Es necesario, por 1 0 tanto,realizar un disefio (al menos 1 0 que se ha llamado unaestrategia de disefio, puesto que el propio generador seencarga de parte de los detal1es del disefio tradicional:descomposici6n modular, estructura l6gica y organizaci6n delos ficheros).


49/73


( Recotecci fin de hequisitoslstrategia de hiseno l Generaclfin de h,odigo

Prueba l~/ r t Utilizaciiin J/1' J( Manteni~ento I

JSustltuclen-, " 1Figura 3. 2.3. Ciclo de vida usando tecnicas de euarta.,generaelon.

Las herramientas de cuarta generaei6n se eneargantambien de produeir automaticamente la doewm.entaci6n delc6digo generado. Es necesario eompletar la doeumentaei6nhasta obtener una que contenga un sentido acorde al sistemaelaborado.

Con respecto a las pruebas, se supone que el c6digogenerado es correcto y acorde con la especificaci6n, y que nocontiene los tipicos errores de la codificaci6n manual. Pero encualquier caso es necesaria la fase de prueba, para comprobarla eficieneia del c6digo generado ( l a generaei6n automatica delos accesos a bases puede produeir c6digo muy efieienteeuando el volumen de informaci6n es grande por ejemplo lasdistintas formas de relacionar tablas en SQL):, tambien paradetectar los errores en la espeeifieaei6n a partir de la eual segener6 el e6digo y por Ultimo, para que el eliente eompruebesi el produeto final satisfaee sus necesidades.


50/73


El resto de las fases del ciclo de vida usando estastecnicas es igual a las del paradigma del ciclo de vida encascada, el cual es una adaptaci6n a las nuevas herramientasde producci6n de software.

Se puede comentar a manera de informacion para elempresano que mediante el uso de tecnicas de cuartageneraci6n no se han obtenido los resultados previstoscuando estas herramientas comenzaron a desarrollarse aprincipios de los ochenta (estos resultados incluian ladesaparici6n de la codificaci6n manual y con ello de losprogramadores, e incluso de los analistas, al poder encargarseel propio cliente con unos pequeiios conocimientos tecnicosde manejar el generador), puesto que los avances enprocesamiento de lenguaje natural (siempre ambiguo) no hansido demasiado grandes ni se han desarrollado lenguajesforrna1es de especificaci6n con la potencia expresiva necesaria.

Sin embargo, estas herramientas consiguen reducir eltiempo de desarrollo de software, eliminando las tareas m a srepetitivas y tediosas (por ejemplo control de la entrada! salidapor terminal) y aumentan la productividad de losprogramadores, por 1 0 que son ampliamente utilizadas en laactualidad, especialmente si nos referimos al acceso a bases dedatos, la gesti6n de la entrada! salida por terminal y lageneraci6n de informes, ademas forman parte de muchoslenguajes de programaci6n que se usan actualmente, sobretodo en el campo del software de gesti6n (ejemplo Infonnix,Natural).No obstante, entre las criticas mas habituales estan:


51/73

41La Autornatizacion de los Procesos de Produccion en 1aEmpresa

No son mas faciles de utilizar que los lenguajes detercera generaci6n. En concreto, muchos de loslenguajes de especificaci6n que utilizan puedenconsiderarse como lenguajes de programaci6n, de un nivelalgo mas alto que los ante riores , pero que no logranprescindir de la codificaci6n en S 1 , sino que simplementela disfrazan de 'especificaci6n'.

El c6digo fuente que producen es ineficiente. Al estargenerado autornaticamente no pueden hacer uso de lostrucos habituales para aumentar el rendimiento, que sebasan en el buen conocimiento de cada caso particular.Esta critica podria aplicarse a cualquier lenguaje deprogramaci6n con respecto a l ensamblador (losprogramas codificados en ensamblador siempre seran masrapidos y mas pequefios que los generados por cualquiercompilador), pero la reducci6n de los tiempos dedesarrollo yel continuo aumento de la potencia de calculode los ordenadores compensan ampliamente esta menoreficiencia.

S6lo son aplicables al software de gesti6n. La mayor i ade la s herramientas de cuarta generaci6n estan orientadasa la generaci6n de informes a partir de grandes bases dedatos, pero Ultimamente estan surgiendo herrarnientas quegeneran esquemas de c6digo para aplicaciones deingenieria y de tiempo real.


52/73

42La Automatizacion de los Procesos de Producci6n en la Empresa

3.2.5. Cons true cion de prototipos.

Dos de las criticas hechas al modelo de ciclo de vida encascada son dificiles de tenerlas claras para todos los requisites delsistema al inicio del proyecto, y que no se dispone de una versionoperativa del programa hasta las fases finales del desarrollo, 10 quedificulta la deteccion de errores y deja tambien para el final eldescubrimiento de los requisites inadvertidos en las fases de analisis,Para solucionar estas deficiencias se ha propuesto un modelo de ciclode vida basado en la construccion de prototipos.

En primer lugar, es verificar si el sistema que se debedesarrollar es un buen elemento a utilizar el paradigma de ciclo devida de construccion de prototipos 0 al modelo en espiral. Engeneral, cualquier aplicacion que presente mucha interaccion con elusuario, 0 que necesite algoritmos que puedan construirse de maneraevolutiva, yendo de 10 m a s general a 10 m a s espedfico es una buenaforma. No obstante, hay que tener en cuenta la comp1ejidad, si laaplicacion necesita desarrollar una gran cantidad de codigo paramostrar un prototipo al usuario. La s ventajas de la construccion deprototipos se venin superadas por el esfuerzo de desarrollar unprototipo que al final habra que desechar 0 modificar. Tambien hayque tener en cuenta la disposicion del cliente para probar unprototipo y sugerir modificaciones d e los requisitos. Puede ser que elcliente no yea las ventajas de este metodo de desarrollo pero que esfuncional.

Tambien es conveniente construir prototipos para probar laeficiencia de los algoritmos que se van a implementar, 0 paracomprobar el rendimiento de un determinado componente delsistema, por ejemplo, una base de datos 0 el soporte de hardware, en


53/73


condiciones similares a las que existiran durante la utilizacion delsistema. Es bastante frecuente que el producto de ingenieriadesarrollado presente un buen rendimiento durante la fase de pruebasrealizada por los ingenieros antes de entregarlo al cliente (pruebas quese realizaran normalmente con unos pocos registros en la base dedatos 0 un unico terminal conectado al sistema), pero que va hacerineficiente, 0 incluso inviable, a la hora de almacenar 0 procesar elvolumen real de informacion que debe manejar el cliente. En estoscasos, la construccion de un prototipo de parte del sistema y larealizacion de pruebas de rendimiento, sirven para decidir, antes deempezar la fase de disefio, cual es el modelo m a s adecuado entre lagama disponible para el soporte hardware 0 como deben hacerse losaccesos a la base de datos para obtener buenas respuestas en tiernpocuando la aplicacion este en funcionamiento.

En otros casos, el prototipo servira para modelar y mostrar alcliente como va a realizarse la E /S de datos en la aplicacion, de formaque este pueda tener una idea del sistema final, pudiendo entoncesdetectar deficiencias 0errores .

Segun esto, un prototipo puede tener una de la s tres formassiguientes:

prototipo, en papel 0 ejecutable en ordenador, que describa lainteraccion hombre-miquina y los listados del sistema.

prototipo que implemente algillt(os) subconjunto(s) de la funcionrequerida, y que sirva para evaluar el rendimiento de un algoritmoo las necesidades de capacidad de almacenamiento y velocidad decalculo del sistema final.


54/73


un programa que realice todo 0 una parte de la funci6n deseada,pero que tenga caracteristicas que deban ser mejoradas durante eldesarrollo del proyecto.

La secuencia de tareas del paradigma de construcci6n deprototipos puede verse en la figura 3.2.4.

Si se ha decidido construir un prototipo, 1 0 primero que sedebe hacer es realizar un modelo del sistema, a partir de losreqursitos ya conocidos. En este caso no es necesario realizar unadefinici6n completa de los requisitos, pero si es convenientedeterminar al menos las areas donde sera necesaria una definici6nposterior mas detallada.

Luego se procede a disefiar el prototipo. Se tratara de undisefio rapido, centrado sobre todo en la arquitectura del sistema y 1 adefinici6n de 1 a estructura de las interfaces m a s que en aspectosprocedimentales de los programas.

A partir del disefio se construye el prototipo, Existenherramientas especializadas en generar prototipos ejecutables a partirdel disefio. Otra opcion es utilizar tecnicas de cuarta generaci6n. Laposibilidad mas reciente consiste en el uso de especificacionesfonnales, que Ultimamente tienden al desarrollo de entomosinteractivos que faciliten el desarrollo incremental de especificacionesy permitan la prueba de estas especificaciones.

En cualquier caso, e 1 objetivo es siempre que la codificaci6nsea rapida, aunque sea en detrimento de la calidadl del softwaregenerado.

Desarrollado el prototipo, se debe presentar al cliente paraque 1 0 pruebe y sugiera modificaciones. El cliente puede hacer una


55/73


implementacion de los requisrtos que ha definido inicialmente ysugerir las modificaciones necesarias en las especificaciones para quesatisfagan mejor sus necesidades.

A partir de los cambios que se muestren necesarios en losrequisitos, se procedera a construir un nuevo prototipo y as!sucesrvamente hasta que los requisuos queden totalmenteforma1izados, y se pueda entonces empezar con el desarrollo delproducto final.

Por tanto, el prototipo es una tecnica que sirvefundamentalmente para la fase de analisis de requisitos, pero llevaconsigo la obtencion de una serie de subproductos que son utiles a 1 0largo del desarrollo del proyecto:

Gran parte del trabajo realizado durante la fase de disefiorapido (especialmente la definicion de pantallas e infonues)puede ser utilizada durante el disefio del producto final.Ademas, tras realizar varias vueltas en el ciclo de construccionde prototipos, el disefio del mismo se parece cada vez m a s alque tendra el producto final.

Durante la fase de construccion de prototipos es necesariocodificar algunos componentes del software que tambienpodran ser reutilizados en la codificacion del producto final,aunque deban ser optimizados en cuanto a correccion 0velocidad de procesamiento.

No obstante, hay que tener en cuenta que el prototipo noes el sistema final, pues norma1mente es poco utilizable. Serademasiado lento, demasiado grande, inadecuado para el volumende datos necesario, contendra errores (debido al disefio r apido) ,sera demasiado general (sin considerar casos particulares, que


56/73


debe tener en euenta el sistema final) 0 estara codificado en unlenguaje 0para una maquina inadecuada, a partir de componentesde software previamente existentes. No hay que preocuparse dehaber perdido tiempo 0 esfuerzos construyendo prototipos queluego habran de ser desechados, si con ello hemos conseguidotener mas clara la especificaci6n del proyecto, puesto que eltiempo perdido 1 0 ahorraremos en las fases siguientes, quepodran realizarse con menos esfuerzo y en la s que se cometeranmenos errores.

Se debe considerar un analisis de requisitos incorrecto 0incompleto, cuyos errores y deficiencias se detecten a la hora delas pruebas 0tras entregar el software a 1 cliente. Se tiene querepetir las fases de analisis, disefio y codificaci6n, que se habiarealizado cuidadosamente, pensando en el desarrollo delproducto final. Al repetir estas fases, se esta desechando una grancantidad de trabajo, normalmente superior a 1 esfuerzo deconstnur un prototipo basandose en un disefio rapido, en lareutilizaci6n de trozos de software preexistentes y enherramientas de generaci6n de c6digo para informes y manejo deventanas.

Uno d e los problemas que suelen aparecer siguiendo elparadigma de construcci6n de prototipos, es que con muchafrecuencia el prototipo pasa a ser parte del sistema final, bien seapor presiones del cliente, que quiere tener el sistema funcionando1 0 antes posible 0 bien porque los tecnicos se han acostumbradoa la maquina, el sistema operativo 0 el lenguaje con el que sedesarroll6 el prototipo. Se olvida que el prototipo ha sidoconstruido de forma acelerada, SID tener en euentaconsideraciones de eficiencia, calidad del software, facilidad de


57/73


mantenmuento, 0 que las elecciones de lenguaje, sistemaoperativo 0 maquina para desarrollarlo se han hecho basandoseen criterios como e 1 mejor conocimiento de esas herramientas porparte los tecnicos.

wando se utiliza el prototipo en el producto final seobservan los errores que este pudiera presentar.

3.2.6. El modelo en espiral.

El modelo en espiral combina la s principales ventajasdel modelo de ciclo de vida en cascada y del modelo deconstrucci6n de prototipos. Proporciona un modelo evolutivopara el desarrollo de sistemas de software cornplejos, muchom a s realista que el ciclo de vida clasico, y permite lautilizaci6n de prototipos en cualquier etapa de la evoluci6ndel proyecto. Este es un modelo relativamente nuevo (fuepropuesto en 1988) y no ha sido tan usado como los dosanteriores, aunque se esperar que se extienda cada vez m a s .

Otra caracteristica de este modelo es que incorpora ene l ciclo de vida el anllisis de riesgos. Los prototipos se utilizancomo mecanismo d e reducci6n del riesgo, pennitiendofinalizar el proyecto antes de haber iniciado e l desarrollo delproducto fina1.(Fig.3. 2.5. El modelo en espiral).

El modelo en espiral define cuatro tipos deactividades, y representa cada uno d e ellos en un cuadrante:

Planificacion,Consiste en determinar los objetivos del

proyecto, las posibles alternativas y las


58/73


restricciones. Esta fase equivale a la de recolecci6nde requisites del ciclo de vida clasico e incluyeadernas la planificaci6n de las actividades a realizaren cada iteraci6n.

Analisis de riesgo.Una de las actividades de la planificaci6n

de proyectos es el analisis de riesgos. El desarrollode cualquier proyecto complejo lleva implicito unaserie de riesgos, unos relativos al propio proyecto(los riesgos que pueden hacer que el proyectofracase) y otros relatives a las decisiones quedeben tomarse durante su desarrollo (los riesgosasociados a que una de estas decisiones seaerr6nea).

EI analisis de nesgo consiste en cuatro actividadesprincipales:

Identificar los riesgos. Pueden ser: riesgos delproyecto (presupuestarios, de organizaci6n, delcliente, otros) , riesgos tecnicos (problemas dedisefio, codificaci6n, mantenimiento), riesgos delnegoclO (de mercado: que se adelante lacompetencia 0que el producto no se venda bien).

Estimaci6n de riesgos. Consiste en evaluar, paracada riesgo identificado, la probabilidad de queocurra y las consecuencias.

Evaluaci6n de ries gos. Consiste en establecer losniveles de referencia para el incremento del costo,de duraci6n del proyecto y para 1 a degradaci6n de


59/73


la calidad que si se superan haran que seinterrumpa el proyecto. Luego se relacionacuantitativamente cada uno de los riesgos conestos niveles de referencia, de forma que encualquier momento del proyecto se pueda calcularsi ha superado alguno de los niveles de referencia.

Gestion de riesgos. Consiste en supervisar eldesarrollo del proyecto, de forma que se detectenlos nesgos tan pronto como aparezcan,intentando minimizar sus dafios y que exista unapoyo previsto para las tareas criticas.

Ingenieria.Consiste en el desarrollo del sistema 0 de

un prototipo del mismo. Evaluaci6n del cliente.

Consiste en la valoraci6n, por parte delcliente, de los resultados de la ingenierla.

En la primera iteraci6n se definen losrequisitos del sistema y se realiza la planificaci6ninicial del mismo. A continuaci6n se a n a l i z a n losriesgos del proyecto, basandonos en los requisitosiniciales y se procede a construir un prototipo delsistema. Entonces el cliente procede a evaluar elprototipo y con sus comentarios, se procede arefinar los requisitos ya reajustar la planificaci6ninicial, volviendo a empezar el ciclo ,

En cada una de las iteraciones se realiza elanalisis de riesgos, teniendo en cuenta losrequisitos y la reacci6n del cliente ante el Ultimo


60/73


prototipo. Si los riesgos son demasiado grandes seterrnina el proyecto, aunque 1 0 normal es que sesiga avanzando a 1 0 largo de la espiral.

Con cada iteracion, se construyensucesivas versiones del software, cada vez mascornpletas, y aurnenta la duracion de lasoperaClOnes del cuadrante de ingenieria,obteniendose al final el sistema de ingenieriacompleto.

La diferencia principal con el modelo deconstruccion de prototipos, es que en este losprototipos se usan para perfilar y definir losrequisitos. AI final, el prototipo se desecha ycomienza el desarrollo del software siguiendo elcido clas ico , En el modelo en espiral, en cambio,los prototipos son sucesivas versiones delproducto, cada vez m a s detalladas (e l Ultimo es elproducto en sQ y constituyen el esqueleto delproducto de ingenieria. Por tanto debenconstruirse siguiendo estandares de calidad.

3.2.7. Vision generics de la ingenieria del software.

Independientemente del paradigma que se utilice en el area deaplicacion y del tarnafio y la complejidad del proyecto, el proceso dedesarrollo de software contiene siempre una serie de fases genericas,existentes en todos los paradigmas. Estas fases son la definicion, eldesarrollo yel mantenimiento.


61/73


Definicion.La fase de definicion se centra en el que. Durante esta fase, se

intenta identificar:

Que informacion es la que debe ser procesada? Que funcion y rendimiento son los que se esperan? Que restricciones de disefio existen.? Que interfaces deben utilizarse? Que lenguaje de programacion, sistema operatrvo y soporte

hardware van a ser utilizados? Que criterios de validacion se necesitan para conseguir que el

sistema final sea correcto?

Aunque los pasos concretos dependen del modelo de cido devida utilizado, en general se realizaran tres tareas espedficas:

Analisis del sistema.Como ya hemos visto, el analisis del sistema define el

papel de cada elemento de un sistema informatico,estableciendo cual es el papel del software dentro de esesistema. .Analisis de requisitos del software.

El analisis del sistema proporciona el ambito delsoftware, su relacion con el resto de componentes del sistema,pero antes de empezar a desarro1lar es necesario hacer unadefinicion m a s detallada de 1 a funcion del software.

Existen dos forrnas de realizar el analisis yrefinamiento de los requisitos del software. Por una parte, sepuede hacer un analisis formal del ambito de la informacionpara establecer modelos del flujo y 1 a estructura de lainformacion. Luego se amplian unos modelos para


62/73


convertirlos en una especificaci6n del software. La otraalternativa consiste en construir un prototipo del software,que sera evaluado por el cliente para intentar consolidar losrequisites. Los requisitos de rendimiento y las limitaciones derecursos se traducen en directivas para la fase de disefio.

El analisis y definici6n de los requisitos es una tareaque debe llevarse a cabo conjuntamente por el desarrolladorde software y por el cliente. La especificaci6n d e requisites delsoftware es el documento que se produce como resultado deesta etapa. Planificacion del proyecto software.

Durante esta etapa se lleva a cabo el a na lisis deriesgos, se definen los recursos necesarios para desarrollar elsoftware y se establecen la s estimaciones de tiempo y costes.El prop6sito de esta etapa de planificaci6n es proporcionaruna indicaci6n preliminar de la viabilidad del. proyecto deacuerdo con e l coste y con la agenda que se hayan establecido.Posterionnente, la gesti6n del proyecto durante el desarrollodel mismo realiza y revisa el plan de proyecto de software.

Desarrollo.La fase de definici6n se centra en el como.

COmo ha de ser la arquitectura de la aplicaci6n? COmo han de ser las estructuras de datos? COmo han de implementarse los detalles de los

procedimientos de los m6dulos? COmo van a ser la s interfaces'

COmo ha de traducirse el disefio a un lenguaje deprogramaci6n?


63/73


COmo van a realizarse las pruebas?Aunque, al igual que antes, los pasos concretosdependen del modelo de ciclo de vida utilizado, en general se

realizaran cuatro tareas espedficas: Diseiio.

El disefio del software traduce los requisitos a unconjunto de representaciones (gcificas, en forma de tabla 0basadas en a l g U n . lenguaje apropiado) que describen como vana estructurarse los datos, cual va a ser la arquitectura de l aa pl ic ac io n, c ua l va a ser la estructura de cada programa ycomo van a ser las interfaces. Es necesario seguir criterios dedisefio que permitan asegurar la calidad del producto.

Finalizado el disefio es necesario revisarlo para asegurar lacompletitud yel cumplimiento de los requisitos del software. Codificaci6n.

En esta fase, el disefio se traduce a un lenguaje deprogramacion, dando como resultado un programa ejecutable.La buena calidad de los programas desarrollados depende engran medida de la calidad del disefio.

Una vez codificados los programas debe revisarse suestilo y claridad, y se comprue ba que haya. unacorrespondencia con la estructura de los mismos definida enla fase de disef io.

El listado fuente de cada modulo (0 el programafuente en soporte magnet ico) pasa a formar parte de laconfiguracion del sistema.

Pruebas.Implementado el software es preClSOprobarlo,

para detectar errores de codificacion, de disefio 0 de


64/73


especificaci6n. Las pruebas son necesarias para encontrarel mayor numero posible de errores antes de entregar elprograma al cliente.

Es necesario pro bar cada uno de los componentespor separado (cada uno de los modules 0 programas)para comprobar el rendimiento funcional de cada una deestas unidades.

A continuaci6n se procede a integrar loscomponentes para pro bar toda la arquitectura delsoftware, y probar su funcionamiento y las interfaces. Eneste punto hay que comprobar si se cumplen todos losrequisitos de la especificaci6n.

Se puede desarrollar un plan y procedimiento depruebas y guardar informaci6n sobre los casos de pruebasy los resultados de las mismas.

Garantia de cal idad .Terminada la fase de pruebas, el software esta casi

preparado para ser entregado a 1 cliente.

Mantenimiento.La fase de mantenimiento se centra en los

cambios que va a sufrir el software a 1 0 largo de su vidautil. Como dijo anterionnente, estos cambios puedendeberse a la correcci6n de errores, a cambios en elentomo inmediato del software 0 a cambios en losrequisitos del cliente, dirigidos normalmente a ampliar elsistema.

La fase de mantenimiento vuelve a aplicar lospasos de la s fases de definici6n y de desarrollo, pero en el


65/73

5 5La Automatizacion de los Procesos de Produccion en la Empresa

contexto de un software ya existente y enfuncionamiento(Figura 3.2.6. Diagrama de etapas de laIngenieria del Software).

3.2.8. Ingenierla inversa y reingenierla del software.

Los modelos descritos en las secciones antenores dan unavision directa de la IS como un proceso evolutivo en el que elsoftware pasa por etapas sucesivas de gestacion, construccion, uso ysustitucion, Sin embargo existen determinadas tareas dentro de la ISque obligan a realizar el camino inverso, 1 0 que ha llevado a acufiar eltermino de ingenieria inversa.

Como se vio en el tema anterior, en sus primeros tiempos, eincluso recientemente, el software se desarrollaba sin ningunaplanificacion, 1 0 que ha llevado a la existencia de numerosasaplicaciones actualmente en funcionamiento que carecen porcompleto de documentacion. Con el tiempo, y con la marcha de laspersonas que las han programado, desaparece por completo elconocimiento que se tiene sobre estas aplicaciones, y despues de afiosde procesamiento automatico de la informacion, incluso las personasque las maneJan desconocen cuales son exactamente lastransformaciones que realizan sobre los datos que mane j an ,

Esto causa graves problemas a la hora de intentar realizarcualquier cambio en estas aplicaciones, al intentar optimizarlas 0adaptarlas a para que funcionen sobre nuevos ordenadores, sistemasoperativos 0lenguajes 0a la hora de rescribirlas segun los nuevosestilos de trabajo con ordenador (primero fue 1 a entrada de datosinteractiva usando pantallas de texto, hoy son los entomos gcificosde ventanas).


66/73


La ingenieria inversaConsiste en analizar un programa en un esfuerzo derepresentarlo en un mayor nivel de abstraccion que el codigo

fuente, de forma que se extraiga informacion del disefio de datos,de la arquitectura y del detalle del procedimiento nusmo, parapoder entenderlo.

La reingenieria del software no solo recupera informacionsobre el disefio de un programa existente sino que utiliza estainformacion para reestructurar 0reconstruir el programa existente,con vistas a adaptarlo a un cambio, a ampliarlo 0a mejorar su calidadgeneral, con el objetivo de conseguir una mayor facilidad demantenimiento en el futuro (esto es 1 0 que se denominamantenimiento preventivo).

Existen herramientas CASE especializadas en ingenieriainversa y reingenieria, pero as! como las herramientas de ingenieria'normal' producen buenos resultados, estas son aun muyrudimentarias, estando muy limitados tanto su campo de aplicacioncomo los resultados que producen.

Utilizaci6n J

Fig. 2.1. Ciclo de vida clasico 0 en cascada


67/73


lReculecclfin de ..equisitos lstrategia de h,iseiio l Generaclfin de ~odigoPrueba l~i Utilizacion

/ J( Mantenim:ento I

/[' Sustltucifin, -, 1Fig. 2.3. Cido de vida usando tecnicas de cuarta generaci6n.

Ag. 2.4. Conatrucdlin de protolipos.


68/73


V is i6 n g en er ic a d e la In ge nie ria d el S oftw a re .Definic i6n. ~Que?Ana l is is d e l s is tema .E s t a b l e c e r e l c i t rb i t o d e l s if tw t r e .Analisis d e r eq u is ito s d el s is tem a s of tw a re .D e f in ic i6 n d e ta l l a d a d e fa f u n c i 6 n d e l s i ft w t re .Plani f i caci6n.A n c il i s is d e r U : s f f $ .A s i f ! j 1 t l C i O n d e r e a o s c s .D e f i n i c i O n d e tareas.E s t i m t c i 6 n d e ( ' ( F I R s .De sa rr ol lo . ~C6mo ?Disefio.A r q u i t a t u r a d e fa a p l i c a c i 6 n .E s truaum d e fa data.E struaura intema d e I C E pWi!!mrus.D i s e f i o d e l a s i n t e i f a c e s .Codi f i caci6n.Pruebas .Mantenimiento . E I camb io .Comai6n d e e r r o r e s .Otrrbia en e l entorno.Otrrbia en fa requisius.


69/73


CAPITULO IV

4. LA AUT OMAT IZACI ON DE LOS PROCESOS DEPRODUCCION , METODO DE SELECCION SI ESINDUSTRIAL

4.1 Automatizaci6n.Actualrnente, ningun estudio de procesos estaria completo sin

hacer referencia a la automatizacion, dado que la economia de lamecanizacion industrial es parte importante de los beneficios quehacen que cualquier industria sea rentable. La autornatizacion tienedos ramas: la primera se aplica al control de procesos, la segunda a laretroalimentacion de datos, con el fin de mantener el control deciertas variables que se relacionan con la produccion, Toda lasecuencia se coordina cuidadosamente con el fin de que las diversasoperaciones que la componen efectuen sus cidos en

Tesis La Automatizacion de Los Procesos de Produccion en La Empresa

Documents

Transcript of Tesis La Automatizacion de Los Procesos de Produccion en La Empresa