• No se han encontrado resultados

Integración del modelo de procesos con el método RAISE

N/A
N/A
Protected

Academic year: 2017

Share "Integración del modelo de procesos con el método RAISE"

Copied!
3
0
0

Texto completo

(1)

Integración del Modelo de Procesos con el método RAISE G. Montejano, D. Riesco

Universidad Nacional de San Luis Departamento de Informática

Ejército de los Andes 950 5700 San Luis - Argentina

driesco@unsl.edu.ar

Resumen

Los métodos formales nos garantizan el desarrollo de software de calidad. Utilizan una base matemática para describir las propiedades del sistema, permitiendo desarrollar y verificar matemáticamente los sistemas de manera sistemática. Sin embargo en el desarrollo de grandes sistemas donde involucran diferentes unidades organizativas dentro de una corporación es difícil determinar la primera especificación formal, y más difícil aún permitir una comunicación fluida con los stakeholders de cada unidad organizativa.

El modelado de procesos permite encontrar tareas que deben ser realizadas en cada una de las áreas de la organización. Para entender el dominio es crucial especificar cada una de esas tareas. Por lo tanto, utilizamos el modelado de procesos para encontrar cada una de las tareas dentro de cada unidad organizativa, y el método formal RAISE para definir de forma precisa esas tareas. A partir de la especificación formal de las tareas, se completa el proceso de desarrollo de software aplicando los pasos del método RAISE.

1. Contexto del Trabajo

Este trabajo está enmarcado dentro de un proceso de reingeniería de negocio, siendo uno de los pasos necesarios cuando se aplica tanto ingeniería inversa como ingeniería directa. Hoy por hoy, la reingeniería de procesos de negocios tiene un conjunto de principios, técnicas y herramientas ad hoc para analizar la empresa: su modo de operar, desde lo estratégico hasta lo táctico, y para sugerir cambios en esos modos de operar. El objetivo global de esta línea de investigación es contribuir a la formalización del proceso de reingeniería de negocios.

2. Introducción

Un proceso de negocio es un conjunto de tareas lógicamente relacionadas que se efectúan con objeto de obtener un determinado resultado de negocio [DAV90]. Un proceso de negocio abarca recursos humanos, recursos materiales, y los procedimientos de negocios con objeto de producir un resultado concreto con un valor agregado para la organización. Los procesos cruzan los límites de las unidades organizativas, necesitan que participen distintos grupos en la ejecución de las tareas que conforman el proceso.

El modelado de procesos o modelado de negocio [CHA95, JAC99, HOM98, AGU99, ROH98] son herramientas que permiten visualizar para un proceso dado las tareas o actividades y flujos, así como también las unidades organizativas que son afectadas por el proceso.

3. Modelado de Procesos

(2)

dependiendo en que punto del proceso de reingeniería que se esté trabajando.

Las herramientas generan un artefacto que representan un proceso completo [JAC96]. Un diagrama representa un proceso y describe cada una de las actividades relacionándolas entre sí. Modela la transformación de un estímulo, que surge de una entidad externa a la organización, en una respuesta a esa u otra entidad externa (cliente del proceso). Para transformar este estímulo, es necesario llevar a cabo distintas tareas o actividades que son las que conforman el proceso. El estudio de dividir el proceso en tareas es un punto principal en el modelado de procesos. El encadenamiento de las tareas adecuadamente permite transformar el estímulo del ambiente en la respuesta al cliente del proceso. Una misma tarea puede formar parte de distintos procesos.

La descripción de las tareas o actividades, normalmente, se utiliza el lenguaje natural, llevando a descripciones vagas y ambiguas. La propuesta es formalizar cada tarea utilizando un lenguaje formal, en nuestro caso, RSL (RAISE Specification Language) [RAI92] que es el lenguaje del método formal RAISE [RAI95]. Al tener una especificación precisa permite entender claramente el dominio. Por lo tanto, cada una de las tareas descriptas en el modelo de procesos, deben ser especificadas formalmente usando RAISE. Esto nos garantiza que cada tarea tiene una única interpretación, sin ambigüedad.

4. Integración entre el modelado de procesos y el método RAISE.

La técnica que aquí se bosqueja es comenzar el proceso de desarrollo de software estudiando y analizando el dominio. Para ello, se utiliza el diagrama de procesos o diagrama de actividad para entender el funcionamiento de la organización o para reestructurarla, si se quiere producir cambios que lleven a entregarle al cliente del proceso un valor agregado. Una vez que se ha definido los distintos modelos de procesos (un modelo por cada proceso de la organización) se comienza con la definición de la especificación formal. Para construir la especificación inicial se siguen heurísticas. A continuación se describen, como ejemplo, algunas de ellas.

Transformar cada tarea especificada en el modelo de proceso en un esquema RSL, donde se construirá la especificación formal. Considerando que la tarea es una actividad (acción) se genera en este esquema una función RSL que llevará a cabo la tarea.

Comenzar una especificación formal de esta manera, genera una construcción modular divida por unidad organizativa, de manera que es más clara para el entendimiento no sólo por parte de los usuarios de la organización, sino también por los ingenieros que aplican el método RAISE.

Construir un esquema RSL por cada almacenamiento de datos del modelo de procesos, el cual contiene todas las funciones pertinentes a la tarea que accede a este almacenamiento de datos.

Es aconsejable definir funciones auxiliares dentro del esquema que ayuden a entender la especificación formal de la actividad.

Los requisitos necesarios para ejecutar la tarea son especificados como precondición de la función principal.

Si es necesario el uso de funciones de otras clases, el esquema contendrá una declaración de esas clases mediante una declaración de un objeto por cada clase.

Una vez desarrollada la especificación formal inicial se continúa el proceso de desarrollo de software aplicando los pasos determinados en el método formal RAISE.

(3)

-Geographical Information System) mantiene información sobre todas las parcelas provinciales. El ambiente concreto sobre el cual se llevó a cabo ha sido usando el modelador de Procesos de Oracle Designer 2000, y la herramienta RSLTC (RAISE Specification Language Type Checking) para especificar cada tarea descripta con la herramienta Oracle.

5. Conclusiones

La técnica bosquejada aquí comienza con la utilización de herramientas de la reingeniería de procesos como un front-end, es decir, como principio estructurador de la especificación formal inicial, para continuar luego con la aplicación del método RAISE. Esta técnica permite ayudar en la comunicación con el cliente, y estudiar y estructurar las actividades que se realizan o se deben realizar (según el punto dentro del proceso de reingeniería que se esté aplicando, ya sea ingeniería inversa e ingeniería directa) en una corporación construyendo una especificación formal sin ambigüedades.

Esta técnica tiene todas las ventajas del uso de los métodos formales pero aplicadas en el primer paso del proceso de reingeniería. Básicamente, consiste en aplicar el modelado de procesos, y especificar cada una de sus tareas usando una especificación formal, en este caso el RSL de RAISE.

Permite al grupo de ingenieros, que hacen ingeniería hacia adelante, tener una especificación no ambigua y clara de cada una de las tareas hechas por la organización. De esta manera se evita el problema de la vaguedad inherente en la descripción informal, ayudando a construir sistemas más confiables. También facilita la especificación rigurosa y el análisis de sistemas de software complejos.

La especificación RAISE resultante puede ser un contrato entre los desarrolladores y los usuarios, así como también entre los desarrolladores que especifican los modelos de procesos de la organización, y los desarrolladores que aplican la ingeniería hacia adelante.

References

[DAV90] Davenport, T.H. y Young, J.E., "The New Industrial Engineering: Information Technology and Business Process Redesign", Sloan Management Review, 1990.

[CHA95] Champy, J. “Reengineering Management”, Harper Business, 1995

[JAC99] Jacobson, I, Booch, G., Rumbaugh, J, "The Unified Software Development Process", Addison-Wesley, 1999.

[HOM98] Hommes, B., Reijswoud, V., "Assessing the Quality of Business Process Modeling Techniques", Proceedings of the 33rd Hawaii International Conference on Systema Sciences, IEEE, 1998.

[AGU99] Aguilar, M., Pater, A., "Business Process Simulation: A Fundamental Step Supporting Process Centered Management", Proceedings of the 1999 Winter Simulation Conference, IEEE, 1999.

[ROH98] Rohm, A., Hermann, G, Gunther, P., Proceedings of the 15th Annual Computer Security Applications Conference, IEEE, 1998.

[BOO99] Booch, G., Rumbaugh, J, Jacobson, I, "The Unified Modeling Language User Guide", Addison-Wesley, 1999.

[HAM93] Hammer, M. and Champy, J. “Reengineering the Corporation: A Manifesto for Business Revolution”, Harper Collins Publishing, Inc., 1993

[JAC96] Jacobson, I. “Objectifying Business Process Reengineering”, Addison Wesley, 1996 [RAI92] The RAISE Language Group, "The RAISE Specification Language", Prentice Hall, 1992. [RAI95] The RAISE Method Group, "The RAISE Development Method", Prentice Hall, 1995.

Referencias

Documento similar

"No porque las dos, que vinieron de Valencia, no merecieran ese favor, pues eran entrambas de tan grande espíritu […] La razón porque no vió Coronas para ellas, sería

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Esto viene a corroborar el hecho de que perviva aún hoy en el leonés occidental este diptongo, apesardel gran empuje sufrido porparte de /ue/ que empezó a desplazar a /uo/ a

Sanz (Universidad Carlos III-IUNE): "El papel de las fuentes de datos en los ranking nacionales de universidades".. Reuniones científicas 75 Los días 12 y 13 de noviembre

(Banco de España) Mancebo, Pascual (U. de Alicante) Marco, Mariluz (U. de València) Marhuenda, Francisco (U. de Alicante) Marhuenda, Joaquín (U. de Alicante) Marquerie,

[r]

SVP, EXECUTIVE CREATIVE DIRECTOR JACK MORTON

Social Media, Email Marketing, Workflows, Smart CTA’s, Video Marketing. Blog, Social Media, SEO, SEM, Mobile Marketing,