Modelando 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 durante 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
Modelando una Solucin de Software
Juan Bravo Carrasco
4 JUAN BRAVO CARRASCO, 2008
JUAN BRAVO C.
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 Revista 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.
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
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
11
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
13
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 organizaciones 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 tambin como una forma de crear riqueza en toda la sociedad a travs de la transferencia de conocimiento. En su reconocido1 libro Globalizacin para el desarrollo, 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. Durante dcadas, el abismo en aparente crecimiento entre los pases desarrollados y los pases en desarrollo ha despertado inquietudes acerca de una brecha tecnolgica. 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 adelantos, 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 subdesarrollo, ya sea aplicar calidad, aprender a modelar un software o trabajar con mtodo. 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-
Entre otras personalidades, el libro es presentado por los Premios Nobel de Economa Joseph Stiglitz y Amartya Sen.
15
derico Santa Mara, adems de talleres en muchas empresas desde hace ya dos dcadas. En mi experiencia como desarrollador de varios cientos de sistemas computacionales 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 Desarrollo 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, como 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 informacin. 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 estudiantes 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 bsica 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:
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 software 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 sistemas computacionales no constituye ninguna ventaja sobre la competencia,
3
Gerente de Sistemas en Empresas Hites S. A.
17
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 empresas 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 moderno, 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 software por una fraccin del ingreso medio de un pas medianamente desarrollado. Entonces, cmo competir en este mundo ms bien adverso? Pues actualizndose 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 esfuerza 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 sobrevivir. 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 anteriores libros y, sobre todo, de su cario por la Ingeniera de Software; especialidad 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 necesidad y prisa de trabajar conforme a los postulados de la Ingeniera de Software, 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 estudio 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 escribiera 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 respond 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 en4 5
Gerente de Desarrollo en BancoEstado. Directora de Sistemas en la Municipalidad de Melipilla.
19
torno rico en posibilidades, en el cual necesariamente debemos considerar la mesa6, es decir, el modelo de negocios en el cual estamos trabajando, considerar 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 necesarias 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 aprendiendo. 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 diseo 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 resultado ha sido excelente. Asimismo, agradecerle su confianza en m, y haberme permitido dar mi opinin.
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 especfico 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 informtico que frente a la construccin de una catedral. El pecado original en informtica es comenzar a desarrollar sin tener los planos, ac es lo mismo, no podemos comenzar a construir el sacro edificio si no tengo planos arquitectnicos 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 inicios, 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 duplicar 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
Gerente de Informtica del Grupo Constructor Besalco.
21
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 borradores de este texto y compartir tanto de su sabidura: Limbi Ortiz Neira, Gloria Arellano Mundaca, Mauricio Arancibia Pino, Gerardo Cerda Neumann, Christian 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 Bustos 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 Toloza 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 Sistemas Computacionales (1996), as es que reitero en ste los agradecimientos a quienes aportaron de una u otro forma en aquellos (revisiones, ideas, motivacin): Rolf Achterberg Neman, Giancarlo Gandolini Ambrosoli, Ricardo Baeza Yates, Eugenio Daz Gonzlez, Santiago Macas Huenchullan, Francisco Mndez Sanhueza, Jos Labra Molina, Jeannette Caballero Pinilla, Alexis Cifuentes Barra, Luis Mndez Reyes, David Medina Avils, Jos Leiva Olmedo, 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 organizaciones 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.
23
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 gestin 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 divulgacin 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 estmulo 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 importancia 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 forma 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 modelamiento 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
Necesidad
Realidad deseada (difusa)
Modelos de la solucin
25
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 instrucciones 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 dlares ya hace necesario un modelar formalmente. La idea es superar la construccin artesanal de software (por ejemplo, construir sin planos) y aplicar los nuevos conocimientos sobre teora de modelos, normalizacin (tal como orientacin 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 necesarias para modelar aplicaciones computacionales (o soluciones de software), en este texto se presentan en la forma de captulos: 1. Un mtodo completo para la gestin de proyectos y as situar el modelamiento de soluciones de software en su contexto. 2. La profesionalizacin de conocimientos que aporta la ingeniera de software 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 modelamiento 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 correspondiente, 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
En el captulo 1 veremos el mtodo completo.
27
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 necesidades, proyectos, procesos, retroalimentacin y sistemas.
Bienestar Productividad Calidad Costo Responsabilidad Social
2p
Soluciones propuestas: 1. Alinear con la estrategia 2. Incluir como plan de accin de RS
Mapa de proyectos
10p
Tiempo
Problemas detectados: 1. Pago tardo a Proveedores 2. Trabajadores fuman en sector atencin clientes
1p
= Libera = Neutro = Requiere
7p
Mapa de necesidades
Procesos Estratgicos
Gestin de Personas Gestin de Procesos Gestin de Proyectos Gestin de Calidad Control de Gestin Gestin de Contratos
Analizar cargos Reclutar Inducir
Mapa de procesos
Desarrollo
Planificacin Estratgica
RS
Evaluar
Formar
Disear carrera
Proceso del Negocio Comercializar

Proyectar ventas Conocer la demanda Visitar Clientes Estadsticas internas Emitir O/C Almacenar Traspasar Comprar Recibir Distribuir Planear cada local Emitir traspaso Ordenar Preparar cada local Presentar Coordinar merchand. Vender al detalle Vender Postventa Atencin al cliente Medicin y seguimiento Servicio de garanta
Cotizar
Recepcionar
Despachar
Cuadrar
Procesos de Apoyo
Adquisiciones Servicios Bsicos Finanzas Contabilidad Legal Transporte Remuneraciones y bienestar Tecnologa y Mantencin
Meditacin
Cobranzas
Buen trabajo en equipo
Devolucin
Liderazgo sistmico
Ventas
Alcance poco claro Retroalimentacin de eventos destacados Demora en entrega final

Dificultades para coordinar entrevistas con usuarios
Facturacin Compras Bodega Entrega
= Experiencias para evitar = Experiencias para replicar
Recepcin
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 Anlisis
Cmo 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.
29
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 solucin, 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, incluye responsabilidad social) y las 4 patas son: personas (incluyendo ambiente), 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 Procesos Tecnologa Estructura
Luego se comienza a trabajar en la pata de los procesos: levantamiento detallado y propuestas de cambio. Se emplean principalmente los modelos mapa de procesos y flujograma de informacin, los cuales se observan en la siguiente figura (detalle en los captulos 1 y 3 respectivamente).
Vender al detalle
PROCESO DESPACHO INMEDIATO

CLIENTE OE BODEGA ADMINISTRATIVO DE BODEGA FINANZAS DESPACHADOR
Vender
Despachar
Cuadrar
PROCESOS VENDER
Reservar y emitir GD
GD4
GD3 GD2 GD1
GDs
Buscar producto
Al Contado A Crdito
Inmediato A domicilio
GD4 OE
Rebajar saldo
Cliente recibe y firma recepcin
Programar
Entregar
GD2 GD1 GD3
PROCESO CUADRAR
Mapa de procesos
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).
Clientes
Pedidos y devoluciones Costos
Gerencia
Niveles
Compras Devoluciones Entradas Traspasos
Ventas
Artculos y factura Artculos y gua
Control del stock
Salidas
Devoluciones Traspasos
Control de stock
Despacho de artculos Peticiones
Proveedores
Orden de compra y devoluciones
Sala de ventas
Diagrama de contexto
Maestros
Modelo orientado al objetivo principal del sistema

Clientes Artculos Proveedores
Transacciones
Proveedores
Cuentas Contables
Historial Ventas
Historial Compras
Ventas Compras
Devolucin ventas
X X
Compras
Clientes
X X X
X X X
X X X
Artculos
Ventas
Modelo orientado a los datos

Cotizador
Modelo orientado al flujo de transacciones

Terminales del rea de Adquisiciones Cotizar Aprobar cotizacin Ingresar O/C Aprobar O/C Enviar O/C O/C = Orden de Compra Jefe de Adquisiciones
Administrativo de Adquisiciones
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 recomendacin es trabajar con estos nuevos modelos (detalle en los captulos 5 y 6).
31
Terminal en bodega
Terminal del Administrativo de Adquisiciones Administrativo de Adquisiciones Ingresar O/C
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
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
Caso de uso de alto nivel

Encabezado de O/C compuesta por se asocia a 1 1..* contiene * existe en 1 existe en * almacena 1 Bodega Productos contiene * existe en 1 Proveedores
Caso de uso de expandido

Encabezado de O/C N O/C Fecha compuesta por contiene existe en * 1 Proveedores Rut Nombre
Lneas de la O/C
Lneas de la O/C Unidades Precio
contiene existe en * 1
Productos ...
existe en * almacena 1 Bodega ...
Modelo conceptual de datos
Modelo conceptual con atributos
Interfaz de Entrada
Gua Interna de Recepcin por Compra
Cdigo Enc. Recepcin RUT Proveedor Direccin Proveedor Comuna
C
-
Encargado Recepcin Razn Social Proveedor
D F
N Gua Recepcin Fecha Recepcin

e-Mail
Encabezado de transaccin
C/E Mensaje 1
Ingresar transaccin
Personas
E I
G
Ciudad M
H
Fax
Fono
K N
Precio
L O
Valor Neto
Gua de Despacho de Proveedor N
Fecha G/ D. Proveedor
N de O/C.
Detalle de transaccin
C/E Mensajes 4 y 5
Productos
L.
Cdigo
Descripcin
Cantidad
LL
Modelo funcional generalizado

Cerrada Anulada
W Y
Cerrar X Anular Z
XX
Salir
V
Grabar Total acumulado
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 sucesivos y la tcnica de desarrollo en espiral (ver anexo 3) se avanza en el diseo, 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 de transaccin N documento Fecha Rut persona 1 Agregar 2 Consultar 3 Imprimir
C/E Mensaje 1
Personas Ingreso de transaccin Encabezado, detalle y totales segn formato 1 Aceptar datos 2 Cuadrar totales
C/E
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
Rut Nombre Direccin Telfono 1 Agregar 2 Consultar 3 Imprimir
Detalle de transaccin N documento Cdigo artculo Costo Cantidad 1 Clculo total
Productos
C/E Mensajes 4 y 5
Cdigo artculo Tipo artculo Descripcin ltimo costo Saldo 1 Agregar 2 Consultar 3 Imprimir 4 Sumar saldo 5 Restar saldo
Objeto Ingreso de ventas Ingreso de compras
Tabla de objetos, clase Ingreso de transaccin Atributos Funciones Indicar stock del producto Deben cuadrar totales, stock mayor a unidades por vender. Mensaje 5 Crear proveedor y artculo si no existen. Mensaje 4
Modelo funcional generalizado y detallado

Administrativo Sistema
Visin interna de la clase ingreso de transaccin con la tabla de objetos

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.
Ingresar N de O/C Ingresar cdigo de prod. Repetir hasta que no haya ms productos Ingresar cantidad Dar OK a la lnea
Diagrama de secuencia
Contrato
33
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 N O/C Fecha Crear lnea Imprimir compuesta por 1 contiene * existe en 1 Rut Nombre Crear proveed. Modificar Rut Modificar nombre
se asocia a
1..* contiene * existe en 1 existe en almacena

*
Lneas de la O/C Unidades Precio Agregar lnea
Productos ...
1 Bodega ...
Diagrama de diseo de clases

Operacin: Dar OK al Ingreso de la lnea de O/C Ingresar producto (cd, cant, pre) Terminal del administrativo 1: Crear lnea de O/C (cod, cant, pre) Encabezado 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 sistema 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 figura (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 horizontal, 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
35
anlisis y diseo. La visin global, sistmica, que ofrece un mtodo es indispensable para entender 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 profesional 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 continua. Tanto las etapas como las fases se pueden traslapar en los lmites. Tambin existen prcticas transversales a las etapas, es decir, aplican en algunas o en todas las etapas del mtodo. Son 28: direccin del proyecto, plan de la etapa, exposicin de los planes, retroalimentacin, equipo de trabajo, entrevistas, comunicacin, informes, tcnicas, herramientas de apoyo, trazabilidad, Quick wins, costos y duracin, gestin de riesgos, gestin de la calidad, responsabilidad social, insercin, orientacin al cliente, sensibilizacin, capacitacin, 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
Por habilidad organizacional entendemos una competencia que adquiere la empresa mediante 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 catedrales, 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 iniciados 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 alcance 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 objetivo 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 planifique, organice, dirija, controle y coordine. Todas esas acciones configuran la gestin del proyecto, que generalmente ser ms compleja mientras ms recursos 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.
37
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 pueden 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 realizado 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% termin 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 lenguajes, normas de calidad y herramientas que el mercado ofrece, aprendiendo de tales opciones e incorporando las mejores prcticas para aplicar en las organizaciones de Latinoamrica, donde podemos profundizar en trabajar con calidad 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 significativas y duraderas. A menudo la palanca sigue el principio de la economa de medios, buscando el lugar donde los mejores resultados no provienen de esfuerzos en gran escala sino de actos pequeos y bien focalizados. El pensamiento 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, buscando especializacin. Tambin nos ayuda a pensar en integralidades, en volver a unir las partes de los rompecabezas que hemos creado. Este nuevo paradigma tiene su propio campo de conocimientos y se nutre desde otras disciplinas: 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 cooperacin 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 responsabilidad con el bien comn. Qu es un sistema? No existe una definicin generalmente aceptada para un sistema. Tradicionalmente 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.
39
Dice Idalberto Chiavenato (2000, p. 769): El concepto sistema pas a dominar 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 nervioso, 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 utilizndolo 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 desarrollo completo de un proyecto, pasando por todas las etapas de su ciclo de vida: concepcin, factibilidad, anlisis, diseo, implementacin, despliegue y operacin. 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 innovacin en la organizacin que contempla las definiciones estratgicas, formacin de las personas, mtodo, creacin de estructura organizacional y apoyo tecnolgico (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, justificacin 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 necesidades del cliente, as como lo que se espera hacer para satisfacerlas. El cliente puede remitirse al plan para tener informacin sobre las actividades del proceso de desarrollo, siendo fcil seguir el avance del proyecto durante el desarrollo 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 (CFADIDO)
Concepcin 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
41
1.2. CLAVES DE LA IMPLANTACIN DE MTODO

Son claves que guan el trabajo en la implantacin de mtodo. Previo, es necesario 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, tampoco 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 estar 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, aunque 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 causas y soluciones. En la figura 1-2 se muestra, como ejemplo, dos estudios para responsabilidad social.
Bienestar Productividad Calidad Costo Responsabilidad Social Tiempo
Soluciones propuestas: 1. Alinear con la estrategia 2. Incluir como plan de accin de RS
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 organizacin como un todo sea ms inteligente.
43
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 establecer un sistema de vasos comunicantes entre proyectos, uno que libera personas y otras que las requieren11.
10p
2p
1p
= Libera = Neutro = Requiere
7p
Figura 1-3. Mapa de proyectos con relaciones para reubicar personas
Un mapa de proyectos tiene mltiples aplicaciones, por ejemplo, desde el punto de vista de responsabilidad social, ayuda a evitar despedir personas que quedan liberadas de procesos obsoletos, ellos pueden aportar en otros proyectos. Lo mismo es vlido para los recursos de la empresa: espacio fsico, equipamiento, etc
Hemos visto que ms o menos un tercio de los proyectos libera personas y recursos, el otro tercio requiere y el ltimo es neutro.
11
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
Desarrollo Planificacin Estratgica RS Gestin de Procesos Gestin de Proyectos Gestin de Calidad Control de Gestin Gestin de Contratos Gestin de Personas
Ana lizar cargos Recluta r Inducir
Evaluar
Formar
Disear ca rrera
Proceso del Negocio Comercializar

Proyectar ventas Conocer la demanda Visitar Clientes Estadsticas internas Emitir O/C Almacenar Traspasar Comprar Recibir Distribuir Planear cada local Emitir traspaso Ordenar Preparar cada local Presentar Coordinar merchand. Vender al detalle Vender Postventa Atencin al cliente Medicin y seguimiento Servicio de garanta
Cotizar
Recepcionar
Despachar
Cuadrar
Procesos de Apoyo
Adquisiciones Servicios Bsicos Finanzas Contabilidad Legal Transporte Remuneraciones y bienestar Tecnologa y 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 porque 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.
45
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 mapa mental. Ntese que se evit la distincin positiva o negativa de experiencias 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 eventos destacados Demora 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 puede 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 principales entre ellas. En la figura 1-6 se consideraron algunos sistemas tradicionales. 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 organizacin, este mapa de sistemas computacionales es vital para modelar la solucin 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 conceptos (UML, SOA y otros que veremos en los captulos de este libro).
47
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 conciencia. 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 respecto 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 orientacin es simplicidad, flexibilidad y aplicabilidad, para que realmente sea utilizado 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 ejemplo, 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 proyecto, especialistas en procesos y tecnologa, adems de consultores. La alta direccin, gerencia u otra autoridad se encarga de la toma de decisiones 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. Debemos asegurarnos que lo nuevo es efectivamente mejor, sin el encandilamiento transitorio que tanto dao provoca.
49
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), actualizacin permanente, flexibilidad para abordar todo tipo de proyectos y negociacin 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 complejidad 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 representar 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 paperless (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 mismo 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, menos. 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 abandona 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 definiciones, 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, debemos actuar con pragmatismo y adaptar el mtodo segn el tipo de proyecto. Es lo que veremos a continuacin.
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.
13
51
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 complemento, como en el yin y yang (la armona de los opuestos, el justo medio que proclama 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 transversales. Es lo que explica Alfredo Weitzenfeld en su libro acerca de ingeniera de software (2005, p. 35): Una creencia comn, aunque equivocada, es la existencia de un solo modelo de proceso aplicable a cualquier proyecto, pues el modelo de proceso depende del tipo particular de proyecto, por ejemplo: primer proyecto de su tipo, segundo proyecto de su tipo, variacin de un proyecto, reescritura de software existente, creacin de software reutilizable y proyecto 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 necesidades 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 tamao determina nuevas formas de hacer las cosas.
53
3. Estructura para la gestin de proyectos

La buena gestin de proyectos tambin tiene que ver con una serie de instancias 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 adecuada: 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 incorpora 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 soluciones. 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 aseguramiento 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 compromisos vigentes e histricos, as como definir la forma de toma de decisiones 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.
55
cmo se comportaron el plazo, costo y otras variables respecto al plan. El informe lleva la firma de todos los actores relevantes. Esto es independiente de los entregables por cada etapa cuya aprobacin depende 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 clase 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 recopilacin 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 conocimiento: 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 ejemplo, 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, requeridas para brindar confianza en que el proyecto va a satisfacer los estndares de calidad relevantes. El Control de Calidad implica verificar los resultados especficos del proyecto para determinar si estos cumplen con los estndares de calidad relevantes e identificar maneras de eliminar las causas de los resultados insatisfactorios. 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-
57
nas de estas son: confidencialidad, no falsificar su nivel de competencia, derechos 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 profesionales 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 computacional 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 cubrir 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 objetivos, resultados y propsito alineado. Ms all de los entregables por etapa, es vital definir y conocer lo que se quiere 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 sentido 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 proyecto. 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
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 entregable es un plan de proyecto, adems de los informes para trazabilidad. Incluye las etapas de concepcin y factibilidad. Desarrollo: donde el plan se materializa. El entregable es la solucin completa y en explotacin. Incluye las etapas de anlisis, diseo, implementacin y despliegue. Mejora continua: donde la solucin ya en operacin se mantiene y perfecciona. Contiene solamente la etapa de operacin, la ms extensa y que existe mientras dura la vida til de la solucin, lo cual tambin debera estar estimado 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.
59
Qu tienen en comn la construccin de un edificio, el desarrollo de un sistema computacional, la creacin de un nuevo producto o el rediseo de la estructura 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 edificio, tanto de la obra gruesa como de todos sus componentes (ascensores, conductos elctricos, etc.) similar a los cmo que detalla la etapa de diseo 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 proyecto. 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 mayores 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 evidente, 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 entregables de las etapas anteriores, porque es necesario conservar la trazabilidad del proyecto y es seguro que ser necesario realizar cambios en modelos 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 problema 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.
61
Yendo a los fundamentos conceptuales, la visin sistmica tiene especial predileccin por invertir tiempo en la adecuada definicin de los problemas, antes 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 obligatoriedad 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 necesidades 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 necesidades 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 principalmente dos caminos: a) Solicita un estudio ms detallado de la necesidad. b) Solicita el cierre de la etapa de concepcin con el entregable que corresponda.
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 obligatoriedad 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 alcances 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 directivos 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 siguiente despus de la toma de decisin por parte de la autoridad correspondiente. Suponemos un Comit de Proyectos (CP) en lo que sigue. La toma de decisin sera despus de realizar cada una de estas acciones:
En el libro Anlisis de Sistemas se trata extensamente acerca del nfasis en el problema. 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.
22 21
63
a) Una investigacin creativa de muchas soluciones y propuesta de alternativas 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 descripcin, 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 principio 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 sombreros 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 diversidad de conocimientos suficientes en una multitud de campos, y no el conocimiento 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 opciones, logstica, un sistema de gestin de iniciativas y muchas otras. Getz y Robinson agregan (2005, p. 53): Un sistema de gestin de ideas transforma el potencial creativo en accin creativa y despierta esa fuerza formidable 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 proyectos: incorporacin del cliente y de los proveedores, costos, plazos, comunicacin, riesgos, completitud, son 28 en total.
23 24
Detalladas en el libro Gestin de Procesos. En el libro Responsabilidad Social se profundiza en este tipo de anlisis.
65
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 requerimientos 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 solucin. 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 organizacin, tal como se muestra en la figura 1-9.
Estrategia Personas Procesos Tecnologa 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 destinado 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 integralidad 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: sensibilizacin, capacitacin, empoderamiento, participacin, anticipacin, ambiente 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 interaccin. 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:
67
La cultura de la organizacin (lo que no se ve): formas de relacin, comunicacin, tradiciones, creencias y mucho ms, en directa relacin con la estrategia (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 relacionados, 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 flujograma 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 mapa de procesos global (ver figura 1-4).
Vender al detalle
Vender
Despachar
Cuadrar
Al Contado A Crdito
Inmediato 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, Inmediato, 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 informacin 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 operativos, 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.
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).
25
69
PROCESO VENDER A CRDITO

CLIENTE REA DE VENTAS VENDEDOR CAJERO BODEGA
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 flujogramas de informacin podra ser parte de cada iteracin. El mapa de procesos debera estar construido desde el principio y solamente se realizaran perfeccionamientos en cada vuelta de la espiral. Se debe realizar el diseo de formularios asociados al detalle de los flujogramas 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 externalizacin, 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, asimismo 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 tecnologas consideradas en el proyecto: comunicacin, transporte, movimiento automatizado de carga, despacho, almacenamiento, construccin, automatizacin 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 planteados 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.
71
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 negocios, especialmente personas, procesos, estructura organizacional y tecnologa. 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 forma 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, estructura organizacional y tecnologa. Ntese que se trabaja con y no se entrega o delega el trabajo a especialistas, 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 dedicados 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, esencialmente 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
73
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 implementar 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 computacional, una poltica acerca de las personas o el diseo de una estructura organizacional. Implementar tambin implica retroalimentar el diseo sobre aspectos no contemplados 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, cambiaron las condiciones previstas en el diseo o la aplicacin es difcil de usar. En fin, por muchos motivos la implementacin puede fracasar. Cmo mitigar estos 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 equipamiento 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 cuando 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 prometido 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 proyectos, 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 adaptacin a las contingencias del mundo.
75
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 infraestructura, 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 rediseo 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 rpida 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, aquella 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 mantener 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 28
El libro Anlisis de Sistemas aborda el tema de la complejidad de los sistemas. 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 alguna 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 prototipo es para que el usuario vea un boceto de lo que quiere o para probar aspectos 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 modificar 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 correspondiente 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 capacitacin 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 especficos en que trabaja la persona.
77
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 ingresar 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 usuario 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 tendencias en un sistema computacional. Para realizar el despliegue debemos recurrir a muchas instancias de comunicacin 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 conectan libremente y existen niveles de evaluacin. Hay amplias experiencias positivas con el uso de esta tcnica para la preparacin de cajeros y de muchos 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 utilizada 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.
79
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 adicionales 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 menores 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 cuanto 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 REA DESARROLLO DEPARTAMENTO DE INFORMTICA JEFE INFORMTICA ANALISTA SUBCOMIT CAMBIOS
SC
Asignar Analista Estudiar impacto Casos de uso Emitir informe

II
Abreviaturas: SC: Solicitud de Cambio II: Informe de Impacto PD: Plan de Desarrollo
Plan de Desarrollo
II
PD
PD
SC II
PROCESO IMPLEMENTAR
PD
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
81
Entrega informe al subcomit de informtica (encargado de los requerimientos 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 alguna 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 despliegue, 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 virtualmente, 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 incorporadas 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, comenzando 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 acotado 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 desarrollo 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 general. Por ejemplo, la prctica definir herramientas para la etapa estar definida 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.
83
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 cambio se realice o no. Podra llegar a ser el 20% del presupuesto para los cambios? Puede ser, depende 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 particular el ahorro que se puede generar (recordar multiplicar por un factor tambin 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
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.
32
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 necesarias para cumplir con lo prometido, particularmente en calidad, eficiencia, eficacia, satisfaccin del cliente, plazos y costos. Contempla motivar, comunicar, 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.
85
Comunicar el proyecto con frecuencia dentro y fuera de la empresa, integrando 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, involucrndolos en la fijacin de metas. El simple acto de fijar una meta desafiante pero alcanzable y de medir peridicamente el desempeo contra la meta establecida 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, podemos citar a Daniel Goleman, uno de los mejores expertos en relaciones humanas, quien, en su libro Inteligencia social seala (2006, p. 393): Los mejores jefes son personas confiables, empticas y capaces de sintonizar con los dems, 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 Heildelberg, 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 potica 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 involucramiento va team building es similar al modelo de orquesta sinfnica y sus caractersticas 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, coaching, 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 material 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 disonancias 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: vivenciar 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 improvisadores 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 contingencias en los proyectos. Contingencias de verdad, no situaciones que eran predecibles 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 incluso 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 proyecto 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 siendo vlido, especialmente si pas mucho hasta la siguiente. Por supuesto, el plan de la etapa debe ser aprobado por autoridad.
87
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 disponibles 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? Tambin 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, manteniendo un ncleo de participantes permanentes durante el proyecto.
88
JUAN BRAVO C.
Se trata de formar un equipo integrado por especialistas en rediseo de procesos, informtica, usuarios ejecutivos y consultores se gana el efecto consultor, 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 usuarios) y usuarios clave de cada rea a redisear. El usuario lder trabaja coordinadamente con el jefe del proyecto. Lo ms probable es que en cada etapa cambien integrantes del equipo de trabajo 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 usuarios, 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 preparar cada entrevista, anticipando lo que se pueda utilizar. Vital es la buena ejecucin 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 confianza con una actitud serena que surge de la puntualidad, preparacin y presentacin (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. Asimismo, debe pensar cmo lograr que la entrevista sea satisfactoria para el individuo al que entreviste.
89
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 conveniente comunicar mucho. Esta sola actividad implica disponer de horas de especialistas en comunicacin, 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 actividad completamente transversal.
8. Informes
Cada etapa tiene uno o ms entregables que deben quedar registrados en informes. 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 competencias mnimas en el equipo de trabajo (que es preferible no dar por adquiridas), por ejemplo: redaccin, ortografa y capacidad de sntesis. Al menos, la habilidad de leer. Por supuesto, debiera documentarse al mismo tiempo que se avanza en la etapa, 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 embargo, 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 evaluacin 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, fertilizantes 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.
91
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 acciones 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 proyecto, 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 proyecto 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: factibilidad, anlisis y diseo. Es necesario incluir costos ocultos tales como la misma planeacin de la etapa, las reuniones de coordinacin, la negociacin con la direccin y las exposiciones de avance, entre otros.
14. Gestin de riesgos

Se trata de detectar riesgos y elaborar un plan para mitigarlos y/o traspasarlos. 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 expectativa. Es el momento adecuado? Y si no se llega a una conclusin? Y si excede 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 ocurrencia (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 menos 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 entregables 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 proyecto 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 35
En el libro Gestin de Procesos hay un anlisis de la gestin de riesgos. Quality Assurance, traducida como aseguramiento de la calidad.
93
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 proyecto mientras este dure, trabajar con eficiencia, alinear intereses, cuidar el entorno 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 gestin 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 recursos, 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.
18. Orientacin al cliente

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 dentro y fuera de la organizacin que tienen relacin con el proyecto. Es diferente a comunicar y capacitar, aunque se complementa con esas prcticas. 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, relator, extensin y muchos otros aspectos deben estar bien pensados. La capacitacin de los usuarios es vital en el proyecto. Por supuesto, es diferente segn tipos de usuarios y puede tomar variadas formas (la recomendacin 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 pedagoga 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 relacin con el diseo de indicadores.
95
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 continuidad de las operaciones cuando el proyecto est en funcionamiento, ms all de slo tener planes de contingencia. La idea de fondo es evitar la contingencia, prevenir. Objetivos del plan de continuidad operacional: Crear conciencia en el equipo de trabajo y en los usuarios acerca de la prevencin 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 severidad 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 operaciones 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 elementos que se requerirn en el proyecto: equipos computacionales, redes, licencias, escritorios, espacio fsico, baos, comedores y otros. Un trabajo bien hecho en materia de recursos fsicos tendr su nivel de influencia 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 consume 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 presupuesto 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 organizacin. Esperar puede poner en riesgo su existencia.
26. Control de cambios

El control de cambios tiene dos interpretaciones: durante el desarrollo y durante 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 contemplados en las prcticas anteriores, tal como direccin del proyecto, sensibilizacin, 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 diramos 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.
97
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 empresas 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 requerimientos precisos. A veces se malentiende la gestin de proveedores y de subcontratistas, errneamente, 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 volver 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
99
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 ingenieros de software han sido los hijos del zapatero. Aunque estos profesionales han construido sistemas complejos que automatizan 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 produccin 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 modelos 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 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.
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 metodolgicamente. Hay que desmitificar la produccin de software, transformndola en una actividad 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 desarrollo. Usuarios calificados son profesionales y ejecutivos que poseen entrenamiento formal en tecnologa de la informacin, quienes conocen su problema y saben como estructurarlo. La orientacin del captulo y de todo el libro, es hacia la produccin de software que apoye directamente los procesos de la organizacin teniendo siempre al cliente como norte (al cliente final, el que paga). La ingeniera de software incluye la produccin de otros productos de software, como sistemas operativos, herramientas de productividad o de automatizacin de oficinas. stos siguen patrones parecidos a la produccin de software administrativo e incluyen algunos aspectos ms especializados, como el nfasis 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
101
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 ejecucin. Es lo que plantea Ian Sommerville (2005, p. 6): La ingeniera del software es una disciplina de la ingeniera que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema 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 software, trataremos sobre la necesaria educacin y discutiremos sobre la real necesidad de construir software con el objetivo de asegurarnos de trabajar en proyectos 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: externalizacin, trabajo de equipo, redefinicin de procedimientos, rediseo organizacional, 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 produccin sistemtica de productos de programacin, que son desarrollados y modificados 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 eficientemente sobre mquinas reales.
102
JUAN BRAVO C.
Comentarios de Roger S. Pressman: La ingeniera del software surge, sobrepasndola, 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 productiva. 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 relacionadas con el desarrollo de software: fiabilidad, eficacia, control, normalizacin 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 productividad permita satisfacer las demandas pendientes. Sin embargo, hay instalaciones donde se increment la productividad del desarrollo y an as los usuarios no estn satisfechos. No ser que comenzamos por el lugar equivocado? 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 necesidades. Contratar desarrollo externo. Veamos estos puntos con mayor detalle: 1. Realmente hacer ingeniera y buscar otras alternativas de solucin al problema, 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 productos 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 consistente 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.
103
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 locura desarrollar aplicaciones tpicas, tales como: contabilidad, inventarios, remuneraciones, activo fijo y facturacin. En el mercado existe una amplia gama de excelentes soluciones para todo tipo de plataformas, comenzando 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 computacionales (25% de los casos). 3. Estudiar la posibilidad que sea el mismo usuario quien resuelva su problema. Con capacitacin y herramientas apropiadas puede resolver su requerimiento 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 grandes bases de datos para extraer informacin, puede ocupar Microsoft Access o alguno de los mdulos de consulta que proveen los sistemas administradores 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 complejidad 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 etapas 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 requerimientos 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 perfeccionamiento, debiera destinar una cantidad equivalente de horas a los temas 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 sistemticamente en tcnicas y herramientas uniformes para el desarrollo de sistemas. Adicionalmente, se incrementa la capacidad individual, mejora el funcionamiento 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 calidad 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 educada y no a una acumulacin de ttulos. Est relacionada con una sistematizacin 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 supeditada 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 personas, comenzando por los ejecutivos de mayor nivel. Para disear el programa de enseanza, se pueden extraer algunos temas de la clasificacin de materias presentada en la figura 2-1, la cual es solamente un ejemplo del tipo de materias en cada categora.
105
La empresa en la comunidad Planificacin estratgica Adaptacin al cambio Liderazgo, organizacin y administracin Ambiente de Calidad Reingeniera y benchmarking Mejoramiento continuo Visin sistmica Gestin de procesos Mapas de procesos Flujograma de Informacin Gestin de proyectos Orientacin al cliente Diseo de sistemas Sistema de productividad Tecnologa De Informacin Orientacin a objetos y UML Modelamiento de datos Mtodos de desarrollo de software 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 propias 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 empresa moderna, est entrando en el colegio y en el hogar. Qu es la tecnologa de informacin? La palabra tecnologa ya nos dice mucho, ella proviene de la raz latina techne = arte y logy = organizacin, es decir, 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 herramientas en rpido progreso. Sobre la informacin, hay cientos de libros que la tratan desde todo punto de vista. Podramos agregar que los datos se encuentran hoy en computadores que los procesan para obtener, gota a gota, esa informacin 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 observacin y la experiencia, es lo que produce tecnologa. Es un tipo de conocimiento medible, de rpida formacin, traspasable, actualizado y perfeccionado, con redes internacionales de especialistas que comparten su saber. Esto ha sido en gran medida lo que origin la revolucin industrial y ahora la revolucin del conocimiento. Aunque no basta con el conocimiento, tambin es indispensable el entendimiento37. 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 conveniente 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.
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 caracterizado 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.
37
107
Es que la implementacin de cualquier tecnologa debe armonizar conocimiento 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 respondieron 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 intereses contrarios a los de la organizacin, falta de perfeccionamiento de los colaboradores, sesgo informtico, etc Entre las causas, se considera especialmente relevante la carencia de una visin 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 encuentra desactualizado, estaramos en presencia de problemas mayores cuya solucin comenzar cuando se cuente con el plan estratgico de la organizacin. Para efectos de ofrecer luces respecto a lo que debe incluir el plan estratgico 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 debera 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 generalmente la relacin costobeneficio es claramente conveniente. Por lo tanto, no es caro probar opciones, es ms, muchas veces resulta ms econmica una equivocacin 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
109
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 especfico, algunos productos de software y un mtodo de desarrollo. Ahora hablamos de mentalidad, flexibilidad y disposicin al cambio. Si en la empresa se ha vencido el temor a ensayar opciones; si de alguna forma se tiene institucionalizado probar alternativas para seleccionar aqulla que mejor les parece, entonces la resistencia al cambio es muy baja. Como consecuencia, se obtiene un subproducto 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 estratgicas que estn ms all del mbito informtico. Estas decisiones estratgicas deben ser tomadas en reuniones conjuntas de la alta gerencia con sus especialistas 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 conversaciones 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 desintegracin de la industria. Para adaptarse, emprendieron el proceso de la reingeniera de acuerdo 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 productos gustan y a esos se les da prioridad Queremos tener socios en cada pas a travs de sociedades 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 administracin.
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, procedimientos 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 estructurado. Es creciente la velocidad de introduccin de las tcnicas de orientacin 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 (pantallas e informes) y funcionalidad (ingreso de datos o seleccin). Generacin automtica de cdigo. Lo cual es hoy una realidad con mltiples 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.
111
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 informtica, es que las rentas de especialistas bien preparados en cualquiera de esos temas son mayores al promedio. Los primeros pueden ver esto como 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 virtualmente 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 primera 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 organizacionales, 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 departamentos usuarios, trabajando en pequeas unidades de informtica descentralizadas 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 internos, especialmente en innovaciones, informacin y adaptacin al cambio. El nuevo rol del analista ya es solucionar problemas, en lugar de desarrollar sistemas computacionales; en consecuencia, su preparacin debe incluir 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 cliente 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 Gerente 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 menos 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 dificultades. 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.
113
25% Ya poseen los nuevos conocimientos
25% No tienen tolerancia 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 definiciones estratgicas respecto a la ingeniera de software. Analizaremos aqu algunas posibilidades de organizacin informtica, compatibles 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 autonoma 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 nivel de la empresa y de cada rea viable. As como existe una fuerza area nacional 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 computadores 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 arquitectura abierta, por lo estndar de los PCs. Externalizacin (outsourcing) Significa contratar externamente el servicio de informtica, teniendo el cuidado 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 relacin con la informtica: Es ms econmico, porque generalmente resulta de ms bajo costo subcontratar que proporcionarse uno mismo el servicio, incluyendo en el costo interno las rentas de las personas, infraestructura fsica y uso de otros recursos generales: contabilidad, servicios bsicos, etc. Esto agrega el gran beneficio 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 misin, la cual desatiende al destinar tiempo y recursos en atender a la autogeneracin de servicios que puede tomar del medio. En otras palabras, aun cuando el servicio interno resulte ms econmico que ser contratado externamente, 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.
115
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 departamentos tal como Falabella, Ripley y Almacenes Pars en Chile los bancos comerciales, los supermercados y muchos otros que necesitan el procesamiento 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 empresa dedicada a otra misin: su renta queda rpidamente estancada; su evolucin profesional es ms lenta porque solamente conoce la realidad de la empresa; no hay mayores incentivos para innovaciones, porque no se aprecian 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 rendimiento 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 aspecto debe ser analizado en la gerencia con la mayor atencin debido al impacto 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 contrataciones 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 Realidad actual: Definiciones estratgicas Aplicaciones Conjuntos de datos Proyectos en desarrollo Definiciones estratgicas: Organizacin Equipamiento Bases de Datos Mtodos Herramientas de productividad Normas Participacin del usuario Conjuntos de datos En los procesos Referencias cruzadas Procesos vs datos
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: organizacin de la funcin informtica; plan de equipamiento; tipo de producto para
117
administrar las bases de datos de la empresa; mtodos de la tecnologa de informacin; 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 generalmente 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, orientados al cliente y a objetivos internos, respectivamente. Luego, identificamos los conjuntos de datos que se manejan en cada proceso: clientes, proveedores, artculos u rdenes de compra. Despus, construimos una matriz con todos los procesos y conjuntos de datos, el objetivo es obtener referencias cruzadas y determinar 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 proyectos 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, infraestructura, 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 definiciones estratgicas reformuladas a la luz de los nuevos antecedentes aportados durante 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 planificacin estratgica en tecnologa de informacin. Al igual que con cualquier normalizacin viable, el desarrollo de la planificacin estratgica en informtica debe tener las siguientes caractersticas: consensual, 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 programadores 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 externo debe ser compensado con un cambio interno equivalente, de lo contrario, el sistema corre el riesgo de romperse.
119
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 ambiente 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 anterior (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 logrado imponer su visin. Es el caso del comportamiento autocrtico, indudablemente mejor que la anarqua, aunque pobre en rendimiento. Generar normalizaciones internas particulares ajenas a su negocio no es la misin de la organizacin, esto produce un desgaste que atenta contra el mejor 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 organizacin 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 compromiso de la empresa, como un todo, con el nuevo enfoque. En este nivel comienza 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 resistencia 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 incorporacin. Este ltimo nivel permite cuestionar y renovar las normas de la organizacin. 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 incorporada (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 garantizado 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 implementacin, 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 productividad. Si la organizacin est en los niveles anrquico o de normalizacin interna, el resultado de incorporar nuevas tecnologas es tiene alta probabilidad 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 informtica sino solamente servir de gua para profesionales, quienes introduSe refiere al ranking de la revista homnima con respecto a las 500 empresas de mayores ingresos y rentabilidad.
39
121
cirn cambios y realizarn las adaptaciones necesarias para atender cada situacin 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 organizacin. 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 ventaja competitiva. En las debilidades es preferible no desgastarse, mejor externalizar 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 valores que percibe el cliente.
40
Ver libro Gestin de procesos.
123
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 sistema 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 armonioso 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 computacionales es un factor diferenciador para el xito del negocio. Obviamente, esto no es gratis, pues exige una inversin que debera ser asumida como un proyecto, comparando beneficios versus costos, incluyendo el costo vigente de la falta de informacin para la toma de decisiones. La inversin, adems de dinero, incluye tiempo, disposicin y esfuerzo de los interesados. Es ms, si la organizacin como conjunto no est dispuesta a comprometerse, 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 software, slo puede ser modificado por una solucin con variedad equivalente. Esa
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.
41
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 advertencia: 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 factor. Por ejemplo, tal vez no elijamos la herramienta ms moderna, pero nuestra seleccin se lleva bien con el hardware que empleamos, es fcil de aprender 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 Weitzenfeld 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 discuten los desafos ms importantes de la ingeniera de software. En este artculo 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, confiabilidad, 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
125
nfasis en aspectos de calidad, control de riesgos e incorporacin de las competencias 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 producido. Este concepto se aplica generalmente a implementar la aplicacin en diferentes plataformas, aunque tambin se refiere a la portabilidad del diseo. Las tcnicas tambin deben ayudar a facilitar el perfeccionamiento de las aplicaciones, 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 componentes, 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 organizacin 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 computadores 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 rendimiento 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 infraestructura. 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 estaciones 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.
Sorprende al autor el rpido avance, en 1980 estaba a cargo de una instalacin con equipamiento 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, Planificacin en Informtica, se describi este concepto.
43
127
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 mucho ms profundo la adaptacin al cambio. A veces el usuario no sabe exactamente lo que quiere, an as, eso no es motivo para un trabajo anrquico. Es posible hacer prototipos en las etapas de anlisis 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 construccin de un sistema de informacin no significa una imposicin de cambios 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 comprensin que tiene el usuario de su propia necesidad45 y de la calidad de la informacin 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 principios del siglo XX. Cuando recin aparecieron, se pensaba que era difcil su masificacin, porque cada automvil requera un chofer-mecnico. Sin embargo, 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 identificacin, 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 amistosos (hardware, muchas herramientas y mtodos), existe una importante infraestructura 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 productividad? 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, estimndose que ellos puedan absorber sin problemas casi la mitad del desarrollo 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 contratacin del servicio externo directamente por el usuario. Hay que ser cuidadoso con no abusar de esta descentralizacin porque la autonoma del usuario podra interferir con la necesidad de tener sistemas centralizados 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 interacciones innecesarias con otras personas. Se le llama tambin costo de transaccin o de administracin. Es el tiempo invertido en la definicin y control del acuerdo. Desde un punto de vista tcnico, se gana tiempo disminuyendo el overhead administrativo, el cual se podra definir como el tiempo improductivo 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,
129
produce cuando una persona pretende hacer 2 3 tareas a la vez, desconociendo 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 intraempresarios, quienes gestan, participan y se comprometen con su proyecto. Son los menos. Ellos son intraempresarios o empresarios al interior de la empresa, 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 proyecto 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 interesante: contratar a un especialista en informacin. Este profesional debiera tener amplios conocimientos de planificacin estratgica, proyectos, ingeniera
el procesamiento monousuario es ms eficiente que el manejo multiusuario, porque el procesamiento 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 procesador 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 usuarios 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 proponer 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 seguir 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 categora. 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 productividad de hasta 30 veces entre programadores. Es fcil observar en cualquier organizacin las diferencias de rendimiento, ver que generalmente en una muestra superior a 10 personas la relacin entre el menos y el ms productivo comienza a pasar de las cinco veces. Resulta evidente nivelar hacia arriba con un esfuerzo de investigacin que descubra causas asociadas al conocimiento, 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: especializacin y comunicacin interpersonal, tal como se muestra en la figura 2-4, donde se aprecia que la productividad es producto de la armona entre esos factores. El extremo de la especializacin podra llevar a la incomunicacin. Las mediciones que hemos realizado en empresas muestran que en promedio estamos 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 sensibilizar que si aumentamos 1 en la tcnica, el producto ser 12 y si aumentamos 1 en la comunicacin, el producto es 15
131
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 prometen reducir los tiempos de desarrollo y aumentar la tasa de xito de los proyectos, pero los ingenieros de software experimentados tienden a ser justificadamente 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 comunicarse. 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 construccin de hardware sofisticado. Si nuestra misin es producir o vender prendas 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 creatividad, 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 normalizadas 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 esfuerzos 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 diferentes reas.
133
Tmese como ejemplo la anarqua en el desarrollo de sistemas computacionales al interior de muchas organizaciones, existiendo en el medio buenos mtodos 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 revisin, idealmente una vez por semana. Naturalmente, la normalizacin tambin podra ser corregida frente a situaciones excepcionales, como la implementacin de un nuevo sistema o la integracin de otra persona a la organizacin. 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, debiera ser breve y precisa. Por ejemplo, las pautas referidas al rea informtica, 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 interior de la empresa, de tal forma que todos sus estamentos normalicen polticas, mtodos, herramientas, tecnologa y todo aquello que facilite la comunicacin. 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 empresa con reglamentaciones. Muy por el contrario, se toman del medio esquemas probados para no distraer la atencin de los verdaderos intereses de la organizacin. En este contexto, las innovaciones son bienvenidas y pueden desarrollarse con amplia colaboracin. La buena normalizacin garantiza el funcionamiento regular de la institucin, dejando espacio para el desarrollo permanente de nuevas ideas. Conocida por todos los interesados: se recomienda crear un sistema de informacin destinado a enviar oportunamente un ejemplar de la normalizacin o de su actualizacin a todos los interesados, segn una base de usuarios actualizada y con mecanismos apropiados para eliminar las copias 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 positivos pueden ayudar a aumentar la productividad ms all de las 10 veces sealadas 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, silencio 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 mercado 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 excelencia en la gestin.
135
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 implementacin 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 criterio 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 sistemas 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 bifurcaciones) 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 funcional. Definicin de rutinas complejas. Nada hay que complique ms la mantencin que la incorporacin de rutinas complejas dentro de un programa. Siempre es posible simplificar y modularizar las rutinas. Es ms, en la mayora 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 complejos hacer uso indiscriminado de vectores o matrices, los cuales representan 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 introduccin masiva de las bases de datos es menos frecuente en nuevos sistemas, 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 entonces 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 banderas 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 muestra, 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 requiere 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 almacenamiento. El costo de esta solucin es US$ 500, considerando lograr algn ingreso con la venta del PC antiguo.
137
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 soluciones propuestas para un perodo de tres aos.
Ampliar hardware US$ 500 US$ 100 2 das 1 da alta Optimizar cdigo US$ 400 US$ 600 1 mes 1 semana nula
Factor de comparacin Costo inicial Costo de mantencin Tiempo de implementacin Tiempo del usuario Utilizacin en otras aplicaciones
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 claramente conveniente ampliar el hardware y esto sin considerar los otros factores 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 valorado 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 olvidando 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 geomtricamente (se reduce 3 aumenta 9) a raz de la mantencin del cdigo. Desarrollo por prototipos es la solucin, aplicndolo en sistemas computacionales 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 antiguas. Cesanta de programadores, en la realidad se est produciendo el fenmeno contrario, una oferta total de trabajo creciente para especialistas preparados 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, producindose las llamadas islas de automatizacin, con lo que aumenta ms an la confusin.
139
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 administradores 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 objetos 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 objetos. 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, personalizado, econmico, portable, simple, rpido y amistoso, en plazos convenidos y dentro del presupuesto asignado. Resolver slo problemas simples. Aplicando los criterios de modularizacin y de descomposicin funcional, siempre es posible dividir un problema complejo en un subconjunto de problemas ms fciles de resolver; por lo tanto, lo que finalmente se resuelve son problemas simples, aunque mantenindose 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 necesario aplicar frmulas de optimizacin, porque podran introducir sofisticaciones indeseadas en el modelo. Independencia de la aplicacin respecto al especialista. Un problema frecuente 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 desarrollador. 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, mediante 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 herramientas de productividad va en aumento y es posible que en algn momento represente 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 programas 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:
141
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 construir 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 requiere varios das. Esto, porque impactan aspectos sicolgicos y de ordenamiento 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 computador, 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 construir. 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, porque se trabaja construyendo un prototipo que se va transformando poco a poco en la aplicacin final, a travs de perfeccionamientos sucesivos. Las herramientas 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 general que las herramientas CASE provean generadores de datos de prueba. Las ltimas pruebas son en ambiente real, lo que es equivalente a tener la aplicacin 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 mantener intacta la capacidad de desarrollo continuo de una aplicacin, tema que veremos ms extensamente en el siguiente punto, sobre mantenimiento de la solucin de software.
6. Mantenimiento de la solucin de software

Cada vez en mayor medida, la palabra mantenimiento est siendo reemplazada 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 implementa48
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 probabilidad 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 palabra 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 producto menor con un xito sin precedentes... Esto significa que la planificacin debe agregar la condicin de reformulacin permanente.
143
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 tradicional 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 disponerse 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 regeneracin 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 repositorios de datos. Pruebas. Reentrenamiento. Aqu hay una diferencia notable respecto al mtodo tradicional. Ahora el mantenimiento del sistema significa realizar cambios sobre el diseo, la especificacin 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 especialistas en un departamento de sistemas al menos en 100 %, porque unos dos tercios de las actividades regulares de los centros de computacin estn destinadas a mantenimiento. Junto con el mantenimiento de un sistema computacional se realiza su explotacin, 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
145
2.5. MTODOS PARA LA PRODUCCIN DE SOFTWARE

Los mtodos de desarrollo apuntan a cmo construir tcnicamente el software. Generalmente se han clasificado en dos grandes grupos: Sobre la gestin del proyecto: donde se proponen mtodos para planificacin 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, diseo 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 importancia, 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 definen los conjuntos de datos, la organizacin del sistema y se especifican los programas. 5.- Programacin: su objetivo es construir y probar los programas especificados 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, entrenamiento de las personas, poblamiento de las bases de datos y procesamiento en paralelo. 7.- Mantencin: su objetivo es dar respuesta a cambios sobre el sistema despus de su implementacin. Se estima que esta tarea consume tanto tiempo 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 comunican 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 requerimientos y de un nuevo proceso de desarrollo, retardndose excesivamente 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.
147
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 netamente intelectuales, como el trabajo administrativo, donde se utiliza mucha simbologa (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, confusos 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 prototipo 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 desarrollo, 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 solucin. 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 exhaustiva 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 alteradas 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, ampliamente 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 deberan 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).
149
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! Simplemente es otro error de la naturaleza que result ser apropiado en ese ambiente 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 En el Polo Norte Primera generacin Cuarta generacin
Piel delgada
Piel normal
Piel gruesa
Grosor de la 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 generacin 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 delgada, 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 mediana 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. Tambin se puede apreciar la libertad que usa para buscar soluciones a su problema, sin mayores prejuicios. Se podr observar que la forma de seleccionar alternativas que el nio emplea, an est exenta de nuestros patrones de conducta, 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 aplicacin 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. Generalmente 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 interaccin 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 inventarios o el formulario de liquidacin de renta mensual en un sistema de remuneraciones. Dependiendo de cada problema, debe estudiarse la real conveniencia de aplicar la tcnica de prototipos, ella es especialmente til en problemas administrativos 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 funcionamiento manual del sistema o alguna solucin de software anterior, aunque
151
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 corrientes y contabilidad. Es preferible que la empresa adquiera ese tipo de sistemas en el mercado y reserve el desarrollo interno para los sistemas computacionales 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 abajo, tipo top down, comenzando por una visin de alto nivel que se va detallando en niveles cada vez ms profundos. Concurrencia: significa que existen varios procesos que pueden ser activados 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 puede servir a otra aplicacin. Se aplican aqu los siguientes criterios: o Acoplamiento, equivalente a traspasar informacin entre rutinas. Se sugiere que sea lo ms dbil posible. o Cohesin interna del mdulo; lo ms fuerte posible. Descomposicin funcional: es el concepto detrs de la modularidad, significa tener funciones atmicas, que resuelvan solamente una necesidad, con la mayor independencia entre s. Antes, junto con el diseo estructurado se ocupaba la programacin estructurada, 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 objetivo 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.
Clientes
Pedidos y devoluciones Costos
Gerencia
Niveles
Artculos y factura
Control de stock
Artculos y gua
Despacho de artculos Peticiones
Proveedores
Orden de compra y devoluciones
Sala de ventas
Figura 2-7. Ejemplo de diagrama de contexto
En la figura 2-7 el crculo seala el sistema y los rectngulos indican las entidades con las cuales se relaciona. Los flujos de informacin se muestran con
Una experiencia interesante ha sido que el diseo estructurado no obliga a tener programacin estructurada, as como la orientacin a objetos no obliga a emplear programacin orientada al objeto.
51
153
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 almacenamiento o archivo.
Compras, traspasos y devoluciones
1 Recibir Unidades y costo
2 Ventas, traspasos y Despachar devoluciones Unidades 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 temporales 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 propsito 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 direccin 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 representado 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 correspondiente segn cada estrato de profundidad; por ejemplo, el proceso recibir de la figura 2-9 incluira tres subprocesos en el siguiente nivel: 1.1 comprar, 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 especificacin 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 funcionalidad del proceso. Para esto se usa pseudolenguaje, el cual es equivalente a espaol estructurado. Veamos algunas de sus caractersticas:
155
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 flexibilidad 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 resultados 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 resultado 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 modelo 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 (Extreme 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 desarrollador de sistemas puede controlar son el tiempo, el costo, la calidad y el alcance. Cuando estas cuatro variables de control se incluyen de manera apropiada 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 codificacin es esencial en cualquier proyecto de software. Las pruebas de funcionalidad, desempeo y conformidad son obligatorias. La actividad de escuchar 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 organizacin normal y sigue los mtodos descritos en este libro. Podr reducir significativamente su tiempo de desarrollo, puede que hasta la mitad, e incrementar tambin su productividad. Adems, podr hacerlo sin alterar la calidad, 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 funcionar slo con problemas sencillos, y el desarrollo de software no lo es. El desarrollo 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.
157
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 aplicacin que luego se implementen, la explotacin mejora en mucho. A diferencia de cuando se pretende incorporar ayudas para la operacin y auditora del sistema 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 sistemas 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 tipo 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 diferentes partes del proceso (por ejemplo, nmero de registros ledos igual a la cantidad de artculos impresos) y que estn de acuerdo con promedios histricos. La mayora de las verificaciones de este tipo podran haber sido consideradas 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 parcialmente 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 procesos 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 uniformidad, 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 base 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.
159
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 computacional. En un esquema de organizacin centralizada, la auditora computacional controla toda la gestin del centro de computacin, incluyendo la parte administrativa 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 desarrollar 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 deberan 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 creatividad. Para cumplir con su labor contralora, el auditor computacional debe ubicarse fuera del departamento de sistemas, normalmente en un departamento de auditora computacional, a cuya jefatura debe hacer llegar los informes de sus auditoras, generados en forma independiente de cualquier otro emitido por el rea de computacin. Generalmente el departamento de auditora computacional es parte de contralora 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, porque el nfasis debiera ser puesto en el desarrollo de las personas, en autonoma, colaboracin y relaciones basadas en confianza.
160
JUAN BRAVO C.
La necesidad de la auditora computacional es particularmente evidente en instalaciones 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 computacionales y crear departamentos de auditora computacional, los cuales agrupan a un conjunto de profesionales de tipo multidisciplinario, porque deben ser especialistas en computacin y en auditora interna. Pero tambin la auditora ha salido beneficiada con el advenimiento de la computacin. Hoy, con mltiples programas de apoyo, se pueden efectuar minuciosas revisiones, como la tarea de verificar la totalidad de la informacin disponible en el computador respecto de un problema, la cual sera prcticamente imposible 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 organizaciones 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.
161
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 posible amenaza. Por ejemplo, si todo lo expuesto en los captulos de este libro fuera aceptado como la metodologa de trabajo para un departamento de sistemas, 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 cumplimiento 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 normalizados 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 desean optar a la certificacin en las normas ISO 9000 o CMM deben someterse 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, ayudando 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 computacional, 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 incorporacin a nivel del diseo de la aplicacin. Cuando las sugerencias se realizan sobre 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 nmero de terminales y PCs en poder de usuarios, la labor de proteccin se ha venido 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 autorizados, 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 invalidaciones 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 reiniciar 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 posibles riesgos, cuantificar cada uno de ellos y estimar la probabilidad de ocurrencia 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.
163
4. Seguridad de la informacin
El concepto de seguridad incluye variados tpicos: Instalaciones fsicas: control de acceso de las personas o riesgo de incendios, a modo de ejemplo. Procedimientos administrativos: fugas por errores en el diseo lgico, documentos 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 accidental 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 primeros problemas pueden ser enfrentados con el apoyo de los proveedores y el tercero con la ayuda de herramientas de productividad y mucho, mucho orden. Respecto de los intentos de infiltracin deliberada, la principal forma de evitarlos 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 lectoras 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 segundo intento el ejecutivo dijo s a un cheque robado y con orden de no pago. 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 derechos 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 modificacin). 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 altera 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 incorporados estos y otros mecanismos.
5. Integridad de la informacin
El problema de integridad es asegurarse que los datos de las tablas en el computador sean exactos en todo momento, es decir, protegerlos contra invalidaciones 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 generar 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 comparacin entre campos. Verificaciones de consistencia a travs de revalidar la informacin en maestros. Verificacin de claves.
165
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 olvidar 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 respaldos utilizado. La alternativa ms habitual de recuperacin de informacin es la reconstruccin 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 archivar 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 (Abuelo-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 administradores 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 interfaz humana de la solucin de software. Se refiere a definir interfaces intuitivas 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 interfaz 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 cdigo 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 utilizar 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 conocern el mismo entorno y la organizacin habr dado un paso ms hacia la normalizacin externa.
167
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 funcionamiento si no solamente cmo lo debe utilizar para sacarle provecho. Sin embargo, si el diseo de la interfaz no es el adecuado se estar obligando al usuario a aprender a utilizar complejos instrumentos para sacar provecho 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 opciones 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 niveles 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 actualizados? A estas alturas sera preferible que los usuarios aprendieran a navegar dentro de buenas ayudas en lnea52. Ordenamiento de procesos: corresponde a la definicin previa de secuencias 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 diferentes objetos y las funciones generalizadas permitiran acceder a las consultas, informes y diferentes procesos del sistema.
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.
52
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 expedita 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 forma 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 (evitando 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 situacin aparecen mensajes diferentes o a la inversa, para situaciones distintas se utiliza el mismo mensaje. En este sentido resulta muy importante mantener 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
169
necesario la cambia por otra digitndola. La opcin de impresin debiera tener en forma predefinida el papel y la calidad de impresin que se utilizan 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 ventanas, 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 responsabilidad. Es demasiado fcil asumir que otra persona en el equipo de desarrollo solucionar cualquier dificultad de interfaz que surja. Adems es importante recordar de que los programadores van a tender siempre a codificar 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 distancia. 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 porcentaje de error y un alto porcentaje de rendimiento y satisfaccin. Ahora bien, este trmino es ms conocido como Look and Feel, concepto orientado 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 entregar lo que el usuario desea, esto es: trabajar en un entorno grato y conocido. Entonces, qu mejor si es el usuario quien define como ver sus aplicaciones? Obviamente no podr tener acceso a las partes preestablecidas o inalterables. Ley 9: Usabilidad, que cumpla con la Intuitividad: usabilidad es una mezcla entre intuicin y facilidad, que permite al producto o servicio impactar e influenciar directamente sobre la productividad, rentabilidad y eficiencia 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
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 internacionalmente, tales como: CMM del SEI, ISO 9000 y/o Tick IT.
53
171
1. Corba
CORBA (Common Object Request Broker Architecture, en espaol, arquitectura 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 funciones 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 establecen las APIs55 y las comunicaciones que permitan interactuar a varias aplicaciones (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 modelos) 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 modelamiento 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 implementacin 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.
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.
54
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 niveles 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 categora. 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 visibilidad 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 documentado, 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 cantidad de compaas de xito en el desarrollo de software.
El Software Engineering Institute (SEI) es un Centro de investigacin y desarrollo financiado con fondos federales patrocinado por el Departamento de Defensa de Estados Unidos, por intermedio de la Oficina del Subsecretario de Defensa para la Adquisicin, 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 Universidad 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 sistemas de defensa de Estados Unidos. Cumple esta misin promoviendo la evolucin de la
56
173
4. ISO 9000
ISO corresponde a la Organizacin Internacional de Estandarizacin. La serie de normas ISO 9000 son bastante conocidas. Destaca que el sector informtico 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 aplicacin de las normas, su amplitud. Incluso la gestin de procesos fue considerada en la nueva redaccin de normas 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 organizacin 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 polticas especficas. 6. Implantar y mantener un sistema de aseguramiento de calidad.
6. ITIL
ITIL (Information Technology Infrastructure Library) se traduce como Biblioteca 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 (similares 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 propuesta. 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 calidad de los servicios TI: existencia de pre-requisitos mnimos, intento de gestin, capacidad de proceso, integracin interna, productos, control de calidad, informacin de gestin, integracin interna e interfaz.
175
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 principal es aprovechar las funcionalidades de aplicaciones computacionales antiguas sin necesidad de intervenirlas. Se logra empaquetndolas y relacionndose 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 aplicaciones. 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. Sobre todo, se reducen errores al evitar reinventar innecesariamente la rueda. Al igual que la orientacin a objetos, es posible aplicar SOA mediante cualquier 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
177
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 negocio en s y de sistemas; o dicho de otra forma, no existen problemas 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 modelos de una solucin de software, tal como se aprecia en la siguiente figura (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.
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 construir 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 actividad 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 de entrada
Caja Negra
Variables 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 reglas de negocio.
179
2. Concepto de homomorfismo
Un homomorfismo es una representacin simplificada del objeto real. Un modelo 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 puede superar la complejidad para estudiar un automvil? Un mal mtodo sera intentar reconocerlo todo de una vez, porque los diferentes componentes dificultaran 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 aerodinmicas 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 persigue 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 Devoluciones Entradas Traspasos Ventas
Control del stock
Salidas
Devoluciones 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 proveedor, de ah el sentido de las flechas. Una compra puede incluir varios artculos y un artculo puede estar presente en varias compras. A su vez, un proveedor 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 Ingreso de datos Compras Artculos
Funcin Actualizacin de compras
Reglas Mover ltimo costo Sumar las unidades adquiridas al stock
Figura 3-4. Modelo orientado a las funciones del sistema
181
Cuarta, segn el flujo de transacciones: se muestra en este modelo que las transacciones atraviesan (actualizan) horizontalmente los maestros, tal como vemos en la figura 3-5. Es una matriz con entidades permanentes y transitorias, distincin ms conocida como maestros y transacciones, respectivamente. Los maestros son los pilares, por ejemplo: clientes, artculos y proveedores. Las transacciones fluyen, por ejemplo: ventas del da, compras y devoluciones de ventas.
Maestros Transacciones
Clientes
Artculos Proveedores
Cuentas Contables
Historial Ventas
Historial Compras
Ventas Compras
Devolucin ventas
X X
X X X
X X 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 diferente manera a los propsitos del diseador. En el fondo, la variedad de visiones es tan amplia como la variedad de puntos de vista respecto a una realidad57. En la figura 3-6 se muestra este concepto de infinitas visiones que se obtiene como subproducto del concepto de homomorfismo.
Modelo de funciones Modelo de datos Prototipo visual
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.
Abriendo levemente la puerta de la filosofa, hay quienes plantean que no existe una realidad 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.
57
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 respuesta, 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 necesario modificar el diseo. Sin embargo, es poco conocido hablar de un cambio 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 diseo, la cual est directamente relacionada con el modo de procesamiento. Veremos:
183
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 informacin: 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 objetivo de este informe es revisar manualmente los datos del ltimo perodo de ingreso. Actualizacin: con las transacciones del ltimo perodo de ingreso se actualizan 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 informacin 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 actualizacin 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 transacciones 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 relativamente nuevo y trascendental, porque implica ingresar y actualizar la informacin 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 comunicacin que se requieren. Este es el esquema predilecto en Internet.
185
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 independientes 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 computacionales. Son diferentes a las caractersticas universales del diseo de productos y servicios, como por ejemplo: abstraccin, amistosidad, flexibilidad, portabilidad, impersonalidad y factibilidad. Se supone que ellas son conocidas. Veremos: 1. Fluidez 2. Intuicin 3. Simplicidad 4. Orientacin al cliente 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 reglamentacin obsoleta, pero la naturaleza viene en ayuda de la organizacin! Y ese flujo se desborda y busca sus caminos naturales: cuntos manuales de procedimientos 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 intuicin 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 conciencia. Es esa sensacin de incomodidad, de que algo sobra o algo falta en el modelo, tal vez percibimos que no deberamos hacer el sistema computacional 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 capacidad para extraer conclusiones a partir de una pequea seleccin de datos significativos 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 capacidad 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 observaciones de la realidad detectadas con mayor rapidez.
187
Entonces, sin ser toda la fuente para una toma de decisin consciente, la intuicin 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, especialmente el usuario y cuando se siente que es simple. La simplicidad tambin se refleja en mantener una solucin limpia, sin particularizaciones para efectos de la implementacin tecnolgica. Simple como un anillo, dice Pablo Neruda en su famoso Poema 15.
4. Orientacin al cliente
Desde el punto de vista de proyectos de negocios, todos en la organizacin deben 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 podran variar desde cuando se concibe la aplicacin hasta su explotacin. Lo nico 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 maquinaria o mtodos de construccin y por supuesto, dentro de parmetros generales 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 siguientes 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).
189
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 inteligencia, porque los nuevos problemas particulares que se vislumbran ya estarn resueltos. Es un signo de inteligencia no resolver siempre los mismos problemas. Esto significa buscar el metaproblema, aqul que representa a todos los problemas 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 cuarto 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 anfibios? Es una tarea que requiere mucha prolijidad y creatividad, porque es necesario descubrir afinidades, identificar aspectos comunes e inventar clasificaciones. 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 involucrados; 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 reproducir 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.
191
La solucin formal y elegante es aplicar una contra-transaccin, una transaccin 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 incorrecta? 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 realidad deseada. Cuando en el modelo se le da importancia desproporcionada a situaciones indeseadas, el efecto es que se aumenta la probabilidad de ocurrencia 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 armonizar 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 situaciones indeseadas. El efecto psicolgico es que cuando un operador del proceso observa el rombo, 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 universidad, 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 evaluacin 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.
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 atencin el lenguaje que ocupa la gente [en la TV]. Supuestamente la televisin siempre ha enseado. 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.
58
193
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 requerimiento, 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 pblica 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 elctrico, 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 buscar la funcionalidad comn que tienen la mayora de las aplicaciones: ingreso de datos, informes, clculos, extraccin de informacin, actualizacin, seleccin 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 sobre 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 modelamiento tradicional, es cuando ya no se obtiene beneficio al seguir fraccionando; lo cual, incluso, puede llegar a ser inconveniente o absurdo. Esta situacin 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 normalizacin 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 descomposicin 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 forma 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, separaciones 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 geogrficas (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
195
computacionales es similar, porque la descomposicin funcional ubica finalmente 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 aplicacin. Por otra parte, la implementacin puede simplificarse con un generador de cdigo que tome directamente los modelos de datos y funciones, para generar automticamente los programas. Ya lo veremos en el captulo 7 (Herramientas 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 vendidas 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 funciones, definindose ahora relaciones funcionales entre las entidades, que se activan 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.
Ventas
Actualizar stock Actualizar saldo de crdito del cliente
Artculos
Actualizar stock
Mermas
Clientes
Figura 3-10. Ejemplo de relaciones funcionales
Una relacin funcional puede corresponder a cualquier funcin entre dos entidades, 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 entre dos entidades.
3. Funciones asociadas a una entidad

Algunos tipos de funciones donde se trabaja con una entidad, son los siguientes: Ingreso: se realizan las operaciones de consultar, agregar, modificar y eliminar registros de una entidad. Si se trabaja con alguna herramienta, la presentacin 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 propias. Tambin el formato de la pantalla debiera ser proporcionado por omisin y con posibilidades de ser alterado.
197
Informe: se obtiene desde una entidad, indicndose: ancho del informe, campos que se imprimen, formato de impresin, saltos de pgina, ordenamiento, 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 monetaria. Adems de las operaciones bsicas: sumar, restar, multiplicar, dividir, 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 sumatoria de unidades por valor, de un determinado nmero de factura en la entidad 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 ingreso 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 existencia sobre la entidad maestro de artculos. Significa esto que hay dos entidades en el ingreso de datos? S, a nivel fsico, de implementacin y construccin; 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 artculos aparece nicamente cuando se activa la funcionalidad asociada al campo cdigo del artculo, definida en el modelo de datos. Es una validacin relacionada 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 informacin 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 provisorio, porque luego, en la orientacin a objetos, aplicando el concepto de encapsulamiento, veremos que realmente toda funcin acta slo sobre una entidad. 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: actualizacin, 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
Operaciones entre campos: Mover, sumar y restar
Maestro
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 maestro 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 mover 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.
199
El registro se crea si no existe. Se busca un registro especfico de la entidad 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 obtener 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 aparece 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 entidad 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
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
Operaciones de mover, con o sin condiciones
Destino
Figura 3-13. Esquema de una seleccin
200
JUAN BRAVO C.
En la seleccin, las condiciones fijas debieran quedar incorporadas al programa, evitndose que el usuario ingrese parmetros al ejecutar la aplicacin; por ejemplo, la condicin: obtener los artculos con stock < 0 puede ser la opcin 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, refrigeradores, etc Mantencin Esta funcin permite mantener una entidad de maestro a travs de transacciones que quedan registradas. Toma la forma que se muestra en la figura 3-14.
Mover clave de maestro
Transaccin
Agregar, modificar o eliminar
Maestro
Figura 3-14. Esquema de una mantencin
Permite agregar, modificar y eliminar registros. Esta funcin es de fundamental 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.
201
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 problemas 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 particular de un problema general ms fcil de resolver. Tambin se obtienen algunos subproductos: Uniformidad, porque los problemas simples tienen la importante caracterstica 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, entonces automatizar las soluciones es el siguiente paso, ms aun con el apoyo 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 programadores deban usar instrucciones de salto incondicional (GO TO) en los programas. 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-
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 recuperar y disponer de su obra en Internet.
59
203
des cada uno con muchos mdulos, administraremos las funciones computacionales atmicas que componen una aplicacin en la forma de componentes. Entonces, obtendramos lo siguiente:
1 Entrada
Funcin Atmica
1 Salida
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 aportado 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 cantidad 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 programa 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 suficientemente demostrado que el nivel de complejidad de un programa aumenta geomtricamente respecto a su tamao. Bajo estos conceptos la nica 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 totalmente conocidas y estructuradas; por lo mismo, fciles de automatizar y mejorar. Adems, es posible reemplazar una funcin computacional atmica 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.
205
3.6. CRITERIO CURSO NORMAL DE LOS EVENTOS

El criterio curso normal de los eventos es un nuevo aporte de la teora de modelos 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 feliz, sealando las acciones correctas de un proceso o relato, no se incluyen las excepciones. Por ejemplo, si se requiere que un supervisor apruebe un documento, no se indica grficamente qu pasa si no lo aprueba, o si un bodeguero debe recibir mercadera, no se indica que sucede si la rechaza. Son excepciones a la regularidad del proceso que se narran en hoja anexa, como parte 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 mismo 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 actividades del proceso. Es un tipo de diagrama de flujo de informacin que proporciona amplia visin acerca de variados aspectos del proceso: flujo, mensajes, actividades, estructura y tecnologa. El FI es la secuencia y temporalidad. Los Mensajes son el medio de comunicacin, pueden ser documentos, comunicaciones electrnicas u orales. Las Actividades quedan especificadas por cargos o roles. La Estructura queda representada por columnas. La Tecnologa 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 apliquen 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 empoderamiento, 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 smbolos de uso ms habitual se describen en las siguientes pginas.
PROCESO DESPACHO INMEDIATO

CLIENTE OE BODEGA ADMINISTRATIVO DE BODEGA FINANZAS DESPACHADOR
PROCESOS VENDER
Reservar y emitir GD
GD4
GD3 GD2 GD1
GDs
Buscar producto
GD4 OE
Rebajar saldo
Cliente recibe y firma recepcin
GD2 GD1
GD3
PROCESO CUADRAR
OE: Orden de Entrega, GD: Gua de Despacho
Figura 3-15. Ejemplo de flujograma de informacin despacho inmediato
207
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 presentado 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 realiza 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 pantalla 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 vendedor 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 entrenamiento 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 formularios, 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 desafos que no estn resueltos en el diagrama, sin embargo, ah estn las personas para decidir qu hacer. Esas mismas variantes ayudarn a perfeccionar el diagrama 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 estado 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 evitarse 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 figura 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.
209
Por qu? Porque estamos describiendo actividades que realizan seres humanos, con una variedad y riqueza infinitas, as es que en cada paso hay que dejar 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 condiciones 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 computacional (Cobol, C, Visual Basic y muchos otros). Por lo tanto, incorpora condiciones, 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-
Es lo habitual, sin embargo, depende de la convencin que se use en la empresa, ocasionalmente 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.
60
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 operativos: 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 nuevo es construir flujogramas de informacin independientes para cada proceso 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 diagrama, 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 borradores sucesivos. Smbolos de uso ms habitual * actualzar* 2 lminas ppt
Actividad manual Se debe usar verbos en infinitivo: Emitir O/C, Ingresar solicitud. Es un rectngulo.
Actividad
Actividad Las actividades que tienen algn componente computacional de interaccin computacional se indican con 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 computacional
Actividad de control
Es una actividad de control, tal como una informacin al rea de auditora. Es un cuadrado.
Control
211
Archivo manual permanente Archivo manual transitorio Formulario
El tringulo con la punta hacia abajo representa almacenamiento manual permanente de la informacin, principalmente archivadores y gavetas. El tringulo con la punta hacia arriba representa almacenamiento manual transitorio, tal como una carpeta con solicitudes de compra en espera de firma por el gerente. Es toda forma en papel en que los datos fluyen, tal como una factura, una orden de compra o una liquidacin de sueldo. Indica acciones que estn ms all del proceso. 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 manual
Archivo transitorio
Formulario
Otro proceso
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 Internet, 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 procesos. 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 correspondientes 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 Saldo
Rebajar saldo
2
Usa el lector de cdigo de barras para leer la etiqueta de cada producto que se vende. En el sistema se rebaja el saldo del producto.
Nota: una actividad computacional del FI se transforma en un Caso de Uso de alto nivel
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 flujograma 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.
213
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
215
Captulo 4. Modelamiento de datos

Sencillez, claridad y elegancia son los sellos de los buenos programas; 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 aplicacin 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 modelos de una solucin de software, tal como se aprecia en la siguiente figura (en la introduccin se incluy la visin global). Es indispensable que el analista conozca acerca del modelamiento de datos como simple responsabilidad profesional porque es una habilidad bsica de su labor.
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 solucin 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 conjunto de datos coherentes que forman una unidad entre s; por ejemplo: clientes, facturas de venta, proveedores. Una relacin permite enlazar dos entidades para establecer recorridos que permitan efectuar la navegacin automtica, 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 identificacin de cada persona u organizacin para fines tributarios).
RUT del cliente 4.101.201-4 7.749.654-3 10.143.245-6 Fecha de incorporacin 10/01/1993 15/02/1993 01/03/1993 Nombre del cliente Juan Prez Pedro Torres Ximena Kohl Lnea de crdito 500.000 700.000 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:
217
Cada lnea corresponde a un registro de la entidad clientes, tambin llamada 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 modelamiento y en la interaccin con el usuario, debido a su poca naturalidad. Hoy, la orientacin a objetos, algunas bases de datos y herramientas de productividad, 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 cliente (RP)
Rut 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 relacin 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 accesos 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 incorporacin 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 queremos acceder a la informacin: nombre, ciudad, telfono, etc y esa informacin estar siempre ordenada. En una relacin propia el contenido de los campos puede ser con o sin duplicado. En el primer caso los campos pueden repetirse y no sirve como una clave 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 campo es una relacin propia.
3. Caractersticas estticas y funcionales de campos

Cada uno de los campos de una entidad incluye caractersticas estticas y funcionales. En la figura 4-2, una caracterstica esttica es la fecha de incorporacin 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.
219
Las caractersticas estticas son atributos fijos del campo, por ejemplo: nombre del campo, descripcin, comentario, largo, tipo, signo, formato de despliegue, 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 mismo 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 manipulacin de datos. La lista de valores posibles es una caracterstica del campo y no es necesario definir una funcin. En la prctica, la mayora de las bases de datos modernas lo proveen como un parmetro ms. Rutinas de clculos especiales, como clculo de dgito verificador y transformacin 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, rebajar 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 modificadas; 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 mscaras 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 alfanumrico 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; diferentes 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, ciudades o pases. La funcionalidad asociada a los tipos de campo viene aportada por la respectiva 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 identificar 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. Algunos ejemplos de entidades de este tipo son: proveedores, clientes, artculos o empleados. Transacciones: son los conjuntos de datos que transitan por la organizacin y que afectarn las tablas maestras. Por ejemplo: ventas del da, compras del da y descuentos en sueldos. Temporales: se trata de una o varias tablas donde se guardan datos transitorios extrados de maestros, transacciones o de ambos. Puede ser directamente una copia de algunos de ellos. La entidad temporal se utiliza para ordenar y seleccionar datos o realizar clculos. Generalmente se elimina despus 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:
221
M1 T1 T2
M2
M3
Mi = Maestro; Ti = Transaccin
Se puede apreciar que los maestros son los pilares que dan el soporte a la estructura 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, proveedores, 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 intermedias 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 malla que es llamada modelo de datos, de esta forma:
0,n Clientes 1 Facturas 1,10 0,n 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 artculo 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
Clientes 0,1 1 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 Clientes
1 Facturas Facturas
Es una relacin de uno a muchos. Las formas ms habituales de representacin 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.
223
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 denomina 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 confundir 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 muchos artculos y un artculo es provisto por muchos proveedores.
Proveedores 0,m 0,m Artculos
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 personales 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 resolver 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 originales. Cada una es un ndice que apunta a la otra entidad, tal como en la siguiente 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 consistencia 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 embargo, 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.
225
4) Relacin N:M especial La relacin N:M tpica no permite manejar informacin propia de la interaccin; 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 transforma en una entidad asociativa en la cual se puede almacenar mayor informacin, 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 manipularn los datos. A esta relacin tambin se le denomina NUB natural porque tiene vida propia, 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 siguientes atributos (persona, persona, parentesco).
Personas
Parentesco
Por simplicidad del modelo, se recomienda estudiar la real necesidad de establecer nodos con informacin adicional en relaciones N:M. Relaciones de uso Las relaciones de uso son independientes de las entidades, porque no es necesario que su estructura contenga la relacin, como en la pertenencia. A veces, para efectos de implementacin, es necesario crear entidades asociativas, como 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.
227
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 preliminar 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 conjunto de datos uniforme, sujetos a la misma clave, esto simplifica el modelo 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 organizacin, sino tambin al exterior. De esta manera se economiza en preparacin de especialistas y es posible aplicar herramientas uniformes, como los sistemas administradores de bases de datos relacionales y las diferentes herramientas de productividad, para automatizar mltiples funciones: consulta de informacin, integridad, privacidad, recuperacin, ingreso de datos, informes y muchas otras. Aplicar herramientas de apoyo en el modelamiento, todas las cuales ayudan 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 inconvenientes: 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 identificador de cada ocurrencia del grupo repetitivo; puede ser un nmero correlativo o alguno de los campos del grupo repetitivo. El ejemplo de la figura 4-3 corresponde a la eliminacin de un grupo repetitivo incorporando un nmero correlativo externo en una factura de venta.
A Entidad no normalizada Clave N factura Fecha Rut del cliente Grupo repetitivo tem 10 tem 1 Cdigo Cantidad Precio Cdigo Cantidad Precio Entidades normalizadas B Encabezado Rut Clave Fecha del N factura cliente C detalle Clave N factura N tem Cdigo Cantidad Precio
Figura 4-3. Eliminacin de grupo repetitivo usando nmero correlativo externo
En este caso:
229
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 entidad 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 anotara en orden ascendente en el documento. Es ms uniforme y ordenado. Se le da flexibilidad al modelo, porque se podra repetir un cdigo sin afectar 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 record 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.
Entidades normalizadas B Encabezado Clave N factura Fecha Rut del cliente C detalle Clave Cantidad N factura Cdigo Precio
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 entidad (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 detalle 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.
231
A Entidad no normalizada Clave Cdigo de Sucursal producto Stock Cdigo Descripcin Nombre de de del estado producto estado
Entidades normalizadas B Entidad original normalizada T/T 18 Clave Stock Cdigo de Sucursal Cdigo de estado producto
C/E C Nueva entidad
Tabla de Traduccin (T/T) T/T 18 Descripcin del estado
Clave Nombre de Cdigo 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 dependientes de toda la clave: Descripcin del estado: es la traduccin del cdigo de estado en la sucursal, 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 traduccin 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 existencia 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 posible 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 perfeccionamientos sucesivos hasta dar por terminado el modelo y despus igual se sigue perfeccionando. Tambin podra haberse utilizado una entidad preexistente 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 como un saldo de mercaderas o la renta de un empleado. La entidad de existencia es un maestro tpico (clientes, artculos, empleados, proveedores) el cual, probablemente, tambin tiene uso desde otras aplicaciones. No obstante, las facilidades de la herramienta y la experiencia del diseador sern decisivas.
De aqu surge la necesidad de tener agrupadas en un slo lugar todas las traducciones simples, 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 punto tratamos este tema.
61
233
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 naturalidad 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.
El efecto scrolling permite moverse en una tabla desde una ventana en la pantalla del equipo. 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 diferentes conceptos: ndices, palabras claves, fontica, etc 63 Algunos programadores preguntan: cmo se construye manualmente una tabla de traduccin? 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.
62
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 herramientas de productividad, la tabla de traduccin tiende a desaparecer.
Nme ro de tabla 1 1 1 1 2 2 2 99 99
Cdigo de tem 1 2 3 4 1 2 3 1 2
Te xto a traducir Santiago Valparaso Via del Mar Quilpu azul rojo verde Ciudades Colores
235
4.3. ENFOQUE DE BASES DE DATOS

Se incluye esta seccin debido a las referencias que se hacen en el texto a materias propias del enfoque de bases de datos, un tema ms especializado y directamente 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
Mtodos de acceso a los archivos fsicos
Nivel conceptual
Modelo de datos completo de la base de datos
Nivel externo
Visin de Usuario A 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 cargas, instituciones previsionales, proyectos en los cuales trabaja, renta o departamento 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 requiera preparar al usuario del departamento de personas una vista con: nombre del empleado, proyectos en que labora y departamento al cual pertenece, 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 muchos. 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 muchos 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 muchos. Por ejemplo, entre facturas y artculos, porque pueden haber varios artculos en una factura y un artculo puede estar presente en muchas facturas. Esto es conceptualmente equivalente a tener dos jerarquas: ventasartculos 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 compartidos ) 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 importantes de las bases de datos: redundancia, integracin de datos e independencia 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 normalizacin y en muchos casos redundantes. Tal vez el ideal sera tener las posibilidades de las bases de datos no relacionales pero con la simplicidad de los archivos lineales. Esto es lo que se trata de lograr con la estructura relacional.
237
En el enfoque relacional, tal como su nombre lo indica, se relacionan algunas 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 datos 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 asociativa 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, vertical 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 efectan 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 surgen 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 cumplieron su misin. La eliminacin de la redundancia es una de las principales 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 consistente. El trmino se aplica cuando algunos datos son consecuencia, resultado o estn relacionados con otros, como una sumatoria o la mantencin 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, integridad y recuperacin, tratados en el captulo 2. Veamos un resumen: Seguridad: incluye la privacidad de datos, el anlisis de procedimientos y errores en el diseo. Integridad: es asegurar la consistencia de los datos en todo momento 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, reconstruccin 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
239
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 simultneamente el mismo registro. Son varias las soluciones para este tipo de problemas; 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 datos o de la norma SQL. La idea es que los datos pertenecen a toda la organizacin y no a una aplicacin particular. Bajo este concepto, una aplicacin no modifica directamente los datos, sino que lo hace un intermediario comn a todas las aplicaciones: el sistema administrador de la base de datos a travs de los mecanismos 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 requiere ubicar informacin que est en bases de datos ubicadas en diferentes equipos. Manejo de Bases de Datos remotas: significa manejar datos que se encuentran en bases muy distantes. Esta caracterstica es cada vez ms indispensable y tiene varias consecuencias: implica resolver el problema de la comunicacin 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 SQL
DBMS
DD
DB
DB
DB
Figura 4-7. Enfoque de bases de datos
241
A continuacin veremos cada uno de lo elementos de este enfoque. Administrador de la Base de Datos. Data Base Administrator (DBA), corresponde a una funcin administrativa encargada, entre otras, de las siguientes 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 diferentes 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, descripcin, 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 almacenarse las caractersticas de los datos y sus relaciones, tambin se agregan caractersticas lgicas, formatos predefinidos, cdigo reutilizable y en especial, 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 almacenadas en el diccionario de datos. Lenguaje de manipulacin de datos: Data Manipulation Language (DML), utilizado para actualizar los datos de la base: agregando, modificando 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 este lenguaje se puede hacer un recorrido o una navegacin automtica 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 administrar 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 factores 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 productividad que las organizaciones requieren.
243
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 perfeccionando en el tiempo. Esta es la quinta competencia considerada para apoyar la elaboracin de modelos 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 necesario que el analista sea muy hbil en la orientacin a objetos como parte 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.
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,
245
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 desarrollo de la computacin que comenz en los mismos aos de la Segunda Guerra Mundial con el advenimiento de los primeros computadores en Alemania 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 diseo. Hacia fines de esa dcada ya existan algunas formas de diseo estructurado 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, principalmente va SmallTalk, nos comienza a proveer con algunas herramientas buscadas por largo tiempo: las bibliotecas de clases. Cuntas veces uno implementa la misma funcin de bsqueda, slo porque el tipo de datos cambia?. 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 solamente 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, manteniendo slo un diseo estructurado mejorado para quienes conservaban esa tecnologa en sus instalaciones o se incorporaban tardamente.
247
La orientacin a objetos es muy amplia y permite modelar realidades de diferente 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 9 funciones (n2) M1 Operacin 10 T1 M2 Operacin 11 M3 Operacin 12 M1 Operacin 10 T2 M2 Operacin 11 M3 Operacin 12 M1 Operacin 10 T3 M2 Operacin 11 M3 Operacin 12
Mensaje 12 Mensaje 11 Mensaje 10
Objetos 3 funciones (n) M1 Operacin 10
M2 Operacin 11
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 independientes que se comunican entre s a travs de mensajes, tal como se muestra 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 encapsulamiento 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 funciones, producto de las tres tablas de transacciones que actualizan a 3 tablas maestras. Frente a la misma situacin, en la OO tan slo se requieren 3 funciones, 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 funcionales 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 consultas 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 procesamiento no lo permite en forma eficiente.
249
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 repositorios 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 almacenamiento y el tiempo de uso de procesador. Tpicamente, cada programa incorporaba muchos archivos, tal como se muestra 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 contables y totales de transacciones; por eso la doble flecha en esos archivos maestros. 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: Cobol, Clipper, RPG, C u otro.
Ventas
Artculos
Compras
Actualizacin diaria
Cuentas 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 consuma 5 veces ms tiempo y recursos que la construccin. De hecho, era frecuente que las instalaciones llegaran a su lmite de saturacin, manteniendo
Se conserv la palabra archivo que se usaba en este esquema para referirse a los conjuntos de datos.
64
250
JUAN BRAVO C.
solamente lo urgente, ni siquiera lo importante. Prcticamente no se construan nuevas aplicaciones. Ni siquiera ayudaba que el mismo constructor hiciera la mantencin, porque al poco tiempo olvidaba las sutilezas del programa. Tampoco ayudaba la programacin 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 computacionales 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 construyendo la primera, las siguientes se copian y adaptan. Bajo este esquema, el tiempo de construccin de los pequeos programas de la figura 5-2 probablemente 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 inconsistencias que se generan cuando no se modifican todas las funciones debidas. Adems, cuesta manejar un exceso de pequeas funciones a veces muy parecidas 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 extremo 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 muchos programas pequeos y si eso no era posible, usar la programacin estructurada aplicndola 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 principios de la programacin estructurada.
251
Ventas
1 Actualizar stock
Artculos
3 Actualizar stock
Mermas
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 funciones 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 figura 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 Ventas
Mensaje 1
Cdigo Descripcin Stock 1.- Restar stock
Mermas
Mensaje 1
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 acercarnos 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 organizaciones que adoptan la tecnologa UML
DE
Tiempo
Figura 5-5. Grfico de incorporacin de nuevas tecnologas
La incorporacin de nuevos entrantes es muy lenta al principio, luego se produce una fuerte aceleracin hasta llegar a un alto nivel de entrada de nuevas organizaciones que la adoptan. Finalmente, cuando la tecnologa est totalmente 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.
253
Algunos argumentos pueden ser esclarecedores respecto al xito de la orientacin 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 cambio 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 principales 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 basado 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 existencia 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 observarlos 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.
255
5.2. DEFINICIONES SOBRE ORIENTACIN A OBJETOS

Precisaremos aqu los conceptos bsicos de la OO y algunos trminos asociados 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 ocurrencias 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 Personas Rut Nombre Direccin Ingresar Eliminar Imprimir Objetos Avales Objeto Ventas N documento Rut Ingresar eliminar Instancias de clientes: Juan Prez, Alberto Torres
Clientes
C/E
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 Edward Yourdon. Veremos que en los diagramas finales de diseo hay solamente 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 elementos a los objetos que de ella derivan; por ejemplo, en la figura 5-6 se aprecia que los objetos clientes y avales se derivan de la clase personas y heredan 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 medida, de las reglas de negocio, o lgica que realmente tiene que ver con las necesidades particulares de la aplicacin. Las funciones permiten dar vida a una estructura esttica. Por ejemplo, actualizar el saldo de un inventario 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 indisolublemente 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;
257
por ejemplo, el costo de cada artculo por proveedor en una relacin muchos 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 valorizacin del saldo segn la frmula saldo x costo de un producto del inventario. Tambin puede ser lgica, como cuando se usa una variable global 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 subrayado. 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 observaciones 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 sustantivos para clases y objetos, tales como personas, artculos y documentos; y verbos 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 entidad, 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 Documentos Nombres Direccin Telfono RUT
: numrico largo 9, con signo : numrico largo 6 : alfanumrico largo 30 : alfanumrico largo 35 : alfanumrico largo 15 : 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.
Entidad A Donde B pertenece a A, lo cual da origen a la notacin: A Entidad B 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.
259
Se llega automticamente al hijo pasando por el padre a travs de la relacin 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 automticamente y viceversa. Asimismo con las funciones, cualquier funcin del detalle puede ser activada desde el encabezado y viceversa. El primer atributo de un detalle es la misma clave de la entidad encabezado, as es que no sera necesario anotarla en el objeto de detalle. Esta distincin es vital, porque a nivel de la implementacin significa que no es necesario construir ningn tipo de ndice intermedio, pues todo lo necesario est contenido en los objetos y en su estructura. Considerando lo poderoso de la relacin, es conveniente que un mismo diseador 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 siguiente 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 sistemas administradores de bases de datos y herramientas de productividad. Es tambin una posibilidad mantenerla como una clase o rutina reutilizable.
261
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 forma, 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 incorporadas. Se parece al funcionamiento de una clula, la cual recibe mensajes del exterior y reacciona proporcionando los productos correspondientes, cmo lo hace? Eso es parte de sus funciones incorporadas67.
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 exterior, 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 saber 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.
67
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 funciones 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 generalizacin que no llega a transformarse en tablas, por ejemplo: personas. El objeto representa algo del mundo real que tendr una representacin fsica, por ejemplo, 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 detectado 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 mente, 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 objetos, 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.
263
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 elementos 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 forma de representacin para un ejemplo de clientes. La identificacin del objeto contiene un nombre corto, un nmero y un nemotcnico; en el ejemplo: Clientes, 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 objeto no pueden aplicar procedimientos externos para actuar directamente sobre los datos, por esta razn se habla de ocultamiento de datos (data hiding).
A propsito, es curioso que algunas abstracciones las tenemos inconscientemente en perfeccionamiento 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.
69
264
JUAN BRAVO C.
Clientes 08 CL RUT Nombre Direccin 1. Ingresar datos 2. Obtener informe 3. Consulta
Identificacin
Atributos
Funciones
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 individual 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 modelos 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, nemotcnico, descripcin, fecha de creacin, fecha de expiracin, propietario o condiciones fijas.
265
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 maneras; 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 caracterstica de atomicidad (o descomposicin funcional) porque: Cumple un objetivo preciso y bien acotado; por ejemplo: agregar un cliente, 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 estructura 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, independientemente del valor que tomen sus atributos. Un objeto puede cambiar libremente 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 naturalidad, 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 muchos 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 componentes mnimos de un mensaje son: objeto destino, funcin que activa y parmetros. Los parmetros son los valores y condiciones de entrada que requiere 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 Ventas
Mensaje 1
Cdigo 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.
267
Para efectos de la implementacin del diseo con programacin tradicional, la generacin de un mensaje puede significar la realizacin de una llamada paramtrica a una rutina. En todo caso, su forma final depender de las herramientas 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 funciones 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 necesario 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 intercambiables. 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 comunicacin entre ellos. Significa que disminuyen las interacciones innecesarias 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 permite 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, puede 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 interacciones 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? Consideremos 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.
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 nuestras 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 especialmente conflictivo en las respectivas personas. Del mismo modo, la sanacin de una relacin enferma repercutir favorablemente en cada integrante y en el conjunto.
70
269
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 objetos, como si fuera una herencia. Por ejemplo, si las transacciones del inventario 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 decisiones. El concepto de generalizacin de la orientacin a objetos permite acercarnos 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 elementos. Un objeto hereda siempre todas las caractersticas de la clase. Si hay elementos 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 experiencia para formar una abstraccin. Considerando que la clase es algo abstracto, 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 Einstein 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 rebaja de prstamos a las personas; los atributos comunes son: nmero de documento, RUT del empleado y monto de la transaccin; las funciones comunes son: verificacin de existencia, ingreso, informe y activacin del mensaje 19 sobre la clase empleados al terminar el ingreso de datos.
Descuento de anticipos N documento Rut Monto Ingresar datos Obtener informe C/E Mensaje 19 Empleados Rut Monto Total haber Total descuento 18. Sumar haber 19. Sumar descto C/E Mensaje 19 Rebaja de Prstamos N documento Rut Monto N cuota Ingresar datos 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 de sueldos N documento Rut Monto Ingresar datos Obtener informe
Empleados Rut Monto Total haber Total descuento 18. Sumar haber 19. Sumar descto
C/E Rebaja de prstamos N cuota Mensaje 19
Figura 5-11. Ejemplo de definir una clase de transacciones de sueldos
271
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 extenso 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 corregido quedara solamente con las clases y la tabla de objetos, tal como se muestra en la figura 5-12.
Transacciones de sueldos N documento Rut Monto Ingresar datos Obtener informe C/E Mensaje 18/19
Empleados Rut Monto Total haber Total descuento 18. Sumar haber 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: tomando 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 incorporando 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 contado 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 Fecha Cliente Precio Cantidad Ingresar datos Obtener informe Ventas por mayor Descuento Emitir factura
Emitir boleta Ventas crdito
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 transacciones, 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.
273
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
Objeto
Objeto
Nuevo atributo o funcin
Figura 5-14. Herencia mltiple
Un ejemplo de herencia mltiple a nivel del diseo es el siguiente: en un sistema de ventas necesitamos formar el objeto clientes. Entonces, de la clase personas jurdicas heredamos los datos para formar el objeto. Adicionalmente, requerimos agregar los datos de las personas que hacen contacto con nuestra organizacin comprador, gerente y tesorero, los cuales heredamos desde la clase personas naturales. En este ejemplo, consideraramos a clientes como heredero de la clase principal; 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 eventos (transacciones) van a producir cambios de estado (variacin de atributos) 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 aplicacin: proteccin, en lo que se refiere a privacidad, integridad y recuperacin; 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
275
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 de compras Detalle de compras Proveedores Clientes Encabezado de ventas Detalle de ventas
Artculos Lnea blanca
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 pertenencia 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.
Personas
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 interacciones entre las clases. Se presenta en la figura 5-17, siguiendo el mismo ejemplo de los puntos anteriores.
C/E Mensaje 1
Ingresar transaccin
Personas
C/E Mensajes 4 y 5
Productos
Figura 5-17. Modelo funcional generalizado
Observaciones respecto a la figura 5-17: Se agreg una nueva clase: ingreso de transaccin. sta representa el ingreso de un documento directamente en la pantalla del equipo, tal como si estuviramos llenando una factura.
277
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 diferentes 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 procesamiento 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 de transaccin N documento Fecha Rut persona 1 Agregar 2 Consultar 3 Imprimir

C/E Mensaje 1
Personas Ingreso de transaccin Encabezado, detalle y totales segn formato 1 Aceptar datos 2 Cuadrar totales
C/E
Rut Nombre Direccin Telfono 1 Agregar 2 Consultar 3 Imprimir
Detalle de transaccin N documento Cdigo artculo Costo Cantidad 1 Clculo total
Productos
C/E Mensajes 4 y 5
Cdigo artculo Tipo artculo Descripcin ltimo costo Saldo 1 Agregar 2 Consultar 3 Imprimir 4 Sumar saldo 5 Restar saldo
Figura 5-18. Modelo funcional generalizado y detallado
En la figura 5-18 se puede apreciar que: 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 nuevo 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 funciones generalizadas es tambin una clase en otro nivel de abstraccin.
279
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 trabajando en la modularidad y se busca intercambiar y comercializar clases, sin embargo, todava est en proceso de consolidarse. Mientras tanto, es una excelente 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 componentes 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 Tipo de artculo Descripcin ltimo costo Saldo 1. Crear 2. Consultar 3. Imprimir : numrico largo 5. Es la llave principal : numrico largo 2, asociado a la tabla de traduccin 18 : alfanumrico largo 30 : numrico largo 6 : numrico largo 6, con signo. Si queda negativo, procedimiento normal : se agrega un artculo. Parmetros: los 5 atributos. : presentacin tabular de los datos, bsqueda por cualquier atributo. : sin el costo, con corte de control por tipo de artculo y orden por descripcin en cada tipo. Funcin normal. : suma unidades al saldo y mueve ltimo costo, parmetros: cdigo, unidades y costo. : resta unidades al saldo, parmetros: cdigo y unidades. Si el saldo queda negativo, procedimiento normal.
Tabla de objetos, clase productos Atributos
4. Suma saldo 5. Resta saldo
Objeto Artculos de lnea blanca
Funciones
Figura 5-19. Visin interna de la clase productos
281
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
Objeto Ingreso de ventas Ingreso de compras
Tabla de objetos, clase Ingreso de transaccin Atributos Funciones Indicar stock del producto Deben cuadrar totales, stock mayor a unidades por vender. Mensaje 5 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, deberamos 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 productos 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 funcionalidad 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 funcionamiento pleno. En el captulo 2, acerca de ingeniera de software, dedicamos una seccin al diseo de estas interfaces.
283
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 equipos (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 objeto, 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.
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.
73
284
JUAN BRAVO C.
Es tambin una buena prctica para evitar confundir el contenido con la relacin. 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 incorporada al objeto puede ser realizada utilizando los servicios de una rutina catalogada a travs de una buena parametrizacin o mediante mensajes. Aunque tambin es una alternativa la generacin de cdigo ad-hoc con una herramienta de productividad. La reutilizacin del cdigo tiene en Japn una prioridad tan alta que aproximadamente el 75% de cada aplicacin se construye con componentes reutilizables; en comparacin con el 25% de reutilizacin en Estados Unidos. En el departamento de sistemas de su empresa, qu porcentaje de las aplicaciones 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 programacin, donde cada programa es, a veces, una obra de arte irrepetible, desperdicindose lamentablemente todo el tremendo aprendizaje que el programador obtuvo en ese cdigo, cunta mayor eficiencia podemos lograr al perfeccionar 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 prestigio, que efecte control de calidad de alto nivel para cada funcin aceptada. Incentivos 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 apropiadamente las estrategias, reconociendo de antemano el verdadero esfuerzo de cambio
285
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 rpidamente 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 integradores. Los desarrolladores construyen clases, actividad reservada a los programadores ms hbiles de la instalacin. Los integradores toman las clases y las adaptan para crear objetos de aplicaciones particulares, eventualmente ellos podran completar una aplicacin con muy poca programacin. Esto es muy interesante, porque en la prctica significa que en un equipo de integradores 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 programacin 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, entonces 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 desarrollen y generalicen productos apropiados. Herramientas CASE orientadas al objeto, las que pueden ayudar en el modelamiento 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 incorporando 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 serie 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.
287
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 para analizar los requisitos del sistema y el problema que necesitamos 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, expresin 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 modelos 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 indispensable 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).
289
UML surgi de los aportes combinados de tres pioneros en el campo del modelamiento orientado a objetos, los doctores Grady Booch, Jim Rumbaugh e Ivar Jacobson, a peticin de la OMG (Object Management Group), organizacin 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 modelos 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 sistema: 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 desarrollo. 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
291
1. Casos de uso
Los casos de uso (use case) son los modelos ms conocidos de UML, permiten 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, principalmente 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 seguimos 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 descripcin 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 recomendacin es usarlas, realmente facilitan el trabajo y si el sistema es grande, son indispensables. Adems, tienen la ventaja de generar el cdigo de la aplicacin 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.
293
6.2. APLICACIN DE LOS MODELOS UML EN LA ETAPA DE ANLISIS

El siguiente ejemplo muestra en la prctica el uso simplificado de los principales 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: 1. Diagrama de casos de uso 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
1. Diagrama de casos de uso

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 personas u otros sistemas computacionales identificados con el smbolo tipo dibujo 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 Aprobar cotizacin Ingresar O/C Aprobar O/C Enviar O/C O/C = Orden de Compra Jefe de Adquisiciones
Figura 6-2. Ejemplo de un diagrama de casos de uso
En este diagrama se utilizan dos caractersticas que provienen de la orientacin 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 casos 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 original. Explican Stevens y Pooley (2002, p. 124): Si un caso de uso incorpora dos o ms escenarios con diferencias significativas, pueden ocurrir varias cosas diferentes dependiendo de las circunstancias, se puede decidir que sera ms claro mostrarlos como un caso principal y uno o ms casos
295
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 relacin 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. Permite 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
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 expandido 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 respectivo campo en la interfaz visual, tal como se aprecia en la figura 6-5 (copiada desde el anexo 7).
297
Interfaz de Entrada
C
-
D F

e-Mail
G
Ciudad M
H
Fax
Fono
K N
Precio
L O
Valor Neto
N de O/C.
L.
Cdigo
Descripcin
Cantidad
LL
Cerrada Anulada
W Y
Cerrar X Anular Z
XX
Salir
V
Figura 6-5. Ejemplo de Interfaz visual detallada
4. Modelo conceptual
El modelo conceptual define responsabilidades y el dominio del sistema computacional, al comienzo asociado a los casos de uso identificados. Es un modelo que se va construyendo en paralelo con los casos de uso. Identifica los conceptos ms relevantes del mundo real en el dominio respectivo: roles de personas, tipos de documentos o elementos fsicos. Tambin identifica las asociaciones entre conceptos con palabras de enlace: usa, registra 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 O/C compuesta por se asocia a 1 1..* contiene * existe en 1 existe en * almacena 1 Bodega Productos contiene * existe en 1 Proveedores
Lneas de la O/C
Figura 6-6. Ejemplo de modelo conceptual sistema de compras
En la figura 6-6 se puede apreciar que: 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 gruesa) del modelamiento de datos. En la composicin, tambin llamada unicidad, una lnea de la O/C no puede existir sin su encabezado y viceversa.
299
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 de O/C N O/C Fecha compuesta por
Proveedores Rut Nombre
Lneas de la O/C Unidades Precio
Productos ...
existe en * 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 aplicacin, 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 conceptual. A este nivel de especificacin, la aplicacin sigue siendo como una caja negra 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 productos Ingresar cantidad 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 central de la orientacin a objetos: el encapsulamiento, es decir, un slo todo (clase u objeto) con los atributos y los mtodos. Cuando se trata del primer caso de uso que estamos desarrollando en un sistema, el diagrama de secuencia y la visin dinmica son iguales, desde el segundo 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.
301
Sistema Caso de uso Aprobar cotizacin Ingresar N de cotizacin Dar OK al documento ... Ingresar N de O/C Ingresar cdigo de producto Ingresar cantidad Dar OK a la lnea
Caso de uso Ingresar O/C
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 observa 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 la O/C Introduccin 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 ...
303
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 principales modelos de UML en la etapa de diseo75. Veremos: 1. Diagrama de diseo de clases 2. Diagrama de colaboracin
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 necesarias 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 N O/C Fecha Crear lnea Imprimir compuesta por 1 contiene * existe en 1 Rut Nombre Crear proveed. Modificar Rut Modificar nombre
se asocia a
1..* contiene * existe en 1 existe en almacena

*
Lneas de la O/C Unidades Precio Agregar lnea
Productos ...
Bodega ...
Figura 6-13. Ejemplo de diagrama de diseo de clases
75
Ms detalle en el libro Gestin de proyectos de procesos y tecnologa.
305
2. Diagrama de colaboracin
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 (cd, cant, pre) Terminal del administrativo 1: Crear lnea de O/C (cod, cant, pre) Encabezado de O/C 1.1: Crear (cod, cant, pre) Lneas de la O/C
Figura 6-14. Ejemplo de diagrama de colaboracin
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 caractersticas de la implementacin a nivel del diseo. 77 Se supone la existencia de la biblioteca de clases.
76
306
JUAN BRAVO C.
CAPTULO 7. HERRAMIENTAS DE LA TECNOLOGA DE INFORMACIN
307
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 supuesto, 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 adecuada. 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 sistemas 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 modelos de una solucin de software, tal como se aprecia en la siguiente figura (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 modelamiento y para compartir en equipos de trabajo.
308
JUAN BRAVO C.
En el caso de las herramientas de ayuda en la produccin de software conviene actuar con prudencia, por ah aparecen mensajes del siguiente tipo: es posible que las aplicaciones se construyan casi solas o que el mismo usuario pueda construir su propio software sin depender del programador. Esos y otros mensajes se demuestran con aplicaciones muy pequeas y estructuradas, extrapolndose las conclusiones al resto del software. Sin embargo, siendo vlido, 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 siempre que se pueda integrar al esquema de desarrollo del departamento de sistemas en particular. Para tranquilidad de muchos programadores, hasta hoy no se ha visto el reemplazo de un especialista por una herramienta de productividad. S ocurre que la incorporacin de la nueva herramienta acarrea a veces nuevas contrataciones, 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 tecnologa de informacin. Luego estudiaremos las herramientas de uso especfico, es decir, aqullas orientadas a temas precisos, como procesadores de texto, planillas 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 produccin 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
309
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 computacin ya se percat de este hecho y comenz a desarrollar una amplia variedad 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 lenguajes de cuarta generacin y ms recientemente, se les comenz a llamar herramientas de productividad, nombre que a veces compite con el de herramientas de desarrollo clienteservidor. Independientemente de las denominaciones, las nuevas herramientas incluyen una amplia variedad de nuevos productos: procesadores de texto, planillas electrnicas, administradores de bases de datos, herramientas CASE, Workflow, Groupware y otras. En las siguientes pginas 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 informtica. 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 trabajar 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 equipos 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 llamado 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 producidos en esta quinta generacin sean capaces de aprender de sus errores, reconocer mensajes incompletos, tomar cierto grado de decisiones y crear sus propios 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, motivaciones, 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 suspensivos, porque realmente ignoramos todava su potencial.
311
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 Procesadores de textos Ciclo completo de desarrollo Lenguajes de cuarta Para construccin de generacin De uso especfico aplicaciones Amistosos y Productivos Cdigo compilado o interpretado Bajo nmero de instrucciones
COBOL/FORTRAN/C
Lenguajes de alto nivel
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 probablemente varios miles de instrucciones, producto de la desagregacin con que obliga 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 cercano 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 instrucciones 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 donde reside. Para ser ejecutado, el programa en lenguaje simblico debe ser compilado, obtenindose un programa objeto en lenguaje de mquina que todava es bastante eficiente en cuanto al uso de recursos, porque el programa fuente no est demasiado lejos del programa objeto.
313
3. Lenguajes de alto nivel

Los lenguajes de alto nivel se desarrollaron como respuesta a la excesiva dependencia de la mquina que presentaban los lenguajes simblicos y para evitar 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 sucedi 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 problemas. Por ejemplo, FORTRAN para aplicaciones cientficas y COBOL para aplicaciones 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 fabricante, 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.
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-
78
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 computador (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 interpretacin 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 ejecucin. 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 apertura 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 concentraban 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 importantes 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 especialistas, no exento de un cierto grado de temor y admiracin. Sin embargo, cuando el usuario aprendi a sacar provecho del computador y observ que distrones de programacin; como la programacin estructurada o la programacin prctica (ambas expuestas en el libro Desarrollo de sistemas de informacin, una visin prctica).
315
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 originalmente considerado. Otro problema fue el atraso invisible que se produca cuando los usuarios preferan 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 nuevas 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 incrementar 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 segundas 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 estructurar 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 informacin es la integracin total. Esto significa que todos los productos de la instalacin 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 probando 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 simplicidad, 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 cuaComo ejemplo de esta tendencia, obsrvese la integracin del producto MS Office para Windows, el cual incluye Word, Powerpoint, Excel, Access, Outlook y otras aplicaciones.
79
317
les tendrn incorporadas o poseern buenas interfaces a grficos, planillas electrnicas, procesamiento de imgenes, almacenamiento de voz, procesamiento de texto, transmisin de datos. En lugar de diccionario de datos, comenzaremos a escuchar con mayor frecuencia el trmino enciclopedia, o diccionario 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 apoyar 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 sistemas operativos generalizados, es decir, atravesar horizontalmente las diferentes 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 automticamente o se aplicar cdigo reutilizable. Hoy, sin tener que programar, ya es posible pintar pantallas, generar informes, realizar operaciones de actualizacin entre entidades o efectuar mltiples clculos. Al mismo tiempo, se incrementar 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 compleja, 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, aunque 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 relevancia pueden tener las herramientas de uso especfico sobre el desarrollo de software? 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 mayores potencialidades de las herramientas. Por ejemplo, hoy, con un simple procesador de palabras puede ordenar textos, efectuar clculos, imprimir etiquetas 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 directamente en la produccin de software a travs de la automatizacin de las variadas y rutinarias labores asociadas a la produccin de software, por ejemplo: pintar una pantalla, ordenar una tabla, comunicar informacin, realizar seguimiento del proyecto, modelar los datos y comunicar el modelo a una base de datos. Veremos: 1. Herramientas integradas para automatizacin de oficinas 2. Groupware 3. Workflow
319
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 sistemas computacionales con personal especializado, quienes pueden ahora destinar 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 interactuar con bases de datos, sino tambin para desarrollar.
2. Groupware
Durante este perodo tambin surgieron las herramientas para trabajo de grupo, 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 coordine para obtener promedios grupales de ponderacin de factores de decisin, los que antes dependan slo de la buena fe de algn profesional aislado.
Impresiona que antes de este tipo de procesadores debamos construir algn pequeo sistema 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.
80
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 actividades realizadas por diferentes personas en distintas unidades organizacionales. 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 automatizar el proceso, con o sin una herramienta Workflow, se evaluaran otras opciones, por ejemplo82: Eliminar o externalizar el proceso completo. Agrupar todas las actividades para que las realice una sola persona (concepto 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 realice en la misma ubicacin. Con las herramientas tipo Workflow se tiende a eliminar los documentos manuales y hacer todo el trabajo directamente en el computador. Por ejemplo, operaciones 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.
321
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 necesaria 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 transaccional, 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 cuales 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 transacciones operacionales de la organizacin, por ejemplo: cotizaciones, pedidos, compras, produccin, distribucin, facturacin, contabilidad, personas y cobranza. 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 proveedores (SRM).
4. CRM
Los productos CRM (Customer Relationship Management, en espaol, gestin de la relacin con los clientes) ayudan en la integracin con clientes proporcionando un entorno tecnolgico para una relacin ms personalizada (observan 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 manifiesta en el marketing relacional.
323
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 electrnico 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 software, tambin llamados productos orientados a la construccin de sistemas computacionales, 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 computacional) son un soporte automtico o semiautomtico para los mtodos de desarrollo de software; una definicin ms amplia podra ser: las herramientas CASE ayudan 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 problema 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 disponibilidad 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
325
desarrollar. Sin embargo, se han encontrado con las dificultades propias del desarrollo 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 computacional, 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 coordinar 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 Upper CASE Lower CASE
Etapas que apoya Definicin de requerimientos de Diseo 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 diagramas 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 administrador 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 correcciones 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:
327
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 lenguaje 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 para: manejar tablas, administrar una bitcora de uso de la aplicacin, inicializar 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 funciones. Ejemplos de lenguajes en esta categora son Synon/2, Genexus, Genial83, 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 integradas 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 aplicaciones computacionales: actualizaciones, clculos o informes con diferentes cortes de control. En estos casos, habitualmente es necesario programar esas funciones usando algn lenguaje de alto nivel del SABD, ya sea husped 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 Bravo/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, calculadora, 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 requiere un proceso de interpretacin, aunque no de instrucciones fuentes, sino de las tablas del software. Ante un requerimiento del usuario, el cdigo reutilizable hace uso del diccionario de referencias para manipular o seleccionar informacin 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 adicionando 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
329
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 funciones 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 intervenidos. 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 aplicacin: 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 rpidamente 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 descentralizada de aplicaciones. El esquema tpico son grandes instalaciones con un departamento de sistemas centralizado que no alcanza a atender los requerimientos 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 empleados. 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 desarrollo 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 herramientas de productividad tipo cliente servidor estn muy orientadas hacia especialistas 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 programadores 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 desarrollo 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.
331
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 usados. 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 usuario, sino que el cliente de la organizacin), porque la nueva visin de la totalidad 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 modelos 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 organizacin y para todas las etapas de un proyecto, no slo el mbito tecnolgico. Eficientar el diseo con herramientas de productividad y criterios de modelamiento tal como el curso normal de los eventos y otros que provee la visin sistmica. Aplicar normas de calidad: CMM, ISO 9000, Tick IT Alinear el desarrollo de software con las verdaderas necesidades del negocio, esto significa alinear con la estrategia de la organizacin y verdaderamente 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. ~~
333
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 departamentales 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 preparar a su organizacin para ser receptiva al cambio. Debera permitir que la empresa absorba los golpes del medio, se detenga, prepare bien una respuesta y reaccione con mucha fuerza para lograr sobrevivir85.
Este es un resumen acerca de estrategia desde el libro Planificacin sistmica. 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.
85
84
334
JUAN BRAVO C.
El objetivo de la Planificacin Estratgica (PE) es ayudar a obtener una visin 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 superior, 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 crticos del xito Sistemas de Informacin Gerenciales
Definicin del negocio
Destino de la organizacin
Mediciones
Figura A1-1. Esquema de planificacin estratgica
En la figura A1-1 podemos apreciar una visin de conjunto del esquema propuesto. 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 mediciones estables, confiables, oportunas y permanentes. Adems, debemos considerar 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
335
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 tiene verdaderos objetivos. Para definir el negocio es indispensable efectuar un estudio iterativo y retroalimentado (en el sentido de construir borradores sucesivos) sobre los siguientes temas: Introspeccin: es un escrutinio interno destinado a conocer nuestras fortalezas y debilidades, compararlas con las de la competencia y as perfeccionar 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 aprendimos en el colegio, donde nos gastbamos todo el tiempo en llevar las debilidades a un punto de rendimiento medio y las fortalezas quedaban abandonadas. 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 diferenciamos? 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 diferenciacin 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 desarrollar en el sistema del que formamos parte, aquella funcin donde otorgamos 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 mayoristas, centro naturista de atencin al pblico o asesoras en planificacin estratgica 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, distinta de las personas que la componen, aunque en el largo plazo se produce cierta similitud. Es decir, tanto la organizacin como sus integrantes comienzan a tener conductas parecidas. Los valores se expresan prioritariamente 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 satisfaccin 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 financian 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 proveedores necesitan conocernos para entender nuestras necesidades, requieren pagos puntuales, una relacin comercial fluida, niveles de calidad establecidos de comn acuerdo. Sealando explcitamente un conjunto de creencias, principios ticos y modalidades de gestin. Cules son las condiciones del trato entre las personas? Cmo se manejan temas claves (disciplina, anticipacin, comunicacin interpersonal)? Qu sucede con el fomento a la creatividad e innovaciones? La emocin del negocio es una fuente para la motivacin de todas las personas de la organizacin y el principal alimento del lder. Surge de nuestros sueos, de identificar la necesidad social concreta que estamos satisfaciendo: abrigo, alimentacin o consejera. Es el nexo que nos une con el entorno, 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
337
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 Henry 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 supermercados 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 comparaciones 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 buenas intenciones. Existen previsiones a la cantidad de aos que uno desee, aunque generalmente se hace una distincin entre objetivos de corto, mediano y largo plazo, 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 diferentes 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 directamente de la misin de la empresa y deben ser considerados en la toma de decisiones de la alta gerencia; representan un filtro en la cantidad de informacin 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 siguientes 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 industria, 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 instalaciones importantes o la renuncia de un empleado clave. Situaciones programadas, como el desarrollo de una meta; por ejemplo, la nueva organizacin de la empresa.
339
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 perfeccionamiento del personal. Al dejarlo as no pasa de ser una bonita declaracin, sin embargo, para que se transforme en una realidad, es necesario agregarle un ndice; por ejemplo, horas de capacitacin anual por empleado. Ahora podemos hablar en concreto: cuntas horas estamos capacitando hoy a nuestro personal y a cuntas queremos llegar? Otro ejemplo es el de una empresa de confecciones que se plantea por objetivo 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, financieros, infraestructura, conocimiento o herramientas de software. Los sistemas de informacin gerenciales son procesos claramente identificables, 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 grupos 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 prevenidos es estar armados.
341
ANEXO 2. ALINEAR INTERESES

Existe la necesidad de negociar intereses, porque las personas y organizaciones 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 buscar 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, aprendiendo 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 gerencia y exige mucha fortaleza y habilidad, porque muchos grupos le exigirn justas demandas (para ellos) y algunos gritarn ms que otros: mayores utilidades!, 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 personas ms preparadas de la organizacin estaran obteniendo mayores beneficios 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 (principalmente ellos mismos a travs de los fondos de pensiones) para obtener mejores 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 produccin 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 reparaciones de maquinarias y de una u otra forma, siempre hay mucho trabajo en lugar de pagar por su buen funcionamiento. Otro caso es nuestra interaccin con los mdicos en algunos tipos de programas. 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 resultado 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 medida que haya ms gente sana. Eso es alinear intereses. Por ejemplo, en la prevencin de riesgos a quien o a qu grupo le puede convenir 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 segundo, 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.
343
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 ejemplo, 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 conviene que haya muchos equipos malos. Si el objetivo del equipo de mantencin fuera obtener ingresos por tener los equipos en ptimo estado de funcionamiento, tendramos las misiones alineadas e incentivaramos la mantencin 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 tcnicos un premio mensual extra de US$ 10.000 a repartirse en el grupo, a condicin 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 demasiado 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, tambin 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 aproximacin 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 proyecto 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 pretende avanzar en cada etapa con todos los requerimientos a la vez, en consecuencia, recin se ven resultados al trmino del proyecto, tal vez un ao en el caso de proyectos medianos.
345
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 relativamente pequeo del total de requerimientos. Al trmino del proyecto (despus de todos los ciclos) se recomienda incorporar 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 deteccin 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.
347
Causas Procesos
Especializacin Forma obsoleta
Efecto Personas
Rotacin Motivacin Preparacin
Falta directriz Comunicar
No participacin Falta rea
Falta Tecnologa Obsoleta
Insatisfaccin de clientes debido a excesiva duracin del proceso (49 minutos)
Estrategia
Estructura
Tecnologa
Figura A4-1. Ejemplo de grfico de Ishikawa
Se priorizan y grafican de mayor a menor impacto segn el porcentaje asignado, 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 relevantes, los pocos crticos. El grfico tiene la siguiente forma, donde la columna ms a la derecha tiene el acumulado de las causas anteriores ms la nueva. El nivel de profundidad al cual se llega tiene que ver con la tcnica de desarrollo 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 prescripciones de medicamentos incorrectas por ao, 500 operaciones quirrgicas incorrectas 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 proponer 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 operativos. 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 Informacin (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 factible. Cul es el proceso perfecto89? (Puede ser de todo el mbito). 5. Explicar oportunidades de mejora y sealarlas en un nuevo FI. Cmo quedan 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, reconocido 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 pensamiento es un poder real y segundo, que os permite transportaros al futuro y vivirlo con anticipacin. 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.
349
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 llamamos 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, entrenamiento 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 obtiene 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 construccin, 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 documentacin de los productos de software. 5. Verificacin de la calidad. Siendo la calidad uno de los ms graves problemas de la construccin tradicional de software, se propone incluir indicadores 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 funcionamiento real. Mayor informacin puede encontrarse en www.omg.org, www.rational.com, www.uml.com y otros sitios relacionados.
351
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)
Proyeccin ventas
Adquisiciones
Ventas
Servicio postventa
Macroprocesos
Primer Flujograma de Informacin

RECEPCIN POR COMPRAS DESPACHO POR VENTAS
Procesos operativos
Devoluciones
Devoluciones
Bibliografa: Esta presentacin se basa principalmente en el libro Applying UML and Patterns de Craig Larman - 1998 (Prentice Hall) ISBN 0-13-748880-7
Bibliografa: Adicionalmente, esta presentacin se basa en la serie de libros de gestin, anlisis y sistemas de Juan Bravo C. que incluye, entre otros, a: Gestin de Procesos (2005) y gestin de proyectos de procesos y tecnologa (2006).

Flujograma : Proceso de Recepcin de Productos de Proveedores - (Gua Interna de Recepcin por Compra) Encargado de Recepcin
3 G/D 1 Proveed. 2 G/D 1 Proveed. 2 3
353
Proveedor
Control de Calidad
Inventario (Bodega)
Depto. de Compras
Depto. de Contabilidad
Ingresar Gua de Recepcin

3
G/R 1 Interna
G/R 3 Interna
3
G/R 1 Interna
Verificar Calidad de Productos
Nota: Un determinado documento (papel o electrnico) puede ser cambiado (por ejemplo: VB, firma, tick) ... para indicar algn tipo de accin que se ha tomado con l - tal como: revisin, aprobacin, etc -. Con ello, aunque el documento sigue siendo el mismo, ya no es el mismo. Se indica grficamente esta situacin por medio de cremillas, que se incrementan, como se muestra en este flujograma para diversos pasos que sigue la copia # 2 de la Gua de Recepcin.
G/D 3 Proveed.
G/D 1 Proveed.
3 2
G/R 2 Interna
Ingresar Productos a Bodega
G/R 2 Interna
Casos de Uso: Crear Guas Internas de Recepcin por Compra y de Despacho por Venta (Productos con registro persistente)
Ref. # 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 Funcin
Funciones Bsicas
(Base Craig Larman)
Categora evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente oculta oculta
Capturar y activar opciones desde un Men de Opciones, aceptar Opcin (Seleccin Manual). Desplegar la Interfaz de Creacin de Gua de Recepcin, N de Gua de Recepcin (correlativo) y Fecha de la Transaccin, - aceptar eventual modificacin de Fecha (Ingreso Manual). Capturar el Cdigo del Encargado de Recepcin (Ingreso Manual). Desplegar datos del Encargado de Recepcin registrados en almacenamiento persistente. Capturar la informacin del Proveedor usando el RUT (Ingreso Manual) y desplegar datos pertinentes del Proveedor registrados en almacenamiento persistente. Capturar N de Gua de Despacho del Proveedor (Ingreso Manual), verificar validez (No Existencia previa) y desplegarlo. Capturar Fecha (Propia) de Gua de Despacho del Proveedor (Ingreso Manual) y desplegarla. Capturar/Verificar (C/E) N de Orden de Compra (Ingreso Manual) y desplegarlo. Registrar la transaccin en proceso: los Productos a recibir. Capturar la informacin del Producto a recibir usando el Cdigo (interno) (Ingreso Manual). Desplegar la descripcin del Producto registrado en almacenamiento persistente. Capturar el Costo (Precio del Proveedor) del Producto (Ingreso manual) y desplegarlo. Capturar la Cantidad de unidades del Producto respectivo (Ingreso manual). y calcular valor de la lnea actualizando los totales de la Gua de Recepcin en la Interfaz al dar OK a la lnea. Grabar en el Detalle de la Gua de Recepcin (lnea a lnea) los datos de cada lnea a medida que se completa y calcula cada una de ellas. Actualizar los valores de existencia y recibido de Productos (evitando doble actualizacin) al 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
Casos de Uso: Crear Guas Internas de Recepcin por Compra y de Despacho por Venta (Productos con registro persistente)
Ref. # R1.15 R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8 R2.9 R2.10 R2.11 R2.12 R2.13 Funcin Ofrecer un mecanismo de almacenamiento persistente.
JUAN BRAVO C.
Funciones Bsicas
(Base Craig Larman)
Categora oculta evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente oculta oculta
Desplegar la Interfaz de Creacin de Gua de Despacho, N de Gua de Despacho (correlativo) y Fecha de la Transaccin, - aceptar eventual modificacin de Fecha - (Ingreso Manual). Capturar el Cdigo del Encargado de Despacho (Ingreso Manual). Desplegar datos del Encargado de Despacho registrados en almacenamiento persistente. Capturar la informacin del Cliente usando el RUT (Ingreso Manual) y desplegar datos pertinentes del Cliente registrados en almacenamiento persistente. Capturar N de Nota de Venta del Cliente (Ingreso Manual), verificar validez (No Existencia previa) y desplegarlo. Capturar Fecha (Propia) de Nota de Venta del Cliente (Ingreso Manual) y desplegarla. Capturar/Verificar Condicin de Pago de la Venta (Ingreso Manual) y desplegarla. Registrar la transaccin en proceso: los Productos a despachar. Capturar la informacin del Producto a despachar usando el Cdigo (interno) (Ingreso Manual). Desplegar la descripcin del Producto registrado en almacenamiento persistente. Capturar el Precio al Cliente del Producto (Ingreso manual) y desplegarlo. Capturar la Cantidad de unidades del Producto respectivo (Ingreso manual). y calcular valor de la lnea actualizando los totales de la Gua de Despacho en la Interfaz al dar OK a la lnea. Grabar en el Detalle de la Gua de Despacho (lnea a lnea) los datos de cada lnea a medida que se completa y calcula cada una de ellas. Actualizar los valores de existencia y despachado de Productos (evitando doble actualizacin) 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. # R1.5 Funcin Capturar la informacin del Proveedor usando el RUT y desplegar sus datos. Categora evidente Atributo Tiempo de respuesta Interfaz Restriccin mx. 2 segundos Estilo Windows En colores y efectos 3D R1.12 Capturar la Cantidad de unidades del Producto respectivo y calcular valor de la lnea actualizando los totales de la Gua de Recepcin en la Interfaz al dar OK a la lnea. Ofrecer un mecanismo de almacenamiento persistente. evidente Tiempo de respuesta mx. 2 segundos Categora obligatoria obligatoria opcional obligatoria
R1.15
oculta
Plataforma
Usar base de datos corporativa actualmente instalada
obligatoria
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).
355
Diagrama de Casos de Uso

(Casos de Uso Bsicos) (Base Craig Larman)
Nota: Para ejemplificar el mtodo de Desarrollo en espiral, se estara 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 Recepcin por Compra
Nota: Administrador, Encargado de Recepcin, Encargado de Despacho... son roles que juegan las personas de la Organizacin. (No necesariamente son tres personas distintas).
Encargado de Recepcin (Empleado)
Crear Gua Interna de Despacho por Venta
Proveedor
Iniciar Sistema de Bodegas

Cliente
Encargado de Despacho (Empleado)
Administrar Sistema de Bodega de Recepcin y Despacho
Realizar procesos de Fin de Da

Nota: Administrar Sistema ... Son Casos de Uso Genricos que en el transcurso del anlisis se desagregaran en otros Casos de Uso.
Administrador (Empleado)
Caso de Uso: Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Caso de Uso de Alto Nivel

Terminal Recepcin
Crear Gua Interna de Recepcin por Compra

Caso de Uso: Crear Gua Interna de Recepcin por Compra. Actores: Proveedor, Encargado de Recepcin. Tipo: Primario.
Encargado de Recepcin (Empleado) Proveedor
Comentarios relevantes : 1) Se trata de una transaccin entre dos entidades, (con Proveedor y Encargado de Recepcin). 2) Se trata de una transaccin que implica una entrega / recepcin de Productos. 3) Existe un Registro de Proveedores. 4) Existe un Registro de Encargados de Recepcin (Empleado). 5) Existe un Registro de Productos. 6) Se lleva un registro persistente de la transaccin.
Nota: Descripcin - Sigue la narrativa que se desprende del Flujograma de Informacin correspondiente -.
Descripcin: Este Caso de Uso comienza cuando un Proveedor llega con mercadera acompaando la documentacin legal de rigor. El Encargado registra el ingreso de la mercadera, emite la Gua Interna de Recepcin por Compra, firma toda la documentacin, entrega las copias pertinentes al Proveedor y enva las restantes copias a sus respectivos destinos. El Proveedor se retira, con lo cual termina el Caso de Uso.
Nota: El inicio y el fin del Caso de Uso deberan estar inequvocamente indicados en la narrativa. Ello evita las superposiciones y ambigedades en las especificaciones.
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 Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Caso de Uso Expandido
Nota : (Craig Larman, 2.7.2, pg. 26) Los Casos de Uso Expandidos son extensas narrativas de descripcin de un proceso - pueden contener cientos de frases - . Ver tambin: (Craig Larman, 6.3.2, pg. 50). Encargado de Recepcin
Terminal Recepcin
Crear Gua Interna de Recepcin por Compras
Caso de Uso : Crear Gua Interna de Recepcin por Compra Actores : Propsito: Resumen:
Proveedor
Proveedor (Iniciador) , Encargado de Recepcin (Actor Primario). Capturar Datos de Recepcin de Productos Comprados. Este Caso de Uso comienza cuando un Proveedor contacta a un Encargado de Recepcin para solicitarle que reciba los Productos que est entregando, la Transaccin requerida la documenta con una Gua de Despacho o Factura. El Encargado de Recepcin verifica la entrega fsica (Cantidad y Estado General) contra lo indicado 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 respectivos destinos las restantes copias tambin firmadas (segn Flujograma de Informacin correspondiente). El Caso de Uso termina cuando el Proveedor se retira. Primario y real.
Tipo:
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 comprende desde la Hoja actual hasta las siguientes 4 Hojas (5 en total)
Caso de Uso: (Expandido) Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman ) Curso Normal de los Eventos
Accin de los actores
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). 4. El Encargado de Recepcin verifica visualmente el N de Gua de Recepcin y Fecha ofrecidos por el sistema y a continuacin ingresa su identificacin (Cdigo) en C. 6. El Encargado de Recepcin ingresa en E el RUT del Proveedor y verifica los datos del mismo desplegados por el sistema. 8. El Encargado de Recepcin ingresa en M, N y O respectivamente el N de Gua de Despacho del Proveedor, la Fecha de la Gua de Despacho y el 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. 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. 14. Al terminar de ingresar los Productos, el Encargado de Recepcin oprime el botn V para indicar al sistema el fin de la captura de datos. 16. El Encargado de Recepcin cierra la interfaz de Transaccin oprimiendo el botn XX para volver al Men de Opciones y entrega o enva una copia de la Transaccin terminada al Proveedor por la va de comunicacin preestablecida. (Notificacin de cumplimiento del compromiso). Opcionalmente vuelve a oprimir (Tab) para ingresar otra recepcin, con lo cual el sistema pasa a 3.
Respuestas del Sistema
3. El sistema despliega la interfaz de Creacin de Gua de Recepcin, asigna y despliega automticamente en A el N de Gua de Recepcin correlativo correspondiente y en B la fecha del sistema. 5. El sistema obtiene y despliega el nombre del Encargado de Recepcin en D. 7. El sistema despliega los datos bsicos del Proveedor (Razn Social, Direccin, e-Mail, Comuna, Ciudad, Telfono, Fax) en F, G, H, I, J, K y L respectivamente. 9. El sistema verifica la validez / existencia del N de la Orden de Compra. 11. El sistema despliega el N de Lnea en LL, obtiene y despliega la descripcin del Producto en Q.
13. El sistema calcula el valor de la lnea ingresada y lo acumula, desplegando los valores en T y U, a la vez que graba la lnea recin completada. 15. El sistema calcula los valores subtotales / total y los despliega / redespliega en los campos T y U, adems actualiza los datos de la transaccin en el sistema de almacenamiento persistente. Calcula el costo promedio y lo actualiza Genera un original y 2 copias de la transaccin realizada utilizando la interfaz de salida indicada. Limpia la interfaz de entrada y posiciona el cursor en A.
357
Caso de Uso: (Expandido) Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Interfaz de Entrada
C
-
D F

e-Mail
G
Ciudad M
H
Fax
Fono
K N
Precio
L O
Valor Neto
N de O/C.
L.
Cdigo
Descripcin
Cantidad
LL
Cerrada Anulada
W Y
Cerrar X Anular Z
XX
Salir
V
Caso de Uso: (Expandido) Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (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:

( para desarrollar en vueltas futuras de la espiral) Curso Normal 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
Nota: Se indican algunas de las excepciones posibles nicamente a modo de ejemplo.
358
Caso de Uso (Expandido): Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
JUAN BRAVO C.
Interfaz de Salida
Gua de Recepcin N
RUT Proveedor 999.999.999 - X XXXXXXX
XXXXXXX e-Mail XXXXXXX XXXXXXX XXXXXXX
999.999 Fecha
99/99/9999
Encargado Recepcin
XXXXXXX
Razn Social Proveedor Direccin Proveedor Comuna

XXXXXXX
Ciudad
Telfono 99/99/9999
Fax
XXXXXXX
N G/D del Proveedor
999.999
Fecha G/D Proveedor
N de O/C.
999.999 Cantidad 9999 Valor Neto 999999,99
L. 99
Cdigo XXXXXXX
Descripcin XXXXXXXXXXXX
Precio 9999,99
Firma Autorizada y Timbre
Total Neto
99999999,99
Modelo Conceptual (simplificado) Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Nota : En este modelo se consideran los conceptos mnimos. En un anlisis y desarrollo posteriores se podran incluir conceptos tales como Bodega, Terminal, Empresa, etc. Por lo contrario, se podran excluir : Empleados, Ordenes de Compra. Encabezado de Gua Interna de Recepcin por Compra N de Gua Fecha Proveedor Nombre
* Empleados
Cdigo Nombre
* * Proveedores
RUT Nombre Direccin
1 1..5
Detalle de Gua Interna de Recepcin por Compra Descripcin Costo Cantidad
Nota: La flecha gruesa entre el Encabezado y el Detalle indica una Relacin de Pertenencia. (Base Juan Bravo C.La Nueva Visin... pg 200)
* Productos
Cdigo Descripcin Costo
Ordenes de Compra
N OC Fecha
Nota: Segn Craig Larman (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, asociaciones y atributos del mundo real, no se trata de un modelo de software.
Nota: Dentro de los requerimientos, no necesariamente se encuentra el concepto de Orden de Compra. (Puede ser un ingreso manual).
359
Diagrama de Diseo de Clases (Borrador inicial) Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Nota: Segn Craig Larman (21.3, pg.257): Si bien la presentacin de los diagramas de clases es posterior a la creacin de los diagramas de interaccin, en la prctica usualmente se crean en paralelo. Muchas clases, mtodos y relaciones pueden bosquejarse tempranamente en la etapa de Diseo
Encabezado de Gua Interna de Recepcin por Compra

RUT Proveedor N de Gua Proveedor N Gua Interna Fecha Recepcin Cdigo Enc. Recepcin Fecha Gua Proveedor N de Ord. de Compra total()
Nota: A diferencia del Modelo Conceptual, que muestra atributos tiles para entender los conceptos del contexto, se descubri - observando la interfaz de entrada -, la conveniencia de agregar otros atributos al encabezado. (A su vez se elimin : Nombre)
* * Proveedores 1
RUT Nombre Direccin validarRut()
Empleados
Cdigo Nombre
* 1
1 1..5 Detalle de Gua Interna de Recepcin por Compra

Descripcin Costo Cantidad subtotal()
Nota: Segn Craig Larman (21.8.4 a 21.8.8 - pgs.262 - 264) Salvo casos especficos, es conveniente omitir los mtodos : crear(), modificar(), eliminar() y consultar() en los diagramas de clases dado que no agregan valor y aumentan el ruido - se consideran implcitos -
* Productos
Cdigo Descipcin Costo costoProm()
Ordenes de Compra
N OC Fecha
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 (Productos con registro persistente) (Base Craig Larman)
Caso de Uso: Crear Gua de Recepcin ( Curso Normal de los Eventos) Obtener / Ingresar(Tab) N de Gua Recepcin y Fecha sistema, verificar correlativo y fecha. Ingresar Cdigo del Empleado y obtener / verificar el nombre del mismo. Ingresar RUT del Proveedor y obtener / verificar los datos del mismo. Ingresar datos de G/D Proveedor ( N Gua, Fecha, N O/C ) Para cada lnea: Ingresar el Cdigo del Producto Obtener / Verificar datos del Producto Ingresar precio y cantidad del Producto Dar OK a la lnea (Grabar) Al terminar: Dar OK a la Transaccin (Grabar) Salir al Men
Versin en Lenguaje Natural :Sistema
Encargado de Recepcin
Ingresar a la Opcin del Men Desplegar la Interfaz Crear la Gua de Recepcin Ingresar Cdigo del Empleado en Encabezado Ingresar RUT del Proveedor en Encabezado Ingresar N Gua Proveedor, Fecha y N O/C en Encabezado Ingresar Cdigo del Producto en Lnea Detalle Reiterar hasta que no haya ms Productos que ingresar Ingresar Precio y Cantidad del Producto Dar OK a la Lnea de Detalle Calcular la Lnea de Detalle Dar OK al Final para Terminar la Creacin Salir al Men
360
Diagrama de Secuencia del Sistema Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Caso de Uso: Crear Gua de Recepcin ( Curso Normal de los Eventos) Obtener / Ingresar(Tab) N de Gua Recepcin y Fecha sistema, verificar correlativo y fecha. Ingresar Cdigo del Empleado y obtener / verificar el nombre del mismo. Ingresar RUT del Proveedor y obtener / verificar los datos del mismo. Ingresar datos de G/D Proveedor ( N Gua, Fecha, N O/C ) Para cada lnea: Ingresar el Cdigo del Producto Obtener / Verificar datos del Producto Ingresar precio y cantidad del Producto Dar OK a la lnea (Grabar) Al terminar: Dar OK a la Transaccin (Grabar) Salir al Men
JUAN BRAVO C.
Versin llamando los Eventos por su Nombre

( equivalente a Operaciones del sistema)
:Sistema
Encargado de Recepcin
ingresarOpcin(CrearGuiaRecepcion) desplegar(NumGuiaRecCom, FechaR) crearEncabezado(NumGuiaRecCom, FechaR) ingresarCodEmpleado(CodigoEmpleado) ingresarRutProveedor(RutProveedor) ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC) ingresarCodProducto(CodigoProducto) Reiterar hasta que no haya ms Productos que ingresar ingresarPrecioCantidad(Precio,Cantidad) grabarLnea() calcularTotales() terminarTransaccin() salirAMen()
Nota: desplegar es subordinado de
ingresarOpcion y no es invocado por el actor en forma directa.
Nota: calcularTotales es subordinado

de grabarLnea y no es invocado por el actor en forma directa.
Operaciones del Sistema Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman) Visin Dinmica del Sistema Sistema
ingresarOpcin(CrearGuiaRecepcion) desplegar(NumGuiaRecCom, FechaR) crearEncabezado(NumGuiaRecCom, FechaR) crearEncabezado(NumGuiaRecCom, FechaR) ingresarCodEmpleado(CodigoEmpleado) ingresarRutProveedor(RutProveedor) ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC) ingresarCodProducto(CodigoProducto) ingresarPrecioCantidad(Precio,Cantidad) grabarLnea() calcularTotales() terminarTransaccin() salirAMenu()
361
Contratos: Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Contrato
Nombre: Responsabilidades: ingresarOpcion(CrearGuiaRecepcion) Aceptar (Click) en la opcin del Men. Obtener el siguiente N de Gua correlativo (NumGuiaRecCom). Obtener la fecha del sistema (FechaR) . Usar ambos parmetros para invocar el despliegue de la interfaz de CrearGuiaRecepcin Sistema R1.1 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. N/A N/A El sistema tiene el Men y la opcin Crear Gua de Recepcin por Compra requerida instalados y activos.Adems conoce y tiene acceso a EncGuiaRecCompra.NumGuiaRecCom
Tipo: Referencias cruzadas: Notas:

Nota:
Los nombres de elementos usados en los contratos hacen referencia al Diagrama de Secuencia de pg. 18, al Modelo de Clases de pg. N 38 y al Modelo Funcional de pg. N 39.
Excepciones: Salida: Precondiciones:
Postcondiciones: Se acept (Click) en el Men de Opciones. Nota: Obtener Fecha del sistema y obtener N de Gua correlativo son operaciones (mtodos) que no son evidentes para el usuario en este momento, 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 Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman)
Contrato
Nombre: Responsabilidades: desplegar(NumGuiaRecCom, FechaR) Desplegar la Interfaz de Creacin de Gua de Recepcin. Aceptar (Tab) para iniciar el ingreso de la transaccin. Desplegar NumGuiaRecCom, desplegar FechaR, opcionalmente aceptar modificacin manual de la fecha. Sistema R1.2 Esta operacin es invocada por ingresarOpcion. El Empleado oprime (Tab) para iniciar el ingreso. N/A N/A

Nota:
El sistema tiene el Men y la opcin Crear Gua de Recepcin por Compra requerida instalados y activos. Tiene disponibles a NumGuiaRecCom y FechaR. 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.
Contrato
Nombre: Responsabilidades: crearGuiaRecCompra(NumGuiaRecCom, FechaR) Crear instancias de EncGuiaRecCompra y DetGuiaRecCompra y establecer las asociaciones necesarias entre Terminal, EncGuiaRecCompra y DetGuiaRecCompra Sistema R1.15 El Empleado oprime (Tab) para cambiar de campo en la interfaz para el ingreso. Opcionalmente usa el mouse N/A N/A El sistema tiene el Men, la opcin Crear Gua de Recepcin por Compra y la interfaz correspondiente requerida instalados y activos.

Nota:
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
Contrato
Nombre: Responsabilidades: ingresarCodEmpleado(CodigoEmpleado) 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. Sistema R1.3, R1.4, R1.15 Usar Base de Datos MS Access y (Tab) para sucesivos campos Error en ingreso manual del Cdigo o Cdigo no registrado N/A El sistema conoce a Empleados.CodigoEmpleado (Registrado oportunamente con anterioridad)
Tipo: Referencias cruzadas:

Nota:
Notas: Excepciones: Salida: Precondiciones:
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 (modificacin 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
363
Contrato
Nombre: Responsabilidades: ingresarRutProveedor(RutProveedor) Aceptar el ingreso de RutProveedor, por su intermedio, obtener y desplegar los Datos del Proveedor registrados en el sistema de almacenamiento persistente. A continuacin posicionar el cursor en el campo M. Sistema R1.5, R1.15 Usar Base de Datos MS Access - el Encargado de Recepcin oprime (Tab) para pasar a los sucesivos campos Error en ingreso manual del RUT o RUT no registrado N/A El sistema conoce a Proveedores.RutProveedor (Registrado oportunamente con anterioridad)
Tipo: Referencias cruzadas:

Nota:
Notas: Excepciones: Salida: Precondiciones:
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
Contratos: Crear Gua Interna de Recepcin por Compra (Productos con registro persistente) (Base Craig Larman) Nombre:
Responsabilidades:
Contrato
ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC) Aceptar el ingreso de NumGDP, FecGD, NumOC, eventualmente verificar existencia del N de Orden de Compra registrada en el sistema de almacenamiento persistente. A continuacin posicionar el cursor en el campo P. Sistema R1.6, R1.7 y R1.8, R1.15 Usar Base de Datos MS Access - el Encargado de Recepcin oprime (Tab) para pasar a los sucesivos campos N/A N/A
Tipo:
Nota:
Referencias cruzadas: Notas: Excepciones: Salida: 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 EncOrdCompra 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.
Contrato
Nombre: Responsabilidades: ingresarCodProducto(CodigoProducto) Aceptar el ingreso de CodigoProducto. Basado en CodigoProducto, obtener y desplegar los Datos del Producto registrados en el sistema de almacenamiento persistente. Al oprimir (Tab) - fin de ingreso de CodigoProducto - asignar Nmero correlativo a la Instancia de DetGuaRecCompra.NumLinea y pasar al campo Q. Si la Descripcin es la correcta pasar (Tab) al campo R: Precio. Tipo: Sistema Referencias cruzadas: R1.9, R1.10, R1.15 Notas: Usar Base de Datos MS Access y tecla (Tab) Error en ingreso manual del Cdigo o Cdigo no registrado N/A El sistema conoce a Productos.CodigoProducto (Registrado oportunamente con anterioridad)
Nota:
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 (modificacin de atributo) Se despleg la Descripcin del Producto, Descripcion en Q. Se posicion el cursor en R: Precio
Contrato
ingresarPrecioCantidad(Precio, Cantidad) 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. Sistema R1.11 y R1.12 Usar Base de Datos MS Access N/A N/A El sistema conoce a Productos.Existencia (Registrado oportunamente con anterioridad) 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
Nombre:
Responsabilidades:
Tipo:
Nota:
Referencias cruzadas: Notas: Excepciones: Salida: Precondiciones: Postcondiciones:
365
Contrato
Nombre: grabarLnea() Responsabilidades: Aceptar avance con (Tab) hasta la siguiente lnea de la interfaz, creando una nueva Lnea de DetGuiaRecCompra. Calcular /ValorLnea y desplegarlo en T de la lnea previa. Grabar en almacenamiento persistente un registro de DetGuiaRecCompra con los datos ingresados/calculados en la lnea previa (anterior). Calcular /ValorTotal y desplegarlo en U. Posicionar 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 reiterar el ingreso de un nuevo cdigo CodigoProducto o caso contrario, pasar a terminarTransaccin() N/A N/A N/A
Nota:
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.
Contrato
Nombre: terminarTransaccin() Responsabilidades: Aceptar (click) del Botn V (Grabar). Recalcular /ValorTotal y redesplegarlo en U. Grabar en almacenamiento persistente la instancia actual de EncGuiaRecCompra.Limpiar los datos desplegados en la interfaz. Actualizar Productos.Existencia, Productos.Recibido, Productos.CostoUn y DetGuiaRecCompra.notAct. Posicionar en A el cursor. Tipo: Sistema Referencias cruzadas: Notas: R1.2, R1.14, R1.15 Usar Base de Datos MS Access. Al terminar, el sistema queda listo para ingresar una nueva transaccin o volver al Men de opciones. Productos.Existencia y Productos.Recibido ya fueron actualizados. N/A N/A
Nota:
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: Creacin de EncGuiaRecCompra ingresarOpcion(CrearGuiaRecepcion) desplegar(GuiaRecCompra) crearEncabezado(NumGuiaRecCom, FechaR) (Productos con registro persistente) (Base Craig Larman)
Nota: desplegar() es mtodo propio de Terminal, por ello este mensaje no va ms all de este punto. ingresarOpcion(CrearGuiaRecepcion) desplegar(GuaRecCompra)
Nota: ingresarOpcion(CrearGuiaRecepcion) es un mtodo del Men. La clase Fecha es una clase del Sistema en s - siendo ahora() un mtodo de la misma-, mientras que desplegar(Guia RecCompra) pertenece a Terminal y siguiente() pertenece a la clase EncRecCompra - an cuando esta ltima es una funcin genrica reutilizable-. Nota: En forma excepcional se representan en este diagrama de colaboracin los mensajes correspondientes a dos operaciones y sus respectivos contratos (desplegar es subordinado de ingresarOpcion).
t1:Terminal
1:NumGuiaRecCom := siguiente():NumGuia
:EncGuiaRecCompra
2:FechaR := ahora():Fecha
Fecha
crearEncabezado(NumGuiaRecCom, FechaR)
t1:Terminal
3 :[NuevaGuiaRecepcion] crearEncabezado(NumGuiaRecCom, FechaR)
r 1:EncGuiaRecCompra
Omisin del Contenedor de Lneas Nota: Segn Craig Larman ( 21.8.6 - pg.262 ) : Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / coleccin en s mismo... estas clases ( tales como java.util.Vector... ) son clases predefinidas de la biblioteca de clases... no es til mostrarlas explcitamente... agregan ruido pero poca informacin nueva.
3.1 :[NuevaGuiaRecepcion] crearDetRecCompra(NumGuiaRecCom)
Nota : crearDetRecCompra() es una de las 4 funciones bsicas implcitas. (Podra ser omitida en el Modelo de Datos).
l1:DetGuiaRecCompra
367
Diagramas de Colaboracin: Creacin de EncGuiaRecCompra ingresarCodEmpleado(CodigoEmpleado) ingresarRutProveedor(RutProveedor) (Productos con registro persistente) ingresarCodEmpleado(CodigoEmpleado) (Base Craig Larman)
t1:Terminal
1:ingresarCodEmpleado(CodigoEmpleado)
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 es la gua para determinar las responsabilidades y la estructura del diagrama. La forma y secuencia de los mensajes que activarn las operaciones respectivas se derivan de la aplicacin de estos patrones.
e1:Empleados
ingresarRutProveedor(RutProveedor) 2:ingresarRutProveedor(RutProveedor)
t1:Terminal
r1:EncGuiaRecCompra
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
Diagramas de Colaboracin: Creacin de EncGuiaRecCompra

ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)
(Productos con registro persistente) (Base Craig Larman)

ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)
1: ingresarNGuiaFechaNOrdC(NumGDP,
FecGD, NumOC) r1:EncGuiaRecCompra
t1:Terminal
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) 1.c: aceptarDatos(NumGuiaRecCom, NumOC)
ll:DetGuiaRecCompra
368
JUAN BRAVO C.
Diagramas de Colaboracin: Creacin de EncGuiaRecCompra ingresarCodProducto(CodigoProducto) (Productos con registro persistente) (Base Craig Larman)
ingresarCodProducto(CodigoProducto) siguiente () : NumLinea 1:ingresarCodProducto(CodigoProducto) 2 *:[i:=1...6] NumLnea:= siguiente () : NumLinea
t1:Terminal
r1:EncGuiaRecCompra
Asignacin de Responsabilidades Nota: Segn Craig Larman ( 18.9 a 18.11 - pg.193 a 205 ) La aplicacin de los patrones GRASP es la gua para determinar las responsabilidades y la estructura del diagrama. La forma y secuencia de los mensajes que activarn las operaciones respectivas se derivan de estos patrones.
1.1:aceptarCodigo(CodigoProducto) 2.1
*:[i:=1...6]
NumLnea:= siguiente () : NumLinea 2.2:crearLinea(NumLinea)
1.2:Descripcion := consultarDatos(CodigoProducto)
ll:DetGuiaRecCompra
b1:Productos
Omisin del Contenedor de Lneas Nota: Segn Craig Larman ( 21.8.6 - pg.262 ) : Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / coleccin en s mismo... estas clases ( tales como java.util.Vector... ) son clases predefinidas de la biblioteca de clases... no es til mostrarlas explcitamente... agregan ruido pero poca informacin nueva.
Diagramas de Colaboracin: Creacin de EncGuiaRecCompra ingresarPrecioCantidad(Precio, Cantidad) grabarLnea() y calcularTotales() (Productos con registro persistente) (Base Craig Larman)
ingresarPrecioCantidad(Precio, Cantidad)
t1:Terminal
1:ingresarPrecioCantidad(Precio, Cantidad)
r1:EncGuiaRecCompra
Nota: calcularTotales es grabarLinea() calcularTotales() subordinado de grabarLnea y no es invocado por el actor en forma directa.
1.1:aceptarDatos(Precio, Cantidad)
ll:DetGuiaRecCompra r1:EncGuiaRecCompra
t1:Terminal
2: /ValorTotal := calcularTotales()
2.1*:[i:=1...6]: /ValorLnea := calcularValor()
Nota:No se muestra la secuencia de mensajes que correspondera a grabarLinea(). Esta correspondera a la interaccin entre la capa del dominio (aplicacin) y la capa de servicios de almacenamiento persistente. (Otro conjunto de diagramas - no abordado aqu -).
ll:DetGuiaRecCompra
Nota: Despus de grabarLinea() el usuario vuelve a la accin anterior de ingresarCodProducto() hasta que no queden ms productos que ingresar, en cuyo caso pasa a la siguiente accin : terminarTransaccion()
369
Diagramas de Colaboracin: Creacin de EncGuiaRecCompra terminarTransaccion() (Primera Parte) (Productos con registro persistente) (Base Craig Larman)
Nota: terminarTransaccion() es muy amplio y se presenta dividido en dos partes.
calcularTotales()
Nota:terminarTransaccin() es realmente un mensaje compuesto , que se desdobla en : calcularTotales() y los mensajes que interactan con las capas de almacenamiento persistente y presentacin. Esto es, por ejemplo, sumarExistencia() se realiza en la capa de dominio, sin embargo se registra en la capa de almacenamiento persistente (Tema no considerado aqu)
t1:Terminal
1: /ValorTotal := calcularTotales()
r1:EncGuiaRecCompra
1.1*:[i:=1...6] /ValorLnea := calcularValor() sumarExistencia(CodigoProducto, Cantidad) sumarRecibido(CodigoProducto, Cantidad) 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)
ll:DetGuiaRecCompra
t1:Terminal
r1:EncGuiaRecCompra
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) 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)
ll:DetGuiaRecCompra
b1:Productos
Diagramas de Colaboracin: Creacin de EncGuiaRecCompra terminarTransaccion() (Segunda Parte) (Productos con registro persistente) (Base Craig Larman)
siguiente():NumGuia ahora():Fecha
Nota: terminarTransaccin() finalmente termina enviando los mensajes para crearEncadezado() y obtener los datos de inicializacin desplegndolos en la interfaz limpia. Por cierto que esto implica una interaccin entre la capa de dominio y la capa de presentacin. (Tema no abordado aqu). Para implementar el mensaje compuesto terminarTransaccin() (completo), se usaran los patrones aplicables - entre otros, por ejemplo, Indireccin, Fachada, Observador -.
t1:Terminal
3:NumGuiaRecCom := siguiente():NumGuia
:EncGuiaRecCompra
4:FechaR := ahora():Fecha
Fecha
crearEncabezado(NumGuiaRecCom, FechaR)
5 :[NuevaGuiaRecepcion] crearEncabezado(NumGuiaRecCom, FechaR)
t1:Terminal
r 1:EncGuiaRecCompra
5.1 :[NuevaGuiaRecepcion] crearDetRecCompra(NumGuiaRecCom)
l1:DetGuiaRecCompra
370
JUAN BRAVO C.
Diagrama de Diseo de Clases Crear Gua Interna de Proveedores Recepcin por Compra (Productos con Registro RUT Proveedor Razn Social persistente)
Direccin e-Mail Comuna Ciudad Pas Contacto Fono Fax
Encabezado de Gua de Recepcin * 1 1

RUT Proveedor N Gua Proveedor N de Gua Recepcin Fecha Recepcin Cdigo Empleado Fecha Guia Proveedor N Orden de Compra / Valor Total Transaccin Cerrada Transaccin Anulada crearEncabezado() aceptarDatos() calcularTotales() cerrarTransaccin() anularTransaccin() copiarTransaccin() siguiente()
Empleados * * 1 Cdigo Empleado Nombre
Nota: Agregado para clarificar el contexto, (ingreso manual).
Gua de Despacho de Proveedor N Gua de Proveedor RUT Proveedor Fecha Gua etc... 1 Productos Cdigo Producto Descripcin U.Medida Costo Unitario Existencia Inicial Existencia Recibido Despachado sumarExistencia() restarExistencia() sumarRecibido() sumarDespachado() existenciaNegativa() calcularCPP() 1 *
Nota: Agregado para clarificar el contexto, en principio es una Lista de Valores Posibles.
1..* Detalle de Gua de Recepcin N Lnea Cdigo Producto Precio Cantidad / Valor Lnea notAct Lnea Cerrada Lnea Anulada
crearLnea() aceptarCodigo() aceptarDatos() calcularValor() cerrarLnea() anularLnea() copiarLnea() siguiente() notAct()
Ordenes de Compra 1 N Orden de Compra Datos
Nota: Segn Craig Larman (21.8.4 a 21.8.8 - pgs.262 - 264) Salvo casos especificos, es conveniente omitir los mtodos : crear(), modificar(), eliminar() y consultar() en los diagramas de clases dado que no agregan valor y aumentan el ruido - se consideran implcitos -
Nota: Al crear la lnea de detalle, notAct se incializa a: true
Modelo Funcional (Detallado y Generalizado) Crear Gua Interna de Recepcin por Compra (Productos con Registro persistente) (Base este libro)
Encabezado de Gua de Recepcin

RUT Proveedor N Guia Proveedor N Gua Recepcin Fecha Recepcin Cdigo Empleado Fecha Gua Proveedor N Orden de Compra / Valor Total
C/E, msg1, msg2, msg6 y msg10
Proveedores C/E y msg4 RUT Proveedor Razn Social Direccin e_Mail Comuna Ciudad Pas Contacto Fono Fax 4. consultarDatos() Empleados Cdigo Empleado Nombre ... 4. consultarDatos()
Terminal
Encabezado, detalle y totales segn formato de pantalla adjunto. 1. Desplegar interfaz(Correlativo, Fecha). 2. Aceptar datos. 3. Enviar mensajes de C/E a registros. 4. Enviar mensajes de consulta de datos 5. Calcular totales cumulativos 6. Enviar mensajes de actualizacin de existencias y actualizar lnea a lnea el registro de la transaccin
Transaccin Cerrada Transaccin Anulada

1. crearEncabezado() 2. aceptarDatos() 6. calcularTotales() 7. cerrarTransaccin() 8. anularTransaccin() 9. copiarTransaccin() 10. siguiente()
C/E y msg4
C/E, msg1, msg2, msg6, msg10 C/E y msg4
msg3, y msg11
Detalle de Gua de Recepcin

N Lnea Cdigo Producto Precio Cantidad / Valor lnea notAct Lnea Cerrada Lnea Anulada 1. crearLnea() 2. aceptarCodigo() 3. aceptardatos() 6. calcularValor() 7. cerrarLnea() 8. anularLnea() 9. copiarLnea() 10. siguiente() 11. notAct()
C/E, msg4, msg6, msg8 y msg11
Productos Cdigo Producto Descripcin U.Medida Costo Unitario Existencia Inicial Existencia Recibido Despachado
4. consultarDatos() 6. sumarExistencia() 7. restarExistencia() 8. sumarRecibido() 9. sumarDespachado() 10. existenciaNegativa() 11. calcularCPP()
Gua de Despacho de Proveedor N Gua de Proveedor RUT Proveedor Fecha Gua etc... 4. consultarDatos()
C/E y msg4 Ordenes de Compra N Orden de Compra Datos 4. consultarDatos()
Nota: Al crear la lnea de detalle, notAct se incializa a: true
371
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, Espaa, McGraw-Hill. AT&T Quality Process Center (1992): Reengineering Handbook, USA, AT&T Bell Laboratories. 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, volumen 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 requirements, USA, Society for management information system proceeding. CERDA, G. (2002): Estamos diseando las interfaces de Software correctas?, Chile, Revista Akdemeia, Universidad de Ciencias de la Informtica, diciembre de 2002, volumen 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 Informtica, diciembre de 2004, volumen 4, nmero 2. CHIAVENATO, I. (2000): lntroduccin a la teora general de la administracin, Quinta edicin, Mxico, McGraw-Hill. COLLADO, M. y GARCA, P. (1994): Programacin orientada al objeto en sistemas comerciales, 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, AddisonWesley. 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, Regional Information Technology Studies, USA, 1995. ISHIKAWA, K. (1986): Qu es el control total de calidad? La modalidad Japonesa, Colombia, 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, Databases, 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 implicancias 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.
373
LEDGARD, H. y TAUER, J. (1987): Software Engineering Concepts. USA, AddisonWesley. 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, McGrawHill. 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 superior, 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, Argentina, Biblioteca Harvard de Administracin de Empresas. ROCKART, J. y Bullen, C. (1981): A primer on critical sucess factors. Massachusetts Institute of Technology.
374
JUAN BRAVO C.
SEELY, J. y DUGUID, P. (2001): La vida social de la informacin, Buenos Aires, PrenticeHall. 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 Mercurio, 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, Argentina, 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 Series, USA, Prentice Hall. YOURDON, E. y COAD, P. (1991): Object-oriented Analysis. Yourdon Press Computing Series, USA, Prentice Hall. 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, McGrawHill. WIRFS-BROCK, R., WILKERSON, B. y WIENER, L. (1990): Designing Object-Oriented Software. New Jersey, Prentice Hall.
375
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 sociedad 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 organizaciones. 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.
377
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 gestacin, 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 empresas 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 disfrutamos 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 comprendida 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 profesionalizar 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 Precio versin en papel: US$ 15, Chile $10.000 (2007, 2 edicin 230 Pgs., 18,5 x 13 cm., 1 edicin de 1998). Es un libro orientado a todas las personas que quieren comunicarse 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 superacin personal. Estamos vivos y lo ms caracterstico de la vida es la transformacin. Y porque el vnculo con nuestros seres queridos es lo nico que realmente cuenta, adems la mejora en las comunicaciones en las empresas tiene un efecto inmediato en la vida familiar y social de sus trabajadores. RESPONSABILIDAD SOCIAL (RS) Precio versin en papel: US$ 24, Chile $16.000 (2007, 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 ganar fomentando la Responsabilidad Social (investigacin, 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.
379
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 organizacin 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 resumir en una sola palabra que bien conocen en el Instituto: prevencin. Es un avance de Responsabilidad Social que se puede proyectar a otros mbitos para contribuir al Bien Comn. Ya sabemos que una historia puede inspirar a las personas para lograr fines superiores, al menos para encontrarle sentido 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 Precio versin en papel: US$ 15, Chile $10.000 (2005, 150 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 contexto de buenas prcticas de gestin la tesis es que las empresas exitosas se distinguen por algunas pocas prcticas excepcionales. As como existe la gestin por competencias dirigida a las personas, tambin existe una gestin por competencias corporativa. Adems de hacer las cosas bien, las empresas exitosas se distinguen por un pequeo nmero de prcticas que hacen muy bien, les hemos llamado sistema de diferenciacin. Se presentan los ejemplos de IST, ENAMI Ventanas, Termosistema e Integramdica.
380
JUAN BRAVO C.
GESTIN, EL CASO ENAMI VENTANAS Precio versin en papel: US$ 24, Chile $16.000 (2005, 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 Ventanas de la Empresa Nacional de Minera, ENAMI. Tiene una cultura distintiva que se aprecia en la ingeniera 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, productividad, entorno y personas TAYLOR REVISITADO Precio versin en papel: US$ 15, Chile $10.000 (2005, 140 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 superacin de la pobreza y porque sus propuestas, debidamente actualizadas, podran generar grandes beneficios en la economa de Latinoamrica.
381
A LA SALIDA DEL TNEL Precio versin en papel: US$ 15, Chile $10.000 (2000, 231 Pgs., 23 x 16 cm.) Es un libro creado con las entrevistas realizadas a los participantes del programa de televisin del mismo nombre en donde se extrajeron sus mejores ideas, propuestas y mensajes. Fue un programa de UCV TV, conducido por el dinmico 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 obligado para profesores, estudiantes, profesionales y pblico en general. Una inspiracin para pequeos y grandes empresarios y orientacin vivencial para nuestras autoridades. AMBROSOLI, DESDE LOS ALPES A LOS ANDES Precio versin en papel: US$ 24, Chile $16.000 (1998, 133 Pgs., 26,5 x 18,5 cm.) Coautor: Giancarlo Gandolini Ambrosoli. Este libro es un reconocimiento a la labor de don Constantino Ambrosoli y a todos los emprendedores que ayudan a crear un mundo ms humano. Es un ejemplo inspirador 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 tradiciones y seguir adelante unidos. Es un gran desarrollo, inseparablemente unido 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, comunicacin, libertad, creatividad y otras respuestas. Si pretendemos 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 catstrofe, los crculos virtuosos, la orientacin al cliente, etc.
PLANIFICACIN SISTMICA Precio versin en papel: US$ 24, Chile $16.000 (1997, 240 Pgs., 26,5 x 18,5 cm.). Tradicionalmente, hemos hecho planificacin suponiendo que las condiciones ambientales se mantendran ms o menos 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 planificacin sistmica recurre a herramientas tales como: participacin, creatividad y manejo de la incertidumbre del medio. La planificacin sistmica nos ayuda a cumplir los sueos, siguiendo un camino que comienza por determinar qu es lo que queremos, en nuestra empresa o en nuestra vida. Luego, establecemos un sistema de diferenciacin y un plan.
383
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 computacionales, tales como inventarios, contabilidad, remuneraciones o facturacin. Se busca aumentar la productividad en ese mbito. En especial se estudia el diseo de sistemas computacionales, una labor bella y eminentemente creativa que origina verdaderas obras de arte, a veces artesanales. Siempre conservando la creatividad, Ser posible que los mtodos de trabajos y las herramientas sean de uso general? S! Definitivamente el diseo de sistemas dej de ser arte para transformarse en tecnologa. Esta propuesta de la ingeniera de software tiene su base en tres slidos pilares: La planificacin estratgica en informtica, el diseo orientado al objeto y las herramientas de productividad. REINGENIERA DE NEGOCIOS Precio versin en papel: US$ 24, Chile $16.000 (1995, 300 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 ventas 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 organizacin. 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 empresa 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 herramientas de apoyo en cada etapa del desarrollo del sistema de informacin. En las ltimas dcadas la computacin ha sido un agente de cambio al interior 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 Precio versin en papel: US$ 24, Chile $16.000 (1996, 3 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 reglamentacin. Tambin se orienta a estudiantes de carreras del rea computacin e informtica, quienes podrn ver facilitado su aprendizaje al enfrentarse con metodologas y ejemplos concretos, sobre la base de una visin de conjunto del desarrollo de sistemas de informacin. El libro ha sido de gran ayuda para acadmicos de las reas mencionadas.
385
ACERCA DEL AUTOR:
Juan Bravo Carrasco Doctor por la Universidad de Lleida (Espaa). Master en Direccin de Informtica (Ide Cesem, Espaa) e Ingeniero de Ejecucin en Sistemas de Informacin (USM, Chile). Es Presidente de Evolucin, Centro de Estudios Avanzados y editor de la Revista 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 Seguridad, ENAMI, BancoEstado, Rolec, Transbank, Isapre Colmena, Municipalidad de Quillota, Banco Ita, Empresa Portuaria de Valparaso, Constructora TECSA y Termosistema. El Dr. Bravo es profesor de programas de postgrado en la Pontificia Universidad 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 ejemplo, 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 indican: 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 papel o digital. Editorial Evolucin S.A.: Av. Libertador Bernardo OHiggins N171, of 307, Santiago, fono: 6389717 www.evolucion.cl, info@evolucion.cl.

Modelando Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelando Software

Uploaded by

Copyright:

Available Formats

2

MODELANDO UNA SOLUCIN DE SOFTWARE

Modelando una Solucin de Software

Juan Bravo Carrasco

4 JUAN BRAVO CARRASCO, 2008

MODELANDO UNA SOLUCIN DE SOFTWARE

MODELANDO UNA SOLUCIN DE SOFTWARE

MODELANDO UNA SOLUCIN DE SOFTWARE

MODELANDO UNA SOLUCIN DE SOFTWARE

MODELANDO UNA SOLUCIN DE SOFTWARE

MODELANDO UNA SOLUCIN DE SOFTWARE

Gerente de Sistemas en Empresas Hites S. A.

MODELANDO UNA SOLUCIN DE SOFTWARE

Gerente de Desarrollo en BancoEstado. Directora de Sistemas en la Municipalidad de Melipilla.

MODELANDO UNA SOLUCIN DE SOFTWARE

Gerente de Informtica del Grupo Constructor Besalco.

MODELANDO UNA SOLUCIN DE SOFTWARE

MODELANDO UNA SOLUCIN DE SOFTWARE

Realidad deseada (difusa)

MODELANDO UNA SOLUCIN DE SOFTWARE

Contenido del libro

Competencias necesarias para modelar aplicaciones computacionales

Sntesis de modelos de una solucin de software

En el captulo 1 veremos el mtodo completo.

MODELANDO UNA SOLUCIN DE SOFTWARE

Soluciones propuestas: 1. Alinear con la estrategia 2. Incluir como plan de accin de RS

Proceso del Negocio Comercializar

Alcance poco claro Retroalimentacin de eventos destacados Demora en entrega final

Facturacin Compras Bodega Entrega

= Experiencias para evitar = Experiencias para replicar

Mapa de sistemas computacionales

Cmo Diseo Constructor

Cliente Usuarios y Analistas

MODELANDO UNA SOLUCIN DE SOFTWARE

Estrategia Personas Procesos Tecnologa Estructura

PROCESO DESPACHO INMEDIATO

GD3 GD2 GD1

Compras Devoluciones Entradas Traspasos

Artculos y factura Artculos y gua

Control del stock

Despacho de artculos Peticiones

Orden de compra y devoluciones

Modelo orientado al objetivo principal del sistema

Modelo orientado a los datos

Modelo orientado al flujo de transacciones

Diseo general de la interfaz

Diagrama de casos de uso

MODELANDO UNA SOLUCIN DE SOFTWARE

Terminal del Administrativo de Adquisiciones Administrativo de Adquisiciones Ingresar O/C

Caso de uso de alto nivel

Caso de uso de expandido

Lneas de la O/C Unidades Precio

existe en * almacena 1 Bodega ...

Modelo conceptual de datos

Modelo conceptual con atributos

Encargado Recepcin Razn Social Proveedor

N Gua Recepcin Fecha Recepcin

Gua de Despacho de Proveedor N

Modelo funcional generalizado

Interfaz visual detallada

Rut Nombre Direccin Telfono 1 Agregar 2 Consultar 3 Imprimir

Detalle de transaccin N documento Cdigo artculo Costo Cantidad 1 Clculo total

Objeto Ingreso de ventas Ingreso de compras

Modelo funcional generalizado y detallado