Research article

Incorporación de la Calidad Total en un Modelo Integrado de Proceso Software

Resumen

La modelización del Proceso Software constituye un marco de referencia para la organización de las actividades que involucran todas las etapas del desarrollo. La representación del ciclo de vida define los estados por los que pasa un producto software y la representación del proceso software define el conjunto de actividades esenciales no ordenadas en el tiempo que requiere el desarrollo de software. En el presente artículo se propone una modelización integrada del Proceso Software y del Ciclo de Vida del producto, que diferencie claramente actividades y productos con incorporación de mejoras inspiradas en los Modelos de Proceso Industriales, como la Calidad Total.

Incorporation of the Total Quality in an Integrated Model of Process Software

Abstract

The modeling of the Process Software constitutes a mark of it indexes for the organization of the activities that they involve all the stages of the development. The representation of the cycle of life defines the states for those that it passes a product software and the representation of the process software defines the one group of essential activities not ordered in the time that requires the one software development. Presently article intends an integrated modeling of the Process Software and of the Cycle of Life of the product that differentiates activities clearly and products with incorporation of improvements inspired by the Models of Process Industrial, as the Total Quality.

1. Introducción

La modelización de los procesos para la industria en general, requiere de la Ingeniería de Procesos como un factor clave para brindar niveles de calidad predecibles y escalables, basándose en la clara definición de las actividades de los procesos. La forma de aumentar la eficiencia en este sentido, consiste en centrar la producción en procesos y mejorar la capacidad de éstos.

El diseño, la medición y la mejora de los procesos en ciclos se han revelado como la clave para mejorar de forma continua la eficiencia y la calidad productiva. En esta irrupción de la relevancia del proceso, algunos modelos de proceso industrial configuran una ecuación en la que, las personas ayudadas por la tecnología actúan como recursos para ejecutarlos.

En lo relativo a la organización de los recursos humanos, a lo largo de la historia se ha ido transformando la fórmula de la eficiencia que regía la actividad productiva en general: conseguir el mayor tiempo de trabajo con el menor costo posible. La innovación en los aspectos productivos está marcada por la incorporación del saber, del conocimiento como constructor del capital intelectual imprescindible para la producción.

En los aspectos organizativos centrales del proceso en la industria del software, la materia prima que posibilita la construcción del producto software es el conocimiento, constituido en el único elemento capaz de generar valor, a través del capital intelectual y la capacidad de transformarlo en producto.

La modelización del proceso software debe considerar los productos del software que va construyendo, tanto como la relación entre los procesos específicos y los entornos socio-organizacionales en los cuales se desarrolla que se determinan por esa capacidad intelectual.

La incorporación en la modelización del proceso software de algunos aspectos socio-organizacionales, en la mayoría de los modelos vigentes se centra en conceptualizar y formalizar la administración de los recursos humanos en cierta interacción y comunicación sin embargo, carece de un modo sistemático y disciplinado de inclusión de aspectos organizacionales que capitalicen el conocimiento como eje central de la capacidad productiva.

Los diferentes estándares, Modelos de Proceso [1] [2] o Modelos de Madurez [3] [4] y Modelos de Ciclos de Vida [5]; [6]; [7], comparten la concepción de que una buena definición del proceso software facilita el aseguramiento de que cada elemento de trabajo se asigna y se desarrolla adecuadamente, lo que indica que la calidad del proceso determina la calidad del producto.

No obstante, ninguno de los modelos presentados, define al Conocimiento de las personas como un elemento inherente al producto [8], que debe ser ordenado de una manera determinada, o que constituye parte del ciclo de vida del producto como un elemento más, constitutivo del propio producto.

Por otra parte, el desarrollo conceptual del proceso software no es ajeno a la evolución de las formas de organización en la producción industrial en general. El surgimiento de Metodologías Ágiles [9] ; [10]; [11] en el desarrollo de software da cuenta de ello, al introducir formas de organización provenientes de la mejora de los modelos de proceso industriales en la actualidad [12]; [13], tales como el capital intelectual, la importancia de los conocimientos el desarrollo modular, la flexibilidad en los procesos, o la programación por pares [14], todas ellas tendentes todas a quebrar las fronteras en los compartimentos estancos de los equipos de desarrollo.

La solución planteada aquí, pretende resolver dos problemas que se detectan en los enfoques del proceso software en la actualidad. El primero es la separación conceptual entre Proceso y Producto, tratando de diferenciar conceptualmente lo que es un modelo de proceso software con la definición clara de actividades, de lo que es un modelo de ciclo de vida de producto software con los productos que se van construyendo a medida que se realiza el proceso, incorporando ambos conceptos en un único modelo.

El segundo problema que intenta resolver es la incorporación definida y sistematizada de mejoras en el proceso software, a partir de mejoras que se han incorporado en los modelos de procesos industriales, tales como la detención del proceso de construcción ante la presencia de fallos y la transferencia de conocimiento como elementos organizativos centrales de la Calidad Total del producto.

2 Descripción del problema

La importancia del proceso software en el contexto de la ingeniería del software está respaldada por el gran número de trabajos de investigación que se han realizado hasta la fecha, en la que se presentan numerosos Estándares de Proceso [1], [3], [4], [15], diversas clasificaciones y caracterizaciones de Modelos de Proceso [16], [17], [18], [19], [20] que definen el proceso software ideal que debería seguir una organización para conseguir productos software de calidad. Asimismo, los diferentes Modelos de Ciclos de Vida [21] representan las transformaciones del producto software a medida que se va desarrollando mediante el proceso.

Un análisis global de estos marcos de referencia determina la falta de consenso en la terminología empleada para caracterizar los enfoques de modelización del proceso software, de los modelos de Ciclos de Vida y la carencia de una comprensión común de los criterios de evaluación [22].

El proceso software intenta ordenar el proceso de desarrollo de un producto software, prescribiendo y articulando el conjunto de actividades necesarias para gestionar, desarrollar y mantener software, con las especificidades requeridas.

La modelización del proceso constituye una colección de actividades que comienza con la identificación de una necesidad y concluye con el retiro del software que satisface dicha necesidad.

Las actividades que lo conforman deben estar interrelacionadas, y puede existir más de una manera de interrelacionarlas. Las distintas maneras representan diversas estrategias para cumplimentar la construcción de software.

Un proceso software básico está formado por seis etapas genéricas: detección de la necesidad, análisis, diseño, codificación, pruebas e implementación. Este modelo básico puede aumentar su complejidad si se le incorporan el conjunto de actividades técnicas, las actividades de gestión y cualquier otra actividad que se realice durante el desarrollo, así como otros elementos que forman parte del proceso como su entorno y los participantes en él.

El enfoque centrado en la modelización de la transformación del producto software se reconoce como ciclo de vida. Es decir, la modelización del ciclo que el producto software sufre a lo largo de su vida, desde que nace (o se detecta la necesidad) hasta que muere (o se retira el sistema).

En el campo de investigación de la ingeniería de software se trabaja esta perspectiva diferencial entre el producto y el proceso, no obstante, en la definición y descripción de la mayoría de los modelos de ciclos de vida propuestos en la actualidad, hacen referencia al ciclo de vida del producto software a través del conjunto de actividades del proceso software.

En general, los estándares de modelos de proceso software, hacen referencia al conjunto de actividades y tareas determinando los productos que deben construirse. Por lo tanto, esta separación entre producto y proceso no queda claramente diferenciada en el desarrollo de software.

Considerando el desarrollo de software como una actividad industrial con características específicas definidas por el producto que desarrolla, el marco conceptual del proceso software no es ajeno a la evolución de las formas de organización en la producción industrial en general.

En la producción industrial, los modelos de proceso se han desarrollado en la medida que la ciencia y la tecnología han ido evolucionando en el último siglo. No obstante, han sucedido cambios en los modelos de proceso industriales que no responden exclusivamente a los avances tecnológicos, sino a las formas de organización del proceso de trabajo en el ámbito de las fábricas y las empresas.

Fuera de la industria del software, se aplican desde la organización de la industria, diversos factores moduladores de la organización del trabajo que impactan en forma directa en los niveles de producción y en las formas de organización de una corporación en su conjunto.

Si bien el producto software no puede ser comparado con los productos ingenieriles clásicos, ya que posee peculiaridades que lo diferencian sustancialmente de estos, es posible establecer similitudes entre el proceso de desarrollo o de construcción del software, en términos de organización, y los elementos de los modelos de proceso industriales.

Delimitados los aspectos divergentes entre los diferentes tipos de productos software y a su vez con la producción industrial, se abordarán los diversos Modelos de Ciclo de Vida software y los Modelos de Proceso software para luego analizar los diferentes modelos de proceso industrial que se aplican en la industria, con el fin de identificar los elementos predominantes en las formas de organización que rigen para la producción y desarrollo de software.

3 Importancia del problema

En la definición de los modelos industriales, la diferenciación en las formas de organizar las actividades está claramente definida en estándares de proceso y estándares de productos. La definición de proceso permite a todo un equipo productivo comunicarse y trabajar conjuntamente hacia un mismo objetivo, facilitando la comunicación entre usuarios, desarrolladores, gestores y clientes sobre el proceso.

Un proceso productivo definido claramente, genera una mejor comprensión de la gestión, proporciona una base precisa para la automatización, facilita la movilidad de los recursos dentro del proceso y permite construir una base sólida para la mejora y la reutilización del mismo. Un proceso bien definido es más fácil de mejorar y de corregir, por lo tanto, la definición del proceso software y la infraestructura que lo soporta en una organización debe estar claramente establecido y evolucionar en base a la experiencia.

Los modelos aplicados para la industria del software, constituyen un marco de referencia para identificar las áreas de conocimiento de la producción y mantenimiento del software, y desarrollan pautas de ingeniería para trabajar con sistemas que tienen niveles de integridad elevados, pero no tienen en cuenta las características organizacionales que han incorporado los nuevos modelos industriales, que introducen el conocimiento como un insumo necesario para el ordenamiento del proceso.

Las innovaciones incorporadas, en las últimas décadas, a los procesos industriales, podrían igualmente incorporarse al desarrollo de software con el fin de obtener mejoras semejantes a las ocurridas con su introducción en la producción industrial. En la industria del software, muchos de los elementos indicados como postulados o principios de los Métodos Ágiles en la industria del software, parecen estar inspirados, sistemáticamente o no, en las mejoras introducidas por los modelos industriales más innovadores.

4 Breve esbozo de la solución

En base a este análisis, en el marco de la presente investigación, se propone un Modelo de Proceso Software que representa un enfoque dirigido por el desarrollo del producto en cuanto al Ciclo de Vida del software y por el proceso software en cuanto al conjunto de actividades sistematizadas.

El modelo propuesto diferencia conceptualmente el proceso software con una definición clara de actividades y el ciclo de vida de producto, incorporando ambos conceptos en un único modelo. Esta diferenciación, permite separar las actividades del proceso de las características técnicas de los productos que construye, y comparar genéricamente el proceso software con los procesos industriales para incorporar al desarrollo de software las mejoras generadas en otros campos de la producción, fundamentalmente las referidas al rol central que adopta el conocimiento como factor clave de la producción.

El modelo propuesto está centrado en el Conocimiento de los recursos humanos que requiere el desarrollo de software, como capital intelectual intrínseco de la producción. Representa la construcción del producto software en una serie de versiones, conformando cada una de ellas un ciclo de desarrollo indeterminado en el tiempo, en una secuencia no ordenada ni predefinida de actividades y en una secuencia indeterminada de productos construidos, que incorpora los conceptos de calidad total al producto, garantizado por las particularidades de la organización de las actividades del proceso basadas en el conocimiento y en la detención del proceso ante la presencia de fallos.

5 Características del Modelo propuesto

El Modelo de Proceso Software propuesto como solución, llamado Modelo Meridional, representa un enfoque dirigido por el desarrollo del Ciclo de Vida de la construcción del producto software y por el Proceso software con el conjunto de actividades sistematizadas, repetibles, no ordenadas en el tiempo, como una instancia diferente del ciclo de vida, es decir que las actividades serán repetibles e independientes del ciclo de vida que adopte un producto software específico.

Dirigido por la gestión para el análisis y estructuración del proceso software, propone un modelo de desarrollo evolutivo que acompaña la naturaleza iterativa y concurrente de las actividades de construcción del producto en su ciclo de vida software, con los aspectos controlados y sistemáticos del proceso software.

El Modelo Meridional propone la construcción del producto software en una serie de versiones, conformando cada una de ellas un ciclo de desarrollo indeterminado en el tiempo, en la secuencia de actividades y en la secuencia de productos construidos. De este modo, se propone la separación conceptual entre proceso (representado por el conjunto de actividades) y producto (representado por el ciclo de vida que transita el producto con los sub-productos que se construyen a lo largo del proceso).

Las actividades del proceso constituyen acciones genéricas que todo proceso software debe cumplir, independientemente de las características que contenga para cada modelo de proceso. Éstas, en la mayoría de los modelos de proceso, se presentan en un orden secuencial, aunque claramente no deban estar definidas en el tiempo. Los modelos de ciclos de vida analizados, presentan indistintamente estas actividades tanto como fases del desarrollo del proceso y como fases del ciclo de vida del producto software.

En el Modelo Meridional, las actividades del proceso son acciones que realiza un equipo de desarrollo, definidas por los estándares de proceso. Por otra parte, el ciclo de vida del producto constituye los estados de transformación por los que va pasando el producto software a lo largo del proceso, es decir, a través de las actividades del proceso software.

Esta diferenciación, permite separar las actividades del proceso de las características de los productos que construye, y de esta manera poder analizar genéricamente el proceso software comparativamente con los procesos industriales, por una parte, y los productos software, por otra parte, con las particularidades que tiene el software como producto.

6 Mejoras incorporadas al Modelo propuesto

El Modelo Meridional constituye un modelo de proceso de producción adecuado para la construcción de productos software. Según la concepción generalizada de la calidad de los productos software, la madurez del proceso garantiza la calidad de los productos.

La definición y especificación de todas las actividades del proceso de desarrollo, en los modelos proceso software existente, son fieles exponentes del Modelo Fordista[12], con la estandarización de procesos y la definición de Normas de Calidad.

El Modelo Japonés o Toyotista [13], incorpora una serie de innovaciones en las formas organizacionales de los procesos industriales que reducen los tiempos de producción y eliminan la presencia de fallos en los productos. Estos elementos son incorporados en el Modelo de Proceso Meridional para el desarrollo de Software.

A la luz de los elementos que permiten comparar los modelos de proceso industriales con los modelos de proceso software, el Modelo Meridional incorpora de manera sistemática las innovaciones implementadas por el toyotismo en la industria en general.

6.1. Conocimientos del equipo

El conocimiento es considerado como una materia prima inherente al producto que debe desarrollarse. La planificación de la producción debe ser consensuada y coordinada. Debe realizarse en cada puesto o módulo funcional y con eso construir la planificación global coordinada. En el Modelo Meridional se representa en cada intersección entre producto y proceso es el punto de planificación, que con la definición del producto (meridiano) define los planes para la gestión (paralelo).

La pluriespecialización de los trabajadores, implica que el amplio conocimiento y la alta cualificación de los integrantes de un equipo de trabajo genera una relación participativa en la toma de decisiones, y en el conocimiento de todas las instancias de la producción o desarrollo.

El modelo propone incorporar prácticas que implique un mayor acercamiento en el conjunto de tareas, así como un vínculo más estrecho entre la concepción y la ejecución de tareas, lo que representa se logra a partir del conocimiento como capital e insumo de la producción.

6.2. Calidad

Incorporando al Modelo Meridional los conceptos de calidad total basadas en la detención del proceso de producción ante la presencia de fallos, cada instancia del producto, desarrollada en una fase del Modelo, puede pasar a otra fase del desarrollo, cualquiera que sea, solo si tiene una aceptación de que todo lo necesario para esa parte ha sido completada y si el producto que la requiera para iniciar su ejecución cuenta con los conocimientos necesarios para comenzar dicha instancia.

Si se detecta un fallo, el producto no pasa de fase y se detiene el proceso hasta que el problema está resuelto. Debe existir cero defectos para que una parte del producto pase a la siguiente fase de su desarrollo.

De este modo, cada fase continúa trabajando en forma concurrente en cualquier instancia del producto si es que tiene lo estrictamente necesario para avanzar, provisto por los procesos anteriores, sin ninguna organización temporal y/o secuencial determinada a priori. La Figura 1 representa la Iteración, en la finalización del proyecto, en el cual todos los productos han sido terminados y entregados en los polos.

6.3. Iteratividad versus Secuencialidad

En el Modelo Meridional, la construcción de los productos que se inicia a partir de la entrega de un producto en un polo, requiere, como esencial, del conocimiento aportado por otro producto anterior. Esta entrega de producto conlleva el conocimiento necesario para que se dispare el inicio de otro producto.

La construcción de los productos es realizada por las actividades del proceso, en tanto que, la transmisión de la condición de inicio entre los productos determina la falta de secuencialidad en las actividades del proceso.

La iteratividad y sucesión no secuencial de actividades es generada por las características de cada producto y por la indeterminación del tiempo de desarrollo de cada una de las actividades del proceso.

Las condiciones para que cada producto sea entregado en un polo, la brindan las diferentes técnicas aplicadas en el proceso para cada una de las actividades que garantizan la calidad en el producto, como por ejemplo, las técnicas de requisitos, las técnicas de validación de diseño, las técnicas de verificación del código, etc.

Las técnicas utilizadas para cada instancia del producto accionan para probar el conocimiento acerca del producto, que puede ser transmitido a los demás productos. En este sentido, cada producto entregable en un polo está conformado por el conocimiento sobre sí mismo.

6.4. Estados del ciclo de vida

Cada producto, en el estado en que se encuentre en el ciclo de vida, se comporta como un dispositivo receptor y transmisor de conocimiento sobre cómo deben seguir los otros productos. De este modo, cada instancia del producto, desarrollado en una fase del ciclo de vida puede pasar a otra fase, cualquiera que sea, solo si tiene una aceptación de que todo lo necesario para esa parte ha sido completado y si el producto que lo requiere para iniciar su ejecución cuenta con los conocimientos necesarios para comenzar dicha instancia.

El desarrollo concurrente y paralelo de diversos productos en una misma fase del ciclo de vida, no se encuentra determinado en el orden de sucesión de instancias, sino que se va determinando de acuerdo a las condiciones para que cada producto, se construya, se detenga o se entregue en un polo. Cada actividad comienza a desarrollar un producto cuando tiene las condiciones para hacerlo.

Los productos que se construyen no tienen una secuencia definida en el ciclo de vida, sino que la consecución del producto está definida por la indeterminación de lo que cada producto va construyendo y la indeterminación del tiempo para realizar las actividades de su construcción. Para representar esta indeterminación, la Figura 2 muestra los pasos de una posible secuencia, con los diferentes Estados del ciclo de vida del producto en diversas Iteraciones.

Figura 2. Ciclo de Vida del producto

Iteración 1

La operación Inicia se utiliza para inicializar el producto antes de que comience su construcción, en el Estado 0.

La declaración de conocimiento da inicio a las iteraciones del ciclo de vida del producto.

El Estado 0 avanza con el primer producto (... REQ1…) si, y solo sí, tiene conocimiento.

El Estado 0 desarrolla producto y avanza al Estado 1.

El Estado 1 desarrolla producto: Si tiene conocimientos para transferir, entrega conocimiento en el polo y avanza al Estado 2. Si no tiene conocimientos para transferir, se queda en el Estado 2.

Iteración 2

El Estado 2: si tiene conocimiento desarrolla producto (... REQ2…), si no, espera por conocimiento transferido desde Estado 1. Si desarrolla producto, avanza. Si tiene conocimientos para transferir, entrega conocimiento en el polo y avanza al Estado 3. Si no tiene conocimientos para transferir, se queda en el Estado 2.

El Estado 3: si tiene conocimiento desarrolla producto que utilice el conocimiento transferido (... PRU1; DIS1…), si no, espera por conocimiento transferido desde Estado 2.

Si desarrolla producto, avanza. Si tiene conocimientos para transferir, entrega conocimiento en el polo y avanza al siguiente Estado. Si no tiene conocimientos para transferir, se queda en el Estado 3.

5 Conclusiones y Trabajos Futuros

En el presente artículo se ha presentado un modelo de proceso software que integra al ciclo de vida del producto software y permite la confluencia de diversos aspectos provenientes de la ingeniería de procesos del modelo toyotista.

La intención del mismo es centrar el análisis en la transformación constante de los elementos organizativos del proceso software, de manera tal que permita introducir en el ciclo de vida del software, el concepto de detención del proceso ante la presencia de fallos y la continuidad del proceso a través de la transferencia de conocimiento.

La concurrencia de las posibilidades de avanzar en las actividades del proceso que generan los cambios de estado en el ciclo de vida del software se presentan sin ningún tipo de control sobre el flujo temporal de sus apariciones. El Modelo Toyotista incorpora las técnicas de Calidad Total basadas fundamentalmente en la detención del proceso productivo en cada módulo ante la presencia de fallos.

En la presente investigación y como línea futura de trabajo, queda por definir cuáles son las condiciones para que cada producto en cada fase avance o se detenga, para instanciar los permisos que cada fase tiene para entregar y/o para recibir una parte del producto, aplicados también por el toyotismo en la línea de producción. Si bien los conceptos de parar por un error (falta de conocimiento) o avanzar por la solución del error (obtención de conocimiento) resultan los elementos claves, queda aún por determinar las técnicas y/o prácticas que permitirían instanciar el punto de avance o detención en cada una de las fases.

Bibliografía

1. IEEE Standard for Developing Software Life Cycle Processes, IEEE Standard 1074-1997. IEEE, 1997.
2. ISO/IEC. International Standard: Information Technology. Software Life Cycle Processes, ISO/IEC Standard 12207-1995/Amd. 1-2008.
3. ISO/IEC TR 15504. Information Technology – Software process assessment. International Organization for Standardization, International Electrotechnical Commission, 1998. http://wwwsel.iit.nrc.ca/spice
4. Capability Maturity Model Integration for Development (CMMI-DEV), Version 1.2. Software Engineering Institute, Carnegie Mellon University. 2006.
5. Boehm, B. A Spiral Model of Software Development and Enhancement Computer, pp. 61-78, May 1988.
6. Boehm, B.& R. Ross A Collaborative Spiral Software Process Model Based on Theory W. Proceedings, ICSP3. IEEE, Reston, VA, Octubre 1994.
7. Jacobson, I; Booch, G; Rumbaugh, J. El Proceso Unificado de Desarrollo de Software, Addison Wesley, 1999.
8. I. Nonaka, H. Takeuchi. La Organización Creadora de Conocimiento. Ed Oxford, 1999.
9. Beck,K; Beedle,M; Cockburn,A; Cunnimgham,W; Fowler,M;Agile Manifesto. web site. (2001). http://agilemanifesto.org.
10. Fowler,M. “Is design dead?” Proceedings XP2000. Web site (2001). http://www.martinfowler.com/articles/designDead.html
11. Larman,C. Agile & Iterative Development. A Manager’s Guide. (Addison Wesley, 2004).
12. B. Coriat. El Taller y el Robot. Siglo XXI, 1992.
13. B. Coriat. Pensar al Revés: Trabajo y Organización en la Empresa Japonesa. Siglo XXI, 1992.
14. Beck, K. Extreme Programming Explained: Embrace Change. (Addison Wesley, 1999).
15. Chrissis,M.B., Konrad,M., Shrum,S. CMMI: Guidelines for Process Integration and Product Improvement (Sei Series in Software Engineering). Amazon, 2008.
16. R. Conradi, C. Liu y M. L. Jaccheri, “Process modelling paradigms: An evaluation”. Proceedings of the Seventh International Software Process Workshop, Octubre 1991. pp. 51-53.
17. P. Armenise, S. Bandinelli, C. Ghezzi y A. Morzenti, “A survey and assessment of software process representation formalisms”. International Journal of Software Engineering and Knowledge Engineering 3, 3. 1993. pp. 401-426.
18. V. Ambriola, R. Conradi y A. Fuggetta, “Assessing process-centered software engineering environments”. ACM Transactions on Software Engineering and Methodology 6, 3. 1997. pp. 283-328.
19. J. Lonchamp, “A structured conceptual and terminological framework for software process engineering”. Proceedings of the Second International Conference on the Software Process, Febrero 1993. pp 41-53.
20. [Madhavji, 1991] Madhavji, “The process cycle”. Software Engineering Journal 6, 5 Setiembre 1991. pp. 234-242.
21. Alexander, L. and Davis, A. “Criteria for selecting software process models”. Proceedings of COMPSAC’91. 521-528. 1991.
22. A. Finkelstein, J. Kramer, B. Nuseibeh, “Software Process Modelling and Technology“. Research Studies Press, 1994.

Técnica Administrativa
ISSN 1666-1680

http://www.cyta.com.ar -

Vol.:08
Nro.:02
Buenos Aires, 15-04-2009

URL http://www.cyta.com.ar/ta0802/v8n2a3.htm