154

UNVERSDAD SALESANA DE BOLVA DOCENTE: LC.
ZARA YUJRA CAMA

CARRERA NGENERA DE SSTEMAS MATERA: NGENERA DE SOFTWARE
1

UNIDAD I
CONCEPTOS SOBRE GESTION DE PROYECTOS

1. INTRODUCCION

QU ES? Aunque muchos de nosotros (en nuestros momentos ms oscuros)
tomamos la visin de Dilbert sobre la "gestin, falta una actividad muy necesaria
cuando se construyen productos y sistemas basados en computadoras. La gestin de
proyectos implica la planificacin, supervisin y control del personal, del proceso y de
los eventos que ocurren mientras evoluciona el software desde la fase preliminar a la
implementacin operacional.

QUIN LO HACE? Todos "gestionamos de algn modo, pero el mbito de las
actividades de gestin vara en funcin de la persona que los realiza. Un ingeniero de
software gestiona sus actividades da a da, planificando, supervisando y controlando
las tareas tcnicas. Los gestores del proyecto planifican, supervisan y controlan el
trabajo de un equipo de ingenieros de software. Los gestores expertos coordinan la
relacin entre el negocio y los profesionales del software.

POR QU ES IMPORTANTE? La construccin de software de computadora es una
empresa compleja, particularmente si participa mucha gente, trabajando durante un
periodo de tiempo relativamente largo. Esta es la razn por la cual los proyectos de
software necesitan ser gestionados.

CULES SON LOS PASOS? Comprender las cuatro "P's Personal, Producto,
Proceso y Proyecto -. El personal debe estar organizado para desarrollar el trabajo
del software con efectividad. La comunicacin con el cliente debe ocurrir para que se
comprenda el alcance del procducto y los requisitos. Debe seleccionarse el proceso
adecuado para el personal, y el producto. El proyecto debe planificarse estimando el
esfuerzo y el tiempo para cumplir las tareas; definiendo los productos del trabajo,
estableciendo puntos de control de calidad y estableciendo mecanismos para controlar
y supervisar el trabajo definido en la planificacin.

CUL ES EL PRODUCTO OBTENIDO? Un plan de proyecto se realiza al
comienzo de las actividades de gestin. El plan define el proceso y las tareas a
realizar el personal que realizar el trabajo y los mecanismos para evaluar los riesgos,
controlar el cambio y evaluar la calidad.

CMO PUEDO ESTAR SEGURO DE QUE LO HE HECHO CORRECTAMENTE?
Nunca ests completamente seguro de que el plan de proyecto es correcto hasta que
no has entregado un producto de alta calidad dentro del tiempo y del presupuesto.
Sin embargo, un gestor de proyectos hace lo correcto cuando estimula al personal
para trabajar juntos como equipo efectivo, centrando su atencin en las necesidades
del cliente y en la calidad del producto.

2. EL ESPECTRO DE LA GESTION

La gestin eficaz de un proyecto de software se centra en las cuatro P's: Personal,
Producto, Proceso y Proyecto. El orden no es arbitrario. El gestor que se olvida que
el trabajo de ingeniera del software es un esfuerzo humano intenso nunca tendr xito
en la gestin de proyectos. Un gestor que no fomenta una minuciosa comunicacin
UNVERSDAD SALESANA DE BOLVA DOCENTE: LC. ZARA YUJRA CAMA
2
con el cliente al principio de la evolucin del proyecto se arriesga a construir una
elegante solucin para un problema equivocado. El administrador que presta poca
atencin al proceso corre el riesgo de arrojar mtodos tcnicos y herramientas
eficaces al vaco. El gestor que comprende un proyecto sin un plan slido arriesga el
xito del producto.

2.1 PersonaI. La necesidad de contar con personal para el desarrollo del software
altamente preparado y motivado se viene discutiendo desde los aos 60. De
hecho, el "factor humano es tan importante que el nstituto de ngeniera del
Software ha desarrollado un Modelo de Madurez de Capacidad de Gestin de
Personal (MMCGP) "para aumentar la preparacin de organizaciones del software
para llevar a cabo las cada vez ms complicadas aplicaciones ayudando a atraer,
aumentar, motivar, desplegar y retener el talento necesario para mejorar su
capacidad de desarrollo de software.

El Modelo de Madurez de gestin de personal define las siguientes reas clave
prcticas para el personal que desarrolla software: Reclutamiento, Seleccin, Gestin
de Rendimiento, Entrenamiento, retribucin, Desarrollo de la Carrera, Diseo de la
Organizacin y del Trabajo y Desarrollo Cultural y de Espritu de Equipo.

El MMCGP es compaero del modelo de madurez de la capacidad de software, que
gua a las organizaciones en la creacin de un proceso de software maduro.

2.2 Producto.

Antes de poder planificar un proyecto, se deberan establecer objetivos y el mbito del
producto, se deberan considerar soluciones alternativas e identificar las dificultades
tcnicas y de gestin. Sin esta informacin es imposible definir unas estimaciones
razonables (y exactas) del coste; una valoracin efectiva del riesgo, una subdivisin
realista de las tareas de l proyecto o una planificacin del proyecto asequible que
proporcione una indicacin fiable del progreso.

El desarrollador de software y el cliente deben reunirse para definir los objetivos del
producto y su mbito. En muchos casos, esta actividad empieza como parte del
proceso de ingeniera del sistema o del negocio y contina con el primer paso en el
anlisis de los requisitos del software. Los objetivos identifican las metas generales
del proyecto sin considerar cmo se conseguirn.

El mbito identifica los datos primarios, funciones y comportamientos que caracterizan
al producto, y ms importante, intenta abordar estas caractersticas de una manera
cuantitativa.

Una vez que se han entendido los objetivos y el mbito del producto, se consideran
soluciones alternativas.

2.3 Proceso.

Un proceso de software proporciona la estructura desde la que se puede establecer un
detallado plan para el desarrollo del software. Un pequeo nmero de actividades
estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta
su tamao o complejidad. Diferentes conjuntos de tareas permiten a las actividades
estructurales adaptarse a las caractersticas del proyecto de software y a los requisitos
del equipo del proyecto. Finalmente, las actividades protectoras tales como garanta
de calidad del software y medicin cubren el modelo de proceso. Las actividades
3
protectoras son independientes de las estructurales y tienen lugar a lo largo del
proceso.

2.4 Proyecto.

Dirigimos los proyectos de software planificados y controlados por una razn principal -
es la nica manera de gestionar la complejidad . Y todava seguimos esforzndonos.
En 1998, los datos de la industria del software indicaron que el 26 por 100 de
proyectos de software fallaron completamente y que el 26 por 100 experimentaron un
desbordamiento en la planificacin y en el coste. Aunque la proporcin de xito para
los proyectos del software ha mejorado un poco, nuestra proporcin de fracaso de
proyecto permanece ms alto del que debera ser.

Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros
del software que construyeron el producto deben eludir un conjunto de seales de
peligro comunes; comprender los factores del xito crticos que conducen a la gestin
correcta del proyecto y desarrollar un enfoque de sentido comn para planificar,
supervisar y controlar el proyecto.

4

UNIDAD II

PLANIFICACIN DE PROYECTOS DE SOFTWARE

La gestin de un proyecto de software comienza con un conjunto de actividades que
globalmente se denominan planificacin del proyecto. Antes de que el proyecto
comience, el gestor y el equipo de software deben realizar una estimacin del trabajo a
realizar, de los recursos necesarios y del tiempo que transcurrir desde el comienzo
hasta el final de su realizacin. Siempre que estimamos, estamos mirando hacia el
futuro y aceptamos resignados cierto grado de incertidumbre.

A QUE SE REFIERE LA PLANIFICACIN DE PROYECTOS?
La planificacin de un proyecto de software realmente comprende todas las
actividades tratadas en temas anteriores. Sin embargo en el contexto de este tema la
planificacin implica estimacin su intento por determinar cunto dinero, esfuerzo,
recursos, y tiempo supondr construir un sistema producto especfico de software.

QUIN LO HACE?
Loa gestores del software utilizando la informacin solicitada a los clientes y a los
ingenieros de software y los datos de mtricas de software obtenidas de proyectos
anteriores.

POR QU ES IMPORTANTE?
Podra construir una casa sin saber cuanto estara dispuesto a gastar? Por supuesto
que no, y puesto que la mayora de los sistemas y productos basados en computadora
cuestan considerablemente ms que construir una casa grande, podra ser razonable
desarrollar y estimar antes de empezar a construir el software.

CULES SON LOS PASOS?
La estimacin comienza con una descripcin del mbito del producto. Hasta que no
se "delimita el mbito no es posible realizar una estimacin con sentido. El problema
es entonces descompuesto en un conjunto de problemas de menor tamao y cada uno
de estos se estima guindose con datos histricos y con la experiencia. Es
aconsejable realizar las estimaciones utilizando al menos dos mtodos diferentes
(como comprobacin). La complejidad y el riesgo del problema se considera antes de
realizar la estimacin final.

CUL ES EL PRODUCTO OBTENIDO?
Se obtiene una tabla que indica las tareas a desarrollar, las funciones a implementar, y
el coste, esfuerzo y el tiempo necesario para la realizacin de cada uno. Tambin se
obtiene una lista de recursos necesarios para el proyecto.

CMO PUEDE ESTAR SEGURO DE QUE LO HA HECHO CORRECTAMENTE?
Esto es difcil, puesto que realmente no lo sabr hasta que el proyecto haya finalizado.
Sin embargo, si tienen experiencia y sigue un enfoque sistemtico, realiza
estimaciones utilizando datos histricos slidos, crea puntos de estimacin mediante al
menos dos mtodos diferentes y descompone la complejidad y el riesgo, puede estar
seguro de hacer acertado correctamente.

1. OBSERVACIONES SOBRE LA ESTIMACIN.

A un destacado ejecutivo se le pregunt una vez por la caracterstica ms importante
que debe tener un gestor de proyectos. Respondi: " ... una persona con la habilidad
5
de saberqu es lo que va a ir mal antes de que ocurra .... Debemos aadir: "... y con
el coraje para hacer estimaciones cunado el futuro no est claro ....

La estimacin de recursos, costes y planificacin temporal de un esfuerzo en el
desarrollo del software requiere experiencia, acceder a una buena informacin
histrica y el coraje de confiar en predicciones (medidas) cuantitativas cuando todo lo
que existe son datos cualitativos. La estimacin conlleva un riesgo inherente y este
riesgo el que conlleva a la incertidumbre.

Se deben considerar:

- La complejidad del proyecto: Tiene un gran efecto en la incertidumbre, que es
inherente en la planificacin. Sin embargo, la complejidad es una medida
relativa que se ve afectada por la familiaridad con esfuerzos anteriores.

- El tamao del proyecto: Otro factor importante que puede afectar a la precisin
y a la eficiencia de las estimaciones. A medida que el tamao aumenta, crece
rpidamente la interdependencia entre varios elementos del software.

- El grado de incertidumbre estructural: Tiene tambin efecto en el riesgo de la
estimacin. En este contexto, la estructura se refiere al grado en el que los
requisitos se han definido, las facilidad con la que pueden subdividirse
funciones, y la naturaleza jerrquica de la informacin que debe procesarse.

La disponibilidad de informacin histrica tienen una fuerte influencia en el riesgo
de la estimacin. Al mirar atrs, podemos emular lo que se ha trabajado y mejorar
las reas en donde surgieron problemas. Cuando se dispone de las mtricas
completas del software de proyectos anteriores , se pueden hacer estimaciones
con mayor seguridad; esablecer planificaciones para eviatar dificultades anteriores,
y as reducir el riesgo global.

El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas
establecidas por recursos, coste y planificacin temporal..

2. OBJETIVOS DE LA PLANIFICACIN DEL SOFTWARE

El objetivo de la planificacin del proyecto de software es proporcionar un marco de
trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y
planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo
limitado al comienzo de un proyecto de software, y deberan actualizarse
regularmente a medida que progresa el proyecto. Adems las estimaciones deberan
definir los escenarios del "mejor caso y "peor caso de forma que los resultados del
proyecto puedan limitarse.

AMBITO DEL SOFTWARE.

Es la primera actividad de la planificacin del proyecto de software, se debe
delimitar su declaracin.

El mbito del software describe:
- El control y los datos a procesar
- La funcin
- El rendimiento
- Las restricciones
- Las interfaces
6
- La fiabilidad

2.1.1 OBTENCION DE LA INFORMACIN NECESARIA PARA EL AMBITO

Al principio de un proyecto de software las cosas siempre estn borrosas. Se ha
definido una necesidad y se han enunciado Ias metas y objetivos bsicos, pero
todava no se ha estabIecido Ia informacin necesaria para definir eI mbito
(prerrequisito para la estimacin).

La tcnica utilizada con ms frecuencia para acercar al cliente y al desarrollador, y
para hacer que comience el proceso de comunicacin es establecer un reunin o
entrevista preliminar. La primera reunin entre un ingeniero de software (el
analista) y el cliente puede compararse a la primera cita entre adolescentes.
Ninguna persona sabe lo que va ha preguntar, ambos estn preocupados por si lo
que dicen es mal interpretado; ambos estn pensando hasta donde podran llegar
(probablemente ambos tienen expectativas diferentes); ambos quieren quitrselo
de encima; pero al mismo tiempo quieren que salga bien.

Gause y Weinberg sugieren que el analista comience haciendo preguntas de
contexto libre (abiertas). Es decir, una serie de preguntas que lleven a:
- Un entendimiento bsico del problema
- Las personas que estn interesadas en la solucin
- La naturaleza de la solucin que se desea y la efectividad prevista
PREGUNTAS QUE PODRAN FORMULARSE:
- Quin est detrs de la solicitud de este trabajo?
- Quin utilizar esta solucin?
- Cul es el beneficio econmico de una buena solucin?
- Hay otro camino para la solucin?

Las preguntas siguientes permiten que el analista comprenda mejor el problema y
que el cliente exprese sus percepciones sobre una solucin:
- Cmo caracteriza (el cliente) un resultado "correcto que se generara con una
solucin satisfactoria?
- Con qu problema(s) se afrontar esta solucin satisfactoria?}
- Puede mostrarme (o describirme) el entorno en el que se utilizar la solucin?
- hay aspectos o limitaciones especiales de rendimiento que afecten a la forma
en que se aborde la solucin?

La ltima serie de preguntas se centra en la efectividad de la reunin, Gause y
Weinberg las llaman "metacuestiones y proponen la lista siguiente (abreviada):

- Es Ud. La persona apropiada para responder a estas preguntas?
- Son "oficiales las respuestas?
- Son relevantes mis preguntas para su problema?
- Estoy realizando muchas preguntas?
- Hay alguien ms que pueda proporcionar informacin adicional?
- Hay algo ms que debera preguntarle?

La sesin P&R sIo se debera usar para eI primer encuentro,
reempIazndose posteriormente por un tipo de reunin que combine
eIementos de resoIucin de probIemas, negociacin y especificacin.

7
2.1.2 VIABILIDAD

Putnam y Myers sugieren, de forma acertada, que el estudio del mbito no es
suficiente. Una vez que se ha comprendido el mbito, tanto el equipo de desarrollo
como el resto deben trabajar para determinar si puede ser construido dentro de las
dimensiones reflejadas anteriormente (Si es Viable o Factible de realizarse:
Tcnicamente, Econmicamente, Tiempo, Recursos). Esto es crucial, aunque es
una parte del proceso de estimacin pasada por alto a menudo.

3. RECURSOS
La segunda tarea de la planificacin del desarrollo de software es la estimacin de los
recursos requeridos para acometer el esfuerzo de desarrollo del software. La figura 1
muestra los recursos de desarrollo en forma de pirmide..

PERSONAS
COMPONENETES DE
SOFTWARE
REUTLZABLES
HERRAMENTAS DE
HARDWARE/SOFTWARE
FIGURA 1. RECURSOS DEL PROYECTO

3.1 RECURSOS HUMANOS.
El encargado de la planificacin comienza elevando el mbito y seleccionando las
habilidades que se requieren para llevar a cabo el desarrollo. Hay que especificar
tanto la posicin dentro de la organizacin (p.e. Gestor, ng. De Software
Experimentado, etc. ) como la especialidad (p.e. Telecomunicaciones, Bases de
Datos, Cliente/Servidor, etc.). En proyectos relativamente pequeo una sola persona
podr llevar a cabo todos los pasos de ingeniera del software, consultando con
especialistas siempre que sea necesario.

El nmero de personas requerido para un proyecto de software slo puede ser
determinado despus de hacer estimacin del esfuerzo de desarrollo (p.e. personas -
mes).

3.2 RECURSOS DE SOFTWARE REUTILIZABLES

La ingeniera de Software basada en Componentes (SBC) destaza la reutilizacin
esto es, la creacin y la reutilizacin de bloques de construccin de software Dichos
bloques de construccin, llamados compomentes, deben establecerse en catlogos
para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para
una fcil integracin.

Bennatan sugiere cuatro categoras de recursos de software que se deberan tener en
cuenta a medida que se avanza con la planificacin:

1. Componentes ya desarroIIados: El software existente se puede adquirir de
una tercera parte o provenir de uno desarrollado internamente para un proyecto
anterior. Llamados componentes Comercialmente ya desarrollados (CCYD),
8
estos componenetes estn listos para utilizarse en el proyecto actual y se han
validado totalmente.

2. Componentes ya experimentados: Especificaciones, Diseos, Cdigo o
Datos de Prueba existentes desarrollados para proyectos anteriores que son
similares al software que se va a construir para el proyecto actual. Los
miembros del equipo de software actual ya han tnido la experiencia completa
en el rea de la aplicacin representada para estos componentes. Las
modificaciones, por tanto requeridas para componentes de total experiencia,
tendrn un riesgo relativamente bajo.

3. Componentes con experiencia parciaI: Especificaciones, Diseo, Cdigo o
datos de prueba existente desarrollados para proyectos anteriores que se
relacionan con el software que se va ha construir para el proyecto actual, pero
que requieren una modificacin sustancial. Los miembros del equipo se
software actual han limitado su experiencia slo al rea de aplicacin
representada por estos componentes. Las modificaciones, por tanto,
requeridas para componentes de experiencia parcial tendrn bastante grado de
riesgo.

4. Componentes nuevos: Los componentes de software que el equipo de
software debe construir especficamente para las necesidades del proyecto.

De forma irnica, a menudo se descuida Ia utiIizacin de componentes de
software reutiIizabIes durante Ia pIanificacin, IIegando a convertirse en Ia
preocupacin primordiaI durante Ia fase de desarroIIo deI proceso de
software. Es mucho mejor especificar al primcipio las necesidades de recursos
del software. De esta forma se puede dirigir la evaluacin tcnica de alternativas y
puede tener lugar la adquisicin oportuna.

3.3 RECURSOS DE ENTORNO

El entorno es donde se apoya el proyecto de software, llamado a menudo Entrono de
ngeniera de Software (ES). El hardware proporciona una plataforma con las
herramientas (software) requeridas para producir los productos que son el resultado de
un buen prctica de reingeniera del software. Como la mayora de las organizaciones
de software tienen muchos aspectos que requieren acceso a ES, un planificador de
proyecto debe determinar la ventana temporal requerida para el hardware y el software

4. TCNICAS DE DESCOMPOSICIN
TAMAO DEL SOFTWARE

En el contexto de la planificacin de proyectos, el tamao se refiere a una
produccin cuantificable del proyecto del proyecto. Si se toma un enfoque directo,
el tamao puede medirse en LDC. Si se selecciona un enfoque un enfoque
indirecto, el tamao se representa como PF.

Tamao en Igica difusa: Este enfoque usa tcnicas aproximadas de
razonamientos que son la piedra angular de la lgica difusa.

Tamao de componentes estndar: El planificador de proyectos desarrolla
estimaciones de caractersticas del dominio de informacin estudiadas en el captulo
anterior (Ver Mtricas del PF).

9
Tamao de cambio: El software se compone de un nmero de "componentes
estndar" que son genricos para un rea en particular para un sistema de
informacin son: subsistemas, mdulos, pantallas, informes, programas interactivos,
LDC e instrucciones para objetos. El planificador de proyectos estima el nmero de
incidencias de cada uno de los componentes estndar y utiliza datos de proyectos
histricos para determinar el tamao de entrega por componente estndar.

Tamao del cambio: El enfoque se utiliza cuando un proyecto comprende la
utilizacin de software existente que se debe modificar de alguna manera como de un
proyecto como parte de un proyecto. El planificador estima el nmero y tipo de
modificaciones que se deben llevar a cabo.

ESTIMACIONES BASADAS EN PROBLEMAS

Las estimaciones de LDC, y PF son tcnicas de estimacin distintas. El
planificador del proyectos comienza con un enfoque limitados para el mito del
software y desde este estado intenta descomponer el software en funciones que se
pueden estimar individualmente. Para cada funcin se estiman las LDC y el PF.

USO DE ESTIMACION BASADA EN LDC

Considrese la situacin de la una empresa denominada Supermercados KETAL",
la que cuenta con sucursales en La Paz, Cbba y Sta. Cruz, cuenta en cada
sucursal con 20, 30, 40 empleados respectivamente. La empresa requiere los
servicios de consultora en software para el inicio de un proyecto que permita
contar con un sistema integrado que permita el control del inventario existente de
los productos que ofrece, el control de asistencia y sanciones al personal, adems
como se cuentan con lectores en cdigo de barra se desea que las ventas se
controlen usando el mismo as como su registro en inventarios, se desea llevar u
registro de toda la clientela de modo que si se tiene alguna promocin stos
resulten primeramente beneficiados, Se desean registrar los activos fijos que tiene
la empresa en cada sucursal, tambin hacer un seguimiento del record de trabajo
de cada persona de modo que se las pueda categorizar para el pago de su salario,
tambin en cuanto a ventas se desea realizar un seguimiento de los pedidos y
compras realizados a los proveedores, as como las ventas al por mayor bajo
convenio con instituciones.

Realizar el anlisis respectivo usando un estimacin basada en LDC.

USO DE ESTIMACION BASADA EB PF

Considerando el detalle anterior:
Realizar el anlisis respectivo usando un estimacin basada en PF

PROBLEMA DE APLICACIN:

Estimacin basada en el tamao

Luego de comprendido en mbito del proyecto, y habiendo realizado un estudio ms
detallado se identifican las funciones de software siguientes:

- Control de nventarios(Productos en stock, Activos Fijos)
- Control del Personal
- Elaboracin de Planillas de Sueldo
- Transacciones de productos (Compras, Ventas, Promociones,)
10

Por experiencia propia se conocen las lneas de cdigo necesarias para sistemas de
Control de nventarios: S
opt
=3000 S
m
=4200 S
pes
=5000

FUNCION S
opt
S
m
S
pes

Control de Inventarios 3.000 4.200 5.000
Control del Personal 6.000 6.800 8.000
Elaboracin de Planillas de Sueldo 4.000 5.500 7.000
Transacciones de productos 7.000 7.800 9.000

Aplicando la frmula respectiva para hallar la media ponderada ( Valor Esperado -
VE) para estimar las LDC:

VE = (S
+ 4S
+S
)/6

Por ejemplo para el Control de inventarios, tendremos un valor esperado de:
VE=(3.000 + 4*4.200+5.000) = 24800/6 = 4133

De la misma forma se realizarn otras estimaciones:

FUNCION LDC ESTIMADO
Control de Inventarios 4133
Control del Personal 6867
Elaboracin de Planillas de
Sueldo
5500
Transacciones de productos 7867
LINEAS DE CODIGO
ESTIMADAS
24367

DATOS HISTORICOS

Adems por la experiencia obtenida en anteriores proyectos similares se tienen los
siguientes datos histricos:
Es posible realizar:
- 1500 LDC/pm (Lneas de cdigo por mes)
- Tarifa Laboral de 7.500 Bs por mes a cada programador incluye impuestos de
ley
- Coste total del proyecto: 55.000 Bs
Por lo que cada lnea de cdigo cost: 7.500/1.500 = 5 Bs
Esfuerzo estimado es:
Aplicando la regla de tres

7.500Bs ---------------------------- 1persona

55.000Bs ---------------------------- X personas

Luego: X = (55.000*1)/7.500 = 7 personas

DATOS ESTIMADOS

En el presente proyecto se precisar:
Por lo que cada lnea de cdigo cost: 7.500/1.500 = 5 Bs
Esfuerzo estimado es:
Aplicando la regla de tres
11

1.500 LDC ---------------------------- 1persona

24.367 LDC ---------------------------- X personas

Luego: X = (24.367*1)/1.500 = 16 personas
Costo total del Proyecto: 16 *7.500 = 24.000 Bs

5. METRICAS ORIENTADAS A LA FUNCION

Este tipos de mtricas del software orientadas a la funcin utilizan una medida de la
funcionalidad entregada por la aplicacin como valor de normalizacin. Por ser la
"funcionalidad una medida indirecta no es posible medirse directamente, se debe
entonces derivar indirectamente mediante otras medidas directas. Fueron propuestas
por primera vez por Albretch [ALB79], quien sugigiri{o una medida llamada punto de
funcin.

Se deben considerar los siguientes aspectos que a continuacin se mencionan en el
siguiente esquema:

CALCULO DE PUNTOS DE FUNCION

Caractersticas deI
Sistema
CompIejidad
Baja
CompIejidad
Media
CompIejidad
AIta
Nmero de entradas 3 4 6
Nmero de salidas 4 5 7
Consultas 3 4 6
Archivos lgicos internos 7 10 15
Archivos de interfaz
externos
5 7 10

Para calcular los puntos de funcin (PF), se utiliza la relacin siguiente:

PF = cuenta-total X [0.65 + 0,01 X
14
i=1

(F
i
)]

Donde:
cuenta totaI:
Es la suma de todas las entradas PF obtenidas al aplicar los parmetros
de la tabla anterior.
F
i
(i= 1 al 14)
Son valores de ajuste de complejidad segn respuestas a las siguientes
preguntas:

1. Requiere el sistema de copias de seguridad y recuperacin
fiables?
2. Requiere comunicacin de datos?
3. Existen funciones de procesamiento distribuido?
4. ?Es crtico el rendimiento
5. Se ejecutar el sistema en un entorno operativo existente y
fuertemente utilizado?
6. Requiere el sistema entrada de datos interactiva?
12
7. Requiere la entrada de datos interactiva que las transacciones de
entrada se lleven a cabo sobre mltiples pantallas u operaciones?
8. Se actualizan los archivos de forma interactiva?
9. Son complejas las entradas, las salidas, los archivos o las
peticiones?
10. Es complejo el procesamiento interno?
11. Se ha diseado el cdigo para ser reutilizable?
12. Estn incluidos en el diseo la conversin y la instalacin?
13. Se ha diseado el sistema para soportar mltiples instalaciones en
diferentes organizaciones?
14. Se ha diseado la aplicacin para facilitar los cambios y para ser
fcilmente utilizada por el usuario?

Cada una de las preguntas anteriores es respondida usando una nueva escala con
rangos desde 0 (no importante o aplicable) hasta 5 absolutamente esencial. Los
valores constantes de la ecuacin y los factores de peso que se aplican a las cuentas
de dominios de informacin se determinan empricamente.

VaIores de ajuste de compIejidad

Descripcin VaIor
Sin influencia 0
Accidental, nfluencia no
significativa 1
Moderado, nfluencia
moderada 2
Medio, nfluencia media 3
Significativo, nfluencia
significativa. 4
Esencial, nfluencia esencial 5

Una vez calculados los puntos de funcin, se utilizan de manera anloga a las LDC
como forma de normalizar las medidas de productividad, calidad y otros atributos de
software.

6. ESTIMACIN DEL COSTE DEL PROYECTO

Existen una serie de mtricas propuestas por la Ingeniera deI Software para
determinar el esfuerzo de un proyecto, el alcance del mismo y la productividad de sus
programadores. Vamos a aplicar algunas de las mismas a este desarrollo, para
calibrar su dificultad y rendimiento obtenido.

Las mtricas orientadas a tamao
La mtrica del software es un factor realmente importante en el anlisis de un
proyecto. Las mtricas orientadas al tamao proporcionan medidas directas del
software y del proceso por el cual se desarrolla. Se basan en la medicin del nmero
de Lneas De Cdigo LDC - que contiene el desarrollo, entendiendo por lnea de
cdigo una sentencia del lenguaje de programacin (se excluyen comentarios y lneas
en blanco de los fuentes)
13
Una forma de clasificarlos es atendiendo al nmero de lneas de cdigo, como se
muestra en la tabla:

Categora Programadores Duracin
Lneas de
cdigo
Ejemplo
Trivial 1
0 4
semanas
< 1k Utilidad de ordenacin
Pequeo 1
1 6
meses
1k 3k Biblioteca de funciones
Media 2 5
0,5 2
aos
3k 50k Compilador de C
Grande 5 20 2 3 aos 50k 100k SO pequeo
Muy grande 100 1000 4 5 aos 100k 1M Grandes SO
Gigante 1000-5000
5 10
aos
> 1M Sistema de Distribucin
TabIa: "Categora de un proyecto en funcin de sus Ineas de cdigo"

SpiderBot ha generado ms de 8.200 lneas de cdigo, con lo que nos enfrentamos a
un proyecto software con una clasificacin de complejidad media, para el cual se
necesitaran de 2 a 5 programadores trabajando de medio ao a 2 aos.

El mtodo COCOMO

Una metodologa que se encarga de medir proyectos software es COCOMO. La
metodologa COCOMO (COnstructive COst MOdel) se debe a Barry Boehm, y est
orientada a lneas de cdigo.
Hay una jerarqua de modelos COCOMO: bsico, intermedio y avanzado, la cual se
aplica a tres tipos diferentes de software:

1. Orgnico: proyectos relativamente sencillos, menores de 50.000 lneas de
cdigo. Se tiene experiencia en proyectos similares y se encuentra en un
entorno estable.
2. SemiacopIado: proyectos intermedios en complejidad y tamao. La
experiencia en este tipo de proyectos es variable, y las restricciones
intermedias.
3. Empotrado: proyectos bastante complejos, en los que apenas se tiene
experiencia y en un entorno de gran innovacin tcnica. Se trabaja con unos
requisitos muy restrictivos y de gran volatilidad.

Dado que slo se va a emplear una variable para la estimacin (la lnea de cdigo), se
emplear COCOMO bsico, ya que es un modelo univariable esttico, con lo que se
obtiene una vaIoracin objetiva del esfuerzo realizado. Este proyecto ser
considerado como software orgnico, ya que posee menos de 50.000 lneas de
cdigo.
La ecuacin del esfuerzo de COCOMO bsico tiene la siguiente forma:

E = Esfuerzo = a KLDC
(persona x mes)

donde KLDC es el nmero de lneas de cdigo, distribuidas en millares, para el
proyecto.
La ecuacin del tiempo de desarrollo es:

T = Tiempo de duracin del desarrollo = c Esfuerzo
(meses)
14

Por su parte los coeficientes a, b, c y d se obtienen empricamente del estudio de una
serie de proyectos, y sus valores son:

Proyecto de software a b c d
Orgnico 2,4 1,05 2,5 0,38
Semiacoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32
TabIa "Coeficientes COCOMO"

En el desarrollo de SpiderBot se han codificado 8,2 miles de lneas de cdigo.
Esfuerzo realizado = 2,4 * 8,2
1,05
= 21,9 personas-mes
T = 2,5 * 21,9
0,38
= 8,1 mes
N de personas para desarrollar el proyecto = E/T= 21,9 / 8,1 3 personas

La controversia: Lneas de cdigo frente a puntos de funcin

Existe en el mundo de la ngeniera del Software una viva polmica sobre qu tipo de
mtricas son mejores para evaluar un proyecto: las orientadas a tamao o las que
utilizan puntos de funcin.
El centro de controversia est en considerar las lneas de cdigo como medida clave,
ya que los que se oponen a su uso, aducen que las medidas basadas en lneas de
cdigo son dependientes del lenguaje de programacin. En cualquier caso esta
polmica queda apartada gracias a Casper Jones, quin cre la siguiente tabla de
correspondencia entre algunos de los lenguajes de programacin ms conocidos con
su nmero de equivalencia entre lneas de cdigo por punto de funcin:

Lenguaje LDC/PF
Ensamblador 320
C 150
Cobol 106
Pascal 91
Basic 64
TCL 64
Java 53
C++ 29
TabIa "Conversin Lneas de cdigo a Puntos de funcin"

Conclusiones

Con todo este astudio, debemos concluir que se ha reaIizado un gran esfuerzo, pues
la mtrica nos dice que habiendo desarrollado un programa de este tamao hubiesen
sido necesarias tres personas, en lugar de solo una como ha sido el caso, para
desarroIIar eI Proyecto en tan solo nueve meses.

Adems se puede comparar este desarrollo con el de un compiIador tarea nada
desdeable, y que ha sido el desarrollo de varios alumnos para obtener el ttulo de
ingeniero correspondiente al cicIo superior.

15
7. ESTIMACIN DE COSTOS
Todo proyecto de ingeniera de software debe partir con un buen plan, pero
lamentablemente, la planificacin es una tarea nada trivial. Uno de los aspectos que
dificultan la labor de administradores y jefes de proyecto en torno a la planificacin es
la difcil tarea de realizar una estimacin de costos y plazos realista.
La estimacin es ms arte que ciencia; tambin es parte de la etapa de la planificacin
y algunas actividades de la ingeniera. La diferencia en la estimacin de costos entre
ingeniera de software y otras disciplinas es que en ingeniera de software lo principal
para las personas es el costo; y en otras disciplinas el costo de las cosas materiales
depende de la actividad.
Existen tcnicas para la estimacin de costos, pero para ello se requiere experiencia,
acceso a una buena informacin histrica y coraje para confiar en medidas
cuantitativas cuando todo lo que existe son datos cualitativos.
El manejador de costo principal para un proyecto de desarrollo de software es sin duda
el tamao del producto. La medida del tamao debe ser tal que est en relacin
directa con el esfuerzo de desarrollo, por lo que las mtricas de tamao tratan de
considerar todos los aspectos que influyen en el costo, como tecnologa, tipos de
recursos y complejidad.

7.1 MTRICAS PARA LA PRODUCTIVIDAD Y CALIDAD DEL SOFTWARE
La medicin es esencial para cualquier disciplina de ingeniera y la ingeniera de
software no es una excepcin.
Las mtricas de software se refieren aun amplio rango de medidas para el software de
computadoras dentro del contexto de la planificacin del proyecto de software, las
mtricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los
cuales directamente afectan a la estimacin de costos.
Las mediciones en el mundo fsico pueden ser catalogadas en dos campos: medidas
directas (por ej. La longitud de un tornillo), y medidas indirectas (por ej. Calidad de
tornillos producidos, medida por la cuenta de los tornillos rechazados). Las mtricas
de software pueden ser catalogadas de forma parecida.
Se puede clasificar en:
Mtricas de productividad, se centran en el rendimiento del proceso de la ingeniera de
software.
Mtricas de Calidad, proporcionan una indicacin de cmo se ajusta el software, a los
requerimientos implcitos y explcitos del cliente.
Mtricas Tcnicas, se centran en el carcter del software mas que en el proceso, a
travs del cual el software a sido desarrollado.
Mtricas Orientadas al tamao, son utilizadas para obtener medidas directas del
resultado y la calidad de la ingeniera del software.
Mtricas Orientadas a la Funcin, son medidas indirectas del software y del proceso
por el cual se desarrollar; se centran en la funcionalidad o utilidad del programa
(Puntos de Funcin)
16
Mtricas Orientadas a la persona, consiguen informacin sobre la forma en que la
gente desarrolla software de computadora y sobre el punto de vista humano de la
efectividad de las herramientas y mtodos.
7.2 ESTIMACION DEL PROYECTO DE SOFTWARE
Para realizar estimaciones seguras de coste y esfuerzo surge un numero de posible de
opciones como:
Retrasar la estimacin mas adelante en el proyecto (obviamente se puede hacer una
estimacin cien por ciento fiable despus de completar el proyecto)
Utilizar "tcnicas de descomposicin " relativamente simples para generar las
estimaciones del proyecto de software (por ej. Estimacin LDC y PF)
Desarrollar un modelo emprico para el coste y el esfuerzo de software.
Adquirir una o ms herramientas automticas de estimacin.
Desdichadamente la primera opcin, aunque atractiva no es practica, porque las
estimaciones del coste deben ser proporcionadas de antemano. Las tres opciones
restantes son aproximaciones viables para la estimacin del proyecto de software.
Las tcnicas de descomposicin utilizan una aproximacin de "divide y vencers " para
la estimacin del proyecto de software. Los modelos de estimacin empricos pueden
utilizarse para completar las tcnicas de descomposicin y ofrecer una aproximacin
de la estimacin potencialmente evaluable por ella misma. Las herramientas
automticas de estimacin implementan una o mas tcnicas de descomposicin o
modelos empricos.
7.3 MODELOS DE ESTIMACIN EMPRICA
Un modelo de estimacin para el software por computadora utiliza formulas derivadas
empricamente para predecir los datos.
Los datos empricos que soportan la mayora de los modelos se obtienen de una
muestra limitada de proyectos. Tomando en cuenta los recursos se tienen los
modelos recursos y consisten en una o ms ecuaciones obtenidas empricamente que
predicen el esfuerzo (personas-mes), la duracin del proyecto (meses cronolgicos) o
otros datos pertinentes al proyecto. Segn Basili
1
describe cuatro modelos de recurso:
modelos simple-variable estticos (ej. COCOMO), modelos multi-variables estticos,
modelos multi-dinmicos variables y modelos tericos.
7.3.1 MODELO COCOMO
Barry Boehm en su libro "economa de la ingeniera de software" detalla un modelo
amplio de estimacin de costos llamado COCOMO (Constructive Cost Model). La
palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a
comprender mejor la complejidad del software; este modelo es un ejemplo de variable
simple esttico y es usado por miles de administradores de proyecto de software .
COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de
desarrollo, equipamiento y mantenimiento).
El modelo provee tres "niveles" de aplicacin: bsico, intermedio y avanzado, basados
en los factores considerados por el modelo.

1
En su libro: Model and Metrics Ior SoItware Management and Engineering
17
Bsico, es un modelo esttico simplemente evaluado que calcula el esfuerzo (y costo)
del desarrollo del software como funcin del programa expresado en lneas de cdigo
(LDC estimados).
ntermedio, calcula el esfuerzo del desarrollo del software como funcin del tamao del
programa y un conjunto de "guas de costo" que incluye una evaluacin subjetiva del
producto, hardware, personal y de los atributos del proyecto.
Avanzado, incorpora todas las caractersticas de la versin intermedia con una
evaluacin del impacto de las vas de costo en cada fase (anlisis, diseo, etc) del
proceso de la ingeniera de software.
El modelo bsico se extiende para considerar un conjunto de atributos de guas de
costo que pueden agruparse en cuatro categoras principales:
Producto ( por ej. Requerimientos de software, confiabilidad, tamao de la base de
datos, y complejidad del producto).
Computadora (por ej. Restricciones en el tiempo de ejecucin y almacenamiento).
Personal (por ej. Capacidad de anlisis, experiencia en aplicaciones tanto en
lenguajes de programacin y capacidad del programador)
Proyecto (por ej. Uso de practicas modernas de programacin, uso de herramientas de
software y requerimiento de un plan de desarrollo).
En cada nivel de aplicacin estn definidos para tres tipos de proyectos de software:
Modo orgnico, proyectos de software relativamente pequeos y sencillos en los que
pequeos equipos con buena experiencia en la aplicacin trabajan en un conjunto de
requerimiento poco rgidos.
Modo semi-acoplado(semi-detached), un proyecto de software intermedio en tamao y
complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer
requerimientos poco y medio rgidos
Modo acoplado(detached), un proyecto de software que debe ser desarrollado dentro
un conjunto estricto de hardware, software y de restricciones operativas.
Modos que estn basados en la complejidad de la aplicacin y el desarrollo del
ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicacin y
modos est dado por :

Donde:

E = es el esfuerzo estimado expresado en
hombres-mes
EDS es el nmero estimado de lneas de cdigo
distribuidas en miles para el proyecto
E = a (EDSI)
h
* (EAF)

18
a, h son constantes determinadas por el modo
del desarrollo, ambos incrementados por la
complejidad de la aplicacin.
EAF es el factor de ajuste de esfuerzo, es igual
a 1 para la modelo bsica e igual al
producto de 15 factores de costo para la
modelo intermedia y avanzada. Cada
factor de costo multiplicativo es reflexivo de
un incremento proporcional (> 1) o
decremento (<1) en costo.
A continuacin veremos los coeficientes para el modelo intermedio que depende de
modo de desarrollo:

MODO DE
DESARROLLO
A b c d
Organic 3.2 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32

Modo bsico utiliza el tamao y el modo intermedio 15 manejadores de costo que son
los siguientes:

Manejadores de Costo Very Low Low NominaI High
Very
High
Extra
High
ACAP Analyst Capability 1.46 1.19 1.00 0.86 0.71 -
AEXP Applications Experience 1.29 1.13 1.00 0.91 0.82 -
CPLX Product Complexity 0.70 0.85 1.00 1.15 1.30 1.65
DATA Database Size - 0.94 1.00 1.08 1.16 -
LEXP Language Experience 1.14 1.07 1.00 0.95 - -
MODP Modern Programming
Practices
1.24 1.10 1.00 0.91 0.82 -
PCAP Programmer Capability 1.42 1.17 1.00 0.86 0.70 -
RELY Required Software Reliability 0.75 0.88 1.00 1.15 1.40 -
SCED Required Development
Schedule
1.23 1.08 1.00 1.04 1.10 -
STOR Main Storage Constraint - - 1.00 1.06 1.21 1.56
TME Execution Time Constraint - - 1.00 1.11 1.30 1.66
TOOL Use of Software Tools 1.24 1.10 1.00 0.91 0.83 -
TURN Computer Turnaround Time - 0.87 1.00 1.07 1.15 -
VEXP Virtual Machine Experience 1.21 1.10 1.00 0.90 - -
VRT Virtual Machine Volatility - 0.87 1.00 1.15 1.30 -

El tiempo de desarrollo es igual a :

Donde:
TDEV = c E
d

19
E, es el esfuerzo
c,d son coeficiente, cuyos valores se indicaron
anteriormente en una tabla.
El nmero de programadores es igual a:

Representando un enfoque monoltico para la estimacin de costos, a continuacin
presentaremos un ejemplo:
Ejemplo
1. Usando COCOMO bsico para estimar el esfuerzo requerido en el desarrollo
de un programa de 850 lneas en modo orgnico se tiene los siguiente:
E = 3.2 (8.5)
1.05
* 1 = 30 Mes-hombre
Boehn tambin adopta el modelo COCOMO ntermedio para repartir costos a
componentes individuales, considerando las 8500 lneas proyectadas,
realizando la lista de componentes:

COMPONENTES EDS % TOTAL CMM
NOM

PERSONAL 2000 23.4% 7.06
FACTURA 3000 35.3% 10.60
POR COBRAR 3500 41.2% 12.36

Nivel de Componente de COCOMO ntermedio
Basado sobre 30hombre-mes para el esfuerzo (E), el numero de EDS para
hombre-mes es dado por.
(EDS/mes-hombre)
NOM
= 8500/30 = 283 EDS mes-hombre
Usando el EDS/ mes-hombre, cada componente aporta una proporcin al total
de valor por ejemplo el componente nominal mes-hombre(CMM
NOM
) para el
componente de personal es dado por:
(CMM
NOM
) = EDS
por componente
/ (EDS/MM)
NOM
= 200/283 =7.06 CMM
NOM

Despus de calcular el CMM
NOM
para cada componente, el factor de ajuste de
esfuerzo (EAF ) es calculado individualmente para cada componente. El factor
EAF es aplicado a CMM
NOM
llegando a un nuevo ajuste en mes-hombre,
estimando (CMM
ADJ
) para cada componente. Esto es como un modelo
monoltico, el cual es aplicado a un simple EAF para el sistema. Por lo tanto, es
posible aclarar las variaciones entre los factores de costo y las diversidades de
componentes. Por ejemplo: el CMM
ADJ
para el componente factura es calculado
por :
CMM
ADJ
= (CMM
NOM
)*(EAF)= 10.60*1.13 = 11.98 CMM
ADJ

PG = E / TDEV
20
2. usando COCOMO ntermedio
Modo es orgnico
Tamao = 200 KDS
Manejadores de costo>
Baja Confiabilidad => 0.88
Alta Complejidad del producto => 1.15
Baja experiencia en la aplicacin => 1.13
Alta experiencia en los lenguajes de programacin => 0.95
Otros manejadores de costo asumen a ser nominales => 1.00

EAF = .88 * 1.15 * 1.13 * .95 = 1.086

E = 3.2 * ( 200
1.05
) * 1.086 = 906 mes-hombre

TDEV = 2.5 * 906
0.38
= 33.24

PG = 906/33.24 = 27 programadores

3. Utilizando la herramienta Modelo de mplementacin ntermedio
COCOMO81, para la estimacin de costos de un Sistema Colaborativo. (ver
anexos)
Ventajas
COCOMO es transparente, se puede ver como trabaja con otros modelos tal
como SLM (Software Life Cycle Management).
Manejadores de costo ayudan particularmente a el estimador a comprender el
impacto de diferentes factores que afectan en el costo del proyecto.

Desventajas
Triunfo depende ampliamente de la adaptacin de el modelo a las necesidades
de la organizacin, usando datos histricos; los cuales no siempre estn
disponibles.
Extremadamente vulnerable para la mis-clasificacin de el modo de desarrollo.
Es difcil estimar KDS con precisin sobre el antiguo proyecto, cuando la
mayora de las estimaciones de esfuerzo son requeridas.
KDS, realmente, no es una medida del tamao, sino una medida de longitud.
Como mejora de COCOMO surgieron varias versiones de COCOMO y podemos
mencionar una de ellas que es: COCOMO , Ada COCOMO y COCOMO ncremental.
COCOMO II
El nuevo modelo incorporado en el ao 1990, tiene caractersticas de los modelos
COCOMO 81 y Ada COCOMO. COCOMO tiene tambin tres submodelos ; El
modelo de composicin de la aplicacin es usada para estimar el esfuerzo y
planificacin de proyectos que usa las herramientas integradas CASE (Computer
Aided Software Engineering) para un desarrollo rpido de la aplicacin.
Realizando una comparacin entre COCOMO 81 y COCOMO ; a este ltimo se le
aadi nuevos manejadores de costos para la aplicaciones precedentes, flexibilidad
21
en el desarrollo, necesita documentacin para el ciclo de vida, mltiples sitios de
desarrollo y requiere software reusable.
Modelo COCOMO post-arquitectura cubre el actual desarrollo y mantenimiento de
un producto de software. Esta etapa del ciclo de vida procede mas a un costo
efectivo, si el ciclo de vida de una arquitectura de software ha sido desarrollada,
validada con respecto a la misin del sistema y establecida como un marco de trabajo
para el producto.
El modelo de post-arquitectura predice el esfuerzo de desarrollo del software,
personas-mes (PM), utiliza un conjunto de 17 multiplicadores de manejadores de costo
(EM) y un conjunto de 5 escalas de manejadores de costo para determinar la escala
del exponente del proyecto (SF). Esta escalas de los manejadores de costo remplazan
los modos de aplicacin (orgnico, sem.-acoplado y acoplado); el modelo tiene la
siguiente forma:
PM = A * (Size)
1.01 +
j
5
= 1
*
17
= 1
Em
il

Los manejadores de costo tiene para elegir una de las seis posibilidades que son:
Very Low (VL), Low (L), Nominal (N), High (H), Very High (VH), y Extra High (XH); no
todos los rangos son vlidos para todos los manejadores de costo.
ADA COCOMO
Barr Bohema & Walter Roce, 1987, 1988 definen el nuevo modelo COCOMO,
llamado "Ada COCOMO".
Este modelo al igual que el COCOMO estndar utiliza los manejadores de costo y
ecuaciones anteriormente definidas.
COCOMO INCREMENTAL
Fue definido casi al mismo tiempo que Ada COCOMO. EL modelo COCOMO
ncremental es una moderna alternativa para el tradicional modelo cascada de el
desarrollo de procesos de software.
El modelo de desarrollo ncremental COCOMO permite una variedad de desarrollo de
procesos. En vez de modelar el software como a esfuerzo simple para obtener un
producto simple; el modelo incremental COCOMO permite desarrollar una serie de
proyectos de software concurrente y producir un producto intermedio.
Esta estrategia reduce risk y permite entregar un producto inicial ms fcilmente al
cliente.
Tambin existen algunas derivaciones de COCOMO como ser:
Cocots, (Constructive Cost)
Cossemo, (Constructive Staged Schedule & Effort Model).
Copromo, (Constructive Productivity mprovement Model).
Coqualmo
Coradmo

22

7.4 CONCLUSIONES
Al realizar el trabajo de investigacin acerca de COCOMO llegamos a las siguientes
conclusiones:
COCOMO es una herramienta basada en la lneas de cdigo la cual le hace
muy poderoso para la estimacin de costos y no como otros que solamente
miden el esfuerzo en base al tamao.
Hoy en da es necesario para un administrador de proyectos posser una
herramienta de estimacin de costos; y esta herramienta puede ser COCOMO.
COCOMO representa el ms extenso modelo emprico para la estimacin de
software publicado hasta la fecha.
Existen herramientas automticas que estiman costos basados en COCOMO
como ser: Costar, COCOMO 81.
Con la realizacin de este trabajo ampliamos nuestro conocimientos acerca de
la estimacin de costos que es fundamental para un analista, administrador de
proyecto.
Para mayor detalle respecto al Modelo COCOMO ver Anexos.

23
UNIDAD III

I N T R O D U C C I O N
EL PROCESO Y EL SOFTWARE

Un enfoque actuaI sobre Ia caIidad deI software

Oscar M. Fernndez Carrasco
1
, Delba Garca Len
2
y Alfa Beltrn Benavides
3

4. nvestigador Agregado. Centro de Desarrollo nformtico. SOFTCAL, SME.
5. Especialista en Sistemas de Computacin.
6. Aspirante a nvestigador.

Uno de los problemas que se afrontan actualmente en la esfera de la computacin es
la calidad del software. Desde la dcada del 70, este tema ha sido motivo de
preocupacin para especialistas, ingenieros, investigadores y comercializadores de
softwares, los cuales han realizado gran cantidad de investigaciones al respecto con
dos objetivos fundamentales:

1. Cmo obtener un software con calidad?
2. Cmo evaluar la calidad del software?

Ambas interrogantes conllevan amplias respuestas, pero estn estrechamente ligadas
con el concepto de la calidad del software, que es el resultado de la primera y la fuente
de la segunda.

QUE ES LA CALIDAD DEL SOFTWARE?
La calidad del software es el conjunto de cualidades que lo caracterizan y que
determinan su utilidad y existencia. La calidad es sinnimo de eficiencia, flexibilidad,
correccin, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad.

La calidad del software es medible y vara de un sistema a otro o de un programa a
otro. Un software elaborado para el control de naves espaciales debe ser confiable al
nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el
mismo nivel de calidad; mientras que un producto de software para ser explotado
durante un largo perodo (10 aos o ms), necesita ser confiable, mantenible y flexible
para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de
explotacin.

La calidad del software puede medirse despus de elaborado el producto. Pero esto
puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en
el diseo, por lo que es imprescindible tener en cuenta tanto la obtencin de la calidad
como su control durante todas las etapas del ciclo de vida del software.

COMO OBTENER UN SOFTWARE DE CALIDAD?

La obtencin de un software con calidad implica la utilizacin de metodologas o
procedimientos estndares para el anlisis, diseo, programacin y prueba del
software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor
confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
24
productividad, tanto para la labor de desarrollo como para el control de la calidad del
software.

La poltica establecida debe estar sustentada sobre tres principios bsicos:
tecnolgico, administrativo y ergonmico.

El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del
software.
El principio administrativo contempla las funciones de planificacin y control del
desarrollo del software, as como la organizacin del ambiente o centro de ingeniera
de software.

El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado.
La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del
software, pero no la asegura. Para el aseguramiento de la calidad es necesario su
control o evaluacin.

COMO CONTROLAR LA CALIDAD DEL SOFTWARE?

Para controlar la calidad del software es necesario, ante todo, definir los parmetros,
indicadores o criterios de medicin, ya que, como bien plantea Tom De Marco, "usted
no puede controlar lo que no se puede medir".

Las cualidades para medir la calidad del software son definidas por innumerables
autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John
Wiley define mtricas de calidad y criterios, donde cada mtrica se obtiene a partir de
combinaciones de los diferentes criterios. La Metodologa para la evaluacin de la
calidad de los medios de programas de la CC, de Rusia, define indicadores de calidad
estructurados en cuatro niveles jerrquicos: factor, criterio, mtrica, elemento de
evaluacin, donde cada nivel inferior contiene los indicadores que conforman el nivel
precedente. Otros autores identifican la calidad con el nivel de complejidad del
software y definen dos categoras de mtricas: de complejidad de programa o cdigo,
y de complejidad de sistema o estructura.

Todos los autores coinciden en que el software posee determinados ndices medibles
que son las bases para la calidad, el control y el perfeccionamiento de la
productividad.

Una vez seleccionados los ndices de calidad, se debe establecer el proceso de
control, que requiere los siguientes pasos:

Definir el software que va a ser controlado: clasificacin por tipo, esfera de
aplicacin, complejidad, etc., de acuerdo con los estndares establecidos para
el desarrollo del software.
Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada
clase de software es necesario definir los indicadores y sus magnitudes.
Crear o determinar los mtodos de valoracin de los indicadores: mtodos
manuales como cuestionarios o encuestas estndares para la medicin de
criterios periciales y herramientas automatizadas para medir los criterios de
clculo.
Definir las regulaciones organizativas para realizar el control: quines
participan en el control de la calidad, cundo se realiza, qu documentos deben
ser revisados y elaborados, etc.

25
A partir del anlisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un
proyecto para el Aseguramiento de la Calidad del Software (ACS), vlido para
cualquier entidad que se dedique a la investigacin, produccin y comercializacin del
software, el cual incluye la elaboracin de un Sistema de ndicadores de la Calidad del
Software, la confeccin de una Metodologa para el Aseguramiento de la Calidad del
Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la
aplicacin de las tcnicas y procedimientos del ACS, de forma tal que se conforme un
Sistema de Aseguramiento de la Calidad del Software.

CONCLUSIONES
Lograr el xito en la produccin de software es hacerlo con calidad y demostrar su
buena calidad. Esto slo es posible con la implantacin de un Sistema para el
Aseguramiento de la Calidad del Software directamente relacionado con la poltica
establecida para su elaboracin y que est en correspondencia con la definicin
internacional SO de calidad, amplia mente aceptada, y por los estndares del grupo
SO 9000.

26
UNIDAD IV

EL PROCESO DE SOFTWARE Y MTRICAS DE PROYECTOS

Introduccin

La medicin es fundamental para cualquier disciplina de ingeniera, y la ingeniera
del software no es una excepcin. La medicin nos permite tener una visin mns
profunda proporcionando un mecanismo para la evaluacin objetiva. Lord Kelvin
en una ocasin dijo:

"Cuando pueda medir lo que est diciendo y expresarlo con nmeros , ya conoce
algo sobre ello; cuando no pueda medir, cuando no pueda expresar lo que dice
con nmeros, su conocimiento es precario y deficiente: puede ser el comienzo del
conocimiento, pero en sus pensamientos, apenas est avanzando hacia el
escenario de la ciencia.

La comunidad de la ingeniera de software ha comenzado finalmente a tomarse en
serio las palabras de Lord Kelvin. Pero no sin frustraciones y s con gran
controversia.

Las mtricas del software se refieren a una amplio elenco de mediciones para el
desarrollo de software de computadora. La medicin se puede aplicar al proceso
del software con el intento de mejorarlo sobre una base continua. Se puede utilizar
el producto del software para ayudar en la estimacin, el control de calidad, la
evaluacin de productividad y el control de proyectos. Finalmente, el ingeniero de
software puede utilizar la medicin para ayudar a evaluar la calidad de los
resultados de trabajos tcnicos y para ayudar a la toma de decisiones tctica a
medida que el proyecto evoluciona.

QU ES EL PROCESO DE SOFTWARE Y MTRICAS DE PROYECTOS?

El proceso de software y las mtricas del producto son una medida cuantitativa
que permite a la gente del software tener una visin profunda de la eficacia del
proceso del software y de los proyectos que dirigen utilizando el proceso como un
marco de trabajo. Se renen los datos bsicos de calidad y productividad. Estos
datos son entonces analizados, comparados con promedios anteriores, y
evaluados para determinar las mejoras en la calidad y productividad. Las mtricas
son tambin utilizadas para sealar reas con problemas de manera que se
puedan desarrollar los remedios y mejorar el proceso del software.

QUIN LO HACE?

Las mtricas del software son analizadas y evaluadas por los administradores del
software. A menudo las medidas son reunidas por los ingenieros de software.

POR QU ES IMPORTANTE?

Si no se mide, slo se podr juzgar basndonos en una evaluacin subjetiva.
Mediante la medicin, se pueden sealar las tendencias (buenas o malas), realizar
mejores estimaciones, llevar a cabo una verdadera mejora sobre el tiempo.

CULES SON LOS PASOS?

27
Comenzar definiendo un conjunto limitado de medidas de procesos, proyectos y
productos que sean fciles de recoger. Estas medidas a menudo normalizados
utilizando mtricas orientadas al tamao o a la funcin. El resultado se analiza y
se compara con promedios anteriores de proyectos similares realizados con la
organizacin. Se evalan las tendencias y se generan las conclusiones.

CUL ES EL PRODUCTO OBTENIDO?

Es un conjunto de mtricas del software que proporcionan una visin profunda del
proceso y de la compresnin del proyecto.

CMO PUEDO ESTAR SEGURO DE QUE LO HECHO CORRECTAMENTE?

Aplicando un plan de medicin sencillo pero consistente, que nunca utilizaremos
para evaluar, premiar o castigar el rendimiento individual.

Dentro del contexto de la gestin de proyectos de software, en primer lugar existe
una gran preocupacin por las mtricas de productividad y de calidad medidas
"de salida (finalizacin) del desarrollo del software, basadas en el esfuerzo y
tiempo empleados, y medidas de la "utilidad del producto obtenido -.

Park, Goethe y Florac [PAR96] tartan en su gua de la medicin del software las
razones por las que medimos:

- Caracterizar
- Evaluar
- Predecir
- Mejorar

Caracterizamos para comprender mejor los procesos, los productos, los recursos y
los entornos y para establecer las lneas base para las comparaciones con
evaluaciones futuras.

Evaluamos para determinar el estado con respecto al diseo. Las medidas
utilizadas son los censores que nos permiten conocer cuando nuestros proyectos y
procesos estn perdiendo la pista, de modo que podamos ponerlos bajo control.
Tambin evaluamos para valorar la consecucin de los objetivos de la calidad y
para evaluar el impacto de la tecnologa y las mejoras del proceso de los productos
y procesos.

Predecimos para poder planificar. Realizar mediciones para la prediccin implica
aumentar la comprensin de las relaciones entre procesos y los productos y la
construccin de modelos de estas relaciones, por lo que los valores que
observamos para algunos atributos pueden ser usados para predecir otros.
Hacemos esto porque queremos establecer objetivos alcanzables para el coste,
planificacin y calidad de modo que se puedan aplicar los recursos apropiados-.
Las medidas de prediccin tambin son la base para la extrapolacin de
tendencias, por lo que la estimacin para el coste, tiempo y calidad se puede
actualizar basndose en la evidencia actual. Las proyecciones y las estimaciones
basadas en datos histricos tambin nos ayudan a analizar riesgos y a realizar
intercambios diseo/coste.

Medimos para mejorar cuando recogemos la informacin cuantitativa que nos
ayuda a identificar obstculos, problemas de raz, ineficiencias y otras
oportunidades para mejorar la calidad del producto y el rendimiento del proceso.
28

PUNTOS A CONSIDERAR:

1. Medidas, Mtricas e ndicadores
2. Mtricas en el proceso y Dominio del Proyecto
3. Mediciones del Software
4. Reconciliacin de los diferentes enfoques de mtricas
5. Mtricas para la calidad del software
6. ntegracin de mtricas dentro del proceso del software

Para el estudio de cada punto se debe consultar el texto base proporcionado
(ngeniera del Software un Enfoque Prctico, Roger Pressman), las fotocopias
adicionales y las diapositivas.

29
UNIDAD V
MANTENIMIENTO Y DOCUMENTACION

1. Definicin

Modificacin de un producto de software, despus de su entrega para corregir errores,
mejorar el rendimiento u otros atributos o adaptar el producto a cambios del entorno.
EEE Std. 1219-1998.

Segn IEEE, 1990
Proceso de modificar un sistema o componente software despus de su entrega
para corregir defectos, mejorar el rendimiento u otros atributos o adaptarlo a un
entorno cambiante.
Fase que se inicia de finalizada las Pruebas
Fase ms costosa del ciclo, el mantenimiento consume ms del 60% del coste de
todo el ciclo de vida
Barrera de mantenimiento cuando sobrepasa lmite de recursos
Correccin de defectos en el software.
Creacin de nuevas funcionalidades en el software por nuevos requisitos de
usuario.
Mejora de la funcionalidad y del rendimiento.

Cuando el sistema ya esta en uso. Las actividades de mantenimiento resultan muy
visibles para el cliente. Pueden afectar negativamente a la imagen de la
organizacin.
Distribucin deI Costo deI CicIo de
Vida (Rock-Evans y HaIes, 1990)
Pruebas
ModuIares
8%
Cdigo
7%
Diseo
5%
AnIisis de
Requisitos
6%
Pruebas de
Integracin
7%
Mantenimient
o
67%
30
2. Tipos de Mantenimiento
a) Perfectivo: Se realiza para dar respuesta a nuevos requisitos del cliente, o para
mejorar el rendimiento del sistema.
Mejoras al rendimiento
Aumento de facilidad para mantener un programa ante cambios.
Nuevas funcionalidades (de ampliacin) y mejoras de eficiencia de
ejecucin (Gorla,1991).

b) Adaptativo: conjunto actividades para adaptar el sistema a los cambios (HW o
SW) en su entorno tecnolgico. Permite al software continuar en
funcionamiento, adaptndose a cambios producidos en su entorno de
operacin.
Los cambios tpicos se suelen centrar en el hardware con el que interacta,
en el sistema operativo, o en formatos de datos que recibe o enva.

El entorno de datos: cambio de soporte de los datos de una aplicacin
Archivos a sistema Relacional
El entorno de Proceso:
Nueva plataforma de explotacin
Nuevo Sistema Operativo
c) Correctivo: Tiene como finalidad corregir fallos o problemas. Dentro del
mantenimiento correctivo se suele diferenciar entre "de emergencia" o "de
agenda"; en funcin de la urgencia con la que deba aplicarse la solucin.
En algunas ocasiones el cliente necesita urgentemente la reparacin del fallo,
y en otras, puede seguir operando con el error presente, y esperar a la
prxima versin que normalmente incluye cambios acumulados en la agenda
de mantenimiento, tanto de tipo adaptativo, como correctivo y perfectivo.
Correccin de defectos en el HW o SW detectados por el usuario en la
explotacin .
Terminaciones anormales o salidas incorrectas.Procesamiento
Tiempos de respuestas altos..Rendimiento
Violacin de estndares de programacin o inconsistencias del
diseo.Implementacin
Pruebas y actualizacin de documentacin luego de las modificaciones
d) Preventivo: actividades para facilitar el mantenimiento futuro.
En su versin de 1993, el estndar EEE 1229 inclua tambin en su
clasificacin el mantenimiento preventivo como aquel que se realiza para
evitar la aparicin futura de errores, o para mejorar la integridad de producto
en prevencin de stos. Algunos textos lo consideran como un 4 tipo de
mantenimiento, y otros lo incluyen como mantenimiento correctivo.
Validacin de datos entrada
Mejoras en su legibilidad

31

3. Costos por Tipo Mantenimiento

Distribucin del tiempo en tareas de mantenimiento (MCclure,1992)

4. El Proceso de Mantenimiento
e) Vara considerablemente dependiendo del tipo de Software
f) Proceso informal o formal.
g) Actividades fundamentales:
Anlisis del cambio
Planeacin de la versin
mplementacin del sistema
Entrega

Costos por Tipo Mantenimiento (Frazer,
1992)
Perfectivo
60%
Correctivo
17%
Preventivo
5%
Adaptativo
18%
Estudiar
peticiones
18%
Estudiar
documentacin
6%
Estudiar cdigo
23%
ReaIizar pruebas
28%
ActuaIizar
documentacin
6%
ImpIementar
cambio
19%
Peticiones de
Cambio
Anlisis de
mpacto
Planeacin de
versiones
mplementacin
de cambios
Liberacin del
Sistema
Reparacin de
fallas
Adaptacin de
plataforma
Perfeccionamiento
del Sistema
32
5. Prediccin deI Mantenimiento

Predecir el numero de peticiones de cambios para un sistema requiere entender la
relacin entre el sistema y sus entorno
Evaluacin relacin sistema y su entorno
Nmero y complejidad de las interfaces del sistema.
Nmero de requerimientos inherentemente voltiles del sistema.
Los procesos de negocios en los que se utiliza el sistema.
Ejemplos de mtricas para evaluar la mantenibilidad:
Nmero de peticiones de mantenimiento correctivo.
Tiempo promedio requerido para el anlisis de impacto.
Tiempo promedio para implementar una peticin de cambio.
Nmero de peticiones de cambio pendientes.

6. DificuItades deI mantenimiento

El mantenimiento es una de las fases ms difciles del ciclo de vida, y generalmente no
est lo suficientemente reconocida.
Las principales razones de esta situacin son:
En las organizaciones de software no aparece asociada a nuevas
oportunidades de negocio, que es sin duda un aspecto mucho ms
atractivo para sus gestores.
Los trabajos de mantenimiento suelen tener asignados sus propios
presupuestos pre-establecidos, y se ven como un "negocio normal, por
lo que no suelen atraer la atencin de la actividad del negocio.
El personal tcnico suele preferir trabajar en proyectos nuevos y no en
mantener sistemas ya desarrollados.

En muchos sentidos, el mantenimiento resulta ms difcil tanto desde el punto de vista
tcnico como de gestin del proyecto. Algunos de los factores que hacen del
mantenimiento un proceso difcil son:
Posibilidad de introduccin de errores en cascada o distorsionar
funcionalidades ya implementadas al insertar nuevas modificaciones.
El equipo de mantenimiento debe tener un conocimiento global del
producto.
33
Las pruebas suelen resultar especialmente complicadas porque
generalmente las limitaciones de tiempo no hacen posible ejecutar
pruebas completas de regresin.
Desde el punto de vista de gestin, las tres categoras de
mantenimiento (correctivo, perfectivo y adaptativo) suelen realizarse de
manera simultnea, con gestin de prioridades de cada peticin de
cambio, y respetando la gestin de la configuracin del sistema.

DificuItad por degradacin deI sistema

Cuanto mejor diseado, codificado y documentado est un sistema, ms fcil
resulta su mantenimiento.

Las propias tareas de mantenimiento tienden a degradar el diseo, la limpieza
del cdigo y su documentacin, generando de esta forma una espiral que se
retroalimenta y que con el tiempo incrementa la dificultad de mantenimiento de
un sistema.
Los factores que favorecen esta situacin, y que por tanto es necesario
gestionar adecuadamente son:
Los mitos ya apuntados de no otorgar al mantenimiento la
importancia y rigor necesarios.
Las presiones de tiempo y recursos con las que suelen
ejecutarse.
La consideracin por parte del personal tcnico de tareas de
"segunda divisin

Gestin de Mantenimiento

Las tareas de mantenimiento deben ejecutarse dentro de un marco de gestin,
de igual forma que si se trata el desarrollo de un sistema nuevo.
Tambin es frecuente que en este aspecto tambin el mantenimiento suele ser
tratado como "la cenicienta en los proyectos de software, y generalmente
resulta ms difcil la gestin de un proyecto de mantenimiento que la de un
desarrollo nuevo. De hecho puede ocurrir que dentro del mantenimiento de un
sistema se incluya tambin el desarrollo de un nuevo sub-sistema paraa
ampliar su funcionalidad.

Por tanto todas las tareas e indicaciones propias de la gestin de proyectos de
software son aplicables a los proyectos de mantenimiento: estimacin del
esfuerzo necesario, identificacin de procesos necesarios, planificacin de
costes y agendas, gestin de riesgos, etc.

7. Las 7 fases deI mantenimiento

Para identificar y comprender las actividades que deben tenerse en cuenta en el
mantenimiento, los pasos que deben seguirse y las herramientas y mtodos que
deben emplearse, resulta muy til considerar que los procesos de cambio o
modificaciones de un sistema de software comprenden 7 fases:

dentificacin clasificacin y priorizacin del problema o de la
modificacin.
Anlisis.
Diseo.
mplementacin.
Pruebas de sistema y de regresin.
34
Pruebas de aceptacin.
Entrega.

Al realizar tareas de mantenimiento, en cada una de estas fases deben considerarse
los siguientes elementos:

1.- Identificacin deI probIema, cIasificacin y priorizacin
Cada peticin de cambio debe identificarse, clasificarse y asignarle una prioridad,
teniendo en cuenta qu tipo de mantenimiento implica (correctivo, adaptativo,
perfectivo y si es de emergencia)

2. AnaIisis
La fase de anlisis emplea la relacin de peticiones de cambio registradas y validadas
para analizar su viabilidad, alcance de las modificaciones y preparar un plan preliminar
de diseo implementacin y entrega

EN CADA FASE
Entradas Procesos Control Salidas Mtricas
Peticin de cambio Asignar n de
identificacin
Clasificar por tipo
de mantenimiento
Analizar y deter-
minar se se acepta
rechaza o pospone
Primera estimacin
de su magnitud
Priorizar la
modificacin
Asignar la peticin
a qu bloque de
modificaciones
prevista va a ir
Una vez identificada
la peticin de
cambio, debe
quedar registrada
en un registro de
peticiones de
cambio
Peticin de cambio
validada que queda
en un registro con la
siguiente
informacin:
Definicin del
problema o del
nuevo requisito
Evaluacin
Tipo de mantenim.
Prioridad inicial
Estimacin inicial
de recursos
necesarios
N de omisiones
en la P.C.
N de P.C.
enviadas
N de peticiones
de cambio
duplicadas
Tiempo invertido
en la validacin.
Factores medidos:
correccin y
mantenibilidad
Peticin de cambio
validada
Estimacin inicial
de recursos y
dems informacin
registrada.
Documentacin del
proyecto (si la
hay).
Anlisis de
viabilidad
(impacto,
soluciones
alternativas,
implicaciones de
seguridad, coste y
beneficio de la
modificacin.)
Anlisis detallado
(SRS de la
modificacin,
elementos a
modificar,
estrategia de
pruebas.)
Realizar revisiones
tcnicas y revisar
Estrategia de
pruebas.
Que la documen-
tacin est completa
y actualizada e
incluye parmetros
de seguridad
Informe de
viabilidad de las
P.C.
Informe del anli-
sis detallado.
Requisitos
actualizados (y
trazables)
Lista preliminar
de mofificaciones.
Plan de pruebas
Plan de
implementacin
Modificaciones de
requisitos
% de errores en
la documentacin
Esfuerzo por rea
(SQA, SE, etc.)
Tiempo empleado
% de errores
generados por
prioridad y tipo.
Factores: flexibilidad
trazabilidad
usabilidad
mantenibilidad
reusabilidad
35

3. Diseo
En esta fase se emplea toda la documentacin del sistema, del proyecto y la generada
en la fase anterior (anlisis) para disear la modificacin del sistema.

4. ImpIementacin
A partir del diseo realizado y verificado, el cdigo y la documentacin del sistema y
del proyecto se lleva a cabo el trabajo de implementacin.

Salidas de la fase
de anlisis.
Documentacin del
sistema y del
proyecto
Cdigo,
comentarios y
bases de datos del
sistema.
Identificacin de
los mdulos
afectados.
Documentacin de
las modificaciones
Creacin de casos
de prueba para las
modificaciones
Identificacin y
creacin de
pruebas de
regresin
Actualizacin de
documentacin
(SRS manuales.)
Inspeccin /
verificacin del
diseo
Inspeccin /
verificacin de la
documentacin
asociada
Revisados:
Lista de
modificacines
Anlisis detallado
Plan de
implementacin
actualizado
Lnea base de
diseo
Planes de
pruebas
Complejidad del
software
Cambios diseo
Esfuerzo por rea
Cambios en
planes de prueba
Nmero de
mdulos
N lneas de
cdigo aadidas o
modificadas
Resultados de la
fase de diseo.
Cdigo fuente y
bases de datos del
sistema.
Documentacin del
sistema y del
proyecto.
Codificacin y
pruebas unitarias
Integracin
Anlisis de riesgos
Revisin de
pruebas
Revisiones de
cdigo
Verificacin de la
integracin.
Verificacin de
modificaciones y
actualizaciones
de
documentacin.
Gestin de
riesgos y
supervisin
durante las
pruebas
Revisados:
Software
actualizado.
Documentacin
de diseo,
pruebas,
manuales
documentacin
de formacin
actualizados.
Definicin de
riesgos e
impactos.
Informe de
revisin de las
pruebas
Volumen (puntos
de funcin /
lneas de cdigo)
Porcentaje de
errores
generados.
36
5. Pruebas de sistema y regresion
Tras la implementacin deben realizarse las pruebas del sistema modificado. Las
pruebas de regresin son parte de las pruebas del sistema que comprueban que el
cdigo modificado no ha introducido errores nuevos.

6. Pruebas de aceptacin
Sobre el sistema completamente integrado, el cliente, los usuarios o un tercero
nombrado por el cliente lleva a cabo las pruebas de aceptacin

Informe de las
pruebas.
Documentacin de
los planes de
prueba, casos de
prueba,
procedimientos de
prueba, manuales
de usuario, diseo.
Sistema
actualizado
Prueba funcional
del sistema.
Pruebas de
interfaz.
Pruebas de
regresin.
Las pruebas del
sistema se han
realizado segn
los planes SQA.
Control de la
gestin de la
configuracin de:
cdigo, peticiones
de cambio,
documentacin
de pruebas
Revisados:
Sistema revisado.
Informes de
pruebas.
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
Informes de
pruebas.
Sistema
completamente
integrado.
Planes de pruebas
de aceptacin.
Casos de prueba
de aceptacin.
Procedimientos de
aceptacin
Ejecucin de las
pruebas de
aceptacin a nivel
funcional.
Ejecucin de
pruebas de
interoperabilidad.
Ejecucin de
pruebas de
regresin.
Ejecucin de
planes de
aceptacin.
Auditora
funcional.
Puesta bajo
control de
configuracin de
la nueva
documentcin.
Establecimiento
de la nueva lnea
base del sistema.
Informe de los
resultados de
auditora
funcional.
Nueva lnea base
del sistema.
Informe de
auditora
funcional.
Informe de
pruebas de
aceptacin.
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
37

7. Entrega
Entrega del sistema modificado.

8. Mito de Ios DesarroIIadores
a) Mito: Una vez que se escribe un programa y se hace funcionar el mismo, el
trabajo de programacin ha terminado.
b) Realidad: Alguien dijo una vez "cuanto ms pronto se comience a escribir
cdigo, ms se tardara en terminarlo". Los datos indican que entre el
cincuenta y sesenta por ciento de todo el esfuerzo dedicado a un programa
se realizar despus de la primera entrega del software al cliente.
c) Mito: Hasta que no se cuente con un programa ejecutable, realmente no se
puede comprobar su calidad.
d) Realidad: Desde el inicio de un proyecto de software debe aplicarse uno de
los mecanismos ms efectivos para garantizar la calidad del software: la
revisin tcnica formal. La revisin del software es un filtro de calidad que
es mucho ms efectivo que la prueba, para encontrar ciertas clases de
defectos en el software.

e) Mito: Lo nico que se entrega al terminar el proyecto es el programa
funcionando.
f) Realidad: Un programa que funciona es slo una parte de una
configuracin de software que incluye programas, documentos y datos. La
documentacin es la base de un buen desarrollo y, lo que es ms
importante, proporciona guas para la tarea de mantenimiento de software
El sistema
modificado segn
se represente en la
nueva lnea base.
Auditora fsica de
la configuracin.
Notificacin a la
comunidad de
usuarios.
Desarrollo y
archivo de una
copia de seguridad
del nuevo sistema.
Instalacin y
formacin de
usuarios.
Ejecucin de la
auditora fsica de
la configuracin.
Documento de
descripcin de la
versin.
Informe de la
auditora fsica.
Documento de
descripcin de la
versin.
Cambios en la
documentacin
(manuales de
usuario, de
operacin,
documento
descripcin de
versin, etc.)
38
UNIDAD VI

INGENIERA DE SOFTWARE DEL COMERCIO ELECTRNICO

Que es
La arquitectura cliente servidor dominan el horizonte de los sistemas basados en
computadora. Todo existe desde redes de cajeros automticos hasta nternet, y esto
es debido a que el software que reside en una computadora el cliente solicita al
servicios Y7o datos de otra computadora .

La ingeniera de software cliente /servidor combina principios convencionales,
conceptos y mtodos tratados anteriormente en esta gua, con elementos de la
ingeniera de software basada en componentes y orientada a objetos para crear el
sistema.

Quien Io Hace?
Los ingenieros de software llevan a cabo el anlisis, diseo, implementacin y prueba
de estos temas.

Por que es importante?
El impacto de los sistemas cliente servidor en los negocios, el comercio electrnico, el
gobierno y la ciencia es dominante. Puesto que los avances tecnolgicos (por
ejemplo, desarrollo basado en componentes, agentes de solicitud de objetos, JAVA)
cambian la forma de construir el sistemas cliente servidor, en su construccin se
debe aplicar un proceso de ingeniera de software solid.

Cuales son los pasos. Los pasos que se siguen en la ingeniera de los sistemas cliente
servidor son similares alas que se aplican durante la ingeniera del software basada
en componentes y orientados a objetos. El modelo de proceso es evolutivo,
comenzando por la obtencin de los requisitos.

La funcionalidad se asigna a los subsistemas de componentes que se van a asignar
despus o bien al cliente o al servidor de la arquitectura cliente servidor. El diseo se
centra en la integracin de los componentes nuevos. La implementacin y las pruebas
luchan por ejercitar la funcionalidad del cliente y del servidor dentro del contexto de
los estndares de integracin de componentes y de la arquitectura cliente servidor.

CuaI es eI producto obtenido
Un sistema cliente servidor de alta calidad es el producto de la ingeniera de software
cliente servidor.
Tambin se produce otros productos de trabajo de software

1. Introduccin

El crecimiento de la tecnologa en los ltimos aos, ha generado avances y cambios
en todos los aspectos. La evolucin de nternet ha sido uno de estos grandes cambios.
nternet ha influido en nuestras vidas y en nuestras costumbres, en nuestra forma de
buscar informacin, de entretenernos, de comunicarnos y por supuesto han aparecido
nuevas formas de comprar y vender bienes.

Estos cambios traen grandes beneficios, por ejemplo hoy en da las personas se
comunican desde dos puntos muy distantes del planeta, ya sea a travs del telfono o
de algunos de los medios que ofrece nternet; as mismo, las empresas han
encontrado grandes oportunidades en los desarrollos de las comunicaciones,
39
destacando que los costos de las comunicaciones se reducen y que estas tecnologas
estn al alcance tanto de grandes empresas como de pequeas empresas.

El desarrollo de estas tecnologas y de las telecomunicaciones ha hecho que los
intercambios de datos crezcan a niveles extraordinarios, simplificndose cada vez mas
y creando nuevas formas de comercio, y en este marco se desarrolla el Comercio
Electrnico.

Se considera "Comercio Electrnico" al conjunto de aquellas transacciones
comerciales y financieras realizadas a travs del procesamiento y la transmisin de
informacin, incluyendo texto, sonido e imagen.

Existen diversas ventajas y desventajas que vienen con la alta tecnologa del comercio
electrnico, pero todo estoy lo hablaremos ms adelante en nuestro trabajo, as como
tambin tocaremos interesantes puntos que van ligado al tema en cuestin.

2. Sistemas Distribuidos
Esta arquitectura consiste bsicamente en que un programa el Cliente informtico
realiza peticiones a otro programa, el servidor, que les da respuesta.

Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola
computadora es ms ventajosa en un sistema operativo multiusuario distribuido a
travs de una red de computadoras.

En esta arquitectura la capacidad de proceso est repartida entre los clientes y los
servidores, aunque son ms importantes las ventajas de tipo organizativo debidas a la
centralizacin de la gestin de la informacin y la separacin de responsabilidades, lo
que facilita y clarifica el diseo del sistema.

La separacin entre cliente y servidor es una separacin de tipo lgico, donde el
servidor no se ejecuta necesariamente sobre una sola mquina ni es necesariamente
un slo programa.

Una disposicin muy comn son los sistemas multicapa en los que el servidor se
descompone en diferentes programas que pueden ser ejecutados por diferentes
computadoras aumentando as el grado de distribucin del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monoltica en la que no hay
distribucin, tanto a nivel fsico como a nivel lgico.

3. Ventajas de Ia arquitectura cIiente-servidor

CentraIizacin deI controI: los accesos, recursos y la integridad de los datos
son controlados por el servidor de forma que un programa cliente defectuoso
o no autorizado no pueda daar el sistema.
EscaIabiIidad: se puede aumentar la capacidad de clientes y servidores por
separado.
El servidor de cliente es la arquitectura de red que separa al cliente (a
menudo un uso que utiliza un interfaz utilizador grfico) de un servidor. Cada
caso del software del cliente puede enviar peticiones a un servidor. Los tipos
especficos de servidores incluyen los servidores web, los servidores del uso,
los servidores de archivo, los servidores terminales, y los servidores del
correo. Mientras que sus propsitos varan algo, la arquitectura bsica sigue
siendo igual.

40

4. Caractersticas de un servidor:
Voz pasiva (esclavo)
Espera para las peticiones
Sobre el recibo de peticiones, las procesa y entonces los servicios son
contestados
5.Caractersticas de un cIiente:
Enva peticiones
Las esperas para y reciben contestaciones del servidor

Otro tipo de arquitectura de red se conoce como arquitectura del par-a-par porque
cada nodo o caso del programa es un "cliente y un "servidor y cada uno tiene
responsabilidades equivalentes. Ambas arquitecturas estn en uso amplio.

Arquitectura con capas Una arquitectura genrica del cliente/servidor tiene dos tipos
de nodos en la red: clientes y servidores. Consecuentemente, estas arquitecturas
genricas se refieren a veces como arquitecturas "de dos niveles.

Algunas redes consistirn en tres diversas clases de nodos: cliente, servidores del uso
que datos de proceso para los clientes, y servidores de la base de datos que
almacenan los datos para los servidores del uso. Esta configuracin se llama una
arquitectura de la tres-capas.

La ventaja de una arquitectura de Ia n-capas comparado con una arquitectura de
dos niveles (o una tres-capas con un de dos niveles) es que separa hacia fuera el
proceso, eso ocurre para mejorar el balance la carga en los diversos servidores; es
ms escalable. Las desventajas de las arquitecturas de la n-capas son: 1)Pone ms
carga en la red 2)Es mucho ms difcil programar y probar software que en
arquitectura de dos niveles porque ms dispositivos tienen que comunicarse para
terminar la transaccin de un usuario

Ventajas
Todos los datos se almacenan en los servidores, as que tienen capacidad mejor del
control de la seguridad. El servidor puede controlar el acceso y el recurso al
cerciorarse que dej solamente sos accesos de usuarios permitidos y cambia datos.
Es ms flexible que el paradigma del P2P para poner al da los datos u otros recursos.
Hay las tecnologas maduradas diseadas para el paradigma de C/S que asegura
seguridad, el usuario-friendliness del interfaz, y la facilidad de empleo.

Desventajas
La congestin del trfico ha sido siempre un problema desde el primer da del
nacimiento del paradigma de C/S. Cuando una gran cantidad de clientes envan
peticiones al mismo servidor al mismo tiempo, puede ser que cause muchos de los
apuros para el servidor. Ms clientes hay ms apuros que tiene. Mientras que, el
ancho de banda de la red del P2P se compone de cada nodo en la red, cuanto ms
nodos hay, mejor el ancho de banda que tiene. El paradigma de C/S no tiene la
buena robustez como red del P2P. Cuando el servidor est cado, las peticiones de los
clientes no pueden ser satisfechas. En la mayor parte de redes del P2P, los recursos
estn situados generalmente en nodos por todas partes de la red. Aunque algn nodos
salen o abandonan la descarga; otros nodos pueden todava acabar de descargar
consiguiendo datos del resto de los nodos en la red. El software y el hardware de un
servidor es generalmente muy terminantes. Un hardware regular del ordenador
41
personal puede no poder servir sobre cierta cantidad de clientes. Mientras tanto, una
edicin casera de Windows XP incluso no tiene S a trabajar como servidor. Necesita
software y el hardware especfico satisfacer el trabajo. Por supuesto, aumentar el
coste.

Direccin Los mtodos de direccin en ambientes del servidor de cliente se pueden
describir como sigue:
Direccin del proceso de la mquina; donde la direccin se divide como sigue
proceso@mquina. Por lo tanto 56@453 indicara el proceso 56 en la computadora
453
Servidor de nombres; Los servidores de nombres tienen un ndice de todos los
nombres y direcciones de servidores en el dominio relevante.
LocaIizacin de Paquetes; Los mensajes de difusin se envan a todas las
computadoras en el sistema distribuido para determinar la direccin de la computadora
de la destinacin
Comerciante; Un comerciante es un sistema que pone en un ndice todos los servicios
disponibles en un sistema distribuido. Una computadora que requiere un servicio
particular comprobar con el servicio que negocia para saber si hay la direccin de
una computadora que proporciona tal servicio.

6. Tipos de servidores

a) PIataformas de Servidor (Server PIatforms): Un trmino usado a menudo
como sinnimo de sistema operativo, la plataforma es el hardware o software
subyacentes para un sistema, es decir, el motor que dirige el servidor.

b) Servidores de ApIicaciones (AppIication Servers): Designados a veces
como un tipo de middleware (software que conecta dos aplicaciones), los
servidores de aplicaciones ocupan una gran parte del territorio entre los
servidores de bases de datos y el usuario, y a menudo los conectan.

c) Servidores de Audio/Video (Audio/Video Servers): Los servidores de
Audio/Video aaden capacidades multimedia a los sitios web permitindoles
mostrar contenido multimedia en forma de flujo continuo (streaming) desde el
servidor.

d) Servidores de Chat (Chat Servers): Los servidores de chat permiten
intercambiar informacin a una gran cantidad de usuarios ofreciendo la
posibilidad de llevar a cabo discusiones en tiempo real.

e) Servidores de Fax (Fax Servers): Un servidor de fax es una solucin ideal
para organizaciones que tratan de reducir el uso del telfono pero necesitan
enviar documentos por fax.

f) Servidores FTP (FTP Servers): Uno de los servicios ms antiguos de nternet,
File Transfer Protocol permite mover uno o ms archivos.

g) Servidores Groupware (Groupware Servers): Un servidor groupware es un
software diseado para permitir colaborar a los usuarios, sin importar la
localizacin, va nternet o va ntranet corporativo y trabajar juntos en una
atmsfera virtual.

h) Servidores IRC (IRC Servers): Otra opcin para usuarios que buscan la
discusin en tiempo real, nternet Relay Chat consiste en varias redes de
42
servidores separadas que permiten que los usuarios conecten el uno al otro va
una red RC.

i) Servidores de Listas (List Servers): Los servidores de listas ofrecen una
manera mejor de manejar listas de correo electrnico, bien sean discusiones
interactivas abiertas al pblico o listas unidireccionales de anuncios, boletines
de noticias o publicidad.

j) Servidores de Correo (MaiI Servers): Casi tan ubicuos y cruciales como los
servidores web, los servidores de correo mueven y almacenan el correo
electrnico a travs de las redes corporativas (va LANs y WANs) y a travs de
nternet.

k) Servidores de Noticias (News Servers): Los servidores de noticias actan
como fuente de distribucin y entrega para los millares de grupos de noticias
pblicos actualmente accesibles a travs de la red de noticias USENET.

l) Servidores Proxy (Proxy Servers): Los servidores proxy se sitan entre un
programa del cliente (tpicamente un navegador) y un servidor externo
(tpicamente otro servidor web) para filtrar peticiones, mejorar el
funcionamiento y compartir conexiones.

m) Servidores TeInet (TeInet Servers): Un servidor telnet permite a los usuarios
entrar en un ordenador husped y realizar tareas como si estuviera trabajando
directamente en ese ordenador.
n) Servidores de Base de Datos: Son computadoras que almacenan grandes
cantidades de datos estructurados.

7. Que es eI comercio eIectrnico?

El comercio, es la actividad ancestral del ser humano, ha evolucionado de muchas
maneras, pero su significado y su fin siempre es el mismo.

El Comercio es "el proceso y los mecanismos utilizados, necesarios para colocar las
mercancas, que son elaboradas en las unidades de produccin, en los centros de
consumo en donde se aprovisionan los consumidores, ltimo eslabn de la cadena de
comercializacin. Es comunicacin y trato".

El comercio electrnico se entiende como cualquier forma de transaccin comercial en
la cual las partes involucradas interactan de manera electrnica y no de la manera
tradicional por medio de intercambios fsicos o trato fsico directo.

Actualmente la manera de comerciar se caracteriza por el mejoramiento constante en
los procesos de abastecimiento, y como respuesta a ello los negocios a nivel mundial
estn cambiando tanto su organizacin como sus operaciones. El comercio electrnico
es el medio de llevar a cabo dichos cambios dentro de una escala global, permitiendo
a las compaas ser ms eficientes y flexibles en sus operaciones internas, para as
trabajar de una manera ms cercana con sus proveedores y estar ms pendiente de
las necesidades y expectativas de sus clientes. Adems permiten seleccionar a los
mejores proveedores sin importar su localizacin geogrfica para que de esa forma se
pueda vender a un mercado global

Jaime Neilson nos dice que: "El comercio electrnico es cualquier actividad de
intercambio comercial en la que las rdenes de compra - venta y pagos se realizan a
43
travs de un medio telemtico, los cuales incluyen servicios financieros y bancarios
suministrados por nternet. El comercio electrnico es la venta a distancia
aprovechando las grandes ventajas que proporcionan las nuevas tecnologas de la
informacin, como la ampliacin de la oferta, la interactividad y la inmediatez de la
compra, con la particularidad que se puede comprar y vender a quin se quiera, y,
dnde y cundo se quiera. Es toda forma de transaccin comercial o intercambio de
informacin, mediante el uso de Nueva Tecnologa de Comunicacin entre empresas,
consumidores y administracin pblica."
8. Tipos de Transacciones de Comercio EIectronico

"Business to business" (entre empresas): las empresas pueden intervenir
como compradoras o vendedoras, o como proveedoras de herramientas o
servicios de soporte para el comercio electrnico, instituciones financieras,
proveedores de servicios de nternet, etc.
"Business to consumers" (Entre empresa y consumidor): as empresas venden
sus productos y prestan sus servicios a travs de un sitio Web a clientes que
los utilizarn para uso particular.
"Consumers to consumers" (Entre consumidor y consumidor): es factible que
los consumidores realicen operaciones entre s, tal es el caso de los remates
en lnea.
"Consumers to administrations" (Entre consumidor y administracin): los
ciudadanos pueden interactuar con las Administraciones Tributarias a efectos
de realizar la presentacin de las declaraciones juradas y/o el pago de los
tributos, obtener asistencia informativa y otros servicios.
"Business to administrations" (Entre empresa y administracin): las
administraciones pblicas actan como agentes reguladores y promotores del
comercio electrnico y como usuarias del mismo.
9. Ventajas deI Comercio EIectrnico

Para Ias Empresas

Reduccin de costo real al hacer estudio de mercado.
Desaparecen los lmites geogrficos y de tiempo.
Disponibilidad las 24 horas del da, 7 das a la semana, todo el ao.
Reduccin de un 50% en costos de la puesta en marcha del comercio
electrnico, en comparacin con el comercio tradicional.
Hacer ms sencilla la labor de los negocios con sus clientes.
Reduccin considerable de inventarios.
Agilizar las operaciones del negocio.
Proporcionar nuevos medios para encontrar y servir a clientes.
ncorporar internacionalmente estrategias nuevas de relaciones entre clientes
y proveedores.
Reducir el tamao del personal de la fuerza.
Menos inversin en los presupuestos publicitarios.
Reduccin de precios por el bajo coste del uso de nternet en comparacin
con otros medios de promocin, lo cual implica mayor competitividad.
Cercana a los clientes y mayor interactividad y personalizacin de la oferta.
Desarrollo de ventas electrnicas.
Globalizacin y acceso a mercados potenciales de millones de clientes.
mplantar tcticas en la venta de productos para crear fidelidad en los clientes.
Para los clientes

44
Abarata costos y precios
Da poder al consumidor de elegir en un mercado global acorde a sus
necesidades
Un medio que da poder al consumidor de elegir en un mercado global acorde
a sus necesidades.
Brinda informacin pre-venta y posible prueba del producto antes de la
compra.
nmediatez al realizar los pedidos.
Servicio pre y post-venta on-line.
Reduccin de la cadena de distribucin, lo que le permite adquirir un producto
a un mejor precio.
Mayor interactividad y personalizacin de la demanda.
nformacin inmediata sobre cualquier producto, y disponibilidad de acceder a
la informacin en el momento que as lo requiera.
Permite el acceso a ms informacin.
10. Desventajas deI Comercio EIectrnico

Desconocimiento de la empresa. No conocer la empresa que vende es un
riesgo del comercio electrnico, ya que sta puede estar en otro pas o en el
mismo, pero en muchos casos las "empresas" o "personas-empresa" que
ofrecen sus productos o servicios por nternet ni siquiera estn constituidas
legalmente en su pas y no se trata mas que de gente que esta "probando
suerte en nternet".

Forma de Pago. Aunque ha avanzado mucho el comercio electrnico, todava
no hay una transmisin de datos segura el 100%. Y esto es un problema pues
nadie quiere dar sus datos de la Tarjeta de Crdito por nternet. De todos
modos se ha de decir que ha mejorado mucho.

ntangibilidad. Mirar, tocar, hurgar. Aunque esto no sea sinnimo de compra,
siempre ayuda a realizar una compra.

El idioma. A veces las pginas web que visitamos estn en otro idioma
distinto al nuestro; a veces, los avances tecnolgicos permiten traducir una
pgina a nuestra lengua materna. Con lo cual podramos decir que ste es un
factor "casi resuelto". (Hay que aadir que las traducciones que se obtienen
no son excelentes ni mucho menos, pero por lo menos nos ayudan a entender
de que nos estn hablando o que nos pretenden vender).

Conocer quien vende. Ya sea una persona o conocer de que empresa se
trata. En definitiva saber quien es, como es, etc. Simplemente es una forma
inconsciente de tener mas confianza hacia esa empresa o persona y los
productos que vende.

Poder volver (post y pre-venta). Con todo ello podemos reclamar en caso de
ser necesario o pedir un servicio "post-venta". Al conocerlo sabemos donde
poder ir. El cliente espera recibir una atencin "pre-venta" o "post-venta".

Privacidad y seguridad. La mayora de los usuarios no confa en el Web como
canal de pago. En la actualidad, las compras se realizan utilizando el nmero
de la tarjeta de crdito, pero an no es seguro introducirlo en nternet sin
conocimiento alguno. Cualquiera que transfiera datos de una tarjeta de crdito
mediante nternet, no puede estar seguro de la identidad del vendedor.
Anlogamente, ste no lo est sobre la del comprador. Quien paga no puede
45
asegurarse de que su nmero de tarjeta de crdito no sea recogido y sea
utilizado para algn propsito malicioso; por otra parte, el vendedor no puede
asegurar que el dueo de la tarjeta de crdito rechace la adquisicin. Resulta
irnico que ya existan y funcionen correctamente los sistemas de pago
electrnico para las grandes operaciones comerciales, mientras que los
problemas se centren en las operaciones pequeas, que son mucho ms
frecuentes.

11. ConcIusin
Aun cuando los sistemas cliente/servidor puedan adoptar uno o mas de los modelos
de procesos de software y muchos de los mtodos de anlisis y diseo de sistemas
las caractersticas de las arquitecturas especiales de cliente servidor requieren una
personalizacin de software. En general el modelo de proceso de software que se
aplica a los sistemas cliente servidor tiene una naturaleza evolutiva, y los mtodos
tcnicos suelen tender enfoques orientados a objetos.

El desarrollador debe describir aquellos objetos que se produzcan en la
implementacin de los componentes de interaccin con el usuario, de base de datos
y de aplicacin. Los objetos definidos para es estos componentes deberan asignarse
bien a la maquina, o bien a la maquina servidor, y se pueden vincular a travs de un
distribuidor de solicitudes de objetos.

46
UNIDAD VII

INGENIERA WEB

Las aplicaciones desarrolladas para la Web tienen caractersticas especiales que
hacen que los mecanismos de ingeniera empleados sean diferentes. En este trabajo
describimos qu es la Ingeniera Web, qu marca la diferencia y por qu es necesaria.

1. Introduccin
Pocos pueden discutir que nternet y la World-Wide Web estn cambiando nuestras
vidas. Cada da es ms comn que tareas tales como la lectura del peridico, la
compra de libros o discos, operaciones bancarias, reserva de hoteles, compra de
billetes de avin o tren, entre otras muchas, las
realicemos conectados con nuestro ordenador a nternet. Es as que, durante la ltima
dcada hemos asistido al crecimiento vertiginoso del desarrollo y uso de aplicaciones
y sistemas Web cada vez ms complejos y sofisticados.

Desafortunadamente, dicha complejidad no parece estar acompaada de los
mecanismos adecuados que garanticen la calidad de unos sistemas de los que cada
da tenemos mayor dependencia a nivel social, funcional y econmico.

Esta carencia de calidad ha venido generando una preocupacin creciente entre la
comunidad cientfica y tcnica involucrada en el desarrollo Web. As pues, en los
ltimos aos surgen varias iniciativas con el objetivo de poner cierto orden dentro de la
maraa que estamos creando y en la que nos movemos habitualmente.
En 1998, Roger Presuman [PRE98] moder una mesa redonda virtual con
representantes la ingeniera software tradicional y del desarrollo software basado
exclusivamente en nternet. El debate principalmente se centr en discutir si vala la
pena aplicar un proceso de ingeniera a las aplicaciones con base en internet, o qu
caractersticas tenan stas que justificaran el no utilizarlo. La conclusin general fue
que aplicar un proceso de ingeniera nunca es una mala idea pero que ste debera
adaptarse a los requerimientos de cambio continuo y rapidez siempre presentes en el
proceso de desarrollo Web. De iniciativas como sta y de otras como la organizacin
de congresos y talleres especializados en el desarrollo para la Web, surge el
nacimiento de una nueva disciplina denominada ngeniera Web

Se pretende dar una visin general de qu es la ngeniera Web, qu marca la
diferencia
y por qu es necesaria.

2. Qu es Ia Ingeniera Web?

Murugesan et al. promotores iniciales del establecimiento de la ngeniera Web como
nueva disciplina, dan la siguiente definicin: "Web Engineering is the establishment
and use of sound
scientific, engineering and management principles and disciplined and systematic
approaches to the successful development, deployment and maintenance of high
quality Web-based systems and applications.

Y que escuetamente podemos "traducir como el proceso utilizado para crear,
implantar y mantener
aplicaciones y sistemas Web de alta calidad. Esta breve definicin nos lleva a abordar
un aspecto clave de cualquier proyecto como es determinar que tipo de proceso es
ms adecuado en funcin de
47
las caractersticas del mismo.

2.1 EI Proceso de Ingeniera Web

Caractersticas como inmediatez y evolucin y crecimiento continuos, nos llevan a un
proceso incremental y evolutivo, que permite que el usuario se involucre activamente,
facilitando el desarrollo de productos que se ajustan mucho lo que ste busca y
necesita.
Segn Pressman [PRE00], las actividades que formaran parte del marco de trabajo
incluiran las tareas abajo enumeradas. Dichas tareas seran aplicables a cualquier
aplicacin Web, independientemente del tamao y complejidad de la misma.
Las actividades que forman parte del proceso son: formulacin, planificacin anlisis,
modelizacin, generacin de pginas, test y evaluacin del cliente. La Formulacin
identifica objetivos y establece el alcance de la primera entrega. La Planificacin
genera la estimacin del coste general del proyecto, la evaluacin de riesgos y el
calendario del desarrollo y fechas de entrega. El Anlisis especifica los requerimientos
e identifica el contenido.
La Modelizacin se compone de dos secuencias paralelas de tareas. Una consiste en
el diseo y produccin del contenido que forma parte de la aplicacin. La otra, en el
diseo de la arquitectura, navegacin e interfaz de usuario. Es importante destacar la
importancia del diseo de la interfaz.

ndependientemente del valor del contenido y servicios prestados, una buena interfaz
mejora la percepcin que el usuario tiene de stos. En la Generacin de pginas se
integra contenido, arquitectura, navegacin e interfaz para crear esttica o
dinmicamente el aspecto ms visible de las aplicacin, las pginas. El Test busca
errores a todos lo niveles: contenido, funcional, navegacional, rendimiento, etc. El
hecho de que las aplicaciones residan en la red, y que interoperen en plataformas muy
distintas, hace que el proceso de test sea especialmente difcil. Finalmente, el
resultado es sometido a la evaluacin del cliente.

2.2 ControI y Garanta de Ia CaIidad

Una de las tareas colaterales que forman parte del proceso es el Control y Garanta de
la Calidad (CGC). Todas las actividades CGC de la ingeniera software tradicional
como son: establecimiento y supervisin de estndares, revisiones tcnicas formales,
anlisis, seguimiento y registro de informes, etc, son igualmente aplicables a la
ngeniera Web. Sin embargo, en la Web toman especial relevancia para valorar la
calidad aspectos como:
Usabilidad, Funcionabilidad, Fiabilidad, Seguridad, Eficiencia y Mantenibilidad

2.3 ControI de Ia Configuracin
Establecer mecanismos adecuados de control de la configuracin para la ngeniera
Web es uno de los mayores desafos a los que esta nueva disciplina se enfrenta. La
Web tiene caractersticas nicas que demandan estrategias y herramientas nuevas.
Hay cuatro aspectos importantes a tener en cuenta:

Contenido: Considerando la dinamicidad con la que el contenido se genera,
es tarea compleja organizar racionalmente los objetos que forman la
configuracin y establecer mecanismos de control.
PersonaI: Cualquiera realiza cambios. Hay mucho personal no especializado
que no reconoce la importancia que tiene el control del cambio.
EscaIabiIidad: Es comn encontrar aplicaciones que de un da para otro
crecen considerablemente. Sin embargo, las tcnicas de control no escalan
de forma adecuada.
48
PoItica: Quin posee la informacin? Quin asume la responsabilidad y
coste de mantenerla?

2.4 La Gestin deI Proceso

En un proceso tan rpido como es el proceso de ngeniera Web, donde los tiempos de
desarrollo y los ciclos de vida de los productos son tan cortos, merece la pena el
esfuerzo requerido por la gestin? La respuesta es que dada su complejidad es
imprescindible. Entre los aspectos que aaden dificultad a la gestin destacamos: -
alto porcentaje de contratacin a terceros, - el desarrollo incluye una gran variedad de
personal tcnico y no tcnico trabajando en paralelo, - el equipo de desarrollo debe
dominar aspectos tan variopintos como, software basado en componentes, redes,
diseo de arquitectura y navegacin, diseo grfico y de interfaces, lenguajes y
estndares en nternet, test de aplicaciones Web, etc, lo que hace que el proceso de
bsqueda y contratacin de
personal sea arduo.

3. Qu marca Ia diferencia?

A modo de breve resumen enumeramos las siguientes diferencias:
Confluencia de disciplinas: Sistemas de nformacin, ngeniera Software y
Diseo Grfico que requiere equipos multidisciplinares y polivalentes.
Ciclos de vida y tiempo de desarrollo muy cortos
Cambio continuo: Necesidad de soluciones que permitan flexibilidad y
adaptacin conforme el proyecto cambia.
Requisitos fuertes de Seguridad, Rendimiento y Usabilidad.

4. Por qu es necesaria?

La Web evoluciona y crece sin diseo alguno. Prcticas tan pobres de calidad pueden
introducir defectos que dejen al efecto 2000 como un juego de nios. Es deber de
todos proporcionar cimientos firmes a una tecnologa que "mgicamente nos permite
acceder a cualquier hora a cualquier punto del planeta para obtener bienes tan
valiosos como son los Servicios y la
nformacin.

5. PrincipaIes servicios en Ingeniera Web
Sistemas de Consulta de Cuenta Corriente.
Sistema de nventario.
Sistemas Historial de Transacciones.
Sistema de Contacto.
Sistema de Catlogo y Cotizacin.
Sistemas de Foros.
Sistemas de Seguimiento de reclamos.
Sistema de Publicacin, Reportes y descarga de documentos.
Portales de Servicios.
Comercio electrnico

49
5. ConcIusiones
La aplicacin de principios de ingeniera pueden evitar el caos potencial al que nos
enfrentamos, y
poner bajo control el desarrollo de las aplicaciones Web, minimizando riesgos
y mejorando el mantenimiento y calidad.

Los servicios ofrecidos hoy en da por nternet, han abierto un amplio abanico de
posibilidades para las empresas, permitindoles llegar a un publico masivo, eliminar
los intermediarios y abaratar costos en los que a la comunicacin con el cliente se
refiere, es debido a esto que cada da son ms las empresas que utilizan esta
herramienta tecnolgica para captar usuarios, fidelizarlos, hacerles llegar sus ofertas y
realizar transacciones con ellos.
El auge que han experimentado las aplicaciones de nternet se manifiesta a cada
instante en nuestra vida cotidiana, permitindonos realizar tareas como comprar un
pasaje de avin o realizar una transaccin bancaria, desde la comodidad de nuestro
hogar. La ngenieria Web pone todo el potencial de nternet, ofreciendo aplicaciones
flexibles, modularizadas

50
UNIDAD VIII

REINGENIERA DE SOFTWARE

1. Introduccin
En un articulo seminal escrito para la Harvard Bussiness Review, Michael Hammer
sentaba las bases para una revolucin del pensamiento administrativo acerca de los
procesos y la computacin en los negocios: " Ha llegado el momento de dejar de
pavimentar los senderos de vacas ". En lugar de incrustar unos procesos anticuados
en silicio y en software, deberamos eliminarlos y volver a empezar. Tenemos que la
ingeniera de nuestros negocios: hay que utilizar la potencia de la tecnologa de la
informacin moderna para redisear de forma radical nuestros procesos de negocios,
con objeto de lograr unas mejoras dramticas de su rendimiento. Todas las compaas
funcionan de acuerdo con una gran cantidad de reglas no escritas... La Reingeniera
intenta apartarse de las viejas reglas acerca de la forma en que se organizan y
desarrollan nuestros negocios.

Al igual que todas las revoluciones, la llamada a las armas Hammer ha dado lugar
tanto a cambios positivos como a otros negativos. Algunas compaas han hecho un
esfuerzo legitimo para rehacer su ingeniera, y los resultados han mejorado su
competitividad. Otras se han basado nicamente en reducir las dimensiones y hacer
subcontratos para mejorar sus beneficios. Con excesiva frecuencia, unas
organizaciones con poco potencial de futuro crecimiento han sido el nico resultado.

Cul es el nexo existente entre la Reingeniera de negocio y la ngeniera del
software?
La respuesta yace en una El software suele ser la realizacin de las reglas de
negocios que describe Hammer. A medida que cambian estas reglas, el software tiene
que cambiar tambin. En la actualidad, existen compaas importantes que poseen
decenas de miles de programas de computadora.

"Reingeniera de Software".

Este escenario resulta sumamente conocido: se tiene una aplicacin que ha servido
para las necesidades del negocio de una compaa durante diez o quince aos. A lo
largo de este tiempo, ha sido corregida, adaptada y mejorada muchas veces. Las
personas se dedicaban a esta tarea con la mejor de las intenciones, pero las buenas
practicas de ingeniera del software siempre se echaban a un lado. Ahora, la
aplicacin se ha vuelto inestable. Sigue funcionando, pero cada vez que se intenta
efectuar un cambio, se producen efectos colaterales graves e inesperados. Y sin
embargo, la aplicacin debe de seguir evolucionando. Qu se puede hacer? El
software imposible de mantener no es un problema nuevo.

"Mantenimiento deI Software"

A principios de los aos 70, el iceberg de mantenimiento era suficientemente grande
para hundir un portaaviones. En la actualidad, podra hundir toda la armada. El
mantenimiento del software existente puede dar cuenta de mas del 60 por ciento de
las inversiones efectuadas por una organizacin de desarrollo, y ese porcentaje sigue
ascendiente a medida que se produce mas software. Se puede prever en el horizonte
la existencia de organizaciones de desarrollo de software, que ya no puedan producir
software nuevo porque todos los recursos disponibles se estarn invirtiendo en el
mantenimiento de software viejo. Segn Osborne y Chikosfsky; gran parte del software
del que dependemos en la actualidad tiene por termino medio entre diez y quince aos
51
de antigedad. Aun cuando estos programas se crearon empleando las mejores
tcnicas de diseo y codificacin conocidas en su poca , se crearon cuando los
tamaos de los programas y el espacio de almacenamiento eran las preocupaciones
principales. A continuacin se trasladaron a las nuevas plataformas, se ajustaron para
adecuarlos a cambios de maquina y de sistema operativo, y se mejoraron para
satisfacer nuevas necesidades del usuario; y todo se hizo sin tener en cuenta la
arquitectura global.

Se puede definir el mantenimiento describiendo las cuatro actividades que se
emprenden cuando se publica un programa para su utilizacin:
- Mantenimiento correctivo
- Mantenimiento adoptivo
- Mejores o mantenimiento de perfeccionamiento
- Mantenimiento preventivo o Reingeniera

Tan solo el 20 por ciento de nuestros esfuerzos de mantenimiento se
invertirn . El 80 por ciento restante se dedica a adaptar los sistemas existentes a los
cambios de su entorno externo, a efectuar las mejoras solicitadas por los usuarios y a
rehacer la ingeniera de las aplicaciones para su posterior utilizacin.

"Un ModeIo de Procesos de Reingeniera deI software"

La Reingeniera requiere tiempo; cuestan unas cantidades significativas de dinero y
absorbe recursos que de otro modo podran dedicarse a preocupaciones ms
inmediatas. Por todas estas razones, la Reingeniera no se lleva a cabo en unos pocos
meses, ni siquiera en unos pocos aos. La Reingeniera de sistemas de informacin
durante muchos aos. Esta es la razn por la cual toda organizacin necesita una
estrategia pragmtica para la Reingeniera del software.

Una estrategia realizable ira implicada en un modelo de procesos de Reingeniera.
Veamos en primer lugar algunos principios bsicos. La Reingeniera es una tarea de
reconstruccin, se puede comprender mejor la Reingeniera de sistemas de
informacin si se considera una actividad anloga: la reconstruccin de una casa.
Considere la situacin siguiente:

Suponga que ha adquirido una casa que se encuentra en otro estado. Nunca ha
llegado a ver realmente la finca, pero la consigui por un precio sorprendentemente
reducido, advirtindosele que quiz fuera preciso reconstruirla en su totalidad. Cmo
se las arreglara?
- Antes de empezar a reconstruir, seria razonable inspeccionar la casa. Para
determinar si necesita una reconstruccin, usted creara una lista de criterios,
para que la inspeccin fuera sistemtica.
- Antes de derribar y de reconstruir toda la casa, asegrese de que la estructura
esta en mal estado.
- Antes de empezar a reconstruir, asegrese de que entiende la forma en que se
construyo el original. Eche una ojeada por detrs de las paredes. Comprenda el
cableado, la fontanera y los detalles internos de la estructura. Aun cuando vayan
a eliminarlos todos ellos, las ideas que obtendr le servirn muy bien cuando
empiece a construirla.
- Si empieza a reconstruir, utilice tan solo los materiales ms modernos y de mayor
duracin. Quiz le cuestan un poquito mas ahora, pero le ayudaran a evitar un
mantenimiento costoso y lento ms tarde.
- Si se decide a reconstruir, tenga una actitud disciplinada. Haga uso de
herramientas que den lugar a una gran calidad, tanto hoy como en el futuro. Aun
52
cuando los principios anteriores se centran en la reconstruccin de una casa, son
aplicables igualmente bien a la Reingeniera de sistemas y aplicaciones basadas
en computadoras.

El paradigma de la ingeniera es un modelo cclico. Esto Significa que cada una de las
actividades presentes como parte del paradigma pueden volver a visitarse en otras
ocasiones. Para cualquier ciclo particular, el proceso puede terminar despus de
cualquiera de estas actividades.

2. Las cinco etapas de rpida reingeniera:
Damos el nombre de rpida reingeniera, a nuestra metodologa de reingeniera de los
procesos (R.P.), porque se ha diseado para producir resultados sustantivos
rpidamente, por lo general en el trmino de seis meses a un ao.
Rpida Reingeniera se dise para realizar los beneficios que si se pueden obtener
en ese espacio de tiempo, dejando el terreno preparado para ultimas mejoras. Las
etapas se dividen en 54 tareas en conjunto. La metodologa completa supone que las
etapas uno y dos (preparacin e identificacin) tiene como campo de accin los
procesos claves de una compaa. Las etapas tres, cuatro y cinco (visin, solucin y
transmisin) se repiten para cada proceso o grupo de procesos seleccionados para
darles reingeniera.
La rpida reingeniera no especifica que sea necesario contratar consultores externos.
Se ha diseado para gerentes y profesionales de la mayora de las compaas sin
consultores especializados. Hay compaas que al usar ellas mismas rpida
reingeniera, sin ayuda externa. En otras compaas, todo el equipo de reingeniera fue
instruido por consultores que despus actuaron como facilitadores del trabajo del
equipo. Y en otras compaas, los consultores forman parte integrante de los equipos
de reingeniera. Como la rpida reingeniera se dise para utilizarla en todos estos
casos, tiene que ser accesible a los no especialistas.
La rpida reingeniera se dise de manera tal que requiere muy pocas herramientas.
Se puede ejecutar con un lpiz, papel, un modelo de diagramacin del flujo de trabajo
y unos pocos formularios sencillos. En un nivel apenas ligeramente ms sofisticado, se
pueden pensar en programas de proyeccin electrnica para las tareas cuantitativas,
lo mismo que para la presentacin de datos cualitativos en forma tabular. Programas
de administracin de proyectores se pueden pesar no slo para planificar y vigilar el
desarrollo del proyecto de reingeniera sino tambin para simples diagramas de flujo
del proceso.

Etapa 1: PREPARACIN
En un proyecto real de reingeniera, la administracin casi siempre tendr alguna idea
de las metas no financieras. Entre ellas se incluyen ideas sobre servicio a clientes,
rapidez y precisin de la ejecucin, calidad, facultar a los empleados, mayor
disponibilidad de informacin, aplanamiento de organizacin, descentralizacin etc.
As podremos ver mejor como las metas no financieras entran en la visin. Adems de
las metas, el equipo administrativo tiene que desarrollar tambin una lista de
cuestiones pertinentes. Entre esas cuestiones se incluyen el tiempo, el costo, el riesgo
y las dimensiones sociales del cambio. Este puede ser el reemplazo de un alto
ejecutivo. O puede ser cualquier otro acontecimiento que compense al patrocinador de
que las cosas tienen que cambiar. Para una compaa, la descongelacin es algo as
como abrir una ventana a la oportunidad. Lo importante es ver que la nueva reforma
represente un avance decisivo emprendimiento, en relacin con lo que antes exista, y
que no sea simplemente un cambio incremental. El tiempo disponible para el proyecto
de reingeniera puede depender nicamente de la paciencia del patrocinador. Por
ejemplo, una compaa puede verse obligada a redisear su proceso de servicio al
cliente a fin de sustentar un nuevo producto cuya fecha de introduccin ya se fij. Otra
compaa talvez tenga que redisearse y mejorar su rendimiento para evitar ser
53
vendida por la casa matriz o para alcanzar mejor precio. En general, el tiempo para el
proyecto se debe calcular entre seis y dieciocho meses.
La segunda cuestin es el costo. Esto significa si esos casos los fondos tienen que
tomarse de otras reas, la compaa tiene que aceptar ms baja rentabilidad y debe
tomar dinero prestado, o bien que el proyecto de reingeniera tiene que ser
autofinanciado. La administracin tiene que decirle al equipo de reingeniera cuanto
dinero est dispuesto a gastar en el proyecto de reingeniera y a qu ritmo.
La tercera cuestin es el riesgo. Qu pasa si fracasa el proyecto de reingeniera?
Durante las cuatro primeras etapas de reingeniera, una compaa tendr
oportunidades adecuadas de cambiar de direccin o suspender el proyecto. No hay
que olvidar que reingeniera significa avance decisivo, no cambio incrementado.
La 4 cuestin es la dimensin social, que est ntimamente relacionada con el riesgo.
La cuestin social es: cunta perturbacin estamos dispuestos a producir en la vida
de las personas? Para los empleados que quedan en el proceso rediseo, la vida
tambin cambia en general, en los procesos rediseados los cargos son ms amplios
y requieren mayor responsabilidad. Hay ms autonoma y menos supervisin. Los
socios en los negocios, como vendedores, proveedores, asociados en empresas
conjuntas y clientes, tambin pueden ser afectados por la reingeniera.
La ltima parte del taller ejecutivo se dedica a integrar y orientar al equipo de
reingeniera por lo menos la posibilidad de tres tipos distintos de equipos:
- El primero es el que ejecuta las etapas uno y dos, preparacin e identificacin.
- El segundo tipo de equipo de reingeniera es el que ejecuta las etapas visin y
solucin.
- El tercer tipo de equipo es el que ejecuta la etapas cinco, transformacin.

Tarea 1.1: EIegir Personas Idneas
Para los equipos de reingeniera es uno de los factores crticos para el xito de un
proyecto de este tipo. Sus miembros deben no slo dar informacin acerca de sus
respectivas reas y cmo les afecta el proceso sino que tambin deben representar a
esas reas. Dos caractersticas que buscan al escoger a los miembros del equipo:
conocimientos y autoridad.
La Reingeniera de procesos es un programa que una compaa puede delegar
tranquilamente en personas de fuera, como por ejemplo, con consultores de
administracin. Tiene que hacerla el personal de la misma compaa, otra parte,
personal de fuera tratarse de consultores, empleados de otras divisiones o de
individuos contratados ex profeso representan un papel valiossimo en los proyectos
de reingeniera. Los consultores, sean internos o externos, suelen aportar igualmente
mtodos especficos, herramientas y experiencia al proyecto de reingeniera. Tambin
es necesario concederles a los miembros del equipo tiempo suficiente para dedicarlo
al trabajo del proyecto.

Tarea 1.2: Preparacin
Una vez organizado el equipo de reingeniera, est listo para recibir su constitucin: el
mando que le da el grupo ejecutivo. En este punto, la ltima tarea de dicho grupo es
evitar ese mandato al equipo de reingeniera, y hay varias maneras de darlo, segn la
cultura de la compaa y la oportunidad de las cuestiones.

Tarea 1.3: Capacitar AI Equipo
Esta tarea capacitar al equipo para acometer su misin. ncluir definir las expectativas
de la administracin, desarrollar trabajo de equipo, aprender el mtodo, escoger las
herramientas manuales o automticas que se va a usar en el proyecto, adoptar una
terminologa comn, trabajar como ejemplos de reingeniera, y, finalmente, asumir la
responsabilidad del proyecto.

Tarea 1.4: PIanificar EI Cambio
54
La ltima tarea del equipo de reingeniera en la etapa de preparacin es desarrollar el
plan global para el resto del proyecto. Esta tarea desarrolla igualmente el plan y la
programacin del proyecto y defiende los mtodos de administracin de este si todava
no se han especificado. Estos dos factores la tecnologa y las personas son la clave de
la transformacin de los procesos en la vida de los negocios. En muchos proyectos de
reingeniera se comete el error de "tecnocentrismo". Se dicen cosas como: (estamos
rediseando, hemos adquirido procesamiento de imagen", o bien: "estamos
adquiriendo procedimientos de imagen", o bien: "estamos rediseando, estamos
pasando plataformas de cliente / servidor".
1. Porque se necesita el proyecto de reingeniera.
2. Cul es su alcance.
3. Resultados clave de la R. P.
La reingeniera cambia los procesos: la manera de hacer el trabajo. Reingeniera de
Procesos significa cambio, y a la gente no le gusta cambiar.
La herramienta ms poderosa que tiene la administracin es la comunicacin. No hay
ninguna "reingeniera secreta", de modo que la eleccin no es entre comunicacin y no
comunicacin, sino entre comunicacin administrada y comunicacin no administrada.
Administrando la comunicacin, la compaa por lo menos dispone de los medios para
hacer frente a estos hechos. El mecanismo de retro informacin es muy importante por
tres razones: la primera, porque proporciona al equipo de reingeniera la manera de
verificar el acierto de lo que est haciendo, la segunda, por qu sirve como mecanismo
de evaluacin, y la tercera, porque da a los receptores una sensacin de participacin
de no poder darles un canal de comunicacin de una sola va. La comunicacin inicial
hecha por el equipo de reingeniera tiene una importancia crtica porque fija el tono y el
contexto de todo el proyecto. Debe efectuarse lo ms temprano que se pueda y debe
contener los 4 elementos siguientes:
1. Quines fueron elegidos para figurar en el equipo de reingeniera y porque.
2. que ocurrir durante el proyecto y cuando.
3. qu participacin tendrn las personas en el proyecto.
4. qu se puede decir desde ahora sobre la manera como la reingeniera afectar a
todos los interesados. A nadie debe culpar (ni siquiera a antiguos empleados) de la
situacin actual, ni sealar a ningn grupo para elogiarlo.
Si en la compaa es estilan canales de comunicacin peridica (como reuniones o
boletines informativos), sera lgico adoptar este formato. La idea es evitar a los
empleados una visin previa de lo que ser la cultura al terminar la reingeniera.

Etapa 2: IDENTIFICACIN
El propsito de estas etapas es desarrollar y comprender el modelo del negocio con
procesos orientados al cliente. En ella se producen definiciones de clientes, procesos,
rendimiento y xito; identificacin de actividades que agregan valor; un diagrama de
organizacin, recursos, volmenes y frecuencias; y la seleccin de los procesos que
se deben redisear. La etapa de ubicacin, lo mismo que la de preparacin es para
realizarse una sola vez por cada programa de reingeniera.
En otras palabras, las etapas de identificacin y preparacin capacitan a una
compaa para resolver que procesos redisear y en qu orden, y luego las etapas de
visin, solucin y transformacin.

Tarea 2.1: MoIdear CIientes
En esta tarea se identifican los clientes externos, se defienden sus necesidades y
deseos y se identifican las diversas interacciones entre la organizacin y los clientes.
Es enteramente apropiado empezar la reingeniera de procesos con el cliente, puesto
que todas las cosas de una empresa rentabilidad, prestigio, las recompensas
psicolgicas del xito dependen en ltima instancia de cliente. Estas son las
recompensas de jugar al deporte que llamamos los negocios. Por otra parte, el precio
de ser jugador es satisfacer las necesidades del cliente de manera completa y
55
permanente. El ambiente competitivo de nuestros das tiene pocos nichos en que una
compaa pueda sobrevivir si no sirve adecuadamente a su clientela. Moldear al
cliente es apenas una de las cincuenta y cuatro tareas de la metodologa rpida
Reingeniera pronto basta decir que la reingeniera tiene que empezar por entender a
la cliente: quin es, que necesita o que desea, y porque es importante para l. A veces
ya existe dentro de la compaa el necesario conocimiento del cliente, por lo general
como resultado de actividades estudios especiales continuos emprendidos por
departamentos de marketing o cuentas. Al azar la lista de las necesidades y los
deseos del cliente, el equipo de trabajo tiene que tener buen cuidado de distinguir
entre lo que el cliente dice y lo que realmente quiere. Esta la primera cuestin. Por
ejemplo, cuando cliente dice que quiere un precio bajo, lo que realmente quiere es un
precio bajo pero un determinado nivel de valor en lo tocante a calidad o rendimiento.
Una segunda cuestin es saber quin es el cliente. Los minoristas y las compaas de
servicios personales, por ejemplo, tratan directamente con el consumidor final de sus
bienes o servicios. Pero en cambio muchos fabricantes tratan con revendedores que
no son los usuarios finales. El equipo de reingeniera tiene que entender estas
distinciones y modelarlas.

Tarea 2.2: Definir Y Medir Rendimiento
Esta tarea define la medida de rendimiento orientada al cliente y determina los
actuales niveles de rendimiento, tanto promedios como variaciones. Tambin examina
las normas actuales e identifica los problemas de rendimiento. Slo cuando se
entienden las necesidades y los deseos de los clientes puede una compaa definir
qu significa "rendimiento" y como medir los puntos, tradicionalmente muchas
compaas han desarrollado medidas orientadas a necesidades internas, tales como
costo del producto. Es ms; para que las medidas sean tiles herramientas de
administracin, tienen que guardar relacin con un punto de referencia. Cuando una
medida se ha venido usando durante cierto tiempo, el punto de referencia puede ser
una lnea base o una norma.

Tarea 2.3: Definir Entidades
Esta tarea de fin de las entidades o "cosas" conque negocian las organizaciones. Por
ejemplo, en la entidad "empleados" puede presentar los casos "Juan", "Pedro" y
"Enriqueta". Adems, las entidades tienen atributos que las describen; nmero del
seguro social, fecha de nacimiento, direccin. Otros atributos de entidad guardan
relacin con el estado en que se encuentran la entidad, por ejemplo, dilogo jubilado.
Algunas entidades, como clientes y empleados, son relativamente permanentes
continan existiendo, y nosotros continuamos interesados en ellas durante un tiempo
relativamente largo. Otras, tales como pedidos o cheques, son transacciones existen y
nos interesan durante periodos relativamente cortos. Esta tarea define tambin los
estados en que puede encontrarse cada entidad, y correlaciona los cambios de estado
con las interacciones, es decir, identifican que interaccin causa cada cambio de
estado. Si al lector le parece extraa esta abstraccin, no est solo. La mayora de las
personas a quienes enseamos la metodologa tienen una reaccin anloga. Sin
embargo, sta atraccin es parte cortante de la metodologa rpida Reingeniera. El
primer propsito de esta tarea es obligar al equipo de reingeniera a ver el trabajo del
negocio en una forma nueva, en trminos de procesos en lugar de funciones El
propsito de la atraccin es estimular dicho cambio presentando los familiares en una
forma no familiar, ms o menos como se vera su vecindario si uno lo viera antes de
un globo una avioneta. El segundo propsito es ofrecer un mtodo seguro de
identificar los procesos de una compaa. El tercer propsito de esta tarea es empezar
a identificar la informacin que se necesita en el proceso rediseo y cmo organizarlo.
Puesto que las entidades son "cosas" de inters, son las candidatas o das para
registro de informacin. Es decir, necesitaremos un conjunto de informacin sobre
cada caso de cara entidad (sus atributos), por ejemplo, de cada empleado, cada
56
mquina, cada pedido. Entre los atributos tienen que estar los que describen su estado
(inactivo o jubilado, recibido o despacho.

Tarea 2.4: ModeIar Procesos
Esta tarea define cada proceso e identificar su serie de cambios de estado. Define los
factores crticos del xito. dentificar los insumos y los resultados del proceso, lo
mismo que cualquier estmulo adicional que cause un cambio de estado.

Tarea 2.5: Identificar Actividades
Esta tarea identifica las principales actividades necesarias para efectuar cada cambio
de estado. Determina asimismo el grado en que cada actividad agrega valor, es decir,
el grado en que la actividad contribuye a satisfacer las necesidades o los deseos del
cliente. Las actividades de valor agregado entre las caractersticas: realizan algo que
el cliente aprecia, cambian materialmente una entidad, y es importante ese orden
correctamente desde la primera vez.

Tarea 2.6: Extender ModeIo De Proceso
En este punto de la metodologa rpida Re, los estados de proceso han cumplido su
propsito. Algunas de las mayores oportunidades de mejorar tanto el servicio de los
clientes, como la eficiencia de los procesos, provienen de integrar los procesos de una
compaa ms ntimamente con los de sus clientes. Para estas oportunidades es
necesario extender los lmites del modelo de proceso para incluir sus interfases como
los procesos de los clientes. Por ejemplo, despachar pedidos se toca por un extremo
con el proceso de compras de cliente, por el otro con su proceso de cuentas por
pagar. Esta tarea identifica tambin a los proveedores internos y externos y sus
interacciones con los procesos. As como la administracin eficiente de un proceso,
desde el punto de vista del cliente, requiere medida del rendimiento (externos), as
tambin requiere medida del rendimiento interno. Por eso esta tarea identifica las
medidas adicionales de rendimiento orientadas a los clientes internos, y las incorpora
tambin en el modelo de proceso.

Tarea 2.7: CorreIacionar Organizacin
Esta tarea define las organizaciones que toman parte de cada una de las actividades
principales y el tipo de participacin. Por consiguiente de primera frontera proceso /
organizacin.

Tarea 2.8: CorreIacionar Recursos
En esta tarea se calcula el nmero de empleados y los gastos en cada actividad y
cada proceso. Tambin se calculan los volmenes y la frecuencia de transacciones.
sta informacin se utiliza para computar los costos anuales estimados por actividad y
por proceso, lo mismo que el costo unitario por transaccin. Un segundo propsito de
esta tarea es obtener una lnea de base para la utilizacin de los recursos. Esto se
puede comparar con una similar estimacin del proceso rediseando para obtener la
medida que la mejora que producir la reingeniera. La metodologa de esta tarea es
muy parecida a hablar de determinar costos sobre la base de actividades.

Tarea 2.9: Fijar Prioridades De Procesos
En esta tarea se pondera cada proceso por su impacto sobre las metas y las
prioridades fijadas en la tarea 1. 2, desarrollar consenso ejecutivo, y por los recursos
consumidos. Se toman estos cincuenta, lo mismo que el tiempo, el costo, la dificultad y
el riesgo de la reingeniera el enfoque multidimensional a fin de fijar prioridades para el
proceso de reingeniera. Esta tarea se dise para permitir al equipo de proyecto
desarrollar prioridades que recomienda para reingeniera, obtener la aprobacin
ejecutiva y seguir adelante. Desarrollar prioridades para reingeniera es una tarea
compleja, y requiere analizar mltiples factores y anlisis de alternativas.
57
Los tres componentes principales del anlisis son:
1. mpacto: la contribucin actual y potencial de cada proceso a las metas de la
empresa.
2. Magnitud: los recursos que consuma o utilice cada proceso.
3. Alcance: el tiempo, el costo, el riesgo y el cambio social implcito en la reingeniera
de cada proceso.
La cuantificacin de beneficios esos son los requisitos a que ms se resiste un equipo
de reingeniera porque sus miembros estn acostumbrados a hacer estimaciones
cuantitativas nicamente despus de un anlisis mucho mayor que el que permite la
etapa de identificacin. Muchos gerentes tienen la idea equivocada de que para tomar
decisiones importantes, como que procesos redisear y en que orden, se necesita una
precisin y una exactitud mayores que las que aqu se ilustran. Otro error comn es
tratar de reducir un anlisis complejo de mltiples factores a una sola funcin
numrica. Habitualmente, los equipos tratan de hacer esto asignando puntos a cada
factor para cada proceso, asignando luego ponderaciones a los diversos factores, y,
finalmente, sumando los puntajes ponderados de los procesos para obtener un puntaje
total para cada proceso.

Etapa 3: VISIN
El propsito de esta etapa es desarrollar una emisin del proceso, capaz de producir
un avance decisivo en rendimiento. Se identifican en la etapa de visin los elementos
existentes del proceso, tales como organizaciones, sistemas, flujo de informacin y
problemas y cuestiones corrientes. La capa de visin y las que les siguen se disearon
para practicarse una vez para cada uno de los procesos que se van a redisear. La
"visin", que es la meta y el producto de la capa de visin, es ms que una idea y
menos que un diseo. Es un planteamiento del propsito de redisear el proceso.
Algunos tratadistas de reingeniera empiezan su descripcin de este proceso con el
desarrollo de una visin. Las tareas 3. 1 y 3. 2 tienen por objeto entender la estructura
del flujo del procedimiento actual.

Tarea 3.1: Entender La Estructura DeI Proceso
La estructura de proceso se define en funcin de actividades, pasos, insumos,
productos y estmulos. Necesitamos definir las actividades como las principales
subdivisiones de un proceso. Cada actividad representa una unidad de trabajo mental
o material y produce un resultado. Cada actividad utiliza el resultado material o
informativo de otras actividades (sus insumos). El objetivo de la tarea 3. 1 es
desarrollar eficiente comprensin de tal manera cmo funcionan los procesos actuales
para asegurar que los procesos rediseados que los van a reemplazar representen
realmente una gran mejora. El nivel de detalles que se necesita para llegar a sta
comprensin ser distinto en diferentes casos pero siempre ser menor que el que se
necesita para corregir de proceso actual.

Tarea 3.2: Identificar Actividades De VaIor Agregado
En esta tarea se evala el impacto de cada actividad del proceso sobre las medidas de
rendimiento externo para identificar actividades que agregan valor, las que no lo
agregan y las que son puramente de control interno. Como la etapa de identificacin
trata de todos los procesos principales de una compaa, era entonces necesario
entender todas las necesidades y deseos de los clientes. Ahora en la etapa de visin
tratamos nicamente de un proceso o de unos pocos procesos, de manera que el
equipo no necesita entender sino las necesidades y los deseos del cliente a que
atiende el proceso escogido.
En esta tarea, el equipo de reingeniera identifica las actividades y los pasos que
agregan (o que quitan) valor. Una vez que stos son conocidos y entendidos,
mostrarn el camino para el diseo de los procesos siguiendo principios generales:
reforzar las actividades que agregan valor y tratar de eliminar las que no agregan
58
valor. La manera ms fcil de identificar los pasos que agregan valor es considerar el
impacto de cada uno sobre las medidas de rendimiento del proceso. La ejecucin de
este paso ejercer un impacto positivo en la medida del
rendimiento? Si es as, el paso se conformar con la definicin del valor agregado:
hacer algo que el cliente quiere. El paso puede tambin ejercer un impacto negativo, o
ningn impacto, sobre la medida de rendimiento. El propsito de esta tarea es permitir
al equipo de reingeniera plantearse los interrogantes claves: "Por qu hacemos las
cosas como las hacemos?", "Es esto realmente necesario?" Y "qu estamos
haciendo que en realidad?". Volver a recoger un pedido que se haba recogido
incorrectamente mejora la precisin pero aumenta el tiempo del ciclo. Aqu la
alternativa entre despachar un pedido incorrecto ms pronto y un pedido correcto un
poco despus es obvia, pero ste no es siempre el caso.

Tarea 3.3: Referenciar (Benchmark) EI Rendimiento
En esta tarea se comparan el rendimiento de los procesos en la empresa y la manera
cmo se lleva a cabo con los de organizaciones semejantes, a fin de obtener ideas
para mejorar. Las organizaciones semejantes pueden estar dentro de la misma familia
corporativa o pueden ser compaas comparables, lderes de la industria, o
realizadoras que se consideran las mejores de su clase. La tarea consiste en
identificar empresas comparables, determinar el rendimiento de su proceso y las
diferencias principales que explican las diferencias de rendimiento, y evaluar la
aplicabilidad de dichas diferencias a nuestros procesos. El propsito de la tarea es
plantear las importantes preguntas: por qu realizamos nuestro proceso como lo
realizamos, mientras que ellos lo hacen de una manera distinta? Podemos aprender
algo de ellos?. El benchmarking se ha convertido en un tema que tiene su propia
literatura. Se populariz desde mediados hasta fines de los aos 80 como parte del
movimiento en favor de la calidad, y es una actividad que se requiere para toda
compaa que aspire al premio nacional de calidad Malcolm Baldrige. Pero lo que s es
claro para nosotros es que el benchmarking "clsico" no es ni factible necesario para
la reingeniera de procesos. No es factible porque se emplea en ella demasiado tiempo
y requiere demasiados recursos para un proceso de reingeniera. En el benchmarking
clsico puede gastarse enormes cantidades de tiempo investigando a otras
compaas; seleccionando inhibiendo variables de rendimiento; normalizando
resultados para asegurar que se compare
entidades homogneas; y negociando, arreglando y llevando a cabo visitas recprocas
con las muchas compaas.
Nuestro enfoque en el benchmarking se vale principalmente de fuentes secundarias y
terciarias de informacin, rara vez de fuentes primarias. An as, el mtodo de adquirir
informacin es de preferencia el telfono, ms bien que visitas personales. El
propsito de toda esta actividad de benchmarking es doble: primero, ofrecer puntos de
vista adicionales sobre las caractersticas de nuestra propia prctica; Y segundo,
obtener ideas de cmo hacer mejor lo que hacemos. Para cumplir este propsito no es
necesario tener medidas numricas precisas del desempeo relativo. Basta conocer el
rendimiento relativo en forma general. Si la compaa X parece tener un rendimiento
que es 15% superior al nuestro, no importa que realmente sea el 10% o el 20%.
Primero que todo debemos descontar una estimacin demasiado generosa. Luego
debemos descontar la posibilidad de que nosotros y la compaa X. miramos el
rendimiento de manera distinta. Finalmente, estamos buscando un avance decisivo, y
un 10% o un 20% no representan nada sensacional. As que probablemente
llegaramos a la conclusin de que la compaa X. no es contra el proceso mucho
mejor que nosotros. Pero si el margen fuera del 50%, entonces s es claro que habra
que investigar el asunto ms a fondo.

Tarea 3.4: Determinar Los ImpuIsos DeI Rendimiento
59
Esta tarea define los factores que determinan el rendimiento de los procesos
identificados:
- Fuentes del problema y errores.
- Capacitadores e inhibidores del rendimiento del proceso.
- Disfunciones e incongruencias.
- Fragmentacin de actividades u oficios.
- Lagunas de informacin o demoras.
Cuando uno examina un proceso y trata de entender por qu es como es, est
haciendo arqueologa industrial, pues los procesos en la mayor parte de las
compaas no se disearon desde el principio sino que son ms bien accidentes
histricos, acumulacin de costumbres y prcticas con una capa de sistemas y
procedimientos. La tarea de determinar los impulsores de rendimiento identificar, pues,
factores, caractersticas y elementos del proceso que son responsables de sus
deficiencias y evaluar su impacto.

Tarea 3.5: CaIcuIar Oportunidades
La falta de datos cuantitativos en realidad no ofrece dificultades en esta etapa porque
el nico propsito de esta evaluacin es decidir en forma preliminar que oportunidades
de mejora se han de incorporar en la visin del proceso. La etapa siguiente, solucin,
se tomarn decisiones especficas sobre cmo alcanzar la visin del proceso, y
entonces s se pueden hacer clculos ms confiables de costos y beneficios. Por
ahora todo lo que pide el equipo de proyecto es que el patrocinador acepte la visin y
lo autorice para seguir adelante y pasar a la etapa siguiente.

Tarea 3.6: VisuaIizar EI IdeaI (Externo)
Esta tarea describe cmo operara el proceso una vez optimizadas todo a las medidas
de rendimiento extremo. En particular, describe el comportamiento de las actividades
que tiene interfaz con clientes y proveedores.

Tarea 3.7: VisuaIizar EI IdeaI (Interno)
Esta tarea describe cmo operara el proceso con todas las medidas optimizadas de
rendimiento interno. Repite, pues, la tarea 3. 7 tratando a los participantes internos
como clientes y proveedores. Esta tarea describe tambin cmo se ejecutaran las
funciones claves de cada oficio para alcanzar rendimiento ideal.

Tarea 3.8: Integrar Ediciones
Es posible que los ideales internos y externos estn en conflicto. Esta tarea identifica
tales conflictos y busca acomodamiento entre las capacidades alternas para producir
la visin integrada ms eficaz. Las tareas 3.7, 3. 8 y 3.9 se ejecutan por lo general
simultneamente o por lo menos en forma interactiva; pero, en todo caso, la visin
final debe ser internamente coherente y convincente.

Tarea 3.9: Definir Subdivisiones
En esta tarea se examina el tiempo necesario para realizar la visin del proceso, y la
posibilidad de definir subdivisiones sucesivas entre el proceso actual y la visin
completamente integrar. Cada subdivisin, si se define se relaciona con metas de
rendimiento.

Etapa 4 : SOLUCIN: DISEO TCNICO
El propsito de sta etapa es producir un diseo del proceso capaz de realizar la
visin. La etapa contesta la pregunta "cmo?" El desarrollo de la solucin tiene dos
componentes: diseo tcnico y diseo social. Observar que la informtica ofrece dos
claras capacidades para mejorar el rendimiento del trabajo. La primera y ms popular
60
es la automatizacin y el reemplazo efectivo de tareas manuales por tareas de
mquinas. La segunda es la informacin. Para automatizar, un computador tiene que
desarrollaron registro electrnico del proceso que est automatizando. El tercer
capacitadores de Reingeniera de Procesos es el potencial humano. La mayor
debilidad de la organizacin de mando y control es que es inflexible y pesada. Los
trabajadores que se encuentran en la interfaz entre el ambiente externo y la
organizacin no estn facultados para responder a los cambios que encuentra. Deben
transmitir informacin, lenta e imperfectamente, a los altos ejecutivos, que slo se
resuelven cmo se debe responder. El modelo de mando y control se ven hoy como
una organizacin cada vez menos eficiente, porque vivimos en una poca de cambio
acelerado. Ya no hay tiempo para que la burocracia responda. Y grandes estrategias y
planes son rebasados por los acontecimientos ms rpido de lo que se poda prever.
Las tendencias geopolticas, sociales, econmicas, culturales y tecnolgicas cambian
con tanta velocidad y en tal magnitud que la gente ve el ambiente como catico. En
este tipo de ambiente la nica respuesta racional es desarrollar formas
organizacionales ms aptas para reaccionar y hacer frente a los hechos imprevisibles.
Los diseos tcnico y social de un proceso tienen que ser congruentes. Es decir,
deben apoyar ambos las metas del proceso. Walton hizo una observacin muy
importante: la tecnologa en s misma es neutral con respecto al papel que se asigna a
los seres humanos. La tecnologa que se puede usar para controlar a las personas o
para facultarlas.

Tarea 4 A.1: ModeIar ReIaciones De Entidades
Esta tarea identifica las relaciones entre entidades. dentifica tambin la direccin y la
cardinalidad de dichas relaciones, es decir, si la relacin es de uno a uno, de unos
muchos, o de muchos a muchos, y cul entidad es "duea" de otra entidad. Puesto
que las entidades son las "cosas" enormemente conque tiene que ver un proceso, los
elementos tcnicos del proceso comprenden informacin sobre las entidades. Esta
tarea es un primer paso para modelar los tractos Las entidades y sus relaciones son el
primer nivel de un modelo informativo del proceso. Niveles subsiguientes,
desarrollados en la etapa 5, especifican los atributos y la implementacin lgica del
modelo informativo. Sin embargo, para el propsito de la presente etapa slo
necesitamos conocer las entidades.

Tarea 4 A.2: Reexaminar Conexiones De Los Procesos
Esta tarea considera si el movimiento de pasos entre entidades, de actividades entre
procesos, o la redistribucin de la responsabilidad de los pasos pueden mejorar el
rendimiento. dentifica tambin casos en que una mejor coordinacin entre actividades
mejorara el rendimiento.

Tarea 4 A.3: Instrumentar E Informar
Esta tarea identifica la informacin necesaria para medir y manejar el rendimiento del
proceso, define puntos donde la informacin se puede almacenar y agregar procesos,
segn se necesite, para captar, reunir y diseminar la informacin necesaria. Por
instrumentar queremos decir instalar los instrumentos necesarios para medir las
variables de rendimiento por las cuales vamos a administrar el proceso. Por informar
queremos decir hacer disponible la informacin de rendimiento de una forma til. Los
instrumentos tienen que suministrar informacin completa y congruente. En un
proceso de reingeniera, el equipo debe cohesionarlo todo, pero especialmente el flujo
de informacin. Con frecuencia se llevan registros y se preparan y distribuyen informes
que son totalmente innecesarios. Un consultor, estudiando los procesos de una
compaa manufacturera pequea, descubri que el gerente de la bodega preparaba
todos los lunes por la maana un informe sobre el consumo de tarimas de madera; la
semana anterior y lo remita al director ejecutivo, ste no tena ni la ms remota idea
de que existan tales informes, pues, sin su consentimiento, su secretaria
61
sencillamente los archivaba. El gerente de bodega no sabia por que preparaba tales
informes; ese haba sido uno de los deberes que le haba dejado su antecesor en el
cargo. Nadie se explicaba semejante caso hasta que el director ejecutivo record que,
diez aos antes en un cctel haba conocido a un individuo que fabricaba tarimas: este
le dijo que le poda ofrecer tarimas a muy buen precio, y le pregunto cuantas
necesitara su compaa. El director ejecutivo no lo sabia, pero prometi averiguarlo.
El lunes siguiente, efectivamente, llamo al gerente de la bodega y le pidi que le
preparara un informe sobre el consumo de tarimas la semana pasada y despus nadie
se acord de advertirle al gerente de bodega que suspendiera ese trabajo.

Tarea 4 a.4: consoIidar interfases e informacin:
Esta tarea define los cambios de proceso necesarios para reducir o simplificar
interfases, tanto internas como externas. dentifica y elimina duplicacin de corrientes
de informacin, y con ellas las actividades de reconciliacin necesarias para resolver a
cual de los duplicados se debe dar crdito. La mayor parte de las organizaciones no
han tenido hasta ahora una perspectiva de proceso, y, por consiguiente, sus esfuerzos
por introducir procedimientos, sistemas y automatizar el trabajo han producido por lo
general una colcha de retrasos de soluciones parciales incompatibles. No es raro ver
un proceso de negocios apoyado por una combinacin de sistemas manuales y
computarizados que no guardan relacin entre s. Esta ambientacin de la informacin
sobre el proceso y el flujo de trabajo tiene varias consecuencias negativas: Crea
trabajo adicional para traducir la informacin de la forma requerida en un paso a la
forma requerida en otro. Con frecuencia vemos empleados alimentando datos a un
programa de computador, que est leyendo de uniforme o documento producido por
otro programa de computador. Se introducen errores y demoras por la necesidad de
trascripcin.

Tarea 4 A.5: Reubicar Y Reprogramar ControIes
Esta tarea busca reducir el nmero de actividades que no agregan valor en el proceso,
simplificando la estructura de control de ste. Se logr esto integrando los controles en
actividades que si agregan valor, tratando de detectar errores por evitar errores, y
trasladando la deteccin del error lo ms cerca posible al punto donde ste se
presenta. Cuando se gozan sistemas manuales, los procesos sobre su mayora
seriales porque toda la informacin necesaria para procesar una transaccin tiene que
pasar por el proceso junto con la transaccin. Distintas personas no pueden trabajar al
mismo tiempo en esta porque el archivo slo puede estar en un lugar a un mismo
tiempo. Las compaas que gozan tales sistemas suelen tener departamentos
centralizados de archivo, que cual destacan los archivos segn se necesite. A veces
esta tarea determina que actividades que antes se hacan en serie elevada ejecutar en
paralelo.

Tarea 4 A.6: MduIo A AnaIizar
El propsito de esta tarea es definir las partes del proceso rediseado que se pueden
implantar independientemente. Esta participacin del proceso, que existe, permite que
el proceso sea distribuido en el espacio o en el tiempo. El anlisis formal de esta tarea
consiste determinar las dependencias entre las actividades del proceso revisado y en
determinar interacciones entre actividades y entidades.

Tarea 4 A.7: Especificar ImpIantacin
Esta tarea utiliza los mdulos definidos en la tarea anterior para evaluar alternativas
estructurales y alternativas de implementacin. El anlisis de estas alternativas
conduce enseguida a la implantacin elegida.

62
Tarea 4 A.8: ApIicar TecnoIoga
La tecnologa es uno de los capacitadores claves de la reingeniera de procesos. Las
principales aplicaciones de tecnologa en la reingeniera de procesos son para lo
siguiente:
- Analizar, por ejemplo; simulaciones, correlaciones, tendencias, proyecciones
electrnicas, presupuestos, o los estndar de contralor real.
- Captar y documentar, por ejemplo; imagen, almacenamiento de datos, micro pelcula.
- Comunicar, por ejemplo; comunicaciones de datos, telefona, vdeo, deberes.
- Control, por ejemplo; telemetra, control de proceso, inteligencia artificial,
retroalimentacin, mando control.
- Manufacturar, por ejemplo; diseo ayudado por computador, manufacturar
computarizadas o integrada, manejo de materiales, robtica.
- Dar movilidad, por ejemplo; telfono celular, jugadores ratn o manuales.
- Compartir pericias, por ejemplo; sistemas expertos basados en conocimientos,
carteleras.
- Compartir informacin, por ejemplo; bases de datos, servicios de informacin
externas y deberes.

Tarea 4 A.9: PIanificar ImpIementacin
La revisin en este punto culminante es la ms importante de todo el proyecto de
reingeniera. Detiene adelante, los recursos se gastarn mucho ms velozmente que
antes y el conocimiento de los planes se extender ms all del equilibrio y de sus
patrocinadores. Un requisito previo para lograr el apoyo necesario es identificar
temprano a los interesados y sus problemas, y luego hacer frente a sus problemas.
Otro requisito previo es ver que las personas necesarias llegan participando en el
proyecto y comprometidas con l.

Etapa 4 B: SoIucin: Diseo SociaI
El diseo social necesariamente tiene que realizarse al mismo tiempo del diseo
tcnico pues para que un proceso fuere eficaz, estos dos componentes deben ser
congruentes. El propsito de sta etapa es especificar las dimensiones sociales del
proceso. La etapa de diseo social produce descripciones de la organizacin y de
dotacin de personal, cargos, planes de carrera e incentivos que se emplea en el
proceso de diseo.

Tarea 4 B.1: FacuItar AI PersonaI Que Tiene Contacto Con EI CIiente
Para mejorar la respuesta y la calidad del servicio que un proceso presta el cliente, es
preciso facultar al personal que tiene contacto con l. Por "facultar" entendemos
cambiar la responsabilidad, la autoridad, el conocimiento, las destrezas y los
instrumentos que se necesitan para capacitar al personal que tiene contacto con el
cliente, a fin de que desempee sus deberes correctamente desde la primera vez. La
reingeniera de procesos est firmemente dentro de la teora y de administracin.
Estimula la idea de que casi todos los trabajadores desean trabajar y hacer un buen
trabajo, pero que la organizacin se impide. Una manera como la administracin
estorba el buen desempeo del individuo es que no le comunica claramente al
empleado que es lo que quiere que este rea. El diseo social de un proceso busca
eliminar todas estas defunciones. En particular, esta tarea examina los cambios que se
necesitan en la definicin de empleos de contacto con el cliente: la responsabilidad y
la autoridad se les asigna y ciertas son conmensurables o no con el alcance del
empleo.

Tarea 4 B.2: Identificar Grupos De Caractersticas De Cargos
Todos los cargos, an los ms sencillos, tienen mltiples requisitos: caractersticas
humanas que son importantes en su desempeo. Hasta el del concebido autmata
que no hace ms que apretar tuercas en una lnea de montaje se podra describir en
63
funcin de caractersticas tales como destreza manual, a fuerza, o capacidad de poner
atencin. Destrezas o habilidades y las actitudes que se requieren en el empleo: cmo
hacer las cosas. El trmino destreza es sinnimo de arte de oficio porque la esencia
de una vocacin es el conjunto de destrezas que se requieren para su oficio. El
conocimiento se adquiere generalmente por medio de la educacin y ampliar y que
modificar con la experiencia. Tanto las destrezas como los conocimientos consiste en
el contenido que un trabajador aporta al cargo.

Tarea 4 B.3: Definir Cargos Y Equipos
En la tarea anterior, identificamos las destrezas, los conocimientos y la orientacin que
se necesitan en los cargos actuales al redefinirlos para satisfacer las necesidades del
proceso de rediseo en esta tarea, examinamos la agrupacin de requisito de los
cargos para determinar cules de los actuales cargos se pueden conservar o subir de
categora, cuales combinar y cules eliminar. En una situacin ideal, o slo cargo
realizara todo un proceso, como lo cual se eliminaran todas las actividades que no
agregan valor, como traspasar trabajos, a comunicar, coordinar, a controlar, etc. Eso
reducira tambin las oportunidades de introducir errores en el proceso.

Tarea 4 B.4: Definir Necesidades De Destrezas Y PersonaI
sta etapa empieza por identificar el nivel de cada destreza, rea de conocimiento y
orientacin que se requieran para cada nuevo cargo y refleja estos requisitos de una
matriz. La revisin es en parte mecnica y en parte valorativa. La parte mecnica
consiste en hacer el nivel de cada requisito del cargo rediseado igual al
mximo de los niveles en cualquiera de los cargos combinados para formar el nuevo.

Tarea 4 b.5: especificar Ia estructura gerenciaI.
En esta tarea se especifica cmo se van a llevar a cabo en el proceso rediseado los
tres componentes principales de la gerencia. El liderazgo es necesario para ser que la
gente trabaje de acuerdo en la misma direccin. Los deberes del lder son planificar y
fijar la direccin. La direccin del trabajo es necesaria para asegurar que se haga el
trabajo que se necesita, que lo hagan personas idneas, en tiempo oportuno y en
forma correcta. En teora tradicional de administracin, estos tres papeles gerenciales
se concentran en un mismo individuo. Pero esto pasa por alto el hecho de que no
todos los gerentes son igualmente aptos en los tres papeles. El dueo del proceso es
el gerente de ms bajo nivel responsable de todo el proceso. En una organizacin no
rediseada, el dueo, segn esta definicin, es el director ejecutivo en jefe de
operaciones puesto que la mayora de los procesos sobre intereses funcionales. En
una organizacin no rediseada no hay dueo del proceso porque nadie se hace
responsable de este: nadie tiene que rendir cuentas de los resultados. Generalmente,
los candidatos a dueos son los gerentes de ms alto nivel. La era de diseo con
frecuencia organizaciones que son "ms planas" de lo que eran antes, es decir, que
contienen menos niveles de administracin. Puesto que todos los empleados estn
facultados, ms ellos son responsables de su propio trabajo o forman parte equipos
autnomos, de manera que los gerentes tienen menos responsabilidad de la direccin
del trabajo. Cuando no se observa la estructura organizacional de una gran compaa,
con muchos niveles de administracin y muchos empleados administrativos y
profesionales de apoyo, se da rpidamente cuenta de que toda la estructura entre el
primer nivel gerencial y la alta administracin es decir, la gerencia media se dedica
principalmente a permitir informacin entre unos y otros. En la direccin hacia arriba,
analiza, interpreta, sintetiza y lleva a cabo estudios especiales para informar a los altos
administradores. En la direccin hacia abajo traduce la estrategia de los altos
administradores en tcticas, polticas y procedimientos operativos. Al ejecutar stas
funciones, los gerentes medios agregan pero tambin sustraen valor.

64
Tarea 4 B.6: Redisear Fronteras OrganizacionaIes
Esta tarea considera la conveniencia de cambiar las estructuras organizacionales a fin
de asegurar que cada equipo permanezca dentro de una sola organizacin y reducir el
nmero de fronteras organizacionales que el proceso atraviesa. Los equipos definidos
para proceso rediseado son esencialmente diferentes de los equipos elegidos para
proyectos, tales como el equipo de reingeniera. En los procesos rediseado, en
cambio, los equipos son caractersticas permanentes del proceso. Generalmente se
disean para llevar a cabo actividades, subprocesos, o el proceso total, es decir
trabajo de repeticin ms bien que un proyecto. Cuando el diseo para un proceso
rediseado coloca todos los equipos e individuos dentro de una sola organizacin, o
cuando mucho de unas pocas, reduce el nmero de fronteras organizacionales que
proceso tiene que cruzar. Esto mejora automticamente la eficiencia y la calidad del
proceso. Por qu? Porque cada frontera crea la necesidad de un esfuerzo adicional:
esfuerzo para traspasar trabajo, comunicarse, coordinar, sincronizar, explicar,
controlar, registrar, reconciliar, etc. Similarmente, cada frontera que cruce el proceso
crea oportunidades adicionales de error: oportunidades de desacuerdo, de
malentendidos, de malas interpretaciones, malas comunicaciones errores de
trascripcin.

Tarea 4 B.7: Especificar Cambios De Cargos
Esta tarea prepara una nueva matriz de requisitos de tres presas, conocimientos y
orientacin, frente a transiciones de cargos viejos a cargos nuevos. Los elementos de
la matriz consiste primero de cambio que requiere la transicin. Esta tarea tambin
asigna ponderaciones a los requisitos de destrezas, conocimientos y orientacin,
ponderaciones que representan la dificultad relativa de adquirir esta caracterstica. La
media de dificultad de la transicin se us para planificar por adelantado la
reorganizacin y un plan de estudios para capacitar y educar al personal del proceso,
lo que ocurrira en la tapa 5.

Tarea 4 B.8: Disear PIanes De Carreras
Esta tarea es parecida a la anterior, salvo que ahora la matriz es de transicin de un
cargo nuevo a otro tambin nuevo. La tarea ofrece una solucin formal para uno de los
problemas ms enfadosos de la reingeniera. Esta tarea desarrolla medidas de la
dificultad de efectuar transiciones del cargo a cargos, o del cargo real cargo A al cargo
B, o del cargo B al cargo A. Si pasara de A a B es ms difcil y que de B a A, a
entonces claramente el cargo B es de hecho "mayor". Esta tarea considera todas las
transiciones y determina cules son factibles. Esto lleva directamente al desarrollo de
carreras.

Tarea 4 B.9: Definir La Organizacin De Transicin
Hasta aqu, a la tapa 4 se ha concentrado en el diseo social necesario para realizar la
visin final del proceso. Esta tarea examina el diseo social de las subdivisiones, y la
hay. Se lleva a cabo paralelamente con la tarea 4 a. 8, "especificar implantacin", para
que los elementos sociales y tcnicos del proceso sean congruentes. El
aprovechamiento de oportunidades a corto plazo suele plantear un dilema al equipo de
reingeniera. Por una parte, los patrocinadores y otros interesados estn naturalmente
impacientes por ver resultados, y el equipo de reingeniera, por su parte, no quiere
pasar por alto ninguna oportunidad obvia de mejoramiento. Por otra parte, es muy fcil
caer en la trampa de perseguir ganancias fciles y perder en ello el impuls para
ganancias ms significativas.

Tarea 4 B.10: Redisear Programa De Gestin DeI Cambio
Esta es la tarea ms importante de la rpida Reingeniera porque ms proyectos de
reingeniera fracasan por falta de una eficientes gestin del cambio que por defectos
en su diseo tcnico social. A esta altura del proyecto de reingeniera ya se habrn
65
definido las dimensiones mayores de esta cuestin: definicin de cargos, estructura
organizacional y nmero de personas. La tarea programa de gestin del cambio
empieza 40 axiomas de los interesados y sus problemas. Algunos interesados son
personas que disean los mismos cargos y tiene intereses comunes, de modo que el
cargo mismo se puede tratar como el interesado. Los empleados constituyen una
clase o va de interesados, pero hay tambin muchos otros. Segn la organizacin,
puede incluirse entre ellos los distribuidores y los representantes de ventas, los
proveedores, accionistas, reguladores y directores.

Tarea 4 B.11: Disear Incentivos
El objetivo de esta tarea es conocer las metas individuales, organizacionales y del
proceso de incentivos que motive a la gente para ser la transicin al nuevo proceso,
alcanzar los niveles dictados de rendimiento, y comprometerse a una mejora continua.
El tema de incentivos puede ser y ha sido materia de libros aparte. De igual modo, una
necesidad satisfecha deja de ser motivadora. Una vez que el individuo tiene lo
"suficiente" de bienes materiales para satisfacer sus necesidades fisiolgicas, ms de
los mismo ya no lo motiva. Para complicar ms an las cosas, considerarse el dinero.
El dinero es el incentivo ms comn que se usa en los negocios, y puede contribuir a
cualquiera de los cinco niveles de la jerarqua y a todos ellos. Con todo, el dinero es un
motivador dudoso y ambiguo. Es dudoso porque, en las cantidades que generalmente
empleamos para motivar a las personas, hace una contribucin marginal a la
satisfaccin de las necesidades.

Tarea 4 B.12: PIanificar ImpIementacin
En esta tarea se sabe en planes preliminares para implementar los aspectos sociales
del proceso rediseado, inclusive hubo contratacin de empleados, educacin,
capacitacin, reorganizacin y reubicacin. Estos planes sern luego introducidos por
fases, juntamente con los paralelos de implementacin de los aspectos tcnicos del
proceso, desarrollados en las tarea 4A.10. Esta tarea define tambin la "estructura de
gobierno" para el etapa 5, es decir, el papel y las responsabilidades del patrocinador
del proyecto de reingeniera, el dueo del proceso, el gerente del proyecto de
reingeniera y de otros individuos y organizaciones. A las funciones de servicios de
informacin y de recursos humanos les corresponde un papel principal en la etapa 5

Etapa 5: TRANSFORMACIN
El propsito de sta etapa de realizar la visin del proceso implementando el diseo
producido el etapa 4. Las preguntas claves que contesta sta etapa son:
Cundo debemos empezar a controlar el progreso?
Cmo sabemos si vamos por buen camino?
Qu mecanismos debemos desarrollar para resolver problemas imprevistos?
Cmo podemos asegurarnos de que el periodo de transicin no haya tropiezos?
Cmo seguimos creando impulso para cambio continuo?
Qu tcnicas debemos utilizar para reajustar la organizacin?
Entre los participantes en la etapa de transformacin se incluyen el equipo de
reingeniera y las organizaciones de apoyo, tales como servicios de informacin,
recursos humanos, administracin de oficinas, instalaciones, ingeniera industrial,
interesados en el proceso, el dueo del proceso, del patrocinador y otros miembros de
la alta administracin. En algunos proyectos de reingeniera el equipo del proyecto
acta como comit directivo, y la principal responsabilidad de la implementacin recae
sobre las organizaciones zonales en otros proyectos, el equipo de reingeniera acta
como contratista general, y hacer por s mismo las cosas que puede hacer y
subcontrata las que no puede hacer con las organizaciones funcionales poco
abastecedoras externas.

66
Tarea 5.1: CompIetar EI Diseo DeI Sistema
En esta tarea lo mismo que en la subsiguientes, la metodologa rpida se vale de la
nomenclatura de ingeniera informtica. Sin embargo, cualquier mtodo probado,
desarrollo es igualmente vlido. El diseo y el desarrollo de sistemas automatizados
de aplicacin es una empresa llena de riesgos y dificultades. Pese a que las
organizaciones grandes han venido creando tales sistemas desde hace por lo menos
30 aos, el ndice de xitos es considerablemente ms bajo el de otros esfuerzos
organizaciones sindicales. La causa primaria de estos efectos insatisfactorios es que
la mayora de las organizaciones no han rediseado su proceso de desarrollo de
sistemas. ste es un tema que merece su propio libro, y muchos de los ya escrito
sobre reingeniera de software, metodologa que desarrollo de sistemas, y
administracin de proyectos.

Tarea 5.2: Ejecutar Diseo Trmico
Esta tarea tiene que ver con el diseo "interno" del sistema nuevo o revisado que
apoyar proceso rediseado. Para paquetes, esta tarea de la realizaba el vendedor. Las
decisiones sobre seleccin de plataforma de ser impulsadas por las necesidades y por
la disponibilidad de software de aplicacin. En igualdad de circunstancias, un equipo
de reingeniera debe escoger primero el paquete de aplicacin ms apropiado y luego
la plataforma en la cual funcionar mejor. Una vez que sea seleccionado plataforma, el
trabajo restante de la tarea depende de si la aplicacin se va basar el paquete o se va
a desarrollar individualizada.

Tarea 5.3: DesarroIIar PIanes De Prueba Y De Introduccin
Esta tarea determina los mtodos que se van a emplear para validar el sistema; es
decir, determina como verificar la correccin y la calidad de las entregas del proyecto.
La tarea determina tambin los mtodos que se van a usar para conversin y
transicin y desarrolla un plan de implantacin por fases. Tambin hay varias
cuestiones implicadas en implantar o llevar al terreno el sistemas, particularmente en
una organizacin geogrficamente dispersa. El personal que va estar encargado de
llevar el sistema al terreno "en principio" debe tambin intervenir en la planificacin.
Finalmente, la tarea gradual los impactos del nuevo sistema y define los planes de
retirada y contingencia.

Tarea 5.4: EvaIuar AI PersonaI
Esta tarea evala al personal actual en funcin de sus destrezas, conocimientos,
orientacin, el grado de conformidad con el cambio y su actitud. La evaluacin de
actitud es muy importante A pesar de todas estas prcticas, a menudo es necesario
reducir el personal, y entonces la cuestin sta en quienes conservar. El primer criterio
debe ser la actitud de una persona para el empleo rediseado. El segundo criterio
debe ser la conformidad de la persona con el cambio, si lo coge con entusiasmo con
temor. Una vez que esperamos quienes van a manejar el proceso rediseado y
conozcamos sus actuales destrezas, conocimientos y orientacin en comparacin con
los requisitos del cargo, podemos formular las necesidades de capacitacin de cada
persona.

Tarea 5.5: Construir Sistema
Esta tarea produce una versin del nuevo proceso lista para operaciones. Cuando el
proceso se basa en un sistema individualizado, esta tarea incluye desarrollo y prueba
de bases de datos, desarrollo y prueba de sistemas y procedimientos, y
documentacin. Cuando el proceso se basa en un paquete, esta tarea incluye
instalacin y modificacin o extensin del paquete y su prueba. En ambos casos, la
tarea comprende tambin conversin de datos.

67
Tarea 5.6: Capacitar AI PersonaI
sta tarea da capacitacin en operacin, la administracin y el mantenimiento del
nuevo proceso, cost tiempo para que el personal asuma sus nuevas
responsabilidades. ncluye igualmente instrucciones particulares cuando los
empleados asumen dichas responsabilidades por primera vez. A veces instruimos a
las personas para trabajar con el nuevo sistema mientras sta todava siendo
sometido a pruebas. Esto les da a los empleados tiempo adicional para familiarizarse y
aprender a manejarlo antes de tener que emplear en vivo, y a quienes lo desarrollan
les ofrece casos adicionales de prueba y no planificados para evaluar.

Tarea 5.7: Hacer Prueba PiIoto DeI Nuevo Proceso
Esta tarea pone en operacin el nuevo proceso en una rea limitada a fin de identificar
mejoras o correcciones necesarias, sin correr el riesgo de una implantacin total.

Tarea 5.8: Refinamiento Y Transicin
Esta tarea corrige las fallas que se descubran en la operacin piloto e implantando
proceso de una forma controlada, de acuerdo con el plan de lanzamiento desarrollado
En la tarea 5. 3.

Tarea 5.9: Mejora Continua
La mejora de un proceso es continua, no porque se haga en todos los instantes sino
porque se hacen mejoras en todo intervalo de tiempo; pero mejora continua es el
trmino que se emplea en la literatura sobre la materia y es el que nosotros usaremos.
La reingeniera puede convertirse en un programa permanente para algunas
organizaciones porque tienen muchos procesos distintos que redisear, por ejemplo
cuando una empresa se compone de muchas unidades diversas. Y algunas
organizaciones pueden verse en el caso de redisear repetidas veces porque estn en
una industria que encuentra cambios frecuentes, por ejemplo en tecnologa,
reglamentacin o competencia. Pero la mayora de las compaas no deben estar
obligadas a redisear muy a menudo. Para ellas basta con mejora continua.

3.SeIeccin de Herramientas de Reingeniera:
La reingeniera de procesos es un ejercicio de administracin del detalle: del tipo de
actividad que se beneficia con el uso de herramientas automatizadas. Elegir
herramientas de Reingeniera es distinto de la decisin de adquirir el software normal.
Es un proyecto que no es de reingeniera, esperamos que la misma herramienta se
aplique por el mismo personal una y otra vez a lo largo de los aos, y, por
consiguiente, podemos justificar una inversin considerable para adiestrar al personal,
instalar la herramienta y llamar consultores para que las cosas se hagan bien desde el
principio.

4. Beneficios y requisitos de Ias herramientas:
Si vemos la compra de herramientas como una inversin, los beneficios que se
esperan de la eleccin deben superar a los costos esperados dentro del periodo de la
inversin. Como hemos visto, la naturaleza, corta y no repetitiva de los proyectos de
reingeniera nos hacen ver los beneficios y los requisitos de una herramienta desde un
nuevo punto de vista.

NUEVO PUNTO DE VISTA: BENEFICIOS DE LAS HERRAMIENTAS DE
REINGENIERA
- Mejora de productividad.
- Proyectos ms rpidos.
- Ms altos niveles de calidad.
- Eliminacin de trabajo aburrido y, por consiguiente, concentracin en trabajo que
agrega valor.
68
- Si el tiempo que se necesita para aprender a manejar una herramienta en seis meses
o ms, pregntese si esa herramienta es indispensable para el proyecto de
Reingeniera de Procesos; si no descrtela.

NUEVO PUNTO DE VISTA: REQUISITOS DE LAS HERRAMIENTAS DE
REINGENIERA
Las herramientas de reingeniera, deben:
- Ser utilizables por las personas de negocios.
- Generar un rendimiento sobre la inversin.
- ntensificar la calidad de la visin.
- mponer consistencia de diseo.
- Dar refinamiento de arriba hacia abajo.

PLATAFORMAS
La eleccin de una herramienta de ingeniera automatizada implica igualmente la
eleccin de computadores, sistemas operativos y redes de rea local que funcionen
con las herramientas. Si las herramientas deseadas no funcionan en una plataforma
que ya esta disponible en la compaa, entonces el equipo de reingeniera tendr que
adquirir y operar el mismo una plataforma. Estas consideraciones sealan una
diferencia muy importante entre la decisin sobre herramientas de reingeniera y la
decisin sobre plataforma. Mientras que la decisin sobre herramientas tiene que ver
con una ventana de rendimiento sobre inversin de un ao, la decisin sobre
plataforma tiene que ver con una ventana de RS de tres a cinco aos. Obviamente las
herramientas de reingeniera tienen que funcionar sobre alguna cosa, de manera que
cualquier conflicto entre elecciones de plataforma y de herramientas tiene que
resolverse. Como el caso de seleccin de herramientas para la era de el desarrollo de
una estrategia para la seleccin de plataforma se gua por las cuestiones pertinentes.

NUEVO PUNTO DE VISTA: LA INTEGRACIN COMO PORCIN DOMINANTE
Las cuestiones que hay que tener en cuenta al seleccionar la plataforma de
reingeniera son:
- Productividad.
- Costo beneficio.
- Compatibilidad con normas actuales.
- Compatibilidad con normas futuras.
- Amplia disponibilidad herramientas alternas.
La integracin afecta directamente a la productividad al facilitar los vnculos entre
usuarios y procesos. Estos enlaces a grandes mejoran directamente los tiempos de
procesamiento y disponibilidad de informacin. A tareas manera de mejorar la
productividad, pero la integracin la mejora mediante normas que aseguran que
distintos herramientas operen toda en la misma forma compatible.

NUEVO PUNTO DE VISTA: ESTRATEGIA DE SELECCIN DE PLATAFORMA
Primero, el beneficio que se busca de las herramientas de reingeniera proviene del
software. Segundo, salud en ambientes de computadores grandes y mini
computadores, la eleccin de sabor ser el impulsor de cost en la decisin sobre
seleccin de herramientas. Es de presumir que un corto de reingeniera no elegir una
plataforma de computadores grandes, a menos que ste se halle instalado en la
compaa, pero an as, la inversin software para herramientas de reingeniera puede
ser superior a partir inversin instrumental en hardware.

69
ALTERNATIVAS DE PLATAFORMA
En la prctica, las soluciones disponibles para un equipo de R. P. son mucho ms
limitadas que lo que podra parecer a primera vista. Muchos tipos de plataforma que
seran aceptables tienen que limitarse por naturaleza de la tecnologa que emplea. En
primer lugar, es muy poco probable que los beneficios esperados de una herramienta
sean tan grandes que justifiquen la compra de grandes computadores o mini
computadores. En segundo lugar, los sistemas operativos Unix son manejados
generalmente por estaciones de mandos de ingeniera, razn por la cual las personas
de negocios requieren mucho entrenamiento para poder usar estos sistemas. Por un
proceso de eliminacin, hemos llegado an con un tomo reducido de elecciones de
plataforma. Lgicamente, este conjunto reducido es el que se encuentra ms
comnmente joyeros negocios: los computadores personales. Esta versin nos deja
todava con varios detalles de plataforma por decidir, incluso:
- Computadora personal tipo husped.
- Sistemas operativos: dos, Windows, os/2.

COSTO GLOBAL DE LA HERRAMIENTA:
Cmo se ha dicho arriba, la eleccin de herramientas es ante todo una cuestin de los
beneficios desesperan por un costo determinado. Eleccin de herramientas se
incluyen:
- Curva de aprendizaje.
- ntegracin.
- Expectacin de costos durante la vida de la herramienta.

CONTRA DE APRENDIZAJE
Al estimar el costo probable de una herramienta, es indispensable que sea realista la
expectativa sobre lo que costar aprender a manejarla. La experiencia de otros, ojal
con la misma herramientas que uno est considerando, le puede decir mucho sobre lo
que puede esperar. Si no se encuentra usuarios de la misma herramientas, deben
buscarse usuarios de herramientas similares.

INTEGRACIN
La automatizacin de la Reingeniera de Procesos requieren ms de una herramienta.
Cada herramienta se orienta a una especialidad, pero la reingeniera es
inherentemente una actividad de mltiples especialidades. Como se necesitan
mltiples herramientas, es preciso tener alguna manera de integrarlas. Por integrar
queremos decir utilizar la informacin de salida de una herramienta costo insumo para
otra: aprovechar el resultado del anlisis del proceso, insumo para las herramientas
remodelacin. La informacin de salida de las herramientas de reingeniera tienen
tambin integrarse en los documentos de procesamiento de palabras.

5. HERRAMIENTAS DE GERENCIA DE PROYECTO
Las herramientas de gerencia de proyecto desempean dos papeles principales en la
automatizacin de Reingeniera de Procesos el papel obvio es apoyar la planificacin y
la operacin del proyecto. Pero otro papel que no es obvio esta en el anlisis de
proceso y en remodelacin. Este uso de herramientas de la GP como un reemplazo
para todo de CASE es importante porque es una respuesta eficaz y no costosa al alto
costo de aprendizaje de CASE.

Diez preceptos para eI xito
1. Empezar con los procesos estratgicos de valor agregado, es decir, los que son
crticos para sus clientes y su estrategia comercial.
2. Atender igualmente a los procesos de sustentacin.
3. Pensar en incorporar tecnologa informtica en los servicios bsicos de valor
agregado.
70
4. Repensar las fronteras entre sus procesos y los de sus proveedores y clientes.
5. Analizar las opciones de ejecutar ciertas funciones internamente o con terceros.
6. Repensar los beneficios de la descentralizacin en contraposicin a
descentralizacin.
7. Pensar en sedimentar insumo y crear sus logros paralelos de proceso.
8. Notificar el orden en que se llevan a cabo una ciertas actividades donde esto sea
posible, para eliminar la necesidad de subprocesos separados.
9. Repensar por controles.
10. Simplificar interfases y corrientes de informacin.

71

LECTURAS COMPEMENTARIAS.

Tienen la finalidad de que el estudiante pueda consultar informacin ms actualiada

- MPS y otra informacin relacionada con la calidad est disponible en la
Sociedad Americana para la calidad en www.asq.org
- Se puede obtener informacin completa sobre los puntos de funcin en:
www.ifpug.org
- Se puede encontrar una lista til de preguntas realizadas con frecuencia
sobre los puntos de funcin (y los puntos de funcin extendidos) en:
http://ourworId-compuserve.com/homepages/softcomp/
- Se puede encontrar una excelente fuente de informacin sobre la calidad
del software y temas relacionados (incluyendo mtricas) en:
www.quaIityworId.com
- Se puede descargar una gua para la medicin del software orientado a
objetivos desde: www.sei.cmu.edu

72

BIBLIOGRAFA

AUTOR

OBRA

LUGAR DE EDIC.

EDITORIAL

AO

Pressman Roger S.

ngeniera de Software
Un Enfoque Prctico

Quinta Edicin
nteramericana
de Espaa, S.A.U.

McGraw -
Hill
2002

Pressman Roger S.

ngeniera de Software
Un Enfoque Prctico

Cuarta Edicin
nteramericana
de Espaa, S.A.U.

McGraw -
Hill
2002

Sodhi, Jag

Software Engineering
Methods Management
and
CASE

McGraw
Hill
1991

Sommerville

Software Engineering

McGraw
Hill
1997
R. Hammer 'Reingeneira. Grupo
Editorial
NORMAl
2000
R. Pressman 'Can Internet-Based
Applications Be
Engineered? IEEE
SoItware
September/October
1998.
pag 104 110.

73
GLOSARIO
Significado
ACTVDAD Los procedimientos necesarios para implementar
un rea clave de proceso. Comprende el
establecimiento de planes y procedimientos, la
ejecucin del trabajo, el seguimiento del mismo, el
control de las salidas del proceso, y las acciones
correctivas que deben tomarse segn sea
necesario.
ACTUAR Etapa del ciclo DEAL en que se introducen o
mejoran los procesos (e.g. modelamiento,
introduccin de nuevas metodologa, etc.), se
entrena a los respectivos niveles de personal, se
miden los avances/beneficios logrados, se realizan
proyectos pilotos, se implanta los procesos
mejorados en los proyectos nuevos o existentes,
se hacen mini-evaluaciones para constatar la
evolucin del plan, etc.
AREA DE PROCESO CLAVE dentifica una agrupacin de actividades y
prcticas relacionadas, las cuales cuando son
realizadas en forma colectiva permiten lograr
alcanzar las metas fundamentales del proceso.
Pueden clasificarse en 3 tipos de proceso: Gestin,
Organizacional e ngeniera
ANLSS DE REQUSTOS Proceso de estudio de las necesidades del usuario
para conseguir una definicin de los requisitos del
sistema o del software
CAPACDAD DE REALZACN Describe las condiciones previas que debe existir
en el proyecto o la organizacin para poder aplicar
el proceso de software en forma efectiva.
Normalmente enfocan los recursos, las estructuras
de la organizacin, el entrenamiento y las
condiciones previas que deben existir
CARACTERSTCA COMN Atributos que indican si la implementatcin y la
institucionalizacin de un proceso clave es
efectivo, repetible y duradero
CCLO DE VDA DEL
SOFTWARE
El conjunto de procesos sistemticos que tienen
lugar durante la existencia del producto, desde su
concepcin inicial hasta que la organizacin decide
no continuar mantenindolo
COMT DE CONTROL DE LA
CONFGURACN DEL
SOFTWARE
Grupo representativo de los distintos
departamentos que tiene autoridad para decidir los
componentes de cada una de las versiones del
producto de software, as como autorizar su
entrega a los clientes
74
COMPROMSO DE
REALZACN
El compromiso para realizacin describe las
acciones que la organizacin debe tomar para
asegurar que el proceso se establezca y sea
permanente. Normalmente abarcan el
establecimiento de polticas y liderazgo a nivel de
la organizacin
CMM Siglas de "Capability Maturity Model, modelo
desarrollado por SE (Software Engineering
nstitute) en 1990, para la evaluacin y mejora de
los procesos. El primer modelo desarrollado para
evaluar y mejorar los procesos fue el SW-CMM,
por lo que muchas veces se hace referencia a el
coloquialmente como "CMM. En la actualidad los
modelos de evaluacin y mejora desarrollados y
mantenidos por SE son: P-CMM (People
Capability Maturity Model), SA-CMM (Software
Acquisition Capability Maturity Model). Con la
aparicin en 2001 de los modelos CMM, SE ha
dejado de mantener desde finales de 2004 los
siguientes modelos CMM, por haberse integrado
en los nuevos CMM: SW-CMM (Capability
Maturity Model for Software), SE-CMM (Systems
Engineering Capability Maturity Model), PD-CMM
(ntegrated Product Development Maturity Model).

CMM Siglas de "Capability Maturity Model ntegration,
modelos desarrollados por SE que integran varias
disciplinas: Desarrollo de software, ngeniera de
sistemas, ntegracin de productos y procesos de
desarrollo.
COCOMO Constructive Cost Model. Modelo constructivo de
costes, desarrollado por B.W. Boehm a finales de
los 70, y expuesto en su libro "Software
Engineering Economics. Es una jerarqua de
modelos de estimacin de costes que incluye los
sub-modelos: bsico, intermedio y detallado.
CPM Mtodo para el control y la optimizacin de los
costes de operacin mediante la planificacin
adecuada de las actividades que componen un
proyecto. Fue desarrollado en 1957 en los Estados
Unidos por un centro de investigacin de
operaciones para la firma Dupont y Remington
Rand. Actualmente se utilizan sus principios en
combinacin con los del mtodo PERT en lo que
se conoce como PERT/CPM.
CRSS DEL SOFTWARE Trmino acuado en 1968, en la primera
conferencia de la OTAN sobre desarrollo de
software, con el que se identificaron los problemas
que surgan en el desarrollo de sistemas de
75
software.
DEBLDAD, OPORTUNDAD
PARA MEJORAR
Desviacin o implementacin insuficiente de
prcticas de ingeniera de software en la
organizacin
DAGNOSTCAR Etapa del ciclo DEAL en que se evala mediante
un mtodo formal las fortalezas y debilidades del
proceso seguido por los proyectos
DFUNDR Etapa del ciclo DEAL en que se aprende de la
experiencia del ciclo recin realizado y aumentar la
habilidad de la empresa u organizacin para
mejorar los procesos en forma continua
DESCRPCON DEL SSTEMA Documento orientado al cliente que describe las
caractersticas del sistema desde el punto de vista
del usuario final. El documento se utiliza para
coordinar conjuntamente los objetivos del sistema
del usuario, cliente, desarrollador e intermediarios
DSEO DETALLADO Proceso de definicin y ampliacin del diseo
preliminar de un sistema o de un componente
hasta un grado de detalle suficiente para llevar a
cabo la implementacin.
ESTABLECER Etapa del ciclo DEAL en que se realiza la
planificacin especfica de los mejoramientos que
se desea alcanzar
EVALUACN Es la determinacin de la manera en que las
prcticas de ingeniera de software han sido
implementadas por la organizacin, habitualmente
usando el CMM como referencia. Puede ser
realizada por evaluadores externos o internos,
dependiendo si el propsito es determinar
competencia o mejorar internamente
EVALUACN DE LA
CAPACDAD DEL SOFTWARE
Mtodo de evaluacin creado por el SE para
evaluar la capacidad de procesos de una
compaa mediante un equipo de evaluadores
externos (se usa habitualmente para seleccionar o
supervisar subcontratistas
EVALUACN DEL PROCESO
DE SOFTWARE BASADA EN EL
CMM PARA MEJORAMENTO
NTERNO DEL PROCESO (CBA-
P)
Mtodo de evaluacin creado por el SE para
evaluar la capacidad de procesos de una
organizacin mediante un equipo de evaluadores
internos dirigidos por un asesor Lder CBA-P
debidamente autorizado por el SE
ESPECFCACONES DE LOS
REQUSTOS DEL SOFTWARE
Documentacin de requisitos fundamentales
(necesarios, esenciales e indispensables) de
funcionalidades, rendimiento, restricciones y
atributos del software, y sus interfaces externas.
76
GARANTA DE CALDAD DEL
SOFTWARE

GESTN DE LA
CONFGURACN
Disciplina que aplica la direccin y supervisin
tcnica y administrativa para: identificar y
documentar las caractersticas funcionales y fsicas
de un elemento de configuracin, controlar
cambios, registrar cambios procesados, registrar el
estado de la implementacin, informar y verificar la
conformidad con los requisitos especificados.
GRUPO DE NGENERA DE
SOFTWARE
Es el equipo de profesionales y gestionarios que
posee la competencia y experiencia necesaria para
crear o mantener productos de software.
Comprende analistas, arquitectos, programadores,
personal de pruebas, etc.
GRUPO DE PROCESO DE
NGENERA DE SOFTWARE
Grupo altamente calificado responsable por
introducir, gestionar y dirigir el proyecto de
mejoramiento de procesos en la organizacin
MPLANTACN
MPLEMENTACN
Adopcin y utilizacin de una prctica de ingeniera
de software en los proyectos u organizacin
NCAR Etapa del ciclo DEAL en que se establecen los
fundamentos bsicos para garantizar que la
iniciativa de mejoramiento de procesos.
NSTTUCONALZACN El uso generalizado de un proceso a lo largo de los
proyectos. Comprende la documentacin de dicho
proceso, el entrenamiento, la medicin de su
eficacia y su evolucin (mantenimiento)
NGENERA DE SOFTWARE Aplicacin de procesos sistemticos y
disciplinados para el desarrollo, operacin y
mantenimiento de software.
NTERFAZ DE USUARO nterfaz que permite la comunicacin entre un
usuario y un sistema, o los componentes de un
sistema.
LDER DE EVALUACN
AUTORZADO
Un CBA-P Lead Assessor debidamente calificado
por el SE para dirigir al equipo que realizar la
evaluacin de procesos
MANTENMENTO Proceso de corregir problemas y agregar nuevas
capacidades a un programa de software despus
de su entrega a los usuarios
MEDCN Valor que indica el rendimiento de un proceso
MEDCN Y ANLSS Describen la necesidad de medir el proceso y
analizar las mediciones resultantes
77
MEJORAMENTO Evolucin del proceso para hacerlo ms eficiente
para satisfacer las necesidades de la empresa y
los individuos que lo utilizan
MEJORAMENTO NTERNO DEL
PROCESO
Proyecto emprendido por la organizacin para
incorporar nuevos procesos o hacer ms eficaces
los existentes, a objeto de aumentar su capacidad
para producir software
MEMBRO DEL EQUPO DE
EVALUACN
Personal experimentado de la organizacin,
debidamente entrenado, que realiza la evaluacin
de los procesos bajo la direccin de un asesor lder
CBA-P
MODELO DE MADUREZ DE
CAPACDADES
Conjunto de prcticas de ingeniera de software
recomendadas por el SE-CMU en la versin 1.1
del SW-CMM
PATROCNADOR Ejecutivos de la gerencia superior que apadrinan la
iniciativa de mejoramiento (o la evaluacin CBA-
P) y que tienen la capacidad de proveer los
recursos necesarios para su ejecucin
PLAN DE ACCN Es el plan que identifica las actividades del
proyecto de mejoramiento de procesos. dentifica
recursos, entrenamiento, calendarios, riesgos, etc.
PERT Mtodo para el control de los tiempos de ejecucin
de diversas actividades integrantes de proyectos.
Fue desarrollado en 1957 por la armada de los
Estados Unidos. Actualmente se utilizan sus
principios en combinacin con los del mtodo CPM
en lo que se conoce como PERT/CPM
RUP Ver Rational Unified Process
SQA Se aplica a lo procesos o a las funciones
encaminadas a garantizar que la organizacin
realiza el trabajo de desarrollo, operacin o
mantenimiento de software conforme a los
procedimientos y mtodos establecidos para el
proyecto.
UML Segn sus creadores, UML (Lenguaje Unificado de
Modelado) es un lenguaje grfico para visualizar,
especificar, construir y documentar los
componentes de un sistema software. UML
permite tanto la especificacin conceptual de un
sistema como la especificacin de elementos
concretos, como pueden ser las clases o un diseo
de base de datos.
VERFCACON Y VALDACON Proceso que determina si los requisitos de un
sistema o de un componente son completos y
78
correctos, si los productos de cada fase cumplen
los requisitos o condiciones marcados al inicio de
la fase y si el sistema o componente final cumple
con los requisitos especificados.

154

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

154

Caricato da

Copyright:

Formati disponibili

UNVERSDAD SALESANA DE BOLVA DOCENTE: LC.

ZARA YUJRA CAMA

CONCEPTOS SOBRE GESTION DE PROYECTOS

UNVERSDAD SALESANA DE BOLVA DOCENTE: LC. ZARA YUJRA CAMA

UNVERSDAD SALESANA DE BOLVA DOCENTE: LC. ZARA YUJRA CAMA

Potrebbero piacerti anche