INGENIERIA DEL SOFTWARE APLICADO A SISTEMAS PRODUCTIVOS

1.- INTRODUCCIÓN.

La situación actual en los sistemas informáticos se caracteriza por una rápida evolución de los componentes hardware, que incrementan continuamente sus prestaciones manteniendo o incluso disminuyendo sus precios, junto con una fuerte tendencia a la estandarización (ordenadores personales, estaciones de trabajo con sistema operativo UNIX, sistemas distribuidos funcionando sobre plataformas heterogéneas, etc.) y una gran diversidad de marcas y modelos con prestaciones y precios similares. En este escenario, la potencia de los grandes ordenadores de las décadas pasadas está hoy disponible en un miniordenador e incluso en un ordenador personal. El software es el mecanismo que nos permite utilizar y explotar este potencial.

Esto hace que, a la hora de plantearnos la adquisición de un sistema informático completo, ya sea para gestionar una empresa, para controlar un proceso industrial, o para uso doméstico, el software es lo que marca la diferencia. Entre varios productos de características hardware similares, nos decidiremos por una determinada compañía vendedora basándonos en las prestaciones, inteligencia, calidad y facilidad de uso de su software.

Por otra parte, el desarrollo de software no es una tarea fácil. La complejidad actual de los sistemas informáticos hace a veces necesario el desarrollo de proyectos software de decenas de miles de líneas de código. Esto no puede ser abordado directamente, empezando a programar sin más. Es necesario analizar qué es lo que tenemos que hacer, cómo lo vamos a hacer, cómo se van a coordinar todas las personas que van a intervenir en el proyecto y cómo vamos a controlar el desarrollo del mismo de forma que al final obtengamos los resultados esperados.

Como vemos, el software es actualmente, dentro de cualquier sistema basado en el uso de ordenadores, el componente cuyo desarrollo presenta mayores problemas: es el más difícil de planificar, el que tiene mayor probabilidad de fracaso, y el que tiene menos posibilidades de que se cumplan las estimaciones de costes iniciales. Por otra parte, la demanda de software (y también la complejidad del software que se demanda) aumentan continuamente, lo que aumenta la magnitud de estos problemas.

De todas formas, no hay que ser demasiado catastrofistas. El desarrollo de software es una actividad muy reciente (apenas tiene 50 años), si la comparamos con otras actividades de ingeniería (p.ej. la construcción de puentes o incluso la ingeniería eléctrica, de la que deriva la ingeniería de hardware), y la disciplina que se encarga de establecer un orden en el desarrollo de sistemas de software (esto es, la Ingeniería del Software) es aún más reciente. Existen buenos métodos de desarrollo de software pero quizás el problema esté en que no están lo suficientemente difundidos o valorados. Sólo recientemente, estas técnicas están logrando una amplia aceptación.

2.- EVOLUCIÓN DE LA INDUSTRIA DEL SOFTWARE.

Hemos dicho que el software era el factor decisivo a la hora de elegir entre varias soluciones informáticas disponibles para un problema dado, pero esto no ha sido siempre así. En los primeros años de la informática, el hardware tenía una importancia mucho mayor que en la actualidad. Su coste era comparativamente mucho más alto y su capacidad de almacenamiento y procesamiento, junto con su fiabilidad, era lo que limitaba las prestaciones de un determinado producto. El software se consideraba como un simple añadido, a cuyo desarrollo se dedicaba poco esfuerzo y no se aplicaba ningún método sistemático. La programación era un arte de andar por casa, y el desarrollo de software se realizaba sin ninguna planificación. La mayoría del software se desarrollaba y era utilizado por la misma persona u organización. La misma persona lo escribía, lo ejecutaba y, si fallaba, lo depuraba. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estaría allí cuando se encontrara algún error. Debido a este entorno personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien y la documentación normalmente no existía.

En este contexto, las empresas de informática se dedicaron a mejorar las prestaciones del hardware, reduciendo los costes y el consumo de los equipos, y aumentando la velocidad de cálculo y la capacidad de almacenamiento. Para ello, tuvieron que dedicar grandes esfuerzos a investigación y aplicaron métodos de ingeniería industrial al análisis, diseño, fabricación y control de calidad de los componentes hardware. Como consecuencia de esto, el hardware se desarrolló rápidamente y la complejidad de los sistemas informáticos aumentó notablemente, necesitando de un software cada vez más complejo para su funcionamiento. Surgieron entonces las primeras casas de software, y el mercado se amplió considerablemente. Con ello aumentó la movilidad laboral, y con la marcha de un trabajador desaparecían las posibilidades de mantener o modificar los programas que éste había desarrollado.

Al no utilizarse metodología alguna en el desarrollo del software, los programas contenían numerosos errores e inconsistencias, lo que obligaba a una depuración continua, incluso mucho después de haber sido entregados al cliente. Estas continuas modificaciones no hacían sino aumentar la inconsistencia de los programas, que se alejaban cada vez más de la corrección y se hacían prácticamente ininteligibles. Los costes se disparaban y frecuentemente era más rápido (y por tanto más barato) empezar de nuevo desde cero, desechando todo el trabajo anterior, que intentar adaptar un programa preexistente a un cambio de los requisitos. Sin embargo, los nuevos programas no estaban exentos de errores ni de futuras modificaciones, con lo que la situación volvía a ser la misma. Había comenzado la denominada crisis del software.

Hoy en día, la distribución de costes en el desarrollo de sistemas informáticos ha cambiado drásticamente. El software, en lugar del hardware, es el elemento principal del coste. Esto ha hecho que las miradas de los ejecutivos de las empresas se centren en el software y a que se formulen las siguientes preguntas:

• ¿ Por qué lleva tanto tiempo terminar los programas ?

• ¿ Por qué es tan elevado el coste ?

• ¿ Por qué no es posible encontrar todos los errores antes de entregar el software al cliente ?

• ¿ Por qué resulta tan difícil constatar el progreso conforme se desarrolla el software ?

Estas y otras muchas preguntas son una manifestación del carácter del software y de la forma en que se desarrolla y han llevado a la aparición y la adopción paulatina de la ingeniería del software.

3.- CARACTERÍSTICAS DEL SOFTWARE.

Una definición de software podría ser la siguiente:

Software: (1) instrucciones de ordenador que cuando se ejecutan proporcionan la función y el comportamiento deseado, (2) estructuras de datos que facilitan a los programas manipular adecuadamente la información, y (3) documentos que describen la operación y el uso de los programas.

Por tanto, el software incluye no sólo los programas de ordenador, sino también las estructuras de datos que manejan esos programas y toda la documentación que debe acompañar al proceso de desarrollo, mantenimiento y uso de dichos programas.

Según esto, el software se diferencia de otros productos que los hombres puedan construir en que es, por su propia naturaleza lógico. En el desarrollo del hardware, el proceso creativo (análisis, diseño, construcción, prueba) se traduce finalmente en una forma material, en algo físico. Por el contrario, el software es inmaterial y por ello tiene unas características completamente distintas al hardware. Entre ellas podemos citar:

3.1.- El software se desarrolla, no se fabrica en sentido estricto.

Existen similitudes entre el proceso de desarrollo del software y el de otros productos industriales, como el hardware. En ambos casos existen fases de análisis, diseño y desarrollo o construcción, y la buena calidad del producto final se obtiene mediante un buen diseño. Sin embargo, en la fase de producción del software pueden producirse problemas que afecten a la calidad y que no existen, o son fácilmente evitables, en el caso del software

Por otro lado, en el caso de producción de hardware a gran escala, el coste del producto acaba dependiendo exclusivamente del coste de los materiales empleados y del propio proceso de producción, reduciéndose la repercusión en el coste de las fases de ingeniería previas. En el software, el desarrollo es una más de las labores de ingeniería, y la producción a gran o pequeña escala no influye en el impacto que tiene la ingeniería en el coste, al ser el producto inmaterial. Por otro lado, la replicación del producto (lo que sería equivalente a la producción del producto hardware) no presenta problemas técnicos, y no se requiere un control de calidad individualizado.

3.2.- El software no se estropea.

Podemos comparar las curvas de índices de fallos del hardware y el software en función del tiempo. En el caso del hardware (figura 1.1), se tiene la llamada curva de bañera, que indica que el hardware presenta relativamente muchos fallos al principio de su vida. Estos fallos son debidos fundamentalmente a defectos de diseño o a la baja calidad inicial de la fase de producción. Una vez corregidos estos defectos, la tasa de fallos cae hasta un nivel estacionario y se mantiene así durante un cierto periodo de tiempo. Posteriormente, la tasa de fallos vuelve a incrementarse debido al deterioro de los componentes, que van siendo afectados por la suciedad, vibraciones y la influencia de muchos otros factores externos. Llegados a este punto, podemos sustituir los componentes defectuosos o todo el sistema por otros nuevos, y la tasa de fallos vuelve a situarse en el nivel estacionario.

Figura. 1.1. Curva de fallos del hardware

El software no es susceptible a los factores externos que hacen que el hardware se estropee. Por tanto la curva debería seguir la forma de la figura 1.2. Inicialmente la tasa de fallos es alta, debido a la presencia de errores no detectados durante el desarrollo, los denominados errores latentes. Una vez corregidos estos errores, la tasa de fallos debería alcanzar el nivel estacionario y mantenerse ahí indefinidamente.

Figura 1.2. Curva ideal de fallos del software

Pero esto no es más que una simplificación del modelo real de fallos de un producto software. Durante su vida, el software sufre cambios, debidos al mantenimiento. El mantenimiento puede deberse a la corrección de errores latentes o a cambios en los requisitos iniciales del producto. Conforme se hacen cambios es bastante probable que se introduzcan nuevos errores, con lo que se producen picos en la curva de fallos.

Estos errores pueden corregirse, pero el efecto de los sucesivos cambios hace que el producto se aleje cada vez más de las especificaciones iniciales de acuerdo a las cuales fue desarrollado, conteniendo cada vez más errores latentes. Además, con mucha frecuencia se solicita - y se emprende - un nuevo cambio antes de haber conseguido corregir todos los errores producidos por el cambio anterior.

Por estas razones, el nivel estacionario que se consigue después de un cambio es algo superior al que el que había antes de efectuarlo (figura 1.3.), degradándose poco a poco el funcionamiento del sistema. Podemos decir entonces que el software no se estropea, pero se deteriora.

Figura 1.3. Curva real de fallos del software

Además, cuando un componente software se deteriora, no podemos sustituirlo por otro, como en el caso del hardware: no existen piezas de repuesto. Cada fallo del software indica un fallo en el diseño o en el proceso mediante el cual se transformó el diseño en código máquina ejecutable. La solución no es sustituir el componente defectuoso por otro (que sería idéntico y contendría los mismos errores) sino un nuevo diseño y desarrollo del producto. Por tanto, el mantenimiento del software tiene una complejidad mucho mayor que el mantenimiento del hardware.

3.3.- La mayoría del software se construye a medida.

El diseño de hardware se realiza, en gran medida, a base de componentes digitales existentes, cuyas características se comprueban en un catálogo y que han sido exhaustivamente probados por el fabricante y los usuarios anteriores. Estos componentes cumplen unas especificaciones claras y tienen unas interfaces definidas.

El caso del software es bien distinto. No existen catálogos de componentes, y aunque determinados productos como sistemas operativos, editores, entornos de ventanas y bases de datos se venden en grandes ediciones, la mayoría del software se fabrica a medida, siendo la reutilización muy baja. Se puede comprar software ya desarrollado, pero sólo como unidades completas, no como componentes que pueden ser reensamblados para construir nuevos programas. Esto hace que el impacto de los costes de ingeniería sobre el producto final sea muy elevado, al dividirse entre un número de unidades producidas muy pequeño.

Se ha escrito mucho sobre reutilización del software, y han sido muchos los intentos para conseguir aumentar el nivel de reutilización, normalmente con poco éxito. Uno de los ejemplos de reutilización más típicos, que ha venido usándose desde hace tiempo, son las bibliotecas. Durante los años sesenta se empezaron a desarrollar bibliotecas de subrutinas científicas, reutilizables en una amplia gama de aplicaciones científicas y de ingeniería. La mayor parte de los lenguajes modernos incluyen bibliotecas de este tipo, así como otras para facilitar la entrada/salida y más recientemente los entornos de ventanas. Sin embargo esta aproximación no puede aplicarse fácilmente a otros problemas también de uso muy frecuente, como puede ser la búsqueda de un elemento en una estructura de datos, debido a la gran variación que existe en cuanto a la organización interna de estas estructuras y en la composición de los datos que contienen. Existen algoritmos para resolver estos problemas, pero no queda más remedio que programarlos una y otra vez, adaptándolos a cada situación particular.

Un nuevo intento de conseguir la reutilización se produjo con la utilización de técnicas de programación estructurada y modular. Sin embargo, se dedica por lo general poco esfuerzo al diseño de módulos lo suficientemente generales para ser reutilizables, y en todo caso, no se documentan ni se difunden todo lo que sería necesario para extender su uso, con lo que la tendencia habitual es diseñar y programar módulos muy semejantes una y otra vez. La programación estructurada permite diseñar programas con una estructura más clara, y que, por tanto, sean más fáciles de entender. Esta estructura interna más clara y estudiada, permite la reutilización de módulos dentro de los programas, o incluso dentro del proyecto que se está desarrollando, pero la reutilización de código en proyectos diferentes es muy baja.

La última tendencia para conseguir la reutilización es el uso de técnicas orientadas a objetos, que permiten la programación por especialización. Los objetos, que encapsulan tanto datos como los procedimientos que los manejan - los métodos -, haciendo los detalles de implementación invisibles e irrelevantes a quien los usa, disponen de interfaces claras, los errores cometidos en su desarrollo pueden ser depurados sin que esto afecte a la corrección de otras partes del código y pueden ser heredados y reescritos parcialmente, haciendo posible su reutilización aún en situaciones no contempladas en el diseño inicial.

4.- CALIDAD DEL SOFTWARE.

A la hora de definir la calidad del software se debe diferenciar entre la calidad del producto software y la calidad del proceso de desarrollo de éste (calidad de diseño y fabricación). No obstante, las metas que se establezcan para la calidad del producto van a determinar los objetivos a establecer de calidad del proceso de desarrollo, ya que la calidad del primero va a depender, entre otros aspectos, de ésta. Sin un buen proceso de desarrollo es casi imposible obtener un buen producto. Este proceso constituye el objeto del presente trabajo.

Pero la calidad del producto software se diferencia de la calidad de otros productos de fabricación industrial, ya que el software tiene sus propias características específicas:

El software es un producto mental, no restringido por las leyes de la Física o por los límites de los procesos de fabricación. Es algo abstracto, un intangible.

Se desarrolla, no se fabrica. El coste está fundamentalmente en el proceso de diseño, no en la posterior producción en serie, y los errores se introducen también en el diseño, no en la producción.

Los costes del desarrollo de software se concentran en las tareas de Ingeniería, mientras que en la fabricación clásica los costes se acentúan más en las tareas de producción.

El software no se deteriora con el tiempo. No es susceptible de los efectos del entorno y su curva de fallos es muy diferente de la del hardware. Todos los problemas que surjan durante el mantenimiento estaban allí desde el principio y afectan a todas las copias del mismo; no se generan nuevos errores.

Es artesanal en gran medida. El software, en su mayoría, se construye a medida, en vez de ser construido ensamblando componentes existentes y ya probados, lo que dificulta aún más el control de su calidad.

El mantenimiento del software es mucho más complejo que el mantenimiento del hardware. Cuando un componente del hardware se deteriora se sustituye por una pieza de repuesto, pero cada fallo en el software implica un error en el diseño o en el proceso mediante el cual se tradujo el diseño en código máquina ejecutable.

Es engañosamente fácil realizar cambios sobre un producto software, pero los efectos de estos cambios se pueden propagar de forma explosiva e incontrolada.

Como disciplina, el desarrollo de software es aún muy joven, por lo que las técnicas de las que dispone aún no están perfeccionadas.

El software con errores no se rechaza. Se asume que es inevitable que el software presente algunos errores de poca importancia.

También es importante destacar que la calidad de un producto software debe ser considerada en todos sus estados de evolución (especificaciones, diseño, códigos,...). No basta con verificar la calidad del producto una vez finalizado cuando los problemas de mala calidad ya no tienen solución o su reparación es muy costosa.

4.1. La problemática general a la que se enfrenta el software es:

• Aumento constante del tamaño y complejidad de los programas.

• Carácter dinámico e iterativo a lo largo de su ciclo de vida, es decir que los programas de software a lo largo de su vida cambian o evolucionan de una versión a otra para mejorar las prestaciones con respecto a las anteriores.

• Dificultad de conseguir productos totalmente depurados, ya que en ningún caso un programa será perfecto.

• Se dedican elevados recursos monetarios a su mantenimiento, debido a la dificultad que los proyectos de software entrañan y a la no normalización a la hora de realizar los proyectos.

• No suelen estar terminados en los plazos previstos, ni con los costes estipulados, ni cumpliendo los niveles deseables de los requisitos especificados por el usuario.

• Incrementos constantes de los costes de desarrollo debido entre otros, a unos niveles de productividad bajos.

• Los clientes tienen una alta dependencia de sus proveedores por ser en muchos casos aplicaciones a "medida".

• Procesos artesanales de producción con escasez de herramientas.

• Insuficientes procedimientos normalizados para estipular y evaluar la productividad, costes, y calidad.

Todo lo anterior puede concretarse en:

Ausencia de especificaciones completas, coherentes y precisas previas por parte del cliente, así como posteriores por parte de los proveedores del software.

Ausencia de la aplicación sistemática de métodos, procedimientos y normas de ingeniería del software.

Escasez o ausencia de entornos integrados de programación.

Escasez de uso de técnicas actuales y automatizadas para la gestión de proyectos.

Escasez de personal con formación y experiencia en los nuevos métodos, normas y uso de entornos y utilidades de programación.

Otros derivados del grado de desarrollo técnico y organizativo de cada compañía.

4.2. La calidad a través de la normalización en la ingeniería del software y su problemática.

La normalización consiste en un proceso donde se elaboran guías, normas y convenciones sobre una determinada materia, con el objeto de definir, simplificar y especificar las actividades relacionadas con la materia de que se trate.

La Ingeniería del Software (IS) se ha ido desarrollando en los últimos 15 años, a través de la creación e implantación en la industria software de métodos, procedimientos, técnicas y útiles que tratan de cubrir las necesidades de cada una de las etapas del ciclo de vida de un producto software, desde la definición de sus requisitos hasta su mantenimiento una vez el producto comience a emplearse. Y ello con las restricciones generales de todos los procesos modernos de ingeniería, esto es, la necesidad creciente de incrementar la productividad de la programación mejorando y garantizando, simultáneamente la calidad del producto resultante.

La creación e implantación de normas de desarrollo del software son un autentico desafío que tiene la IS como medio de comunicación para transferir sus métodos, técnicas y procedimientos a la industria del software para el diseño y desarrollo de nuevos productos. Estas normas tienen como criterio general de desarrollo maximizar la comunicación entre los profesionales del software a través de la definición de documentos generales que se han de producir, proveyendo de guías que indican a nivel de detalle el contenido de dichos documentos y recomendaciones de las actividades que hay que realizar durante todo el proceso de producción del software. En pocas palabras, las normas de IS son la solución a una de las mayores necesidades de la industria del software actual: la comunicación mas adecuada y precisa entre sus profesionales.

A medida que ha ido aumentando la necesidad de un software más fiable, se ha reconocido que las normas de ingeniería del software (NIS) son una contribución fundamental para asegurar la producción de software de calidad. Además una consecuencia del objetivo genérico de mejorar la comunicación es que se reducen los costes por un aumento de productividad y una mejora de la calidad de los desarrollos de software.

En relación a las normas los profesionales se encuentran con un problema fundamental: la dispersión de las normas relativas a1 software que, con frecuencia, han sido creadas por organismos muy diversos, bajo enfoques distintos y destinadas a ámbitos de actuación diferentes. Muchas compañías, por su parte, se han visto obligadas a generar sus propias normas cuando no disponen de unas de ámbito general. De hecho muchas organizaciones desarrollan sus propios conjuntos de normas adecuándolas a sus fines específicos. Pero también se dan casos en que organizaciones distintas tienen los mismos objetivos por lo que resultaría razonable su colaboración y, en todo caso, la adopción de las normas de la organización que tenga más avanzados sus desarrollos y un ámbito de actuación más amplio. Puede afirmarse que en la actualidad se ha llegado a un nivel de madurez en la industria del software que ha permitido a todos 1os implicados que exista un interés por aunar sus experiencias y esfuerzos para crear normas generales que abarquen sus áreas de interés.

Estos esfuerzos varían en cuanto al tipo de industrias o usuarios así como en lo relativo a los logros alcanzados, pero la tendencia actual es hacia la normalización de1 proceso de desarrollo software a través de normas que conduzcan a homogeneizar los planes de garantía de calidad de él, los planes de gestión de la configuración del software, la documentación de sus pruebas, etc.

5.- SISTEMAS DE PRODUCCIÓN.

Para nuestros estudios diremos que la producción es el acto intencional de producir algo útil. De ninguna manera limita el método por el cual algo se produce, pero elimina la generación accidental de productos. La definición de producción se modifica para incluir el concepto de sistema, diciendo que un sistema de producción es el proceso específico por miedo del cual los elementos se transforman en productos útiles. Un proceso es un procedimiento organizado para lograr la conversión de insumos en resultados.

Una unidad de producción normalmente requiere de varios tipos de insumos. En un proceso industrial los insumos dan cuenta de la mayor parte del costo variable de producción. Los medios de conversión están asociados con el costo fijo, y la producción con los ingresos. La utilidad depende de la relación de los costos variables y fijos, con respecto a los ingresos, es decir, de la interacción de costos de insumo y de conversión con los ingresos obtenidos a base de la producción.

Cualquier sistema es una colección de componentes interactuales; el objetivo de un sistema podría ser producir un componente que se va a ensamblar con otros componentes para alcanzar el objetivo que es un sistema mayor.

5.1. Modelos De Sistemas De Producción.

Un modelo es una réplica o abstracción de las características esenciales de un proceso. Muestra las relaciones entre causa y efecto, entre objetivos y restricciones. Problemas que no se pueden resolver por medio de soluciones directas debido a su magnitud, complejidad o estructura, a menudo se pueden manejar, buscando una solución aproximada por medio de modelos de simulación. La naturaleza del problema indica cuáles de los siguientes tipos de modelos es el mas apropiado.

Modelo físico. Son modelos que derivan su utilidad de un cambio en la escala. Los patrones microscópicos pueden amplificarse para su investigación, y las enormes estructuras pueden hacerse a una escala más pequeña, hasta una magnitud que sea manipulable. Los problemas de flujo en una planta modelo se estudian fácilmente con las estructuras y máquinas hechas a una escala pequeña, haciendo cambios que no podrían duplicarse con partes reales debido al costo, confusión o inconveniencia. Necesariamente, algunos detalles se pierden en los modelos. En las réplicas físicas, ésta pérdida puede ser una ventaja, cuando la consideración clave, es un factor, tal como la distancia, pero puede hacer inútil un estudio si la influencia predominante se devirtúa en la construcción del modelo.

Modelo esquemático. Las gráficas de fluctuaciones en los precios, los diagramas simbólicos de las actividades, los mapas de rutas y las redes de eventos regulados, todos representan el mundo real en un formato dirigido y diagramático. Los aspectos gráficos son útiles para pronósticos de demostración. Algunos ejemplos que se encuantran comúnmente incluyen los diagramas de la organización, diagramas de flujo del proceso y gráficas de barras. Los símbolos sobre tales diagramas, pueden arreglarse fácilmente para investigar el efecto de la reorganización. Una experimentación semejante en el lugar real de trabajo podría ser dañino.

Modelo matemático. Las expresiones cuantitativas, es decir, los modelos más abstractos, generalmente son las más útiles. Cuando un modelo matemático puede construirse para representar en forma exacta la situación de un problema, suministra una poderosa arma para el estudio; es fácil de manipular, el efecto de las variables interactuantes se aprecia claramente y, sobre todo, es un modelo preciso. Por lo general, cualquier deficiencia debida al empleo de los modelos matemáticos se origina por algún error cometido en las suposiciones básicas y en las premisas sobre las cuales están basadas. En contraste con los otros tipos de modelos, es más difícil decidir lo que se va a emplear que cómo se va a emplear.

5.2 Ventajas que tienen diseñar los sistemas de producción

El diseño de sistemas de producción es algo esencial en la empresa, ya que maneja todos los departamentos de esta, así llevando un control de costos, control de inventarios, control de la producción, control de procesos, control de calidad.

Los diseños de producción deben utilizarse siempre, es decir, no solamente durante la implementación de los mismos, para luego destacarlos, ni archivarse en un estante para que acumulen polvo y se vuelvan obsoletos. Los costos del proceso de reingenieria son demasiado altos y los diseños demasiado valiosos.

Los diseños y los modelos de reingeniería se utilizan obviamente para respaldar los esfuerzos futuros en este campo. Si se implementa una iniciativa de calidad total, la compañía necesitara cambiar sus procesos sobre una base común cuando las mejoras se implanten. Como una medida de control, estas actividades deben desarrollarse siguiendo los métodos de reingeniería y toda la documentación debe actualizarse.

Los diseños contienen información que puede ser útil en la toma de decisiones operacionales habituales, en el entrenamiento y en el control del desempeño laboral.

5.2 Que visión del futuro les da a las empresas los diseños de sistemas de producción

.Le da la habilidad de que entrar al mercado junto con otras compañías.

.Habilidad de los proveedores para ejercer una presión sobre los costos de los competidores el mercado.

.La habilidad de los clientes para influir en los competidores, por ejemplo, si son sensibles a los precios, los clientes forzaran la competencia precios.

.La habilidad de las alternativas para presionar al mercado.

.Las actividades competitivas de las compañías más rivales.

6.- ALGUNOS DE SISTEMAS DE PRODUCCIÓN.

6.1 Sistemas empujar

Los sistemas empujar, tienen una componente técnica, al igual que los conceptos administrativos esenciales. La componente técnica se refiere a la manera en que se mandan los trabajos al sistema de producción y su flujo a través del sistema. Se determina una fecha de entrega para cada trabajo, ya sea a partir de mercadotecnia de su siguiente operación. Los trabajos se mandan a una fecha de inicio, que es la fecha de entrega menos el tiempo de entrega. Se hace notar que el tiempo de entrega es un parámetro de planeación determinístico. El tiempo de flujo es un tiempo real que toma el material en atravesar el sistema de producción; es variable y se quiere reducir esa variabilidad cuanto sea posible. Una vez enviado el trabajo, fluye de una operación a otra a través del sistema de producción sin importar lo que pase delante de él. De aquí el término “empujar” para este método; se empujan los trabajos a través del sistema de producción. Otro nombre para los sistemas de empujar, es sistemas basados en el programa, ya que el programa empuja la producción.

6.2 Sistemas Jalar.

De la misma manera que los sistemas empujar, los sistemas jalar tienen una componente técnica y un concepto administrativo. La componente técnica es un derivado de una técnica de control de la producción desarrollada en Toyota Motor company en Japón, a principios de los sesenta. La técnica se dio a conocer como el sistema de producción Toyota. El objetivo es proporcionar una técnica de control sencilla que reduzca el tiempo de entrega y el trabajo en proceso. Kanban, la palabra japonesa para tarjeta, es la herramienta original que se uso para lograr estos objetivos. Este enfoque resalta la habilidad de Toyota para cumplir con la demanda de sus clientes de los diferentes modelos de automóviles con un retraso mínimo.

Existe una diferencia sutil entre los sistemas empujar y los sistemas jalar. Un sistema empujar controla el envío de las órdenes de trabajo, mientras que el sistema jalar controla la planta. Para ser más específicos, los sistemas empujar controlan la producción y miden el trabajo en proceso mientras que los sistemas jalar controlan el trabajo en proceso y miden la producción.

Al pasar el tiempo, la técnica jalar evolucionó a un concepto administrativo mucho mas amplio. Con frecuencia se le da el nombre de justo al tiempo “JIT” o sistema JIT integrado. Este ya no es un sistema de producción para fabricar el tipo de unidades necesarias, en el tiempo necesario y en las cantidades necesarias, nmas bien es un concepto que debe adoptarse. Abarca no sólo a los sistemas de producción, sino a los clientes y los proveedores junto con el control de calidad y del flujo del trabajo. El alcance se amplia para incluir del desperdicio de cualquier tipo o forma como inventarios, productos defectuosos, entregas retrasadas, tiempos de entrega largos y más. Esto hace que el JIT integrado sea una parte de una estrategia de negocios corporativa.

6.3 Sistemas Kanban

En un sentido mas amplio es una señal de comunicación de un cliente a una productor. Como tal es un sistema de información manual para controlar la producción, el transporte de materiales y el inventario.

6.4 Sistemas de tarjeta dual

El sistema tiene dos ciclos de control. Un ciclo para controlar la operación de la célula, y un ciclo para controlar la transferencia de material entre los centros de trabajo.

Sistema de una sola tarjeta

Un sistema de una tarjeta es una combinación del control de empujar para la producción y un control de jalar para las entregas. Tal vez el inventario sea mas alto en este sistema, ya que la producción esta controlada por el programa. Estos sistemas operan bien cuando el tiempo de producción es corto, y es posible crear un programa de producción detallado.

6.5 Modelos CONWIP

CONWIP viene de trabajo en proceso constante (constant working process). Este es un enfoque de sistemas jalar. Los sistemas Kanban funcionan mejor con un flujo uniforme, una característica muy estable para el desarrollo de un sistema que posee los beneficios de un sistema jalar, pero se pueden usar en una gran variedad de sistemas de manufactura.

Para describir CONWIP, se supone una sola línea de producción, donde las partes se mueven en contenedores y cada uno de ellos contiene prácticamente la misma cantidad de contenido de trabajo. Esto asegura que el tiempo de procesado en cada estación de trabajo será mas o menos el mismo. Igual que el Kanban, CONWIP se basa en una señal de información (por tarjetas, electrónica o con los mismos contenedores). La tarjeta se fija al contenedor al principio de la línea y viaja con él hasta el final. En ese punto , se quita la tarjeta del contenedor al principio de la línea y viaja con él hasta el final. En este punto se quita la tarjeta del contenedor y se regresa a una línea de espera o cola de tarjetas al principio de la línea . Eventualmente , la tarjeta dejará la cola, también llamadas lista de faltantes y se fijará a otro contenedor de partes , con el fin de viajar por la línea de producción otra vez.

7.- PLANEACIÓN DE LA DISTRIBUCIÓN COMPUTARIZADA

La planeación de distribución computarizada para las instalaciones de procesos intermitentes ha evolucionado desde 1963 cuando se desarrolló CRAFT, el primer programa práctico. Hoy en día, según el catálogo del Center for Environmental Research, se dispone aproximadamente de 80 programas de computadora. Se examinarán dos programas conocidos: CRAH, para lo criterios cuantitativos y ALDEP para los cualitativos.

CRAFT (Computerizad Relative Allocation of Facilities - Asignación relativa de instalaciones computarizada-. CRAPT fue desarrollado por Armour y Bufla y después perfeccionado por ellos mismos y Vollmann. Utiliza una formulación de distribución por criterios cuantitativos y puede resolver problemas de hasta 40 departamentos o centros de actividad.

Los datos para CRAFT son una matriz de costos unitarios y una de distribución inicial. La matriz de costos unitarios es el producto de las matrices Tij y Cij antes descritas. El plan de distribución inicial puede ser uno existente o uno inicial arbitrario. Después, mediante el uso de la distribución inicial que se le proporcional la computadora determina las distancias entre los centroides de los departamentos.

El siguiente paso del programa es calcular el costo de la distribución inicial mediante el uso de la matriz de costo unitario y de las distancias calculadas en la distribución inicial.

El programa CRAFT determina entonces si el costo total inicial puede reducirse mediante el intercambio de departamentos en pares. Cada posible par de departamentos se cambia y se calcula el costo, ya sea en incremento o en disminución y se almacena en la memoria de la computadora. Una vez considerados todos los pares de intercambio, se selecciona el intercambio con el menor costo y se cambian estos departamentos en el diseño inicial. Si se reduce el costo, se imprimen el costo resultante y el diseño nuevo y se repite el procedimiento para un segundo intercambio de departamentos. Se imprime un nuevo diseño y costo inferior en cada ronda sucesiva de intercambios hasta que ya no se obtenga reducción de costos adicional.

Con frecuencia, la solución final a la que llega CRAFT depende de loS datos del diseño inicial. Es decir, para reducir el efecto de las desviaciones se deben seleccionar varios diagramas iniciales diferentes. CRAFT no proporciona una solución de costo mínimo. CRAFT es un programa heurístico que da una solución muy buena aunque no una solución que se garantice como la óptima. Sin embargo, en la práctica la falta de una solución verdaderamente óptima, no es una limitación muy seria (cualquier mejora sobre la distribución presente o sobre otros métodos de distribución resulta útil).

CRAFT fue aplicado en la práctica a un gran número de distintos problemas de diseño diferente. De acuerdo con Buffa, lo han utilizado cuatro plantas constructoras de aeronaves, dos de las compañías automotrices más grandes, dos operaciones de fabricación de computadoras, un fabricante de productos farmacéuticos, una empacadora de carne, una tienda de máquinas de precisión, un estudio cinematográfico y un hospital. Como el programa tiene amplia circulación, no es de dudarse que se haya utilizado también para otras aplicaciones.

ALDEP (Automated Layout Design Prograin - Programa de diseño de la dis-tribución automatizado-. ALDEP lo desarrolló IBM en 1967 y fue originalmente descrito por Seehof y Evans (1967). El programa ALDBP solamente maneja problemas de distribución con criterios cualitativos.

Los datos para ALDEP incluyen una matriz de relaciones y limitaciones como tamaño del edificio, ubicaciones fijas para departamentos, escaleras, etc. El programa ALDEP comienza por seleccionar al azar un departamento y lo coloca en el plan de distribución. En el segundo plan se revisan todos los departamentos restantes y solamente se selecciona al azar uno que tenga una calificación de relación de alta cercanía (como A o E) y se coloca en la distribución cerca del primer departamento. Si no puede encontrar una calificación de alta cercanía, se selecciona un departamento al azar y se coloca en la distribución. Este proceso de selección continúa hasta que se han colocado todos los departamentos en el plan de distribución. Se calcula entonces una calificación total para el diagrama mediante la conversión de cada relación de cercanía a una escala numé-rica y sumando los valores de estas relaciones en el plan de distribución. Se repite varias veces todo el proceso y como primer paso en cada ocasión se comienza con un departamento diferente que es seleccionado al azar. Cada interacción da como resultado la generación de un plan de distribución.

El programa ALDEP es útil para generar un gran número de buenas distribuciones para su revisión. El programa puede controlarse para que solamente se impriman las distribuciones que tengan una calificación especificada o mayor a ésta. Esta tiene el efecto de reducir el número de diagramas que se tienen que revisar. Aunque ALDEP es un programa heurístico útil para generar buenos diseños, sólo produce soluciones óptimas por accidente.

ALDEP ahorra mucho del trabajo tedioso que implica la distribución, sin embargo, aún se requiere un juicio para llegar a la solución final. El programa ALDEP esta diseñado para manejar hasta 63 departamentos y un edificio de 3 pisos.

8.- COMPUTADORAS Y AUTOMATIZACIÓN EN EL DISEÑO DEL SISTEMA

Un sistema de información gerencial debe establecerse para proveer de capacidades de vigilancia sobre las actividades dentro de las redes de flujo de recursos. La geren­cia moderna de producción y operaciones usa ampliamente computadoras y auto­matización en estos sistemas, y la tecnología y conceptos asociados se desarrollarán en este capitulo.

8.1 Hardware

Se ha desarrollado mucha jerigonza en el campo de la computación; a través de este capítulo, esta jerga se usará y definirá al irse sucediendo. El término hardware se re­fiere a los aspectos físicos de los aparatos o equipos. Los usos del hardware incluyen la conversión de datos primos a una forma aceptable de entrada para la computado­ra; alimentar los datos a la computadora; transferir los datos e instrucciones de un lugar a otro dentro de la computadora y los instrumentos de control. El hardware incluye a la computadora en sí, los aparatos de almacenamiento externo (como cin­tas, discos y tambores magnéticos) y el equipo de entrada-salida (como las lectoras de tarjetas, impresoras y terminales).

8.2 Unidad Central De Proceso

La unidad central de procesamiento (CPU, siglas del inglés: Central Processing Unit) es el corazón del sistema de computación. Contiene la memoria principal, la unidad aritmética / lógica y la unidad de control. La memoria principal, en ocasiones un núcleo magnético de memoria semiconductiva, se usa para procesar los datos e instrucciones internamente durante el ciclo de procesamiento. La unidad aritmética-lógica proporciona la capacidad de cálculo y la habilidad de la computadora de ra­mificarse lógicamente a través de redes elaboradas de procesos alternativos. La uni­dad de control controla la entrada y salida, así como la secuencia de cálculos y el tiempo durante el Proceso.

8.3 Software

En términos generales, el software puede definirse como el grupo de instrucciones a la computadora, las cuales pueden utilizarse para dirigir automáticamente su opera­ción hacia objetivos específicos. Pueden clasificarse como sigue:

Lenguajes de programación y compiladoras.

Subrutinas.

Generadores de programas de reportes.

Programas de aplicaciones estándar.

Sistemas operativos.

Programas de servicio.

Programas de conversión.

9.- AUTOMATIZACIÓN

La palabra automatización ha tenido un impacto tremendo en nuestra sociedad. Aparece en periódicos, revistas y difusiones, y la usan con frecuencia los hombres de negocios, los líderes sindicales, los políticos y el público en general. Se podría pensar que habría un consenso general sobre el significado de esa palabra tan ampliamente empleada, pero lo que sigue representa definiciones de la automatización dadas por varias personas responsables:

En la Ford hemos definido la automatización como "el manejo automático de partes entre procesos progresivos de la producción". Es nada más el resultado de una mejor planeación, herramientas mejoradas, y la aplicación de métodos de fabricación más eficientes que aprovechan plena­mente de progresos alcanzados por los fabricantes de máquinas-herra­mienta y equipo.

D. J. David, Vicepresidente-Fabricación

Ford Motor Company

La automatización representa un desarrollo totalmente nuevo en el proceso tecnológico, porque la automatización, además de sustituir la energía hu­mana por energía mecánica, principia a sustituir con criterio mecánico el criterio humano -la máquina principia a sustituir al proceso pensante, que hasta ahora lo hacía exclusivamente la mente humana.

Walter P. Reuther, Presidente,

Congress of Industrial Organizations

La automatización sólo es un término más reciente para la mecaniza­ción, que ha continuado desde que se inició la Revolución Industrial. No se crea que es un gran túnel en un extremo de la máquina, dentro del cual se coloca la materia prima y por el otro extremo sale un dispositivo completa­mente armado. . . La automatización viene poco a poco y en piezas. Pri­mero es la automatización de un solo proceso, y luego gradualmente se unen varios procesos para obtener un conjunto o un subensamble completo.

Don G. Mitchell, Presidente de la Cía. y Presidente del Consejo,

Sylvania Electric Products, lnc.

Personalmente, prefiero creer que la automatización, en su sentido más amplio -es una innovación creada por el hombre para aumentar su producción; la tecnocracia silo desean.

Willam W. Barton, Presidente,

W. F. & John Barnes Company

Tomando el primer aspecto de la palabra, encontramos que en algunas formas la automatización significa lo que cada individuo de la calle cree que signifique, ya que en un alto grado es una palabra que produce varias clases de temores en varias clases de individuos. . . En este sentido, la auto­matización no es nada nuevo. . . Tomando el segundo aspecto de la pa­labra, el aspecto técnico, encontramos que en forma general la palabra representa un cambio tecnológico, lo que ciertamente no es nada nuevo.

James P. Mitchell, Secretario de Trabajo

Para propósitos prácticos en las instalaciones de planeación de la fabricación, la General Electric define la automatización como "produc­ción automática continua", principalmente en el sentido de eslabonar las operaciones individuales sumamente mecanizadas. La automatización es una forma de trabajo basada en el concepto de que la producción es un flu­jo continuo, en vez de un procesamiento por lotes de trabajo intermitente.

Ralph J. Cordiner, Presidente,

General Electric Company

10.- CONCLUSIÓN

Como se ha visto a lo largo de esta trabajo de investigación, hoy día se comienza a imponer la obligación de normas de calidad del software donde un fallo en la información, o en el tratamiento de ésta puede llevar a fallos catastróficos y de consecuencias imprevisibles. Por ello las organizaciones están exigiendo controles de calidad más rigurosos en la confección de su software.

Hoy día el tener implantados sistemas de software al sistema productivo en la empresa, debe llevar no solo él tener que instalar la metodología del sistema de producción sino también sistemas de información que controlen y coordinen el sistema, sistemas automáticos, sistemas documentales, etc. Por todo ello la implantación de sistemas de producción en cualquier empresa u organización debe implicar que también el software que empleen los posea, y ello repercute en la obligación de que sus proveedores de software los hayan empleado en la elaboración de sus productos. De esa forma se evitarían defectos provenientes de los sistemas de información.

11.- BIBLIOGRAFÍA

Ingeniería del Software: un enfoque prácticos. Pressman. McGraw Hill. Madrid, 1993. 3ª

Edición. Cap. 5, 6 y 9.

Kitchenham,B.; Towards a Constructive Quality Model, Software Engineering Journal, Vol.2, N. 4, pp. 105-113, 1987.

Murine, G.E. , Integrating software quality metrics with software QA, Quality Progress vol.21, no.11; pp. 38-43; Nov. 1988.

"Automatición and Technological Change", Heariogs, Subcommittee on Economic stabilitation of the joint committee on the Economic Report, Congress of the United States,

Octubre, 1955, Págs. 53-54.

Estructuras de datos: especificación, diseño e implementación:

X. Franch Gutiérrez

Edicions UPC, 1994.

INDICE

1.- INTRODUCCIÓN.

1