UNIVERSIDAD METROPOLITANA CASTRO CARAZO

ESCUELA DE INFORMÁTICA

CIENCIAS DE LA COMPUTACIÓN CON ÉNFASIS EN DESARROLLO

DE APLICACIONES INFORMÁTICAS 

GESTION DE LA CALIDAD

ALLAN NARANJO ROJAS

FABIO NARANJO ROJAS
GABRIEL GRANADOS AGUERO
WALTER CHACÓN VALERIO

PROYECTO REINGENIERIA DE PROCESOS

SAN JOSE - COSTA RICA

ABRIL 2011
Introducción
En la actualidad la satisfacción del uso de un producto o programa puede
marcar una gran diferencia ya que en el mercado vamos a encontrar gran cantidad
de ellos y mucho va depender de su calidad. Por tal motivo el producto en
consumo debe de satisfacer las expectativas del cliente. Para el desarrollo de un
producto como es el software no está ajeno a esta realidad. Es por eso que las
empresas desarrolladoras de aplicaciones se preocupan por implementar algún
mecanismo y estrategia que les ayudan a garantizar la calidad e eficiencia de sus
productos. Al desarrollar aplicaciones que en su momento no cumplen con lo
esperado por sus clientes, en muchas ocasiones se ven obligados a implementar
acciones que le ayuden a reinventar sus aplicaciones o procesos, buscando la
calidad total del producto que su ves busca una posición estable dentro del
mercado.
La reingeniería de procesos, o BPR (Business Process Reeingeniering)
aunque no se involucra directamente en el proceso de la gestión de calidad, esta
podría considerarse como una herramienta de la misma. Esta aparece a finales de
los ochenta con la cual se logra simplificar los procesos y velar por que estos se
simplifiquen para que se obtengan cambios sustanciales en una organización.
Con una buena reingeniería de los procesos se pretende satisfacer las
necesidades de los clientes, competir en un mercado exigente, y quera su vez va
de la mano con la tecnología y lo más importante saber aplicar el cambio ya que
una mala decisión podría ser faltan si no se tiene una idea clara de que se quiere
obtener al final.
La BPR, es una herramienta muy nueva, y la misma debe de entenderse
como una mejora sustancial al cambio de las realidades de una empresa. Con ella
pretendemos dar o aportar soluciones que permitan luchar con los retos que
exigen los clientes, barreras que suponen la competencia y sobre todo riesgos de
un cambio en ocasiones profundo.
De forma más profunda veremos las características más importantes de la
BPR y analizaremos detalladamente las mismas, así como algunos conceptos de
Hammer y Champ que a partir de los cuales se sustenta la Reingeniería de
Procesos.

Resumen
Muchas de las empresas implementan un plan de gestión de calidad al cual
realizan mejoras continuas, sin embargo después de cierto tiempo deben de
realizar un cambio radical, esto por los cambios que se dan en los mercados. Con
la aplicación de la reingeniería en sus procesos tendrán una poderosa herramienta
para mantenerse competitivas y poder liderar en su área.
Se aportan los pasos fundamentales y cuidados que se deben tener al
momento de su aplicación. Ya que una mala reingeniería podría ser fatal.
Finalmente se concluye que una redefinición de los procesos abre oportunidades
en un alto grado de eficacia y eficiencia para la organización.

Abstract
Some business develop a quality gestion plan, which is improved very often;
neverthless, after a while they have to make a radical change, because of the
marketing changing.  With the re-engineering application in their processes, they
will obtain a powerful tool to keep them competitive and leaders in their area.
 
They take care of mainly steps in the application time, because a bad re-
engineering could be dangerous.  Finally, we got to the conclusion, that a
redefinition of processes, open opportunities in a high efficiency and efficacy grade
for the organization.

Objetivos
Objetivo General.
 Dada las motivaciones expuestas en el anterior apartado, se desea analizar
cómo se debe de realizar un buen planteamiento para realizar la
reingeniería a un proceso.
Objetivos específicos
1. Definir la reingeniería de procesos aplicada en el software.
2. Analizar cuando se debe de aplicar una reingeniería en los procesos.
3. Determinar los requerimientos necesarios para una reestructuración de los
procesos.
4. Analizar los posibles escenarios antes, durante y después de un proceso
de reingeniería.

Justificación
La reingeniería de procesos no tiene que verse solo como un cambio radical
a un proceso ya establecido sino como una propuesta de mejora a los
procedimientos actuales.

Alcance
1. Esta investigación abarcara los puntos más importantes que se deben de
tomar en cuenta para la aplicación de la reingeniería de procesos.
2. Dado el tiempo que se tiene para desarrollar el tema se verán las mejores
prácticas en el desarrollo de la reingeniería
3. Estudiar cuando es conveniente aplicar una reingeniería y posibles errores
que se puedan cometer obteniendo como resultado el fracaso de una mala
decisión.

Limitaciones
No se tienen limitaciones para el desarrollo del siguiente trabajo ya que se
basa específicamente en la investigación de cómo aplicar la reingeniería de
procesos.
Presentación de la Metodología
Definición de reingeniería de procesos
Necesitamos tener una definición clara de reingeniería de procesos, para
poder lograr esto debemos de plantearnos una pregunta: “Deseo mejorar lo que
tengo o no he logrado lo esperado” Tomando en cuenta lo aprendido y utilizando
la tecnología de vanguardia, ¿Debería de cambiar mi sistema por otro mejor?
Existe un concepto muy generalizado a lo que se refiere la BPR y es que para
lograr mejoras drásticas se debe de pasar por un rediseño radical. Encontramos
varias definiciones:
1. Análisis y diseño de los flujos y procesos de una organización(T.H.
Davenprot)
2. Reconsideración, procesos, gestión de sistemas y reconsideración a treves
de los cuales se crea valor (R. Talwar)

Como estas podemos incluir más sin embargo analizaremos la de Hammer y

Champy orientada a la Reingeniería de procesos al desarrollo de software.
“Reingeniería es la revisión fundamental y el rediseño radical de proceso
para alcanzar mejoras espectaculares en medidas críticas y contemporáneas de
rendimiento, tales como costos, calidad, servicio y rapidez”

De esta definición podemos sacar cuatro conceptos claves para poder

entender la reingeniería de procesos.
1. Fundamental: Cuando se decide realizar la reingeniería a un sistema
informático, nos debemos preguntar porque el mal funcionamiento del
mismo o porque no cumple con los requisitos necesarios? La reingeniería
nos va ayudar a determinar qué es lo que debe hacer para posteriormente
como debe hacerlo. (Un mejor conocimiento del mercado, un buen
levantamiento de requerimientos, entre otros )
2. Radical: Nuestra aplicación debe de ser rediseñada por completo puesto
que debe de cumplir con lo esperado. NO debemos de realizar cambios
 superficiales para salir del paso o tratar de realizar cambios a lo ya
diseñado. Pues que solo estamos dando solución a una pequeña parte. El
sistema debe de ser rediseñado por completo.
3. Espectacular: como su nombre lo indica algo revolucionario. Nunca
marginales (como mejoras o modificaciones). Asociando el BPR debe de
ser el mejor rendimiento esperado.
4. Procesos: El concepto más importante y posiblemente que merece más
importancia. “Un proceso puede ser definido como un conjunto de
actividades enlazadas entre sí que, partiendo de uno o más inputs
(entradas) los transforma, generando un output (resultado).” Cada una de
estas tareas son importantes pero si no trabajan en conjunto al final el
proceso no da el resultado esperado.

La BPR como en el punto cuatro debe verse como un proceso para la mejora
de una aplicación existente y a su vez utilizando la ingeniería inversa junto con la
reasignación y reestructuración de código. Utilizando la BPR podemos utilizar un
modelo cíclico, en el cual vamos a definir seis etapas las cuales se muestran en la
figura #1. Cada actividad se presenta como parte del paradigma pueden repetirse
en otras ocasiones. Para un ciclo en particular, el proceso puede terminar después
de cualquier de estas actividades.
 Análisis del inventario.
Por lo general la empresa de desarrollo mantiene una lista de todas las
aplicaciones creadas. En dicha lista posiblemente de detalla (Tamaño de la
aplicación, importancia que tiene, fecha de creación entre otros). Las aplicaciones
a las que se les debe aplicar la BPR aparecen según la importancia que tengan
para el negocio o posiblemente cuando ya se han hecho obsoletas para el
mercado que fueron creadas. A partir de este momento es posible asignar
recursos a las aplicaciones seleccionadas.
Es importante mencionar que el inventario se de be de crear con regularidad
así como su estado ya que este puede cambiar en función del tiempo y , como
resultado, cambiara su prioridad.

Reestructuración de los documentos.

Por lo general la documentación es escasa en la mayoría de los sistemas.
Acá nace la pregunta ¿Qué debemos de hacer?
1. Como la creación de la documentación toma demasiado tiempo. En caso
del que el sistema funciona y se ajustan a lo que se tiene, en algunos casos
no se crean. Sin embargo hay que evaluar si el sistema que se tiene es
estático, este ya está llegando a su vida útil, por lo que no es probable que
experimente cambio alguno.
2. Cuando es preciso documentar la información y se tiene poco presupuesto.
Se puede evaluar documentar solo los cambios o actualizaciones que se la
realicen al sistema. Ya que la recolección de documentos ira evolucionando
con el tiempo.
3. Cuando un sistema es fundamental para la empresa, y se requiere de forma
definitiva la información. Hay que dar un toque inteligente y consiste en
reducir la documentación únicamente al mínimo necesario.
Ingeniería inversa.
El termino reingeniería inversa consiste en “Obtener información a partir de
un producto accesible al público, con el fin de determinar de qué está hecho, qué
lo hace funcionar y cómo fue fabricado.” Por lo general hay que hacer reingeniería
inversa no al sistema de la competencia sino más bien al creado por la empresa.
Es un proceso de analizar el software como se mencionó anteriormente
siempre con el objetivo de recuperar su diseño y especificación. Este va a requerir
de entradas tal como el código fuente. A su vez se va a diferenciar de la
reingeniería ya que tratamos de crear un sistema más sostenible. Fig. #2

Fig. #2

Reestructuración de código.
Uno de los tipos más comunes de reingeniería es la reestructuración de
código. Algunos sistemas tienen una arquitectura de programa muy sólida, sin
embargo existen módulos individuales que han sido codificados de una forma que
hace difícil su comprensión. Para estos casos, es recomendable reestructurar el
código en dichos módulos.
Para este apartado se analiza el código fuente y se indican las violaciones
de las estructuras de programación, de esta forma se reestructura el código y se
revisa para comprobar que no se haya anomalías.
Reestructuración de los datos.
Una de las primeras tareas de que debemos de realizar, esto por la
frecuente ocurrencia de los datos en distintos niveles de abstracción.
Cuando se tiene un programa con una estructura de datos débil, va ser
difícil adaptarla y mejorarla. La estructuración de los datos a diferencia del código
es una actividad de reingeniería a gran escala. Por lo general se empieza por una
actividad de ingeniería inversa. Esta se analiza minuciosamente y se define el
modelo de datos necesarios. Debemos de identificar los datos y atributos para
después revisar la estructura de para efectos de calidad. Si la estructura de los
datos llegara a ser débil (archivos planos), se debe de aplicar la reingeniería de
datos.
Ya que la arquitectura de los datos es de gran importancia en el sistema, y
sobre todo los algoritmos, los cambios de los datos darán lugar a cambios
radicales en el mismo.
Una buena estructura de la base de datos comprende los objetos existentes
y sus respectivas relaciones Fig. #3. Por lo que es aconsejable seguir:
1. Construcción de un modelo inicial de objeto.
2. Determinación de los candidatos claves.
3. Refinar las clases tentativas.
4. Definición de generalidades.
5. Descubrimiento de asociaciones.

Podemos citar algunas de las ventajas de la restructuración de los datos:

1. Mejora la comprensión de los sistemas
2. Incrementa la productividad del personal encargo del mantenimiento.
3. Mejora la documentación sobre los datos.
4. Ayuda a la implementación de estándares.
5. Facilita la reutilización de los datos para otras aplicaciones.
Ingeniería directa.
La cual se denomina también renovación o reclamación, no solamente
recupera la información de diseño de un software ya existente, sino que, además,
utiliza esta información en un esfuerzo por mejorar su calidad. En la mayoría de
los casos, el software procedente de una reingeniería vuelve a implementar la
funcionalidad del sistema existente, y añade además nuevas funciones y/o mejora
el rendimiento.

Características de la BPR como lograrlo.

Una vez establecidos los requisitos que el proceso de BPR debe de reunir
podemos determinar características comunes en dichos procesos:
1. Unificar las tareas: se unifican varias tareas en un equipo y como
consecuencia logramos la reducción de plazos,

Que no es reingeniería.
Cuando hablamos de reingeniería, no se trata de automatizar un proceso.
Sino que tratamos de ofrecer maneras más eficientes de hacer lo que no se bebe
hacer. NO se trata de mejorar lo deficiente se trata de reinventar de forma que
comience a ser eficiente desde su concepción. En la reingeniería de software no
se puede reestructurar o reducir, algo que consiste en hacer menos empleando
menos, sino reinventar, algo mucho mas fácil que consiste en hacer más
empleando menos.

Conclusión

Bibliografía

Reingeniería del Cambio – Benoît Grouard y Francis Meston – Alfaomega

Marcombo – 1995

Reingeniería – Michael Hammer y James Champy – Norma – 1993

La creatividad y la administración del cambio – Tudor Rickards – Oxford – 1999

Psicología Organizacional – Fernando Zepeda Herrera – Addison Wesley

Longman / Pearson – 1999

Revolución Empresarial – Francis Goullart y James Kelly – McGraw Hill – 1996

Reconceptualización de los negocios – Mauricio Lefcovich – www.monografia.com

Hammer Michael & Champy James. Reingenieria. Editorial: Carvajal S.A, Edición:
1994, 2004