Modelando Una Solución de Software

2 JUAN BRAVO C.
Estimado lector:
Hemos visto cmo este libro agrega valor para la humanidad a travs del
conocimiento que aporta, por lo tanto, con mucho agrado empleo tambin
este medio digital.
Esta es una versin completa y actualizada del libro en 2009, sin costo du-
rante este ao como forma de contribuir en la solucin de la crisis que nos
afecta a nivel mundial.
La serie de libros aporta motivacin, conceptos, tcnicas y herramientas que
han probado ser efectivas en cientos de casos narrados en los mismos textos.
Observar que grandes avances fueron logrados justamente en alguna otra
crisis. Esas soluciones tuvieron siempre, al menos, algo de conocimiento y
una dosis de esfuerzo personal sereno, responsable y con fe.
Le saluda cordialmente,
Juan Bravo C.
Doctor por la Universidad de Lleida
Presidente Evolucin Centro de Estudios Avanzados
www.evolucion.cl
PD1. Pueden bajar presentaciones de apoyo en Modelos de la Gestin de
Procesos y la revista RS, sin costo ni claves.
MODELANDO UNA SOLUCIN DE SOFTWARE 3
Modelando
una Solucin
de Software
Juan Bravo Carrasco

4 JUAN BRAVO C.
JUAN BRAVO CARRASCO, 2008

Inscripcin N 169.936 del 24 de marzo de 2008
I.S.B.N.: 978-956-7604-15-9 del 24 de marzo de 2008
Derechos reservados, jbravo@vtr.net
Edicin revisada y actualizada en mayo de 2009
Valor versin digital: $ 5.000 (Chile) US$ 7 (sin costo en 2009)

Puede complementar bajando los Modelos de la Gestin de Procesos y la Re-
vista de Responsabilidad social (www.evolucion.cl).
EDITORIAL EVOLUCIN S.A.

www.evolucion.cl, info@evolucion.cl
Alameda 171 Of. 307, Fono 6389717
Santiago de Chile
A todos los profesionales de la tecnologa que se esfuerzan cada da por

trabajar metodolgica y ticamente.
6 JUAN BRAVO C.
CONTENIDO
CONTENIDO ............................................................................................................................... 6
TABLA DE ILUSTRACIONES ...................................................................................................... 12
PRLOGO ................................................................................................................................. 14
AGRADECIMIENTOS ................................................................................................................. 22
INTRODUCCIN ........................................................................................................................ 24
Contenido del libro .......................................................................................................... 25
Sntesis de modelos de una solucin de software ............................................................ 26
CAPTULO 1. MTODO PARA LA GESTIN DE PROYECTOS............................... 34
1.1. TRABAJAR METODOLGICAMENTE................................................................................... 36
1. Qu es mtodo?.......................................................................................................... 36
2. Las mejores prcticas .................................................................................................. 37
3. Fundamento conceptual: la visin sistmica ............................................................... 37
4. Mtodo GSP ................................................................................................................. 39
1.2. CLAVES DE LA IMPLANTACIN DE MTODO....................................................................... 41
Clave 1. Cinco mapas globales para la visin de conjunto ............................................. 41
Clave 2. Mnimo indispensable ........................................................................................ 47
Clave 3. Participacin de todos los actores .................................................................... 47
Clave 4. Circularidad ...................................................................................................... 48
1.3. ADAPTACIN Y PROFESIONALISMO ................................................................................... 49
1. Adhesin a estndares y normas de calidad ................................................................ 49
2. Actualizacin y adaptabilidad del mtodo................................................................... 50
3. Estructura para la gestin de proyectos ...................................................................... 53
4. Aportes del PMI ........................................................................................................... 55
5. tica y visin global del profesional ........................................................................... 56
1.4. ETAPAS GENRICAS .......................................................................................................... 58
1. Concepcin .................................................................................................................. 60
2. Factibilidad ................................................................................................................. 62
3. Anlisis ........................................................................................................................ 65
4. Diseo .......................................................................................................................... 71
5. Implementacin............................................................................................................ 73
6. Despliegue ................................................................................................................... 76
7. Operacin .................................................................................................................... 78
1.5. PRCTICAS TRANSVERSALES ............................................................................................ 82
1. Direccin del proyecto................................................................................................. 84
2. Plan de la etapa ........................................................................................................... 86
3. Exposicin de los planes .............................................................................................. 87
4. Retroalimentacin........................................................................................................ 87
5. El equipo de trabajo .................................................................................................... 87
6. Entrevistas ................................................................................................................... 88
7. Comunicacin .............................................................................................................. 89
8. Informes ....................................................................................................................... 89
9. Tcnicas ....................................................................................................................... 89
10. Herramientas de apoyo .............................................................................................. 90

11. Trazabilidad............................................................................................................... 90
12. Quick Wins ................................................................................................................. 91
13. Costos y duracin ...................................................................................................... 91
14. Gestin de riesgos...................................................................................................... 91
15. Gestin de la calidad ................................................................................................. 92
16. Responsabilidad social .............................................................................................. 92
17. Insercin .................................................................................................................... 93
18. Orientacin al cliente ................................................................................................ 93
19. Sensibilizacin ........................................................................................................... 94
20. Capacitacin .............................................................................................................. 94
21. Seguimiento ............................................................................................................... 94
22. Cuidar la solucin anterior ....................................................................................... 95
23. Continuidad operacional ........................................................................................... 95
24. Plan de recursos fsicos del proyecto ........................................................................ 95
25. Kill time ..................................................................................................................... 96
26. Control de cambios .................................................................................................... 96
27. Gestin del cambio .................................................................................................... 96
28. Gestin de proveedores ............................................................................................. 97
CAPTULO 2. INGENIERA DE SOFTWARE ................................................................ 98
2.1. ALCANCE DE LA INGENIERA DE SOFTWARE ................................................................... 101
1. Definiciones de la ingeniera de software.................................................................. 101
2. Desarrollar un buen software o solucionar el problema? ....................................... 102
3. Esfuerzo de educacin ............................................................................................... 104
4. Tecnologa de informacin ........................................................................................ 106
2.2. PLANIFICACIN EN INFORMTICA ................................................................................... 108
1. Algunas directrices sobre la tecnologa de informacin ........................................... 109
2. Reconversin de la informtica ................................................................................. 111
3. Nuevas formas de organizacin informtica ............................................................. 113
4. Mtodo de planificacin estratgica en informtica ................................................. 116
5. Cambio cultural de la organizacin .......................................................................... 118
6. Resumen de la planificacin estratgica en informtica ........................................... 120
2.3. SISTEMA DE PRODUCTIVIDAD EN EL DESARROLLO DE SOFTWARE .................................. 123
1. Mtodo ....................................................................................................................... 124
2. Tcnicas ..................................................................................................................... 125
3. Herramientas de software .......................................................................................... 125
4. Hardware ................................................................................................................... 126
5. Incorporacin del usuario ......................................................................................... 127
6. Habilidad del desarrollador ...................................................................................... 130
7. Normalizacin externa ............................................................................................... 131
8. Factores de contexto .................................................................................................. 134
2.4. CRITERIOS DE DESARROLLO DE SOFTWARE .................................................................... 135
1. Criterios anticuados de desarrollo de software ......................................................... 135
2. Mitos del desarrollo de software ............................................................................... 138
3. Nuevos principios para el desarrollo de software ..................................................... 139
4. Construir sistemas computacionales sin programar? ............................................. 140
8 JUAN BRAVO C.
5. Pruebas del software por el programador................................................................. 141

6. Mantenimiento de la solucin de software ................................................................ 142
2.5. MTODOS PARA LA PRODUCCIN DE SOFTWARE ............................................................ 145
1. Ciclo de vida clsico .................................................................................................. 145
2. Tcnica de prototipos ................................................................................................ 147
3. Diseo estructurado................................................................................................... 151
4. Programacin extrema (XP) ...................................................................................... 155
2.6. APOYO DEL DISEO EN LA EXPLOTACIN DEL SISTEMA ................................................. 157
1. Operacin del sistema ............................................................................................... 157
2. Auditora computacional ........................................................................................... 159
3. Contribucin del diseo a la proteccin de la informacin ...................................... 162
4. Seguridad de la informacin ..................................................................................... 163
5. Integridad de la informacin ..................................................................................... 164
6. Recuperacin de la informacin ................................................................................ 165
2.7. DISEO DE INTERFACES .................................................................................................. 166
1. Directrices para el diseo de interfaces humanas ..................................................... 166
2. Diseo de niveles de mens ....................................................................................... 167
3. Leyes para lograr una mejor interfaz humana .......................................................... 168
2.8. NORMAS Y ESTNDARES APLICADOS A LOS MODELOS TI .............................................. 170
1. Corba ......................................................................................................................... 171
2. MDA........................................................................................................................... 171
3. CMM .......................................................................................................................... 172
4. ISO 9000 .................................................................................................................... 173
5. Tick IT ........................................................................................................................ 173
6. ITIL ............................................................................................................................ 174
7. SOA ............................................................................................................................ 175
CAPTULO 3. TEORA DE MODELOS APLICADA ................................................... 176
3.1. MARCO TERICO DE LOS MODELOS ............................................................................... 178
1. Concepto de caja negra ............................................................................................. 178
2. Concepto de homomorfismo ...................................................................................... 179
3.2. MODOS DE PROCESAMIENTO .......................................................................................... 182
1. Batch-Interactivo ....................................................................................................... 183
2. En lnea ...................................................................................................................... 183
3. En tiempo real............................................................................................................ 184
3.3. ONCE CLAVES DE LOS MODELOS COMPUTACIONALES.................................................... 185
1. Fluidez ....................................................................................................................... 185
2. Intuicin ..................................................................................................................... 186
3. Simplicidad ................................................................................................................ 187
4. Orientacin al cliente ................................................................................................ 187
5. Independencia de la implementacin tecnolgica ..................................................... 188
6. Iteracin..................................................................................................................... 188
7. Totalidad .................................................................................................................... 189
8. Generalizacin ........................................................................................................... 189
9. Desarrollo incremental .............................................................................................. 190
10. Transacciones presentes .......................................................................................... 190
11. Armona entre el modelo y la realidad .................................................................... 191
3.4. MODELAMIENTO DE FUNCIONES ..................................................................................... 193

1. Descomposicin funcional ......................................................................................... 193
2. Reglas del negocio ..................................................................................................... 195
3. Funciones asociadas a una entidad ........................................................................... 196
4. Relaciones funcionales entre dos entidades .............................................................. 198
3.5. FUNDAMENTOS DEL MODELAMIENTO DE FUNCIONES ..................................................... 201
1. Resolucin de problemas simples .............................................................................. 201
2. Modelar bien a la primera ......................................................................................... 202
3. Concepto de mquinas abstractas ............................................................................. 202
3.6. CRITERIO CURSO NORMAL DE LOS EVENTOS .................................................................. 205
1. Aplicado al flujograma de informacin ..................................................................... 205
2. Relacin del FI con la tcnica UML .......................................................................... 212
CAPTULO 4. MODELAMIENTO DE DATOS ............................................................. 214
4.1. DEFINICIONES SOBRE EL MODELO DE DATOS ................................................................. 216
1. Representacin de una entidad .................................................................................. 216
2. Relaciones propias (RP) ............................................................................................ 217
3. Caractersticas estticas y funcionales de campos .................................................... 218
4. Tipos de entidades ..................................................................................................... 220
5. Relaciones entre entidades ........................................................................................ 222
4.2. CRITERIOS BSICOS DE NORMALIZACIN DE DATOS ...................................................... 227
1. Eliminacin de grupos repetitivos ............................................................................. 228
2. Eliminacin de dependencias parciales..................................................................... 230
3. Tabla de traduccin ................................................................................................... 233
4.3. ENFOQUE DE BASES DE DATOS ....................................................................................... 235
1. Arquitectura de sistemas de bases de datos ............................................................... 235
2. Estructura relacional ................................................................................................. 236
3. Visin de bases de datos ............................................................................................ 238
4. Elementos del enfoque de bases de datos .................................................................. 240
CAPTULO 5. ORIENTACIN A OBJETOS ................................................................ 243
5.1. FUNDAMENTOS DE LA ORIENTACIN A OBJETOS ............................................................ 246
1. Mayor eficiencia ........................................................................................................ 247
2. Visin de los datos ..................................................................................................... 248
3. Visin histrica funcional .......................................................................................... 249
4. La orientacin a objetos ............................................................................................ 251
5. Incorporacin de nuevas tecnologas ........................................................................ 252
5.2. DEFINICIONES SOBRE ORIENTACIN A OBJETOS ............................................................. 255
1. Definiciones preliminares .......................................................................................... 255
2. Convenciones de diseo ............................................................................................. 257
3. Relacin de pertenencia ............................................................................................ 258
4. Condicin de existencia ............................................................................................. 259
5.3. CONCEPTOS DE LA ORIENTACIN A OBJETOS ................................................................. 261
1. Encapsulamiento........................................................................................................ 261
2. Clase .......................................................................................................................... 262
3. Objeto ........................................................................................................................ 263
4. Funcin ...................................................................................................................... 265
10 JUAN BRAVO C.
5. Identidad de instancias de objetos ............................................................................. 265

6. Mensaje ...................................................................................................................... 266
7. Independencia ............................................................................................................ 267
8. Enfoque sistmico ...................................................................................................... 268
5.4. PROCESO DE GENERALIZACIN ...................................................................................... 269
1. Obtencin de clases ................................................................................................... 269
2. Herencia .................................................................................................................... 272
5.5. FASES DE LA ORIENTACIN A OBJETOS........................................................................... 274
1. Modelamiento de la informacin ............................................................................... 274
2. Identificacin de clases.............................................................................................. 275
3. Visin externa ............................................................................................................ 276
4. Visin interna............................................................................................................. 279
5. Interfaz humana ......................................................................................................... 282
5.6. INCORPORACIN DE LA TECNOLOGA DE OBJETOS ......................................................... 283
1. Personalizacin del objeto......................................................................................... 283
2. Reutilizacin de cdigo.............................................................................................. 284
3. Construccin de un modelo de objetos ...................................................................... 285
CAPTULO 6. UNIFIED MODELING LANGUAGE (UML) ....................................... 287
6.1. MODELOS DE UML......................................................................................................... 290
1. Casos de uso .............................................................................................................. 291
2. Uso de herramientas .................................................................................................. 292
6.2. APLICACIN DE LOS MODELOS UML EN LA ETAPA DE ANLISIS .................................... 293
1. Diagrama de casos de uso ......................................................................................... 293
2. Caso de uso de alto nivel ........................................................................................... 295
3. Caso de uso expandido .............................................................................................. 295
4. Modelo conceptual..................................................................................................... 297
5. Diagrama de secuencia del sistema ........................................................................... 299
6. Visin dinmica del sistema ...................................................................................... 300
7. Diagrama de estado ................................................................................................... 301
8. Contratos ................................................................................................................... 302
6.3. APLICACIN DE LOS MODELOS UML EN LA ETAPA DE DISEO ...................................... 304
1. Diagrama de diseo de clases ................................................................................... 304
2. Diagrama de colaboracin ........................................................................................ 305
CAPTULO 7. HERRAMIENTAS DE LA TECNOLOGA DE INFORMACIN ..... 306
7.1. EVOLUCIN DE LOS LENGUAJES DE COMPUTADOR ......................................................... 309
1. Lenguajes de mquina ............................................................................................... 312
2. Lenguajes simblicos ................................................................................................. 312
3. Lenguajes de alto nivel .............................................................................................. 313
4. La cuarta generacin de lenguajes ............................................................................ 314
5. Las nuevas herramientas ........................................................................................... 315
7.2. HERRAMIENTAS DE USO ESPECFICO .............................................................................. 318
1. Herramientas integradas para automatizacin de oficinas ....................................... 319
2. Groupware ................................................................................................................. 319
3. Workflow .................................................................................................................... 320
7.3. UNA PIRMIDE DE SOLUCIONES ...................................................................................... 321
1. BI ............................................................................................................................... 321
2. Data Warehouse ........................................................................................................ 322
3. ERP ............................................................................................................................ 322
4. CRM ........................................................................................................................... 322
5. SRM ........................................................................................................................... 323
6. Motor de base de datos .............................................................................................. 323
7.4. HERRAMIENTAS DE APOYO PARA LA PRODUCCIN DE SOFTWARE ................................. 324
1. Herramientas tipo UPPER CASE .................................................................................. 326
2. Herramientas tipo LOWER CASE .................................................................................. 326
3. Herramientas de productividad en ambiente cliente servidor ................................... 329
CONCLUSIONES, ANEXOS Y BIBLIOGRAFA ......................................................... 331
CONCLUSIONES...................................................................................................................... 332
ANEXO 1. INTRODUCCIN A LA PLANIFICACIN ESTRATGICA.............................................. 333
Definicin del negocio ................................................................................................... 334
Destino de la organizacin ............................................................................................ 337
Factores crticos del xito .............................................................................................. 338
Mediciones ..................................................................................................................... 339
Sistemas de informacin gerenciales ............................................................................. 339
ANEXO 2. ALINEAR INTERESES .............................................................................................. 341
ANEXO 3. DESARROLLO EN ESPIRAL DEL PROYECTO ............................................................ 344
ANEXO 4. RELACIN CAUSAL................................................................................................ 346
ANEXO 5. MTODO DE ACCIN RPIDA (MAR) .................................................................... 348
ANEXO 6. AD/CYCLE Y RUP................................................................................................. 349
AD/Cycle ........................................................................................................................ 349
RUP ............................................................................................................................... 350
ANEXO 7. CASO COMPRAS CON UML ................................................................................... 351
BIBLIOGRAFA........................................................................................................................ 371
12 JUAN BRAVO C.
TABLA DE ILUSTRACIONES
Figura 1-1. Totalidad del mtodo GSP 45

Figura 1-2. Mapa de necesidades con problemas y soluciones 47
Figura 1-3. Mapa de proyectos con relaciones para reubicar personas 48
Figura 1-4. Mapa de procesos de Fabrica de Electrodomsticos Linhogar 49
Figura 1-5. Mapa de retroalimentacin para replicar o evitar 50
Figura 1-6. Mapa de Sistemas Computacionales 51
Figura 1-7. Adaptacin del mtodo a cada tipo de proyecto 57
Figura 1-8. Esfuerzo estimado por etapa en el mtodo GSP 63
Figura 1-9. El modelo de negocios como una mesa 70
Figura 1-10. Mapa de procesos 72
Figura 1-11. Flujograma de informacin 74
Figura 1-12. Diseo general de la interfaz 76
Figura 1-13. Flujograma de informacin de control de cambios 85
Figura 2-1. Clasificacin de materias para perfeccionamiento en TI 111
Figura 2-2. Reconversin de programadores 119
Figura 2-3. Planificacin estratgica en informtica 122
Figura 2-4. Armona entre tcnica y comunicacin 137
Figura 2-5. Tabla comparativa para disminuir tiempo de respuesta 143
Figura 2-6. Ejemplo de grosor de la piel de las cras de osos 155
Figura 2-7. Ejemplo de diagrama de contexto 158
Figura 2-8. Estructura general de un D. F. D. 159
Figura 2-9. Ejemplo de D. F. D. nivelado 159
Figura 2-10. Definicin de mens como una clase 174
Figura 3-1. Concepto de caja negra 186
Figura 3-2. Modelo orientado al objetivo principal del sistema 187
Figura 3-3. Modelo orientado a los datos 188
Figura 3-4. Modelo orientado a las funciones del sistema 188
Figura 3-5. Modelo orientado al flujo de transacciones 189
Figura 3-6. Infinitas visiones de una realidad 189
Figura 3-7. Las tres dimensiones del diseo 190
Figura 3-8. Esquema de aproximaciones sucesivas 197
Figura 3-9. Concepto de descomposicin funcional 202
Figura 3-10. Ejemplo de relaciones funcionales 204
Figura 3-11. Esquema de una actualizacin 206
Figura 3-12. Esquema de una extraccin 207
Figura 3-13. Esquema de una seleccin 207
Figura 3-14. Esquema de una mantencin 208
Figura 3-15. Ejemplo de flujograma de informacin despacho inmediato 214
Figura 3-16. Diagrama de flujo computacional 217
Figura 3-17. Relacin del FI con la tcnica UML 220
Figura 4-1. Componentes de una entidad 226
Figura 4-2. Representacin grfica de una entidad 227
Figura 4-3. Eliminacin de grupo repetitivo usando nmero correlativo externo 238
Figura 4-4. Eliminacin de grupo repetitivo usando campo interno 239

Figura 4-5. Ejemplo de eliminacin de dependencias parciales 241
Figura 4-6. Arquitectura de bases de datos 245
Figura 4-7. Enfoque de bases de datos 250
Figura 5-1. Interacciones entre objetos 258
Figura 5-2. Esquema tradicional de diseo 260
Figura 5-3. Ejemplo de relaciones funcionales estructuradas 262
Figura 5-4. Ejemplo de orientacin a objetos 262
Figura 5-5. Grfico de incorporacin de nuevas tecnologas 263
Figura 5-6. Nomenclatura de la orientacin a objetos 266
Figura 5-7. Relacin de pertenencia 269
Figura 5-8. Representacin de un objeto 275
Figura 5-9. Ejemplo de estructura de un mensaje 277
Figura 5-10. Ejemplo de transacciones de sueldos con objetos 281
Figura 5-11. Ejemplo de definir una clase de transacciones de sueldos 281
Figura 5-12. Diagrama final de la generalizacin 282
Figura 5-13. Ejemplo de herencia en un sistema de ventas 283
Figura 5-14. Herencia mltiple 284
Figura 5-15. Modelo de datos simplificado de inventarios 286
Figura 5-16. Modelo de datos generalizado 287
Figura 5-17. Modelo funcional generalizado 287
Figura 5-18. Modelo funcional generalizado y detallado 289
Figura 5-19. Visin interna de la clase productos 291
Figura 5-20. Visin interna de la clase ingreso de transaccin 292
Figura 6-1. Ejemplo de un caso de uso de alto nivel 304
Figura 6-2. Ejemplo de un diagrama de casos de uso 307
Figura 6-3. Caso de uso de alto nivel Ingresar orden de compra 308
Figura 6-4. Caso de uso de expandido Ingresar orden de compra 309
Figura 6-5. Ejemplo de Interfaz visual detallada 310
Figura 6-6. Ejemplo de modelo conceptual sistema de compras 311
Figura 6-7. Ejemplo de modelo conceptual con atributos 312
Figura 6-8. Ejemplo de diagrama de secuencia 313
Figura 6-9. Ejemplo de diagrama visin dinmica del sistema 314
Figura 6-10. Ejemplo de diagrama de estado 315
Figura 6-11. Forma de un contrato por operacin 316
Figura 6-12. Ejemplo de contrato en dar OK ingreso lnea 316
Figura 6-13. Ejemplo de diagrama de diseo de clases 317
Figura 6-14. Ejemplo de diagrama de colaboracin 318
Figura 7-1. Clasificacin de lenguajes de computador 325
Figura 7-2. Una pirmide de soluciones 335
Figura 7-3. Herramientas Upper CASE y Lower CASE 340
Figura A1-1. Esquema de planificacin estratgica 349
Figura A4-1. Ejemplo de grfico de Ishikawa 362
14 JUAN BRAVO C.
PRLOGO
La presin irrazonable en la planificacin puede hacer que los

desarrolladores pierdan el respeto a sus directivos. La mayora
de las personas se sentirn contentas con los resultados de un
proyecto planificado con precisin.
McCONNELL (1997, pp. 237-8)
Este libro responde a una bsqueda de lograr mayor productividad en las orga-
nizaciones de Latinoamrica, en una intensa investigacin acerca de las mejores
prcticas para modelar buenas soluciones de software. Lo destaco porque la
serie de modelos de anlisis y diseo efectivamente debe dar solucin a una
necesidad bien comprendida y evaluada, todo ello en el contexto de aplicar un
mtodo completo para la gestin del proyecto.
Es importante, no slo por el imperativo de trabajar con calidad sino que tam-
bin como una forma de crear riqueza en toda la sociedad a travs de la transfe-
rencia de conocimiento. En su reconocido1 libro Globalizacin para el desarro-
llo, Goldin y Reinert sealan (2007, p. 344): La transferencia global de ideas en
forma de tecnologa es uno de los procesos de desarrollo ms importantes. Du-
rante dcadas, el abismo en aparente crecimiento entre los pases desarrollados y
los pases en desarrollo ha despertado inquietudes acerca de una brecha tec-
nolgica. En aos recientes, los pases en desarrollo lderes como Brasil, China,
India y Sudfrica han demostrado que pueden no slo salvarla, sino tambin
ponerse en la delantera en algunas reas puntuales. Debido en parte a estos ade-
lantos, los pases en desarrollo buscan entre s las ideas y la colaboracin.
Hemos aprendido que se puede hacer lo que es debido para salir del subdesarro-
llo, ya sea aplicar calidad, aprender a modelar un software o trabajar con mto-
do. Lo importante es que podemos lograrlo.
El contenido de este libro se sustenta en varios pilares:
Las buenas ideas del medio nacional e internacional recogidas a travs de
mltiples lecturas, en congresos, seminarios y formacin de postgrado en
Chile y el exterior.
Los cursos sobre anlisis y diseo que he dictado a alumnos y profesionales
en la Universidad de Chile, Universidad Catlica y Universidad Tcnica Fe-
1
Entre otras personalidades, el libro es presentado por los Premios Nobel de Economa Jo-
seph Stiglitz y Amartya Sen.
derico Santa Mara, adems de talleres en muchas empresas desde hace ya

dos dcadas.
En mi experiencia como desarrollador de varios cientos de sistemas compu-
tacionales destinados a diferentes organizaciones, ensayando variadas formas
de diseo y construccin, propias y normalizadas; incluso, constru una
herramienta CASE a fines de los 80s.
En relacin al desarrollo de software, mi propia evolucin se fue orientando
desde el perfeccionamiento de mtodos tradicionales, reflejados en el libro De-
sarrollo de sistemas de informacin, una visin prctica, publicado a fines de la
dcada de los 80, hacia la bsqueda de frmulas cada vez ms productivas, co-
mo el mtodo de cuarta generacin y el modelamiento de datos y funciones,
expuestos en revistas especializadas a comienzos de la dcada de los 90. Esos
avances fueron profundizados en el libro Modelamiento de sistemas de informa-
cin. La bsqueda sigui hasta desembocar a mediados de esa dcada en la
orientacin a objetos, una respuesta natural, productiva, elegante, amistosa y
simple para modelar soluciones de software. Ese aprendizaje qued reflejado en
el libro La Nueva Visin, Diseo y Construccin de Sistemas Computacionales.
Hacia fines de los 90, la orientacin a objetos se transform en un estndar de
hecho en la forma del lenguaje de modelamiento UML, el cual incorpor en mis
desarrollos y document en un nuevo libro en el 2006, Gestin de Proyectos de
Procesos y Tecnologa.
Lectores del libro

Esta nueva publicacin se orienta a especialistas en informtica, a docentes y es-
tudiantes de carreras afines a la computacin quienes requieren conocer mtodos
para aumentar su productividad y efectividad.
Tambin a usuarios de la tecnologa, quienes podrn conocer la terminologa bsi-
ca para interactuar con los especialistas.
Libros de apoyo
Complementando este texto y para efectos de que el lector pueda profundizar
en ideas especficas (sin ser indispensable porque el modelamiento se trata
aqu como una totalidad), hago referencia dentro de la lectura a mis libros
relacionados con el tema2:
2
Para las citas en el pie de pgina indicar slo su ttulo. Los libros estn editados en Santiago
de Chile por Editorial Evolucin S.A.
16 JUAN BRAVO C.
Desarrollo de sistemas de informacin, una visin prctica (1988)

Reingeniera de negocios (1995)
Planificacin sistmica (1997)
Anlisis de sistemas (1998)
Gestin de procesos (2005)
Taylor revisitado, la productividad es la clave (2005)
Gestin de proyectos de procesos y tecnologa (2006)
Responsabilidad social (2007)
No hago referencias a mis libros Modelamiento de sistemas de informacin y
La nueva visin, diseo y construccin de sistemas computacionales porque
todos sus contenidos relevantes para efectos de modelar soluciones de softwa-
re estn incorporados en esta nueva obra.
Prlogo de Gerentes de reas de sistemas

Algunos estimados amigos me han otorgado el privilegio de agregar algunas
palabras. Tienen en comn estar a cargo de reas de informtica, las cuales
estn insertas en organizaciones de diferente tamao y sector.
Christian Andrews3
Todo libro conlleva un gran esfuerzo del parte del autor, por la bsqueda de
conceptos e ideas nuevas que se desarrollan y plasman alrededor de una idea
maestra, donde convergen todas las otras ideas menores, como afluentes a un
ro mayor. Mi amigo Juan Bravo, autor de un gran nmero de libros del rea de
la Tecnologa de la Informacin (TI) aplicada a los negocios, a quien conozco
por muchos aos, nuevamente ha realizado otro gran esfuerzo, para entregar
estos nuevos conocimientos, ideas y conceptos actualizados al da de hoy. En su
particular manera de escribir, nos ofrece esta nueva entrega literaria: un libro
que versa alrededor de una idea: el modelar soluciones de software.
Dnde radica la importancia de este libro para los profesionales de TI? A mi
juicio, esta entrega orienta y prepara a las pequeas y medianas empresas, en
concebir los sistemas computacionales como un commodity, es decir, sistemas
que son construidos con mtodos estndares de construccin y calidad. Con
metodologas que aseguran un resultado predecible en las operaciones diarias de
los diferentes procesos comerciales. Ratificando una vez ms, que el tener sis-
temas computacionales no constituye ninguna ventaja sobre la competencia,
3
Gerente de Sistemas en Empresas Hites S. A.
muy por el contrario, el no tener estos sistemas constituye una clara desventaja
competitiva, sin importar en cual industria participe y compita. Desventaja que
erosiona gravemente los mrgenes de ingreso, da tras da, en todas estas empre-
sas sin los sistemas computacionales.
La tierra es plana postula Thomas Friedman, destacado periodista americano,
como un eslogan que interpreta el impacto de la globalizacin en el mundo mo-
derno, botando muros polticos, tendiendo expeditos puentes comerciales
sobre los diferentes ocanos, derribando montaas y cordilleras que separan a
los pases y finalmente conectando con unas extraordinarias autopistas de fibra
ptica todos los continentes de este planeta Tierra, que permiten acercar y hacer
local casi cualquier bien o servicio. Un hecho impactante es la cercana de los
productos de origen chino en casi todo el diario vivir o la oferta increble de
servicios computacionales y tecnolgicos de grandes compaas de origen indio.
Hoy por hoy, la gran fbrica de software del mundo est en India, ms que en
otro lugar de este mundo, miles de ingenieros de software con conocimientos
actualizados y metodologas, estn dispuestos a desarrollar productos de softwa-
re por una fraccin del ingreso medio de un pas medianamente desarrollado.
Entonces, cmo competir en este mundo ms bien adverso? Pues actualizndo-
se permanentemente en los diferentes avances que se van liberando en el mundo
desarrollado.
De ah, la importancia de este libro de Juan Bravo, quien nuevamente se esfuer-
za en descubrir, rescatar lo medular de cada nuevo conocimiento del ltimo
tiempo, lo encapsula, lo simplifica y lo entrega como un mtodo simple a seguir
por sus alumnos y profesionales que siguen sus libros.
Quizs hoy ms que nunca es relevante actualizar los conocimientos con la
mayor prontitud posible. En su libro, Thomas Friedman cuenta una historia
que es atingente: En el frica, cada maana el len hambriento piensa que
debe correr ms rpido que la gacela ms lenta para poder alimentarse y so-
brevivir. Cada maana la gacela piensa que debe correr ms rpido que el len
ms rpido para poder sobrevivir. Para nosotros, que no estamos en el frica,
slo podemos pensar que, no importa si somos len o gacela, cada maana
debemos comenzar a correr rpido si queremos sobrevivir.
18 JUAN BRAVO C.
Rodrigo Collado4
Conozco a Juan desde hace muchos aos, conozco de su trabajo, de sus ante-
riores libros y, sobre todo, de su cario por la Ingeniera de Software; especia-
lidad cuya formalizacin le ha tenido de cabezas por un par de dcadas.
He ledo su nuevo libro Modelando una solucin de software, una obra que
sirve a los especialistas en construccin de software, pero tambin a los que
estn ms lejos del diseo de software. Para los iniciados, el mensaje es
claro: abandonemos la artesana y hagamos ingeniera. Para los legos, es la
oportunidad de conocer la complejidad de una disciplina que an no alcanza
la formalidad de otras especialidades. Para ambos, tomar conciencia de la ne-
cesidad y prisa de trabajar conforme a los postulados de la Ingeniera de Soft-
ware, la cual est apoyando el desarrollo y desempeo de casi todas las reas
en el mundo del siglo XXI. Y es clave en muchos casos.
Siendo tan relevantes y amplios estos mensajes, debemos buscar la forma que
el libro se desmaterialice y llegue a las salas de clases y a las empresas. Juan
tiene la ventaja de conocer el medio local, de haber enseado en l, de haber
trabajado en muchas empresas chilenas, de haber intercambiado sus puntos de
vista y sus sueos con tantos, entre los que me cuento. Deseo firmemente que
su libro no sea uno ms, que compita o se compare con cualquier otro editado
en Estados Unidos o en otro pas.
Agradezco el empeo de Juan, el cario por su profesin, su amor por el estu-
dio de esta especialidad y su coraje en la bsqueda de la impecabilidad en el
modelamiento de buenas soluciones de software.
Limbi Ortiz Neira5

Cuando el doctor Juan Bravo Carrasco, me llam para pedirme que le escri-
biera un prlogo a este libro, me embarg la emocin por el gran honor que
esto significa para m, y luego de unos segundos de respirar profundo, le res-
pond que lo hara. Mi humilde opinin es la que presento ahora a ustedes:
El creativo, novedoso y entretenido enfoque que le ha dado el doctor Juan
Bravo C. a este libro, ha logrado que el hecho de modelar una solucin de
Software, sea un desafo que nos obliga a considerar diferentes aspectos, por
lo general no considerados en este ejercicio, tal como visin sistmica, un
concepto que nos abre la mente a ver nuestro software como parte de un en-
4
Gerente de Desarrollo en BancoEstado.
5
Directora de Sistemas en la Municipalidad de Melipilla.
torno rico en posibilidades, en el cual necesariamente debemos considerar la

mesa6, es decir, el modelo de negocios en el cual estamos trabajando, consi-
derar tambin el diseo orientado a objetos, el cual nos aclara conceptos tan
utilizados como desconocidos hoy en da.
Un acierto, que destaca dentro de la claridad de este libro, ha sido el hecho de
que el doctor Bravo ha logrado explicar de manera simple, sencilla y sin
abandonar la formalidad de la Ingeniera de software, las competencias nece-
sarias para modelar una solucin de software, las cuales tienen tal importancia
que ellas siete se traducen en los respectivos captulos del libro. Merece la
pena nombrarlas aqu:
Competencia 1: Aplicar un mtodo completo para la gestin de proyectos
Competencia 2: Profesionalizar el desarrollo con la ingeniera de software
Competencia 3: Conocer la nueva teora de modelos
Competencia 4: Manejar el modelamiento de datos
Competencia 5: Conocer necesariamente la orientacin a objetos
Competencia 6: Trabajar con el estndar UML
Competencia 7: Conocer las herramientas de la TI
El libro es tan entretenido que te transporta y te inquieta por continuar apren-
diendo. Te desafa a utilizar todos los conceptos, tcnicas y herramientas que
all aparecen, as tambin, te estimula a continuar investigando.
Modelando una solucin de software, una visin sistmica del anlisis y di-
seo orientado a objetos, con UML y herramientas TI, es uno de esos libros
que por ser tan interesantes, no quieres que se termine y te entusiasma. En este
libro, se plasma mucho de la gran experiencia adquirida en sta rea por el
doctor Bravo, parte de la cual he tenido la suerte de escuchar y aprender.
Finalmente, quisiera felicitar al doctor Juan Bravo por hacernos partcipes a
todos de este libro, al cual ha dedicado muchsimas horas de trabajo y el resul-
tado ha sido excelente. Asimismo, agradecerle su confianza en m, y haberme
permitido dar mi opinin.
6
Se refiere a cinco elementos que se representan con la metfora de una mesa (la cubierta es
la estrategia y las 4 patas son: personas, procesos, estructura y tecnologa), la cual se describe
brevemente en la introduccin y se detalla en la etapa de anlisis (seccin 1.4).
20 JUAN BRAVO C.
Carlos Toloza 7
Cuando Juan me pidi revisar el material de este libro y escribir unas lneas al
respecto acept sin ningn problema, pero al sumergirme en el tema especfi-
co del UML (ISO 19501:2005) debo reconocer que vi la oportunidad que se
me brindaba de poder llegar a una lectora o lector y compartir mi opinin con
la esperanza de que en el momento de estar leyendo estas lneas aportar un
mensaje simple y claro.
Yo pienso que lo que estamos hablando en este libro es de tener y sentir la
misma responsabilidad profesional frente al desarrollo de un sistema inform-
tico que frente a la construccin de una catedral. El pecado original en in-
formtica es comenzar a desarrollar sin tener los planos, ac es lo mismo, no
podemos comenzar a construir el sacro edificio si no tengo planos arquitect-
nicos hechos y bien hechos.
Tengo la suerte de trabajar en una empresa constructora y sera un suicidio
comenzar un proyecto sin tener los planos, bueno, en informtica los planos
del sistema podemos dibujarlos con alguna nomenclatura estndar como UML
o alguna propia, pero ese es el punto, por favor no comience la construccin
sin los planos!!!
La verdad es que prefiero dejar un mensaje simple y fuerte en la mente del
lector que participa en un proyecto informtico, no comience el desarrollo sin
planos, no olvide que hay personas que van a vivir dentro de ese sistema y va
a ser su casa en forma permanente.
De pronto me siento repitiendo algo que escuch por primera vez en mis ini-
cios, cuando programaba mi primer software, pero la realidad de las empresas
es muy exigente y a veces la presin por resultados nos hace improvisar o
simplificar el tema en las etapas iniciales de los proyectos, les tengo malas
noticias, es verdad que los costos de improvisar son muy altos y pueden dupli-
car fcilmente cualquier presupuesto de tiempo y costo con el consiguiente
impacto negativo en el negocio.
Juan dice en el prlogo de este libro que lo que buscamos finalmente es una
mayor productividad de nuestras empresas, o sea que con los mismos recursos
seamos capaces de entregar ms productos o si lo profieren que con menos
recursos podamos entregar los mismos productos. Un sistema informtico
bien hecho (partiendo de su modelacin) debe bajar los costos del rea en la
7
Gerente de Informtica del Grupo Constructor Besalco.
cual se implementa y esta reduccin debe pagar la inversin comprometida

para generar utilidades en el tiempo.
Bueno, eso es todo, no estamos hablando de modelar por modelar, estamos
hablando de hacer un buen proyecto informtico que genere utilidades a la
empresa, si lo entienden se darn cuenta del poder que hay en la informtica.
22 JUAN BRAVO C.
AGRADECIMIENTOS
El liderazgo complementa a la gestin, no la sustituye.

Kotter (2004, p. 41)
Mi especial reconocimiento a quienes tuvieron la gentileza de revisar borrado-

res de este texto y compartir tanto de su sabidura: Limbi Ortiz Neira, Gloria
Arellano Mundaca, Mauricio Arancibia Pino, Gerardo Cerda Neumann, Chris-
tian Andrews Villagra, Rolf Achterberg Neman, Rodrigo Collado Lizama,
Luis Cavieres Rojas, Vctor Silva Ballerini, Ignacio Castro Escobar, Carlos
Reyes Rubio, Eugenio Daz Gonzlez, Hugo Osses Bravo, Carlos Parra Bus-
tos y Ral Prado Baldratti.
Muchas ideas y motivacin han surgido de las conversaciones con Liliana
Gajardo, Derek Hyland, Francisco Ramrez, Daniel Kanonitsch, Miguel Sez,
Luis Cid, Francisco Medina, Rodrigo Baldecchi, Marcos Merino, Carlos To-
loza y Enrique Jorquera (mis disculpas por las eventuales omisiones).
Este libro es heredero de dos textos anteriores: Modelamiento de Sistemas
Computacionales (1994) y La Nueva Visin, Diseo y Construccin de Siste-
mas Computacionales (1996), as es que reitero en ste los agradecimientos a
quienes aportaron de una u otro forma en aquellos (revisiones, ideas, motiva-
cin): Rolf Achterberg Neman, Giancarlo Gandolini Ambrosoli, Ricardo
Baeza Yates, Eugenio Daz Gonzlez, Santiago Macas Huenchullan, Francis-
co Mndez Sanhueza, Jos Labra Molina, Jeannette Caballero Pinilla, Alexis
Cifuentes Barra, Luis Mndez Reyes, David Medina Avils, Jos Leiva Ol-
medo, Ricardo Cahe Cabach, Juan Carlos Soto Trucido, Francisco Guerrero
Novoa, Bernardo Cienfuegos Areces, Sonia Esturillo Herrera, Liliana Gajardo
Campos, Jorge Stein Blau, Manuel Videla Abarca, Dagoberto Cabrera Tapia y
Cristian Rubilar Utillano.
Estoy agradecido de las empresas donde me acogieron como colaborador de
tiempo completo: Empremar, NCR y Weisselberger y Ca. Tambin de las or-
ganizaciones donde he tenido el privilegio de participar como asesor o relator de
seminarios: CMP, AT&T Chile, Agencia de Aduanas Jorge Stein, Polygram
Chile Ltda., Termosistema, Aquacultivos, Editorial Televisa, Integramdica,
Sota y Nicoletti Comunicaciones, entre otras. Especial mencin requieren las
empresas con las cuales hemos trabajado en la ltima dcada: BancoEstado,
Empresa Portuaria de Valparaso, Rolec, Enami Ventanas (actual Codelco),
IST y ACHS.
En cuanto al mbito acadmico, destacar actividades abiertas de capacitacin,

por ejemplo, a travs de:
Universidad Tcnica Federico Santa Mara en Via del Mar y Santiago. El
diploma realizado por varios aos en anlisis y diseo de sistemas.
Universidad Santa Mara en Ecuador, el magster en gestin y tecnologa.
Universidad de Chile, los cursos acerca de procesos y de tecnologa.
Pontificia Universidad Catlica de Chile, en particular los cursos de ges-
tin de proyectos de procesos y de tecnologa en el formato de dos das.
Revista Gerencia, en la forma de mltiples seminarios de un da de divul-
gacin de estos temas.
La colaboracin de Silvia, mi hermana, una vez ms fue muy valiosa en todo
tipo de apoyo logstico.
El diseo de la portada es obra de Juan Pablo Bravo Zamora.
A todos agradezco sus aportes y libero de cualquier responsabilidad por algn
error en el texto.
Un reconocimiento especial a mi esposa e hijos, su cercana ha sido un est-
mulo en la realizacin de esta obra.
Juan Bravo C.
24 JUAN BRAVO C.
INTRODUCCIN
El hecho de adoptar una perspectiva de sistemas da a los

analistas de sistemas la oportunidad de empezar a clarificar y
comprender los diversos aspectos con los que se enfrentarn. Es
importante que los miembros de los subsistemas se den cuenta
que su trabajo est interrelacionado Los problemas surgen
cuando cada gerente tiene un concepto diferente de la importan-
cia de su subsistema funcional.
KENDALL y KENDALL (2005, p. 30)
Modelar una solucin de software es una labor bella y creativa. Por esta razn,
frecuentemente se obtienen muy buenos productos que son verdaderas obras
de arte, tal como si a un artista le encargaran una obra (requerimientos) y l,
utilizando sus propios mtodos y herramientas de trabajo, diera vida a una
creacin nica e irrepetible.
Ser posible profesionalizar conservando la creatividad? S! y de esta for-
ma los mtodos y herramientas van a recibir el aporte de muchas personas.
Modelar soluciones de software puede ser arte y tecnologa a la vez.
Este es el desafo, modelar soluciones de software con tcnicas normalizadas,
buscando simplicidad, eficiencia y adaptabilidad al cambio, en el contexto de un
proceso general de desarrollo que permita trazabilidad y productos repetibles.
Por qu modelar? Porque es necesario representar formalmente una realidad
deseada, que de otra forma resultara muy difcil de transmitir, en este caso una
solucin de software. Lo ms probable es que la realidad deseada se encuentre
vagamente escrita y que principalmente est en la mente de las personas, ms
como un deseo difuso que como un requerimiento. La funcin del modelamien-
to es hacer tangible y aclarar esa realidad para que luego se pueda implementar.
Si esa realidad deseada da respuesta a una necesidad por una parte y por otra los
modelos de esa realidad son factibles de implementar, entonces la probabilidad
de xito es alta. Eso es lo que quiere mostrar la siguiente figura.
Problema Solucin Implementacin
Realidad deseada Modelos

Necesidad
(difusa) de la solucin
Shari Pfleeger explica en su libro Ingeniera de software (2002, p. 226): Se

utiliza la especificacin de requerimientos para definir el problema. Entonces,
podemos declarar que algo es una solucin a un problema si satisface todos los
requerimientos planteados en la especificacin. En muchos casos el nmero de
soluciones es prcticamente ilimitado.
Siempre es necesario modelar la solucin antes de implementar?

Depende, si usted slo quiere extender una pared interior de 2 metros, es posible
que no requiera los modelos, puede contratar un experto y slo darle instruccio-
nes verbales, tal vez le resulte y ahorre tiempo y dinero. Sin embargo, si quiere
construir su casa necesitar de maquetas y muchos planos (obra gruesa, caeras
de agua, cables de electricidad y todo lo dems).
En el software es igual, toda aplicacin desde un costo de algunos miles de dla-
res ya hace necesario un modelar formalmente. La idea es superar la construc-
cin artesanal de software (por ejemplo, construir sin planos) y aplicar los nue-
vos conocimientos sobre teora de modelos, normalizacin (tal como orienta-
cin a objetos y UML) y construccin con herramientas CASE.
Contenido del libro

Lo primero sucede en esta misma introduccin, una seleccin de los modelos
ms relevantes de una solucin de software, donde slo se muestra un boceto de
ellos para lograr una visin de conjunto (el detalle de cada uno est en el resto
del libro).
Esta presentacin ser nuestra gua y a partir de esta experiencia extraeremos
una conclusin vital: las competencias que debera tener un profesional de la
informtica. Las competencias son conocimientos, habilidades y actitudes ne-
cesarias para modelar aplicaciones computacionales (o soluciones de softwa-
re), en este texto se presentan en la forma de captulos:
1. Un mtodo completo para la gestin de proyectos y as situar el modela-
miento de soluciones de software en su contexto.
2. La profesionalizacin de conocimientos que aporta la ingeniera de soft-
ware para comprender todos los aspectos tcnicos de los modelos, las
normas y estndares que existen.
3. Los mltiples aportes de la nueva teora de modelos, en particular el mo-
delamiento de funciones y el criterio curso normal de los eventos.
4. El indispensable modelamiento de datos.
5. Los necesarios conocimientos de la orientacin a objetos.
26 JUAN BRAVO C.
6. El estndar UML.
7. Las herramientas de la tecnologa de informacin.
Cada captulo, en el mismo orden, profundiza en la competencia correspon-
diente, producindose un avance que parece una pirmide, tal como se aprecia
en la siguiente figura.
CAPTULO 7. HERRAMIENTAS TI
CAPTULO 6. UML
CAPTULO 5. ORIENTACIN A OBJETOS
CAPTULO 4. MODELAMIENTO DE DATOS
CAPTULO 3. TEORA DE MODELOS
CAPTULO 2. INGENIERA DE SOFTWARE
CAPTULO 1. MTODO PARA LA GESTIN DE PROYECTOS
Competencias necesarias para modelar aplicaciones computacionales
Sntesis de modelos de una solucin de software

Los modelos se crean en las etapas de anlisis y diseo de la Gestin Sistmica
de Proyectos (GSP)8. El camino para dibujarlos es iterativo, es decir, se van
perfeccionando mediante borradores sucesivos.
Es recomendable contar cuanto antes con un boceto de todos los modelos que se
considerarn para cada etapa de la aplicacin particular, una primera versin
destinada a lograr una visin de conjunto. Ese es el sentido de esta introduccin.
Seguimos la idea de una doble espiral que se traslapan parcialmente: la primera
del anlisis y la segunda del diseo, tal como vemos en la figura.
Anlisis Diseo
8
En el captulo 1 veremos el mtodo completo.
Mapas para la visin de conjunto

Conviene observar estos cinco mapas que deberan existir en la organizacin
previo al desarrollo de una aplicacin especfica. Son los mapas de necesida-
des, proyectos, procesos, retroalimentacin y sistemas.
Bienestar
Soluciones propuestas: Mapa de
1. Alinear con la estrategia
2. Incluir como plan de proyectos
Productividad Costo accin de RS 10p
Responsabilidad
Calidad Social
2p
Tiempo
Problemas detectados: 1p 7p
1. Pago tardo a
Proveedores
2. Trabajadores fuman en = Libera
sector atencin clientes = Neutro
= Requiere
Mapa de necesidades
Procesos Estratgicos Gestin de Personas
Analizar
Planificacin Gestin de Gestin de Gestin de Control de Gestin de Reclutar Inducir
cargos
Mapa de Desarrollo
Estratgica
RS
Procesos Proyectos Calidad Gestin Contratos
procesos Evaluar Formar

Disear
carrera
Proceso del Negocio Comercializar

Proyectar ventas Comprar Recibir Distribuir Ordenar Vender al detalle Postventa
Conocer Planear Preparar Atencin

la demanda Vender
Cotizar Recepcionar cada local cada local al cliente
Visitar Emitir Medicin

Clientes Presentar Despachar y seguimiento
traspaso
Estadsticas Emitir O/C Almacenar

Coordinar Servicio
Traspasar Cuadrar
internas merchand. de garanta
Procesos de Apoyo
Servicios Remuneraciones Tecnologa y
Adquisiciones Finanzas Contabilidad Legal Transporte
Bsicos y bienestar Mantencin
Meditacin
Cobranzas
Buen trabajo Devolucin
en equipo Liderazgo
sistmico Ventas
Alcance
poco claro
Retroalimentacin de Demora Facturacin
eventos destacados en entrega
final
Compras Bodega
Dificultades para Entrega
coordinar entrevistas
con usuarios
= Experiencias para evitar

Recepcin
= Experiencias para replicar
Mapa de retroalimentacin Mapa de sistemas computacionales

28 JUAN BRAVO C.
Estos mapas son modelos que ayudan a lograr la visin de conjunto para luego
formalizar en el anlisis y diseo la solucin de software. El detalle de cada
uno se puede apreciar en el captulo 1.
La visin de conjunto es vital en la visin sistmica, cosmovisin que gua
todo el trabajo de este libro, tanto en los mapas como en los siguientes
modelos, los cuales tienen la caractersticas de contextualidad, es decir,
dependen del mtodo y nivel de madurez de cada organizacin.
Los modelos que se presentan a continuacin para anlisis y diseo son slo
una muestra de las posibilidades del modelamiento. Cada empresa debe tener
su propia ruta metodolgica e incluso adaptada segn tipos de proyectos.
Se presentan los modelos ordenados segn las etapas de anlisis y diseo. En
la siguiente figura se aprecia el objetivo y actores de cada una. Todo el
modelamiento est orientado al cliente (externo, quien paga), la etapa de
anlisis se orienta a definir el qu y la de diseo el cmo, en ambas participan
analistas y usuarios. Una vez que el diseo est completo, se enva al
constructor (aunque sea el mismo analista en otro rol).
Qu Cmo
Anlisis Diseo
Constructor
Cliente
Usuarios y Analistas
Modelos de la etapa de anlisis

La siguiente seleccin de modelos no pretende ser exhaustiva, se incluye con
el nico objetivo de lograr una visin global, no se explican aqu porque el
detalle de cada uno est en los captulos del libro.
En este caso, los modelos siguen la lgica del mtodo GSP, en la empresa
corresponden a los contenidos del proceso de desarrollo de software que sta
se haya dado.
En esta etapa todo el trabajo se centra en el modelo de negocios de la solu-
cin, con cinco elementos que se representan con la metfora de una mesa, la
cubierta es la estrategia (alineando la de la empresa y la de del proyecto, in-
cluye responsabilidad social) y las 4 patas son: personas (incluyendo ambien-
te), procesos, estructura (organizacional y fsica) y tecnologa (de todo tipo).
En esencia: corresponde decidir Qu hacer, comenzando por la cubierta de la
mesa (detalle de la figura en el captulo 1).
Estrategia
Personas Tecnologa
Procesos Estructura
Luego se comienza a trabajar en la pata de los procesos: levantamiento deta-

llado y propuestas de cambio. Se emplean principalmente los modelos mapa
de procesos y flujograma de informacin, los cuales se observan en la siguien-
te figura (detalle en los captulos 1 y 3 respectivamente).
Vender al detalle
PROCESO DESPACHO INMEDIATO
CLIENTE BODEGA FINANZAS
ADMINISTRATIVO DE BODEGA DESPACHADOR
OE
Vender Despachar Cuadrar Reservar y

PROCESOS emitir GD GD3
VENDER GD2 GDs
GD4 GD1
Buscar
producto
Al Contado Inmediato GD4
OE
Rebajar
A Crdito A domicilio saldo
Cliente
recibe
y firma
recepcin
Programar Entregar
GD3
GD2 PROCESO
Mapa de procesos GD1 CUADRAR
OE: Orden de Entrega, GD: Gua de Despacho

30 JUAN BRAVO C.
Desde aqu surgirn definiciones para las otras patas de la mesa: personas,
estructura y tecnologa. Lo cual est descrito en el captulo 1.
Para definir el alcance de la solucin de software en la etapa de anlisis, se
puede emplear esta serie de modelos (una buena tcnica es por borradores
sucesivos, comenzando por cualquiera de ellos). El objetivo es decidir qu
incluye el modelo de negocios (detalle en los captulos 1, 2 y 3).
Pedidos y Costos Compras Ventas
Clientes devoluciones Gerencia
Devoluciones Entradas Control Salidas Devoluciones
Artculos y factura Niveles Traspasos
del stock Traspasos
Control
de stock
Artculos y gua Despacho de artculos
Proveedores Orden de compra y Peticiones

Sala de ventas
devoluciones
Modelo orientado al objetivo

Diagrama de contexto principal del sistema
Maestros Cuentas Historial Historial
Clientes Artculos Proveedores
Proveedores Contables Ventas Compras
Transacciones
Ventas X X X X
Compras X X X X
Devolucin ventas X X X X
Compras Clientes
Artculos Ventas
Modelo orientado al flujo de

Modelo orientado a los datos transacciones
Cotizador Terminales del rea de Adquisiciones
Cotizar
Jefe de
Aprobar Adquisiciones
Administrativo de cotizacin
Adquisiciones
Ingresar
O/C
Aprobar
O/C
Enviar
O/C = Orden
O/C
de Compra
Diseo general de la interfaz Diagrama de casos de uso
Una vez lograda la decisin respecto a los qu, es necesario profundizar en los
requerimientos principales de la solucin de software, en tal caso, la recomen-
dacin es trabajar con estos nuevos modelos (detalle en los captulos 5 y 6).
Terminal en bodega Terminal del Administrativo de Adquisiciones

Administrativo
de Adquisiciones
Ingresar O/C
Administrativo de
Adquisiciones Ingresar O/C Resumen: (el mismo del caso de uso de alto nivel).
Funciones relacionadas:
Curso Normal de los eventos
Accin del actor Respuesta del sistema
1. Tomar la O/C desde el archivador
2. Ingresar N O/C en (A) 3. Verifica correlativo y enva respuesta
Ingresa la Orden de Compra en (B)
a partir de los documentos de 4. Ingresar Rut en (D) 5. Verifica que proveedor exista, obtiene
cotizacin a proveedores. y despliega nombre y fono en (E) y (F)
6.
Para cada lnea: Para cada lnea:
La O/C queda disponible 7. Ingresar el cdigo de
producto en (H)
8. Verifica existencia del producto,
obtiene y despliega la descripcin
para ser enviada al proveedor y el precio en (I) y (J)
luego de la aprobacin 9. Ingresar las unidades en (K) 10. Calcula el subtotal y despliega en
(L)
electrnica por el jefe de 10. Dar OK a la lnea 11.
adquisiciones
Excepciones:
1. Si el nmero de O/C ya existe, vea caso de uso Corregir Correlativo. 2
Incluye interfaces detalladas de E/S
Caso de uso de alto nivel Caso de uso de expandido

Encabezado Proveedores
Encabezado de contiene existe en Proveedores de O/C contiene existe en
O/C * 1 N O/C * 1 Rut
compuesta por 1 Fecha Nombre
compuesta por
se asocia a 1..*
Lneas de la contiene existe en Productos
O/C * 1 Lneas de la contiene existe en Productos
existe en * O/C * 1 ...
Unidades existe en *
almacena 1 Precio
Bodega
almacena 1
Bodega
...
Modelo conceptual de datos Modelo conceptual con atributos
Interfaz de Entrada
Gua Interna de Recepcin por Compra A C/E Ingresar
D
N Gua Recepcin Encabezado
Cdigo Enc. Recepcin C Encargado Recepcin de transaccin transaccin Personas
Fecha Recepcin B Mensaje 1
Razn Social Proveedor
RUT Proveedor E - F
Direccin Proveedor G e-Mail H
Comuna I Ciudad J Fono K Fax L Detalle de C/E
Gua de Despacho de Proveedor N M Fecha G/ D. Proveedor N N de O/C. O transaccin Productos
Mensajes 4 y 5
L. Cdigo Descripcin Precio Cantidad Valor Neto
LL P Q R S T
Modelo funcional generalizado

Cerrada W Cerrar X XX V
Anulada Y Anular Z Salir Grabar Total acumulado U
Interfaz visual detallada

32 JUAN BRAVO C.
Modelos de la etapa de diseo

De la misma forma que la etapa de anlisis, es decir, mediante borradores su-
cesivos y la tcnica de desarrollo en espiral (ver anexo 3) se avanza en el dise-
o, sin mayores problemas de volver a veces a la etapa de anlisis, porque
ambas forman una totalidad que llamamos modelar una solucin de software
(el detalle de estos modelos est en los captulos 5 y 6).
Encabezado Personas Ingreso de transaccin

de transaccin Ingreso de transaccin
Rut Encabezado, detalle y totales segn
N documento Nombre Formato de pantalla adjunto
Fecha C/E Encabezado, detalle y C/E
Rut persona totales segn formato Direccin
Mensaje Telfono Aceptar datos y actualizar lnea a
1 lnea cada producto.
1 Agregar 1 Aceptar datos 1 Agregar
2 Consultar 2 Cuadrar totales 2 Consultar Enviar mensajes para verificar
3 Imprimir 3 Imprimir Existencia de personas y artculos,
Ambos deben existir.
Cuadrar totales para referencia.

Enviar solicitudes para actualizar el stock
Detalle Productos
de transaccin
N documento Cdigo artculo
Cdigo artculo C/E Tipo artculo
Costo Descripcin Tabla de objetos, clase Ingreso de transaccin
Mensajes 4 y 5 ltimo costo Objeto Atributos Funciones
Cantidad
Saldo Ingreso de ventas Indicar stock del producto Deben cuadrar totales, stock mayor a
1 Clculo total unidades por vender. Mensaje 5
1 Agregar Ingreso de compras Crear proveedor y artculo si no
2 Consultar existen. Mensaje 4
3 Imprimir
4 Sumar saldo
5 Restar saldo
Visin interna de la clase ingreso de

transaccin con la tabla de objetos
Modelo funcional generalizado y detallado
Administrativo Sistema Contrato

Identificacin: Dar OK al ingreso de la lnea
Responsabilidades: con cada ingreso de lnea los
conceptos deben ser consistentes.
Tipos de datos: afecta a los conceptos
Ingresar N de O/C Encabezado de O/C y Detalle de O/C.
Referencias cruzadas: no hay
Notas: nada especial
Ingresar cdigo de prod. Excepciones: la no existencia de la lnea en el
Repetir hasta sistema ya fue validada con el ingreso de O/C.
que no haya ms Salida: no hay
Ingresar cantidad Precondiciones: no existe la lnea.
productos
Poscondiciones:
Dar OK a la lnea Se cre una lnea en el concepto detalle.
Se actualiz el contador de lneas en el
encabezado.
Se actualiz la asociacin entre
encabezado y detalle de O/C.
Diagrama de secuencia Contrato

Los dos modelos ms caractersticos del diseo desde el punto de vista de

UML son el de diseo de clases y colaboracin (detalle en el captulo 6).
Proveedores
Encabezado de O/C
Rut
N O/C
contiene existe en Nombre
Fecha
Crear lnea * 1 Crear proveed.
Imprimir Modificar Rut
Modificar nombre
compuesta por 1
se asocia a 1..*

O/C ...
Unidades * 1
Precio
existe en *
Agregar lnea
almacena 1
Bodega
...
Diagrama de diseo de clases
Operacin: Dar OK al Ingreso de la lnea de O/C
Ingresar producto 1: Crear lnea de O/C

(cd, cant, pre) (cod, cant, pre)
Terminal del Encabezado
administrativo de O/C
1.1: Crear (cod, cant, pre)

Lneas de la
O/C
Diagrama de colaboracin
34 JUAN BRAVO C.
CAPTULO 1.
MTODO PARA LA GESTIN
DE PROYECTOS
Captulo 1. Mtodo para la gestin de proyectos
El papel de la arquitectura de software es parecido al papel que

juega la arquitectura en la construccin de edificios. El edificio
se contempla desde varios puntos de vista: estructura, servicios,
conduccin de calefaccin, fontanera, electricidad, etc. Esto
permite a un constructor ver una imagen completa antes de que
comience la construccin. Anlogamente, la arquitectura en el
sistema de software se describe mediante diferentes vistas del sis-
tema en construccin.
BOOCH, JACOBSON y RUMBAUGH (2000, p. 5)
Este captulo introduce en los conceptos y la necesidad de contar con un

mtodo completo para la gestin de proyectos en la organizacin, no slo en
el mbito tecnolgico.
Esta es la primera competencia considerada para apoyar la elaboracin de
modelos de una solucin de software, tal como se aprecia en la siguiente fi-
gura (en la introduccin se incluy la visin global de las competencias). Es
necesario que el analista conozca la totalidad de pasos de un proyecto para
insertar su aporte. Podramos decir que es un conocimiento de tipo horizon-
tal, con visin de procesos, porque se refiere a entender la totalidad de la
gestin de proyectos, independiente de que su foco estar en las etapas de
CAPTULO 6. UML

anlisis y diseo.
La visin global, sistmica, que ofrece un mtodo es indispensable para en-

tender la totalidad que surge de necesidades concretas en la empresa que los
proyectos ayudarn a resolver creando una habilidad organizacional9.
Al mtodo que presentamos en estas pginas le hemos llamado GSP (Gestin
Sistmica de Proyectos), es resultado de extensas investigaciones acerca de las
mejores prcticas de proyectos y es un extracto del libro Gestin de proyectos
de procesos y tecnologa, sealado en el prlogo.
Trabajar metodolgicamente es una competencia indispensable para todo pro-
fesional del rea de proyectos y para todo tipo de proyectos, ya sea que estn
orientados a procesos del negocio, de apoyo o estratgicos. Por otra parte, toda
organizacin debe contar con un mtodo para la gestin de sus proyectos.
Las etapas son los grandes bloques que aporta el mtodo GSP: concepcin,
factibilidad, anlisis, diseo, implementacin, despliegue y operacin.
Las etapas estn agrupadas en tres fases: estudio, desarrollo y mejora conti-
nua. Tanto las etapas como las fases se pueden traslapar en los lmites.
Tambin existen prcticas transversales a las etapas, es decir, aplican en algu-
nas o en todas las etapas del mtodo. Son 28: direccin del proyecto, plan de
la etapa, exposicin de los planes, retroalimentacin, equipo de trabajo, entre-
vistas, comunicacin, informes, tcnicas, herramientas de apoyo, trazabilidad,
Quick wins, costos y duracin, gestin de riesgos, gestin de la calidad, res-
ponsabilidad social, insercin, orientacin al cliente, sensibilizacin, capacita-
cin, seguimiento, cuidar la solucin anterior, continuidad operacional, plan
de recursos fsicos del proyecto, kill time, control de cambios, gestin del
cambio y gestin de proveedores.
Veremos:
Trabajar metodolgicamente
Claves de la implantacin de mtodo
Adaptacin y profesionalismo
Etapas genricas
Prcticas transversales
9
Por habilidad organizacional entendemos una competencia que adquiere la empresa me-
diante una solucin de software, por ejemplo, ahora puede vender a travs de Internet o tener
su contabilidad al da.
36 JUAN BRAVO C.
1.1. TRABAJAR METODOLGICAMENTE
En la Edad Media, la incorporacin a un oficio, hacer zapatos o construir cate-

drales, era una iniciacin en un gremio muy cerrado. El arte o secreto de los
maestros se transmita desde stos a principiantes a travs de la revelacin de
los misterios del oficio.
De la misma forma comenz el desarrollo de proyectos tecnolgicos, con ini-
ciados que conocan los secretos del arte y que parecan estar juramentados para
no revelarlo. Sin embargo, no ha sido necesario que transcurrieran 400 aos
para que ese arte se transformara en tecnologa, tal como ocurri con la mayora
de los oficios de la Edad Media.
En la gestin de proyectos TI han bastado slo 40 aos para que la situacin
cambiara drsticamente.
Hoy sabemos cmo hacer gestin de proyectos y ese conocimiento est al al-
cance de todos en la forma de mtodos de alcance bastante amplio.
Una definicin de la gestin de proyectos hace Alejandro Covacevich (1994, p
82): Un proyecto es un conjunto de acciones y recursos que tienen un objeti-
vo no recurrente y un plazo o un costo fijos para ejecutar un proyecto en
que intervienen personas y recursos fsicos, se necesita un ejecutivo que plani-
fique, organice, dirija, controle y coordine. Todas esas acciones configuran la
gestin del proyecto, que generalmente ser ms compleja mientras ms re-
cursos y personas intervengan.
Veremos:
1. Qu es mtodo?
2. Las mejores prcticas
3. Fundamento conceptual: la visin sistmica
4. Mtodo GSP
1. Qu es mtodo?
Antes de continuar, aclaremos qu es mtodo? Consideramos que es una
competencia bsica para todo profesional que le permite guiar su trabajo de
acuerdo con normas y procedimientos definidos, visualizar el inicio y el fin de
los procesos en que participa, ubicar su aporte en el contexto del proceso
completo y trabajar en equipo con los dems participantes del proceso.
Se desprende de la definicin que mtodo est asociado con personas, quienes

deben trabajar metodolgicamente, lo cual aplica para todo tipo de procesos y
proyectos de cambio organizacional.
Las prcticas que adquieren las personas con la competencia mtodo se pue-
den ver como un continuo que comienza desde la toma de conciencia de
cmo lo hacemos (ya sea un proceso operativo o un proyecto) hasta aplicar
mejora continua, rediseo e innovacin sobre esa secuencia.
Refirindose a la buena gestin de proyectos, Campero y Alarcn en su libro
Administracin de Proyectos Civiles sealan (1999, pp. 2-3): Los buenos
resultados de una administracin sern el producto de condiciones personales
de los responsables y de las tcnicas de administracin que empleen. Cumplir
con las metas programadas de costo y plazo no resulta fcil y existe una alta
posibilidad de arriesgar los beneficios y costos esperados. Un estudio realiza-
do por Thompson y Perry usando un gran nmero de proyectos del Banco
Mundial, indica que, de 1.778 proyectos revisados, en el 63% de los casos el
costo final super el presupuesto, de 1.627 proyectos revisados, el 88% ter-
min con atraso. De 42 proyectos controlados, el 70% de ellos no alcanz a la
tasa interna de retorno (TIR) esperada.
2. Las mejores prcticas

El mtodo presentado surge de revisar y ensayar con las propuestas de lengua-
jes, normas de calidad y herramientas que el mercado ofrece, aprendiendo de
tales opciones e incorporando las mejores prcticas para aplicar en las organi-
zaciones de Latinoamrica, donde podemos profundizar en trabajar con cali-
dad y excelencia.
Es un mtodo genrico porque la idea es conocer y seleccionar del medio las
mejores tcnicas (causa-efecto, creatividad, mapa de procesos, flujograma de
informacin, UML, ITIL, PMI, orientacin a objetos y otras) avanzando hacia
las estandarizaciones formales o de hecho.
3. Fundamento conceptual: la visin sistmica

El modelamiento de soluciones de software tiene su base conceptual en la
visin sistmica10, tambin conocida como pensamiento sistmico, visin
area, aceptacin del caos y de la complejidad.
10
El libro Anlisis de sistemas se refiere en su totalidad a visin sistmica.
38 JUAN BRAVO C.
Peter Senge provee algunas claves en su libro La quinta disciplina (1992, p.

148): La clave del pensamiento sistmico es la palanca: hallar el punto donde
los actos y modificaciones en estructuras pueden conducir a mejoras significa-
tivas y duraderas. A menudo la palanca sigue el principio de la economa de
medios, buscando el lugar donde los mejores resultados no provienen de es-
fuerzos en gran escala sino de actos pequeos y bien focalizados. El pensa-
miento asistmico resulta perjudicial porque nos induce a efectuar cambios de
bajo apalancamiento: nos concentramos en los sntomas donde la tensin es
mayor y reparamos o aliviamos los sntomas. Pero esos esfuerzos a lo sumo,
mejoran la situacin en el corto plazo, y la empeoran en el largo plazo.
Conviene conocer algo de la visin sistmica porque nos ayuda a entender por
qu hemos organizado el mundo tal como lo conocemos, en fragmentos, bus-
cando especializacin. Tambin nos ayuda a pensar en integralidades, en vol-
ver a unir las partes de los rompecabezas que hemos creado. Este nuevo para-
digma tiene su propio campo de conocimientos y se nutre desde otras discipli-
nas: antropologa, sociologa, psicologa, pedagoga, todas las cuales aportan a
una visin ms amplia.
Una gua para modelar una solucin de software

La visin sistmica ser el gran fundamento conceptual que citaremos en este
camino prctico del modelamiento de aplicaciones de software. Por ejemplo,
nos ayuda a entender que un cambio en un modelo afectar a todos los dems,
que la actitud de los diseadores es fundamental y que el nimo y la coopera-
cin de quienes modelan es vital.
La visin sistmica nos ayuda a ver el todo, apreciar sus interacciones, la
energa presente y descubrir sus caractersticas distintivas, aquellas que son
propias del conjunto y que no existen en las partes. A la vez, ubica el sistema
en su entorno, acepta la complejidad que nos excede, la irreversibilidad del
tiempo, la autoorganizacin, la inteligencia de los sistemas y nuestra res-
ponsabilidad con el bien comn.
Qu es un sistema?
No existe una definicin generalmente aceptada para un sistema. Tradicio-
nalmente se lo entiende en dos aspectos: orientado al exterior en cuanto se
encuentra situado en un medio donde interacta con otros sistemas de su nivel
y con sistemas mayores de los que forma parte, y orientado a su interior, en
este caso el sistema es energa que toma la forma de interacciones y crea los
elementos que sean necesarios para su evolucin.
Dice Idalberto Chiavenato (2000, p. 769): El concepto sistema pas a domi-

nar las ciencias y, en especial, la administracin. Si se habla de astronoma, se
piensa en el sistema solar; si el tema es fisiologa, se piensa en el sistema ner-
vioso, en el sistema circulatorio o en el sistema digestivo. La sociologa habla
de sistema social; la economa, de sistemas monetarios; la fsica, de sistemas
atmicos, y as sucesivamente. En la actualidad, el enfoque sistmico es tan
comn en administracin que no se nos ocurre pensar que estamos utilizndo-
lo en todo momento.
Y en este texto lo estamos aplicando a modelar soluciones de software
4. Mtodo GSP
El Mtodo GSP (Gestin Sistmica de Proyectos) es una gua para el desarro-
llo completo de un proyecto, pasando por todas las etapas de su ciclo de vida:
concepcin, factibilidad, anlisis, diseo, implementacin, despliegue y ope-
racin. Es un mtodo abierto, con etapas genricas, amplio uso de tcnicas del
medio, apoyo de herramientas existentes y aplicacin de las mejores prcticas.
El Mtodo GSP es parte de un modelo integral para la gestin de la innova-
cin en la organizacin que contempla las definiciones estratgicas, formacin
de las personas, mtodo, creacin de estructura organizacional y apoyo tec-
nolgico (todos los elementos de la mesa sealados en la introduccin y que
se estudian en detalle en la etapa de anlisis de la seccin 1.4).
El plan de proyecto es una totalidad con contenidos mucho ms all de la carta
Gantt, incluye tambin la historia del proyecto, clculos financieros, justifica-
cin de la necesidad y mucho ms segn veremos en la etapa de factibilidad
en la seccin 1.4.
Adems, el plan de proyecto contempla dos lneas de trabajo paralelas, como
las vas del ferrocarril:
Etapas del proyecto
Prcticas transversales
Shari Pfleeger seala (2002, p. 135): Para comunicar a los clientes el anlisis
y la gestin del riesgo, el cronograma y la organizacin, usualmente se escribe
un documento denominado plan de proyecto. El plan deja por escrito las nece-
sidades del cliente, as como lo que se espera hacer para satisfacerlas. El clien-
te puede remitirse al plan para tener informacin sobre las actividades del pro-
ceso de desarrollo, siendo fcil seguir el avance del proyecto durante el desa-
rrollo Un buen plan incluye los siguientes items: alcance del proyecto, cro-
40 JUAN BRAVO C.
nograma, organizacin del equipo de trabajo, descripcin tcnica del sistema

propuesto, estndares del proyecto, procedimientos y tcnicas y herramientas
propuestas. La lista se extiende hasta los planes especficos para las prcticas
transversales, tales como plan de aseguramiento de calidad, de riesgos, dee
recursos y muchos otros.
En la figura 1-1 se presenta la totalidad del mtodo GSP.
Mtodo GSP
Etapas del mtodo genrico Concepcin

(CFADIDO) Factibilidad
Anlisis
Diseo
Implementacin
Despliegue
Operacin
Prcticas Transversales
Direccin del proyecto
Plan de la etapa
Gestin de riesgos
Retroalimentacin
Capacitacin
Entrevistas
Comunicacin
Informes
y las otras 20
Figura 1-1. Totalidad del mtodo GSP

1.2. CLAVES DE LA IMPLANTACIN DE MTODO
Son claves que guan el trabajo en la implantacin de mtodo. Previo, es nece-

sario sincerar lo que realmente hace la organizacin con mtodo y lo que est
dispuesta a aplicar.
Mtodo no es algo que solamente se compra y usa, como una mquina, tam-
poco se puede internalizar mediante pastillas (ni disponemos todava de la
tecnologa de la pelcula Matrix, aquella donde Neo aprenda rpido mediante
un tubo conectado directamente al cerebro).
Mtodo tiene que ver con el desarrollo de competencias de las personas, con
un trabajo arduo de generar estndares internos y sumarse a normas externas.
Hemos detectado 4 claves, son recursivas, es decir, tambin aplican para los
proyectos que utilizarn el mtodo en la organizacin.
Clave 1. Cinco mapas globales para la visin de conjunto
Clave 2. Mnimo indispensable
Clave 3. Participacin de todos los actores
Clave 4. Circularidad
Clave 1. Cinco mapas globales para la visin de conjunto

Adems de ver el mtodo en su totalidad, la visin de conjunto se apoya en
cinco mapas globales: necesidades, proyectos, procesos, retroalimentacin y
sistemas, los cuales veremos en las siguientes pginas.
Cada mapa debe tener una documentacin de apoyo con los atributos de cada
componente, su propia base de datos y el registro de cambios. Por supuesto, es
vital mantener una versin actualizada de cada uno de ellos.
Los mapas deben estar disponibles para toda la organizacin en dos formatos:
En digital, segn las herramientas elegidas por la organizacin y que
sean de fcil acceso para todos.
En papel, en la forma de un mapa territorial, completo, que puede es-
tar pegado en la pared. No hay problema que tenga varios metros de
largo. As efectivamente es una visin de conjunto. A esto le llamamos
mapa global. Se recomienda por su gran efectividad.
Siendo tan reciente la aplicacin de la visin sistmica en el modelamiento,
no existe todava una forma normalizada de cada mapa, as es que eso puede
ser una buena alternativa de flexibilidad para seguir experimentando.
42 JUAN BRAVO C.
Estos mapas deberan crearse como parte de la implantacin del mtodo, aun-
que adaptando segn la cultura y el nivel de avance previo de la organizacin.
a) Mapa de Necesidades
Seala las necesidades genricas de la organizacin que se estn estudiando y
resolviendo. Cada vez que se detecta una necesidad genrica se incluyen cau-
sas y soluciones. En la figura 1-2 se muestra, como ejemplo, dos estudios para
responsabilidad social.
Soluciones propuestas:
Bienestar 1. Alinear con la estrategia
2. Incluir como plan de
Productividad Costo accin de RS
Responsabilidad
Calidad Social
Tiempo
Problemas detectados:
1. Pago tardo a
Proveedores
2. Trabajadores fuman en
sector atencin clientes
Figura 1-2. Mapa de necesidades con problemas y soluciones
La idea de fondo es aplicar generalizacin en los problemas detectados y las

soluciones que se le han dado. El conocimiento que hemos adquirido es que
las causas de fondo de los problemas tienden a ser parecidas. Esta es una gran
oportunidad para resolver a nivel de problemas genricos y hacer que la orga-
nizacin como un todo sea ms inteligente.
b) Mapa de Proyectos
Muestra todos los proyectos que se estn realizando en la empresa y permite
establecer relaciones entre ellos. En el mapa de la figura 1-3 se usa para esta-
blecer un sistema de vasos comunicantes entre proyectos, uno que libera per-
sonas y otras que las requieren11.
10p
2p
1p 7p
= Libera
= Neutro
= Requiere
Figura 1-3. Mapa de proyectos con relaciones para reubicar personas
Un mapa de proyectos tiene mltiples aplicaciones, por ejemplo, desde el pun-

to de vista de responsabilidad social, ayuda a evitar despedir personas que
quedan liberadas de procesos obsoletos, ellos pueden aportar en otros proyec-
tos. Lo mismo es vlido para los recursos de la empresa: espacio fsico, equi-
pamiento, etc
11
Hemos visto que ms o menos un tercio de los proyectos libera personas y recursos, el otro
tercio requiere y el ltimo es neutro.
44 JUAN BRAVO C.
c) Mapa de Procesos
Quedan reflejados todos los procesos de la organizacin, ya sean estratgicos,
del negocio o de apoyo. Ntese en la figura 1-4 que la prctica es ubicar arriba
los procesos estratgicos, al centro los del negocio y abajo los de apoyo. En
este caso se muestra para la empresa comercial e industrial Linhogar (nombre
ficticio por supuesto).
Procesos Estratgicos Gestin de Personas
Ana lizar
Planificacin Gestin de Gestin de Gestin de Control de Gestin de Recluta r Inducir
Desarrollo RS cargos
Estratgica Procesos Proyectos Calidad Gestin Contratos
Disear
Evaluar Formar
ca rrera
Proceso del Negocio Comercializar

Proyectar ventas Comprar Recibir Distribuir Ordenar Vender al detalle Postventa
Conocer Planear Preparar Atencin

la demanda Vender
Cotizar Recepcionar cada local cada local al cliente
Visitar Emitir Medicin

Clientes Presentar Despachar y seguimiento
traspaso
Estadsticas Emitir O/C Almacenar

Coordinar Servicio
Traspasar Cuadrar
internas merchand. de garanta
Procesos de Apoyo
Servicios Remuneraciones Tecnologa y
Adquisiciones Finanzas Contabilidad Legal Transporte
Bsicos y bienestar Mantencin
Figura 1-4. Mapa de procesos de Fabrica de Electrodomsticos Linhogar
El mapa de procesos es una gran contribucin de la gestin de procesos12 por-

que permite que cada levantamiento y rediseo de procesos aporte al mapa
global y viceversa, evitndose la prctica tan cara de repetir el levantamiento
de un cierto mbito en cada aplicacin de software, en proyectos de gestin de
calidad o cualquier otro.
12
Ver libro del mismo nombre.
d) Mapa de Retroalimentacin
Lleva registros de eventos enriquecedores al finalizar los proyectos. Conviene
conocerlos ya sea porque son experiencias que es bueno replicar o porque
hubo sucesos que queremos evitar. En la figura 1-5 se us la forma de un ma-
pa mental. Ntese que se evit la distincin positiva o negativa de expe-
riencias porque todas las vivencias sirven en la medida que haya una buena
retroalimentacin y que efectivamente se use en proyectos futuros.
Meditacin
Buen trabajo
en equipo Liderazgo
sistmico
Alcance
poco claro
Retroalimentacin de Demora
eventos destacados en entrega
final
Dificultades para
coordinar entrevistas
con usuarios
= Experiencias para evitar

= Experiencias para replicar
Figura 1-5. Mapa de retroalimentacin para replicar o evitar
Es fundamental que el mapa este a la vista y siempre actualizado. As se pue-

de capitalizar la retroalimentacin.
Hay lugares donde se hace retroalimentacin en un informe de fin de proyecto
que luego queda archivado y nadie lo lee. No sirve, esa informacin debe estar
viva, por eso es que se promueve que este mapa y los dems estn pegados en
las paredes donde sean visibles y su rica informacin sirva.
46 JUAN BRAVO C.
e) Mapa de Sistemas Computacionales

Indica las aplicaciones que existen en la organizacin y las relaciones princi-
pales entre ellas. En la figura 1-6 se consideraron algunos sistemas tradiciona-
les. En la medida que se considere necesario, sobre la lnea se pueden indicar
las entradas y salidas, como en un diagrama de contexto.
Cobranzas
Devolucin
Ventas
Facturacin
Compras Bodega Entrega
Recepcin
Figura 1-6. Mapa de Sistemas Computacionales
Junto con el mapa de procesos y el modelo conceptual de datos de la organi-

zacin, este mapa de sistemas computacionales es vital para modelar la solu-
cin de software. Al proporcionar las entradas y salidas y que adems estn
visibles para todos los analistas y constructores, se avanza hacia un esquema
de componentes, tal como proponen las nuevas normas, estndares y concep-
tos (UML, SOA y otros que veremos en los captulos de este libro).
Clave 2. Mnimo indispensable

Se trata de negociar el alcance de la implantacin del mtodo bajo el criterio
del mnimo indispensable, es decir, el mnimo que todos los interesados se
comprometen a cumplir, no por imposicin, sino por reflexin o toma de con-
ciencia. Aplica aqu la ley de los pocos crticos y muchos triviales de Vilfredo
Pareto.
No se refiere exactamente a la interpretacin de Juran del 80-20 se logra el
80% de avance con el 20% del esfuerzo sino que a una negociacin respec-
to a lo que se considere mnimo para la organizacin particular.
El mnimo indispensable significa un mtodo flexible y preciso, bien adaptado
a la realidad de la organizacin y de cada proyecto particular, porque su orien-
tacin es simplicidad, flexibilidad y aplicabilidad, para que realmente sea uti-
lizado en las organizaciones latinoamericanas.
Es importante considerar que este mnimo indispensable estar influido por la
cultura de la organizacin en cuanto a disciplina y estandarizacin. Por ejem-
plo, lo ms probable es que en una empresa certificada en normas de calidad
sea ms fluida la implantacin de mtodo debido a que ya estn familiarizados
en la definicin y uso de procedimientos.
Clave 3. Participacin de todos los actores

Implantar un proceso de gestin de proyectos en la organizacin es una tarea
de todos. El mtodo que se decida no puede ser propiedad de una parte de la
organizacin, pertenece a toda ella, independiente que alguien lo administre.
Lo primero es identificar los actores, por ejemplo:
El cliente es el cliente. Est fuera de la organizacin, l paga los sueldos
de todos y es a quien sirven los proyectos en definitiva. Por lo tanto, se
debe validar cada proyecto a la luz de sus intereses.
El usuario es quien hace uso de los sistemas para servir a los clientes. Se
pueden identificar usuarios ejecutivos y usuarios operativos.
Profesionales de proyectos forman el equipo de trabajo: gerente de proyec-
to, especialistas en procesos y tecnologa, adems de consultores.
La alta direccin, gerencia u otra autoridad se encarga de la toma de deci-
siones respecto al proyecto.
Luego, es necesario definir los roles de cada uno con relacin al mtodo y la
forma en que se abordar su incorporacin, habitualmente es una combinacin
de sensibilizacin, capacitacin y coaching.
48 JUAN BRAVO C.
Es interesante observar que solamente difundir el mtodo es un proyecto en s

mismo, donde aplica todo lo indicado en este texto.
Clave 4. Circularidad
Implantar un mtodo puede seguir la forma de desarrollo en espiral. As, en un
par de meses la organizacin ya podra estar usando un proceso documentado
y disfrutando de los beneficios de proyectos realizados con efectividad.
Con el desarrollo en cascada la implantacin puede ser larga, muy larga, dos
aos? Demasiado! podra decir la comunidad.
La gradualidad es el concepto de fondo, es decir, implantar sobre la base de
avances sucesivos, a partir de negociaciones respecto a lo que realmente las
personas quieren y pueden hacer. Justamente una de las ideas centrales de este
mtodo es el buen manejo del cambio, donde se plantea que un sistema en
buen funcionamiento es una joya que debe tratarse con mucho cario. Debe-
mos asegurarnos que lo nuevo es efectivamente mejor, sin el encandilamiento
transitorio que tanto dao provoca.
1.3. ADAPTACIN Y PROFESIONALISMO
Entendemos la adaptacin del mtodo en varios sentidos: incorporar estndares,

normas de calidad y aprendizajes del medio (tal como los aportes del PMI), ac-
tualizacin permanente, flexibilidad para abordar todo tipo de proyectos y nego-
ciacin para tener una estructura organizacional adecuada.
Por profesionalismo aplicado al mtodo entendemos la conducta tica y visin
global que todo profesional debiera tener.
Veremos:
1. Adhesin a estndares y normas de calidad
2. Actualizacin y adaptabilidad del mtodo
3. Estructura para la gestin de proyectos
4. Aportes del PMI
5. tica y visin global del profesional
1. Adhesin a estndares y normas de calidad

El mtodo GSP existe para la buena gestin de proyectos y tiene una comple-
jidad que no puede ser reducida artificialmente, porque corremos el riesgo de
simplificar demasiado.
Adems de cumplir con la normativa interna y externa obligatoria, el mtodo
GSP es abierto y se enriquece trabajando con estndares formales o de hecho,
tales como: mapas de procesos globales, flujogramas de informacin con el
criterio curso normal de los eventos, normas ISO, orientacin a objetos, UML,
CMM, ITIL, SOA, PMI y otros (todas estas siglas y los conceptos asociados
son tratadas dentro del texto).
Son temas relacionados con la calidad de la informacin y la habilidad de re-
presentar adecuadamente el flujo de los procesos, as es que incluimos algunas
palabras al respecto.
Informacin de calidad
El ideal es que todo el manejo de la informacin sea en lnea y que los datos
sean capturados en la punta del proceso, evitando digitaciones. Adems, trabajar
todo lo posible en formato digital. Una buena idea es un programa del tipo pa-
perless (sin papel) que estn impulsando muchas organizaciones.
50 JUAN BRAVO C.
En el mtodo GSP se reconoce la importancia de la informacin y sus atributos:

oportuna, completa, confiable, creble13, relevante para el cliente, de calidad y
con la profundidad necesaria.
Curso normal de los eventos

El curso normal de los eventos es un nuevo criterio de la teora de modelos y
es central en la nueva generacin de tcnicas visuales. Lo veremos en detalle
en el captulo 3 (teora de modelos).
La idea general es tratar las excepciones como excepciones, sin darles el mis-
mo espacio visual que el curso normal de los eventos, en esto debe existir
armona con la realidad, donde lo ms habitual aparece ms y lo menos, me-
nos. Se aplica especialmente en flujogramas de informacin y casos de uso
expandidos.
Las excepciones se definen aqu como situaciones indeseables que perturban
el flujo, van como texto fuera del modelo cuando son relevantes.
La aplicacin del criterio curso normal de los eventos va junto a un nuevo
principio: el SPPP (Simplificar Procesos y Potenciar Personas) el cual aban-
dona la antigua, peyorativa e intil pretensin de construir sistemas a prueba
de tontos.
2. Actualizacin y adaptabilidad del mtodo

El concepto es que se planifica al comienzo y se contina planificando durante
todo el proyecto, por la imperiosa necesidad de mantener actualizadas las de-
finiciones, porque si slo existe el plan inicial, rpidamente pierde sentido por
la dinmica de la realidad.
Tenemos que aprender a elaborar buenos planes y mantenerlos actualizados,
considerar los riesgos, prevenir y confeccionar planes de contingencia.
Es bueno tener presente la conocida afirmacin de Murphy: si algo puede
fallar, fallar. Por lo tanto, si queremos que la aplicacin tenga xito, debe-
mos actuar con pragmatismo y adaptar el mtodo segn el tipo de proyecto. Es
lo que veremos a continuacin.
13
Un dato puede ser confiable pero no creble. Es que la confiabilidad pertenece al sistema y
la credibilidad al usuario, por eso decan: la mujer del Csar no slo debe ser virtuosa, sino
adems parecerlo.
Pragmatismo
Pragmatismo es hacer lo mejor que se pueda hacer para lograr los objetivos de
un proyecto, es lo opuesto al fundamentalismo, ms bien sera el complemen-
to, como en el yin y yang (la armona de los opuestos, el justo medio que pro-
clama Confucio).
No es sinnimo de improvisacin ni de liviandad en seguir un mtodo. Es
darse cuenta que en un momento del tiempo hay una bifurcacin mejor a la
establecida.
A propsito, Jeff Davidson, en su libro La Gestin de Proyectos (2001, pp.
2123), ofrece siete sugerencias para triunfar en la gestin de proyectos:
Aprender a utilizar eficazmente las herramientas de gestin
Saber hacer y recibir crticas
Ser receptivo a los nuevos procedimientos
Gestionar adecuadamente el tiempo
Ser eficaz al organizar reuniones
Perfeccionar la capacidad de tomar decisiones
Conservar el sentido del humor
En cada etapa se puede volver a una anterior para efectuar cambios o cancelar
el proyecto. No hay problema en la medida que sea por adaptacin a nuevas
circunstancias. Hay problema cuando el motivo es porque la etapa anterior no
se hizo correctamente.
Adaptacin segn tipo del proyecto

La idea es adaptar el mtodo a cada tipo de proyecto segn su tamao, nivel
de avance y otras condiciones, aunque sin llegar a saltarse etapas. Se puede
negociar las actividades que incluira y el alcance de las prcticas transversa-
les.
Es lo que explica Alfredo Weitzenfeld en su libro acerca de ingeniera de
software (2005, p. 35): Una creencia comn, aunque equivocada, es la exis-
tencia de un solo modelo de proceso aplicable a cualquier proyecto, pues el
modelo de proceso depende del tipo particular de proyecto, por ejemplo: pri-
mer proyecto de su tipo, segundo proyecto de su tipo, variacin de un proyec-
to, reescritura de software existente, creacin de software reutilizable y pro-
yecto de mejora o mantenimiento.
52 JUAN BRAVO C.
Esa es la idea de la figura 1-7, donde el mtodo de la organizacin es una base

de conocimiento que se adapta a cada tipo de proyecto particular, aunque, por
supuesto, mantiene un tronco comn.
Mtodo de la
Organizacin
Adaptacin
Aplicacin a un
tipo de proyecto
Figura 1-7. Adaptacin del mtodo a cada tipo de proyecto
Por ejemplo, la prioridad, puede llevar a tener una especie de Fast Track (va
rpida) en el caso de proyectos prioritarios por alguna contingencia o por ne-
cesidades estratgicas.
En el caso del tamao del proyecto lo primero es definir que se entiende por
tamao, por ejemplo, una posibilidad es trabajar con distinciones simples,
como estas, aumentando un orden de magnitud cada vez (aceptando que los
lmites entre tramos son difusos):
Proyecto pequeo: hasta US$ 100.000
Proyecto mediano: ms de US $ 100.000 y hasta US$ 1.000.000
Proyecto grande: ms de US$ 1.000.000 y hasta unos US$ 10.000.000
Ms all son proyectos muy grandes para la realidad de Latinoamrica y ms
bien escasos. Debera hacerse un esfuerzo metodolgico especial.
El mtodo debe adaptarse a cada realidad porque no es lo mismo un proyecto
pequeo que uno grande en trminos de cantidad de actividades, controles y
cantidad de participantes. Desde la gestin de procesos sabemos que el tama-
o determina nuevas formas de hacer las cosas.
3. Estructura para la gestin de proyectos

La buena gestin de proyectos tambin tiene que ver con una serie de instan-
cias de estructura organizacional o funciones.
Esto es lo que se denomina incorporar a la organizacin, es decir, llevar al
cuerpo, hacer carne, sumar a la estructura organizacional.
Algunas de estas instancias son:
rea de metodologa o UTP
rea de estudios
rea de desarrollo
Comit de Proyectos (CP)
reas relacionadas
Generalmente la responsabilidad de mantener los mapas globales14 recae en
algunas de estas reas. Por ejemplo, para cada mapa se indica el rea ms ade-
cuada:
Necesidades: estudios
Proyectos: desarrollo
Procesos: gestin de procesos
Retroalimentacin: estudios y/o desarrollo
Sistemas: sistemas
Se presenta a continuacin una breve descripcin de cada rea.
a) rea de metodologa o UTP

En el rea de metodologa trabajan los responsables del mtodo, quienes lo
actualizarn y difundirn.
Puede tener adems la forma de una UTP (Unidad Tcnica de Proyectos) que
se asegure de la formalidad metodolgica de cada proyecto, es decir, se incor-
pora aqu una labor ms bien operativa.
Tambin se le llama PMO (Project Management Office).
Eventualmente las reas de metodologa y de UTP pueden ser reas diferentes
y que trabajan coordinadamente.
14
Es la primera clave de la implantacin de mtodo de la seccin 1.2.
54 JUAN BRAVO C.
b) rea de estudios
El rea de estudios se dedica a procesar propuestas para necesidades y solu-
ciones. Se centra en las etapas de concepcin y factibilidad del mtodo GSP.
Es un rea que ayuda a generar mucha rentabilidad a la organizacin, porque
deja en evidencia la gran cantidad de proyectos que se pueden realizar. En el
fondo, ayuda a aprovechar el gran potencial que existe en la mente de todos
los integrantes de la empresa y que generalmente se pierde.
Uno de los principales entregables de esta rea son los planes de proyectos
cuando ya se cuenta con la autorizacin de desarrollo.
c) rea de desarrollo
Aqu se modelan e implementan los proyectos interna o externamente.
El rea de desarrollo se hace cargo de los proyectos aprobados y listos para
concretarse, cada uno cuenta con un plan de proyecto.
Se centra en las etapas de anlisis, diseo, implementacin y despliegue del
mtodo GSP.
Una exigencia es que el rea de desarrollo se coordine con un rea de asegu-
ramiento de calidad.
d) Comit de Proyectos15
Considerando que los proyectos sirven a procesos estratgicos, del negocio y
de apoyo en la organizacin, la figura del Comit de Proyectos (CP) introduce
una mirada sistmica y de negocios.
El CP gua el proceso de deteccin de necesidades y formulacin de proyectos
(etapas de concepcin y factibilidad del mtodo).
Tambin recibe la retroalimentacin de los proyectos en desarrollo.
Por supuesto, el CP requiere una frmula simple para administrar los com-
promisos vigentes e histricos, as como definir la forma de toma de decisio-
nes en casos de emergencia.
Al finalizar el proyecto, el CP cierra la carpeta del proyecto con un informe
que seale cmo fueron resueltas las necesidades originales (y actualizadas) y
15
Es cierto que al menos en Chile la figura del Comit est un poco desprestigiada. Con
este u otro nombre, el desafo es organizar un equipo de personas que acten con efectividad y
mstica en la toma de decisiones.
cmo se comportaron el plazo, costo y otras variables respecto al plan. El in-

forme lleva la firma de todos los actores relevantes.
Esto es independiente de los entregables por cada etapa cuya aprobacin de-
pende de la estructura que el mismo CP aprob.
e) reas relacionadas
En la gestin de proyectos se trabaja con reas cercanas, tales como gestin de
procesos, gestin de la calidad y sistemas.
4. Aportes del PMI

PMI son las siglas del Project Management Institute, una organizacin de cla-
se mundial que recoge las mejores prcticas para la realizacin de proyectos y
las presenta en documentos, uno de los ms relevantes es el PMBOK.
Se incluyen algunas palabras acerca de los aportes del PMI porque cada vez
con mayor frecuencia las empresas ms avanzadas requieren profesionales
preparados y certificados.
El mtodo propuesto por el PMI para la gestin de proyectos tiene muchos
puntos de encuentro con el mtodo GSP (recurdese que la GSP es una reco-
pilacin de las mejores prcticas) y es conveniente conocerlo16.
El PMI define 5 grandes fases para todo proyecto:
Iniciacin
Planificacin
Ejecucin
Control
Cierre
Similar a las prcticas transversales de la GSP, se definen nueve reas de co-
nocimiento: integracin, alcance, costo, tiempo, calidad, recursos humanos,
comunicaciones, riesgo y adquisiciones. Son grupos de criterios generales
para la buena gestin y administracin de proyectos.
Existe una organizacin local en la mayora de los pases de Latinoamrica,
son llamados Captulos.
Ms en www.pmi.cl www.pmi.com www.pmi.org.
16
As como deben ser conocidas las normas CMM, ISO 9000, Tick IT y otras. Adems de
estndares formales o de hecho tales como ITIL, Corba y MDA. Todos ellos los veremos en
el captulo segundo.
56 JUAN BRAVO C.
Gestin de calidad en proyectos

Es un tema fundamental abordado por todos los mtodos existentes, por ejem-
plo, en el PMBOK del PMI se lee:
La GCP (Gestin de Calidad en Proyectos) incluye los procesos requeridos
para asegurar que el proyecto satisfar las necesidades por las cuales fue
iniciado, contempla: planificacin de la calidad, aseguramiento de la calidad
y control de calidad.
La Planificacin de la calidad identifica qu estndares de calidad son
relevantes para el proyecto y luego determinar como satisfacerlos.
El Aseguramiento de la calidad incluye todas las actividades, planificadas
y sistemticas, implementadas en el marco del sistema de calidad, reque-
ridas para brindar confianza en que el proyecto va a satisfacer los estn-
dares de calidad relevantes.
El Control de Calidad implica verificar los resultados especficos del pro-
yecto para determinar si estos cumplen con los estndares de calidad re-
levantes e identificar maneras de eliminar las causas de los resultados in-
satisfactorios.
Se complementa con la definicin en de la norma ISO 9001:2000 Calidad es
la totalidad de las caractersticas de una entidad que le confieren la aptitud
para satisfacer las necesidades implcitas y establecidas.
5. tica y visin global del profesional

Un aspecto central de la totalidad que representa la GSP es la integridad del
profesional, especialmente en dos aspectos: comportamiento tico y visin
global, ambos considerados dentro de trabajar metodolgicamente.
Comportamiento tico
Respecto a la tica de los profesionales, Ian Sommerville seala (2005, pp.
12-13): Deben comportarse de una forma tica y moral responsable si es que
desean ser respetados como profesionales. No basta con decir que usted debe
poseer estndares normales de honestidad e integridad. No debera utilizar su
capacidad y sus habilidades para comportarse de forma deshonesta o de forma
que deshonre la profesin de la ingeniera del software. Sin embargo, existen
reas donde los estndares de comportamiento aceptable no estn acotados por
las leyes, sino por las ms tenue nocin de responsabilidad profesional. Algu-
nas de estas son: confidencialidad, no falsificar su nivel de competencia, dere-

chos de propiedad intelectual y uso inapropiado de los computadores.
Visin y accin global

Sucede a veces que el punto de partida de un proyecto es la definicin de una
necesidad computacional. En tal caso puede ocurrir que no existan otros pro-
fesionales para desarrollar la estrategia y los dems elementos del modelo de
negocios: personas, procesos y estructura organizacional. En tal caso, la
prctica ha sido que los mismos analistas encargados del desarrollo computa-
cional del sistema de informacin se encarguen del desarrollo completo del
modelo de negocios, al menos en el mnimo indispensable. Otra opcin es que
el analista avise de esta situacin para que otras personas se encarguen de cu-
brir lo que falta del modelo de negocios.
Un analista de sistemas debiera tener la capacidad de trabajar en la mesa
completa. Para ello es vital una formacin lo ms completa posible17.
Pasin por conocer la finalidad, el para qu

Por otra parte, todos los actores del proyecto deben tener claridad en objeti-
vos, resultados y propsito alineado.
Ms all de los entregables por etapa, es vital definir y conocer lo que se quie-
re lograr, los objetivos finales. Tener la vista puesta en el destino ayudar a
darle sentido a todas las actividades del proyecto.
Aconseja Davidson (2001, p. 33): Al tener una idea clara del final deseado,
todas las decisiones que se tomen respecto al proyecto irn en el mismo senti-
do con ms probabilidad de lograr ese final deseado.
17
Ver libro Anlisis de Sistemas.
58 JUAN BRAVO C.
1.4. ETAPAS GENRICAS
Ya vimos que las etapas son las distinciones principales del trabajo en el pro-
yecto. Hemos identificado siete: Concepcin, Factibilidad, Anlisis, Diseo,
Implementacin, Despliegue y Operacin. El acrstico es CFADIDO.
En la figura 1-8 (como una punta de flecha) se aprecia el esfuerzo promedio
estimado de cada una18. Ntese que a partir de la etapa de diseo se expande
el trabajo incorporando la especializacin de otros actores.
Estudio Desarrollo MC
C F A D I D O
Figura 1-8. Esfuerzo estimado por etapa en el mtodo GSP
Se aprecia tambin que las etapas estn agrupadas en tres grandes fases:
Estudio: donde se detectan necesidades y se proponen soluciones, el entre-
gable es un plan de proyecto, adems de los informes para trazabilidad. In-
cluye las etapas de concepcin y factibilidad.
Desarrollo: donde el plan se materializa. El entregable es la solucin com-
pleta y en explotacin. Incluye las etapas de anlisis, diseo, implementa-
cin y despliegue.
Mejora continua: donde la solucin ya en operacin se mantiene y perfec-
ciona. Contiene solamente la etapa de operacin, la ms extensa y que exis-
te mientras dura la vida til de la solucin, lo cual tambin debera estar es-
timado en el plan de proyecto.
Lo habitual es que cada fase sea realizada por equipos y reas diferentes.
18
Este promedio es parte del mtodo GSP, obtenido desde la duracin estimada de las etapas
en proyectos exitosos. Como todo promedio, es solamente un punto de referencia y no aplica
a casos particulares.
Qu tienen en comn la construccin de un edificio, el desarrollo de un sis-

tema computacional, la creacin de un nuevo producto o el rediseo de la es-
tructura organizacional? Todos aplican el ciclo de vida de un proyecto. Antes
de construir un edificio, alguien lo concibe y hace una evaluacin del proyecto
(como en las etapas de concepcin y factibilidad), una vez aprobado, viene la
fase de desarrollo, donde:
Se hace arquitectura, es decir, una solucin creativa que se representa en
maquetas y que resuelve los grandes qu del edificio, tal como veremos
que ocurre en la etapa de anlisis para las aplicaciones de software.
Se realiza la ingeniera de detalle, es decir, los planos detallados del edifi-
cio, tanto de la obra gruesa como de todos sus componentes (ascensores,
conductos elctricos, etc.) similar a los cmo que detalla la etapa de dise-
o en el desarrollo de software.
Luego viene la construccin, que en el mtodo GSP sera equivalente a las
etapas de implementacin y despliegue. Despus, en ambos casos, sigue la
operacin y las mejoras.
Es similar al desarrollo de un nuevo producto: alguien lo gesta y luego define
el producto, hace un diseo detallado, construye y da servicio postventa.
Es fundamental cumplir todas las etapas del mtodo para lograr xito en el pro-
yecto. Que esto no se confunda con rigidez, porque es posible volver a etapas
anteriores en un proceso de retroalimentacin producto de las necesidades del
proyecto. El objetivo es evitar errores que producirn dificultades cada vez ma-
yores en los siguientes pasos.
Aunque todo proyecto tiene las mismas etapas, su alcance puede diferir segn
las condiciones particulares del proyecto.
Son importantes algunos aspectos comunes a todas las etapas:
Revisar las prcticas transversales ms relevantes para la etapa.
Entre cada etapa es necesario lograr la autorizacin de inicio por el Comit
de Proyectos, el usuario lder u otra autoridad. Es preferible no comenzar si
no se cuenta con la aprobacin correspondiente. Esto puede parecer eviden-
te, sin embargo, es increble la cantidad de acciones que se inician sin estar
formalmente aprobadas, lo que trae muchas dificultades a la larga y no es
profesional. Generalmente esta actitud es un ejemplo ms de la enfermedad
ejecutivitis de una jefatura que quiere todo para ayer.
Revisar al inicio de la etapa que los documentos de entrada estn vigentes,
puede ser necesario actualizarlos (eventualmente rehacer la etapa anterior).
60 JUAN BRAVO C.
Una estimacin de este esfuerzo debe estar contemplada en la autorizacin

de inicio por parte de la autoridad.
La entrada a una etapa es el entregable de la etapa anterior, ms los entre-
gables de las etapas anteriores, porque es necesario conservar la trazabili-
dad del proyecto y es seguro que ser necesario realizar cambios en mode-
los que fueron resultado de una etapa anterior.
Veremos:
1. Concepcin
2. Factibilidad
3. Anlisis
4. Diseo
5. Implementacin
6. Despliegue
7. Operacin
1. Concepcin
Lo que da origen al trabajo en la etapa es un sntoma o una serie de sntomas
que producen molestias (tal como prdidas y atrasos). Decimos que es una
confusin porque no sabemos realmente cul es el problema de fondo.
El objetivo de esta etapa es concebir una necesidad, o un problema, definido
como una distancia, entre donde estamos y donde queremos estar. El proble-
ma de fondo nace desde la causa raz de la confusin. Es necesario aclarar la
confusin para obtener un enunciado validado, a eso le llamamos Problema.
La confusin es un conjunto de sntomas que toman forma de inquietud, dolor
o dificultad. Por supuesto, la confusin lleva implcita una oportunidad.
Concepcin
Entrada: sntomas o definiciones estratgicas
Entregable: una necesidad validada, cuantificada y en su contexto
Se da inicio a esta etapa porque hay algo que se quiere solucionar o una meta
que se desea alcanzar, hablamos genricamente de Problema, puesto entre
comillas porque al comienzo resulta pretencioso llamarle as, hay muchos
sntomas difciles de interpretar, ms bien lo que se tiene es una confusin o
una sensacin de molestia indefinida.
Entonces, la solucin de la confusin es el problema.
Yendo a los fundamentos conceptuales, la visin sistmica tiene especial pre-

dileccin por invertir tiempo en la adecuada definicin de los problemas, an-
tes de hablar de las soluciones.
De hecho, en teora de sistemas se dice que cuando uno descubre el verdadero
problema, el de fondo, la solucin est incluida!
Nos podemos ayudar en esta etapa con una serie de tcnicas, por ejemplo:
causa efecto de Ishikawa, los siete por qu, Pareto, meditacin, una noche de
sueo y otras.
Esta salida tambin puede provenir desde las definiciones estratgicas o desde
el mapa de necesidades de la organizacin, en ambos casos, se le considera
una necesidad.
Es posible saltarse esta etapa cuando una necesidad proviene de un proceso
de planificacin estratgica, desde el mapa de necesidades o desde la obligato-
riedad de implantar una norma? No, es preferible no saltarse la etapa aunque
la necesidad sea obligada, porque igual es necesario cuantificar19 y dar un
formato comn para pasar a la siguiente etapa.
Aqu debiera hacerse un anlisis estratgico desde el punto de vista de las ne-
cesidades el problema detectado es relevante para la organizacin? se ajusta
a la visin de negocios? son necesidades de la industria o de la competencia
relevante? Tal vez conviene dejar pasar el problema si no resuelve necesida-
des estratgicas (recurdese que todava no hablamos de soluciones).
Durante la concepcin tiene uso predominante el mapa de necesidades (ver
seccin 1.2, claves de la implantacin de mtodo).
Todo integrante20 de la organizacin puede detectar necesidades (ojal en un
formulario sencillo o una pantalla simple en el computador, no ms de una
pgina). Si se aprueba esa deteccin, el comit de estudios decide principal-
mente dos caminos:
a) Solicita un estudio ms detallado de la necesidad.
b) Solicita el cierre de la etapa de concepcin con el entregable que co-
rresponda.
19
Adems, nunca la decisin es obligada, por ejemplo, una opcin es que el dueo de la
empresa decida cerrarla. Suena utpico, sin embargo, tomemos una situacin real: la obligato-
riedad de la incorporacin de una norma de calidad a todas las empresas de capacitacin de
Chile en el 2006. Resultado? sobre el 70% de las empresas prefiri cerrar.
20
En el libro Anlisis de Sistemas, tercera y cuarta parte, se pueden encontrar mayores alcan-
ces acerca de la importancia de la participacin y de su impacto positivo en los resultados.
62 JUAN BRAVO C.
En ambos caminos recurre a profesionales especializados de dentro o fuera de

la organizacin.
Es tan importante la deteccin de problemas y la consiguiente generacin de
ideas de los colaboradores de terreno, que Isaac Getz y Alan Robinson, en su
libro Tus ideas lo cambian todo, afirman (2005, p. 30): Los empleados de
primera lnea, que trabajan en la frontera, estn mejor situados que los directi-
vos o los ingenieros para detectar los problemas y encontrar las soluciones.
Aunque no permanezcan todo el da all, a veces les bastan unos minutos para
tener una idea til.
Un informe tpico de esta etapa debera incluir los siguientes puntos.
mbito del problema
Identificar el problema21
a) Exponer la confusin (sntomas)
b) Buscar causas races y variables crticas del problema
c) Ensayar enunciados y obtener un enunciado validado
d) Cuantificar el problema: VA (Valor Actual) y VA social
2. Factibilidad
Lo que da origen al trabajo en la etapa es una necesidad de la organizacin,
viene dada desde la etapa de concepcin. El objetivo es obtener el plan de
proyecto de la solucin despus de un barrido creativo de muchas soluciones y
de un estudio comparativo de algunas de ellas.
Factibilidad
Entrada: una necesidad bien estudiada
Entregable final: el plan de proyecto
Entregables intermedios: La investigacin de soluciones y la evaluacin
comparativa de alternativas de solucin seleccionadas
La etapa de factibilidad22 tiene tres entregables secuenciales, se accede al si-

guiente despus de la toma de decisin por parte de la autoridad correspon-
diente. Suponemos un Comit de Proyectos (CP) en lo que sigue. La toma de
decisin sera despus de realizar cada una de estas acciones:
21
En el libro Anlisis de Sistemas se trata extensamente acerca del nfasis en el problema.
22
Un buen apoyo es el libro Desarrollo de sistemas de informacin, una visin prctica,
pginas 50 a 58. Tambin el libro Anlisis de Sistemas, Quinta parte.
a) Una investigacin creativa de muchas soluciones y propuesta de alter-

nativas a estudiar.
b) Una evaluacin comparativa de alternativas de solucin seleccionadas.
c) El plan de Proyecto de la alternativa seleccionada. Este plan considera
el programa de actividades (carta Gantt), la evaluacin tcnica, legal y
econmica, el VAN interno y social, el anlisis de riesgos, la descrip-
cin, el equipo de trabajo por etapa, el impacto estratgico, su historia,
la evaluacin comparativa, la justificacin de la necesidad y todos los
dems detalles del proyecto (comentamos tambin sobre su alcance en
la descripcin del mtodo GSP de la seccin 1.1).
Por supuesto, en cualquiera de esas acciones, el CP puede solicitar replantear
el estudio. Pueden presentar este formulario los evaluadores designados para
ello por el CP y que cuenten con las competencias necesarias.
Se revisa que cada alternativa evaluada est alineada con la estrategia de la
organizacin. Cada una incluye acciones respecto a las personas, procesos,
estructura y tecnologa, por supuesto, con diferente nfasis en cada una.
Usamos la palabra solucin porque es ms amplia y representativa que indicar
solamente rediseo de procesos o aplicacin computacional. Adems, lo ms
probable es que la solucin seleccionada resulte de una combinacin de varias
alternativas.
Creatividad aplicada
En esta etapa es vital la creatividad e inventiva aplicada en la bsqueda de
soluciones.
Se exploran amplias posibilidades de solucin al problema hasta decidir por la
frmula que se considere ms apropiada.
As evitamos la rigidez paradigmtica que se produce cuando desde el princi-
pio alguien cree que tiene la solucin.
Qu tcnica es buena para la invencin? Adems de las tcnicas indicadas en
la etapa de concepcin, se puede mencionar: tormenta de ideas, seis sombre-
ros para pensar, comparacin con otras organizaciones, bsqueda bibliogrfica
y consultora. Tambin la integralidad en el conocimiento es importante, tal
como sealan Getz y Robinson (2005, p. 32 ): Deducimos que es la diversi-
dad de conocimientos suficientes en una multitud de campos, y no el conoci-
miento excepcional en un solo campo lo que contribuye al surgimiento de
grandes ideas, y esto a travs de asociaciones inesperadas.
64 JUAN BRAVO C.
Por otra parte, existe un amplio abanico de tcnicas23 que pueden ayudar a
generar soluciones, por ejemplo: cadena de valor, just-in-time, flujos tensados,
Kanban, produccin flexible, costo objetivo, nuevas reglas del juego, salir del
pensamiento dicotmico, armonizar las economas de escala con otras opcio-
nes, logstica, un sistema de gestin de iniciativas y muchas otras.
Getz y Robinson agregan (2005, p. 53): Un sistema de gestin de ideas trans-
forma el potencial creativo en accin creativa y despierta esa fuerza formida-
ble que frecuentemente est dormida y desaprovechada en la empresa.
Algunas actividades de esta etapa son:
Conformar el equipo de trabajo
Revisar el problema
Describir el mbito de trabajo
Plantear un ideal de solucin
Plantear alternativas con amplia libertad
Definir un gran desafo
Identificar restricciones de la solucin
Seleccionar alternativas y objetivos generales
Evaluar cada alternativa
Evaluar las alternativas en forma comparativa
Decidir la opcin y los objetivos especficos
Elaborar el plan de proyecto
Algunas tcnicas en la etapa de factibilidad:
Evaluacin financiera
Tcnicas de evaluacin de programas y proyectos
Anlisis costo-beneficio para la evaluacin social de proyectos24
Idealizacin y creatividad
Planificacin de proyectos
Tambin se debe revisar cada prctica transversal para incluir en el plan de
proyecto. Recurdese que cada una aborda aspectos fundamentales de los pro-
yectos: incorporacin del cliente y de los proveedores, costos, plazos, comuni-
cacin, riesgos, completitud, son 28 en total.
23
Detalladas en el libro Gestin de Procesos.
24
En el libro Responsabilidad Social se profundiza en este tipo de anlisis.
3. Anlisis
Lo que da origen a esta etapa es el plan de proyecto aprobado. Es el inicio de
la ejecucin del proyecto.
El objetivo es plantear el modelo de negocios de la solucin y los requeri-
mientos correspondientes. El Qu.
Anlisis
Entrada: el plan de proyecto aprobado
Entregable: el modelo de negocios de la solucin con los requerimientos
principales
Se trata del anlisis integral de la solucin. Tambin es llamada ingeniera

bsica, ingeniera conceptual o arquitectura de la solucin.
Desde aqu surgen las definiciones respecto al modelo de negocios de la solu-
cin. Recurdese la metfora de una mesa: la cubierta es la estrategia y las 4
patas son: personas, procesos, estructura organizacional y tecnologa. Estas
definiciones ya estn avanzadas desde la etapa de factibilidad.
El modelo de negocios es la visin integral de la solucin y se apoya en un
concepto o idea fuerza. Debe estar bien sustentado en la estrategia de la orga-
nizacin, tal como se muestra en la figura 1-9.
Estrategia
Personas Tecnologa
Procesos Estructura
Figura 1-9. El modelo de negocios como una mesa

66 JUAN BRAVO C.
A diferencia del trabajo en la etapa de factibilidad, ms bien general y desti-

nado principalmente a cuantificar el volumen y tipo de trabajo, en el anlisis
se profundiza hasta decidir los qu de la solucin.
El modelo de negocios es una totalidad que debe ser conocida por todos los
integrantes del equipo de proyecto. Puede ser que slo un analista y un usuario
conciban el modelo. Tambin puede ser que se requiera un equipo de trabajo
de decenas de personas donde cada uno tiene la visin del todo, es decir, lo
que veremos a continuacin respecto a los elementos del modelo de negocios.
a) Estrategia
Es la estrategia del proyecto, con algunos contenidos como estos:
Misin, visin, valores, imagen y dems definiciones que se presentan
en el anexo 1, esta vez aplicadas al proyecto.
Un concepto o idea fuerza que gue la solucin. Tal como la integrali-
dad en el caso de la solucin Vendedor Integral de grandes tiendas, la
transparencia en una solucin arquitectnica o personificar con humor,
como en la campaa para ofrecer crditos de un banco en Chile, decan
Se te apareci marzo? Cuando alguien estaba tranquilamente en un
bote terminando sus vacaciones y se le apareca una persona (marzo).
Es importante destacar que la estrategia del proyecto debe estar sustentada y
alineada con el plan estratgico formal de la compaa, el cual fue vital en la
etapa anterior para darle el pase al proyecto.
b) Personas
Qu sucede con las personas en el modelo de negocios para este proyecto?
Cmo aportan? Cmo se capacitan? Cul es la gestin del cambio?
Hablamos de generar los requerimientos macro de la solucin respecto a: sen-
sibilizacin, capacitacin, empoderamiento, participacin, anticipacin, am-
biente de trabajo, forma de interaccin y otros.
Se requieren planes orientados al equipo de trabajo, por ejemplo: seleccin,
formacin, informacin, participacin, ambiente de trabajo, forma de interac-
cin. Tambin orientados a los usuarios de la solucin, incluso de los clientes
si es necesario (por ejemplo, cuando se introduce un tipo de apoyo automtico
para clientes de las sucursales de un banco y es necesario elaborar planes para
ensear su uso).
El trabajo con las personas considera dos aspectos vitales:
La cultura de la organizacin (lo que no se ve): formas de relacin, comu-

nicacin, tradiciones, creencias y mucho ms, en directa relacin con la es-
trategia (ver anexo 1).
Los detalles del ambiente (lo que se ve): tal como colores, aromas, sonidos,
y texturas, ms all de los aspectos de estructura.
c) Gestin de Procesos
Se requiere la descripcin del nuevo flujo de trabajo y de los procesos relacio-
nados, ya sean del negocio o de apoyo, involucrados en el mbito de trabajo
del proyecto.
Las tcnicas principales que se emplean son el mapa de procesos y el flujo-
grama de informacin.
Por ejemplo, para una empresa comercial, el mapa de procesos del mbito
venta al detalle se vera como en la figura 1-10, un zoom de una parte del ma-
pa de procesos global (ver figura 1-4).
Vender al detalle
Vender Despachar Cuadrar
Al Contado Inmediato
A Crdito A domicilio
Programar Entregar
Figura 1-10. Mapa de procesos

68 JUAN BRAVO C.
Se aprecia en la figura 1-10 que el macroproceso Comercializar incluye un proceso

operativo: Proyectar ventas, ms tres macroprocesos: Comprar, Vender al detalle y
Servicio postventa. Luego el macroproceso Vender al detalle se abre en otra cadena
donde hay otros macroprocesos y procesos operativos y as sucesivamente. Una de
los macroprocesos, Despachar, se abre a su vez en dos procesos, uno operativo, In-
mediato, y otro macro: A domicilio. Utilizaremos como ejemplo el proceso Despacho
inmediato en el siguiente modelo, el flujograma de informacin.
Todo mapa de procesos debe iniciarse con los requisitos que impone el cliente
y debe finalizar considerando el grado de satisfaccin logrado por l.
Flujograma de Informacin (FI)

Junto con el mapa de procesos se emplea la tcnica flujogramas de informa-
cin la cual veremos con cierto detalle en el captulo 3 para describir los
procesos operativos de la organizacin.
Podemos anticipar algunas caractersticas del FI25:
Sigue el criterio del curso normal de los eventos (al igual que los casos
de uso de UML) y el principio SPPP (Simplificar Procesos y Potenciar
Personas), ya indicados.
Tiene temporalidad
Est orientado a seres humanos, principalmente a los usuarios operati-
vos, para quienes debera ser autoexplicativo.
No es un diagrama de flujo computacional.
Debe caber en una pgina con letra de tamao legible.
Las actividades con doble lnea tienen alguna relacin con TI y luego
dan origen a los casos de uso.
Un ejemplo se muestra en la figura 1-11.
25
Ms detalle en el libro Gestin de Procesos, captulo 11 (si usted saba acerca de procesos
pero no ha renovado su conocimiento, digamos desde el ao 2000, es conveniente una nueva
inmersin, el cambio ha sido grande en esta materia).
PROCESO VENDER A CRDITO

CLIENTE REA DE VENTAS BODEGA
VENDEDOR CAJERO
Vender
Aprobar
en SC
CC
Formalizar
CC
Emitir OE CC
OE PROCESOS
DESPACHAR
SC: Sistema de Crditos, CC: Comprobante del Crdito, OE: Orden de Entrega
Figura 1-11. Flujograma de informacin
Si se est utilizando el desarrollo en espiral, el detalle a nivel de los flujogra-

mas de informacin podra ser parte de cada iteracin. El mapa de procesos
debera estar construido desde el principio y solamente se realizaran perfec-
cionamientos en cada vuelta de la espiral.
Se debe realizar el diseo de formularios asociados al detalle de los flujogra-
mas de informacin. Vlido para formularios manuales o computacionales.
Desde el modelamiento de los procesos surgen las definiciones hacia las otras
patas de la mesa: las personas, la estructura organizacional y la tecnologa.
70 JUAN BRAVO C.
d) Estructura organizacional
Se refiere a la definicin de la nueva estructura organizacional desde la mirada
que aporta el modelamiento de los procesos.
Los cambios van ms all de slo crear o eliminar cargos (agregar, mover o
sacar cajas del organigrama), alcanzan tambin a: planes y propuestas de ex-
ternalizacin, delegacin, trabajo en equipo, empoderamiento, ms o menos
supervisin, JIT, Kanban y SCM26, entre otros.
Hemos acuado el dicho: un pterodctilo no es una mariposa grande, en el
sentido que tienen una estructura muy diferente y apropiada a su tamao, asi-
mismo debe ocurrir con la organizacin, su estructura depende del tamao, del
rubro y de otros factores.
e) Tecnologa
En cuanto a la tecnologa, se requieren planes para incorporar o adaptar tecno-
logas consideradas en el proyecto: comunicacin, transporte, movimiento
automatizado de carga, despacho, almacenamiento, construccin, automatiza-
cin de oficinas, telefona interna y mucho ms. Debiera incluir precisiones de
propuestas, contratos, capacitacin y en general, formas de implementacin.
Luego, en la medida que se requiera una aplicacin computacional, se procede
a la ingeniera de requerimientos tecnolgicos, los cuales pueden ser plantea-
dos mediante la tcnica UML (la conoceremos en el captulo 6).
Un aspecto importante que debe quedar planteado en la etapa de anlisis es el
diseo general de la interfaz visual, tal como se observa en el ejemplo de la
figura 1-12, donde lo relevante es el esquema general de diseo de la interfaz,
el que luego se aplicar a cada pantalla particular.
26
Supply Chain Management, establece una cadena de valor con el medio llevando la visin
de procesos ms all de los lmites de la organizacin, hasta la cadena que llega al cliente
final, tal como el flujo interorganizacional que se forma para producir y llegar con la fruta
hasta la seora que compra una manzana en un supermercado europeo.
Figura 1-12. Diseo general de la interfaz
4. Diseo
Lo que da origen a esta etapa es el modelo de negocios de la solucin con los
requerimientos principales.
El objetivo es obtener el detalle de la solucin que propone el modelo de ne-
gocios, especialmente personas, procesos, estructura organizacional y tecno-
loga. Es el Cmo. Tambin se denomina Ingeniera de Detalle a esta etapa.
Diseo
Entrada: el modelo de negocios con los requerimientos principales
Entregable: el modelo de negocios con el detalle de requerimientos y la for-
ma de implementar
El diseo detallado consiste en dibujar planos, preparar modelos, identificar

los encargados, dimensionar los recursos financieros, definir el espacio fsico,
conocimientos requeridos, interacciones con el entorno, elaborar licitaciones y
contratos.
Esto es necesario incluso en proyectos pequeos.
72 JUAN BRAVO C.
Se incorpora formalmente en esta etapa el aporte de los especialistas en la

forma de trabajo conjunto con los analistas del proyecto.
Trabajo conjunto con los especialistas

Durante esta etapa se trabaja con profesionales especialistas en cada mbito
de la solucin. Principalmente lo relacionado con personas, procesos, estruc-
tura organizacional y tecnologa.
Ntese que se trabaja con y no se entrega o delega el trabajo a especialis-
tas, porque se trata de un trabajo conjunto.
En esta etapa normalmente se recurre a la asesora especializada, porque hay
que ir al detalle, probablemente empleando terminologa ms precisa. Algunas
sugerencias:
Trabaje en conjunto con el especialista hasta obtener el resultado deseado,
porque habr mucha labor de perfeccionamiento sucesivo, adems, una vez
que el especialista se retire, usted deber seguir manteniendo la solucin.
Evite la dependencia total y no se deje amedrentar por la erudicin, las
sofisticaciones o la especializacin. Un buen profesional no hace alarde de
sus conocimientos y tiene la capacidad de explicar materias complejas con
simplicidad.
Conserve la visin de conjunto y asegrese que los equipos de trabajo de-
dicados a diferentes partes de la solucin estn plenamente coordinados.
Ms importante que una supercreacin tecnolgica, de estructura o de flujos
de procesos, es desarrollar armnicamente la solucin.
Muchos proyectos han fracasado porque cada mbito de accin fue tomado
por separado.
En esta etapa del ciclo de desarrollo de un proceso se trabaja en la preparacin
detallada de cada elemento de la solucin y la forma de implementar, esen-
cialmente el diseo de:
El nuevo flujo del proceso con nombres de encargados y recursos
Procedimientos en detalle
El plan de capacitacin y de implementacin
Las nuevas labores a realizar
El ambiente fsico y cultural
La nueva estructura organizacional
La red de comunicacin
El detalle de equipamiento y software
Tambin desde el punto de vista de los riesgos:

Cul es el costo futuro de un mal diseo?
Cul es el costo futuro de no hacer diseo?
La parte del diseo computacional puede ser orientado a objetos, tal como se
plantea en el captulo 5 y mediante el uso de UML, tal como se indica en el
captulo 6.
5. Implementacin
Esta etapa nace desde el diseo de la solucin.
El objetivo es llevar a la prctica (tambin construir o realizar) la solucin
detallada que propone el modelo de negocios, armonizando todas sus partes
(estrategia, personas, procesos, estructura y tecnologa). Se trata de imple-
mentar el diseo en una aplicacin real, aunque en carcter piloto.
Implementacin
Entrada: el modelo de negocios con el detalle de requerimientos y la forma
de implementar
Entregable: el piloto de la solucin en buen funcionamiento y el informe
correspondiente
Algunas acciones de la etapa:

Las personas son capacitadas y reubicadas.
Se implementan las nuevas definiciones de los procesos.
Se aplica la nueva estructura organizacional.
Se instala la aplicacin de software, tal vez en mquinas diferentes.
Implementar significa llevar a la realidad el diseo, ya sean planos de un
edificio, plan de capacitacin, flujos de informacin, formularios, apoyo com-
putacional, una poltica acerca de las personas o el diseo de una estructura
organizacional.
Implementar tambin implica retroalimentar el diseo sobre aspectos no con-
templados con anterioridad.
Es necesario asegurar paso a paso que la solucin cumple su objetivo. La
flexibilidad es fundamental para efectuar los ajustes necesarios sobre el plan
original. La participacin de todos los interesados, as como el manejo del
cambio son vitales en esta etapa.
74 JUAN BRAVO C.
Se corren riesgos importantes en esta etapa, por ejemplo: el usuario ya no est

comprometido con el sistema, el tiempo de implementacin es muy largo, cam-
biaron las condiciones previstas en el diseo o la aplicacin es difcil de usar. En
fin, por muchos motivos la implementacin puede fracasar. Cmo mitigar es-
tos riesgos? La respuesta general es trabajar metodolgicamente. En particular,
asegurar la participacin del usuario y mantener la continuidad entre el diseo y
el uso de la aplicacin.
Otras actividades de esta etapa son:
Completar la documentacin.
Comunicar el avance a todas las personas relacionadas con el cambio en
los procesos.
Capacitar por niveles en forma oportuna, cuidando de no recargar a las
personas. Se requiere dimensionar el tiempo de cada integrante del equipo.
Una forma de motivar la capacitacin es fomentando el equilibrio de costos
entre todos los factores de incidencia en un proyecto. Hay empresas donde
se han efectuado inversiones de cientos de miles de dlares en equipamien-
to que ha quedado abandonado, debido a que el proyecto no contemplaba
gastar en capacitacin.
Especial relevancia tienen en esta etapa las siguientes acciones:
a) Negociar los compromisos

Parece un contrasentido, por qu negociar algo que ya est comprometido?
Porque la experiencia indica que este es un factor crtico de xito. Justo cuan-
do es necesario llevar los planes a la prctica, sucede que personas con que el
analista contaba estn destinadas a otras labores urgentes, espacios fsicos que
el analista saba que tendra, no los tiene o un equipo computacional prometi-
do no lleg. Supongamos adems que todo ello est bien justificado.
Para este tipo de supuestos debieran existir planes de contingencia.
Una forma de mitigar este problema es acortar el tiempo de ciclo de los pro-
yectos, puede ser a travs del desarrollo en espiral.
Otra forma es negociar con base en la nueva realidad, cmo? reiterando la
actualidad de los objetivos que dieron origen a los compromisos asumidos,
escuchando, intercambiando y buscando nuevas posibilidades creativas.
Es importante aclarar que negociar los compromisos no significa permisividad
ni tolerar el incumplimiento de las tareas, sino que se trata de la simple adap-
tacin a las contingencias del mundo.
b) Implementar los procesos y la tecnologa

Algunas recomendaciones para la implementacin:
Mantener comunicacin con todos los actores involucrados. Por ejemplo,
buenos resultados se han logrado con una reunin semanal breve con los
consultores que apoyan el rediseo, el equipo asesor en metodologa, el
equipo de trabajo de tecnologa, los usuarios, la direccin de la empresa y
proveedores especializados de elementos de comunicacin o infraestructu-
ra, entre otros actores.
Mostrar resultados pronto para mantener el nivel de entusiasmo por
ejemplo, a travs de los quick wins, una de las prcticas transversales
con la precaucin de no abusar de esa va rpida porque el grueso del redi-
seo y del apoyo computacional tiene que seguir el mtodo (el desarrollo
en espiral es recomendado).
Tener la flexibilidad para resolver con rapidez los inevitables problemas
que se producirn, es ideal tener una persona o un equipo de accin rpi-
da como forma de lidiar con la complejidad27. Que esto no se confunda
con improvisacin ni que sea una excusa para una mala planificacin, es
simplemente responder con variedad a la variedad natural del medio, aque-
lla difcil de predecir.
Contar con la dedicacin completa del lder28 y de los dems integrantes
del equipo de trabajo, especialmente en la atencin a los usuarios (puede
ser rotativa a diversas horas). Es crtico en la relacin con el usuario man-
tener verdaderamente puertas abiertas y despejados todos los medios de
comunicacin. Es preferible invertir en disponibilidad de personas que en
mayor equipamiento tcnico (si se puede ambas cosas a la vez, mejor).
Aplicar la estrategia tenaza, cuidar el corto plazo (la solucin preexistente)
y el largo plazo (el nuevo proyecto) a la vez.
c) Instalar el piloto
Una actividad vital de esta etapa es comenzar a operar la solucin en carcter
piloto, considerando un perodo de prueba integral con datos reales y en la
prctica.
27
El libro Anlisis de Sistemas aborda el tema de la complejidad de los sistemas.
28
El autor tuvo el privilegio de asesorar en una conocida empresa minera en un proyecto de
renovacin tecnolgica. Ocurri que justo en el momento de la implementacin el lder del
proyecto se fue de vacaciones fuera del pas El fracaso estuvo cercano y slo la excelente
disposicin de los usuarios y del resto del equipo lograron salvar la situacin.
76 JUAN BRAVO C.
Al mismo tiempo se avanza en:

Capacitacin de usuarios piloto, quienes luego pueden hacer de instructores
para los dems usuarios. Es importante la dedicacin completa de estas
personas al proyecto.
Comunicacin del avance.
Desde el punto de vista de la TI, la etapa contempla instalar el sistema en al-
guna mquina especfica y comenzar el uso real en una instalacin piloto.
Es importante no confundir la instalacin piloto con un prototipo. El piloto es
para certificar en la prctica que la aplicacin cumple con los requerimientos
explcitos e implcitos y que luego se replica para todos los usuarios. El proto-
tipo es para que el usuario vea un boceto de lo que quiere o para probar aspec-
tos especficos de la funcionalidad, luego se desecha (en el caso ms usado del
prototipo del tipo usar y botar).
Una recomendacin es asegurarse que efectivamente se usa lo nuevo. Y si lo
nuevo no se usa, tal vez sea por razones fundamentadas, lo que llevara a mo-
dificar el proyecto.
6. Despliegue
La etapa de despliegue nace desde la implementacin piloto de la solucin.
El objetivo es expandir la solucin generada hasta ser bien utilizada por todos
los usuarios previstos en el plan de proyecto.
Despliegue
Entrada: el piloto de la solucin en buen funcionamiento
Entregable: la solucin completa en buen funcionamiento y el informe co-
rrespondiente
Se trata de instalar la solucin completa que propone el modelo de negocios

en todos los puntos donde fue requerida. Esto implica que:
Los usuarios se capacitan, entrenan29 y reubican si corresponde (la
sensibilizacin ya debera estar lograda).
29
De acuerdo lo indicado en el libro Gestin de Procesos, se hace una distincin entre capaci-
tacin y entrenamiento. La capacitacin se orienta al desarrollo de competencias generales. El
entrenamiento (el training de F. W. Taylor) se refiere a la formacin en los procesos especfi-
cos en que trabaja la persona.
Los procesos rediseados son implementados.

La nueva estructura organizacional se pone en marcha.
El software se instala en las plataformas correspondientes.
La etapa de despliegue tambin contempla las siguientes acciones:
a) Revisar y actualizar elementos

Se trata de asegurar la disponibilidad de todos los elementos para difundir la
solucin tecnolgica:
Manuales de usuario, del sistema o ayudas en lnea.
Disponibilidad de equipamiento computacional.
Disponibilidad del software necesario.
Disponibilidad de licencias del software .
Disponibilidad de dispositivos de comunicacin.
Una base de datos con las respuestas a preguntas tpicas del despliegue.
Tambin de cada atencin a usuarios, quiz el mismo usuario pueda ingre-
sar y detallar su solicitud.
Se requiere una mesa de ayuda, con opciones de soporte telefnico, Intranet,
visitas en terreno y todo lo que se acostumbra en este caso.
Acerca de la capacitacin:
Programas detallados de capacitacin de usuarios piloto y monitores.
Programas detallados de capacitacin segn tipo de usuarios.
Comunicacin directa con los proveedores de tecnologa.
b) Incorporar a cada usuario

Aqu es necesario considerar al menos los siguientes elementos:
Instalar en forma personalizada en cada mquina.
Definir cuales elementos del sistema se instalan en el computador del usua-
rio y cuales en el servidor.
Asegurar que los dispositivos de comunicacin funcionan.
Disponer de un mapa de instalacin, para conocer configuraciones fsicas,
de software y de comunicacin.
lograr la dedicacin prevista de analistas, al igual que los instructores. Son
tantas las facetas de la aplicacin que se requiere toda su dedicacin.
Contar con la dedicacin de los ejecutivos para facilitar el despliegue.
Conviene enfatizar los aspectos de comunicacin, en todo sentido.
78 JUAN BRAVO C.
c) Capacitar a los usuarios

Capacitar segn tipos de usuarios: usuarios operativos que interactan con el
cliente tal como un cajero supervisores que deben tomar decisiones rpidas
con una mirada global de lo que sucede o ejecutivos que desean ver tenden-
cias en un sistema computacional.
Para realizar el despliegue debemos recurrir a muchas instancias de comuni-
cacin rpida y efectiva, sobre todo si se trata de llegar a cientos o miles de
usuarios, por ejemplo:
Revisar y actualizar el material (el cual debera estar preparado desde las
etapas de diseo e implementacin).
Desarrollar algn video explicativo cuando corresponda.
Utilizar Internet. Por ejemplo, a travs de e-learning los usuarios se conec-
tan libremente y existen niveles de evaluacin. Hay amplias experiencias
positivas con el uso de esta tcnica para la preparacin de cajeros y de mu-
chos otros tipos de usuarios operativos (mejora cuando se complementa
con algn porcentaje presencial).
Reuniones ampliadas de los gerentes dando la partida al proceso.
Tambin capacitar a los capacitadores y cuidar los elementos pedaggicos.
Un desarrollo impecable puede fracasar porque el especialista en informtica
no sabe transmitir el uso del software.
7. Operacin
La etapa de operacin nace cuando la solucin generada est siendo bien utili-
zada por todos los usuarios previstos en el plan de proyecto. Requiere de la
documentacin generada en todas las etapas.
Operacin
Entrada: la solucin completa en buen funcionamiento
Entregable: mantener la solucin en buen funcionamiento hasta que cumpla
con su vida til. La mejora continua es una actividad central.
El buen funcionamiento de la solucin debe lograrse en todo el modelo de

negocios (estrategia, personas, procesos, estructura y tecnologa). Por lo tanto,
la mejora continua opera en cada uno de sus elementos.
Cuando la solucin est en operacin comienza la mejora continua, la cual es

compatible con el rediseo programado30.
Mientras se trabaja en una vuelta del desarrollo en espiral (suponiendo que se
emplea esa tcnica), no aplica todava la mejora continua porque los casos de
uso que se van desplegando estn en desarrollo y todo el equipo de proyecto
con los usuarios est atento a los cambios. Es decir, mientras la solucin est
en desarrollo existe la infraestructura para abordar el cambio mayor y menor.
Algunas actividades indispensables durante la operacin son:
Una mesa de ayuda
Buena operacin de la aplicacin
Gestin de la calidad
Rediseo programado de la solucin
Algunas tcnicas del mejoramiento continuo

Algunas de las tcnicas31 ms efectivas para la mejora de la aplicacin son:
1. Las 3C
2. Benchmarking
3.
4. Flujograma de Informacin
5. Estandarizacin interna y externa
6. Efecto paraguas (el ejemplo personal)
7. Kanban (sistema visual)
8. Compensadores de complejidad
9. El momento de la verdad
10. Seis Sigma
11. Ciclo PDCA (Plan Do Check Act)
12. Las 5-S
13. Tormenta de ideas
14. Crculos de calidad
15. Diagramas causa-efecto (ver anexo 4)
16. Diagramas de Pareto (ver anexo 4)
Adems de una amplia gama de tcnicas cercanas a la estadstica.
30
En el libro Desarrollo de sistemas de informacin, una visin prctica hay alcances adicio-
nales bajo el ttulo Sistemas en Actividad.
31
Se presentan aqu solamente como una muestra de la profundidad de la mejora continua,
estn detalladas en el libro Gestin de Procesos, captulo 15.
80 JUAN BRAVO C.
Control de cambios
Se trata de establecer un procedimiento de aceptacin de requerimientos me-
nores en el mbito de la TI. Ya sea obtencin de nuevos informes o consultas,
es indispensable seguir el procedimiento general del rea de sistemas en cuan-
to a requerimientos menores. Un ejemplo de procedimiento se presenta en la
figura 1-13 y a continuacin como texto.
PROCESO: EMITIR UNA SOLICITUD DE CAMBIO MENOR EN APLICACIONES COMPUTACIONALES
USUARIO AUTORIZADO DEPARTAMENTO DE INFORMTICA REA DESARROLLO
JEFE INFORMTICA ANALISTA SUBCOMIT CAMBIOS
Asignar
SC Analista
Estudiar
impacto
Casos de
uso
Emitir
Abreviaturas: informe
SC: Solicitud de Cambio II
II: Informe de Impacto

PD: Plan de Desarrollo
Plan de
II
Desarrollo
SC
II
PD
PD
PROCESO PD
IMPLEMENTAR
Figura 1-13. Flujograma de informacin de control de cambios
Detalle del procedimiento de control de cambios menores:

1. Un usuario autorizado emite una solicitud de cambio menor.
2. El jefe de informtica la recibe y asigna a un analista
3. El analista realiza un estudio de impacto:
Lo presenta como un caso de uso
Determina impacto en la aplicacin y en otros sistemas
Calcula costo y recursos
Determina duracin
Entrega informe al subcomit de informtica (encargado de los re-

querimientos menores).
4. El subcomit de informtica, con la participacin especial del usuario, el
jefe de informtica y el analista que realiz el estudio de impacto, toma al-
guna decisin de cambio. Se le enva la solicitud con las indicaciones al
mismo analista que hizo el estudio.
5. El analista presenta el plan de desarrollo detallado del requerimiento al
jefe de informtica, incluyendo equipo de trabajo y costos, de acuerdo con
las indicaciones del subcomit de informtica.
6. El jefe de informtica aprueba.
7. El rea de desarrollo realiza el trabajo, incluyendo lo mismo indicado en
las secciones anteriores del ciclo de desarrollo, desde anlisis hasta des-
pliegue, aunque a una escala menor.
Por lo menos contempla:
Participacin del usuario en forma continua
Actualizacin de documentacin
Bsqueda de programas, bibliotecas, documentacin
Ordenamiento de manuales
Control de versiones de programas y de bases de datos
Anlisis, diseo e implementacin
Pruebas
Reentrenamiento
8. Todos los actores involucrados en el cambio se renen fsica o virtualmen-
te, escriben la experiencia relevante para efectos de retroalimentacin y
proponen perfeccionamientos al proceso.
82 JUAN BRAVO C.
1.5. PRCTICAS TRANSVERSALES
La administracin del proyecto considera una gran cantidad de acciones bien

coordinadas que ayudan a lograr el todo, en este caso, un proyecto exitoso. Es
un efecto sinrgico. Muchas de estas acciones influyen en algunas o en todas
las etapas del proyecto. A estas acciones que se repiten en diferentes etapas y
que han demostrado su efectividad en los buenos proyectos les llamamos:
prcticas transversales.
Estas prcticas se aplican en la fase de estudio y luego deben quedar incorpo-
radas en el plan de proyecto, en la forma de planes especficos.
Ordenamiento de las prcticas

Las prcticas se han ordenado de acuerdo con el criterio de mayor uso, co-
menzando por aquellas que indudablemente deben estar presentes en todas las
etapas. El resultado no seala precedencia.
Este criterio de ordenamiento no pretende juzgar niveles de importancia de
cada prctica, porque cada una tiene su espacio y quiz aunque su uso sea aco-
tado a pocas etapas, es vital en ellas.
Definir una poltica por cada prctica

Cuando hay una rutina de realizar proyectos y existe un proceso para el desa-
rrollo de proyectos en la organizacin, la forma de trabajar con las prcticas
transversales estar indicada en el mtodo, en tal caso, la revisin es ms ge-
neral. Por ejemplo, la prctica definir herramientas para la etapa estar defi-
nida como estndares corporativos o, al menos, como una poltica.
Es importante destacar:
La aplicacin de cada prctica transversal a un proyecto debera ser una
particularizacin de la poltica correspondiente.
La poltica de cada prctica debe estar siempre actualizada.
La participacin de todos es vital en el contenido de las polticas, porque es
lo que verdaderamente aplicar la organizacin
Llevar a la Carta Gantt

Fruto del anlisis de cada prctica, surgirn mltiples acciones a realizar que
debern incluirse en la carta Gantt. Ese es un resultado concreto de aplicar las
prcticas transversales.
Por ejemplo, en el control de cambios es necesario contemplar el tiempo de

negociacin del jefe del proyecto con el usuario, independiente de que el cam-
bio se realice o no.
Podra llegar a ser el 20% del presupuesto para los cambios? Puede ser, de-
pende de la organizacin, por eso es necesario disponer de una base de datos
de estndares numricos.
Base de datos de estndares numricos

Desde la base de datos de estndares numricos obtenemos el dato de cuanto
tiempo y costo presupuestar, por ejemplo, para el tiempo de negociacin de un
cambio.
Tambin en esta base de datos deberan incluirse estndares como estos:
Plazo mximo de proyectos.
Tasa de descuento y plazo para evaluacin de proyectos.
Valor hora de los clientes (hemos usado US $ 4 promedio en experiencias
de pblico masivo, tal como un hospital pblico).
Forma de un flujo de caja, por ejemplo, cuando incluir la inversin.
Costos de movimientos internos y externos de mercaderas.
Valor hora promedio de los ejecutivos, de los profesionales, mando medio
y personal operativo para efectos de cuantificar las propuestas, en particu-
lar el ahorro que se puede generar (recordar multiplicar por un factor tam-
bin estndar respecto al valor que cada persona agrega32).
Veremos:
1. Direccin del proyecto
2. Plan de la etapa
3. Exposicin de los planes
4. Retroalimentacin
5. El equipo de trabajo
6. Entrevistas
7. Comunicacin
8. Informes
9. Tcnicas
10. Herramientas de apoyo
32
Cada uno de nosotros es contratado en la organizacin por el valor que agrega respecto a
cumplir sus fines. Este valor, conservadoramente, es unas 5 veces la renta lquida. En todo
caso, la recomendacin del mtodo es multiplicar slo por 2 para efectos de obtener un costeo
conservador.
84 JUAN BRAVO C.
11. Trazabilidad
12. Quick Wins
13. Costos y duracin
14. Gestin de riesgos
15. Gestin de la calidad
16. Responsabilidad social
17. Insercin
18. Orientacin al cliente
19. Sensibilizacin
20. Capacitacin
21. Seguimiento
22. Cuidar la solucin anterior
23. Continuidad operacional
24. Plan de recursos fsicos del proyecto
25. Kill time
26. Control de cambios
27. Gestin del cambio
28. Gestin de proveedores
1. Direccin del proyecto

La direccin del proyecto es, tal vez, la prctica ms relevante para el xito
del mismo, por eso le hemos dedicado algunas lneas ms que a las siguientes.
La direccin del proyecto es una visin y accin de todas las actividades nece-
sarias para cumplir con lo prometido, particularmente en calidad, eficiencia,
eficacia, satisfaccin del cliente, plazos y costos. Contempla motivar, comuni-
car, alinear intereses y sobre todo, realmente liderar el equipo de trabajo.
La direccin del proyecto tambin considera buscar formas para superar las
expectativas y reconocer las mejores prcticas relacionadas.
Algunos facilitadores del trabajo del lder en el proyecto:
Dedicacin completa y visin clara de los objetivos del proyecto.
Apoyo de la alta direccin, nivel de autonoma adecuado y facilidad para
acceder a la toma de decisin fluida con relacin al proyecto.
Competencia en trabajo en equipo y liderazgo.
Espritu de equipo y el profesionalismo de su gente.
Gestin de los riesgos.
Comunicar el proyecto con frecuencia dentro y fuera de la empresa, inte-

grando a todo el equipo de trabajo. As perfecciona el mensaje, se aclara a
s mismo y gana en retroalimentacin.
Reencantar cada cierto tiempo a su equipo.
Cambiar las creencias limitantes en el equipo de trabajo, del tipo: no se
puede, el gerente no quiere y tantas otras.
Kendall y Kendall en su libro Anlisis y Diseo de Sistemas explican (2005, p.
66): Los miembros de un equipo se pueden motivar, al menos en parte, invo-
lucrndolos en la fijacin de metas. El simple acto de fijar una meta desafiante
pero alcanzable y de medir peridicamente el desempeo contra la meta esta-
blecida parece eficaz para motivar a los individuos. Las metas sirven como
imanes para atraer a los individuos a la consecucin de estas.
Siendo el liderazgo lo ms representativo de la direccin del proyecto, pode-
mos citar a Daniel Goleman, uno de los mejores expertos en relaciones huma-
nas, quien, en su libro Inteligencia social seala (2006, p. 393): Los mejores
jefes son personas confiables, empticas y capaces de sintonizar con los de-
ms, que nos hacen sentir ms tranquilos, apreciados e inspirados. Los peores,
distantes, difciles y arrogantes, hacen que nos sintamos, en el mejor de los
casos, mal; y en el peor, resentidos.
Un estimado amigo, Reinhard Friedmann, doctor por la Universidad de Heil-
delberg, consultor y autor de reconocidos libros, compara la labor del lder del
proyecto con la de un director de orquesta, en su libro Arte y gestin, una po-
tica para el gerente del tercer milenio, define (2007, pp. 41-43): Un equipo
de alto rendimiento es aquel que ha alcanzado los objetivos propuestos de una
manera excelente en trminos de eficacia y de eficiencia. El alto involucra-
miento va team building es similar al modelo de orquesta sinfnica y sus ca-
ractersticas son: la existencia de un director o coach; cada miembro tiene una
posicin fija; cada miembro coordina su parte con el resto del equipo y exige
una partitura que requiere mucho ensayo para su correcto funcionamiento.
Ntese las similitudes con dirigir un proyecto mientras Reinhard detalla el rol
de director de la orquesta (idem): El director ha de escoger los instrumentos y
a los msicos, compenetrarlos en la tarea y dirigir la realizacin de la obra
(dar el tiempo y marcar el comps). De acuerdo a la etapa de desarrollo del
equipo tendr que elegir el estilo de conduccin (participativo, directivo, coa-
ching, etc.). Su tarea central consiste en sincronizar ptimamente una serie de
variables (composicin y miembros del equipo y procesos) que condicionan el
xito del equipo durante las etapas de su desarrollo. stas constituyen el mate-
rial sonoro de la composicin. El xito del equipo resulta de la consonancia
86 JUAN BRAVO C.
de los diversos elementos (sinergia), vale decir: de su buena orquestacin. Del

director se exige la habilidad de escucha activa para detectar eventuales diso-
nancias y corregirlas a tiempo. Cualquier desajuste (misfits) marca errores y
prdidas de eficiencia.
Luego Reinhard muestra experiencias de importantes instituciones que para
tener mejores lderes de proyecto les ofrecen talleres de entrenamiento donde
tienen la oportunidad de dirigir una orquesta. Agrega que as pueden: vi-
venciar en carne propia que la armona de un equipo slo se da cuando cada
uno de los integrantes conserva su individualidad y, a la vez, sabe coordinar y
comunicarse armnicamente con el resto de los integrantes del equipo.
Y sus aportes no terminan aqu, porque luego sale a escena el Jazz, donde, a
diferencia de la sinfona, lo que se privilegia es la improvisacin. Aunque en
estricto rigor es una improvisacin educada, de hecho, los mejores improvisa-
dores son profesionales que estudian mucho. Un mensaje de fondo es que se
puede aprender a improvisar.
La conclusin de los aportes de Reinhard es armonizar la preparacin de la
sinfona con la improvisacin del Jazz, porque siempre aparecern contingen-
cias en los proyectos. Contingencias de verdad, no situaciones que eran prede-
cibles y que se encuentran tratadas en los mtodos de gestin de proyectos.
2. Plan de la etapa
Una vez que est decidido realizar una etapa, es necesario revisar y detallar el
plan de la misma (duracin, encargado, costo, documentos de licitacin que
ser necesario construir, entre otros). Incluso, tal vez sea necesario replantear
el plan general del resto del proyecto Son reestimaciones a la luz del avance.
Se hace una programacin detallada de la etapa, con fechas precisas e inclu-
so horarios en algunos casos. El plan de la etapa puede ser el nico que existe,
como en la concepcin y factibilidad, porque todava no hay proyecto.
Es conveniente considerar que en cualquier etapa se puede cancelar el proyec-
to o volver a una etapa anterior, por ejemplo, si se detect algo no considerado
o si hubo un cambio relevante en el entorno para el par problema-solucin.
Una recomendacin, asegrese que lo definido en la etapa anterior sigue sien-
do vlido, especialmente si pas mucho hasta la siguiente.
Por supuesto, el plan de la etapa debe ser aprobado por autoridad.
3. Exposicin de los planes

Exponer el plan de trabajo a todos los actores relevantes, al interior y exterior
del equipo de proyecto para ayudar en la coordinacin del proyecto.
Es conveniente porque surgirn muchas sugerencias para lograr xito en el
proyecto. En el fondo, lo ms importante es la retroalimentacin que se logra.
Aqu tienen especial relevancia las competencias del equipo de trabajo para
exponer a un grupo de personas en forma clara y precisa.
Son competencias de comunicacin, personales en cuanto a desarrollar un
mensaje y tcnicas en cuanto al uso de herramientas, tal como un software
tipo PowerPoint, un proyector o un puntero lser.
La exposicin es uno mismo. Al comienzo la atencin est puesta en cmo
uno se ve, habla, mueve, gesticula, viste o entona, es el efecto de la primera
impresin. Para comenzar: hay que disfrutarlo, sino, para qu estamos ah?
Es indispensable la fuerza, la pasin y la energa al transmitir el mensaje.
Algunas recomendaciones: 1) preparacin del tema, 2) presentacin personal,
3) buena diccin, 4) lenguaje formal, 5) manejo del tiempo, 6) llegar al menos
media hora antes, 7) cumplir los tiempos.
4. Retroalimentacin
Se trata de revisar el resultado logrado respecto a lo planeado para la etapa. Se
comunican los resultados al resto del equipo y las conclusiones quedan dispo-
nibles para toda la organizacin.
Practicar la retroalimentacin es un proceso continuo de preguntarnos: Qu
aprendimos? Qu aprend? Si tuviramos que hacer nuevamente el mismo
trabajo de la etapa, cmo lo haramos? Qu cambios introduciramos? Tam-
bin contempla preguntarnos si se estn resolviendo las necesidades originales
actualizadas.
Retroalimentar es una prctica que debe incluirse tanto al trmino de cada
etapa como al completar el proyecto.
El espritu de este punto es detenernos, reflexionar, aprender y seguir.
5. El equipo de trabajo
La prctica ms habitual es formar un equipo de trabajo en cada etapa, mante-
niendo un ncleo de participantes permanentes durante el proyecto.
88 JUAN BRAVO C.
Se trata de formar un equipo integrado por especialistas en rediseo de proce-

sos, informtica, usuarios ejecutivos y consultores se gana el efecto con-
sultor, una mirada externa fresca. Debe estar claro quin es el director del
proyecto. La participacin de los ejecutivos es vital.
Es necesario incorporar a clientes y proveedores en este equipo de trabajo.
Normalmente se designa un usuario lder (representante de los dems usua-
rios) y usuarios clave de cada rea a redisear. El usuario lder trabaja coordi-
nadamente con el jefe del proyecto.
Lo ms probable es que en cada etapa cambien integrantes del equipo de tra-
bajo segn sus competencias.
Una faceta del equipo de trabajo es que debe funcionar realmente como un
equipo y aqu juega un rol fundamental el lder. Dice Goleman (2006, p. 391):
El liderazgo se resume a una serie de intercambios sociales en los que el lder
tiene que conducir a las emociones del otro a un estado mejor o peor. En los
intercambios de gran calidad, el subordinado siente la atencin y la empata de
su lder, su apoyo y su actitud positiva. En las interacciones de baja calidad, se
siente aislado y amenazado.
6. Entrevistas
Una prctica frecuente en los proyectos es la realizacin de entrevistas a usua-
rios, ejecutivos y personas de fuera de la organizacin. La finalidad principal
es levantar informacin til al proyecto y se complementa con otras tcnicas
(encuestas, informes de consultora o de auditora).
Al comenzar la etapa debe elaborar el plan de entrevistas. Luego debe prepa-
rar cada entrevista, anticipando lo que se pueda utilizar. Vital es la buena eje-
cucin y el anlisis posterior para incorporar las conclusiones al proyecto y
cumplir los compromisos adquiridos.
Durante la entrevista lo principal es crear ambiente, es decir, un clima de con-
fianza con una actitud serena que surge de la puntualidad, preparacin y pre-
sentacin (las tres P de las entrevistas).
Kendall y Kendall agregan (2005, p. 66): Necesita pensar detalladamente en
las entrevistas antes de hacerlas. Visualice por qu las va a hacer, qu va a
preguntar y qu es lo que a su juicio har que esta entrevista tenga xito. Asi-
mismo, debe pensar cmo lograr que la entrevista sea satisfactoria para el
individuo al que entreviste.
7. Comunicacin
Se trata de comunicar el proyecto al interior y exterior de la empresa, con
mensajes adaptados segn el tipo de interlocutor (no es lo mismo comunicar a
la direccin que a los funcionarios administrativos o a los clientes). Es conve-
niente comunicar mucho.
Esta sola actividad implica disponer de horas de especialistas en comunica-
cin, con dedicacin parcial o total segn la envergadura del proyecto.
Incluye la formacin de diferentes tipos de mesas de ayuda segn la etapa del
proyecto.
Se puede comunicar en el mbito de problema o de la solucin, es una activi-
dad completamente transversal.
8. Informes
Cada etapa tiene uno o ms entregables que deben quedar registrados en in-
formes. En el plan detallado de cada etapa deben quedar resueltos aspectos
tales como: quin redacta qu informe? A quin se le entrega?
La prctica genrica es documentar e implica el desarrollo de las competen-
cias mnimas en el equipo de trabajo (que es preferible no dar por adquiridas),
por ejemplo: redaccin, ortografa y capacidad de sntesis. Al menos, la habi-
lidad de leer.
Por supuesto, debiera documentarse al mismo tiempo que se avanza en la eta-
pa, evitando postergar.
Es necesario establecer un modelo de documentacin de las aplicaciones.
9. Tcnicas
Se trata de seleccionar las tcnicas a emplear en cada etapa del proyecto, por
ejemplo, para efectos del anlisis, realizar la ingeniera de requerimientos con
UML, utilizar mapas de procesos globales o flujogramas de informacin con
el curso normal de los eventos.
Hoy ya sabemos que tcnicas emplear en cada etapa de un proyecto, sin em-
bargo, la variedad es tan amplia que la organizacin debe definir algunas.
90 JUAN BRAVO C.
10. Herramientas de apoyo

Se trata de seleccionar herramientas de apoyo a las tcnicas que se usarn en
cada etapa. Tambin llamadas CASE (desarrollo apoyado por computador),
por ejemplo, de tipo33: MS Project, Visio, Aris, Corporate Modeler, M1, Z4,
Rational o ERWIN. Lo importante es que la organizacin tenga una definicin
al respecto.
Pueden ser ayudas en la construccin de un prototipo, flujo de un proceso,
caso de uso, interfaz visual, modelo conceptual y cualquier otro modelo.
Tambin para cooperar en la planificacin estratgica, el control de costos y la
evaluacin financiera, entre otras posibilidades.
Se pueden emplear diferentes herramientas de apoyo en cada etapa, esa es hoy
la realidad. Sin embargo, existe una tendencia a unificar en una sola o en un
pequeo conjunto de herramientas bien integradas, la ventaja es la facilidad
para acceder a los modelos, su actualizacin y la trazabilidad.
Una aspiracin de las herramientas de apoyo es que acten a nivel del ciclo
completo, incluyendo la generacin de cdigo cuando corresponda.
11. Trazabilidad
Trazabilidad se entiende en dos sentidos:
a) Trazabilidad de las transacciones, donde se sigue la pista a la actualizacin
de los datos. Se usan transacciones formales y presentes desde la creacin
de un dato, por ejemplo, como se ha movido el saldo de la cuenta corriente
de un cliente.
b) Trazabilidad del desarrollo, donde se sigue la pista a cada requerimiento
implementado, como fue diseado, el anlisis que le dio forma, la evalua-
cin que lo aprob, quien lo gest y por qu.
Es como la trazabilidad de la fruta, donde el cliente de un supermercado en
Europa puede saber que el durazno que adquiri viene de Chile (importador,
exportador o puerto) y de un lote especfico con detalle del packing, fertilizan-
tes y suelos.
33
MS Project y Visio de Microsoft, Aris de SAP, Corporate Modeler de Case Wise, M1 y
Rational de IBM, Z4 de Tuxpan, ERWIN Data Modeler de Computer Associates.
12. Quick Wins

Se llama Quick Wins literalmente ganancias rpidas o Hits a cambios de
breve diseo e implementacin y que tengan un alto nivel de impacto en el
avance de la solucin. Son entregables de accin rpida, generalmente accio-
nes simples que quedaron en evidencia desde las primeras conversaciones.
Gracias a estas acciones tempranas se ven resultados a corto plazo y se alienta
tanto a los operadores del proceso como a la direccin a continuar con el pro-
yecto, renovndose la motivacin y manteniendo la atencin en el proyecto.
Por supuesto, no se puede abusar de estas ganancias rpidas. La solucin no
termina ah, el objetivo es terminar bien el proyecto.
13. Costos y duracin

Se calculan costos y duracin tanto de la etapa como del proyecto completo.
Es importante y valiente ver la realidad de lo que est sucediendo y reestimar
si es necesario. No es cambiar por cambiar sino que adaptar el avance del pro-
yecto a la realidad de hoy (imposible de predecir en su totalidad cuando se
elabor el plan de proyecto). Lo opuesto es cerrar los ojos y tratar de cumplir
un plan que tal vez no tiene sentido. Ah... adems, verifique que los fondos
para el proyecto existen.
Se calculan costos cada vez ms precisos del proyecto en tres etapas: factibili-
dad, anlisis y diseo.
Es necesario incluir costos ocultos tales como la misma planeacin de la eta-
pa, las reuniones de coordinacin, la negociacin con la direccin y las expo-
siciones de avance, entre otros.
14. Gestin de riesgos

Se trata de detectar riesgos y elaborar un plan para mitigarlos y/o traspasar-
los. Por ejemplo, en la concepcin: conviene abordar el problema? A veces
el sentido comn (y los amplios estudios de Maturana, Echeverra, Varela y
otros) indica que el solo hecho de sealar un problema ya crea una expectati-
va. Es el momento adecuado? Y si no se llega a una conclusin? Y si ex-
cede los plazos o costos?
Cada etapa tiene sus propios riesgos que deben ser atendidos: una tecnologa
difcil de obtener, especialistas escasos, cambio de prioridades, atrasos, costos
excedidos, incumplimiento de proveedores, tecnologa difcil de implementar,
92 JUAN BRAVO C.
usuarios que no desean el nuevo proceso, apego irrestricto al plan o simple

agotamiento.
Se han identificado ms de cien riesgos asociados a los proyectos, lo mnimo
es tener formas de detectar, transferir y/o neutralizar.
Una frmula para priorizar riesgos34 es: R = C x P. La magnitud del riesgo (R)
se obtiene multiplicando el costo si ocurre (C) por la probabilidad de ocurren-
cia (P). Tambin ofrece un lmite a la inversin en el riesgo para mitigar o
traspasar.
15. Gestin de la calidad

Cada etapa del proyecto debe llevar el sello de la gestin de la calidad, al me-
nos en:
Planeacin, aseguramiento y control de calidad.
Aplicar o definir estndares de gestin y determinar como se cumplen.
Tan importante es la calidad que a veces se crea un rea de aseguramiento de
la misma tpicamente llamada QA35 para ayudar a elaborar el plan de
calidad del proyecto, para verificar el proceso de produccin y validar los en-
tregables de cada etapa.
Existe todo un aporte de la gestin de calidad aplicada a proyectos, con una
planificacin, control y seguimiento.
16. Responsabilidad social

Veremos algunos elementos de la Responsabilidad Social (RS) aplicada a
proyectos.
Es necesario manejar bien el temor de las personas de que este tipo de proyec-
to las dejar sin empleo.
Establecer un pacto social o una alianza estratgica con los colaboradores es
un excelente camino que han aplicado empresas exitosas. Todos cooperan con
el cambio necesario y la empresa no despide por motivo de estos proyectos.
No es justo ni necesario despedir slo porque queremos hacer las cosas de otra
forma. Se puede evitar generando vinculaciones con otros proyectos en un
esquema de vasos comunicantes porque hay infinitas iniciativas que se pueden
34
En el libro Gestin de Procesos hay un anlisis de la gestin de riesgos.
35
Quality Assurance, traducida como aseguramiento de la calidad.
desarrollar, una parte libera recursos y la otra requiere recursos, es cuestin de

unir una cosa con otra, otra aplicacin de visin sistmica.
Se requiere mantener al menos el nivel de servicio previo al inicio del proyec-
to mientras este dure, trabajar con eficiencia, alinear intereses, cuidar el en-
torno y la comunidad, organizar el trabajo seguro y el buen trato, tanto de los
profesionales internos como de contratistas, evitando discriminar entre ellos,
evitar la improvisacin, hacernos responsables, prevenir en todo los riesgos y
calcular el VA (Valor Actual) social, que refleja el efecto del proyecto en el
medio, que debe dar positivo.
La RS alcanza a todas las interacciones internas y con el medio: integrantes,
clientes, proveedores, comunidad, gobierno y muchas otras. Destaquemos dos
en especial, el medio ambiente y la naturaleza del negocio, el cual debe ser de
til a la sociedad. Cada interaccin debe ser aprobada, no basta con un buen
promedio general.
En esto el mtodo GSP puede apoyar especialmente con el nfasis en la ges-
tin de las ideas, en capitalizar toda la creatividad de las personas.
17. Insercin
El problema y la solucin deben insertarse en un todo mayor rea, empresa
o industria para comprender y alinear los intereses.
Insertar es observar cmo se relaciona el problema o la solucin con otros
problemas o soluciones dentro y fuera de la organizacin y as transferir recur-
sos, alinear intereses, optimizar adquisiciones y manejar el aspecto poltico en
cuanto al mejor momento de plantear el cambio.
Se debe monitorear la contribucin actualizada de la finalidad del proyecto a
la estrategia de la organizacin.

Ya sea en el problema o la solucin, la orientacin al cliente es central para
lograr la conclusin exitosa del proyecto.
Es vital escuchar y apreciar lo que es realmente importante para el cliente, en
lugar de nuestra habitual tendencia a la autorreferencia, cuando creemos saber
lo que el otro quiere. Por supuesto, generalmente nos equivocamos.
Ya indicamos que por cliente hablamos del cliente externo, quien paga a todos
en la organizacin.
94 JUAN BRAVO C.
19. Sensibilizacin
Es el manejo del cambio en relacin a la emocin. El objetivo es encantar a
los afectados.
La idea es aplicar lo aprendido acerca de encantar a todas las personas de de-
ntro y fuera de la organizacin que tienen relacin con el proyecto.
Es diferente a comunicar y capacitar, aunque se complementa con esas prcti-
cas. Se aplica mediante anticipacin, participacin, talleres ver prctica
Quick Winsy otras formas creativas (poleras, lpices, etc.)
20. Capacitacin
La capacitacin del equipo de proyecto debiera ser continua durante todo el
proyecto. Adems, es una excelente oportunidad para lograr acuerdos en los
mltiples detalles de la necesidad y del proyecto.
El diseo de la actividad es muy importante: lugar, objetivos, duracin, rela-
tor, extensin y muchos otros aspectos deben estar bien pensados.
La capacitacin de los usuarios es vital en el proyecto. Por supuesto, es dife-
rente segn tipos de usuarios y puede tomar variadas formas (la recomenda-
cin es una combinacin de posibilidades):
Puede ser realizada por relatores profesionales, por siclogos preparados
en los mensajes del proyecto, por el equipo de proyecto, por usuarios que
actan como monitores, por ejecutivos, etc
Puede emplear variados medios creativas: Intranet, e-learning, Internet,
clases presenciales, videos, teleconferencia, etc...
Puede comenzar en etapas tempranas del proyecto, se programa en detalle
en cada etapa.
No tiene que ser extensa, aunque s bien realizada, con preparacin en peda-
goga de quienes van a capacitar. En especial, lo que ya sabemos de armonizar
las variadas dimensiones del ser humano: espiritual, intelectual, emocional y
corporal.
21. Seguimiento
Realizar seguimiento es llevar control del avance del proyecto completo y en
cada etapa. Se monitorean variables crticas del proyecto (costos, plazos,
hitos, satisfaccin de usuarios, calidad) Desde este punto de vista tiene rela-
cin con el diseo de indicadores.
Es necesario que exista algn nivel de control centralizado y que el equipo de

direccin del proyecto tenga la informacin inmediata del avance.
22. Cuidar la solucin anterior

Cuidar la solucin anterior significa que al mismo tiempo que se trabaja en la
nueva solucin, se aplica alguna forma de continuidad de lo existente. Incluso
se sigue realizando mejora continua de la antigua solucin.
En algunas experiencias incluso se designa un gerente de continuidad, al
mismo tiempo que otro gerente se encarga del proyecto de cambio.
23. Continuidad operacional

Se refiere a incorporar en el proyecto los mecanismos que permitan la conti-
nuidad de las operaciones cuando el proyecto est en funcionamiento, ms all
de slo tener planes de contingencia. La idea de fondo es evitar la contingen-
cia, prevenir.
Objetivos del plan de continuidad operacional:
Crear conciencia en el equipo de trabajo y en los usuarios acerca de la pre-
vencin y de las implicancias de una contingencia en la continuidad de los
productos y servicios.
Minimizar interrupciones a las operaciones del negocio y limitar la severi-
dad de la interrupcin.
Minimizar prdidas financieras.
Agilizar la restauracin de los servicios y reiniciar operaciones crticas en
un tiempo breve.
Asegurar a los clientes la proteccin de sus intereses y mantener la buena
imagen de la empresa.
La continuidad operacional est relacionada con la seguridad de las operacio-
nes y la calidad de la informacin.
24. Plan de recursos fsicos del proyecto

El plan de recursos fsicos se refiere a disponer oportunamente de los elemen-
tos que se requerirn en el proyecto: equipos computacionales, redes, licen-
cias, escritorios, espacio fsico, baos, comedores y otros.
Un trabajo bien hecho en materia de recursos fsicos tendr su nivel de in-
fluencia en la moral del equipo de trabajo y en los plazos.
96 JUAN BRAVO C.
25. Kill time

Un Kill time se define como momento de cancelacin del proyecto.
Es decir, bajo qu condiciones conviene cancelar el proyecto, lo cual queda
definido en el plan de proyecto y se revisa al inicio de cada etapa.
Por ejemplo, en el contexto de que no hay un cambio importante en las reglas
del juego de una inversin, se define que el proyecto se cancelar si se consu-
me el presupuesto completo ms un 20% o si la duracin exceder en un 25%
al tiempo asignado. Es sabio, porque si el proyecto gasta mucho ms del pre-
supuesto o su duracin es excesiva, lo ms probable es que el costo llegue a
ser prohibitivo para la organizacin o que nunca termine.
Asumir a tiempo la prdida acota el efecto a un nivel soportable por la organi-
zacin. Esperar puede poner en riesgo su existencia.
26. Control de cambios

El control de cambios tiene dos interpretaciones: durante el desarrollo y du-
rante la operacin.
Durante el desarrollo del proyecto son cambios en las especificaciones. No
hay problema si son necesarios, el mtodo debe contemplar la facilidad de
incorporacin cambiando la serie de modelos que da origen a la solucin. Si
se emplea desarrollo en espiral se facilita la incorporacin de los cambios
porque normalmente se incluyen en la siguiente vuelta de la espiral.
Durante la operacin se refiere a un procedimiento para cambios menores que
incluso puede enlazar con la mejora continua de la solucin36.
27. Gestin del cambio

Esta prctica se refiere a la gestin del cambio en las personas. Est hacia el
final porque varios de los elementos de la buena gestin del cambio estn con-
templados en las prcticas anteriores, tal como direccin del proyecto, sensibi-
lizacin, capacitacin, exposiciones, entrevistas y responsabilidad social.
Vital es incorporar en forma personalizada a todos los actores relevantes tal
como seala F. W. Taylor en su administracin cientfica, tipo Coaching dir-
amos hoy distinto a la capacitacin masiva.
36
En la etapa de operacin descrita en la seccin 1.4 se present un proceso de control de
cambios.
La coherencia del equipo interno es vital. Su propia predisposicin al cambio

ayudar en la moral de los usuarios.
28. Gestin de proveedores

Cada vez es ms frecuente que en los proyectos participen personas y empre-
sas externas a la organizacin. Es indispensable una buena gestin con ellos
para el xito del proyecto, por ejemplo, claridad de los objetivos de su trabajo,
condiciones igualitarias para trabajadores propios y de contratistas y requeri-
mientos precisos.
A veces se malentiende la gestin de proveedores y de subcontratistas, err-
neamente, se piensa en tener una funcin que optimice solamente el inters de
la organizacin sin consideracin por las necesidades de esos terceros (malos
pagos o malas condiciones laborales) desconociendo que tal prctica se vol-
ver contra la misma empresa.
Una verdadera gestin de proveedores va por el oro, como se ensea en los
buenos cursos de negociacin, donde se maximiza el inters de la empresa y
de los proveedores, mucho ms all de pagos justos y oportunos o buenas
condiciones laborales. Se trata de lograr la mayor armona en los intereses
buscando aplicarse todos con el mayor entusiasmo y creatividad al xito del
proyecto, incluso aportando ideas y siendo parte de la solucin.
98 JUAN BRAVO C.
CAPTULO 2.
INGENIERA DE SOFTWARE
Captulo 2. Ingeniera de software
Todo el mundo conoce la historia de los hijos del zapatero: el

zapatero est tan ocupado haciendo zapatos para otros que sus
hijos van descalzos. Durante los ltimos 20 aos, muchos inge-
nieros de software han sido los hijos del zapatero. Aunque es-
tos profesionales han construido sistemas complejos que automa-
tizan el trabajo de otros, ellos mismos no han aplicado estas
tcnicas.
Roger S. Pressman
El objetivo ms importante de la ingeniera de software es lograr la produc-

cin profesional de software, donde se aumente la calidad y la productividad y
se disminuyan los riesgos del proyecto mediante una excelente planificacin y
modelamiento. No se refiere a la produccin en serie, sino a la obtencin de
un producto creativo y personalizado, desarrollado con mtodo, tcnicas y
herramientas conocidas.
Esta es la segunda competencia considerada para apoyar la elaboracin de
necesario que el analista conozca acerca de la ingeniera de software para
que inserte su aporte en el contexto de esta disciplina. Es una competencia de
tipo vertical, porque se profundiza en una especializacin, el desarrollo de
software.
CAPTULO 6. UML
Se trata de avanzar desde aplicaciones computacionales que son obras de arte

nicas, hacia productos de programacin normalizados, con documentacin
100 JUAN BRAVO C.
automatizada, fciles de construir y de mantener, para lograr aumentos de

productividad de los desarrolladores de software.
No hay una contradiccin entre obtener productos creativos trabajando meto-
dolgicamente.
Hay que desmitificar la produccin de software, transformndola en una acti-
vidad mucho ms amistosa, a travs de la aplicacin de tcnicas simples y
herramientas poderosas, con una finalidad revolucionaria: permitir que los
usuarios calificados puedan participar activamente en todo el ciclo de desa-
rrollo. Usuarios calificados son profesionales y ejecutivos que poseen entre-
namiento formal en tecnologa de la informacin, quienes conocen su proble-
ma y saben como estructurarlo.
La orientacin del captulo y de todo el libro, es hacia la produccin de soft-
ware que apoye directamente los procesos de la organizacin teniendo siem-
pre al cliente como norte (al cliente final, el que paga).
La ingeniera de software incluye la produccin de otros productos de softwa-
re, como sistemas operativos, herramientas de productividad o de automatiza-
cin de oficinas. stos siguen patrones parecidos a la produccin de software
administrativo e incluyen algunos aspectos ms especializados, como el nfa-
sis en la programacin orientada al objeto o la utilizacin de lenguajes que
provean mxima eficiencia.
Todo lo que se refiere al apoyo automatizado para el desarrollo de software
(Herramientas CASE) se incluy en el captulo 7, sobre herramientas de la
tecnologa de informacin.
Veremos:
Alcance de la ingeniera de software
Planificacin en informtica
Sistema de productividad en el desarrollo de software
Criterios de desarrollo de software
Mtodos para la produccin de software
Apoyo del diseo en la explotacin del sistema
Diseo de interfaces
Normas y estndares aplicados a los modelos TI
2.1. ALCANCE DE LA INGENIERA DE SOFTWARE
El principal objetivo de la ingeniera de software es sentar las bases para la

produccin profesional de software, a travs de proponer mtodos completos
que permitan obtener buenos productos de software, es decir, econmicos
(costo / beneficio positivo), de alta calidad, amistosos y rpidos en la ejecu-
cin. Es lo que plantea Ian Sommerville (2005, p. 6): La ingeniera del softwa-
re es una disciplina de la ingeniera que comprende todos los aspectos de la
produccin de software desde las etapas iniciales de la especificacin del siste-
ma hasta el mantenimiento de ste despus de que se utiliza.
Consideramos que cumplir plazos y costos est incluido en alta calidad.
En las siguientes secciones precisaremos la definicin de ingeniera de softwa-
re, trataremos sobre la necesaria educacin y discutiremos sobre la real nece-
sidad de construir software con el objetivo de asegurarnos de trabajar en pro-
yectos plenamente justificados.
La realidad muestra que una gran parte de los proyectos informticos nunca
debieran haberse realizado (la mitad es una estimacin conservadora) porque
ni siquiera se exploraron superficialmente otras soluciones, por ejemplo: ex-
ternalizacin, trabajo de equipo, redefinicin de procedimientos, rediseo or-
ganizacional, automatizacin de oficinas, cambios en productos y mercados o
desmantelamiento de estructuras especializadas.
Veremos:
1. Definiciones de la ingeniera de software
2. Desarrollar un buen software o solucionar el problema?
3. Esfuerzo de educacin
4. Tecnologa de informacin
1. Definiciones de la ingeniera de software

Algunas definiciones sobre la ingeniera de software:
Richard Fairley: Disciplina tecnolgica y administrativa dedicada a la produc-
cin sistemtica de productos de programacin, que son desarrollados y modifi-
cados a tiempo y dentro de un presupuesto definido.
Fritz Bauer: El establecimiento y uso de slidos principios de ingeniera,
orientados a obtener, econmicamente, software que sea fiable y funcione efi-
cientemente sobre mquinas reales.
102 JUAN BRAVO C.
Comentarios de Roger S. Pressman: La ingeniera del software surge, sobre-

pasndola, de la ingeniera de sistemas y del hardware. Abarca tres elementos
clave: mtodos, herramientas y procedimientos, que facilitan al gestor controlar
el proceso de desarrollo del software y suministrar a los que practiquen dicha
ingeniera las bases para construir software de alta calidad de una forma produc-
tiva. Todo, bajo una filosofa predominante de coordinacin, control y gestin.
2. Desarrollar un buen software o solucionar el problema?

La ingeniera de software naci como respuesta a variadas necesidades rela-
cionadas con el desarrollo de software: fiabilidad, eficacia, control, normali-
zacin y productividad, por nombrar algunas. Consideremos la productividad
del desarrollo. La situacin es que se requieren nuevas aplicaciones que los
especialistas no alcanzan a construir. Se espera que el incremento en la pro-
ductividad permita satisfacer las demandas pendientes. Sin embargo, hay ins-
talaciones donde se increment la productividad del desarrollo y an as los
usuarios no estn satisfechos. No ser que comenzamos por el lugar equivo-
cado? Ser necesario desarrollar la aplicacin? Es que el inters del usuario
es solucionar su problema, lo cual no implica necesariamente el desarrollo de
una solucin de software. Por ejemplo, se puede explorar:
Hacer ingeniera y buscar alternativas de solucin no computacionales al
problema.
Adquirir software de uso generalizado.
Preparar a los usuarios para que ellos mismos resuelvan parte de sus nece-
sidades.
Contratar desarrollo externo.
Veamos estos puntos con mayor detalle:
1. Realmente hacer ingeniera y buscar otras alternativas de solucin al pro-
blema, no computacionales, tal como vimos en el captulo primero. Por
ejemplo, ampliar o reducir mercados, aplicar just in time, externalizacin,
trabajo de equipo o cambiar el diseo del producto. De aqu podran surgir
opciones tales como eliminar la bodega o descontinuar una lnea de pro-
ductos con dificultades de ventas que se pensaba controlar ms en detalle
con un sistema computacional.
Con esto es posible resolver tal vez el 50% de los casos, lo cual es consis-
tente con estudios que sealan que hasta la mitad del software construido
en Chile nunca debera haberse hecho, porque existan otras soluciones
mejores que ni siquiera fueron exploradas.
2. Si el camino es de ndole computacional, estudiar si la aplicacin existe

en el mercado para adquirirla a una empresa especializada. Hoy es una lo-
cura desarrollar aplicaciones tpicas, tales como: contabilidad, inventarios,
remuneraciones, activo fijo y facturacin. En el mercado existe una am-
plia gama de excelentes soluciones para todo tipo de plataformas, comen-
zando por los productos ERP (que veremos en el captulo siete). El costo
de este software genrico es equivalente a una pequea fraccin del costo
del desarrollo.
Es posible que esto d respuesta a la mitad de los requerimientos compu-
tacionales (25% de los casos).
3. Estudiar la posibilidad que sea el mismo usuario quien resuelva su pro-
blema. Con capacitacin y herramientas apropiadas puede resolver su re-
querimiento en menos tiempo del que le hubiera tomado explicrselo a un
especialista. Si se trata de la creacin de bases de datos simples, lo puede
hacer hasta con un procesador de texto. Si requiere interactuar con gran-
des bases de datos para extraer informacin, puede ocupar Microsoft Ac-
cess o alguno de los mdulos de consulta que proveen los sistemas admi-
nistradores de bases de datos. Si requiere efectuar clculos y presentar
grficos, las planillas electrnicas le ayudarn a resolver su problema.
Esto resuelve una parte de las situaciones que no pudieron ser resueltas
con software normalizado (digamos el 12,5% de los casos).
Resulta evidente que esta opcin se aplica cuando el tamao y compleji-
dad del requerimiento lo permiten.
4. Si no hay software de tipo generalizado y el usuario no lo puede resolver,
es posible recurrir al desarrollo externo. Significa que todas o algunas eta-
pas se pueden contratar externamente. Por ejemplo, realizar internamente
el anlisis y el diseo y contratar la construccin del sistema.
Esta opcin y otras creativas resuelven la ltima tajada de los requerimien-
tos originales (el otro 12,5% de los casos).
Cualquiera de estas opciones soluciona el problema del usuario sin recurrir al
desarrollo interno, la cual es una opcin que debiera quedar abierta slo para
casos excepcionales.
Tal como se aprecia en la evolucin de la construccin de software, el equipo
interno principalmente coordina y hace gestin de calidad, ms que construir
ellos mismos.
Tiene mucha relacin con el esfuerzo de educacin.
104 JUAN BRAVO C.
3. Esfuerzo de educacin
La ingeniera de software es una materia especializada y no es habitual que se
hable de educacin en este contexto. Sin embargo, es indispensable hacerlo si
queremos producir software efectivo y de calidad.
Si un ejecutivo destina a su labor especializada varios miles de horas de per-
feccionamiento, debiera destinar una cantidad equivalente de horas a los te-
mas de su entorno, uno de los cuales es la tecnologa de informacin. Este es
un principio sistmico, el equilibrio entre especializacin y generalizacin.
Es sorprendente la mayor productividad que se logra cuando los ejecutivos se
educan en el anlisis de problemas y los especialistas se capacitan sistemti-
camente en tcnicas y herramientas uniformes para el desarrollo de sistemas.
Adicionalmente, se incrementa la capacidad individual, mejora el funciona-
miento de equipos de trabajo y se refuerza la motivacin.
Este tema es de tal trascendencia que, refirindose al control total de calidad,
el Dr. Kaoru Ishikawa, ganador del premio Deming a la calidad, dice: la ca-
lidad comienza con educacin y termina con educacin.
Utilizamos la palabra educacin porque ella es consecuencia del proceso de
aprendizaje y reflejo de ser una persona culta. Se refiere a una conducta edu-
cada y no a una acumulacin de ttulos. Est relacionada con una sistemati-
zacin del conocimiento, un aprender a pensar y luego cambiar la forma de
pensar. La educacin implica una mentalidad abierta, menos prejuicios, dar
mejores respuestas a los desafos del medio y atreverse a hacer cambios.
Una faceta de la educacin es la capacitacin, la cual se refiere a dominar una
materia o a lograr una destreza especfica. Siendo la actividad de capacitacin
de fundamental importancia en la empresa, ella est indudablemente supedita-
da a los mayores intereses de la educacin.
Otra faceta es el Training (traducido como entrenamiento) destinado a formar
a las personas en los procesos especficos en que participa.
Cmo se aplica el esfuerzo de educacin en la organizacin?
A travs de establecer planes de perfeccionamiento dirigidos a todas las per-
sonas, comenzando por los ejecutivos de mayor nivel. Para disear el progra-
ma de enseanza, se pueden extraer algunos temas de la clasificacin de mate-
rias presentada en la figura 2-1, la cual es solamente un ejemplo del tipo de
materias en cada categora.
La empresa en la comunidad
Planificacin estratgica
Adaptacin al cambio
Liderazgo, organizacin y administracin
Reingeniera y benchmarking
Ambiente
Mejoramiento continuo
de
Visin sistmica
Calidad Gestin de procesos
Mapas de procesos
Flujograma de Informacin
Gestin de proyectos
Orientacin al cliente
Diseo de sistemas
Sistema de productividad
Orientacin a objetos y UML
Tecnologa
Modelamiento de datos
De Mtodos de desarrollo de software
Informacin Herramientas CASE
Bases de datos simple
Automatizacin de oficinas
Figura 2-1. Clasificacin de materias para perfeccionamiento en TI
En la figura 2-1 se puede apreciar que las materias de perfeccionamiento para

los ejecutivos y profesionales de la organizacin estn clasificadas en dos
grandes reas: un ambiente de calidad, orientado a los eslabones ms altos del
manejo de informacin y la tecnologa de informacin, con las materias pro-
pias del rea informtica.
De esta manera, los ejecutivos y profesionales podrn apreciar su organizacin
desde un punto de vista ms amplio. Con una visin de conjunto que permita
tener a todos sus integrantes un alto grado de participacin en el rediseo de
los procesos del negocio, computacionales o no.
Parte de este esfuerzo de educacin es conocer en profundidad los alcances de
la tecnologa de informacin y sus implicancias.
106 JUAN BRAVO C.
4. Tecnologa de informacin
La Tecnologa de Informacin (TI) est revolucionando nuestra sociedad ms
rpidamente que cualquier otra disciplina, penetr profundamente en la em-
presa moderna, est entrando en el colegio y en el hogar.
Qu es la tecnologa de informacin? La palabra tecnologa ya nos dice mu-
cho, ella proviene de la raz latina techne = arte y logy = organizacin, es de-
cir, arte organizado, susceptible de ser compartido, estudiado y completado,
en contraposicin al simple chispazo de la techne; en resumen, tecnologa
sera un cuerpo de conocimientos organizado que consta de mtodos y herra-
mientas en rpido progreso. Sobre la informacin, hay cientos de libros que la
tratan desde todo punto de vista. Podramos agregar que los datos se encuen-
tran hoy en computadores que los procesan para obtener, gota a gota, esa in-
formacin que a su vez es la base del conocimiento.
Por supuesto, ese procesamiento involucra muchos recursos de hardware,
software y sobre todo, personas altamente capacitadas.
La formacin de un conocimiento objetivo, a partir de la informacin, la ob-
servacin y la experiencia, es lo que produce tecnologa. Es un tipo de cono-
cimiento medible, de rpida formacin, traspasable, actualizado y perfeccio-
nado, con redes internacionales de especialistas que comparten su saber. Esto
ha sido en gran medida lo que origin la revolucin industrial y ahora la revo-
lucin del conocimiento.
Aunque no basta con el conocimiento, tambin es indispensable el entendi-
miento37. Con la comprensin que nos provee podremos darnos cuenta que la
aplicacin de un determinado conocimiento puede ser daino para el conjunto
y para nosotros mismos en el mediano y largo plazo. Tal vez resulte ms con-
veniente no extraer aquel petrleo desde el fondo del lago, porque el costo de
la contaminacin y de la prdida de agua potable sean mayores que el eventual
beneficio. Sabemos cmo hacerlo, pero decidimos no hacerlo.
Si el conocimiento es fruto de la informacin, observacin y experiencia, el
entendimiento es hijo de la reflexin y de la verdadera educacin, aqulla que
nos hace cambiar y pensar por nosotros mismos.
37
Es el entendimiento el que nos lleva al desarrollo, directamente relacionado con el aumento
de la calidad de vida. La nueva visin de la organizacin es la de un sistema social caracteri-
zado por la interdependencia, esto es comprender que cualquier problema que alguien tenga,
nos afectar a nosotros de una u otra forma. Y lo que a l le beneficie, nos ayudar tambin a
nosotros. Esta visin de sistema social es la base de una habilidad fundamental en nuestros
das, la adaptacin al cambio, sustento de las nuevas definiciones de inteligencia.
Es que la implementacin de cualquier tecnologa debe armonizar conoci-

miento y entendimiento. Esto es profesionalismo.
La tecnologa de informacin avanza velozmente y cambia su contenido en
perodos cada vez ms breves. Con capacitacin podemos conocerla, no cabe
duda, pero slo con educacin sabremos dnde, cundo y por qu aplicarla, en
la direccin del desarrollo social y del incremento en la calidad de vida.
108 JUAN BRAVO C.
2.2. PLANIFICACIN EN INFORMTICA
Una realidad a simple vista es que muchos sistemas computacionales no res-

pondieron de acuerdo con las expectativas. Incluso, hubiera sido preferible no
construirlos, porque el costo para la organizacin result ser ms alto que
mantener el problema original. Cul es la causa? Hay varias: construccin
apresurada, desarrollo informal, imposiciones de centros de poder con inter-
eses contrarios a los de la organizacin, falta de perfeccionamiento de los co-
laboradores, sesgo informtico, etc
Entre las causas, se considera especialmente relevante la carencia de una vi-
sin estratgica, por ello es que se incluye este captulo y los anexos 1 y 2,
acerca de estrategia y alinear intereses, respectivamente.
Por supuesto, todo proyecto de la organizacin, de tecnologa o cualquier otro
tipo, debe estar de acuerdo con el plan estratgico global. Si este no existe, fue
construido en forma apresurada en algunos retiros de fin de semana o se en-
cuentra desactualizado, estaramos en presencia de problemas mayores cuya
solucin comenzar cuando se cuente con el plan estratgico de la organiza-
cin. Para efectos de ofrecer luces respecto a lo que debe incluir el plan es-
tratgico es que se incluyeron los dos primeros anexos. Cabe agregar que el
plan informtico debera ser parte de ese plan global.
Por otra parte, tal como vimos en el captulo 1, este aspecto estratgico deber-
a estar contemplado en el mtodo que la organizacin adopte. Desde este
punto de vista, el contenido de esta seccin es profundizar en la parte del
mtodo referida a la estrategia.
Es que resulta vital desarrollar una visin estratgica, una vista panormica de
la realidad que permita tomar los mejores cursos de accin para cumplir los
grandes intereses de la organizacin.
La nueva tecnologa informtica ofrece ms rapidez, es ms amistosa y gene-
ralmente la relacin costobeneficio es claramente conveniente. Por lo tanto, no
es caro probar opciones, es ms, muchas veces resulta ms econmica una equi-
vocacin que esperar.
La opcin ms cara es mantener los esquemas tradicionales. Las empresas que
hacen cambios en forma sistemtica logran mejores resultados.
Veremos:
1. Algunas directrices sobre la tecnologa de informacin
2. Reconversin de la informtica
3. Nuevas formas de organizacin informtica

4. Mtodo de planificacin estratgica en informtica
5. Cambio cultural de la organizacin
6. Resumen de la planificacin estratgica en informtica
1. Algunas directrices sobre la tecnologa de informacin

La tecnologa de informacin va ms all de la seleccin de un hardware espec-
fico, algunos productos de software y un mtodo de desarrollo. Ahora hablamos
de mentalidad, flexibilidad y disposicin al cambio. Si en la empresa se ha ven-
cido el temor a ensayar opciones; si de alguna forma se tiene institucionaliza-
do probar alternativas para seleccionar aqulla que mejor les parece, entonces
la resistencia al cambio es muy baja. Como consecuencia, se obtiene un subpro-
ducto de gran proyeccin: la adaptacin al cambio38.
La tendencia de la tecnologa de informacin se estara orientando hoy, hacia un
conjunto de directrices cuya implementacin significa tomar decisiones estrat-
gicas que estn ms all del mbito informtico. Estas decisiones estratgicas
deben ser tomadas en reuniones conjuntas de la alta gerencia con sus especialis-
tas y preferentemente con apoyo externo no comprometido con alguna opcin
en particular.
38
Stan Shih, fundador y presidente de Acer, en un viaje a Chile realizado para sostener con-
versaciones con la subsidiara local, expone (El Mercurio, 30 de julio de 1995) algunas de las
causas del xito de Acer, compaa que en slo un ao salt del nmero 14 al 7 de entre los
mayores fabricantes de PCs a nivel mundial. Opina que la computacin recin comienza y
que a principio de los 90s se produjo un cambio radical en el mercado que llamaron desinte-
gracin de la industria. Para adaptarse, emprendieron el proceso de la reingeniera de acuer-
do con tres grandes estrategias:
El modelo de comida rpida. La idea es ensamblar el PC en el punto de ventas y fabricar las
piezas en otra parte.
La estructura organizativa de clienteservidor. Cada empresa del grupo es independiente y
cada una est enfocada a una lnea de productos La relacin de la red les permite mejorar la
calidad y reducir costos. Esta clase de estructura maneja mejor los cambios y en esta industria
el cambio es constante.
La idea de marca global, toque local. As, por ejemplo, en Chile se ve qu clase de produc-
tos gustan y a esos se les da prioridad Queremos tener socios en cada pas a travs de so-
ciedades annimas abiertas.
Dice: los gerentes son tambin inversionistas hacemos mucha capacitacin las unidades
toman sus propias decisiones no buscamos tamao, tenemos que buscar el retorno y cmo
podemos construir competitividad innovacin no slo en el producto, tambin en la admi-
nistracin.
110 JUAN BRAVO C.
Algunas de las nuevas directrices son:

reas de sistemas orientadas al cliente (el cliente de la organizacin, el
que paga) filtrando cada requerimiento en funcin de si le agrega valor o
no a ste. Implica que los profesionales de informtica conocen y aplican
la estrategia de la organizacin.
Incorporacin del usuario (o cliente interno) al proceso de desarrollo de
sistemas, al menos en la gestin de su propia demanda de requerimientos.
Tambin en resolver sus propias necesidades simples: informes y consultas
de toda ndole, con alta eficacia y eficiencia en la obtencin de resultados.
Participacin creciente del usuario ejecutivo en la formulacin de modelos
corporativos, que representen la realidad de la empresa.
Fuerte nfasis en perfeccionamiento y educacin. Incluso, este aspecto es
una ventaja competitiva a nivel profesional.
Desarrollo y procesamiento descentralizado, en armona con la existencia
de un pequeo departamento de sistemas centralizado y de acuerdo con la
planificacin informtica y las normalizaciones en mtodos, procedimien-
tos y herramientas que la organizacin se haya dado. En particular, cada
unidad de negocios administrar su propio presupuesto de informtica.
Orientacin a objetos, UML y otros estndares en lugar de diseo estructu-
rado. Es creciente la velocidad de introduccin de las tcnicas de orienta-
cin a objetos.
Software cada vez ms amistoso con uso intensivo de factores humanos:
simplicidad, ayudas en lnea, ventanas, conos o idioma nativo del usuario.
Utilizacin creciente de prototipos para ensayar interfaces visuales (panta-
llas e informes) y funcionalidad (ingreso de datos o seleccin).
Generacin automtica de cdigo. Lo cual es hoy una realidad con mlti-
ples herramientas disponibles en el mercado.
Bsqueda de cdigo reutilizable. Promesa que con la orientacin a objetos
est comenzando a ser cumplida (es ya una realidad al interior de algunas
organizaciones, pero todava falta un mercado de cdigo reutilizable).
Apoyarse en herramientas de productividad en todo el ciclo de desarrollo.
La idea es automatizar sobre la base de mtodos formales, dejando de lado
la produccin artesanal del software.
Alineamiento cada vez mejor entre la tecnologa de la informacin y las
necesidades estratgicas de la organizacin.
Estrategia de la organizacin e informtica permanentemente reformulada.

Integracin total, incluyendo a las aplicaciones antiguas a travs de
rescatar su funcionalidad en la forma de componentes a los cuales se
accede mediante mensajes (orientacin a objetos). Tambin redes
neuronales e interconexin con clientes y proveedores.
Uso intensivo de Internet, Intranet y Extranet. Uno mismo puede establecer
como desea que sean sus aplicaciones.
Nuevos criterios de evaluacin de programadores: ya no ser por lneas de
cdigo o menor cantidad de errores, sino que por el grado de satisfaccin
del usuario.
Mayor calidad y cantidad de aplicaciones, lo que a su vez significar la
adquisicin de ms hardware y software.
Fuerte demanda de especialistas preparados en mtodos y herramientas
modernas: Gupta, Powerbuilder, Ingres, Progress, Oracle, Sybase, Visual
Basic, Informix y muchas otras.
Una variable a tomar en cuenta por desarrolladores y ejecutivos del rea in-
formtica, es que las rentas de especialistas bien preparados en cualquiera
de esos temas son mayores al promedio. Los primeros pueden ver esto co-
mo una real oportunidad profesional. Los segundos debieran ser cuidadosos
en que los costos del proyecto no se disparen.
Fuerte expansin de la multimedia (sonido, imagen, tacto, movimiento,
etc.). La idea es vivir la experiencia. Por ejemplo, se puede pasear vir-
tualmente dentro de la casa que uno quiere comprar, cambiarle colores o
hacer transformaciones.
Importantes avances en la tecnologa de tratamiento de imgenes. De
hecho, existen experiencias exitosas en importantes organizaciones.
Equipos PC cada vez ms poderosos y econmicos. Hoy, a fines de la pri-
mera dcada del segundo milenio, ya se habla en Terabytes (TB) para los
dispositivos de almacenamiento y en Gigabytes (GB) para las memorias.
2. Reconversin de la informtica
La tecnologa de informacin, junto con la masiva incorporacin del usuario,
las revoluciones del hardware, software, mtodos y esquemas organizaciona-
les, estn provocando profundos cambios en el perfil de los especialistas en
computacin, slo comparables a las enormes reconversiones que significaron
112 JUAN BRAVO C.
el cambio del ferrocarril a vapor por la locomotora elctrica y del carbn por
otras fuentes de energa.
Una de las consecuencias ms inmediatas es el cambio en las funciones de los
diferentes especialistas:
Digitadores y operadores prcticamente no se requieren en el centro de
informtica, pero pueden pasar a desempearse como apoyo en departa-
mentos usuarios, trabajando en pequeas unidades de informtica descen-
tralizadas o directamente en funciones propias del quehacer de otras reas,
aprovechando su conocimiento sobre la organizacin.
Los programadores pasarn a ser analistas-programadores, ellos deben
proveer de soluciones informticas completas, a partir del diseo de la
aplicacin. Tanto en el diseo como en la construccin de sistemas deben
apoyarse en las herramientas de productividad.
Los analistas de sistemas pasarn a desempearse como consultores inter-
nos, especialmente en innovaciones, informacin y adaptacin al cambio.
El nuevo rol del analista ya es solucionar problemas, en lugar de desarro-
llar sistemas computacionales; en consecuencia, su preparacin debe in-
cluir conocimientos sobre todas las nuevas herramientas de apoyo integral
a la organizacin: estrategia, gestin de procesos, benchmarking, liderazgo
o inteligencia competitiva.
El jefe de informtica ser un lder y trabajar con sus colaboradores en el
marco de una relacin ms profesional que jerrquica. Su misin principal
ser la interaccin con el medio: clientes, proveedores o competencia, para
aumentar permanentemente la productividad, la calidad y el servicio al clien-
te no slo de su rea, sino de toda la empresa. Tambin el cambio se aprecia
en la evolucin del nombre del cargo, el nuevo nombre que usamos es Ge-
rente de Sistemas.
Observando la realidad actual de muchas organizaciones, se llega a concluir
que la reconversin de programadores sigue los mismos patrones que en otras
reas con cambios drsticos, tal como se muestra en la figura 2-2. Ms o me-
nos el 25% de los actuales programadores no requiere entrenamiento especial,
pues ya tiene conocimientos actualizados y aplica las nuevas tecnologas. El
50% deber ser reentrenado y puede seguir desempendose sin mayores difi-
cultades. El 25% restante tiene poca tolerancia al cambio, aunque la mayora de
ellos puede subirse a este nuevo mundo con perfeccionamiento en la medida
que su predisposicin personal sea positiva.
25% 25%
Ya poseen No tienen
los nuevos tolerancia
conocimientos al cambio
50%
Pueden ser
reentrenados
Figura 2-2. Reconversin de programadores
3. Nuevas formas de organizacin informtica

El diseo organizacional del rea informtica es parte integrante de las defini-
ciones estratgicas respecto a la ingeniera de software.
Analizaremos aqu algunas posibilidades de organizacin informtica, compa-
tibles entre s:
Equilibrio entre centralizacin y descentralizacin

Significa conservar un centro de informacin a nivel de la empresa, dando a
cada rea usuaria autonoma en el manejo informtico, en el marco de las
normas convenidas y administradas por el centro de informacin. La autonom-
a en esta materia tiene su base en los principios sistmicos de viabilidad y
recursividad. Para que un rea sea viable, debe poseer funciones esenciales de
sobrevivencia: manejo econmico, de personas, direccin y tecnologa, entre
otras. La recursividad dice que estas funciones esenciales se encuentran a ni-
vel de la empresa y de cada rea viable. As como existe una fuerza area na-
cional y una rama aeronaval de la armada, en la organizacin debieran existir
funciones de manejo de la informacin, centralizada y como parte de cada
rea usuaria autnoma.
114 JUAN BRAVO C.
Rightsizing (tamao justo)

Significa dimensionar el equipamiento y el rea de sistemas de acuerdo con
los requerimientos y la disponibilidad de nuevas tecnologas. Si es posible
satisfacer la demanda interna con un servidor y equipos conectados en red,
entonces ese es el tamao apropiado. Si es posible satisfacer al cliente interno
subcontratando el desarrollo de sistemas y la nica infraestructura centralizada
es un especialista en informacin, entonces ese es el tamao correcto.
Rightsizing deriv del trmino downsizing, todava muy en boga para efectuar
una reduccin del tamao de la infraestructura, en particular el equipamiento,
porque ha venido sucediendo que el desarrollo exponencial de los computado-
res personales est dejando obsoletos los mainframes o equipos grandes. Es
frecuente obtener ms rendimiento a travs de microcomputadores por el
mismo costo de mantener un mainframe, con la ventaja extra de la arquitectu-
ra abierta, por lo estndar de los PCs.
Externalizacin (outsourcing)
Significa contratar externamente el servicio de informtica, teniendo el cuida-
do de mantener internamente algn interlocutor con amplios conocimientos de
informtica y de administracin, un especialista en informacin. Desde los
puntos de vista econmico, sistmico y humano esta opcin aparece como la
ms apropiada en la mayora de las organizaciones cuya misin no tiene rela-
cin con la informtica:
Es ms econmico, porque generalmente resulta de ms bajo costo subcon-
tratar que proporcionarse uno mismo el servicio, incluyendo en el costo in-
terno las rentas de las personas, infraestructura fsica y uso de otros recur-
sos generales: contabilidad, servicios bsicos, etc. Esto agrega el gran be-
neficio del ahorro de tiempo en interacciones innecesarias al interior de la
empresa, el cual probablemente es mayor al costo directo.
Es ms natural, porque, segn el enfoque sistmico, la mxima potencia de
una organizacin se logra cuando est totalmente concentrada en su mi-
sin, la cual desatiende al destinar tiempo y recursos en atender a la auto-
generacin de servicios que puede tomar del medio. En otras palabras, aun
cuando el servicio interno resulte ms econmico que ser contratado exter-
namente, lo cual ya es poco probable, esa diferencia a su favor es nfima
comparada con el costo de oportunidad o el mayor rendimiento potencial
de los mismos recursos destinados a apoyar la misin de la organizacin.
En esto debemos ser cuidadosos, porque hay organizaciones con misiones

que dependen totalmente de la tecnologa, incluso, uno podra plantear que
su negocio es tecnologa. Es el caso de las grandes tiendas por departamen-
tos tal como Falabella, Ripley y Almacenes Pars en Chile los bancos
comerciales, los supermercados y muchos otros que necesitan el procesa-
miento en tiempo real y el manejo de grandes volmenes de transacciones.
En estos casos, las innovaciones tecnolgicas son definitivamente ventajas
competitivas.
Es ms humano, porque, generalmente, el profesional de informtica y lo
mismo es vlido para contadores, cobradores, guardias y otras personas de
servicios internos tiene menos posibilidades de desarrollo en una empre-
sa dedicada a otra misin: su renta queda rpidamente estancada; su evolu-
cin profesional es ms lenta porque solamente conoce la realidad de la
empresa; no hay mayores incentivos para innovaciones, porque no se apre-
cian los cambios creativos debido a lo especializado de su rea. Adems,
existen serias dificultades de comunicacin con el resto de la empresa.
Esta es la regla general, sin embargo, debemos estudiar cada caso en forma
individual para su eventual aplicacin. La prudencia indica que debemos
reconocer muy bien la misin de la empresa, porque tal vez el negocio de
fondo es tecnolgico y en ese caso los profesionales de informtica pueden
hacer una carrera al interior de la organizacin.
Cuando el profesional de informtica se desempea en una organizacin de
informtica, ya no es un patito feo, porque ahora puede comunicarse con
sus pares. Su campo de desarrollo profesional se ampla, sus contribuciones
son comprendidas y apreciadas, la renta se va incrementando segn su ren-
dimiento y se produce un ambiente motivador que ayuda a incrementar la
productividad.
Un plan de externalizacin debera incluir el destino de los especialistas en
informtica, de comn acuerdo con ellos, quienes podran formar la empresa
que proveer el servicio o integrarse a una empresa mayor de la especialidad
informtica que provea el servicio, entre muchas otras posibilidades. Este as-
pecto debe ser analizado en la gerencia con la mayor atencin debido al im-
pacto que tiene sobre la motivacin de todas las personas.
Por ejemplo, IBM de Chile, como parte de su poltica corporativa, externaliz
a mediados de los 90 gran parte de los servicios administrativos pago de
remuneraciones, contabilidad y otros, los cuales fueron provistos por una
116 JUAN BRAVO C.
empresa de 30 ex-empleados que, a poco andar, tuvo que hacer muchas con-
trataciones adicionales.
4. Mtodo de planificacin estratgica en informtica

La planificacin estratgica da el rumbo a la organizacin en la forma de un
plan estratgico. La planificacin informtica fija el marco para priorizar los
proyectos informticos y obtiene un plan que debe mantenerse actualizado.
En la figura 2-3 vemos un esquema de planificacin informtica.
Planificacin Estratgica
Procesos del negocio

Definiciones
Realidad actual:
estratgicas:
Definiciones estratgicas Conjuntos de datos
Organizacin
Aplicaciones En los procesos
Equipamiento
Conjuntos de datos
Bases de Datos
Proyectos en desarrollo
Mtodos Referencias cruzadas
Herramientas de Procesos vs datos
productividad
Normas
Participacin del usuario Modelo conceptual
de datos
Evaluacin
Estrategia Informtica
Prioridades de desarrollo, modelo de datos, definiciones estratgicas
y plan de implementacin
Figura 2-3. Planificacin estratgica en informtica
En la figura 2-3 podemos ver que a partir de la planificacin estratgica de la

empresa, se trabaja en las definiciones estratgicas del rea informtica: orga-
nizacin de la funcin informtica; plan de equipamiento; tipo de producto para
administrar las bases de datos de la empresa; mtodos de la tecnologa de in-

formacin; herramientas de productividad para los usuarios y el desarrollo de
sistemas computacionales; acuerdos de normalizacin en mltiples aspectos y
grado de participacin de los usuarios.
Es importante destacar que esta planificacin no es aislada, sino que se trata de
un subproducto de la planificacin estratgica de la organizacin, la cual gene-
ralmente est apoyada con consultora externa.
En paralelo con las definiciones estratgicas se puede ir avanzando en definir
los procesos del negocio de la organizacin, principales y secundarios, orienta-
dos al cliente y a objetivos internos, respectivamente. Luego, identificamos los
conjuntos de datos que se manejan en cada proceso: clientes, proveedores, art-
culos u rdenes de compra. Despus, construimos una matriz con todos los pro-
cesos y conjuntos de datos, el objetivo es obtener referencias cruzadas y deter-
minar la importancia relativa de cada conjunto de datos para comenzar a formar
un modelo de datos conceptual de la organizacin.
Es posible obtener en esta planificacin el modelo conceptual detallado, con
todos los datos y relaciones.
Tambin en paralelo, podra adelantarse en ver con qu contamos? Es decir,
determinar cul es la realidad actual de las definiciones estratgicas indicadas
en la segunda columna de la figura 2-3. Adicionalmente, debemos conocer las
aplicaciones en funcionamiento, los conjuntos de datos ya formados y los pro-
yectos en desarrollo. El objetivo es darle prioridad a aquellas aplicaciones que
se perciben importantes y que, adems, tienen algn grado de avance.
Con todos estos antecedentes se realiza una evaluacin junto con los usuarios.
Para definir las prioridades se consideran: importancia del proceso, grado de
desarrollo previo y tamao, entre otros factores. Para evaluar, es indispensable
dimensionar los requerimientos de personas, capacitacin, software, infraestruc-
tura, comunicaciones o hardware.
Conciliar el inters particular y general es de suma importancia en esta etapa.
El plan informtico que obtenemos como resultado incluye las prioridades de
desarrollo, un modelo de los conjuntos de datos y sus relaciones, las definicio-
nes estratgicas reformuladas a la luz de los nuevos antecedentes aportados du-
rante el desarrollo del estudio y el plan de implementacin definido para llevar a
cabo los diferentes proyectos. Considerando que las personas son lo importante,
el aspecto perfeccionamiento es de primera importancia en este plan.
La forma de trabajar en estas materias es mediante un equipo interdisciplinario
donde tambin participan especialistas en informacin. La coordinacin a alto
118 JUAN BRAVO C.
nivel, gerencia general y jefaturas funcionales, se logra mediante talleres de pla-

nificacin estratgica en tecnologa de informacin.
Al igual que con cualquier normalizacin viable, el desarrollo de la planifica-
cin estratgica en informtica debe tener las siguientes caractersticas: consen-
sual, flexible, actualizada y vendible, en el sentido de que sea aceptable para la
alta gerencia.
5. Cambio cultural de la organizacin

La incorporacin exitosa de cualquier nueva tecnologa requiere un cambio
cultural previo de la organizacin. Es preguntarse, cul es el ambiente en
donde esta tecnologa tiene su mayor potencialidad? Por ejemplo, en muchas
organizaciones chilenas no se han obtenido los resultados esperados de los
correos electrnicos y herramientas tipo Groupware, porque la mayora de la
personas no tiene el hbito de contestar un mensaje, equivalente a devolver
una llamada con la anterior tecnologa. En Estados Unidos s ha tenido xito,
porque la mayora de las personas tiene el hbito de contestar los mensajes.
Para intentar solucionar el problema, algunas empresas chilenas han buscado
que el software obligue a responder. Lo cual no ha sido necesario en el pas de
origen del producto. De qu sirve cambiar la tcnica si no han cambiado las
conductas que hacan ineficaz el mtodo anterior? No es equivalente a cerrar
los ojos y creer que mgicamente una nueva tecnologa funcionar sin los
cambios de fondo que requiere?
Para el caso anterior, es mejor promover el cambio de hbito, comenzando por
el ejemplo de los ejecutivos superiores y siendo firmes en cumplir y hacer
cumplir los nuevos acuerdos, en lugar de desnaturalizar una herramienta.
En otras palabras, reiterar la necesidad de liderazgo.
Hemos visto casos de incorporacin de excelentes herramientas, productos
CASE y bases de datos, que no han aumentado en nada la productividad, pero
s el costo. Por qu? Porque no cambi la cultura de la organizacin, todos
mantuvieron sus hbitos. Los usuarios siguieron sin comprometerse, los pro-
gramadores siguieron codificando y manteniendo el cdigo igual que siempre
aunque ahora en otro lenguaje y algunas reas progresistas de la empresa
continuaron con sus islas de automatizacin o de desarrollo independiente.
El cambio cultural de la organizacin tiene relacin directa con un principio
sistmico: para que la organizacin conserve su viabilidad, todo cambio ex-
terno debe ser compensado con un cambio interno equivalente, de lo contra-
rio, el sistema corre el riesgo de romperse.
Para la incorporacin exitosa de la tecnologa es indispensable la preparacin

de la organizacin, comenzar por ubicarse en uno de los siguientes niveles de
evolucin de tolerancia al cambio:
1. - Anarqua: significa que las diferentes reas son como feudos, con escasa
coordinacin entre ellas y sin normalizacin ni planes comunes. Aqu las
buenas soluciones que aparecen se ven ahogadas en el medio. En este am-
biente surgen llaneros solitarios que logran mejorar su rea a costa de
mucho esfuerzo personal, aunque pareciera que mantienen una situacin
artificial, porque, cuando ellos se van, todo vuelve a la normalidad ante-
rior (es como empujar murallas de goma).
2. - Normalizacin interna: tambin llamado folklore nativo. Aqu hay un alto
grado de acuerdo y compromiso al interior de la organizacin, con planes
comunes, normalizacin y comunicacin, aunque basada en soluciones
particulares o debido al esfuerzo de algn miembro con poder que ha lo-
grado imponer su visin. Es el caso del comportamiento autocrtico, in-
dudablemente mejor que la anarqua, aunque pobre en rendimiento. Gene-
rar normalizaciones internas particulares ajenas a su negocio no es la mi-
sin de la organizacin, esto produce un desgaste que atenta contra el me-
jor desempeo global. Es como si en la empresa textil se desarrollara una
herramienta de mayor productividad para informtica.
3. - Normalizacin externa: en este caso las soluciones son compatibles con el
medio, se aplican mtodos y herramientas normalizadas, as la organiza-
cin se inserta en su comunidad y evita desgastarse creando mtodos y
herramientas particulares para contabilidad, informtica o finanzas. Toma
del medio las tecnologas que necesita y acude al mercado laboral para
proveerse de personas entrenadas; aqu ya se aprecia un fuerte compromi-
so de la empresa, como un todo, con el nuevo enfoque. En este nivel co-
mienza a notarse la importancia del perfeccionamiento de las personas de
la organizacin.
4. - Adaptacin a la dinmica del medio: sobre la base de la normalizacin
externa, la organizacin prueba nuevas opciones. Con esto se vence la re-
sistencia al cambio y la organizacin es permeable a las buenas ideas del
ambiente. Cada vez que una tecnologa se ve interesante para la empresa,
se revisa, se comparten los resultados y se analiza su eventual incorpora-
cin. Este ltimo nivel permite cuestionar y renovar las normas de la or-
ganizacin. El perfeccionamiento de las personas es vital.
120 JUAN BRAVO C.
Luego se establece un plan de trabajo para pasar al siguiente nivel. Si ya est

en el nivel 4, para seguir perfeccionndose.
Un aspecto importante de esta evolucin es que no se trata slo de acciones a
realizar sino que tambin de estructura organizacional que debe ser incorpora-
da (como en el modelo de negocios del captulo 1, el cambio debe realizarse
en toda la mesa: estrategia, personas, procesos, estructura y tecnologa).
En esta clasificacin por cierto flexible, porque las distinciones entre un
nivel y otro no son rgidas, sino que se trata de orientaciones generales cada
nivel incluye las caractersticas evolutivas del anterior. Es interesante conocer
que estudios realizados en Estados Unidos (sealados por Edward Yourdon en
su curso Anlisis y orientacin a objetos, dictado en Santiago en Octubre de
1992) indican que el 87% de las organizaciones de ese pas caen en la primera
categora, un 12% en el segundo nivel y slo el 1% llega a los niveles tercero
y cuarto, aunque es sintomtico que la mayora de las empresas Fortune39 500
estn en el cuarto nivel.
En un ambiente de amplia uniformidad y consenso est razonablemente garan-
tizado que la decisin de incorporar una nueva tecnologa no es producto de la
impulsividad de una persona, como podra ser en los niveles anrquico o de
normalizacin interna, sino resultado de estudios, pruebas, comparaciones
formales y mucha reflexin. Es indispensable la generacin de un plan de im-
plementacin, como parte del proyecto de cambio, que incluya infraestructura,
educacin, capacitacin y herramientas de apoyo.
Concretamente, la implementacin exitosa de los mtodos y herramientas de
la tecnologa de informacin, exige que la cultura de la empresa est en los
niveles tercero o cuarto. Cuando menos, en transicin desde el segundo al
tercer nivel. Slo en ese suelo frtil se puede cosechar el fruto de la producti-
vidad. Si la organizacin est en los niveles anrquico o de normalizacin
interna, el resultado de incorporar nuevas tecnologas es tiene alta probabili-
dad de ser un fracaso ms. En tal caso, es indispensable que la organizacin
invierta previamente en el cambio cultural.
6. Resumen de la planificacin estratgica en informtica

Este resumen no pretende ser una receta para realizar planificacin en in-
formtica sino solamente servir de gua para profesionales, quienes introdu-
39
Se refiere al ranking de la revista homnima con respecto a las 500 empresas de mayores
ingresos y rentabilidad.
cirn cambios y realizarn las adaptaciones necesarias para atender cada situa-
cin particular.
Definiciones estratgicas del rea informtica
Organizacin de la funcin informtica
Plan de equipamiento
Administrador de las bases de datos de la empresa
Mtodos de la tecnologa de informacin
Herramientas de productividad para usuarios y especialistas
Acuerdos de normalizacin en mltiples aspectos
Grado de participacin de los usuarios
Identificacin de los procesos del negocio de la organizacin, principales y
secundarios
Conjuntos de datos que se manejan en cada proceso
Matriz con todos los procesos y conjuntos de datos
Modelo de datos conceptual de la organizacin
Realidad actual
De las definiciones estratgicas
Aplicaciones en funcionamiento
Conjuntos de datos ya formados
Proyectos en desarrollo
Evaluacin
Participacin de los usuarios
Factores (negociaciones)
Importancia del proceso
Grado de desarrollo previo
Tamao
Dimensionamiento
Requerimientos de personas
Capacitacin
Hardware
Software
Infraestructura
Comunicaciones
Estrategia informtica
Prioridades de desarrollo
Modelo de los conjuntos de datos y sus relaciones
Definiciones estratgicas reformuladas
122 JUAN BRAVO C.
Plan de implementacin
Perfeccionamiento
En conclusin
La TI por si sola no aporta valor, est al servicio del propsito de la organi-
zacin. La proporcin en que se aplica ser mayor si se acerca al corazn
del negocio
La buena comunicacin con los socios tecnolgicos es central
La TI pasa a travs de integrantes de la organizacin quienes deben querer
usarla y estar capacitados para ello
La secuencia Fortalezas (FO), Factores de diferenciacin (FD) y Ventajas
competitivas (VC) es importante.
FO FD VC
El principal esfuerzo en TI debe estar centrado en las fortalezas del negocio,

as se obtendr un factor diferenciador que luego podra llegar a ser una venta-
ja competitiva. En las debilidades es preferible no desgastarse, mejor externa-
lizar o aplicar la solucin tipo commodity.
Se sugiere revisar el concepto de cadena de valor40 de Michael Porter, el cual
se centra en el mismo mensaje: disear una estrategia para fortalecer los valo-
res que percibe el cliente.
40
Ver libro Gestin de procesos.
2.3. SISTEMA DE PRODUCTIVIDAD EN EL

DESARROLLO DE SOFTWARE
Una pregunta clave es: cmo aumentar la productividad41 en el desarrollo de

software? Desde la visin sistmica ya sabemos que no existe el factor de
productividad (tambin conocido como bala de plata o panacea), ni siquiera la
incorporacin aislada de varios factores. Lo que realmente funciona es un sis-
tema de productividad42.
El sistema de productividad se podra definir como la mejor combinacin de
todos los elementos del conjunto de factores de productividad. No se trata de
tener lo mejor de cada factor, sino la combinacin que resulte ms apropiada a
la realidad de la organizacin.
Como todo sistema viable, el sistema de productividad es mucho ms que la
suma aislada de los factores y necesariamente considera un acuerdo armonio-
so entre los integrantes de la organizacin para su implementacin.
Ya sabemos que es vital aumentar la productividad del desarrollo de software.
Con la aplicacin del sistema de productividad, el desarrollo de aplicaciones
puede elevar su rendimiento en una proporcin estimada de 1:10 (aumento de
10 veces). Esto es vital, porque ms all de las beneficiosas implicancias
econmicas de corto plazo, disponer a tiempo de los sistemas computaciona-
les es un factor diferenciador para el xito del negocio.
Obviamente, esto no es gratis, pues exige una inversin que debera ser asu-
mida como un proyecto, comparando beneficios versus costos, incluyendo el
costo vigente de la falta de informacin para la toma de decisiones. La inver-
sin, adems de dinero, incluye tiempo, disposicin y esfuerzo de los intere-
sados. Es ms, si la organizacin como conjunto no est dispuesta a compro-
meterse, no vale la pena el esfuerzo.
Tambin se puede justificar el sistema de productividad desde el punto de
vista sistmico: un sistema rico en variedad, como es la produccin de softwa-
re, slo puede ser modificado por una solucin con variedad equivalente. Esa
41
Productividad, en simple, es producir ms con menos recursos. Es la base de la creacin de
riqueza, en el libro Gestin de procesos se profundiza en este concepto.
42
Se refiere especficamente al desarrollo de software, este sistema de productividad se puede
ver como un subconjunto del mtodo GSP presentado en el captulo 1. Por lo mismo, no se
incluy aqu la vital orientacin al cliente.
124 JUAN BRAVO C.
es la variedad que aporta el sistema de productividad. En contraposicin a

soluciones con escasa variedad, por ejemplo, cuando slo abordan uno o dos
factores, como el equipamiento o el software.
Se describen a continuacin los principales factores detectados, con una ad-
vertencia: el xito del sistema de productividad es la armona del conjunto, lo
cual es mucho ms importante que tomar lo mejor del mercado para cada fac-
tor. Por ejemplo, tal vez no elijamos la herramienta ms moderna, pero nues-
tra seleccin se lleva bien con el hardware que empleamos, es fcil de apren-
der y conocida en el medio (podra ser un lenguaje de programacin, una
herramienta clienteservidor o un administrador de bases de datos).
Es que no hay balas de plata (las que matan al hombre lobo). Alfredo Weit-
zenfeld se refiere a ellas (2005, p. 17): Un legado importante de Fred Brooks
fue el clebre aunque controversial artculo No Silver Bullet, en el cual se dis-
cuten los desafos ms importantes de la ingeniera de software. En este art-
culo Brooks deja un desafo a las nuevas generaciones: Segn miramos al
horizonte de una dcada, no vemos ninguna bala de plata. No existe un solo
desarrollo, en la tecnologa o tcnica de administracin, que por si mismo
prometa incluso una mejora de un orden de magnitud en productividad, con-
fiabilidad, simplicidad, dentro de una dcada.
Aunque este artculo fue escrito en los aos 70, mantiene su actualidad, nada
hay en el horizonte que prometa cambios radicales en las variables crticas del
desarrollo de software. Hoy como ayer, slo el trabajo arduo y metodolgico
hace una diferencia.
Los factores son:
1. Mtodo
2. Tcnicas
3. Herramientas de software
4. Hardware
5. Incorporacin del usuario
6. Habilidad del desarrollador
7. Normalizacin externa
8. Factores de contexto
1. Mtodo
Se requiere mtodo para toda la organizacin y que aborde el ciclo de vida
completo de cualquier proyecto, no slo su parte tecnolgica. Por supuesto, el
nfasis en aspectos de calidad, control de riesgos e incorporacin de las com-

petencias de las personas resulta central.
Es lo que vimos en el captulo 1.
2. Tcnicas
Las tcnicas debieran ser modernas, simples, fciles de aprender y conocidas
por todos, tanto para el ciclo completo de desarrollo como al interior de cada
etapa. Por ejemplo, orientacin a objetos y UML.
Las tcnicas tienen que llevar a una amplia portabilidad del software produci-
do. Este concepto se aplica generalmente a implementar la aplicacin en dife-
rentes plataformas, aunque tambin se refiere a la portabilidad del diseo.
Las tcnicas tambin deben ayudar a facilitar el perfeccionamiento de las apli-
caciones, para que:
Puedan utilizarse en otras unidades de la misma organizacin.
Puedan utilizarse como parte de otra aplicacin.
Sean independientes de sus desarrolladores.
Sean fcil de ampliar, explicar y de utilizar por otras personas.
En otras palabras, incorporando un amplia portabilidad, en la forma de com-
ponentes, como en la tcnica de orientacin a objetos.
Directamente relacionados con las tcnicas se encuentran los procedimientos,
indispensables para enlazar diferentes tcnicas en distintas etapas del ciclo de
vida de un sistema de informacin, regular la participacin de especialistas y
usuarios o normar el uso de una u otra herramienta segn el tipo de problema.
Por ejemplo, como el enlace que veremos en el captulo 6 entre las actividades
del flujograma de informacin y los casos de uso de UML.
3. Herramientas de software
Los mtodos y tcnicas tienen que estar apoyados por buenas herramientas,
con especial nfasis en la amistosidad. Por supuesto, la incorporacin de este
tipo de software debiera ir acompaada del correspondiente entrenamiento, no
slo en el uso del producto sino tambin en la tcnica que le acompaa, esa
tecnologa que viene junto con la herramienta.
Es indispensable el alineamiento entre los mtodos adoptados por la organiza-
cin y las herramientas de apoyo al desarrollo de software (CASE).
126 JUAN BRAVO C.
Algunos ejemplos de herramientas son: simuladores, administradores de bases

de datos y generadores de aplicaciones.
En el captulo 7 se describen algunas herramientas.
4. Hardware
Mucho se habla sobre el extraordinario avance en el rendimiento de los com-
putadores y el acierto de Gordon E. Moore con la conocida ley que lleva su
apellido, dice que cada 18 meses se duplica la capacidad de los computadores,
originalmente aplicada a los grandes equipos, se populariz para los PCs43.
Es innecesario profundizar en este aspecto, aunque s puntualizar la imperiosa
necesidad de aprovechar este potencial para aumentar la productividad.
Especial mencin requiere la revolucin provocada con la introduccin de los
PCs, cada vez ms poderosos, al punto de hacerse comparables con el rendi-
miento de los mainframes (equipos grandes).
Incluso surgi una tendencia, llamada Downsizing44, orientada a la reduccin
de tamao del equipamiento computacional y en general de toda la infraes-
tructura. En el caso de los equipos, tpicamente se pasa desde mainframes a
microcomputadores que tienen el rol de servidores en una red.
En todo caso, se aprecia que en las grandes instalaciones predominan los
equipos tipo mainframes, especializados en el manejo de alto volumen de
transacciones.
Una solucin que est siendo cada vez ms utilizada es disponer de estacio-
nes de trabajo con PCs poderosos donde los especialistas puedan desarrollar
y luego llevar el producto de software al computador central.
Es destacable que los avances del hardware han permitido el uso masivo de
software ms poderoso. Y viceversa, porque nuevo software, como los juegos
para nios, requieren hardware cada vez ms poderoso.
El respaldo y la solidez del proveedor fueron y siguen siendo fundamentales.
43
Sorprende al autor el rpido avance, en 1980 estaba a cargo de una instalacin con equipa-
miento por valor de ms de un milln de dlares. Hoy, a fines de la primera dcada del nuevo
milenio, esa misma instalacin (512 KB de memoria, 200 MB en disco, 6 terminales), costara
alrededor de una milsima parte y tendra 100 veces ms capacidad.
44
En el punto 3, Nuevas formas de las organizacin informtica, de la seccin 2.2, Planifica-
cin en Informtica, se describi este concepto.
5. Incorporacin del usuario

Es indispensable que trabajen en conjunto el usuario y el especialista. Resulta
evidente la necesidad de preparacin del especialista, sin embargo, tambin es
vital la formacin del usuario en la tecnologa de informacin.
No obstante, la dificultad no est en el grado de capacitacin, sino en algo mu-
cho ms profundo la adaptacin al cambio.
A veces el usuario no sabe exactamente lo que quiere, an as, eso no es moti-
vo para un trabajo anrquico. Es posible hacer prototipos en las etapas de an-
lisis y de diseo aunque sea solamente para aclarar sus requerimientos.
Usuarios entrenados en la tecnologa de informacin, particularmente mtodos
y herramientas amistosas, pueden desarrollar sus aplicaciones ms sencillas;
adems, estarn en condiciones de participar activamente en el desarrollo de
aplicaciones ms grandes en conjunto con el especialista.
Aqu influye un elemento conceptual de primera importancia: la aplicacin le
pertenece al usuario, l debiera ser el gestor, no los especialistas. La cons-
truccin de un sistema de informacin no significa una imposicin de cam-
bios al usuario, sino que es una respuesta a su requerimiento bien planteado.
El es quien debe hacer una buena gestin de la demanda.
El grado de xito de la aplicacin depender en gran medida de la compren-
sin que tiene el usuario de su propia necesidad45 y de la calidad de la infor-
macin entregada por l.
La introduccin del usuario en el desarrollo de software implica que l debe
aprender a dimensionar y analizar su problema, lo cual puede lograrse en el
contexto de un amplio esfuerzo de educacin, tal como vimos en la seccin
anterior.
Se puede hacer una similitud con la evolucin de los automviles desde prin-
cipios del siglo XX. Cuando recin aparecieron, se pensaba que era difcil su
masificacin, porque cada automvil requera un chofer-mecnico. Sin em-
bargo, los automviles se simplificaron, la infraestructura de apoyo mejor
(garajes, red vial, etc) y los usuarios aprendieron a conducir y a realizar el
nivel bsico de mantenimiento (cambio de neumtico o revisin de niveles).
45
Se presenta ante un Juez el infractor de una norma de trnsito, le dice: seor Juez, es la
primera vez que tengo una infraccin, puede anularla? El Juez seala el computador que
tiene en su escritorio (recin instalado, todava sin funcionar) y le dice: Si ingreso su identifi-
cacin, el sistema me dir si usted dice la verdad, lo hago? El infractor contesta: Prefiero
pagar. El Juez tiene clara su necesidad.
128 JUAN BRAVO C.
En el caso del desarrollo de software, hoy todos los elementos son ms amis-
tosos (hardware, muchas herramientas y mtodos), existe una importante in-
fraestructura de apoyo (departamentos de sistemas, consultores, proveedores)
y los usuarios estn aprendiendo.
Sin que el usuario afecte su especializacin dentro de la organizacin, debera
destinar unas 100 200 horas al perfeccionamiento inicial en tecnologa de
informacin y luego unas 40 horas anuales, en el marco de un equilibrio entre
especializacin y generalizacin. Naturalmente, la cantidad precisa de horas
para perfeccionamiento estar dada por la definicin de capacidades que se
deseen obtener y la preparacin previa del usuario.
Cmo influye la amistosidad de las herramientas en el aumento de la produc-
tividad? Se entiende la caracterstica de amistosidad en un sentido amplio, de
integracin del usuario e incluyendo el concepto de interfaz intuitiva, en el
cual se trata de dar al software el mximo de naturalidad a travs del uso de
imgenes, voz e conos.
Desde este punto de vista, se considera la caracterstica de amistosidad como
parte de la productividad, porque sta puede aumentar casi al doble si los
usuarios comienzan a resolver una porcin de sus propias necesidades, es-
timndose que ellos puedan absorber sin problemas casi la mitad del desarro-
llo lo cual significa que se libera la mitad del trabajo de los especialistas
particularmente la de aquellas aplicaciones que demoran ms en explicarse
que en hacerse. Esto es hoy una realidad para aplicaciones muy simples que se
pueden resolver, por ejemplo, con una planilla electrnica o con la contrata-
cin del servicio externo directamente por el usuario.
Hay que ser cuidadoso con no abusar de esta descentralizacin porque la au-
tonoma del usuario podra interferir con la necesidad de tener sistemas cen-
tralizados e integrados. La solucin del conflicto es materia de un proceso de
negociacin interna.
Cuando el usuario soluciona sus propias necesidades menores, se obtiene un
subproducto que aumenta en mucho la productividad: la reduccin de las in-
teracciones innecesarias con otras personas. Se le llama tambin costo de
transaccin o de administracin. Es el tiempo invertido en la definicin y con-
trol del acuerdo. Desde un punto de vista tcnico, se gana tiempo disminuyen-
do el overhead administrativo, el cual se podra definir como el tiempo im-
productivo destinado a una labor productiva. Este overhead46 tambin se
46
Se podra definir el overhead como el tiempo que ocupa el sistema en su organizacin
interna para dar respuesta al requerimiento. Por ejemplo, desde el punto de vista de la rapidez,
produce cuando una persona pretende hacer 2 3 tareas a la vez, descono-

ciendo nuestra limitacin natural de que slo podemos, realmente, hacer una
cosa a la vez, conscientemente. De esta manera se optimiza el uso del tiempo
y se obtienen mejores resultados.
Aunque estamos haciendo una suposicin peligrosa: que el usuario sabe lo
que quiere, porque l debiera conocer mejor que nadie su propio problema.
Todo analista experimentado sabe que generalmente eso no es cierto. Son bien
conocidas las dificultades para que usuarios intermedios se comprometan y
ayuden a completar la definicin de sus propios requerimientos.
Ms que una generalizacin en este sentido, sera ms preciso distinguir entre
dos tipos de usuarios:
Los emprendedores, bien representados como empresarios o intraempresa-
rios, quienes gestan, participan y se comprometen con su proyecto. Son los
menos. Ellos son intraempresarios o empresarios al interior de la empre-
sa, profesionales que luchan por el proyecto como si fuera algo personal.
Los dependientes, quienes participan en el proyecto por obligacin, buscan
a toda costa evitar comprometerse y quieren ver funcionando un sistema
perfecto antes de firmar un papel. Ellos se han visto arrastrados al pro-
yecto por imposicin de la alta gerencia o por otras razones. Ya sabemos
que la probabilidad de xito del desarrollo es baja en este caso.
Por supuesto, entre los emprendedores y los dependientes hay infinidad de
situaciones intermedias.
En algunas empresas est comenzando a implementarse una alternativa intere-
sante: contratar a un especialista en informacin. Este profesional debiera te-
ner amplios conocimientos de planificacin estratgica, proyectos, ingeniera
el procesamiento monousuario es ms eficiente que el manejo multiusuario, porque el proce-

samiento de dos tareas en paralelo demora ms que la suma de los tiempos de ejecucin de las
mismas tareas procesadas en serie. Cul es la causa? Al procesar concurrentemente, el proce-
sador gasta tiempo en la coordinacin de la ejecucin de los diferentes procesos debido a que
cuando se produce una interrupcin para dar prioridad a otro proceso, debe ocupar tiempo
para guardar el estado de la tarea anterior, inicializar variables y administrar el cambio de
tarea. Por ejemplo, si tenemos dos procesos que demoran una hora cada uno en modalidad
monousuario, al procesar en forma multiusuario es posible que los dos procesos terminen de
ejecutarse en 4 horas. En tal caso, el overhead habra sido del 100%, porque la suma de los
tiempos en modalidad monousuario es de 2 horas.
Cmo influir en este efecto la nueva generacin de equipos multiprocesadores? Ya se ver,
en todo caso, ser como procesamiento en diferentes equipos y un procesador debera atender
una tarea a la vez.
130 JUAN BRAVO C.
e informtica, entre otros temas que le permitan comunicarse bien con usua-
rios y especialistas en informtica.
6. Habilidad del desarrollador

La habilidad es algo que se obtiene principalmente con la buena experiencia y
una capacitacin puede acelerarla notablemente.
Un aspecto fundamental de la habilidad del desarrollador es su conocimiento
del negocio de la organizacin. Tambin debe tener claro el objetivo final:
entender como su trabajo agrega valor al negocio. Esto puede llevarlo a pro-
poner cambios drsticos en la aplicacin a su cargo.
Una situacin difcil de creer y lamentablemente reiterativa, es la de reas de
sistemas donde algunos de sus integrantes prcticamente no saben a qu se
dedica la organizacin y tampoco estn interesados en aprender, quieren se-
guir atrincherados en su inexpugnable y aislado reducto, tal como los castillos
de los seores feudales durante la Edad Media.
Sobre todo, las personas aprenden en un medio exigente y con colegas de ca-
tegora. Incluso, un importante elemento de motivacin para el programador
es trabajar en un ambiente donde est en constante aprendizaje.
Cmo influye la habilidad? Existen estudios que sealan diferencias de pro-
ductividad de hasta 30 veces entre programadores. Es fcil observar en cual-
quier organizacin las diferencias de rendimiento, ver que generalmente en
una muestra superior a 10 personas la relacin entre el menos y el ms pro-
ductivo comienza a pasar de las cinco veces. Resulta evidente nivelar hacia
arriba con un esfuerzo de investigacin que descubra causas asociadas al co-
nocimiento, actitudes y habilidades, como en la gestin por competencias.
Trabajar en tcnica y comunicacin

Hemos aprendido que se requiere trabajar en dos lneas a la vez: especializa-
cin y comunicacin interpersonal, tal como se muestra en la figura 2-4, don-
de se aprecia que la productividad es producto de la armona entre esos facto-
res. El extremo de la especializacin podra llevar a la incomunicacin. Las
mediciones que hemos realizado en empresas muestran que en promedio es-
tamos en 5 en especializacin y en 2 en comunicacin interpersonal, con lo
cual el producto es 10. Es decir, en el 10% del potencial. Es interesante sensi-
bilizar que si aumentamos 1 en la tcnica, el producto ser 12 y si aumenta-
mos 1 en la comunicacin, el producto es 15
Especializacin 10
100% de potencialidad
(mxima productividad)
0
0 10 Comunicacin Interpersonal
Figura 2-4. Armona entre tcnica y comunicacin
Es vital el factor comunicacin, especialmente en proyectos grandes. A esto se

refieren Stevens y Pooley (2002, p. 7): Todas las nuevas tecnologas prome-
ten reducir los tiempos de desarrollo y aumentar la tasa de xito de los proyec-
tos, pero los ingenieros de software experimentados tienden a ser justificada-
mente escpticos al respecto. Uno de los problemas fundamentales que ha de
afrontar una tcnica para tratar con grandes proyectos es el mito del hombre
mes de Fred Brooks. Cuanto mayor es el proyecto, mayor es la proporcin de
los costes del mismo y del tiempo que se pierde en la comunicacin entre la
gente del proyecto, debido a que cada persona tiene ms gente con quien co-
municarse. Es sabido que mientras ms gente sume a un proyecto atrasado,
este ms se atrasar.
7. Normalizacin externa
Es indispensable realizar un sostenido, coherente y planificado esfuerzo de
normalizacin al interior de toda la organizacin y con el exterior. As, cada
una de las etapas del desarrollo de software se realizar uniformemente, sin
las grandes variaciones entre los esquemas particulares de cada especialista.
Este esfuerzo debera estar considerado en el plan informtico, ser ejecutado
por el responsable de informtica y supervisado por el comit de informtica.
Qu debe normalizarse? Todo: el hardware, los mtodos de desarrollo, las
herramientas de software, el entrenamiento, la documentacin. Por qu es
necesaria la normalizacin? Porque la organizacin tiene que centrarse en su
negocio y tomar del medio lo que necesite para cumplir con su misin.
132 JUAN BRAVO C.
Si estamos en un hospital, su negocio es ayudar a recuperar la salud de los

pacientes y no el desarrollo de nuevas tcnicas de modelamiento o la cons-
truccin de hardware sofisticado. Si nuestra misin es producir o vender pren-
das de vestir, probablemente lo vamos a hacer muy mal si nos desgastamos en
crear e introducir mtodos particulares de desarrollo de software.
No obstante, la normalizacin interna debera dejar espacio para la creativi-
dad, el surgimiento de nuevas soluciones y el ensayo de nuevos mtodos y
herramientas. De alguna manera dejar una ventana abierta a la exploracin de
nuevas posibilidades, sin que la organizacin corra el riesgo de perturbar la
satisfaccin de sus necesidades de informacin. Sin ser una receta, a veces se
dice que el 90% de los requerimientos debieran canalizarse por las vas nor-
malizadas y el 10% por vas alternativas ms innovadoras, tal vez podra ser el
10% de menor impacto en la organizacin...
Las normas permiten acumular experiencia transmisible, son reglas de sentido
comn para la organizacin que van siendo parte de la inteligencia colectiva.
La normalizacin externa otorga mltiples ventajas a la organizacin. Veamos
algunas de ellas:
Le permite centrarse en su misin, sin distraerse en materias ajenas.
Puede solicitar personas capacitadas externamente, a diferencia de cuando
la tecnologa es particular, obligndose en este caso a efectuar grandes es-
fuerzos de entrenamiento.
Hay independencia de individuos que monopolicen y manipulen con el
conocimiento especfico interno.
Puede seleccionar del medio las mejores y ms productivas tecnologas.
Es ms sencillo subcontratar servicios especficos.
El concepto existente detrs de la normalizacin es la total integracin con el
medio. La nueva empresa no prosperar si se transforma en una isla porque
est inserta en un ambiente que recibe sus productos y a su vez le proporciona
personas, insumos, infraestructura y otra serie de servicios menos conocidos,
entre los cuales se cuentan tecnologas, esquemas de organizacin, mtodos de
trabajo y herramientas de apoyo. Frecuentemente, estos ltimos servicios han
sido desarrollados en forma particular en la empresa a un costo muy alto en
recursos y en prdida de oportunidades al dispersar los esfuerzos en tareas
prescindibles con el agravante de repetir esas tareas improductivas en diferen-
tes reas.
Tmese como ejemplo la anarqua en el desarrollo de sistemas computaciona-

les al interior de muchas organizaciones, existiendo en el medio buenos mto-
dos que podran satisfacer sus necesidades de manera simple y econmica.
Las principales caractersticas de la normalizacin son:
Siempre actualizada: a travs de reuniones peridicas destinadas a su revi-
sin, idealmente una vez por semana. Naturalmente, la normalizacin tam-
bin podra ser corregida frente a situaciones excepcionales, como la im-
plementacin de un nuevo sistema o la integracin de otra persona a la or-
ganizacin.
Simplicidad: una normalizacin larga y compleja, preparada solamente por
consultores o unidades especializadas de la empresa, est fuera de poca y
es poco prctica. Para incrementar las posibilidades de que se respete, de-
biera ser breve y precisa. Por ejemplo, las pautas referidas al rea inform-
tica, sobre mtodos, herramientas, hardware y software bsico, no debieran
exceder la decena de pginas.
Orientada a toda la empresa: la normalizacin tambin debe darse al inter-
ior de la empresa, de tal forma que todos sus estamentos normalicen polti-
cas, mtodos, herramientas, tecnologa y todo aquello que facilite la comu-
nicacin.
Consenso: las diferentes normas debieran ir surgiendo como resultado de
consenso entre todos los interesados, para asegurar la implementacin.
Cuando las pautas son impuestas por la jerarqua, consultores u organismos
especializados de la empresa, las posibilidades de que sean respetadas son
menores.
Permite las innovaciones: la normalizacin no significa ahogar la empre-
sa con reglamentaciones. Muy por el contrario, se toman del medio es-
quemas probados para no distraer la atencin de los verdaderos intereses de
la organizacin. En este contexto, las innovaciones son bienvenidas y pue-
den desarrollarse con amplia colaboracin. La buena normalizacin garan-
tiza el funcionamiento regular de la institucin, dejando espacio para el de-
sarrollo permanente de nuevas ideas.
Conocida por todos los interesados: se recomienda crear un sistema de
informacin destinado a enviar oportunamente un ejemplar de la normali-
zacin o de su actualizacin a todos los interesados, segn una base de
usuarios actualizada y con mecanismos apropiados para eliminar las co-
pias anteriores obsoletas.
Atiende materias especficas: no existe la normalizacin de la empresa,
sino que son varias y cada una atiende un asunto especfico. Es preparada
134 JUAN BRAVO C.
por quienes estn dedicados a la materia; por ejemplo, en la normalizacin

informtica participan analistas, programadores y usuarios. Otros temas se
orientan a mantencin, produccin, administracin o secretara.
8. Factores de contexto
Hay otra serie de factores que tambin debemos tomar en cuenta. Si son posi-
tivos pueden ayudar a aumentar la productividad ms all de las 10 veces sea-
ladas al comienzo de esta seccin acerca del Sistema de productividad en el
desarrollo de software.
Algunos factores de contexto son:
Calidad de la planificacin, en el sentido de su reformulacin permanente
y conocimiento de ella por parte de todos los integrantes de la empresa.
Alineamiento del plan TI con el plan de negocios de la organizacin.
Motivacin de las personas. Con amplia participacin, cumplimiento de
los acuerdos y un ambiente de colaboracin. Ya vimos en el captulo 1 la
especial relevancia que tienen el liderazgo y el trabajo en equipo.
Ambiente fsico: temperatura, ventilacin, comodidad, tranquilidad, silen-
cio y otros elementos ambientales tienen un importante rol que jugar en la
productividad de los profesionales de sistemas y de toda la organizacin.
Permeabilidad de la empresa a la innovacin tecnolgica.
Respuesta a la competencia y permanente conocimiento de lo que el mer-
cado ofrece.
Capacidad de la gerencia, particularmente en la lnea de ser ms
empresario que administrador.
Conocimiento del problema: es vital la participacin del usuario y decisivo
para el xito del proyecto de software.
Participantes experimentados: as aumenta la eficiencia y la probabilidad
de xito del proyecto.
Conocimiento del entorno donde se insertar el producto desarrollado.
Esta serie de factores de contexto podran resumirse en la bsqueda de la ex-
celencia en la gestin.
2.4. CRITERIOS DE DESARROLLO DE SOFTWARE
En gran medida, la idea de publicar esta obra nace del gran cambio producido
en la forma de enfrentar el diseo de una aplicacin computacional, antes
orientado a la optimizacin en el uso de recursos computacionales y ahora con
nfasis en la simplicidad y la calidad del diseo, independiente de la imple-
mentacin tecnolgica.
Con esa filosofa se presentan a continuacin antiguos criterios, nuevos mitos
y algunos principios para un nuevo esquema de desarrollo de software.
Veremos:
1. Criterios anticuados de desarrollo de software
2. Mitos del desarrollo de software
3. Nuevos principios para el desarrollo de software
4. Construir sistemas computacionales sin programar?
5. Pruebas del software por el programador
6. Mantenimiento de la solucin de software
1. Criterios anticuados de desarrollo de software

Antiguamente enfrentbamos el desarrollo de sistemas con el siguiente crite-
rio de optimizacin:
Mnimo uso de espacio en disco, memoria principal y tiempo de procesador.
La aplicacin de esta pauta dio origen a modalidades de construccin de sis-
temas que retrasaban el desarrollo, perturbaban la mantencin y dificultaban la
actualizacin de la documentacin, como stas:
Diseo del sistema en forma muy particular. Se definen repositorios de
datos y programas en forma muy particular para la aplicacin, tanto que,
finalmente, slo son conocidos por el especialista, con el riesgo de que aun
a l se le olviden las particularidades. Son las llamadas ingeniosidades.
Construccin de programas grandes que resuelven varias funciones. Se
supone que tienen la ventaja de cargar slo un programa que resuelve
muchas funciones, en lugar de varios programas que se iran llamando
segn se requieran. El programa grande es consumidor de recursos, difcil
de construir y de mantener. Habitualmente incorpora elementos extraos
como switches (marcas o banderas que ayudan a condicionar bifurcacio-
nes) e instrucciones sofisticadas del lenguaje, no posee una buena estructu-
136 JUAN BRAVO C.
racin y ms bien est construido con una desagregacin muy poco funcio-
nal.
Definicin de rutinas complejas. Nada hay que complique ms la manten-
cin que la incorporacin de rutinas complejas dentro de un programa.
Siempre es posible simplificar y modularizar las rutinas. Es ms, en la ma-
yora de los casos el problema que da origen a la rutina compleja podra
haberse enfrentado de otra manera en el diseo. Tambin podran utilizarse
rutinas prehechas o generadas con herramientas de cuarta generacin.
Construir rutinas complejas para resolver problemas del mismo tipo no es
como reinventar frecuentemente la rueda?
Utilizacin de matrices en programas. Es tpico de programas muy com-
plejos hacer uso indiscriminado de vectores o matrices, los cuales represen-
tan una excelente instancia de optimizacin, pero no deberan utilizarse a
menos que sea realmente indispensable porque el contenido del vector o
matriz queda invisible para la organizacin, la informacin pasa a ser parte
del cdigo, con enormes dificultades para su actualizacin (hoy con la in-
troduccin masiva de las bases de datos es menos frecuente en nuevos sis-
temas, sin embargo, todava hay mucha mantencin de sistemas antiguos).
Por ejemplo, en el cambio de milenio (pasar desde 1999 al ao 2000) el
problema era que en las aplicaciones antiguas los programadores haban
asignado solamente dos dgitos al campo ao para ocupar menos espacio.
De esta forma el computador entenda que pasaba desde 99 a 00 y enton-
ces bajaba de ao en vez de subir. Una complicacin adicional fue que los
datos estaban dentro del programa (por ejemplo, que hacer al llegar cierta
fecha) y no como parmetros. Adems, el 00 y el 99 se usaban como ban-
deras o condiciones de diferente tipo.
Con el abaratamiento de los medios de almacenamiento y la mayor velocidad
de los procesadores, el criterio de optimizacin qued obsoleto. Como mues-
tra, vase el siguiente ejercicio:
Un usuario de un PC necesita mejorar el tiempo de respuesta de su aplicacin,
la cual funciona bien, pero cada consulta demora hasta 10 segundos y l re-
quiere la respuesta en un mximo de 3 segundos.
Se plantean dos alternativas de solucin:
Adquirir un equipo ms poderoso, de mayor rapidez y capacidad de alma-
cenamiento. El costo de esta solucin es US$ 500, considerando lograr
algn ingreso con la venta del PC antiguo.
Contratar un programador para optimizar el cdigo de los programas. El

presupuesto es de US$ 400.
En la figura 2-5 se muestra el ejemplo de una tabla comparativa entre las solu-
ciones propuestas para un perodo de tres aos.
Ampliar Optimizar
Factor de comparacin hardware cdigo
Costo inicial US$ 500 US$ 400
Costo de mantencin US$ 100 US$ 600
Tiempo de implementacin 2 das 1 mes
Tiempo del usuario 1 da 1 semana
Utilizacin en otras aplicaciones alta nula
Figura 2-5. Tabla comparativa para disminuir tiempo de respuesta
Es interesante observar en la figura 2-5 lo engaoso que puede llegar a ser

dejarse llevar por el menor costo inicial de la optimizacin del cdigo porque
el costo total, considerando la mantencin del cdigo, asciende a US$ 1.000
en el caso de codificar y a US$ 600 en el caso de ampliar el hardware. Es cla-
ramente conveniente ampliar el hardware y esto sin considerar los otros facto-
res de comparacin que, si se cuantifican en dinero, ampliaran todava ms la
brecha.
Otros factores seran: cunto es el costo de oportunidad al retrasar la solucin
en un mes, en el caso de optimizar cdigo? y cunto cuesta el tiempo del
usuario, considerando que al optimizar cdigo debe disponer de tiempo para
interactuar con el especialista?
Es importante destacar que en el caso de la optimizacin de cdigo, se ha va-
lorado conservadoramente el costo de la mantencin, el cual puede elevarse
varias veces cuando el programa no est bien documentado o los mtodos de
programacin han sido anrquicos.
Este ejercicio se puede extrapolar a problemas mayores en las instalaciones,
donde hay otros factores que tambin inciden. El objetivo ha sido destacar que
la simple renovacin del hardware resuelve automticamente un cierto rango
de problemas. Lo mismo es vlido para variadas formas de externalizacin.
138 JUAN BRAVO C.
2. Mitos del desarrollo de software

En algunos departamentos de sistemas, nuevos mitos han tomado el lugar de
los antiguos criterios de desarrollo, mantenindose los clsicos problemas de:
Colas de desarrollo pendiente que alcanzan a varios aos.
Ciclo de desarrollo excesivamente largo, a veces de ms de un ao.
Dedicacin predominante a la tarea de mantencin, en lugar de atender los
nuevos requerimientos del negocio.
Algunos de los nuevos mitos en el desarrollo de software son:
Desarrollar rpidamente, apoyndose en variadas herramientas y olvidan-
do considerar que cada lnea de cdigo deber ser mantenida.
Una correcta especificacin evitar la mantencin, desconociendo que el
80% de la mantencin se debe a cambios y el 20% a errores.
Automatizar el mximo de funciones administrativas, sin evaluar que en un
gran porcentaje de los casos, el costo para la organizacin aumenta geom-
tricamente (se reduce 3 aumenta 9) a raz de la mantencin del cdigo.
Desarrollo por prototipos es la solucin, aplicndolo en sistemas compu-
tacionales donde su aporte es escaso y descuidando la necesaria definicin
previa de requerimientos.
Las herramientas de cuarta generacin sern la solucin, olvidndose de
la necesidad del modelamiento de la solucin, del aporte de cdigo muy
especfico y del problema de la conversin de datos desde aplicaciones an-
tiguas.
Cesanta de programadores, en la realidad se est produciendo el fenme-
no contrario, una oferta total de trabajo creciente para especialistas prepa-
rados en apoyar a los usuarios. Este mito se alimenta a veces de algunos
pocos ejemplos de externalizacin (outsourcing) donde se han despedido
programadores, sin tomar en cuenta que las nuevas empresas proveedoras
de servicios informticos contratan especialistas a una tasa mayor que los
despidos por ese concepto.
As llegamos a tener usuarios desesperados porque todava no obtienen lo que
necesitan, incluso algunos han optado por seguir su propio camino, produ-
cindose las llamadas islas de automatizacin, con lo que aumenta ms an
la confusin.
3. Nuevos principios para el desarrollo de software

En los aos 60 y 70 el manejo de informacin se orient ms a los procesos
computacionales que a la administracin de los datos, porque el objetivo era la
optimizacin de algoritmos para economizar tiempo y memoria debido a la
limitacin de recursos de hardware. Es en el mismo perodo cuando comienza
la aplicacin del anlisis y diseo estructurado.
En los aos 80 se dio una importancia desproporcionada a los sistemas admi-
nistradores de bases de datos (muchos especialistas pensaron que era la tan
anhelada panacea) con nfasis en las estructuras de datos. Fue un esquema
difcil de entender, engorroso de implementar y excesivamente caro, pero tuvo
el gran mrito de llamar la atencin sobre la importancia de los datos.
En los noventa, con el surgimiento de estndares como la orientacin a obje-
tos y UML, ms el nfasis en trabajar metodolgicamente, se dio inicio a un
proceso de profesionalizacin que efectivamente ha producido un avance en la
calidad del software.
Hoy estamos en busca de un equilibrio entre la orientacin a los procesos o a
los datos de ah que haya tomado auge tan rpidamente la orientacin a ob-
jetos. Es en este contexto que se plantean algunos principios para un nuevo
esquema de desarrollo de software:
Lograr la produccin profesional del software. A travs de mtodos y
herramientas normalizadas para producir software de calidad, personaliza-
do, econmico, portable, simple, rpido y amistoso, en plazos convenidos y
dentro del presupuesto asignado.
Resolver slo problemas simples. Aplicando los criterios de modulariza-
cin y de descomposicin funcional, siempre es posible dividir un proble-
ma complejo en un subconjunto de problemas ms fciles de resolver; por
lo tanto, lo que finalmente se resuelve son problemas simples, aunque man-
tenindose la visin de conjunto.
Evitar las particularizaciones producto de una optimizacin innecesaria.
Una vez que el problema ha sido resuelto en forma simple e independiente
de la implementacin tecnolgica, se debe estudiar si es realmente necesa-
rio aplicar frmulas de optimizacin, porque podran introducir sofistica-
ciones indeseadas en el modelo.
Independencia de la aplicacin respecto al especialista. Un problema fre-
cuente ha sido el alto grado de dependencia de la aplicacin respecto del
especialista que la desarroll. Lo que ahora se busca es permitir que otros
especialistas y usuarios calificados puedan tambin entender, mantener y
140 JUAN BRAVO C.
continuar el desarrollo de la aplicacin frente a la salida del primer desarro-

llador. De esta manera, cada nuevo desarrollo de sistema ser una inversin
en inteligencia para la organizacin.
Incrementar la productividad. Se requiere elevar la productividad de los
especialistas en, al menos, un orden de magnitud (de 1 a 10 veces), lo cual
es posible aplicando los conceptos de productividad de la seccin anterior.
4. Construir sistemas computacionales sin programar?

Es plenamente factible construir software sin necesidad de programar, me-
diante herramientas que generan completamente la aplicacin o a travs de la
biblioteca de clases de la orientacin a objetos (claro que en este caso, un
equipo de desarrollo previamente debera haber construido las clases).
Cierto que cualquier aplicacin compleja incluye en definitiva alguna cantidad
de programacin, tambin es vlido que el apoyo ofrecido por las herramien-
tas de productividad va en aumento y es posible que en algn momento repre-
sente un porcentaje cercano a la aplicacin completa. Hoy est consolidado su
aporte en la construccin de los elementos ms normalizados: definicin de
pantallas, informes, mens y otras partes de la aplicacin.
Una dificultad en la produccin de software es la estructuracin manual de
lgica o programacin, la cual relativamente pocas personas son capaces de
hacerla correctamente. Considrese que en Estados Unidos se han efectuado
estudios que indican que slo el 1% de la poblacin tiene aptitudes naturales
para ella (veremos que se refiere a la estructuracin de lgica en programas
grandes). Quienes no tienen esa aptitud natural y necesitan programar, deben
tener una larga formacin hasta lograrlo. En todo caso, si el porcentaje de la
poblacin con esa aptitud es tan bajo, significa que la programacin es una
actividad poco natural.
Una forma de reducir el impacto de este problema es mediante un buen diseo
implementado con la ayuda de una herramienta de productividad. Esto facilita
la participacin del usuario y se motiva al especialista a resolver el problema
en un nivel de modelo conceptual, ms que a nivel fsico, o de programacin.
Sin programar significa ms bien sin programacin tradicional, esos pro-
gramas largos, de miles de instrucciones en lenguaje de alto nivel, difciles de
construir y de mantener. No es el caso de la necesaria estructuracin de las
reglas del negocio en pocas decenas de lneas de pseudocdigo u otro tipo
de lenguaje, para ser incluidas en la base de conocimiento o en un diccionario
de funciones de la herramienta con la cual se estara trabajando. Por ejemplo:
SI campo existencia ES MENOR O IGUAL QUE campo nivel mnimo,

ENTONCES emitir orden de compra.
No es lo mismo escribir 50 reglas del negocio de 30 lneas cada una, que cons-
truir un programa de 1500 lneas de cdigo. Aunque en ambos casos debe
actuar un especialista. Lo primero lo puede hacer en pocos das, en tanto que
para lo segundo requerir de varias semanas, adems de mucha ms destreza.
Para mantener el cdigo, la dificultad disminuye proporcionalmente al tamao
de los programas; por ejemplo, realizar un cambio en una rutina de 30 lneas
es cuestin de minutos; el mismo cambio en un programa de 1.500 lneas re-
quiere varios das. Esto, porque impactan aspectos sicolgicos y de ordena-
miento del programa que hacen muy difcil el trabajo en un programa grande.
En resumen, en las aplicaciones complejas sigue existiendo la necesidad de
aportar cdigo, tarea destinada a especialistas en informtica, quienes pueden
acceder a tcnicas y herramientas que les simplificarn su labor. Sobre todo,
modelar bien.
5. Pruebas del software por el programador

Un concepto que aporta el mtodo es probar al tiempo que se construye por el
mismo programador, como al construir un edificio, donde podemos apreciar
que se va probando inmediatamente lo construido, si no se imagina el nivel de
dificultades si la red elctrica o de agua fuera probada por otras personas y en
otro momento?
La extrema especializacin en informtica llev a que en algunos centros un
programador slo codificaba y otra persona deba probar el programa, sealarle
por escrito los errores y entonces l proceda a efectuar las correcciones que
luego seguan el mismo ciclo. En gran medida, esta deficiencia se produca por
la separacin en dos etapas del proceso codificar-probar47.
Lo cual no se contrapone con la existencia de un rea de testing porque su labor
viene despus de que el mismo programador realiz las pruebas de lgica de su
propio cdigo.
Es que probar es ms que verificar la efectividad de una programa de computa-
dor, tambin significa probar la aplicacin completa para revisar su diseo y
47
A tanto lleg este criterio que en una oportunidad un programador se molest con el autor
de este libro porque le pidi que le entregara probada la rutina que el mismo acababa de cons-
truir. Explic, exaltado, que su funcin era codificar, no probar el resultado de las rutinas, esa
actividad, seal, era para alguien de inferior categora
142 JUAN BRAVO C.
verificar si se cumplen los requerimientos actualizados. Porque el problema

inicial podra haber variado mientras se diseaba o programaba.
Existe amplia flexibilidad para la realizacin de las pruebas. Podran llegar a ser
tan simples como ensayar con datos de prueba o equivalentes a un paralelo, por-
que se trabaja construyendo un prototipo que se va transformando poco a poco
en la aplicacin final, a travs de perfeccionamientos sucesivos. Las herramien-
tas CASE apoyaran la verificacin de consistencia y documentacin. Respecto a
pruebas con altos volmenes de datos, irreemplazables en aplicaciones grandes,
tambin se cuenta con apoyo semiautomtico, porque ya se est haciendo gene-
ral que las herramientas CASE provean generadores de datos de prueba.
Las ltimas pruebas son en ambiente real, lo que es equivalente a tener la apli-
cacin en funcionamiento normal, aunque en la forma de un piloto, tal como
vimos en la etapa de implementacin del mtodo.
Luego, la dinmica del medio y de la propia empresa48 hacen que todo sistema
est en permanente mejoramiento. Entonces, desde el principio hay que mante-
ner intacta la capacidad de desarrollo continuo de una aplicacin, tema que ve-
remos ms extensamente en el siguiente punto, sobre mantenimiento de la solu-
cin de software.
6. Mantenimiento de la solucin de software

Cada vez en mayor medida, la palabra mantenimiento est siendo reemplaza-
da por perfeccionamiento en el contexto de la tecnologa de informacin. Es
indispensable comenzar a aplicar al desarrollo de aplicaciones el concepto de
mejora continua, el cual comienza en el momento de terminar la implementa-
48
Cuando comenz la computacin este replanteamiento no era tan indispensable, porque las
variables ambientales se movan ms lentamente. Hoy, aparecen productos diferentes, nuevos
mtodos y herramientas con una velocidad sorprendente. La creciente competencia obliga a
mantener un muy alto nivel de flexibilidad y de adaptacin a todo tipo de cambios. Este es el
contexto de la teora del caos, la cual postula que una prediccin puede tener una alta proba-
bilidad de certeza solamente en el corto plazo, mientras que en el mediano y largo plazo la
prediccin no tiene ninguna validez y se obtendr un comportamiento errtico, de ah la pala-
bra caos. En el ambiente organizacional, esa alta probabilidad de ocurrencia significa slo
algunas semanas. Cualquiera estimacin de aos, es prcticamente intil, porque depende de
pequeos cambios en las condiciones iniciales que hoy da nos parecen insospechadas por
ejemplo: se fue un empleado clave, Estados Unidos aument su tasa de inters, se enferm el
gerente de finanzas, el dueo de la empresa tuvo un conflicto matrimonial, lanzamos un pro-
ducto menor con un xito sin precedentes... Esto significa que la planificacin debe agregar
la condicin de reformulacin permanente.
cin y aun dentro del perodo de garanta que todo sistema computacional debe
tener, al igual que un edificio o un nuevo artculo.
El perodo de garanta es el equivalente a la marcha blanca del desarrollo tradi-
cional de sistemas. Es un tiempo convenido, en el cual, adems de conservarse
la posibilidad de desarrollo continuo de la aplicacin, se busca disponer de los
mismos especialistas que participaron en el desarrollo. Tambin debiera dispo-
nerse de apropiados recursos de hardware y software, ojal los mismos que se
emplearon durante la construccin. Sabemos que este perodo es de alto nivel de
cambios, por lo tanto, es de simple responsabilidad estar preparados
Hablar sobre desarrollo continuo de un sistema computacional significa, entre
otras cosas:
Disponer de documentacin actualizada en todo momento, ojal con el
apoyo de alguna herramienta de productividad.
Un alto grado de participacin y compromiso del usuario.
Ir probando cada estructura o funcin que se construye, evitando juntar
todas las pruebas para el final.
Resolver en forma automtica los problemas de consistencia, de regenera-
cin de estructuras frente a cambios, de integracin del proyecto.
Generar automticamente o usar cdigo reutilizable en un alto porcentaje de
la aplicacin.
En esto puede ayudar la tcnica de desarrollo en espiral que se presenta en el
anexo 3.
En una instalacin tradicional, los principales esfuerzos de mantenimiento se
destinan a:
Modificacin o reconstruccin de programas.
Actualizacin de documentacin.
Bsqueda de programas, bibliotecas y documentacin.
Ordenamiento de manuales, versiones de programas y cambios en reposito-
rios de datos.
Pruebas.
Reentrenamiento.
Aqu hay una diferencia notable respecto al mtodo tradicional. Ahora el man-
tenimiento del sistema significa realizar cambios sobre el diseo, la especifica-
cin o las reglas del negocio y rehacer parte de la aplicacin con la ayuda de
alguna herramienta de desarrollo.
144 JUAN BRAVO C.
Se estima que este solo concepto permite elevar la productividad de los especia-
listas en un departamento de sistemas al menos en 100 %, porque unos dos ter-
cios de las actividades regulares de los centros de computacin estn destinadas
a mantenimiento.
Junto con el mantenimiento de un sistema computacional se realiza su explota-
cin, esto es, la operacin regular de la aplicacin destinada a satisfacer el
requerimiento para el cual fue construida. Sin pretender profundizar en esta
materia, conviene sealar algunas labores clave:
Mantencin de una bitcora de procesos
Control de funcionamiento correcto
Optimizacin de recursos
Reconstruccin de bases de datos
Seguridad e integridad de la informacin
Recuperacin de la informacin
Auditora computacional
2.5. MTODOS PARA LA PRODUCCIN DE SOFTWARE
Los mtodos de desarrollo apuntan a cmo construir tcnicamente el soft-

ware. Generalmente se han clasificado en dos grandes grupos:
Sobre la gestin del proyecto: donde se proponen mtodos para planifica-
cin y control del proyecto de software.
Sobre el desarrollo del software: donde se proponen mtodos generales
para todo el ciclo de desarrollo y particulares segn cada etapa: anlisis, di-
seo o implementacin.
En lo que sigue, se presentan algunos ejemplos de mtodos de apoyo: el ciclo
de vida clsico, que abarca todas las etapas del desarrollo de sistemas, la
tcnica de prototipos, la cual apoya especialmente las etapas de ingeniera y
diseo y el diseo estructurado. Todos han tenido su cuota de contribucin en
las definiciones que estamos logrando.
No se incluye aqu la orientacin a objetos ni UML porque, debido a su im-
portancia, les dedicamos los captulos 5 y 6.
Veremos:
1. Ciclo de vida clsico
2. Tcnica de prototipos
3. Diseo estructurado
4. Programacin extrema (XP)
1. Ciclo de vida clsico

El ciclo de vida clsico es ms que un mtodo orientado slo a la produccin
de software, representa un todo armonioso dirigido al desarrollo de sistemas
de informacin49.
Consta de las siguientes etapas:
1.- Diagnstico: su objetivo es identificar el problema y situarlo en su medio.
2.- Factibilidad: su objetivo es plantear y evaluar alternativas de solucin al
problema identificado.
3.- Diseo lgico: su objetivo es determinar qu se requiere; apunta hacia el
desarrollo administrativo de la alternativa seleccionada, principalmente en
49
En el libro Desarrollo de sistemas de informacin, una visin prctica, se analiza este
mtodo en todo detalle.
146 JUAN BRAVO C.
cuanto a departamentalizacin, organizacin general, definicin de los

procesos del negocio, diseo de funciones, flujos de informacin, diseo
de formularios, diseo del sistema de codificacin y diseo del modelo de
datos (modelo de informacin).
4.- Diseo fsico: su objetivo es el diseo computacional del sistema; se defi-
nen los conjuntos de datos, la organizacin del sistema y se especifican
los programas.
5.- Programacin: su objetivo es construir y probar los programas especifi-
cados en la etapa de diseo fsico.
6.- Implementacin: su objetivo es la puesta en marcha del sistema mediante
pruebas generales, produccin de la documentacin del sistema, entrena-
miento de las personas, poblamiento de las bases de datos y procesamien-
to en paralelo.
7.- Mantencin: su objetivo es dar respuesta a cambios sobre el sistema des-
pus de su implementacin. Se estima que esta tarea consume tanto tiem-
po y recursos como unas tres veces todas las etapas anteriores (con el
riesgo de que se eternice).
Estas siete etapas del ciclo de vida clsico se aplican en la modalidad tipo
cascada, es decir, se realiza cada una con todos los requerimientos antes de
pasar a la siguiente.
Los problemas ms comunes que intenta resolver este mtodo son:
Tiempo de desarrollo normalmente excedido.
Largas colas de espera de aplicaciones por desarrollar: visibles, que estn
en la planificacin de actividades, e invisibles, de usuarios que an no co-
munican ese requerimiento, justamente por el excesivo tiempo de respuesta
del rea de informtica.
Especificaciones poco adaptadas a la realidad. La demora en los ciclos de
desarrollo provoca una desactualizacin de los requerimientos iniciales.
As, la etapa de implementacin viene seguida de una redefinicin de re-
querimientos y de un nuevo proceso de desarrollo, retardndose excesiva-
mente la etapa de explotacin.
Aplicacin anrquica del mtodo, prcticamente cada especialista tiene su
propia forma de desarrollar sistemas.
Dificultad de comunicacin entre especialistas y usuarios.
Aplicaciones poco flexibles.
Y sin considerar los problemas de la mantencin y documentacin.

Aunque es posible aplicar desarrollo en espiral, generalmente el mtodo de
ciclo de vida clsico usa el esquema tipo cascada, donde se requiere un muy
alto grado de precisin en la determinacin de requerimientos para enfocar la
aplicacin desde una perspectiva integral. Se hace necesaria entonces una gran
capacidad de abstraccin por parte del usuario para plantear todas sus posibles
necesidades y por parte del analista para hacer las preguntas precisas y sugerir
las soluciones posibles.
Pese a lo necesaria que puede resultar para este tipo de tareas, la capacidad de
abstraccin no est suficientemente desarrollada en el ser humano. Si ya se
requiere un gran esfuerzo de formacin para el desempeo de tareas netamen-
te intelectuales, como el trabajo administrativo, donde se utiliza mucha simbo-
loga (escritura y clculos) y un cierto nivel de abstraccin; entonces, qu
sucede cuando un usuario se enfrenta a pensar todas las posibles variaciones
de un proceso todava inexistente? Lo ms probable es que resulte un esfuerzo
largo, tedioso e intil, porque los requerimientos quedarn incompletos, con-
fusos y errados.
Por qu debieran enfrentarse usuarios y especialistas a este esfuerzo poco
natural? Simplemente por inercia, porque as se ha hecho siempre. El ciclo de
vida clsico ayuda a resolver esta situacin, aunque al principio (desde los
aos 60) era slo para iniciados siendo muy escasa su difusin. En el mismo
perodo, el hardware ha mejorado a niveles bastante conocidos y el software
ha evolucionado desde los lenguajes de alto nivel a las nuevas herramientas de
productividad.
Se utiliza el trmino iniciados haciendo una comparacin exagerada con los
gremios de la Edad Media, los cuales seleccionaban secretamente a los futuros
miembros y los iniciaban en los secretos del oficio.
2. Tcnica de prototipos
La idea del prototipo de un sistema computacional es la misma que el prototi-
po de un avin o de un automvil: a partir de una idea original, se construye
un producto concreto que se perfecciona mediante aproximaciones sucesivas
realizadas en mltiples contactos de prueba con la realidad.
La tcnica de prototipos es una ayuda en cualquier etapa del ciclo de desarro-
llo, porque permite aclarar un problema o visualizar una solucin. Tambin
complementa algunos mtodos de diseo con excelentes resultados.
148 JUAN BRAVO C.
Existen prototipo evolutivos y de usar y botar. Los primeros siguen un proceso

de avances sucesivos bien controlado que poco a poco van perfilando una so-
lucin. Los segundos son especficos y a estos nos referimos principalmente
en este punto.
Un prototipo no es el sistema final. Se hace esta aclaracin porque a veces
entran en explotacin sistemas incompletos que nacieron como prototipos.
Eventualmente un prototipo puede ser la base de un sistema concreto, pero
hay que terminarlo.
Esta tcnica est adaptada a lo natural para el ser humano: tomar decisiones
segn el mtodo de prueba y error; es decir, pensar una solucin, desarrollarla
y probar, si sirve queda, si no sirve se descarta, en lugar de excesivos estudios
y planeamientos.
Un artculo de la revista Amrica Economa en 1993 revel que el nivel de
fracasos de proyectos con extensos estudios de mercado es de un 92%. Queda
el mensaje implcito que se obtienen casi los mismos resultados sin haber
hecho mayores estudios y aplicando mucho sentido comn.
La tcnica de prototipos necesita una definicin de requerimientos menos ex-
haustiva para plantear un producto de software que se va perfeccionando de
acuerdo con lo observado en las pruebas y segn el uso real y prctico. Es
importante sealar que en este caso el cambio es suave, escalonado, adaptado
a las necesidades reales y no traumtico para usuarios, quienes no ven altera-
das sus rutinas de un momento a otro, como cuando llega un nuevo sistema en
el cual no han participado.
El desarrollo por prototipos tiene su base en la tcnica de prueba y error, am-
pliamente utilizada en la naturaleza, lo que se puede apreciar a simple vista al
observar la adaptacin al cambio y el crecimiento de las especies.
Cmo influye el error en el crecimiento?
En la naturaleza, cada error que se produce es una alternativa que se prueba.
As funciona: supngase que una manada de osos se traslada hasta el Polo
Norte50; la piel de estos osos es mediana y no est adaptada a los rigores de las
bajas temperaturas, por lo tanto, se estima que en unas 4 generaciones ya de-
beran haberse extinguido totalmente. Sin embargo, eso no sucedi!, a la
cuarta generacin la poblacin de osos es superior a la que lleg inicialmente,
50
(Esperemos que seamos capaces de detener el calentamiento global para que los osos de
este ejemplo conserven su habitat y puedan sobrevivir, al igual que muchas otras especies).
pero... la mayora tiene una caracterstica diferente: su piel es ms gruesa que

la de los osos de la primera generacin.
Por qu?
Tal vez la piel se fue haciendo progresivamente ms gruesa como respuesta
al medio, producto de una planificacin o de un supercerebro? No! Sim-
plemente es otro error de la naturaleza que result ser apropiado en ese am-
biente y aumentaron las probabilidades de supervivencia y de reproduccin de
los ejemplares que nacieron con el error de una piel ms gruesa.
Cmo funciona?
Puesto que la naturaleza est siempre cometiendo errores, apliquemos esto al
grosor de la piel, tal como se muestra en la figura 2-6.
Poblacin de osos
Primera generacin Cuarta generacin
En el Polo Norte
Piel Piel Piel gruesa Grosor de la

delgada normal piel
Figura 2-6. Ejemplo de grosor de la piel de las cras de osos
Obsrvese en la figura 2-6 que la ms alta probabilidad en la primera genera-

cin se da para que la piel de una cra sea normal, es decir, muy parecida a
la de su ascendencia. Una menor probabilidad, en los extremos de la curva y
equivalente entre s, independiente del medio, se da para que nazcan oseznos
con piel ms delgada o con piel ms gruesa. Cuando nacen con piel ms del-
gada, las probabilidades de sobrevivir en el fro son escasas. Cuando nacen
con piel ms gruesa no slo aumentan sus probabilidades de sobrevivencia,
sino que, adems, pueden transmitir ese error a un mayor nmero de cras,
logrndose que, poco a poco, se mueva la curva de normalidad desde piel me-
diana a piel gruesa.
Esto es el mtodo de prueba y error que emplea la naturaleza y es la base para
plantear el mtodo de prototipos.
150 JUAN BRAVO C.
Para la mejor comprensin del mtodo de prototipos, puede observar el juego

de un nio, ojal menor de 7 aos, para apreciar cmo, una vez que se plantea
una meta, hace todos los intentos necesarios para cumplirla; aprende de sus
errores y no se cuestiona personalmente por cada fracaso que tiene. Tam-
bin se puede apreciar la libertad que usa para buscar soluciones a su proble-
ma, sin mayores prejuicios. Se podr observar que la forma de seleccionar
alternativas que el nio emplea, an est exenta de nuestros patrones de con-
ducta, de nuestros limitantes debe ser as.
Cuando el nio ensaya opciones, las primeras alternativas que practica son las
que le proveen de mayor informacin, as aprende por cuales caminos seguir
despus.
As tambin con los prototipos; cada iteracin y especialmente las primeras,
proporcionan valiosa informacin para realizar correcciones y decidir la nueva
ruta. Por lo tanto, teniendo claro los objetivos, el rumbo principal de una apli-
cacin queda definido en las primeras iteraciones con el prototipo.
Los prototipos se aplican habitualmente a:
Definir requerimientos: significa efectuar una presentacin preliminar de
formularios y procesos para acotar y aclarar el requerimiento. Generalmen-
te el prototipo es desechado despus de cumplir con su objetivo.
Revisar interfaces visuales: son los ms habituales y se confeccionan para
repasar el formato, la presentacin y la secuencia de mens, pantallas de
ingreso de datos, formularios, informes y todo lo relacionado con la inter-
accin con el usuario.
Estudiar la funcionalidad principal: significa definir con precisin cul es
el objetivo principal del sistema y construir un prototipo que resuelva esa
necesidad especfica; por ejemplo, el control del stock en un sistema de in-
ventarios o el formulario de liquidacin de renta mensual en un sistema de
remuneraciones.
Dependiendo de cada problema, debe estudiarse la real conveniencia de apli-
car la tcnica de prototipos, ella es especialmente til en problemas adminis-
trativos donde cuesta definir todos los requerimientos o los mismos son muy
cambiantes; en tal caso, el usuario deseara ver un bosquejo de lo que desea
antes de hacer una definicin en detalle.
En las primeras iteraciones con el prototipo se utilizan datos de prueba, luego
se va introduciendo informacin ms consistente, hasta llegar a trabajar con
los datos reales. Puede realizarse entonces una comparacin contra el funcio-
namiento manual del sistema o alguna solucin de software anterior, aunque
esto en la prctica ha resultado difcil, porque muchas de las facilidades que se

obtienen con las herramientas de apoyo no existan antes.
En general, no son aplicables los prototipos para el desarrollo de sistemas de
uso generalizado, tales como inventarios, cuentas por cobrar, cuentas corrien-
tes y contabilidad. Es preferible que la empresa adquiera ese tipo de sistemas
en el mercado y reserve el desarrollo interno para los sistemas computaciona-
les directamente relacionados con su negocio.
3. Diseo estructurado
El diseo estructurado responde a una visin funcional del sistema. Naci en
los aos 60, en un contexto tecnolgico totalmente distinto al que conocemos
hoy. En aquellos das era fundamental la economa de espacio en disco y de
memoria. Tampoco estaba bien desarrollado el concepto de modelo de datos,
apenas comenzaba a considerarse en grandes instalaciones.
Algunos conceptos asociados al diseo estructurado son:
Estructura jerrquica: significa modelar el sistema desde arriba hacia aba-
jo, tipo top down, comenzando por una visin de alto nivel que se va deta-
llando en niveles cada vez ms profundos.
Concurrencia: significa que existen varios procesos que pueden ser activa-
dos en forma simultnea; se aplica en contraposicin al sistema secuencial.
Modularidad: significa identificar mdulos completos, bien definidos y
con las interfaces entre ellos. Cada mdulo tiene una funcin precisa sobre
una estructura de datos. Una caracterstica deseable es que un mdulo pue-
de servir a otra aplicacin. Se aplican aqu los siguientes criterios:
o Acoplamiento, equivalente a traspasar informacin entre rutinas. Se su-
giere que sea lo ms dbil posible.
o Cohesin interna del mdulo; lo ms fuerte posible.
Descomposicin funcional: es el concepto detrs de la modularidad, signi-
fica tener funciones atmicas, que resuelvan solamente una necesidad, con
la mayor independencia entre s.
Antes, junto con el diseo estructurado se ocupaba la programacin estructu-
rada, con la idea de que los mdulos definidos a nivel del diseo pudieran ser
parte de un programa, ms precisamente, de un gran programa. Porque el ob-
jetivo de la modularidad era incluir una gran cantidad de mdulos en cada
programa. Supuestamente, eso simplificara la construccin y la mantencin.
Estudios sicolgicos demostraron que eso es prcticamente imposible, porque
aun cuando un programa estuviera bien estructurado y documentado, lo cual
152 JUAN BRAVO C.
es de por s casi una utopa, despus de un tiempo ni siquiera el programador

que lo construy crea en eso y efectuaba revisiones detalladas para efectos de
la mantencin, perdindose los supuestos beneficios del enfoque51.
Las principales herramientas del diseo estructurado son: Diagrama de Flujo
de Datos (D.F.D.), Diccionario de Datos (D.D.) y mini especificaciones en
pseudolenguaje.
El diagrama de flujo de datos se presenta a travs de diferentes niveles que
representan el grado de descomposicin de los procesos en subprocesos, hasta
llegar al nivel elemental o atmico. Esta herramienta se divide en dos partes:
diagrama de contexto y D.F.D. nivelado; veremos cada una de ellas, ms el
D.D. y la mini especificacin.
El diagrama de contexto muestra la ubicacin del sistema respecto al medio
donde se encuentra. La ubicacin est dada por la relacin que se produce (y
que debe existir) entre las entidades que le solicitarn o le proveern de datos
o informacin. Las entidades tambin llamadas fuentes son empresas,
departamentos o personas relacionadas con el sistema, las cuales proveen o
reciben informacin del sistema;
En la figura 2-7 podemos apreciar un ejemplo: el diagrama de contexto de un
sistema de control de stock.
Pedidos y Costos
Clientes devoluciones Gerencia
Artculos y factura Niveles

Control
de stock
Artculos y gua Despacho de artculos
Proveedores Orden de compra y Sala de ventas

Peticiones
devoluciones
Figura 2-7. Ejemplo de diagrama de contexto
En la figura 2-7 el crculo seala el sistema y los rectngulos indican las enti-
dades con las cuales se relaciona. Los flujos de informacin se muestran con
51
Una experiencia interesante ha sido que el diseo estructurado no obliga a tener programa-
cin estructurada, as como la orientacin a objetos no obliga a emplear programacin orien-
tada al objeto.
lneas rectas continuas terminadas con una cabeza de flecha, la que seala la
direccin del flujo.
D.F.D. nivelado
El diagrama de flujo de datos nivelado permite describir un sistema en sus
componentes y en su flujo; se relacionan procesos, datos y repositorios de
datos. Posee la estructura general que se muestra en la figura 2-8.
Datos Datos Datos

Proceso Proceso
Datos
Archivo
Figura 2-8. Estructura general de un D. F. D.
Comienza con un diagrama de nivel 1 o superior, como el de la figura 2-9,

donde la relacin entre ambos procesos (1 y 2) se da a travs de un almacena-
miento o archivo.
1 2 Ventas, traspasos y
Compras, traspasos
Recibir Despachar devoluciones
y devoluciones
Unidades y Unidades
costo
Artculos
Figura 2-9. Ejemplo de D. F. D. nivelado
Veamos algunas de las caractersticas del D. F. D. nivelado:

No es necesario volver a indicar las entidades externas, ya que es suficiente
con la lnea de flujo de datos.
Los archivos (o tablas) son conjuntos o repositorios de datos, como una
gua de despacho o una factura. Vendran a ser depsitos de datos tempora-
les o permanentes; con diferente notacin en cada caso, una o dos barras,
respectivamente, tal como vemos en la siguiente figura:
154 JUAN BRAVO C.
Archivo = Archivo temporal
Archivo = Archivo permanente
Los procesos indican una transformacin de los datos para lograr un prop-
sito bien definido; por ejemplo, ingresar o despachar. Generalmente, el
nombre del proceso es un verbo en modo infinitivo.
Los datos fluyen dentro de un Flujo de Datos (F.D.), es una lnea con di-
reccin en la cual se seala un paquete de informacin conocida, en un
mismo instante del tiempo (si diferentes datos van en momentos distintos,
sera necesario agregar otra lnea).
El DFD comienza con un primer grado de abstraccin, generalmente represen-
tado con un dgito, como los procesos 1 y 2 de la figura 2-9. Cada proceso
puede generar otros DFD en forma jerrquica, respetando la numeracin co-
rrespondiente segn cada estrato de profundidad; por ejemplo, el proceso re-
cibir de la figura 2-9 incluira tres subprocesos en el siguiente nivel: 1.1 com-
prar, 1.2 recibir devolucin, 1.3 recibir traspaso. Si fuera necesario un mayor
nivel de detalle, el prximo nivel tendra la numeracin: 1.1.1, 1.1.2, 1.1.3,
..... y as sucesivamente. Se les llama niveles elementales a los ltimos niveles
de descomposicin.
Cada proceso tiene asociado un diccionario de datos (DD) y una mini especi-
ficacin en pseudolenguaje.
Diccionario de datos
El diccionario de datos es el apoyo detallado de los DFD, incluye:
Descripcin y componentes del flujo de datos.
Descripcin de repositorios de datos.
Descripcin de las primitivas funcionales (ver mini especificacin).
Cualquier otra definicin; por ejemplo: frecuencia de un proceso, tamao
de repositorios de datos, prioridades y tipo de procesamiento, periodicidad,
caractersticas y estructura de datos.
Mini especificacin
La mini especificacin consiste en detallar lo ms fielmente posible la funcio-
nalidad del proceso. Para esto se usa pseudolenguaje, el cual es equivalente a
espaol estructurado. Veamos algunas de sus caractersticas:
Se ocupan palabras clave: si, entonces, sino, mientras, repetir, fin.

Tambin se emplean verbos, tal como: incrementar, buscar, extraer.
Permite reemplazar los diagramas de flujo.
Puede ser utilizada a cualquier nivel de abstraccin, o nivel del proceso en
el D.F.D.
Se construye el flujo de control del proceso, usando el estilo jerrquico
hacia abajo, o top down. Significa que cada frase puede ser expandida en
un pseudocdigo ms detallado, en un nivel inferior.
Cuando se ensea sobre pseudolenguaje, generalmente se le compara con una
receta de cocina, como muestra de simplicidad y secuencia. Sin embargo, la
prctica demuestra que esa comparacin es un mito, porque el grado de flexi-
bilidad que posee la receta es absolutamente distinto de la rigidez y cuidadosa
estructuracin del pseudocdigo. Cualquiera de nosotros puede seguir una
receta sin mucha rigurosidad y lograr un objetivo ms o menos aceptable; se
imagina si hiciramos lo mismo con un programa de computador? Los resul-
tados seran aleatorios y el desastre seguro.
Una supuesta ventaja del diseo estructurado es la presentacin grfica a
travs de los DFDs, como el diseo de una casa se ha dicho. Sin embargo,
esos diagramas, ms el diccionario de datos y la mini especificacin, han re-
sultado duros para el usuario tpico y han desalentado la participacin.
No obstante las limitaciones indicadas, el diseo estructurado fue hasta los
aos 80 prcticamente la nica forma coherente, completa y normalizada de
modelar la realidad para efectos del desarrollo de un sistema computacional.
Su refinamiento mediante pasos sucesivos, la descomposicin funcional que
provee, la autodocumentacin y la facilidad para efectuar cambios en el mode-
lo han sido vitales para su adopcin generalizada en el ambiente profesional.
Incluso, durante los noventa se presentaron nuevas versiones refinadas, como
el Anlisis y diseo estructurado mejorado que Edward Yourdon presentara
en 1994.
4. Programacin extrema (XP)

La programacin extrema es ms conocida por su sigla en ingls, XP (Extre-
me Programming) y es tambin llamada metodologa gil de desarrollo de
software. Se puede aplicar con variados mtodos.
La programacin extrema es ms bien un concepto que lleva al extremo las
mejores prcticas del desarrollo. El mtodo GSP (captulo 1) la contempla a
travs del nfasis en los pocos crticos de Pareto y en el desarrollo en espiral.
156 JUAN BRAVO C.
Explican Kendall y Kendall (2005, p. 68): Las cuatro variables que un des-
arrollador de sistemas puede controlar son el tiempo, el costo, la calidad y el
alcance. Cuando estas cuatro variables de control se incluyen de manera apro-
piada en la planificacin, se genera un estado de equilibrio entre los recursos y
las actividades que se requieren para terminar el proyecto Las actividades
de XP consisten en codificar, probar, escuchar y disear. Por supuesto, la co-
dificacin es esencial en cualquier proyecto de software. Las pruebas de fun-
cionalidad, desempeo y conformidad son obligatorias. La actividad de escu-
char al cliente y otros programadores y analistas es fundamental.
En el fondo, programacin extrema es hacer bien las cosas, lo cual es lo que
mejor permitir un desarrollo gil, ese es uno de los mensajes de este libro.
Para evitar caer en la tentacin de considerarla una panacea (o bala de plata)
veamos lo que dice Steve McConnell (1997, pp. 4-5): Si trabaja en una orga-
nizacin normal y sigue los mtodos descritos en este libro. Podr reducir
significativamente su tiempo de desarrollo, puede que hasta la mitad, e incre-
mentar tambin su productividad. Adems, podr hacerlo sin alterar la cali-
dad, el coste, el rendimiento o la facilidad de mantenimiento. Sin embargo, la
mejora no ser instantnea, no la obtendr a partir de una nica y nueva
herramienta o mtodo, y no la alcanzar cogiendo simplemente el paquete de
la estantera. Requerir tiempo y esfuerzo. Hubiera deseado tener una solucin
sencilla para el problema de la velocidad del desarrollo. Tambin me gustara
tener cinco millones de dlares. Pero las soluciones simples tienden a funcio-
nar slo con problemas sencillos, y el desarrollo de software no lo es. El desa-
rrollo rpido de software es an menos simple.
McConnell tambin se refiere a que hay variados modelos para el desarrollo
rpido y que esto depende del tipo de proyectos (1997, p. 122): Diferentes
proyectos tienen diferentes necesidades de desarrollo rpido, aunque todos
necesiten ser desarrollados tan rpido como sea posible.
En fin, hay consenso en que la receta es trabajar duro y con mtodo.
2.6. APOYO DEL DISEO EN LA EXPLOTACIN DEL

SISTEMA
El objetivo de esta seccin es analizar la potencialidad de la etapa de diseo

para asegurar el buen funcionamiento del sistema durante su vida til.
Es sabido que tomando algunas precauciones en la etapa de diseo de la aplica-
cin que luego se implementen, la explotacin mejora en mucho. A diferencia
de cuando se pretende incorporar ayudas para la operacin y auditora del siste-
ma durante la construccin o en la misma explotacin. En este caso el costo
aumenta al menos en un orden de magnitud y el modelo pierde elegancia.
El criterio con que abordaremos esta seccin es mxima participacin del
usuario en el diseo y mnimo esfuerzo durante la operacin del sistema.
Para obtener una aplicacin amistosa, es deseable ejecutar cada proceso de la
forma ms automtica posible, evitndose el ingreso de parmetros, fechas u
opciones de men.
Veremos:
1. Operacin del sistema
2. Auditora computacional
3. Contribucin del diseo a la proteccin de la informacin
4. Seguridad de la informacin
5. Integridad de la informacin
6. Recuperacin de la informacin
1. Operacin del sistema

Entendemos la operacin como el conjunto de tareas que permiten el buen
funcionamiento de la aplicacin, realizadas por especialistas y usuarios. Es
importante este cambio de concepto, porque ya qued atrs la poca cuando la
operacin del sistema slo estaba ligada a la participacin de un operador
computacional. En sistemas mayores hoy es una labor de conjunto y en siste-
mas pequeos los usuarios pueden realizar todas las labores.
El diseador del sistema debera conocer algunas tareas tcnicas propias de la
operacin, como las siguientes:
Mantencin de una bitcora de procesos: incluso en los sistemas de tiempo
real hay procesos batch que es indispensable programar segn una bitcora de
158 JUAN BRAVO C.
procesos, para equilibrar la carga del computador, cumplir con entregas de ti-
po peridico y por seguridad.
Control de funcionamiento correcto: para asegurar el buen funcionamiento de
un sistema en cada ejecucin (o en puntos intermedios dentro de la misma)
debera verificarse que los totales de control sean coincidentes entre las dife-
rentes partes del proceso (por ejemplo, nmero de registros ledos igual a la
cantidad de artculos impresos) y que estn de acuerdo con promedios histri-
cos. La mayora de las verificaciones de este tipo podran haber sido conside-
radas en el diseo e informadas en forma automtica al presentarse diferencias
(o un simple trmino normal si todo est bien).
Uso de recursos: una importante tarea que tambin podra estar parcialmen-
te incorporada en el diseo, es buscar permanentemente minimizar el uso de
recursos. Esto significa:
Estudiar el tamao de bases de datos para dimensionar dispositivos.
Borrar los archivos temporales o tablas intermedias
Dosificar el procesamiento del sistema para evitar las fluctuaciones
innecesarias en el uso de procesador, las que podran disminuir el
rendimiento.
Estudiar las secuencias de control para evitar duplicidades en proce-
sos u ordenamientos.
Organizar el uso de la impresora para economizar papel, obtener los
informes en el mnimo de tiempo, etc
Evitar la impresin automtica de informes, mejor dejar disponible
en el sistema para que el usuario lo vea y decida si lo imprime o no
(con cargo a su centro de costo por supuesto).
Este tipo de tareas no implica particularizar el diseo ni romper la uni-
formidad, son parte del conjunto de normas del rea de informtica.
Reconstruccin de bases de datos: dependiendo del sistema operativo del
computador, en algunos casos ser necesario reconstruir peridicamente la ba-
se de datos, con el fin de reorganizar las claves y recuperar el espacio ocupado
por registros eliminados.
Qu pasa si?... significa preguntarse cmo apoyar la operacin, cuando, por
ejemplo, se corte la luz, se saturen las lneas o una tabla se dae. Una causa de
las serias dificultades en que caen algunos sistemas es porque no se hicieron
estas preguntas a nivel del diseo.
Desde el punto de vista del mtodo presentado en el captulo 1, ms all de
los planes de contingencia, el concepto es la continuidad operacional.
2. Auditora computacional
Dado el carcter contralor de la auditora, sta tiene tuicin sobre todas las reas
de la empresa. Una de ellas es el rea computacional, donde, debido a su alto
grado de especializacin, fue necesario crear una nueva rama: la auditora com-
putacional.
En un esquema de organizacin centralizada, la auditora computacional con-
trola toda la gestin del centro de computacin, incluyendo la parte administra-
tiva de los sistemas de informacin que de all se generan y ms en particular, se
encarga del control sobre la proteccin de informacin.
En un esquema de organizacin descentralizada, adicionalmente la auditora
computacional apunta a realizar controles sobre cada rea computacional de
los departamentos usuarios, en especial, asegurando y capacitando en el uso
de la normativa interna.
A propsito, las principales reas usuarias debieran tener la libertad de des-
arrollar en forma interna o externa, respetando la normalizacin y uniformidad
que se haya dado la organizacin y lo ms importante, ocupando su propio
presupuesto.
Adems del logro de la normalizacin, una administracin eficiente tambin
significa resolver el problema de la adaptacin al cambio. Esto implica dejar
espacios para la innovacin y para probar otros esquemas, sin que resulte
crtico para la instalacin. Es ms, todos los interesados de la empresa deber-
an aprender y beneficiarse con las pruebas, lo cual se podra conseguir con
una apropiada difusin de los resultados. En esos espacios de libertad la
auditora computacional tendr que ser muy flexible para no ahogar la creati-
vidad.
Para cumplir con su labor contralora, el auditor computacional debe ubicarse
fuera del departamento de sistemas, normalmente en un departamento de audi-
tora computacional, a cuya jefatura debe hacer llegar los informes de sus audi-
toras, generados en forma independiente de cualquier otro emitido por el rea
de computacin.
Generalmente el departamento de auditora computacional es parte de contra-
lora o auditora interna, rea que su vez depende directamente del directorio
de la compaa.
En general, las reas de control de la organizacin debieran ser pequeas, por-
que el nfasis debiera ser puesto en el desarrollo de las personas, en autonom-
a, colaboracin y relaciones basadas en confianza.
160 JUAN BRAVO C.
La necesidad de la auditora computacional es particularmente evidente en insta-

laciones con sistemas de tiempo real, donde ha desaparecido en gran parte el
respaldo manual de los movimientos. Esto es particularmente crtico cuando la
mayor parte de las operaciones son transacciones de carcter legal que generan
movimientos de dinero, como es el caso de las instituciones financieras.
Los sistemas de tiempo real provocan dificultades insalvables para la auditora
tradicional en el seguimiento de las operaciones. Debido a esto, el centro de
computacin debe asumir su propio control interno, inconsistencia evidente
desde donde surge la necesidad de entrenar a los auditores en materias computa-
cionales y crear departamentos de auditora computacional, los cuales agrupan a
un conjunto de profesionales de tipo multidisciplinario, porque deben ser espe-
cialistas en computacin y en auditora interna.
Pero tambin la auditora ha salido beneficiada con el advenimiento de la com-
putacin. Hoy, con mltiples programas de apoyo, se pueden efectuar minucio-
sas revisiones, como la tarea de verificar la totalidad de la informacin disponi-
ble en el computador respecto de un problema, la cual sera prcticamente im-
posible de realizar manualmente.
Como ya fue indicado, las posibilidades de la auditora computacional son muy
amplias y los controles alcanzan, entre otros, a los siguientes aspectos:
Organizacin del departamento de sistemas.
Contratacin de personas y evaluacin de funciones, principalmente en lo
que se refiere a funciones incompatibles; por ejemplo: en ciertas organiza-
ciones y para determinados tipos de sistemas un operador no debera ser
programador al mismo tiempo.
Administracin de los profesionales de informtica.
Evaluacin de necesidades y seleccin de equipos.
Formacin de grupos de trabajo, como el comit de informtica.
Plan general de informtica.
Plan de recuperacin de desastres.
Seguridad de las instalaciones.
Proteccin de la informacin.
Mtodo de desarrollo de sistemas y controles incorporados.
Entrega de los productos pactados en cada etapa del desarrollo
Implementacin de sistemas.
Instalaciones fsicas.
Presupuesto de proteccin.
Presupuesto del departamento de sistemas.
Lugar de funcionamiento del departamento de sistemas.

Rendimiento (evaluacin costo/beneficio) del departamento de sistemas y
de sus profesionales.
Plan de perfeccionamiento.
Cumplimiento de las normas acordadas.
Tales controles se aplican de acuerdo a estndares, mediciones y estimaciones
internas, como la cuantificacin de riesgos para determinar el costo de cada po-
sible amenaza. Por ejemplo, si todo lo expuesto en los captulos de este libro
fuera aceptado como la metodologa de trabajo para un departamento de siste-
mas, entonces, una de las labores de la auditora computacional sera aplicar
controles para verificar el correcto cumplimiento de las normas aqu definidas.
Tal como en las auditoras de las normas ISO o CMM, donde se evala el cum-
plimiento de lo que est detallado en los respectivos procedimientos.
Puede parecer burocrtico mantener normas para todo tipo de aspectos que
tienen que ver con el desarrollo y la operacin de sistemas. Es aparente, como
lo demuestran los siguientes argumentos:
Tanto Japn como Alemania mantienen tpicamente esquemas muy nor-
malizados en sus instalaciones y... son los pases ms estudiados a nivel
mundial por su habilidad en la creacin de riqueza.
Esta documentacin y normalizacin sobre la forma de hacer las cosas se
est transformando cada vez ms en una exigencia. Las empresas que de-
sean optar a la certificacin en las normas ISO 9000 o CMM deben some-
terse a normas ms rigurosas que las que hemos visto aqu.
En el mbito de la calidad total, la cual es cada vez ms importante dentro
de la estrategia competitiva, es absolutamente exigible esta normalizacin.
Es deseable que el rol del auditor sea de tipo creativo ms que punitivo, ayudan-
do a dar ms riqueza al mtodo. En este sentido, puede cooperar realizando una
labor educativa de los colaboradores y de mejora continua de las normas.
Una opcin es que en todo grupo de desarrollo participe un auditor computacio-
nal, aunque manteniendo su independencia para conocer la aplicacin y avanzar
con la verificacin de controles al mismo tiempo que se desarrolla el sistema.
De esta manera, sus observaciones podrn ser consideradas para su incorpora-
cin a nivel del diseo de la aplicacin. Cuando las sugerencias se realizan so-
bre un sistema en explotacin, el incorporarlas tiene un costo mucho mayor.
162 JUAN BRAVO C.
3. Contribucin del diseo a la proteccin de la informacin

Con el advenimiento masivo de la computacin y el notable aumento del nme-
ro de terminales y PCs en poder de usuarios, la labor de proteccin se ha veni-
do haciendo progresivamente ms importante.
Hoy es indispensable incorporar las condiciones de seguridad que exige el
medio. Comencemos por conocer los siguientes trminos:
Seguridad: es un concepto amplio que abarca desde la seguridad fsica de
la instalacin hasta la proteccin de los datos contra accesos no autoriza-
dos, alteracin, hurto o destruccin de la informacin.
Privacidad: se considera un aspecto particular de la seguridad en lo que se
refiere a la proteccin de bases de datos contra accesos no autorizados, ya
sean accidentales o deliberados.
Integridad: es un concepto que se refiere a la calidad de la informacin
almacenada, la que debe ser siempre consistente y estar protegida de inva-
lidaciones accidentales o deliberadas.
Recuperacin: es el conjunto de tareas destinadas a poner nuevamente en
marcha el sistema una vez que ste se ha cado, ya sea a raz de fallas o
errores, tales como un problema elctrico o un comando equivocado.
Respaldo: se refiere a la copia de las bases de datos que se mantendr en
otro lugar para ser ocupada en caso de error o cada del sistema.
Restablecimiento: son las operaciones realizadas despus de una cada
del sistema, previo a la reanudacin del procesamiento normal (determinar
la transaccin en proceso, conocer el estado de los registros de maestros,
traer respaldos o reordenar bases de datos).
Reiniciacin: corresponde a la culminacin del restablecimiento, cuando se
pone nuevamente en marcha el sistema despus de una cada. Para reini-
ciar el procesamiento se ejecutan programas especiales o los programas
originales si tienen mecanismos de recuperacin.
Para proteger la informacin debe hacerse un estudio preciso de todos los posi-
bles riesgos, cuantificar cada uno de ellos y estimar la probabilidad de ocurren-
cia en un cierto perodo. As, se obtendr cul es el costo aproximado de cada
riesgo, lo que permitir establecer un presupuesto para el plan de proteccin.
La proteccin de informacin abarca la seguridad, integridad y recuperacin de
los sistemas, temas inseparables de la labor de diseo.
4. Seguridad de la informacin
El concepto de seguridad incluye variados tpicos:
Instalaciones fsicas: control de acceso de las personas o riesgo de incen-
dios, a modo de ejemplo.
Procedimientos administrativos: fugas por errores en el diseo lgico, do-
cumentos faltantes, descuadraturas, etc.
Privacidad de la informacin: consultar o alterar informacin privada.
La seguridad de la informacin en el computador se puede perder en forma ac-
cidental o deliberada. Las causas ms comunes de destruccin accidental de la
informacin corresponden a fallas en el hardware, fenmenos externos como un
corte de energa elctrica o errores en la estructuracin de lgica. Los dos prime-
ros problemas pueden ser enfrentados con el apoyo de los proveedores y el ter-
cero con la ayuda de herramientas de productividad y mucho, mucho orden.
Respecto de los intentos de infiltracin deliberada, la principal forma de evitar-
los es mediante mecanismos de identificacin, autentificacin y de control de
acceso, como los que se describen a continuacin:
Mecanismos de identificacin y autentificacin: la idea es que cualquier
usuario que intente entrar al sistema debe identificarse y eventualmente dar
su ubicacin (por ejemplo, nmero del terminal). Slo entonces se procede a
autentificar su identificacin, lo cual significa demostrar que el usuario es
quien dice ser. Para esta identificacin existen, por ejemplo, mquinas lecto-
ras de tarjetas preimpresas que ayudan a resolver el problema. El proceso de
autentificacin puede ser usado en el otro sentido: para que el usuario se
asegure de estar conversando con su computador y no con otro infiltrado.
Estos mecanismos permiten resolver situaciones como la de aquel banco
donde la cajera pidi autorizacin al ejecutivo de cuentas corrientes para el
pago de un cheque de alto valor. La primera vez qued en espera y al se-
gundo intento el ejecutivo dijo s a un cheque robado y con orden de no pa-
go. La investigacin subsiguiente demostr que la autorizacin no la dio l,
sino otro funcionario infiltrado en el sistema, quien conoca la clave del
ejecutivo.
Mecanismos de control de acceso a la informacin: en este caso los dere-
chos de los usuarios deben quedar explcitamente establecidos, toda vez
que existan datos reservados. Los mecanismos de mayor uso son:
164 JUAN BRAVO C.
Matriz de control de acceso: usuario vs. conjuntos de datos, donde

cada elemento especifica el nivel de acceso (lectura, grabacin o mo-
dificacin).
Cerrojos: cada conjunto de datos posee una clave de acceso.
Criptografa: consiste en una serie de operaciones reversibles que
cambian el contenido de un registro, como la sustitucin, donde se
reemplazan los caracteres por otros; y la transposicin, donde se alte-
ra el orden de los caracteres.
Lo ideal para la seguridad de un sistema es que sus mecanismos estn bajo la
supervisin de un monitor que registre todas las posibles violaciones.
Hoy, la mayora de los sistemas administradores de bases de datos traen in-
corporados estos y otros mecanismos.
5. Integridad de la informacin
El problema de integridad es asegurarse que los datos de las tablas en el com-
putador sean exactos en todo momento, es decir, protegerlos contra invalida-
ciones accidentales o deliberadas.
Para hacer ms comprensible esta descripcin, es necesario definir los trminos
fallas, errores y cadas del sistema.
Fallas: se presentan por un mal funcionamiento en el hardware o en el
software o por una mala operacin de las personas. Una falla podra gene-
rar errores.
Errores: son registros de datos o partes de programas, almacenados o
transmitidos en forma incorrecta.
Tambin es un error la prdida de informacin.
Cada del sistema: es una detencin inesperada de la normal operacin del
sistema o la ejecucin de operaciones incorrectas en el computador. Tanto
una falla como un error podran provocar esta cada.
Algunas medidas que se podran tomar para asegurar la integridad de los datos
en las bases de datos son:
Prevenir el ingreso de errores a travs de exhaustivas validaciones; por
ejemplo, de rango de valores, tipo de datos, dgito verificador y compara-
cin entre campos.
Verificaciones de consistencia a travs de revalidar la informacin en
maestros.
Verificacin de claves.
Verificacin de reiniciacin.
El conjunto de medidas de prevencin de integridad tiene que establecerse a
nivel del diseo y de acuerdo con la naturaleza de los datos a proteger, sin olvi-
dar que este tema es inseparable de los conceptos de seguridad, recuperacin y
de las facilidades de las herramientas de apoyo.
6. Recuperacin de la informacin
La recuperacin de la informacin est muy influida por el diseo del sistema.
Podra existir recuperacin automtica en cada funcin computacional, aunque
esta posibilidad se encuentra directamente relacionada con el sistema de res-
paldos utilizado.
La alternativa ms habitual de recuperacin de informacin es la reconstruc-
cin total, la que se utiliza cuando las tablas maestras deben ser totalmente
reconstruidas. Esta forma de reconstruccin opera trayendo el respaldo de las
bases de datos ms recientes y actualizando sobre ellas los movimientos no
incorporados a la fecha.
Para realizar la reconstruccin, el sistema de respaldos consiste en copiar y ar-
chivar fuera del equipo toda la informacin del sistema en forma peridica,
habitualmente una vez por semana y respaldar los movimientos ingresados al
sistema en forma diaria, o cada ciertas horas si la frecuencia de fallas es alta.
Desde un punto de vista prctico, es la frmula ms sencilla y simple de operar.
Es aconsejable mantener un mnimo de 3 juegos de respaldos completos (Abue-
lo-Padre-Hijo) y uno de ellos fuera de la instalacin, para prevenir riesgos de
incendio, inundacin u otros. Los respaldos de transacciones diarias debieran
mantenerse, al menos, desde la misma fecha del respaldo completo ms antiguo.
La reconstruccin total es vlida no slo para sistemas batch, sino tambin para
sistemas en lnea, donde se debera tener preparado un programa actualizador,
tipo batch, para incorporar a los maestros las transacciones realizadas desde la
fecha del ltimo respaldo.
Algunas tcnicas de respaldo ms sofisticadas llegan hasta mantener duplicados
del computador original, todos ejecutando en paralelo los mismos procesos. En
otros casos, se trata de asegurar el respaldo con una revisin diaria automtica,
previa al funcionamiento normal.
Todo esto sin contar las facilidades que hoy proveen los sistemas administra-
dores de bases de datos y la externalizacin del servicio.
166 JUAN BRAVO C.
2.7. DISEO DE INTERFACES
Actualmente, la mayor parte del esfuerzo de desarrollo se concentra en la in-

terfaz humana de la solucin de software. Se refiere a definir interfaces intui-
tivas con conos, ayudas en lnea, colores o ventanas. Es fundamental, porque
es lo que ve el usuario y de nada servir un excelente modelamiento funcional
y de datos si el modelamiento falla en el diseo de la interfaz.
Debe ser una placentera experiencia de navegacin.
Es lo que plantean Cerda y Guzmn (2004, p. 1): Si bien la Ingeniera de
Software ha mejorado la calidad y confiabilidad del software, existe un rea
que ha sido descuidada hasta el momento: el diseo y construccin de la in-
terfaz del usuario. Gran cantidad del esfuerzo en el desarrollo del software
est invertido en el diseo, en la construccin de la base de datos y en el cdi-
go necesario para manipularla, adems de las comunicaciones necesarias para
que estos datos se puedan accesar. Sin embargo, lo nico que ve el usuario
final es la interfaz. Si sta es difcil de utilizar, no importar toda la calidad
que posea el resto del software, el usuario se frustrar y se sentir incmodo
cuando tenga que interactuar con el programa. A pesar de esto, se dedica poco
esfuerzo a crear un diseo de calidad de dicha interfaz que tome en cuenta las
caractersticas particulares tanto del usuario como del entorno en que se utili-
zar el software.
Veremos:
1. Directrices para el diseo de interfaces humanas
2. Diseo de niveles de mens
3. Leyes para lograr una mejor interfaz humana
1. Directrices para el diseo de interfaces humanas

Hemos visto que las mejores experiencias de diseo de interfaces sigue ms o
menos estas directrices:
Disear los formatos de pantallas, informes y mens: es de importante
ayuda trabajar con un prototipo de las interfaces visuales, el cual podra ser
desarrollado en paralelo con las fases anteriores de la orientacin a objetos.
Preparar el esquema de pantallas segn normas: como las del ambiente
windows de MICROSOFT u otro. De esta manera, todos los participantes co-
nocern el mismo entorno y la organizacin habr dado un paso ms hacia
la normalizacin externa.
Disear las interfaces segn el tipo de usuario: empleados o ejecutivos,

principiantes o expertos, baja o alta especializacin. La idea es simple
asegura Gerardo Cerda (2002, p. 2): El usuario quiere utilizar un software
que sea lo ms simple posible. No le interesa entender el por qu del fun-
cionamiento si no solamente cmo lo debe utilizar para sacarle provecho.
Sin embargo, si el diseo de la interfaz no es el adecuado se estar obligan-
do al usuario a aprender a utilizar complejos instrumentos para sacar pro-
vecho al software (imagnese que se obligara a los pasajeros de un vuelo a
tener conocimientos aeronuticos para poder abordar un avin).
Disear la jerarqua de opciones: significa realizar el ordenamiento de
opciones segn la normalizacin; por ejemplo: incorporar primero las op-
ciones de uso ms frecuente ordenadas segn la secuencia de ejecucin de
tareas, agruparlas de 3 en 3 y con una profundidad de no ms de tres nive-
les en la jerarqua de opciones.
Ayudas en lnea eficientes: de tal forma que, ojal, no sea necesaria la
existencia de los manuales.
Estamos a fines de la primera dcada del 2000, en un ambiente donde la
tecnologa computacional est ya totalmente consolidada, ser necesario
mantener todava los manuales? Usted realmente los usa? Estn actuali-
zados? A estas alturas sera preferible que los usuarios aprendieran a nave-
gar dentro de buenas ayudas en lnea52.
Ordenamiento de procesos: corresponde a la definicin previa de secuen-
cias de procesos, generalmente agrupados bajo una opcin de men.
2. Diseo de niveles de mens

La definicin de diferentes niveles de mens es un importante componente de
la interfaz humana. Una primera aproximacin podra ser considerar cada
men como una clase que representa a todo el diseo, tal como se aprecia en
la figura 2-10. En este caso, los conjuntos de datos seran accesos a los dife-
rentes objetos y las funciones generalizadas permitiran acceder a las consul-
tas, informes y diferentes procesos del sistema.
52
Si todava hubiera usuarios con temor a usar el computador, un amigo Rolf Achterberg,
Gerente de sistemas, les pide jugar al buscaminas para aprender a posicionar el mouse en
un punto y luego al solitario, para aprender a tomar, mover y soltar. Ambos juegos vienen
incluidos en el sistema operativo Windows.
168 JUAN BRAVO C.
Men
Conjuntos
de datos
Funciones
generalizadas
Figura 2-10. Definicin de mens como una clase
Cada clase tendra tambin objetos mens, denominados agentes, los cual
aportaran inteligencia, por ejemplo, para presentar una ruta de acceso ex-
pedita cuando hay un requerimiento frecuente.
Una promesa que puede ayudar ms adelante sern las pantallas con visin
tridimensional, lpices con microprocesador que reemplazaran al teclado, uso
masivo de la voz e interfaces inteligentes que pueden anticiparse a algunos
requerimientos del usuario, tal como avisar las actividades del da. Todo esto
incrementar la tendencia hacia el perfeccionamiento de la interfaz humana.
3. Leyes para lograr una mejor interfaz humana

Este punto es un extracto del artculo ya citado de Cerda y Guzmn (2004, pp.
3-9). Para darle nfasis, los autores presentan sus recomendaciones en la for-
ma de leyes.
Ley 1: Mantener sencillo lo sencillo: la idea es que lo que es fcil de usar
lo siga siendo y no se complique de manera artificial.
Ley 2: Retroalimentar convenientemente a los usuarios: se debe partir del
supuesto que los usuarios se equivocarn (an los ms expertos). Por este
motivo los mensajes del software deben ser lo ms claros posibles (evitan-
do la costumbre de poner la palabra ERROR).
Ley 3: Mantener un estilo definido: cuando un software ha sido hecho por
distintas personas el usuario se da fcilmente cuenta. Para la misma situa-
cin aparecen mensajes diferentes o a la inversa, para situaciones distintas
se utiliza el mismo mensaje. En este sentido resulta muy importante man-
tener un estilo grfico consistente.
Ley 4: El mnimo esfuerzo: el usuario de la interfaz solo debe digitar el
mnimo indispensable. A modo de ejemplo, la fecha del registro debe ser
propuesta por el software y el usuario solo la confirma. En caso de que sea
necesario la cambia por otra digitndola. La opcin de impresin debiera

tener en forma predefinida el papel y la calidad de impresin que se utili-
zan ms frecuentemente.
Ley 5: Unificacin de mensajes y textos: antes de empezar a construir el
programa se debe lograr un consenso respecto a los ttulos de las ventanas,
los captions de los botones, las ayudas (hints) y como resaltar las opciones
que estn activas (por ejemplo mostrar claramente cul es la pestaa que
se est usando). Con respecto a los mensajes, botones y ttulos de las ven-
tanas, lo ideal es que se usen tecnicismos acorde con el ambiente en el cual
se va a insertar el sistema, en lo posible trminos relacionados con el rubro
de la organizacin.
Ley 6: Tener un rol de Diseador de interfaz: cuando todo el mundo es
responsable de la calidad de la interfaz en realidad nadie toma esta respon-
sabilidad. Es demasiado fcil asumir que otra persona en el equipo de desa-
rrollo solucionar cualquier dificultad de interfaz que surja. Adems es im-
portante recordar de que los programadores van a tender siempre a codifi-
car una interfaz que a ellos les sea ms cmoda o ms fcil de usar.
Ley 7: Accesibilidad, que cumpla con Todo a la vista: se refiere a que la
interfaz tenga todo lo que el usuario desee, nada ms pero tampoco nada
menos. El ideal es que se brinde toda la funcionalidad a un click de dis-
tancia. A fin de cuentas es entregarle al usuario la cantidad justa de pasos
a seguir para sacar provecho de la interfaz, generando as un mnimo por-
centaje de error y un alto porcentaje de rendimiento y satisfaccin. Ahora
bien, este trmino es ms conocido como Look and Feel, concepto orien-
tado a la programacin de los entornos grficos, tales como JAVA.
Ley 8: Personalizacin, que cumpla con No tocar: se refiere a que el
programa no cambie las modificaciones hechas por el usuario, es decir que
no toque la interfaz personalizada. Con esto se avanza un paso ms en en-
tregar lo que el usuario desea, esto es: trabajar en un entorno grato y cono-
cido. Entonces, qu mejor si es el usuario quien define como ver sus
aplicaciones? Obviamente no podr tener acceso a las partes preestableci-
das o inalterables.
Ley 9: Usabilidad, que cumpla con la Intuitividad: usabilidad es una
mezcla entre intuicin y facilidad, que permite al producto o servicio im-
pactar e influenciar directamente sobre la productividad, rentabilidad y efi-
ciencia de un negocio, on y off line, y con ello, la experiencia de usuario
en general.
170 JUAN BRAVO C.
2.8. NORMAS Y ESTNDARES APLICADOS A LOS

MODELOS TI
El objetivo de esta seccin es revisar las normas o estndares formales o de

hecho tiles al diseo de los sistemas computacionales,
Veremos propuestas de la OMG tales como Corba, APIs y MDA. Ms que
nada para presentarlas y apreciar estudios que es necesario realizar.
Revisaremos tambin algunas normas de calidad desde las cuales aprender
buenas prcticas. Se revisarn brevemente las normas CMM, ISO 9000 y Tick
IT (como ejemplo, muchas compaas de xito en la India53 se han adherido a
una o ms de estas normas).
Un aspecto comn a las normas y estndares es el costo: del aprendizaje, de la
certificacin a veces, de la infraestructura, de la implementacin y muchos
otros. Tambin es comn el beneficio:
Que el proyecto se site dentro de los plazos y costos previstos
Que el desarrollo sea de calidad
Que se pueda rastrear
Que se pueda hacer una auditora de su cumplimiento
Que el desarrollo sea eficiente y eficaz
Agregamos tambin referencias respecto al PMI por la difusin que han tenido
sus prcticas.
Veremos:
1. Corba
2. MDA
3. CMM
4. ISO 9000
5. Tick IT
6. ITIL
7. SOA
53
En OECD (2000, p. 140) se aprecia el impacto de tecnologas como CMM en la India, donde
hasta 1998 se haban certificado 89 de las 250 compaas top en la produccin de software ,
otras 136 estaban en proceso de certificarse y slo 25 compaas, el 10%, no tena planes al
respecto. Luego (ibid, p. 139) se precisa que la certificacin es segn normas reconocidas inter-
nacionalmente, tales como: CMM del SEI, ISO 9000 y/o Tick IT.
1. Corba
CORBA (Common Object Request Broker Architecture, en espaol, arquitec-
tura comn de intermediarios en requerimientos a objetos), es un estndar
basado en la orientacin a objetos el cual crea una base para el desarrollo de
sistemas distribuidos de acuerdo con el esquema de componentes remotos a
los cuales se accede mediante mensajes.
CORBA empaqueta la aplicacin en un componente que conoce las funcio-
nes que puede utilizar y cmo se accede a ellas, permitiendo su uso mediante
el protocolo de comunicacin.
CORBA es otro producto del Object Management Group (OMG)54. Se esta-
blecen las APIs55 y las comunicaciones que permitan interactuar a varias apli-
caciones (consideradas como componentes, los cuales pueden haber sido
construidos en plataformas distintas). Tambin permite agregar funcionalidad
para seguridad, bitcora de uso y otras.
2. MDA
MDA (Model-Driven Architecture, en espaol, arquitectura guiada por mode-
los) es una propuesta de la OMG que proporciona un conjunto de guas para
crear especificaciones en la forma de modelos. En la misma lnea del mode-
lamiento visual del software (UML, lo veremos en el captulo 6).
La idea con MDA es que los modelos que representan la funcionalidad del
sistema sean independientes de la plataforma en que se implementar.
Luego, se definen nuevos modelos que se acercan cada vez ms a la imple-
mentacin en la plataforma correspondiente. El aporte del concepto MDA es
que el traspaso entre modelos conceptuales y fsicos se pueda llevar a cabo
utilizando herramientas automatizadas, siguiendo a su vez otros estndares de
la OMG.
54
OMG, en espaol es el grupo de administracin de objetos, comentaremos acerca de esta
organizacin en el captulo 5 (orientacin a objetos).
55
API (del ingls Application Programming Interface, en espaol, Interfaz de Programacin
de Aplicaciones) se refiere a las clases de una biblioteca (funciones y procedimientos) segn
el concepto de orientacin a objetos que veremos en el captulo 5.
172 JUAN BRAVO C.
3. CMM
CMM (Capabilitiy Maturity Model), traducido como Modelo de Madurez de
Capacidades, es la norma preferida en el desarrollo de software. Tiene nive-
les cada vez ms exigentes que la organizacin candidata debe ir certificando.
CMM provee un detalle exhaustivo de cada nivel de madurez y no es difcil
de interpretar. Incorpora todo un sistema de mediciones a la madurez de la
organizacin respecto de las capacidades del desarrollo de software, lo cual
facilita los procesos de evaluacin.
Los niveles de madurez que seala CMM son cinco:
1. Nivel Inicial (Initial): por omisin todas las empresas estn en esta categor-
a. Aqu se describe la pseudoanarqua presente en el desarrollo. El proceso
de desarrollo es prcticamente inexistente. Se trabaja apagando incendios
con esfuerzos heroicos. Existe inmadurez en el desarrollo. No existe visibi-
lidad acerca del proceso de desarrollo ni de los resultados del producto de
software (tiempos, costos o errores).
2. Nivel Repetible (Repeatable): en este nivel el proceso se puede repetir,
existen tcnicas y normas comunes, hay seguimiento de costos, plazos y
funcionalidad en los procesos.
3. Nivel Definido (Defined): el proceso de desarrollo de software est docu-
mentado, estandarizado e integrado.
4. Nivel Gestionado (Managed): los procesos estn bajo un nivel de control
donde la prediccin de plazos y costos es posible.
5. Nivel de optimizacin (Optimizing): se incorpora el mejoramiento continuo
de los procesos.
CMM surgi en 1993 de una iniciativa del Software Engineering Institute
(SEI)56, con toda una historia anterior que incluy estudiar una amplia canti-
dad de compaas de xito en el desarrollo de software.
56
El Software Engineering Institute (SEI) es un Centro de investigacin y desarrollo
financiado con fondos federales patrocinado por el Departamento de Defensa de Esta-
dos Unidos, por intermedio de la Oficina del Subsecretario de Defensa para la Adquisi-
cin, Tecnologa y Logstica. El contrato del SEI para la investigacin aplicada en el
tema de la metodologa de software, fue adjudicado por licitacin pblica a la Universi-
dad Carnegie Mellon en Diciembre de 1984. La misin del SEI es: Promover y avanzar
en la prctica de la Ingeniera de Software, porque el software de calidad, producido
conforme a plazos y dentro de un presupuesto, es un componente crtico para los siste-
mas de defensa de Estados Unidos. Cumple esta misin promoviendo la evolucin de la
4. ISO 9000
ISO corresponde a la Organizacin Internacional de Estandarizacin. La serie
de normas ISO 9000 son bastante conocidas. Destaca que el sector informti-
co fue uno de los ms reacios en adherirse a ellas.
Un punto de encuentro se est produciendo con la masiva incorporacin de la
gestin de procesos al desarrollo de software. Esta es una ventaja de la aplica-
cin de las normas, su amplitud.
Incluso la gestin de procesos fue considerada en la nueva redaccin de nor-
mas ISO, en las denominadas normas ISO 9001:2000. De hecho, la principal
diferencia con las normas de la versin 1994 es la introduccin del concepto
de gestin por procesos interrelacionados. En estas nuevas normas la gestin
de calidad tiene un enfoque ms integral y sistmico y se incorpora la mejora
continua. Dice la nueva Norma ISO 9001:2000 (p. vi): Para que una organi-
zacin funcione de manera eficaz, tiene que identificar y gestionar numerosas
actividades relacionadas entre s Frecuentemente el resultado de un proceso
constituye directamente el elemento de entrada del siguiente proceso La
aplicacin de un sistema de procesos dentro de la organizacin, junto con la
identificacin e interacciones de estos procesos, as como su gestin, puede
denominarse como enfoque basado en procesos.
5. Tick IT
Surgi en Gran Bretaa por las carencias que se detectaron en las normas ISO
9000 orientadas a la industria del software, tales como difcil interpretacin y
aplicacin, inexistencia de aspectos crticos del desarrollo y de implementar
en la forma de un proceso evolutivo. El encargado de realizar los estudios y
patrocinar la nueva norma fue el Departamento de Industria y Comercio (DTI:
Departament of Trade and Industry). Actualmente el encargado de Tick IT es
el DISC, oficina dependiente del British Standards Institution (BSI) Standards
Division.
Tpicamente, un sistema de calidad Tick IT sigue pautas como las enumeradas
a continuacin (las cuales seran sujetos de revisin en una auditora):
1. Elaboracin de propuestas y revisin de contratos asegurando que todos
los requerimientos estn bien especificados y que la organizacin tiene la
capacidad para cumplirlos.
Ingeniera de Software desde ser una actividad ad-hoc de alto contenido de trabajo
de personas hacia ser una disciplina bien gestionada y apoyada por tecnologa.
174 JUAN BRAVO C.
2. Anlisis y especificacin de los requerimientos del sistema asegurando

que sean revisados y acordados con el cliente.
3. Planeacin, control y monitoreo del avance del desarrollo respecto al plan
comunicando a todas las partes afectadas y que avise oportunamente de
problemas potenciales.
4. Planeacin de la calidad del proyecto, especificando las inspecciones,
revisiones y pruebas requeridas durante el desarrollo.
5. Establecer polticas y objetivos de calidad generales de la organizacin
que sirvan para alinearla en todas sus actividades, procedimientos y pol-
ticas especficas.
6. Implantar y mantener un sistema de aseguramiento de calidad.
6. ITIL
ITIL (Information Technology Infrastructure Library) se traduce como Bi-
blioteca de Infraestructura de Tecnologas de Informacin. Una traduccin no
literal es Cumplimiento de niveles de servicios en TI con base en una serie de
libros (unos 60 a fines de los ochenta) con las mejores prcticas.
Todo surge de los bajos estndares de servicios TI en el Reino Unido (simila-
res a los de otras latitudes), principalmente los que se refieren a los servicios a
usuarios durante la etapa de operacin (ms del 80% del total). As es que se
encarg al CCTA (Central Comunications and Telecom Agency) una propues-
ta. La respuesta fue ITIL, la cual poco a poco ha ido ganando terreno como
referente en el campo de los servicios TI.
El objetivo es la mejora en la atencin de los clientes y usuarios y la reduccin
de costos y riesgos.
ITIL documenta buenas prcticas para lo que denomina los 6 componentes del
Soporte del Servicio:
Gestin de Configuracin
Mesa de Servicios
Gestin de Incidencias
Gestin de Problemas
Gestin de Cambios
Gestin de Difusin
Tiene cierto parecido con CMM en los niveles de madurez respecto a la cali-
dad de los servicios TI: existencia de pre-requisitos mnimos, intento de ges-
tin, capacidad de proceso, integracin interna, productos, control de calidad,
informacin de gestin, integracin interna e interfaz.
Son propuestas de amplio sentido comn, tal como la de administrar una base
de datos de elementos de configuracin: software, hardware y documentacin,
incluyendo su estado y relaciones, base a su vez del anlisis de incidencias y
problemas.
7. SOA
SOA (Service Oriented Architecture, en espaol, arquitectura orientada a los
servicios) es ms un concepto que una herramienta porque su objetivo princi-
pal es aprovechar las funcionalidades de aplicaciones computacionales anti-
guas sin necesidad de intervenirlas. Se logra empaquetndolas y relacionn-
dose con ellas en trminos de entradas y salidas, tal como en la orientacin a
objetos.
Es una mirada amplia desde los procesos de negocios que facilitan esas apli-
caciones. Al conocer y dejar disponibles los servicios que otorgan, es posible
aprovecharlos en el diseo de nuevos procesos de negocios, principalmente en
el mundo virtual (webservices).
Est de lleno en dos aspectos esenciales de los nuevos modelos: la integracin
y la modularidad en la forma de componentes.
La aplicacin de SOA permite recuperar para su uso global sistemas creados
con cualquier lenguaje y tecnologa, en cualquier lugar. Quedan disponibles
para ser usados por otras sistemas o por los usuarios de la misma forma que
los servicios de una clase (lo veremos en el captulo 5, orientacin a objetos).
Adems, se facilita el intercambio de informacin y se hace ms factible la
externalizacin.
Al evitar construir de nuevo los servicios, se economiza tiempo y dinero. So-
bre todo, se reducen errores al evitar reinventar innecesariamente la rueda.
Al igual que la orientacin a objetos, es posible aplicar SOA mediante cual-
quier tecnologa basada en servicios. Tambin se enfatiza la reusabilidad y
que los equipos de trabajo se mentalicen en esta lnea de compartir.
Por supuesto, requiere las mismas formalidades que el desarrollo tradicional
en cuanto a planificacin, calidad y uso de mtodo.
176 JUAN BRAVO C.
CAPTULO 3.
TEORA DE MODELOS
APLICADA
Captulo 3. Teora de modelos aplicada
Sin importar el tipo de empresa, el analista trabaja en problemas

comerciales. Sera un error distinguir entre problemas del nego-
cio en s y de sistemas; o dicho de otra forma, no existen proble-
mas de sistemas que no hayan sido primero del negocio.
Senn (1987, p. 56)
La nueva teora de modelos aporta avances vitales que deben ser conocidos
para enriquecer la creacin de modelos de una solucin de software.
Esta es la tercera competencia considerada para apoyar la elaboracin de
gura (en la introduccin se incluy la visin global de las competencias). En
este caso, el analista debe conocer acerca de la teora de modelos como una
simple responsabilidad profesional que deriva de su misin de modelador de
una realidad deseada.
CAPTULO 6. UML
Los aportes de visin sistmica y de la gestin de procesos, en particular el

criterio del curso normal de los eventos, son claves en esta misin.
Veremos:
Marco terico de los modelos
Modos de procesamiento
Once claves de los modelos computacionales
Modelamiento de funciones
Fundamentos del modelamiento de funciones
Criterio curso normal de los eventos
178 JUAN BRAVO C.
3.1. MARCO TERICO DE LOS MODELOS
Se presenta este breve anlisis sobre teora de los modelos, utilizando dos
conceptos tomados de la teora de sistemas: caja negra y homomorfismo. Con
ellos se pretende obtener un mnimo de base conceptual para el desarrollador.
Veremos:
1. Concepto de caja negra
2. Concepto de homomorfismo
1. Concepto de caja negra

Corresponde a una forma de estudiar sistemas con elementos e interacciones
muy difciles de conocer y con un comportamiento solamente predecible en
trminos probabilistas.
La forma de abordar estos sistemas es observando sus entradas y salidas, para
determinar qu estmulos en las variables de entrada producen cambios en las
variables de salida, tal como se muestra en la figura 3-1. As se puede cons-
truir un modelo del sistema que entregue respuestas lo ms aproximadas a la
realidad. Por ejemplo, no conocemos el comportamiento de la economa, pero
hemos observado que un aumento en la tasa de inters produce menor activi-
dad en la economa o que un tipo de cambio alto incentiva las exportaciones.
Con stos y otros antecedentes podramos formar un modelo matemtico que
nos ayude en la toma de decisiones con estimaciones probabilistas sobre los
efectos de decisiones importantes.
Variables Caja Variables

de entrada Negra de salida
Figura 3-1. Concepto de caja negra
Tambin un sistema de informacin puede abordarse segn el concepto de

caja negra. Comenzando por el entorno, entradas y salidas, se avanza hacia
conocer la informacin que utiliza, hasta identificar los procedimientos y re-
glas de negocio.
2. Concepto de homomorfismo
Un homomorfismo es una representacin simplificada del objeto real. Un mo-
delo de sistemas es una de las visiones que tienen diferentes personas respecto
a un mismo objeto. Tambin corresponde a los diferentes puntos de vista
con que una persona intenta reconocer ese objeto; por ejemplo, cmo se pue-
de superar la complejidad para estudiar un automvil? Un mal mtodo sera
intentar reconocerlo todo de una vez, porque los diferentes componentes difi-
cultaran una correcta apreciacin, entonces, lo mejor es enfrentar el estudio
construyendo diferentes modelos; por ejemplo, sobre:
La apariencia externa, tal vez una fotografa?
La carrocera.
El sistema elctrico.
El sistema de frenos.
Por supuesto, deberamos preguntarnos acerca de la finalidad que perseguimos
con este estudio. Tal vez sea realizar un estudio sobre las caractersticas aero-
dinmicas del automvil, por lo tanto, los modelos que se construyan deben
ayudar a ese objetivo, por ejemplo, diagramas detallados sobre:
La carrocera, desde diversos ngulos.
El impacto del roce a diferentes velocidades.
En resumen, los modelos deben construirse de acuerdo con los fines que per-
sigue el diseador. En los sistemas de informacin, los modelos se construyen
para comprender la realidad y efectuar un diseo correcto. Por ejemplo, las
siguientes cuatro perspectivas de un sistema de inventarios.
Primera, segn el objetivo principal: por ejemplo, el control del stock, tal
como se aprecia en la figura 3-2. Las transacciones actan sobre actualizar el
stock de los productos en el inventario. Este modelo obliga a plantearse cul
es el objetivo vital del sistema. Incluso, podra construirse rpidamente un
prototipo para observar la operacin del sistema en funcin del cumplimiento
de ese objetivo.
Compras Ventas
Devoluciones Entradas Control Salidas Devoluciones
Traspasos
del stock Traspasos
Figura 3-2. Modelo orientado al objetivo principal del sistema

180 JUAN BRAVO C.
Segunda, segn el modelo de datos: se modelan los conjuntos de datos del

sistema y las relaciones entre ellos, tal como se observa en la figura 3-3. Un
proveedor puede tener varias compras y una compra slo puede tener un pro-
veedor, de ah el sentido de las flechas. Una compra puede incluir varios art-
culos y un artculo puede estar presente en varias compras. A su vez, un pro-
veedor puede suministrar varios artculos y un artculo puede ser suministrado
por varios proveedores. Un cliente puede tener varias ventas y una venta slo
puede tener un cliente. Una venta puede incluir varios artculos y un artculo
puede estar presente en varias ventas.
Proveedores
Compras Clientes
Artculos Ventas
Figura 3-3. Modelo orientado a los datos
Tercera, segn la funcionalidad: se establecen, por ejemplo, las reglas del

negocio que vemos en la figura 3-4. Las funciones de ingreso y actualizacin
de compras actan sobre el stock y el costo de los productos en el inventario.
Este modelo cumple una misin parecida a la del diseo estructurado, separa
las entidades y las funciones.
Funcin
Compras Artculos
Ingreso de datos Funcin
Actualizacin de compras
Reglas
Mover ltimo costo
Sumar las unidades adquiridas al stock
Figura 3-4. Modelo orientado a las funciones del sistema

Cuarta, segn el flujo de transacciones: se muestra en este modelo que las

transacciones atraviesan (actualizan) horizontalmente los maestros, tal co-
mo vemos en la figura 3-5. Es una matriz con entidades permanentes y transi-
torias, distincin ms conocida como maestros y transacciones, respectiva-
mente. Los maestros son los pilares, por ejemplo: clientes, artculos y provee-
dores. Las transacciones fluyen, por ejemplo: ventas del da, compras y devo-
luciones de ventas.
Maestros Cuentas Historial Historial

Clientes Artculos Proveedores
Transacciones
Contables Ventas Compras
Ventas X X X X
Compras X X X X
Devolucin ventas X X X X
Figura 3-5. Modelo orientado al flujo de transacciones
Cada modelo representa una visin particular sobre el problema: objetivos,

modelo de datos, funciones y flujo de transacciones. Cada uno sirve de dife-
rente manera a los propsitos del diseador. En el fondo, la variedad de visio-
nes es tan amplia como la variedad de puntos de vista respecto a una reali-
dad57. En la figura 3-6 se muestra este concepto de infinitas visiones que se
obtiene como subproducto del concepto de homomorfismo.
Modelo de funciones Prototipo visual
Modelo de datos Objetivo del sistema
Flujo de transacciones
Figura 3-6. Infinitas visiones de una realidad
Para efectos del software, importa consensuar los modelos ms adecuados y

decidir cules sern parte del mtodo que la organizacin adopte.
57
Abriendo levemente la puerta de la filosofa, hay quienes plantean que no existe una reali-
dad objetiva, sino que hay solamente visiones subjetivas, avalando la afirmacin con estudios
sicolgicos que demuestran que la percepcin del entorno es siempre personalizada, porque
tiene que atravesar el filtro de las abstracciones personales obtenidas de nuestras experiencias
particulares.
182 JUAN BRAVO C.
3.2. MODOS DE PROCESAMIENTO
Un mismo requerimiento puede variar totalmente en su diseo dependiendo

del tiempo de respuesta solicitado. Si necesitamos la respuesta para dos das
ms, entonces el modo de procesamiento batch-interactivo sera la solucin.
Si el requerimiento se puede satisfacer dentro de 24 horas, tal vez el esquema
en lnea sea la solucin. Si la informacin se requiere procesada al mismo
tiempo que se genera el dato por ejemplo, en un punto de ventas o en una
recepcin de mercadera entonces necesitamos un sistema que la respuesta
sea en tiempo real.
Las diferencias no son gratis, porque mientras ms pronto es el tiempo de res-
puesta, ms complejo es el diseo, mayor el tiempo de implementacin y el
costo sube. Por eso hablamos de las tres dimensiones del diseo.
Las tres dimensiones del diseo son: datos, funciones y tiempo de respuesta,
tal como se aprecia en la figura 3-7. Cualquier variacin substancial de alguna
de ellas provocar un cambio de modelo.
Datos
Funciones
Tiempo de respuesta
Figura 3-7. Las tres dimensiones del diseo
En general, se entiende que si el modelo de datos sufre cambios notables o si

las funciones a realizar con ellos varan significativamente, entonces ser ne-
cesario modificar el diseo. Sin embargo, es poco conocido hablar de un cam-
bio en el modelo cuando vara el tiempo de respuesta requerido del sistema;
ese es el objetivo de esta seccin, dar a conocer esa tercera dimensin del di-
seo, la cual est directamente relacionada con el modo de procesamiento.
Veremos:
1. Batch-Interactivo
2. En lnea
3. En tiempo real
1. Batch-Interactivo
En este caso los datos se ingresan en forma diferida respecto a su generacin,
ya sea en el departamento de sistemas o en el punto de generacin del dato. La
actualizacin de la informacin es diferida respecto al ingreso.
Por punto de generacin del dato entendemos el lugar donde se origina la in-
formacin: el escritorio de la vendedora que atiende a un cliente, el rea de
despacho de una bodega, la caja de un banco, etc
En general se modela segn la siguiente secuencia de funciones:
Ingreso: se ingresan los datos de un perodo determinado a la entidad de
transaccin. Habitualmente los movimientos de un da.
Informe: se imprimen todos los datos de la entidad de transaccin. El obje-
tivo de este informe es revisar manualmente los datos del ltimo perodo de
ingreso.
Actualizacin: con las transacciones del ltimo perodo de ingreso se ac-
tualizan una o varias tablas para agregar, modificar o totalizar datos.
Inicializacin: despus que los datos del ltimo perodo de ingreso fueron
efectivamente actualizados, se elimina la tabla de transacciones del perodo
actualizado (ms bien se respalda fuera de lnea).
En este ltimo tiempo se ha producido una revalorizacin del procesamiento
batch, es como volver a la sencillez original. Podra ser un buen comienzo
para usuarios y especialistas principiantes. Adems, representa un punto de
partida fcil, rpido y seguro para el primer prototipo de una aplicacin.
A muchos usuarios se les vendi el procesamiento en tiempo real sin haber
sido una necesidad para ellos, podran haber resuelto su problema con infor-
macin diferida algunas horas e incluso das. Esto trajo como consecuencia un
nivel de complejidad y costos innecesariamente altos.
2. En lnea
Se ingresan los datos en forma diferida respecto a su generacin, ya sea en el
departamento de sistemas o en el punto de generacin del dato. La actualiza-
cin de la informacin es simultnea al ingreso.
184 JUAN BRAVO C.
Al terminarse el ingreso de una transaccin, se activan mensajes para realizar

las actualizaciones de maestros, uno de los cuales ser un registro de las tran-
sacciones del da, o del perodo de ingreso considerado.
Aqu la caracterstica principal es que se procesa transaccin a transaccin.
3. En tiempo real
Se ingresan los datos en el punto de generacin del dato y la actualizacin de
la informacin es inmediata. Este es un mtodo de procesamiento relativa-
mente nuevo y trascendental, porque implica ingresar y actualizar la informa-
cin en el momento y desde el lugar donde se genera la transaccin, por lo
tanto, es necesario cuantificar los recursos de software, hardware y de comu-
nicacin que se requieren.
Este es el esquema predilecto en Internet.
3.3. ONCE CLAVES DE LOS MODELOS

COMPUTACIONALES
Estas claves de los modelos de sistemas computacionales son orientaciones

conceptuales adicionales al mtodo que la organizacin decida. Por lo tanto,
no hay una indicacin en la forma de pasos a seguir. Asimismo, son inde-
pendientes de la implementacin, de algn hardware especfico y de las
herramientas de software que apoyan el desarrollo.
Son 11 claves orientadas a enriquecer los modelos de aplicaciones computa-
cionales. Son diferentes a las caractersticas universales del diseo de produc-
tos y servicios, como por ejemplo: abstraccin, amistosidad, flexibilidad, por-
tabilidad, impersonalidad y factibilidad. Se supone que ellas son conocidas.
Veremos:
1. Fluidez
2. Intuicin
3. Simplicidad
5. Independencia de la implementacin tecnolgica
6. Iteracin
7. Totalidad
8. Generalizacin
9. Desarrollo incremental
10. Transacciones presentes
11. Armona entre el modelo y la realidad
1. Fluidez
El modelamiento del sistema debe mantener abiertos los cauces por donde
fluyen libremente los datos de la organizacin, de la misma manera como las
aguas de un ro buscan su cauce natural.
En la organizacin, a veces el flujo de datos queda atrapado en una reglamen-
tacin obsoleta, pero la naturaleza viene en ayuda de la organizacin! Y ese
flujo se desborda y busca sus caminos naturales: cuntos manuales de proce-
dimientos reflejan la realidad?
Es fundamental que el diseador no pretenda forzar la realidad, sino que la
capture lo ms fielmente posible en pocos modelos dinmicos.
186 JUAN BRAVO C.
2. Intuicin
El modelamiento es una tarea eminentemente creativa, por lo tanto, la intui-
cin juega un rol preponderante. Esto se puede interpretar como de acuerdo
con el sentido comn o percepcin.
Qu es la intuicin? Hay quienes dicen que es una de las voces de la con-
ciencia. Es esa sensacin de incomodidad, de que algo sobra o algo falta en el
modelo, tal vez percibimos que no deberamos hacer el sistema computacio-
nal porque hay una solucin mejor y no nos atrevemos a comunicarla? podra
afectar nuestros intereses?
Es un buen momento para reiterar algo que qued esbozado en el captulo
primero: un verdadero profesional es aquel que soluciona el problema del
cliente de la mejor forma. No es quien aplica la tcnica ms moderna o usa los
productos ms sofisticados, esas son solamente herramientas que aplican los
especialistas. Un especialista puede ser un profesional en la medida que ponga
el problema del cliente por sobre su especialidad e incluso por sobre su inters
comercial.
Si un modelo cumple con todas las reglas, pero a usted algo le incomoda,
hgale caso a su intuicin! Probablemente descubrir que su percepcin era
correcta, tal vez algo cambi en la realidad o existe un problema de enfoque
que es mejor atender.
No estamos hablando de algo mstico, sino de procesos biolgicos que recin
se comienzan a estudiar cientficamente. Lo explica bien Malcolm Gladwell
en su documentado libro Inteligencia Intuitiva (2006, pp 51-52): La capaci-
dad para extraer conclusiones a partir de una pequea seleccin de datos signi-
ficativos no es un don extico. Es una parte central de lo que significa ser
humano. Lo hacemos siempre que conocemos a una persona o tenemos que
entender algo con rapidez o nos encontramos ante una situacin nueva. Lo
hacemos porque tenemos que hacerlo y llegamos a depender de esa capaci-
dad en muchas situaciones en las que prestar una atencin minuciosa a unos
pocos datos reveladores, aunque no sea ms que durante uno o dos segundos,
puede darnos muchsima informacin.
Es simple, el subconsciente es bastante ms rpido que la reflexin por una
cuestin de sobrevivencia, utiliza pocos datos relevantes (como en la teora de
los pocos crticos de Pareto) y ayuda a tomar decisiones en poco tiempo. Lo
que plantea Gladwell es que esos pocos datos relevantes son simples observa-
ciones de la realidad detectadas con mayor rapidez.
Entonces, sin ser toda la fuente para una toma de decisin consciente, la intui-
cin tiene un rol que jugar en la validacin de los modelos, sobre todo si se
trata de personas preparadas que han educado su intuicin con informacin
cada vez ms relevante.
3. Simplicidad
Habitualmente, la elegancia va de la mano con la simplicidad. Es ms, se
podra plantear la siguiente regla: si el modelo se ve complicado, hgalo otra
vez. Slo hay que darse por satisfecho cuando el modelo es y se ve fcil de
entender, lo cual puede llevar esfuerzo, pero es una excelente inversin.
Existe simplicidad en el modelo cuando lo entienden los dems, especialmen-
te el usuario y cuando se siente que es simple.
La simplicidad tambin se refleja en mantener una solucin limpia, sin parti-
cularizaciones para efectos de la implementacin tecnolgica.
Simple como un anillo, dice Pablo Neruda en su famoso Poema 15.
Desde el punto de vista de proyectos de negocios, todos en la organizacin de-
ben estar orientados al cliente (las personas que pagan nuestro sueldo, no el
cliente interno, metfora que slo agrega confusin cuando algunas personas
creen que es suficiente con realizar bien su funcin).
Tambin se le llama Visin de procesos, porque siempre existe una doble
responsabilidad, la funcin individual y asegurarse que funcione el proceso
completo del cual nuestra funcin es parte.
Cul es el cliente del rea de RRHH? El Cliente.
Cul es el cliente del rea de informtica? El Cliente.
En ambos casos y en muchos otros, es circunstancial otorgar un servicio interno,
lo ms importante es cmo ese servicio impactar en el cliente (el negocio de la
organizacin).
El usuario del sistema es un cliente interno con quien hay que negociar para
satisfacer de la mejor forma los requisitos de los clientes (finales, aunque sea
redundante).
Es tan natural la aplicacin de la orientacin al cliente porque proviene de una
de las caractersticas ms intrnsecamente humanas: el deseo de servir. Por
188 JUAN BRAVO C.
eso es que cuando no lo hacemos o pretendemos tomar en cuenta slo nuestro

inters, alguna seal nos enva la conciencia.
Esto es verdadera educacin.
5. Independencia de la implementacin tecnolgica

Significa que los modelos de la aplicacin deben poder implementarse con
diferentes lenguajes y en diferentes plataformas.
Ms precisamente, el modelamiento del sistema debe ser independiente del
hardware y del software, porque ambos aspectos son tan dinmicos que podr-
an variar desde cuando se concibe la aplicacin hasta su explotacin. Lo ni-
co que realmente debiera afectar al modelo son los cambios en la realidad o
los requerimientos.
Es equivalente a disear los edificios con independencia de los tipos de ma-
quinaria o mtodos de construccin y por supuesto, dentro de parmetros ge-
nerales de factibilidad tcnica y financiera, ms propios del entorno que de un
proyecto especfico.
Este es un giro trascendental en la forma de visualizar el modelamiento, antes
amarrado a los recursos disponibles en el momento y ahora con libertad para
modelar lo ms fielmente posible la realidad.
6. Iteracin
El modelamiento final se obtiene despus de varias iteraciones, buscando en
cada nueva versin perfeccionar la anterior.
Las iteraciones no son infinitas, porque podemos apreciar que generalmente
las primeras versiones resuelven los aspectos de mayor importancia y las si-
guientes son perfeccionamientos cada vez menores; tal como se muestra en la
figura 3-8.
Se puede realizar iteracin de varias formas, para construir prototipos, aplicar
desarrollo incremental por mdulos o desarrollo en espiral (ver anexo 3).
Figura 3-8. Esquema de aproximaciones sucesivas
7. Totalidad
El modelamiento de la aplicacin debe considerar todos los elementos, aunque
algunas partes sean incorporadas slo para conservar la visin de conjunto, sin
llegar a un nivel de detalle.
La totalidad responde a la necesidad de una visin holstica del problema. Lo
importante es captar completamente la realidad y llevarla al modelo.
Desde el punto de vista de la ingeniera de requerimientos, el uso del diagrama
de casos de uso es un buen ejemplo.
Tener a la vista la totalidad ayuda a comparar y priorizar.
8. Generalizacin
Cada problema, apropiadamente planteado, no es ms que un caso particular
de un problema general ms fcil de resolver. As se hace inversin en inteli-
gencia, porque los nuevos problemas particulares que se vislumbran ya es-
tarn resueltos.
Es un signo de inteligencia no resolver siempre los mismos problemas. Esto
significa buscar el metaproblema, aqul que representa a todos los proble-
mas del mismo tipo. Una aplicacin es el mapa de necesidades que vimos en
el captulo 1.
190 JUAN BRAVO C.
El concepto de generalizacin tiene sus races en el proceso cognitivo del ser

humano y es uno de los pilares de la orientacin a objetos. En el captulo cuar-
to se analiza en detalle.
Para aplicar generalizacin es necesario hacer uso intensivo de las tcnicas de
clasificacin. Significa ordenar los elementos con caractersticas similares;
por ejemplo, separar los vehculos de transporte terrestre entre automviles,
camionetas, buses, camiones, motos. Y las bicicletas, trenes y vehculos an-
fibios? Es una tarea que requiere mucha prolijidad y creatividad, porque es
necesario descubrir afinidades, identificar aspectos comunes e inventar clasi-
ficaciones. Por supuesto, no existe la clasificacin perfecta, pero el sentido
comn dar la pauta de hasta adonde llegar.
9. Desarrollo incremental
Consiste en dar una solucin simple, general y de la mayor relevancia respecto
al problema, es una plataforma que funciona bien. Luego, por agregacin de
mdulos se va gestando un sistema final personalizado.
Generalmente, el desarrollo incremental lo aplican empresas que poseen un
sistema base y ofrecen el incremento como una adaptacin a las necesidades
especficas del cliente.
Por supuesto, el desarrollo incremental es esencialmente iterativo.
10. Transacciones presentes

La forma ms usual de procesamiento de datos es mediante transacciones que
actualizan maestros; stos van modificando sus datos en la medida que las
transacciones los afectan.
Qu sucede cuando se descubre un error de digitacin en la factura ingresada
ayer y que ya afect a los maestros de inventarios y de cuentas contables? Una
posible y muy generalizada solucin es arreglar a mano los maestros in-
volucrados; significa intervenir directamente el resultado en el maestro; por
ejemplo, incrementar el inventario en dos unidades. Esto
tiene muy altos costos, porque, si fuera necesario reprocesar a raz de una
cada del sistema, todos los arreglos efectuados a mano no se podran repro-
ducir y los repositorios de datos quedaran inconsistentes a menos que se
lleve un registro manual de las correcciones y se vuelva a hacer el esfuerzo de
digitacin; bueno!, por eso es cara y engorrosa esa solucin; sin contar con
que se transgreden normas elementales de control y auditora.
La solucin formal y elegante es aplicar una contra-transaccin, una transac-

cin presente que revierta la anterior; en el ejemplo, la anulacin de la factura
errnea y su reingreso correcto. Ahora, qu sucede si la anulacin est inco-
rrecta? No se continua con un juego infinito de contra-transacciones, sino que
se hace una transaccin de ajuste. Esto significa definir el siguiente juego de
operaciones: transaccin original, contra-transaccin y ajuste. As, se da una
lnea continua en el tiempo y nunca se vuelve al pasado.
La aplicacin de transacciones que revierten otras es lo habitual en la realidad,
incluso, es un principio contable; por eso los documentos legales no se pueden
enmendar y cada uno tiene su opuesto. Por ejemplo, la factura versus notas de
crdito y dbito.
Es una aplicacin de una de las prcticas transversales del mtodo GSP, la
trazabilidad.
11. Armona entre el modelo y la realidad

Los modelos son representaciones de la realidad, especialmente de una reali-
dad deseada. Cuando en el modelo se le da importancia desproporcionada a
situaciones indeseadas, el efecto es que se aumenta la probabilidad de ocu-
rrencia de esas situaciones.
Es lo mismo que el criterio curso normal de los eventos que veremos en la
seccin 3.6 aplicados en los flujogramas de informacin y en los casos de uso
del lenguaje UML. Lo que queremos enfatizar aqu es que esta clave de armo-
nizar el modelo y la realidad aplica a todos los tipos de modelos de la solucin
de software.
Por ejemplo, al buscar un producto en una bodega, una situacin indeseada es
que el producto no se encuentra y esto ocurre en el 1% de los casos. Un error
de modelamiento sera incluir un rombo en cualquier tipo de modelo donde
diga Lo encontr? y luego ese rombo tenga dos salidas, S y No. Ntese que
visualmente se le estara dando una importancia equivalente a las dos salidas,
sin embargo, una ocurre en el 99% de los casos y la otra en el 1%. Adems, lo
que estamos modelando es como queremos que sea la realidad, sin esas situa-
ciones indeseadas.
El efecto psicolgico es que cuando un operador del proceso observa el rom-
bo, es como si tcitamente tuviera permiso para dejarse llevar a la situacin
indeseada. En Chile se dice: se deja la cada.
192 JUAN BRAVO C.
Como en el criterio normal de los eventos, no cerramos los ojos a los eventos
indeseados, estos son escritos y analizados en los talleres de formacin en el
proceso. Aunque no le damos el mismo espacio visual que lo deseado58.
Una experiencia del autor. En cursos a profesionales en una reconocida uni-
versidad, ocurra que al momento de la evaluacin siempre faltaba uno o dos
alumnos de un grupo de 25. As es que antes de conocer esta clave, dibuj un
diagrama de flujo, con rombos, para explicar al curso las acciones en caso que
alguien no se presentara a la evaluacin. El resultado fue que las ausencias
llegaron a un 40% al momento de la prueba. Al conocer este efecto, todo se
aclar, los alumnos interpretaron la bifurcacin de no presentarse a la eva-
luacin como una opcin vlida. Por supuesto, en los siguientes cursos se
aplic armonizar el modelo con la realidad y las ausencias para la evaluacin
volvieron al nivel anterior.
58
A propsito, el modelo que ofrece la TV es muy fuerte en este sentido. Por ejemplo, en
Chile se ha hecho costumbre fomentar el uso de lenguaje grosero en la TV. En una entrevista
a la conocida humorista chilena Gloria Benavides (2006), La cuatro, dice: Me llama la aten-
cin el lenguaje que ocupa la gente [en la TV]. Supuestamente la televisin siempre ha ense-
ado. En Estados Unidos, de hecho, estamos bajo la fuerte presin de la FCC que se preocupa
de que no digas ni siquiera una mala palabra ac hubo como un destape.
3.4. MODELAMIENTO DE FUNCIONES
Una funcin computacional da respuesta a un requerimiento de usuarios. Para

cumplir su objetivo incluye una parte pblica y otra que depende del requeri-
miento, ms conocida como regla del negocio.
La parte pblica es generalizada y la parte regla del negocio es propia de la
misin de la organizacin. Se puede hacer una comparacin entre parte pbli-
ca y regla del negocio con las partes generalizada y opcional de la compra de
un automvil, respectivamente. El automvil no se reinventa cada vez, sino
que trae una gran base predefinida: motor, carrocera, frenos, sistema elctri-
co, etc. Adicionalmente, existe la posibilidad de efectuar una personalizacin
mediante algunas elecciones: tapiz, radio, tipo de caja de cambios y colores
interiores.
La idea es tomar como un todo la necesidad del procesamiento de datos y bus-
car la funcionalidad comn que tienen la mayora de las aplicaciones: ingreso
de datos, informes, clculos, extraccin de informacin, actualizacin, selec-
cin y otras. Con esa funcionalidad comn, se plantean procesos reutilizables.
Veremos:
1. Descomposicin funcional
2. Reglas del negocio
3. Funciones asociadas a una entidad
4. Relaciones funcionales entre dos entidades
1. Descomposicin funcional
El objetivo es identificar funciones computacionales atmicas que actan so-
bre una o dos entidades. Por ejemplo, en funciones asociadas a una entidad
tenemos ingreso, informe y clculo. En dos entidades: actualizacin, seleccin
y extraccin.
La funcin computacional es la mnima unidad que se obtiene al dividir un
sistema computacional. En ese sentido es atmica. En el contexto del mode-
lamiento tradicional, es cuando ya no se obtiene beneficio al seguir fraccio-
nando; lo cual, incluso, puede llegar a ser inconveniente o absurdo. Esta situa-
cin se da, por ejemplo, al construir dos programas de ingreso de datos para la
misma entidad o al construir tres programas para hacer la actualizacin entre
ventas y artculos: uno para restar el stock, otro para calcular la valorizacin y
el tercero para acumular el total de unidades vendidas en el da.
194 JUAN BRAVO C.
Es similar a la naturaleza simple que propone Ren Descartes en su Discurso

del Mtodo (de anlisis) y a la tabla plana que surge del proceso de normaliza-
cin de datos.
Cmo se llega a determinar una funcin computacional atmica?
Aplicando el concepto de descomposicin funcional, el mismo que se usa en
programacin estructurada para identificar los mdulos del programa y ahora
orientado a partes de la aplicacin. La idea es llevar el concepto de descompo-
sicin funcional desde el mbito de un programa de computador hacia el de un
sistema.
La atomicidad depende del nivel en el cual estamos hablando: en el anlisis
pueden ser procesos del negocio, en el diseo objetos y dentro de un objeto
funciones que actan sobre los datos.
Es ms preciso entender la descomposicin funcional comparando con la for-
ma como se establecen las fronteras de los pases en la figura 3-9. En el caso
A las fronteras estn definidas considerando dominio cultural, historia, sepa-
raciones naturales (cordilleras, ros) y mucha negociacin, eso sera
te a la descomposicin funcional. En el caso B, supongamos que los pases
surgen de una divisin artificial y rpida basada en las coordenadas geogrfi-
cas (paralelos y meridianos) creando caos y confusin (cualquier similitud
la actual situacin de frica es mera coincidencia, bueno, casi).
0 20 40
Caso A: Separacin natural Caso B: Divisin artificial
Figura 3-9. Concepto de descomposicin funcional
En la figura 3-9 queda de manifiesto que cada pas es la unidad atmica del
mapa, definido siguiendo el orden natural de las cosas. Con las aplicaciones
computacionales es similar, porque la descomposicin funcional ubica final-

mente tipos de funciones sobre una entidad (lo veremos en el captulo 5
sobre orientacin a objetos).
Cada funcin atmica se puede transformar directamente en un programa de
computador, es decir:
1 Funcin atmica = 1 Programa
En cada programa, el cdigo fuente aportado por sobre la normalizacin de la

funcin probablemente sea muy poco, tal vez no mayor a 100 lneas; igual
debe cuidarse su claridad, sencillez y elegancia.
En todo caso, esto depende tambin del tamao y complejidad de la aplica-
cin. Por otra parte, la implementacin puede simplificarse con un generador
de cdigo que tome directamente los modelos de datos y funciones, para gene-
rar automticamente los programas. Ya lo veremos en el captulo 7 (Herra-
mientas TI).
2. Reglas del negocio

Cada funcin incluye reglas del negocio que actan sobre los campos de las
entidades relacionadas; por ejemplo, en una funcin de actualizacin desde
ventas a artculos se identificaron las siguientes reglas que modificaran la
entidad artculos: restar la cantidad vendida del stock y sumar unidades vendi-
das en el mes.
Para efectos de la ejecucin de las funciones, cada una puede ser simplemente
una opcin de un men o parte de una Funcin mayor, la que permite ejecutar
varias funciones en un orden predeterminado.
La idea es que sobre el modelo de datos se sobreponga el modelo de funcio-
nes, definindose ahora relaciones funcionales entre las entidades, que se ac-
tivan segn las secuencias de procesamiento, tal como se muestra en la figura
3-10, donde los recuadros indican entidades y las lneas sealan funciones.
196 JUAN BRAVO C.
1 3
Ventas Artculos Mermas
Actualizar Actualizar
stock stock
Actualizar saldo de
2 crdito del cliente
Clientes
Figura 3-10. Ejemplo de relaciones funcionales
Una relacin funcional puede corresponder a cualquier funcin entre dos enti-
dades, con la caracterstica de que una de ellas, o ambas, sean alteradas. Es el
caso de la actualizacin, extraccin o seleccin de informacin.
En la figura 3-10 se puede apreciar una secuencia de procesamiento de varias
funciones:
1.- Actualizar stock de artculos desde ventas
2.- Actualizar saldo de crdito disponible del cliente
3.- Actualizar stock de artculos desde mermas
Veremos a continuacin algunos tipos de funciones atmicas sobre una y en-
tre dos entidades.
3. Funciones asociadas a una entidad

Algunos tipos de funciones donde se trabaja con una entidad, son los siguien-
tes:
Ingreso: se realizan las operaciones de consultar, agregar, modificar y eli-
minar registros de una entidad. Si se trabaja con alguna herramienta, la pre-
sentacin de la pantalla podra ser proporcionada por omisin, aunque con
la posibilidad de que el usuario la pueda alterar o pintar de acuerdo con
su gusto.
Consulta: aqu se permite la consulta por la clave y por las relaciones pro-
pias. Tambin el formato de la pantalla debiera ser proporcionado por omi-
sin y con posibilidades de ser alterado.
Informe: se obtiene desde una entidad, indicndose: ancho del informe,

campos que se imprimen, formato de impresin, saltos de pgina, ordena-
miento, totalizaciones, encabezado de pgina y pie de pgina.
Clculo: se realizan diferentes operaciones sobre algunos campos de una
entidad para obtener, por ejemplo, valorizacin de stock o correccin mo-
netaria. Adems de las operaciones bsicas: sumar, restar, multiplicar, divi-
dir, promediar y mover valores fijos. Es deseable poder realizar operaciones
matemticas, estadsticas y financieras.
Clculo selectivo: significa realizar operaciones entre campos de diferentes
registros de una misma entidad; por ejemplo, obtener el total neto, la suma-
toria de unidades por valor, de un determinado nmero de factura en la en-
tidad detalle de factura.
Reconstruccin: es una funcin que permite reconstruir una entidad, para
regrabar los ndices y ordenar los datos.
Inicializacin: es una funcin que permite crear una entidad antes del in-
greso de datos; es lo mismo que un archivador, el cual tiene que existir para
poder guardar documentos.
Se ha utilizado con xito esta tipificacin en mltiples aplicaciones reales. No
obstante, es una lista que puede continuar extendindose.
Una entidad puede tener asociadas, desde el modelo de datos, otras entidades,
tablas e ndices que permitirn cumplir con las funciones indicadas. Tomemos
como ejemplo el ingreso de un artculo en la entidad detalle de la factura; en
este caso, al digitarse el cdigo del artculo, se aplica una condicin de exis-
tencia sobre la entidad maestro de artculos. Significa esto que hay dos
entidades en el ingreso de datos? S, a nivel fsico, de implementacin y cons-
truccin; pero no a nivel del modelamiento, que es lo que nos interesa. A este
nivel solamente hay una entidad: el detalle de la factura; el maestro de artcu-
los aparece nicamente cuando se activa la funcionalidad asociada al campo
cdigo del artculo, definida en el modelo de datos. Es una validacin relacio-
nada con ese campo especfico y no interfiere con la funcin computacional.
Las asociaciones de campos con su funcionalidad, definidas en el diccionario
de datos, servirn para validar condiciones de existencia, presentar la informa-
cin extrada desde las entidades asociadas o efectuar clculos.
Es el mismo caso en relacin a tablas, para lograr la traduccin automtica de
un cdigo a un texto; por ejemplo, el nombre de cada sucursal.
198 JUAN BRAVO C.
4. Relaciones funcionales entre dos entidades

La funcin computacional atmica se obtiene cuando participan dos entidades
(cuando hay ms, no interactan todas a la vez, sino que por turnos).
Nota: La definicin de funciones entre dos entidades tiene aqu carcter provi-
sorio, porque luego, en la orientacin a objetos, aplicando el concepto de en-
capsulamiento, veremos que realmente toda funcin acta slo sobre una enti-
dad.
Si se trata de una actualizacin donde hay una transaccin y dos maestros,
primero se actualiza un maestro y luego otro. Por lo tanto, para qu las tres
entidades? Tal vez, como se explic en el primer captulo, por criterios de
eficiencia ya obsoletos.
Veremos a continuacin algunos tipos de funciones entre dos entidades: ac-
tualizacin, extraccin, seleccin y mantencin.
Actualizacin
Una entidad de transaccin actualiza una entidad de maestro, tal como se
muestra en la figura 3-11.
Mover clave de maestro

Transaccin Maestro
Operaciones entre campos:
Mover, sumar y restar
Figura 3-11. Esquema de una actualizacin
Generalmente, la actualizacin puede tomar alguna de estas formas:

Slo se agregan nuevos registros: se llevan registros a la entidad de maes-
tro a partir de los registros de la entidad de transaccin. Los registros que
se agregarn no deben existir en la entidad de maestro; por ejemplo, llevar
las ventas del da a un historial de transacciones.
Actualizar sobre registros existentes: se busca un registro especfico de la
entidad de maestro segn la clave formada con los campos de la entidad de
transaccin, para efectuar sobre l operaciones de actualizacin, como mo-
ver o sumar campos. Los registros especificados deben existir previamente
en la entidad de maestro; por ejemplo, cuando las ventas del da rebajan el
stock de los productos vendidos en el maestro de artculos.
El registro se crea si no existe. Se busca un registro especfico de la enti-

dad de maestro segn la clave formada con los campos de la entidad de
transaccin; si no existe, el registro se crea en forma automtica con todos
sus campos en blanco o en cero, para luego efectuar sobre l operaciones
tales como sumar o multiplicar campos. Por ejemplo, cuando se quiere ob-
tener la venta total por sucursal: al principio, el maestro de totales no tiene
registros, luego, cada vez que aparece por primera vez una sucursal se crea
uno y despus se va acumulando sobre ese registro cuando la sucursal apa-
rece otras veces.
Obsrvese que los registros que sern actualizados o agregados podran
existir o no en la entidad de maestro.
Extraccin
Es una funcin que permite a la entidad A pedir uno o varios datos a la enti-
dad B. Aqu se busca un registro especfico en la entidad B segn la clave
formada con los campos de la entidad A, para extraer uno o varios campos
que sern regrabados en la entidad A, donde tambin deben estar definidos.
En la figura 3-12 se muestra el esquema de una extraccin.
Clave
A B
Datos solicitados
Figura 3-12. Esquema de una extraccin
Seleccin
Esta funcin permite seleccionar informacin desde una entidad ORIGEN para
llevarla a una entidad DESTINO. El traspaso se realiza aplicando condiciones de
seleccin fijas o variables, de forma similar a trabajar con herramientas tipo
QUERY (en relacin a consultas no estructuradas sobre la base de datos), tal
como se observa en la figura 3-13.
Origen Destino
Operaciones de mover,
con o sin condiciones
Figura 3-13. Esquema de una seleccin

200 JUAN BRAVO C.
En la seleccin, las condiciones fijas debieran quedar incorporadas al progra-

ma, evitndose que el usuario ingrese parmetros al ejecutar la aplicacin; por
ejemplo, la condicin: obtener los artculos con stock < 0 puede ser la op-
cin de un men.
Una alternativa de mayor flexibilidad y necesaria en estos tiempos, es que los
parmetros se almacenen en tablas, evitando que sean parte del cdigo.
Respecto a las condiciones variables, el usuario ingresa los valores requeridos
al momento de la ejecucin de la aplicacin; por ejemplo, tipo de artculos =
??; el usuario indica el tipo de artculos que desea obtener: lavadoras, refrige-
radores, etc
Mantencin
Esta funcin permite mantener una entidad de maestro a travs de transaccio-
nes que quedan registradas. Toma la forma que se muestra en la figura 3-14.
Mover clave de maestro

Transaccin Maestro
Agregar, modificar o eliminar
Figura 3-14. Esquema de una mantencin
Permite agregar, modificar y eliminar registros. Esta funcin es de fundamen-

tal importancia porque muchas veces se hace mantencin directa sobre un
maestro sin que quede ningn rastro. En este caso, todos los cambios quedan
registrados en una entidad histrica de transacciones, donde se almacenan
todos los movimientos.
Esto es importante, porque es muy posible que la entidad de transaccin sea
inicializada si el procesamiento fuera de tipo batch-interactivo.
3.5. FUNDAMENTOS DEL MODELAMIENTO DE

FUNCIONES
Por qu es modelar las funciones? El modelamiento de funciones tiene bases

slidas, algunas son:
Tener un modelo antes de construir. Es equivalente a preguntar sobre los
planos de un edificio, donde la extensin y profundidad de los modelos va
en directa relacin con la envergadura de la obra.
Economizar mucho tiempo y dinero al resolver gran parte de los problemas
en abstracto, antes de llevarlos a la construccin de cdigo.
Tener la posibilidad de aplicar herramientas de productividad o cdigo
reutilizable, lo cual sera imposible sin un modelo previo.
Realizar trabajo de grupo con otros colegas y con usuarios.
Simplificar la relacin con el usuario al conversar su requerimiento en la
forma de modelos.
Veremos:
1. Resolucin de problemas simples
2. Modelar bien a la primera
3. Concepto de mquinas abstractas
1. Resolucin de problemas simples

Siempre es posible dividir un problema complejo en un conjunto de proble-
mas simples, cada uno de los cuales ser ms fcil de resolver. Este es un
importante principio asociado al concepto de descomposicin funcional.
Adems, debemos reconocer que cada solucin obtenida es un caso particu-
lar de un problema general ms fcil de resolver.
Tambin se obtienen algunos subproductos:
Uniformidad, porque los problemas simples tienen la importante caracters-
tica de ser muy similares entre s. Por ejemplo, en la actualizacin se puede
encontrar que en la mayora de los casos se trata de mover, sumar o restar
campos entre dos entidades.
Automatizacin, si los problemas son simples, similares y uniformes, en-
tonces automatizar las soluciones es el siguiente paso, ms aun con el apo-
yo de las herramientas para la produccin de software.
202 JUAN BRAVO C.
2. Modelar bien a la primera

El problema debera ser resuelto con un buen modelo, simple, elegante y lo
ms estndar posible. As se evita en la implementacin hacer correcciones
innecesarias, parchar o incorporar ingeniosidades, porque todo lo necesario
qued resuelto en el modelo. Ya sea que se trate de la eficiencia en el espacio,
rapidez, esttica o seguridad.
De esta forma se reduce el riesgo de incorporar particularidades difciles de
programar y mantener.
Incluso se facilita el indispensable perfeccionamiento continuo que tiene lugar
despus de la implementacin.
3. Concepto de mquinas abstractas

Este concepto comenz a aplicarse en los aos sesenta, buscando modularidad
en los programas de computador. De aqu nacieron tambin los conceptos de
la programacin estructurada.
Uno de los principales investigadores en esta materia fue el Dr. Edsger W.
Dijkstra59, tambin importante impulsor de la programacin estructurada; l
define que una mquina abstracta consta de una entrada y una salida.
En 1968, el Dr. Edsger W. Dijkstra envi una carta a la Asociacin para
mquinas de computacin, en Estados Unidos, sobre el tema de si los progra-
madores deban usar instrucciones de salto incondicional (GO TO) en los pro-
gramas. Ah propuso la disciplina de secuenciamiento riguroso para evitar los
saltos incondicionales, con base en el concepto de mquinas abstractas de la
teora de sistemas. Se considera que esa carta dio origen a la prctica de la
programacin estructurada (y a la descomposicin funcional que luego sera
base del encapsulamiento).
La propuesta de este texto es aplicar el concepto de mquinas abstractas a
nivel de la aplicacin completa. As, en lugar de tener pocos programas gran-
59
Dijkstra (1930 2002), fue fsico terico y trabaj para Burroughs Corporation en los aos
70. Realiz reconocidos aportes a la naciente ciencia de la computacin y recibi el Premio
Turing en 1972. Promova utilizar estructuras de control en los programas de computador y
fue firme partidario de evitar en ellos la instruccin GO TO.
Sus aportes son tan relevantes, que se han formado grupos formados por discpulos y colegas
suyos de la Universidad de Texas donde ense el ltimo cuarto del siglo 20 para recu-
perar y disponer de su obra en Internet.
des cada uno con muchos mdulos, administraremos las funciones computa-
cionales atmicas que componen una aplicacin en la forma de componentes.
Entonces, obtendramos lo siguiente:
1 Entrada Funcin 1 Salida

Atmica
Una funcin computacional atmica tiene slo una entrada y una salida, lo
cual no tiene que ver con su tamao, porque lo importante es el cdigo apor-
tado para responder a las reglas del negocio. Por ejemplo, podemos tener un
programa de ingreso de datos de 1000 instrucciones y solamente 100 de ellas
corresponder a lgica del negocio propiamente tal, el resto es estructuracin
tpica de cdigo manejar pantallas, aceptar y validar datos que puede ser
aportado con herramientas de productividad o mediante cdigo reutilizable.
Podemos concluir que la funcin computacional se compone de una gran can-
tidad de cdigo generalizado y de alguna porcin de reglas del negocio.
A propsito, si estamos trabajando para una organizacin cuya misin no es la
informtica, sera de gran eficiencia ocupar el cdigo generalizado que ya
existe en el mercado en lugar de reinventarlo.
La implementacin de este concepto se cumple a cabalidad cuando un pro-
grama responde solamente a una funcin atmica, lo cual funciona bien bajo
el esquema tradicional de programacin y mejor aun si se cuenta con alguna
herramienta de apoyo para la produccin de software.
Algunos beneficios de este enfoque:
Permite reducir el tamao y la complejidad de los programas. Est sufi-
cientemente demostrado que el nivel de complejidad de un programa au-
menta geomtricamente respecto a su tamao. Bajo estos conceptos la ni-
ca preocupacin en cuanto a cdigo seran las reglas del negocio, las cuales
pueden ser administradas por alguna herramienta apropiada, hoy de bajo
costo en el mercado.
Las interacciones entre las funciones computacionales atmicas son total-
mente conocidas y estructuradas; por lo mismo, fciles de automatizar y
mejorar. Adems, es posible reemplazar una funcin computacional atmi-
ca por otra sin afectar al resto del sistema, si es que se mantienen intactas
las interacciones.
204 JUAN BRAVO C.
La modularidad e independencia de las funciones atmicas permite que

una aplicacin computacional sea construida con piezas intercambiables y
tal vez desarrolladas en diferentes lugares (como los juegos de armar de los
nios).
En el captulo 5 veremos que la orientacin a objetos recoge la mayora de los
conceptos descritos en este punto.
3.6. CRITERIO CURSO NORMAL DE LOS EVENTOS
El criterio curso normal de los eventos es un nuevo aporte de la teora de mo-

delos y aplica en varios tipos de modelos. Por ejemplo, en la nueva generacin
de flujogramas de informacin, en los casos de uso expandidos de la tcnica
UML (que veremos en el captulo 6) y en el mtodo GSP del captulo 1. Tiene
sus races en la ley de los pocos crticos de Pareto, que ya hemos comentado.
Se describe el curso normal de los eventos, tambin llamado el camino fe-
liz, sealando las acciones correctas de un proceso o relato, no se incluyen
las excepciones. Por ejemplo, si se requiere que un supervisor apruebe un do-
cumento, no se indica grficamente qu pasa si no lo aprueba, o si un bode-
guero debe recibir mercadera, no se indica que sucede si la rechaza. Son ex-
cepciones a la regularidad del proceso que se narran en hoja anexa, como par-
te de un texto complementario.
Aunque menos habitual, si el manejo de la excepcin tiene cierta complejidad,
tambin se puede construir un modelo especial para ella.
La idea general es tratar las excepciones como excepciones, sin darles el mis-
mo espacio visual que el curso normal de los eventos, en esto debe existir
armona entre el modelo y la realidad, donde lo ms habitual aparece ms y lo
menos, menos.
Veremos:
1. Aplicado al flujograma de informacin
2. Relacin del FI con la tcnica UML
1. Aplicado al flujograma de informacin

El Flujograma de Informacin (FI) describe y representa una gua de las acti-
vidades del proceso. Es un tipo de diagrama de flujo de informacin que pro-
porciona amplia visin acerca de variados aspectos del proceso: flujo, mensa-
jes, actividades, estructura y tecnologa. El FI es la secuencia y temporalidad.
Los Mensajes son el medio de comunicacin, pueden ser documentos, comu-
nicaciones electrnicas u orales. Las Actividades quedan especificadas por
cargos o roles. La Estructura queda representada por columnas. La Tecnolog-
a se indica en las actividades que tendrn algn nivel de apoyo tecnolgico.
El flujograma de informacin describe el curso normal de los eventos, donde
se describe grficamente el esquema habitual, la rutina. Las excepciones se
incluyen aparte.
206 JUAN BRAVO C.
As, el flujograma de informacin deja espacios para que las personas apli-
quen criterio, dejando de lado el absurdo intento de preparar flujos a prueba
de tontos. Lo nuevo es el principio SPPP (Simplificar Procesos y Potenciar
Personas), lo cual se logra aplicando por un lado el criterio curso normal de
los eventos y por otro a travs de capacitacin, sensibilizacin y empodera-
miento, entre otras acciones dirigidas a las personas.
Veamos este FI retomando el ejemplo del mapa de procesos del captulo 1. En
este flujograma de informacin los nmeros en recuadros con lnea punteada
son tiempos en minutos: duracin de cada actividad cuando estn dentro del
recuadro y tiempos de reposo de la transaccin cuando estn fuera. Los smbo-
los de uso ms habitual se describen en las siguientes pginas.
PROCESO DESPACHO INMEDIATO
CLIENTE BODEGA FINANZAS
ADMINISTRATIVO DE BODEGA DESPACHADOR
OE
Reservar y
PROCESOS emitir GD GD3
VENDER GD2 GDs
GD4 GD1
Buscar
producto
GD4
OE
Rebajar
saldo
Cliente
recibe
y firma
recepcin
GD3
GD2 PROCESO
GD1 CUADRAR
OE: Orden de Entrega, GD: Gua de Despacho
Figura 3-15. Ejemplo de flujograma de informacin despacho inmediato

Descripcin siguiendo el curso normal de los eventos

El ejemplo de la figura 3-15 corresponde a un proceso de Despacho inmediato
de productos vendidos en el mismo local, segn el mapa de procesos presen-
tado en la etapa de anlisis del captulo 1. Se trata de un local de ventas de
artculos de lnea blanca con una bodega al fondo de la tienda. El cliente reali-
za la compra, paga en el local y recibe una orden de entrega (OE), la cual
muestra en la bodega para retirar su producto.
El administrativo de la bodega recibe la OE y se asegura que est disponible
en el inventario una cantidad suficiente del producto, consultando en la panta-
lla del computador. Inmediatamente reserva la cantidad indicada del producto
y emite la gua de despacho (GD) en 4 ejemplares:
El ejemplar 4 se archiva junto con la OE.
Los ejemplares 1, 2 y 3 se envan al despachador, quien:
Busca el producto en la bodega (en la misma gua de despacho se indica la
ubicacin).
Rebaja el producto del inventario en el computador.
Le entrega el producto al cliente, quien firma la recepcin conforme.
junto con los ejemplares 1 y 2 de la GD.
Enva el ejemplar 3 de la GD a finanzas.
Excepciones:
Cuando consulta el administrativo de bodega, si no hay stock del producto
derivar al vendedor o al jefe de local, porque al efectuar la venta debiera
haberse hecho una reserva provisoria del producto.
Si el cliente no est conforme con el producto, entonces derivar al vende-
dor o jefe de local.
Si el despachador no encuentra el producto podra intentar en otra tienda,
buscar producto similar y otras posibilidades que se estudian durante el en-
trenamiento en el proceso. En cualquier caso, est empoderado para tomar
esas decisiones y para compensar al cliente por los retrasos o cambios hasta
un cierto monto.
Alcance del flujograma de informacin

El FI incorpora todo el detalle necesario porque desarrolla un proceso de bajo
nivel e incluso requiere adjuntar las muestras o el diseo de todos los formula-
rios, informes o pantallas que muestra el flujo.
208 JUAN BRAVO C.
Es un acuerdo que todos se comprometen a cumplir mientras se mantenga la

normalidad. Sin embargo, la complejidad del medio producir da a da desaf-
os que no estn resueltos en el diagrama, sin embargo, ah estn las personas
para decidir qu hacer. Esas mismas variantes ayudarn a perfeccionar el dia-
grama en la medida que se discuten y se hacen rutinarias.
Hacer flujogramas de informacin a escala humana significa conocer bien el
proceso y a las personas que los realizarn, tal como dice uno de los pioneros
de la gestin de calidad en Japn, Kaoru Ishikawa (1986, pp. 57-58): Las
normas y los reglamentos detallados resultan intiles si son fijados por el es-
tado mayor de la sede e ingenieros especialistas que no conocen la planta y
que ignoran los deseos de las personas que tienen que seguirlos. No es raro
encontrar tcnicos y personal de la sede que disfrutan dificultndolo todo en el
lugar de trabajo mediante la creacin de normas y reglamentos engorrosos. Si
encontramos que muchas normas nacionales son insatisfactorias, podemos
inferir que se establecieron en condiciones como las descritas.
El flujograma de informacin permite describir en todo detalle un proceso, es
fcil de usar, define canales fluidos de informacin, sirve como capacitacin y
documentacin, ayuda a normalizar el trabajo de la organizacin, facilita la
comparacin con procesos que se realizan en otras organizaciones y estimula
la participacin.
Cuando se incluyen los tiempos de duracin de las actividades y de reposo de
la transaccin, se aprecian con claridad las necesidades de optimizacin. Por
ejemplo, en la figura 3-15 la sumatoria de duracin de las actividades es de 15
minutos y los tiempos de reposo (los documentos estn en una cola) son de 34
minutos. Ser posible disminuir estos tiempos y as aumentar la satisfaccin
del cliente?
Un Flujograma de Informacin no es un diagrama de flujo computacional

Un FI no es un diagrama de flujo computacional, en consecuencia, debe evi-
tarse toda forma de condiciones, como los rombos tpicos de los flujogramas
antiguos (del tipo if then else, si sucede esto entonces haga aquello, si no
haga esto otro). No incluye condiciones, representadas por un rombo (ver fi-
gura 3-16). Cualquier decisin es una actividad ms y tiene como salida el
curso normal de los eventos. Tampoco incluye ciclos iterativos, de aquel tipo
en que una bifurcacin vuelve hacia arriba del flujo. Es suficiente con una
nota y normalmente ni siquiera eso es necesario, porque los flujogramas de
informacin son bastante autoexplicativos en ese aspecto.
Por qu? Porque estamos describiendo actividades que realizan seres huma-
nos, con una variedad y riqueza infinitas, as es que en cada paso hay que de-
jar la posibilidad de que las personas decidan variantes que no consider el
analista que dibuj el flujo (si utiliz rombos, entonces deja generalmente dos
salidas y en la vida real hay muchas ms). Adems, los smbolos y condicio-
nes computacionales tienden a alejar a los potenciales usuarios.
Por otro lado, as como el flujograma de informacin est dirigido a personas,
el diagrama de flujo est destinado a la lgica del computador, un flujo digital
estricto, tal como se aprecia en la figura 3-16.
Figura 3-16. Diagrama de flujo computacional
El diagrama de flujo est orientado a la codificacin en un lenguaje computa-

cional (Cobol, C, Visual Basic y muchos otros). Por lo tanto, incorpora condi-
ciones, retornos, loops y otras funciones propias del programa de computador.
Es diferente a un flujograma de informacin.
Caractersticas del Flujograma de Informacin

1. Se mantiene la temporalidad. Una actividad que se realiza despus va ms
abajo60. Adems, as como no podemos retroceder en el tiempo, se evita
volver con una lnea hacia arriba.
2. El flujograma de informacin es a nivel atmico, es decir, con todo detalle.
Por ejemplo, si una orden de compra tiene cuatro ejemplares (un original y
tres copias), en el diagrama debe indicarse el destino de cada uno de ellos,
es decir, cada rama debe ser explorada. Tambin corresponde al concepto
de atomicidad conservar el orden de cada ejemplar de un documento, por-
60
Es lo habitual, sin embargo, depende de la convencin que se use en la empresa, ocasio-
nalmente la temporalidad se aplica hacia la derecha (como escribimos). Est bien, es una u
otra forma, nunca ambas a la vez en la misma organizacin.
210 JUAN BRAVO C.
que no es lo mismo recibir el ejemplar uno que el ejemplar tres del

formulario, sobre todo si se usa papel autocopiativo.
3. Incluye la estructura organizacional, representada por las columnas que
estn de fondo. Llega hasta el nivel de cargos.
4. Describe procesos operativos. Es breve y no incluye conectores, porque se
trabaja con procesos operativos, breves, en no ms de una pgina. Por
ejemplo, un macroproceso de compras se redujo a cuatro procesos operati-
vos: compra de artculos de oficina, compra de equipos computacionales,
compra de repuestos de maquinarias y compra de materias primas, cada
uno con su propio FI. En los diagramas antiguos (tipo diagrama de flujo
computacional) se hubiera incorporado el macroproceso completo. Lo nue-
vo es construir flujogramas de informacin independientes para cada pro-
ceso operativo y el mapa de procesos ayuda a ver el todo.
5. No incluye comentarios, porque se trata que sea autoexplicativo. Aunque es
vlido usar a veces columnas de observaciones en los extremos del dia-
grama, principalmente en el extremo derecho. El detalle del flujograma se
incluye en texto anexo (dos pginas de texto por cada pgina de FI es un
promedio razonable) como parte de la descripcin de los procedimientos
administrativos.
6. Es un diagrama que se va construyendo y perfeccionando a travs de bo-
rradores sucesivos.
Smbolos de uso ms habitual * actualzar* 2 lminas ppt
Actividad Se debe usar verbos en infinitivo: Emitir

manual O/C, Ingresar solicitud. Actividad
Es un rectngulo.
Actividad Las actividades que tienen algn componente
computacional de interaccin computacional se indican con Actividad
computacional
doble lnea (a los lados o en todo el borde)
Actividad Es una actividad de aprobacin, tal como
de aprobacin autorizar un crdito o una compra.
Actividad Es una actividad de control, tal como una

de control informacin al rea de auditora. Control
Es un cuadrado.
Archivo El tringulo con la punta hacia abajo repre- Archivo

manual senta almacenamiento manual permanente de manual
permanente la informacin, principalmente archivadores

y gavetas.
Archivo El tringulo con la punta hacia arriba repre-
manual senta almacenamiento manual transitorio, tal
Archivo
transitorio como una carpeta con solicitudes de compra transitorio
en espera de firma por el gerente.
Formulario Es toda forma en papel en que los datos flu-
Formulario
yen, tal como una factura, una orden de com-
pra o una liquidacin de sueldo.
Otro proceso Indica acciones que estn ms all del proce-
so. Por ejemplo, es una forma de decir que se
envi un documento a un proveedor o que la
accin sigue en otro proceso. En cul? Hay
que ver el mapa de procesos.
Archivo Ambas formas aplican, tipo tambor es ms

computacional reciente y recomendable.
Comunicacin Tipo rayo para comunicacin electrnica y

electrnica smbolos Windows sobre el rayo para ms
detalle (correo, planilla, etc) @ para Inter-
net, otro para intranet o sistemas internos
Resultados del Flujograma de informacin

Tpicamente, al trabajar con un flujograma de informacin se pide identificar:
Cliente del proceso
Dueo del proceso
Variables crticas y mediciones asociadas
Adems de las observaciones, las excepciones y el trabajo conjunto con el
mapa de procesos, el cual debiera estar siempre a la vista.
En el anexo 5 se presenta el Mtodo de Accin Rpida (MAR) sobre proce-
sos. Una tcnica orientada a la gestin de procesos que hace uso intenso de los
flujogramas de informacin para mejorar el hacer de la organizacin.
212 JUAN BRAVO C.
2. Relacin del FI con la tcnica UML

Uno de los aspectos metodolgicos y de investigacin ms interesantes de este
libro es el hecho de buscar un punto de encuentro entre dos tcnicas de amplio
uso: los flujogramas de informacin y UML.
Especficamente ese punto de encuentro est en las actividades con alguna
interaccin computacional del flujograma de informacin, las cuales, si estn
debidamente segmentadas segn las propuestas del texto, darn origen a los
casos de uso del sistema computacional. Son los casos de uso correspondien-
tes a los procesos del negocio.
En la figura 3-17 se aprecia este punto de encuentro. La actividad Rebajar
saldo del flujograma de informacin (figura 3-15) se transforma en un caso
de uso de alto nivel de UML.
Actividad del FI Caso de uso de alto nivel

Despachador Terminal en Bodega
Rebajar Rebajar saldo

Saldo
2
Nota: una actividad Usa el lector de cdigo de

computacional del barras para leer la etiqueta
FI se transforma de cada producto que se
en un Caso de Uso vende. En el sistema se
de alto nivel rebaja el saldo del producto.
Figura 3-17. Relacin del FI con la tcnica UML
Especficamente en la figura 3-17:

El actor es el despachador, tomado desde el nombre de la columna del flu-
jograma de informacin.
El caso de uso es Rebajar saldo, puesto en infinitivo porque refleja una
accin.
El caso de uso de esta figura es del tipo alto nivel porque la descripcin
es general.
La situacin ocurre en el terminal de la bodega, incluyendo los accesorios,

tal como el lector de cdigo de barras.
Una recomendacin metodolgica es unir en un Diagrama de casos de uso
(una forma de agrupacin de casos de uso) los casos de uso de cada proceso
operativo (o flujograma de informacin).
214 JUAN BRAVO C.
CAPTULO 4.
MODELAMIENTO DE DATOS
Captulo 4. Modelamiento de datos
Sencillez, claridad y elegancia son los sellos de los buenos pro-

gramas; oscuridad, ingeniosidad y complejidad son indicaciones
de un diseo inadecuado y un pensamiento mal orientado.
Richard Fairley
El modelamiento de datos logra una visin de conjunto de los datos de la apli-

cacin y de su contexto. En todo caso, se requiere un gran modelo con los
conjuntos de datos de toda la organizacin para que las diferentes aplicaciones
vean y trabajen con la porcin que les corresponde.
Esta es la cuarta competencia considerada para apoyar la elaboracin de
gura (en la introduccin se incluy la visin global). Es indispensable que el
analista conozca acerca del modelamiento de datos como simple responsabi-
lidad profesional porque es una habilidad bsica de su labor.
CAPTULO 6. UML
Es vital la visin de conjunto que provee el modelo conceptual de datos de

toda la organizacin, permite comprender, ubicarse y evitar inconsistencias
como la de crear dos veces la misma tabla. De esta forma, el aporte de la solu-
cin de software ser aportar nuevas tablas o modificar las existentes.
Veremos:
Definiciones sobre el modelo de datos
Criterios bsicos de normalizacin de datos
Enfoque de bases de datos
216 JUAN BRAVO C.
4.1. DEFINICIONES SOBRE EL MODELO DE DATOS
El modelo de datos consta de entidades y relaciones. Una entidad es un con-

junto de datos coherentes que forman una unidad entre s; por ejemplo: clien-
tes, facturas de venta, proveedores. Una relacin permite enlazar dos entida-
des para establecer recorridos que permitan efectuar la navegacin automti-
ca, con el fin de consultar y manipular informacin. Por ejemplo: obtener una
lista de los clientes que han adquirido el artculo 2051.
Disponiendo del modelo de datos completo ser posible presentar visiones
parciales a los usuarios, segn sus requerimientos.
Veremos:
1. Representacin de una entidad
2. Relaciones propias
3. Caractersticas estticas y funcionales de campos
4. Tipos de entidades
5. Relaciones entre entidades
1. Representacin de una entidad

La representacin tpica de una entidad o tabla se muestra en la figura 4-1 para
un ejemplo de clientes (el RUT Rol nico Tributarioen Chile es la iden-
tificacin de cada persona u organizacin para fines tributarios).
Fecha de Nombre Lnea

RUT del cliente
incorporacin del cliente de crdito
4.101.201-4 10/01/1993 Juan Prez 500.000

7.749.654-3 15/02/1993 Pedro Torres 700.000
10.143.245-6 01/03/1993 Ximena Kohl 900.000
Figura 4-1. Componentes de una entidad
Para efectos de facilitar la comprensin de las materias, se han conservado

algunas denominaciones tradicionales, tales como entidad, registro y campo.
En la figura 4-1 se puede apreciar que:
Cada lnea corresponde a un registro de la entidad clientes, tambin llama-

da fila. Por ejemplo, la lnea correspondiente a Juan Prez.
Cada columna corresponde a un campo de la entidad clientes. Tambin se
le llama atributo. Por ejemplo: Fecha de incorporacin.
Todos los registros (lneas) de una entidad deben tener los mismos campos
y cada campo debe tener un valor vlido en todo momento. por ejemplo, no
sera vlido un cliente sin nombre o RUT.
Generalmente, para individualizar cada registro se define una clave de acceso,
compuesta por uno o varios campos, como el RUT en el ejemplo de la figura
4-1. Esta clave debe ser nica (no puede repetirse entre un registro y otro).
La caracterstica de clave nica ha sido uno de los pilares del modelamiento
tradicional, aunque tambin ha sido fuente de muchas dificultades en el mode-
lamiento y en la interaccin con el usuario, debido a su poca naturalidad. Hoy,
la orientacin a objetos, algunas bases de datos y herramientas de productivi-
dad, estn transformndola poco a poco en slo una caracterstica opcional.
La entidad tambin puede representarse con un rectngulo, su clave se anota
arriba, a la izquierda las Relaciones Propias (RP) y a la derecha el resto de los
campos, tal como se muestra en la figura 4-2.
Nombre del Rut

cliente (RP)
Clientes Fecha de incorporacin
Lnea de crdito
Figura 4-2. Representacin grfica de una entidad
En la figura 4-2 se puede apreciar que su clave es el RUT, que tiene una rela-
cin propia por nombre del cliente y que el resto de los campos son fecha de
incorporacin y lnea de crdito.
2. Relaciones propias (RP)

Las relaciones propias son al interior de la tabla, cuando un campo se declara
como una llave alterna y permite recorrerla. Las RP permiten diferentes acce-
sos a los datos de una entidad, de tal forma que cualquier campo puede ser
una relacin propia o parte de ella. Por ejemplo, el nombre del cliente, la
218 JUAN BRAVO C.
fecha de incorporacin y la lnea de crdito en el caso de la figura 4-2. Una

relacin propia puede contener dos o ms campos; por ejemplo, fecha de in-
corporacin y nombre del cliente.
La nica limitacin en la definicin de relaciones propias es la disponibilidad
de mayores recursos de hardware, porque por cada relacin propia el sistema
administrador de bases de datos crea y mantiene nuevas tablas de ndices.
Se podra decir que la RP corresponde a un ordenamiento permanentemente
actualizado de los datos. Podemos declarar la relacin propia por la cual que-
remos acceder a la informacin: nombre, ciudad, telfono, etc y esa infor-
macin estar siempre ordenada.
En una relacin propia el contenido de los campos puede ser con o sin dupli-
cado. En el primer caso los campos pueden repetirse y no sirve como una cla-
ve identificatoria alternativa. En el segundo caso, puesto que el contenido de
los campos no se repite, la relacin propia puede ser usada como una llave
alternativa.
La definicin de relaciones propias, al igual que la identificacin de claves,
est dejndose de lado en la medida que nuevas herramientas de software
permiten un manejo automatizado, apoyado por el equipamiento moderno
cada vez ms poderoso. Esto es un avance importante en simplificacin que
facilita la incorporacin del usuario; por ejemplo, la figura 4-2 podra haber
quedado de esta forma:
Clientes
RUT
Nombre del cliente
Fecha de incorporacin
Lnea de crdito
Solamente ese sera el esfuerzo si tuviramos el apoyo automtico para que el

software se encargara de individualizar cada registro y suponer que cada cam-
po es una relacin propia.
3. Caractersticas estticas y funcionales de campos

Cada uno de los campos de una entidad incluye caractersticas estticas y fun-
cionales. En la figura 4-2, una caracterstica esttica es la fecha de incorpora-
cin del cliente con la estructura dd/mm/aaaa, una caracterstica funcional es
validar que los valores posibles para el mes sean slo entre 1 y 12.
Las caractersticas estticas son atributos fijos del campo, por ejemplo: nom-
bre del campo, descripcin, comentario, largo, tipo, signo, formato de desplie-
gue, dgitos parte entera y decimales.
Las caractersticas funcionales son atributos dinmicos del campo, los cuales
pueden ser implementados con estructuracin de lgica en la forma de cdigo
reutilizable. Generalmente, son pequeas funciones computacionales tambin
denominadas triggers o reglas del negocio.
Algunos ejemplos de caractersticas funcionales son:
Condiciones de validacin, para verificar rangos (desde-hasta), secuencias
de valores fijos o condiciones entre campos.
Condiciones de existencia, para verificar la existencia de un registro en otra
entidad. Por ejemplo: cuando en la entidad ventas se ingresa el cdigo de
producto hay que asegurarse que exista en el maestro de artculos. Al mis-
mo tiempo debiera ser posible ver otros datos en la entidad de verificacin,
por ejemplo, desplegar la descripcin del artculo.
Esto es parte de la llamada integridad referencial.
Conjunto de valores posibles, para despliegue en una ventana al momento
del ingreso de datos y como apoyo en mltiples formas de consulta y mani-
pulacin de datos.
La lista de valores posibles es una caracterstica del campo y no es necesa-
rio definir una funcin. En la prctica, la mayora de las bases de datos mo-
dernas lo proveen como un parmetro ms.
Rutinas de clculos especiales, como clculo de dgito verificador y trans-
formacin de cantidades a letras.
Procesos de actualizacin, se refiere a procedimientos que van a modificar
el contenido de un campo al cumplirse alguna condicin; por ejemplo, re-
bajar el stock del producto cuando se produce una salida por ventas.
Tipos de campo
Prcticamente todas las herramientas proveen tipos de campo, a cada uno de
ellos se asocian caractersticas estticas y funcionales que pueden ser modifi-
cadas; por ejemplo, algunos tipos de campo son:
Numrico: largo 9, sin signo.
Alfanumrico: largo 45.
Fecha: largo de 8 dgitos: 2 para da, 2 para mes y 4 para ao; con msca-
ras a eleccin: dd/mm/aaaa o mm/dd/aaaa; realizar aritmtica de fechas:
responder a cuntos das hbiles del mes llevamos? sumar o restar un
220 JUAN BRAVO C.
mes; y efectuar las validaciones tpicas: mes de 1 a 12, da de 1 a 28, 29, 30

31, segn mes y ao.
Campo con dgito verificador: 10 dgitos de largo, ms un campo alfa-
numrico para el dgito verificador; debiera aceptar diferentes mdulos,
mscaras y tablas de ponderadores.
Perodo mensual: largo de cuatro dgitos: 2 para mes y 2 para ao; diferen-
tes mscaras y clculo de meses de diferencia.
Lista de valores: asocia una conexin a otra tabla donde se encuentra una
lista de los valores posibles que puede tomar el campo, por ejemplo, ciuda-
des o pases.
La funcionalidad asociada a los tipos de campo viene aportada por la respecti-
va herramienta, aunque lo habitual es que tambin sea posible aportar cdigo.
4. Tipos de entidades
Prcticamente en todos los casos del procesamiento de datos, es posible iden-
tificar los siguientes tipos de entidades:
Maestro: contiene la informacin permanente del sistema. Los datos de la
entidad de maestro slo deberan modificarse a travs de transacciones. Al-
gunos ejemplos de entidades de este tipo son: proveedores, clientes, artcu-
los o empleados.
Transacciones: son los conjuntos de datos que transitan por la organiza-
cin y que afectarn las tablas maestras. Por ejemplo: ventas del da, com-
pras del da y descuentos en sueldos.
Temporales: se trata de una o varias tablas donde se guardan datos transito-
rios extrados de maestros, transacciones o de ambos. Puede ser directa-
mente una copia de algunos de ellos. La entidad temporal se utiliza para or-
denar y seleccionar datos o realizar clculos. Generalmente se elimina des-
pus de ser utilizada. Tambin puede ser una vista parcial.
La relacin entre maestros y transacciones da origen a una referencia cruzada,
tal como vimos en el modelo orientado al flujo de transacciones de la seccin
anterior. Formalmente, la relacin sera de este tipo:
M1 M2 M3
T1
T2
Mi = Maestro; Ti = Transaccin
Se puede apreciar que los maestros son los pilares que dan el soporte a la es-
tructura y las transacciones la atraviesan horizontalmente, modificando los
datos de cada maestro asociado a esas transacciones. Por ejemplo, la entidad
de transaccin 1 afecta a los maestros 1 y 2, la entidad de transaccin 2 afecta
a los maestros 1 y 3.
En cada nodo o punto de encuentro entre una entidad de transaccin y una de
maestro, es necesario realizar un proceso de actualizacin, generalmente a
travs de construir una funcin computacional atmica (tal como vimos en el
captulo 3).
Origen de las entidades
Se incluye la siguiente tipologa como una forma de ayudar al diseador en la
identificacin de entidades, por ejemplo:
Elementos fsicos: automviles, fbricas, libros, edificios, lnea blanca,
vestuario, medios de transporte.
Elementos lgicos: cuentas contables, venta histrica, cuentas corrientes.
Roles de personas: doctores, ingenieros, profesores, empleados, abogados,
dueas de casa, siclogos.
Roles de instituciones: clnicas, AFPs, isapres, farmacias, casas de reposo,
empresas de diferente tipo.
Roles mixtos, personas u organizaciones: contribuyentes, clientes, provee-
dores, asociados.
Transacciones: eventos que provocan cambios en otros objetos, compras,
ventas, accidentes, vuelos, depsitos, giros, ajustes.
Interacciones: generalmente dan origen a una entidad asociativa: costos
entre proveedores y artculos, licencias entre drogas y laboratorios, ventas
entre vendedores y clientes.
No son distinciones rgidas, porque pueden haber mltiples situaciones inter-
medias y otras clasificaciones.
Una caracterstica comn es que aparecen ms de una vez en la situacin que
se est estudiando para modelar.
222 JUAN BRAVO C.
5. Relaciones entre entidades

Son relaciones donde se comunican dos entidades, lo que da origen a una ma-
lla que es llamada modelo de datos, de esta forma:
0,n 1 1,10 0,n

Clientes Facturas Artculos
En esta figura se utiliz el esquema de notacin que identifica la cantidad (m)

o un rango (m, n) de ocurrencias entre las entidades. Un cliente puede tener
desde 0 a n facturas. Una factura puede tener entre 1 y 10 artculos. Un artcu-
lo puede estar entre 0 y n facturas.
En lo que sigue, veremos los cuatro tipos bsicos de relaciones: 1:1, 1:N y
N:M y N:M especial, tambin comentaremos sobre la relacin de pertenencia
y las relaciones de uso.
1) Relacin 1:1
0,1 1
Clientes Crdito
Por ejemplo, un cliente puede tener slo un crdito autorizado o ninguno. Un

crdito autorizado pertenece a slo un cliente.
2) Relacin 1:N
Clientes Facturas Clientes
0,m 1
Clientes Facturas Facturas
Es una relacin de uno a muchos. Las formas ms habituales de representa-

cin de una relacin 1:N se muestran con el ejemplo de clientes y facturas de
venta. En esta relacin, un cliente puede tener desde cero a varias facturas y
una factura puede tener solamente un cliente.
Relacin de pertenencia
Un caso especial de la relacin uno a muchos es la relacin de pertenencia.
Aqu la entidad dominante es llamada Padre y la entidad dependiente se de-
nomina Hijo. En este tipo de jerarqua deberan considerarse especialmente
estas restricciones:
No se puede eliminar un registro padre si existen registros hijo.
No se puede agregar un registro hijo si no existe el registro padre.
La clave de la entidad hijo es la clave de la entidad padre ms otro, u otros
campos, identificadores de la entidad hijo. Sera el caso de la relacin
PROVEEDORES FACTURAS, donde necesariamente la entidad hijo debe tener
como clave el RUT del proveedor y el nmero de factura, para evitar confun-
dir las facturas de diferentes proveedores.
3) Relacin N:M
Tambin llamada tipo red (muchos a muchos).
Las formas ms habituales de representacin grfica de una red se muestran
en la siguiente figura. Como ejemplo, se utiliz la relacin existente entre las
entidades proveedores y artculos. En este caso, un proveedor abastece mu-
chos artculos y un artculo es provisto por muchos proveedores.
Proveedores Artculos
0,m 0,m
Proveedores Artculos
Proveedores Proveedores
Artculos Artculos
A diferencia de la jerarqua, en la red la relacin es independiente de los datos

de las entidades. Esto significa que no hay pertenencia entre entidades y que
los respectivos campos de relacin podran no ser parte de las entidades; por
ejemplo, los artculos ofrecidos por el proveedor.
224 JUAN BRAVO C.
Se puede comprender mejor la independencia entre relacin y entidad con un

sencillo ejemplo: las entidades alumnos profesores incluyen los datos per-
sonales de los alumnos y de profesores, respectivamente; sin embargo, slo en
la relacin se encuentra la informacin de alumnos por profesor y profesores
por alumno.
La implementacin de la relacin tipo red es bastante compleja, porque cada
operacin sobre una entidad significa actualizar los ndices de acceso y resol-
ver los serios problemas de consistencia de los datos, aunque actualmente esta
facilidad viene provista automticamente por los sistemas administradores de
bases de datos.
La descomposicin lgica de una red significa construir una doble jerarqua,
implementada mediante dos nuevas entidades, hijas de las entidades origina-
les. Cada una es un ndice que apunta a la otra entidad, tal como en la siguien-
te figura con las entidades A y B.
A A B
=
B ndice A/B ndice B/A
Si el recurso es slo un sistema administrador de bases de datos jerrquico

igual se puede implementar una red de esta forma, aunque cuidando la consis-
tencia de la base, porque es fcil realizar alguna operacin por ejemplo de
eliminacin de un registro y dejar alguna tabla de ndices sin actualizar.
Algunas convenciones tpicas de la implementacin de la relacin muchos a
muchos son:
Al agregar un tem en la relacin, previo deben existir ambos padres.
Al eliminar un padre, se eliminan primero los elementos de la relacin.
En general, por simplicidad del modelo y mejora del tiempo de respuesta, se
considera apropiado dejar slo las relaciones N:M que sean indispensables. Por
ejemplo, la relacin entre clientes y avales es muchos a muchos. Un cliente
puede tener ms de un aval y un aval puede avalar a varios clientes; sin em-
bargo, en algunas instituciones financieras, la norma es que un aval slo puede
avalar a un cliente, aunque un cliente puede tener varios avales. Por lo tanto,
la relacin cambi a uno a muchos y se resolvi una relacin N:M.
4) Relacin N:M especial

La relacin N:M tpica no permite manejar informacin propia de la interac-
cin; por ejemplo, en la relacin: proveedores artculos, el precio de los
artculos segn cada proveedor. Para resolver este problema, la relacin puede
tomar la siguiente forma:
Proveedores Costo Artculos
Donde se establece un nodo en el arco de la relacin, la que a su vez se trans-

forma en una entidad asociativa en la cual se puede almacenar mayor infor-
macin, por ejemplo, el costo del artculo entre diferentes proveedores.
Esta entidad asociativa es indispensable en el esquema relacional, donde las
diferentes tablas deben contener los campos a travs de los cuales se manipu-
larn los datos.
A esta relacin tambin se le denomina NUB natural porque tiene vida pro-
pia, es decir, aparece en el modelo conceptual (modelo que ve la realidad del
usuario) y tiene un identificador. Tambin existe el NUB artificial, creado
slo para evitar la relacin N:M mediante una doble jerarqua, no los ve el
usuario en el modelo conceptual ni tienen identificador propio.
La entidad asociativa tambin puede estar relacionada con una sola entidad,
como en el siguiente ejemplo, donde la entidad parentesco tendra los siguien-
tes atributos (persona, persona, parentesco).
Personas Parentesco
Por simplicidad del modelo, se recomienda estudiar la real necesidad de esta-

blecer nodos con informacin adicional en relaciones N:M.
Relaciones de uso
Las relaciones de uso son independientes de las entidades, porque no es nece-
sario que su estructura contenga la relacin, como en la pertenencia. A veces,
para efectos de implementacin, es necesario crear entidades asociativas, co-
mo en el caso del NUB natural o artificial.
226 JUAN BRAVO C.
Las relaciones de uso pueden tomar cualquiera de las siguientes formas:

Relacin uno a uno.
Relacin uno a muchos, a excepcin de la relacin de pertenencia.
Relacin muchos a muchos, ms conocida como tipo red.
4.2. CRITERIOS BSICOS DE NORMALIZACIN DE

DATOS
Se presenta un esquema de normalizacin del modelo de datos, basado en dos

criterios: eliminacin de grupos repetitivos y eliminacin de dependencias
parciales. Ambos fciles de entender y aplicar, as aumenta la posibilidad de
aplicacin por parte de especialistas y usuarios.
Aunque, un esquema completo de normalizacin es el que propone el Dr. E.
F. Codd, con sus formas normales y variaciones sobre ellas. Los dos criterios
de este captulo son una simplificacin que permite un acercamiento prelimi-
nar y equivalen hasta la tercera forma normal.
Por qu normalizar?
Porque presenta variados beneficios, por ejemplo:
Lograr definir entidades atmicas, tiene la ventaja de trabajar con un con-
junto de datos uniforme, sujetos a la misma clave, esto simplifica el mode-
lo y da la posibilidad de aplicar funciones normalizadas.
Evitar la redundancia de datos, lo cual, adems de ordenar y economizar
recursos, ayuda a mantener la integridad, porque cada dato existe slo una
vez en el sistema, si no fuera as? A cules de las versiones de un dato le
cree el usuario?
Normalizar el almacenamiento de datos, no slo al interior de la organiza-
cin, sino tambin al exterior. De esta manera se economiza en preparacin
de especialistas y es posible aplicar herramientas uniformes, como los sis-
temas administradores de bases de datos relacionales y las diferentes
herramientas de productividad, para automatizar mltiples funciones: con-
sulta de informacin, integridad, privacidad, recuperacin, ingreso de da-
tos, informes y muchas otras.
Aplicar herramientas de apoyo en el modelamiento, todas las cuales ayu-
dan y hacen exigible la normalizacin de los datos. Por ejemplo, algunas
herramientas de apoyo en el modelamiento de datos son: ERWIN y System
Architect.
228 JUAN BRAVO C.
Evitar los tipos de registros

Uno de los principales elementos que confabula contra la normalizacin de los
datos, es incluir tipos de registros; por ejemplo: una tabla de transacciones
con tipo de dato 1 para ventas y 2 para compras, lo cual presenta varios incon-
venientes:
Probablemente existirn campos del registro asociados solamente a un
tipo de datos.
Se produce una excesiva dependencia de los especialistas que
construyeron el sistema, porque es muy difcil de entender.
Como la entidad no es uniforme, es difcil aplicarle funciones
automticas; en consecuencia, los programas que manipulan estas
entidades son complejos y extensos.
Veremos:
1. Eliminacin de grupos repetitivos
2. Eliminacin de dependencias parciales
3. Tabla de traduccin
1. Eliminacin de grupos repetitivos

Significa que los campos que se repiten en una entidad se llevan a otra.
La nueva entidad nace con la misma clave de la entidad origen, ms un identi-
ficador de cada ocurrencia del grupo repetitivo; puede ser un nmero correla-
tivo o alguno de los campos del grupo repetitivo.
El ejemplo de la figura 4-3 corresponde a la eliminacin de un grupo repetiti-
vo incorporando un nmero correlativo externo en una factura de venta.
A Entidad no normalizada
Clave Rut Grupo repetitivo

Fecha del tem 1 tem 10
N factura cliente Cdigo Cantidad Precio Cdigo Cantidad Precio
Entidades normalizadas
B Encabezado C detalle
Clave Rut Clave
Fecha del Cdigo Cantidad Precio
N factura cliente N factura N tem
Figura 4-3. Eliminacin de grupo repetitivo usando nmero correlativo externo
En este caso:
La factura de la entidad A tiene los campos: # factura, fecha, RUT y 10

artculos, cada uno con cdigo, cantidad y precio. La normalizacin de esta
entidad dio como resultado la creacin de las entidades B Y C.
Nota: el subrayado en # factura significa que el campo es identificatorio,
que pertenece a la clave.
La entidad B (ENCABEZADO), qued con los campos: # factura, fecha y RUT
del cliente. Se puede apreciar que posee los mismos datos de la entidad A,
menos el grupo repetitivo.
La entidad C (DETALLE), qued con los campos: # factura, # tem, cdigo de
artculo, cantidad y precio. Se agreg el nmero de tem a la clave de la en-
tidad de detalle, equivalente a un nmero de lnea en la factura, porque en
la factura podra repetirse un artculo, lo cual inhabilitara al cdigo para
ser parte de la clave.
El uso del nmero de tem, un correlativo externo, presenta varias ventajas:
Se respeta el orden de ingreso de cada elemento del grupo repetitivo, lo
que es vital en el momento de hacer revisiones manuales. Si la clave fuera
el cdigo del artculo, aun cuando ste no se repitiera, es posible que se
pierda el orden de ingreso, porque es poco probable que el cdigo se anota-
ra en orden ascendente en el documento.
Es ms uniforme y ordenado.
Se le da flexibilidad al modelo, porque se podra repetir un cdigo sin afec-
tar la integridad del documento; por ejemplo, en el caso de una factura se
podra anotar dos veces un mismo producto, tal vez porque el cliente re-
cord al final del pedido que requera mayor cantidad del primer producto
solicitado.
En el ejemplo de la figura 4-4 vemos la eliminacin de un grupo repetitivo
usando un campo de la entidad origen (la misma de la figura 4-3), para este
ejemplo, el cdigo de artculo de la factura de venta.
B Encabezado C detalle
Clave Rut Clave
Fecha del Cantidad Precio
N factura cliente N factura Cdigo
Figura 4-4. Eliminacin de grupo repetitivo usando campo interno

230 JUAN BRAVO C.
Al usar el cdigo podemos apreciar que:

La eliminacin del grupo repetitivo de la entidad A dio origen a una enti-
dad (C) de detalle, con los campos: # factura, cdigo de artculo, cantidad y
precio. En este caso, suponemos que el cdigo de artculo no se repite en la
factura, as es que se lo incorpor en la clave como un campo identificador.
La entidad (B) de encabezado qued igual que en la figura 4-3.
Eliminar un grupo repetitivo usando un campo que ya viene incorporado en la
entidad original es la forma ms habitual de resolver un grupo repetitivo.
Prcticamente en todos los casos, la eliminacin de un grupo repetitivo da
origen a una relacin de pertenencia entre las entidades de encabezado y deta-
lle que se obtuvieron del proceso de normalizacin. Grficamente, el resultado
se ve as:
B
2. Eliminacin de dependencias parciales

El trmino dependencia parcial se aplica a campos que dependen slo de una
parte de la clave o bien de un campo que no es parte de la clave. Por lo tanto,
una dependencia vlida se da cuando el campo depende de toda la clave.
Generalmente, la eliminacin de las dependencias parciales significa llevar los
campos parcialmente dependientes a una tabla de traduccin (T/T) o aplicar
una condicin de existencia (C/E) sobre otra entidad que tenga como clave el o
los campos origen de la dependencia parcial, tal como se muestra en la figura
4-5. La eliminacin de la dependencia parcial da origen a una relacin uno a
muchos cuando la dependencia del campo es respecto a una parte de la clave.
Si la dependencia es respecto de un campo no clave, se genera una relacin de
uso entre las entidades.
A Entidad no normalizada
Clave Cdigo Descripcin Nombre
Cdigo de Stock de del estado de
Sucursal producto estado producto
B Entidad original normalizada Tabla de Traduccin (T/T)
Clave T/T 18 T/T 18
Stock Cdigo de Descripcin
Sucursal Cdigo
producto
de
estado del estado
C/E
C Nueva entidad
Clave Nombre
Cdigo de de
producto producto
Figura 4-5. Ejemplo de eliminacin de dependencias parciales
En la figura 4-5 se aprecia que la entidad A tiene dos campos que no son de-
pendientes de toda la clave:
Descripcin del estado: es la traduccin del cdigo de estado en la sucur-
sal, un campo no clave. La forma que toma la descripcin es, por ejemplo:
1=terminado, 2=semiterminado.
La tabla de traduccin que da respuesta a esta dependencia parcial podra
haberse reemplazado por una lista de valores posibles, como la que aparece
en el ambiente Windows cuando se requiere buscar dentro de una gama de
posibilidades. Este tema se trata extensamente en el siguiente punto, sobre
tabla de traduccin.
Nombre del artculo: dependiente del cdigo del producto, un campo clave.
Cmo se resuelven estas dos dependencias parciales de la entidad A?
En el primer caso, como se trata simplemente de la traduccin de un cdigo
(cdigo de estado versus descripcin de estado), se le asigna una tabla de tra-
duccin identificada con el nmero 18 en el ejemplo. Tambin estara correcto
definir una nueva entidad, la cual nacera con el cdigo y la descripcin del
232 JUAN BRAVO C.
estado, aunque sera muy elemental y estorbara en el modelo de datos porque

no sera la nica y entonces existiran muchas tablas pequeas61.
En el segundo caso, respecto al cdigo y nombre del artculo, formando una
nueva entidad (C) con: cdigo del artculo y nombre del artculo. Sobre esta
nueva entidad, llamada entidad de existencia, se aplica la condicin de exis-
tencia a travs de relacionar el cdigo del artculo de la entidad B con la clave
de la entidad C.
Se intercalaron puntos suspensivos en la entidad C para destacar que es posi-
ble agregarle otros campos; por ejemplo: stock mnimo y costo del artculo,
aun cuando no estaban incluidos en la entidad A; esto porque el modelamiento
es una actividad plenamente retroalimentada, es decir, se van haciendo perfec-
cionamientos sucesivos hasta dar por terminado el modelo y despus igual
se sigue perfeccionando. Tambin podra haberse utilizado una entidad pre-
existente para formar la condicin de existencia.
La entidad B es lo que qued de la entidad A despus de la normalizacin.
A veces es preferible aplicar una condicin de existencia antes que una tabla
de traduccin, observando seales como stas:
Existe ms de un campo asociado a la clave de la entidad de existencia;
por ejemplo, adems del cdigo y nombre de moneda, el pas de origen y
la conversin a dlares. Es ms que la simple dupla cdigo-traduccin.
La entidad de existencia tiene muchos registros.
Algunos campos de la entidad de existencia tienen alta volatilidad, tal co-
mo un saldo de mercaderas o la renta de un empleado.
La entidad de existencia es un maestro tpico (clientes, artculos, emplea-
dos, proveedores) el cual, probablemente, tambin tiene uso desde otras
aplicaciones.
No obstante, las facilidades de la herramienta y la experiencia del diseador
sern decisivas.
61
De aqu surge la necesidad de tener agrupadas en un slo lugar todas las traducciones sim-
ples, papel que cumple la tabla de traduccin. sta representa una forma de simplificar el
modelo porque tan slo se asigna un nmero para luego hacer una traduccin automtica con
apoyo de una herramienta, la mayora de las cuales provee esta facilidad. En el siguiente pun-
to tratamos este tema.
3. Tabla de traduccin
La tabla de traduccin (T/T) se aplica sobre un campo que requiere traduccin
automtica de un cdigo a un texto. Por ejemplo, el campo cdigo de comuna
tiene asociada una tabla de traduccin con el siguiente contenido:
1 = Santiago Centro
2 = Las Condes
3 = Pudahuel
La tabla de traduccin es una tabla ms en el modelo de datos, el cual contiene
todas las traducciones de cdigos.
Tambin se define el atributo traduccin de cdigo, el cual, dentro de una
entidad desnormalizada, recibe una traduccin de cdigo desde una tabla de
traduccin. Por ejemplo: el nombre traducido de comunas: Santiago Centro,
Las Condes, Pudahuel, La Florida.
El uso de la tabla de traduccin lleva implcita una validacin de existencia y
para efectos de implementacin, es deseable que se presente una ventana con
efecto scrolling62 para buscar y seleccionar con un click el elemento deseado.
El uso eficiente de la T/T est llevando a eliminar las codificaciones simples
en algunas instalaciones, a travs de tomar directamente desde una ventana el
texto correspondiente; por ejemplo: Santiago Centro, Las Condes. Esta natura-
lidad y simplicidad es de mucho mayor beneficio que el eventual costo de usar
un poco ms de espacio en disco.
La base de la tabla de traduccin63 lo constituye una tabla de cdigos (A) con
la siguiente estructura:
A (nmero de tabla, cdigo de tem, texto a traducir, otros campos).
Por ejemplo, con el contenido de la siguiente tabla.
El cdigo 99 se usa aqu para los ttulos de las mismas tablas.
62
El efecto scrolling permite moverse en una tabla desde una ventana en la pantalla del equi-
po. Hacia adelante, atrs, por bloques de registros, etc. A veces se presenta un problema
cuando la tabla de valores es larga, en este caso el scrolling se hace cansador mientras se
busca el valor deseado. Una solucin es que el software provea tambin bsqueda por diferen-
tes conceptos: ndices, palabras claves, fontica, etc
63
Algunos programadores preguntan: cmo se construye manualmente una tabla de traduc-
cin? Respondiendo a su pregunta es que se incluye la tcnica. Adems, le puede ser til a
otras personas. El autor us este esquema desde fines de los setenta con bastante xito.
234 JUAN BRAVO C.
La tabla, ms un programa simple de mantencin, diversos informes y un

formato predefinido para usar la tabla desde mltiples aplicaciones, hacen
muy fcil la mantencin de los cdigos de la instalacin.
Cabe destacar que con la introduccin de la lista de valores posibles como una
caracterstica ms del campo y manejada en forma automtica con herramien-
tas de productividad, la tabla de traduccin tiende a desaparecer.
Nme ro Cdigo Te xto a

de tabla de tem traducir
1 1 Santiago
1 2 Valparaso
1 3 Via del Mar
1 4 Quilpu
2 1 azul
2 2 rojo
2 3 verde

99 1 Ciudades
99 2 Colores
4.3. ENFOQUE DE BASES DE DATOS
Se incluye esta seccin debido a las referencias que se hacen en el texto a ma-
terias propias del enfoque de bases de datos, un tema ms especializado y di-
rectamente relacionado con el modelamiento de datos.
Veremos:
1. Arquitectura de sistemas de bases de datos
2. Estructura relacional
3. Visin de bases de datos
4. Elementos del enfoque de bases de datos
1. Arquitectura de sistemas de bases de datos

Una arquitectura de sistemas de bases de datos se muestra en la figura 4-6.
Nivel interno Nivel conceptual Nivel externo
Visin de
Mtodos de Modelo de datos Usuario A
acceso a los completo de la
archivos fsicos base de datos Visin de
Usuario B
Figura 4-6. Arquitectura de bases de datos
Hay tres niveles de modelamiento de bases de datos:

Interno: se refiere a los mtodos para acceder a los datos almacenados en
los respectivos tipos de archivos que provee el sistema operativo.
Conceptual: es el modelo completo donde se relacionan todas las entidades
de la base de datos. Aqu quedan predefinidos todos los recorridos posibles
para acceder a la informacin. Por ejemplo: los colaboradores con sus car-
gas, instituciones previsionales, proyectos en los cuales trabaja, renta o de-
partamento donde labora.
Externo: tambin llamado vista, son subconjuntos del modelo conceptual
que prepara el administrador del sistema para los usuarios que lo soliciten.
Es como una ventana del modelo conceptual; por ejemplo, tal vez requie-
ra preparar al usuario del departamento de personas una vista con: nom-
bre del empleado, proyectos en que labora y departamento al cual pertene-
ce, sin incluir la renta ni el nmero de cargas.
236 JUAN BRAVO C.
Las estructuras de bases de datos son tres: jerrquica, redes y relacional.

Estructura jerrquica: esta estructura representa una relacin uno a mu-
chos. Como un padre con sus hijos o un cliente con sus ventas. A veces,
con la estructura jerrquica es posible simular relaciones de muchos a mu-
chos a travs de crear una nueva relacin (por ejemplo: ventas-artculos y
artculos-ventas) o siguiendo las instrucciones de la herramienta particular.
Estructura de red: esta estructura representa una relacin de muchos a mu-
chos. Por ejemplo, entre facturas y artculos, porque pueden haber varios
artculos en una factura y un artculo puede estar presente en muchas factu-
ras. Esto es conceptualmente equivalente a tener dos jerarquas: ventas-
artculos y artculos-ventas. Para su implementacin, la red requiere de
software complejo, especialmente cuando se maneja el enlace entre las dos
entidades como una subestructura que tiene otros atributos. Por ejemplo, el
precio de cada artculo en una relacin proveedoresartculos.
Estructura relacional: en 1970, trabajando para IBM, el doctor Edgar F.
Codd public el artculo A relational model of data for large shared data
banks (Un modelo de datos relacional para grandes bancos de datos com-
partidos ) que dio inicio a esta novedosa forma de describir los datos y sus
relaciones. Desde entonces, el Dr. Codd ha sido considerado el padre del
esquema relacional, el cual consiste en una visin natural de los datos con
un estilo tabular de anotacin, lo cual facilita la participacin del usuario,
quien da su descripcin de la informacin que maneja.
Entonces, el nivel interno podra organizarse segn una estructura de redes y
los niveles conceptual y externo segn el esquema relacional. Se aprecia que
cada nivel utiliza la estructura ms apropiada a sus fines.
En consideracin a la importancia de la estructura relacional, en el siguiente
punto profundizamos en sus principios.
2. Estructura relacional
Las estructuras jerrquicas y redes permiten resolver los problemas ms im-
portantes de las bases de datos: redundancia, integracin de datos e indepen-
dencia de los datos versus las aplicaciones; sin embargo, queda un sabor algo
amargo cuando se aplican estas estructuras no lineales, porque se extraan las
simples tablas planas, aquellas entidades individuales, aisladas, sin normaliza-
cin y en muchos casos redundantes. Tal vez el ideal sera tener las posibili-
dades de las bases de datos no relacionales pero con la simplicidad de los ar-
chivos lineales. Esto es lo que se trata de lograr con la estructura relacional.
En el enfoque relacional, tal como su nombre lo indica, se relacionan algu-

nas tablas con otras en base a campos presentes en las mismas tablas. Esto
significa, entre otras cosas, que la relacin muchos a muchos no se acepta en
forma directa, por lo que debe ser resuelta a travs de tablas intermedias.
Algunas denominaciones usadas en el enfoque relacional son:
Relacin o tabla : equivalente a entidad o archivo.
Tupla : equivalente a registro.
Atributo : equivalente a campo.
Dominio : conjunto de datos de un atributo.
En el enfoque relacional se aplican las formas normales propuestas por el Dr.
Codd, siendo generalmente aceptado que la mayor parte del modelamiento de
datos se resuelve con el uso de las tres primeras de ellas.
El esquema relacional predomina actualmente en el ambiente de bases de da-
tos porque tiene una slida base conceptual y terica, con muchos elementos
extrados de la teora de conjuntos y del lgebra relacional, especialmente las
operaciones destinadas a la consulta de datos: seleccin, proyeccin, unin,
interseccin y otras.
De aqu deriva el conocido esquema Entidad-Relacin ER. En ste no hay
tablas de ndices que enlacen las tablas porque siempre los datos que requiere
la relacin estn presentes en las tablas. Por este motivo se usa la entidad aso-
ciativa cuando hay relaciones muchos a muchos.
Especial mencin merece la extraccin de datos desde una relacin. La idea es
que con los comandos que provee el sistema administrador de la base de datos
sea posible extraer datos desde una o varias tablas; en forma horizontal, verti-
cal o en una combinacin de ambas.
Por ejemplo, en una relacin con los atributos: nmero de factura, fecha y
nombre de proveedor se pueden realizar operaciones como estas:
Extraccin horizontal, consiste en seleccionar una tupla; por ejemplo, la
factura 1518 del 10/01/95 de LINHOGAR LTDA.
Extraccin vertical, significa obtener, por ejemplo, todos los nombres de
los proveedores.
Una combinacin podra ser: extraer las tuplas con nmero de factura del
1.000 al 2.000 de los proveedores ubicados en la ciudad de Santiago en
este caso, la herramienta debera buscar en dos tablas.
Actualmente, stas y muchas otras consultas bastante ms refinadas, se efect-
an principalmente con productos tipo SQL (Structured Query Language).
238 JUAN BRAVO C.
3. Visin de bases de datos

La visin de bases de datos se origina en la necesidad de administrar los datos
de manera uniforme y como un recurso ms de la organizacin. De aqu sur-
gen las principales caractersticas del enfoque de bases de datos:
Manejo de la redundancia: significa que cada dato, por ejemplo el nombre
y el saldo de crdito del seor Prez, se incorpora al modelo conceptual y
queda almacenado una sola vez en las bases de datos. Le creera usted al
sistema si el saldo de crdito del Sr. Prez aparece en dos lugares a la vez y
con diferente contenido? Puede existir la redundancia controlada, es decir,
copias de datos para algn uso especfico, que son borrados cuando cum-
plieron su misin. La eliminacin de la redundancia es una de las principa-
les razones para realizar el proceso de normalizacin de datos, presentado
en el captulo tercero.
Integridad referencial: significa que cada dato de la base est siempre con-
sistente. El trmino se aplica cuando algunos datos son consecuencia, re-
sultado o estn relacionados con otros, como una sumatoria o la manten-
cin de un ndice de un dato original. Algunos ejemplos:
Modificar automticamente el campo total neto de la factura cada
vez que vare un tem de la factura.
Validar la existencia del producto cuando se incluye en una factura.
Readecuar automticamente el modelo de datos despus de agregar
o eliminar campos.
Proteccin de la informacin: se refiere a los conceptos de seguridad, inte-
gridad y recuperacin, tratados en el captulo 2. Veamos un resumen:
Seguridad: incluye la privacidad de datos, el anlisis de procedi-
mientos y errores en el diseo.
Integridad: es asegurar la consistencia de los datos en todo momen-
to y protegerlos contra invalidaciones accidentales o deliberadas.
Recuperacin: son las precauciones a tomar frente a cadas del
sistema, bsicamente en lo que se refiere a reiniciacin, reconstruc-
cin y respaldos.
Auditora: el software debera permitir efectuar totalizaciones, cuadraturas,
referencias cruzadas y otros procesos destinados a apoyar puntos de control
y eventuales revisiones, adems de proveer los mecanismos para seguir la
ruta de auditora. sta consiste en reconstruir la secuencia de transacciones
que afectaron a un determinado dato, generalmente a travs de una bitcora

de procesos.
Concurrencia: el sistema administrador de bases de datos debe incluir el
manejo de colisiones en una aplicacin con mltiples usuarios, situacin
que se produce cuando dos o ms usuarios intentan actualizar simultnea-
mente el mismo registro. Son varias las soluciones para este tipo de pro-
blemas; por ejemplo, el que toma primero el registro deja al otro esperando
hasta que lo actualiza.
Independencia de datos: es clsica la caracterstica de independencia entre
datos y aplicaciones. Significa separar el almacenamiento de los datos de
las caractersticas de una aplicacin particular. Un ejemplo elemental de
prdida de independencia, vlido incluso en ambientes sin base de datos, es
cuando se incorporan en un programa tablas con datos que slo existen en
ese programa y no pueden ser accesadas ni siquiera desde otro programa.
A veces, la consistencia de la base de datos se ve afectada por cdigo que
acta directamente sobre los datos. Esto se ha intentado resolver haciendo
que cada sistema administrador de bases de datos tenga su propio lenguaje
de alto nivel o utilizando un preprocesador para lenguajes husped, tipo
COBOL o C. Desde stos se puede usar el conjunto de instrucciones de
manipulacin de datos propios del sistema administrador de la base de da-
tos o de la norma SQL.
La idea es que los datos pertenecen a toda la organizacin y no a una apli-
cacin particular. Bajo este concepto, una aplicacin no modifica directa-
mente los datos, sino que lo hace un intermediario comn a todas las apli-
caciones: el sistema administrador de la base de datos a travs de los me-
canismos que tenga disponibles.
Normalizacin del almacenamiento: significa que el almacenamiento y la
seleccin de los datos de la organizacin siguen las mismas pautas; por
ejemplo, para:
Definicin: tipo de campo, largo, descripcin, etc.
Documentacin: en informes o ayudas en lnea.
Estructurar los campos de las entidades de manera uniforme: por
ejemplo, aplicando hasta la tercera forma normal del modelo del Dr.
Codd o la normalizacin simplificada de este texto.
As se obtiene una mnima repeticin de definiciones. Adems, con la
normalizacin del almacenamiento podemos aplicar funciones genricas
240 JUAN BRAVO C.
sobre los datos, para consulta, ingreso, modificacin, eliminacin y otras,

que todo sistema administrador de bases de datos provee.
Manejo de Bases de Datos distribuidas: significa que varias bases de datos
se ven como una sola. Es muy til cuando desde una aplicacin se re-
quiere ubicar informacin que est en bases de datos ubicadas en diferentes
equipos.
Manejo de Bases de Datos remotas: significa manejar datos que se encuen-
tran en bases muy distantes. Esta caracterstica es cada vez ms indispensa-
ble y tiene varias consecuencias: implica resolver el problema de la comu-
nicacin remota y conocer el mundo de los satlites, controladores o lneas
dedicadas.
4. Elementos del enfoque de bases de datos

Los principales elementos del enfoque de bases de datos se muestran en la
figura 4-7, con las abreviaturas en ingls por ser de uso generalizado.
DBA = Data Base Administrator. Administrador de la base de datos.
DBMS = Data Base Management System. Sistema administrador de bases de datos
(SABD).
DD = Data Dictionary. Diccionario de datos.
DB = Data Base. Bases de datos.
DDL = Data Definition Language. Lenguaje de definicin de datos.
DML = Data Manipulation Language. Lenguaje de manipulacin de datos.
SQL = Structured Query Languaje. Lenguaje de consultas estructuradas.
DBA
Lenguajes
DDL
DML DBMS DD
SQL
DB DB DB
Figura 4-7. Enfoque de bases de datos

A continuacin veremos cada uno de lo elementos de este enfoque.

Administrador de la Base de Datos. Data Base Administrator (DBA), co-
rresponde a una funcin administrativa encargada, entre otras, de las si-
guientes actividades:
Disear la base de datos
Definir los metadatos (atributos estticos y funcionales de datos)
Proteger la base de datos
En suma, de todas las actividades tendientes a optimizar el uso del recurso
informacin.
Esta funcin puede ser desempeada por una o varias personas, quienes
pueden apoyarse en herramientas de software para lograr sus objetivos.
Sistema administrador de bases de datos (SABD). Data Base Management
System (DBMS), es el software administrador de la base y del diccionario de
datos. Posee mltiples funciones, por ejemplo:
Manejar la integridad, privacidad y recuperacin
Accesar los datos
Mantener los ndices y el diccionario de datos
Proveer funcionalidad bsica a los conjuntos de datos
Para cumplir con su funcin se relaciona con el usuario a travs de los dife-
rentes lenguajes que provee.
Diccionario de Datos. Data Dictionary (DD), es un archivo reservado del
SABD donde se almacenan las caractersticas de los datos, o los metadatos
de la organizacin. Por ejemplo, por cada campo se archiva: nombre, des-
cripcin, tipo de dato, largo, condiciones de validacin, ayudas en lnea o
documentacin. En el DD tambin se graban las relaciones entre los datos.
El diccionario de datos evoluciona hacia el diccionario de conocimientos,
tambin llamado enciclopedia o repositorio. En ste, adems de almacenar-
se las caractersticas de los datos y sus relaciones, tambin se agregan ca-
ractersticas lgicas, formatos predefinidos, cdigo reutilizable y en espe-
cial, reglas de ejecucin, las que se activan al momento de producirse un
error o al cumplirse alguna condicin; por ejemplo, generar una orden de
reposicin cuando el stock de un producto llegue a su nivel mnimo.
Bases de Datos. Data Base (DB), es el conjunto de tablas (archivos fsicos)
donde se almacenan los datos de la organizacin. Slo puede ser accesado
segn los mtodos del SABD.
242 JUAN BRAVO C.
Lenguajes. Son los lenguajes del SABD que permiten al usuario interactuar
con la base de datos o el diccionario de datos.
Algunos SABD poseen un lenguaje que cumple con todas las funciones; en
otros, existen explcitamente estos tres:
Lenguaje de definicin de datos: Data Definition Language (DDL),
permite mantener las definiciones y estructuras de datos almacena-
das en el diccionario de datos.
Lenguaje de manipulacin de datos: Data Manipulation Language
(DML), utilizado para actualizar los datos de la base: agregando, mo-
dificando o eliminando registros.
Lenguaje de consulta: Query Language, permite realizar consultas
sobre la base de datos, por ejemplo, las ventas del cliente Juan
Prez o los artculos ms vendidos en el ltimo mes. A travs de es-
te lenguaje se puede hacer un recorrido o una navegacin autom-
tica dentro de la base de datos, siguiendo camino de las relaciones
predefinidas para dar respuesta al requerimiento. Cuando se trabaja
con bases de datos relacionales, se usa el principalmente el lenguaje
SQL Structured Query Languaje basado en el lgebra y clculo
relacional propuestos por el doctor Codd.
Es importante la armona entre buenas herramientas por ejemplo, para ad-
ministrar bases de datos, desarrollar sistemas computacionales o consultar
datos y todos los dems factores de productividad: mtodo, incorporacin
del usuario, excelente preparacin del profesional de informtica, mtodos de
trabajo normalizados, hardware adecuado, normalizacin externa y los facto-
res de contexto: colaboracin o ambiente fsico.
Slo el desarrollo equilibrado del conjunto de factores ms que el avance
espectacular en alguno de ellos permitir lograr los objetivos de productivi-
dad que las organizaciones requieren.
CAPTULO 5.
ORIENTACIN A OBJETOS
244 JUAN BRAVO C.
Captulo 5. Orientacin a objetos
En los ltimos aos, el desarrollo ms significativo en ingeniera

del software ha sido la aparicin de UML como estndar para la
descripcin de sistemas orientados a objetos, y el desarrollo de
mtodos giles como la programacin extrema.
Sommerville (2005, p. xiv)
La orientacin a objetos (OO) provee una forma simple y natural para crear
los modelos de la solucin de software. Los objetivos que se pretenden lograr
son ambiciosos: aumentar la productividad, mejorar la calidad, facilitar la
mantencin, incorporar al usuario, reducir los riesgos y reutilizar el trabajo
previo, entre otros. Cabe destacar dos caractersticas: la mayor naturalidad y el
aporte a los contenidos a travs de una biblioteca de clases que se va perfec-
cionando en el tiempo.
Esta es la quinta competencia considerada para apoyar la elaboracin de
necesario que el analista sea muy hbil en la orientacin a objetos como par-
te de su responsabilidad profesional, porque es una competencia central de su
labor que tiene un impacto mucho ms all de las etapas de anlisis y diseo,
tiene que ver con la visin de trabajar con integracin y componentes.
CAPTULO 6. UML
Con la orientacin a objetos es posible que la solucin de un desarrollador sea

comprendida ms fcilmente por otros, obtenindose mayor independencia del
modelo respecto a su creador; as, la empresa usuaria se beneficia doblemente,
porque no se repiten soluciones a los mismos problemas y porque hay una

inversin en inteligencia al ser posible que nuevos especialistas aprovechen
todo o parte del avance de sus predecesores, ms aun cuando el diseo queda
registrado en alguna herramienta de apoyo para esta etapa.
En este libro se aborda la orientacin a objetos desde el punto de vista del
desarrollo de las aplicaciones computacionales que apoyarn el negocio de la
organizacin.
Veremos:
Fundamentos de la orientacin a objetos
Definiciones sobre orientacin a objetos
Conceptos de la orientacin a objetos
Proceso de generalizacin
Fases de la orientacin a objetos
Incorporacin de la tecnologa de objetos
246 JUAN BRAVO C.
5.1. FUNDAMENTOS DE LA ORIENTACIN A OBJETOS
La Orientacin a Objetos (OO) es un hito fundamental en el proceso de desa-

rrollo de la computacin que comenz en los mismos aos de la Segunda
Guerra Mundial con el advenimiento de los primeros computadores en Ale-
mania y Estados Unidos.
El objetivo de esta evolucin histrica ha sido el aumento de productividad.
Lo cual se logra en esta tcnica mediante tres formas principales:
Evitando la redundancia en la construccin de cdigo
Reutilizando estructuras y cdigo
Aplicando visin sistmica (visin de conjunto y autonoma)
Al principio de la informtica, las aplicaciones prcticamente no tenan diseo
y luego surgieron diversas formas ms bien locales y artesanales. En los aos
60 surgi lo que conocemos como diseo fsico o esquema tradicional de di-
seo. Hacia fines de esa dcada ya existan algunas formas de diseo estructu-
rado y otras que enfatizan el enfoque de base de datos. La aparicin de la
orientacin a objetos en los aos 80 hereda esos avances previos.
En un artculo en Revista Informtica de principios de los 90, Reutilizacin, el
sueo de la ingeniera de software, Jos Piquer, acadmico del Departamento
de Ciencias de la Computacin, Escuela de Ingeniera de la Universidad de
Chile, ya aconseja a los ingenieros en computacin que comiencen a estudiar
la orientacin a objetos. Seala que la programacin orientada a objetos, prin-
cipalmente va SmallTalk, nos comienza a proveer con algunas herramien-
tas buscadas por largo tiempo: las bibliotecas de clases. Cuntas veces uno
implementa la misma funcin de bsqueda, slo porque el tipo de datos cam-
bia?. Agrega: cada vez aparecen ms bibliotecas comerciales de clases
dedicadas a algunos temas como optimizacin o diseo de interfaces
Al margen de formas artesanales de diseo y de las tcnicas centradas sola-
mente en los datos, el principal mtodo que domin desde los aos 60 es el
diseo estructurado.
Considerando que hemos reconocido a Edward Yourdon como uno de los
padres de este esquema, no requiere de mayores comentarios mencionar que
en la dcada de los noventa l promovi la orientacin a objetos, mante-
niendo slo un diseo estructurado mejorado para quienes conservaban esa
tecnologa en sus instalaciones o se incorporaban tardamente.
La orientacin a objetos es muy amplia y permite modelar realidades de dife-

rente ndole, como textos, imgenes, voces, figuras geomtricas y mucho ms.
Cabe indicar que la programacin orientada al objeto fue la precursora de los
conceptos de OO a travs de lenguajes tales como C++, SMALLTALK y SIMULA.
Veremos:
1. Mayor eficiencia
2. Visin de los datos
3. Visin histrica funcional
4. La orientacin a objetos
5. Incorporacin de nuevas tecnologas
1. Mayor eficiencia
Una fuerte justificacin de la orientacin a objetos es su mayor eficiencia. De
hecho, la cantidad potencial de funciones es n en el esquema estructurado y n
en la orientacin a objetos, tal como vemos en la figura 5-1.
Esquema estructurado Objetos

9 funciones (n2) 3 funciones (n)
M1 Operacin 10
M1
T1 M2 Operacin 11
Mensaje 10
Operacin 10
M3 Operacin 12
M1 Operacin 10
M2
T2 M2 Operacin 11
Mensaje 11
Operacin 11
M3 Operacin 12
M1 Operacin 10
M3
T3 M2 Operacin 11
Mensaje 12
Operacin 12
M3 Operacin 12
Mi = Maestro; Ti = Transaccin
Figura 5-1. Interacciones entre objetos

248 JUAN BRAVO C.
La cantidad de interacciones funcionales entre los componentes disminuye

notablemente respecto a otros mtodos, debido a la estructura de objetos inde-
pendientes que se comunican entre s a travs de mensajes, tal como se mues-
tra en la figura 5-1. Se puede comparar con la realidad de las empresas, donde
a veces se logra mayor productividad eliminando interacciones innecesarias
entre los departamentos.
La disminucin en el nmero de funciones se debe a la caracterstica de en-
capsulamiento del objeto, donde slo es posible afectar una variable con una
operacin que se activa a travs de un solo tipo de mensaje. Suponiendo que
cada maestro es afectado de la misma forma por cada uno de los repositorios
de datos de transacciones, en el esquema estructurado se requieren 9 funcio-
nes, producto de las tres tablas de transacciones que actualizan a 3 tablas ma-
estras. Frente a la misma situacin, en la OO tan slo se requieren 3 funcio-
nes, una por cada objeto. Cada una de ellas sera activada tres veces, una vez
por cada objeto de transaccin.
Para entender mejor la disminucin en la complejidad de las relaciones fun-
cionales y el notable aumento de productividad que genera, veremos en el
siguiente punto la evolucin que han seguido los modelos de soluciones de
software.
2. Visin de los datos

La visin de los datos que surgi en los aos 60 buscaba tener todos los datos
puros de la organizacin de forma centralizada. As se origin el enfoque de
bases de datos que vimos en el captulo 4.
En este esquema los datos no deben actualizarse, sino que se mantienen los
valores originales.
Para satisfacer las necesidades de informacin de la empresa, no es necesario
construir un sistema computacional porque todo se obtiene realizando consul-
tas sobre la base de datos, con la ayuda de un sistema administrador de bases
de datos.
Por ejemplo, se requiere obtener el saldo de inventario de un producto. En
lugar de acceder a un campo stock, el cual no est permitido en el enfoque
de los datos porque es un resultado, se hace una consulta a la base de datos
buscando todo el movimiento del producto, se suman las entradas y se restan
las salidas.
Hasta fines de la primera dcada del 2000, todava la capacidad de procesa-
miento no lo permite en forma eficiente.
3. Visin histrica funcional

Durante muchos aos y tal vez masivamente hasta la dcada del 90, la forma
tradicional de desarrollar era a travs de un diseo fsico que culminaba en un
diagrama de procesos, mediante el cual se graficaban los programas y reposi-
torios de datos del sistema. En gran medida, el objetivo de esta lnea de diseo
era la optimizacin de recursos del equipo, en particular, minimizar el alma-
cenamiento y el tiempo de uso de procesador.
Tpicamente, cada programa incorporaba muchos archivos, tal como se mues-
tra en la figura 5-2 para un programa de actualizacin, uno de los ms vitales
de todo sistema. En este ejemplo, los archivos64 de transacciones: ventas,
compras y mermas del da, actualizan a los maestros de artculos, cuentas con-
tables y totales de transacciones; por eso la doble flecha en esos archivos ma-
estros.
La construccin de un programa como el de la figura 5-2 significaba, cuando
menos, algunas semanas de trabajo de un buen programador, probablemente
escribiendo varios miles de instrucciones en algn lenguaje de alto nivel: Co-
bol, Clipper, RPG, C u otro.
Ventas Artculos
Actualizacin Cuentas
Compras
diaria contables
Mermas Totales
Figura 5-2. Esquema tradicional de diseo
En esta visin funcional la mantencin se vea dificultada por la extensin del

programa. Era frecuente observar que una pequea modificacin significaba
varios das de trabajo. En este entorno, se calculaba que la mantencin con-
suma 5 veces ms tiempo y recursos que la construccin. De hecho, era fre-
cuente que las instalaciones llegaran a su lmite de saturacin, manteniendo
64
Se conserv la palabra archivo que se usaba en este esquema para referirse a los conjun-
tos de datos.
250 JUAN BRAVO C.
solamente lo urgente, ni siquiera lo importante. Prcticamente no se constru-

an nuevas aplicaciones.
Ni siquiera ayudaba que el mismo constructor hiciera la mantencin, porque al
poco tiempo olvidaba las sutilezas del programa. Tampoco ayudaba la pro-
gramacin estructurada, porque fue utilizada en pocas instalaciones y de modo
tan informal, que generalmente se transformaba en una receta de no usar la
instruccin go to a toda costa65.
Descomposicin funcional
Luego, aprendimos a hacer descomposicin funcional. En muchos casos, a
travs del modelamiento de funciones que se investigaba por esos das. En
otros, de la mano del diseo estructurado.
La idea de la descomposicin funcional es ubicar las funciones computaciona-
les atmicas sin mezclarlas dentro de un programa. Por ejemplo, el programa
de actualizacin de la figura 5-2 quedara como el esquema estructurado de la
figura 5-1, convertido en 9 funciones similares entre s, de tal forma que cons-
truyendo la primera, las siguientes se copian y adaptan. Bajo este esquema, el
tiempo de construccin de los pequeos programas de la figura 5-2 probable-
mente no exceda de dos das y la mantencin se simplifique tanto que tal vez
quede tiempo para nuevos desarrollos.
Sin embargo, hay algunos inconvenientes. Por ejemplo, cuando se modifica
un campo de una entidad, hay que buscar en muchas funciones para corregir
todas las rutinas que afectan a ese campo. Otro problema es la serie de incon-
sistencias que se generan cuando no se modifican todas las funciones debidas.
Adems, cuesta manejar un exceso de pequeas funciones a veces muy pare-
cidas entre ellas, tal como vemos en la figura 5-3.
65
El autor trabaj en instalaciones donde la programacin estructurada estaba vedada, porque
haban tenido muchas malas experiencias de programas innecesariamente extensos y en ex-
tremo complejos. El argumento en defensa de la programacin estructurada era que no haba
sido comprendida por el programador y estaba mal aplicada en el programa.
La recomendacin en esos das (y todava en ciertos mbitos) es que era preferible tener mu-
chos programas pequeos y si eso no era posible, usar la programacin estructurada aplicn-
dola correctamente. Lo cual no era tan fcil porque era bastante difcil de aprender.
En el libro Desarrollo de sistemas de informacin, una visin prctica se describen los prin-
cipios de la programacin estructurada.
1 3
Ventas Artculos Mermas
Actualizar Actualizar
stock stock
Figura 5-3. Ejemplo de relaciones funcionales estructuradas
En el ejemplo de la figura 5-3 se definieron dos procesos de actualizacin

sobre el maestro de artculos: desde ventas y desde mermas. Ambas son fun-
ciones atmicas y estn bien definidas. Aunque, si observamos detenidamente,
apreciaremos que ambas funciones hacen lo mismo: restar el stock. Entonces,
por qu repetirlas?
4. La orientacin a objetos
Con la orientacin a objetos se evita repetir cdigo, porque la funcin restar
stock se define una sola vez y pasa a ser parte del objeto artculos. De esta
manera, cuando se requiera ocuparla, ya sea por ventas, mermas, ajustes de
salida o devolucin de compras, se activa con un mensaje, el cual tiene como
parmetros el cdigo del producto y la cantidad que se restar.
Entonces, el ejemplo de la figura anterior quedara como se muestra en la fi-
gura 5-4. En este caso, la funcin puede ser activada desde los objetos ventas
y mermas a travs del mensaje 1 (su estructura es: cdigo, cantidad).
Artculos
Cdigo
Ventas Descripcin Mermas
Mensaje 1 Stock Mensaje 1
1.- Restar stock
Figura 5-4. Ejemplo de orientacin a objetos
El gran avance es el encapsulamiento, donde los datos y las funciones estn

indisolublemente unidos.
252 JUAN BRAVO C.
Tal como vimos en la introduccin del captulo, la orientacin a objetos nos

provee de otro concepto vital: la generalizacin. Es la posibilidad de acercar-
nos a la forma natural del aprendizaje: el proceso cognitivo del ser humano.
A travs de esta breve sntesis histrica pudimos apreciar la evolucin del
concepto de diseo durante los ltimos 20 aos, destacando las ventajas de la
orientacin a objetos.
5. Incorporacin de nuevas tecnologas

Es de conocimiento general que la incorporacin de nuevas tecnologas sigue
la curva que se presenta en la figura 5-5.
Ciclo de tiempo de incorporacin a la tecnologa

OO
Cantidad de UML
organizaciones que
adoptan la tecnologa
DE
Tiempo
Figura 5-5. Grfico de incorporacin de nuevas tecnologas
La incorporacin de nuevos entrantes es muy lenta al principio, luego se pro-

duce una fuerte aceleracin hasta llegar a un alto nivel de entrada de nuevas
organizaciones que la adoptan. Finalmente, cuando la tecnologa est total-
mente consolidada y hay mucha experiencia, se incorpora una menor cantidad
de usuarios, los ms escpticos, justamente cuando una nueva tecnologa est
naciendo.
El diseo estructurado se encontrara hoy (2008) prcticamente sin nuevos
entrantes, ms o menos en el punto (DE) sealado en la figura 5-5. A su vez,
la orientacin a objetos se encontrara en la cspide de su madurez y UML
(que veremos en el captulo 7) estara en la fase de incorporacin acelerada de
nuevos entrantes.
Algunos argumentos pueden ser esclarecedores respecto al xito de la orienta-

cin a objetos:
Business Week catalog a la tecnologa de objetos como la ms grande
invencin despus del fuego. Sin duda una apreciacin exagerada, pero
sintomtica respecto a los sentimientos que provoca.
Ms del 75% de las empresas Fortune 100, la est usando o probando.
Estadsticas de 1993 indican que en EE.UU. se estaba utilizando en el
11,9% de los proyectos, en comparacin a un 3,8% en 1991. Hacia fines de
la primera dcada del 2000 ms del 70% de aplicaciones la usa de una u
otra forma.
La orientacin a objetos es una tecnologa joven que comenz a mediados de
los 80 con un fenmeno muy curioso: naci en cientos de lugares a la vez:
Japn, Europa, USA, Chile y otros pases. Tena diferentes nombres y muchas
variaciones, aunque con los mismos objetivos66. Por qu se produjo este
fenmeno? Porque era una necesidad de mercado. El mtodo tradicional y las
tcnicas estructuradas haban sido sobrepasadas por la realidad y por el cam-
bio en la computacin.
Fundacin de la OMG
Es tan amplia la OO que unas 200 compaas del rea TI formaron en los aos
80 el grupo de administracin de objetos ms conocido por sus siglas en
ingls: OMG (Object Management Group). Integran este grupo las princi-
pales empresas de computacin a nivel mundial: IBM, Unisys, NCR y otras.
En forma resumida, el OMG tiene por misin:
Maximizar la portabilidad y la reutilizacin del software.
Crear una arquitectura de referencia, con trminos y definiciones en los
cuales basar todas las especificaciones.
Ofrecer un foro abierto para el anlisis, la educacin y la promocin de la
tecnologa de orientacin a objetos.
En 1994, la OMG encarg el desarrollo de un lenguaje de modelamiento ba-
sado en la orientacin a objetos, as surgi UML en 1997.
66
Hacia fines de la dcada de los 80 el autor se encontraba trabajando en el modelamiento de
datos y funciones, donde reuna en un solo todo la estructura y la funcionalidad asociada a una
entidad, trabajaba en reutilizacin de cdigo y experimentaba con herramientas CASE como
una forma de agilizar el desarrollo de sistemas computacionales. Una vez que supo de la exis-
tencia de la tecnologa de objetos, adapt toda su investigacin a ella.
254 JUAN BRAVO C.
Hacia el 2008, la OMG tiene varios cientos de miembros y sus productos son
estndares de hecho, tal como CORBA, MDA, UML, APIs y otros.
Nuevo enfoque, nuevas soluciones

Es posible que muchos problemas tengan soluciones muy simples al observar-
los con un nuevo enfoque, distinto a la visin permitida por las estructuras
tradicionales de archivos planos y programas asociados, porque slo se ha
apreciado una pequea porcin de la realidad, dejndose de lado la imagen
real que percibe el usuario: objetos vivos, textos, formas tridimensionales,
fotografas o conjuntos de datos con estructuracin libre.
Con la tecnologa de objetos podemos ver a la organizacin de forma ms
simple, natural y real.
5.2. DEFINICIONES SOBRE ORIENTACIN A OBJETOS
Precisaremos aqu los conceptos bsicos de la OO y algunos trminos asocia-

dos del modelamiento de datos y funciones.
Veremos:
1. Definiciones preliminares
2. Convenciones de diseo
3. Relacin de pertenencia
4. Condicin de existencia
1. Definiciones preliminares
El juego de denominaciones tiene como base la figura 5-6, donde se aprecia
que las clases y objetos se componen de atributos y funciones. Tambin se
observa que las ocurrencias de una clase son los objetos y que las ocurren-
cias de un objeto son las instancias. Son conceptos recursivos y que dependen
del contexto. En cierto contexto un objeto puede ser visto como una clase y en
otro como un objeto.
Clase Objetos
Personas Avales
Rut Objeto
Nombre Ventas
Direccin N documento
Ingresar Clientes C/E
Rut
Eliminar
Imprimir Ingresar
eliminar
Instancias de clientes:
Juan Prez, Alberto Torres
Figura 5-6. Nomenclatura de la orientacin a objetos
Ntese en la figura 5-6 que la representacin grfica de los objetos es con una
doble lnea y la de las clases es con una sola lnea, tal como lo propone Ed-
ward Yourdon. Veremos que en los diagramas finales de diseo hay solamen-
te clases, por lo tanto, se justifica una representacin ms simple para ellas. El
punto () seala que el campo es llave principal. El campo Rut es un nmero
identificador de personas y empresas en Chile.
256 JUAN BRAVO C.
Definiciones de la OO:
Atributo: es equivalente a campo. Por ejemplo: el campo fecha con sus
procedimientos de cambio de da, mes y ao, traduccin del nombre del da
y del mes, diferentes formatos (AAAA/MM/DD o DD/MM/AAAA), etc Un
atributo posee caractersticas estticas y funcionales, tal como vimos en el
captulo anterior.
Atributo identificatorio: es parte de la clave del objeto.
Atributo referencial: es un atributo que a su vez es llave o parte de la clave
de otro objeto. Tambin se le llama llave externa o llave fornea. Por
ejemplo, el RUT del cliente en el objeto ventas de la figura 5-6.
Clase: es una abstraccin que no tiene una implementacin tecnolgica. Se
aplica a nivel del modelamiento y sirve para identificar y darle sus elemen-
tos a los objetos que de ella derivan; por ejemplo, en la figura 5-6 se apre-
cia que los objetos clientes y avales se derivan de la clase personas y here-
dan de ella sus elementos comunes.
Veremos ms sobre clases en el resto del captulo.
Funcin: es un procedimiento que permite cumplir alguna accin, en la
forma de un programa de computador. Consta en su mayor parte de lgica
generalizada, comn a todas las funciones del mismo tipo y en menor me-
dida, de las reglas de negocio, o lgica que realmente tiene que ver con las
necesidades particulares de la aplicacin. Las funciones permiten dar vi-
da a una estructura esttica. Por ejemplo, actualizar el saldo de un inventa-
rio o imprimir una cartola.
Instancia: es una ocurrencia de los datos reales de cada objeto, equivalente
al registro del diseo tradicional o a la tupla del esquema relacional.
Por ejemplo, cada cliente individual del objeto CLIENTES de la figura 5-6,
los seores Juan Prez y Alberto Torres.
Objeto: Es algo concreto del mundo real que tiene una representacin fsica
en la construccin del sistema. Cada objeto viene a ser una instancia de su
clase. Se define como un conjunto de atributos con funciones indisoluble-
mente asociadas, equivalente a la entidad ms su funcionalidad. A nivel del
diseo, algunos ejemplos de objetos seran: clientes, avales, proveedores,
facturas de venta, notas de devolucin de compras, artculos, etc
Objeto asociativo: generalmente resulta de una relacin tipo red entre dos
objetos, especialmente cuando se agregan atributos propios de la relacin;
por ejemplo, el costo de cada artculo por proveedor en una relacin mu-
chos a muchos entre artculos y proveedores. El objeto asociativo tambin
puede estar asociado a un solo objeto; por ejemplo, parentescos del objeto
personas.
Variable de resultado: puede ser fsica, como un atributo del objeto donde
se guarda el resultado actualizado de alguna operacin, como la valoriza-
cin del saldo segn la frmula saldo x costo de un producto del in-
ventario. Tambin puede ser lgica, como cuando se usa una variable glo-
bal y el clculo se efecta cada vez que se requiera la variable de resultado.
La variable no puede ser parte de la clave cuando es un atributo del objeto.
Variable global: es una variable que no pertenece a ningn objeto, permite
efectuar operaciones aritmticas, pasar parmetros a travs de mensajes,
identificar el estado de los objetos, etc A veces se la identifica con sub-
rayado.
Recursividad: significa que tanto los datos como las funciones son a su vez
clases y objetos en otro nivel de profundidad. Asimismo, lo que declaramos
como clase en un nivel podra ser objeto en otro, esto porque las observa-
ciones se realizan de acuerdo al fin particular de la aplicacin.
Los nombres de clases, objetos y funciones son vitales para lograr claridad en
modelos complejos. Algunas convenciones recomendables son usar sustanti-
vos para clases y objetos, tales como personas, artculos y documentos; y ver-
bos en infinitivo para funciones, tales como restar, sumar e ingresar. Tambin
se sugiere evitar el uso de prefijos y sufijos, con el fin de obtener nombres
fcilmente entendibles y que proporcionen el mximo de informacin.
2. Convenciones de diseo
Algunas convenciones para el diseo pueden ser, por ejemplo:
Validar el dgito verificador de campos que son llave de la entidad cuando
el dato entra por primera vez al sistema. Por ejemplo, al ingresar el RUT al
objeto CLIENTES. Si el campo con dgito verificador se utiliza en otra enti-
dad, por ejemplo, VENTAS, se aplica una condicin de existencia respecto a
la entidad a la cual ingres la primera vez (CLIENTES en el ejemplo) y no se
vuelve a validar el dgito verificador.
Suponer los siguientes largos de campos, salvo indicacin diferente:
258 JUAN BRAVO C.
Valor : numrico largo 9, con signo

Documentos : numrico largo 6
Nombres : alfanumrico largo 30
Direccin : alfanumrico largo 35
Telfono : alfanumrico largo 15
RUT : numrico largo 10, ms dgito verificador
Los conceptos relacin de pertenencia y condicin de existencia, relacionados

con las convenciones de diseo, se definen en los siguientes puntos.
3. Relacin de pertenencia
Una relacin de pertenencia surge de una estructura jerrquica como la que se
muestra en la figura 5-7, en la cual se aprecia la pertenencia de entidades.
Donde B pertenece a A, lo
Entidad A cual da origen a la notacin:
A
Entidad B
Figura 5-7. Relacin de pertenencia
La lnea que une los objetos A y B es ms gruesa, para reflejar lo fuerte de la

relacin; es el caso de un encabezado y su detalle en documentos como una
factura o una nota de devolucin.
La relacin de pertenencia es un caso particular de la relacin uno a muchos
presentada en el captulo anterior. Se agregan las siguientes caractersticas:
Unicidad: significa que todos los objetos son parte de un solo todo; en
consecuencia, los objetos hijo no podran sobrevivir independientemente.
Cada hijo tiene un solo padre. Los hijos se relacionan a travs del padre.
No se puede eliminar un padre si existen hijos y no se puede crear un hijo
si no existe el padre.
Se llega automticamente al hijo pasando por el padre a travs de la rela-

cin de pertenencia.
Para efectos de implementacin, generalmente la informacin del padre se
presenta en forma lineal y la del hijo en forma tabular, tal como se aprecia
en el siguiente diagrama:
Forma lineal
Forma tabular
Algunas convenciones sobre esta relacin son:

Suponemos que existe un traspaso automtico de informacin entre padre e
hijo. Esto significa que si el objeto de detalle no tiene los datos requeridos
para estructurar un mensaje y s estn en el encabezado, se toman autom-
ticamente y viceversa.
Asimismo con las funciones, cualquier funcin del detalle puede ser acti-
vada desde el encabezado y viceversa.
El primer atributo de un detalle es la misma clave de la entidad encabeza-
do, as es que no sera necesario anotarla en el objeto de detalle. Esta dis-
tincin es vital, porque a nivel de la implementacin significa que no es
necesario construir ningn tipo de ndice intermedio, pues todo lo necesa-
rio est contenido en los objetos y en su estructura.
Considerando lo poderoso de la relacin, es conveniente que un mismo dise-
ador sea dueo de todos los objetos sujetos a relaciones de pertenencia.
4. Condicin de existencia
La condicin de existencia (C/E) es una relacin funcional entre objetos, la
cual permite asegurarse de que uno o ms atributos referenciales de un objeto
260 JUAN BRAVO C.
origen, con los cuales se forma la clave de un objeto destino, existan en ste.
Por ejemplo, en la figura 5-6 el objeto origen es Ventas, el destino es Clientes
y el atributo referencial es el RUT, el cual es la clave del objeto destino.
La condicin de existencia es una validacin que sigue, ms o menos, la si-
guiente lgica:
Existe la instancia en el objeto destino? (por ejemplo, un cliente)
SI. Accin de desplegar algo y aviso OK.
NO. Ofrecer tres alternativas a eleccin del usuario:
1. Buscar en una ventana la instancia deseada.
2. Crear la instancia en el objeto destino desde una ventana en el
objeto origen.
3. Rechazar el campo en el objeto origen.
Generalmente este tipo de lgica viene provista en forma automtica por sis-
temas administradores de bases de datos y herramientas de productividad. Es
tambin una posibilidad mantenerla como una clase o rutina reutilizable.
5.3. CONCEPTOS DE LA ORIENTACIN A OBJETOS
Los conceptos de la orientacin a objetos aplican en las etapas de anlisis,

diseo e implementacin del mtodo GSP.
Veremos:
1. Encapsulamiento
2. Clase
3. Objeto
4. Funcin
5. Identidad de instancias de objetos
6. Mensaje
7. Independencia
8. Enfoque sistmico
1. Encapsulamiento
El encapsulamiento significa incluir en un solo todo, llamado objeto, los datos
y las funciones que afectan esos datos; por ejemplo, una tabla de artculos con
todas las funciones necesarias para extraer y actualizar sus datos. De esta for-
ma, si otro objeto requiere algo, por ejemplo, el historial de un artculo, se lo
pide al objeto artculos, el cual responder de acuerdo con sus funciones in-
corporadas. Se parece al funcionamiento de una clula, la cual recibe mensa-
jes del exterior y reacciona proporcionando los productos correspondientes,
cmo lo hace? Eso es parte de sus funciones incorporadas67.
67
Alfred Gilman, ganador junto con Martin Rodbell del Premio Nobel de Medicina 1994
nos dice que la clula es una verdadera maravilla en miniatura: contiene en su ncleo toda la
informacin gentica y vive, por as decirlo, su propia vida: recibe sustancias desde el exte-
rior, las transforma para conseguir energa, arroja fuera los desechos, fabrica los componentes
que el organismo necesita y los exporta al lugar apropiado. Ella necesita saber qu tipos de
molculas se encuentran a su alrededor para dejarlas entrar o cerrarles el paso. Necesita sa-
ber qu hacer con el material que entra. Tambin necesita conocer el estado del organismo,
para actuar en consecuencia. Se trata de todo un mundo fascinante que funciona a base de
informacin. Y ah desempean un papel importante las protenas G. Con el tiempo, se
sabr cmo se relacionan entre s las docenas de receptores, protenas G y electores diversos.
Y podr predecirse cmo reaccionarn las clulas en respuesta a cualquier combinacin de
seales.
262 JUAN BRAVO C.
Otro ejemplo, el objeto clientes, el cual adems de una estructura de campos

(nombre, direccin, fecha de nacimiento y otras) tiene una cantidad de funcio-
nes incorporadas, tales como: enviar mensajes de e-mail para el cumpleaos,
obtener saldo de crdito, agregar o eliminar registros.
2. Clase
La clase68, es una abstraccin de la realidad y vendra a ser la forma comn de
describir objetos similares. Gracias a ella es posible reconocer rpidamente
otros objetos del mismo tipo, asocindolos a ella y dndoles los elementos
comunes, los cuales pueden ser alterados en un objeto determinado.
Qu diferencia hay entre una clase y un objeto? La clase es una generaliza-
cin que no llega a transformarse en tablas, por ejemplo: personas. El objeto
representa algo del mundo real que tendr una representacin fsica, por ejem-
plo, las tablas de clientes y proveedores.
A partir de experiencias concretas vamos formando y perfeccionando cada
abstraccin. Por ejemplo, la idea de mesa la representamos como una cubierta
68
El concepto de clase es tan importante porque tiene una fuerte sustentacin natural; de
muestra, revisemos esta cita extrada del libro Mustrame tu rostro, de Ignacio Larraaga,
sobre el proceso cognitivo en el ser humano: Por el viaducto de los sentidos entran en la
mente humana las impresiones y sensaciones de los diferentes objetos. En realidad, la mente
es eso: una red filtradora o una fbrica de elaboracin. Efectivamente, de cada objeto detec-
tado por los diferentes sentidos, la mente aparta lo que el objeto tiene de propio o individual
y extrae y retiene lo que tiene de comn con todos los dems objetos de su especie. Esto es,
deduce una idea comn a todos los objetos y por consiguiente, universal. Es un trabajo de
universalizacin. Vamos a un ejemplo concreto.
Aqu veo una silla. All lejos veo otra silla, pero qu diferente a sta! En ese rincn hay otra
silla que no se parece nada a estas dos ni en tamao ni en diseo. Y as, entraron en mi men-
te, supongamos, cincuenta sillas de cincuenta formas diferentes. Ahora comienza el trabajo
elaborador de la mente. De todas las sillas, mejor, de las imgenes concretas de cada silla,
la mente, dejando aparte aquello que le es propio a cada una, saca y se queda con lo que es
comn a todas: una idea universal de silla.
Una vez terminado este trabajo de elaboracin, pueden presentar ante mis ojos mil sillas en
medio de diez mil otros objetos. Mi mente toma, como un candil, aquella idea universal y con
su luz, voy distinguiendo, reconociendo e identificando las mil sillas entre los diez mil obje-
tos, sin equivocarme.
Lo mismo sucede en otras reas. Si me ponen delante otros cinco mil objetos, sabr decir con
precisin cules son fros, cules calientes o tibios. O, en otro orden, cules son duros o
blandos; cules verdes, rojos o amarillos.
As funciona y sta es la gnesis del pensamiento humano.
con algn tipo de soporte. De la misma forma, tenemos abstracciones de

alegra, responsabilidad, padre, madre, pareja y as sucesivamente.
Tambin creamos clases y formamos abstracciones de abstracciones formando
conceptos cada vez ms complejos.
Las abstracciones son vitales, porque las utilizamos para filtrar la realidad y
enfrentar nuevas situaciones69.
Somos capaces de reconocer un lpiz, una experiencia nueva, porque sus ele-
mentos distintivos cuadran con nuestra abstraccin de lpiz, obtenida como
resultado de todas nuestras experiencias anteriores sobre el concepto de lpiz.
No se puede dibujar una abstraccin, porque si lo hacemos estamos obligados
a particularizarla en un objeto concreto, por ejemplo, en el caso de la mesa,
tendramos que sealar tamao, forma, textura o color.
Queda de manifiesto la estrecha relacin existente entre el concepto de clase
de la orientacin a objetos y la abstraccin del proceso cognitivo en el ser
humano.
3. Objeto
Es una unidad monoltica de atributos con sus funciones que tiene su propia
identificacin, tal como se aprecia en la figura 5-8, donde se muestra una for-
ma de representacin para un ejemplo de clientes. La identificacin del objeto
contiene un nombre corto, un nmero y un nemotcnico; en el ejemplo: Clien-
tes, 08, CL. Los atributos corresponden a la definicin de los datos (RUT,
nombre y direccin) y las funciones realizan operaciones sobre los atributos
(ingresar, obtener informe y consultar).
El objeto se comunica con el mundo exterior a travs de mensajes, de aqu el
concepto de encapsulamiento de datos y procesos. Las funciones manipulan
los datos y solamente se activan a travs de mensajes. Un usuario u otro obje-
to no pueden aplicar procedimientos externos para actuar directamente sobre
los datos, por esta razn se habla de ocultamiento de datos (data hiding).
69
A propsito, es curioso que algunas abstracciones las tenemos inconscientemente en perfec-
cionamiento continuo y otras se nos quedan rgidamente ancladas en alguna parte del pasado,
sin verse afectadas por las nuevas experiencias que vivimos, hasta cuando viene una crisis y
hacemos una actualizacin rpida y agotadora.
264 JUAN BRAVO C.
Clientes 08 CL Identificacin
RUT
Nombre
Atributos
Direccin
1. Ingresar datos
2. Obtener informe Funciones
3. Consulta
Figura 5-8. Representacin de un objeto
Un objeto tiene una identidad, un comportamiento (de acuerdo con la funcin

activada) y un estado que resulta del valor que tomen sus atributos. El objeto
as concebido no se daa por errores en otros objetos.
El objeto nace a partir de una abstraccin de la realidad. Es un punto de vista
que puede diferir de persona a persona y que representa algo del mundo real,
por ejemplo, es la imagen que traemos a nuestra mente cuando imaginamos un
lpiz, una silla o el maestro de clientes en la aplicacin de cuentas corrientes.
Aplicando el concepto de recursividad de la orientacin a objetos, tambin
puede ser que el maestro de clientes sea una clase y que cada cliente indivi-
dual sea un objeto.
Los diferentes tipos de modelos permiten entender mejor la realidad, para as
ayudar a resolver problemas concretos. En este sentido, los objetos son mode-
los que reflejan de mejor manera la realidad que otros mecanismos actuales,
porque lo hacen de manera ms natural. Por ejemplo, una fecha no se entiende
habitualmente como caracterstica de datos y clculos por separado, sino que,
intuitivamente, uno la entiende como un conjunto donde hay datos
(DD/MM/AAAA) y operaciones (cambio de da, mes, ao, situaciones especiales
como aos bisiestos o meses con diferente cantidad de das).
El objeto tambin posee caractersticas propias; son rasgos que lo definen,
independientemente de sus ocurrencias; por ejemplo, nombre, nmero, ne-
motcnico, descripcin, fecha de creacin, fecha de expiracin, propietario o
condiciones fijas.
Para efectos del diseo, cada entidad se transforma en un objeto; por lo tanto,
el nombre del objeto debera ser el mismo que el de la entidad.
4. Funcin
Por funcin entendemos funcin computacional, de la misma forma como fue
presentada en el captulo anterior y con la misma distincin entre parte pblica
y reglas del negocio.
Orientacin a objetos no implica programacin orientada al objeto, porque son
niveles diferentes. Por lo tanto, la funcin puede construirse de diferentes ma-
neras; por ejemplo:
Con cdigo reutilizable.
Utilizando facilidades de sistemas administradores de bases de datos.
A travs de alguna herramienta de productividad.
Programando en algn lenguaje de alto nivel: Cobol, Clipper, C u otro.
En la orientacin a objetos, la funcin computacional debe poseer la carac-
terstica de atomicidad (o descomposicin funcional) porque:
Cumple un objetivo preciso y bien acotado; por ejemplo: agregar un clien-
te, eliminar un cliente, obtener un informe o verificar el nivel de crdito.
Esto trae como consecuencia que en general las rutinas tengan pocas lneas
de cdigo.
Slo se relaciona con los atributos del objeto y con ningn otro conjunto
de datos, porque todo lo que necesita viene dado como parmetro en la es-
tructura del mensaje. Es equivalente a que toda funcin acte nicamente
sobre una entidad; de esta manera, desaparecen las relaciones funcionales
entre entidades, las cuales son reemplazadas por el protocolo de un objeto.
5. Identidad de instancias de objetos

Significa que cada instancia de un objeto tiene su propia identidad, indepen-
dientemente del valor que tomen sus atributos. Un objeto puede cambiar li-
bremente cualquier atributo sin dejar de ser l mismo. En consecuencia, no
sera necesario definir atributos identificatorios en un objeto, simplificndose
notablemente la participacin del usuario por este solo concepto.
Con la identidad de instancias de objetos damos un gran paso hacia la natura-
lidad, porque en la realidad cada instancia es independiente. Por ejemplo, una
persona no pierde su identidad si cambia su nombre, RUT o direccin.
266 JUAN BRAVO C.
Opcionalmente, tambin debiramos poder trabajar con una clave nica. En

otras palabras, el sistema administrador de objetos tendra la capacidad de
generar y manejar la identidad de objetos, adems de permitir referenciar cada
instancia segn una clave nica, a opcin, para responder a la realidad de mu-
chos objetos que no tienen problemas con una clave identificatoria (RUT o
cdigo de barras) la que en algunos casos es indispensable: artculos de un
supermercado o diferenciacin de productos a nivel internacional.
6. Mensaje
Es una forma lgica de representar la comunicacin entre objetos. Los com-
ponentes mnimos de un mensaje son: objeto destino, funcin que activa y
parmetros. Los parmetros son los valores y condiciones de entrada que re-
quiere la funcin seleccionada. Por ejemplo, en la figura 5-9 podemos apreciar
la estructura del mensaje 1 al objeto artculos, el cual activa la funcin 1 y
lleva los parmetros: cdigo del artculo y cantidad a restar.
Artculos
Mensaje 1 Cdigo
Ventas Descripcin
Stock
1.Restar stock
Mensaje 1: Artculos (cdigo, cantidad)
Figura 5-9. Ejemplo de estructura de un mensaje
Al conjunto de mensajes vlidos de un objeto se le llama protocolo del objeto.

Un mensaje puede generarse de diferentes maneras; por ejemplo:
Al terminar el ingreso de una transaccin
Desde un men
Al cumplirse una fecha y hora
Desde un proceso batch
El mismo mensaje se puede enviar a muchos destinos al mismo tiempo.
Todo mensaje debe ser contestado, aunque slo sea para decir lo escuch,
tal como en la buena comunicacin humana.
Para efectos de la implementacin del diseo con programacin tradicional, la

generacin de un mensaje puede significar la realizacin de una llamada pa-
ramtrica a una rutina. En todo caso, su forma final depender de las herra-
mientas disponibles para realizar el diseo.
7. Independencia
Cada objeto es independiente, est identificado individualmente y no puede
ser alterado desde otros objetos o programas. Puede realizar diferentes funcio-
nes y tiene conexiones fcilmente reconocibles.
La independencia es una consecuencia del encapsulamiento, porque los datos
de un objeto no pueden ser alterados en forma directa. Slo se puede llegar a
ellos a travs de mensajes que activan funciones propias del objeto.
Se pueden cambiar libremente las funciones de un objeto sin afectar a otros,
siempre que no cambie la estructura del mensaje. No obstante, si fuera necesa-
rio afectar los mensajes producto de cambios mayores, el esfuerzo se vera
notablemente simplificado, porque las interacciones con otros objetos estn
definidas y acotadas.
Esto permite una forma simple, prctica y natural de abordar los problemas de
procesamiento de datos, porque se espera llegar a tener objetos intercambia-
bles. Es decir, se podra cambiar un objeto por otro ms poderoso sin afectar
al resto del sistema, en la medida que el protocolo se mantenga intacto.
La independencia de los objetos tiene efecto inmediato sobre el grado de co-
municacin entre ellos. Significa que disminuyen las interacciones innecesa-
rias o de dependencia y se incrementan las relaciones importantes, aqullas
que se refieren a qu es lo que quiero.
Es un tipo de comunicacin estructurada donde se pueden identificar puestos
intercambiables de objetos, como stos:
Cliente, solicita la accin.
Servidor, da respuesta al pedido.
Esta distincin es dinmica, porque puede variar rpidamente. Haciendo una
similitud con el esquema cliente-servidor en las redes, se puede apreciar que
el servidor toma el puesto de cliente cuando requiere datos desde un servidor
de mayor nivel.
Modularidad
En la orientacin a objetos, el mismo esquema de definicin de objetos permi-
te una modularizacin natural a travs de la definicin de clases.
268 JUAN BRAVO C.
Por otro lado, las interfaces entre clases son muy claras y precisas.
Debe entenderse que la simplicidad de los elementos modulares involucra
mayor complejidad en su comunicacin, pero como sta es estructurada, pue-
de ser automatizada.
8. Enfoque sistmico
El enfoque sistmico se caracteriza por proporcionar una visin de conjunto
sobre el sistema en estudio, reflejada en identificar los objetos y las interac-
ciones entre ellos (los mensajes). En este enfoque, cada interaccin tiene el
status de un componente ms70.
Cul es el nmero potencial de interacciones entre los objetos? Considere-
mos que si hay 2 objetos, la interaccin es 1. Si hay 3, las interacciones son 3.
Si hay 4, el nmero de interacciones puede llegar a 6 y as sigue aumentando
exponencialmente.
Las interacciones entre los objetos tienen que ser tan bien estudiadas como los
objetos mismos, porque cada una es individual y afecta de diferente manera al
objeto y tal como en las interacciones personales, la calidad de la relacin se
traspasar al conjunto.
70
Como analoga, si aplicamos este enfoque a una familia con tres miembros (pap, mam,
hijo), identificaremos inmediatamente tres relaciones principales: pap-mam, pap-hijo,
mam-hijo. Cada una con su propia identidad y peculiaridades. Somos dependientes de nues-
tras relaciones y cada una nos estremece de diferente manera, a veces, hasta hacernos entrar
en resonancia. Una mala relacin afecta a toda la familia, incluso cuando no haya algo es-
pecialmente conflictivo en las respectivas personas. Del mismo modo, la sanacin de una
relacin enferma repercutir favorablemente en cada integrante y en el conjunto.
5.4. PROCESO DE GENERALIZACIN
Es tan importante el concepto de generalizacin en la orientacin a objetos

que le hemos dedicado la presente seccin.
Veremos:
1. Obtencin de clases
2. Herencia
1. Obtencin de clases
La generalizacin significa ir poco a poco formando clases de objetos que
nacen como consecuencia de muchas experiencias con objetos. Hasta cierto
punto capitalizan la inteligencia de una instalacin y sirven para derivar obje-
tos, como si fuera una herencia. Por ejemplo, si las transacciones del inventa-
rio son rdenes de entrada y rdenes de salida, dos objetos, podramos definir
una clase transacciones de inventario que contenga los elementos comunes de
las dos experiencias. Es como funciona el proceso cognitivo en el ser humano.
Nosotros aprendemos formando y perfeccionando mltiples abstracciones y
luego aplicamos la abstraccin para reconocer experiencias y tomar decisio-
nes. El concepto de generalizacin de la orientacin a objetos permite acer-
carnos un poco a la tan buscada inteligencia artificial.
Entonces, en el proceso de generalizacin formamos clases a partir de objetos
o de otras clases. Aclaremos:
Una clase nace del primer objeto que no encaja en ninguna clase existente.
Un objeto siempre pertenece a alguna clase de donde hereda sus
Un
elementos.
objeto hereda siempre todas las caractersticas de la clase. Si hay ele-
mentos que debe eliminar significa que deberamos crear una subclase o
modificar la clase para que sea representativa.
Profundizando ms en la concepcin de clases, no es imprescindible la expe-
riencia para formar una abstraccin. Considerando que la clase es algo abs-
tracto, es posible crear clases de objetos que no existen todava como es el
caso de las clases de partculas subatmicas enunciadas en la teora de Eins-
tein y en la fsica cuntica que luego se fueron descubriendo.
270 JUAN BRAVO C.
Para qu sirve una clase? Para no multiplicar esfuerzos haciendo lo mismo

en cada ocurrencia comn y reconocer nuevos objetos de la misma clase, los
que heredarn sus elementos y ayudarn a perfeccionarla.
Para aclarar ms el concepto, veamos el ejemplo sobre remuneraciones en la
secuencia de figuras 5-10, 5-11 y 5-12.
En la figura 5-10 se pueden apreciar los objetos descuentos de anticipos y re-
baja de prstamos a las personas; los atributos comunes son: nmero de do-
cumento, RUT del empleado y monto de la transaccin; las funciones comu-
nes son: verificacin de existencia, ingreso, informe y activacin del mensaje
19 sobre la clase empleados al terminar el ingreso de datos.
Descuento Empleados Rebaja de

de anticipos Prstamos
Rut
N documento Monto N documento
C/E C/E Rut
Rut Total haber
Monto Total descuento Monto
Mensaje Mensaje N cuota
Ingresar datos 19 18. Sumar haber 19
Ingresar datos
Obtener informe 19. Sumar descto Obtener informe
Figura 5-10. Ejemplo de transacciones de sueldos con objetos
En la figura 5-11 se muestra cmo se forma la clase transacciones de sueldos

con los elementos comunes de los objetos descuentos de anticipos y rebaja de
prstamos a empleados.
Descuento
de Anticipos
Transacciones Empleados
de sueldos
Rut
N documento Monto
Rut C/E Total haber
Monto Total descuento
Rebaja de Mensaje
Ingresar datos prstamos 19
Obtener 18. Sumar haber
informe N cuota 19. Sumar descto
Figura 5-11. Ejemplo de definir una clase de transacciones de sueldos

Sin embargo, justo cuando tenemos listo nuestro modelo, nos damos cuenta
que no consideramos las bonificaciones. No hay problema, pues, como es
tambin una transaccin de sueldos, la hacemos nacer con los elementos de la
clase. Sin embargo, la bonificacin se suma al total haber del objeto personal
y es necesario activar la funcin 18 de personal, en lugar de la 19, como en el
caso de las otras transacciones.
Cmo reflejamos lo particular de cada objeto respecto a su clase? Sera ex-
tenso indicar en el diagrama de clases ese nivel de detalle, as es que usamos
una tabla de objetos asociada a cada clase. Por lo tanto, el modelo final corre-
gido quedara solamente con las clases y la tabla de objetos, tal como se mues-
tra en la figura 5-12.
Transacciones Empleados
de sueldos
Rut
N documento C/E Monto
Rut Total haber
Monto Mensaje Total descuento
18/19
Ingresar datos 18. Sumar haber
Obtener informe 19. Sumar descto
Tabla de objetos de la clase Transacciones de sueldos

Objeto Atributos Funciones
Anticipos msg 19
Prstamos N cuota msg 19
Bonificaciones msg 18
Figura 5-12. Diagrama final de la generalizacin
En la figura 5-12 podemos apreciar la estructura de la tabla de objetos: to-

mando como base los elementos heredados de la clase, seala qu atributos o
funciones se agregan a cada objeto y lo particularizan.
Los mensajes tambin llamados solicitudes pertenecen a cada relacin
particular entre objetos; as es que se indicaron explcitamente en la tabla de
objetos.
En esta secuencia apreciamos la definicin, aplicacin y perfeccionamiento
continuo de una clase, de la misma forma en que opera el proceso cognitivo
del ser humano en relacin a las abstracciones.
272 JUAN BRAVO C.
2. Herencia
El concepto de herencia es similar a la herencia gentica en el ser humano;
heredar significa recibir nuestras caractersticas a travs de los genes y as
partimos con lo que nuestros padres nos transmitieron71, sin posibilidad de
modificarlo color de ojos, estatura o ancho de los dedos aunque incorpo-
rando nuestra particular forma de ser obtenida de la experiencia y la reflexin.
En la figura 5-13 se aprecia el nacimiento y aplicacin de la clase ventas, la
cual fue definida a partir de los elementos comunes de los objetos ventas con-
tado y ventas crdito. Si fuera necesario definir un nuevo objeto, por ejemplo
ventas por mayor, ste nacera con los datos y funciones de la clase ventas,
adems, puede tener particularidades tales como el atributo descuento y la
funcin emitir factura.
Ventas contado
Ventas
N documento
Emitir boleta Fecha Ventas por mayor
Cliente
Precio Descuento
Ventas crdito Cantidad
Emitir factura
Ingresar datos
Obtener informe
Emitir pagar
Figura 5-13. Ejemplo de herencia en un sistema de ventas
En otro nivel de abstraccin, las funciones tambin pueden ser clases; por
ejemplo, el documento de crdito en la figura 5-13 podra ser genrico y
representar todos los casos del mismo tipo: letras, pagars, o cheques a fecha.
En la herencia, los objetos heredan sin discusin los elementos de la clase y
pueden agregar otros atributos y funciones.
El concepto de herencia entrega una forma muy clara de apoyar el diseo de
aplicaciones administrativas, particularmente en la definicin de transaccio-
nes, donde existen muchas similitudes entre un tipo de transaccin y otra.
Herencia mltiple
71
Y lo que no nos transmitieron por error gentico y que la naturaleza invent, pero eso es
otro tema.
Con la herencia mltiple pueden existir subclases o una jerarqua de clases;

adems, las caractersticas heredadas pueden ser incorporadas directamente o
provenir desde otras clases u objetos, tal como se aprecia en la figura 5-14.
Clase Clase
Nuevo atributo o
Objeto Objeto
funcin
Figura 5-14. Herencia mltiple
Un ejemplo de herencia mltiple a nivel del diseo es el siguiente: en un sis-

tema de ventas necesitamos formar el objeto clientes. Entonces, de la clase
personas jurdicas heredamos los datos para formar el objeto. Adicionalmen-
te, requerimos agregar los datos de las personas que hacen contacto con nues-
tra organizacin comprador, gerente y tesorero, los cuales heredamos
desde la clase personas naturales.
En este ejemplo, consideraramos a clientes como heredero de la clase princi-
pal; es decir, de personas jurdicas.
274 JUAN BRAVO C.
5.5. FASES DE LA ORIENTACIN A OBJETOS
Se presenta en esta seccin una tcnica para realizar orientacin a objetos. Se

aplica una visin sinttica, holstica, yendo de lo general a lo particular.
Todo comienza con el modelamiento de la informacin.
Veremos:
1. Modelamiento de la informacin
2. Identificacin de clases
3. Visin externa
4. Visin interna
5. Interfaz humana
1. Modelamiento de la informacin
Antes de comenzar con la OO es indispensable contar con el modelamiento de
la informacin.
Repasemos brevemente esta condicin de entrada al OO.
Identificar entidades: consiste en seleccionar los conjuntos de datos que
participarn en el modelo. De dnde nacen? De la identificacin de los
procesos de la organizacin y ms en particular, de las transacciones que
ellos generan.
Modelar y normalizar los datos: significa delimitar cuidadosamente cada
conjunto de datos, eliminar la redundancia, identificar con precisin los
atributos de cada entidad resultante y establecer las relaciones entre ellas.
Modelar funciones: significa aclarar las reglas del negocio e identificar las
relaciones funcionales entre entidades.
Definir el flujo de transacciones: significa visualizar cmo diferentes even-
tos (transacciones) van a producir cambios de estado (variacin de atribu-
tos) de una entidad (maestro) a travs de ciertas acciones (funciones).
Adems de las funciones propias del modelamiento de la solucin, debern
definirse otras orientadas a la infraestructura de apoyo que requiere una apli-
cacin: proteccin, en lo que se refiere a privacidad, integridad y recupera-
cin; mens, bsqueda de informacin, bitcora de uso del sistema, creacin y
reconstruccin de objetos.
Vamos a comenzar suponiendo que existe un modelo de datos normalizado
sobre un sistema de inventarios simplificado, como el de la figura 5-15. Este
modelo tiene transacciones de ventas y compras, cada una de ellas posee la

estructura encabezado-detalle. Tambin incluye los maestros de proveedores,
clientes y artculos de lnea blanca.
Encabezado Encabezado
Proveedores Clientes
de compras de ventas
Detalle de Artculos Detalle

compras Lnea blanca de ventas
Figura 5-15. Modelo de datos simplificado de inventarios
Los smbolos corresponden a relaciones unos a muchos:
Relacin de pertenencia
Relacin de uso
Tambin existen las relaciones funcionales entre entidades, por ejemplo, para:
Realizar verificaciones de existencia en el ingreso de las transacciones:
sobre proveedores en el caso de compras, respecto a clientes en el caso de
ventas y sobre artculos en ambos casos.
Actualizar el maestro de artculos al terminar el ingreso de una transaccin,
para rebajar el saldo en el caso de ventas y para sumar el saldo y calcular
costo promedio en el caso de compras.
Ms que presentar recetas, el contenido de las fases es una gua para la accin,
ellas deben complementarse con mucho sentido comn.
2. Identificacin de clases
Durante esta fase se realiza el proceso de generalizacin, con el fin de definir
las clases y objetos que formarn parte del sistema.
El resultado esperado es el modelo de datos generalizado, como el de la figura
5-16. En sta, se aprecian las siguientes relaciones entre las clases: de perte-
nencia entre encabezado y detalle de la transaccin, de uso (uno a muchos)
entre personas y el encabezado de transaccin, al igual que entre productos y
detalle de transaccin.
276 JUAN BRAVO C.
Encabezado Personas
de transaccin
Detalle de
transaccin Productos
Figura 5-16. Modelo de datos generalizado
Se obtuvo al modelo de la figura 5-16 a partir del modelo de datos de la figura

5-15. Las clases encabezado y detalle se obtuvieron de los elementos comunes
de las entidades ventas y compras. La clase persona es una generalizacin de
clientes y proveedores. La clase productos es una generalizacin de artculos
de lnea blanca.
3. Visin externa
Significa definir el protocolo del sistema, es decir, todos los mensajes vlidos
que activarn las funciones de los objetos. La principal herramienta en esta
fase es el modelo funcional generalizado, cuyo objetivo es mostrar las interac-
ciones entre las clases. Se presenta en la figura 5-17, siguiendo el mismo
ejemplo de los puntos anteriores.
Encabezado C/E Ingresar

de transaccin transaccin Personas
Mensaje 1
Detalle de C/E
transaccin Productos
Mensajes 4 y 5
Figura 5-17. Modelo funcional generalizado
Observaciones respecto a la figura 5-17:

Se agreg una nueva clase: ingreso de transaccin. sta representa el in-
greso de un documento directamente en la pantalla del equipo, tal como si
estuviramos llenando una factura.
Se utiliz este smbolo para graficar la clase de ingreso de datos72:
Ingresar
transaccin
Se us la abreviatura C/E para condicin de existencia.
Por qu darle tratamiento de una clase al ingreso de datos?

Porque refleja de mejor manera la realidad. En la prctica, el ingreso de dife-
rentes tipos de transacciones es bastante similar.
Desde el punto de vista de implementacin, siempre el ingreso de datos pasa a
travs de un almacenamiento transitorio. Explcitamente cuando en el proce-
samiento batch-interactivo los datos se guardan en una tabla de transacciones
del da, e implcitamente cuando los datos quedan en la memoria del equipo o
de la pantalla.
En ambos casos, existe almacenamiento intermedio y mucha funcionalidad,
eso justifica darle al ingreso de datos el tratamiento de una clase a nivel del
diseo.
Visin de conjunto del modelo

El modelo funcional generalizado lleva un mayor nivel de detalle, como en el
caso de la figura 5-18, es un modelo que representa toda la aplicacin, como
un mapa, as se puede lograr la necesaria visin global que tanto ayuda en el
perfeccionamiento de la aplicacin.
72
Incluir todos los datos en la pantalla simulando el documento original equivale a un proceso
de desnormalizacin del modelo de datos.
278 JUAN BRAVO C.
Encabezado Personas
de transaccin Ingreso de transaccin
N documento Rut
Fecha C/E Encabezado, detalle y C/E Nombre
Rut persona totales segn formato Direccin
Mensaje Telfono
1
1 Agregar 1 Aceptar datos 1 Agregar
2 Consultar 2 Cuadrar totales 2 Consultar
3 Imprimir 3 Imprimir
Detalle Productos
de transaccin
N documento Cdigo artculo
Cdigo artculo C/E Tipo artculo
Costo Descripcin
Mensajes 4 y 5 ltimo costo
Cantidad
Saldo
1 Clculo total
1 Agregar
2 Consultar
3 Imprimir
4 Sumar saldo
5 Restar saldo
Figura 5-18. Modelo funcional generalizado y detallado

Se contina sealando explcitamente la relacin de pertenencia, esto por la
caracterstica de funcionalidad intercambiable indicada al comienzo del
captulo.
Por ejemplo, el mensaje 1 que tiene por misin solicitar agregar un nue-
vo documento a la clase transacciones se envi slo al encabezado, con
lo cual tambin se agregar automticamente en el detalle (a travs de un
mensaje que enviar el encabezado al detalle).
Los mensajes 4 y 5 sobre inventarios se refieren a sumar o restar el saldo
del artculo, respectivamente.
La similitud que existe entre las funciones de las clases nos debera llevar a
definir un conjunto de funciones generalizadas que tuvieran siempre la
misma identificacin. Un mensaje implcito es que cada una de estas fun-
ciones generalizadas es tambin una clase en otro nivel de abstraccin.
Por ejemplo, la lista podra incluir:

a) Condicin de existencia
b) Agregar un registro
c) Eliminar un registro
d) Modificar cualquier campo del registro
e) Consultar todo
f) Imprimir todo
g) Obtener copia de seguridad total
h) Obtener copia de seguridad con las ltimas modificaciones
i) Estadsticas de uso
j) Eliminacin de ocurrencias sin movimiento
k) Respaldo automtico
l) Reconstruccin automtica
m) Inicializacin
n) Auditora
o) Restricciones de acceso
La funcionalidad generalizada puede ser una norma del medio? Se est tra-
bajando en la modularidad y se busca intercambiar y comercializar clases, sin
embargo, todava est en proceso de consolidarse. Mientras tanto, es una exce-
lente opcin darse normas de reutilizacin al interior de la organizacin o en
pequeas agrupaciones de empresas.
4. Visin interna
En la visin interna se describen minuciosamente cada uno de los tres compo-
nentes de la clase caractersticas propias, atributos y funciones y la tabla
de objetos. En la figura 5-19 se muestra la visin interna de la clase productos,
incluida en la figura 5-18. Ntese que la tabla de objetos consta solamente de
una ocurrencia, con los mismos elementos que la clase.
280 JUAN BRAVO C.
En este tipo de modelos es frecuente referenciar funciones generalizadas, tal

como se aprecia en la figura 5-19 para las acciones a realizar en el caso de
stock negativo o la funcin imprimir. Tambin se normaliza la notacin de los
atributos, por ejemplo, num 6,2 puede significar: atributo numrico de 6
enteros y dos decimales, con signo.
15 Productos (PR)
Propietario: Juan Prez, diseador de sistemas
Es el maestro de artculos, todos los productos estn en una bodega
Creacin: 21/4/2008 Expiracin: 21/4/2014
Variables globales: costo total y descripcin
Cdigo del artculo : numrico largo 5. Es la llave principal
Tipo de artculo : numrico largo 2, asociado a la tabla de
traduccin 18
Descripcin : alfanumrico largo 30
ltimo costo : numrico largo 6
Saldo : numrico largo 6, con signo. Si queda negativo,
procedimiento normal
1. Crear : se agrega un artculo. Parmetros: los 5 atributos.
2. Consultar : presentacin tabular de los datos, bsqueda por
cualquier atributo.
3. Imprimir : sin el costo, con corte de control por tipo de
artculo y orden por descripcin en cada tipo.
Funcin normal.
4. Suma saldo : suma unidades al saldo y mueve ltimo costo,
parmetros: cdigo, unidades y costo.
5. Resta saldo : resta unidades al saldo, parmetros: cdigo y
unidades. Si el saldo queda negativo,
procedimiento normal.
Tabla de objetos, clase productos

Artculos de lnea blanca
Figura 5-19. Visin interna de la clase productos

En la siguiente figura, nmero 5-20, vemos la descripcin de la clase Ingreso

de transaccin, sealada en el punto anterior.
Ingreso de transaccin
Encabezado, detalle y totales segn

Formato de pantalla adjunto
Aceptar datos y actualizar lnea a

lnea cada producto.
Enviar mensajes para verificar

Existencia de personas y artculos,
Ambos deben existir.
Cuadrar totales para referencia.

Enviar solicitudes para actualizar el stock
Tabla de objetos, clase Ingreso de transaccin

Ingreso de ventas Indicar stock del producto Deben cuadrar totales, stock mayor a
unidades por vender. Mensaje 5
Ingreso de compras Crear proveedor y artculo si no
existen. Mensaje 4
Figura 5-20. Visin interna de la clase ingreso de transaccin
Para completar el sistema de inventarios presentado en la figura 5-18, deber-

amos describir las otras clases e incluir la tabla de objetos de cada una:
Encabezado y Detalle de transaccin: van juntas porque hay una relacin
de pertenencia entre ellas.
Personas: podra suceder que la descripcin de clientes y proveedores sea
igual, sin diferencias entre s, en tal caso, la tabla sera similar a la de pro-
ductos de la figura 5-19.
Dos niveles de funcionalidad

En la OO existen dos niveles de definicin de funcionalidad. En el primer
nivel se asocian procedimientos lgicos a atributos individuales de un objeto,
como la verificacin de existencia entre las clases transaccin y personas de la
282 JUAN BRAVO C.
figura 5-18. Generalmente esta funcionalidad viene definida desde el modelo

de datos.
En el segundo nivel se define funcionalidad sobre conjuntos de atributos, tal
como agregar un artculo u obtener un informe. En ambos casos, la funciona-
lidad puede ser generalizada, en otras palabras, seran clases en otro nivel de
abstraccin.
5. Interfaz humana
Especialmente en el orientacin a objetos el diseo de la interfaz humana es
vital para lograr el objetivo final de tener una buena aplicacin en funciona-
miento pleno.
En el captulo 2, acerca de ingeniera de software, dedicamos una seccin al
diseo de estas interfaces.
5.6. INCORPORACIN DE LA TECNOLOGA DE

OBJETOS
Para una incorporacin exitosa de la tecnologa de objetos en la organizacin,

es indispensable considerar su cultura y nivel de madurez, especialmente en
cuanto a respetar normas internas y con el medio73.
Veremos:
1. Personalizacin del objeto
2. Reutilizacin de cdigo
3. Construccin de un modelo de objetos
1. Personalizacin del objeto

La forma ideal de trabajo en la orientacin a objetos es entre pequeos equi-
pos (teams) donde participen usuarios y profesionales de la informtica.
Como tcnica de definicin es muy til personalizar el objeto, mejor an,
pensar que yo soy el objeto y comenzar a hacernos preguntas; por ejemplo:
Quin soy?
Para qu sirvo?
Qu atributos tengo?
Qu funciones cumplo?
Cundo realizo esa funcin?
Cul es el valor agregado que aporto?
Qu informacin necesito de otros objetos?
Qu informacin necesito para cumplir una funcin?
A travs de las cuales se va aclarando el entorno y luego el contenido del obje-
to, tal como en el enfoque sistmico.
En un grupo de trabajo cada uno de los participantes puede tomar el rol de un
objeto para lograr simular, entre todos, el funcionamiento del sistema. Esta es
una excelente tcnica para refinar la comunicacin entre los objetos y entre
las personas.
73
Es lo que vimos en el captulo 2 sobre el cambio cultural en la organizacin y en el captulo
5 acerca de incorporacin de nuevas tecnologas.
284 JUAN BRAVO C.
Es tambin una buena prctica para evitar confundir el contenido con la rela-
cin. Separar la esencia del objeto de su comportamiento en un instante del
tiempo, igual que entre los seres humanos.
2. Reutilizacin de cdigo
Una idea largamente acariciada es la reutilizacin de cdigo, lo que en el caso
de la orientacin a objetos es perfectamente factible, porque cada funcin in-
corporada al objeto puede ser realizada utilizando los servicios de una rutina
catalogada a travs de una buena parametrizacin o mediante mensajes. Aun-
que tambin es una alternativa la generacin de cdigo ad-hoc con una herra-
mienta de productividad.
La reutilizacin del cdigo tiene en Japn una prioridad tan alta que aproxi-
madamente el 75% de cada aplicacin se construye con componentes reutili-
zables; en comparacin con el 25% de reutilizacin en Estados Unidos.
En el departamento de sistemas de su empresa, qu porcentaje de las aplica-
ciones se construye con cdigo reutilizable?
El principal beneficio de la reutilizacin, adems de la mayor economa en el
mediano plazo, es el perfeccionamiento continuo del cdigo de cada funcin.
Para lograr productividad tenemos que abandonar la artesana en la programa-
cin, donde cada programa es, a veces, una obra de arte irrepetible, desperdi-
cindose lamentablemente todo el tremendo aprendizaje que el programador
obtuvo en ese cdigo, cunta mayor eficiencia podemos lograr al perfeccio-
nar muchas veces las mismas rutinas! No es slo corregir un error, sino que un
esfuerzo sistemtico de mejoramiento de una clase.
Para incentivar la reutilizacin, no es suficiente con una arenga del jefe de
informtica a sus subordinados. Es indispensable crear ambiente y dar seales
claras en esa direccin, como en Japn, donde regularmente se proveen, entre
otras, las siguientes condiciones:
Incentivos econmicos para quienes completen una aplicacin con un alto
componente de reutilizacin.
Una biblioteca de componentes reutilizables a cargo de personal de presti-
gio, que efecte control de calidad de alto nivel para cada funcin
Incentivos
aceptada. cuando se construye una funcin que ser reutilizable
El medio cultural latinoamericano no es proclive a estas iniciativas, no lo digo
para desalentar, sino para tomar en cuenta la realidad y adaptar apropiadamen-
te las estrategias, reconociendo de antemano el verdadero esfuerzo de cambio
que ser necesario realizar. Al principio puede ser difcil y caro, an as es una
buena inversin, porque los retornos son altos en el mediano y largo plazo.
Como tcnica, es muy til comenzar con equipos piloto que muestren rpida-
mente resultados en la lnea de reutilizacin.
Desde la estructura: desarrolladores e integradores

Con la introduccin de herramientas de productividad para el mbito cliente
servidor las cuales permiten la programacin orientada a objetos est
comenzando a ser aplicada una nueva diferenciacin: desarrolladores e inte-
gradores. Los desarrolladores construyen clases, actividad reservada a los
programadores ms hbiles de la instalacin. Los integradores toman las cla-
ses y las adaptan para crear objetos de aplicaciones particulares, eventualmen-
te ellos podran completar una aplicacin con muy poca programacin. Esto es
muy interesante, porque en la prctica significa que en un equipo de integra-
dores pueden participar usuarios.
En este esquema, las clases representan cdigo reutilizable.
3. Construccin de un modelo de objetos

Cmo se construye un modelo de OO? Se puede implementar con programa-
cin tradicional o te tipo OO, bases de datos o cualquier otra forma, porque el
diseo es independiente de la implementacin tecnolgica.
Ms concretamente, supongamos que ya tenemos listo nuestro diseo, enton-
ces podemos implementarlo con:
Sistemas Administradores de Bases de Datos orientados al objeto, aunque
el apoyo a las aplicaciones administrativas todava es bajo. Es posible que
esta sea en algn momento la mejor opcin, en la medida que se desarro-
llen y generalicen productos apropiados.
Herramientas CASE orientadas al objeto, las que pueden ayudar en el mode-
lamiento y generar cdigo en ambientes con o sin bases de datos.
Bases de datos relacionales a travs de herramientas especiales, propias o
externas.
Adaptaciones al cdigo generado por otras herramientas de productividad.
Lenguajes de tercera generacin tales como Cobol y RPG, buscando
amplia aplicacin de cdigo reutilizable.
Otras alternativas
286 JUAN BRAVO C.
Siempre en la lnea de entregar en estas pginas un mnimo indispensable, la

simplicidad final del concepto, no se ha querido romper la unicidad incorpo-
rando particularizaciones, por ejemplo, transformar las clases en entidades
concretas o tomar los atributos desde un diccionario completo de los datos de
la organizacin.
Una reflexin sobre la mayor naturalidad de la tecnologa de objetos: hemos
llegado hasta un punto donde estamos incorporando al modelamiento una se-
rie de caractersticas tpicamente sociales o humanas, como la personalizacin
de objetos, el enfoque sistmico, la comunicacin de mensajes, la identidad
personal y el proceso de generalizacin, qu viene despus? Creemos que
ms estndares y mayor nfasis en trabajar metodolgicamente.
CAPTULO 6.
UNIFIED MODELING
LANGUAGE (UML)
288 JUAN BRAVO C.
Captulo 6. Unified Modeling Language (UML)
UML es una notacin, no un mtodo. No preescribe un proceso

para modelar un sistema. No obstante, como UML incluye los
diagramas de casos de uso, se le considera estar dotado de una
aproximacin al diseo centrada en el problema con los casos de
uso. El Diagrama de Caso de Uso nos da el punto de entrada pa-
ra analizar los requisitos del sistema y el problema que necesi-
tamos solucionar.
Popkin Software and Systems http://es.tldp.org
UML significa literalmente Lenguaje Unificado de Modelamiento, aunque la

idea queda mejor expresada con: Modelamiento Visual del Software, expre-
sin que se est utilizando cada vez ms en espaol. UML est orientado a la
especificacin, visualizacin y documentacin de los productos de software.
Se le considera parte del desarrollo tecnolgico de un modelo de negocios,
enfocado en la definicin de los requerimientos de la aplicacin.
Esta es la sexta competencia considerada para apoyar la elaboracin de mo-
delos de una solucin de software, tal como se aprecia en la siguiente figura
(en la introduccin se incluy la visin global de las competencias). Es indis-
pensable que el analista maneje UML porque es el nico estndar en esta
materia, por lo tanto, tambin se trata de una responsabilidad profesional,
porque hoy es considerado como parte de la calidad estar integrado al mundo
(y en este caso es literal porque UML es el lenguaje utilizado para solicitar
servicios de desarrollo al otro lado del planeta).
CAPTULO 6. UML

UML surgi de los aportes combinados de tres pioneros en el campo del mo-
delamiento orientado a objetos, los doctores Grady Booch, Jim Rumbaugh e
Ivar Jacobson, a peticin de la OMG (Object Management Group), organiza-
cin creada por las empresas lderes mundiales de la industria del software
(entre las cuales se encuentran IBM, Unisys, Alcatel, Toshiba y Microsoft)
destinada a fijar estndares en la industria con la tecnologa de objetos.
La primera versin de UML estuvo disponible en 1997. Ha sido perfeccionado
en el tiempo y la versin actual es la 2.0.
Es mucho lo que se puede decir de UML, en este captulo veremos los mode-
los y en el anexo 7 podr ver un caso completo, el cual puede bajar desde la
pgina www.evolucion.cl.
Veremos:
Modelos de UML
Aplicacin de los modelos UML en la etapa de anlisis
Aplicacin de los modelos UML en la etapa de diseo
290 JUAN BRAVO C.
6.1. MODELOS DE UML
La versin 2.0 de UML tiene 13 tipos de diagramas.

Diagramas de estructura, los cuales se concentran en los elementos que deben
existir del sistema:
1. Diagrama de clases
2. Diagrama de componentes
3. Diagrama de objetos
4. Diagrama de estructura compuesta
5. Diagrama de despliegue
6. Diagrama de paquetes
Diagramas de comportamiento, utilizados para reflejar las acciones del siste-
ma:
7. Diagrama de actividades
8. Diagrama de casos de uso
9. Diagrama de estados
Diagramas de Interaccin, son parte de los diagramas de comportamiento que
se refieren al flujo de control y de datos entre los elementos del sistema:
10. Diagrama de secuencia
11. Diagrama de colaboracin
12. Diagrama de tiempos
13. Diagrama de vista de interaccin
Tambin utiliza un glosario: incluye la definicin de todos los trminos que se
emplean en los modelos de UML, es aplicable en todas las etapas del desarro-
llo.
En UML se usa el trmino artefactos para referirse a diversas agrupaciones de
modelos, a modelos individuales o a cualquier elemento que sea identificado
individualmente. Cuando en el contexto de UML se usa la palabra sistema, es
porque hace referencia al sistema computacional.
Veremos:
1. Casos de uso
2. Uso de herramientas
1. Casos de uso
Los casos de uso (use case) son los modelos ms conocidos de UML, permi-
ten mostrar las interacciones con el usuario. Tal como plantea Ivar Jacobson:
es una narracin que describe la secuencia de eventos de un actor (agente
externo) que utiliza un sistema computacional para completar un proceso.
Tambin es cualquier punto de interaccin con el computador, principalmen-
te detectados desde las actividades del flujograma de informacin.
El caso de uso describe lo que importa al usuario, desde su perspectiva, es un
tem especfico de funcionalidad. El caso de uso describe el curso normal de
los eventos, las excepciones son incorporadas como observaciones al final del
texto. Por ejemplo, si la narracin dice: se ingresa la identificacin del cliente,
no explicamos que sucede si esa identificacin es invlida, simplemente se-
guimos el curso normal de los sucesos. En algunos casos, las excepciones
podran dar origen a otros casos de uso.
Se aplican a la definicin de los requerimientos computacionales del sistema
de informacin. Los casos de uso pueden ser llamados:
De alto nivel, explicados en dos o tres oraciones.
Expandidos, pueden contener cientos de oraciones, se incorpora una des-
cripcin minuciosa destinada a la implementacin computacional.
Por ejemplo, en la figura 6-1 se aprecia que en una tienda minorista, un vendedor
consulta en su terminal por la informacin de un cliente. El ambiente donde suceden
los hechos es el dominio. Incorpora el concepto de actor, es decir, alguien fuera del
sistema que interacta con la aplicacin, en este caso el vendedor.
Terminal en la tienda
Vendedor
Consultar situacin
del cliente
Saldo de crdito y posibilidades

de cuotas.
Apoyo en realizacin de clculos
respecto a financiamiento.
Figura 6-1. Ejemplo de un caso de uso de alto nivel

292 JUAN BRAVO C.
2. Uso de herramientas
Existe una amplia gama de herramientas que ayudan en los modelos de UML
(Visio, Rational, UML Studio, Enterprise Architect y muchas otras). La reco-
mendacin es usarlas, realmente facilitan el trabajo y si el sistema es grande,
son indispensables. Adems, tienen la ventaja de generar el cdigo de la apli-
cacin en forma automtica y son vitales para la comunicacin de los modelos
(generalmente en XML).
Existe en Internet una amplia variedad de software libre para trabajar con
UML, incluso la mayora de estas herramientas permiten generar cdigo, por
ejemplo: ArgoUML, BOUML, Fujaba, gModeler MonoUML y otras.
6.2. APLICACIN DE LOS MODELOS UML EN LA

ETAPA DE ANLISIS
El siguiente ejemplo muestra en la prctica el uso simplificado de los principa-

les modelos de UML en la etapa de anlisis74. Planteados en el espritu del
mtodo GSP de trabajar con el mnimo indispensable, para que efectivamente
pueda ser aplicado en la mayora de las organizaciones.
En el anexo 7 se pueden apreciar estos modelos para una aplicacin real y
detallada de UML.
Veremos:
2. Caso de uso de alto nivel
3. Caso de uso expandido
4. Modelo conceptual
5. Diagrama de secuencia del sistema
6. Visin dinmica del sistema
7. Diagrama de estado
8. Contratos

El diagrama de casos de uso representa una agrupacin de casos de uso, por
ejemplo, todos los casos de uso que tienen relacin con un proceso incluido en
el flujograma de informacin. En la figura 6-2 se presenta un diagrama de
casos de uso para el mbito de adquisiciones. Se observa que cada actor puede
interactuar con ms de un caso de uso.
En el desarrollo en espiral, se espera que el universo completo de casos de uso
est levantado al menos como diagramas de casos de uso. Entonces, los casos
de uso seleccionados para la respectiva vuelta de la espiral se transforman en
casos de uso expandidos.
El diagrama de casos de uso incluye uno o varios actores (que pueden ser per-
sonas u otros sistemas computacionales identificados con el smbolo tipo di-
bujo de nio), un dominio (en este caso terminales del rea de adquisiciones)
y una accin con un verbo en infinitivo dentro de cada valo.
74
Ms detalle en libro Gestin de proyectos de procesos y tecnologa.
294 JUAN BRAVO C.
Cotizador Terminales del rea de Adquisiciones
Cotizar
Jefe de
Aprobar Adquisiciones
Administrativo de cotizacin
Adquisiciones
Ingresar
O/C
Aprobar
O/C
Enviar
O/C = Orden
O/C
de Compra
Figura 6-2. Ejemplo de un diagrama de casos de uso
En este diagrama se utilizan dos caractersticas que provienen de la orienta-

cin a objetos:
Reutilizar casos de uso, en este caso se usa la forma <<include>> sobre
una lnea punteada que apunta hacia el caso de uso comn. Sealan Stevens
y Pooley (2002, p. 120): El caso ms vital es cuando se puede sacar factor
comn del comportamiento de dos o ms casos de uso originales o (mejor
todava) cuando se descubre que puede implementar parte de uno de los ca-
sos de uso utilizando un componente. Por ejemplo, ambas descripciones de
los casos de uso Tomar prestada copia de libro y Ampliar prstamo
mencionan la necesidad de comprobar si existe una reserva sobre el libro.
Entonces deciden incorporar esa necesidad comn, Comprobar reserva
como otro caso de uso referenciado por los dos anteriores.
Separacin del comportamiento variable, en este caso aplica la forma
<<extend>> sobre una lnea punteada que apunta hacia el caso de uso ori-
ginal. Explican Stevens y Pooley (2002, p. 124): Si un caso de uso incor-
pora dos o ms escenarios con diferencias significativas, pueden ocurrir va-
rias cosas diferentes dependiendo de las circunstancias, se puede decidir
que sera ms claro mostrarlos como un caso principal y uno o ms casos
secundarios. Cundo hacer esto es un problema de juicio, ya que siempre se

pueden mostrar situaciones variables en un caso de uso. Por ejemplo, se
podra separar Tomar prestada copia de libro en el caso normal en el que
al usuario se le permite tomar prestado el libro de la situacin inusual en la
que al usuario no se le permite tomar prestado el libro porque l o ella ya
tiene prestados el mximo nmero de artculos. Entonces deciden sacar
esa excepcin como otro caso de uso llamado Rechazar prstamo y la re-
lacin extend seala que pertenece al caso de uso original.
2. Caso de uso de alto nivel

El caso de uso de alto nivel se caracteriza porque la narracin es breve. Permi-
te conocer un poco del requerimiento, algo de la accin, actor(es) y dominio,
tal como se aprecia en la figura 6-3.
Terminal en bodega
Administrativo de
Adquisiciones Ingresar O/C
Ingresa la Orden de Compra

a partir de los documentos de
cotizacin a proveedores.
La O/C queda disponible
para ser enviada al proveedor
luego de la aprobacin
electrnica por el jefe de
adquisiciones
Figura 6-3. Caso de uso de alto nivel Ingresar orden de compra
3. Caso de uso expandido

El caso de uso expandido incluye una narracin en todo detalle e incluye las
interfaces visuales. Recurdese que se usa aqu el concepto de curso normal
de los eventos, las excepciones se anotan al final para no romper la secuencia
de la historia. En la figura 6-4 se aprecia un ejemplo del caso de uso expandi-
do Ingresar orden de compra.
296 JUAN BRAVO C.
Terminal del Administrativo de Adquisiciones

Administrativo
de Adquisiciones
Ingresar O/C
Resumen: (el mismo del caso de uso de alto nivel).

Funciones relacionadas:
Curso Normal de los eventos
Accin del actor Respuesta del sistema
1. Tomar la O/C desde el archivador
2. Ingresar N O/C en (A) 3. Verifica correlativo y enva respuesta
en (B)
4. Ingresar Rut en (D) 5. Verifica que proveedor exista, obtiene
y despliega nombre y fono en (E) y (F)
6.
Para cada lnea: Para cada lnea:
7. Ingresar el cdigo de 8. Verifica existencia del producto,
producto en (H) obtiene y despliega la descripcin
y el precio en (I) y (J)
9. Ingresar las unidades en (K) 10. Calcula el subtotal y despliega en
(L)
10. Dar OK a la lnea 11.
Excepciones:
1. Si el nmero de O/C ya existe, vea caso de uso Corregir Correlativo. 2
Incluye interfaces detalladas de E/S
Figura 6-4. Caso de uso de expandido Ingresar orden de compra
Tiene dos columnas: accin del actor y respuesta del sistema, las excepciones
van aparte. No siempre una accin del actor tiene respuesta, como la accin 1:
Tomar la O/C desde el archivador (que est en algn mueble cercano).
El caso de uso se complementa con una copia del documento orden de compra
y de la interfaz de la pantalla, en este caso los campos se indican con letras
maysculas entre parntesis (A, B, ) para identificar la ubicacin del respec-
tivo campo en la interfaz visual, tal como se aprecia en la figura 6-5 (copiada
desde el anexo 7).
Interfaz de Entrada
Gua Interna de Recepcin por Compra N Gua Recepcin A
Cdigo Enc. Recepcin C Encargado Recepcin D
Fecha Recepcin B
RUT Proveedor E - F
Comuna I Ciudad J Fono K Fax L
Gua de Despacho de Proveedor N M Fecha G/ D. Proveedor N N de O/C. O
LL P Q R S T
Figura 6-5. Ejemplo de Interfaz visual detallada
4. Modelo conceptual
El modelo conceptual define responsabilidades y el dominio del sistema com-
putacional, al comienzo asociado a los casos de uso identificados. Es un mo-
delo que se va construyendo en paralelo con los casos de uso.
Identifica los conceptos ms relevantes del mundo real en el dominio respec-
tivo: roles de personas, tipos de documentos o elementos fsicos. Tambin
identifica las asociaciones entre conceptos con palabras de enlace: usa, regis-
tra en, almacenado en, pagado por, contenida en Se trazan lneas entre los
conceptos para representar este detalle.
En esta etapa, una recomendacin es incorporar en el modelo el mximo de
conceptos y el mnimo de asociaciones.
Las caractersticas del modelo conceptual son muy similares al modelamiento
tradicional de datos.
En las asociaciones entre los conceptos se da multiplicidad o cardinalidad.
298 JUAN BRAVO C.
Se expresa de la siguiente forma:

* : cero o ms (muchos)
1..* : uno o ms
1..12 : de uno a doce
3 : exactamente 3
2, 4, 9 : exactamente 2, 4 9
Siguiendo con nuestro ejemplo de la Orden de compra, el modelo conceptual
tendra la forma que se indica en la figura 6-6:
Encabezado de contiene existe en Proveedores

O/C * 1
compuesta por 1
se asocia a 1..*
O/C * 1
existe en *
almacena 1
Bodega
Figura 6-6. Ejemplo de modelo conceptual sistema de compras

Una O/C est compuesta por 1 ms lneas de O/C. A su vez, una lnea de
O/C se asocia a un solo encabezado de O/C.
Un encabezado de O/C contiene un proveedor. Un proveedor existe en 0
ms encabezados de O/C.
Una lnea de O/C contiene un producto. Un producto existe en 0 ms
lneas de O/C.
Un producto existe en 1 bodega. Una bodega almacena 0 ms productos.
Obsrvese que aparece, con un rombo negro, una asociacin de composicin,
equivalente a la relacin de pertenencia (que se marca con una lnea ms grue-
sa) del modelamiento de datos. En la composicin, tambin llamada unicidad,
una lnea de la O/C no puede existir sin su encabezado y viceversa.
En los conceptos tambin existen atributos, tal como se aprecia en el modelo

de la figura 6-7, siguiendo con nuestro ejemplo de la orden de compra.
Encabezado Proveedores
de O/C contiene existe en
N O/C * 1 Rut
Fecha Nombre
compuesta por

O/C * 1 ...
Unidades existe en *
Precio
almacena 1
Bodega
...
Figura 6-7. Ejemplo de modelo conceptual con atributos
5. Diagrama de secuencia del sistema

El objetivo del diagrama de secuencia es identificar las operaciones de la aplica-
cin, las que luego darn origen a los mensajes y al protocolo del sistema.
Con base en la narracin realizada en el caso de uso, se identifican las operaciones
de la aplicacin, aquellas que obligarn al sistema computacional a hacer algo y
que afectarn a uno o ms conceptos de aquellos incluidos en el modelo concep-
tual. A este nivel de especificacin, la aplicacin sigue siendo como una caja ne-
gra de la cual slo se conocen sus entradas y salidas.
En la figura 6-8 se muestra la forma general del diagrama de secuencia para
un caso de uso donde se est ingresando una orden de compra. Suponemos
que se obtuvieron esas operaciones desde la narracin del caso de uso.
300 JUAN BRAVO C.
Administrativo Sistema
Ingresar N de O/C
Ingresar cdigo de prod.

Repetir hasta
que no haya ms Ingresar cantidad
productos
Dar OK a la lnea
Figura 6-8. Ejemplo de diagrama de secuencia
Qu es una operacin? Una operacin es un mensaje, un mandato para que

algo se ejecute, provoca que algo suceda fuera de la frontera del caso de uso.
Especficamente, activa una o ms funciones en el sistema.
Al principio de la especificacin, la aplicacin se ve como una caja negra y en
la medida que se avanza con el detalle, la columna Sistema se abre en otras:
los conceptos, producindose una estructura de mensajes.
6. Visin dinmica del sistema

Este diagrama es un resumen de las operaciones del sistema, la grfica sugiere
que al unir esta funcionalidad con el modelo conceptual, lograremos algo cen-
tral de la orientacin a objetos: el encapsulamiento, es decir, un slo todo (cla-
se u objeto) con los atributos y los mtodos.
Cuando se trata del primer caso de uso que estamos desarrollando en un sis-
tema, el diagrama de secuencia y la visin dinmica son iguales, desde el se-
gundo se diferencian porque la visin dinmica es acumula las operaciones de
los diferentes casos de uso, tal como se aprecia en la figura 6-9.
Sistema
Caso de uso Ingresar N de cotizacin

Aprobar cotizacin Dar OK al documento
...
Ingresar N de O/C
Caso de uso Ingresar cdigo de producto
Ingresar O/C
Ingresar cantidad
Dar OK a la lnea
Figura 6-9. Ejemplo de diagrama visin dinmica del sistema
Algunos comentarios respecto a los diagramas de secuencia y visin dinmica

del sistema:
Las operaciones del sistema y el diagrama de secuencia son uno a uno con
el caso de uso.
Ambos tienen las mismas operaciones, ms bien llamadas a operaciones,
porque corresponden a la estructura de mensajes del diagrama de clases
(que ya veremos).
La nomenclatura es la de orientacin a objetos.
Los mensajes de la visin dinmica del sistema son mensajes que llegarn
a varias clases, cada una tiene la estructura de atributos y funciones.
7. Diagrama de estado
El diagrama de estado de UML representa grficamente el estado del caso de
uso antes y despus de cada una de sus operaciones. En la figura 6-10 se ob-
serva aplicado a nuestro ejemplo de ingreso de una orden de compra.
302 JUAN BRAVO C.
Ingresar lnea de O/C
Ingresar N de O/C
En espera de Introduccin
la O/C de lneas
Terminar la O/C
Imprimir la O/C En espera

del cierre
Figura 6-10. Ejemplo de diagrama de estado
El diagrama de estado aplica principalmente en aplicaciones de ingeniera y se

utiliza poco en el mbito de los sistemas de informacin administrativos, por
lo tanto, no lo incluimos en el curso normal de los eventos de los modelos a
utilizar en el mtodo GSP.
8. Contratos
Los contratos detallan cada operacin y existirn tantos como operaciones se
hayan identificado en el caso de uso y detalladas en el diagrama de secuencia.
Tienen la estructura que se indica en la figura 6-11.
Contrato
Identificacin: nombre de operacin y parmetros
Responsabilidades: descripcin informal de las
responsabilidades u objetivos de la operacin
Tipos de datos: conceptos que afecta o clases
Referencias cruzadas: enlaces con otras funciones
del sistema o casos de uso.
Notas: indicaciones para diseo, algoritmos (tal
como el clculo de dgito verificador) y otros datos.
Excepciones: qu sucede si...? y otros casos
excepcionales.
Salida: Mensajes o registros que se envan fuera
del sistema.
Precondiciones: Supuestos acerca del estado del
sistema antes de ejecutar la operacin.
Poscondiciones: Indicacin de como qued el
sistema despus de la operacin.
Poscondicin 1 ...
Poscondicin 2 ...
Poscondicin n ...
Figura 6-11. Forma de un contrato por operacin
Una clave para entender los contratos son las poscondiciones, es decir, como
qued el sistema despus que se ejecut la operacin. Es como la fotografa
que se toma despus de un suceso. Veamos el ejemplo de la figura 6-12 para
nuestro caso de ingreso de orden de compra.
Contrato
Identificacin: Dar OK al ingreso de la lnea
Responsabilidades: con cada ingreso de lnea los
conceptos deben ser consistentes.
Tipos de datos: afecta a los conceptos
Encabezado de O/C y Detalle de O/C.
Referencias cruzadas: no hay
Notas: nada especial
Excepciones: la no existencia de la lnea en el
sistema ya fue validada con el ingreso de O/C.
Salida: no hay
Precondiciones: no existe la lnea.
Poscondiciones:
Se cre una lnea en el concepto detalle.
Se actualiz el contador de lneas en el
encabezado.
Se actualiz la asociacin entre
encabezado y detalle de O/C.
Figura 6-12. Ejemplo de contrato en dar OK ingreso lnea
Se identific, en tiempo verbal pasado, cmo fueron afectados los conceptos

tras la operacin (poscondiciones). Un contrato sin poscondiciones es una
alerta de error, tal vez en la definicin de la operacin.
304 JUAN BRAVO C.
6.3. APLICACIN DE LOS MODELOS UML EN LA

ETAPA DE DISEO
El siguiente ejemplo muestra en la prctica el uso simplificado de los principa-

les modelos de UML en la etapa de diseo75.
Veremos:
1. Diagrama de diseo de clases
1. Diagrama de diseo de clases

El modelo de UML que se emplea para representar las relaciones entre las
clases es el Diagrama de Diseo de Clases. Corresponde a la visin interna de
la aplicacin. Nace desde el modelo conceptual e incorpora las funciones ne-
cesarias para cumplir con el objetivo de los casos de uso. En la figura 6-13 se
observa este diagrama para el ejemplo de la orden de compra.
Proveedores
Encabezado de O/C
Rut
N O/C
contiene existe en Nombre
Fecha
Crear lnea * 1 Crear proveed.
Imprimir Modificar Rut
Modificar nombre
compuesta por 1
se asocia a 1..*

O/C ...
Unidades * 1
Precio
existe en *
Agregar lnea
almacena 1
Bodega
...
Figura 6-13. Ejemplo de diagrama de diseo de clases
75
Ms detalle en el libro Gestin de proyectos de procesos y tecnologa.
Para cada operacin del caso de uso seleccionado se presenta un diagrama de
colaboracin y detalles de implementacin76.
Diagrama de colaboracin: cada operacin detallada en un contrato se
desarrolla en detalle sealando las solicitudes (o pedidos) entre objetos
(principalmente del modelo de datos y pantallas).
Detalles de implementacin: se responde a qu clases podemos utilizar?
Ya sea de la misma instalacin o del medio, es decir, hacer una revisin de
la biblioteca de clases77 (que en un esquema de orientacin a objetos es un
requisito), por ejemplo, la condicin de existencia. Corresponde al detalle
de cada clase e instancias (objetos) especficas en una tabla de diferencias.
En la figura 6-14 se presenta un ejemplo de diagrama de colaboracin para el
ejemplo del ingreso de orden de compra.
Operacin: Dar OK al Ingreso de la lnea de O/C
Ingresar producto 1: Crear lnea de O/C

(cd, cant, pre) (cod, cant, pre)
Terminal del Encabezado
administrativo de O/C
1.1: Crear (cod, cant, pre)

Lneas de la
O/C
Figura 6-14. Ejemplo de diagrama de colaboracin
76
En este mtodo de desarrollo aplicamos la tcnica de espiral, donde se diluye un poco la
independencia de la implementacin tecnolgica, por este motivo se prefiere avanzar en ca-
ractersticas de la implementacin a nivel del diseo.
77
Se supone la existencia de la biblioteca de clases.
306 JUAN BRAVO C.
CAPTULO 7.
HERRAMIENTAS DE LA
TECNOLOGA DE
INFORMACIN
Captulo 7. Herramientas de la tecnologa de informacin
La manera ideal de construir un nuevo sistema es tomar algunos

componentes existentes y conectarlos unos con otros. Por su-
puesto, la conectividad es la propiedad que permite hacer esto.
La metfora sugiere correctamente que esto es slo en parte una
propiedad de los elementos conectados. Los componentes tienen
que ser elementos que completan las necesidades del sistema en
su totalidad. ms que eso, tienen que ser compatibles unos con
otros y esto depende de la presencia de una arquitectura ade-
cuada.
Perdita Stevens y Rob Pooley (2002, p. 15)
Las Herramientas de la Tecnologa de Informacin son todos los productos de

software que permiten aumentar la productividad de especialistas y usuarios.
stas incluyen desde poderosos procesadores de texto hasta sofisticados siste-
mas administradores de bases de datos, pasando por mltiples productos de
ayuda directa a usuarios y especialistas en desarrollo de aplicaciones.
Esta es la sptima competencia considerada para apoyar la elaboracin de
gura (en la introduccin se incluy la visin global de las competencias). El
analista debe tener una visin global de las herramientas de la tecnologa de
informacin y debe conocer en detalle las que apoyan directamente su labor.
Es una responsabilidad profesional para aumentar la productividad del mo-
delamiento y para compartir en equipos de trabajo.
CAPTULO 6. UML

308 JUAN BRAVO C.
En el caso de las herramientas de ayuda en la produccin de software convie-

ne actuar con prudencia, por ah aparecen mensajes del siguiente tipo: es posi-
ble que las aplicaciones se construyan casi solas o que el mismo usuario pue-
da construir su propio software sin depender del programador. Esos y otros
mensajes se demuestran con aplicaciones muy pequeas y estructuradas, ex-
trapolndose las conclusiones al resto del software. Sin embargo, siendo vli-
do, esa es una parte pequea de la realidad, lo habitual es que el especialista
en informtica tenga la responsabilidad de construir aplicaciones de mayor
nivel de complejidad, en las cuales la herramienta ser slo un apoyo y siem-
pre que se pueda integrar al esquema de desarrollo del departamento de siste-
mas en particular.
Para tranquilidad de muchos programadores, hasta hoy no se ha visto el reem-
plazo de un especialista por una herramienta de productividad. S ocurre que
la incorporacin de la nueva herramienta acarrea a veces nuevas contratacio-
nes, debido a la complejidad de su manejo y al aprovechamiento de las nuevas
oportunidades que genera su mayor potencial.
Abordaremos el tema con una introduccin general a los lenguajes de cuarta
generacin, para apreciar la evolucin que deriv en las herramientas de la tec-
nologa de informacin. Luego estudiaremos las herramientas de uso especfico,
es decir, aqullas orientadas a temas precisos, como procesadores de texto, pla-
nillas electrnicas o consultas de bases de datos; algunos productos los pueden
usar directamente los usuarios finales. Despus, revisaremos las soluciones de
software generalizadas, para concluir con las herramientas de apoyo para la pro-
duccin de software, ms conocidas como herramientas CASE.
Veremos:
Evolucin de los lenguajes de computador
Herramientas de uso especfico
Una pirmide de soluciones
Herramientas de apoyo para la produccin de software
7.1. EVOLUCIN DE LOS LENGUAJES DE

COMPUTADOR
El desarrollo de software no ha ido a la par con los espectaculares aumentos en

la rapidez, rendimiento y confiabilidad del hardware. En muchos departamentos
de sistemas todava se trabaja como hace 30 aos en mquinas un milln de
veces ms poderosas que las de esa poca. No obstante, la industria de la com-
putacin ya se percat de este hecho y comenz a desarrollar una amplia varie-
dad de nuevas herramientas, para aumentar la productividad e incorporar al
usuario final en el proceso informtico.
Estas nuevas herramientas fueron agrupadas inicialmente bajo el nombre len-
guajes de cuarta generacin y ms recientemente, se les comenz a llamar
herramientas de productividad, nombre que a veces compite con el de herra-
mientas de desarrollo clienteservidor. Independientemente de las denomina-
ciones, las nuevas herramientas incluyen una amplia variedad de nuevos produc-
tos: procesadores de texto, planillas electrnicas, administradores de bases de
datos, herramientas CASE, Workflow, Groupware y otras. En las siguientes pgi-
nas se presenta una clasificacin ms acabada de estos productos.
El trmino lenguaje de cuarta generacin puede ser confuso, porque da la
idea de un simple lenguaje de programacin ms avanzado. Es decir, resulta
insuficiente para reflejar la riqueza y amplitud de los nuevos productos de
software orientados tanto a usuarios finales como a profesionales de la in-
formtica. De aqu que el ttulo del captulo fuera genrico: herramientas de
la tecnologa de informacin.
Para el desarrollo de estos lenguajes ha sido necesario romper con el criterio de
eficiencia de una aplicacin en cuanto a mnimo uso de tiempo y memoria, lo
cual ya no es tan importante y a futuro ser una consideracin menor, debido al
substancial mejoramiento del hardware. Adems, la participacin del usuario en
el proceso de desarrollo ha estado restringida a reuniones con los especialistas.
Hoy, l puede participar intensamente! Lo ideal es un trabajo de conjunto entre
el usuario y el analista, como apoyo en la especificacin de requerimientos o
trabajando juntos, directamente en el computador.
Crisis del desarrollo

Existe desde los inicios de la computacin una crisis de productividad de las
reas de sistemas, se manifiesta en largas colas de aplicaciones pendientes por
310 JUAN BRAVO C.
desarrollar, las que con frecuencia llegan a representar ms de 5 aos de trabajo.

Desde el punto de vista del usuario ejecutivo, la solucin significa hacer traba-
jar al computador, dejando de lado largas esperas, reuniones, especificaciones y
cambios de especificaciones por obsolescencia de las anteriores.
Es cierto que los nuevos lenguajes ayudan pero la gran respuesta es incorporar
mtodo, tal como vimos en el captulo 1.
Junto con el aumento de la capacidad del hardware, aunque sin coincidir con la
aparicin de nuevas generaciones de computadores caracterizadas por equi-
pos construidos con tubos en la primera generacin, transistores en la segunda y
circuitos integrados en la tercera han surgido varios niveles de lenguajes: de
mquina, simblicos, de alto nivel, de cuarta generacin y lo que hemos llama-
do provisoriamente las nuevas herramientas.
Tambin est en experimentacin lo que denominan una quinta generacin,
donde se estudia la inteligencia artificial. Se espera que los sistemas produci-
dos en esta quinta generacin sean capaces de aprender de sus errores, recono-
cer mensajes incompletos, tomar cierto grado de decisiones y crear sus pro-
pios procedimientos en la resolucin de problemas. La quinta generacin de
lenguajes no ser analizada aqu porque excede los objetivos de este libro;
adems, an est lejos de alcanzar resultados prcticos, porque busca copiar
capacidades humanas, donde intervienen emociones, sensaciones, motivacio-
nes, antecedentes histricos, diversas energas o fenmenos culturales.
En la figura 7-1 estn sealadas a la izquierda las primeras cuatro categoras; la
ltima y ms reciente, las nuevas herramientas, se indica arriba, con puntos sus-
pensivos, porque realmente ignoramos todava su potencial.
Las nuevas herramientas

Groupware o workflow Herramientas cliente/servidor
Imgenes Integracin total
Grficos Generacin de aplicaciones
Bases de datos simples Herramientas CASE
Planillas electrnicas Bases de datos u objetos
Lenguajes Procesadores de textos Ciclo completo de desarrollo
de cuarta
generacin De uso especfico Para construccin de
aplicaciones
Amistosos y Productivos
Cdigo compilado o interpretado

Lenguajes Bajo nmero de instrucciones
de alto nivel COBOL/FORTRAN/C
Muy poderoso
Portable
Cdigos de instruccin simblicos

Lenguajes Uso de smbolos para variables
Simblicos Compilacin
Macros
Muchas instrucciones
Lenguajes de Mapa de memoria
mquina Ejecutable
OFF
ON
Figura 7-1. Clasificacin de lenguajes de computador
Veremos:
1. Lenguajes de mquina
2. Lenguajes simblicos
3. Lenguajes de alto nivel
4. La cuarta generacin de lenguajes
5. Las nuevas herramientas
312 JUAN BRAVO C.
1. Lenguajes de mquina
A este nivel, la programacin se realiza trabajando primero en binario y ms
adelante en hexadecimal, hasta llegar a usar nemotcnicos. Se controla cada
variable segn su posicin en memoria, lo cual obliga a mantener un mapa del
uso de memoria.
El lenguaje de mquina se caracteriza por proporcionar un conjunto de muchas
instrucciones elementales. Por ejemplo, un programa simple tendr probable-
mente varios miles de instrucciones, producto de la desagregacin con que obli-
ga a programar el lenguaje; la simple operacin C = A + B utiliza entre cinco a
diez sentencias.
El programa producido con el lenguaje de mquina viene a ser un objeto que se
ejecuta directamente, sin un proceso de compilacin. Provee mxima eficiencia,
porque el uso de recursos puede minimizarse y porque es extremadamente cer-
cano a la mquina, no existiendo portabilidad, excepto para procesar en otro
computador con el mismo procesador.
2. Lenguajes simblicos
Son lenguajes tipo ASSEMBLER DE IBM o NEAT/3 de NCR, mediante los cuales se
obtiene un avance substancial al lograr referenciar una variable por smbolos,
haciendo abstraccin de su ubicacin en memoria. El programador utiliza
cdigos de instruccin simblicos, donde cada uno es un nemotcnico de la
propia funcin de la instruccin (por ejemplo: en ASSEMBLER IBM, AGO es un
salto incondicional y AIF es un salto condicional).
Se incorpora tambin al lenguaje simblico el concepto de subprograma.
Una extensin de este lenguaje son las macros, las cuales son conjuntos de ins-
trucciones que pueden ser llamadas desde cualquier programa. Permiten realizar
funciones de entrada de datos, impresin y otras. Por medio de las macros, el
lenguaje simblico se acerca bastante al lenguaje de alto nivel.
Aunque la portabilidad es substancialmente mayor que en los lenguajes de
mquina, an el lenguaje simblico est muy ligado al hardware particular don-
de reside.
Para ser ejecutado, el programa en lenguaje simblico debe ser compilado, ob-
tenindose un programa objeto en lenguaje de mquina que todava es bastante
eficiente en cuanto al uso de recursos, porque el programa fuente no est dema-
siado lejos del programa objeto.
3. Lenguajes de alto nivel

Los lenguajes de alto nivel se desarrollaron como respuesta a la excesiva de-
pendencia de la mquina que presentaban los lenguajes simblicos y para evi-
tar la intervencin de un intermediario entre el usuario y el computador. Los
lenguajes de mquina y simblicos son muy complejos y la programacin es
lenta, lo que obliga a utilizar los servicios de un especialista. Esto se pretenda
evitar con los lenguajes de alto nivel, porque podran ser aprendidos por el
propio usuario para desarrollar sus aplicaciones; en la prctica, esto no suce-
di en las aplicaciones administrativas y fue necesario contar con especialistas
en lenguajes de alto nivel.
Los lenguajes de alto nivel estn mucho ms cerca del usuario que los lenguajes
de mquina y simblicos. Sin embargo, incorporan una lgica extraa y poco
natural que dificulta la programacin por parte del usuario, quien, si insiste en
programar, debera pasar algunos exmenes de aptitud, seguir algunos cursos y
luego practicar; perodo que podra ser muy largo. La dificultad no se produce
por el aprendizaje del conjunto de instrucciones del lenguaje, sino que por la
estructuracin de la lgica de procesamiento.
En general, los lenguajes de alto nivel se orientan a determinados tipos de pro-
blemas. Por ejemplo, FORTRAN para aplicaciones cientficas y COBOL para apli-
caciones comerciales. Normalmente, las instrucciones son bastante poderosas.
Una caracterstica clave de los lenguajes de alto nivel es su portabilidad o la
posibilidad de trasladar el programa desde un computador a otro. En la prctica,
la portabilidad total se ha dado solamente entre diferentes modelos de un mismo
fabricante y cuando se desea trasladar el programa a un computador de otro fa-
bricante, la portabilidad se ve afectada por las particularidades introducidas al
lenguaje y por su difusin, porque el lenguaje podra no estar disponible en esa
lnea de equipos. Se han desarrollado ms de 100 lenguajes de alto nivel y no
ms de 10 se han generalizado78; entre ellos se encuentran: COBOL, FORTRAN,
RPG, PL/1, BASIC, C, PASCAL Y CLIPPER.
78
En lo que se refiere a las grandes aplicaciones administrativas y pese a muchas predicciones
en contra, el lenguaje ms comn ha sido COBOL. Es posible que siga sindolo por muchos
aos, por la gran cantidad de cdigo acumulado, su universalidad y nuevas versiones que
incorporan conceptos tales como orientacin a objetos e interfaces grficas. Le siguen de lejos
RPG, algunas versiones de BASIC, CLIPPER, C y C++.
En general, la estructuracin de lgica en los lenguajes de alto nivel ha sido muy personal
por no decir anrquica, lo cual ha contribuido a reducir an ms la portabilidad y ha dado
origen al estudio de tcnicas para mejorar la lgica de construccin del programa y dar pa-
314 JUAN BRAVO C.
Habitualmente los lenguajes de alto nivel se han clasificado entre lenguajes

compilados (COBOL O FORTRAN) y lenguajes interpretados (BASIC).
Lenguajes Compilados: se les denomina de esta manera porque el cdigo
construido por el programador (programa fuente) pasa por un compilador
(producto de software) que lo transforma en cdigo que entiende el compu-
tador (programa objeto). Normalmente, el lenguaje de mquina generado es
optimizado por el compilador (por ejemplo, se crean tablas en memoria y se
eliminan repeticiones) para disminuir el tiempo de ejecucin y para utilizar
mejor los recursos del sistema operativo.
Lenguajes Interpretados: esta denominacin proviene del trmino interpre-
tacin como sinnimo de traduccin simultnea entre diferentes idiomas.
Esto significa que el cdigo construido por el programador no est traducido
de antemano, sino que al momento de la ejecucin del programa se traduce y
se procesa cada instruccin. Aqu existe solamente el programa fuente. Es
menos eficiente que el programa objeto, porque no se puede optimizar el
cdigo y debe traducir-ejecutar cada vez que el programa se llama a ejecu-
cin. Tiene como ventaja que el programador ve su programa funcionando
inmediatamente, lo que facilita la construccin y la mantencin del cdigo.
4. La cuarta generacin de lenguajes

Con el advenimiento de las herramientas de cuarta generacin hubo una aper-
tura de la informtica hacia los usuarios, quienes pudieron resolver directa y
rpidamente variadas necesidades.
Hasta hace un tiempo, el esquema predominante para el desarrollo de software
haba sido crear un departamento centralizado de informtica, en el cual se con-
centraban los especialistas encargados del desarrollo de nuevas aplicaciones y
de la mantencin de las antiguas. Este esquema de trabajo hizo crisis.
Qu sucedi? Al principio los usuarios observaron cautamente la introduccin
del computador en la empresa y slo se incorporaron los sistemas ms importan-
tes y tradicionales, como cuentas por cobrar, cuentas por pagar, inventarios,
contabilidad y remuneraciones. Al mismo tiempo, en los usuarios exista un
gran desconocimiento del computador y de las tcnicas empleadas por los espe-
cialistas, no exento de un cierto grado de temor y admiracin. Sin embargo,
cuando el usuario aprendi a sacar provecho del computador y observ que dis-
trones de programacin; como la programacin estructurada o la programacin prctica

(ambas expuestas en el libro Desarrollo de sistemas de informacin, una visin prctica).
pona de terminales, se dio cuenta de la gran potencialidad que esto significaba y

pidi nuevas aplicaciones. Y aqu comienza la crisis, porque el departamento de
sistemas no logr dar respuesta rpida a sus requerimientos. Es ms, se fue
acumulando cada vez mayor cantidad de aplicaciones sin desarrollar, llegando a
producirse una cola de trabajos pendientes que alcanzaba a varios aos. De esta
manera, muchos usuarios comenzaron a mirar con escepticismo al departamento
de sistemas, porque no daba respuesta oportuna a sus requerimientos.
Un problema adicional fue la prdida de vigencia de algunas aplicaciones en la
cola, porque el entorno actual de la potencial aplicacin era diferente al origi-
nalmente considerado.
Otro problema fue el atraso invisible que se produca cuando los usuarios pre-
feran no solicitar algunas aplicaciones, porque lo estimaban una prdida de
tiempo dados los excesivos tiempos de respuesta. El atraso invisible llegaba a
ser tan largo como la cola de trabajos pendientes.
En este contexto, mientras el usuario observaba su terminal y pensaba en sus
aplicaciones largamente postergadas, se entiende su sentimiento de impotencia
por poner a trabajar el computador inmediatamente en lo que l necesitaba.
Se puede apreciar en esta introduccin cmo fue creciendo la demanda por nue-
vas herramientas destinadas a incorporar al usuario en el proceso de desarrollo y
aumentar la productividad en la construccin de sistemas.
La respuesta fueron los Lenguajes de Cuarta Generacin, los cuales pueden
clasificarse en dos grandes reas: herramientas de uso especfico y lenguajes
para construccin de aplicaciones. Ambas tienen las caractersticas clave de
amistosidad y productividad. Amistosidad, para incorporar a los usuarios en el
proceso de desarrollo; y productividad, para aumentar, al menos en 10 veces, el
rendimiento en el desarrollo de software.
Por incorporar a los usuarios en el proceso de desarrollo entendemos incre-
mentar substancialmente su nivel de participacin y que entienda el por qu
del desarrollo. No es la idea que programe o arme un sistema, excepto tal vez
en las aplicaciones ms pequeas y con apoyo de una buena herramienta.
5. Las nuevas herramientas

Al comienzo del uso de los lenguajes de cuarta generacin, distinguamos
entre las herramientas de uso especfico y aqullas orientadas a la produccin
de software en que las primeras no tenan una capacidad procedural y las se-
gundas s. Hoy, tanto las herramientas de uso especfico como los productos
orientados a la construccin de aplicaciones tienen la caracterstica clave de
316 JUAN BRAVO C.
especificar en forma procedural y no procedural. Procedural se refiere a es-

tructurar lgica, como en COBOL o PASCAL. Es decir, cuando la funcionalidad
va mens no alcanza para resolver un requerimiento, entonces se utiliza un
lenguaje de alto nivel: husped, como los indicados, o propio, en este caso con
su particular conjunto de instrucciones. Es el caso de la mayora de las macros
que uno puede construir en un administrador de bases de datos, una planilla
electrnica e, incluso, en los actuales procesadores de texto. No procedural se
refiere a resolver un requerimiento a travs de mens o comandos directos, sin
programar.
La posibilidad de agregar lgica en cualquier herramienta le permite aumentar
notablemente su productividad y da la oportunidad a interesados y especialistas
de desarrollar toda su potencialidad.
La caracterstica clave de las nuevas herramientas de la tecnologa de informa-
cin es la integracin total. Esto significa que todos los productos de la instala-
cin se comunican plenamente entre s y comparten los mismos recursos. De
esta manera, el usuario simplemente usa las herramientas y navega libremente
entre ellas. De hecho, es muy posible que veamos en el futuro cercano grandes
productos que integren armoniosamente: automatizacin de oficinas79, bases de
datos, workflow, construccin de aplicaciones y administracin de proyectos.
Es importante aclarar que la decisin de incorporar una herramienta integrada de
la tecnologa de informacin tiene directa relacin con el grado de preparacin
previa de la organizacin, en cuanto a organizacin, normalizacin interna y
externa o participacin de los usuarios. Adems, hay que tomar en cuenta el
problema de la conversin de datos desde aplicaciones antiguas, el cual es tan
importante que algunos proyectos han fracasado porque sus patrocinadores lo
han subestimado.
Cul es el futuro de los nuevas herramientas de la tecnologa de informacin?
En este momento hay una verdadera avalancha de herramientas y se estn pro-
bando muchas opciones. Por ejemplo:
Se intensificar la orientacin total al usuario, con interfaces cada vez ms
amistosas, haciendo uso intensivo de ventanas, conos, colores y mucha sim-
plicidad, para hacer no slo ms fcil el trabajo sino tambin ms atractivo.
Se avanzar mucho ms hacia la integracin total, especialmente entre las
herramientas CASE y los sistemas administradores de bases de datos, los cua-
79
Como ejemplo de esta tendencia, obsrvese la integracin del producto MS Office para
Windows, el cual incluye Word, Powerpoint, Excel, Access, Outlook y otras aplicaciones.
les tendrn incorporadas o poseern buenas interfaces a grficos, planillas

electrnicas, procesamiento de imgenes, almacenamiento de voz, procesa-
miento de texto, transmisin de datos. En lugar de diccionario de datos, co-
menzaremos a escuchar con mayor frecuencia el trmino enciclopedia, o dic-
cionario de conocimiento, el cual incluira no slo caractersticas de datos,
sino tambin formatos de pantallas e informes; capacidades lgicas para
hacer algn tipo de inferencia, buscar recorridos ptimos en consultas o apo-
yar la normalizacin de diseo.
La portabilidad se ver notablemente aumentada, ya que podremos trabajar
con las nuevas herramientas en redes y con variados sistemas operativos:
DOS, UNIX, OS/2, Windows, etc. Con las nuevas herramientas de la tecnologa
de informacin se estara logrando lo que no se consigui a travs de los sis-
temas operativos generalizados, es decir, atravesar horizontalmente las dife-
rentes plataformas de hardware y software.
Disminuir la necesidad de programacin tradicional en el desarrollo de
software; se estima que menos del 3 % del cdigo total de una aplicacin
ser incorporado por el desarrollador, la mayor parte ser generado automti-
camente o se aplicar cdigo reutilizable. Hoy, sin tener que programar, ya es
posible pintar pantallas, generar informes, realizar operaciones de actualiza-
cin entre entidades o efectuar mltiples clculos. Al mismo tiempo, se in-
crementar la necesidad del buen diseo de las aplicaciones.
Esto depende en gran medida de la complejidad de la aplicacin. Si es muy
simple, probablemente no se requiera aportar cdigo, excepto instrucciones
muy precisas en puntos bien determinados. Si la aplicacin es muy comple-
ja, probablemente la herramienta ayudar a definir prototipos con informes,
pantallas, consultas y otros mdulos bsicos que no representan ms all
del 50 % de la aplicacin, todo el otro 50 % deber ser programado, aun-
que no es problema si se realiza en forma de clases. Resulta evidente que
entre esas posibilidades hay muchas situaciones intermedias.
318 JUAN BRAVO C.
7.2. HERRAMIENTAS DE USO ESPECFICO
Algunas herramientas de uso especfico son:

Procesadores de texto
Planillas electrnicas
Administradores y evaluadores de proyectos
Lenguajes de apoyo a la toma de decisiones
Generadores de informes
Generadores de grficos
Diseadores de pantallas
Lenguajes de consulta, tipo QUERY
Lenguajes de definicin y manipulacin de datos en Bases de Datos
Automatizadores de anlisis y diseo
Paquetes generalizados orientados a algn tipo de problemas
Este es un libro sobre modelos de aplicaciones computacionales, qu relevan-
cia pueden tener las herramientas de uso especfico sobre el desarrollo de soft-
ware? Bsicamente en dos aspectos:
El primero es la disminucin en la necesidad de construir software de uso
general, lo cual se puede estimar al menos en un 70%, producto de las mayo-
res potencialidades de las herramientas. Por ejemplo, hoy, con un simple
procesador de palabras puede ordenar textos, efectuar clculos, imprimir eti-
quetas o manejar eficientemente una base de datos simple. Hace algunos
aos, para satisfacer esos requerimientos, era necesario construir sistemas
computacionales pequeos que podan ocupar un mes de programacin y lo
mismo es vlido con el uso de graficadores o planillas electrnicas.
En segundo lugar, algunas herramientas de uso especfico ayudan directa-
mente en la produccin de software a travs de la automatizacin de las va-
riadas y rutinarias labores asociadas a la produccin de software, por ejem-
plo: pintar una pantalla, ordenar una tabla, comunicar informacin, realizar
seguimiento del proyecto, modelar los datos y comunicar el modelo a una ba-
se de datos.
Veremos:
1. Herramientas integradas para automatizacin de oficinas
2. Groupware
3. Workflow
1. Herramientas integradas para automatizacin de oficinas

Todava no hemos calibrado el impacto de los nuevos productos integrados de
automatizacin de oficinas. Con ellos se reduce la necesidad de construir sis-
temas computacionales con personal especializado, quienes pueden ahora des-
tinar su tiempo a las aplicaciones ms complejas y del negocio.
Todos los productos indicados han evolucionado a niveles extraordinarios en las
nuevas versiones. Considere solamente las facilidades del MS Word80:
Opera en el sistema operativo Windows
Est disponibles en varios idiomas, con buenas adaptaciones (ms
que slo traduccin)
Tiene herramientas de dibujo
Manejo de tablas
Buenos aportes de edicin
Impresin automtica de sobres y etiquetas
Con las otras herramientas ocurre lo mismo, por ejemplo, ACCESS, de Microsoft,
se est transformando en uno de los productos ms vendidos81 no slo para in-
teractuar con bases de datos, sino tambin para desarrollar.
2. Groupware
Durante este perodo tambin surgieron las herramientas para trabajo de gru-
po, tipo Groupware, tambin llamadas Workgroup. stas, adems de permitir la
comunicacin entre los miembros de un grupo, tal como lo hara un correo
electrnico, tambin permiten compartir documentos y hacer una construccin
conjunta de proyectos, con una coordinacin central e integrando multimedia,
son productos tales como NOTES, de Lotus o el mismo Outlook de Windows.
Por ejemplo, en evaluacin de proyectos, hoy es posible que un equipo se co-
ordine para obtener promedios grupales de ponderacin de factores de deci-
sin, los que antes dependan slo de la buena fe de algn profesional aislado.
80
Impresiona que antes de este tipo de procesadores debamos construir algn pequeo siste-
ma computacional para dar respuesta a cualquiera de estas facilidades y a otro costo.
81
Un dato: en los primeros 7 meses de venta de la versin 2.0 de Access, en Estados Unidos
se vendieron 3 millones de copias, principalmente a usuarios finales.
320 JUAN BRAVO C.
3. Workflow
La tecnologa de flujos de trabajo, Workflow, permite automatizar un flujo de
trabajo y es un buen complemento para la tendencia actual de identificar y
redisear los procesos del negocio. Ejemplos de este tipo de productos son:
XNEAR, Lotus Notes y Workflow de IBM.
Para cumplir el objetivo de un proceso, generalmente se requieren diversas acti-
vidades realizadas por diferentes personas en distintas unidades organizaciona-
les. Workflow automatiza ese flujo y administra la ubicacin y avance de cada
tarea. Naturalmente, exige que todos los participantes tengan el equipamiento
apropiado, generalmente algn esquema con redes de computadores.
Desde el punto de vista de la reingeniera de negocios, en particular aplicando el
concepto de generalizacin de procesos, sera conveniente que antes de automa-
tizar el proceso, con o sin una herramienta Workflow, se evaluaran otras opcio-
nes, por ejemplo82:
Eliminar o externalizar el proceso completo.
Agrupar todas las actividades para que las realice una sola persona (con-
cepto de integralidad de la gestin de procesos). De esta forma, en lugar de
tener una especie de lnea de produccin con cargos especializados, cada
uno de los mismos participantes puede realizar el proceso completo, tal vez
orientndose a determinados tipos de procesos.
Agrupar las actividades del proceso para que un equipo de personas las reali-
ce en la misma ubicacin.
Con las herramientas tipo Workflow se tiende a eliminar los documentos manua-
les y hacer todo el trabajo directamente en el computador. Por ejemplo, opera-
ciones crediticias o de ventas. El nivel de amistosidad de estas herramientas
debe ser muy alto, porque sern empleadas por la mayora de los usuarios de la
organizacin.
82
Estas y otras posibilidades se estudian en los libros Reingeniera de negocios y Gestin de
procesos.
7.3. UNA PIRMIDE DE SOLUCIONES
Es frecuente observar una pirmide como la que se presenta en la figura 7-2.

Es cierto que es una pirmide de alto costo, sin embargo, cada da es ms ne-
cesaria en las organizaciones.
BI
Data Warehouse
SRM ERP CRM
Motor de base de datos
Sistema operativo y lenguajes
Figura 7-2. Una pirmide de soluciones
Veremos cada una de las capas de esta pirmide, comenzando desde arriba.
1. BI
BI (Business Intelligence, en espaol inteligencia de negocios) consiste en
analizar los datos de las bases de la empresa para elaborar informes, encontrar
tendencias y buscar dimensiones de los datos, entre otros servicios.
Para que esto sea posible es necesario trabajar en sensibilizar y capacitar para
que los usuarios se hagan cargo de la toma de decisiones relacionada con este
anlisis. Por ejemplo, un tipo de herramienta en que se pueden preparar en los
aspectos estadsticos del estudio de datos.
Por supuesto, la informacin a usar en los anlisis debe estar disponible y ser
posible de acceder.
Algunos tipos de soluciones BI son:
Consultas e informes simples
Cubos OLAP (On Line Analytic Processing)
Data Mining o minera de datos
Una implementacin es instalar la solucin BI sobre un Data Warehouse.
322 JUAN BRAVO C.
2. Data Warehouse
Data Warehouse se traduce como almacn de datos y se refiere a un conjunto
de datos organizado de cierta forma y permanentemente actualizado que ayuda
a la toma de decisiones de la empresa.
Lo habitual es instalar el Data Warehouse sobre el procesamiento transaccio-
nal, generalmente un ERP que usa algn motor de bases de datos (los veremos
en los siguientes puntos).
Un aspecto importante es separar los datos operacionales (que residen en el
motor de bases de datos) de los datos en el esquema Data Warehouse, los cua-
les tendrn una estructura normalizada de acuerdo con el tipo de anlisis que
se quiera realizar. Esto significa incorporar un proceso automtico de traspaso
de informacin.
3. ERP
Los productos ERP (Enterprise Resource Planning, en espaol, sistemas de
planificacin de recursos empresariales) administran e integran las transaccio-
nes operacionales de la organizacin, por ejemplo: cotizaciones, pedidos,
compras, produccin, distribucin, facturacin, contabilidad, personas y co-
branza. De esta forma, cuando, por ejemplo, se produce una venta, el sistema
explota una serie de transacciones a contabilidad, bodega o produccin. Se
evita as su ingreso independiente.
Los sistemas ERP derivan desde los antiguos software de Planificacin de
Recursos de Manufactura (MRP II) y de la Planificacin de Requerimientos
de Material (MRP).
En variadas implementaciones, los sistemas ERP se relacionan con dos tipos
de productos: uno cercano al consumidor (CRM) y otro cercano a los provee-
dores (SRM).
4. CRM
Los productos CRM (Customer Relationship Management, en espaol, ges-
tin de la relacin con los clientes) ayudan en la integracin con clientes pro-
porcionando un entorno tecnolgico para una relacin ms personalizada (ob-
servan historial de contactos, de ventas, hbitos y mucho ms). Se puede ver
tambin como un modelo de gestin que se orienta al cliente y que se mani-
fiesta en el marketing relacional.
Es una herramienta del tipo B2C (Business to Consumer, o comercio desde las
empresas al consumidor).
5. SRM
Los productos SRM (Supplier Relationship Management, en espaol, gestin
de la relacin con los proveedores) ayudan en la gestin de las relaciones con
los proveedores. Buscan integracin a travs del software, por ejemplo, para
que un proveedor de materias primas vea el saldo de productos en la bodega
de la empresa y genere una reposicin automtica.
Es una herramienta del tipo B2B (Business to Business, o comercio electrni-
co entre empresas).
6. Motor de base de datos

Aqu se puede referenciar el enfoque de bases de datos del captulo 4, en todo
caso, hablamos de sistemas administradores de bases de datos tales como:
Oracle, Informix, Sybase, Progress, SQL Server, DMS e Ingres.
324 JUAN BRAVO C.
7.4. HERRAMIENTAS DE APOYO PARA LA

PRODUCCIN DE SOFTWARE
Las herramientas de la tecnologa de informacin para la produccin de softwa-

re, tambin llamados productos orientados a la construccin de sistemas com-
putacionales, son aqullas que permiten apoyar todo o una parte del mtodo de
desarrollo. Se las conoce mejor como herramientas CASE.
Las herramientas C.A.S.E. (Computer Aided Software Engineering, sigla que en
espaol significa ms o menos: ingeniera de software con apoyo computacio-
nal) son un soporte automtico o semiautomtico para los mtodos de desarrollo
de software; una definicin ms amplia podra ser: las herramientas CASE ayu-
dan en todo o parte del diseo, construccin y mantenimiento de un proyecto de
software. Por ejemplo, apoyan total o parcialmente en:
Modelamiento de datos
Modelamiento de funciones
Orientacin a objetos
Diseo estructurado
Diagramacin de estructuras
Diseo de informes y pantallas
Prototipos
Administracin de bases de datos
Generacin de cdigo en diferentes lenguajes
Generacin de documentacin
Generacin de datos de prueba
Mantencin y regeneracin de sistemas
En cierta medida, el concepto CASE naci de la urgencia por solucionar el pro-
blema de la productividad en el desarrollo de software.
Tal como vimos en el captulo segundo, el incremento de productividad no se
obtiene automticamente con la introduccin de alguna herramienta. Entre
otros aspectos, tambin influyen la normalizacin, la aplicacin de buenos
mtodos y la participacin del usuario.
Al interior de la empresa un pequeo grupo de ejecutivos, de muy poca disponi-
bilidad de tiempo, poseen el conocimiento preciso sobre los objetivos y planes
de la organizacin, as como de la forma de llevarlos a cabo. Este conocimiento
es la base para plantear sistemas computacionales que ellos pueden ayudar a
desarrollar. Sin embargo, se han encontrado con las dificultades propias del de-
sarrollo tradicional de aplicaciones, tales como atrasos, colas de espera, materias
difciles, programacin muy lenta y dificultad de retroalimentacin. Esto los ha
desalentado y han dejado la iniciativa a especialistas en computacin, quienes
no poseen la misma visin del negocio, agudizndose as el problema.
Con el enfoque CASE se pretende que los usuarios participen directamente en el
desarrollo, en conjunto con los especialistas, siguiendo estos dos pasos:
1. Modelar la realidad a travs de mtodos simples y con apoyo computacio-
nal, de tal forma que el modelo producido se pueda seguir perfeccionando
a travs del tiempo por los mismos u otros desarrolladores.
2. Llevar los modelos a aplicaciones concretas con el apoyo de herramientas
de productividad.
Al hacerlo de esta manera, cada solucin queda registrada automticamente y es
un patrimonio de la organizacin, porque es independiente de las personas que
la desarrollaron y puede ser sucesivamente mejorada. Esta es una inversin en
inteligencia.
Algunas caractersticas relevantes de las herramientas CASE son las siguientes:
Tienen la doble orientacin de productividad y amistosidad.
Sirven a un mtodo para el ciclo completo de desarrollo o para una o ms
etapas especficas.
Proveen la posibilidad de integracin entre diferentes etapas.
Permiten uniformar diseos, documentacin y construccin al interior de la
empresa.
En la construccin de aplicaciones mayores es posible modularizar y coor-
dinar el trabajo de diferentes desarrolladores.
El usuario y el analista se concentran en lo verdaderamente importante:
definir los requerimientos.
Es posible obtener una visin de conjunto de un proyecto modularizado.
Se provee en forma automtica una completa normalizacin de smbolos.
Las herramientas CASE se pueden clasificar en UPPER CASE y LOWER CASE,
dependiendo de si apoyan las etapas superiores o inferiores del ciclo de vida
del proyecto, respectivamente. A veces se incluye otra clasificacin para los
productos en el segmento intermedio, denominada MIDDLE CASE, es menos
utilizada.
En la figura 7-3 podemos apreciar las dos clasificaciones principales.

326 JUAN BRAVO C.
Herramienta Etapas que apoya
Upper CASE Definicin de

requerimientos de Diseo
Lower CASE Construccin
Mantenimiento
Figura 7-3. Herramientas Upper CASE y Lower CASE
Veremos:
1. Herramientas tipo UPPER CASE
2. Herramientas tipo LOWER CASE
3. Herramientas de productividad en ambiente cliente servidor
1. Herramientas tipo UPPER CASE

Tal como se aprecia en la figura 7-3, las herramientas UPPER CASE apoyan las
etapas superiores del desarrollo de software; concretamente la definicin de
requerimientos y el diseo. Con la automatizacin de la obtencin de diagra-
mas de diseo se pueden hacer revisiones ms precisas, reproducciones y es
posible ensayar otras opciones de modelamiento.
Ejemplos de herramientas en este nivel seran System Architect y ERWIN. En
ambos casos es posible traspasar directamente las definiciones a un sistema ad-
ministrador de bases de datos.
De acuerdo con la tendencia de interfaces simples y naturales, se espera que la
definicin de requerimientos y el diseo de las aplicaciones se efecte a partir de
los documentos que utiliza y entiende el usuario.
2. Herramientas tipo LOWER CASE

Las herramientas tipo LOWER CASE apoyan las etapas inferiores del desarrollo
de software, especialmente la construccin y el mantenimiento del sistema.
Estas etapas del desarrollo se ven notablemente simplificadas cuando las co-
rrecciones y el perfeccionamiento de la aplicacin se realizan a nivel de una
especificacin y no directamente en el cdigo de los programas.
La herramienta debera entregar como resultado una completa documentacin
de la aplicacin. Qu se documenta? Todo, especialmente:
La especificacin completa del sistema; todas las clases y objetos con el

detalle de los modelos de datos y funciones.
El esquema de mens de la aplicacin para usuarios finales, incluyendo las
ayudas en lnea.
Las herramientas LOWER CASE se clasifican en los siguientes tipos:
Generadores de programas: son productos que permiten generar programas
individuales: de impresin o de ingreso de datos. Habitualmente el programa
se construye sobre una estructura predefinida, como en el caso de COGEN y
GENCOB. Los programas generados pueden ser intervenidos en el mismo len-
guaje que se construyeron.
Generadores de aplicaciones: en los generadores de aplicaciones existe un
equilibrio entre procesos y datos, a diferencia del generador de programas.
Un generador de aplicaciones puede dar origen a uno o varios programas,
segn su filosofa, pero siempre va a crear automticamente un entorno pa-
ra: manejar tablas, administrar una bitcora de uso de la aplicacin, iniciali-
zar o reconstruir entidades, seguridad o mens. El generador de aplicaciones
puede tener o no un sistema administrador de bases de datos; en caso de no
tenerlo, es posible simular algunas de sus facilidades definiendo nuevas fun-
ciones. Ejemplos de lenguajes en esta categora son Synon/2, Genexus, Ge-
nial83, Escultor y CASE/AP. Aqu ya es posible completar algunas aplicaciones
muy simples sin llegar a programar, aunque es posible agregar funcionalidad
a travs de un lenguaje de alto nivel, husped o propio.
Herramientas de productividad en los sistemas administradores de bases de
datos (SABD): tambin es posible encontrar en los SABD herramientas inte-
gradas o mdulos opcionales para apoyar la produccin de software.
Algunos SABD proveen un buen manejo para la estructuracin y consulta
de datos en las bases de datos, como DBASE III, TOTAL, INFORMIX U ORACLE
sin SQL-PLUS, pero el apoyo es bajo para construir funciones de las aplica-
ciones computacionales: actualizaciones, clculos o informes con diferen-
tes cortes de control. En estos casos, habitualmente es necesario programar
esas funciones usando algn lenguaje de alto nivel del SABD, ya sea hus-
ped o propio.
Existen poderosos sistemas administradores de bases de datos que integran
gran parte de las caractersticas de las herramientas de la TI, por ejemplo:
83
El autor construy esta herramienta a mediados de los 80, originalmente con nombre Bra-
vo/2 L4G.
328 JUAN BRAVO C.
pintores de pantallas e informes, generacin de grficos, manipulacin de

planillas electrnicas, automatizacin de oficinas (procesador de palabras,
correo electrnico, generador de formularios, directorio telefnico, calcula-
dora, calendario y borrador), digitalizacin de imgenes, ayudas en todo el
ciclo de desarrollo (evaluacin y control del proyecto, anlisis, diseo y
construccin), ayudas en la toma de decisiones (anlisis de sensibilidad),
clculos matemticos y financieros u operacin en tiempo real. Algunos
SABD que estn o podran estar en esta categora son: PACE, ORACLE con
SQL PLUS, Sybase, Ingres, Progress y otros.
Las herramientas Lower Case tambin se distinguen entre las que usan cdigo
reutilizable y las que generan cdigo fuente a la medida.
Veamos cada una de ellas:
Sistemas de cdigo reutilizable
Los sistemas de cdigo reutilizable son especificados a travs de mens que, en
lugar de generar programas fuente, crean un diccionario de referencias a partir
de los diccionarios de datos y de funciones, desde donde el software toma los
parmetros para la ejecucin de la aplicacin. En el diccionario de referencias se
incluyen elementos tales como: nombre del campo, largo del campo, ubicacin
del campo dentro de la tabla, nombre de la funcin y men dnde se encuentra.
Como en el caso de los lenguajes de alto nivel, de tipo intrprete, donde por
cada instruccin se realiza un proceso de traducir-ejecutar, aqu tambin se re-
quiere un proceso de interpretacin, aunque no de instrucciones fuentes, sino
de las tablas del software. Ante un requerimiento del usuario, el cdigo reutili-
zable hace uso del diccionario de referencias para manipular o seleccionar in-
formacin de las bases de datos de la aplicacin, habitualmente almacenada bajo
estructuras de datos propias del producto.
Algunas caractersticas de estas herramientas son:
No son muy rpidas ni eficientes en el manejo de grandes volmenes de
datos.
No liberan la aplicacin, porque siempre debe estar presente el software.
Habitualmente son de manejo bastante sencillo.
Normalmente son autosuficientes, es decir, no requieren de otro software
para procesar (como un lenguaje husped tipo COBOL, CLIPPER o C).
Es difcil y a veces imposible, agregar ms funcionalidad a la aplicacin adi-
cionando cdigo. La caracterstica procedural es limitada.
Considerando el dinamismo en el desarrollo de productos de cuarta generacin y
la gran interrelacin entre ellos, es difcil encontrar herramientas puras en esta
categora, algunas excepciones podran ser DBASE III y GENERATOR. No obstante,

es frecuente que herramientas mayores, como Fourth Dimension, Genexus,
PACE y otras, permitan ver un prototipo de la aplicacin bajo este esquema.
Sistemas de cdigo fuente
Los sistemas de cdigo fuente son generadores de cdigo en lenguajes de alto
nivel. A partir de la definicin almacenada en los diccionarios de datos y fun-
ciones de la herramienta CASE, se construyen automticamente los programas
fuentes de la aplicacin, en:
Lenguaje husped, tipo COBOL, PASCAL, C o CLIPPER, quedando a disposicin
del usuario para ser intervenidos.
Lenguaje propio, tambin quedan a disposicin del usuario para ser inter-
venidos.
Lenguaje propio o husped, no pueden ser intervenidos directamente por el
usuario, sino que se agrega lgica a travs de procedimientos especiales.
Esta lgica queda almacenada y luego es intercalada automticamente en
los programas. Es el caso, por ejemplo, de Supprix, Genexus y CASE/AP
en el mercado latinoamericano.
Ante un requerimiento del usuario, los programas de la aplicacin manipulan o
consultan informacin directamente en los repositorios de datos de la aplica-
cin: clientes, artculos o facturas. Esto permite que la eficiencia de este tipo de
sistemas sea mayor que el anterior y sin limitaciones para procesar grandes
volmenes de informacin. Adems, cualquier ineficiencia puede ser rpida-
mente resuelta con la posibilidad abierta de aportar cdigo.
Los productos que generan cdigo fuente son los ms habituales en el mercado
de las herramientas CASE, por ejemplo: CASE/AP, LINC y GENEXUS.
3. Herramientas de productividad en ambiente cliente servidor

Estas herramientas se caracterizan por proporcionar un acabado ambiente
grfico y proveen capacidades en programacin orientada al objeto. Algunos
ejemplos: Gupta (o Centura), PowerBuilder, Delphi, 4D y Visual Basic.
Cul es el aporte de estas herramientas? No debemos olvidar que el esquema
cliente servidor nace como una forma de apoyar la construccin descentrali-
zada de aplicaciones. El esquema tpico son grandes instalaciones con un de-
partamento de sistemas centralizado que no alcanza a atender los requerimien-
tos de importantes reas de la empresa; por ejemplo, de la gerencia de ventas
330 JUAN BRAVO C.
donde trabajan 300 personas o del departamento de produccin, con 800 em-
pleados. Tpicamente, ellos cuentan con soluciones locales.
En este contexto resulta razonable que las gerencias de ventas y produccin
quisieran resolver sus necesidades de aplicaciones a travs de la formacin de
pequeas unidades de informtica, con especialistas en diseo y construccin,
los cuales contaran con herramientas que se comunicarn con la base central
del rea de sistemas.
Ah est el pleno aprovechamiento de la potencialidad de estas herramientas!
Con clientes realizando desarrollo que se comunica, va la norma SQL, con
algn motor de bases de datos en el equipo central.
Un mensaje implcito en esta narracin es que, en el esquema cliente servidor,
cliente no es lo mismo que usuario final. En este caso, para efectos del desa-
rrollo de aplicaciones, el cliente es tambin un especialista que se encuentra
en otra unidad de la empresa.
A excepcin de consultas, informes y otros mdulos especiales, las herramien-
tas de productividad tipo cliente servidor estn muy orientadas hacia especia-
listas en informtica. Un ndice adicional es el largo tiempo que toma llegar a
obtener un manejo de buen nivel, no inferior a seis meses, incluso para pro-
gramadores con experiencia.
El esquema cliente servidor se hace cada vez ms parecido al ambiente WEB.
Y las herramientas de productividad en ambiente WEB?

Con la explosin de aplicaciones WEB ha surgido una amplia variedad de
herramientas en este ambiente, dentro de las ms conocidas: .NET y el desa-
rrollo en JAVA, destacndose J2EE (Java Enterprise Edition). Tambin PHP
integrado con alguna base de datos, como MySQL.
Resulta sorprendente que mucho software en este ambiente es de tipo open
source (cdigo abierto para efectos de lograr aportes en su construccin, no
necesariamente libre de costo como los productos free).
En todo caso, un objetivo principal de la empresa es el desarrollo de pginas
WEB y portales para integrarse con sus proveedores, clientes y dems grupos
de inters. As la empresa se proyecta al medio.
CONCLUSIONES, ANEXOS Y
BIBLIOGRAFA
332 JUAN BRAVO C.
CONCLUSIONES
Los que conocen ntimamente un oficio saben perfectamente que

lo que menos se encuentra es la uniformidad en los mtodos usa-
dos. En lugar de haber una sola manera de trabajar aceptada
generalmente como modelo, se usan diariamente, digamos, 50
100 maneras diferentes para hacer cada elemento de trabajo.
Taylor F. W. (1969, p. 26)
Vimos que tradicionalmente el buen modelamiento de soluciones de software

permite aumentar la productividad del desarrollo y la calidad del producto.
Est bien, aunque debemos agregar la satisfaccin total del cliente (no el usua-
rio, sino que el cliente de la organizacin), porque la nueva visin de la totali-
dad y los requisitos de competitividad hacen necesario una mirada ms all de
lo tradicional.
Vimos que es posible conservar la creatividad y al mismo tiempo obtener mo-
delos repetibles y normalizados con mtodos y herramientas de uso general.
Entonces, el modelamiento de soluciones de software puede ser tecnologa y
arte a la vez.
El buen modelamiento tiene su base en slidos pilares:
La necesidad de trabajar con un mtodo completo, para toda la organiza-
cin y para todas las etapas de un proyecto, no slo el mbito tecnolgico.
Eficientar el diseo con herramientas de productividad y criterios de mode-
lamiento tal como el curso normal de los eventos y otros que provee la vi-
sin sistmica.
Aplicar normas de calidad: CMM, ISO 9000, Tick IT
Alinear el desarrollo de software con las verdaderas necesidades del nego-
cio, esto significa alinear con la estrategia de la organizacin y verdadera-
mente trabajar en conjunto con el usuario.
Incorporar al diseo los estndares modernos: orientacin a objetos y
UML, por ejemplo.
Por supuesto, la efectividad se lograr en un ambiente propicio, con el nivel
de madurez requerido.
Mucho xito y gracias por la lectura.
~~
ANEXO 1. INTRODUCCIN A LA PLANIFICACIN

ESTRATGICA
La idea es tener una visin estratgica, una vista panormica de la realidad

que nos permita tomar los mejores cursos de accin para cumplir con los
grandes intereses de la organizacin84.
Cada rea de la organizacin debera tener su propia misin, objetivos y planes,
en armona con las necesidades estratgicas de la institucin, dando respuesta a
preguntas del siguiente tipo: Damos nfasis a la calidad o al mnimo costo?
Bajo qu paradigma de administracin? Potenciamos el conocimiento de la
propia organizacin o utilizamos mtodos externos? Se requiere desarrollar
ms el rea comercial o el rea productiva?
Tradicionalmente la planificacin se ha preocupado de:
Definicin del propsito de la organizacin y de las metas departa-
mentales
Creacin de nuevos productos
Posicionamiento en determinados segmentos de mercado
Perfil de empleados
Estrategia de marketing
Estrategia de comercializacin
Definicin de imagen corporativa
reas geogrficas de la organizacin y globalizacin.
Por lo tanto, el desafo es flexibilidad y creatividad.
Hoy, el rol de la planificacin estratgica va mucho ms all. Debera prepa-
rar a su organizacin para ser receptiva al cambio. Debera permitir que la
empresa absorba los golpes del medio, se detenga, prepare bien una respues-
ta y reaccione con mucha fuerza para lograr sobrevivir85.
84
Este es un resumen acerca de estrategia desde el libro Planificacin sistmica.
85
Es equivalente a cuando se critica a alguien y esa persona, en vez de resistir, defenderse o
contraatacar, como sera lo habitual, absorbe silenciosa y positivamente la crtica. Esto es,
reflexiona sobre ella e independiente de las exageraciones que pudiera contener, la toma con
agradecimiento y se esfuerza por ajustar su conducta en base a la porcin de verdad que ella
contiene. Quiz por eso Plutarco escritor romano dijo: Un buen enemigo es el mejor
maestro.
334 JUAN BRAVO C.
El objetivo de la Planificacin Estratgica (PE) es ayudar a obtener una vi-

sin de los verdaderos intereses y necesidades concretas de la organizacin
con el fin de tomar decisiones hoy, siguiendo una direccin clara y definida.
Esto obliga a una reformulacin permanente de la planificacin estratgica.
Por eso es que hoy hablamos de planificacin continua.
La PE la hace solamente la alta gerencia? El ideal es que participen todos los
miembros de la organizacin. Aunque la PE comienza por la direccin supe-
rior, luego se produce mucha retroalimentacin a medida que pasa a travs de
los diferentes niveles jerrquicos.
En los siguientes pasos, sealados en la figura A1-1, revisaremos los aspectos
ms importantes de la planificacin estratgica.
Factores Sistemas de
Definicin Destino de la Informacin
crticos Mediciones
del negocio organizacin Gerenciales
del xito
Figura A1-1. Esquema de planificacin estratgica
En la figura A1-1 podemos apreciar una visin de conjunto del esquema pro-
puesto. Comienza por una definicin clara y precisa del negocio, luego viene
la definicin del destino de la organizacin (lo que queremos, en la forma de
visin, objetivos y metas). A continuacin, vienen los factores crticos del
xito, aquellos aspectos fundamentales para la supervivencia y desarrollo de la
organizacin, que sern ocupacin prioritaria del ejecutivo.
Los objetivos, metas y factores crticos del xito necesitan apoyarse en medi-
ciones estables, confiables, oportunas y permanentes. Adems, debemos con-
siderar que la implementacin de las mediciones es la base para la definicin
de los sistemas de informacin gerenciales.
Veamos este esquema.
Definicin del negocio

El primer paso de la tcnica es aclarar el giro: Cul es mi negocio? o Cul
es el valor agregado de mi actividad? Necesariamente significa preguntarse:
Existen reas prescindibles?
As como el hombre, segn Viktor Frankl, fundador de la logoterapia, est en
ltima instancia en bsqueda del sentido de la vida; las personas que integran
la organizacin tambin deben preguntarse cul es el sentido de la existencia

de sta, el rol que le toca jugar en la sociedad.
A este aspecto, Koch y Campbell (Cmo despertar y reanimar la empresa) le
asignan una importancia radical. Ellos hablan de xito cuando la empresa tie-
ne verdaderos objetivos.
Para definir el negocio es indispensable efectuar un estudio iterativo y retroa-
limentado (en el sentido de construir borradores sucesivos) sobre los siguien-
tes temas:
Introspeccin: es un escrutinio interno destinado a conocer nuestras forta-
lezas y debilidades, compararlas con las de la competencia y as perfeccio-
nar nuestras ventajas competitivas. Destaquemos en forma especial que lo
que hace la diferencia en una empresa no es lo que hace menos mal, sino
lo que hace muy bien. Esto significa destinar a las fortalezas el mximo
posible de tiempo y mejorar las debilidades solamente para llevarlas a un
nivel aceptable, donde no pongan en peligro la existencia de la empresa.
No le parece revolucionario? Es exactamente al revs de como lo apren-
dimos en el colegio, donde nos gastbamos todo el tiempo en llevar las de-
bilidades a un punto de rendimiento medio y las fortalezas quedaban aban-
donadas.
Anlisis de la industria: es un detallado estudio de la industria donde est
inserta la empresa. Se busca identificar las oportunidades y amenazas que
surgen de la interaccin con el medio.
Estrategia competitiva: Marketing o innovaciones? En qu nos diferen-
ciamos? Nuestra orientacin tender hacia la apertura de nuevos mercados
o a innovar en productos manteniendo nuestro actual mercado? Tenemos
que buscar nuestras ventajas competitivas a partir de nuestras fortalezas, las
cuales, al ser trabajadas, sern elementos diferenciadores: calidad, rapidez
en la entrega, servicio ptimo, solidez o lo que sea. El sistema de diferen-
ciacin y luego la ventaja competitiva es la forma como vamos a competir
en el mercado. Se apoya en la orientacin al cliente.
Misin del negocio: es la funcin especfica que nos corresponde desarro-
llar en el sistema del que formamos parte, aquella funcin donde otorga-
mos un verdadero valor agregado y adems, plenamente reconocido por la
sociedad como til y complementaria para lograr los objetivos de bien
comn. Por ejemplo: confeccin de jeans a pedido para clientes mayoris-
tas, centro naturista de atencin al pblico o asesoras en planificacin es-
tratgica dirigidas a la direccin de las organizaciones.
336 JUAN BRAVO C.
Tcnicamente, la misin debe incluir los productos que ofrecemos y los

mercados que atendemos.
Valores de la organizacin: la organizacin tiene personalidad propia, dis-
tinta de las personas que la componen, aunque en el largo plazo se produce
cierta similitud. Es decir, tanto la organizacin como sus integrantes co-
mienzan a tener conductas parecidas. Los valores se expresan prioritaria-
mente de dos formas:
Destacando el tipo de interaccin que queremos tener con cada tipo de
asociado: Cmo queremos que sea la relacin con los colaboradores,
clientes o proveedores? La mecnica es describir las necesidades de cada
grupo de asociados y ayudarles a satisfacerlas, en armona con la satisfac-
cin de necesidades de nuestra organizacin. Por ejemplo, los integrantes
de la organizacin tienen necesidad de una renta digna, un trato respetuoso,
un ambiente laboral estable, condiciones de trabajo que protejan su salud
fsica y mental. Los clientes merecen todo nuestro apoyo, pues ellos finan-
cian nuestras actividades, es indispensable que tengan la certeza de que
trabajamos para entregarles calidad, innovando da a da en su beneficio y
que les ofrecemos lo mismo que la competencia y mucho ms. Los provee-
dores necesitan conocernos para entender nuestras necesidades, requieren
pagos puntuales, una relacin comercial fluida, niveles de calidad estable-
cidos de comn acuerdo.
Sealando explcitamente un conjunto de creencias, principios ticos y
modalidades de gestin. Cules son las condiciones del trato entre las per-
sonas? Cmo se manejan temas claves (disciplina, anticipacin, comuni-
cacin interpersonal)? Qu sucede con el fomento a la creatividad e inno-
vaciones?
La emocin del negocio es una fuente para la motivacin de todas las per-
sonas de la organizacin y el principal alimento del lder. Surge de nuestros
sueos, de identificar la necesidad social concreta que estamos satisfacien-
do: abrigo, alimentacin o consejera. Es el nexo que nos une con el entor-
no, nos ayuda a reflejarnos y compartir experiencias con quienes tienen la
misma perspectiva, aun cuando cumplan misiones diferentes86.
86
Tal como lo reflejara muy grficamente el dueo de una panadera. La emocin del negocio
es abrir uno de los panes que estamos produciendo, inspirar profundamente, sentir su aroma y
esbozar una sonrisa de satisfaccin.
Muchos empresarios se nutren de la importancia de su labor en la sociedad para crear riqueza,
fabricar bienes, dar empleos, etc
La imagen corporativa es la cara que queremos mostrar de la empresa a

travs de: papelera, banderas o revista interna.
Destino de la organizacin
El asunto es: la organizacin estar a la deriva o tendr un rumbo mantenido
con mano firme? Indudablemente, identificar el destino de la organizacin es
indispensable. Para ello, tenemos que definir cuatro aspectos, en el mismo
orden: ideal, ideal factible, objetivos y metas.
El ideal es nuestro sueo para la organizacin. Queremos tener el 90% del
mercado, o que cada norteamericano tenga un automvil, como deca Hen-
ry Ford. Que en cada supermercado se venda salmn en la misma forma y
cantidad que el pollo o llevar a cero el consumo de drogas, lo que sea su
sueo.
El ideal factible surge de negociar con la realidad y proponer algo posible
para el futuro cercano. Aceptamos disminuir un poco nuestra pretensin
original, si corresponde, para lograr algo concreto. Entonces diremos que s
es posible obtener el 35% del mercado, construir un automvil posible de
adquirir por los trabajadores, comenzar a vender salmn en los supermer-
cados en diferentes presentaciones o reducir el consumo de droga en un
90%. Tcnicamente, el ideal factible es una propuesta que sabemos posible,
aunque no es tan precisa como un objetivo... es la visin del negocio.
Los objetivos son los elementos ms representativos de la planificacin
estratgica, porque corresponden al destino concreto de nuestra empresa,
aquel punto adonde queremos llegar. La planificacin estratgica define los
objetivos segn el ideal factible, un diseo efectuado sin amarrarnos a la
historia del negocio. Cada objetivo asocia mediciones para establecer com-
paraciones y apreciar un estado de avance. As, deja de ser solamente una
buena intencin. Ha observado las emotivas declaraciones de principios
de empresas en quiebra? Tan insubstanciales como las declaraciones de
desarrollo integral del nio en colegios altamente represivos.
Un antiguo proverbio dice: El camino al infierno est pavimentado de bue-
nas intenciones.
Existen previsiones a la cantidad de aos que uno desee, aunque general-
mente se hace una distincin entre objetivos de corto, mediano y largo pla-
zo, unos 2, 5 y 15 aos, respectivamente. Los plazos indicados representan
solamente un promedio, porque no existe uniformidad al respecto. Largo
338 JUAN BRAVO C.
plazo puede significar 4 aos para el ejecutivo de una empresa pequea o

30 aos para el presidente de una corporacin japonesa.
Las metas vendran a ser las paradas intermedias, cada uno de los diferen-
tes escalones que nos permitirn lograr un objetivo. Cada meta requiere un
responsable, recursos y plazos.
Factores crticos del xito

Los Factores Crticos del xito (FCE) son tan vitales para la empresa, que
afectan directamente sus posibilidades de sobrevivencia. Dependen directa-
mente de la misin de la empresa y deben ser considerados en la toma de de-
cisiones de la alta gerencia; representan un filtro en la cantidad de informa-
cin que llega al ejecutivo. Significa que l podra delegar todo lo que no es
un FCE. Por ejemplo, en una empresa de confecciones se encontraron los si-
guientes FCE:
Eficiencia en la produccin
Estabilidad en la produccin
Perfeccionamiento tecnolgico
Nueva organizacin de la empresa
Los factores crticos del xito se pueden clasificar en:
Permanentes: se mantienen a travs del tiempo y son relativos a la indus-
tria, es decir, se pueden encontrar en la mayora de las empresas del mismo
tipo, como el perfeccionamiento tecnolgico, la eficiencia y estabilidad de
la produccin, del ejemplo anterior.
Temporales: se mantienen por perodos cortos de tiempo; generalmente se
originan en:
Particularidades transitorias, como una campaa comercial o el
lanzamiento de un nuevo producto.
Hechos circunstanciales, como una nueva ley, un incendio en insta-
laciones importantes o la renuncia de un empleado clave.
Situaciones programadas, como el desarrollo de una meta; por
ejemplo, la nueva organizacin de la empresa.
Mediciones
La planificacin puede carecer de sentido si no est fuertemente anclada a los
hechos y la realidad, lo que se consigue a travs de las mediciones, en lugar de
solamente las buenas intenciones.
Las mediciones deben estar presentes en todos los elementos mencionados:
objetivos, metas, comparaciones con la competencia o factores crticos del
xito.
En alguna parte de la planificacin podra decir: aumentar el perfeccionamien-
to del personal. Al dejarlo as no pasa de ser una bonita declaracin, sin em-
bargo, para que se transforme en una realidad, es necesario agregarle un ndi-
ce; por ejemplo, horas de capacitacin anual por empleado. Ahora podemos
hablar en concreto: cuntas horas estamos capacitando hoy a nuestro perso-
nal y a cuntas queremos llegar?
Otro ejemplo es el de una empresa de confecciones que se plantea por objeti-
vo aumentar la produccin. En este caso, la medicin es nmero de prendas
por da, entonces: Cul es actualmente el nmero de prendas por da y a qu
nivel queremos llegar?
Sistemas de informacin gerenciales

En el punto anterior, ambos ejemplos terminan con preguntas donde podemos
apreciar la necesidad de mediciones actualizadas para definir sistemas de
informacin.
Cada vez que un ejecutivo da pautas sobre cmo hacer algo o se anticipa a una
crisis o punto de quiebre, est diseando sistemas de informacin gerenciales.
Un sistema de informacin es un modelo diseado para cumplir con algn fin
prctico, en este caso, apoyar una medicin. En el sistema de informacin
gerencial participan personas y se emplean variados recursos: tcnicos, finan-
cieros, infraestructura, conocimiento o herramientas de software.
Los sistemas de informacin gerenciales son procesos claramente identifica-
bles, cuyo diseo debe estar permanentemente actualizado para conservar su
efectividad. Permiten conocer e influir sobre el estado de una variable; por
ejemplo, si el nmero de prendas producidas en el da baja hasta un cierto
nivel, se genera automticamente un alerta a ventas y produccin; si el ndice
llega a un nivel todava ms bajo, podra alertarse a la gerencia general.
Quin disea el sistema de informacin? Tradicionalmente, sta ha sido la
principal labor del ejecutivo, a veces sin que l lo supiera. Hoy, existe una
340 JUAN BRAVO C.
tendencia a la participacin de todos los interesados. De hecho, algunos gru-

pos autodirigidos definen y mantienen sus propios sistemas de informacin.
El diseo de sistemas de informacin gerenciales tiene relacin directa con
una antigua habilidad: la anticipacin. Como deca El Quijote: estar preveni-
dos es estar armados.
ANEXO 2. ALINEAR INTERESES
Existe la necesidad de negociar intereses, porque las personas y organizacio-

nes tienen propsitos diferentes. Una vez que los intereses estn claros, un
proceso nada de simple, la gerencia debiera mantener la coherencia a travs de
un sistema de seales, es decir, establecer indicaciones y acciones concretas y
permanentes segn el objetivo que se desea obtener. Las personas hacen lo
que hacen porque les conviene hacerlo (o creen que les conviene), porque hay
estmulos para ello.
Es necesario alinear todas las acciones con la cultura de la organizacin y bus-
car armona entre los grupos de inters: clientes, colaboradores, accionistas o
inversionistas, distribuidores, empresas afines, gobierno, comunidad, bancos e
instituciones financieras, proveedores y muchos otros a quienes conviene la
existencia de la empresa. Cmo lograrlo? Negociando, escuchando, apren-
diendo a reconocer los intereses propios y ajenos, ponindonos en el lugar del
otro y practicando la buena comunicacin, entre otras acciones.
Tambin hay que lograr armona entre los costos, lo cual implica negociar con
los diferentes grupos de inters, buscando satisfacer sus intereses en armona
con los de la empresa. Este es uno de los aspectos ms difciles para la geren-
cia y exige mucha fortaleza y habilidad, porque muchos grupos le exigirn
justas demandas (para ellos) y algunos gritarn ms que otros: mayores utili-
dades!, mejores sueldos!, ms tributacin!
De hecho, en las grandes empresas norteamericanas87 comienza a ganar el
talento, los trabajadores del conocimiento, como dira Peter Drucker. Las per-
sonas ms preparadas de la organizacin estaran obteniendo mayores benefi-
cios que los accionistas, lo cual conduce a la rareza de que los trabajadores
que no son del conocimiento hagan alianza con los dueos del capital (princi-
palmente ellos mismos a travs de los fondos de pensiones) para obtener me-
jores beneficios. Paradojas de la nueva economa.
Liderar interacciones
Para mantener la armona, la gerencia debera liderar valores en la relacin
con cada grupo de inters, eso contribuir al respeto y la confianza mutua. El
trabajo en equipo resulta aqu esencial. A esto se refiere Russell Ackoff
(1994) cuando explica que un ejecutivo lidera interacciones.
87
Segn un artculo de Martin y Moldoveanu (2003) en el Harvard Business Review.
342 JUAN BRAVO C.
Es fcil darnos cuenta de esto con algunos ejemplos:

Si contratramos a los mejores futbolistas del mundo y los hiciramos
jugar juntos, lo ms probable es que el rendimiento no fuera el ptimo.
En la empresa manufacturera, es caracterstico otorgar incentivos de pro-
duccin por cantidades de productos que en muchos casos se almacenan,
en lugar de incentivar a producir slo lo que se vende.
En departamentos de mantencin, es frecuente pagar horas extras por repa-
raciones de maquinarias y de una u otra forma, siempre hay mucho tra-
bajo en lugar de pagar por su buen funcionamiento.
Otro caso es nuestra interaccin con los mdicos en algunos tipos de pro-
gramas. Partiendo de la base que el objetivo de la sociedad es el bien
comn, nuestro negocio es estar sanos. Y el de los mdicos? el negocio
de los mdicos en esos programas es que haya muchos enfermos! Porque
un mdico gana ms en la medida que hay ms enfermos. Este es el resul-
tado de una cultura mecanicista que slo ve partes. La responsabilidad no
es solamente de los mdicos y lo mismo es vlido en la mayora de las
profesiones. Es ms, muchos de ellos mantienen su profesionalismo y
amor al trabajo bien hecho a pesar de los incentivos equvocos que otorga
la sociedad. Un esquema sistmico sera aquel donde el negocio del mdico
es la salud y no la enfermedad, es decir, que el mdico gane ms en la me-
dida que haya ms gente sana. Eso es alinear intereses.
Por ejemplo, en la prevencin de riesgos a quien o a qu grupo le puede con-
venir que hayan ms accidentes aun cuando no lo diga y tal vez ni siquiera lo
sepa88? Entendiendo que muchas veces son intereses que residen en capas
muy profundas y que pueden operar a nivel subconsciente. Igual es necesario
identificarlos y negociar para alinear intereses.
Es la situacin tpica que se produce cuando el nfasis est en la correccin y
no en la prevencin. El mensaje es negociar con todos los interesados.
Alinear el inters particular con el inters general

A diferencia de lo que planteaba Henri Fayol de supeditar el inters particular
al general, en visin sistmica se propone alinear el inters particular con el
inters general. En el primer caso solamente hay mando y control, en el se-
gundo, participacin y negociacin.
88
Como cuando un mdico cirujano le pregunta a otro, cmo te va? Y aquel responde: mal,
porque he tenido pocas operaciones.
Debemos asegurarnos que la misin del proceso sea consistente con la misin
de la empresa y dar seales de que ambos negocios estn alineados. Por ejem-
plo, si el negocio de la empresa es la fabricacin de productos industriales, su
conveniencia respecto a las maquinarias es que se mantengan en buen estado
de funcionamiento. Sin embargo, la conveniencia del grupo de mantencin es
que las mquinas estn en mal estado, porque sus ingresos provienen de la
reparacin de maquinarias descompuestas, incluso se les paga horas extra para
incrementar el volumen de reparacin. Se puede apreciar que ambos negocios
se contraponen: a uno le conviene tener los equipos buenos y al otro le con-
viene que haya muchos equipos malos. Si el objetivo del equipo de manten-
cin fuera obtener ingresos por tener los equipos en ptimo estado de fun-
cionamiento, tendramos las misiones alineadas e incentivaramos la manten-
cin preventiva.
Esto es alinear intereses y una forma de implementarlo podra ser: ofrecer un
incentivo por tener todas las mquinas en buen estado y descontar de ah
cuando se presenten fallas. Vemoslo ms en detalle con el resumen de un
caso real. Supongamos que son 5 tcnicos, que el sueldo de cada uno es de
US$ 1.000 y que el costo para la organizacin por mquinas que fallan es de
US$ 40.000 al mes (horas improductivas). Entonces, se les ofrece a los tcni-
cos un premio mensual extra de US$ 10.000 a repartirse en el grupo, a condi-
cin de que las mquinas estn en buen estado de funcionamiento, pero, si una
mquina falla, se descuenta de ese fondo un valor predefinido por cada hora
detenida. En este caso tenemos alineadas las misiones: a la organizacin y al
servicio tcnico les conviene tener las mquinas buenas.
Eplogo: en el caso real los tcnicos aumentaron su remuneracin en un 50% y
las fallas de las maquinarias disminuyeron en 70%.
Veamos otro ejemplo, si uno toma separadamente el rea de produccin de
una empresa, puede parecer deseable producir cada vez ms. Sin embargo, es
eso realmente conveniente para la empresa? Tal vez no, porque se podra ver
en la necesidad de sacrificar demasiado sus mrgenes, absorber gastos dema-
siado altos de ventas o de administracin Podra ser que el objetivo del rea
productiva fuera producir segn la demanda? S, a travs de algn esquema
que permita disminuir libremente la produccin sin incrementar el costo por
unidad producida.
Entonces, es posible la armona en la organizacin en pro de sus propsitos
superiores? Por supuesto, a travs de alinear intereses.
344 JUAN BRAVO C.
ANEXO 3. DESARROLLO EN ESPIRAL DEL PROYECTO
El desarrollo en espiral es una tcnica donde el proyecto de negocios abarca

una porcin cada vez mayor de los requerimientos y en cada iteracin avanza
en calidad, eficacia y eficiencia.
Este mtodo est dirigido a proyectos de cambio mayor. Simplificando, tam-
bin se puede aplicar a proyectos de cambio un poco menor, como en el
benchmarking o la mejora, aunque resultara un poco forzado.
Dice Steve McConnell (1997, p. 153): El modelo de espiral es un modelo de
ciclo de vida orientado a riesgos que divide un proyecto en miniproyectos
Se parte de una escala pequea en medio de la espiral, se localizan los riesgos,
se genera un plan para manejarlos y a continuacin, se establece una aproxi-
macin a la siguiente iteracin Se avanza un nivel en el rollo de canela, se
comprueba que se tiene lo que se desea y despus se comienza a trabajar en el
siguiente nivel.
Cada vuelta de la espiral es un ciclo completo de desarrollo para el grupo de
requerimientos seleccionados. En cada iteracin la complejidad se incrementa
progresivamente y se reduce el riesgo. Por supuesto y al igual que en un pro-
yecto tradicional, un desarrollo de esta naturaleza exige amplio esfuerzo de
gestin y operacin.
Se espera que una vuelta de la espiral demore entre dos y diez semanas, para
un rango de entre el 5% al 20% de los requerimientos.
Esta es la nueva propuesta para los proyectos menos estructurados. La forma
tradicional es la tcnica llamada desarrollo en cascada, en la cual se preten-
de avanzar en cada etapa con todos los requerimientos a la vez, en consecuen-
cia, recin se ven resultados al trmino del proyecto, tal vez un ao en el caso
de proyectos medianos.
En el desarrollo en espiral cada vuelta o ciclo es un pequeo desarrollo en

cascada, porque pasa por todas las etapas, aunque para un nmero relativa-
mente pequeo del total de requerimientos.
Al trmino del proyecto (despus de todos los ciclos) se recomienda incorpo-
rar la mejora continua (ver etapa 7 del mtodo).
346 JUAN BRAVO C.
ANEXO 4. RELACIN CAUSAL
Existen varias tcnicas asociadas a la deteccin de causas: rbol de decisin,

tcnica de los por qu y otras detalladas en el texto. Veremos aqu la tcnica
causa - efecto de Kaoru Ischikawa junto con la deteccin de prioridades del
italiano Vilfredo Pareto (1848 1923).
Es una combinacin que hemos venido utilizando con efectividad, en la de-
teccin de los riesgos de fondo en eventos de prdida de la administracin del
riesgo operacional y en la mejora continua.
La tcnica causa efecto se utilizaba principalmente en el mbito industrial y
las espinas hacan referencia a los temas relacionados: materiales, materias
primas, mano de obra, maquinarias y ambiente. Aqu las espinas son los
elementos del modelo de negocios: estrategia, personas, procesos, estructura
organizacional y tecnologa. En este caso la aplicamos buscando el problema
de fondo de un sntoma o dificultad.
Personas Procesos
Sntoma(s)
Estrategia Estructura Tecnologa

Por ejemplo, para un sntoma de descuadraturas de caja, en la lnea personas
se podra anotar, entre otras causas:
Falta de capacitacin
Escasa motivacin
Personas no idneas
Dificultades entre colaboradores y jefe
Lo habitual es que se anoten muchas causas, como en una tormenta de ideas.
Entonces, se detectan causas, se analizan, indicando en que porcentaje influye
cada una sobre el sntoma, riesgo o lo que sea que estemos analizando. La
frmula es Y = F(x). En la figura A4-1 se presenta un caso de aplicacin de
esta tcnica para una situacin de tiempo de espera excedido de clientes en
una empresa de venta al detalle de productos de lnea blanca y electrnica.
Causas Efecto
Procesos Personas
Rotacin
Especializacin Motivacin
Forma obsoleta Preparacin Insatisfaccin de
clientes debido a
excesiva duracin del
Falta directriz No participacin Falta Tecnologa
proceso (49 minutos)
Comunicar Falta rea Obsoleta
Estrategia Estructura Tecnologa
Figura A4-1. Ejemplo de grfico de Ishikawa
Se priorizan y grafican de mayor a menor impacto segn el porcentaje asigna-

do, se lleva un grfico acumulativo que cuando llega al 80% (o el porcentaje
que acuerde el equipo de proyecto) se tiene el conjunto de causas ms relevan-
tes, los pocos crticos.
El grfico tiene la siguiente forma,
donde la columna ms a la derecha
tiene el acumulado de las causas ante-
riores ms la nueva.
El nivel de profundidad al cual se llega tiene que ver con la tcnica de desa-
rrollo en espiral y con el nivel de error aceptable para la organizacin en algn
nivel de sigma.
Esta forma de trabajo es recursiva, puede ser necesario que una causa tenga su
propio anlisis causal y as sucesivamente. Es decir, X1 = F(x1), esquema
central en la tcnica Six Sigma.
A propsito de Six Sigma, en su libro Anlisis de la causa raz, los autores
Wilson, Dell y Anderson dicen (1999, p. 6): En Estados Unidos el 0.1% de
fallas significa: 16.000 piezas de correo perdidas por hora, 20.000 prescrip-
ciones de medicamentos incorrectas por ao, 500 operaciones quirrgicas in-
correctas por semana, 50 bebs recin nacidos se les caen a los mdicos por
da, 22.000 cheques deducidos de cuentas corrientes equivocadas por hora, su
corazn no late 32.000 veces por ao.
348 JUAN BRAVO C.
ANEXO 5. MTODO DE ACCIN RPIDA (MAR)
El objetivo del Mtodo de Accin Rpida (MAR) sobre procesos es capturar

oportunidades de mejora o de rediseo de los procesos operativos de cualquier
mbito de la empresa. puede ser un rea o un macroproceso. Se trata de pro-
poner el (re) diseo en alguna herramienta tal como PowerPoint, Optimus,
Visio, System Arquitect u otra, a condicin de que este disponible para todos.
Se han logrado importantes cambios en las empresas con esta tcnica.
En el MAR es vital la participacin de quienes trabajan en los procesos opera-
tivos. La idea es la siguiente:
1. Seleccionar un mbito de trabajo y dibujar un mapa de procesos.
2. Identificar un proceso operativo y describirlo con un Flujograma de Infor-
macin (FI). Aplicar criterio Curso normal de los eventos.
3. Identificar cliente, dueo, variable crtica y mediciones estimadas.
4. Establecer objetivos siguiendo el principio de idealizacin: ideal, ideal fac-
tible. Cul es el proceso perfecto89? (Puede ser de todo el mbito).
5. Explicar oportunidades de mejora y sealarlas en un nuevo FI. Cmo que-
dan las mediciones?
6. Realizar un cierre de la propuesta indicando beneficios y costos. Estimar
VAN interno y social (impacto econmico en el medio)
Los detalles actualizados de esta tcnica los puede bajar desde la pgina
www.evolucion.cl.
89
El concepto de proceso perfecto viene de aplicar algo largamente reconocido, el poder
del pensamiento. Cuando logramos ver en nuestra mente ese proceso perfecto, de alguna
forma se generan caminos para acercarnos a ese ideal. Aceptmoslo de una vez, el futuro no
existe, es solamente imaginacin nuestra, algo que sucede en nuestra mente y que podemos
controlar.
El mismsimo Omraam Mikhal Avanhov (1900-1986, sabio francs de origen blgaro, reco-
nocido por su aporte a la espiritualidad) en su libro Poderes del pensamiento nos aporta
(pginas 39 y 40): Hay dos grandes verdades que debis conocer: primero, que el pensamien-
to es un poder real y segundo, que os permite transportaros al futuro y vivirlo con anticipa-
cin. Ved, por ejemplo, que si tenis que afrontar una situacin terrible, pasar un examen o
comparecer ante un tribunal, ya estis temblando varios das antes, os inquietis: qu va a
pasar? Y cuando pensis que vais a reuniros con aqul o aqulla que amis y que vais a
abrazarla, estis ya saboreando el gozo de estos minutos prximos o lejanos El poder del
pensamiento es real, tanto para lo negativo como para lo positivo y tenemos, por tanto, que
servirnos de l para lo positivo.
ANEXO 6. AD/CYCLE Y RUP
Se puede apreciar la evolucin en el desarrollo de mtodos orientados hacia el

ciclo de vida genrico de proyectos, con el ejemplo de dos propuestas:
AD/Cycle y RUP, ambos de IBM (RUP fue adquirido en 2005 junto con la
empresa Rational). El primero ms antiguo y el segundo ms reciente.
AD/Cycle
El ciclo de desarrollo de aplicaciones computacionales de IBM, AD/Cycle,
anunciado en 1989, se acerca bastante al ciclo de vida genrico, la principal
diferencia es que incorpora explcitamente una etapa de pruebas, la cual es
parte de la construccin en el mtodo genrico. Adems, en AD/Cycle se
habla de Anlisis/diseo para referirse a lo que en el mtodo genrico llama-
mos diseo.
AD/Cycle provee un ambiente integrado de desarrollo que incluye desde el
modelamiento hasta la mantencin. Cada una de sus etapas es apoyada por
herramientas de automatizacin propias o de otros proveedores. Las etapas de
AD/Cycle son:
Recoleccin de requerimientos: incluye planificacin de sistemas,
objetivos, factores crticos del xito, prioridades y procesos del negocio.
Anlisis/Diseo: basado en anlisis y diseo estructurado.
Codificacin: es la construccin de los programas, servicio proporcionado
por los generadores de aplicacin.
Pruebas: se incorpora formalmente el uso de prototipos y la idea de lograr
un resultado a travs de perfeccionamientos sucesivos.
Mantencin: ya sea por errores o cambios en el entorno.
Se puede apreciar que ya en 1989 IBM haba eliminado la implementacin
como una etapa ms, aunque sus principales tareas: documentacin, entrena-
miento y poblamiento, se continan realizando en forma automtica o como
parte de otras etapas. Se puede apreciar cmo se va delineando poco a poco el
concepto de que una aplicacin no termina nunca, crendose el ambiente para
el desarrollo continuo de la aplicacin.
Con AD/Cycle tambin se eliminan las etapas de diagnstico y factibilidad
aplicados a resolver problemas en forma reactiva, las que fueron reemplazadas
por un enfoque global, una visin de conjunto de la organizacin que se ob-
tiene de la recoleccin de requerimientos.
350 JUAN BRAVO C.
RUP
Los autores del UML (captulo 6) son tambin creadores de Rational Software
Corporation (adquirida por IBM en el ao 2005), desde donde han propuesto
el RUP (Rational Unified Process), un mtodo completo para el desarrollo de
software que rpidamente est siendo incorporado en la industria informtica.
RUP considera seis mejores prcticas del desarrollo de software:
1. Desarrollo Iterativo (o en espiral). Se resuelven primero los casos de uso
(o requerimientos) ms importantes, aquellos donde el riesgo es mayor.
2. Manejo de los requerimientos. Se seleccionan, organizan y documentan los
requerimientos, se establece una prioridad en base a riesgos. Se aplica la
tcnica de casos de uso, donde se establece lo que importa para el usuario,
incluyendo la interfaz.
3. Uso de una arquitectura de componentes. Aqu se establece la arquitectura
de la solucin de software. Debe cumplir que el software sea fcil de usar,
funcional, de buen rendimiento, reusable, factible, entendible, econmico,
esttico y elegante. Haciendo una comparacin con el rubro de la construc-
cin, esta etapa sera la de arquitectura.
4. Modelamiento visual del software. Se aplican aqu los modelos que provee
UML, orientados a la especificacin, visualizacin, construccin y docu-
mentacin de los productos de software.
5. Verificacin de la calidad. Siendo la calidad uno de los ms graves pro-
blemas de la construccin tradicional de software, se propone incluir indi-
cadores de calidad y verificaciones en cada punto del proceso de desarrollo.
Se incorpora una labor de Testing en el ciclo de vida, en cada vuelta de la
espiral.
6. Control de cambios. En un ambiente de creciente complejidad: mltiples
desarrolladores, equipos de trabajo, instalaciones, versiones del software,
proyectos y plataformas, se requiere un control explcito de requerimientos,
configuracin y mediciones.
En este mtodo, cada iteracin acerca ms el sistema a lo que desea el usuario
y a su plena funcionalidad, por otra parte, cada versin va quedando en fun-
cionamiento real.
Mayor informacin puede encontrarse en www.omg.org, www.rational.com,
www.uml.com y otros sitios relacionados.
ANEXO 7. CASO COMPRAS CON UML
Este caso fue un desarrollo completo de los modelos de UML contemplados

en el mtodo GSP (captulo 1).
En el aspecto metodolgico se basa principalmente en el libro Applying
UML and Patterns de Craig Larman (1998, Prentice Hall).
Reconociendo que es difcil revisar en el papel, usted puede bajar este archivo
desde la pgina www.evolucion.cl
Puede bajar tambin:
El caso de uso Ventas
Mtodo de Accin Rpida (MAR) sobre procesos, modelo en Power Point
y detalle en Word. Lo vimos en el anexo 5.
Veremos en las siguientes lminas un caso completo de compras en UML,
comienza por los modelos de la etapa de anlisis.
Cada lmina tiene notas que explican el respectivo modelo.
352 JUAN BRAVO C.
Etapa de Anlisis
Modelos de UML de una aplicacin de ejemplo: compras
Las pginas siguientes corresponden a la etapa de anlisis,

la cual se extiende hasta la documentacin de los contratos
de las operaciones del sistema inclusive.
MAPA DE PROCESOS
(como parte del Modelo de Negocios)
Macro-
Proyeccin ventas Adquisiciones Ventas Servicio postventa
procesos
Primer Flujograma
de Informacin
RECEPCIN DESPACHO
POR COMPRAS POR VENTAS
Procesos
operativos
Devoluciones Devoluciones
Bibliografa: Esta presentacin se Bibliografa: Adicionalmente, esta presentacin se basa en la

basa principalmente en el libro serie de libros de gestin, anlisis y sistemas de Juan Bravo C.
Applying UML and Patterns de que incluye, entre otros, a: Gestin de Procesos (2005) y gestin
Craig Larman - 1998 - de proyectos de procesos y tecnologa (2006).
(Prentice Hall) ISBN 0-13-748880-7
Flujograma : Proceso de Recepcin de Productos de Proveedores - (Gua Interna de Recepcin por Compra)
Encargado Control de Inventario Depto. de Depto. de

Proveedor de Recepcin Calidad (Bodega) Compras Contabilidad
3
3
2
G/D 1 2
G/D 1
Proveed.
Proveed.
Ingresar Gua Nota: Un determinado documento

de Recepcin
(papel o electrnico) puede ser cambiado
(por ejemplo: VB, firma, tick) ... para
3 indicar algn tipo de accin que se ha
2 tomado con l - tal como: revisin, aproba-
G/R 1
Interna cin, etc -. Con ello, aunque el documento
sigue siendo el mismo, ya no es el
mismo. Se indica grficamente esta situa-
cin por medio de cremillas, que se
3 incrementan, como se muestra en este
G/R 3
Interna 2 flujograma para diversos pasos que sigue la
G/R 1
Interna Verificar copia # 2 de la Gua de Recepcin.
Calidad de
Productos
G/D 3 3
Proveed. 2
G/D 1
Proveed.
G/R 2
Interna
Ingresar
Productos
a Bodega
G/R 2
Interna
Casos de Uso: Crear Guas Internas de Recepcin por Compra y Funciones Bsicas
de Despacho por Venta (Productos con registro persistente) (Base Craig Larman)
Ref. # Funcin Categora
R1.1 Capturar y activar opciones desde un Men de Opciones, aceptar Opcin (Seleccin Manual). evidente
R1.2 Desplegar la Interfaz de Creacin de Gua de Recepcin, N de Gua de Recepcin (correlativo) evidente
y Fecha de la Transaccin, - aceptar eventual modificacin de Fecha (Ingreso Manual).
R1.3 Capturar el Cdigo del Encargado de Recepcin (Ingreso Manual). evidente
R1.4 Desplegar datos del Encargado de Recepcin registrados en almacenamiento persistente. evidente
R1.5 Capturar la informacin del Proveedor usando el RUT (Ingreso Manual) y desplegar datos evidente
pertinentes del Proveedor registrados en almacenamiento persistente.
R1.6 Capturar N de Gua de Despacho del Proveedor (Ingreso Manual), verificar validez (No evidente
Existencia previa) y desplegarlo.
R1.7 Capturar Fecha (Propia) de Gua de Despacho del Proveedor (Ingreso Manual) y desplegarla. evidente
R1.8 Capturar/Verificar (C/E) N de Orden de Compra (Ingreso Manual) y desplegarlo. evidente
R1.9 Registrar la transaccin en proceso: los Productos a recibir. Capturar la informacin del evidente
Producto a recibir usando el Cdigo (interno) (Ingreso Manual).
R1.10 Desplegar la descripcin del Producto registrado en almacenamiento persistente. evidente
R1.11 Capturar el Costo (Precio del Proveedor) del Producto (Ingreso manual) y desplegarlo. evidente
R1.12 Capturar la Cantidad de unidades del Producto respectivo (Ingreso manual). y calcular valor de evidente
la lnea actualizando los totales de la Gua de Recepcin en la Interfaz al dar OK a la lnea.
R1.13 Grabar en el Detalle de la Gua de Recepcin (lnea a lnea) los datos de cada lnea a medida oculta
que se completa y calcula cada una de ellas.
R1.14 Actualizar los valores de existencia y recibido de Productos (evitando doble actualizacin) al oculta
dar OK a la Gua de Recepcin en su totalidad. Adems calcular el nuevo Costo Promedio.
Nota: (Craig Larman, 5.6.1.a 5.6.3, pgs. 42 a 44) Las funciones bsicas se descubren durante el
desarrollo de las entrevistas con los usuarios, quienes relatan qu es lo que el sistema debe hacer, (en
forma evidente u oculta). Tambin el analista agregar algunas que no son evidentes para el usuario.
354 JUAN BRAVO C.
Casos de Uso: Crear Guas Internas de Recepcin por Compra y Funciones Bsicas
de Despacho por Venta (Productos con registro persistente) (Base Craig Larman)
Ref. # Funcin Categora
R1.15 Ofrecer un mecanismo de almacenamiento persistente. oculta
R2.1 Desplegar la Interfaz de Creacin de Gua de Despacho, N de Gua de Despacho (correlativo) y evidente
Fecha de la Transaccin, - aceptar eventual modificacin de Fecha - (Ingreso Manual).
R2.2 Capturar el Cdigo del Encargado de Despacho (Ingreso Manual). evidente
R2.3 Desplegar datos del Encargado de Despacho registrados en almacenamiento persistente. evidente
R2.4 Capturar la informacin del Cliente usando el RUT (Ingreso Manual) y desplegar datos evidente
pertinentes del Cliente registrados en almacenamiento persistente.
R2.5 Capturar N de Nota de Venta del Cliente (Ingreso Manual), verificar validez (No Existencia evidente
previa) y desplegarlo.
R2.6 Capturar Fecha (Propia) de Nota de Venta del Cliente (Ingreso Manual) y desplegarla. evidente
R2.7 Capturar/Verificar Condicin de Pago de la Venta (Ingreso Manual) y desplegarla. evidente
R2.8 Registrar la transaccin en proceso: los Productos a despachar. Capturar la informacin del evidente
Producto a despachar usando el Cdigo (interno) (Ingreso Manual).
R2.9 Desplegar la descripcin del Producto registrado en almacenamiento persistente. evidente
R2.10 Capturar el Precio al Cliente del Producto (Ingreso manual) y desplegarlo. evidente
R2.11 Capturar la Cantidad de unidades del Producto respectivo (Ingreso manual). y calcular valor de evidente
la lnea actualizando los totales de la Gua de Despacho en la Interfaz al dar OK a la lnea.
R2.12 Grabar en el Detalle de la Gua de Despacho (lnea a lnea) los datos de cada lnea a medida que oculta
se completa y calcula cada una de ellas.
R2.13 Actualizar los valores de existencia y despachado de Productos (evitando doble actualizacin) oculta
al dar OK a la Gua de Despacho en su totalidad.
Funciones Bsicas - Atributos y restricciones de las funciones del sistema

(Base Craig Larman)
Ref. # Funcin Categora Atributo Restriccin Categora
R1.5 Capturar la informacin del Proveedor evidente Tiempo de res- mx. 2 segundos obligatoria
usando el RUT y desplegar sus datos. puesta
Interfaz Estilo Windows obligatoria
En colores y opcional
efectos 3D
R1.12 Capturar la Cantidad de unidades del evidente Tiempo de res- mx. 2 segundos obligatoria
Producto respectivo y calcular valor de puesta
la lnea actualizando los totales de la
Gua de Recepcin en la Interfaz al dar
OK a la lnea.
R1.15 Ofrecer un mecanismo de almacena- Plataforma Usar base de da- obligatoria

oculta
miento persistente. tos corporativa
actualmente ins-
talada
Nota: (Craig Larman, 5.7.1, pgs. 45 y 46) Los atributos y restricciones de las funciones bsicas se
descubren durante el desarrollo de las entrevistas con los usuarios, quienes relatan qu atributos
debiera tener el sistema y cules eventualmente seran las correspondientes restricciones, - si las
hubiera - y si ellas seran obligatorias u opcionales. (Aqu, por razones de espacio, se dan unos
pocos ejemplos).
Diagrama de Casos de Uso

(Casos de Uso Bsicos)
(Base Craig Larman)
Nota:
Para ejemplificar el mtodo de Crear Gua Interna de
Desarrollo en espiral, se estara Recepcin por Compra
proponiendo estos casos de uso para ser
desarrollados en las primeras vueltas de
la espiral. (No se muestran aqu todos
por razones de espacio).
Crear Gua Interna de
Despacho por Venta Proveedor
Encargado
Nota:
de Recepcin
Administrador,
(Empleado)
Encargado de Recepcin,
Encargado de Despacho...
son roles que juegan las personas de la Iniciar Sistema de
Organizacin. (No necesariamente son tres Bodegas
personas distintas).
Cliente
Encargado Administrar Sistema de

de Despacho Bodega de Recepcin
(Empleado) y Despacho
Realizar procesos de
Fin de Da Administrador
(Empleado)
Nota:
Administrar Sistema ...
Son Casos de Uso Genricos que en el
transcurso del anlisis se desagregaran
en otros Casos de Uso.
Caso de Uso de Alto Nivel

Caso de Uso: Crear Gua Interna
Terminal Recepcin
de Recepcin por Compra
(Productos con registro persistente)
(Base Craig Larman) Crear Gua Interna de
Recepcin por Compra
Caso de Uso: Crear Gua Interna de

Recepcin por Compra.
Comentarios relevantes :
Actores: Proveedor, Encargado de
1) Se trata de una transaccin Recepcin.
entre dos entidades, (con Provee-
dor y Encargado de Recepcin). Tipo: Primario. Proveedor
2) Se trata de una transaccin Encargado
de Recepcin Descripcin: Este Caso de Uso co-
que implica una entrega / mienza cuando un Proveedor llega con
(Empleado)
recepcin de Productos. mercadera acompaando la documen-
3) Existe un Registro de Provee- tacin legal de rigor. El Encargado
Nota: El inicio y el fin del
dores. registra el ingreso de la mercadera,
Caso de Uso deberan estar
4) Existe un Registro de Encar- emite la Gua Interna de Recepcin por inequvocamente indicados
gados de Recepcin (Empleado). Compra, firma toda la documentacin, en la narrativa. Ello evita las
5) Existe un Registro de Productos. entrega las copias pertinentes al Pro- superposiciones y ambige-
6) Se lleva un registro persistente veedor y enva las restantes copias a dades en las especificaciones.
sus respectivos destinos.
de la transaccin.
El Proveedor se retira, con lo cual
Nota: Descripcin - Sigue termina el Caso de Uso.
la narrativa que se desprende
del Flujograma de Informacin
correspondiente -.
Nota : (Craig Larman, 2.7.2, pg. 26)
Los Casos de Uso de Alto Nivel son
breves descripciones de un proceso
- usualmente dos o tres frases - .
Ver tambin: (Craig Larman, 6.3.1, pg. 49)
356 JUAN BRAVO C.
Caso de Uso Expandido

Caso de Uso: (Expandido) Crear Gua
Terminal Recepcin
Interna de Recepcin por Compra
(Base Craig Larman) Crear Gua Interna de
Recepcin por Compras
Caso de Uso Expandido

Nota : (Craig Larman, 2.7.2, pg. 26) Encargado de Recepcin
Los Casos de Uso Expandidos son
extensas narrativas de descripcin de un Caso de Uso : Crear Gua Interna de Recepcin por Compra Proveedor
proceso - pueden contener cientos de
frases - . Actores : Proveedor (Iniciador) , Encargado de Recepcin (Actor Primario).
Ver tambin: (Craig Larman, 6.3.2, pg. 50).
Propsito: Capturar Datos de Recepcin de Productos Comprados.
Resumen: Este Caso de Uso comienza cuando un Proveedor contacta a un Encargado de Re-
cepcin para solicitarle que reciba los Productos que est entregando, la Trans-
accin requerida la documenta con una Gua de Despacho o Factura. El Encargado
de Recepcin verifica la entrega fsica (Cantidad y Estado General) contra lo indi-
cado por el Documento adjunto y despus registra en el Terminal de Recepcin los
datos consignados en el mismo, al terminar confirma la Transaccin. El Proveedor
recibe la 3 copia de la Gua de Recepcin y la 3 copia de su Gua de Despacho o
Factura ambas firmadas por el Encargado de Recepcin, quien enva a sus respec-
tivos destinos las restantes copias tambin firmadas (segn Flujograma de Infor-
macin correspondiente). El Caso de Uso termina cuando el Proveedor se retira.
Tipo: Primario y real.
Referencias cruzadas: Funciones: R1.1, R1.2, R1.3, R1.4, R1.5, R1.6, R1.7, R1.8
R1.9, R1.10, R1.11, R1.12, R1.13, R1.14, R1.15
Nota: Este Caso de Uso com-

prende desde la Hoja actual hasta
las siguientes 4 Hojas (5 en total)

(Base Craig Larman ) Curso Normal de los Eventos
Accin de los actores Respuestas del Sistema
1. Este caso comienza cuando un Proveedor se contacta con un
Encargado de Recepcin para solicitar que se efecte una
Recepcin de Productos. (Peticin).
2. El Encargado de Recepcin acuerda realizar la Transaccin.
(Aceptacin del compromiso) y para ello ingresa a la opcin de
Crear Gua de Recepcin del Men de Opciones haciendo (Click)
y despus oprimiendo la tecla (Tab). 3. El sistema despliega la interfaz de Creacin de Gua de Recepcin,
asigna y despliega automticamente en A el N de Gua de Recepcin
4. El Encargado de Recepcin verifica visualmente el N de Gua de correlativo correspondiente y en B la fecha del sistema.
Recepcin y Fecha ofrecidos por el sistema y a continuacin
ingresa su identificacin (Cdigo) en C. 5. El sistema obtiene y despliega el nombre del Encargado de Recepcin
6. El Encargado de Recepcin ingresa en E el RUT del Proveedor y en D.
verifica los datos del mismo desplegados por el sistema.
7. El sistema despliega los datos bsicos del Proveedor (Razn Social,
8. El Encargado de Recepcin ingresa en M, N y O respectivamente Direccin, e-Mail, Comuna, Ciudad, Telfono, Fax) en F, G, H, I, J, K
el N de Gua de Despacho del Proveedor, la Fecha de la Gua de y L respectivamente.
Despacho y el N de la Orden de Compra.
9. El sistema verifica la validez / existencia del N de la Orden de Compra.
10. El Encargado de Recepcin pasa a la seccin de detalle, en el cual
ingresa el Cdigo del Producto en P. 11. El sistema despliega el N de Lnea en LL, obtiene y despliega la
descripcin del Producto en Q.
12. El Encargado de Recepcin verifica los datos del Producto e
ingresa el costo unitario(Precio) y la cantidad recibida en R y
S. Luego oprime (Tab) para grabar la lnea actual y crear una
nueva lnea o terminar el ingreso de datos. 13. El sistema calcula el valor de la lnea ingresada y lo acumula, desplegan-
do los valores en T y U, a la vez que graba la lnea recin completada.
14. Al terminar de ingresar los Productos, el Encargado de Recep-
cin oprime el botn V para indicar al sistema el fin de la
captura de datos. 15. El sistema calcula los valores subtotales / total y los despliega / re-
despliega en los campos T y U, adems actualiza los datos de la
16. El Encargado de Recepcin cierra la interfaz de Transaccin opri- transaccin en el sistema de almacenamiento persistente. Calcula el
miendo el botn XX para volver al Men de Opciones y entrega o costo promedio y lo actualiza Genera un original y 2 copias de la
enva una copia de la Transaccin terminada al Proveedor por la transaccin realizada utilizando la interfaz de salida indicada.
va de comunicacin preestablecida. (Notificacin de cumpli- Limpia la interfaz de entrada y posiciona el cursor en A.
miento del compromiso). Opcionalmente vuelve a oprimir (Tab)
para ingresar otra recepcin, con lo cual el sistema pasa a 3.

(Base Craig Larman)
Interfaz de Entrada
Gua Interna de Recepcin por Compra N Gua Recepcin A
Cdigo Enc. Recepcin C Encargado Recepcin D
Fecha Recepcin B
RUT Proveedor E - F
Comuna I Ciudad J Fono K Fax L
Gua de Despacho de Proveedor N M Fecha G/ D. Proveedor N N de O/C. O
LL P Q R S T

(Base Craig Larman)
Excepciones al Curso Normal de los Eventos:

- Cursos Alternos al Curso Normal de los Eventos -
(para desarrollar los Casos de Uso correspondientes en otras vueltas de la espiral)
1) Campo F : Producto no registrado (Cdigo no existe). Comunicarse con Administrador.
2) Campo M : N de Gua ya existe para el RUT del Proveedor. Indicar error, rechazar.
3) Campo E : RUT de Proveedor no registrado (RUT no existe). Comunicarse con Administrador.
4) Campo C : Encargado de Recepcin no registrado (Cdigo no existe). Comunicarse con Administrador.
5) Campo O : N de Orden de Compra no existe. Comunicarse con Departamento de Compras.
Notas adicionales a la Interfaz de Entrada: Nota:

( para desarrollar en vueltas futuras de la espiral) Se indican algunas de las excepcio-
nes posibles nicamente a modo de
Curso Normal ejemplo.
1) Considerar operacion(es) de Cerrado en Encabezado
2) Considerar operacion(es) y flag de Cerrada en Lneas
Excepciones
3) Considerar operacin(es) y flag de Reversado en Encabezado
4) Considerar operacion(es) de Anulado de Encabezado
5) Considerar operacion(es) y flag de Anulada en Lneas
6) Considerar operacion(es) y flag de Reversada en Lneas
7) Considerar operacin(es) de Modificar en Encabezado
8) Considerar operacin(es de Modificar en Encabezado
9) Considerar operacin(es) de Cancelar en Encabezado
10) Considerar operacin(es) de Cancelar en Lneas
358 JUAN BRAVO C.
Caso de Uso (Expandido): Crear Gua

(Base Craig Larman)
Interfaz de Salida
Gua de Recepcin N 999.999 Fecha 99/99/9999
RUT Proveedor 999.999.999 - X Encargado Recepcin XXXXXXX
Razn Social Proveedor XXXXXXX

Direccin Proveedor XXXXXXX e-Mail XXXXXXX
Comuna XXXXXXX Ciudad XXXXXXX Telfono XXXXXXX Fax XXXXXXX
N G/D del Proveedor 999.999 Fecha G/D Proveedor 99/99/9999 N de O/C. 999.999
99 XXXXXXX XXXXXXXXXXXX 9999,99 9999 999999,99
Firma Autorizada
y Timbre
Total Neto 99999999,99
Modelo Conceptual (simplificado)

Recepcin por Compra
(Base Craig Larman)
Encabezado de
Nota : En este modelo se consideran Gua Interna de
los conceptos mnimos. En un anlisis * Recepcin por *
y desarrollo posteriores se podran in- Compra
cluir conceptos tales como Bodega, *
N de Gua
Terminal, Empresa, etc. Por lo contrario, Emplea- Fecha
se podran excluir : Empleados, Ordenes dos Proveedor
Provee-
de Compra. dores
Cdigo Nombre 1
Nombre 1 RUT
1 Nombre
Nota: 1..5 Direccin
La flecha gruesa entre el Encabe-
zado y el Detalle indica una Relacin Detalle de Gua
de Pertenencia. (Base Juan Bravo C.- Interna de Recep-
La Nueva Visin... pg 200) cin por Compra
*
Descripcin Ordenes
Productos Costo de Compra
1
1 Cantidad
Cdigo N OC
Descripcin Fecha
Nota: Segn Craig Larman Costo
(9.3 y 9.4 - pgs. 87 a 91 -,
adems de 9.6.1 a 9.6.3 - pgs.96
y 97) Se trata de conceptos, asocia-
ciones y atributos del mundo real, no Nota:
se trata de un modelo de software. Dentro de los requerimientos,
no necesariamente se encuentra
el concepto de Orden de Compra.
(Puede ser un ingreso manual).
Diagrama de Diseo de Clases

(Borrador inicial) Nota: A diferencia del Modelo
Crear Gua Interna de Conceptual, que muestra atributos
tiles para entender los concep-
Recepcin por Compra Encabezado de Gua tos del contexto, se descubri - obser-
(Productos con registro persistente) Interna de Recep- vando la interfaz de entrada -, la conve-
cin por Compra niencia de agregar otros atributos al enca-
(Base Craig Larman) bezado. (A su vez se elimin : Nombre)
RUT Proveedor
Nota: Segn Craig Larman N de Gua Proveedor
(21.3, pg.257): Si bien la pre- N Gua Interna
sentacin de los diagramas de Fecha Recepcin
clases es posterior a la creacin
*
Cdigo Enc. Recepcin
de los diagramas de interaccin, en la Emplea- Fecha Gua Proveedor *
prctica usualmente se crean en para-
*
dos N de Ord. de Compra Provee-
lelo. Muchas clases, mtodos y relacio- Cdigo
nes pueden bosquejarse tempranamente total() dores
Nombre
en la etapa de Diseo 1 RUT
1 1 Nombre
1..5 Direccin
Detalle de Gua validarRut()
Interna de Recep-
Nota: Segn Craig Larman cin por Compra
(21.8.4 a 21.8.8 - pgs.262 - 264) * Ordenes
Salvo casos especficos, es conve- Descripcin
niente omitir los mtodos : crear(),
Productos Costo 1 de Compra
modificar(), eliminar() y consultar() 1 Cantidad
Cdigo N OC
en los diagramas de clases dado que Descipcin
subtotal() Fecha
no agregan valor y aumentan el Costo
ruido - se consideran implcitos -
costoProm()
Nota:
Dentro de los requerimientos,
no necesariamente se encuentra
el concepto de Orden de Compra.
(Puede ser un ingreso manual).
Diagrama de Secuencia del Sistema

Crear Gua Interna de Recepcin
por Compra
(Base Craig Larman) Versin en Lenguaje Natural
Caso de Uso: :Sistema

Crear Gua de Recepcin Encargado de Recepcin
( Curso Normal de los Eventos)
Ingresar a la Opcin del Men
Obtener / Ingresar(Tab) N de
Desplegar la Interfaz
Gua Recepcin y Fecha sistema,
verificar correlativo y fecha. Crear la Gua de Recepcin
Ingresar Cdigo del Empleado y
obtener / verificar el nombre del Ingresar Cdigo del Empleado en Encabezado
mismo.
Ingresar RUT del Proveedor y Ingresar RUT del Proveedor en Encabezado
obtener / verificar los datos del
mismo.
Ingresar datos de G/D Provee- Ingresar N Gua Proveedor, Fecha y N O/C en Encabezado
dor ( N Gua, Fecha, N O/C )
Para cada lnea: Ingresar Cdigo del Producto en Lnea Detalle
Ingresar el Cdigo del
Producto Ingresar Precio y Cantidad del Producto
Obtener / Verificar datos del Reiterar hasta
Producto que no haya
ms Productos Dar OK a la Lnea de Detalle
Ingresar precio y cantidad del que ingresar
Producto
Dar OK a la lnea (Grabar) Calcular la Lnea de Detalle
Al terminar:
Dar OK al Final para Terminar la Creacin
Dar OK a la Transaccin
(Grabar)
Salir al Men
Salir al Men
360 JUAN BRAVO C.
Diagrama de Secuencia del Sistema

Crear Gua Interna de Recepcin
por Compra Versin llamando los Eventos
(Productos con registro persistente) por su Nombre
(Base Craig Larman) ( equivalente a Operaciones del sistema)
Caso de Uso:
Crear Gua de Recepcin :Sistema
( Curso Normal de los Eventos) Encargado de Recepcin
ingresarOpcin(CrearGuiaRecepcion)
Obtener / Ingresar(Tab) N de
Gua Recepcin y Fecha sistema, desplegar(NumGuiaRecCom, FechaR)
verificar correlativo y fecha.
Ingresar Cdigo del Empleado y crearEncabezado(NumGuiaRecCom, FechaR)
obtener / verificar el nombre del
mismo. ingresarCodEmpleado(CodigoEmpleado)
Ingresar RUT del Proveedor y Nota: desplegar
es subordinado de
obtener / verificar los datos del ingresarRutProveedor(RutProveedor) ingresarOpcion y no es
mismo. invocado por el actor en
Ingresar datos de G/D Provee- forma directa.
ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)
dor ( N Gua, Fecha, N O/C )
Para cada lnea: ingresarCodProducto(CodigoProducto)
Ingresar el Cdigo del Nota: calcularTo-
Producto tales es subordinado
Obtener / Verificar datos del Reiterar hasta de grabarLnea y no
que no haya ingresarPrecioCantidad(Precio,Cantidad)
Producto es invocado por el actor
Ingresar precio y cantidad del ms Productos en forma directa.
que ingresar grabarLnea()
Producto
Dar OK a la lnea (Grabar) calcularTotales()
Al terminar:
Dar OK a la Transaccin terminarTransaccin()
(Grabar)
Salir al Men salirAMen()
Operaciones del Sistema

Recepcin por Compra
(Base Craig Larman)
Visin Dinmica del Sistema
Sistema
ingresarOpcin(CrearGuiaRecepcion)
desplegar(NumGuiaRecCom, FechaR)
crearEncabezado(NumGuiaRecCom, FechaR)
ingresarCodEmpleado(CodigoEmpleado)
ingresarRutProveedor(RutProveedor)
ingresarCodProducto(CodigoProducto)
ingresarPrecioCantidad(Precio,Cantidad)
grabarLnea()
calcularTotales()
terminarTransaccin()
salirAMenu()
Contratos: Crear Gua Contrato

Interna de Recepcin Nombre: ingresarOpcion(CrearGuiaRecepcion)
por Compra
Responsabilidades: Aceptar (Click) en la opcin del Men. Obtener el siguiente N de Gua
(Productos con registro correlativo (NumGuiaRecCom). Obtener la fecha del sistema (FechaR) .
persistente) Usar ambos parmetros para invocar el despliegue de la interfaz de
(Base Craig Larman) CrearGuiaRecepcin
Tipo: Sistema
Referencias cruzadas: R1.1
Notas: Usar Sistema de Men; Ahora() de MS Access; obtener ltimo

N de Gua de Recepcin vlido y sumarle 1 (uno) para obtener
el nuevo N correlativo de Gua de Recepcin.
Nota:
Excepciones: N/A
Los nombres de elementos usados
Salida: N/A
en los contratos hacen referencia
Precondiciones: El sistema tiene el Men y la opcin Crear Gua de Recepcin por Compra
al Diagrama de Secuencia de pg. 18,
requerida instalados y activos.Adems conoce y tiene acceso a
al Modelo de Clases de pg. N 38 EncGuiaRecCompra.NumGuiaRecCom
y al Modelo Funcional de pg. N 39.
Postcondiciones: Se acept (Click) en el Men de Opciones.
Nota: Obtener Fecha del sistema y obtener N de Gua correlativo son opera-
ciones (mtodos) que no son evidentes para el usuario en este momen-
to, sin embargo, se harn evidentes al momento real de despliegue,
(descrito por el siguiente contrato).
Se obtuvo la fecha del sistema (FechaR).
Se obtuvo el ltimo N vigente y se calcul el nuevo N correlativo de Gua de
Recepcin por Compra (NumGuiaRecCom).
Se invoc el despliegue de la interfaz de Creacin de la Gua de Recepcin
por Compra usando los parmetros NumGuiaRecCom y FechaR.
Contratos:Crear Gua
Contrato
Interna de Recepcin
Nombre: desplegar(NumGuiaRecCom, FechaR)
por Compra
(Productos con registro Responsabilidades: Desplegar la Interfaz de Creacin de Gua de Recepcin. Aceptar (Tab)
para iniciar el ingreso de la transaccin. Desplegar NumGuiaRecCom,
persistente) desplegar FechaR, opcionalmente aceptar modificacin manual de la fecha.
(Base Craig Larman)
Tipo: Sistema
Notas: Esta operacin es invocada por ingresarOpcion. El Empleado
oprime (Tab) para iniciar el ingreso.
Excepciones: N/A
Nota:
Los nombres de elementos usados Salida: N/A
Precondiciones: El sistema tiene el Men y la opcin Crear Gua de Recepcin por Compra
requerida instalados y activos. Tiene disponibles a NumGuiaRecCom y
al Modelo de Clases de pg. N 38 FechaR.
y al Modelo Funcional de pg. N 39. Postcondiciones: Se despleg la interfaz de Crear Gua de Recepcin por Compra (limpia).
Se posicion el cursor en A y se acept (Tab) para proseguir.
Se despleg el Nmero correlativo de Gua de Recepcin: NumGuiaRecCompra
en A y la Fecha: FechaR en B.
362 JUAN BRAVO C.
Contratos: Crear Gua

Contrato
Interna de Recepcin
Nombre: crearGuiaRecCompra(NumGuiaRecCom, FechaR)
por Compra
(Productos con registro Responsabilidades: Crear instancias de EncGuiaRecCompra y DetGuiaRecCompra
y establecer las asociaciones necesarias entre Terminal,
persistente) EncGuiaRecCompra y DetGuiaRecCompra
(Base Craig Larman)
Tipo: Sistema
Notas: El Empleado oprime (Tab) para cambiar de campo en la interfaz
para el ingreso. Opcionalmente usa el mouse
Excepciones: N/A
Nota:
Los nombres de elementos usados Salida: N/A
Precondiciones: El sistema tiene el Men, la opcin Crear Gua de Recepcin por Compra
y la interfaz correspondiente requerida instalados y activos.
al Modelo de Clases de pg. N 38
y al Modelo Funcional de pg. N 39. Postcondiciones: Se cre una nueva instancia de EncGuiaRecCompra (creacin de instancia)
Se asoci EncGuiaRecCompra a Terminal (asociacin formada)
Se cre una nueva instancia DetGuiaRecCompra (creacin de instancia)
Se asoci DetGuiaRecCompra a EncGuiaRecCompra (asociacin formada)
Se asign el Nmero correlativo de Gua de Recepcin al campo:
EncGuiaRecCompra.NumGuiaRecCom (modificacin de atributos)
Se asign la Fecha del sistema al campo:
EncGuaRecCompra.FechaR ( modificacin de atributos)
Se posicion el cursor en el campo C : Cdigo Enc. Recepcin
Contratos: Crear Gua Interna

(Productos con registro Contrato
persistente) Nombre: ingresarCodEmpleado(CodigoEmpleado)
(Base Craig Larman) Responsabilidades: Aceptar el ingreso de CodigoEmpleado. Basado en CodigoEmpleado,
obtener y desplegar Nombre registrado en el sistema de almacenamiento
persistente. (Alternativa a Lista de Valores Posibles).
A continuacin posicionar el cursor en el campo E.
Tipo: Sistema
Referencias cruzadas: R1.3, R1.4, R1.15

Nota:
Notas: Usar Base de Datos MS Access y (Tab) para sucesivos campos
en los contratos hacen referencia Excepciones: Error en ingreso manual del Cdigo o Cdigo no registrado
Salida: N/A
y al Modelo Funcional de pg. N 39. Precondiciones: El sistema conoce a Empleados.CodigoEmpleado (Registrado opor-
tunamente con anterioridad)
Postcondiciones: Se despleg CodigoEmpleado en C y Nombre en D..
Se asoci EncGuiaRecCompra a una instancia de Empleados basado en
una igualdad de CodigoEmpleado (asociacin formada)
Se asign CodigoEmpleado a EncGuiaRecCompra.CodigoEmpleado (modi-
ficacin de atributo)
Nota : Alternativamente ( desde Lista de Valores Posibles ) - Sustituyendo
CodigoEmpleado por Nombre -
- Se asign Nombre a EncGuiaRecCompra.Nombre (modificacin de
atributo).
Se posicion el cursor en el campo E: RUT Proveedor

de Recepcin por Compra Contrato
(Productos con registro
persistente) Nombre: ingresarRutProveedor(RutProveedor)
(Base Craig Larman) Responsabilidades: Aceptar el ingreso de RutProveedor, por su intermedio, obtener y des-
plegar los Datos del Proveedor registrados en el sistema de almacena-
miento persistente. A continuacin posicionar el cursor en el campo M.
Tipo: Sistema
Referencias cruzadas: R1.5, R1.15
Notas: Usar Base de Datos MS Access - el Encargado de Recepcin oprime

Nota:
(Tab) para pasar a los sucesivos campos -
Excepciones: Error en ingreso manual del RUT o RUT no registrado
al Diagrama de Secuencia de pg. 18, Salida: N/A
Precondiciones: El sistema conoce a Proveedores.RutProveedor (Registrado oportuna-
mente con anterioridad)
Postcondiciones: Se despleg RutProveedor en el campo E

Se asoci EncGuiaRecCompra a una instancia de Proveedores basado en una
igualdad de RutProveedor (asociacin formada)
Se asign RutProveedor a EncGuiaRecCompra.RutProveedor (modificacin de
atributo)
Se desplegaron los datos bsicos del Proveedor segn los campos de la interfaz
( RazonSocial, Direccion, eMail, Comuna, Ciudad, Fono, Fax) (Campos F,
G, H, I, J, K, L )
Se posicion el cursor en el campo M: Gua de Despacho de Proveedor N

persistente) Contrato
(Base Craig Larman) Nombre: ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)
Responsabilidades: Aceptar el ingreso de NumGDP, FecGD, NumOC, eventualmente verificar
existencia del N de Orden de Compra registrada en el sistema de almace-
namiento persistente. A continuacin posicionar el cursor en el campo P.
Tipo: Sistema
Nota: Referencias cruzadas: R1.6, R1.7 y R1.8, R1.15
Notas: Usar Base de Datos MS Access - el Encargado de Recepcin oprime
(Tab) para pasar a los sucesivos campos -
Excepciones: N/A
y al Modelo Funcional de pg. N 39. Salida: N/A
Precondiciones: El sistema eventualmente conoce a EncOrdCompra.NumOC (Registrado
oportunamente con anterioridad). Est disponible la Gua de Despacho
del Proveedor.
Postcondiciones: Se despleg NumGDP, FecGD, NumOC en los campos M, N y O
Eventualmente, se asoci EncGuiaRecCompra a una instancia de EncOrdCom-
pra basado en una igualdad de NumOC (asociacin formada)
Se asign NumGDP a EncGuiaRecCompra.NumGDP
(modificacin de atributo)
Se asign FecGD a EncGuiaRecCompra.FecGD (modificacin de atributo)
Se asign NumOC a EncGuiaRecCompra.NumOC (modificacin de atributo)
Se posicion el cursor en el campo P:Cdigo.
364 JUAN BRAVO C.
Contratos: Contrato
Crear Gua Interna de Nombre: ingresarCodProducto(CodigoProducto)
Recepcin por Compra Responsabilidades: Aceptar el ingreso de CodigoProducto. Basado en CodigoProducto, ob-
(Productos con registro tener y desplegar los Datos del Producto registrados en el sistema de
almacenamiento persistente. Al oprimir (Tab) - fin de ingreso de Codi-
persistente) goProducto - asignar Nmero correlativo a la Instancia de DetGua-
(Base Craig Larman) RecCompra.NumLinea y pasar al campo Q. Si la Descripcin es la cor-
recta pasar (Tab) al campo R: Precio.
Tipo: Sistema
Notas: Usar Base de Datos MS Access y tecla (Tab)
Nota: Excepciones: Error en ingreso manual del Cdigo o Cdigo no registrado

Salida: N/A
al Diagrama de Secuencia de pg. 18, Precondiciones: El sistema conoce a Productos.CodigoProducto (Registrado oportuna-
al Modelo de Clases de pg. N 38 mente con anterioridad)
Postcondiciones: Se redespleg CodigoProducto en P
Se despleg el Nmero de Lnea NumLnea en LL
Se asoci DetGuaRecCompra a una instancia de Productos basado en una
igualdad de CodigoProducto (asociacin formada)
Se asign NumLnea a DetGuiaRecCompra.NumLnea ( modificacin de
atributo )
Se asoci la nueva lnea de DetGuaRecCompra a EncGuaRecCompra
(asociacin formada)
Se asign CodigoProducto a DetGuiaRecCompra.CodigoProducto (modi-
ficacin de atributo)
Se despleg la Descripcin del Producto, Descripcion en Q.
Se posicion el cursor en R: Precio

persistente) Contrato
(Base Craig Larman)
Nombre: ingresarPrecioCantidad(Precio, Cantidad)
Responsabilidades: Aceptar el Precio del Producto del Proveedor en R, avanzar con (Tab)
hasta el campo S. Aceptar Cantidad en S.
Si todo est correcto pasar con (Tab) al campo T.
Tipo: Sistema
Nota: Referencias cruzadas: R1.11 y R1.12

Notas: Usar Base de Datos MS Access
al Diagrama de Secuencia de pg. 18, Excepciones: N/A
Salida: N/A
Precondiciones: El sistema conoce a Productos.Existencia (Registrado oportuna-
mente con anterioridad)
Postcondiciones: Se posicion el cursor en R
Se redespleg Precio en R y se posicion el cursor en S.
Se redespleg Cantidad en S
Se asign Precio a DetGuiaRecCompra.Precio y Cantidad a
DetGuiaRecCompra.Cantidad ( modificacin de atributos)
Se posicion el cursor en T: Valor Neto

Interna de Recepcin por Nombre: grabarLnea()
Compra
Responsabilidades: Aceptar avance con (Tab) hasta la siguiente lnea de la interfaz, creando
una nueva Lnea de DetGuiaRecCompra. Calcular /ValorLnea y desple-
persistente) garlo en T de la lnea previa. Grabar en almacenamiento persistente un
(Base Craig Larman) registro de DetGuiaRecCompra con los datos ingresados/calculados en la
lnea previa (anterior). Calcular /ValorTotal y desplegarlo en U. Posicio-
nar el cursor en P de la nueva lnea.
Tipo: Sistema
Referencias cruzadas: R1.13, R1.15
Notas: Usar Base de Datos MS Access. En este punto el sistema queda listo para
Nota:
reiterar el ingreso de un nuevo cdigo CodigoProducto o caso contrario,
Los nombres de elementos usados pasar a terminarTransaccin()
Excepciones: N/A
al Modelo de Clases de pg. N 38 Salida: N/A
Precondiciones: N/A
Postcondiciones: Se calcul /ValorLnea y se despleg en T
Se calcul/recalcul /ValorTotal y se despleg/redespleg en U.
Se asign /ValorLnea a DetGuiaRecCompra./ValorLnea
( modificacin de atributo )
Se grab en almacenamiento persistente el registro de DetGuiaRecCompra
recin completado
Se cre una nueva Lnea de DetGuiaRecCompra. (creacin de instancia)
Se asoci la nueva Lnea de DetGuiaRecCompra. a EncGuiaRecCompra
(asociacin formada)
Se posicion el cursor en P de la nueva Lnea de DetGuiaRecCompra.

Interna de Recepcin Nombre: terminarTransaccin()
por Compra
Responsabilidades: Aceptar (click) del Botn V (Grabar). Recalcular /ValorTotal y redesple-
(Productos con registro garlo en U. Grabar en almacenamiento persistente la instancia actual de
persistente) EncGuiaRecCompra.Limpiar los datos desplegados en la interfaz. Actua-
(Base Craig Larman) lizar Productos.Existencia, Productos.Recibido, Productos.CostoUn y
DetGuiaRecCompra.notAct. Posicionar en A el cursor.
Tipo: Sistema

Notas: Usar Base de Datos MS Access. Al terminar, el sistema queda listo pa-
Nota:
ra ingresar una nueva transaccin o volver al Men de opciones.
Los nombres de elementos usados Excepciones: Productos.Existencia y Productos.Recibido ya fueron actualizados.
en los contratos hacen referencia Salida: N/A
al Diagrama de Secuencia de pg. 18, Precondiciones: N/A
y al Modelo Funcional de pg. N 39. Postcondiciones: Se activ onClick_CBGrabar de commandGrabar
Se recalcul /ValorTotal y se grab/regrab en almacenamiento persistente la
instancia EncGuiaRecCompra y las lneas completadas DetGuiaRecCompra.
Se verific notAct() de DetGuiaRecCompra y se actualiz Productos.Existencia,
Productos.Recibido y Productos.CostoUn, regrabando los registros de Productos
afectados por la transaccin (modificacin de atributo), despus de ello, se le
asign el valor false al atributo DetGuiaRecCompra.notAct (modificacin de
atributo), regrabando los registros correspondientes de DetGuiaRecCompra.
Se cre una nueva EncGuiaRecCompra (creacin de instancia) (en blanco)
La nueva EncGuiaRecCompra fue asociada a Terminal (asociacin formada)
Se cre una nueva DetGuiaRecCompra ( creacin de instancia) (en blanco)
Se asoci la nueva instancia de DetGuiaRecCompra a EncGuiaRecCompra
(asociacin formada)
Se posicion el cursor en A, esperando la prxima accin del usuario.
366 JUAN BRAVO C.
Etapa de Diseo
Las pginas siguientes corresponden a la etapa de diseo,

la cual se extiende hasta la documentacin de las clases
de diseo y los diagramas correspondientes -.
Diagramas de Colaboracin: Nota:

Creacin de EncGuiaRecCompra ingresarOpcion(CrearGuiaRecepcion)
es un mtodo del Men. La clase Fecha es
ingresarOpcion(CrearGuiaRecepcion) una clase del Sistema en s - siendo ahora() un
mtodo de la misma-, mientras que desplegar(Guia
desplegar(GuiaRecCompra) RecCompra) pertenece a Terminal y siguiente()
crearEncabezado(NumGuiaRecCom, FechaR) pertenece a la clase EncRecCompra - an cuando
esta ltima es una funcin genrica reutilizable-.
(Base Craig Larman) Nota: En forma excepcional se
representan en este diagrama de
Nota: desplegar() es colaboracin los mensajes correspon-
ingresarOpcion(CrearGuiaRecepcion)
mtodo propio de Termi- dientes a dos operaciones y sus respec-
nal, por ello este mensaje no desplegar(GuaRecCompra) tivos contratos (desplegar es subordinado
va ms all de este punto. de ingresarOpcion).
1:NumGuiaRecCom := siguiente():NumGuia
t1:Terminal :EncGuiaRecCompra
2:FechaR := ahora():Fecha
Fecha
3 :[NuevaGuiaRecepcion] crearEncabezado(NumGuiaRecCom, FechaR)

t1:Terminal r 1:EncGuiaRecCompra
Omisin del Contenedor de Lneas

Nota: Segn Craig Larman 3.1 :[NuevaGuiaRecepcion] crearDetRecCompra(NumGuiaRecCom)
( 21.8.6 - pg.262 ) : Un mensaje
a un multiobjeto se interpreta como
un mensaje al objeto contenedor / colec-
cin en s mismo... estas clases ( tales como Nota :
java.util.Vector... ) son clases predefinidas
crearDetRecCompra() es
de la biblioteca de clases... no es til mos- l1:DetGuiaRecCompra
trarlas explcitamente... agregan ruido una de las 4 funciones
pero poca informacin nueva. bsicas implcitas. (Podra
ser omitida en el Modelo de
Datos).
Diagramas de Colaboracin:
Creacin de EncGuiaRecCompra
ingresarCodEmpleado(CodigoEmpleado)
ingresarRutProveedor(RutProveedor)
(Productos con registro persistente) ingresarCodEmpleado(CodigoEmpleado)
(Base Craig Larman)
1:ingresarCodEmpleado(CodigoEmpleado)
t1:Terminal r1:EncGuiaRecCompra
1.1:Nombre := consultarDatos(CodigoEmpleado)
Asignacin de Responsabilidades
Nota: Segn Craig Larman
( 18.9 a 18.11 - pg.193 a 205 )
La aplicacin de los patrones GRASP e1:Empleados
es la gua para determinar las responsa-
bilidades y la estructura del diagrama.
La forma y secuencia de los mensajes que
activarn las operaciones respectivas se ingresarRutProveedor(RutProveedor)
derivan de la aplicacin de estos patrones.
2:ingresarRutProveedor(RutProveedor)
2.1.a:RazonSocial := consultarDatos (RutProveedor)

2.1.b:Direccion := consultarDatos (RutProveedor)
2.1.c: eMail := consultarDatos (RutProveedor)
2.1.d:Comuna := consultarDatos (RutProveedor)
2.1.e:Ciudad := consultarDatos (RutProveedor)
2.1.f: Fono := consultarDatos (RutProveedor)
2.1.g:Fax := consultarDatos (RutProveedor)
p1:Proveedores
(Base Craig Larman)
1: ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)


es equivalente a repetir tres veces la funcin aceptarDatos(),
enviando cada vez un parmetro correspondiente a un atributo
distinto de la misma instancia de
1.a: aceptarDatos(NumGuiaRecCom, NumGDP)
1.b: aceptarDatos(NumGuiaRecCom, FecGD) ll:DetGuiaRecCompra
1.c: aceptarDatos(NumGuiaRecCom, NumOC)
368 JUAN BRAVO C.
(Base Craig Larman)
siguiente () : NumLinea
1:ingresarCodProducto(CodigoProducto)
2 *:[i:=1...6] NumLnea:= siguiente () : NumLinea
Asignacin de Responsabilidades 1.1:aceptarCodigo(CodigoProducto)

( 18.9 a 18.11 - pg.193 a 205 ) 2.1 *:[i:=1...6] NumLnea:= siguiente () : NumLinea
La aplicacin de los patrones GRASP
es la gua para determinar las responsa- 2.2:crearLinea(NumLinea)
bilidades y la estructura del diagrama.
La forma y secuencia de los mensajes que
activarn las operaciones respectivas se
derivan de estos patrones. 1.2:Descripcion := consultarDatos(CodigoProducto)
ll:DetGuiaRecCompra
b1:Productos
Omisin del Contenedor de Lneas
( 21.8.6 - pg.262 ) : Un mensaje
a un multiobjeto se interpreta como
un mensaje al objeto contenedor / colec-
cin en s mismo... estas clases ( tales como
java.util.Vector... ) son clases predefinidas
de la biblioteca de clases... no es til mos-
trarlas explcitamente... agregan ruido
pero poca informacin nueva.
ingresarPrecioCantidad(Precio, Cantidad)
grabarLnea() y calcularTotales()
(Productos con registro persistente) ingresarPrecioCantidad(Precio, Cantidad)
(Base Craig Larman)
1:ingresarPrecioCantidad(Precio, Cantidad)
Nota: calcularTotales es
1.1:aceptarDatos(Precio, Cantidad)
subordinado de grabarLnea
y no es invocado por el actor
grabarLinea() en forma directa.
calcularTotales()
ll:DetGuiaRecCompra
2: /ValorTotal := calcularTotales()
2.1*:[i:=1...6]: /ValorLnea := calcularValor()
ll:DetGuiaRecCompra
Nota:No se muestra la secuen-
cia de mensajes que correspondera
a grabarLinea(). Esta corresponde-
ra a la interaccin entre la capa
Nota:
del dominio (aplicacin) y la capa de
Despus de grabarLinea() el
servicios de almacenamiento per-
usuario vuelve a la accin anterior
sistente. (Otro conjunto de diagra-
de ingresarCodProducto() hasta que
mas - no abordado aqu -).
no queden ms productos que ingre-
sar, en cuyo caso pasa a la siguiente
accin :
terminarTransaccion()
Nota:terminarTransaccin() es realmente un mensaje

Diagramas de Colaboracin: compuesto , que se desdobla en :
Creacin de EncGuiaRecCompra calcularTotales() y los mensajes que interactan con las
capas de almacenamiento persistente y presentacin. Esto
terminarTransaccion() (Primera Parte) es, por ejemplo, sumarExistencia() se realiza en la capa de
(Productos con registro persistente) dominio, sin embargo se registra en la capa de almacena-
miento persistente (Tema no considerado aqu)
(Base Craig Larman) calcularTotales()
Nota:
1: /ValorTotal := calcularTotales()
terminarTransaccion() es muy t1:Terminal r1:EncGuiaRecCompra
amplio y se presenta dividido en
dos partes.
1.1*:[i:=1...6] /ValorLnea := calcularValor()
sumarExistencia(CodigoProducto, Cantidad)
sumarRecibido(CodigoProducto, Cantidad) ll:DetGuiaRecCompra
calcularCPP(CodigoProducto, Cantidad, Precio)
2.a*:[i:=1...6 ][notAct] sumarExistencia(CodigoProducto, Cantidad)

2.b*:[i:=1...6 ][notAct] sumarRecibido(CodigoProducto, Cantidad)
2.c*:[i:=1...6 ][notAct] calcularCPP(CodigoProducto, Cantidad, Precio)
2.1.a*:[i:=1...6 ][notAct] sumarExistencia(CodigoProducto, Cantidad)

2.1.b*:[i:=1...6 ][notAct] sumarRecibido(CodigoProducto, Cantidad)
2.1.c*:[i:=1...6 ][notAct] calcularCPP(CodigoProducto, Cantidad, Precio)
2.3*:[i:=1...6 ][notAct] notAct := notAct(notAct := false)

ll:DetGuiaRecCompra
2.2.a*:[i:=1...6 ][notAct] sumarExistencia(CodigoProducto, Cantidad)
2.2.b*:[i:=1...6 ][notAct] sumarRecibido(CodigoProducto, Cantidad)
2.2.c*:[i:=1...6 ][notAct] calcularCPP(CodigoProducto, Cantidad, Precio)
b1:Productos
Nota: terminarTransaccin() finalmente termina

Diagramas de Colaboracin: enviando los mensajes para crearEncadezado() y ob-
Creacin de EncGuiaRecCompra tener los datos de inicializacin desplegndolos en la interfaz
limpia. Por cierto que esto implica una interaccin entre la
terminarTransaccion() (Segunda Parte) capa de dominio y la capa de presentacin. (Tema no abor-
(Productos con registro persistente) dado aqu). Para implementar el mensaje compuesto
terminarTransaccin() (completo), se usaran los patrones
(Base Craig Larman) aplicables - entre otros, por ejemplo, Indireccin, Fachada,
Observador -.
siguiente():NumGuia
ahora():Fecha
3:NumGuiaRecCom := siguiente():NumGuia
t1:Terminal :EncGuiaRecCompra
4:FechaR := ahora():Fecha
Fecha
5 :[NuevaGuiaRecepcion] crearEncabezado(NumGuiaRecCom, FechaR) r 1:EncGuiaRecCompra

t1:Terminal
5.1 :[NuevaGuiaRecepcion] crearDetRecCompra(NumGuiaRecCom)
l1:DetGuiaRecCompra
370 JUAN BRAVO C.
Diagrama de Diseo de Clases Encabezado de Gua

de Recepcin
Crear Gua Interna de * RUT Proveedor
Recepcin por Compra Proveedores N Gua Proveedor
1 1 N de Gua Recepcin Empleados
(Productos con Registro RUT Proveedor Fecha Recepcin
persistente) Razn Social Cdigo Empleado *
Cdigo
Direccin Fecha Guia Proveedor 1 Empleado
N Orden de Compra *
e-Mail Nombre
/ Valor Total
Comuna
Transaccin Cerrada
Ciudad Transaccin Anulada
Nota: Agregado para
Pas crearEncabezado()
clarificar el contex- Contacto aceptarDatos()
to, (ingreso manual). Fono calcularTotales() Nota: Agregado para
Fax cerrarTransaccin() clarificar el contexto, en
anularTransaccin() principio es una Lista de
Gua de Despa- Valores Posibles.
copiarTransaccin()
cho de Proveedor siguiente()
1 1 Nota: Agregado para
N Gua de 1..* clarificar el contex-
Proveedor to, (ingreso manual).
Detalle de Gua de
RUT Proveedor Productos
Recepcin Ordenes
Fecha Gua Cdigo Producto
etc... N Lnea de Compra
Descripcin 1
U.Medida Cdigo Producto
N Orden
* Precio
Costo Unitario 1 de Compra
Cantidad
Existencia Inicial / Valor Lnea
Nota: Segn Craig Larman Existencia Datos
notAct
(21.8.4 a 21.8.8 - pgs.262 - 264) Recibido Lnea Cerrada
Salvo casos especificos, es conve-
Despachado Lnea Anulada
niente omitir los mtodos : crear(),
modificar(), eliminar() y consultar() sumarExistencia() crearLnea() Nota: Al crear la
en los diagramas de clases dado que restarExistencia() aceptarCodigo() lnea de detalle,
no agregan valor y aumentan el aceptarDatos() notAct se incializa
sumarRecibido() calcularValor() a: true
ruido - se consideran implcitos -
sumarDespachado() cerrarLnea()
existenciaNegativa() anularLnea()
copiarLnea()
calcularCPP() siguiente()
notAct()
Encabezado de Gua
de Recepcin Proveedores
Modelo Funcional RUT Proveedor
C/E, msg1, msg2,
C/E y msg4
(Detallado y Generalizado) N Guia Proveedor msg6 y msg10 RUT Proveedor
N Gua Recepcin Razn Social
Crear Gua Interna de Fecha Recepcin Direccin
Recepcin por Compra Cdigo Empleado Terminal e_Mail
Fecha Gua Proveedor
(Productos con Registro N Orden de Compra Encabezado, detalle y totales segn Comuna
/ Valor Total formato de pantalla adjunto. Ciudad
persistente) Pas
Transaccin Cerrada 1. Desplegar interfaz(Correlativo, Fecha).
(Base este libro) Transaccin Anulada 2. Aceptar datos. Contacto
3. Enviar mensajes de C/E a registros. Fono
1. crearEncabezado()
4. Enviar mensajes de consulta de datos Fax
2. aceptarDatos()
5. Calcular totales cumulativos
6. calcularTotales() 4. consultarDatos()
6. Enviar mensajes de actualizacin de
7. cerrarTransaccin()
existencias y actualizar lnea a lnea
8. anularTransaccin()
el registro de la transaccin Empleados
9. copiarTransaccin()
10. siguiente() C/E y msg4
Cdigo
Empleado
Nota: Agregado para C/E, msg1, msg2, msg3,
clarificar el contex- C/E, msg4, Productos Nombre
msg6, msg10 y msg11
to, (ingreso manual).
msg6, msg8 ...
Detalle de Gua de y msg11 Cdigo Producto
C/E y msg4 Recepcin Descripcin 4. consultarDatos()
N Lnea U.Medida
Cdigo Producto
Gua de Despacho Precio Costo Unitario
Cantidad Existencia Inicial C/E y msg4
de Proveedor / Valor lnea Existencia Ordenes
notAct
N Gua de Lnea Cerrada Recibido de Compra
Proveedor Lnea Anulada Despachado
RUT Proveedor 4. consultarDatos() N Orden
1. crearLnea()
Fecha Gua 2. aceptarCodigo()
Nota: Al crear la 6. sumarExistencia() de Compra
lnea de detalle,
etc... 3. aceptardatos() notAct se incializa
7. restarExistencia() Datos
6. calcularValor() a: true 8. sumarRecibido()
4. consultarDatos() 7. cerrarLnea() 9. sumarDespachado() 4. consultarDatos()
8. anularLnea() 10. existenciaNegativa()
9. copiarLnea() 11. calcularCPP()
10. siguiente()
11. notAct()
BIBLIOGRAFA
ACEVEDO, H. (1996): El anlisis estructurado de sistemas y el desarrollo de proyectos

informticos, Valparaso, Ecogestin Editora.
ACKOFF, R. (1972): Un concepto de planeacin de empresas, Mxico, Limusa.
ACKOFF, R. (1979): Rediseando el futuro, Mxico, Limusa.
ALLEN, D. (1994): Desarrollo con xito de nuevos productos, Barcelona, Biblioteca de
empresa del Financial Times, Ediciones Folio.
ANDREU, R., RICART, J. y VALOR, J. (1991): Estrategia y sistemas de informacin, Espa-
a, McGraw-Hill.
AT&T Quality Process Center (1992): Reengineering Handbook, USA, AT&T Bell Labora-
tories.
BAEZA, R. (1991): Apuntes del curso orientacin a objetos, Chile, Universidad de Chile.
BRAVO, J. artculos:
Se justifica el desarrollo de un sistema computacional? Revista Informtica, volu-
men 7, nmero 2, marzo de 1985.
Modelamiento de datos y funciones. Revista Ejecucin, ao 10, nmero 21, julio de
1990.
BRAVO, J. libros (Santiago de Chile, Editorial Evolucin S.A.):
Desarrollo de sistemas de informacin, una visin prctica (1988)
Reingeniera de Negocios (1995)
Planificacin Sistmica (1997)
Anlisis de Sistemas (1998)
Gestin de Procesos (2005)
Taylor Revisitado, la productividad es la clave (2005)
Gestin de Proyectos de Procesos y Tecnologa (2006)
Responsabilidad Social (2007)
BOOCH, G. (1991): Object Oriented Design with Applications. USA, Benjamin/Cummings.
Business Week (1991). Software made simple, will object-oriented programming transform
the computer industry?, septiembre 30.
CAMPERO, M. y ALARCN, L. (1999): Administracin de Proyectos Civiles, Santiago de
Chile, Pontificia Universidad Catlica.
CARROL, Daniel T. (1976): How the president satisfies his information systems require-
ments, USA, Society for management information system proceeding.
CERDA, G. (2002): Estamos diseando las interfaces de Software correctas?, Chile, Re-
vista Akdemeia, Universidad de Ciencias de la Informtica, diciembre de 2002, vo-
lumen 2, ao 2.
CERDA, G. y GUZMN, R. (2004): Algunas recomendaciones a aplicar en el diseo de
interfaces de software, Chile, Revista Akdemeia, Universidad de Ciencias de la In-
formtica, diciembre de 2004, volumen 4, nmero 2.
CHIAVENATO, I. (2000): lntroduccin a la teora general de la administracin, Quinta edi-
cin, Mxico, McGraw-Hill.
COLLADO, M. y GARCA, P. (1994): Programacin orientada al objeto en sistemas co-
merciales, Chile, Empresa Binaria S.A.
372 JUAN BRAVO C.
COMISIN PRESIDENCIAL (1999): Tecnologas de informacin y comunicacin. Chile:

Hacia la sociedad de la informacin. Presidencia de Chile.
COSTA Romero de Tejada, Manuel. (1984): Introduccin a la Ingeniera del Software.
Revista Mundo Electrnico, N 143, Espaa.
COVACEVICH, A. (1994): Gerencia versus sistemas de informacin, Santiago de Chile,
Ediciones Asterin Ltda.
DAHL, J., DIJKSTRA, E. y HOARE, C. (1980): Structured Programming. Academic Press
Inc. (London) LTD
DAVIDSON, J. (2001): La Gestin de Proyectos, Madrid, Pearson.
Diario El Mercurio (12 de febrero de 1995): Protenas que piensan. Santiago de Chile.
DRUCKER, P. (1993): Administracin y futuro, Buenos Aires, Sudamericana.
FAIRLEY, R. (1987): Ingeniera de Software. Mxico, McGraw-Hill.
FERNNDEZ S., Sergio M. (1995): Fundamentos del diseo y la programacin orientada a
objetos. McGraw-Hill, Madrid.
FRIEDMANN, R. (2007): Arte y gestin, una potica para el gerente del tercer milenio,
Chile, El periodista.
GATTELL, R. (1992): Object data management. Sun Microsystems, Inc. USA, Addison-
Wesley.
GETZ, I. y ROBINSON, A. (2005): Tus ideas lo cambian todo, Madrid, Alfaomega.
GILLENSON, M. (1987): Introduccin a las Bases de Datos. Mxico, McGraw-Hill.
GLADWELL, M. (2006): Inteligencia Intuitiva, Buenos Aires, Taurus.
GOLDIN, I. y REINERT, K. (2007): Globalizacin para el desarrollo, Bogot, Planeta.
GOLEMAN, D. (2006): Inteligencia social, Mxico, Planeta.
GRAHAM, I. (1992): Object oriented methods. Addison-Wesley Publishing Company,.
IBM de Chile S.A. (mayo de 1993): Humanizando la tecnologa, Revista Providencia 655.
INTERNATIONAL Data Corporation (1995): Latin America Research Prospectus, Region-
al Information Technology Studies, USA, 1995.
ISHIKAWA, K. (1986): Qu es el control total de calidad? La modalidad Japonesa, Co-
lombia, Editorial Norma.
JACKSON, M. (1979): Principies of program design. Quinta Edicin. Academic Press Inc.
(London) LTD.
JACOBSON, I., BOOCH, G. y RUMBAUGH, J. (2000): El proceso unificado de desarrollo
de software, Madrid, Pearson educacin, S.A.
JALOTE, P. (2000): CMM in practice, Processes for executing software projects at Infosys,
California, Addison Wesley.
KENDALL, K. y KENDALL, J. (2005): Anlisis y Diseo de Sistemas, Mxico, Pearson.
KHOSHAFIAN, S. y ABNOUS, R. (1990): Object orientation. Concepts, Languages, Data-
bases, User Interfases. New York, John Wiley & Sons, Inc.
KIM, W. y LOCHOVSKY, F. (1989): Object-oriented concepts, databases, and applications.
USA, Addison-Wesley Publishing Company, ACM PRESS.
KOTTER, J. (2004): Liderazgo, Coleccin HBR, Argentina, Deusto.
KOVACEVIC, A. y GONZLEZ, A. (1990): Sistemas de Informacin, conceptos e impli-
cancias para la empresa. Santiago de Chile, Universidad Catlica de Chile.
LAMB, D. (1988): Software Engineering: planning for change. USA, Prentice-Hall.
LARMAN, C. (1999): UML y Patrones, Mxico, Prentice Hall.
LARRAAGA, I. Mustrame tu Rostro. Coedicin CEFEPAL y Paulinas, Chile, 1979.
LEDGARD, H. y TAUER, J. (1987): Software Engineering Concepts. USA, Addison-

Wesley.
LIPSCHUTZ, S. (1987): Teora de Conjuntos y Temas afines, Serie Schaum, Mxico,
McGraw-Hill.
MARTIN, J. (1985): La sociedad telemtica, el desafo del maana. Buenos Aires, Editorial
Pairos.
MARTIN, J. y ODELL, J. (1994): Anlisis y diseo orientado a objetos. USA, Prentice-Hall.
McCONNELL, S. (1997): Desarrollo y gestin de proyectos informticos, Madrid, McGraw-
Hill.
MODELL, M. (1996): Systems Analysis, USA, McGraw-Hill.
OECD (2000): Information Technology Outlook 2000, Unin Europea.
PARIKH, G. y SVEGINTZOV, N. (1983): Tutorial on Software Maintenance, USA, Silver
Springs. IEEE Computer Society.
PETERS, T. (2004): Re-imagina, Madrid, Pearson.
PFLEEGER, S. (2002): Ingeniera de Software, teora y prctica, Buenos Airtes, Pearson.
PORTER, M. (1992): Ventaja competitiva, creacin y sostenimiento de un desempeo supe-
rior, Mxico, Continental.
PREECE, J. y otros autores. (1996): Human-Computer Interaction. USA, Addison-Wesley.
PRESSMAN, R. (1993): Ingeniera de Software, un enfoque prctico, 3 edicin, Espaa,
McGraw-Hill.
REVISTA AMRICA ECONOMA
Telecomunicaciones, abril/93.
Ms vale la respuesta rpida, septiembre/93.
Facturas digitales, septiembre/94.
El giro al servicio, septiembre/94.
El groupware que ya viene, septiembre/94.
Infogerencia y High Tech Chile, suplementos 2 semestre 1994.
El difcil mundo de ERP, marzo de 1996.
REVISTA COMPUTERWORLD, Santiago de Chile.
Reingeniera de negocios, el desafo de hoy para la empresa del futuro, marzo de 1993.
Archivos con rostros, un gran ejemplo de reingeniera de procesos, abril de 1993.
La realidad de la reingeniera, junio de 1993.
Reingeniera en las hipotecas, julio de 1995.
Objetos: La revolucin de los 90, agosto de 1995.
REVISTA INFORMTICA, Santiago de Chile.
Reutilizacin: El sueo de la Ingeniera de Software, enero de 1995.
REVISTA MICROBYTE, Santiago de Chile.
Bases de Datos de Objetos, una ventaja?, marzo de 1991.
Aprovechando el potencial de CASE, octubre de 1991.
EDI: negocios con rapidez electrnica, mayo de 1993.
REVISTA NEWS 3X/400, Espaa.
Doce pasos para disear Bases de Datos relacionales, julio de 1994.
ROCKART, J. (1979): Los altos directivos definen sus necesidades de informacin, Argen-
tina, Biblioteca Harvard de Administracin de Empresas.
ROCKART, J. y Bullen, C. (1981): A primer on critical sucess factors. Massachusetts Insti-
tute of Technology.
374 JUAN BRAVO C.
SEELY, J. y DUGUID, P. (2001): La vida social de la informacin, Buenos Aires, Prentice-

Hall.
SENGE, P. (1992): La Quinta Disciplina, Buenos Aires, Granica y Vergara.
SENN, J. (1987): Anlisis y diseo de sistemas de informacin, Mxico, McGraw-Hill.
SHLAER, S. and Mellor, S. (1988): Object-oriented systems Analysis, Modeling the world in
Data. USA, Yourdon Press computing series, Prentice Hall.
SHLAER, S. and M. (1992): Object Lifecycles, Modeling the world in states. USA, Yourdon
Press computing series, Prentice Hall.
SOLMINIHAC, H. (2005): La gestin de costos de proyectos, Clase ejecutiva de El Mercu-
rio, 13 de octubre, B11, Santiago de Chile.
SOMMERVILLE, I. (2005): Ingeniera del software, 7 ed., Mxico, Pearson (p. 6).
STEVENS, Perdita y POOLEY, Rob (2002): Utilizacin de UML en Ingeniera del software
con Objetos y Componentes, Madrid, Pearson Educacin.
SYSTEM ARCHITECT. (1992): Object-oriented Technology (incluye Mtodos de Grady
Booch y Coad/Yourdon), USA, Popkin Software & System Inc.
SWENSON, L. (1984): Teoras del aprendizaje, Buenos Aires, Paids.
TAYLOR, F. W. (1969, original de 1911): Principios de la administracin cientfica, Argen-
tina, El Ateneo.
TEASLEY, B. (1990): Software engineering with student project guidance, USA, Prentice
Hall.
TOLOZA, C. (2005): Cul es la rentabilidad de la informtica en su empresa?, Diario
Financiero, 18 de noviembre, Santiago de Chile.
VARELA, F. (1990): Conocer; las ciencias cognitivas: tendencias y perspectivas, Barcelona,
Editorial Gedisa.
VERITY, J. y SCHWARTZ, E. (1991): Software made simple, will object programming
transform the computer industry. septiembre 30, Bussiness week.
YOURDON, E. (1992 y 1994): Apuntes de los cursos anlisis y diseo orientado al objeto.
Chile, CIISA.
YOURDON, E. y COAD, P. (1991): Object-oriented Design. Yourdon Press Computing
Series, USA, Prentice Hall.
YOURDON, E. y COAD, P. (1991): Object-oriented Design. Yourdon Press Computing
YOURDON, E. y COAD, P. (1991): Object-oriented Analysis. Yourdon Press Computing
YOURDON, E. (1989): Managing the Structured Techniques, USA, Prentice Hall.
WEITZENFELD, Alfredo (2005): Ingeniera de software orientada a objetos con UML, Java
e Internet, Mxico, Thomson.
WILSON, P., Dell, L. y Anderson, G. (1999): Anlisis de la causa raz, una herramienta
para administracin de la calidad total, Mxico, Oxford University Press.
WIEDERHOLD, G. (1986): Diseo de Bases de Datos, Segunda edicin, Mxico, McGraw-
Hill.
WIRFS-BROCK, R., WILKERSON, B. y WIENER, L. (1990): Designing Object-Oriented
Software. New Jersey, Prentice Hall.
LIBROS DEL AUTOR PUBLICADOS POR EDITORIAL EVOLUCIN
GESTIN AVANZADA DE PROCESOS

Precio versin en papel: US$ 15, Chile $10.000
(2009, 190 Pgs., 21 x 14 cm.)
El objetivo del libro es aportar mtodos concretos para el rediseo y mejora de

procesos en la organizacin, como un medio para lograr la eficiencia y agregar
valor para el cliente en una relacin de confianza.
Surge de una profunda inquietud por el despilfarro de recursos en nuestra socie-
dad y, sobre todo, por la subutilizacin del enorme potencial de las personas.
La gestin de procesos es un deseo que se intuye como importante en las orga-
nizaciones. Sin embargo, es poco lo que logra realizarse porque no se sabe
cmo hacerlo, provocando grandes prdidas en las mismas organizaciones y en
la sociedad por proyectos mal planteados o fuera de costo y plazo, trmites que
demoran ms de la cuenta, mala atencin de clientes, productos defectuosos,
entregas con retraso, equivocaciones mdicas, errores, prdidas de clientes y
tanto ms
En el libro se ensea cmo incorporar a la organizacin un modelo integral para
la gestin de procesos.
Este libro complementa, aporta tcnicas y muestra aplicaciones de los conceptos
desarrollados en el libro Gestin de Procesos, el cual es prerrequisito para ste.
376 JUAN BRAVO C.
GESTIN DE PROCESOS
GESTIN DE PROCESOS
Precio versin en papel: US$ 24, Chile $16.000
(2006, 2 edicin, 400 Pgs., 24,5 x 17,2 cm.)
(1 edicin de 2005)
Es fcil aceptar la necesidad de cambio en nuestro mundo. Ms difcil es

cambiar nosotros mismos o que cambie nuestra organizacin, o la forma
cmo hacemos las cosas, a las cuales podramos llamar procesos.
La gestin de procesos nos insta a detenernos, reflexionar acerca de lo que
hacemos y preguntarnos: por qu?, para qu?, cmo?. Porque, si
profesionales capaces tienen ideas brillantes que permitirn ganar o ahorrar
mucho dinero, al mismo tiempo deberan inventar los nuevos empleos de las
personas que sern liberadas de funciones obsoletas. Lo pueden hacer, porque
son capaces. Lo deben hacer, por su condicin de seres humanos.
La gestin de procesos es un medio para lograr grandes metas
organizacionales, como la calidad, competitividad, productividad,
comunicacin y rentabilidad.
GESTIN DE PROYECTOS
Precio versin en papel: US$ 15, Chile $10.000 (2006, 260
Pgs., 21 x 14 cm.)
El objetivo de este libro es ofrecer un mtodo para la gesta-
cin, evaluacin, planificacin, direccin y buena ejecucin
de los proyectos, principalmente de procesos y tecnologa.
Es importante hacer bien los proyectos, porque a travs de
ellos se materializa el cambio propuesto por la estrategia de
la organizacin o por las oportunidades que el medio ofrece.
El mtodo tiene como base un amplio estudio de las mejores
prcticas de la gestin de los proyectos y del cambio en las personas. Las em-
presas pblicas y privadas de Chile pierden anualmente ms de 2.000 millones
de dlares debido a fallas evitables en proyectos de gestin. De una u otra
forma esa ineficiencia la pagamos todos y con creces, porque tampoco disfru-
tamos de los beneficios del proyecto si hubiese sido bien hecho.
MODELANDO UNA SOLUCIN DE SOFTWARE

Precio versin en papel: US$ 24, Chile $16.000 (2008,
392 Pgs., 24,5 x 17 cm.)
El objetivo de este libro es cooperar en aumentar la
productividad del desarrollo y la calidad de la solucin
de software mediante la excelencia de su modelacin.
Comenzamos por asegurarnos que la serie de modelos
(correspondientes a las etapas de anlisis y diseo)
efectivamente dan solucin a una necesidad bien com-
prendida y evaluada.
Modelar soluciones de software es una labor bella y
creativa que origina verdaderas obras de arte. Sin
perder la belleza y creatividad, ser posible profesio-
nalizar su elaboracin? S! Definitivamente el diseo de sistemas puede ser
arte y tecnologa a la vez.
378 JUAN BRAVO C.
EL ENCANTO DE LA COMUNICACIN
edicin 230 Pgs., 18,5 x 13 cm., 1 edicin de 1998).
Es un libro orientado a todas las personas que quieren co-
municarse mejor con quienes les rodean para incrementar la
calidad de su vida. El espritu de este libro es que nos sirva
de gua prctica en esta tarea de toda la vida destinada a
relacionarnos mejor y a transformarnos. Por qu? Porque la
comunicacin es cambio que podemos guiar hacia la supe-
racin personal.
Estamos vivos y lo ms caracterstico de la vida es la transformacin. Y por-

que el vnculo con nuestros seres queridos es lo nico que realmente cuenta,
adems la mejora en las comunicaciones en las empresas tiene un efecto in-
mediato en la vida familiar y social de sus trabajadores.
RESPONSABILIDAD SOCIAL (RS)
380 Pgs., 24,5 x 17,3 cm.)
En los pases de Latinoamrica podemos ganar miles de
millones de dlares al ao con la RS. Surgen de dejar de
perder evitando la Irresponsabilidad Social (accidentes,
delincuencia, corrupcin, mala educacin, etc.) y de ga-
nar fomentando la Responsabilidad Social (investiga-
cin, innovacin, emprendimiento, comunicacin, etc.).
Por eso la RS es la nueva causa de la riqueza de las
Naciones. Se puede lograr, tenemos ejemplos de buenos
diseos que han disminuido grandes males sociales en
un 80%. Es el caso, en Chile, de la disminucin de la tasa de accidentabilidad
de los trabajadores desde el 35% de los aos 60 al actual 7%. Por supuesto, el
nfasis ha estado en la prevencin.
HISTORIA DEL IST, 50 AOS

Precio versin en papel: US$ 24, Chile $16.000.
(2007, 164 Pgs., 25 x 25 cm.)
Cumplir 50 aos es un gran logro para toda or-
ganizacin y mucho ms para una que se dedica
a la seguridad social por el gran impacto que
tiene en la comunidad. La historia del IST es a
la vez parte de la historia de la seguridad del
trabajo en Chile, cuyos avances se pueden re-
sumir en una sola palabra que bien conocen en
el Instituto: prevencin.
Es un avance de Responsabilidad Social que se puede proyectar a otros mbi-
tos para contribuir al Bien Comn. Ya sabemos que una historia puede inspi-
rar a las personas para lograr fines superiores, al menos para encontrarle senti-
do a su quehacer y motivarse. Tambin permite aprender, porque de la lectura
se podr extraer una buena manera de gestionar una empresa, comenzando por
una gran dosis de visin.
EMPRESAS DE XITO
Pgs., 21 x 14 cm.)
Este es un libro acerca de las empresas de xito, aquellas

con una gestin que las lleva a diferenciarse. En un contex-
to de buenas prcticas de gestin la tesis es que las empre-
sas exitosas se distinguen por algunas pocas prcticas ex-
cepcionales.
As como existe la gestin por competencias dirigida a las
personas, tambin existe una gestin por competencias cor-
porativa.
Adems de hacer las cosas bien, las empresas exitosas se distinguen por un
pequeo nmero de prcticas que hacen muy bien, les hemos llamado siste-
ma de diferenciacin. Se presentan los ejemplos de IST, ENAMI Ventanas,
Termosistema e Integramdica.
380 JUAN BRAVO C.
GESTIN, EL CASO ENAMI VENTANAS

224 Pgs., 25,5 x 19,5 cm.)
Es importante destacar lo positivo de la gestin de las

empresas, as aprendemos de experiencias concretas. La
idea fue desafiante: compartir y aprender de la gestin
realizada en una unidad de negocios de una importante
organizacin. Se trata de la Fundicin y Refinera Ven-
tanas de la Empresa Nacional de Minera, ENAMI.
Tiene una cultura distintiva que se aprecia en la inge-
niera o innovacin permanente, en su contribucin al
bienestar del pas, en el sentido de honor, en la pasin por aprender, entre
otras.
Se identificaron varios factores relevantes, por ejemplo: liderazgo, producti-
vidad, entorno y personas
TAYLOR REVISITADO
Pgs., 21 x 14 cm.)
Pocas veces se ha visto una distancia tan grande entre la

excelencia de las contribuciones de un hombre y el pobre
sitial que le hemos asignado en la historia. A Frederick W.
Taylor los pases ricos le deban su condicin de tales, dice
Peter Drucker. Taylor sigue aportando a la creacin de
riqueza a travs de la mayor productividad. Fue precursor
del entrenamiento o capacitacin y de la gestin por competencias. Busc
evitar el derroche de materiales y se le reconoce como padre de la ingeniera
industrial y de la ergonoma. Busc que se compartieran los beneficios de la
mayor productividad, entre empresarios, trabajadores y la sociedad. Por qu
es tan actual su mensaje? Porque su mensaje de fondo est orientado a la su-
peracin de la pobreza y porque sus propuestas, debidamente actualizadas,
podran generar grandes beneficios en la economa de Latinoamrica.
A LA SALIDA DEL TNEL

Pgs., 23 x 16 cm.)
Es un libro creado con las entrevistas realizadas a los parti-
cipantes del programa de televisin del mismo nombre en
donde se extrajeron sus mejores ideas, propuestas y mensa-
jes. Fue un programa de UCV TV, conducido por el din-
mico y querido periodista Atilio Macchiavello.
Este documento recrea la vida de muchos visionarios y
podra ser la salida de su propio tnel. Es un Texto obliga-
do para profesores, estudiantes, profesionales y pblico en general. Una inspi-
racin para pequeos y grandes empresarios y orientacin vivencial para nues-
tras autoridades.
AMBROSOLI, DESDE LOS ALPES A LOS ANDES

133 Pgs., 26,5 x 18,5 cm.)
Coautor: Giancarlo Gandolini Ambrosoli.
Este libro es un reconocimiento a la labor de don Cons-
tantino Ambrosoli y a todos los emprendedores que ayu-
dan a crear un mundo ms humano. Es un ejemplo inspi-
rador que queremos compartir, porque excedi en mucho
nuestras expectativas.
Para qu sirve una historia? Para conocer, entender y
difundir la cultura de una organizacin, establecer un
vnculo entre sus integrantes, comunicar una causa comn, preservar las tradi-
ciones y seguir adelante unidos. Es un gran desarrollo, inseparablemente uni-
do a la historia de la familia Ambrosoli, as que para entender la evolucin de
este negocio, necesitamos conocer la rica tradicin acumulada en esta familia.
382 JUAN BRAVO C.
ANLISIS DE SISTEMAS
Precio versin en papel: US$ 24, Chile $16.000. (1998,
415 Pgs., 26,5 x 18,5 cm.).
Debemos descubrir los sistemas y aprender de ellos para

ayudar en el desarrollo de las organizaciones. La vieja
cosmovisin mecanicista, que considera el mundo estable
y predecible, abre paso a los sistemas: donde prevalecen
las interacciones, lo evolutivo, el caos, la complejidad y
sus compensadores, la humanidad, educacin, comunica-
cin, libertad, creatividad y otras respuestas. Si pretende-
mos ignorarla, dar rdenes o slo poner reglas, la complejidad se abrir paso
igual, como las aguas de un ro que se pretenden frenar con un prohibido el
paso.
Cmo hacer anlisis de sistemas? Con un enfoque al problema-solucin que
pasa por comprender la confusin.
Algunas herramientas sistmicas son: la teora del caos, la teora de la cats-
trofe, los crculos virtuosos, la orientacin al cliente, etc.
PLANIFICACIN SISTMICA
Pgs., 26,5 x 18,5 cm.).
Tradicionalmente, hemos hecho planificacin suponiendo
que las condiciones ambientales se mantendran ms o me-
nos constantes. Hoy nos damos cuenta que el entorno vara
con mucha rapidez! y que la velocidad del cambio sigue y
sigue aumentando. Para adaptarnos a esta realidad, la plani-
ficacin sistmica recurre a herramientas tales como: partici-
pacin, creatividad y manejo de la incertidumbre del medio.
La planificacin sistmica nos ayuda a cumplir los sueos, siguiendo un ca-
mino que comienza por determinar qu es lo que queremos, en nuestra empre-
sa o en nuestra vida. Luego, establecemos un sistema de diferenciacin y un
plan.
LA NUEVA VISIN, DISEO Y CONSTRUCCIN DE SISTEMAS COMPUTACIONALES

Precio versin en papel: US$ 24, Chile $16.000, (contenido
actualizado en libro Modelando una solucin de software)
(2 edicin 2007, 272 Pgs., 26,5 x 18,5 cm.) (1 edicin de
1996) Slo coleccin.
Este libro trata sobre el desarrollo de sistemas computacio-
nales, tales como inventarios, contabilidad, remuneraciones
o facturacin.
Se busca aumentar la productividad en ese mbito. En espe-
cial se estudia el diseo de sistemas computacionales, una labor bella y emi-
nentemente creativa que origina verdaderas obras de arte, a veces artesana-
les. Siempre conservando la creatividad, Ser posible que los mtodos de
trabajos y las herramientas sean de uso general? S! Definitivamente el dise-
o de sistemas dej de ser arte para transformarse en tecnologa.
Esta propuesta de la ingeniera de software tiene su base en tres slidos pila-
res: La planificacin estratgica en informtica, el diseo orientado al objeto
y las herramientas de productividad.
REINGENIERA DE NEGOCIOS
Pgs., 26,5 x 18,5 cm.)
La finalidad de la reingeniera es lograr grandes desafos, por
ejemplo: aumentar la productividad de las personas, las ven-
tas o la produccin, no en un 30%, sino en 400% y ms.
Cmo lograrlo? A travs de efectuar grandes cambios en los
procesos del negocio, potenciar a las personas, definir una
estructura organizacional flexible e incorporar tecnologa.
Todo en sintona con la cultura y estrategia de la organiza-
cin.
Para qu hacer reingeniera? Para cumplir con la misin de la organizacin,
tarea en la que deben estar empeadas todas las personas que ah laboran,
sirviendo los intereses de los clientes en armona con los valores de la empre-
sa y de la comunidad.
384 JUAN BRAVO C.
MODELAMIENTO DE SISTEMAS DE INFORMACIN

Precio versin en papel: US$ 24, Chile $16.000 (contenido
actualizado en libro Modelando una solucin de software)
(1994, 250 Pgs., 24,4 x 18,2 cm.). Slo coleccin.
Da una visin de conjunto sobre el desarrollo de sistemas de

informacin, comenzando por la planificacin estratgica
del negocio.
En el texto se incorporan los conceptos de evaluacin de
proyectos informticos, los lenguajes de cuarta generacin y la orientacin a
objetos. Especial relevancia tienen la Ingeniera de Software y las herramien-
tas de apoyo en cada etapa del desarrollo del sistema de informacin.
En las ltimas dcadas la computacin ha sido un agente de cambio al in-
terior de la organizacin, hoy las reas de informtica o de sistemas tambin
deben cambiar. Se trata de lograr el desarrollo de software de calidad,
econmico y en plazos convenidos.
DESARROLLO DE SISTEMAS DE INFORMACIN

edicin, 204 Pgs., 26,5 x 18,5 cm.) (1 edicin de 1987)
El objetivo de este libro es servir de gua prctica en el
desarrollo y en la mantencin de sistemas de informacin
orientados a empresas. Est especialmente dirigido a todos
quienes laboran en el rea de informtica, y que podran
hacer uso de las materias prcticas, que buscan mejorar el
rendimiento, mediante la aplicacin de pautas simples y
lgicas, donde el criterio predomina sobre la reglamenta-
cin.
Tambin se orienta a estudiantes de carreras del rea computacin e inform-
tica, quienes podrn ver facilitado su aprendizaje al enfrentarse con metodo-
logas y ejemplos concretos, sobre la base de una visin de conjunto del desa-
rrollo de sistemas de informacin.
El libro ha sido de gran ayuda para acadmicos de las reas mencionadas.
ACERCA DEL AUTOR:
Juan Bravo Carrasco

Doctor por la Universidad de Lleida (Espaa). Master en Direccin de In-
formtica (Ide Cesem, Espaa) e Ingeniero de Ejecucin en Sistemas de In-
formacin (USM, Chile).
Es Presidente de Evolucin, Centro de Estudios Avanzados y editor de la Re-
vista Responsabilidad Social.
Con ms de 30 aos de experiencia como ejecutivo, consultor y relator de
seminarios, el Dr. Bravo ha ayudado a clientes tales como: Mutual de Seguri-
dad, ENAMI, BancoEstado, Rolec, Transbank, Isapre Colmena, Municipali-
dad de Quillota, Banco Ita, Empresa Portuaria de Valparaso, Constructora
TECSA y Termosistema.
El Dr. Bravo es profesor de programas de postgrado en la Pontificia Universi-
dad Catlica, Universidad Tcnica Federico Santa Mara (Chile y Ecuador),
Universidad de Chile y otras destacadas instituciones.
Public los 18 libros indicados.
LA SERIE DE LIBROS
A mayo de 2009 todos los libros estn disponibles en papel.
Su disponibilidad en digital y actualizacin se explica a continuacin.
Libros en digital y actualizados

Estos seis textos estn disponibles y actualizados en digital. Son los libros
ms relacionados con el hacer actual de consultora:
1. Gestin Avanzada de Procesos
2. Gestin de Procesos
3. Gestin de Proyectos
4. Modelando una Solucin de Software
5. El Encanto de la Comunicacin
386 JUAN BRAVO C.
6. Responsabilidad Social
Los siguientes doce libros no tienen actualizacin:
Seis son histricos (A la salida del Tnel, Ambrosoli, Enami, Taylor, IST y
Empresas de xito).
Otros seis (Desarrollo, Modelamiento, Reingeniera, Diseo, Planificacin y
Anlisis) perdieron tanta vigencia que no basta con la actualizacin para su
permanencia. En este caso aplica el rediseo, en la forma de nuevos textos que
heredan contenidos reciclados posibles de rescatar de los antiguos. Por ejem-
plo, el libro Modelando una Solucin de Software hered algunos contenidos de
los textos Modelamiento y Diseo.
Libros en digital sin actualizacin

Estos siete libros estn disponibles en digital en su versin original del ao
que se indica:
1. Reingeniera de Negocios(1995)
2. Diseo de sistemas computacionales (1996)
3. Planificacin Sistmica (1997)
4. Anlisis de Sistemas (1998)
5. A la Salida del Tnel (2000)
6. Taylor Revisitado (2005)
7. Empresas de xito (2005)
Libros slo en papel sin actualizacin

Estos cinco libros estn disponibles slo en papel desde las fechas que se in-
dican:
1. Desarrollo de sistemas de informacin, (1996, tercera edicin, primera
versin de 1987)
2. Modelamiento de sistemas de informacin (1994)
3. Ambrosoli, desde Los Alpes a Los Andes (1998)
4. Gestin, el caso Enami Ventanas (2005)
5. Instituto de Seguridad del Trabajo, historia (2007)
INFORMACIN GENERAL
Cada texto puede ser adquirido en la forma de una versin corporativa en pa-
pel o digital.
Editorial Evolucin S.A.: Av. Libertador Bernardo OHiggins N171, of 307,
Santiago, fono: 6389717 www.evolucion.cl, info@evolucion.cl.

Modelando Una Solución de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelando Una Solución de Software

Cargado por

Copyright:

Formatos disponibles

2 JUAN BRAVO C.

Juan Bravo Carrasco

JUAN BRAVO CARRASCO, 2008

Valor versin digital: $ 5.000 (Chile) US$ 7 (sin costo en 2009)

EDITORIAL EVOLUCIN S.A.

A todos los profesionales de la tecnologa que se esfuerzan cada da por

10. Herramientas de apoyo .............................................................................................. 90

5. Pruebas del software por el programador................................................................. 141

3.4. MODELAMIENTO DE FUNCIONES ..................................................................................... 193

5. Identidad de instancias de objetos ............................................................................. 265

Figura 1-1. Totalidad del mtodo GSP 45

Figura 4-4. Eliminacin de grupo repetitivo usando campo interno 239

La presin irrazonable en la planificacin puede hacer que los

derico Santa Mara, adems de talleres en muchas empresas desde hace ya

Lectores del libro

Desarrollo de sistemas de informacin, una visin prctica (1988)

Prlogo de Gerentes de reas de sistemas

Limbi Ortiz Neira5

torno rico en posibilidades, en el cual necesariamente debemos considerar la

cual se implementa y esta reduccin debe pagar la inversin comprometida

El liderazgo complementa a la gestin, no la sustituye.

Mi especial reconocimiento a quienes tuvieron la gentileza de revisar borrado-

En cuanto al mbito acadmico, destacar actividades abiertas de capacitacin,

El hecho de adoptar una perspectiva de sistemas da a los

Realidad deseada Modelos

Shari Pfleeger explica en su libro Ingeniera de software (2002, p. 226): Se

Siempre es necesario modelar la solucin antes de implementar?

Contenido del libro

CAPTULO 5. ORIENTACIN A OBJETOS

CAPTULO 4. MODELAMIENTO DE DATOS

CAPTULO 3. TEORA DE MODELOS

CAPTULO 2. INGENIERA DE SOFTWARE

CAPTULO 1. MTODO PARA LA GESTIN DE PROYECTOS

Competencias necesarias para modelar aplicaciones computacionales

Sntesis de modelos de una solucin de software

Mapas para la visin de conjunto

procesos Evaluar Formar

Proceso del Negocio Comercializar

Conocer Planear Preparar Atencin

Visitar Emitir Medicin

Estadsticas Emitir O/C Almacenar

= Experiencias para evitar

Mapa de retroalimentacin Mapa de sistemas computacionales

Modelos de la etapa de anlisis

Luego se comienza a trabajar en la pata de los procesos: levantamiento deta-

Vender Despachar Cuadrar Reservar y

Mapa de procesos GD1 CUADRAR

OE: Orden de Entrega, GD: Gua de Despacho

Proveedores Orden de compra y Peticiones

Modelo orientado al objetivo

Modelo orientado al flujo de

Diseo general de la interfaz Diagrama de casos de uso

Terminal en bodega Terminal del Administrativo de Adquisiciones

Caso de uso de alto nivel Caso de uso de expandido

Modelo conceptual de datos Modelo conceptual con atributos

Modelo funcional generalizado

Interfaz visual detallada

Modelos de la etapa de diseo

Encabezado Personas Ingreso de transaccin

Cuadrar totales para referencia.

Visin interna de la clase ingreso de

Administrativo Sistema Contrato

Diagrama de secuencia Contrato

Los dos modelos ms caractersticos del diseo desde el punto de vista de