73926258 Modelando Software

JUAN BRAVO C. 2

Estimado lector: Hemos visto cómo este libro agrega valor para la humanidad a través del conocimiento que aporta, por lo tanto, con mucho agrado empleo también este medio digital.

Esta es una versión completa y actualizada del libro en 2009, sin costo du-rante este año como forma de contribuir en la solución de la crisis que nos afecta a nivel mundial.

La serie de libros aporta motivación, conceptos, técnicas 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 Evolución Centro de Estudios Avanzados www.evolucion.cl PD1. Pueden bajar presentaciones de apoyo en “Modelos de la Gestión de Procesos” y la revista RS, sin costo ni claves.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 3

Modelando una Solución de Software

Juan Bravo Carrasco

JUAN BRAVO C. 4

JUAN BRAVO CARRASCO, 2008

Inscripción 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, [email protected] Edición revisada y actualizada en mayo de 2009

Valor versión digital: $ 5.000 (Chile) ó US$ 7 (sin costo en 2009) Puede complementar bajando los Modelos de la Gestión de Procesos y la Re-

vista de Responsabilidad social (www.evolucion.cl).

EDITORIAL EVOLUCIÓN S.A.

www.evolucion.cl, [email protected] Alameda 171 Of. 307, Fono 6389717

Santiago de Chile


A todos los profesionales de la tecnología que se esfuerzan cada día por trabajar metodológica y éticamente.

JUAN BRAVO C. 6

CONTENIDO

CONTENIDO ............................................................................................................................... 6 TABLA DE ILUSTRACIONES ...................................................................................................... 12 PRÓLOGO ................................................................................................................................. 14 AGRADECIMIENTOS ................................................................................................................. 22 INTRODUCCIÓN ........................................................................................................................ 24

Contenido del libro .......................................................................................................... 25 Síntesis de modelos de una solución de software ............................................................ 26

CAPÍTULO 1. MÉTODO PARA LA GESTIÓN DE PROYECTOS.... ........................... 34 1.1. TRABAJAR METODOLÓGICAMENTE ................................................................................... 36

1. ¿Qué es método?.......................................................................................................... 36 2. Las mejores prácticas .................................................................................................. 37 3. Fundamento conceptual: la visión sistémica ............................................................... 37 4. Método GSP ................................................................................................................. 39

1.2. CLAVES DE LA IMPLANTACIÓN DE MÉTODO....................................................................... 41 Clave 1. Cinco mapas globales para la visión de conjunto ............................................. 41 Clave 2. Mínimo indispensable ........................................................................................ 47 Clave 3. Participación de todos los actores .................................................................... 47 Clave 4. Circularidad ...................................................................................................... 48

1.3. ADAPTACIÓN Y PROFESIONALISMO ................................................................................... 49 1. Adhesión a estándares y normas de calidad ................................................................ 49 2. Actualización y adaptabilidad del método ................................................................... 50 3. Estructura para la gestión de proyectos ...................................................................... 53 4. Aportes del PMI ........................................................................................................... 55 5. Ética y visión global del profesional ........................................................................... 56

1.4. ETAPAS GENÉRICAS .......................................................................................................... 58 1. Concepción .................................................................................................................. 60 2. Factibilidad ................................................................................................................. 62 3. Análisis ........................................................................................................................ 65 4. Diseño .......................................................................................................................... 71 5. Implementación............................................................................................................ 73 6. Despliegue ................................................................................................................... 76 7. Operación .................................................................................................................... 78

1.5. PRÁCTICAS TRANSVERSALES ............................................................................................ 82 1. Dirección del proyecto................................................................................................. 84 2. Plan de la etapa ........................................................................................................... 86 3. Exposición de los planes .............................................................................................. 87 4. Retroalimentación ........................................................................................................ 87 5. El equipo de trabajo .................................................................................................... 87 6. Entrevistas ................................................................................................................... 88 7. Comunicación .............................................................................................................. 89 8. Informes ....................................................................................................................... 89 9. Técnicas ....................................................................................................................... 89


10. Herramientas de apoyo .............................................................................................. 90 11. Trazabilidad ............................................................................................................... 90 12. Quick Wins ................................................................................................................. 91 13. Costos y duración ...................................................................................................... 91 14. Gestión de riesgos ...................................................................................................... 91 15. Gestión de la calidad ................................................................................................. 92 16. Responsabilidad social .............................................................................................. 92 17. Inserción .................................................................................................................... 93 18. Orientación al cliente ................................................................................................ 93 19. Sensibilización ........................................................................................................... 94 20. Capacitación .............................................................................................................. 94 21. Seguimiento ............................................................................................................... 94 22. Cuidar la solución anterior ....................................................................................... 95 23. Continuidad operacional ........................................................................................... 95 24. Plan de recursos físicos del proyecto ........................................................................ 95 25. Kill time ..................................................................................................................... 96 26. Control de cambios .................................................................................................... 96 27. Gestión del cambio .................................................................................................... 96 28. Gestión de proveedores ............................................................................................. 97

CAPÍTULO 2. INGENIERÍA DE SOFTWARE ................................................................ 98 2.1. ALCANCE DE LA INGENIERÍA DE SOFTWARE ................................................................... 101

1. Definiciones de la ingeniería de software.................................................................. 101 2. ¿Desarrollar un buen software o solucionar el problema? ....................................... 102 3. Esfuerzo de educación ............................................................................................... 104 4. Tecnología de información ........................................................................................ 106

2.2. PLANIFICACIÓN EN INFORMÁTICA ................................................................................... 108 1. Algunas directrices sobre la tecnología de información ........................................... 109 2. Reconversión de la informática ................................................................................. 111 3. Nuevas formas de organización informática ............................................................. 113 4. Método de planificación estratégica en informática ................................................. 116 5. Cambio cultural de la organización .......................................................................... 118 6. Resumen de la planificación estratégica en informática ........................................... 120

2.3. SISTEMA DE PRODUCTIVIDAD EN EL DESARROLLO DE SOFTWARE .................................. 123 1. Método ....................................................................................................................... 124 2. Técnicas ..................................................................................................................... 125 3. Herramientas de software .......................................................................................... 125 4. Hardware ................................................................................................................... 126 5. Incorporación del usuario ......................................................................................... 127 6. Habilidad del desarrollador ...................................................................................... 130 7. Normalización 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. 8

5. Pruebas del software por el programador ................................................................. 141 6. Mantenimiento de la solución de software ................................................................ 142

2.5. MÉTODOS PARA LA PRODUCCIÓN DE SOFTWARE ............................................................ 145 1. Ciclo de vida clásico .................................................................................................. 145 2. Técnica de prototipos ................................................................................................ 147 3. Diseño estructurado ................................................................................................... 151 4. Programación extrema (XP) ...................................................................................... 155

2.6. APOYO DEL DISEÑO EN LA EXPLOTACIÓN DEL SISTEMA ................................................. 157 1. Operación del sistema ............................................................................................... 157 2. Auditoría computacional ........................................................................................... 159 3. Contribución del diseño a la protección de la información ...................................... 162 4. Seguridad de la información ..................................................................................... 163 5. Integridad de la información ..................................................................................... 164 6. Recuperación de la información ................................................................................ 165

2.7. DISEÑO DE INTERFACES .................................................................................................. 166 1. Directrices para el diseño de interfaces humanas ..................................................... 166 2. Diseño de niveles de menús ....................................................................................... 167 3. Leyes para lograr una mejor interfaz humana .......................................................... 168

2.8. NORMAS Y ESTÁNDARES 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

CAPÍTULO 3. TEORÍA DE MODELOS APLICADA ............ ....................................... 176 3.1. MARCO TEÓRICO 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 línea ...................................................................................................................... 183 3. En tiempo real............................................................................................................ 184

3.3. ONCE CLAVES DE LOS MODELOS COMPUTACIONALES .................................................... 185 1. Fluidez ....................................................................................................................... 185 2. Intuición ..................................................................................................................... 186 3. Simplicidad ................................................................................................................ 187 4. Orientación al cliente ................................................................................................ 187 5. Independencia de la implementación tecnológica ..................................................... 188 6. Iteración ..................................................................................................................... 188 7. Totalidad .................................................................................................................... 189 8. Generalización ........................................................................................................... 189 9. Desarrollo incremental .............................................................................................. 190 10. Transacciones presentes .......................................................................................... 190 11. Armonía entre el modelo y la realidad .................................................................... 191


3.4. MODELAMIENTO DE FUNCIONES ..................................................................................... 193 1. Descomposición 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. Resolución de problemas simples .............................................................................. 201 2. Modelar bien a la primera ......................................................................................... 202 3. Concepto de máquinas abstractas ............................................................................. 202

3.6. CRITERIO CURSO NORMAL DE LOS EVENTOS .................................................................. 205 1. Aplicado al flujograma de información ..................................................................... 205 2. Relación del FI con la técnica UML .......................................................................... 212

CAPÍTULO 4. MODELAMIENTO DE DATOS ................. ............................................ 214 4.1. DEFINICIONES SOBRE EL MODELO DE DATOS ................................................................. 216

1. Representación de una entidad .................................................................................. 216 2. Relaciones propias (RP) ............................................................................................ 217 3. Características estáticas y funcionales de campos .................................................... 218 4. Tipos de entidades ..................................................................................................... 220 5. Relaciones entre entidades ........................................................................................ 222

4.2. CRITERIOS BÁSICOS DE NORMALIZACIÓN DE DATOS ...................................................... 227 1. Eliminación de grupos repetitivos ............................................................................. 228 2. Eliminación de dependencias parciales..................................................................... 230 3. Tabla de traducción ................................................................................................... 233

4.3. ENFOQUE DE BASES DE DATOS ....................................................................................... 235 1. Arquitectura de sistemas de bases de datos ............................................................... 235 2. Estructura relacional ................................................................................................. 236 3. Visión de bases de datos ............................................................................................ 238 4. Elementos del enfoque de bases de datos .................................................................. 240

CAPÍTULO 5. ORIENTACIÓN A OBJETOS ................................................................ 243 5.1. FUNDAMENTOS DE LA ORIENTACIÓN A OBJETOS ............................................................ 246

1. Mayor eficiencia ........................................................................................................ 247 2. Visión de los datos ..................................................................................................... 248 3. Visión histórica funcional .......................................................................................... 249 4. La orientación a objetos ............................................................................................ 251 5. Incorporación de nuevas tecnologías ........................................................................ 252

5.2. DEFINICIONES SOBRE ORIENTACIÓN A OBJETOS ............................................................. 255 1. Definiciones preliminares .......................................................................................... 255 2. Convenciones de diseño ............................................................................................. 257 3. Relación de pertenencia ............................................................................................ 258 4. Condición de existencia ............................................................................................. 259

5.3. CONCEPTOS DE LA ORIENTACIÓN A OBJETOS ................................................................. 261 1. Encapsulamiento........................................................................................................ 261 2. Clase .......................................................................................................................... 262 3. Objeto ........................................................................................................................ 263 4. Función ...................................................................................................................... 265

JUAN BRAVO C. 10

5. Identidad de instancias de objetos ............................................................................. 265 6. Mensaje ...................................................................................................................... 266 7. Independencia ............................................................................................................ 267 8. Enfoque sistémico ...................................................................................................... 268

5.4. PROCESO DE GENERALIZACIÓN ...................................................................................... 269 1. Obtención de clases ................................................................................................... 269 2. Herencia .................................................................................................................... 272

5.5. FASES DE LA ORIENTACIÓN A OBJETOS........................................................................... 274 1. Modelamiento de la información ............................................................................... 274 2. Identificación de clases .............................................................................................. 275 3. Visión externa ............................................................................................................ 276 4. Visión interna............................................................................................................. 279 5. Interfaz humana ......................................................................................................... 282

5.6. INCORPORACIÓN DE LA TECNOLOGÍA DE OBJETOS ......................................................... 283 1. Personalización del objeto......................................................................................... 283 2. Reutilización de código .............................................................................................. 284 3. Construcción de un modelo de objetos ...................................................................... 285

CAPÍTULO 6. UNIFIED MODELING LANGUAGE (UML) ....... ................................ 287 6.1. MODELOS DE UML ......................................................................................................... 290

1. Casos de uso .............................................................................................................. 291 2. Uso de herramientas .................................................................................................. 292

6.2. APLICACIÓN DE LOS MODELOS UML EN LA ETAPA DE ANÁLISIS .................................... 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. Visión dinámica del sistema ...................................................................................... 300 7. Diagrama de estado ................................................................................................... 301 8. Contratos ................................................................................................................... 302

6.3. APLICACIÓN DE LOS MODELOS UML EN LA ETAPA DE DISEÑO ...................................... 304 1. Diagrama de diseño de clases ................................................................................... 304 2. Diagrama de colaboración ........................................................................................ 305

CAPÍTULO 7. HERRAMIENTAS DE LA TECNOLOGÍA DE INFORM ACIÓN ..... 306 7.1. EVOLUCIÓN DE LOS LENGUAJES DE COMPUTADOR ......................................................... 309

1. Lenguajes de máquina ............................................................................................... 312 2. Lenguajes simbólicos ................................................................................................. 312 3. Lenguajes de alto nivel .............................................................................................. 313 4. La cuarta generación de lenguajes ............................................................................ 314 5. Las nuevas herramientas ........................................................................................... 315

7.2. HERRAMIENTAS DE USO ESPECÍFICO .............................................................................. 318 1. Herramientas integradas para automatización de oficinas ....................................... 319 2. Groupware ................................................................................................................. 319 3. Workflow .................................................................................................................... 320

7.3. UNA PIRÁMIDE DE SOLUCIONES ...................................................................................... 321


1. BI ............................................................................................................................... 321 2. Data Warehouse ........................................................................................................ 322 3. ERP ............................................................................................................................ 322 4. CRM ........................................................................................................................... 322 5. SRM ........................................................................................................................... 323 6. Motor de base de datos .............................................................................................. 323

7.4. HERRAMIENTAS DE APOYO PARA LA PRODUCCIÓN 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 BIBLIOGRAFÍA ......................................................... 331 CONCLUSIONES...................................................................................................................... 332 ANEXO 1. INTRODUCCIÓN A LA PLANIFICACIÓN ESTRATÉGICA .............................................. 333

Definición del negocio ................................................................................................... 334 Destino de la organización ............................................................................................ 337 Factores críticos del éxito .............................................................................................. 338 Mediciones ..................................................................................................................... 339 Sistemas de información gerenciales ............................................................................. 339

ANEXO 2. ALINEAR INTERESES .............................................................................................. 341 ANEXO 3. DESARROLLO EN ESPIRAL DEL PROYECTO ............................................................ 344 ANEXO 4. RELACIÓN CAUSAL ................................................................................................ 346 ANEXO 5. MÉTODO DE ACCIÓN RÁPIDA (MAR) .................................................................... 348 ANEXO 6. AD/CYCLE Y RUP................................................................................................. 349

AD/Cycle ........................................................................................................................ 349 RUP ............................................................................................................................... 350

ANEXO 7. CASO COMPRAS CON UML ................................................................................... 351 BIBLIOGRAFÍA ........................................................................................................................ 371

JUAN BRAVO C. 12

TABLA DE ILUSTRACIONES

Figura 1-1. Totalidad del método 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 Electrodomésticos Linhogar 49 Figura 1-5. Mapa de retroalimentación para replicar o evitar 50 Figura 1-6. Mapa de Sistemas Computacionales 51 Figura 1-7. Adaptación del método a cada tipo de proyecto 57 Figura 1-8. Esfuerzo estimado por etapa en el método 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 información 74 Figura 1-12. Diseño general de la interfaz 76 Figura 1-13. Flujograma de información de control de cambios 85 Figura 2-1. Clasificación de materias para perfeccionamiento en TI 111 Figura 2-2. Reconversión de programadores 119 Figura 2-3. Planificación estratégica en informática 122 Figura 2-4. Armonía entre técnica y comunicación 137 Figura 2-5. Tabla comparativa para disminuir tiempo de respuesta 143 Figura 2-6. Ejemplo de grosor de la piel de las crías 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. Definición de menús 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 diseño 190 Figura 3-8. Esquema de aproximaciones sucesivas 197 Figura 3-9. Concepto de descomposición funcional 202 Figura 3-10. Ejemplo de relaciones funcionales 204 Figura 3-11. Esquema de una actualización 206 Figura 3-12. Esquema de una extracción 207 Figura 3-13. Esquema de una selección 207 Figura 3-14. Esquema de una mantención 208 Figura 3-15. Ejemplo de flujograma de información despacho inmediato 214 Figura 3-16. Diagrama de flujo computacional 217 Figura 3-17. Relación del FI con la técnica UML 220 Figura 4-1. Componentes de una entidad 226 Figura 4-2. Representación gráfica de una entidad 227 Figura 4-3. Eliminación de grupo repetitivo usando número correlativo externo 238


Figura 4-4. Eliminación de grupo repetitivo usando campo interno 239 Figura 4-5. Ejemplo de eliminación 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 diseño 260 Figura 5-3. Ejemplo de relaciones funcionales estructuradas 262 Figura 5-4. Ejemplo de orientación a objetos 262 Figura 5-5. Gráfico de incorporación de nuevas tecnologías 263 Figura 5-6. Nomenclatura de la orientación a objetos 266 Figura 5-7. Relación de pertenencia 269 Figura 5-8. Representación 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 generalización 282 Figura 5-13. Ejemplo de herencia en un sistema de ventas 283 Figura 5-14. Herencia múltiple 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. Visión interna de la clase productos 291 Figura 5-20. Visión interna de la clase ingreso de transacción 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 visión dinámica del sistema 314 Figura 6-10. Ejemplo de diagrama de estado 315 Figura 6-11. Forma de un contrato por operación 316 Figura 6-12. Ejemplo de contrato en dar OK ingreso línea 316 Figura 6-13. Ejemplo de diagrama de diseño de clases 317 Figura 6-14. Ejemplo de diagrama de colaboración 318 Figura 7-1. Clasificación de lenguajes de computador 325 Figura 7-2. Una pirámide de soluciones 335 Figura 7-3. Herramientas Upper CASE y Lower CASE 340 Figura A1-1. Esquema de planificación estratégica 349 Figura A4-1. Ejemplo de gráfico de Ishikawa 362

JUAN BRAVO C. 14

PRÓLOGO

La presión irrazonable en la planificación puede hacer que los desarrolladores pierdan el respeto a sus directivos. La mayoría

de las personas se sentirán contentas con los resultados de un proyecto planificado con precisión.

McCONNELL (1997, pp. 237-8)

Este libro responde a una búsqueda de lograr mayor productividad en las orga-nizaciones de Latinoamérica, en una intensa investigación acerca de las mejores prácticas para modelar buenas soluciones de software. Lo destaco porque la serie de modelos de análisis y diseño efectivamente debe dar solución a una necesidad bien comprendida y evaluada, todo ello en el contexto de aplicar un método completo para la gestión del proyecto.

Es importante, no sólo por el imperativo de trabajar con calidad sino que tam-bién como una forma de crear riqueza en toda la sociedad a través de la transfe-rencia de conocimiento. En su reconocido1 libro Globalización para el desarro-llo, Goldin y Reinert señalan (2007, p. 344): “La transferencia global de ideas en forma de tecnología es uno de los procesos de desarrollo más importantes. Du-rante décadas, el abismo en aparente crecimiento entre los países desarrollados y los países en desarrollo ha despertado inquietudes acerca de una brecha tec-nológica. En años recientes, los países en desarrollo líderes como Brasil, China, India y Sudáfrica han demostrado que pueden no sólo salvarla, sino también ponerse en la delantera en algunas áreas puntuales. Debido en parte a estos ade-lantos, los países en desarrollo buscan entre sí las ideas y la colaboración”.

Hemos aprendido que se puede hacer lo que es debido para salir del subdesarro-llo, ya sea aplicar calidad, aprender a modelar un software o trabajar con méto-do. Lo importante es que podemos lograrlo.

El contenido de este libro se sustenta en varios pilares:

• Las buenas ideas del medio nacional e internacional recogidas a través de múltiples lecturas, en congresos, seminarios y formación de postgrado en Chile y el exterior.

• Los cursos sobre análisis y diseño que he dictado a alumnos y profesionales en la Universidad de Chile, Universidad Católica y Universidad Técnica Fe-

1 Entre otras personalidades, el libro es presentado por los Premios Nobel de Economía Jo-seph Stiglitz y Amartya Sen.


derico Santa María, además de talleres en muchas empresas desde hace ya dos décadas.

• En mi experiencia como desarrollador de varios cientos de sistemas compu-tacionales destinados a diferentes organizaciones, ensayando variadas formas de diseño y construcción, propias y normalizadas; incluso, construí una herramienta CASE a fines de los 80’s.

En relación al desarrollo de software, mi propia evolución se fue orientando desde el perfeccionamiento de métodos tradicionales, reflejados en el libro De-sarrollo de sistemas de información, una visión práctica, publicado a fines de la década de los 80, hacia la búsqueda de fórmulas cada vez más productivas, co-mo el método de cuarta generación y el modelamiento de datos y funciones, expuestos en revistas especializadas a comienzos de la década de los 90. Esos avances fueron profundizados en el libro Modelamiento de sistemas de informa-ción. La búsqueda siguió hasta desembocar a mediados de esa década en la orientación a objetos, una respuesta natural, productiva, elegante, amistosa y simple para modelar soluciones de software. Ese aprendizaje quedó reflejado en el libro La Nueva Visión, Diseño y Construcción de Sistemas Computacionales.

Hacia fines de los 90, la orientación a objetos se transformó en un estándar 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, Gestión de Proyectos de Procesos y Tecnología.

Lectores del libro

Esta nueva publicación se orienta a especialistas en informática, a docentes y es-tudiantes de carreras afines a la computación quienes requieren conocer métodos para aumentar su productividad y efectividad.

También a usuarios de la tecnología, quienes podrán conocer la terminología bási-ca para interactuar con los especialistas.

Libros de apoyo

Complementando este texto y para efectos de que el lector pueda profundizar en ideas específicas (sin ser indispensable porque el modelamiento se trata aquí como una totalidad), hago referencia dentro de la lectura a mis libros relacionados con el tema2:

2 Para las citas en el pie de página indicaré sólo su título. Los libros están editados en Santiago de Chile por Editorial Evolución S.A.

JUAN BRAVO C. 16

• Desarrollo de sistemas de información, una visión práctica (1988) • Reingeniería de negocios (1995) • Planificación sistémica (1997) • Análisis de sistemas (1998) • Gestión de procesos (2005) • Taylor revisitado, la productividad es la clave (2005) • Gestión de proyectos de procesos y tecnología (2006) • Responsabilidad social (2007)

No hago referencias a mis libros Modelamiento de sistemas de información y La nueva visión, diseño y construcción de sistemas computacionales porque todos sus contenidos relevantes para efectos de modelar soluciones de softwa-re están incorporados en esta nueva obra.

Prólogo de Gerentes de áreas de sistemas

Algunos estimados amigos me han otorgado el privilegio de agregar algunas palabras. Tienen en común estar a cargo de áreas de informática, las cuales están insertas en organizaciones de diferente tamaño y sector.

Christian Andrews3

Todo libro conlleva un gran esfuerzo del parte del autor, por la búsqueda 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 río mayor. Mi amigo Juan Bravo, autor de un gran número de libros del área de la Tecnología de la Información (TI) aplicada a los negocios, a quien conozco por muchos años, nuevamente ha realizado otro gran esfuerzo, para entregar estos nuevos conocimientos, ideas y conceptos actualizados al día 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.

¿Dónde radica la importancia de este libro para los profesionales de TI? A mi juicio, esta entrega orienta y prepara a las pequeñas y medianas empresas, en concebir los sistemas computacionales como un commodity, es decir, sistemas que son construidos con métodos estándares de construcción y calidad. Con metodologías que aseguran un resultado predecible en las operaciones diarias de los diferentes procesos comerciales. Ratificando una vez más, que el tener sis-temas computacionales no constituye ninguna ventaja sobre la competencia,

3 Gerente de Sistemas en Empresas Hites S. A.


muy por el contrario, el no tener estos sistemas constituye una clara desventaja competitiva, sin importar en cual industria participe y compita. Desventaja que erosiona gravemente los márgenes de ingreso, día tras día, en todas estas empre-sas sin los sistemas computacionales.

La tierra es plana postula Thomas Friedman, destacado periodista americano, como un eslogan que interpreta el impacto de la globalización en el mundo mo-derno, botando muros “políticos”, tendiendo expeditos puentes comerciales sobre los diferentes océanos, derribando montañas y cordilleras que separan a los países 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 cercanía de los productos de origen chino en casi todo el diario vivir o la oferta increíble de servicios computacionales y tecnológicos de grandes compañías de origen indio.

Hoy por hoy, la gran fábrica de software del mundo está en India, más que en otro lugar de este mundo, miles de ingenieros de software con conocimientos actualizados y metodologías, están dispuestos a desarrollar productos de softwa-re por una fracción del ingreso medio de un país medianamente desarrollado. Entonces, ¿cómo competir en este mundo más bien adverso? Pues actualizándo-se permanentemente en los diferentes avances que se van liberando en el mundo desarrollado.

De ahí, la importancia de este libro de Juan Bravo, quien nuevamente se esfuer-za en descubrir, rescatar lo medular de cada nuevo conocimiento del último tiempo, lo encapsula, lo simplifica y lo entrega como un método simple a seguir por sus alumnos y profesionales que siguen sus libros.

Quizás hoy más 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 mañana el león hambriento piensa que debe correr más rápido que la gacela más lenta para poder alimentarse y so-brevivir. Cada mañana la gacela piensa que debe correr más rápido que el león más rápido para poder sobrevivir”. Para nosotros, que no estamos en el África, sólo podemos pensar que, no importa si somos león o gacela, cada mañana debemos comenzar a correr rápido si queremos sobrevivir.

JUAN BRAVO C. 18

Rodrigo Collado4

Conozco a Juan desde hace muchos años, conozco de su trabajo, de sus ante-riores libros y, sobre todo, de su cariño por la Ingeniería de Software; especia-lidad cuya formalización le ha tenido de cabezas por un par de décadas.

He leído su nuevo libro “Modelando una solución de software”, una obra que sirve a los especialistas en construcción de software, pero también a los que están más lejos del diseño de software. Para los “iniciados”, el mensaje es claro: abandonemos la artesanía y hagamos ingeniería. Para los “legos”, es la oportunidad de conocer la complejidad de una disciplina que aún no alcanza la formalidad de otras especialidades. Para ambos, tomar conciencia de la ne-cesidad y prisa de trabajar conforme a los postulados de la Ingeniería de Soft-ware, la cual está apoyando el desarrollo y desempeño 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 enseñado en él, de haber trabajado en muchas empresas chilenas, de haber intercambiado sus puntos de vista y sus sueños con tantos, entre los que me cuento. Deseo firmemente que su libro no sea uno más, que compita o se compare con cualquier otro editado en Estados Unidos o en otro país.

Agradezco el empeño de Juan, el cariño por su profesión, su amor por el estu-dio de esta especialidad y su coraje en la búsqueda de la impecabilidad en el modelamiento de buenas soluciones de software.

Limbi Ortiz Neira5

Cuando el doctor Juan Bravo Carrasco, me llamó para pedirme que le escri-biera un prólogo a este libro, me embargó la emoción por el gran honor que esto significa para mí, y luego de unos segundos de respirar profundo, le res-pondí que lo haría. Mi humilde opinión 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 solución de Software, sea un desafío que nos obliga a considerar diferentes aspectos, por lo general no considerados en este ejercicio, tal como visión sistémica, un concepto que nos abre la mente a ver nuestro software como parte de un en-

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


torno rico en posibilidades, en el cual necesariamente debemos considerar “la mesa6”, es decir, el modelo de negocios en el cual estamos trabajando, consi-derar también el diseño orientado a objetos, el cual nos aclara conceptos tan utilizados como desconocidos hoy en día.

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 Ingeniería de software, las competencias nece-sarias para modelar una solución de software, las cuales tienen tal importancia que ellas siete se traducen en los respectivos capítulos del libro. Merece la pena nombrarlas aquí:

• Competencia 1: Aplicar un método completo para la gestión de proyectos • Competencia 2: Profesionalizar el desarrollo con la ingeniería de software • Competencia 3: Conocer la nueva teoría de modelos • Competencia 4: Manejar el modelamiento de datos • Competencia 5: Conocer necesariamente la orientación a objetos • Competencia 6: Trabajar con el estándar UML • Competencia 7: Conocer las herramientas de la TI

El libro es tan entretenido que te transporta y te inquieta por continuar apren-diendo. Te desafía a utilizar todos los conceptos, técnicas y herramientas que allí aparecen, así también, te estimula a continuar investigando.

“Modelando una solución de software, una visión sistémica del análisis y di-seño 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 partícipes a todos de este libro, al cual ha dedicado muchísimas horas de trabajo y el resul-tado ha sido excelente. Asimismo, agradecerle su confianza en mí, y haberme permitido dar mi opinión.

6 Se refiere a cinco elementos que se representan con la metáfora de una mesa (la cubierta es la estrategia y las 4 patas son: personas, procesos, estructura y tecnología), la cual se describe brevemente en la introducción y se detalla en la etapa de análisis (sección 1.4).

JUAN BRAVO C. 20

Carlos Toloza 7

Cuando Juan me pidió revisar el material de este libro y escribir unas líneas al respecto acepté sin ningún problema, pero al sumergirme en el tema específi-co del UML (ISO 19501:2005) debo reconocer que vi la oportunidad que se me brindaba de poder llegar a una lectora o lector y compartir mi opinión con la esperanza de que en el momento de estar leyendo estas líneas aportar un mensaje simple y claro.

Yo pienso que lo que estamos hablando en este libro es de tener y sentir la misma responsabilidad profesional frente al desarrollo de un sistema informá-tico que frente a la construcción de una catedral. El pecado original en in-formática es comenzar a desarrollar sin tener los planos, acá es lo mismo, no podemos comenzar a construir el sacro edificio si no tengo planos arquitectó-nicos hechos y bien hechos.

Tengo la suerte de trabajar en una empresa constructora y sería un suicidio comenzar un proyecto sin tener los planos, bueno, en informática los planos del sistema podemos dibujarlos con alguna nomenclatura estándar como UML o alguna propia, pero ese es el punto, por favor no comience la construcción sin los planos!!!

La verdad es que prefiero dejar un mensaje simple y fuerte en la mente del lector que participa en un proyecto informático, no comience el desarrollo sin planos, no olvide que hay personas que van a vivir dentro de ese sistema y va a ser su casa en forma permanente.

De pronto me siento repitiendo algo que escuché por primera vez en mis ini-cios, cuando programaba mi primer software, pero la realidad de las empresas es muy exigente y a veces la presión por resultados nos hace improvisar o simplificar el tema en las etapas iniciales de los proyectos, les tengo malas noticias, es verdad que los costos de improvisar son muy altos y pueden dupli-car fácilmente cualquier presupuesto de tiempo y costo con el consiguiente impacto negativo en el negocio.

Juan dice en el prólogo 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 más productos o si lo profieren que con menos recursos podamos entregar los mismos productos. Un sistema informático bien hecho (partiendo de su modelación) debe bajar los costos del área en la

7 Gerente de Informática del Grupo Constructor Besalco.


cual se implementa y esta reducción debe pagar la inversión 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 informático que genere utilidades a la empresa, si lo entienden se darán cuenta del poder que hay en la informática.

JUAN BRAVO C. 22

AGRADECIMIENTOS

El liderazgo complementa a la gestión, no la sustituye.

Kotter (2004, p. 41)

Mi especial reconocimiento a quienes tuvieron la gentileza de revisar borrado-res de este texto y compartir tanto de su sabiduría: Limbi Ortiz Neira, Gloria Arellano Mundaca, Mauricio Arancibia Pino, Gerardo Cerda Neumann, Chris-tian Andrews Villagra, Rolf Achterberg Neüman, Rodrigo Collado Lizama, Luis Cavieres Rojas, Víctor Silva Ballerini, Ignacio Castro Escobar, Carlos Reyes Rubio, Eugenio Díaz González, Hugo Osses Bravo, Carlos Parra Bus-tos y Raúl Prado Baldratti.

Muchas ideas y motivación han surgido de las conversaciones con Liliana Gajardo, Derek Hyland, Francisco Ramírez, Daniel Kanonitsch, Miguel Sáez, Luis Cid, Francisco Medina, Rodrigo Baldecchi, Marcos Merino, Carlos To-loza y Enrique Jorquera (mis disculpas por las eventuales omisiones).

Este libro es heredero de dos textos anteriores: Modelamiento de Sistemas Computacionales (1994) y La Nueva Visión, Diseño y Construcción de Siste-mas Computacionales (1996), así es que reitero en éste los agradecimientos a quienes aportaron de una u otro forma en aquellos (revisiones, ideas, motiva-ción): Rolf Achterberg Neüman, Giancarlo Gandolini Ambrosoli, Ricardo Baeza Yates, Eugenio Díaz González, Santiago Macías Huenchullan, Francis-co Méndez Sanhueza, José Labra Molina, Jeannette Caballero Pinilla, Alexis Cifuentes Barra, Luis Méndez Reyes, David Medina Avilés, José Leiva Ol-medo, Ricardo Cahe Cabach, Juan Carlos Soto Trucido, Francisco Guerrero Novoa, Bernardo Cienfuegos Areces, Sonia Esturillo Herrera, Liliana Gajardo Campos, Jorge Stein Blau, Manuel Videla Abarca, Dagoberto Cabrera Tapia y Cristian Rubilar Utillano.

Estoy agradecido de las empresas donde me acogieron como colaborador de tiempo completo: Empremar, NCR y Weisselberger y Cía. También de las or-ganizaciones donde he tenido el privilegio de participar como asesor o relator de seminarios: CMP, AT&T Chile, Agencia de Aduanas Jorge Stein, Polygram Chile Ltda., Termosistema, Aquacultivos, Editorial Televisa, Integramédica, Sota y Nicoletti Comunicaciones, entre otras. Especial mención requieren las empresas con las cuales hemos trabajado en la última década: BancoEstado, Empresa Portuaria de Valparaíso, Rolec, Enami Ventanas (actual Codelco), IST y ACHS.


En cuanto al ámbito académico, destacar actividades abiertas de capacitación, por ejemplo, a través de:

• Universidad Técnica Federico Santa María en Viña del Mar y Santiago. El diploma realizado por varios años en análisis y diseño de sistemas.

• Universidad Santa María en Ecuador, el magíster en gestión y tecnología. • Universidad de Chile, los cursos acerca de procesos y de tecnología. • Pontificia Universidad Católica de Chile, en particular los cursos de ges-

tión de proyectos de procesos y de tecnología en el formato de dos días. • Revista Gerencia, en la forma de múltiples seminarios de un día de divul-

gación de estos temas.

La colaboración de Silvia, mi hermana, una vez más fue muy valiosa en todo tipo de apoyo logístico.

El diseño de la portada es obra de Juan Pablo Bravo Zamora.

A todos agradezco sus aportes y libero de cualquier responsabilidad por algún error en el texto.

Un reconocimiento especial a mi esposa e hijos, su cercanía ha sido un estí-mulo en la realización de esta obra.

Juan Bravo C.

JUAN BRAVO C. 24

INTRODUCCIÓN

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 enfrentarán. Es importante que los miembros de los subsistemas se den cuenta que su trabajo está interrelacionado… Los problemas surgen

cuando cada gerente tiene un concepto diferente de la importan-cia de su subsistema funcional.

KENDALL y KENDALL (2005, p. 30)

Modelar una solución de software es una labor bella y creativa. Por esta razón, 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 métodos y herramientas de trabajo, diera vida a una creación única e irrepetible.

¿Será posible profesionalizar conservando la creatividad? ¡Sí! y de esta for-ma los métodos y herramientas van a recibir el aporte de muchas personas. Modelar soluciones de software puede ser arte y tecnología a la vez.

Este es el desafío, modelar soluciones de software con técnicas 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 resultaría muy difícil de transmitir, en este caso una solución de software. Lo más probable es que la realidad deseada se encuentre vagamente escrita y que principalmente esté en la mente de las personas, más como un deseo difuso que como un requerimiento. La función del modelamien-to es hacer tangible y aclarar esa realidad para que luego se pueda implementar.

Si esa realidad deseada da respuesta a una necesidad por una parte y por otra los modelos de esa realidad son factibles de implementar, entonces la probabilidad de éxito es alta. Eso es lo que quiere mostrar la siguiente figura.

NecesidadRealidad deseada

(difusa)Modelos

de la solución

Problema Solución Implementación


Shari Pfleeger explica en su libro Ingeniería de software (2002, p. 226): “Se utiliza la especificación de requerimientos para definir el problema. Entonces, podemos declarar que algo es una solución a un problema si satisface todos los requerimientos planteados en la especificación. En muchos casos el número de soluciones es prácticamente ilimitado”.

¿Siempre es necesario modelar la solución antes de implementar?

Depende, si usted sólo quiere extender una pared interior de 2 metros, es posible que no requiera los modelos, puede contratar un experto y sólo darle instruccio-nes verbales, tal vez le resulte y ahorre tiempo y dinero. Sin embargo, si quiere construir su casa necesitará de maquetas y muchos planos (obra gruesa, cañerías de agua, cables de electricidad y todo lo demás).

En el software es igual, toda aplicación desde un costo de algunos miles de dóla-res ya hace necesario un modelar formalmente. La idea es superar la construc-ción artesanal de software (por ejemplo, construir sin planos) y aplicar los nue-vos conocimientos sobre teoría de modelos, normalización (tal como orienta-ción a objetos y UML) y construcción con herramientas CASE.

Contenido del libro Lo primero sucede en esta misma introducción, una selección de los modelos más relevantes de una solución de software, donde sólo se muestra un boceto de ellos para lograr una visión de conjunto (el detalle de cada uno está en el resto del libro).

Esta presentación será nuestra guía y a partir de esta experiencia extraeremos una conclusión vital: las competencias que debería tener un profesional de la informática. Las competencias son conocimientos, habilidades y actitudes ne-cesarias para modelar aplicaciones computacionales (o soluciones de softwa-re), en este texto se presentan en la forma de capítulos:

1. Un método completo para la gestión de proyectos y así situar el modela-miento de soluciones de software en su contexto.

2. La profesionalización de conocimientos que aporta la ingeniería de soft-ware para comprender todos los aspectos técnicos de los modelos, las normas y estándares que existen.

3. Los múltiples aportes de la nueva teoría de modelos, en particular el mo-delamiento de funciones y el criterio curso normal de los eventos.

4. El indispensable modelamiento de datos. 5. Los necesarios conocimientos de la orientación a objetos.

JUAN BRAVO C. 26

6. El estándar UML. 7. Las herramientas de la tecnología de información.

Cada capítulo, en el mismo orden, profundiza en la competencia correspon-diente, produciéndose un avance que parece una pirámide, tal como se aprecia en la siguiente figura.

Síntesis de modelos de una solución de software Los modelos se crean en las etapas de análisis y diseño de la Gestión Sistémica 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 considerarán para cada etapa de la aplicación particular, una primera versión destinada a lograr una visión de conjunto. Ese es el sentido de esta introducción.

Seguimos la idea de una doble espiral que se traslapan parcialmente: la primera del análisis y la segunda del diseño, tal como vemos en la figura.

8 En el capítulo 1 veremos el método completo.

CAPÍTULO 1. MÉTODO PARA LA GESTIÓN DE PROYECTOS

CAPÍTULO 2. INGENIERÍA DE SOFTWARE

CAPÍTULO 3. TEORÍA DE MODELOS

CAPÍTULO 4. MODELAMIENTO DE DATOS

CAPÍTULO 5. ORIENTACIÓN A OBJETOS

CAPÍTULO 6. UML

CAPÍTULO 7. HERRAMIENTAS TI

Competencias necesarias para modelar aplicaciones computacionales

Análisis DiseñoAnálisis Diseño


Mapas para la visión de conjunto

Conviene observar estos cinco mapas que deberían existir en la organización previo al desarrollo de una aplicación específica. Son los mapas de necesida-des, proyectos, procesos, retroalimentación y sistemas.

DesarrolloPlanificaciónEstratégica

RSGestión deProcesos

Gestión deProyectos

Gestión deCalidad

Control deGestión

Gestión deContratos

AdquisicionesServiciosBásicos

Finanzas LegalRemuneraciones

y bienestarTecnología yMantención

Gestión de PersonasProcesos Estratégicos

Proceso del Negocio Comercializar

Procesos de Apoyo

Recibir

Emitir traspaso

Planearcada local

Traspasar

Distribuir

Prepararcada local

Presentar

Coordinarmerchand.

Ordenar Vender al detalle

Atenciónal cliente

Servicio de garantía

Medición y seguimiento

Postventa

Conocer la demanda

VisitarClientes

Estadísticas internas

Proyectar ventas

Emitir O/C

Comprar

Recepcionar

Almacenar

Cotizar

Analizar cargos

Reclutar Inducir

Formar Diseñar carrera

Evaluar

Vender

Despachar

Cuadrar

TransporteContabilidad

Problemas detectados:1. Pago tardío a

Proveedores2. Trabajadores fuman en

sector atención clientes

Responsabilidad Social

Tiempo

Calidad

Productividad

Bienestar

Costo

Soluciones propuestas:1. Alinear con la estrategia2. Incluir como plan de

acción de RS

7p

10p

2p

1p

= Libera

= Requiere= Neutro

DevoluciónCobranzas

Ventas

EntregaBodegaCompras

Recepción

Facturación

Mapa de necesidades

Mapa de proyectos

Mapa de procesos

Mapa de retroalimentación Mapa de sistemas computacionales

Alcance poco claro

Dificultades para coordinar entrevistas

con usuarios

Liderazgosistémico

Meditación

= Experiencias para evitar

= Experiencias para replicar

Retroalimentación deeventos destacados

Demora en entrega

final

Buen trabajo en equipo

JUAN BRAVO C. 28

Estos mapas son modelos que ayudan a lograr la visión de conjunto para luego formalizar en el análisis y diseño la solución de software. El detalle de cada uno se puede apreciar en el capítulo 1.

La visión de conjunto es vital en la visión sistémica, cosmovisión que guía todo el trabajo de este libro, tanto en los mapas como en los siguientes modelos, los cuales tienen la características de contextualidad, es decir, dependen del método y nivel de madurez de cada organización.

Los modelos que se presentan a continuación para análisis y diseño son sólo una muestra de las posibilidades del modelamiento. Cada empresa debe tener su propia ruta metodológica e incluso adaptada según tipos de proyectos.

Se presentan los modelos ordenados según las etapas de análisis y diseño. 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 análisis se orienta a definir el qué y la de diseño el cómo, en ambas participan analistas y usuarios. Una vez que el diseño está completo, se envía al constructor (aunque sea el mismo analista en otro rol).

Modelos de la etapa de análisis

La siguiente selección de modelos no pretende ser exhaustiva, se incluye con el único objetivo de lograr una visión global, no se explican aquí porque el detalle de cada uno está en los capítulos del libro.

Análisis Diseño

CómoQué

Cliente

Usuarios y Analistas

Constructor


En este caso, los modelos siguen la lógica del método GSP, en la empresa corresponden a los contenidos del proceso de desarrollo de software que ésta se haya dado.

En esta etapa todo el trabajo se centra en el modelo de negocios de la solu-ción, con cinco elementos que se representan con la metáfora de una mesa, la cubierta es la estrategia (alineando la de la empresa y la de del proyecto, in-cluye responsabilidad social) y las 4 patas son: personas (incluyendo ambien-te), procesos, estructura (organizacional y física) y tecnología (de todo tipo). En esencia: corresponde decidir Qué hacer, comenzando por la cubierta de la mesa (detalle de la figura en el capítulo 1).

Luego se comienza a trabajar en la pata de los procesos: levantamiento deta-llado y propuestas de cambio. Se emplean principalmente los modelos mapa de procesos y flujograma de información, los cuales se observan en la siguien-te figura (detalle en los capítulos 1 y 3 respectivamente).

CuadrarDespacharVender

Programar Entregar

Inmediato

A Crédito

Al Contado

A domicilio

Vender al detalle

CLIENTE BODEGA FINANZAS

ADMINISTRATIVO DE BODEGA DESPACHADOR

PROCESO DESPACHO INMEDIATO

GD3’

OE

GD4

GD3GD2

GD1

GD4OE

Buscarproducto

GD’s

Cliente recibey firmarecepción

GD1’

Reservar y emitir GD

Rebajarsaldo

GD2’

OE: Orden de Entrega, GD: Guía de Despacho

PROCESO CUADRAR

PROCESOS VENDER

Estructura

Personas

Procesos

Personas

Procesos

Tecnología

Estrategia

Mapa de procesos

JUAN BRAVO C. 30

Desde aquí surgirán definiciones para las otras patas de la mesa: personas, estructura y tecnología. Lo cual está descrito en el capítulo 1.

Para definir el alcance de la solución de software en la etapa de análisis, se puede emplear esta serie de modelos (una buena técnica es por borradores sucesivos, comenzando por cualquiera de ellos). El objetivo es decidir qué incluye el modelo de negocios (detalle en los capítulos 1, 2 y 3).

Una vez lograda la decisión respecto a los qué, es necesario profundizar en los requerimientos principales de la solución de software, en tal caso, la recomen-dación es trabajar con estos nuevos modelos (detalle en los capítulos 5 y 6).

Controldel stock

Compras

Devoluciones

Traspasos

Ventas

Devoluciones

Traspasos

Entradas SalidasControldel stock

Compras

Devoluciones

Traspasos

Ventas

Devoluciones

Traspasos

Entradas Salidas

Proveedores

Compras

Artículos Ventas

Clientes

Proveedores

Compras

Artículos Ventas

Clientes

Clientes

Proveedores

Gerencia

Sala de ventas

Pedidos y devoluciones

Artículos y factura

Artículos y guía

Orden de compra ydevoluciones

Peticiones

Despacho de artículos

Niveles

Costos

Control de stock

Diagrama de contexto Modelo orientado al objetivo

principal del sistema

Clientes Artículos ProveedoresCuentasContables

HistorialVentas

Transacciones

Maestros HistorialCompras

Ventas X X X XCompras X X X XDevolución ventas X X X X

Modelo orientado a los datos Modelo orientado al flujo de

transacciones

Diseño general de la interfaz Diagrama de casos de uso

Cotizar

Jefe deAdquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

IngresarO/C

Terminales del área de Adquisiciones

Administrativo de Adquisiciones

O/C = Orden de Compra


Nº Guía Recepción

Fecha Recepción

RUT Proveedor -

Razón Social Proveedor

Código Enc. Recepción

AAAAAAAA

CCCCCCCCBBBBBBBB

DDDDDDDD

EEEEEEEE FFFFFFFF

GGGGGGGGDirección Proveedor

Comuna Ciudad Fono Fax

HHHHHHHH

IIIIIIII JJJJJJJJ KKKKKKKK LLLLLLLL

MM NNNNNNNN OOOOOOOO

GrabarGrabar

L. Código Descripción Precio Cantidad Valor Neto

Total acumulado

PPPPPPPP QQQQQQQQ RRRRRRRR

Encargado Recepción

Cerrada

Anulada

SSSSSSSS TTTTTTTT

UUUUUUUU

CerrarCerrar VVVVVVVV

AnularAnular

WW

SalirSalir

XX

Guía Interna de Recepción por Compra

Guía de Despacho de Proveedor Nº Fecha G/ D. Proveedor Nº de O/C.Guía de Despacho de Proveedor Nº Fecha G/ D. Proveedor Nº de O/C.

e-Mail

YY ZZ

LLLLLLLLLLLLLLLL

XXXX

Interfaz de Entrada

Ingresa la Orden de Compra a partir de los documentos decotización a proveedores.

La O/C queda disponible para ser enviada al proveedor luego de la aprobación electrónica por el jefe de adquisiciones

Ingresar O/C

Terminal en bodega


Líneas de la O/C

UnidadesPrecio

Bodega...

Encabezado de O/CNº O/CFecha

Proveedores

RutNombre

compuesta por

* 1

existe en contiene

* 1

contiene existe en

*

1

existe en

almacena

Productos...

Ingresar transacción

Encabezado de transacción Personas

Detalle detransacción Productos

C/E

Mensaje 1

C/E

Mensajes 4 y 5




C/E

Mensaje 1

C/E

Mensajes 4 y 5

Caso de uso de alto nivel Caso de uso de expandido

Modelo conceptual con atributos

Modelo funcional generalizado

Interfaz visual detallada

Encabezado de O/C

Proveedores

Líneas de la O/C

Productos

* 1

* 1

1

1..*

Bodega

*

1

compuesta por

se asocia a

contiene

existe en contiene

existe en

existe en

almacena

Encabezado de O/C

Proveedores

Líneas de la O/C

Productos

* 1

* 1

1

1..*

Bodega

*

1

compuesta por

se asocia a

contiene

existe en contiene

existe en

existe en

almacena

1. Si el número de O/C ya existe, vea caso de uso “Corregir Correlativo”. 2…Incluye interfaces detalladas de E/S

Ingresar O/C

Terminal del Administrativo de AdquisicionesAdministrativo

de Adquisiciones

Resumen: (el mismo del caso de uso de alto nivel).Funciones relacionadas:

Curso Normal de los eventos

Excepciones:

Acción del actor Respuesta del sistema

1. Tomar la O/C desde el archivador2. Ingresar Nº O/C en (A) 3. Verifica correlativo y envía 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 línea: Para cada línea:

7. Ingresar el código de 8. Verifica existencia del producto, producto en (H) obtiene y despliega la descripción

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 línea 11….

Modelo conceptual de datos

JUAN BRAVO C. 32

Modelos de la etapa de diseño

De la misma forma que la etapa de análisis, es decir, mediante borradores su-cesivos y la técnica de desarrollo en espiral (ver anexo 3) se avanza en el dise-ño, sin mayores problemas de volver a veces a la etapa de análisis, porque ambas forman una totalidad que llamamos modelar una solución de software (el detalle de estos modelos está en los capítulos 5 y 6).

Ingreso de transacción

Encabezado, detalle y totales segúnFormato de pantalla adjunto

Aceptar datos y actualizar línea a línea cada producto.

Enviar mensajes para verificarExistencia de personas y artículos,

Ambos deben existir.

Cuadrar totales para referencia.Enviar solicitudes para actualizar el stock













Tabla de objetos, clase Ingreso de transacción Objeto Atributos Funciones

Ingreso de ventas Indicar stock del producto Deben cuadrar totales, stock mayor a unidades por vender. Mensaje 5

Ingreso de compras Crear proveedor y artículo si no existen. Mensaje 4

Ingresar Nº de O/C

Dar OK a la línea

Ingresar código de prod.

Administrativo Sistema

Repetir hastaque no haya más productos

Ingresar cantidad

Ingresar Nº de O/C

Dar OK a la línea




Ingresar cantidad

ContratoIdentificación: Dar OK al ingreso de la líneaResponsabilidades: con cada ingreso de línea los conceptos deben ser consistentes.Tipos de datos: afecta a los conceptos Encabezado de O/C y Detalle de O/C.Referencias cruzadas: no hayNotas: nada especialExcepciones: la no existencia de la línea en el sistema ya fue validada con el ingreso de O/C.Salida: no hayPrecondiciones: no existe la línea.Poscondiciones:

•Se creó una línea en el concepto detalle.• Se actualizó el contador de líneas en el encabezado.• Se actualizó la asociación entre encabezado y detalle de O/C.

Encabezado de transacción

• Nº documentoFecha Rut persona

1 Agregar2 Consultar3 Imprimir

Detalle de transacción

• Nº documento• Código artículoCostoCantidad

1 Cálculo total

Productos

1 Agregar2 Consultar3 Imprimir4 Sumar saldo5 Restar saldo

Personas


C/E

Mensaje 1

C/E

C/E

Mensajes 4 y 5


1 Aceptar datos2 Cuadrar totales

Encabezado, detalle y totales según formato

• Código artículoTipo artículo DescripciónÚltimo costoSaldo

• RutNombreDirecciónTeléfono

Visión interna de la clase ingreso de transacción con la tabla de objetos

Modelo funcional generalizado y detallado

Contrato Diagrama de secuencia


Los dos modelos más característicos del diseño desde el punto de vista de UML son el de diseño de clases y colaboración (detalle en el capítulo 6).

Líneas de la O/C

UnidadesPrecio

Agregar línea

Productos...

Bodega...


Crear líneaImprimir

Proveedores

RutNombre

Crear proveed.Modificar Rut

Modificar nombre1

1..*

compuesta por

se asocia a

* 1

existe en contiene

* 1

contiene existe en

*

1

existe en

almacena

Operación: Dar OK al Ingreso de la línea de O/C

Ingresar producto(cód, cant, pre)

1: Crear línea de O/C(cod, cant, pre)

1.1: Crear (cod, cant, pre)

Terminal del administrativo

Encabezado de O/C

Líneas de la O/C

Diagrama de colaboración

Diagrama de diseño de clases

JUAN BRAVO C. 34

CAPÍTULO 1. MÉTODO PARA LA GESTIÓN

DE PROYECTOS

Capítulo 1. Método para la gestión de proyectos

El papel de la arquitectura de software es parecido al papel que juega la arquitectura en la construcción de edificios. El edificio se contempla desde varios puntos de vista: estructura, servicios,

conducción de calefacción, fontanería, electricidad, etc. Esto permite a un constructor ver una imagen completa antes de que comience la construcción. Análogamente, la arquitectura en el

sistema de software se describe mediante diferentes vistas del sis-tema en construcción.

BOOCH, JACOBSON y RUMBAUGH (2000, p. 5)

Este capítulo introduce en los conceptos y la necesidad de contar con un método completo para la gestión de proyectos en la organización, no sólo en el ámbito tecnológico.

Esta es la primera competencia considerada para apoyar la elaboración de modelos de una solución de software, tal como se aprecia en la siguiente fi-gura (en la introducción se incluyó la visión global de las competencias). Es necesario que el analista conozca la totalidad de pasos de un proyecto para insertar su aporte. Podríamos decir que es un conocimiento de tipo horizon-tal, con “visión de procesos”, porque se refiere a entender la totalidad de la gestión de proyectos, independiente de que su foco estará en las etapas de






CAPÍTULO 6. UML




análisis y diseño.

La visión global, sistémica, que ofrece un método es indispensable para en-tender la totalidad que surge de necesidades concretas en la empresa que los proyectos ayudarán a resolver creando una habilidad organizacional9.

Al método que presentamos en estas páginas le hemos llamado GSP (Gestión Sistémica de Proyectos), es resultado de extensas investigaciones acerca de las mejores prácticas de proyectos y es un extracto del libro Gestión de proyectos de procesos y tecnología, señalado en el prólogo.

Trabajar metodológicamente es una competencia indispensable para todo pro-fesional del área de proyectos y para todo tipo de proyectos, ya sea que estén orientados a procesos del negocio, de apoyo o estratégicos. Por otra parte, toda organización debe contar con un método para la gestión de sus proyectos.

Las etapas son los grandes bloques que aporta el método GSP: concepción, factibilidad, análisis, diseño, implementación, despliegue y operación.

Las etapas están agrupadas en tres fases: estudio, desarrollo y mejora conti-nua. Tanto las etapas como las fases se pueden traslapar en los límites.

También existen prácticas transversales a las etapas, es decir, aplican en algu-nas o en todas las etapas del método. Son 28: dirección del proyecto, plan de la etapa, exposición de los planes, retroalimentación, equipo de trabajo, entre-vistas, comunicación, informes, técnicas, herramientas de apoyo, trazabilidad, Quick wins, costos y duración, gestión de riesgos, gestión de la calidad, res-ponsabilidad social, inserción, orientación al cliente, sensibilización, capacita-ción, seguimiento, cuidar la solución anterior, continuidad operacional, plan de recursos físicos del proyecto, kill time, control de cambios, gestión del cambio y gestión de proveedores.

Veremos: • Trabajar metodológicamente • Claves de la implantación de método • Adaptación y profesionalismo • Etapas genéricas • Prácticas transversales

9 Por habilidad organizacional entendemos una “competencia” que adquiere la empresa me-diante una solución de software, por ejemplo, ahora puede vender a través de Internet o tener su contabilidad al día.

JUAN BRAVO C. 36

1.1. TRABAJAR METODOLÓGICAMENTE

En la Edad Media, la incorporación a un oficio, hacer zapatos o construir cate-drales, era una iniciación en un gremio muy cerrado. El “arte” o secreto de los maestros se transmitía desde éstos a principiantes a través de la revelación de los misterios del oficio.

De la misma forma comenzó el desarrollo de proyectos tecnológicos, con ini-ciados que conocían los secretos del arte y que parecían estar juramentados para no revelarlo. Sin embargo, no ha sido necesario que transcurrieran 400 años para que ese arte se transformara en tecnología, tal como ocurrió con la mayoría de los oficios de la Edad Media.

En la gestión de proyectos TI han bastado sólo 40 años para que la situación cambiara drásticamente.

Hoy sabemos cómo hacer gestión de proyectos y ese conocimiento está al al-cance de todos en la forma de métodos de alcance bastante amplio.

Una definición de la gestión de proyectos hace Alejandro Covacevich (1994, p 82): “Un proyecto es un conjunto de acciones y recursos que tienen un objeti-vo no recurrente y un plazo o un costo fijos… para ejecutar un proyecto en que intervienen personas y recursos físicos, se necesita un ejecutivo que plani-fique, organice, dirija, controle y coordine. Todas esas acciones configuran la gestión del proyecto, que generalmente será más compleja mientras más re-cursos y personas intervengan”.

Veremos: 1. ¿Qué es método? 2. Las mejores prácticas 3. Fundamento conceptual: la visión sistémica 4. Método GSP

1. ¿Qué es método? Antes de continuar, aclaremos ¿qué es método? Consideramos que es una competencia básica 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 demás participantes del proceso.


Se desprende de la definición que método está asociado con personas, quienes deben trabajar metodológicamente, lo cual aplica para todo tipo de procesos y proyectos de cambio organizacional.

Las prácticas que adquieren las personas con la competencia método se pue-den ver como un continuo que comienza desde la toma de conciencia de “cómo lo hacemos” (ya sea un proceso operativo o un proyecto) hasta aplicar mejora continua, rediseño e innovación sobre esa secuencia.

Refiriéndose a la buena gestión de proyectos, Campero y Alarcón en su libro Administración de Proyectos Civiles señalan (1999, pp. 2-3): “Los buenos resultados de una administración serán el producto de condiciones personales de los responsables y de las técnicas de administración que empleen. Cumplir con las metas programadas de costo y plazo no resulta fácil y existe una alta posibilidad de arriesgar los beneficios y costos esperados. Un estudio realiza-do por Thompson y Perry usando un gran número de proyectos del Banco Mundial, indica que, de 1.778 proyectos revisados, en el 63% de los casos el costo final superó el presupuesto, de 1.627 proyectos revisados, el 88% ter-minó con atraso. De 42 proyectos controlados, el 70% de ellos no alcanzó a la tasa interna de retorno (TIR) esperada”.

2. Las mejores prácticas El método presentado surge de revisar y ensayar con las propuestas de lengua-jes, normas de calidad y herramientas que el mercado ofrece, aprendiendo de tales opciones e incorporando las mejores prácticas para aplicar en las organi-zaciones de Latinoamérica, donde podemos profundizar en trabajar con cali-dad y excelencia.

Es un método genérico porque la idea es conocer y seleccionar del medio las mejores técnicas (causa-efecto, creatividad, mapa de procesos, flujograma de información, UML, ITIL, PMI, orientación a objetos y otras) avanzando hacia las estandarizaciones formales o de hecho.

3. Fundamento conceptual: la visión sistémica El modelamiento de soluciones de software tiene su base conceptual en la visión sistémica10, también conocida como pensamiento sistémico, visión aérea, aceptación del caos y de la complejidad.

10 El libro Análisis de sistemas se refiere en su totalidad a visión sistémica.

JUAN BRAVO C. 38

Peter Senge provee algunas claves en su libro La quinta disciplina (1992, p. 148): “La clave del pensamiento sistémico es la palanca: hallar el punto donde los actos y modificaciones en estructuras pueden conducir a mejoras significa-tivas y duraderas. A menudo la palanca sigue el principio de la economía de medios, buscando el lugar donde los mejores resultados no provienen de es-fuerzos en gran escala sino de actos pequeños y bien focalizados. El pensa-miento asistémico resulta perjudicial porque nos induce a efectuar cambios de bajo apalancamiento: nos concentramos en los síntomas donde la tensión es mayor y reparamos o aliviamos los síntomas. Pero esos esfuerzos a lo sumo, mejoran la situación en el corto plazo, y la empeoran en el largo plazo”.

Conviene conocer algo de la visión sistémica porque nos ayuda a entender por qué hemos organizado el mundo tal como lo conocemos, en fragmentos, bus-cando especialización. También nos ayuda a pensar en integralidades, en vol-ver a unir las partes de los rompecabezas que hemos creado. Este nuevo para-digma tiene su propio campo de conocimientos y se nutre desde otras discipli-nas: antropología, sociología, psicología, pedagogía, todas las cuales aportan a una visión más amplia.

Una guía para modelar una solución de software

La visión sistémica será el gran fundamento conceptual que citaremos en este camino práctico del modelamiento de aplicaciones de software. Por ejemplo, nos ayuda a entender que un cambio en un modelo afectará a todos los demás, que la actitud de los diseñadores es fundamental y que el ánimo y la coopera-ción de quienes modelan es vital.

La visión sistémica nos ayuda a “ver” el todo, apreciar sus interacciones, la energía presente y descubrir sus características 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 autoorganización, la “inteligencia” de los sistemas y nuestra res-ponsabilidad con el bien común.

¿Qué es un sistema?

No existe una definición generalmente aceptada para un “sistema”. Tradicio-nalmente se lo entiende en dos aspectos: orientado al exterior en cuanto se encuentra situado en un medio donde interactúa 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 energía que toma la forma de interacciones y crea los elementos que sean necesarios para su evolución.


Dice Idalberto Chiavenato (2000, p. 769): “El concepto sistema pasó a domi-nar las ciencias y, en especial, la administración. Si se habla de astronomía, se piensa en el sistema solar; si el tema es fisiología, se piensa en el sistema ner-vioso, en el sistema circulatorio o en el sistema digestivo. La sociología habla de sistema social; la economía, de sistemas monetarios; la física, de sistemas atómicos, y así sucesivamente. En la actualidad, el enfoque sistémico es tan común en administración que no se nos ocurre pensar que estamos utilizándo-lo en todo momento”.

Y en este texto lo estamos aplicando a modelar soluciones de software…

4. Método GSP El Método GSP (Gestión Sistémica de Proyectos) es una guía para el desarro-llo completo de un proyecto, pasando por todas las etapas de su ciclo de vida: concepción, factibilidad, análisis, diseño, implementación, despliegue y ope-ración. Es un método abierto, con etapas genéricas, amplio uso de técnicas del medio, apoyo de herramientas existentes y aplicación de las mejores prácticas.

El Método GSP es parte de un modelo integral para la gestión de la innova-ción en la organización que contempla las definiciones estratégicas, formación de las personas, método, creación de estructura organizacional y apoyo tec-nológico (todos los elementos de la mesa señalados en la introducción y que se estudian en detalle en la etapa de análisis de la sección 1.4).

El plan de proyecto es una totalidad con contenidos mucho más allá de la carta Gantt, incluye también la historia del proyecto, cálculos financieros, justifica-ción de la necesidad y mucho más según veremos en la etapa de factibilidad en la sección 1.4.

Además, el plan de proyecto contempla dos líneas de trabajo paralelas, como las vías del ferrocarril:

• Etapas del proyecto • Prácticas transversales

Shari Pfleeger señala (2002, p. 135): “Para comunicar a los clientes el análisis y la gestión del riesgo, el cronograma y la organización, usualmente se escribe un documento denominado plan de proyecto. El plan deja por escrito las nece-sidades del cliente, así como lo que se espera hacer para satisfacerlas. El clien-te puede remitirse al plan para tener información sobre las actividades del pro-ceso de desarrollo, siendo fácil seguir el avance del proyecto durante el desa-rrollo… Un buen plan incluye los siguientes items: alcance del proyecto, cro-

JUAN BRAVO C. 40

nograma, organización del equipo de trabajo, descripción técnica del sistema propuesto, estándares del proyecto, procedimientos y técnicas y herramientas propuestas”. La lista se extiende hasta los planes específicos para las prácticas 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 método GSP.

Figura 1-1. Totalidad del método GSP

Etapas del método genérico(CFADIDO)

Dirección del proyecto

Plan de la etapa

Gestión de riesgos

Retroalimentación

Capacitación

Entrevistas

Comunicación

Informes

…y las otras 20…

Prácticas Transversales

Método GSP

ConcepciónFactibilidad

AnálisisDiseño

ImplementaciónDespliegue

Operación


1.2. CLAVES DE LA IMPLANTACIÓN DE MÉTODO

Son claves que guían el trabajo en la implantación de método. Previo, es nece-sario sincerar lo que realmente hace la organización con método y lo que está dispuesta a aplicar.

Método no es algo que solamente se compra y usa, como una máquina, tam-poco se puede internalizar mediante pastillas (ni disponemos todavía de la tecnología de la película Matrix, aquella donde Neo aprendía rápido mediante un tubo conectado directamente al cerebro).

Método tiene que ver con el desarrollo de competencias de las personas, con un trabajo arduo de generar estándares internos y sumarse a normas externas.

Hemos detectado 4 claves, son recursivas, es decir, también aplican para los proyectos que utilizarán el método en la organización.

Clave 1. Cinco mapas globales para la visión de conjunto Clave 2. Mínimo indispensable Clave 3. Participación de todos los actores Clave 4. Circularidad

Clave 1. Cinco mapas globales para la visión de conjunto Además de ver el método en su totalidad, la visión de conjunto se apoya en cinco mapas globales: necesidades, proyectos, procesos, retroalimentación y sistemas, los cuales veremos en las siguientes páginas.

Cada mapa debe tener una documentación de apoyo con los atributos de cada componente, su propia base de datos y el registro de cambios. Por supuesto, es vital mantener una versión actualizada de cada uno de ellos.

Los mapas deben estar disponibles para toda la organización en dos formatos:

• En digital, según las herramientas elegidas por la organización y que sean de fácil acceso para todos.

• En papel, en la forma de un mapa territorial, completo, que puede es-tar pegado en la pared. No hay problema que tenga varios metros de largo. Así efectivamente es una visión de conjunto. A esto le llamamos mapa global. Se recomienda por su gran efectividad.

Siendo tan reciente la aplicación de la visión sistémica en el modelamiento, no existe todavía una forma normalizada de cada mapa, así es que eso puede ser una buena alternativa de flexibilidad para seguir experimentando.

JUAN BRAVO C. 42

Estos mapas deberían crearse como parte de la implantación del método, aun-que adaptando según la cultura y el nivel de avance previo de la organización.

a) Mapa de Necesidades

Señala las necesidades genéricas de la organización que se están estudiando y resolviendo. Cada vez que se detecta una necesidad genérica se incluyen cau-sas y soluciones. En la figura 1-2 se muestra, como ejemplo, dos estudios para responsabilidad social.

Figura 1-2. Mapa de necesidades con problemas y soluciones

La idea de fondo es aplicar generalización 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 genéricos y hacer que la orga-nización como un todo sea más inteligente.

Problemas detectados:1. Pago tardío a

Proveedores2. Trabajadores fuman en

sector atención clientes

Responsabilidad Social

Tiempo

Calidad

Productividad

Bienestar

Costo

Soluciones propuestas:1. Alinear con la estrategia2. Incluir como plan de

acción de RS


b) Mapa de Proyectos

Muestra todos los proyectos que se están realizando en la empresa y permite establecer relaciones entre ellos. En el mapa de la figura 1-3 se usa para esta-blecer un sistema de vasos comunicantes entre proyectos, uno que libera per-sonas y otras que las requieren11.

Figura 1-3. Mapa de proyectos con relaciones para reubicar personas

Un mapa de proyectos tiene múltiples aplicaciones, por ejemplo, desde el pun-to de vista de responsabilidad social, ayuda a evitar despedir personas que quedan liberadas de procesos obsoletos, ellos pueden aportar en otros proyec-tos. Lo mismo es válido para los recursos de la empresa: espacio físico, equi-pamiento, etc…

11 Hemos visto que más o menos un tercio de los proyectos libera personas y recursos, el otro tercio requiere y el último es neutro.

7p

10p

2p

1p

= Libera

= Requiere= Neutro

JUAN BRAVO C. 44

c) Mapa de Procesos

Quedan reflejados todos los procesos de la organización, ya sean estratégicos, del negocio o de apoyo. Nótese en la figura 1-4 que la práctica es ubicar arriba los procesos estratégicos, 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).

DesarrolloPlanificaciónEstratégica

RSGestión deProcesos

Gestión deProyectos

Gestión deCalidad

Control deGestión

Gestión deContratos

AdquisicionesServiciosBásicos

Finanzas LegalRemuneraciones

y bienestarTecnología yMantención

Gestión de PersonasProcesos Estratégicos

Proceso del Negocio Comercializar

Procesos de Apoyo

Recibir

Emitir traspaso

Planearcada local

Traspasar

Distribuir

Prepararcada local

Presentar

Coordinarmerchand.

Ordenar Vender al detalle

Atenciónal cliente

Servicio de garantía

Medición y seguimiento

Postventa

Conocer la demanda

VisitarClientes

Estadísticas internas

Proyectar ventas

Emitir O/C

Comprar

Recepcionar

Almacenar

Cotizar

Analizar cargos

Reclutar Inducir

Formar Diseñar carrera

Evaluar

Vender

Despachar

Cuadrar

TransporteContabilidad

Figura 1-4. Mapa de procesos de Fabrica de Electrodomésticos Linhogar

El mapa de procesos es una gran contribución de la gestión de procesos12 por-que permite que cada levantamiento y rediseño de procesos aporte al mapa global y viceversa, evitándose la práctica tan cara de repetir el levantamiento de un cierto ámbito en cada aplicación de software, en proyectos de gestión de calidad o cualquier otro.

12 Ver libro del mismo nombre.


d) Mapa de Retroalimentación

Lleva registros de eventos enriquecedores al finalizar los proyectos. Conviene conocerlos ya sea porque son experiencias que es bueno replicar o porque hubo sucesos que queremos evitar. En la figura 1-5 se usó la forma de un ma-pa mental. Nótese que se evitó la distinción “positiva” o “negativa” de expe-riencias porque todas las vivencias sirven en la medida que haya una buena retroalimentación y que efectivamente se use en proyectos futuros.

Figura 1-5. Mapa de retroalimentación para replicar o evitar

Es fundamental que el mapa este a la vista y siempre actualizado. Así se pue-de capitalizar la retroalimentación.

Hay lugares donde se hace retroalimentación en un informe de fin de proyecto que luego queda archivado y nadie lo lee. No sirve, esa información debe estar viva, por eso es que se promueve que este mapa y los demás estén pegados en las paredes donde sean visibles y su rica información sirva.

Alcance poco claro

Dificultades para coordinar entrevistas

con usuarios

Liderazgosistémico

Meditación

= Experiencias para evitar

= Experiencias para replicar

Retroalimentación deeventos destacados

Demora en entrega

final

Buen trabajo en equipo

JUAN BRAVO C. 46

e) Mapa de Sistemas Computacionales

Indica las aplicaciones que existen en la organización y las relaciones princi-pales entre ellas. En la figura 1-6 se consideraron algunos sistemas tradiciona-les. En la medida que se considere necesario, sobre la línea se pueden indicar las entradas y salidas, como en un diagrama de contexto.

Figura 1-6. Mapa de Sistemas Computacionales

Junto con el mapa de procesos y el modelo conceptual de datos de la organi-zación, este mapa de sistemas computacionales es vital para modelar la solu-ción de software. Al proporcionar las entradas y salidas y que además estén visibles para todos los analistas y constructores, se avanza hacia un esquema de componentes, tal como proponen las nuevas normas, estándares y concep-tos (UML, SOA y otros que veremos en los capítulos de este libro).

DevoluciónCobranzas

Ventas

EntregaBodegaCompras

Recepción

Facturación


Clave 2. Mínimo indispensable Se trata de negociar el alcance de la implantación del método bajo el criterio del mínimo indispensable, es decir, el mínimo que todos los interesados se comprometen a cumplir, no por imposición, sino por reflexión o toma de con-ciencia. Aplica aquí la ley de los pocos críticos y muchos triviales de Vilfredo Pareto.

No se refiere exactamente a la interpretación de Juran del 80-20 —se logra el 80% de avance con el 20% del esfuerzo— sino que a una negociación respec-to a lo que se considere mínimo para la organización particular.

El mínimo indispensable significa un método flexible y preciso, bien adaptado a la realidad de la organización y de cada proyecto particular, porque su orien-tación es simplicidad, flexibilidad y aplicabilidad, para que realmente sea uti-lizado en las organizaciones latinoamericanas.

Es importante considerar que este mínimo indispensable estará influido por la cultura de la organización en cuanto a disciplina y estandarización. Por ejem-plo, lo más probable es que en una empresa certificada en normas de calidad sea más fluida la implantación de método debido a que ya están familiarizados en la definición y uso de procedimientos.

Clave 3. Participación de todos los actores Implantar un proceso de gestión de proyectos en la organización es una tarea de todos. El método que se decida no puede ser propiedad de una parte de la organización, 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 organización, él paga los sueldos de todos y es a quien sirven los proyectos en definitiva. Por lo tanto, se debe validar cada proyecto a la luz de sus intereses.

• El usuario es quien hace uso de los sistemas para servir a los clientes. Se pueden identificar usuarios ejecutivos y usuarios operativos.

• Profesionales de proyectos forman el equipo de trabajo: gerente de proyec-to, especialistas en procesos y tecnología, además de consultores.

• La alta dirección, gerencia u otra autoridad se encarga de la toma de deci-siones respecto al proyecto.

Luego, es necesario definir los roles de cada uno con relación al método y la forma en que se abordará su incorporación, habitualmente es una combinación de sensibilización, capacitación y coaching.

JUAN BRAVO C. 48

Es interesante observar que solamente difundir el método es un proyecto en sí mismo, donde aplica todo lo indicado en este texto.

Clave 4. Circularidad Implantar un método puede seguir la forma de desarrollo en espiral. Así, en un par de meses la organización ya podría estar usando un proceso documentado y disfrutando de los beneficios de proyectos realizados con efectividad.

Con el desarrollo en cascada la implantación puede ser larga, muy larga, ¿dos años? ¡Demasiado! podría 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 método es el buen manejo del cambio, donde se plantea que un sistema en buen funcionamiento es una joya que debe tratarse con mucho cariño. Debe-mos asegurarnos que lo nuevo es efectivamente mejor, sin el encandilamiento transitorio que tanto daño provoca.


1.3. ADAPTACIÓN Y PROFESIONALISMO

Entendemos la adaptación del método en varios sentidos: incorporar estándares, normas de calidad y aprendizajes del medio (tal como los aportes del PMI), ac-tualización permanente, flexibilidad para abordar todo tipo de proyectos y nego-ciación para tener una estructura organizacional adecuada.

Por profesionalismo aplicado al método entendemos la conducta ética y visión global que todo profesional debiera tener.

Veremos: 1. Adhesión a estándares y normas de calidad 2. Actualización y adaptabilidad del método 3. Estructura para la gestión de proyectos 4. Aportes del PMI 5. Ética y visión global del profesional

1. Adhesión a estándares y normas de calidad El método GSP existe para la buena gestión de proyectos y tiene una comple-jidad que no puede ser reducida artificialmente, porque corremos el riesgo de simplificar demasiado.

Además de cumplir con la normativa interna y externa obligatoria, el método GSP es abierto y se enriquece trabajando con estándares formales o de hecho, tales como: mapas de procesos globales, flujogramas de información con el criterio curso normal de los eventos, normas ISO, orientación 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 información y la habilidad de re-presentar adecuadamente el flujo de los procesos, así es que incluimos algunas palabras al respecto.

Información de calidad

El ideal es que todo el manejo de la información sea en línea y que los datos sean capturados en la punta del proceso, evitando digitaciones. Además, trabajar todo lo posible en formato digital. Una buena idea es un programa del tipo pa-perless (sin papel) que están impulsando muchas organizaciones.

JUAN BRAVO C. 50

En el método GSP se reconoce la importancia de la información y sus atributos: oportuna, completa, confiable, creíble13, 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 teoría de modelos y es central en la nueva generación de técnicas visuales. Lo veremos en detalle en el capítulo 3 (teoría de modelos).

La idea general es tratar las excepciones como excepciones, sin darles el mis-mo espacio visual que el curso normal de los eventos, en esto debe existir armonía con la realidad, donde lo más habitual aparece más y lo menos, me-nos. Se aplica especialmente en flujogramas de información 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 aplicación del criterio curso normal de los eventos va junto a un nuevo principio: el SPPP (Simplificar Procesos y Potenciar Personas) el cual aban-dona la antigua, peyorativa e inútil pretensión de “construir sistemas a prueba de tontos”.

2. Actualización y adaptabilidad del método El concepto es que se planifica al comienzo y se continúa planificando durante todo el proyecto, por la imperiosa necesidad de mantener actualizadas las de-finiciones, porque si sólo existe el plan inicial, rápidamente pierde sentido por la dinámica 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 afirmación de Murphy: “si algo puede fallar, fallará”. Por lo tanto, si queremos que la aplicación tenga éxito, debe-mos actuar con pragmatismo y adaptar el método según el tipo de proyecto. Es lo que veremos a continuación.

13 Un dato puede ser confiable pero no creíble. Es que la confiabilidad pertenece al sistema y la credibilidad al usuario, por eso decían: la mujer del César no sólo debe ser virtuosa, sino además parecerlo.


Pragmatismo

Pragmatismo es hacer lo mejor que se pueda hacer para lograr los objetivos de un proyecto, es lo opuesto al fundamentalismo, más bien sería el complemen-to, como en el yin y yang (la armonía de los opuestos, el justo medio que pro-clama Confucio).

No es sinónimo de improvisación ni de liviandad en seguir un método. Es darse cuenta que en un momento del tiempo hay una bifurcación mejor a la “establecida”.

A propósito, Jeff Davidson, en su libro La Gestión de Proyectos (2001, pp. 21–23), ofrece siete sugerencias para triunfar en la gestión de proyectos:

• Aprender a utilizar eficazmente las herramientas de gestión • Saber hacer y recibir críticas • 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 adaptación a nuevas circunstancias. Hay problema cuando el motivo es porque la etapa anterior no se hizo correctamente.

Adaptación según tipo del proyecto

La idea es adaptar el método a cada tipo de proyecto según su tamaño, nivel de avance y otras condiciones, aunque sin llegar a saltarse etapas. Se puede negociar las actividades que incluiría y el alcance de las prácticas transversa-les.

Es lo que explica Alfredo Weitzenfeld en su libro acerca de ingeniería de software (2005, p. 35): “Una creencia común, aunque equivocada, es la exis-tencia de un solo modelo de proceso aplicable a cualquier proyecto, pues el modelo de proceso depende del tipo particular de proyecto, por ejemplo: pri-mer proyecto de su tipo, segundo proyecto de su tipo, variación de un proyec-to, reescritura de software existente, creación de software reutilizable y pro-yecto de mejora o mantenimiento”.

JUAN BRAVO C. 52

Esa es la idea de la figura 1-7, donde el método de la organización es una base de conocimiento que se adapta a cada tipo de proyecto particular, aunque, por supuesto, mantiene un tronco común.

Figura 1-7. Adaptación del método a cada tipo de proyecto

Por ejemplo, la prioridad, puede llevar a tener una especie de Fast Track (vía rápida) en el caso de proyectos prioritarios por alguna contingencia o por ne-cesidades estratégicas.

En el caso del tamaño del proyecto lo primero es definir que se entiende por tamaño, por ejemplo, una posibilidad es trabajar con distinciones simples, como estas, aumentando un orden de magnitud cada vez (aceptando que los límites entre tramos son difusos):

• Proyecto pequeño: hasta US$ 100.000 • Proyecto mediano: más de US $ 100.000 y hasta US$ 1.000.000 • Proyecto grande: más de US$ 1.000.000 y hasta unos US$ 10.000.000

Más allá son proyectos muy grandes para la realidad de Latinoamérica y más bien escasos. Debería hacerse un esfuerzo metodológico especial.

El método debe adaptarse a cada realidad porque no es lo mismo un proyecto pequeño que uno grande en términos de cantidad de actividades, controles y cantidad de participantes. Desde la gestión de procesos sabemos que el tama-ño determina nuevas formas de hacer las cosas.

Método de la Organización

Aplicación a un tipo de proyecto

Adaptación


3. Estructura para la gestión de proyectos La buena gestión de proyectos también tiene que ver con una serie de instan-cias de estructura organizacional o funciones.

Esto es lo que se denomina “incorporar” a la organización, es decir, llevar al cuerpo, “hacer carne”, sumar a la estructura organizacional.

Algunas de estas instancias son:

• Área de metodología 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 más ade-cuada:

• Necesidades: estudios • Proyectos: desarrollo • Procesos: gestión de procesos • Retroalimentación: estudios y/o desarrollo • Sistemas: sistemas

Se presenta a continuación una breve descripción de cada área.

a) Área de metodología o UTP

En el área de metodología trabajan los responsables del método, quienes lo actualizarán y difundirán.

Puede tener además la forma de una UTP (Unidad Técnica de Proyectos) que se asegure de la formalidad metodológica de cada proyecto, es decir, se incor-pora aquí una labor más bien operativa.

También se le llama PMO (Project Management Office).

Eventualmente las áreas de metodología y de UTP pueden ser áreas diferentes y que trabajan coordinadamente.

14 Es la primera clave de la implantación de método de la sección 1.2.

JUAN BRAVO C. 54

b) Área de estudios

El área de estudios se dedica a procesar propuestas para necesidades y solu-ciones. Se centra en las etapas de concepción y factibilidad del método GSP.

Es un área que ayuda a generar mucha rentabilidad a la organización, 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 autorización 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 análisis, diseño, implementación y despliegue del método GSP.

Una exigencia es que el área de desarrollo se coordine con un área de asegu-ramiento de calidad.

d) Comité de Proyectos15

Considerando que los proyectos sirven a procesos estratégicos, del negocio y de apoyo en la organización, la figura del Comité de Proyectos (CP) introduce una mirada sistémica y de negocios.

El CP guía el proceso de detección de necesidades y formulación de proyectos (etapas de concepción y factibilidad del método).

También recibe la retroalimentación de los proyectos en desarrollo.

Por supuesto, el CP requiere una fórmula simple para administrar los com-promisos vigentes e históricos, así como definir la forma de toma de decisio-nes en casos de emergencia.

Al finalizar el proyecto, el CP cierra la carpeta del proyecto con un informe que señale cómo 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 desafío es organizar un equipo de personas que actúen con efectividad y mística en la toma de decisiones.


cómo se comportaron el plazo, costo y otras variables respecto al plan. El in-forme lleva la firma de todos los actores relevantes.

Esto es independiente de los entregables por cada etapa cuya aprobación de-pende de la estructura que el mismo CP aprobó.

e) Áreas relacionadas

En la gestión de proyectos se trabaja con áreas cercanas, tales como gestión de procesos, gestión de la calidad y sistemas.

4. Aportes del PMI PMI son las siglas del Project Management Institute, una organización de cla-se mundial que recoge las mejores prácticas para la realización de proyectos y las presenta en documentos, uno de los más relevantes es el PMBOK.

Se incluyen algunas palabras acerca de los aportes del PMI porque cada vez con mayor frecuencia las empresas más avanzadas requieren profesionales preparados y certificados.

El método propuesto por el PMI para la gestión de proyectos tiene muchos puntos de encuentro con el método GSP (recuérdese que la GSP es una reco-pilación de las mejores prácticas) y es conveniente conocerlo16.

El PMI define 5 grandes fases para todo proyecto: • Iniciación • Planificación • Ejecución • Control • Cierre

Similar a las prácticas transversales de la GSP, se definen nueve áreas de co-nocimiento: integración, alcance, costo, tiempo, calidad, recursos humanos, comunicaciones, riesgo y adquisiciones. Son grupos de criterios generales para la buena gestión y administración de proyectos.

Existe una organización local en la mayoría de los países de Latinoamérica, son llamados “Capítulos”.

Más 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. Además de estándares formales o de hecho tales como ITIL, Corba y MDA. Todos ellos los veremos en el capítulo segundo.

JUAN BRAVO C. 56

Gestión de calidad en proyectos

Es un tema fundamental abordado por todos los métodos existentes, por ejem-plo, en el PMBOK del PMI se lee:

La GCP (Gestión de Calidad en Proyectos) incluye los procesos requeridos para asegurar que el proyecto satisfará las necesidades por las cuales fue iniciado, contempla: planificación de la calidad, aseguramiento de la calidad y control de calidad.

• La Planificación de la calidad identifica qué estándares de calidad son relevantes para el proyecto y luego determinar como satisfacerlos.

• El Aseguramiento de la calidad incluye todas las actividades, planificadas y sistemáticas, implementadas en el marco del sistema de calidad, reque-ridas para brindar confianza en que el proyecto va a satisfacer los están-dares de calidad relevantes.

• El Control de Calidad implica verificar los resultados específicos del pro-yecto para determinar si estos cumplen con los estándares de calidad re-levantes e identificar maneras de eliminar las causas de los resultados in-satisfactorios.

Se complementa con la definición en de la norma ISO 9001:2000 “Calidad es la totalidad de las características de una entidad que le confieren la aptitud para satisfacer las necesidades implícitas y establecidas”.

5. Ética y visión 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 visión global, ambos considerados dentro de trabajar metodológicamente.

Comportamiento ético

Respecto a la ética de los profesionales, Ian Sommerville señala (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 estándares normales de honestidad e integridad. No debería utilizar su capacidad y sus habilidades para comportarse de forma deshonesta o de forma que deshonre la profesión de la ingeniería del software. Sin embargo, existen áreas donde los estándares de comportamiento aceptable no están acotados por las leyes, sino por las más tenue noción de responsabilidad profesional. Algu-


nas de estas son: confidencialidad, no falsificar su nivel de competencia, dere-chos de propiedad intelectual y uso inapropiado de los computadores”.

Visión y acción global

Sucede a veces que el punto de partida de un proyecto es la definición de una necesidad computacional. En tal caso puede ocurrir que no existan otros pro-fesionales para desarrollar la estrategia y los demás elementos del modelo de negocios: personas, procesos y estructura organizacional. En tal caso, la práctica ha sido que los mismos analistas encargados del desarrollo computa-cional del sistema de información se encarguen del desarrollo completo del modelo de negocios, al menos en el mínimo indispensable. Otra opción es que el analista avise de esta situación para que otras personas se encarguen de cu-brir lo que falta del modelo de negocios.

Un analista de sistemas debiera tener la capacidad de trabajar en “la mesa” completa. Para ello es vital una formación lo más completa posible17.

Pasión por conocer la finalidad, el para qué

Por otra parte, todos los actores del proyecto deben tener claridad en objeti-vos, resultados y propósito alineado.

Más allá de los entregables por etapa, es vital definir y conocer lo que se quie-re lograr, los objetivos finales. Tener la vista puesta en el destino ayudará a darle sentido a todas las actividades del proyecto.

Aconseja Davidson (2001, p. 33): “Al tener una idea clara del final deseado, todas las decisiones que se tomen respecto al proyecto irán en el mismo senti-do con más probabilidad de lograr ese final deseado”.

17 Ver libro Análisis de Sistemas.

JUAN BRAVO C. 58

1.4. ETAPAS GENÉRICAS

Ya vimos que las etapas son las distinciones principales del trabajo en el pro-yecto. Hemos identificado siete: Concepción, Factibilidad, Análisis, Diseño, Implementación, Despliegue y Operación. El acróstico es CFADIDO.

En la figura 1-8 (como una punta de flecha) se aprecia el esfuerzo promedio estimado de cada una18. Nótese que a partir de la etapa de diseño se expande el trabajo incorporando la especialización de otros actores.

Figura 1-8. Esfuerzo estimado por etapa en el método GSP

Se aprecia también que las etapas están agrupadas en tres grandes fases:

• Estudio: donde se detectan necesidades y se proponen soluciones, el entre-gable es un plan de proyecto, además de los informes para trazabilidad. In-cluye las etapas de concepción y factibilidad.

• Desarrollo: donde el plan se materializa. El entregable es la solución com-pleta y en explotación. Incluye las etapas de análisis, diseño, implementa-ción y despliegue.

• Mejora continua: donde la solución ya en operación se mantiene y perfec-ciona. Contiene solamente la etapa de operación, la más extensa y que exis-te mientras dura la vida útil de la solución, lo cual también debería estar es-timado en el plan de proyecto.

Lo habitual es que cada fase sea realizada por equipos y áreas diferentes.

18 Este promedio es parte del método GSP, obtenido desde la duración estimada de las etapas en proyectos exitosos. Como todo promedio, es solamente un punto de referencia y no aplica a casos particulares.

C F A D I D O

Estudio Desarrollo MC

C F A D I D O

Estudio Desarrollo MC


¿Qué tienen en común la construcción de un edificio, el desarrollo de un sis-tema computacional, la creación de un nuevo producto o el rediseño de la es-tructura organizacional? Todos aplican el ciclo de vida de un proyecto. Antes de construir un edificio, alguien lo concibe y hace una evaluación del proyecto (como en las etapas de concepción y factibilidad), una vez aprobado, viene la fase de desarrollo, donde:

• Se hace arquitectura, es decir, una solución creativa que se representa en maquetas y que resuelve los grandes qué del edificio, tal como veremos que ocurre en la etapa de análisis para las aplicaciones de software.

• Se realiza la ingeniería de detalle, es decir, los planos detallados del edifi-cio, tanto de la obra gruesa como de todos sus componentes (ascensores, conductos eléctricos, etc.) similar a los cómo que detalla la etapa de dise-ño en el desarrollo de software.

Luego viene la construcción, que en el método GSP sería equivalente a las etapas de implementación y despliegue. Después, en ambos casos, sigue la operación y las mejoras.

Es similar al desarrollo de un nuevo producto: alguien lo gesta y luego define el producto, hace un diseño detallado, construye y da servicio postventa.

Es fundamental cumplir todas las etapas del método para lograr éxito en el pro-yecto. Que esto no se confunda con rigidez, porque es posible volver a etapas anteriores en un proceso de retroalimentación producto de las necesidades del proyecto. El objetivo es evitar errores que producirán dificultades cada vez ma-yores en los siguientes pasos.

Aunque todo proyecto tiene las mismas etapas, su alcance puede diferir según las condiciones particulares del proyecto.

Son importantes algunos aspectos comunes a todas las etapas:

• Revisar las prácticas transversales más relevantes para la etapa. • Entre cada etapa es necesario lograr la autorización de inicio por el Comité

de Proyectos, el usuario líder u otra autoridad. Es preferible no comenzar si no se cuenta con la aprobación correspondiente. Esto puede parecer eviden-te, sin embargo, es increíble 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 más de la enfermedad “ejecutivitis” de una jefatura que quiere todo “para ayer”.

• Revisar al inicio de la etapa que los documentos de entrada están vigentes, puede ser necesario actualizarlos (eventualmente rehacer la etapa anterior).

JUAN BRAVO C. 60

Una estimación de este esfuerzo debe estar contemplada en la autorización de inicio por parte de la autoridad.

• La entrada a una etapa es el entregable de la etapa anterior, más los entre-gables de las etapas anteriores, porque es necesario conservar la trazabili-dad del proyecto y es seguro que será necesario realizar cambios en mode-los que fueron resultado de una etapa anterior.

Veremos: 1. Concepción 2. Factibilidad 3. Análisis 4. Diseño 5. Implementación 6. Despliegue 7. Operación

1. Concepción Lo que da origen al trabajo en la etapa es un síntoma o una serie de síntomas que producen molestias (tal como pérdidas y atrasos). Decimos que es una confusión porque no sabemos realmente cuál es el problema de fondo.

El objetivo de esta etapa es concebir una necesidad, o un problema, definido como una distancia, entre donde estamos y donde queremos estar. El proble-ma de fondo nace desde la causa raíz de la confusión. Es necesario aclarar la confusión para obtener un enunciado validado, a eso le llamamos Problema.

La confusión es un conjunto de síntomas que toman forma de inquietud, dolor o dificultad. Por supuesto, la confusión lleva implícita una oportunidad.

Concepción

Entrada: síntomas o definiciones estratégicas

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 genéricamente de “Problema”, puesto entre comillas porque al comienzo resulta pretencioso llamarle así, hay muchos síntomas difíciles de interpretar, más bien lo que se tiene es una confusión o una sensación de molestia indefinida.

Entonces, la solución de la confusión es el problema.


Yendo a los fundamentos conceptuales, la visión sistémica tiene especial pre-dilección por invertir tiempo en la adecuada definición de los problemas, an-tes de hablar de las soluciones.

De hecho, en teoría de sistemas se dice que cuando uno descubre el verdadero problema, el de fondo, ¡la solución está incluida!

Nos podemos ayudar en esta etapa con una serie de técnicas, por ejemplo: causa efecto de Ishikawa, los siete por qué, Pareto, meditación, una noche de sueño y otras.

Esta salida también puede provenir desde las definiciones estratégicas o desde el mapa de necesidades de la organización, en ambos casos, se le considera una “necesidad”.

¿Es posible saltarse esta etapa cuando una necesidad proviene de un proceso de planificación estratégica, desde el mapa de necesidades o desde la obligato-riedad de implantar una norma? No, es preferible no saltarse la etapa aunque la necesidad sea obligada, porque igual es necesario cuantificar19 y dar un formato común para pasar a la siguiente etapa.

Aquí debiera hacerse un análisis estratégico desde el punto de vista de las ne-cesidades ¿el problema detectado es relevante para la organización? ¿se ajusta a la visión de negocios? ¿son necesidades de la industria o de la competencia relevante? Tal vez conviene dejar pasar el problema si no resuelve necesida-des estratégicas (recuérdese que todavía no hablamos de soluciones).

Durante la concepción tiene uso predominante el mapa de necesidades (ver sección 1.2, claves de la implantación de método).

Todo integrante20 de la organización puede detectar necesidades (ojalá en un formulario sencillo o una pantalla simple en el computador, no más de una página). Si se aprueba esa detección, el comité de estudios decide principal-mente dos caminos:

a) Solicita un estudio más detallado de la necesidad. b) Solicita el cierre de la etapa de concepción con el entregable que co-

rresponda.

19 Además, nunca la decisión es “obligada”, por ejemplo, una opción es que el dueño de la empresa decida cerrarla. Suena utópico, sin embargo, tomemos una situación real: la obligato-riedad de la incorporación de una norma de calidad a todas las empresas de capacitación de Chile en el 2006. ¿Resultado? sobre el 70% de las empresas prefirió cerrar. 20 En el libro Análisis de Sistemas, tercera y cuarta parte, se pueden encontrar mayores alcan-ces acerca de la importancia de la participación y de su impacto positivo en los resultados.

JUAN BRAVO C. 62

En ambos caminos recurre a profesionales especializados de dentro o fuera de la organización.

Es tan importante la detección de problemas y la consiguiente generación 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 línea, que trabajan en la frontera, están mejor situados que los directi-vos o los ingenieros para detectar los problemas y encontrar las soluciones. Aunque no permanezcan todo el día allí, a veces les bastan unos minutos para tener una idea útil”.

Un informe típico de esta etapa debería incluir los siguientes puntos.

• Ámbito del problema • Identificar el problema21

a) Exponer la confusión (síntomas) b) Buscar causas raíces y variables críticas 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 organización, viene dada desde la etapa de concepción. El objetivo es obtener el plan de proyecto de la solución después 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 investigación de soluciones y la evaluación

comparativa de alternativas de solución seleccionadas

La etapa de factibilidad22 tiene tres entregables secuenciales, se accede al si-guiente después de la toma de decisión por parte de la autoridad correspon-diente. Suponemos un Comité de Proyectos (CP) en lo que sigue. La toma de decisión sería después de realizar cada una de estas acciones:

21 En el libro Análisis de Sistemas se trata extensamente acerca del énfasis en el problema. 22 Un buen apoyo es el libro Desarrollo de sistemas de información, una visión práctica, páginas 50 a 58. También el libro Análisis de Sistemas, Quinta parte.


a) Una investigación creativa de muchas soluciones y propuesta de alter-nativas a estudiar.

b) Una evaluación comparativa de alternativas de solución seleccionadas. c) El plan de Proyecto de la alternativa seleccionada. Este plan considera

el programa de actividades (carta Gantt), la evaluación técnica, legal y económica, el VAN interno y social, el análisis de riesgos, la descrip-ción, el equipo de trabajo por etapa, el impacto estratégico, su historia, la evaluación comparativa, la justificación de la necesidad y todos los demás detalles del proyecto (comentamos también sobre su alcance en la descripción del método GSP de la sección 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 organización. Cada una incluye acciones respecto a las personas, procesos, estructura y tecnología, por supuesto, con diferente énfasis en cada una.

Usamos la palabra solución porque es más amplia y representativa que indicar solamente rediseño de procesos o aplicación computacional. Además, lo más probable es que la solución seleccionada resulte de una combinación de varias alternativas.

Creatividad aplicada

En esta etapa es vital la creatividad e inventiva aplicada en la búsqueda de soluciones.

Se exploran amplias posibilidades de solución al problema hasta decidir por la fórmula que se considere más apropiada.

Así evitamos la rigidez paradigmática que se produce cuando desde el princi-pio alguien cree que tiene “la solución”.

¿Qué técnica es buena para la invención? Además de las técnicas indicadas en la etapa de concepción, se puede mencionar: tormenta de ideas, seis sombre-ros para pensar, comparación con otras organizaciones, búsqueda bibliográfica y consultoría. También la integralidad en el conocimiento es importante, tal como señalan Getz y Robinson (2005, p. 32 ): “Deducimos que es la diversi-dad de conocimientos suficientes en una multitud de campos, y no el conoci-miento excepcional en un solo campo lo que contribuye al surgimiento de grandes ideas, y esto a través de asociaciones inesperadas”.

JUAN BRAVO C. 64

Por otra parte, existe un amplio abanico de técnicas23 que pueden ayudar a generar soluciones, por ejemplo: cadena de valor, just-in-time, flujos tensados, Kanban, producción flexible, costo objetivo, nuevas reglas del juego, salir del pensamiento dicotómico, armonizar las economías de escala con otras opcio-nes, logística, un sistema de gestión de iniciativas y muchas otras.

Getz y Robinson agregan (2005, p. 53): “Un sistema de gestión de ideas trans-forma el potencial creativo en acción creativa y despierta esa fuerza formida-ble que frecuentemente está dormida y desaprovechada en la empresa”.

Algunas actividades de esta etapa son:

• Conformar el equipo de trabajo • Revisar el problema • Describir el ámbito de trabajo • Plantear un ideal de solución • Plantear alternativas con amplia libertad • Definir un gran desafío • Identificar restricciones de la solución • Seleccionar alternativas y objetivos generales • Evaluar cada alternativa • Evaluar las alternativas en forma comparativa • Decidir la opción y los objetivos específicos • Elaborar el plan de proyecto

Algunas técnicas en la etapa de factibilidad: • Evaluación financiera • Técnicas de evaluación de programas y proyectos • Análisis costo-beneficio para la evaluación social de proyectos24 • Idealización y creatividad • Planificación de proyectos

También se debe revisar cada práctica transversal para incluir en el plan de proyecto. Recuérdese que cada una aborda aspectos fundamentales de los pro-yectos: incorporación del cliente y de los proveedores, costos, plazos, comuni-cación, riesgos, completitud, son 28 en total.

23 Detalladas en el libro Gestión de Procesos. 24 En el libro Responsabilidad Social se profundiza en este tipo de análisis.


3. Análisis Lo que da origen a esta etapa es el plan de proyecto aprobado. Es el inicio de la ejecución del proyecto.

El objetivo es plantear el modelo de negocios de la solución y los requeri-mientos correspondientes. El Qué.

Análisis

Entrada: el plan de proyecto aprobado

Entregable: el modelo de negocios de la solución con los requerimientos principales

Se trata del análisis integral de la solución. También es llamada ingeniería básica, ingeniería conceptual o arquitectura de la solución.

Desde aquí surgen las definiciones respecto al modelo de negocios de la solu-ción. Recuérdese la metáfora de una mesa: la cubierta es la estrategia y las 4 patas son: personas, procesos, estructura organizacional y tecnología. Estas definiciones ya están avanzadas desde la etapa de factibilidad.

El modelo de negocios es la visión integral de la solución y se apoya en un concepto o idea fuerza. Debe estar bien sustentado en la estrategia de la orga-nización, tal como se muestra en la figura 1-9.

Figura 1-9. El modelo de negocios como una mesa

Estructura

Personas

Procesos

Personas

Procesos

Tecnología

Estrategia

JUAN BRAVO C. 66

A diferencia del trabajo en la etapa de factibilidad, más bien general y desti-nado principalmente a cuantificar el volumen y tipo de trabajo, en el análisis se profundiza hasta decidir los qué de la solución.

El modelo de negocios es una totalidad que debe ser conocida por todos los integrantes del equipo de proyecto. Puede ser que sólo un analista y un usuario conciban el modelo. También puede ser que se requiera un equipo de trabajo de decenas de personas donde cada uno tiene la visión del todo, es decir, lo que veremos a continuación respecto a los elementos del modelo de negocios.

a) Estrategia

Es la estrategia del proyecto, con algunos contenidos como estos:

• Misión, visión, valores, imagen y demás definiciones que se presentan en el anexo 1, esta vez aplicadas al proyecto.

• Un concepto o idea fuerza que guíe la solución. Tal como la integrali-dad en el caso de la solución Vendedor Integral de grandes tiendas, la transparencia en una solución arquitectónica o personificar con humor, como en la campaña para ofrecer créditos de un banco en Chile, decían ¿Se te apareció marzo? Cuando alguien estaba tranquilamente en un bote terminando sus vacaciones y se le aparecía una persona (marzo).

Es importante destacar que la estrategia del proyecto debe estar sustentada y alineada con el plan estratégico formal de la compañía, 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? ¿Cómo aportan? ¿Cómo se capacitan? ¿Cuál es la gestión del cambio?

Hablamos de generar los requerimientos macro de la solución respecto a: sen-sibilización, capacitación, empoderamiento, participación, anticipación, am-biente de trabajo, forma de interacción y otros.

Se requieren planes orientados al equipo de trabajo, por ejemplo: selección, formación, información, participación, ambiente de trabajo, forma de interac-ción. También orientados a los usuarios de la solución, incluso de los clientes si es necesario (por ejemplo, cuando se introduce un tipo de apoyo automático para clientes de las sucursales de un banco y es necesario elaborar planes para enseñar su uso).

El trabajo con las personas considera dos aspectos vitales:


• La cultura de la organización (lo que no se ve): formas de relación, comu-nicación, tradiciones, creencias y mucho más, en directa relación con la es-trategia (ver anexo 1).

• Los detalles del ambiente (lo que se ve): tal como colores, aromas, sonidos, y texturas, más allá de los aspectos de estructura.

c) Gestión de Procesos

Se requiere la descripción del nuevo flujo de trabajo y de los procesos relacio-nados, ya sean del negocio o de apoyo, involucrados en el ámbito de trabajo del proyecto.

Las técnicas principales que se emplean son el mapa de procesos y el flujo-grama de información.

Por ejemplo, para una empresa comercial, el mapa de procesos del ámbito venta al detalle se vería como en la figura 1-10, un zoom de una parte del ma-pa de procesos global (ver figura 1-4).

CuadrarDespacharVender

Programar Entregar

Inmediato

A Crédito

Al Contado

A domicilio

Vender al detalle

Figura 1-10. Mapa de procesos

JUAN BRAVO C. 68

Se aprecia en la figura 1-10 que el macroproceso Comercializar incluye un proceso operativo: Proyectar ventas, más tres macroprocesos: Comprar, Vender al detalle y Servicio postventa. Luego el macroproceso Vender al detalle se abre en otra cadena donde hay otros macroprocesos y procesos operativos y así sucesivamente. Una de los macroprocesos, Despachar, se abre a su vez en dos procesos, uno operativo, In-mediato, y otro macro: A domicilio. Utilizaremos como ejemplo el proceso Despacho inmediato en el siguiente modelo, el flujograma de información.

Todo mapa de procesos debe iniciarse con los requisitos que impone el cliente y debe finalizar considerando el grado de satisfacción logrado por él.

Flujograma de Información (FI)

Junto con el mapa de procesos se emplea la técnica flujogramas de informa-ción —la cual veremos con cierto detalle en el capítulo 3— para describir los procesos operativos de la organización.

Podemos anticipar algunas características del FI25:

• Sigue el criterio del curso normal de los eventos (al igual que los casos de uso de UML) y el principio SPPP (Simplificar Procesos y Potenciar Personas), ya indicados.

• Tiene temporalidad • Está orientado a seres humanos, principalmente a los usuarios operati-

vos, para quienes debería ser autoexplicativo. • No es un diagrama de flujo computacional. • Debe caber en una página con letra de tamaño legible. • Las actividades con doble línea tienen alguna relación con TI y luego

dan origen a los casos de uso.

Un ejemplo se muestra en la figura 1-11.

25 Más detalle en el libro Gestión de Procesos, capítulo 11 (si usted sabía acerca de procesos pero no ha renovado su conocimiento, digamos desde el año 2000, es conveniente una nueva inmersión, el cambio ha sido grande en esta materia).


CLIENTE ÁREA DE VENTAS

VENDEDOR CAJERO

PROCESO VENDER A CRÉDITO

Vender

Aprobar en SC

OE

Formalizar

Emitir OE

CC

BODEGA

CC’

CC’

SC: Sistema de Créditos, CC: Comprobante del Crédito, OE: Orden de Entrega

PROCESOS DESPACHAR

Figura 1-11. Flujograma de información

Si se está utilizando el desarrollo en espiral, el detalle a nivel de los flujogra-mas de información podría ser parte de cada iteración. El mapa de procesos debería estar construido desde el principio y solamente se realizarían perfec-cionamientos en cada vuelta de la espiral.

Se debe realizar el diseño de formularios asociados al detalle de los flujogra-mas de información. Válido 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 tecnología.

JUAN BRAVO C. 70

d) Estructura organizacional

Se refiere a la definición de la nueva estructura organizacional desde la mirada que aporta el modelamiento de los procesos.

Los cambios van más allá de sólo crear o eliminar cargos (agregar, mover o sacar cajas del organigrama), alcanzan también a: planes y propuestas de ex-ternalización, delegación, trabajo en equipo, empoderamiento, más o menos supervisión, JIT, Kanban y SCM26, entre otros.

Hemos acuñado el dicho: “un pterodáctilo no es una mariposa grande”, en el sentido que tienen una estructura muy diferente y apropiada a su tamaño, asi-mismo debe ocurrir con la organización, su estructura depende del tamaño, del rubro y de otros factores.

e) Tecnología

En cuanto a la tecnología, se requieren planes para incorporar o adaptar tecno-logías consideradas en el proyecto: comunicación, transporte, movimiento automatizado de carga, despacho, almacenamiento, construcción, automatiza-ción de oficinas, telefonía interna y mucho más. Debiera incluir precisiones de propuestas, contratos, capacitación y en general, formas de implementación.

Luego, en la medida que se requiera una aplicación computacional, se procede a la ingeniería de requerimientos tecnológicos, los cuales pueden ser plantea-dos mediante la técnica UML (la conoceremos en el capítulo 6).

Un aspecto importante que debe quedar planteado en la etapa de análisis es el diseño 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 diseño 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 visión de procesos más allá de los límites de la organización, 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 señora que compra una manzana en un supermercado europeo.


Figura 1-12. Diseño general de la interfaz

4. Diseño Lo que da origen a esta etapa es el modelo de negocios de la solución con los requerimientos principales.

El objetivo es obtener el detalle de la solución que propone el modelo de ne-gocios, especialmente personas, procesos, estructura organizacional y tecno-logía. Es el Cómo. También se denomina Ingeniería de Detalle a esta etapa.

Diseño

Entrada: el modelo de negocios con los requerimientos principales

Entregable: el modelo de negocios con el detalle de requerimientos y la for-ma de implementar

El diseño detallado consiste en dibujar planos, preparar modelos, identificar los encargados, dimensionar los recursos financieros, definir el espacio físico, conocimientos requeridos, interacciones con el entorno, elaborar licitaciones y contratos.

Esto es necesario incluso en proyectos pequeños.

JUAN BRAVO C. 72

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 solución. Principalmente lo relacionado con personas, procesos, estruc-tura organizacional y tecnología.

Nótese que “se trabaja con” y no “se entrega o delega el trabajo a especialis-tas”, porque se trata de un trabajo conjunto.

En esta etapa normalmente se recurre a la asesoría especializada, porque hay que ir al detalle, probablemente empleando terminología más precisa. Algunas sugerencias:

• Trabaje en conjunto con el especialista hasta obtener el resultado deseado, porque habrá mucha labor de perfeccionamiento sucesivo, además, una vez que el especialista se retire, usted deberá seguir manteniendo la solución.

• Evite la dependencia total y no se deje amedrentar por la erudición, las sofisticaciones o la especialización. Un buen profesional no hace alarde de sus conocimientos y tiene la capacidad de explicar materias complejas con simplicidad.

• Conserve la visión de conjunto y asegúrese que los equipos de trabajo de-dicados a diferentes partes de la solución estén plenamente coordinados.

Más importante que una supercreación tecnológica, de estructura o de flujos de procesos, es desarrollar armónicamente la solución.

Muchos proyectos han fracasado porque cada ámbito de acción fue tomado por separado.

En esta etapa del ciclo de desarrollo de un proceso se trabaja en la preparación detallada de cada elemento de la solución y la forma de implementar, esen-cialmente el diseño de:

• El nuevo flujo del proceso con nombres de encargados y recursos • Procedimientos en detalle • El plan de capacitación y de implementación • Las nuevas labores a realizar • El ambiente físico y cultural • La nueva estructura organizacional • La red de comunicación • El detalle de equipamiento y software


También desde el punto de vista de los riesgos:

• ¿Cuál es el costo futuro de un mal diseño? • ¿Cuál es el costo futuro de no hacer diseño?

La parte del diseño computacional puede ser orientado a objetos, tal como se plantea en el capítulo 5 y mediante el uso de UML, tal como se indica en el capítulo 6.

5. Implementación Esta etapa nace desde el diseño de la solución.

El objetivo es llevar a la práctica (también construir o realizar) la solución detallada que propone el modelo de negocios, armonizando todas sus partes (estrategia, personas, procesos, estructura y tecnología). Se trata de “imple-mentar” el diseño en una aplicación real, aunque en carácter piloto.

Implementación

Entrada: el modelo de negocios con el detalle de requerimientos y la forma de implementar

Entregable: el piloto de la solución 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 aplicación de software, tal vez en máquinas diferentes.

Implementar significa “llevar a la realidad” el diseño, ya sean planos de un edificio, plan de capacitación, flujos de información, formularios, apoyo com-putacional, una política acerca de las personas o el diseño de una estructura organizacional.

Implementar también implica retroalimentar el diseño sobre aspectos no con-templados con anterioridad.

Es necesario asegurar paso a paso que la solución cumple su objetivo. La flexibilidad es fundamental para efectuar los ajustes necesarios sobre el plan original. La participación de todos los interesados, así como el manejo del cambio son vitales en esta etapa.

JUAN BRAVO C. 74

Se corren riesgos importantes en esta etapa, por ejemplo: el usuario ya no está comprometido con el sistema, el tiempo de implementación es muy largo, cam-biaron las condiciones previstas en el diseño o la aplicación es difícil de usar. En fin, por muchos motivos la implementación puede fracasar. ¿Cómo mitigar es-tos riesgos? La respuesta general es trabajar metodológicamente. En particular, asegurar la participación del usuario y mantener la continuidad entre el diseño y el uso de la aplicación.

Otras actividades de esta etapa son:

• Completar la documentación. • 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 capacitación 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 dólares en equipamien-to que ha quedado abandonado, debido a que el proyecto no contemplaba gastar en capacitación.

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 crítico de éxito. Justo cuan-do es necesario llevar los planes a la práctica, sucede que personas con que el analista contaba están destinadas a otras labores urgentes, espacios físicos que el analista sabía que tendría, no los tiene o un equipo computacional prometi-do no llegó. Supongamos además que todo ello está bien justificado.

Para este tipo de supuestos debieran existir planes de contingencia.

Una forma de mitigar este problema es acortar el tiempo de ciclo de los pro-yectos, puede ser a través del desarrollo en espiral.

Otra forma es negociar con base en la nueva realidad, ¿cómo? reiterando la actualidad de los objetivos que dieron origen a los compromisos asumidos, escuchando, intercambiando y buscando nuevas posibilidades creativas.

Es importante aclarar que negociar los compromisos no significa permisividad ni tolerar el incumplimiento de las tareas, sino que se trata de la simple adap-tación a las contingencias del mundo.


b) Implementar los procesos y la tecnología

Algunas recomendaciones para la implementación:

• Mantener comunicación con todos los actores involucrados. Por ejemplo, buenos resultados se han logrado con una reunión semanal breve con los consultores que apoyan el rediseño, el equipo asesor en metodología, el equipo de trabajo de tecnología, los usuarios, la dirección de la empresa y proveedores especializados de elementos de comunicación o infraestructu-ra, entre otros actores.

• Mostrar resultados pronto para mantener el nivel de entusiasmo —por ejemplo, a través de los quick wins, una de las prácticas transversales— con la precaución de no abusar de esa vía rápida porque el grueso del redi-seño y del apoyo computacional tiene que seguir el método (el desarrollo en espiral es recomendado).

• Tener la flexibilidad para resolver con rapidez los inevitables problemas que se producirán, es ideal tener una persona o un equipo “de acción rápi-da” como forma de lidiar con la complejidad27. Que esto no se confunda con improvisación ni que sea una excusa para una mala planificación, es simplemente responder con variedad a la variedad natural del medio, aque-lla difícil de predecir.

• Contar con la dedicación completa del líder28 y de los demás integrantes del equipo de trabajo, especialmente en la atención a los usuarios (puede ser rotativa a diversas horas). Es crítico en la relación con el usuario man-tener verdaderamente “puertas abiertas” y despejados todos los medios de comunicación. Es preferible invertir en disponibilidad de personas que en mayor equipamiento técnico (si se puede ambas cosas a la vez, mejor).

• Aplicar la estrategia tenaza, cuidar el corto plazo (la solución 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 solución en carácter piloto, considerando un período de prueba integral con datos reales y en la práctica. 27 El libro Análisis de Sistemas aborda el tema de la complejidad de los sistemas. 28 El autor tuvo el privilegio de asesorar en una conocida empresa minera en un proyecto de renovación tecnológica. Ocurrió que justo en el momento de la implementación el líder del proyecto se fue de vacaciones fuera del país… El fracaso estuvo cercano y sólo la excelente disposición de los usuarios y del resto del equipo lograron salvar la situación.

JUAN BRAVO C. 76

Al mismo tiempo se avanza en:

• Capacitación de usuarios piloto, quienes luego pueden hacer de instructores para los demás usuarios. Es importante la dedicación completa de estas personas al proyecto.

• Comunicación del avance.

Desde el punto de vista de la TI, la etapa contempla instalar el sistema en al-guna máquina específica y comenzar el uso real en una instalación piloto.

Es importante no confundir la instalación piloto con un prototipo. El piloto es para certificar en la práctica que la aplicación cumple con los requerimientos explícitos e implícitos y que luego se replica para todos los usuarios. El proto-tipo es para que el usuario vea un boceto de lo que quiere o para probar aspec-tos específicos de la funcionalidad, luego se desecha (en el caso más usado del prototipo del tipo usar y botar).

Una recomendación es asegurarse que efectivamente se usa lo nuevo. Y si lo nuevo no se usa, tal vez sea por razones fundamentadas, lo que llevaría a mo-dificar el proyecto.

6. Despliegue La etapa de despliegue nace desde la implementación piloto de la solución.

El objetivo es expandir la solución generada hasta ser bien utilizada por todos los usuarios previstos en el plan de proyecto.

Despliegue

Entrada: el piloto de la solución en buen funcionamiento

Entregable: la solución completa en buen funcionamiento y el informe co-rrespondiente

Se trata de instalar la solución 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 sensibilización ya debería estar lograda).

29 De acuerdo lo indicado en el libro Gestión de Procesos, se hace una distinción entre capaci-tación y entrenamiento. La capacitación se orienta al desarrollo de competencias generales. El entrenamiento (el training de F. W. Taylor) se refiere a la formación en los procesos específi-cos en que trabaja la persona.


• Los procesos rediseñados son implementados. • La nueva estructura organizacional se pone en marcha. • El software se instala en las plataformas correspondientes.

La etapa de despliegue también contempla las siguientes acciones:

a) Revisar y actualizar elementos

Se trata de asegurar la disponibilidad de todos los elementos para difundir la solución tecnológica:

• Manuales de usuario, del sistema o ayudas en línea. • Disponibilidad de equipamiento computacional. • Disponibilidad del software necesario. • Disponibilidad de licencias del software . • Disponibilidad de dispositivos de comunicación. • Una base de datos con las respuestas a preguntas típicas del despliegue.

También de cada atención a usuarios, quizá el mismo usuario pueda ingre-sar y detallar su solicitud.

Se requiere una mesa de ayuda, con opciones de soporte telefónico, Intranet, visitas en terreno y todo lo que se acostumbra en este caso.

Acerca de la capacitación: • Programas detallados de capacitación de usuarios piloto y monitores. • Programas detallados de capacitación según tipo de usuarios. • Comunicación directa con los proveedores de tecnología.

b) Incorporar a cada usuario

Aquí es necesario considerar al menos los siguientes elementos:

• Instalar en forma personalizada en cada máquina. • Definir cuales elementos del sistema se instalan en el computador del usua-

rio y cuales en el servidor. • Asegurar que los dispositivos de comunicación funcionan. • Disponer de un mapa de instalación, para conocer configuraciones físicas,

de software y de comunicación. • lograr la dedicación prevista de analistas, al igual que los instructores. Son

tantas las facetas de la aplicación que se requiere toda su dedicación. • Contar con la dedicación de los ejecutivos para facilitar el despliegue.

Conviene enfatizar los aspectos de comunicación, en todo sentido.

JUAN BRAVO C. 78

c) Capacitar a los usuarios

Capacitar según tipos de usuarios: usuarios operativos que interactúan con el cliente –tal como un cajero– supervisores que deben tomar decisiones rápidas con una mirada global de lo que sucede o ejecutivos que desean ver tenden-cias en un sistema computacional.

Para realizar el despliegue debemos recurrir a muchas instancias de comuni-cación rápida y efectiva, sobre todo si se trata de llegar a cientos o miles de usuarios, por ejemplo:

• Revisar y actualizar el material (el cual debería estar preparado desde las etapas de diseño e implementación).

• Desarrollar algún video explicativo cuando corresponda. • Utilizar Internet. Por ejemplo, a través de e-learning los usuarios se conec-

tan libremente y existen niveles de evaluación. Hay amplias experiencias positivas con el uso de esta técnica para la preparación de cajeros y de mu-chos otros tipos de usuarios operativos (mejora cuando se complementa con algún porcentaje presencial).

• Reuniones ampliadas de los gerentes dando la partida al proceso.

También “capacitar a los capacitadores” y cuidar los elementos pedagógicos. Un desarrollo impecable puede fracasar porque el especialista en informática no sabe transmitir el uso del software.

7. Operación La etapa de operación nace cuando la solución generada está siendo bien utili-zada por todos los usuarios previstos en el plan de proyecto. Requiere de la documentación generada en todas las etapas.

Operación

Entrada: la solución completa en buen funcionamiento

Entregable: mantener la solución en buen funcionamiento hasta que cumpla con su vida útil. La mejora continua es una actividad central.

El buen funcionamiento de la solución debe lograrse en todo el modelo de negocios (estrategia, personas, procesos, estructura y tecnología). Por lo tanto, la mejora continua opera en cada uno de sus elementos.


Cuando la solución está en operación comienza la mejora continua, la cual es compatible con el rediseño programado30.

Mientras se trabaja en una vuelta del desarrollo en espiral (suponiendo que se emplea esa técnica), no aplica todavía la mejora continua porque los casos de uso que se van desplegando están en desarrollo y todo el equipo de proyecto con los usuarios está atento a los cambios. Es decir, mientras la solución está en desarrollo existe la infraestructura para abordar el cambio mayor y menor.

Algunas actividades indispensables durante la operación son:

• Una mesa de ayuda • Buena operación de la aplicación • Gestión de la calidad • Rediseño programado de la solución

Algunas técnicas del mejoramiento continuo

Algunas de las técnicas31 más efectivas para la mejora de la aplicación son:

1. Las 3C 2. Benchmarking 3. 4. Flujograma de Información 5. Estandarización 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. Círculos de calidad 15. Diagramas causa-efecto (ver anexo 4) 16. Diagramas de Pareto (ver anexo 4)

Además de una amplia gama de técnicas cercanas a la estadística.

30 En el libro Desarrollo de sistemas de información, una visión práctica hay alcances adicio-nales bajo el título “Sistemas en Actividad”. 31 Se presentan aquí solamente como una muestra de la profundidad de la mejora continua, están detalladas en el libro Gestión de Procesos, capítulo 15.

JUAN BRAVO C. 80

Control de cambios

Se trata de establecer un procedimiento de aceptación de requerimientos me-nores en el ámbito de la TI. Ya sea obtención de nuevos informes o consultas, es indispensable seguir el procedimiento general del área de sistemas en cuan-to a requerimientos menores. Un ejemplo de procedimiento se presenta en la figura 1-13 y a continuación como texto.

Abreviaturas:

SC: Solicitud de Cambio

II: Informe de Impacto

PD: Plan de Desarrollo

DEPARTAMENTO DE INFORMÁTICA ÁREA DESARROLLO

JEFE INFORMÁTICA ANALISTA

PROCESO:EMITIR UNA SOLICITUD DE CAMBIO MENOR EN APLICACIONE S COMPUTACIONALES

Asignar Analista

SUBCOMITÉ CAMBIOS

Estudiar impacto

Casos de uso

Emitirinforme

II

Plan de Desarrollo

PDPD’

USUARIO AUTORIZADO

II ’

PD’’PROCESO IMPLEMENTAR

SC

SCII’

Figura 1-13. Flujograma de información 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 informática 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 aplicación y en otros sistemas • Calcula costo y recursos • Determina duración


• Entrega informe al subcomité de informática (encargado de los re-querimientos menores).

4. El subcomité de informática, con la participación especial del usuario, el jefe de informática y el analista que realizó el estudio de impacto, toma al-guna decisión de cambio. Se le envía 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 informática, incluyendo equipo de trabajo y costos, de acuerdo con las indicaciones del subcomité de informática.

6. El jefe de informática aprueba.

7. El área de desarrollo realiza el trabajo, incluyendo lo mismo indicado en las secciones anteriores del ciclo de desarrollo, desde análisis hasta des-pliegue, aunque a una escala menor.

Por lo menos contempla: • Participación del usuario en forma continua • Actualización de documentación • Búsqueda de programas, bibliotecas, documentación • Ordenamiento de manuales • Control de versiones de programas y de bases de datos • Análisis, diseño e implementación • Pruebas • Reentrenamiento

8. Todos los actores involucrados en el cambio se reúnen física o virtualmen-te, escriben la experiencia relevante para efectos de retroalimentación y proponen perfeccionamientos al proceso.

JUAN BRAVO C. 82

1.5. PRÁCTICAS TRANSVERSALES

La administración 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 sinérgico. 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: prácticas transversales.

Estas prácticas se aplican en la fase de estudio y luego deben quedar incorpo-radas en el plan de proyecto, en la forma de planes específicos.

Ordenamiento de las prácticas

Las prácticas se han ordenado de acuerdo con el criterio de mayor uso, co-menzando por aquellas que indudablemente deben estar presentes en todas las etapas. El resultado no señala precedencia.

Este criterio de ordenamiento no pretende juzgar niveles de importancia de cada práctica, porque cada una tiene su espacio y quizá aunque su uso sea aco-tado a pocas etapas, es vital en ellas.

Definir una política por cada práctica

Cuando hay una rutina de realizar proyectos y existe un proceso para el desa-rrollo de proyectos en la organización, la forma de trabajar con las prácticas transversales estará indicada en el método, en tal caso, la revisión es más ge-neral. Por ejemplo, la práctica “definir herramientas para la etapa” estará defi-nida como estándares corporativos o, al menos, como una política.

Es importante destacar:

• La aplicación de cada práctica transversal a un proyecto debería ser una particularización de la política correspondiente.

• La política de cada práctica debe estar siempre actualizada. • La participación de todos es vital en el contenido de las políticas, porque es

lo que verdaderamente aplicará la organización

Llevar a la Carta Gantt

Fruto del análisis de cada práctica, surgirán múltiples acciones a realizar que deberán incluirse en la carta Gantt. Ese es un resultado concreto de aplicar las prácticas transversales.


Por ejemplo, en el control de cambios es necesario contemplar el tiempo de negociación del jefe del proyecto con el usuario, independiente de que el cam-bio se realice o no.

¿Podría llegar a ser el 20% del presupuesto para los cambios? Puede ser, de-pende de la organización, por eso es necesario disponer de una base de datos de estándares numéricos.

Base de datos de estándares numéricos

Desde la base de datos de estándares numéricos obtenemos el dato de cuanto tiempo y costo presupuestar, por ejemplo, para el tiempo de negociación de un cambio.

También en esta base de datos deberían incluirse estándares como estos:

• Plazo máximo de proyectos. • Tasa de descuento y plazo para evaluación de proyectos. • Valor hora de los clientes (hemos usado US $ 4 promedio en experiencias

de público masivo, tal como un hospital público). • Forma de un flujo de caja, por ejemplo, cuando incluir la inversión. • Costos de movimientos internos y externos de mercaderías. • Valor hora promedio de los ejecutivos, de los profesionales, mando medio

y personal operativo para efectos de cuantificar las propuestas, en particu-lar el ahorro que se puede generar (recordar multiplicar por un factor tam-bién estándar respecto al valor que cada persona agrega32).

Veremos: 1. Dirección del proyecto 2. Plan de la etapa 3. Exposición de los planes 4. Retroalimentación 5. El equipo de trabajo 6. Entrevistas 7. Comunicación 8. Informes 9. Técnicas 10. Herramientas de apoyo

32 Cada uno de nosotros es contratado en la organización por el valor que agrega respecto a cumplir sus fines. Este valor, conservadoramente, es unas 5 veces la renta líquida. En todo caso, la recomendación del método es multiplicar sólo por 2 para efectos de obtener un costeo conservador.

JUAN BRAVO C. 84

11. Trazabilidad 12. Quick Wins 13. Costos y duración 14. Gestión de riesgos 15. Gestión de la calidad 16. Responsabilidad social 17. Inserción 18. Orientación al cliente 19. Sensibilización 20. Capacitación 21. Seguimiento 22. Cuidar la solución anterior 23. Continuidad operacional 24. Plan de recursos físicos del proyecto 25. Kill time 26. Control de cambios 27. Gestión del cambio 28. Gestión de proveedores

1. Dirección del proyecto La dirección del proyecto es, tal vez, la práctica más relevante para el éxito del mismo, por eso le hemos dedicado algunas líneas más que a las siguientes.

La dirección del proyecto es una visión y acción de todas las actividades nece-sarias para cumplir con lo prometido, particularmente en calidad, eficiencia, eficacia, satisfacción del cliente, plazos y costos. Contempla motivar, comuni-car, alinear intereses y sobre todo, realmente liderar el equipo de trabajo.

La dirección del proyecto también considera buscar formas para superar las expectativas y reconocer las mejores prácticas relacionadas.

Algunos facilitadores del trabajo del líder en el proyecto:

• Dedicación completa y visión clara de los objetivos del proyecto. • Apoyo de la alta dirección, nivel de autonomía adecuado y facilidad para

acceder a la toma de decisión fluida con relación al proyecto. • Competencia en trabajo en equipo y liderazgo. • Espíritu de equipo y el profesionalismo de su gente. • Gestión de los riesgos.


• Comunicar el proyecto con frecuencia dentro y fuera de la empresa, inte-grando a todo el equipo de trabajo. Así perfecciona el mensaje, se aclara a sí mismo y gana en retroalimentación.

• 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 Análisis y Diseño de Sistemas explican (2005, p. 66): “Los miembros de un equipo se pueden motivar, al menos en parte, invo-lucrándolos en la fijación de metas. El simple acto de fijar una meta desafiante pero alcanzable y de medir periódicamente el desempeño contra la meta esta-blecida parece eficaz para motivar a los individuos. Las metas sirven como imanes para atraer a los individuos a la consecución de estas”.

Siendo el liderazgo lo más representativo de la dirección del proyecto, pode-mos citar a Daniel Goleman, uno de los mejores expertos en relaciones huma-nas, quien, en su libro Inteligencia social señala (2006, p. 393): “Los mejores jefes son personas confiables, empáticas y capaces de sintonizar con los de-más, que nos hacen sentir más tranquilos, apreciados e inspirados. Los peores, distantes, difíciles y arrogantes, hacen que nos sintamos, en el mejor de los casos, mal; y en el peor, resentidos”.

Un estimado amigo, Reinhard Friedmann, doctor por la Universidad de Heil-delberg, consultor y autor de reconocidos libros, compara la labor del líder del proyecto con la de un director de orquesta, en su libro Arte y gestión, una poé-tica para el gerente del tercer milenio, define (2007, pp. 41-43): “Un equipo de alto rendimiento es aquel que ha alcanzado los objetivos propuestos de una manera excelente en términos de eficacia y de eficiencia. El alto involucra-miento vía team building es similar al modelo de orquesta sinfónica y sus ca-racterísticas son: la existencia de un director o coach; cada miembro tiene una posición fija; cada miembro coordina su parte con el resto del equipo y exige una partitura que requiere mucho ensayo para su correcto funcionamiento”.

Nótese 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 músicos, compenetrarlos en la tarea y dirigir la realización de la obra (dar el tiempo y marcar el compás). De acuerdo a la etapa de desarrollo del equipo tendrá que elegir el estilo de conducción (participativo, directivo, coa-ching, etc.). Su tarea central consiste en sincronizar óptimamente una serie de variables (composición y miembros del equipo y procesos) que condicionan el éxito del equipo durante las etapas de su desarrollo. Éstas constituyen el mate-rial sonoro de la composición. El éxito del equipo resulta de la “consonancia”

JUAN BRAVO C. 86

de los diversos elementos (sinergia), vale decir: de su buena orquestación. Del director se exige la habilidad de escucha activa para detectar eventuales diso-nancias y corregirlas a tiempo. Cualquier desajuste (misfits) marca errores y pérdidas de eficiencia”.

Luego Reinhard muestra experiencias de importantes instituciones que para tener mejores líderes de proyecto les ofrecen talleres de entrenamiento donde tienen la oportunidad de… dirigir una orquesta. Agrega que así pueden: “vi-venciar en carne propia que la armonía de un equipo sólo se da cuando cada uno de los integrantes conserva su individualidad y, a la vez, sabe coordinar y comunicarse armónicamente 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 sinfonía, lo que se privilegia es la improvisación. Aunque en estricto rigor es una improvisación educada, de hecho, los mejores improvisa-dores son profesionales que estudian mucho. Un mensaje de fondo es que se puede aprender a improvisar.

La conclusión de los aportes de Reinhard es armonizar la preparación de la sinfonía con la improvisación del Jazz, porque siempre aparecerán contingen-cias en los proyectos. Contingencias de verdad, no situaciones que eran prede-cibles y que se encuentran tratadas en los métodos de gestión 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 (duración, encargado, costo, documentos de licitación 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 programación detallada de la etapa, con fechas precisas e inclu-so horarios en algunos casos. El plan de la etapa puede ser el único que existe, como en la concepción y factibilidad, porque todavía no hay proyecto.

Es conveniente considerar que en cualquier etapa se puede cancelar el proyec-to o volver a una etapa anterior, por ejemplo, si se detectó algo no considerado o si hubo un cambio relevante en el entorno para el par problema-solución.

Una recomendación, asegúrese que lo definido en la etapa anterior sigue sien-do válido, especialmente si pasó mucho hasta la siguiente.

Por supuesto, el plan de la etapa debe ser aprobado por autoridad.


3. Exposición 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 coordinación del proyecto.

Es conveniente porque surgirán muchas sugerencias para lograr éxito en el proyecto. En el fondo, lo más importante es la retroalimentación 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 comunicación, personales en cuanto a desarrollar un mensaje y técnicas en cuanto al uso de herramientas, tal como un software tipo PowerPoint, un proyector o un puntero láser.

La exposición es uno mismo. Al comienzo la atención está puesta en cómo uno se ve, habla, mueve, gesticula, viste o entona, es el efecto de la primera impresión. Para comenzar: hay que disfrutarlo, sino, ¿para qué estamos ahí? Es indispensable la fuerza, la pasión y la energía al transmitir el mensaje.

Algunas recomendaciones: 1) preparación del tema, 2) presentación personal, 3) buena dicción, 4) lenguaje formal, 5) manejo del tiempo, 6) llegar al menos media hora antes, 7) cumplir los tiempos.

4. Retroalimentación Se trata de revisar el resultado logrado respecto a lo planeado para la etapa. Se comunican los resultados al resto del equipo y las conclusiones quedan dispo-nibles para toda la organización.

Practicar la retroalimentación es un proceso continuo de preguntarnos: ¿Qué aprendimos? ¿Qué aprendí? Si tuviéramos que hacer nuevamente el mismo trabajo de la etapa, ¿cómo lo haríamos? ¿Qué cambios introduciríamos? Tam-bién contempla preguntarnos si se están resolviendo las necesidades originales actualizadas.

Retroalimentar es una práctica que debe incluirse tanto al término de cada etapa como al completar el proyecto.

El espíritu de este punto es detenernos, reflexionar, aprender y seguir.

5. El equipo de trabajo La práctica más habitual es formar un equipo de trabajo en cada etapa, mante-niendo un núcleo de participantes “permanentes” durante el proyecto.

JUAN BRAVO C. 88

Se trata de formar un equipo integrado por especialistas en rediseño de proce-sos, informática, usuarios ejecutivos y consultores —se gana el “efecto con-sultor”, una mirada externa fresca—. Debe estar claro quién es el director del proyecto. La participación de los ejecutivos es vital.

Es necesario incorporar a clientes y proveedores en este equipo de trabajo.

Normalmente se designa un usuario líder (representante de los demás usua-rios) y usuarios clave de cada área a rediseñar. El usuario líder trabaja coordi-nadamente con el jefe del proyecto.

Lo más probable es que en cada etapa cambien integrantes del equipo de tra-bajo según sus competencias.

Una faceta del equipo de trabajo es que debe funcionar realmente como un equipo y aquí juega un rol fundamental el líder. Dice Goleman (2006, p. 391): “El liderazgo se resume a una serie de intercambios sociales en los que el líder tiene que conducir a las emociones del otro a un estado mejor o peor. En los intercambios de gran calidad, el subordinado siente la atención y la empatía de su líder, su apoyo y su actitud positiva. En las interacciones de baja calidad, se siente aislado y amenazado”.

6. Entrevistas Una práctica frecuente en los proyectos es la realización de entrevistas a usua-rios, ejecutivos y personas de fuera de la organización. La finalidad principal es levantar información útil al proyecto y se complementa con otras técnicas (encuestas, informes de consultoría o de auditoría).

Al comenzar la etapa debe elaborar el plan de entrevistas. Luego debe prepa-rar cada entrevista, anticipando lo que se pueda utilizar. Vital es la buena eje-cución y el análisis posterior para incorporar las conclusiones al proyecto y cumplir los compromisos adquiridos.

Durante la entrevista lo principal es crear ambiente, es decir, un clima de con-fianza con una actitud serena que surge de la puntualidad, preparación y pre-sentación (las tres P de las entrevistas).

Kendall y Kendall agregan (2005, p. 66): “Necesita pensar detalladamente en las entrevistas antes de hacerlas. Visualice por qué las va a hacer, qué va a preguntar y qué es lo que a su juicio hará que esta entrevista tenga éxito. Asi-mismo, debe pensar cómo logrará que la entrevista sea satisfactoria para el individuo al que entreviste”.


7. Comunicación Se trata de comunicar el proyecto al interior y exterior de la empresa, con mensajes adaptados según el tipo de interlocutor (no es lo mismo comunicar a la dirección que a los funcionarios administrativos o a los clientes). Es conve-niente comunicar mucho.

Esta sola actividad implica disponer de horas de especialistas en comunica-ción, con dedicación parcial o total según la envergadura del proyecto.

Incluye la formación de diferentes tipos de mesas de ayuda según la etapa del proyecto.

Se puede comunicar en el ámbito de problema o de la solución, es una activi-dad completamente transversal.

8. Informes Cada etapa tiene uno o más entregables que deben quedar registrados en in-formes. En el plan detallado de cada etapa deben quedar resueltos aspectos tales como: ¿quién redacta qué informe? ¿A quién se le entrega?

La práctica genérica es documentar e implica el desarrollo de las competen-cias mínimas en el equipo de trabajo (que es preferible no dar por adquiridas), por ejemplo: redacción, ortografía y capacidad de síntesis. Al menos, la habi-lidad de leer.

Por supuesto, debiera documentarse al mismo tiempo que se avanza en la eta-pa, evitando postergar.

Es necesario establecer un modelo de documentación de las aplicaciones.

9. Técnicas Se trata de seleccionar las técnicas a emplear en cada etapa del proyecto, por ejemplo, para efectos del análisis, realizar la ingeniería de requerimientos con UML, utilizar mapas de procesos globales o flujogramas de información con el curso normal de los eventos.

Hoy ya sabemos que técnicas emplear en cada etapa de un proyecto, sin em-bargo, la variedad es tan amplia que la organización debe definir algunas.

JUAN BRAVO C. 90

10. Herramientas de apoyo Se trata de seleccionar herramientas de apoyo a las técnicas que se usarán en cada etapa. También 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 organización tenga una definición al respecto.

Pueden ser ayudas en la construcción de un prototipo, flujo de un proceso, caso de uso, interfaz visual, modelo conceptual y cualquier otro modelo. También para cooperar en la planificación estratégica, el control de costos y la evaluación 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 pequeño conjunto de herramientas bien integradas, la ventaja es la facilidad para acceder a los modelos, su actualización y la trazabilidad.

Una aspiración de las herramientas de apoyo es que actúen a nivel del ciclo completo, incluyendo la generación de código cuando corresponda.

11. Trazabilidad Trazabilidad se entiende en dos sentidos:

a) Trazabilidad de las transacciones, donde se sigue la pista a la actualización de los datos. Se usan transacciones formales y presentes desde la creación 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 diseñado, el análisis que le dio forma, la evalua-ción 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 específico con detalle del packing, fertilizan-tes y suelos.

33 MS Project y Visio de Microsoft, Aris de SAP, Corporate Modeler de Case Wise, M1 y Rational de IBM, Z4 de Tuxpan, ERWIN Data Modeler de Computer Associates.


12. Quick Wins Se llama Quick Wins —literalmente ganancias rápidas— o Hits a cambios de breve diseño e implementación y que tengan un alto nivel de impacto en el avance de la solución. Son entregables de acción rápida, generalmente accio-nes simples que quedaron en evidencia desde las primeras conversaciones.

Gracias a estas acciones tempranas se ven resultados a corto plazo y se alienta tanto a los operadores del proceso como a la dirección a continuar con el pro-yecto, renovándose la motivación y manteniendo la atención en el proyecto.

Por supuesto, no se puede abusar de estas ganancias rápidas. La solución no termina ahí, el objetivo es terminar bien el proyecto.

13. Costos y duración Se calculan costos y duración tanto de la etapa como del proyecto completo. Es importante y valiente ver la realidad de lo que está sucediendo y reestimar si es necesario. No es cambiar por cambiar sino que adaptar el avance del pro-yecto a la realidad de hoy (imposible de predecir en su totalidad cuando se elaboró el plan de proyecto). Lo opuesto es cerrar los ojos y tratar de cumplir un plan que tal vez no tiene sentido. Ah... además, verifique que los fondos para el proyecto existen.

Se calculan costos cada vez más precisos del proyecto en tres etapas: factibili-dad, análisis y diseño.

Es necesario incluir costos ocultos tales como la misma planeación de la eta-pa, las reuniones de coordinación, la negociación con la dirección y las expo-siciones de avance, entre otros.

14. Gestión de riesgos Se trata de detectar riesgos y elaborar un plan para mitigarlos y/o traspasar-los. Por ejemplo, en la concepción: ¿conviene abordar el problema? A veces el sentido común (y los amplios estudios de Maturana, Echeverría, Varela y otros) indica que el solo hecho de señalar un problema ya crea una expectati-va. ¿Es el momento adecuado? ¿Y si no se llega a una conclusión? ¿Y si ex-cede los plazos o costos?

Cada etapa tiene sus propios riesgos que deben ser atendidos: una tecnología difícil de obtener, especialistas escasos, cambio de prioridades, atrasos, costos excedidos, incumplimiento de proveedores, tecnología difícil de implementar,

JUAN BRAVO C. 92

usuarios que no desean el nuevo proceso, apego irrestricto al plan o simple agotamiento.

Se han identificado más de cien riesgos asociados a los proyectos, lo mínimo es tener formas de detectar, transferir y/o neutralizar.

Una fórmula para priorizar riesgos34 es: R = C x P. La magnitud del riesgo (R) se obtiene multiplicando el costo si ocurre (C) por la probabilidad de ocurren-cia (P). También ofrece un límite a la inversión en el riesgo para mitigar o traspasar.

15. Gestión de la calidad Cada etapa del proyecto debe llevar el sello de la gestión de la calidad, al me-nos en:

• Planeación, aseguramiento y control de calidad. • Aplicar o definir estándares de gestión y determinar como se cumplen.

Tan importante es la calidad que a veces se crea un área de aseguramiento de la misma —típicamente llamada QA35— para ayudar a elaborar el plan de calidad del proyecto, para verificar el proceso de producción y validar los en-tregables de cada etapa.

Existe todo un aporte de la gestión de calidad aplicada a proyectos, con una planificación, control y seguimiento.

16. Responsabilidad social Veremos algunos elementos de la Responsabilidad Social (RS) aplicada a proyectos.

Es necesario manejar bien el temor de las personas de que este tipo de proyec-to las dejará sin empleo.

Establecer un pacto social o una alianza estratégica 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 sólo porque queremos hacer las cosas de otra forma. Se puede evitar generando vinculaciones con otros proyectos en un esquema de vasos comunicantes porque hay infinitas iniciativas que se pueden

34 En el libro Gestión de Procesos hay un análisis de la gestión de riesgos. 35 Quality Assurance, traducida como aseguramiento de la calidad.


desarrollar, una parte libera recursos y la otra requiere recursos, es cuestión de unir una cosa con otra, otra aplicación de visión sistémica.

Se requiere mantener al menos el nivel de servicio previo al inicio del proyec-to mientras este dure, trabajar con eficiencia, alinear intereses, cuidar el en-torno y la comunidad, organizar el trabajo seguro y el buen trato, tanto de los profesionales internos como de contratistas, evitando discriminar entre ellos, evitar la improvisación, 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 interacción debe ser aprobada, no basta con un buen promedio general.

En esto el método GSP puede apoyar especialmente con el énfasis en la ges-tión de las ideas, en capitalizar toda la creatividad de las personas.

17. Inserción El problema y la solución deben insertarse en un todo mayor —área, empresa o industria— para comprender y alinear los intereses.

Insertar es observar cómo se relaciona el problema o la solución con otros problemas o soluciones dentro y fuera de la organización y así transferir recur-sos, alinear intereses, optimizar adquisiciones y manejar el aspecto político en cuanto al mejor momento de plantear el cambio.

Se debe monitorear la contribución actualizada de la finalidad del proyecto a la estrategia de la organización.

18. Orientación al cliente Ya sea en el problema o la solución, la orientación al cliente es central para lograr la conclusión 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 organización.

JUAN BRAVO C. 94

19. Sensibilización Es el manejo del cambio en relación a la emoción. El objetivo es encantar a los “afectados”.

La idea es aplicar lo aprendido acerca de encantar a todas las personas de de-ntro y fuera de la organización que tienen relación con el proyecto.

Es diferente a comunicar y capacitar, aunque se complementa con esas prácti-cas. Se aplica mediante anticipación, participación, talleres —ver práctica Quick Wins—y otras formas creativas (poleras, lápices, etc.)

20. Capacitación La capacitación del equipo de proyecto debiera ser continua durante todo el proyecto. Además, es una excelente oportunidad para lograr acuerdos en los múltiples detalles de la necesidad y del proyecto.

El diseño de la actividad es muy importante: lugar, objetivos, duración, rela-tor, extensión y muchos otros aspectos deben estar bien pensados.

La capacitación de los usuarios es vital en el proyecto. Por supuesto, es dife-rente según tipos de usuarios y puede tomar variadas formas (la recomenda-ción es una combinación de posibilidades):

• Puede ser realizada por relatores profesionales, por sicólogos preparados en los mensajes del proyecto, por el equipo de proyecto, por usuarios que actúan 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 preparación en peda-gogía 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 críticas del proyecto (costos, plazos, hitos, satisfacción de usuarios, calidad) Desde este punto de vista tiene rela-ción con el diseño de indicadores.


Es necesario que exista algún nivel de control centralizado y que el equipo de dirección del proyecto tenga la información inmediata del avance.

22. Cuidar la solución anterior Cuidar la solución anterior significa que al mismo tiempo que se trabaja en la nueva solución, se aplica alguna forma de continuidad de lo existente. Incluso se sigue realizando mejora continua de la antigua solución.

En algunas experiencias incluso se designa un gerente de continuidad, al mismo tiempo que otro gerente se encarga del proyecto de cambio.

23. Continuidad operacional Se refiere a incorporar en el proyecto los mecanismos que permitan la conti-nuidad de las operaciones cuando el proyecto esté en funcionamiento, más allá de sólo tener planes de contingencia. La idea de fondo es evitar la contingen-cia, prevenir.

Objetivos del plan de continuidad operacional: • Crear conciencia en el equipo de trabajo y en los usuarios acerca de la pre-

vención y de las implicancias de una contingencia en la continuidad de los productos y servicios.

• Minimizar interrupciones a las operaciones del negocio y limitar la severi-dad de la interrupción.

• Minimizar pérdidas financieras. • Agilizar la restauración de los servicios y reiniciar operaciones críticas en

un tiempo breve. • Asegurar a los clientes la protección de sus intereses y mantener la buena

imagen de la empresa.

La continuidad operacional está relacionada con la seguridad de las operacio-nes y la calidad de la información.

24. Plan de recursos físicos del proyecto El plan de recursos físicos se refiere a disponer oportunamente de los elemen-tos que se requerirán en el proyecto: equipos computacionales, redes, licen-cias, escritorios, espacio físico, baños, comedores y otros.

Un trabajo bien hecho en materia de recursos físicos tendrá su nivel de in-fluencia en la moral del equipo de trabajo y en los plazos.

JUAN BRAVO C. 96

25. Kill time Un Kill time se define como “momento de cancelación 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 inversión, se define que el proyecto se cancelará si se consu-me el presupuesto completo más un 20% o si la duración excederá en un 25% al tiempo asignado. Es sabio, porque si el proyecto gasta mucho más del pre-supuesto o su duración es excesiva, lo más probable es que el costo llegue a ser prohibitivo para la organización o que nunca termine.

Asumir a tiempo la pérdida acota el efecto a un nivel soportable por la organi-zación. Esperar puede poner en riesgo su existencia.

26. Control de cambios El control de cambios tiene dos interpretaciones: durante el desarrollo y du-rante la operación.

Durante el desarrollo del proyecto son cambios en las especificaciones. No hay problema si son necesarios, el método debe contemplar la facilidad de incorporación cambiando la serie de modelos que da origen a la solución. Si se emplea desarrollo en espiral se facilita la incorporación de los cambios porque normalmente se incluyen en la siguiente vuelta de la espiral.

Durante la operación se refiere a un procedimiento para cambios menores que incluso puede enlazar con la mejora continua de la solución36.

27. Gestión del cambio Esta práctica se refiere a la gestión del cambio en las personas. Está hacia el final porque varios de los elementos de la buena gestión del cambio están con-templados en las prácticas anteriores, tal como dirección del proyecto, sensibi-lización, capacitación, exposiciones, entrevistas y responsabilidad social.

Vital es incorporar en forma personalizada a todos los actores relevantes —tal como señala F. W. Taylor en su administración científica, tipo Coaching dir-íamos hoy— distinto a la capacitación masiva.

36 En la etapa de operación descrita en la sección 1.4 se presentó un proceso de control de cambios.


La coherencia del equipo interno es vital. Su propia predisposición al cambio ayudará en la moral de los usuarios.

28. Gestión de proveedores Cada vez es más frecuente que en los proyectos participen personas y empre-sas externas a la organización. Es indispensable una buena gestión con ellos para el éxito del proyecto, por ejemplo, claridad de los objetivos de su trabajo, condiciones igualitarias para trabajadores propios y de contratistas y requeri-mientos precisos.

A veces se malentiende la gestión de proveedores y de subcontratistas, erró-neamente, se piensa en tener una función que optimice solamente el interés de la organización sin consideración por las necesidades de esos terceros (malos pagos o malas condiciones laborales) desconociendo que tal práctica se vol-verá contra la misma empresa.

Una verdadera gestión de proveedores va por el oro, como se enseña en los buenos cursos de negociación, donde se maximiza el interés de la empresa y de los proveedores, mucho más allá de pagos justos y oportunos o buenas condiciones laborales. Se trata de lograr la mayor armonía en los intereses buscando aplicarse todos con el mayor entusiasmo y creatividad al éxito del proyecto, incluso aportando ideas y siendo parte de la solución.

JUAN BRAVO C. 98



Capítulo 2. Ingeniería 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 años, muchos inge-

nieros de software han sido “los hijos del zapatero”. Aunque es-tos profesionales han construido sistemas complejos que automa-

tizan el trabajo de otros, ellos mismos no han aplicado estas técnicas.

Roger S. Pressman

El objetivo más importante de la ingeniería de software es lograr la produc-ción profesional de software, donde se aumente la calidad y la productividad y se disminuyan los riesgos del proyecto mediante una excelente planificación y modelamiento. No se refiere a la producción en serie, sino a la obtención de un producto creativo y personalizado, desarrollado con método, técnicas y herramientas conocidas.

Esta es la segunda competencia considerada para apoyar la elaboración de modelos de una solución de software, tal como se aprecia en la siguiente fi-gura (en la introducción se incluyó la visión global de las competencias). Es necesario que el analista conozca acerca de la ingeniería de software para que inserte su aporte en el contexto de esta disciplina. Es una competencia de tipo vertical, porque se profundiza en una especialización, el desarrollo de software.

Se trata de avanzar desde aplicaciones computacionales que son “obras de arte únicas”, hacia productos de programación normalizados, con documentación






CAPÍTULO 6. UML



JUAN BRAVO C. 100

automatizada, fáciles de construir y de mantener, para lograr aumentos de productividad de los desarrolladores de software.

No hay una contradicción entre obtener productos creativos trabajando meto-dológicamente.

Hay que desmitificar la producción de software, transformándola en una acti-vidad mucho más amistosa, a través de la aplicación de técnicas simples y herramientas poderosas, con una finalidad revolucionaria: permitir que los usuarios calificados puedan participar activamente en todo el ciclo de desa-rrollo. Usuarios calificados son profesionales y ejecutivos que poseen entre-namiento formal en tecnología de la información, quienes conocen su proble-ma y saben como estructurarlo.

La orientación del capítulo y de todo el libro, es hacia la producción de soft-ware que apoye directamente los procesos de la organización teniendo siem-pre al cliente como norte (al cliente final, el que paga).

La ingeniería de software incluye la producción de otros productos de softwa-re, como sistemas operativos, herramientas de productividad o de automatiza-ción de oficinas. Éstos siguen patrones parecidos a la producción de software administrativo e incluyen algunos aspectos más especializados, como el énfa-sis en la programación orientada al objeto o la utilización de lenguajes que provean máxima eficiencia.

Todo lo que se refiere al apoyo automatizado para el desarrollo de software (Herramientas CASE) se incluyó en el capítulo 7, sobre herramientas de la tecnología de información.

Veremos: • Alcance de la ingeniería de software • Planificación en informática • Sistema de productividad en el desarrollo de software • Criterios de desarrollo de software • Métodos para la producción de software • Apoyo del diseño en la explotación del sistema • Diseño de interfaces • Normas y estándares aplicados a los modelos TI


2.1. ALCANCE DE LA INGENIERÍA DE SOFTWARE

El principal objetivo de la ingeniería de software es sentar las bases para la producción profesional de software, a través de proponer métodos completos que permitan obtener buenos productos de software, es decir, económicos (costo / beneficio positivo), de alta calidad, amistosos y rápidos en la ejecu-ción. Es lo que plantea Ian Sommerville (2005, p. 6): “La ingeniería del softwa-re es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del siste-ma hasta el mantenimiento de éste después de que se utiliza”.

Consideramos que cumplir plazos y costos está incluido en “alta calidad”.

En las siguientes secciones precisaremos la definición de ingeniería de softwa-re, trataremos sobre la necesaria educación y discutiremos sobre la real nece-sidad de construir software con el objetivo de asegurarnos de trabajar en pro-yectos plenamente justificados.

La realidad muestra que una gran parte de los proyectos informáticos nunca debieran haberse realizado (la mitad es una estimación conservadora) porque ni siquiera se exploraron superficialmente otras soluciones, por ejemplo: ex-ternalización, trabajo de equipo, redefinición de procedimientos, rediseño or-ganizacional, automatización de oficinas, cambios en productos y mercados o desmantelamiento de estructuras especializadas.

Veremos: 1. Definiciones de la ingeniería de software 2. ¿Desarrollar un buen software o solucionar el problema? 3. Esfuerzo de educación 4. Tecnología de información

1. Definiciones de la ingeniería de software Algunas definiciones sobre la ingeniería de software:

Richard Fairley: “Disciplina tecnológica y administrativa dedicada a la produc-ción sistemática de productos de programación, que son desarrollados y modifi-cados a tiempo y dentro de un presupuesto definido”.

Fritz Bauer: “El establecimiento y uso de sólidos principios de ingeniería, orientados a obtener, económicamente, software que sea fiable y funcione efi-cientemente sobre máquinas reales”.

JUAN BRAVO C. 102

Comentarios de Roger S. Pressman: “La ingeniería del software surge, sobre-pasándola, de la ingeniería de sistemas y del hardware. Abarca tres elementos clave: métodos, herramientas y procedimientos, que facilitan al gestor controlar el proceso de desarrollo del software y suministrar a los que practiquen dicha ingeniería las bases para construir software de alta calidad de una forma produc-tiva. Todo, bajo una filosofía predominante de coordinación, control y gestión”.

2. ¿Desarrollar un buen software o solucionar el problema? La ingeniería de software nació como respuesta a variadas necesidades rela-cionadas con el desarrollo de software: fiabilidad, eficacia, control, normali-zación y productividad, por nombrar algunas. Consideremos la productividad del desarrollo. La situación es que se requieren nuevas aplicaciones que los especialistas no alcanzan a construir. Se espera que el incremento en la pro-ductividad permita satisfacer las demandas pendientes. Sin embargo, hay ins-talaciones donde se incrementó la productividad del desarrollo y aún así los usuarios no están satisfechos. ¿No será que comenzamos por el lugar equivo-cado? ¿Será necesario desarrollar la aplicación? Es que el interés del usuario es solucionar su problema, lo cual no implica necesariamente el desarrollo de una solución de software. Por ejemplo, se puede explorar:

• Hacer ingeniería y buscar alternativas de solución no computacionales al problema.

• Adquirir software de uso generalizado. • Preparar a los usuarios para que ellos mismos resuelvan parte de sus nece-

sidades. • Contratar desarrollo externo. Veamos estos puntos con mayor detalle:

1.– Realmente hacer ingeniería y buscar otras alternativas de solución al pro-blema, no computacionales, tal como vimos en el capítulo primero. Por ejemplo, ampliar o reducir mercados, aplicar just in time, externalización, trabajo de equipo o cambiar el diseño del producto. De aquí podrían surgir opciones tales como eliminar la bodega o descontinuar una línea de pro-ductos con dificultades de ventas que se pensaba controlar más en detalle con un sistema computacional.

Con esto es posible resolver tal vez el 50% de los casos, lo cual es consis-tente con estudios que señalan que hasta la mitad del software construido en Chile nunca debería haberse hecho, porque existían otras soluciones mejores que ni siquiera fueron exploradas.


2.– Si el camino es de índole computacional, estudiar si la aplicación existe en el mercado para adquirirla a una empresa especializada. Hoy es una lo-cura desarrollar aplicaciones típicas, tales como: contabilidad, inventarios, remuneraciones, activo fijo y facturación. En el mercado existe una am-plia gama de excelentes soluciones para todo tipo de plataformas, comen-zando por los productos ERP (que veremos en el capítulo siete). El costo de este software genérico es equivalente a una pequeña fracción del costo del desarrollo.

Es posible que esto dé respuesta a la mitad de los requerimientos compu-tacionales (25% de los casos).

3.– Estudiar la posibilidad que sea el mismo usuario quien resuelva su pro-blema. Con capacitación y herramientas apropiadas puede resolver su re-querimiento en menos tiempo del que le hubiera tomado explicárselo a un especialista. Si se trata de la creación de bases de datos simples, lo puede hacer hasta con un procesador de texto. Si requiere interactuar con gran-des bases de datos para extraer información, puede ocupar Microsoft Ac-cess o alguno de los módulos de consulta que proveen los sistemas admi-nistradores de bases de datos. Si requiere efectuar cálculos y presentar gráficos, las planillas electrónicas le ayudarán 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 opción se aplica cuando el tamaño y compleji-dad del requerimiento lo permiten.

4.– Si no hay software de tipo generalizado y el usuario no lo puede resolver, es posible recurrir al desarrollo externo. Significa que todas o algunas eta-pas se pueden contratar externamente. Por ejemplo, realizar internamente el análisis y el diseño y contratar la construcción del sistema.

Esta opción y otras creativas resuelven la última tajada de los requerimien-tos originales (el otro 12,5% de los casos).

Cualquiera de estas opciones soluciona el problema del usuario sin recurrir al desarrollo interno, la cual es una opción que debiera quedar abierta sólo para casos excepcionales.

Tal como se aprecia en la evolución de la construcción de software, el equipo interno principalmente coordina y hace gestión de calidad, más que construir ellos mismos.

Tiene mucha relación con el esfuerzo de educación.

JUAN BRAVO C. 104

3. Esfuerzo de educación La ingeniería de software es una materia especializada y no es habitual que se hable de educación en este contexto. Sin embargo, es indispensable hacerlo si queremos producir software efectivo y de calidad.

Si un ejecutivo destina a su labor especializada varios miles de horas de per-feccionamiento, debiera destinar una cantidad equivalente de horas a los te-mas de su entorno, uno de los cuales es la tecnología de información. Este es un principio sistémico, el equilibrio entre especialización y generalización.

Es sorprendente la mayor productividad que se logra cuando los ejecutivos se educan en el análisis de problemas y los especialistas se capacitan sistemáti-camente en técnicas y herramientas uniformes para el desarrollo de sistemas. Adicionalmente, se incrementa la capacidad individual, mejora el funciona-miento de equipos de trabajo y se refuerza la motivación.

Este tema es de tal trascendencia que, refiriéndose al control total de calidad, el Dr. Kaoru Ishikawa, ganador del premio Deming a la calidad, dice: “la ca-lidad comienza con educación y termina con educación”.

Utilizamos la palabra educación porque ella es consecuencia del proceso de aprendizaje y reflejo de ser una persona culta. Se refiere a una conducta “edu-cada” y no a una acumulación de títulos. Está relacionada con una sistemati-zación del conocimiento, un “aprender a pensar” y luego cambiar la forma de pensar. La educación implica una mentalidad abierta, menos prejuicios, dar mejores respuestas a los desafíos del medio y atreverse a hacer cambios.

Una faceta de la educación es la capacitación, la cual se refiere a dominar una materia o a lograr una destreza específica. Siendo la actividad de capacitación de fundamental importancia en la empresa, ella está indudablemente supedita-da a los mayores intereses de la educación.

Otra faceta es el Training (traducido como entrenamiento) destinado a formar a las personas en los procesos específicos en que participa.

¿Cómo se aplica el esfuerzo de educación en la organización?

A través de establecer planes de perfeccionamiento dirigidos a todas las per-sonas, comenzando por los ejecutivos de mayor nivel. Para diseñar el progra-ma de enseñanza, se pueden extraer algunos temas de la clasificación de mate-rias presentada en la figura 2-1, la cual es solamente un ejemplo del tipo de materias en cada categoría.


Figura 2-1. Clasificación 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 organización están clasificadas en dos grandes áreas: un ambiente de calidad, orientado a los eslabones más altos del manejo de información y la tecnología de información, con las materias pro-pias del área informática.

De esta manera, los ejecutivos y profesionales podrán apreciar su organización desde un punto de vista más amplio. Con una visión de conjunto que permita tener a todos sus integrantes un alto grado de participación en el rediseño de los procesos del negocio, computacionales o no.

Parte de este esfuerzo de educación es conocer en profundidad los alcances de la tecnología de información y sus implicancias.

La empresa en la comunidad

Planificación estratégica

Adaptación al cambio

Liderazgo, organización y administración

Reingeniería y benchmarking

Mejoramiento continuo

Visión sistémica

Gestión de procesos

Mapas de procesos

Flujograma de Información

Gestión de proyectos

Orientación al cliente

Diseño de sistemas

Sistema de productividad

Orientación a objetos y UML

Modelamiento de datos

Métodos de desarrollo de software

Herramientas CASE

Bases de datos simple

Automatización de oficinas

Ambiente

de

Calidad

Tecnología

De

Información

La empresa en la comunidad

Planificación estratégica

Adaptación al cambio

Liderazgo, organización y administración

Reingeniería y benchmarking

Mejoramiento continuo

Visión sistémica

Gestión de procesos

Mapas de procesos

Flujograma de Información

Gestión de proyectos

Orientación al cliente

Diseño de sistemas

Sistema de productividad

Orientación a objetos y UML

Modelamiento de datos

Métodos de desarrollo de software

Herramientas CASE

Bases de datos simple

Automatización de oficinas

Ambiente

de

Calidad

Tecnología

De

Información

Ambiente

de

Calidad

Tecnología

De

Información

JUAN BRAVO C. 106

4. Tecnología de información La Tecnología de Información (TI) está revolucionando nuestra sociedad más rápidamente que cualquier otra disciplina, penetró profundamente en la em-presa moderna, está entrando en el colegio y en el hogar.

¿Qué es la tecnología de información? La palabra tecnología ya nos dice mu-cho, ella proviene de la raíz latina techne = arte y logy = organización, es de-cir, arte organizado, susceptible de ser compartido, estudiado y completado, en contraposición al simple chispazo de la techne; en resumen, tecnología sería un cuerpo de conocimientos organizado que consta de métodos y herra-mientas en rápido progreso. Sobre la información, hay cientos de libros que la tratan desde todo punto de vista. Podríamos agregar que los datos se encuen-tran hoy en computadores que los procesan para obtener, gota a gota, esa in-formación 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 formación de un conocimiento objetivo, a partir de la información, la ob-servación y la experiencia, es lo que produce tecnología. Es un tipo de cono-cimiento medible, de rápida formación, traspasable, actualizado y perfeccio-nado, con redes internacionales de especialistas que comparten su saber. Esto ha sido en gran medida lo que originó la revolución industrial y ahora la revo-lución del conocimiento.

Aunque no basta con el conocimiento, también es indispensable el entendi-miento37. Con la comprensión que nos provee podremos darnos cuenta que la aplicación de un determinado conocimiento puede ser dañino para el conjunto y para nosotros mismos en el mediano y largo plazo. Tal vez resulte más con-veniente no extraer aquel petróleo desde el fondo del lago, porque el costo de la contaminación y de la pérdida de agua potable sean mayores que el eventual beneficio. Sabemos cómo hacerlo, pero decidimos no hacerlo.

Si el conocimiento es fruto de la información, observación y experiencia, el entendimiento es hijo de la reflexión y de la verdadera educación, aquélla que nos hace cambiar y pensar por nosotros mismos.

37 Es el entendimiento el que nos lleva al desarrollo, directamente relacionado con el aumento de la calidad de vida. La nueva visión de la organización es la de un sistema social caracteri-zado por la interdependencia, esto es comprender que cualquier problema que alguien tenga, nos afectará a nosotros de una u otra forma. Y lo que a él le beneficie, nos ayudará también a nosotros. Esta visión de sistema social es la base de una habilidad fundamental en nuestros días, la adaptación al cambio, sustento de las nuevas definiciones de inteligencia.


Es que la implementación de cualquier tecnología debe armonizar conoci-miento y entendimiento. Esto es profesionalismo.

La tecnología de información avanza velozmente y cambia su contenido en períodos cada vez más breves. Con capacitación podemos conocerla, no cabe duda, pero sólo con educación sabremos dónde, cuándo y por qué aplicarla, en la dirección del desarrollo social y del incremento en la calidad de vida.

JUAN BRAVO C. 108

2.2. PLANIFICACIÓN EN INFORMÁTICA

Una realidad a simple vista es que muchos sistemas computacionales no res-pondieron de acuerdo con las expectativas. Incluso, hubiera sido preferible no construirlos, porque el costo para la organización resultó ser más alto que mantener el problema original. ¿Cuál es la causa? Hay varias: construcción apresurada, desarrollo informal, imposiciones de centros de poder con inter-eses contrarios a los de la organización, falta de perfeccionamiento de los co-laboradores, sesgo informático, etc…

Entre las causas, se considera especialmente relevante la carencia de una vi-sión estratégica, por ello es que se incluye este capítulo y los anexos 1 y 2, acerca de estrategia y alinear intereses, respectivamente.

Por supuesto, todo proyecto de la organización, de tecnología o cualquier otro tipo, debe estar de acuerdo con el plan estratégico global. Si este no existe, fue construido en forma apresurada en algunos retiros de fin de semana o se en-cuentra desactualizado, estaríamos en presencia de problemas mayores cuya solución comenzará cuando se cuente con el plan estratégico de la organiza-ción. Para efectos de ofrecer luces respecto a lo que debe incluir el plan es-tratégico es que se incluyeron los dos primeros anexos. Cabe agregar que el plan informático debería ser parte de ese plan global.

Por otra parte, tal como vimos en el capítulo 1, este aspecto estratégico deber-ía estar contemplado en el método que la organización adopte. Desde este punto de vista, el contenido de esta sección es profundizar en la parte del método referida a la estrategia.

Es que resulta vital desarrollar una visión estratégica, una vista panorámica de la realidad que permita tomar los mejores cursos de acción para cumplir los grandes intereses de la organización.

La nueva tecnología informática ofrece más rapidez, es más amistosa y gene-ralmente la relación costo–beneficio es claramente conveniente. Por lo tanto, no es caro probar opciones, es más, muchas veces resulta más económica una equi-vocación que esperar.

La opción más cara es mantener los esquemas tradicionales. Las empresas que hacen cambios en forma sistemática logran mejores resultados.

Veremos: 1. Algunas directrices sobre la tecnología de información 2. Reconversión de la informática


3. Nuevas formas de organización informática 4. Método de planificación estratégica en informática 5. Cambio cultural de la organización 6. Resumen de la planificación estratégica en informática

1. Algunas directrices sobre la tecnología de información La tecnología de información va más allá de la selección de un hardware especí-fico, algunos productos de software y un método de desarrollo. Ahora hablamos de mentalidad, flexibilidad y disposición al cambio. Si en la empresa se ha ven-cido el temor a ensayar opciones; si de alguna forma se tiene “institucionaliza-do” probar alternativas para seleccionar aquélla que mejor les parece, entonces la resistencia al cambio es muy baja. Como consecuencia, se obtiene un subpro-ducto de gran proyección: la adaptación al cambio38.

La tendencia de la tecnología de información se estaría orientando hoy, hacia un conjunto de directrices cuya implementación significa tomar decisiones estraté-gicas que están más allá del ámbito informático. Estas decisiones estratégicas deben ser tomadas en reuniones conjuntas de la alta gerencia con sus especialis-tas y preferentemente con apoyo externo no comprometido con alguna opción en particular.

38 Stan Shih, fundador y presidente de Acer, en un viaje a Chile realizado para sostener con-versaciones con la subsidiara local, expone (El Mercurio, 30 de julio de 1995) algunas de las causas del éxito de Acer, compañía que en sólo un año saltó del número 14 al 7 de entre los mayores fabricantes de PC´s a nivel mundial. Opina que la computación recién comienza y que a principio de los 90´s se produjo un cambio radical en el mercado que llamaron desinte-gración de la industria. Para adaptarse, emprendieron el proceso de la reingeniería de acuer-do con tres grandes estrategias: El modelo de “comida rápida”. La idea es ensamblar el PC en el punto de ventas y fabricar las piezas en otra parte. La estructura organizativa de “cliente–servidor”. Cada empresa del grupo es independiente y cada una está enfocada a una línea de productos… La relación de la red les permite mejorar la calidad y reducir costos. Esta clase de estructura maneja mejor los cambios y en esta industria el cambio es constante. La idea de “marca global, toque local”. Así, por ejemplo, en Chile se ve qué clase de produc-tos gustan y a esos se les da prioridad… Queremos tener socios en cada país a través de so-ciedades anónimas abiertas. Dice: los gerentes son también inversionistas… hacemos mucha capacitación… las unidades toman sus propias decisiones… no buscamos tamaño, tenemos que buscar el retorno y cómo podemos construir competitividad… innovación no sólo en el producto, también en la admi-nistración.

JUAN BRAVO C. 110

Algunas de las nuevas directrices son:

• Áreas de sistemas orientadas al cliente (el cliente de la organización, el que paga) filtrando cada requerimiento en función de si le agrega valor o no a éste. Implica que los profesionales de informática conocen y aplican la estrategia de la organización.

• Incorporación del usuario (o cliente interno) al proceso de desarrollo de sistemas, al menos en la gestión de su propia demanda de requerimientos. También en resolver sus propias necesidades simples: informes y consultas de toda índole, con alta eficacia y eficiencia en la obtención de resultados.

• Participación creciente del usuario ejecutivo en la formulación de modelos corporativos, que representen la realidad de la empresa.

• Fuerte énfasis en perfeccionamiento y educación. Incluso, este aspecto es una ventaja competitiva a nivel profesional.

• Desarrollo y procesamiento descentralizado, en armonía con la existencia de un pequeño departamento de sistemas centralizado y de acuerdo con la planificación informática y las normalizaciones en métodos, procedimien-tos y herramientas que la organización se haya dado. En particular, cada unidad de negocios administrará su propio presupuesto de informática.

• Orientación a objetos, UML y otros estándares en lugar de diseño estructu-rado. Es creciente la velocidad de introducción de las técnicas de orienta-ción a objetos.

• Software cada vez más amistoso con uso intensivo de “factores humanos”: simplicidad, ayudas en línea, ventanas, íconos o idioma nativo del usuario.

• Utilización creciente de prototipos para ensayar interfaces visuales (panta-llas e informes) y funcionalidad (ingreso de datos o selección).

• Generación automática de código. Lo cual es hoy una realidad con múlti-ples herramientas disponibles en el mercado.

• Búsqueda de código reutilizable. Promesa que con la orientación a objetos está comenzando a ser cumplida (es ya una realidad al interior de algunas organizaciones, pero todavía falta un mercado de código reutilizable).

• Apoyarse en herramientas de productividad en todo el ciclo de desarrollo. La idea es automatizar sobre la base de métodos formales, dejando de lado la producción artesanal del software.

• Alineamiento cada vez mejor entre la tecnología de la información y las necesidades estratégicas de la organización.


• Estrategia de la organización e informática permanentemente reformulada.

• Integración total, incluyendo a las aplicaciones antiguas a través de rescatar su funcionalidad en la forma de componentes a los cuales se accede mediante mensajes (orientación a objetos). También redes neuronales e interconexión con clientes y proveedores.

• Uso intensivo de Internet, Intranet y Extranet. Uno mismo puede establecer como desea que sean sus aplicaciones.

• Nuevos criterios de evaluación de programadores: ya no será por líneas de código o menor cantidad de errores, sino que por el grado de satisfacción del usuario.

• Mayor calidad y cantidad de aplicaciones, lo que a su vez significará la adquisición de más hardware y software.

• Fuerte demanda de especialistas preparados en métodos y herramientas modernas: Gupta, Powerbuilder, Ingres, Progress, Oracle, Sybase, Visual Basic, Informix y muchas otras.

Una variable a tomar en cuenta por desarrolladores y ejecutivos del área in-formática, es que las rentas de especialistas bien preparados en cualquiera de esos temas son mayores al promedio. Los primeros pueden ver esto co-mo una real oportunidad profesional. Los segundos debieran ser cuidadosos en que los costos del proyecto no se disparen.

• Fuerte expansión de la multimedia (sonido, imagen, tacto, movimiento, etc.). La idea es vivir la experiencia. Por ejemplo, se puede “pasear” vir-tualmente dentro de la casa que uno quiere comprar, cambiarle colores o hacer transformaciones.

• Importantes avances en la tecnología de tratamiento de imágenes. De hecho, existen experiencias exitosas en importantes organizaciones.

• Equipos PC cada vez más poderosos y económicos. Hoy, a fines de la pri-mera década del segundo milenio, ya se habla en Terabytes (TB) para los dispositivos de almacenamiento y en Gigabytes (GB) para las memorias.

2. Reconversión de la informática La tecnología de información, junto con la masiva incorporación del usuario, las revoluciones del hardware, software, métodos y esquemas organizaciona-les, están provocando profundos cambios en el perfil de los especialistas en computación, sólo comparables a las enormes reconversiones que significaron

JUAN BRAVO C. 112

el cambio del ferrocarril a vapor por la locomotora eléctrica y del carbón por otras fuentes de energía.

Una de las consecuencias más inmediatas es el cambio en las funciones de los diferentes especialistas:

• Digitadores y operadores prácticamente no se requieren en el centro de informática, pero pueden pasar a desempeñarse como apoyo en departa-mentos usuarios, trabajando en pequeñas unidades de informática descen-tralizadas o directamente en funciones propias del quehacer de otras áreas, aprovechando su conocimiento sobre la organización.

• Los programadores pasarán a ser analistas-programadores, ellos deben proveer de soluciones informáticas completas, a partir del diseño de la aplicación. Tanto en el diseño como en la construcción de sistemas deben apoyarse en las herramientas de productividad.

• Los analistas de sistemas pasarán a desempeñarse como consultores inter-nos, especialmente en innovaciones, información y adaptación al cambio. El nuevo rol del analista ya es solucionar problemas, en lugar de desarro-llar sistemas computacionales; en consecuencia, su preparación debe in-cluir conocimientos sobre todas las nuevas herramientas de apoyo integral a la organización: estrategia, gestión de procesos, benchmarking, liderazgo o inteligencia competitiva.

• El jefe de informática será un líder y trabajará con sus colaboradores en el marco de una relación más profesional que jerárquica. Su misión principal será la interacción con el medio: clientes, proveedores o competencia, para aumentar permanentemente la productividad, la calidad y el servicio al clien-te no sólo de su área, sino de toda la empresa. También el cambio se aprecia en la evolución del nombre del cargo, el nuevo nombre que usamos es Ge-rente de Sistemas.

Observando la realidad actual de muchas organizaciones, se llega a concluir que la reconversión de programadores sigue los mismos patrones que en otras áreas con cambios drásticos, tal como se muestra en la figura 2-2. Más o me-nos el 25% de los actuales programadores no requiere entrenamiento especial, pues ya tiene conocimientos actualizados y aplica las nuevas tecnologías. El 50% deberá ser reentrenado y puede seguir desempeñándose sin mayores difi-cultades. El 25% restante tiene poca tolerancia al cambio, aunque la mayoría de ellos puede subirse a este nuevo mundo con perfeccionamiento en la medida que su predisposición personal sea positiva.


Figura 2-2. Reconversión de programadores

3. Nuevas formas de organización informática El diseño organizacional del área informática es parte integrante de las defini-ciones estratégicas respecto a la ingeniería de software.

Analizaremos aquí algunas posibilidades de organización informática, compa-tibles entre sí:

Equilibrio entre centralización y descentralización

Significa conservar un centro de información a nivel de la empresa, dando a cada área usuaria autonomía en el manejo informático, en el marco de las normas convenidas y administradas por el centro de información. La autonom-ía en esta materia tiene su base en los principios sistémicos de viabilidad y recursividad. Para que un área sea viable, debe poseer funciones esenciales de sobrevivencia: manejo económico, de personas, dirección y tecnología, entre otras. La recursividad dice que estas funciones esenciales se encuentran a ni-vel de la empresa y de cada área viable. Así como existe una fuerza aérea na-cional y una rama aeronaval de la armada, en la organización debieran existir funciones de manejo de la información, centralizada y como parte de cada área usuaria autónoma.

50%Pueden ser

reentrenados

25%No tienentoleranciaal cambio

25%Ya poseenlos nuevos

conocimientos

JUAN BRAVO C. 114

Rightsizing (tamaño justo)

Significa dimensionar el equipamiento y el área de sistemas de acuerdo con los requerimientos y la disponibilidad de nuevas tecnologías. Si es posible satisfacer la demanda interna con un servidor y equipos conectados en red, entonces ese es el tamaño apropiado. Si es posible satisfacer al cliente interno subcontratando el desarrollo de sistemas y la única infraestructura centralizada es un especialista en información, entonces ese es el tamaño correcto.

Rightsizing derivó del término downsizing, todavía muy en boga para efectuar una reducción del tamaño de la infraestructura, en particular el equipamiento, porque ha venido sucediendo que el desarrollo exponencial de los computado-res personales está dejando obsoletos los mainframes o equipos grandes. Es frecuente obtener más rendimiento a través de microcomputadores por el mismo costo de mantener un mainframe, con la ventaja extra de la arquitectu-ra abierta, por lo estándar de los PC’s.

Externalización (outsourcing)

Significa contratar externamente el servicio de informática, teniendo el cuida-do de mantener internamente algún interlocutor con amplios conocimientos de informática y de administración, un especialista en información. Desde los puntos de vista económico, sistémico y humano esta opción aparece como la más apropiada en la mayoría de las organizaciones cuya misión no tiene rela-ción con la informática:

• Es más económico, porque generalmente resulta de más bajo costo subcon-tratar que proporcionarse uno mismo el servicio, incluyendo en el costo in-terno las rentas de las personas, infraestructura física y uso de otros recur-sos generales: contabilidad, servicios básicos, etc. Esto agrega el gran be-neficio del ahorro de tiempo en interacciones innecesarias al interior de la empresa, el cual probablemente es mayor al costo directo.

• Es más natural, porque, según el enfoque sistémico, la máxima potencia de una organización se logra cuando está totalmente concentrada en su mi-sión, la cual desatiende al destinar tiempo y recursos en atender a la auto-generación de servicios que puede tomar del medio. En otras palabras, aun cuando el servicio interno resulte más económico que ser contratado exter-namente, lo cual ya es poco probable, esa diferencia a su favor es ínfima comparada con el costo de oportunidad o el mayor rendimiento potencial de los mismos recursos destinados a apoyar la misión de la organización.


En esto debemos ser cuidadosos, porque hay organizaciones con misiones que dependen totalmente de la tecnología, incluso, uno podría plantear que su negocio es tecnología. Es el caso de las grandes tiendas por departamen-tos —tal como Falabella, Ripley y Almacenes París en Chile— los bancos comerciales, los supermercados y muchos otros que necesitan el procesa-miento en tiempo real y el manejo de grandes volúmenes de transacciones. En estos casos, las innovaciones tecnológicas son definitivamente ventajas competitivas.

• Es más humano, porque, generalmente, el profesional de informática —y lo mismo es válido para contadores, cobradores, guardias y otras personas de servicios internos— tiene menos posibilidades de desarrollo en una empre-sa dedicada a otra misión: su renta queda rápidamente estancada; su evolu-ción profesional es más lenta porque solamente conoce la realidad de la empresa; no hay mayores incentivos para innovaciones, porque no se apre-cian los cambios creativos debido a lo especializado de su área. Además, existen serias dificultades de comunicación con el resto de la empresa.

Esta es la regla general, sin embargo, debemos estudiar cada caso en forma individual para su eventual aplicación. La prudencia indica que debemos reconocer muy bien la misión de la empresa, porque tal vez el negocio de fondo es tecnológico y en ese caso los profesionales de informática pueden hacer una carrera al interior de la organización.

Cuando el profesional de informática se desempeña en una organización de informática, ya no es un “patito feo”, porque ahora puede comunicarse con sus pares. Su campo de desarrollo profesional se amplía, sus contribuciones son comprendidas y apreciadas, la renta se va incrementando según su ren-dimiento y se produce un ambiente motivador que ayuda a incrementar la productividad.

Un plan de externalización debería incluir el destino de los especialistas en informática, de común acuerdo con ellos, quienes podrían formar la empresa que proveerá el servicio o integrarse a una empresa mayor de la especialidad informática que provea el servicio, entre muchas otras posibilidades. Este as-pecto debe ser analizado en la gerencia con la mayor atención debido al im-pacto que tiene sobre la motivación de todas las personas.

Por ejemplo, IBM de Chile, como parte de su política 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

JUAN BRAVO C. 116

empresa de 30 ex-empleados que, a poco andar, tuvo que hacer muchas con-trataciones adicionales.

4. Método de planificación estratégica en informática La planificación estratégica da el rumbo a la organización en la forma de un plan estratégico. La planificación informática fija el marco para priorizar los proyectos informáticos y obtiene un plan que debe mantenerse actualizado.

En la figura 2-3 vemos un esquema de planificación informática.

Figura 2-3. Planificación estratégica en informática

En la figura 2-3 podemos ver que a partir de la planificación estratégica de la empresa, se trabaja en las definiciones estratégicas del área informática: orga-nización de la función informática; plan de equipamiento; tipo de producto para

Realidad actual:

Definiciones estratégicasAplicaciones

Conjuntos de datosProyectos en desarrollo

Definiciones estratégicas:

OrganizaciónEquipamientoBases de Datos

MétodosHerramientas de

productividadNormas

Participación del usuario

Procesos del negocio

Referencias cruzadasProcesos vs datos

Conjuntos de datosEn los procesos


Planificación Estratégica

Evaluación

Estrategia InformáticaPrioridades de desarrollo, modelo de datos, definiciones estratégicas

y plan de implementación

Realidad actual:

Definiciones estratégicasAplicaciones

Conjuntos de datosProyectos en desarrollo

Definiciones estratégicas:

OrganizaciónEquipamientoBases de Datos

MétodosHerramientas de

productividadNormas

Participación del usuario

Procesos del negocio

Referencias cruzadasProcesos vs datos

Conjuntos de datosEn los procesos


Planificación Estratégica

Evaluación

Estrategia InformáticaPrioridades de desarrollo, modelo de datos, definiciones estratégicas

y plan de implementación


administrar las bases de datos de la empresa; métodos de la tecnología de in-formación; herramientas de productividad para los usuarios y el desarrollo de sistemas computacionales; acuerdos de normalización en múltiples aspectos y grado de participación de los usuarios.

Es importante destacar que esta planificación no es aislada, sino que se trata de un subproducto de la planificación estratégica de la organización, la cual gene-ralmente está apoyada con consultoría externa.

En paralelo con las definiciones estratégicas se puede ir avanzando en definir los procesos del negocio de la organización, principales y secundarios, orienta-dos al cliente y a objetivos internos, respectivamente. Luego, identificamos los conjuntos de datos que se manejan en cada proceso: clientes, proveedores, artí-culos u órdenes de compra. Después, construimos una matriz con todos los pro-cesos y conjuntos de datos, el objetivo es obtener referencias cruzadas y deter-minar la importancia relativa de cada conjunto de datos para comenzar a formar un modelo de datos conceptual de la organización.

Es posible obtener en esta planificación el modelo conceptual detallado, con todos los datos y relaciones.

También en paralelo, podría adelantarse en ver ¿con qué contamos? Es decir, determinar cuál es la realidad actual de las definiciones estratégicas indicadas en la segunda columna de la figura 2-3. Adicionalmente, debemos conocer las aplicaciones en funcionamiento, los conjuntos de datos ya formados y los pro-yectos en desarrollo. El objetivo es darle prioridad a aquellas aplicaciones que se perciben importantes y que, además, tienen algún grado de avance.

Con todos estos antecedentes se realiza una evaluación junto con los usuarios. Para definir las prioridades se consideran: importancia del proceso, grado de desarrollo previo y tamaño, entre otros factores. Para evaluar, es indispensable dimensionar los requerimientos de personas, capacitación, software, infraestruc-tura, comunicaciones o hardware.

Conciliar el interés particular y general es de suma importancia en esta etapa.

El plan informático que obtenemos como resultado incluye las prioridades de desarrollo, un modelo de los conjuntos de datos y sus relaciones, las definicio-nes estratégicas reformuladas a la luz de los nuevos antecedentes aportados du-rante el desarrollo del estudio y el plan de implementación 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 también participan especialistas en información. La coordinación a alto

JUAN BRAVO C. 118

nivel, gerencia general y jefaturas funcionales, se logra mediante talleres de pla-nificación estratégica en tecnología de información.

Al igual que con cualquier normalización viable, el desarrollo de la planifica-ción estratégica en informática debe tener las siguientes características: consen-sual, flexible, actualizada y vendible, en el sentido de que sea aceptable para la alta gerencia.

5. Cambio cultural de la organización La incorporación exitosa de cualquier nueva tecnología requiere un cambio cultural previo de la organización. Es preguntarse, ¿cuál es el ambiente en donde esta tecnología tiene su mayor potencialidad? Por ejemplo, en muchas organizaciones chilenas no se han obtenido los resultados esperados de los correos electrónicos y herramientas tipo Groupware, porque la mayoría de la personas no tiene el hábito de contestar un mensaje, equivalente a devolver una llamada con la anterior tecnología. En Estados Unidos sí ha tenido éxito, porque la mayoría de las personas tiene el hábito 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 país de origen del producto. ¿De qué sirve cambiar la técnica si no han cambiado las conductas que hacían ineficaz el método anterior? ¿No es equivalente a cerrar los ojos y creer que mágicamente una nueva tecnología funcionará sin los cambios de fondo que requiere?

Para el caso anterior, es mejor promover el cambio de hábito, 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 incorporación 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 organización, todos mantuvieron sus hábitos. Los usuarios siguieron sin comprometerse, los pro-gramadores siguieron codificando y manteniendo el código igual que siempre —aunque ahora en otro lenguaje— y algunas áreas progresistas de la empresa continuaron con sus islas de automatización o de desarrollo independiente.

El cambio cultural de la organización tiene relación directa con un principio sistémico: para que la organización conserve su viabilidad, todo cambio ex-terno debe ser compensado con un cambio interno equivalente, de lo contra-rio, el sistema corre el riesgo de romperse.


Para la incorporación exitosa de la tecnología es indispensable la preparación de la organización, comenzar por ubicarse en uno de los siguientes niveles de evolución de tolerancia al cambio:

1. - Anarquía: significa que las diferentes áreas son como feudos, con escasa coordinación entre ellas y sin normalización ni planes comunes. Aquí las buenas soluciones que aparecen se ven ahogadas en el medio. En este am-biente surgen “llaneros solitarios” que logran mejorar su área a costa de mucho esfuerzo personal, aunque pareciera que mantienen una situación artificial, porque, cuando ellos se van, todo vuelve a la “normalidad” ante-rior (es como empujar “murallas de goma”).

2. - Normalización interna: también llamado folklore nativo. Aquí hay un alto grado de acuerdo y compromiso al interior de la organización, con planes comunes, normalización y comunicación, aunque basada en soluciones particulares o debido al esfuerzo de algún miembro con poder que ha lo-grado imponer su visión. Es el caso del comportamiento autocrático, in-dudablemente mejor que la anarquía, aunque pobre en rendimiento. Gene-rar normalizaciones internas particulares ajenas a su negocio no es la mi-sión de la organización, esto produce un desgaste que atenta contra el me-jor desempeño global. Es como si en la empresa textil se desarrollara una herramienta de mayor productividad para informática.

3. - Normalización externa: en este caso las soluciones son compatibles con el medio, se aplican métodos y herramientas normalizadas, así la organiza-ción se inserta en su comunidad y evita desgastarse creando métodos y herramientas particulares para contabilidad, informática o finanzas. Toma del medio las tecnologías que necesita y acude al mercado laboral para proveerse de personas entrenadas; aquí ya se aprecia un fuerte compromi-so de la empresa, como un todo, con el nuevo enfoque. En este nivel co-mienza a notarse la importancia del perfeccionamiento de las personas de la organización.

4. - Adaptación a la dinámica del medio: sobre la base de la normalización externa, la organización prueba nuevas opciones. Con esto se vence la re-sistencia al cambio y la organización es permeable a las buenas ideas del ambiente. Cada vez que una tecnología se ve interesante para la empresa, se revisa, se comparten los resultados y se analiza su eventual incorpora-ción. Este último nivel permite cuestionar y renovar las normas de la or-ganización. El perfeccionamiento de las personas es vital.

JUAN BRAVO C. 120

Luego se establece un plan de trabajo para pasar al siguiente nivel. Si ya está en el nivel 4, para seguir perfeccionándose.

Un aspecto importante de esta evolución es que no se trata sólo de acciones a realizar sino que también de estructura organizacional que debe ser incorpora-da (como en el modelo de negocios del capítulo 1, el cambio debe realizarse en toda la mesa: estrategia, personas, procesos, estructura y tecnología).

En esta clasificación —por cierto flexible, porque las distinciones entre un nivel y otro no son rígidas, sino que se trata de orientaciones generales— cada nivel incluye las características evolutivas del anterior. Es interesante conocer que estudios realizados en Estados Unidos (señalados por Edward Yourdon en su curso Análisis y orientación a objetos, dictado en Santiago en Octubre de 1992) indican que el 87% de las organizaciones de ese país caen en la primera categoría, un 12% en el segundo nivel y sólo el 1% llega a los niveles tercero y cuarto, aunque es sintomático que la mayoría de las empresas Fortune39 500 estén en el cuarto nivel.

En un ambiente de amplia uniformidad y consenso está razonablemente garan-tizado que la decisión de incorporar una nueva tecnología no es producto de la impulsividad de una persona, como podría ser en los niveles anárquico o de normalización interna, sino resultado de estudios, pruebas, comparaciones formales y mucha reflexión. Es indispensable la generación de un plan de im-plementación, como parte del proyecto de cambio, que incluya infraestructura, educación, capacitación y herramientas de apoyo.

Concretamente, la implementación exitosa de los métodos y herramientas de la tecnología de información, exige que la cultura de la empresa esté en los niveles tercero o cuarto. Cuando menos, en transición desde el segundo al tercer nivel. Sólo en ese suelo fértil se puede cosechar el fruto de la producti-vidad. Si la organización está en los niveles anárquico o de normalización interna, el resultado de incorporar nuevas tecnologías es tiene alta probabili-dad de ser un fracaso más. En tal caso, es indispensable que la organización invierta previamente en el cambio cultural.

6. Resumen de la planificación estratégica en informática Este resumen no pretende ser una receta para realizar planificación en in-formática sino solamente servir de guía para profesionales, quienes introdu-

39 Se refiere al ranking de la revista homónima con respecto a las 500 empresas de mayores ingresos y rentabilidad.


cirán cambios y realizarán las adaptaciones necesarias para atender cada situa-ción particular.

Definiciones estratégicas del área informática Organización de la función informática Plan de equipamiento Administrador de las bases de datos de la empresa Métodos de la tecnología de información Herramientas de productividad para usuarios y especialistas Acuerdos de normalización en múltiples aspectos Grado de participación de los usuarios

Identificación de los procesos del negocio de la organización, 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 organización

Realidad actual De las definiciones estratégicas Aplicaciones en funcionamiento Conjuntos de datos ya formados Proyectos en desarrollo

Evaluación Participación de los usuarios Factores (negociaciones)

Importancia del proceso Grado de desarrollo previo Tamaño

Dimensionamiento Requerimientos de personas Capacitación Hardware Software Infraestructura Comunicaciones

Estrategia informática Prioridades de desarrollo Modelo de los conjuntos de datos y sus relaciones Definiciones estratégicas reformuladas

JUAN BRAVO C. 122

Plan de implementación Perfeccionamiento

En conclusión

• La TI por si sola no aporta valor, está al servicio del propósito de la organi-zación. La proporción en que se aplica será mayor si se acerca al corazón del negocio

• La buena comunicación con los socios tecnológicos es central • La TI pasa a través de integrantes de la organización quienes deben querer

usarla y estar capacitados para ello

La secuencia Fortalezas (FO), Factores de diferenciación (FD) y Ventajas competitivas (VC) es importante.

El principal esfuerzo en TI debe estar centrado en las fortalezas del negocio, así se obtendrá un factor diferenciador que luego podría llegar a ser una venta-ja competitiva. En las debilidades es preferible no desgastarse, mejor externa-lizar o aplicar la solución tipo commodity.

Se sugiere revisar el concepto de cadena de valor40 de Michael Porter, el cual se centra en el mismo mensaje: diseñar una estrategia para fortalecer los valo-res que percibe el cliente.

40 Ver libro Gestión de procesos.

FO FD VCFO FD VC


2.3. SISTEMA DE PRODUCTIVIDAD EN EL

DESARROLLO DE SOFTWARE

Una pregunta clave es: ¿cómo aumentar la productividad41 en el desarrollo de software? Desde la visión sistémica ya sabemos que no existe el factor de productividad (también conocido como bala de plata o panacea), ni siquiera la incorporación aislada de varios factores. Lo que realmente funciona es un sis-tema de productividad42.

El sistema de productividad se podría definir como la mejor combinación de todos los elementos del conjunto de factores de productividad. No se trata de tener lo mejor de cada factor, sino la combinación que resulte más apropiada a la realidad de la organización.

Como todo sistema viable, el sistema de productividad es mucho más que la suma aislada de los factores y necesariamente considera un acuerdo armonio-so entre los integrantes de la organización para su implementación.

Ya sabemos que es vital aumentar la productividad del desarrollo de software. Con la aplicación del sistema de productividad, el desarrollo de aplicaciones puede elevar su rendimiento en una proporción estimada de 1:10 (aumento de 10 veces). Esto es vital, porque más allá de las beneficiosas implicancias económicas de corto plazo, disponer a tiempo de los sistemas computaciona-les es un factor diferenciador para el éxito del negocio.

Obviamente, esto no es gratis, pues exige una inversión que debería ser asu-mida como un proyecto, comparando beneficios versus costos, incluyendo el costo vigente de la falta de información para la toma de decisiones. La inver-sión, además de dinero, incluye tiempo, disposición y esfuerzo de los intere-sados. Es más, si la organización como conjunto no está dispuesta a compro-meterse, no vale la pena el esfuerzo.

También se puede justificar el sistema de productividad desde el punto de vista sistémico: un sistema rico en variedad, como es la producción de softwa-re, sólo puede ser modificado por una solución con variedad equivalente. Esa

41 Productividad, en simple, es producir más con menos recursos. Es la base de la creación de riqueza, en el libro Gestión de procesos se profundiza en este concepto. 42 Se refiere específicamente al desarrollo de software, este sistema de productividad se puede ver como un subconjunto del método GSP presentado en el capítulo 1. Por lo mismo, no se incluyó aquí la vital orientación al cliente.

JUAN BRAVO C. 124

es la variedad que aporta el sistema de productividad. En contraposición a soluciones con escasa variedad, por ejemplo, cuando sólo abordan uno o dos factores, como el equipamiento o el software.

Se describen a continuación los principales factores detectados, con una ad-vertencia: el éxito del sistema de productividad es la armonía del conjunto, lo cual es mucho más importante que tomar lo mejor del mercado para cada fac-tor. Por ejemplo, tal vez no elijamos la herramienta más moderna, pero nues-tra selección se lleva bien con el hardware que empleamos, es fácil de apren-der y conocida en el medio (podría ser un lenguaje de programación, una herramienta cliente–servidor o un administrador de bases de datos).

Es que no hay “balas de plata” (las que matan al hombre lobo). Alfredo Weit-zenfeld se refiere a ellas (2005, p. 17): “Un legado importante de Fred Brooks fue el célebre aunque controversial artículo No Silver Bullet, en el cual se dis-cuten los desafíos más importantes de la ingeniería de software. En este artí-culo Brooks deja un desafío a las nuevas generaciones: Según miramos al horizonte de una década, no vemos ninguna bala de plata. No existe un solo desarrollo, en la tecnología o técnica de administración, que por si mismo prometa incluso una mejora de un orden de magnitud en productividad, con-fiabilidad, simplicidad, dentro de una década”.

Aunque este artículo fue escrito en los años 70, mantiene su actualidad, nada hay en el horizonte que prometa cambios radicales en las variables críticas del desarrollo de software. Hoy como ayer, sólo el trabajo arduo y metodológico hace una diferencia.

Los factores son: 1. Método 2. Técnicas 3. Herramientas de software 4. Hardware 5. Incorporación del usuario 6. Habilidad del desarrollador 7. Normalización externa 8. Factores de contexto

1. Método Se requiere método para toda la organización y que aborde el ciclo de vida completo de cualquier proyecto, no sólo su parte tecnológica. Por supuesto, el


énfasis en aspectos de calidad, control de riesgos e incorporación de las com-petencias de las personas resulta central.

Es lo que vimos en el capítulo 1.

2. Técnicas Las técnicas debieran ser modernas, simples, fáciles de aprender y conocidas por todos, tanto para el ciclo completo de desarrollo como al interior de cada etapa. Por ejemplo, orientación a objetos y UML.

Las técnicas tienen que llevar a una amplia portabilidad del software produci-do. Este concepto se aplica generalmente a implementar la aplicación en dife-rentes plataformas, aunque también se refiere a la portabilidad del diseño.

Las técnicas también deben ayudar a facilitar el perfeccionamiento de las apli-caciones, para que:

• Puedan utilizarse en otras unidades de la misma organización. • Puedan utilizarse como parte de otra aplicación. • Sean independientes de sus desarrolladores. • Sean fácil de ampliar, explicar y de utilizar por otras personas.

En otras palabras, incorporando un amplia portabilidad, en la forma de com-ponentes, como en la técnica de orientación a objetos.

Directamente relacionados con las técnicas se encuentran los procedimientos, indispensables para enlazar diferentes técnicas en distintas etapas del ciclo de vida de un sistema de información, regular la participación de especialistas y usuarios o normar el uso de una u otra herramienta según el tipo de problema.

Por ejemplo, como el enlace que veremos en el capítulo 6 entre las actividades del flujograma de información y los casos de uso de UML.

3. Herramientas de software Los métodos y técnicas tienen que estar apoyados por buenas herramientas, con especial énfasis en la amistosidad. Por supuesto, la incorporación de este tipo de software debiera ir acompañada del correspondiente entrenamiento, no sólo en el uso del producto sino también en la técnica que le acompaña, esa tecnología que viene junto con la herramienta.

Es indispensable el alineamiento entre los métodos adoptados por la organiza-ción y las herramientas de apoyo al desarrollo de software (CASE).

JUAN BRAVO C. 126

Algunos ejemplos de herramientas son: simuladores, administradores de bases de datos y generadores de aplicaciones.

En el capítulo 7 se describen algunas herramientas.

4. Hardware Mucho se habla sobre el extraordinario avance en el rendimiento de los com-putadores y el acierto de Gordon E. Moore con la conocida ley que lleva su apellido, dice que cada 18 meses se duplica la capacidad de los computadores, originalmente aplicada a los grandes equipos, se popularizó para los PC’s43.

Es innecesario profundizar en este aspecto, aunque sí puntualizar la imperiosa necesidad de aprovechar este potencial para aumentar la productividad.

Especial mención requiere la revolución provocada con la introducción de los PC’s, cada vez más poderosos, al punto de hacerse comparables con el rendi-miento de los mainframes (equipos grandes).

Incluso surgió una tendencia, llamada Downsizing44, orientada a la reducción de tamaño del equipamiento computacional y en general de toda la infraes-tructura. En el caso de los equipos, típicamente 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 solución que está siendo cada vez más utilizada es disponer de “estacio-nes de trabajo” con PC´s 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 más poderoso. Y viceversa, porque nuevo software, como los juegos para niños, requieren hardware cada vez más poderoso.

El respaldo y la solidez del proveedor fueron y siguen siendo fundamentales.

43 Sorprende al autor el rápido avance, en 1980 estaba a cargo de una instalación con equipa-miento por valor de más de un millón de dólares. Hoy, a fines de la primera década del nuevo milenio, esa misma instalación (512 KB de memoria, 200 MB en disco, 6 terminales), costaría alrededor de una milésima parte y tendría 100 veces más capacidad. 44 En el punto 3, Nuevas formas de las organización informática, de la sección 2.2, Planifica-ción en Informática, se describió este concepto.


5. Incorporación del usuario Es indispensable que trabajen en conjunto el usuario y el especialista. Resulta evidente la necesidad de preparación del especialista, sin embargo, también es vital la formación del usuario en la tecnología de información.

No obstante, la dificultad no está en el grado de capacitación, sino en algo mu-cho más profundo… la adaptación al cambio.

A veces el usuario no sabe exactamente lo que quiere, aún así, eso no es moti-vo para un trabajo anárquico. Es posible hacer prototipos en las etapas de aná-lisis y de diseño aunque sea solamente para aclarar sus requerimientos.

Usuarios entrenados en la tecnología de información, particularmente métodos y herramientas amistosas, pueden desarrollar sus aplicaciones más sencillas; además, estarán en condiciones de participar activamente en el desarrollo de aplicaciones más grandes en conjunto con el especialista.

Aquí influye un elemento conceptual de primera importancia: la aplicación le pertenece al usuario, él debiera ser el gestor, no los especialistas. La cons-trucción de un sistema de información no significa una “imposición de cam-bios” al usuario, sino que es una respuesta a su requerimiento bien planteado. El es quien debe hacer una buena gestión de la demanda.

El grado de éxito de la aplicación dependerá en gran medida de la compren-sión que tiene el usuario de su propia necesidad45 y de la calidad de la infor-mación entregada por él.

La introducción 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 educación, tal como vimos en la sección anterior.

Se puede hacer una similitud con la evolución de los automóviles desde prin-cipios del siglo XX. Cuando recién aparecieron, se pensaba que era difícil su masificación, porque cada automóvil requería un chofer-mecánico. Sin em-bargo, los automóviles se simplificaron, la infraestructura de apoyo mejoró (garajes, red vial, etc…) y los usuarios aprendieron a conducir y a realizar el nivel básico de mantenimiento (cambio de neumático o revisión de niveles).

45 Se presenta ante un Juez el infractor de una norma de tránsito, le dice: “señor Juez, es la primera vez que tengo una infracción, ¿puede anularla?” El Juez señala el computador que tiene en su escritorio (recién instalado, todavía sin funcionar) y le dice: “Si ingreso su identifi-cación, el sistema me dirá si usted dice la verdad, ¿lo hago?” El infractor contesta: “Prefiero pagar”. El Juez tiene clara su necesidad.

JUAN BRAVO C. 128

En el caso del desarrollo de software, hoy todos los elementos son más amis-tosos (hardware, muchas herramientas y métodos), existe una importante in-fraestructura de apoyo (departamentos de sistemas, consultores, proveedores) y… los usuarios están aprendiendo.

Sin que el usuario afecte su especialización dentro de la organización, debería destinar unas 100 ó 200 horas al perfeccionamiento inicial en tecnología de información y luego unas 40 horas anuales, en el marco de un equilibrio entre especialización y generalización. Naturalmente, la cantidad precisa de horas para perfeccionamiento estará dada por la definición de capacidades que se deseen obtener y la preparación previa del usuario.

¿Cómo influye la amistosidad de las herramientas en el aumento de la produc-tividad? Se entiende la característica de amistosidad en un sentido amplio, de integración del usuario e incluyendo el concepto de interfaz intuitiva, en el cual se trata de dar al software el máximo de naturalidad a través del uso de imágenes, voz e íconos.

Desde este punto de vista, se considera la característica de amistosidad como parte de la productividad, porque ésta puede aumentar casi al doble si los usuarios comienzan a resolver una porción de sus propias necesidades, es-timándose que ellos puedan absorber sin problemas casi la mitad del desarro-llo —lo cual significa que se libera la mitad del trabajo de los especialistas— particularmente la de aquellas aplicaciones que demoran más en explicarse que en hacerse. Esto es hoy una realidad para aplicaciones muy simples que se pueden resolver, por ejemplo, con una planilla electrónica o con la contrata-ción del servicio externo directamente por el usuario.

Hay que ser cuidadoso con no abusar de esta descentralización porque la au-tonomía del usuario podría interferir con la necesidad de tener sistemas cen-tralizados e integrados. La solución del conflicto es materia de un proceso de negociación interna.

Cuando el usuario soluciona sus propias necesidades menores, se obtiene un subproducto que aumenta en mucho la productividad: la reducción de las in-teracciones innecesarias con otras personas. Se le llama también costo de transacción o de administración. Es el tiempo invertido en la definición y con-trol del acuerdo. Desde un punto de vista técnico, se gana tiempo disminuyen-do el overhead administrativo, el cual se podría definir como el tiempo im-productivo destinado a una labor productiva. Este overhead46 también se 46 Se podría definir el “overhead” como el tiempo que ocupa el sistema en su organización interna para dar respuesta al requerimiento. Por ejemplo, desde el punto de vista de la rapidez,


produce cuando una persona pretende hacer 2 ó 3 tareas a la vez, descono-ciendo nuestra limitación natural de que sólo 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 suposición 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 definición de sus propios requerimientos.

Más que una generalización en este sentido, sería más preciso distinguir entre dos tipos de usuarios:

• Los emprendedores, bien representados como empresarios o intraempresa-rios, quienes gestan, participan y se comprometen con su proyecto. Son los menos. Ellos son intraempresarios o “empresarios al interior de la empre-sa”, profesionales que luchan por el proyecto como si fuera algo personal.

• Los dependientes, quienes participan en el proyecto por obligación, buscan a toda costa evitar comprometerse y quieren ver funcionando un sistema “perfecto” antes de firmar un papel. Ellos se han visto “arrastrados” al pro-yecto por imposición de la alta gerencia o por otras razones. Ya sabemos que la probabilidad de éxito del desarrollo es baja en este caso.

Por supuesto, entre los emprendedores y los dependientes hay infinidad de situaciones intermedias.

En algunas empresas está comenzando a implementarse una alternativa intere-sante: contratar a un especialista en información. Este profesional debiera te-ner amplios conocimientos de planificación estratégica, proyectos, ingeniería

el procesamiento monousuario es más eficiente que el manejo multiusuario, porque el proce-samiento de dos tareas en paralelo demora más que la suma de los tiempos de ejecución de las mismas tareas procesadas en serie. ¿Cuál es la causa? Al procesar concurrentemente, el proce-sador gasta tiempo en la coordinación de la ejecución de los diferentes procesos debido a que cuando se produce una “interrupción” 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 habría sido del 100%, porque la suma de los tiempos en modalidad monousuario es de 2 horas. ¿Cómo influirá en este efecto la nueva generación de equipos multiprocesadores? Ya se verá, en todo caso, será como procesamiento en diferentes equipos y un procesador debería atender una tarea a la vez.

JUAN BRAVO C. 130

e informática, entre otros temas que le permitan comunicarse bien con usua-rios y especialistas en informática.

6. Habilidad del desarrollador La habilidad es algo que se obtiene principalmente con la buena experiencia y una capacitación puede acelerarla notablemente.

Un aspecto fundamental de la habilidad del desarrollador es su conocimiento del negocio de la organización. También debe tener claro el objetivo final: entender como su trabajo agrega valor al negocio. Esto puede llevarlo a pro-poner cambios drásticos en la aplicación a su cargo.

Una situación difícil de creer y lamentablemente reiterativa, es la de áreas de sistemas donde algunos de sus integrantes prácticamente no saben a qué se dedica la organización y tampoco están interesados en aprender, quieren se-guir atrincherados en su inexpugnable y aislado reducto, tal como los castillos de los señores feudales durante la Edad Media.

Sobre todo, las personas aprenden en un medio exigente y con colegas de ca-tegoría. Incluso, un importante elemento de motivación para el programador es trabajar en un ambiente donde esté en constante aprendizaje.

¿Cómo influye la habilidad? Existen estudios que señalan diferencias de pro-ductividad de hasta 30 veces entre programadores. Es fácil observar en cual-quier organización las diferencias de rendimiento, verá que generalmente en una muestra superior a 10 personas la relación entre el menos y el más pro-ductivo comienza a pasar de las cinco veces. Resulta evidente nivelar hacia arriba con un esfuerzo de investigación que descubra causas asociadas al co-nocimiento, actitudes y habilidades, como en la gestión por competencias.

Trabajar en técnica y comunicación

Hemos aprendido que se requiere trabajar en dos líneas a la vez: especializa-ción y comunicación interpersonal, tal como se muestra en la figura 2-4, don-de se aprecia que la productividad es producto de la armonía entre esos facto-res. El extremo de la especialización podría llevar a la incomunicación. Las mediciones que hemos realizado en empresas muestran que en promedio es-tamos en 5 en especialización y en 2 en comunicación interpersonal, con lo cual el producto es 10. Es decir, en el 10% del potencial. Es interesante sensi-bilizar que si aumentamos 1 en la técnica, el producto será 12 y si aumenta-mos 1 en la comunicación, el producto es 15…


Figura 2-4. Armonía entre técnica y comunicación

Es vital el factor comunicación, especialmente en proyectos grandes. A esto se refieren Stevens y Pooley (2002, p. 7): “Todas las nuevas tecnologías prome-ten reducir los tiempos de desarrollo y aumentar la tasa de éxito de los proyec-tos, pero los ingenieros de software experimentados tienden a ser justificada-mente escépticos al respecto. Uno de los problemas fundamentales que ha de afrontar una técnica para tratar con grandes proyectos es el mito del hombre mes de Fred Brooks. Cuanto mayor es el proyecto, mayor es la proporción de los costes del mismo y del tiempo que se pierde en la comunicación entre la gente del proyecto, debido a que cada persona tiene más gente con quien co-municarse”. Es sabido que mientras más gente sume a un proyecto atrasado, este más se atrasará.

7. Normalización externa Es indispensable realizar un sostenido, coherente y planificado esfuerzo de normalización al interior de toda la organización 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 debería estar considerado en el plan informático, ser ejecutado por el responsable de informática y supervisado por el comité de informática. ¿Qué debe normalizarse? Todo: el hardware, los métodos de desarrollo, las herramientas de software, el entrenamiento, la documentación. ¿Por qué es necesaria la normalización? Porque la organización tiene que centrarse en su negocio y tomar del medio lo que necesite para cumplir con su misión.

10 Comunicación Interpersonal

0

0

100% de potencialidad(máxima productividad)

Especialización 10

10 Comunicación Interpersonal

0

0

100% de potencialidad(máxima productividad)

Especialización 10

JUAN BRAVO C. 132

Si estamos en un hospital, su negocio es ayudar a recuperar la salud de los pacientes y no el desarrollo de nuevas técnicas de modelamiento o la cons-trucción de hardware sofisticado. Si nuestra misión es producir o vender pren-das de vestir, probablemente lo vamos a hacer muy mal si nos desgastamos en crear e introducir métodos particulares de desarrollo de software.

No obstante, la normalización interna debería dejar espacio para la creativi-dad, el surgimiento de nuevas soluciones y el ensayo de nuevos métodos y herramientas. De alguna manera dejar una ventana abierta a la exploración de nuevas posibilidades, sin que la organización corra el riesgo de perturbar la satisfacción de sus necesidades de información. Sin ser una receta, a veces se dice que el 90% de los requerimientos debieran canalizarse por las vías nor-malizadas y el 10% por vías alternativas más innovadoras, tal vez podría ser el 10% de menor impacto en la organización...

Las normas permiten acumular experiencia transmisible, son reglas de sentido común para la organización que van siendo parte de la inteligencia colectiva.

La normalización externa otorga múltiples ventajas a la organización. Veamos algunas de ellas:

• Le permite centrarse en su misión, sin distraerse en materias ajenas. • Puede solicitar personas capacitadas externamente, a diferencia de cuando

la tecnología es particular, obligándose en este caso a efectuar grandes es-fuerzos de entrenamiento.

• Hay independencia de individuos que monopolicen y manipulen con el conocimiento específico interno.

• Puede seleccionar del medio las mejores y más productivas tecnologías. • Es más sencillo subcontratar servicios específicos.

El concepto existente detrás de la normalización es la total integración 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 tecnologías, esquemas de organización, métodos 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 pérdida de oportunidades al dispersar los esfuerzos en tareas prescindibles con el agravante de repetir esas tareas improductivas en diferen-tes áreas.


Tómese como ejemplo la anarquía en el desarrollo de sistemas computaciona-les al interior de muchas organizaciones, existiendo en el medio buenos méto-dos que podrían satisfacer sus necesidades de manera simple y económica.

Las principales características de la normalización son:

• Siempre actualizada: a través de reuniones periódicas destinadas a su revi-sión, idealmente una vez por semana. Naturalmente, la normalización tam-bién podría ser corregida frente a situaciones excepcionales, como la im-plementación de un nuevo sistema o la integración de otra persona a la or-ganización.

• Simplicidad: una normalización larga y compleja, preparada solamente por consultores o unidades especializadas de la empresa, está fuera de época y es poco práctica. Para incrementar las posibilidades de que se respete, de-biera ser breve y precisa. Por ejemplo, las pautas referidas al área informá-tica, sobre métodos, herramientas, hardware y software básico, no debieran exceder la decena de páginas.

• Orientada a toda la empresa: la normalización también debe darse al inter-ior de la empresa, de tal forma que todos sus estamentos normalicen políti-cas, métodos, herramientas, tecnología y todo aquello que facilite la comu-nicación.

• Consenso: las diferentes normas debieran ir surgiendo como resultado de consenso entre todos los interesados, para asegurar la implementación. Cuando las pautas son impuestas por la jerarquía, consultores u organismos especializados de la empresa, las posibilidades de que sean respetadas son menores.

• Permite las innovaciones: la normalización no significa “ahogar la empre-sa” con reglamentaciones. Muy por el contrario, se toman del medio es-quemas probados para no distraer la atención de los verdaderos intereses de la organización. En este contexto, las innovaciones son bienvenidas y pue-den desarrollarse con amplia colaboración. La buena normalización garan-tiza el funcionamiento regular de la institución, dejando espacio para el de-sarrollo permanente de nuevas ideas.

• Conocida por todos los interesados: se recomienda crear un sistema de información destinado a enviar oportunamente un ejemplar de la normali-zación o de su actualización a todos los interesados, según una “base de usuarios” actualizada y con mecanismos apropiados para eliminar las co-pias anteriores obsoletas.

• Atiende materias específicas: no existe “la normalización” de la empresa, sino que son varias y cada una atiende un asunto específico. Es preparada

JUAN BRAVO C. 134

por quienes están dedicados a la materia; por ejemplo, en la normalización informática participan analistas, programadores y usuarios. Otros temas se orientan a mantención, producción, administración o secretaría.

8. Factores de contexto Hay otra serie de factores que también debemos tomar en cuenta. Si son posi-tivos pueden ayudar a aumentar la productividad más allá de las 10 veces seña-ladas al comienzo de esta sección acerca del Sistema de productividad en el desarrollo de software.

Algunos factores de contexto son:

• Calidad de la planificación, en el sentido de su reformulación 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 organización. • Motivación de las personas. Con amplia participación, cumplimiento de

los acuerdos y un ambiente de colaboración. Ya vimos en el capítulo 1 la especial relevancia que tienen el liderazgo y el trabajo en equipo.

• Ambiente físico: temperatura, ventilación, comodidad, tranquilidad, silen-cio y otros elementos ambientales tienen un importante rol que jugar en la productividad de los profesionales de sistemas y de toda la organización.

• Permeabilidad de la empresa a la innovación tecnológica. • Respuesta a la competencia y permanente conocimiento de lo que el mer-

cado ofrece. • Capacidad de la gerencia, particularmente en la línea de ser más

empresario que administrador. • Conocimiento del problema: es vital la participación 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 podrían resumirse en la búsqueda de la ex-celencia en la gestión.


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 diseño de una aplicación computacional, antes orientado a la optimización en el uso de recursos computacionales y ahora con énfasis en la simplicidad y la calidad del diseño, independiente de la imple-mentación tecnológica.

Con esa filosofía se presentan a continuación 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 solución de software

1. Criterios anticuados de desarrollo de software Antiguamente enfrentábamos el desarrollo de sistemas con el siguiente crite-rio de optimización:

Mínimo uso de espacio en disco, memoria principal y tiempo de procesador.

La aplicación de esta pauta dio origen a modalidades de construcción de sis-temas que retrasaban el desarrollo, perturbaban la mantención y dificultaban la actualización de la documentación, como éstas:

• Diseño del sistema en forma muy particular. Se definen repositorios de datos y programas en forma muy particular para la aplicación, tanto que, finalmente, sólo son conocidos por el especialista, con el riesgo de que aun a él se le olviden las particularidades. Son las llamadas “ingeniosidades”.

• Construcción de programas grandes que resuelven varias funciones. Se supone que tienen la “ventaja” de “cargar” sólo un programa que resuelve muchas funciones, en lugar de varios programas que se irían llamando según se requieran. El programa grande es consumidor de recursos, difícil de construir y de mantener. Habitualmente incorpora elementos extraños como switches (marcas o “banderas” que ayudan a condicionar bifurcacio-nes) e instrucciones sofisticadas del lenguaje, no posee una buena estructu-

JUAN BRAVO C. 136

ración y más bien está construido con una desagregación muy poco funcio-nal.

• Definición de rutinas complejas. Nada hay que complique más la manten-ción que la incorporación de rutinas complejas dentro de un programa. Siempre es posible simplificar y modularizar las rutinas. Es más, en la ma-yoría de los casos el problema que da origen a la rutina compleja podría haberse enfrentado de otra manera en el diseño. También podrían utilizarse rutinas prehechas o generadas con herramientas de cuarta generación. Construir rutinas complejas para resolver problemas del mismo tipo ¿no es como reinventar frecuentemente la rueda?

• Utilización de matrices en programas. Es típico de programas muy com-plejos hacer uso indiscriminado de vectores o matrices, los cuales represen-tan una excelente instancia de optimización, pero no deberían utilizarse a menos que sea realmente indispensable porque el contenido del vector o matriz queda invisible para la organización, la información pasa a ser parte del código, con enormes dificultades para su actualización (hoy con la in-troducción masiva de las bases de datos es menos frecuente en nuevos sis-temas, sin embargo, todavía hay mucha mantención de sistemas antiguos).

Por ejemplo, en el cambio de milenio (pasar desde 1999 al año 2000) el problema era que en las aplicaciones antiguas los programadores habían asignado solamente dos dígitos al campo “año” para ocupar menos espacio. De esta forma el computador “entendía” que pasaba desde 99 a 00 y enton-ces bajaba de año en vez de subir. Una complicación adicional fue que los datos estaban dentro del programa (por ejemplo, que hacer al llegar cierta fecha) y no como parámetros. Además, el 00 y el 99 se usaban como “ban-deras” o condiciones de diferente tipo.

Con el abaratamiento de los medios de almacenamiento y la mayor velocidad de los procesadores, el criterio de optimización quedó obsoleto. Como mues-tra, véase el siguiente ejercicio:

Un usuario de un PC necesita mejorar el tiempo de respuesta de su aplicación, la cual funciona bien, pero cada consulta demora hasta 10 segundos y él re-quiere la respuesta en un máximo de 3 segundos.

Se plantean dos alternativas de solución:

• Adquirir un equipo más poderoso, de mayor rapidez y capacidad de alma-cenamiento. El costo de esta solución es US$ 500, considerando lograr algún ingreso con la venta del PC antiguo.


• Contratar un programador para optimizar el código de los programas. El presupuesto es de US$ 400.

En la figura 2-5 se muestra el ejemplo de una tabla comparativa entre las solu-ciones propuestas para un período de tres años.

Figura 2-5. Tabla comparativa para disminuir tiempo de respuesta

Es interesante observar en la figura 2-5 lo engañoso que puede llegar a ser dejarse llevar por el menor costo inicial de la optimización del código porque el costo total, considerando la mantención del código, asciende a US$ 1.000 en el caso de codificar y a US$ 600 en el caso de ampliar el hardware. Es cla-ramente conveniente ampliar el hardware y esto sin considerar los otros facto-res de comparación que, si se cuantifican en dinero, ampliarían todavía más la brecha.

Otros factores serían: ¿cuánto es el costo de oportunidad al retrasar la solución en un mes, en el caso de optimizar código? y ¿cuánto cuesta el tiempo del usuario, considerando que al optimizar código debe disponer de tiempo para interactuar con el especialista?

Es importante destacar que en el caso de la optimización de código, se ha va-lorado conservadoramente el costo de la mantención, el cual puede elevarse varias veces cuando el programa no está bien documentado o los métodos de programación han sido anárquicos.

Este ejercicio se puede extrapolar a problemas mayores en las instalaciones, donde hay otros factores que también inciden. El objetivo ha sido destacar que la simple renovación del hardware resuelve automáticamente un cierto rango de problemas. Lo mismo es válido para variadas formas de externalización.

Factor de comparaciónAmpliar hardware

Optimizar código

Costo inicial US$ 500 US$ 400

Costo de mantención US$ 100 US$ 600

Tiempo de implementación 2 días 1 mes

Tiempo del usuario 1 día 1 semana

Utilización en otras aplicaciones alta nula

Factor de comparaciónAmpliar hardware

Optimizar código

Costo inicial US$ 500 US$ 400

Costo de mantención US$ 100 US$ 600

Tiempo de implementación 2 días 1 mes

Tiempo del usuario 1 día 1 semana

Utilización en otras aplicaciones alta nula

JUAN BRAVO C. 138

2. Mitos del desarrollo de software En algunos departamentos de sistemas, nuevos mitos han tomado el lugar de los antiguos criterios de desarrollo, manteniéndose los clásicos problemas de:

• Colas de “desarrollo pendiente” que alcanzan a varios años. • Ciclo de desarrollo excesivamente largo, a veces de más de un año. • Dedicación predominante a la tarea de mantención, en lugar de atender los

nuevos requerimientos del negocio.

Algunos de los nuevos mitos en el desarrollo de software son:

• Desarrollar rápidamente, apoyándose en variadas herramientas y olvidan-do considerar que cada línea de código deberá ser mantenida.

• Una correcta especificación evitará la mantención, desconociendo que el 80% de la mantención se debe a cambios y el 20% a errores.

• Automatizar el máximo de funciones administrativas, sin evaluar que en un gran porcentaje de los casos, el costo para la organización aumenta geomé-tricamente (se reduce 3 aumenta 9) a raíz de la mantención del código.

• Desarrollo por prototipos es la solución, aplicándolo en sistemas compu-tacionales donde su aporte es escaso y descuidando la necesaria definición previa de requerimientos.

• Las herramientas de cuarta generación serán la solución, olvidándose de la necesidad del modelamiento de la solución, del aporte de código muy específico y del problema de la conversión de datos desde aplicaciones an-tiguas.

• Cesantía de programadores, en la realidad se está produciendo el fenóme-no contrario, una oferta total de trabajo creciente para especialistas prepa-rados en apoyar a los usuarios. Este mito se alimenta a veces de algunos pocos ejemplos de externalización (outsourcing) donde se han despedido programadores, sin tomar en cuenta que las nuevas empresas proveedoras de servicios informáticos contratan especialistas a una tasa mayor que los despidos por ese concepto.

Así llegamos a tener usuarios desesperados porque todavía no obtienen lo que necesitan, incluso algunos han optado por seguir su propio camino, produ-ciéndose las llamadas “islas de automatización”, con lo que aumenta más aún la confusión.


3. Nuevos principios para el desarrollo de software En los años 60 y 70 el manejo de información se orientó más a los procesos computacionales que a la administración de los datos, porque el objetivo era la optimización de algoritmos para economizar tiempo y memoria debido a la limitación de recursos de hardware. Es en el mismo período cuando comienza la aplicación del análisis y diseño estructurado.

En los años 80 se dio una importancia desproporcionada a los sistemas admi-nistradores de bases de datos (muchos especialistas pensaron que era la tan anhelada panacea) con énfasis en las estructuras de datos. Fue un esquema difícil de entender, engorroso de implementar y excesivamente caro, pero tuvo el gran mérito de llamar la atención sobre la importancia de los datos.

En los noventa, con el surgimiento de estándares como la orientación a obje-tos y UML, más el énfasis en trabajar metodológicamente, se dio inicio a un proceso de profesionalización que efectivamente ha producido un avance en la calidad del software.

Hoy estamos en busca de un equilibrio entre la orientación a los procesos o a los datos —de ahí que haya tomado auge tan rápidamente la orientación a ob-jetos—. Es en este contexto que se plantean algunos principios para un nuevo esquema de desarrollo de software:

• Lograr la producción profesional del software. A través de métodos y herramientas normalizadas para producir software de calidad, personaliza-do, económico, portable, simple, rápido y amistoso, en plazos convenidos y dentro del presupuesto asignado.

• Resolver sólo problemas simples. Aplicando los criterios de modulariza-ción y de descomposición funcional, siempre es posible dividir un proble-ma complejo en un subconjunto de problemas más fáciles de resolver; por lo tanto, lo que finalmente se resuelve son problemas simples, aunque man-teniéndose la visión de conjunto.

• Evitar las particularizaciones producto de una optimización innecesaria. Una vez que el problema ha sido resuelto en forma simple e independiente de la implementación tecnológica, se debe estudiar si es realmente necesa-rio aplicar fórmulas de optimización, porque podrían introducir sofistica-ciones indeseadas en el modelo.

• Independencia de la aplicación respecto al especialista. Un problema fre-cuente ha sido el alto grado de dependencia de la aplicación respecto del especialista que la desarrolló. Lo que ahora se busca es permitir que otros especialistas y usuarios calificados puedan también entender, mantener y

JUAN BRAVO C. 140

continuar el desarrollo de la aplicación frente a la salida del primer desarro-llador. De esta manera, cada nuevo desarrollo de sistema será una inversión en inteligencia para la organización.

• 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 sección anterior.

4. ¿Construir sistemas computacionales sin programar? Es plenamente factible construir software sin necesidad de programar, me-diante herramientas que generan completamente la aplicación o a través de la biblioteca de clases de la orientación a objetos (claro que en este caso, un equipo de desarrollo previamente debería haber construido las clases).

Cierto que cualquier aplicación compleja incluye en definitiva alguna cantidad de programación, también es válido que el apoyo ofrecido por las herramien-tas de productividad va en aumento y es posible que en algún momento repre-sente un porcentaje cercano a la aplicación completa. Hoy está consolidado su aporte en la construcción de los elementos más normalizados: definición de pantallas, informes, menús y otras partes de la aplicación.

Una dificultad en la producción de software es la estructuración manual de lógica o programación, la cual relativamente pocas personas son capaces de hacerla correctamente. Considérese que en Estados Unidos se han efectuado estudios que indican que sólo el 1% de la población tiene aptitudes naturales para ella (veremos que se refiere a la estructuración de lógica en programas grandes). Quienes no tienen esa aptitud natural y necesitan programar, deben tener una larga formación hasta lograrlo. En todo caso, si el porcentaje de la población con esa aptitud es tan bajo, significa que la programación es una actividad poco natural.

Una forma de reducir el impacto de este problema es mediante un buen diseño implementado con la ayuda de una herramienta de productividad. Esto facilita la participación del usuario y se motiva al especialista a resolver el problema en un nivel de modelo conceptual, más que a nivel físico, o de programación.

“Sin programar” significa más bien “sin programación tradicional”, esos pro-gramas largos, de miles de instrucciones en lenguaje de alto nivel, difíciles de construir y de mantener. No es el caso de la necesaria estructuración de las “reglas del negocio” en pocas decenas de líneas de pseudocódigo 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 estaría trabajando. Por ejemplo:


SI campo existencia ES MENOR O IGUAL QUE campo nivel mínimo, ENTONCES emitir orden de compra.

No es lo mismo escribir 50 reglas del negocio de 30 líneas cada una, que cons-truir un programa de 1500 líneas de código. Aunque en ambos casos debe actuar un especialista. Lo primero lo puede hacer en pocos días, en tanto que para lo segundo requerirá de varias semanas, además de mucha más destreza.

Para mantener el código, la dificultad disminuye proporcionalmente al tamaño de los programas; por ejemplo, realizar un cambio en una rutina de 30 líneas es cuestión de minutos; el mismo cambio en un programa de 1.500 líneas re-quiere varios días. Esto, porque impactan aspectos sicológicos y de ordena-miento del programa que hacen muy difícil el trabajo en un programa grande.

En resumen, en las aplicaciones complejas sigue existiendo la necesidad de aportar código, tarea destinada a especialistas en informática, quienes pueden acceder a técnicas y herramientas que les simplificarán su labor. Sobre todo, modelar bien.

5. Pruebas del software por el programador Un concepto que aporta el método 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 eléctrica o de agua fuera probada por otras personas y en otro momento?

La extrema especialización en informática llevó a que en algunos centros un programador sólo codificaba y otra persona debía probar el programa, señalarle por escrito los errores y entonces él procedía a efectuar las correcciones que luego seguían el mismo ciclo. En gran medida, esta deficiencia se producía por la separación en dos etapas del proceso codificar-probar47.

Lo cual no se contrapone con la existencia de un área de testing porque su labor viene después de que el mismo programador realizó las pruebas de lógica de su propio código.

Es que probar es más que verificar la efectividad de una programa de computa-dor, también significa probar la aplicación completa para revisar su diseño y

47 A tanto llegó este criterio que en una oportunidad un programador se molestó con el autor de este libro porque le pidió que le entregara probada la rutina que el mismo acababa de cons-truir. Explicó, exaltado, que su función era codificar, no probar el resultado de las rutinas, esa actividad, señaló, era para alguien de inferior categoría…

JUAN BRAVO C. 142

verificar si se cumplen los requerimientos actualizados. Porque el problema inicial podría haber variado mientras se diseñaba o programaba.

Existe amplia flexibilidad para la realización de las pruebas. Podrían llegar a ser tan simples como ensayar con datos de prueba o equivalentes a un paralelo, por-que se trabaja construyendo un prototipo que se va transformando poco a poco en la aplicación final, a través de perfeccionamientos sucesivos. Las herramien-tas CASE apoyarían la verificación de consistencia y documentación. Respecto a pruebas con altos volúmenes de datos, irreemplazables en aplicaciones grandes, también se cuenta con apoyo semiautomático, porque ya se está haciendo gene-ral que las herramientas CASE provean generadores de datos de prueba.

Las últimas pruebas son en ambiente real, lo que es equivalente a tener la apli-cación en funcionamiento normal, aunque en la forma de un piloto, tal como vimos en la etapa de implementación del método.

Luego, la dinámica del medio y de la propia empresa48 hacen que todo sistema esté en permanente mejoramiento. Entonces, desde el principio hay que mante-ner intacta la capacidad de desarrollo continuo de una aplicación, tema que ve-remos más extensamente en el siguiente punto, sobre mantenimiento de la solu-ción de software.

6. Mantenimiento de la solución de software Cada vez en mayor medida, la palabra mantenimiento está siendo reemplaza-da por perfeccionamiento en el contexto de la tecnología de información. Es indispensable comenzar a aplicar al desarrollo de aplicaciones el concepto de mejora continua, el cual comienza en el momento de terminar la implementa-

48 Cuando comenzó la computación este replanteamiento no era tan indispensable, porque las variables ambientales se movían más lentamente. Hoy, aparecen productos diferentes, nuevos métodos y herramientas con una velocidad sorprendente. La creciente competencia obliga a mantener un muy alto nivel de flexibilidad y de adaptación a todo tipo de cambios. Este es el contexto de la teoría del caos, la cual postula que una predicción puede tener una alta proba-bilidad de certeza solamente en el corto plazo, mientras que en el mediano y largo plazo la predicción no tiene ninguna validez y se obtendrá un comportamiento errático, de ahí la pala-bra “caos”. En el ambiente organizacional, esa alta probabilidad de ocurrencia significa sólo algunas semanas. Cualquiera estimación de años, es prácticamente inútil, porque depende de pequeños cambios en las condiciones iniciales que hoy día nos parecen insospechadas… por ejemplo: se fue un empleado clave, Estados Unidos aumentó su tasa de interés, se enfermó el gerente de finanzas, el dueño de la empresa tuvo un conflicto matrimonial, lanzamos un pro-ducto menor con un éxito sin precedentes... Esto significa que la planificación debe agregar la condición de reformulación permanente.


ción y aun dentro del período de garantía que todo sistema computacional debe tener, al igual que un edificio o un nuevo artículo.

El período de garantía es el equivalente a la marcha blanca del desarrollo tradi-cional de sistemas. Es un tiempo convenido, en el cual, además de conservarse la posibilidad de desarrollo continuo de la aplicación, se busca disponer de los mismos especialistas que participaron en el desarrollo. También debiera dispo-nerse de apropiados recursos de hardware y software, ojalá los mismos que se emplearon durante la construcción. Sabemos que este período 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 documentación actualizada en todo momento, ojalá con el apoyo de alguna herramienta de productividad.

• Un alto grado de participación y compromiso del usuario. • Ir probando cada estructura o función que se construye, evitando juntar

todas las pruebas para el final. • Resolver en forma automática los problemas de consistencia, de regenera-

ción de estructuras frente a cambios, de integración del proyecto. • Generar automáticamente o usar código reutilizable en un alto porcentaje de

la aplicación.

En esto puede ayudar la técnica de desarrollo en espiral que se presenta en el anexo 3.

En una instalación tradicional, los principales esfuerzos de mantenimiento se destinan a:

• Modificación o reconstrucción de programas. • Actualización de documentación. • Búsqueda de programas, bibliotecas y documentación. • Ordenamiento de manuales, versiones de programas y cambios en reposito-

rios de datos. • Pruebas. • Reentrenamiento.

Aquí hay una diferencia notable respecto al método tradicional. Ahora el man-tenimiento del sistema significa realizar cambios sobre el diseño, la especifica-ción o las reglas del negocio y rehacer parte de la aplicación con la ayuda de alguna herramienta de desarrollo.

JUAN BRAVO C. 144

Se estima que este solo concepto permite elevar la productividad de los especia-listas en un departamento de sistemas al menos en 100 %, porque unos dos ter-cios de las actividades regulares de los centros de computación están destinadas a mantenimiento.

Junto con el mantenimiento de un sistema computacional se realiza su explota-ción, esto es, la operación regular de la aplicación destinada a satisfacer el requerimiento para el cual fue construida. Sin pretender profundizar en esta materia, conviene señalar algunas labores clave:

• Mantención de una bitácora de procesos • Control de funcionamiento correcto • Optimización de recursos • Reconstrucción de bases de datos • Seguridad e integridad de la información • Recuperación de la información • Auditoría computacional


2.5. MÉTODOS PARA LA PRODUCCIÓN DE SOFTWARE

Los métodos de desarrollo apuntan a “cómo” construir técnicamente el soft-ware. Generalmente se han clasificado en dos grandes grupos:

• Sobre la gestión del proyecto: donde se proponen métodos para planifica-ción y control del proyecto de software.

• Sobre el desarrollo del software: donde se proponen métodos generales para todo el ciclo de desarrollo y particulares según cada etapa: análisis, di-seño o implementación.

En lo que sigue, se presentan algunos ejemplos de métodos de apoyo: el ciclo de vida clásico, que abarca todas las etapas del desarrollo de sistemas, la técnica de prototipos, la cual apoya especialmente las etapas de ingeniería y diseño y el diseño estructurado. Todos han tenido su cuota de contribución en las definiciones que estamos logrando.

No se incluye aquí la orientación a objetos ni UML porque, debido a su im-portancia, les dedicamos los capítulos 5 y 6.

Veremos: 1. Ciclo de vida clásico 2. Técnica de prototipos 3. Diseño estructurado 4. Programación extrema (XP)

1. Ciclo de vida clásico El ciclo de vida clásico es más que un método orientado sólo a la producción de software, representa un todo armonioso dirigido al desarrollo de sistemas de información49.

Consta de las siguientes etapas:

1.- Diagnóstico: su objetivo es identificar el problema y situarlo en su medio.

2.- Factibilidad: su objetivo es plantear y evaluar alternativas de solución al problema identificado.

3.- Diseño lógico: 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 información, una visión práctica, se analiza este método en todo detalle.

JUAN BRAVO C. 146

cuanto a departamentalización, organización general, definición de los procesos del negocio, diseño de funciones, flujos de información, diseño de formularios, diseño del sistema de codificación y diseño del modelo de datos (modelo de información).

4.- Diseño físico: su objetivo es el diseño computacional del sistema; se defi-nen los conjuntos de datos, la organización del sistema y se especifican los programas.

5.- Programación: su objetivo es construir y probar los programas especifi-cados en la etapa de diseño físico.

6.- Implementación: su objetivo es la puesta en marcha del sistema mediante pruebas generales, producción de la documentación del sistema, entrena-miento de las personas, poblamiento de las bases de datos y procesamien-to en paralelo.

7.- Mantención: su objetivo es dar respuesta a cambios sobre el sistema des-pués de su implementación. Se estima que esta tarea consume tanto tiem-po y recursos como unas tres veces todas las etapas anteriores (con el riesgo de que se eternice).

Estas siete etapas del ciclo de vida clásico 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 más comunes que intenta resolver este método son:

• Tiempo de desarrollo normalmente excedido.

• Largas colas de espera de aplicaciones por desarrollar: visibles, que están en la planificación de actividades, e invisibles, de usuarios que aún no co-munican ese requerimiento, justamente por el excesivo tiempo de respuesta del área de informática.

• Especificaciones poco adaptadas a la realidad. La demora en los ciclos de desarrollo provoca una desactualización de los requerimientos iniciales. Así, la etapa de implementación viene seguida de una redefinición de re-querimientos y de un nuevo proceso de desarrollo, retardándose excesiva-mente la etapa de explotación.

• Aplicación anárquica del método, prácticamente cada especialista tiene su propia forma de desarrollar sistemas.

• Dificultad de comunicación entre especialistas y usuarios.

• Aplicaciones poco flexibles.


Y sin considerar los problemas de la mantención y documentación.

Aunque es posible aplicar desarrollo en espiral, generalmente el método de ciclo de vida clásico usa el esquema tipo cascada, donde se requiere un muy alto grado de precisión en la determinación de requerimientos para enfocar la aplicación desde una perspectiva integral. Se hace necesaria entonces una gran capacidad de abstracción 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 abstracción no está suficientemente desarrollada en el ser humano. Si ya se requiere un gran esfuerzo de formación para el desempeño de tareas netamen-te intelectuales, como el trabajo administrativo, donde se utiliza mucha simbo-logía (escritura y cálculos) y un cierto nivel de abstracción; entonces, ¿qué sucede cuando un usuario se enfrenta a pensar todas las posibles variaciones de un proceso todavía inexistente? Lo más probable es que resulte un esfuerzo largo, tedioso e inútil, porque los requerimientos quedarán incompletos, con-fusos y errados.

¿Por qué debieran enfrentarse usuarios y especialistas a este esfuerzo poco natural? Simplemente por inercia, porque así se ha hecho siempre. El ciclo de vida clásico ayuda a resolver esta situación, aunque al principio (desde los años 60) era sólo para “iniciados” siendo muy escasa su difusión. En el mismo período, 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 término “iniciados” haciendo una comparación 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. Técnica de prototipos La idea del prototipo de un sistema computacional es la misma que el prototi-po de un avión o de un automóvil: a partir de una idea original, se construye un producto concreto que se perfecciona mediante aproximaciones sucesivas realizadas en múltiples contactos de prueba con la realidad.

La técnica de prototipos es una ayuda en cualquier etapa del ciclo de desarro-llo, porque permite aclarar un problema o visualizar una solución. También complementa algunos métodos de diseño con excelentes resultados.

JUAN BRAVO C. 148

Existen prototipo evolutivos y de usar y botar. Los primeros siguen un proceso de avances sucesivos bien controlado que poco a poco van perfilando una so-lución. Los segundos son específicos y a estos nos referimos principalmente en este punto.

Un prototipo no es el sistema final. Se hace esta aclaración porque a veces entran en explotación sistemas incompletos que nacieron como prototipos. Eventualmente un prototipo puede ser la base de un sistema concreto, pero hay que terminarlo.

Esta técnica está adaptada a lo natural para el ser humano: tomar decisiones según el método de prueba y error; es decir, pensar una solución, desarrollarla y probar, si sirve queda, si no sirve se descarta, en lugar de excesivos estudios y planeamientos.

Un artículo de la revista América Economía en 1993 reveló que el nivel de fracasos de proyectos con extensos estudios de mercado es de un 92%. Queda el mensaje implícito que se obtienen casi los mismos resultados sin haber hecho mayores estudios y aplicando mucho sentido común.

La técnica de prototipos necesita una definición de requerimientos menos ex-haustiva para plantear un producto de software que se va perfeccionando de acuerdo con lo observado en las pruebas y según el uso real y práctico. Es importante señalar que en este caso el cambio es suave, escalonado, adaptado a las necesidades reales y no traumático para usuarios, quienes no ven altera-das sus rutinas de un momento a otro, como cuando llega un nuevo sistema en el cual no han participado.

El desarrollo por prototipos tiene su base en la técnica de prueba y error, am-pliamente utilizada en la naturaleza, lo que se puede apreciar a simple vista al observar la adaptación al cambio y el crecimiento de las especies.

¿Cómo influye el error en el crecimiento?

En la naturaleza, cada error que se produce es una alternativa que se prueba. Así funciona: supóngase que una manada de osos se traslada hasta el Polo Norte50; la piel de estos osos es mediana y no está adaptada a los rigores de las bajas temperaturas, por lo tanto, se estima que en unas 4 generaciones ya de-berían haberse extinguido totalmente. Sin embargo, ¡eso no sucedió!, a la cuarta generación la población de osos es superior a la que llegó inicialmente,

50 (Esperemos que seamos capaces de detener el calentamiento global para que los osos de este ejemplo conserven su habitat y puedan sobrevivir, al igual que muchas otras especies).


pero... la mayoría tiene una característica diferente: su piel es más gruesa que la de los osos de la primera generación.

¿Por qué?

¿Tal vez la piel se fue haciendo progresivamente más gruesa como respuesta al medio, producto de una planificación o de un “supercerebro”?… ¡No! Sim-plemente es otro “error” de la naturaleza que resultó ser apropiado en ese am-biente y aumentaron las probabilidades de supervivencia y de reproducción de los ejemplares que nacieron con el “error” de una piel más gruesa.

¿Cómo 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.

Figura 2-6. Ejemplo de grosor de la piel de las crías de osos

Obsérvese en la figura 2-6 que la más alta probabilidad en la primera genera-ción se da para que la piel de una cría 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 más delgada o con piel más gruesa. Cuando nacen con piel más del-gada, las probabilidades de sobrevivir en el frío son escasas. Cuando nacen con piel más gruesa no sólo aumentan sus probabilidades de sobrevivencia, sino que, además, pueden transmitir ese “error” a un mayor número de crías, lográndose que, poco a poco, se mueva la curva de normalidad desde piel me-diana a piel gruesa.

Esto es el método de prueba y error que emplea la naturaleza y es la base para plantear el método de prototipos.

Población de ososEn el Polo Norte

Grosor de la piel

Piel delgada

Piel normal

Piel gruesa

Primera generación Cuarta generaciónPoblación de ososEn el Polo Norte

Grosor de la piel

Piel delgada

Piel normal

Piel gruesa

Primera generación Cuarta generación

JUAN BRAVO C. 150

Para la mejor comprensión del método de prototipos, puede observar el juego de un niño, ojalá menor de 7 años, para apreciar cómo, una vez que se plantea una meta, hace todos los intentos necesarios para cumplirla; aprende de sus errores y no se cuestiona personalmente por cada “fracaso” que tiene. Tam-bién se puede apreciar la libertad que usa para buscar soluciones a su proble-ma, sin mayores prejuicios. Se podrá observar que la forma de seleccionar alternativas que el niño emplea, aún está exenta de nuestros patrones de con-ducta, de nuestros limitantes “debe ser así”.

Cuando el niño ensaya opciones, las primeras alternativas que practica son las que le proveen de mayor información, así aprende por cuales caminos seguirá después.

Así también con los prototipos; cada iteración y especialmente las primeras, proporcionan valiosa información para realizar correcciones y decidir la nueva ruta. Por lo tanto, teniendo claro los objetivos, el rumbo principal de una apli-cación queda definido en las primeras iteraciones con el prototipo.

Los prototipos se aplican habitualmente a:

• Definir requerimientos: significa efectuar una presentación preliminar de formularios y procesos para acotar y aclarar el requerimiento. Generalmen-te el prototipo es desechado después de cumplir con su objetivo.

• Revisar interfaces visuales: son los más habituales y se confeccionan para repasar el formato, la presentación y la secuencia de menús, pantallas de ingreso de datos, formularios, informes y todo lo relacionado con la inter-acción con el usuario.

• Estudiar la funcionalidad principal: significa definir con precisión cuál es el objetivo principal del sistema y construir un prototipo que resuelva esa necesidad específica; por ejemplo, el control del stock en un sistema de in-ventarios o el formulario de liquidación de renta mensual en un sistema de remuneraciones.

Dependiendo de cada problema, debe estudiarse la real conveniencia de apli-car la técnica de prototipos, ella es especialmente útil en problemas adminis-trativos donde cuesta definir todos los requerimientos o los mismos son muy cambiantes; en tal caso, el usuario desearía ver un bosquejo de lo que desea antes de hacer una definición en detalle.

En las primeras iteraciones con el prototipo se utilizan datos de prueba, luego se va introduciendo información más consistente, hasta llegar a trabajar con los datos reales. Puede realizarse entonces una comparación contra el funcio-namiento manual del sistema o alguna solución de software anterior, aunque


esto en la práctica ha resultado difícil, porque muchas de las facilidades que se obtienen con las herramientas de apoyo no existían antes.

En general, no son aplicables los prototipos para el desarrollo de sistemas de uso generalizado, tales como inventarios, cuentas por cobrar, cuentas corrien-tes y contabilidad. Es preferible que la empresa adquiera ese tipo de sistemas en el mercado y reserve el desarrollo interno para los sistemas computaciona-les directamente relacionados con su negocio.

3. Diseño estructurado El diseño estructurado responde a una visión funcional del sistema. Nació en los años 60, en un contexto tecnológico totalmente distinto al que conocemos hoy. En aquellos días era fundamental la economía 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 diseño estructurado son:

• Estructura jerárquica: significa modelar el sistema desde arriba hacia aba-jo, tipo top down, comenzando por una visión de alto nivel que se va deta-llando en niveles cada vez más profundos.

• Concurrencia: significa que existen varios procesos que pueden ser activa-dos en forma simultánea; se aplica en contraposición al sistema secuencial.

• Modularidad: significa identificar módulos completos, bien definidos y con las interfaces entre ellos. Cada módulo tiene una función precisa sobre una estructura de datos. Una característica deseable es que un módulo pue-de servir a otra aplicación. Se aplican aquí los siguientes criterios: o Acoplamiento, equivalente a traspasar información entre rutinas. Se su-

giere que sea lo más débil posible. o Cohesión interna del módulo; lo más fuerte posible.

• Descomposición funcional: es el concepto detrás de la modularidad, signi-fica tener funciones atómicas, que resuelvan solamente una necesidad, con la mayor independencia entre sí.

Antes, junto con el diseño estructurado se ocupaba la programación estructu-rada, con la idea de que los módulos definidos a nivel del diseño pudieran ser parte de un programa, más precisamente, de un gran programa. Porque el ob-jetivo de la modularidad era incluir una gran cantidad de módulos en cada programa. Supuestamente, eso simplificaría la construcción y la mantención.

Estudios sicológicos demostraron que eso es prácticamente imposible, porque aun cuando un programa estuviera bien estructurado y documentado, lo cual

JUAN BRAVO C. 152

es de por sí casi una utopía, después de un tiempo ni siquiera el programador que lo construyó creía en eso y efectuaba revisiones detalladas para efectos de la mantención, perdiéndose los supuestos beneficios del enfoque51.

Las principales herramientas del diseño 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 través de diferentes niveles que representan el grado de descomposición de los procesos en subprocesos, hasta llegar al nivel elemental o atómico. Esta herramienta se divide en dos partes: diagrama de contexto y D.F.D. nivelado; veremos cada una de ellas, más el D.D. y la mini especificación.

El diagrama de contexto muestra la ubicación del sistema respecto al medio donde se encuentra. La ubicación está dada por la relación que se produce (y que debe existir) entre las entidades que le solicitarán o le proveerán de datos o información. Las entidades —también llamadas fuentes— son empresas, departamentos o personas relacionadas con el sistema, las cuales proveen o reciben información del sistema;

En la figura 2-7 podemos apreciar un ejemplo: el diagrama de contexto de un sistema de control de stock.

Figura 2-7. Ejemplo de diagrama de contexto

En la figura 2-7 el círculo señala el sistema y los rectángulos indican las enti-dades con las cuales se relaciona. Los flujos de información se muestran con

51 Una experiencia interesante ha sido que el diseño estructurado no obliga a tener programa-ción estructurada, así como la orientación a objetos no obliga a emplear programación orien-tada al objeto.

Clientes

Proveedores

Gerencia

Sala de ventas

Pedidos y devoluciones

Artículos y factura

Artículos y guía

Orden de compra ydevoluciones

Peticiones

Despacho de artículos

Niveles

Costos

Control de stock


líneas rectas continuas terminadas con una cabeza de flecha, la que señala la dirección 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.

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 relación entre ambos procesos (1 y 2) se da a través de un almacena-miento o archivo.

Figura 2-9. Ejemplo de D. F. D. nivelado

Veamos algunas de las características del D. F. D. nivelado:

• No es necesario volver a indicar las entidades externas, ya que es suficiente con la línea de flujo de datos.

• Los archivos (o tablas) son conjuntos o repositorios de datos, como una guía de despacho o una factura. Vendrían a ser depósitos de datos tempora-les o permanentes; con diferente notación en cada caso, una o dos barras, respectivamente, tal como vemos en la siguiente figura:

ProcesoProcesoDatos Datos Datos

Archivo

Datos

ProcesoProcesoDatos Datos Datos

Archivo

Datos

2Despachar

1Recibir

Unidades ycosto

Unidades

Ventas, traspasos y devoluciones

Compras, traspasos y devoluciones

Artículos

2Despachar

1Recibir

Unidades ycosto

Unidades

Ventas, traspasos y devoluciones

Compras, traspasos y devoluciones

ArtículosArtículos

JUAN BRAVO C. 154

• Los procesos indican una transformación de los datos para lograr un propó-sito bien definido; por ejemplo, ingresar o despachar. Generalmente, el nombre del proceso es un verbo en modo infinitivo.

• Los datos fluyen dentro de un Flujo de Datos (F.D.), es una línea con di-rección en la cual se señala un paquete de información conocida, en un mismo instante del tiempo (si diferentes datos van en momentos distintos, sería necesario agregar otra línea).

El DFD comienza con un primer grado de abstracción, generalmente represen-tado con un dígito, como los procesos 1 y 2 de la figura 2-9. Cada proceso puede generar otros DFD en forma jerárquica, respetando la numeración co-rrespondiente según cada estrato de profundidad; por ejemplo, el proceso re-cibir de la figura 2-9 incluiría tres subprocesos en el siguiente nivel: 1.1 com-prar, 1.2 recibir devolución, 1.3 recibir traspaso. Si fuera necesario un mayor nivel de detalle, el próximo nivel tendría la numeración: 1.1.1, 1.1.2, 1.1.3, ..... y así sucesivamente. Se les llama niveles elementales a los últimos niveles de descomposición.

Cada proceso tiene asociado un diccionario de datos (DD) y una mini especi-ficación en pseudolenguaje.

Diccionario de datos

El diccionario de datos es el apoyo detallado de los DFD, incluye:

• Descripción y componentes del flujo de datos. • Descripción de repositorios de datos. • Descripción de las primitivas funcionales (ver mini especificación). • Cualquier otra definición; por ejemplo: frecuencia de un proceso, tamaño

de repositorios de datos, prioridades y tipo de procesamiento, periodicidad, características y estructura de datos.

Mini especificación

La mini especificación consiste en detallar lo más fielmente posible la funcio-nalidad del proceso. Para esto se usa pseudolenguaje, el cual es equivalente a español estructurado. Veamos algunas de sus características:

Archivo

Archivo

= Archivo temporal

= Archivo permanente

Archivo

Archivo

= Archivo temporal

= Archivo permanente


• Se ocupan palabras clave: si, entonces, sino, mientras, repetir, fin. También se emplean verbos, tal como: incrementar, buscar, extraer.

• Permite reemplazar los diagramas de flujo. • Puede ser utilizada a cualquier nivel de abstracción, o nivel del proceso en

el D.F.D. • Se construye el flujo de control del proceso, usando el estilo jerárquico

hacia abajo, o top down. Significa que cada frase puede ser expandida en un pseudocódigo más detallado, en un nivel inferior.

Cuando se enseña sobre pseudolenguaje, generalmente se le compara con una receta de cocina, como muestra de simplicidad y secuencia. Sin embargo, la práctica demuestra que esa comparación es un mito, porque el grado de flexi-bilidad que posee la receta es absolutamente distinto de la rigidez y cuidadosa estructuración del pseudocódigo. Cualquiera de nosotros puede seguir una receta sin mucha rigurosidad y lograr un objetivo más o menos aceptable; ¿se imagina si hiciéramos lo mismo con un programa de computador? Los resul-tados serían aleatorios y el desastre seguro.

Una supuesta ventaja del diseño estructurado es la presentación gráfica a través de los DFD’s, “como el diseño de una casa” se ha dicho. Sin embargo, esos diagramas, más el diccionario de datos y la mini especificación, han re-sultado “duros” para el usuario típico y han desalentado la participación.

No obstante las limitaciones indicadas, el diseño estructurado fue hasta los años 80 prácticamente 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 descomposición funcional que provee, la autodocumentación y la facilidad para efectuar cambios en el mode-lo han sido vitales para su adopción generalizada en el ambiente profesional.

Incluso, durante los noventa se presentaron nuevas versiones refinadas, como el Análisis y diseño estructurado mejorado que Edward Yourdon presentara en 1994.

4. Programación extrema (XP) La programación extrema es más conocida por su sigla en inglés, XP (Extre-me Programming) y es también llamada metodología ágil de desarrollo de software. Se puede aplicar con variados métodos.

La programación extrema es más bien un concepto que lleva al extremo las mejores prácticas del desarrollo. El método GSP (capítulo 1) la contempla a través del énfasis en los pocos críticos de Pareto y en el desarrollo en espiral.

JUAN BRAVO C. 156

Explican Kendall y Kendall (2005, p. 68): “Las cuatro variables que un des-arrollador de sistemas puede controlar son el tiempo, el costo, la calidad y el alcance. Cuando estas cuatro variables de control se incluyen de manera apro-piada en la planificación, 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 diseñar. Por supuesto, la co-dificación es esencial en cualquier proyecto de software. Las pruebas de fun-cionalidad, desempeño y conformidad son obligatorias. La actividad de escu-char al cliente y otros programadores y analistas es fundamental”.

En el fondo, programación 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 tentación de considerarla una panacea (o bala de plata) veamos lo que dice Steve McConnell (1997, pp. 4-5): “Si trabaja en una orga-nización normal y sigue los métodos descritos en este libro. Podrá reducir significativamente su tiempo de desarrollo, puede que hasta la mitad, e incre-mentar también su productividad. Además, podrá hacerlo sin alterar la cali-dad, el coste, el rendimiento o la facilidad de mantenimiento. Sin embargo, la mejora no será instantánea, no la obtendrá a partir de una única y nueva herramienta o método, y no la alcanzará cogiendo simplemente el paquete de la estantería. Requerirá tiempo y esfuerzo. Hubiera deseado tener una solución sencilla para el problema de la velocidad del desarrollo. También me gustaría tener cinco millones de dólares. Pero las soluciones simples tienden a funcio-nar sólo con problemas sencillos, y el desarrollo de software no lo es. El desa-rrollo rápido de software es aún menos simple”.

McConnell también se refiere a que hay variados modelos para el desarrollo rápido y que esto depende del tipo de proyectos (1997, p. 122): “Diferentes proyectos tienen diferentes necesidades de desarrollo rápido, aunque todos necesiten ser desarrollados tan rápido como sea posible”.

En fin, hay consenso en que la receta es trabajar duro y con método.


2.6. APOYO DEL DISEÑO EN LA EXPLOTACIÓN DEL

SISTEMA

El objetivo de esta sección es analizar la potencialidad de la etapa de diseño para asegurar el buen funcionamiento del sistema durante su vida útil.

Es sabido que tomando algunas precauciones en la etapa de diseño de la aplica-ción que luego se implementen, la explotación mejora en mucho. A diferencia de cuando se pretende incorporar ayudas para la operación y auditoría del siste-ma durante la construcción o en la misma explotación. En este caso el costo aumenta al menos en un orden de magnitud y el modelo pierde elegancia.

El criterio con que abordaremos esta sección es máxima participación del usuario en el diseño y mínimo esfuerzo durante la operación del sistema.

Para obtener una aplicación amistosa, es deseable ejecutar cada proceso de la forma más automática posible, evitándose el ingreso de parámetros, fechas u opciones de menú.

Veremos: 1. Operación del sistema 2. Auditoría computacional 3. Contribución del diseño a la protección de la información 4. Seguridad de la información 5. Integridad de la información 6. Recuperación de la información

1. Operación del sistema Entendemos la operación como el conjunto de tareas que permiten el buen funcionamiento de la aplicación, realizadas por especialistas y usuarios. Es importante este cambio de concepto, porque ya quedó atrás la época cuando la operación del sistema sólo estaba ligada a la participación de un operador computacional. En sistemas mayores hoy es una labor de conjunto y en siste-mas pequeños los usuarios pueden realizar todas las labores.

El diseñador del sistema debería conocer algunas tareas técnicas propias de la operación, como las siguientes:

• Mantención de una bitácora de procesos: incluso en los sistemas de tiempo real hay procesos batch que es indispensable programar según una bitácora de

JUAN BRAVO C. 158

procesos, para equilibrar la carga del computador, cumplir con entregas de ti-po periódico y por seguridad.

• Control de funcionamiento correcto: para asegurar el buen funcionamiento de un sistema en cada ejecución (o en puntos intermedios dentro de la misma) debería verificarse que los totales de control sean coincidentes entre las dife-rentes partes del proceso (por ejemplo, número de registros leídos igual a la cantidad de artículos impresos) y que estén de acuerdo con promedios históri-cos. La mayoría de las verificaciones de este tipo podrían haber sido conside-radas en el diseño e informadas en forma automática al presentarse diferencias (o un simple “término normal” si todo está bien).

• Uso de recursos: una importante tarea que también podría estar parcialmen-te incorporada en el diseño, es buscar permanentemente minimizar el uso de recursos. Esto significa:

• Estudiar el tamaño 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 podrían disminuir el rendimiento.

• Estudiar las secuencias de control para evitar duplicidades en proce-sos u ordenamientos.

• Organizar el uso de la impresora para economizar papel, obtener los informes en el mínimo de tiempo, etc…

• Evitar la impresión automática 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 diseño ni romper la uni-formidad, son parte del conjunto de normas del área de informática.

• Reconstrucción de bases de datos: dependiendo del sistema operativo del computador, en algunos casos será necesario reconstruir periódicamente la ba-se de datos, con el fin de reorganizar las claves y recuperar el espacio ocupado por registros eliminados.

• ¿Qué pasa si?... significa preguntarse cómo apoyar la operación, cuando, por ejemplo, se corte la luz, se saturen las líneas o una tabla se dañe. Una causa de las serias dificultades en que caen algunos sistemas es porque no se hicieron estas preguntas a nivel del diseño.

Desde el punto de vista del método presentado en el capítulo 1, más allá de los planes de contingencia, el concepto es la continuidad operacional.


2. Auditoría computacional Dado el carácter contralor de la auditoría, ésta tiene tuición sobre todas las áreas de la empresa. Una de ellas es el área computacional, donde, debido a su alto grado de especialización, fue necesario crear una nueva rama: la auditoría com-putacional.

En un esquema de organización centralizada, la auditoría computacional con-trola toda la gestión del centro de computación, incluyendo la parte administra-tiva de los sistemas de información que de allí se generan y más en particular, se encarga del control sobre la protección de información.

En un esquema de organización descentralizada, adicionalmente la auditoría 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 propósito, las principales áreas usuarias debieran tener la libertad de des-arrollar en forma interna o externa, respetando la normalización y uniformidad que se haya dado la organización y lo más importante, ocupando su propio presupuesto.

Además del logro de la normalización, una administración eficiente también significa resolver el problema de la adaptación al cambio. Esto implica dejar espacios para la innovación y para probar otros esquemas, sin que resulte crítico para la instalación. Es más, todos los interesados de la empresa deber-ían aprender y beneficiarse con las pruebas, lo cual se podría conseguir con una apropiada difusión de los resultados. En esos “espacios de libertad” la auditoría computacional tendrá que ser muy flexible para no ahogar la creati-vidad.

Para cumplir con su labor contralora, el auditor computacional debe ubicarse fuera del departamento de sistemas, normalmente en un departamento de audi-toría computacional, a cuya jefatura debe hacer llegar los informes de sus audi-torías, generados en forma independiente de cualquier otro emitido por el área de computación.

Generalmente el departamento de auditoría computacional es parte de contra-loría o auditoría interna, área que su vez depende directamente del directorio de la compañía.

En general, las áreas de control de la organización debieran ser pequeñas, por-que el énfasis debiera ser puesto en el desarrollo de las personas, en autonom-ía, colaboración y relaciones basadas en confianza.

JUAN BRAVO C. 160

La necesidad de la auditoría computacional es particularmente evidente en insta-laciones con sistemas de tiempo real, donde ha desaparecido en gran parte el respaldo manual de los movimientos. Esto es particularmente crítico cuando la mayor parte de las operaciones son transacciones de carácter legal que generan movimientos de dinero, como es el caso de las instituciones financieras.

Los sistemas de tiempo real provocan dificultades insalvables para la auditoría tradicional en el seguimiento de las operaciones. Debido a esto, el centro de computación debe asumir su propio control interno, inconsistencia evidente desde donde surge la necesidad de entrenar a los auditores en materias computa-cionales y crear departamentos de auditoría computacional, los cuales agrupan a un conjunto de profesionales de tipo multidisciplinario, porque deben ser espe-cialistas en computación y en auditoría interna.

Pero también la auditoría ha salido beneficiada con el advenimiento de la com-putación. Hoy, con múltiples programas de apoyo, se pueden efectuar minucio-sas revisiones, como la tarea de verificar la totalidad de la información disponi-ble en el computador respecto de un problema, la cual sería prácticamente im-posible de realizar manualmente.

Como ya fue indicado, las posibilidades de la auditoría computacional son muy amplias y los controles alcanzan, entre otros, a los siguientes aspectos:

• Organización del departamento de sistemas. • Contratación de personas y evaluación de funciones, principalmente en lo

que se refiere a funciones incompatibles; por ejemplo: en ciertas organiza-ciones y para determinados tipos de sistemas un operador no debería ser programador al mismo tiempo.

• Administración de los profesionales de informática. • Evaluación de necesidades y selección de equipos. • Formación de grupos de trabajo, como el comité de informática. • Plan general de informática. • Plan de recuperación de desastres. • Seguridad de las instalaciones. • Protección de la información. • Método de desarrollo de sistemas y controles incorporados. • Entrega de los productos pactados en cada etapa del desarrollo • Implementación de sistemas. • Instalaciones físicas. • Presupuesto de protección. • Presupuesto del departamento de sistemas.


• Lugar de funcionamiento del departamento de sistemas. • Rendimiento (evaluación 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 estándares, mediciones y estimaciones internas, como la cuantificación de riesgos para determinar el costo de cada po-sible amenaza. Por ejemplo, si todo lo expuesto en los capítulos de este libro fuera aceptado como la metodología de trabajo para un departamento de siste-mas, entonces, una de las labores de la auditoría computacional sería aplicar controles para verificar el correcto cumplimiento de las normas aquí definidas. Tal como en las auditorías de las normas ISO o CMM, donde se evalúa el cum-plimiento de lo que está detallado en los respectivos procedimientos.

Puede parecer burocrático mantener normas para todo tipo de aspectos que tienen que ver con el desarrollo y la operación de sistemas. Es aparente, como lo demuestran los siguientes argumentos:

• Tanto Japón como Alemania mantienen típicamente esquemas muy nor-malizados en sus instalaciones y... son los países más estudiados a nivel mundial por su habilidad en la creación de riqueza.

• Esta documentación y normalización sobre la forma de hacer las cosas se está transformando cada vez más en una exigencia. Las empresas que de-sean optar a la certificación en las normas ISO 9000 o CMM deben some-terse a normas más rigurosas que las que hemos visto aquí.

• En el ámbito de la calidad total, la cual es cada vez más importante dentro de la estrategia competitiva, es absolutamente exigible esta normalización.

Es deseable que el rol del auditor sea de tipo creativo más que punitivo, ayudan-do a dar más riqueza al método. En este sentido, puede cooperar realizando una labor educativa de los colaboradores y de mejora continua de las normas.

Una opción es que en todo grupo de desarrollo participe un auditor computacio-nal, aunque manteniendo su independencia para conocer la aplicación y avanzar con la verificación de controles al mismo tiempo que se desarrolla el sistema. De esta manera, sus observaciones podrán ser consideradas para su incorpora-ción a nivel del diseño de la aplicación. Cuando las sugerencias se realizan so-bre un sistema en explotación, el incorporarlas tiene un costo mucho mayor.

JUAN BRAVO C. 162

3. Contribución del diseño a la protección de la información Con el advenimiento masivo de la computación y el notable aumento del núme-ro de terminales y PC’s en poder de usuarios, la labor de protección se ha veni-do haciendo progresivamente más importante.

Hoy es indispensable incorporar las condiciones de seguridad que exige el medio. Comencemos por conocer los siguientes términos:

• Seguridad: es un concepto amplio que abarca desde la seguridad física de la instalación hasta la protección de los datos contra accesos no autoriza-dos, alteración, hurto o destrucción de la información.

• Privacidad: se considera un aspecto particular de la seguridad en lo que se refiere a la protección 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 información almacenada, la que debe ser siempre consistente y estar protegida de inva-lidaciones accidentales o deliberadas.

• Recuperación: es el conjunto de tareas destinadas a poner nuevamente en marcha el sistema una vez que éste se ha “caído”, ya sea a raíz de fallas o errores, tales como un problema eléctrico 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 “caída” del sistema.

• Restablecimiento: son las operaciones realizadas después de una “caída” del sistema, previo a la reanudación del procesamiento normal (determinar la transacción en proceso, conocer el “estado” de los registros de maestros, traer respaldos o reordenar bases de datos).

• Reiniciación: corresponde a la culminación del restablecimiento, cuando se pone nuevamente en marcha el sistema después de una “caída”. Para reini-ciar el procesamiento se ejecutan programas especiales o los programas originales si tienen mecanismos de recuperación.

Para proteger la información debe hacerse un estudio preciso de todos los posi-bles riesgos, cuantificar cada uno de ellos y estimar la probabilidad de ocurren-cia en un cierto período. Así, se obtendrá cuál es el costo aproximado de cada riesgo, lo que permitirá establecer un presupuesto para el plan de protección.

La protección de información abarca la seguridad, integridad y recuperación de los sistemas, temas inseparables de la labor de diseño.


4. Seguridad de la información El concepto de seguridad incluye variados tópicos:

• Instalaciones físicas: control de acceso de las personas o riesgo de incen-dios, a modo de ejemplo.

• Procedimientos administrativos: fugas por errores en el diseño lógico, do-cumentos faltantes, descuadraturas, etc.

• Privacidad de la información: consultar o alterar información privada.

La seguridad de la información en el computador se puede perder en forma ac-cidental o deliberada. Las causas más comunes de destrucción accidental de la información corresponden a fallas en el hardware, fenómenos externos como un corte de energía eléctrica o errores en la estructuración de lógica. Los dos prime-ros problemas pueden ser enfrentados con el apoyo de los proveedores y el ter-cero con la ayuda de herramientas de productividad y mucho, mucho orden.

Respecto de los intentos de infiltración deliberada, la principal forma de evitar-los es mediante mecanismos de identificación, autentificación y de control de acceso, como los que se describen a continuación:

• Mecanismos de identificación y autentificación: la idea es que cualquier usuario que intente entrar al sistema debe identificarse y eventualmente dar su ubicación (por ejemplo, número del terminal). Sólo entonces se procede a autentificar su identificación, lo cual significa demostrar que el usuario es quien dice ser. Para esta identificación existen, por ejemplo, máquinas lecto-ras de tarjetas preimpresas que ayudan a resolver el problema. El proceso de autentificación 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ó autorización al ejecutivo de cuentas corrientes para el pago de un cheque de alto valor. La primera vez quedó en espera y al se-gundo intento el ejecutivo dijo sí a un cheque robado y con orden de no pa-go. La investigación subsiguiente demostró que la autorización no la dio él, sino otro funcionario infiltrado en el sistema, quien conocía la clave del ejecutivo.

• Mecanismos de control de acceso a la información: en este caso los dere-chos de los usuarios deben quedar explícitamente establecidos, toda vez que existan datos reservados. Los mecanismos de mayor uso son:

JUAN BRAVO C. 164

• Matriz de control de acceso: usuario vs. conjuntos de datos, donde cada elemento especifica el nivel de acceso (lectura, grabación o mo-dificación).

• Cerrojos: cada conjunto de datos posee una clave de acceso. • Criptografía: consiste en una serie de operaciones reversibles que

cambian el contenido de un registro, como la sustitución, donde se reemplazan los caracteres por otros; y la transposición, donde se alte-ra el orden de los caracteres.

Lo ideal para la seguridad de un sistema es que sus mecanismos estén bajo la supervisión de un monitor que registre todas las posibles violaciones.

Hoy, la mayoría de los sistemas administradores de bases de datos traen in-corporados estos y otros mecanismos.

5. Integridad de la información El problema de integridad es asegurarse que los datos de las tablas en el com-putador sean exactos en todo momento, es decir, protegerlos contra invalida-ciones accidentales o deliberadas.

Para hacer más comprensible esta descripción, es necesario definir los términos fallas, errores y “caídas del sistema”.

• Fallas: se presentan por un mal funcionamiento en el hardware o en el software o por una mala operación de las personas. Una falla podría gene-rar errores.

• Errores: son registros de datos o partes de programas, almacenados o transmitidos en forma incorrecta. También es un error la pérdida de información.

• Caída del sistema: es una detención inesperada de la normal operación del sistema o la ejecución de operaciones incorrectas en el computador. Tanto una falla como un error podrían provocar esta “caída”.

Algunas medidas que se podrían tomar para asegurar la integridad de los datos en las bases de datos son:

• Prevenir el ingreso de errores a través de exhaustivas validaciones; por ejemplo, de rango de valores, tipo de datos, dígito verificador y compara-ción entre campos.

• Verificaciones de consistencia a través de “revalidar” la información en maestros.

• Verificación de claves.


• Verificación de reiniciación.

El conjunto de medidas de prevención de integridad tiene que establecerse a nivel del diseño y de acuerdo con la naturaleza de los datos a proteger, sin olvi-dar que este tema es inseparable de los conceptos de seguridad, recuperación y de las facilidades de las herramientas de apoyo.

6. Recuperación de la información La recuperación de la información está muy influida por el diseño del sistema. Podría existir recuperación automática en cada función computacional, aunque esta posibilidad se encuentra directamente relacionada con el sistema de res-paldos utilizado.

La alternativa más habitual de recuperación de información es la reconstruc-ción total, la que se utiliza cuando las tablas maestras deben ser totalmente reconstruidas. Esta forma de reconstrucción opera trayendo el respaldo de las bases de datos más recientes y actualizando sobre ellas los movimientos no incorporados a la fecha.

Para realizar la reconstrucción, el sistema de respaldos consiste en copiar y ar-chivar fuera del equipo toda la información del sistema en forma periódica, 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 práctico, es la fórmula más sencilla y simple de operar.

Es aconsejable mantener un mínimo de 3 juegos de respaldos completos (Abue-lo-Padre-Hijo) y uno de ellos fuera de la instalación, para prevenir riesgos de incendio, inundación u otros. Los respaldos de transacciones diarias debieran mantenerse, al menos, desde la misma fecha del respaldo completo más antiguo.

La reconstrucción total es válida no sólo para sistemas batch, sino también para sistemas en línea, donde se debería tener preparado un programa actualizador, tipo batch, para incorporar a los maestros las transacciones realizadas desde la fecha del último respaldo.

Algunas técnicas de respaldo más 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 revisión diaria automática, previa al funcionamiento normal.

Todo esto sin contar las facilidades que hoy proveen los sistemas administra-dores de bases de datos y la externalización del servicio.

JUAN BRAVO C. 166

2.7. DISEÑO DE INTERFACES

Actualmente, la mayor parte del esfuerzo de desarrollo se concentra en la in-terfaz humana de la solución de software. Se refiere a definir interfaces intui-tivas con íconos, ayudas en línea, 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 diseño de la interfaz.

Debe ser una placentera experiencia de navegación.

Es lo que plantean Cerda y Guzmán (2004, p. 1): “Si bien la Ingeniería de Software ha mejorado la calidad y confiabilidad del software, existe un área que ha sido descuidada hasta el momento: el diseño y construcción de la in-terfaz del usuario. Gran cantidad del esfuerzo en el desarrollo del software está invertido en el diseño, en la construcción de la base de datos y en el códi-go necesario para manipularla, además 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 difícil de utilizar, no importará toda la calidad que posea el resto del software, el usuario se frustrará y se sentirá incómodo cuando tenga que interactuar con el programa. A pesar de esto, se dedica poco esfuerzo a crear un diseño de calidad de dicha interfaz que tome en cuenta las características particulares tanto del usuario como del entorno en que se utili-zará el software.

Veremos: 1. Directrices para el diseño de interfaces humanas 2. Diseño de niveles de menús 3. Leyes para lograr una mejor interfaz humana

1. Directrices para el diseño de interfaces humanas Hemos visto que las mejores experiencias de diseño de interfaces sigue más o menos estas directrices:

• Diseñar los formatos de pantallas, informes y menús: es de importante ayuda trabajar con un prototipo de las interfaces visuales, el cual podría ser desarrollado en paralelo con las fases anteriores de la orientación a objetos.

• Preparar el esquema de pantallas según normas: como las del ambiente windows de MICROSOFT u otro. De esta manera, todos los participantes co-nocerán el mismo entorno y la organización habrá dado un paso más hacia la normalización externa.


• Diseñar las interfaces según el tipo de usuario: empleados o ejecutivos, principiantes o expertos, baja o alta especialización. “La idea es simple” asegura Gerardo Cerda (2002, p. 2): “El usuario quiere utilizar un software que sea lo más simple posible. No le interesa entender el por qué del fun-cionamiento si no solamente cómo lo debe utilizar para sacarle provecho. Sin embargo, si el diseño de la interfaz no es el adecuado se estará obligan-do al usuario a aprender a utilizar complejos instrumentos para sacar pro-vecho al software (imagínese que se obligara a los pasajeros de un vuelo a tener conocimientos aeronáuticos para poder abordar un avión)”.

• Diseñar la jerarquía de opciones: significa realizar el ordenamiento de opciones según la normalización; por ejemplo: incorporar primero las op-ciones de uso más frecuente ordenadas según la secuencia de ejecución de tareas, agruparlas de 3 en 3 y con una profundidad de no más de tres nive-les en la jerarquía de opciones.

• Ayudas en línea eficientes: de tal forma que, ojalá, no sea necesaria la existencia de los manuales. Estamos a fines de la primera década del 2000, en un ambiente donde la tecnología computacional está ya totalmente consolidada, ¿será necesario mantener todavía los manuales? ¿Usted realmente los usa? ¿Están actuali-zados? A estas alturas sería preferible que los usuarios aprendieran a nave-gar dentro de buenas ayudas en línea52.

• Ordenamiento de procesos: corresponde a la definición previa de secuen-cias de procesos, generalmente agrupados bajo una opción de menú.

2. Diseño de niveles de menús La definición de diferentes niveles de menús es un importante componente de la interfaz humana. Una primera aproximación podría ser considerar cada menú como una clase que representa a todo el diseño, tal como se aprecia en la figura 2-10. En este caso, los conjuntos de datos serían accesos a los dife-rentes objetos y las funciones generalizadas permitirían acceder a las consul-tas, informes y diferentes procesos del sistema.

52 Si todavía 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.

JUAN BRAVO C. 168

Figura 2-10. Definición de menús como una clase

Cada clase tendría también objetos menús, denominados agentes, los cual aportarían “inteligencia”, por ejemplo, para presentar una ruta de acceso ex-pedita cuando hay un requerimiento frecuente.

Una promesa que puede ayudar más adelante serán las pantallas con visión tridimensional, lápices con microprocesador que reemplazarían al teclado, uso masivo de la voz e interfaces inteligentes que pueden anticiparse a algunos requerimientos del usuario, tal como avisar las actividades del día. 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 artículo ya citado de Cerda y Guzmán (2004, pp. 3-9). Para darle énfasis, los autores presentan sus recomendaciones en la for-ma de “leyes”.

• Ley 1: Mantener sencillo lo sencillo: la idea es que lo que es fácil 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 equivocarán (aún los más expertos). Por este motivo los mensajes del software deben ser lo más claros posibles (evitan-do la costumbre de poner la palabra ERROR).

• Ley 3: Mantener un estilo definido: cuando un software ha sido hecho por distintas personas el usuario se da fácilmente cuenta. Para la misma situa-ción aparecen mensajes diferentes o a la inversa, para situaciones distintas se utiliza el mismo mensaje. En este sentido resulta muy importante man-tener un estilo gráfico consistente.

• Ley 4: El mínimo esfuerzo: el usuario de la interfaz solo debe digitar el mínimo 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

Conjuntosde datos

Funciones generalizadas

Menú

Conjuntosde datos

Funciones generalizadas

Menú


necesario la cambia por otra digitándola. �La opción de impresión debiera tener en forma predefinida el papel y la calidad de impresión que se utili-zan más frecuentemente.

• Ley 5: Unificación de mensajes y textos: antes de empezar a construir el programa se debe lograr un consenso respecto a los títulos de las ventanas, los captions de los botones, las ayudas (hints) y como resaltar las opciones que están activas (por ejemplo mostrar claramente cuál es la “pestaña” que se está usando). Con respecto a los mensajes, botones y títulos de las ven-tanas, lo ideal es que se usen tecnicismos acorde con el ambiente en el cual se va a insertar el sistema, en lo posible términos relacionados con el rubro de la organización.

• Ley 6: Tener un rol de “Diseñador de interfaz”: cuando todo el mundo es responsable de la calidad de la interfaz en realidad nadie toma esta respon-sabilidad. Es demasiado fácil asumir que otra persona en el equipo de desa-rrollo solucionará cualquier dificultad de interfaz que surja. Además es im-portante recordar de que los programadores van a tender siempre a codifi-car una interfaz que a ellos les sea más cómoda o más fácil 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 más pero tampoco nada menos. El ideal es que se brinde toda la funcionalidad “a un click de dis-tancia”. A fin de cuentas es entregarle al usuario la cantidad justa de pasos a seguir para sacar provecho de la interfaz, generando así un mínimo por-centaje de error y un alto porcentaje de rendimiento y satisfacción. Ahora bien, este término es más conocido como “Look and Feel”, concepto orien-tado a la programación de los entornos gráficos, tales como JAVA.

• Ley 8: Personalización, 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 más en en-tregar lo que el usuario desea, esto es: trabajar en un entorno grato y cono-cido. Entonces, ¿qué mejor si es el usuario quien define como verá sus aplicaciones? Obviamente no podrá tener acceso a las partes preestableci-das o inalterables.

• Ley 9: Usabilidad, que cumpla con la “Intuitividad”: usabilidad es una mezcla entre intuición y facilidad, que permite al producto o servicio im-pactar e influenciar directamente sobre la productividad, rentabilidad y efi-ciencia de un negocio, on y off line, y con ello, la experiencia de usuario en general.

JUAN BRAVO C. 170

2.8. NORMAS Y ESTÁNDARES APLICADOS A LOS

MODELOS TI

El objetivo de esta sección es revisar las normas o estándares formales o de hecho útiles al diseño de los sistemas computacionales,

Veremos propuestas de la OMG tales como Corba, API’s y MDA. Más que nada para presentarlas y apreciar estudios que es necesario realizar.

Revisaremos también algunas normas de calidad desde las cuales aprender buenas prácticas. Se revisarán brevemente las normas CMM, ISO 9000 y Tick IT (como ejemplo, muchas compañías de éxito en la India53 se han adherido a una o más de estas normas).

Un aspecto común a las normas y estándares es el costo: del aprendizaje, de la certificación a veces, de la infraestructura, de la implementación y muchos otros. También es común el beneficio:

• Que el proyecto se sitúe dentro de los plazos y costos previstos • Que el desarrollo sea de calidad • Que se pueda rastrear • Que se pueda hacer una auditoría de su cumplimiento • Que el desarrollo sea eficiente y eficaz

Agregamos también referencias respecto al PMI por la difusión que han tenido sus prácticas.

Veremos: 1. Corba 2. MDA 3. CMM 4. ISO 9000 5. Tick IT 6. ITIL 7. SOA

53 En OECD (2000, p. 140) se aprecia el impacto de tecnologías como CMM en la India, donde hasta 1998 se habían certificado 89 de las 250 compañías “top” en la producción de software , otras 136 estaban en proceso de certificarse y sólo 25 compañías, el 10%, no tenía planes al respecto. Luego (ibid, p. 139) se precisa que la certificación es según normas reconocidas inter-nacionalmente, tales como: CMM del SEI, ISO 9000 y/o Tick IT.


1. Corba CORBA (Common Object Request Broker Architecture, en español, arquitec-tura común de intermediarios en requerimientos a objetos), es un estándar basado en la orientación 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 aplicación en un componente que conoce las funcio-nes que puede utilizar y cómo se accede a ellas, permitiendo su uso mediante el protocolo de comunicación.

CORBA es otro producto del Object Management Group (OMG)54. Se esta-blecen las APIs55 y las comunicaciones que permitan interactuar a varias apli-caciones (consideradas como componentes, los cuales pueden haber sido construidos en plataformas distintas). También permite agregar funcionalidad para seguridad, bitácora de uso y otras.

2. MDA MDA (Model-Driven Architecture, en español, arquitectura guiada por mode-los) es una propuesta de la OMG que proporciona un conjunto de guías para crear especificaciones en la forma de modelos. En la misma línea del mode-lamiento visual del software (UML, lo veremos en el capítulo 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 más a la imple-mentación en la plataforma correspondiente. El aporte del concepto MDA es que el traspaso entre modelos conceptuales y físicos se pueda llevar a cabo utilizando herramientas automatizadas, siguiendo a su vez otros estándares de la OMG.

54 OMG, en español es el grupo de administración de objetos, comentaremos acerca de esta organización en el capítulo 5 (orientación a objetos). 55 API (del inglés Application Programming Interface, en español, Interfaz de Programación de Aplicaciones) se refiere a las clases de una biblioteca (funciones y procedimientos) según el concepto de orientación a objetos que veremos en el capítulo 5.

JUAN BRAVO C. 172

3. CMM CMM (Capabilitiy Maturity Model), traducido como “Modelo de Madurez de Capacidades”, es la norma preferida en el desarrollo de software. Tiene nive-les cada vez más exigentes que la organización candidata debe ir certificando.

CMM provee un detalle exhaustivo de cada nivel de madurez y no es difícil de interpretar. Incorpora todo un sistema de mediciones a la madurez de la organización respecto de las capacidades del desarrollo de software, lo cual facilita los procesos de evaluación.

Los niveles de madurez que señala CMM son cinco:

1. Nivel Inicial (Initial ): por omisión todas las empresas están en esta categor-ía. Aquí se describe la pseudoanarquía presente en el desarrollo. El proceso de desarrollo es prácticamente inexistente. Se trabaja “apagando incendios” con esfuerzos heroicos. Existe inmadurez en el desarrollo. No existe visibi-lidad acerca del proceso de desarrollo ni de los resultados del producto de software (tiempos, costos o errores).

2. Nivel Repetible (Repeatable): en este nivel el proceso se puede repetir, existen técnicas y normas comunes, hay seguimiento de costos, plazos y funcionalidad en los procesos.

3. Nivel Definido (Defined): el proceso de desarrollo de software está docu-mentado, estandarizado e integrado.

4. Nivel Gestionado (Managed): los procesos están bajo un nivel de control donde la predicción de plazos y costos es posible.

5. Nivel de optimización (Optimizing): se incorpora el mejoramiento continuo de los procesos.

CMM surgió en 1993 de una iniciativa del Software Engineering Institute (SEI)56, con toda una historia anterior que incluyó estudiar una amplia canti-dad de compañías de éxito en el desarrollo de software.

56 El Software Engineering Institute (SEI) es un Centro de investigación y desarrollo —financiado con fondos federales— patrocinado por el Departamento de Defensa de Esta-dos Unidos, por intermedio de la Oficina del Subsecretario de Defensa para la Adquisi-ción, Tecnología y Logística. El contrato del SEI para la investigación aplicada en el tema de la metodología de software, fue adjudicado por licitación pública a la Universi-dad Carnegie Mellon en Diciembre de 1984. La misión del SEI es: Promover y avanzar en la práctica de la Ingeniería de Software, porque el software de calidad, producido conforme a plazos y dentro de un presupuesto, es un componente crítico para los siste-mas de defensa de Estados Unidos. Cumple esta misión promoviendo la evolución de la


4. ISO 9000 ISO corresponde a la Organización Internacional de Estandarización. La serie de normas ISO 9000 son bastante conocidas. Destaca que el sector informáti-co fue uno de los más reacios en adherirse a ellas.

Un punto de encuentro se está produciendo con la masiva incorporación de la gestión de procesos al desarrollo de software. Esta es una ventaja de la aplica-ción de las normas, su amplitud.

Incluso la gestión de procesos fue considerada en la nueva redacción de nor-mas ISO, en las denominadas normas ISO 9001:2000. De hecho, la principal diferencia con las normas de la versión 1994 es la introducción del concepto de gestión por procesos interrelacionados. En estas nuevas normas la gestión de calidad tiene un enfoque más integral y sistémico y se incorpora la mejora continua. Dice la nueva Norma ISO 9001:2000 (p. vi): “Para que una organi-zación 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 aplicación de un sistema de procesos dentro de la organización, junto con la identificación e interacciones de estos procesos, así como su gestión, puede denominarse como «enfoque basado en procesos»”.

5. Tick IT Surgió en Gran Bretaña por las carencias que se detectaron en las normas ISO 9000 orientadas a la industria del software, tales como difícil interpretación y aplicación, inexistencia de aspectos críticos 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.

Típicamente, un sistema de calidad Tick IT sigue pautas como las enumeradas a continuación (las cuales serían sujetos de revisión en una auditoría):

1. Elaboración de propuestas y revisión de contratos asegurando que todos los requerimientos estén bien especificados y que la organización tiene la capacidad para cumplirlos.

Ingeniería de Software desde ser una actividad “ad-hoc” de alto contenido de trabajo de personas hacia ser una disciplina bien gestionada y apoyada por tecnología.

JUAN BRAVO C. 174

2. Análisis y especificación de los requerimientos del sistema asegurando que sean revisados y acordados con el cliente.

3. Planeación, control y monitoreo del avance del desarrollo respecto al plan comunicando a todas las partes afectadas y que avise oportunamente de problemas potenciales.

4. Planeación de la calidad del proyecto, especificando las inspecciones, revisiones y pruebas requeridas durante el desarrollo.

5. Establecer políticas y objetivos de calidad generales de la organización que sirvan para alinearla en todas sus actividades, procedimientos y polí-ticas específicas.

6. Implantar y mantener un sistema de aseguramiento de calidad.

6. ITIL ITIL (Information Technology Infrastructure Library) se traduce como “Bi-blioteca de Infraestructura de Tecnologías de Información”. Una traducción 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 prácticas.

Todo surge de los bajos estándares de servicios TI en el Reino Unido (simila-res a los de otras latitudes), principalmente los que se refieren a los servicios a usuarios durante la etapa de operación (más del 80% del total). Así es que se encargó al CCTA (Central Comunications and Telecom Agency) una propues-ta. La respuesta fue ITIL, la cual poco a poco ha ido ganando terreno como referente en el campo de los servicios TI.

El objetivo es la mejora en la atención de los clientes y usuarios y la reducción de costos y riesgos.

ITIL documenta buenas prácticas para lo que denomina los 6 componentes del Soporte del Servicio:

• Gestión de Configuración • Mesa de Servicios • Gestión de Incidencias • Gestión de Problemas • Gestión de Cambios • Gestión de Difusión

Tiene cierto parecido con CMM en los niveles de madurez respecto a la cali-dad de los servicios TI: existencia de pre-requisitos mínimos, intento de ges-tión, capacidad de proceso, integración interna, productos, control de calidad, información de gestión, integración interna e interfaz.


Son propuestas de amplio sentido común, tal como la de administrar una base de datos de elementos de configuración: software, hardware y documentación, incluyendo su estado y relaciones, base a su vez del análisis de incidencias y problemas.

7. SOA SOA (Service Oriented Architecture, en español, arquitectura orientada a los servicios) es más un concepto que una herramienta porque su objetivo princi-pal es aprovechar las funcionalidades de aplicaciones computacionales anti-guas sin necesidad de intervenirlas. Se logra “empaquetándolas” y relacionán-dose con ellas en términos de entradas y salidas, tal como en la orientación a objetos.

Es una mirada amplia desde los procesos de negocios que facilitan esas apli-caciones. Al conocer y dejar disponibles los servicios que otorgan, es posible aprovecharlos en el diseño de nuevos procesos de negocios, principalmente en el mundo virtual (webservices).

Está de lleno en dos aspectos esenciales de los nuevos modelos: la integración y la modularidad en la forma de componentes.

La aplicación de SOA permite “recuperar” para su uso global sistemas creados con cualquier lenguaje y tecnología, 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 capítulo 5, orientación a objetos). Además, se facilita el intercambio de información y se hace más factible la externalización.

Al evitar construir de nuevo los servicios, se economiza tiempo y dinero. So-bre todo, se reducen errores al evitar reinventar innecesariamente la rueda.

Al igual que la orientación a objetos, es posible aplicar SOA mediante cual-quier tecnología basada en servicios. También se enfatiza la reusabilidad y que los equipos de trabajo se mentalicen en esta línea de compartir.

Por supuesto, requiere las mismas formalidades que el desarrollo tradicional en cuanto a planificación, calidad y uso de método.

JUAN BRAVO C. 176


APLICADA


Capítulo 3. Teoría de modelos aplicada

Sin importar el tipo de empresa, el analista trabaja en problemas comerciales. Sería un error distinguir entre problemas del nego-cio en sí y de sistemas; o dicho de otra forma, no existen proble-

mas de sistemas que no hayan sido primero del negocio.

Senn (1987, p. 56)

La nueva teoría de modelos aporta avances vitales que deben ser conocidos para enriquecer la creación de modelos de una solución de software.

Esta es la tercera competencia considerada para apoyar la elaboración de modelos de una solución de software, tal como se aprecia en la siguiente fi-gura (en la introducción se incluyó la visión global de las competencias). En este caso, el analista debe conocer acerca de la teoría de modelos como una simple responsabilidad profesional que deriva de su misión de modelador de una realidad deseada.

Los aportes de visión sistémica y de la gestión de procesos, en particular el criterio del curso normal de los eventos, son claves en esta misión.

Veremos: • Marco teórico 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






CAPÍTULO 6. UML



JUAN BRAVO C. 178

3.1. MARCO TEÓRICO DE LOS MODELOS

Se presenta este breve análisis sobre teoría de los modelos, utilizando dos conceptos tomados de la teoría de sistemas: caja negra y homomorfismo. Con ellos se pretende obtener un mínimo 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 difíciles de conocer y con un comportamiento solamente predecible en términos probabilistas.

La forma de abordar estos sistemas es observando sus entradas y salidas, para determinar qué estímulos en las variables de entrada producen cambios en las variables de salida, tal como se muestra en la figura 3-1. Así se puede cons-truir un modelo del sistema que entregue respuestas lo más aproximadas a la realidad. Por ejemplo, no conocemos el comportamiento de la economía, pero hemos observado que un aumento en la tasa de interés produce menor activi-dad en la economía o que un tipo de cambio alto incentiva las exportaciones. Con éstos y otros antecedentes podríamos formar un modelo matemático que nos ayude en la toma de decisiones con estimaciones probabilistas sobre los efectos de decisiones importantes.

Figura 3-1. Concepto de caja negra

También un sistema de información puede abordarse según el concepto de caja negra. Comenzando por el entorno, entradas y salidas, se avanza hacia conocer la información que utiliza, hasta identificar los procedimientos y re-glas de negocio.

CajaNegra

Variables de entrada

Variables de salida


2. Concepto de homomorfismo Un homomorfismo es una representación simplificada del objeto real. Un mo-delo de sistemas es una de las visiones que tienen diferentes personas respecto a un mismo objeto. También corresponde a los diferentes “puntos de vista” con que una persona intenta reconocer ese objeto; por ejemplo, ¿cómo se pue-de superar la complejidad para estudiar un automóvil? Un mal método sería intentar reconocerlo todo de una vez, porque los diferentes componentes difi-cultarían una correcta apreciación, entonces, lo mejor es enfrentar el estudio construyendo diferentes modelos; por ejemplo, sobre:

• La apariencia externa, ¿tal vez una fotografía? • La carrocería. • El sistema eléctrico. • El sistema de frenos.

Por supuesto, deberíamos preguntarnos acerca de la finalidad que perseguimos con este estudio. Tal vez sea realizar un estudio sobre las características aero-dinámicas del automóvil, por lo tanto, los modelos que se construyan deben ayudar a ese objetivo, por ejemplo, diagramas detallados sobre:

• La carrocería, desde diversos ángulos. • El impacto del roce a diferentes velocidades.

En resumen, los modelos deben construirse de acuerdo con los fines que per-sigue el diseñador. En los sistemas de información, los modelos se construyen para comprender la realidad y efectuar un diseño correcto. Por ejemplo, las siguientes cuatro perspectivas de un sistema de inventarios.

Primera, según el objetivo principal: por ejemplo, el control del stock, tal como se aprecia en la figura 3-2. Las transacciones actúan sobre actualizar el stock de los productos en el inventario. Este modelo obliga a plantearse cuál es el objetivo vital del sistema. Incluso, podría construirse rápidamente un prototipo para observar la operación del sistema en función del cumplimiento de ese objetivo.

Figura 3-2. Modelo orientado al objetivo principal del sistema

Controldel stock

Compras

Devoluciones

Traspasos

Ventas

Devoluciones

Traspasos

Entradas Salidas

JUAN BRAVO C. 180

Segunda, según 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 sólo puede tener un pro-veedor, de ahí el sentido de las flechas. Una compra puede incluir varios artí-culos y un artículo puede estar presente en varias compras. A su vez, un pro-veedor puede suministrar varios artículos y un artículo puede ser suministrado por varios proveedores. Un cliente puede tener varias ventas y una venta sólo puede tener un cliente. Una venta puede incluir varios artículos y un artículo puede estar presente en varias ventas.

Figura 3-3. Modelo orientado a los datos

Tercera, según la funcionalidad: se establecen, por ejemplo, las reglas del negocio que vemos en la figura 3-4. Las funciones de ingreso y actualización de compras actúan sobre el stock y el costo de los productos en el inventario. Este modelo cumple una misión parecida a la del diseño estructurado, separa las entidades y las funciones.

Figura 3-4. Modelo orientado a las funciones del sistema

Proveedores

Compras

Artículos Ventas

Clientes

Proveedores

Compras

Artículos Ventas

Clientes

Compras ArtículosFunciónIngreso de datos Función

Actualización de compras

ReglasMover último costoSumar las unidades adquiridas al stock

Compras ArtículosFunciónIngreso de datos Función

Actualización de compras

ReglasMover último costoSumar las unidades adquiridas al stock


Cuarta, según el flujo de transacciones: se muestra en este modelo que las transacciones “atraviesan” (actualizan) horizontalmente los maestros, tal co-mo vemos en la figura 3-5. Es una matriz con entidades permanentes y transi-torias, distinción más conocida como maestros y transacciones, respectiva-mente. Los maestros son los pilares, por ejemplo: clientes, artículos y provee-dores. Las transacciones fluyen, por ejemplo: ventas del día, compras y devo-luciones de ventas.

Figura 3-5. Modelo orientado al flujo de transacciones

Cada modelo representa una visión particular sobre el problema: objetivos, modelo de datos, funciones y flujo de transacciones. Cada uno sirve de dife-rente manera a los propósitos del diseñador. En el fondo, la variedad de visio-nes es tan amplia como la variedad de puntos de vista respecto a una reali-dad57. En la figura 3-6 se muestra este concepto de infinitas visiones que se obtiene como subproducto del concepto de homomorfismo.

Figura 3-6. Infinitas visiones de una realidad

Para efectos del software, importa consensuar los modelos más adecuados y decidir cuáles serán parte del método que la organización adopte.

57 Abriendo levemente la puerta de la filosofía, hay quienes plantean que no existe una reali-dad objetiva, sino que hay solamente visiones subjetivas, avalando la afirmación con estudios sicológicos que demuestran que la percepción del entorno es siempre personalizada, porque tiene que atravesar el filtro de las abstracciones personales obtenidas de nuestras experiencias particulares.

…

… …

Modelo de datos

Prototipo visualModelo de funciones

Objetivo del sistema

Flujo de transacciones…

… …

Modelo de datos

Prototipo visualModelo de funciones

Objetivo del sistema

Flujo de transacciones

Clientes Artículos ProveedoresCuentasContables

HistorialVentas

Transacciones

Maestros HistorialCompras

Ventas X X X XCompras X X X XDevolución ventas X X X X

JUAN BRAVO C. 182

3.2. MODOS DE PROCESAMIENTO

Un mismo requerimiento puede variar totalmente en su diseño dependiendo del tiempo de respuesta solicitado. Si necesitamos la respuesta para dos días más, entonces el modo de procesamiento batch-interactivo sería la solución. Si el requerimiento se puede satisfacer dentro de 24 horas, tal vez el esquema en línea sea la solución. Si la información se requiere procesada al mismo tiempo que se genera el dato —por ejemplo, en un punto de ventas o en una recepción de mercadería— entonces necesitamos un sistema que la respuesta sea en tiempo real.

Las diferencias no son gratis, porque mientras más pronto es el tiempo de res-puesta, más complejo es el diseño, mayor el tiempo de implementación y el costo sube. Por eso hablamos de las tres dimensiones del diseño.

Las tres dimensiones del diseño son: datos, funciones y tiempo de respuesta, tal como se aprecia en la figura 3-7. Cualquier variación substancial de alguna de ellas provocará un cambio de modelo.

Figura 3-7. Las tres dimensiones del diseño

En general, se entiende que si el modelo de datos sufre cambios notables o si las funciones a realizar con ellos varían significativamente, entonces será ne-cesario modificar el diseño. Sin embargo, es poco conocido hablar de un cam-bio en el modelo cuando varía el tiempo de respuesta requerido del sistema; ese es el objetivo de esta sección, dar a conocer esa tercera dimensión del di-seño, la cual está directamente relacionada con el modo de procesamiento.

Veremos:

Tiempo de respuesta

Funciones

Datos


1. Batch-Interactivo 2. En línea 3. En tiempo real

1. Batch-Interactivo En este caso los datos se ingresan en forma diferida respecto a su generación, ya sea en el departamento de sistemas o en el punto de generación del dato. La actualización de la información es diferida respecto al ingreso.

Por punto de generación del dato entendemos el lugar donde se origina la in-formación: 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 según la siguiente secuencia de funciones:

• Ingreso: se ingresan los datos de un período determinado a la entidad de transacción. Habitualmente los movimientos de un día.

• Informe: se imprimen todos los datos de la entidad de transacción. El obje-tivo de este informe es revisar manualmente los datos del último período de ingreso.

• Actualización: con las transacciones del último período de ingreso se ac-tualizan una o varias tablas para agregar, modificar o totalizar datos.

• Inicialización: después que los datos del último período de ingreso fueron efectivamente actualizados, se elimina la tabla de transacciones del período actualizado (más bien se respalda fuera de línea).

En este último tiempo se ha producido una revalorización del procesamiento batch, es como volver a la sencillez original. Podría ser un buen comienzo para usuarios y especialistas principiantes. Además, representa un punto de partida fácil, rápido y seguro para el primer prototipo de una aplicación.

A muchos usuarios se les vendió el procesamiento en tiempo real sin haber sido una necesidad para ellos, podrían haber resuelto su problema con infor-mación diferida algunas horas e incluso días. Esto trajo como consecuencia un nivel de complejidad y costos innecesariamente altos.

2. En línea Se ingresan los datos en forma diferida respecto a su generación, ya sea en el departamento de sistemas o en el punto de generación del dato. La actualiza-ción de la información es simultánea al ingreso.

JUAN BRAVO C. 184

Al terminarse el ingreso de una transacción, se activan mensajes para realizar las actualizaciones de maestros, uno de los cuales será un registro de las tran-sacciones del día, o del período de ingreso considerado.

Aquí la característica principal es que se procesa transacción a transacción.

3. En tiempo real Se ingresan los datos en el punto de generación del dato y la actualización de la información es inmediata. Este es un método de procesamiento relativa-mente nuevo y trascendental, porque implica ingresar y actualizar la informa-ción en el momento y desde el lugar donde se genera la transacción, por lo tanto, es necesario cuantificar los recursos de software, hardware y de comu-nicación que se requieren.

Este es el esquema predilecto en Internet.


3.3. ONCE CLAVES DE LOS MODELOS

COMPUTACIONALES

Estas claves de los modelos de sistemas computacionales son orientaciones conceptuales adicionales al método que la organización decida. Por lo tanto, no hay una indicación en la forma de “pasos a seguir”. Asimismo, son inde-pendientes de la implementación, de algún hardware específico y de las herramientas de software que apoyan el desarrollo.

Son 11 claves orientadas a enriquecer los modelos de aplicaciones computa-cionales. Son diferentes a las características universales del diseño de produc-tos y servicios, como por ejemplo: abstracción, amistosidad, flexibilidad, por-tabilidad, impersonalidad y factibilidad. Se supone que ellas son conocidas.

Veremos: 1. Fluidez 2. Intuición 3. Simplicidad 4. Orientación al cliente 5. Independencia de la implementación tecnológica 6. Iteración 7. Totalidad 8. Generalización 9. Desarrollo incremental 10. Transacciones presentes 11. Armonía 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 organización, de la misma manera como las aguas de un río buscan su cauce natural.

En la organización, a veces el flujo de datos queda atrapado en una reglamen-tación obsoleta, pero ¡la naturaleza viene en ayuda de la organización! Y ese flujo se desborda y busca sus caminos naturales: ¿cuántos manuales de proce-dimientos reflejan la realidad?

Es fundamental que el diseñador no pretenda forzar la realidad, sino que la capture lo más fielmente posible en pocos modelos dinámicos.

JUAN BRAVO C. 186

2. Intuición El modelamiento es una tarea eminentemente creativa, por lo tanto, la intui-ción juega un rol preponderante. Esto se puede interpretar como de acuerdo con el sentido común o percepción.

¿Qué es la intuición? Hay quienes dicen que es una de las voces de la con-ciencia. Es esa sensación de incomodidad, de que algo sobra o algo falta en el modelo, ¿tal vez percibimos que no deberíamos hacer el sistema computacio-nal porque hay una solución mejor y no nos atrevemos a comunicarla? ¿podría afectar nuestros intereses?

Es un buen momento para reiterar algo que quedó esbozado en el capítulo primero: un verdadero profesional es aquel que soluciona el problema del cliente de la mejor forma. No es quien aplica la técnica más moderna o usa los productos más 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 interés comercial.

Si un modelo cumple con todas las reglas, pero a usted algo le incomoda, ¡hágale caso a su intuición! Probablemente descubrirá que su percepción era correcta, tal vez algo cambió en la realidad o existe un problema de enfoque que es mejor atender.

No estamos hablando de algo místico, sino de procesos biológicos que recién se comienzan a estudiar científicamente. Lo explica bien Malcolm Gladwell en su documentado libro Inteligencia Intuitiva (2006, pp 51-52): “La capaci-dad para extraer conclusiones a partir de una pequeña selección de datos signi-ficativos no es un don exótico. 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 situación nueva. Lo hacemos porque tenemos que hacerlo y llegamos a depender de esa capaci-dad… en muchas situaciones en las que prestar una atención minuciosa a unos pocos datos reveladores, aunque no sea más que durante uno o dos segundos, puede darnos muchísima información”.

Es simple, el subconsciente es bastante más rápido que la reflexión por una cuestión de sobrevivencia, utiliza pocos datos relevantes (como en la teoría de los pocos críticos de Pareto) y ayuda a tomar decisiones en poco tiempo. Lo que plantea Gladwell es que esos pocos datos relevantes son simples observa-ciones de la realidad detectadas con mayor rapidez.


Entonces, sin ser toda la fuente para una toma de decisión consciente, la intui-ción tiene un rol que jugar en la validación de los modelos, sobre todo si se trata de personas preparadas que han educado su intuición con información cada vez más relevante.

3. Simplicidad Habitualmente, la elegancia va de la mano con la simplicidad. Es más, se podría plantear la siguiente regla: si el modelo se ve complicado, hágalo otra vez. Sólo hay que darse por satisfecho cuando el modelo es y se ve fácil de entender, lo cual puede llevar esfuerzo, pero es una excelente inversión.

Existe simplicidad en el modelo cuando lo entienden los demás, especialmen-te el usuario y cuando se siente que es simple.

La simplicidad también se refleja en mantener una solución limpia, sin parti-cularizaciones para efectos de la implementación tecnológica.

“Simple como un anillo”, dice Pablo Neruda en su famoso Poema 15.

4. Orientación al cliente Desde el punto de vista de proyectos de negocios, todos en la organización de-ben estar orientados al cliente (las personas que pagan nuestro sueldo, no el “cliente interno”, metáfora que sólo agrega confusión cuando algunas personas creen que es suficiente con realizar bien su función).

También se le llama “Visión de procesos”, porque siempre existe una doble responsabilidad, la función individual y asegurarse que funcione el proceso completo del cual nuestra función es parte.

¿Cuál es el cliente del área de RRHH? El Cliente.

¿Cuál es el cliente del área de informática? El Cliente.

En ambos casos y en muchos otros, es circunstancial otorgar un servicio interno, lo más importante es cómo ese servicio impactará en el cliente (el negocio de la organización).

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 aplicación de la orientación al cliente porque proviene de una de las características más intrínsecamente humanas: el deseo de servir. Por

JUAN BRAVO C. 188

eso es que cuando no lo hacemos o pretendemos tomar en cuenta sólo nuestro interés, alguna señal nos envía la conciencia.

Esto es verdadera educación.

5. Independencia de la implementación tecnológica Significa que los modelos de la aplicación deben poder implementarse con diferentes lenguajes y en diferentes plataformas.

Más precisamente, el modelamiento del sistema debe ser independiente del hardware y del software, porque ambos aspectos son tan dinámicos que podr-ían variar desde cuando se concibe la aplicación hasta su explotación. Lo úni-co que realmente debiera afectar al modelo son los cambios en la realidad o los requerimientos.

Es equivalente a diseñar los edificios con independencia de los tipos de ma-quinaria o métodos de construcción y por supuesto, dentro de parámetros ge-nerales de factibilidad técnica y financiera, más propios del entorno que de un proyecto específico.

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 más fielmente posible la realidad.

6. Iteración El modelamiento final se obtiene después de varias iteraciones, buscando en cada nueva “versión” perfeccionar la anterior.

Las iteraciones no son infinitas, porque podemos apreciar que generalmente las primeras versiones resuelven los aspectos de mayor importancia y las si-guientes son perfeccionamientos cada vez menores; tal como se muestra en la figura 3-8.

Se puede realizar iteración de varias formas, para construir prototipos, aplicar desarrollo incremental por módulos o desarrollo en espiral (ver anexo 3).


Figura 3-8. Esquema de aproximaciones sucesivas

7. Totalidad El modelamiento de la aplicación debe considerar todos los elementos, aunque algunas partes sean incorporadas sólo para conservar la visión de conjunto, sin llegar a un nivel de detalle.

La totalidad responde a la necesidad de una visión holística del problema. Lo importante es captar completamente la realidad y llevarla al modelo.

Desde el punto de vista de la ingeniería 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. Generalización Cada problema, apropiadamente planteado, no es más que un caso particular de un problema general más fácil de resolver. Así se hace inversión en inteli-gencia, porque los nuevos problemas particulares que se vislumbran ya es-tarán resueltos.

Es un signo de inteligencia no resolver siempre los mismos problemas. Esto significa buscar el “metaproblema”, aquél que representa a todos los proble-mas del mismo tipo. Una aplicación es el mapa de necesidades que vimos en el capítulo 1.

JUAN BRAVO C. 190

El concepto de generalización tiene sus raíces en el proceso cognitivo del ser humano y es uno de los pilares de la orientación a objetos. En el capítulo cuar-to se analiza en detalle.

Para aplicar generalización es necesario hacer uso intensivo de las técnicas de clasificación. Significa ordenar los elementos con características similares; por ejemplo, separar los vehículos de transporte terrestre entre automóviles, camionetas, buses, camiones, motos. ¿Y las bicicletas, trenes y vehículos an-fibios? Es una tarea que requiere mucha prolijidad y creatividad, porque es necesario descubrir afinidades, identificar aspectos comunes e inventar clasi-ficaciones. Por supuesto, no existe la clasificación perfecta, pero el sentido común dará la pauta de hasta adonde llegar.

9. Desarrollo incremental Consiste en dar una solución simple, general y de la mayor relevancia respecto al problema, es una plataforma que funciona bien. Luego, por agregación de módulos 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 adaptación a las necesidades específicas del cliente.

Por supuesto, el desarrollo incremental es esencialmente iterativo.

10. Transacciones presentes La forma más 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 digitación en la factura ingresada ayer y que ya afectó a los maestros de inventarios y de cuentas contables? Una posible y muy generalizada “solución” es arreglar “a mano” los maestros in-volucrados; significa intervenir directamente el resultado en el maestro; por ejemplo, incrementar el inventario en dos unidades. Esto

tiene muy altos costos, porque, si fuera necesario reprocesar a raíz de una “caída del sistema”, todos los arreglos efectuados a mano no se podrían repro-ducir y los repositorios de datos quedarían inconsistentes… a menos que se lleve un registro manual de las correcciones y se vuelva a hacer el esfuerzo de digitación; ¡bueno!, por eso es cara y engorrosa esa solución; sin contar con que se transgreden normas elementales de control y auditoría.


La solución formal y elegante es aplicar una contra-transacción, una transac-ción presente que revierta la anterior; en el ejemplo, la anulación de la factura errónea y su reingreso correcto. Ahora, ¿qué sucede si la anulación está inco-rrecta? No se continua con un juego infinito de contra-transacciones, sino que se hace una transacción de ajuste. Esto significa definir el siguiente juego de operaciones: transacción original, contra-transacción y ajuste. Así, se da una línea continua en el tiempo y nunca se “vuelve al pasado”.

La aplicación 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 crédito y débito.

Es una aplicación de una de las prácticas transversales del método GSP, la trazabilidad.

11. Armonía entre el modelo y la realidad Los modelos son representaciones de la realidad, especialmente de una reali-dad deseada. Cuando en el modelo se le da importancia desproporcionada a situaciones indeseadas, el efecto es que se aumenta la probabilidad de ocu-rrencia de esas situaciones.

Es lo mismo que el criterio curso normal de los eventos que veremos en la sección 3.6 aplicados en los flujogramas de información y en los casos de uso del lenguaje UML. Lo que queremos enfatizar aquí es que esta clave de armo-nizar el modelo y la realidad aplica a todos los tipos de modelos de la solución de software.

Por ejemplo, al buscar un producto en una bodega, una situación indeseada es que el producto no se encuentra y esto ocurre en el 1% de los casos. Un error de modelamiento sería incluir un rombo en cualquier tipo de modelo donde diga ¿Lo encontró? y luego ese rombo tenga dos salidas, Sí y No. Nótese que visualmente se le estaría dando una importancia equivalente a las dos salidas, sin embargo, una ocurre en el 99% de los casos y la otra en el 1%. Además, lo que estamos modelando es como queremos que sea la realidad, sin esas situa-ciones indeseadas.

El efecto psicológico es que cuando un operador del proceso observa el rom-bo, es como si tácitamente tuviera permiso para dejarse llevar a la situación indeseada. En Chile se dice: se deja la caída.

JUAN BRAVO C. 192

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 formación en el proceso. Aunque no le damos el mismo espacio visual que lo deseado58.

Una experiencia del autor. En cursos a profesionales en una reconocida uni-versidad, ocurría que al momento de la evaluación 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 evaluación. 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 bifurcación de no presentarse a la eva-luación como una opción válida. Por supuesto, en los siguientes cursos se aplicó armonizar el modelo con la realidad y las ausencias para la evaluación volvieron al nivel anterior.

58 A propósito, el modelo que ofrece la TV es muy fuerte en este sentido. Por ejemplo, en Chile se ha hecho costumbre fomentar el uso de lenguaje grosero en la TV. En una entrevista a la conocida humorista chilena Gloria Benavides (2006), La cuatro, dice: “Me llama la aten-ción el lenguaje que ocupa la gente [en la TV]. Supuestamente la televisión siempre ha ense-ñado. En Estados Unidos, de hecho, estamos bajo la fuerte presión de la FCC que se preocupa de que no digas ni siquiera una mala palabra… acá hubo como un destape”.


3.4. MODELAMIENTO DE FUNCIONES

Una función computacional da respuesta a un requerimiento de usuarios. Para cumplir su objetivo incluye una parte pública y otra que depende del requeri-miento, más conocida como regla del negocio.

La parte pública es generalizada y la parte regla del negocio es propia de la misión de la organización. Se puede hacer una comparación entre parte públi-ca y regla del negocio con las partes generalizada y opcional de la compra de un automóvil, respectivamente. El automóvil no se reinventa cada vez, sino que trae una gran base predefinida: motor, carrocería, frenos, sistema eléctri-co, etc. Adicionalmente, existe la posibilidad de efectuar una personalización mediante algunas elecciones: tapiz, radio, tipo de caja de cambios y colores interiores.

La idea es tomar como un todo la necesidad del procesamiento de datos y bus-car la funcionalidad común que tienen la mayoría de las aplicaciones: ingreso de datos, informes, cálculos, extracción de información, actualización, selec-ción y otras. Con esa funcionalidad común, se plantean procesos reutilizables.

Veremos: 1. Descomposición funcional 2. Reglas del negocio 3. Funciones asociadas a una entidad 4. Relaciones funcionales entre dos entidades

1. Descomposición funcional El objetivo es identificar funciones computacionales atómicas que actúan so-bre una o dos entidades. Por ejemplo, en funciones asociadas a una entidad tenemos ingreso, informe y cálculo. En dos entidades: actualización, selección y extracción.

La función computacional es la mínima unidad que se obtiene al “dividir” un sistema computacional. En ese sentido es “atómica”. En el contexto del mode-lamiento tradicional, es cuando ya no se obtiene beneficio al seguir fraccio-nando; lo cual, incluso, puede llegar a ser inconveniente o absurdo. Esta situa-ción se da, por ejemplo, al construir dos programas de ingreso de datos para la misma entidad o al construir tres programas para hacer la actualización entre ventas y artículos: uno para restar el stock, otro para calcular la valorización y el tercero para acumular el total de unidades vendidas en el día.

JUAN BRAVO C. 194

Es similar a la naturaleza simple que propone René Descartes en su Discurso del Método (de análisis) y a la tabla plana que surge del proceso de normaliza-ción de datos.

¿Cómo se llega a determinar una función computacional atómica?

Aplicando el concepto de descomposición funcional, el mismo que se usa en programación estructurada para identificar los módulos del programa y ahora orientado a partes de la aplicación. La idea es llevar el concepto de descompo-sición 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 análisis pueden ser procesos del negocio, en el diseño objetos y dentro de un objeto funciones que actúan sobre los datos.

Es más preciso entender la descomposición funcional comparando con la for-ma como se establecen las fronteras de los países en la figura 3-9. En el caso A las fronteras están definidas considerando dominio cultural, historia, sepa-raciones naturales (cordilleras, ríos) y mucha negociación, eso sería te a la descomposición funcional. En el caso B, supongamos que los países surgen de una división artificial y rápida basada en las coordenadas geográfi-cas (paralelos y meridianos) creando caos y confusión (cualquier similitud la actual situación de África es mera coincidencia, bueno, casi).

Figura 3-9. Concepto de descomposición funcional

En la figura 3-9 queda de manifiesto que cada país es la “unidad atómica” del mapa, definido siguiendo el orden natural de las cosas. Con las aplicaciones

20º 40º0º

Caso A: Separación natural Caso B: División artificial


computacionales es similar, porque la descomposición funcional ubica final-mente “tipos de funciones” sobre una entidad (lo veremos en el capítulo 5 sobre orientación a objetos).

Cada función atómica se puede transformar directamente en un programa de computador, es decir:

En cada programa, el código fuente aportado por sobre la normalización de la función probablemente sea muy poco, tal vez no mayor a 100 líneas; igual debe cuidarse su claridad, sencillez y elegancia.

En todo caso, esto depende también del tamaño y complejidad de la aplica-ción. Por otra parte, la implementación puede simplificarse con un generador de código que tome directamente los modelos de datos y funciones, para gene-rar automáticamente los programas. Ya lo veremos en el capítulo 7 (Herra-mientas TI).

2. Reglas del negocio Cada función incluye reglas del negocio que actúan sobre los campos de las entidades relacionadas; por ejemplo, en una función de actualización desde ventas a artículos se identificaron las siguientes reglas que modificarían la entidad artículos: restar la cantidad vendida del stock y sumar unidades vendi-das en el mes.

Para efectos de la ejecución de las funciones, cada una puede ser simplemente una opción de un menú o parte de una Función mayor, la que permite ejecutar varias funciones en un orden predeterminado.

La idea es que sobre el modelo de datos se sobreponga el modelo de funcio-nes, definiéndose ahora relaciones funcionales entre las entidades, que se ac-tivan según las secuencias de procesamiento, tal como se muestra en la figura 3-10, donde los recuadros indican entidades y las líneas señalan funciones.

1 Función atómica = 1 Programa

JUAN BRAVO C. 196

Figura 3-10. Ejemplo de relaciones funcionales

Una relación funcional puede corresponder a cualquier función entre dos enti-dades, con la característica de que una de ellas, o ambas, sean alteradas. Es el caso de la actualización, extracción o selección de información.

En la figura 3-10 se puede apreciar una secuencia de procesamiento de varias funciones:

1.- Actualizar stock de artículos desde ventas 2.- Actualizar saldo de crédito disponible del cliente 3.- Actualizar stock de artículos desde mermas

Veremos a continuación algunos tipos de funciones atómicas sobre una y en-tre dos entidades.

3. Funciones asociadas a una entidad Algunos tipos de funciones donde se trabaja con una entidad, son los siguien-tes:

• Ingreso: se realizan las operaciones de consultar, agregar, modificar y eli-minar registros de una entidad. Si se trabaja con alguna herramienta, la pre-sentación de la pantalla podría ser proporcionada por omisión, aunque con la posibilidad de que el usuario la pueda alterar o “pintar” de acuerdo con su gusto.

• Consulta: aquí se permite la consulta por la clave y por las relaciones pro-pias. También el formato de la pantalla debiera ser proporcionado por omi-sión y con posibilidades de ser alterado.

Ventas

Clientes

Artículos Mermas1

Actualizar stock

3

Actualizar stock

Actualizar saldo de crédito del cliente2


• Informe: se obtiene desde una entidad, indicándose: ancho del informe, campos que se imprimen, formato de impresión, saltos de página, ordena-miento, totalizaciones, encabezado de página y pie de página.

• Cálculo: se realizan diferentes operaciones sobre algunos campos de una entidad para obtener, por ejemplo, valorización de stock o corrección mo-netaria. Además de las operaciones básicas: sumar, restar, multiplicar, divi-dir, promediar y mover valores fijos. Es deseable poder realizar operaciones matemáticas, estadísticas y financieras.

• Cálculo selectivo: significa realizar operaciones entre campos de diferentes registros de una misma entidad; por ejemplo, obtener el total neto, la suma-toria de unidades por valor, de un determinado número de factura en la en-tidad “detalle de factura”.

• Reconstrucción: es una función que permite reconstruir una entidad, para regrabar los índices y ordenar los datos.

• Inicialización: es una función que permite crear una entidad antes del in-greso de datos; es lo mismo que un archivador, el cual tiene que existir para poder guardar documentos.

Se ha utilizado con éxito esta tipificación en múltiples aplicaciones reales. No obstante, es una lista que puede continuar extendiéndose.

Una entidad puede tener asociadas, desde el modelo de datos, otras entidades, tablas e índices que permitirán cumplir con las funciones indicadas. Tomemos como ejemplo el ingreso de un artículo en la entidad “detalle de la factura”; en este caso, al digitarse el código del artículo, se aplica una condición de exis-tencia sobre la entidad “maestro de artículos”. ¿Significa esto que hay dos entidades en el ingreso de datos? Sí, a nivel físico, de implementación y cons-trucción; 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 artícu-los aparece únicamente cuando se activa la funcionalidad asociada al campo código del artículo, definida en el modelo de datos. Es una validación relacio-nada con ese campo específico y no interfiere con la función computacional.

Las asociaciones de campos con su funcionalidad, definidas en el diccionario de datos, servirán para validar condiciones de existencia, presentar la informa-ción extraída desde las entidades asociadas o efectuar cálculos.

Es el mismo caso en relación a tablas, para lograr la traducción automática de un código a un texto; por ejemplo, el nombre de cada sucursal.

JUAN BRAVO C. 198

4. Relaciones funcionales entre dos entidades La función computacional atómica se obtiene cuando participan dos entidades (cuando hay más, no interactúan todas a la vez, sino que por turnos).

Nota: La definición de funciones entre dos entidades tiene aquí carácter provi-sorio, porque luego, en la orientación a objetos, aplicando el concepto de en-capsulamiento, veremos que realmente toda función actúa sólo sobre una enti-dad.

Si se trata de una actualización donde hay una transacción 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 capítulo, por criterios de eficiencia ya obsoletos.

Veremos a continuación algunos tipos de funciones entre dos entidades: ac-tualización, extracción, selección y mantención.

Actualización

Una entidad de transacción actualiza una entidad de maestro, tal como se muestra en la figura 3-11.

Figura 3-11. Esquema de una actualización

Generalmente, la actualización puede tomar alguna de estas formas:

• Sólo se agregan nuevos registros: se llevan registros a la entidad de maes-tro a partir de los registros de la entidad de transacción. Los registros que se agregarán no deben existir en la entidad de maestro; por ejemplo, llevar las ventas del día a un historial de transacciones.

• Actualizar sobre registros existentes: se busca un registro específico de la entidad de maestro según la clave formada con los campos de la entidad de transacción, para efectuar sobre él operaciones de actualización, como mo-ver o sumar campos. Los registros especificados deben existir previamente en la entidad de maestro; por ejemplo, cuando las ventas del día rebajan el stock de los productos vendidos en el maestro de artículos.

Transacción

Mover clave de maestro

MaestroOperaciones entre campos:Mover, sumar y restar


• El registro se crea si no existe. Se busca un registro específico de la enti-dad de maestro según la clave formada con los campos de la entidad de transacción; si no existe, el registro se crea en forma automática con todos sus campos en blanco o en cero, para luego efectuar sobre él operaciones tales como sumar o multiplicar campos. Por ejemplo, cuando se quiere ob-tener la venta total por sucursal: al principio, el maestro de totales no tiene registros, luego, cada vez que aparece por primera vez una sucursal se crea uno y después se va acumulando sobre ese registro cuando la sucursal apa-rece otras veces.

Obsérvese que los registros que serán actualizados o agregados podrían existir o no en la entidad de maestro.

Extracción

Es una función que permite a la entidad A pedir uno o varios datos a la enti-dad B. Aquí se busca un registro específico en la entidad B según la clave formada con los campos de la entidad A, para extraer uno o varios campos que serán regrabados en la entidad A, donde también deben estar definidos. En la figura 3-12 se muestra el esquema de una extracción.

Figura 3-12. Esquema de una extracción

Selección

Esta función permite seleccionar información desde una entidad ORIGEN para llevarla a una entidad DESTINO. El traspaso se realiza aplicando condiciones de selección fijas o variables, de forma similar a trabajar con herramientas tipo QUERY (en relación a consultas no estructuradas sobre la base de datos), tal como se observa en la figura 3-13.

Figura 3-13. Esquema de una selección

Origen DestinoOperaciones de mover,con o sin condiciones

A B

Clave

Datos solicitados

JUAN BRAVO C. 200

En la selección, las condiciones fijas debieran quedar incorporadas al progra-ma, evitándose que el usuario ingrese parámetros al ejecutar la aplicación; por ejemplo, la condición: “obtener los artículos con stock < 0” puede ser la op-ción de un menú.

Una alternativa de mayor flexibilidad y necesaria en estos tiempos, es que los parámetros se almacenen en tablas, evitando que sean parte del código.

Respecto a las condiciones variables, el usuario ingresa los valores requeridos al momento de la ejecución de la aplicación; por ejemplo, tipo de artículos = ??; el usuario indica el tipo de artículos que desea obtener: lavadoras, refrige-radores, etc…

Mantención

Esta función permite mantener una entidad de maestro a través de transaccio-nes que quedan registradas. Toma la forma que se muestra en la figura 3-14.

Figura 3-14. Esquema de una mantención

Permite agregar, modificar y eliminar registros. Esta función es de fundamen-tal importancia porque muchas veces se hace mantención directa sobre un maestro sin que quede ningún rastro. En este caso, todos los cambios quedan registrados en una entidad histórica de transacciones, donde se almacenan todos los movimientos.

Esto es importante, porque es muy posible que la entidad de transacción sea inicializada si el procesamiento fuera de tipo batch-interactivo.

TransacciónMover clave de maestro

MaestroAgregar, modificar o eliminar


3.5. FUNDAMENTOS DEL MODELAMIENTO DE

FUNCIONES

¿Por qué es modelar las funciones? El modelamiento de funciones tiene bases sólidas, algunas son:

• Tener un modelo antes de construir. Es equivalente a preguntar sobre los planos de un edificio, donde la extensión y profundidad de los modelos va en directa relación 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 construcción de código.

• Tener la posibilidad de aplicar herramientas de productividad o código reutilizable, lo cual sería imposible sin un modelo previo.

• Realizar trabajo de grupo con otros colegas y con usuarios. • Simplificar la relación con el usuario al conversar su requerimiento en la

forma de modelos.

Veremos: 1. Resolución de problemas simples 2. Modelar bien a la primera 3. Concepto de máquinas abstractas

1. Resolución de problemas simples Siempre es posible dividir un problema complejo en un conjunto de proble-mas simples, cada uno de los cuales será más fácil de resolver. Este es un importante principio asociado al concepto de descomposición funcional. Además, debemos reconocer que cada solución obtenida es un caso particu-lar de un problema general más fácil de resolver.

También se obtienen algunos subproductos:

• Uniformidad, porque los problemas simples tienen la importante caracterís-tica de ser muy similares entre sí. Por ejemplo, en la actualización se puede encontrar que en la mayoría de los casos se trata de mover, sumar o restar campos entre dos entidades.

• Automatización, si los problemas son simples, similares y uniformes, en-tonces automatizar las soluciones es el siguiente paso, más aun con el apo-yo de las herramientas para la producción de software.

JUAN BRAVO C. 202

2. Modelar bien a la primera El problema debería ser resuelto con un buen modelo, simple, elegante y lo más estándar posible. Así se evita en la implementación 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, estética o seguridad.

De esta forma se reduce el riesgo de incorporar particularidades difíciles de programar y mantener.

Incluso se facilita el indispensable perfeccionamiento continuo que tiene lugar después de la implementación.

3. Concepto de máquinas abstractas Este concepto comenzó a aplicarse en los años sesenta, buscando modularidad en los programas de computador. De aquí nacieron también los conceptos de la programación estructurada.

Uno de los principales investigadores en esta materia fue el Dr. Edsger W. Dijkstra59, también importante impulsor de la programación estructurada; él define que una máquina abstracta consta de una entrada y una salida.

En 1968, el Dr. Edsger W. Dijkstra envió una carta a la Asociación para máquinas de computación, en Estados Unidos, sobre el tema de si los progra-madores debían usar instrucciones de salto incondicional (GO TO) en los pro-gramas. Ahí propuso la disciplina de secuenciamiento riguroso para evitar los saltos incondicionales, con base en el concepto de máquinas abstractas de la teoría de sistemas. Se considera que esa carta dio origen a la práctica de la programación estructurada (y a la descomposición funcional que luego sería base del encapsulamiento).

La propuesta de este texto es aplicar el concepto de máquinas abstractas a nivel de la aplicación completa. Así, en lugar de tener pocos programas gran-

59 Dijkstra (1930 – 2002), fue físico teórico y trabajó para Burroughs Corporation en los años 70. Realizó reconocidos aportes a la naciente ciencia de la computación y recibió el Premio Turing en 1972. Promovía utilizar estructuras de control en los programas de computador y fue firme partidario de evitar en ellos la instrucción GO TO. Sus aportes son tan relevantes, que se han formado grupos formados por discípulos y colegas suyos de la Universidad de Texas —donde enseñó el último cuarto del siglo 20— para recu-perar y disponer de su obra en Internet.


des cada uno con muchos módulos, administraremos las funciones computa-cionales atómicas que componen una aplicación en la forma de componentes.

Entonces, obtendríamos lo siguiente:

Una función computacional atómica tiene sólo una entrada y una salida, lo cual no tiene que ver con su tamaño, porque lo importante es el código apor-tado para responder a las reglas del negocio. Por ejemplo, podemos tener un programa de ingreso de datos de 1000 instrucciones y solamente 100 de ellas corresponder a lógica del negocio propiamente tal, el resto es estructuración típica de código —manejar pantallas, aceptar y validar datos— que puede ser aportado con herramientas de productividad o mediante código reutilizable.

Podemos concluir que la función computacional se compone de una gran can-tidad de código generalizado y de alguna porción de reglas del negocio.

A propósito, si estamos trabajando para una organización cuya misión no es la informática, sería de gran eficiencia ocupar el código generalizado que ya existe en el mercado en lugar de reinventarlo.

La implementación de este concepto se cumple a cabalidad cuando un pro-grama responde solamente a una función atómica, lo cual funciona bien bajo el esquema tradicional de programación y mejor aun si se cuenta con alguna herramienta de apoyo para la producción de software.

Algunos beneficios de este enfoque:

• Permite reducir el tamaño y la complejidad de los programas. Está sufi-cientemente demostrado que el nivel de complejidad de un programa au-menta geométricamente respecto a su tamaño. Bajo estos conceptos la úni-ca preocupación en cuanto a código serían 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 atómicas son total-mente conocidas y estructuradas; por lo mismo, fáciles de automatizar y mejorar. Además, es posible reemplazar una función computacional atómi-ca por otra sin afectar al resto del sistema, si es que se mantienen intactas las interacciones.

FunciónAtómica

1 Entrada 1 Salida

JUAN BRAVO C. 204

• La modularidad e independencia de las funciones atómicas permite que una aplicación computacional sea construida con piezas intercambiables y tal vez desarrolladas en diferentes lugares (como los juegos de armar de los niños).

En el capítulo 5 veremos que la orientación a objetos recoge la mayoría de los conceptos descritos en este punto.


3.6. CRITERIO CURSO NORMAL DE LOS EVENTOS

El criterio curso normal de los eventos es un nuevo aporte de la teoría de mo-delos y aplica en varios tipos de modelos. Por ejemplo, en la nueva generación de flujogramas de información, en los casos de uso expandidos de la técnica UML (que veremos en el capítulo 6) y en el método GSP del capítulo 1. Tiene sus raíces en la ley de los pocos críticos de Pareto, que ya hemos comentado.

Se describe el curso normal de los eventos, también llamado el “camino fe-liz”, señalando las acciones correctas de un proceso o relato, no se incluyen las excepciones. Por ejemplo, si se requiere que un supervisor apruebe un do-cumento, no se indica gráficamente qué pasa si no lo aprueba, o si un bode-guero debe recibir mercadería, no se indica que sucede si la rechaza. Son ex-cepciones a la regularidad del proceso que se narran en hoja anexa, como par-te de un texto complementario.

Aunque menos habitual, si el manejo de la excepción tiene cierta complejidad, también se puede construir un modelo especial para ella.

La idea general es tratar las excepciones como excepciones, sin darles el mis-mo espacio visual que el curso normal de los eventos, en esto debe existir armonía entre el modelo y la realidad, donde lo más habitual aparece más y lo menos, menos.

Veremos: 1. Aplicado al flujograma de información 2. Relación del FI con la técnica UML

1. Aplicado al flujograma de información El Flujograma de Información (FI) describe y representa una guía de las acti-vidades del proceso. Es un tipo de diagrama de flujo de información que pro-porciona amplia visión acerca de variados aspectos del proceso: flujo, mensa-jes, actividades, estructura y tecnología. El FI es la secuencia y temporalidad. Los Mensajes son el medio de comunicación, pueden ser documentos, comu-nicaciones electrónicas u orales. Las Actividades quedan especificadas por cargos o roles. La Estructura queda representada por columnas. La Tecnolog-ía se indica en las actividades que tendrán algún nivel de apoyo tecnológico.

El flujograma de información describe el curso normal de los eventos, donde se describe gráficamente el esquema habitual, la rutina. Las excepciones se incluyen aparte.

JUAN BRAVO C. 206

Así, el flujograma de información deja espacios para que las personas apli-quen criterio, dejando de lado el absurdo intento de preparar flujos “a prueba de tontos”. Lo nuevo es el principio SPPP (Simplificar Procesos y Potenciar Personas), lo cual se logra aplicando por un lado el criterio curso normal de los eventos y por otro a través de capacitación, sensibilización y empodera-miento, entre otras acciones dirigidas a las personas.

Veamos este FI retomando el ejemplo del mapa de procesos del capítulo 1. En este flujograma de información los números en recuadros con línea punteada son tiempos en minutos: duración de cada actividad cuando están dentro del recuadro y tiempos de reposo de la transacción cuando están fuera. Los símbo-los de uso más habitual se describen en las siguientes páginas.

CLIENTE BODEGA FINANZAS

ADMINISTRATIVO DE BODEGA DESPACHADOR

PROCESO DESPACHO INMEDIATO

GD3’

OE

GD4

GD3GD2

GD1

GD4OE

Buscarproducto

GD’s

Cliente recibey firmarecepción

GD1’

Reservar y emitir GD

Rebajarsaldo

GD2’

OE: Orden de Entrega, GD: Guía de Despacho

PROCESO CUADRAR

PROCESOS VENDER

Figura 3-15. Ejemplo de flujograma de información despacho inmediato


Descripción 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, según el mapa de procesos presen-tado en la etapa de análisis del capítulo 1. Se trata de un local de ventas de artículos de línea blanca con una bodega al fondo de la tienda. El cliente reali-za la compra, paga en el local y recibe una orden de entrega (OE), la cual muestra en la bodega para retirar su producto.

El administrativo de la bodega recibe la OE y se asegura que esté disponible en el inventario una cantidad suficiente del producto, consultando en la panta-lla del computador. Inmediatamente reserva la cantidad indicada del producto y emite la guía de despacho (GD) en 4 ejemplares:

El ejemplar 4 se archiva junto con la OE.

Los ejemplares 1, 2 y 3 se envían al despachador, quien:

• Busca el producto en la bodega (en la misma guía de despacho se indica la ubicación).

• Rebaja el producto del inventario en el computador. • Le entrega el producto al cliente, quien firma la “recepción conforme”. • junto con los ejemplares 1 y 2 de la GD. • Envía el ejemplar 3 de la GD a finanzas.

Excepciones:

• Cuando consulta el administrativo de bodega, si no hay stock del producto derivar al vendedor o al jefe de local, porque al efectuar la venta debiera haberse hecho una reserva provisoria del producto.

• Si el cliente no está conforme con el producto, entonces derivar al vende-dor o jefe de local.

• Si el despachador no encuentra el producto podría intentar en otra tienda, buscar producto similar y otras posibilidades que se estudian durante el en-trenamiento en el proceso. En cualquier caso, está empoderado para tomar esas decisiones y para compensar al cliente por los retrasos o cambios hasta un cierto monto.

Alcance del flujograma de información

El FI incorpora todo el detalle necesario porque desarrolla un proceso de bajo nivel e incluso requiere adjuntar las muestras o el diseño de todos los formula-rios, informes o pantallas que muestra el flujo.

JUAN BRAVO C. 208

Es un acuerdo que todos se comprometen a cumplir mientras se mantenga la normalidad. Sin embargo, la complejidad del medio producirá día a día desaf-íos que no están resueltos en el diagrama, sin embargo, ahí están las personas para decidir qué hacer. Esas mismas variantes ayudarán a perfeccionar el dia-grama en la medida que se discuten y se hacen rutinarias.

Hacer flujogramas de información a escala humana significa conocer bien el proceso y a las personas que los realizarán, tal como dice uno de los pioneros de la gestión de calidad en Japón, Kaoru Ishikawa (1986, pp. 57-58): “Las normas y los reglamentos detallados resultan inútiles si son fijados por el es-tado mayor de la sede e ingenieros especialistas que no conocen la planta y que ignoran los deseos de las personas que tienen que seguirlos. No es raro encontrar técnicos y personal de la sede que disfrutan dificultándolo todo en el lugar de trabajo mediante la creación 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 información permite describir en todo detalle un proceso, es fácil de usar, define canales fluidos de información, sirve como capacitación y documentación, ayuda a normalizar el trabajo de la organización, facilita la comparación con procesos que se realizan en otras organizaciones y estimula la participación.

Cuando se incluyen los tiempos de duración de las actividades y de reposo de la transacción, se aprecian con claridad las necesidades de optimización. Por ejemplo, en la figura 3-15 la sumatoria de duración de las actividades es de 15 minutos y los tiempos de reposo (los documentos están en una cola) son de 34 minutos. ¿Será posible disminuir estos tiempos y así aumentar la satisfacción del cliente?…

Un Flujograma de Información no es un diagrama de flujo computacional

Un FI no es un diagrama de flujo computacional, en consecuencia, debe evi-tarse toda forma de condiciones, como los rombos típicos de los flujogramas antiguos (del tipo “if then else”, si sucede esto entonces haga aquello, si no haga esto otro). No incluye condiciones, representadas por un rombo (ver fi-gura 3-16). Cualquier decisión es una actividad más y tiene como salida el curso normal de los eventos. Tampoco incluye ciclos iterativos, de aquel tipo en que una bifurcación vuelve hacia arriba del flujo. Es suficiente con una nota y normalmente ni siquiera eso es necesario, porque los flujogramas de información son bastante autoexplicativos en ese aspecto.


¿Por qué? Porque estamos describiendo actividades que realizan seres huma-nos, con una variedad y riqueza infinitas, así es que en cada paso hay que de-jar la posibilidad de que las personas decidan variantes que no consideró el analista que dibujó el flujo (si utilizó rombos, entonces deja generalmente dos salidas y en la vida real hay muchas más). Además, los símbolos y condicio-nes computacionales tienden a alejar a los potenciales usuarios.

Por otro lado, así como el flujograma de información está dirigido a personas, el diagrama de flujo está destinado a la lógica 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 codificación en un lenguaje computa-cional (Cobol, C, Visual Basic y muchos otros). Por lo tanto, incorpora condi-ciones, retornos, loops y otras funciones propias del programa de computador. Es diferente a un flujograma de información.

Características del Flujograma de Información

1. Se mantiene la temporalidad. Una actividad que se realiza después va más abajo60. Además, así como no podemos retroceder en el tiempo, se evita volver con una línea hacia arriba.

2. El flujograma de información es a nivel atómico, 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. También corresponde al concepto de atomicidad conservar el orden de cada ejemplar de un documento, por-

60 Es lo habitual, sin embargo, depende de la convención que se use en la empresa, ocasio-nalmente la temporalidad se aplica hacia la derecha (como escribimos). Está bien, es una u otra forma, nunca ambas a la vez en la misma organización.

JUAN BRAVO C. 210

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 están 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 más de una página. Por ejemplo, un macroproceso de compras se redujo a cuatro procesos operati-vos: compra de artículos de oficina, compra de equipos computacionales, compra de repuestos de maquinarias y compra de materias primas, cada uno con su propio FI. En los diagramas antiguos (tipo diagrama de flujo computacional) se hubiera incorporado el macroproceso completo. Lo nue-vo es construir flujogramas de información independientes para cada pro-ceso operativo y el mapa de procesos ayuda a ver el todo.

5. No incluye comentarios, porque se trata que sea autoexplicativo. Aunque es válido usar a veces columnas de “observaciones” en los extremos del dia-grama, principalmente en el extremo derecho. El detalle del flujograma se incluye en texto anexo (dos páginas de texto por cada página de FI es un promedio razonable) como parte de la descripción de los procedimientos administrativos.

6. Es un diagrama que se va construyendo y perfeccionando a través de bo-rradores sucesivos.

Símbolos de uso más habitual * actualzar* 2 láminas ppt

Actividad manual

Se debe usar verbos en infinitivo: “Emitir O/C”, “Ingresar solicitud”. Es un rectángulo.

Actividad computacional

Las actividades que tienen algún componente de interacción computacional se indican con doble línea (a los lados o en todo el borde)

Actividad de aprobación

Es una actividad de aprobación, tal como autorizar un crédito o una compra.

Actividad de control

Es una actividad de control, tal como una información al área de auditoría. Es un cuadrado.

Actividad computacional

Control

Actividad


Archivo manual permanente

El triángulo con la punta hacia abajo repre-senta almacenamiento manual permanente de la información, principalmente archivadores y gavetas.

Archivo manual transitorio

El triángulo con la punta hacia arriba repre-senta almacenamiento manual transitorio, tal como una carpeta con solicitudes de compra en espera de firma por el gerente.

Formulario Es toda forma en papel en que los datos flu-yen, tal como una factura, una orden de com-pra o una liquidación de sueldo.

Otro proceso Indica acciones que están más allá del proce-so. Por ejemplo, es una forma de decir que se envió un documento a un proveedor o que la acción sigue en otro proceso. ¿En cuál? Hay que ver el mapa de procesos.

Archivo computacional

Ambas formas aplican, tipo tambor es más reciente y recomendable.

Comunicación electrónica

Tipo rayo para comunicación electrónica y símbolos Windows sobre el rayo para más detalle (correo, planilla, etc…) @ para Inter-net, otro para intranet o sistemas internos

Resultados del Flujograma de información

Típicamente, al trabajar con un flujograma de información se pide identificar:

• Cliente del proceso • Dueño del proceso • Variables críticas y mediciones asociadas

Además 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 Método de Acción Rápida (MAR) sobre proce-sos. Una técnica orientada a la gestión de procesos que hace uso intenso de los flujogramas de información para mejorar el hacer de la organización.

Archivomanual

Archivotransitorio

Formulario

JUAN BRAVO C. 212

2. Relación del FI con la técnica UML Uno de los aspectos metodológicos y de investigación más interesantes de este libro es el hecho de buscar un punto de encuentro entre dos técnicas de amplio uso: los flujogramas de información y UML.

Específicamente ese punto de encuentro está en las actividades con alguna interacción computacional del flujograma de información, las cuales, si están debidamente segmentadas según las propuestas del texto, darán origen a los casos de uso del sistema computacional. Son los casos de uso correspondien-tes a los procesos del negocio.

En la figura 3-17 se aprecia este punto de encuentro. La actividad “Rebajar saldo” del flujograma de información (figura 3-15) se transforma en un caso de uso de alto nivel de UML.

Figura 3-17. Relación del FI con la técnica UML

Específicamente en la figura 3-17:

• El actor es el despachador, tomado desde el nombre de la columna del flu-jograma de información.

• El caso de uso es “Rebajar saldo”, puesto en infinitivo porque refleja una acción.

• El caso de uso de esta figura es del tipo “alto nivel” porque la descripción es general.

Rebajar saldo

Usa el lector de código de barras para leer la etiqueta de cada producto que se vende. En el sistema se

rebaja el saldo del producto.

Terminal en BodegaDespachador

RebajarSaldo

Actividad del FI

2

Nota: una actividad computacional delFI se transforma

en un Caso de Usode alto nivel

Caso de uso de alto nivel


• La situación ocurre en el terminal de la bodega, incluyendo los accesorios, tal como el lector de código de barras.

Una recomendación metodológica es unir en un “Diagrama de casos de uso” (una forma de agrupación de casos de uso) los casos de uso de cada proceso operativo (o flujograma de información).

JUAN BRAVO C. 214



Capítulo 4. Modelamiento de datos

Sencillez, claridad y elegancia son los sellos de los buenos pro-gramas; oscuridad, ingeniosidad y complejidad son indicaciones

de un diseño inadecuado y un pensamiento mal orientado.

Richard Fairley

El modelamiento de datos logra una visión de conjunto de los datos de la apli-cación y de su contexto. En todo caso, se requiere un gran modelo con los conjuntos de datos de toda la organización para que las diferentes aplicaciones “vean” y trabajen con la porción que les corresponde.

Esta es la cuarta competencia considerada para apoyar la elaboración de modelos de una solución de software, tal como se aprecia en la siguiente fi-gura (en la introducción se incluyó la visión global). Es indispensable que el analista conozca acerca del modelamiento de datos como simple responsabi-lidad profesional porque es una habilidad básica de su labor.

Es vital la visión de conjunto que provee el modelo conceptual de datos de toda la organización, permite comprender, ubicarse y evitar inconsistencias como la de crear dos veces la misma tabla. De esta forma, el aporte de la solu-ción de software será aportar nuevas tablas o modificar las existentes.

Veremos: • Definiciones sobre el modelo de datos • Criterios básicos de normalización de datos • Enfoque de bases de datos






CAPÍTULO 6. UML



JUAN BRAVO C. 216

4.1. DEFINICIONES SOBRE EL MODELO DE DATOS

El modelo de datos consta de entidades y relaciones. Una entidad es un con-junto de datos coherentes que forman una unidad entre sí; por ejemplo: clien-tes, facturas de venta, proveedores. Una relación permite enlazar dos entida-des para establecer recorridos que permitan efectuar la navegación automáti-ca, con el fin de consultar y manipular información. Por ejemplo: obtener una lista de los clientes que han adquirido el artículo 2051.

Disponiendo del modelo de datos completo será posible presentar visiones parciales a los usuarios, según sus requerimientos.

Veremos: 1. Representación de una entidad 2. Relaciones propias 3. Características estáticas y funcionales de campos 4. Tipos de entidades 5. Relaciones entre entidades

1. Representación de una entidad La representación típica de una entidad o tabla se muestra en la figura 4-1 para un ejemplo de clientes (el RUT —Rol Único Tributario—en Chile es la iden-tificación de cada persona u organización para fines tributarios).

Figura 4-1. Componentes de una entidad

Para efectos de facilitar la comprensión de las materias, se han conservado algunas denominaciones tradicionales, tales como entidad, registro y campo.

En la figura 4-1 se puede apreciar que:

RUT del clienteFecha de incorporación

Nombredel cliente

Líneade crédito

4.101.201-4 10/01/1993 Juan Pérez 500.000

7.749.654-3 15/02/1993 Pedro Torres 700.000

10.143.245-6 01/03/1993 Ximena Kohl 900.000


• Cada línea corresponde a un registro de la entidad clientes, también llama-da fila. Por ejemplo, la línea correspondiente a Juan Pérez.

• Cada columna corresponde a un campo de la entidad clientes. También se le llama atributo. Por ejemplo: “Fecha de incorporación”.

• Todos los registros (líneas) de una entidad deben tener los mismos campos y cada campo debe tener un valor válido en todo momento. por ejemplo, no sería válido 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 característica de clave única ha sido uno de los pilares del modelamiento tradicional, aunque también ha sido fuente de muchas dificultades en el mode-lamiento y en la interacción con el usuario, debido a su poca naturalidad. Hoy, la orientación a objetos, algunas bases de datos y herramientas de productivi-dad, están transformándola poco a poco en sólo una característica opcional.

La entidad también puede representarse con un rectángulo, 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.

Figura 4-2. Representación gráfica de una entidad

En la figura 4-2 se puede apreciar que su clave es el RUT, que tiene una rela-ción propia por nombre del cliente y que el resto de los campos son fecha de incorporación y línea de crédito.

2. Relaciones propias (RP) Las relaciones propias son al interior de la tabla, cuando un campo se declara como una llave alterna y permite recorrerla. Las RP permiten diferentes acce-sos a los datos de una entidad, de tal forma que cualquier campo puede ser una relación propia o parte de ella. Por ejemplo, el nombre del cliente, la

Clientes

Nombre del cliente (RP)

Fecha de incorporaciónLínea de crédito

Rut

JUAN BRAVO C. 218

fecha de incorporación y la línea de crédito en el caso de la figura 4-2. Una relación propia puede contener dos o más campos; por ejemplo, fecha de in-corporación y nombre del cliente.

La única limitación en la definición de relaciones propias es la disponibilidad de mayores recursos de hardware, porque por cada relación propia el sistema administrador de bases de datos crea y mantiene nuevas tablas de índices.

Se podría decir que la RP corresponde a un ordenamiento permanentemente actualizado de los datos. Podemos declarar la relación propia por la cual que-remos acceder a la información: nombre, ciudad, teléfono, etc… y esa infor-mación estará siempre ordenada.

En una relación propia el contenido de los campos puede ser con o sin dupli-cado. En el primer caso los campos pueden repetirse y no sirve como una cla-ve identificatoria alternativa. En el segundo caso, puesto que el contenido de los campos no se repite, la relación propia puede ser usada como una llave alternativa.

La definición de relaciones propias, al igual que la identificación de claves, está dejándose de lado en la medida que nuevas herramientas de software permiten un manejo automatizado, apoyado por el equipamiento moderno cada vez más poderoso. Esto es un avance importante en simplificación que facilita la incorporación del usuario; por ejemplo, la figura 4-2 podría haber quedado de esta forma:

Solamente ese sería el esfuerzo si tuviéramos el apoyo automático para que el software se encargara de individualizar cada registro y suponer que cada cam-po es una relación propia.

3. Características estáticas y funcionales de campos Cada uno de los campos de una entidad incluye características estáticas y fun-cionales. En la figura 4-2, una característica estática es la fecha de incorpora-ción del cliente con la estructura dd/mm/aaaa, una característica funcional es validar que los valores posibles para el mes sean sólo entre 1 y 12.

RUTNombre del clienteFecha de incorporaciónLínea de crédito

RUTNombre del clienteFecha de incorporaciónLínea de crédito

Clientes


Las características estáticas son atributos fijos del campo, por ejemplo: nom-bre del campo, descripción, comentario, largo, tipo, signo, formato de desplie-gue, dígitos parte entera y decimales.

Las características funcionales son atributos dinámicos del campo, los cuales pueden ser implementados con estructuración de lógica en la forma de código reutilizable. Generalmente, son pequeñas funciones computacionales también denominadas triggers o reglas del negocio.

Algunos ejemplos de características funcionales son:

• Condiciones de validación, 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 código de producto hay que asegurarse que exista en el maestro de artículos. Al mis-mo tiempo debiera ser posible ver otros datos en la entidad de verificación, por ejemplo, desplegar la descripción del artículo.

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 múltiples formas de consulta y mani-pulación de datos. La lista de valores posibles es una característica del campo y no es necesa-rio definir una función. En la práctica, la mayoría de las bases de datos mo-dernas lo proveen como un parámetro más.

• Rutinas de cálculos especiales, como cálculo de dígito verificador y trans-formación de cantidades a letras.

• Procesos de actualización, se refiere a procedimientos que van a modificar el contenido de un campo al cumplirse alguna condición; por ejemplo, re-bajar el stock del producto cuando se produce una salida por ventas.

Tipos de campo

Prácticamente todas las herramientas proveen tipos de campo, a cada uno de ellos se asocian características estáticas y funcionales que pueden ser modifi-cadas; por ejemplo, algunos tipos de campo son:

• Numérico: largo 9, sin signo. • Alfanumérico: largo 45. • Fecha: largo de 8 dígitos: 2 para día, 2 para mes y 4 para año; con másca-

ras a elección: dd/mm/aaaa o mm/dd/aaaa; realizar aritmética de fechas: responder a ¿cuántos días hábiles del mes llevamos? sumar o restar un

JUAN BRAVO C. 220

mes; y efectuar las validaciones típicas: mes de 1 a 12, día de 1 a 28, 29, 30 ó 31, según mes y año.

• Campo con dígito verificador: 10 dígitos de largo, más un campo alfa-numérico para el dígito verificador; debiera aceptar diferentes módulos, máscaras y tablas de ponderadores.

• Período mensual: largo de cuatro dígitos: 2 para mes y 2 para año; diferen-tes máscaras y cálculo de meses de diferencia.

• Lista de valores: asocia una conexión a otra tabla donde se encuentra una lista de los valores posibles que puede tomar el campo, por ejemplo, ciuda-des o países.

La funcionalidad asociada a los tipos de campo viene aportada por la respecti-va herramienta, aunque lo habitual es que también sea posible aportar código.

4. Tipos de entidades Prácticamente en todos los casos del procesamiento de datos, es posible iden-tificar los siguientes tipos de entidades:

• Maestro: contiene la información permanente del sistema. Los datos de la entidad de maestro sólo deberían modificarse a través de transacciones. Al-gunos ejemplos de entidades de este tipo son: proveedores, clientes, artícu-los o empleados.

• Transacciones: son los conjuntos de datos que “transitan” por la organiza-ción y que afectarán las tablas maestras. Por ejemplo: ventas del día, com-pras del día y descuentos en sueldos.

• Temporales: se trata de una o varias tablas donde se guardan datos transito-rios extraídos de maestros, transacciones o de ambos. Puede ser directa-mente una copia de algunos de ellos. La entidad temporal se utiliza para or-denar y seleccionar datos o realizar cálculos. Generalmente se elimina des-pués de ser utilizada. También puede ser una vista parcial.

La relación entre maestros y transacciones da origen a una referencia cruzada, tal como vimos en el modelo orientado al flujo de transacciones de la sección anterior. Formalmente, la relación sería de este tipo:


Se puede apreciar que los maestros son los pilares que dan el soporte a la es-tructura y las transacciones la atraviesan horizontalmente, modificando los datos de cada maestro asociado a esas transacciones. Por ejemplo, la entidad de transacción 1 afecta a los maestros 1 y 2, la entidad de transacción 2 afecta a los maestros 1 y 3.

En cada nodo o punto de encuentro entre una entidad de transacción y una de maestro, es necesario realizar un proceso de actualización, generalmente a través de construir una función computacional atómica (tal como vimos en el capítulo 3).

Origen de las entidades

Se incluye la siguiente tipología como una forma de ayudar al diseñador en la identificación de entidades, por ejemplo:

• Elementos físicos: automóviles, fábricas, libros, edificios, línea blanca, vestuario, medios de transporte.

• Elementos lógicos: cuentas contables, venta histórica, cuentas corrientes. • Roles de personas: doctores, ingenieros, profesores, empleados, abogados,

dueñas de casa, sicólogos. • Roles de instituciones: clínicas, AFP´s, isapres, farmacias, casas de reposo,

empresas de diferente tipo. • Roles mixtos, personas u organizaciones: contribuyentes, clientes, provee-

dores, asociados. • Transacciones: eventos que provocan cambios en otros objetos, compras,

ventas, accidentes, vuelos, depósitos, giros, ajustes. • Interacciones: generalmente dan origen a una entidad asociativa: costos

entre proveedores y artículos, licencias entre drogas y laboratorios, ventas entre vendedores y clientes.

No son distinciones rígidas, porque pueden haber múltiples situaciones inter-medias y otras clasificaciones.

Una característica común es que aparecen más de una vez en la situación que se está estudiando para modelar.

T1

T2

M1 M2 M3

Mi = Maestro; Ti = Transacción

T1

T2

M1 M2 M3


JUAN BRAVO C. 222

5. Relaciones entre entidades Son relaciones donde se comunican dos entidades, lo que da origen a una ma-lla que es llamada modelo de datos, de esta forma:

En esta figura se utilizó el esquema de notación 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 artículos. Un artícu-lo puede estar entre 0 y n facturas.

En lo que sigue, veremos los cuatro tipos básicos de relaciones: 1:1, 1:N y N:M y N:M especial, también comentaremos sobre la relación de pertenencia y las relaciones de uso.

1) Relación 1:1

Por ejemplo, un cliente puede tener sólo un crédito autorizado o ninguno. Un crédito autorizado pertenece a sólo un cliente.

2) Relación 1:N

Es una relación de uno a muchos. Las formas más habituales de representa-ción de una relación 1:N se muestran con el ejemplo de clientes y facturas de venta. En esta relación, un cliente puede tener desde cero a varias facturas y una factura puede tener solamente un cliente.

Clientes Facturas Artículos1 0,n1,100,n

Clientes Crédito10,1

Clientes FacturasClientes Facturas

Clientes Facturas10,m

Clientes

Facturas


Relación de pertenencia

Un caso especial de la relación uno a muchos es la relación de pertenencia. Aquí la entidad dominante es llamada Padre y la entidad dependiente se de-nomina Hijo. En este tipo de jerarquía deberían 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 más otro, u otros campos, identificadores de la entidad hijo. Sería el caso de la relación PROVEEDORES → FACTURAS, donde necesariamente la entidad hijo debe tener como clave el RUT del proveedor y el número de factura, para evitar confun-dir las facturas de diferentes proveedores.

3) Relación N:M

También llamada tipo red (muchos a muchos).

Las formas más habituales de representación gráfica de una red se muestran en la siguiente figura. Como ejemplo, se utilizó la relación existente entre las entidades proveedores y artículos. En este caso, un proveedor abastece mu-chos artículos y un artículo es provisto por muchos proveedores.

A diferencia de la jerarquía, en la red la relación es independiente de los datos de las entidades. Esto significa que no hay pertenencia entre entidades y que los respectivos campos de relación podrían no ser parte de las entidades; por ejemplo, los artículos ofrecidos por el proveedor.

Proveedores

Artículos

Proveedores

Artículos

Proveedores Artículos

Proveedores Artículos0,m0,m

Proveedores

Artículos

Proveedores

Artículos

Proveedores Artículos

Proveedores Artículos0,m0,m

JUAN BRAVO C. 224

Se puede comprender mejor la independencia entre relación y entidad con un sencillo ejemplo: las entidades alumnos ↔ profesores incluyen los datos per-sonales de los alumnos y de profesores, respectivamente; sin embargo, sólo en la relación se encuentra la información de alumnos por profesor y profesores por alumno.

La implementación de la relación tipo red es bastante compleja, porque cada operación sobre una entidad significa actualizar los índices de acceso y resol-ver los serios problemas de consistencia de los datos, aunque actualmente esta facilidad viene provista automáticamente por los sistemas administradores de bases de datos.

La descomposición lógica de una red significa construir una doble jerarquía, implementada mediante dos nuevas entidades, hijas de las entidades origina-les. Cada una es un índice que apunta a la otra entidad, tal como en la siguien-te figura con las entidades A y B.

Si el recurso es sólo un sistema administrador de bases de datos jerárquico igual se puede implementar una red de esta forma, aunque cuidando la consis-tencia de la base, porque es fácil realizar alguna operación —por ejemplo de eliminación de un registro— y dejar alguna tabla de índices sin actualizar.

Algunas convenciones típicas de la implementación de la relación muchos a muchos son:

• Al agregar un ítem en la relación, previo deben existir ambos “padres”. • Al eliminar un padre, se eliminan primero los elementos de la relación.

En general, por simplicidad del modelo y mejora del tiempo de respuesta, se considera apropiado dejar sólo las relaciones N:M que sean indispensables. Por ejemplo, la relación entre clientes y avales es muchos a muchos. Un cliente puede tener más de un aval y un aval puede avalar a varios clientes; sin em-bargo, en algunas instituciones financieras, la norma es que un aval sólo puede avalar a un cliente, aunque un cliente puede tener varios avales. Por lo tanto, la relación cambió a “uno a muchos” y se “resolvió” una relación N:M.

=

A A

Índice A/B

B

Índice B/AB

=

A A

Índice A/B

B

Índice B/AB


4) Relación N:M especial

La relación N:M típica no permite manejar información propia de la interac-ción; por ejemplo, en la relación: proveedores ↔ artículos, el precio de los artículos según cada proveedor. Para resolver este problema, la relación puede tomar la siguiente forma:

Donde se establece un nodo en el arco de la relación, la que a su vez se trans-forma en una entidad asociativa en la cual se puede almacenar mayor infor-mación, por ejemplo, el costo del artículo entre diferentes proveedores.

Esta entidad asociativa es indispensable en el esquema relacional, donde las diferentes tablas deben contener los campos a través de los cuales se manipu-larán los datos.

A esta relación también se le denomina NUB natural porque tiene “vida pro-pia”, es decir, aparece en el modelo conceptual (modelo que ve la realidad del usuario) y tiene un identificador. También existe el NUB artificial, creado sólo para evitar la relación N:M mediante una doble jerarquía, no los ve el usuario en el modelo conceptual ni tienen identificador propio.

La entidad asociativa también puede estar relacionada con una sola entidad, como en el siguiente ejemplo, donde la entidad parentesco tendría los siguien-tes atributos (persona, persona, parentesco).

Por simplicidad del modelo, se recomienda estudiar la real necesidad de esta-blecer nodos con información adicional en relaciones N:M.

Relaciones de uso

Las relaciones de uso son independientes de las entidades, porque no es nece-sario que su estructura contenga la relación, como en la pertenencia. A veces, para efectos de implementación, es necesario crear entidades asociativas, co-mo en el caso del NUB natural o artificial.

Proveedores ArtículosCostoProveedores ArtículosCosto

Personas ParentescoPersonas Parentesco

JUAN BRAVO C. 226

Las relaciones de uso pueden tomar cualquiera de las siguientes formas:

• Relación uno a uno. • Relación uno a muchos, a excepción de la relación de pertenencia. • Relación muchos a muchos, más conocida como tipo red.


4.2. CRITERIOS BÁSICOS DE NORMALIZACIÓN DE

DATOS

Se presenta un esquema de normalización del modelo de datos, basado en dos criterios: eliminación de grupos repetitivos y eliminación de dependencias parciales. Ambos fáciles de entender y aplicar, así aumenta la posibilidad de aplicación por parte de especialistas y usuarios.

Aunque, un esquema completo de normalización es el que propone el Dr. E. F. Codd, con sus formas normales y variaciones sobre ellas. Los dos criterios de este capítulo son una simplificación que permite un acercamiento prelimi-nar y equivalen hasta la tercera forma normal.

¿Por qué normalizar?

Porque presenta variados beneficios, por ejemplo:

• Lograr definir entidades atómicas, tiene la ventaja de trabajar con un con-junto de datos uniforme, sujetos a la misma clave, esto simplifica el mode-lo y da la posibilidad de aplicar funciones normalizadas.

• Evitar la redundancia de datos, lo cual, además de ordenar y economizar recursos, ayuda a mantener la integridad, porque cada dato existe sólo una vez en el sistema, ¿si no fuera así? ¿A cuáles de las versiones de un dato le cree el usuario?

• Normalizar el almacenamiento de datos, no sólo al interior de la organiza-ción, sino también al exterior. De esta manera se economiza en preparación de especialistas y es posible aplicar herramientas uniformes, como los sis-temas administradores de bases de datos relacionales y las diferentes herramientas de productividad, para automatizar múltiples funciones: con-sulta de información, integridad, privacidad, recuperación, ingreso de da-tos, informes y muchas otras.

• Aplicar herramientas de apoyo en el modelamiento, todas las cuales ayu-dan y hacen exigible la normalización de los datos. Por ejemplo, algunas herramientas de apoyo en el modelamiento de datos son: ERWIN y System Architect.

JUAN BRAVO C. 228

Evitar los tipos de registros

Uno de los principales elementos que confabula contra la normalización de los datos, es incluir tipos de registros; por ejemplo: una tabla de transacciones con tipo de dato 1 para ventas y 2 para compras, lo cual presenta varios incon-venientes:

• Probablemente existirán 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 difícil de entender.

• Como la entidad no es uniforme, es difícil aplicarle funciones automáticas; en consecuencia, los programas que manipulan estas entidades son complejos y extensos.

Veremos: 1. Eliminación de grupos repetitivos 2. Eliminación de dependencias parciales 3. Tabla de traducción

1. Eliminación 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, más un identi-ficador de cada ocurrencia del grupo repetitivo; puede ser un número correla-tivo o alguno de los campos del grupo repetitivo.

El ejemplo de la figura 4-3 corresponde a la eliminación de un grupo repetiti-vo incorporando un número correlativo externo en una factura de venta.

Figura 4-3. Eliminación de grupo repetitivo usando número correlativo externo

En este caso:

Clave

Nº facturaFecha

Clave

Nº facturaNº ítemCódigo Cantidad Precio

Rutdel

cliente

Clave

Nº facturaFecha

Código Cantidad Precio …Ítem 10

Grupo repetitivoÍtem 1

Código Cantidad Precio

A Entidad no normalizada

Entidades normalizadasB Encabezado C detalle

Rutdel

cliente


• La factura de la entidad A tiene los campos: # factura, fecha, RUT y 10 artículos, cada uno con código, cantidad y precio. La normalización de esta entidad dio como resultado la creación 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, código de artículo, cantidad y precio. Se agregó el número de ítem a la clave de la en-tidad de detalle, equivalente a un número de línea en la factura, porque en la factura podría repetirse un artículo, lo cual inhabilitaría al código para ser parte de la clave.

El uso del número 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 código del artículo, aun cuando éste no se repitiera, es posible que se pierda el orden de ingreso, porque es poco probable que el código se anota-ra en orden ascendente en el documento.

• Es más uniforme y ordenado.

• Se le da flexibilidad al modelo, porque se podría repetir un código sin afec-tar la integridad del documento; por ejemplo, en el caso de una factura se podría anotar dos veces un mismo producto, tal vez porque el cliente re-cordó al final del pedido que requería mayor cantidad del primer producto solicitado.

En el ejemplo de la figura 4-4 vemos la eliminación de un grupo repetitivo usando un campo de la entidad origen (la misma de la figura 4-3), para este ejemplo, el código de artículo de la factura de venta.

Figura 4-4. Eliminación de grupo repetitivo usando campo interno

Clave

Nº facturaFecha

Rutdel

cliente

Clave

Nº facturaCódigoCantidad Precio

Clave

Nº facturaFecha

Rutdel

cliente

Clave

Nº facturaCódigoCantidad Precio

Entidades normalizadasB Encabezado C detalle

JUAN BRAVO C. 230

Al usar el código podemos apreciar que:

• La eliminación del grupo repetitivo de la entidad A dio origen a una enti-dad (C) de detalle, con los campos: # factura, código de artículo, cantidad y precio. En este caso, suponemos que el código de artículo 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 más habitual de resolver un grupo repetitivo.

Prácticamente en todos los casos, la eliminación de un grupo repetitivo da origen a una relación de pertenencia entre las entidades de encabezado y deta-lle que se obtuvieron del proceso de normalización. Gráficamente, el resultado se ve así:

2. Eliminación de dependencias parciales El término dependencia parcial se aplica a campos que dependen sólo de una parte de la clave o bien de un campo que no es parte de la clave. Por lo tanto, una dependencia válida se da cuando el campo depende de toda la clave.

Generalmente, la eliminación de las dependencias parciales significa llevar los campos parcialmente dependientes a una tabla de traducción (T/T) o aplicar una condición 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 eliminación de la dependencia parcial da origen a una relación 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 relación de uso entre las entidades.

B

C

B

C


Figura 4-5. Ejemplo de eliminación de dependencias parciales

En la figura 4-5 se aprecia que la entidad A tiene dos campos que no son de-pendientes de toda la clave:

• Descripción del estado: es la traducción del código de estado en la sucur-sal, un campo no clave. La forma que toma la descripción es, por ejemplo: 1=terminado, 2=semiterminado.

La tabla de traducción que da respuesta a esta dependencia parcial podría 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 traducción.

• Nombre del artículo: dependiente del código del producto, un campo clave.

¿Cómo se resuelven estas dos dependencias parciales de la entidad A?

En el primer caso, como se trata simplemente de la traducción de un código (código de estado versus descripción de estado), se le asigna una tabla de tra-ducción identificada con el número 18 en el ejemplo. También estaría correcto definir una nueva entidad, la cual nacería con el código y la descripción del

Código deproducto

C/E

C Nueva entidad

Clave

Sucursal Código deproducto

StockCódigo

deestado

Descripción del estado

Nombre de

producto

Clave


Stock Código deestado


T/T 18 T/T 18

Clave Nombre de

producto


Entidades normalizadas

B Entidad original normalizada Tabla de Traducción (T/T)

Código deproducto

C/E

C Nueva entidad

Clave


StockCódigo

deestado


Nombre de

producto

Clave


Stock Código deestado


T/T 18 T/T 18

Clave Nombre de

producto


Entidades normalizadas

B Entidad original normalizada Tabla de Traducción (T/T)

JUAN BRAVO C. 232

estado, aunque sería muy elemental y estorbaría en el modelo de datos porque no sería la única y entonces existirían muchas tablas pequeñas61.

En el segundo caso, respecto al código y nombre del artículo, formando una nueva entidad (C) con: código del artículo y nombre del artículo. Sobre esta nueva entidad, llamada entidad de existencia, se aplica la condición de exis-tencia a través de relacionar el código del artículo de la entidad B con la clave de la entidad C.

Se intercalaron puntos suspensivos en la entidad C para destacar que es posi-ble agregarle otros campos; por ejemplo: stock mínimo y costo del artículo, aun cuando no estaban incluidos en la entidad A; esto porque el modelamiento es una actividad plenamente retroalimentada, es decir, se van haciendo perfec-cionamientos sucesivos hasta dar por terminado el modelo y después… igual se sigue perfeccionando. También podría haberse utilizado una entidad pre-existente para formar la condición de existencia.

La entidad B es lo que quedó de la entidad A después de la normalización.

A veces es preferible aplicar una condición de existencia antes que una tabla de traducción, observando señales como éstas:

• Existe más de un campo asociado a la clave de la entidad de existencia; por ejemplo, además del código y nombre de moneda, el país de origen y la conversión a dólares. Es más que la simple dupla código-traducción.

• La entidad de existencia tiene muchos registros. • Algunos campos de la entidad de existencia tienen alta volatilidad, tal co-

mo un saldo de mercaderías o la renta de un empleado. • La entidad de existencia es un maestro típico (clientes, artículos, emplea-

dos, proveedores) el cual, probablemente, también tiene uso desde otras aplicaciones.

No obstante, las facilidades de la herramienta y la experiencia del diseñador serán decisivas.

61 De aquí surge la necesidad de tener agrupadas en un sólo lugar todas las traducciones sim-ples, papel que cumple la tabla de traducción. Ésta representa una forma de simplificar el modelo porque tan sólo se asigna un número para luego hacer una traducción automática con apoyo de una herramienta, la mayoría de las cuales provee esta facilidad. En el siguiente pun-to tratamos este tema.


3. Tabla de traducción La tabla de traducción (T/T) se aplica sobre un campo que requiere traducción automática de un código a un texto. Por ejemplo, el campo código de comuna tiene asociada una tabla de traducción con el siguiente contenido:

1 = Santiago Centro 2 = Las Condes 3 = Pudahuel

La tabla de traducción es una tabla más en el modelo de datos, el cual contiene todas las traducciones de códigos.

También se define el atributo traducción de código, el cual, dentro de una entidad desnormalizada, recibe una traducción de código desde una tabla de traducción. Por ejemplo: el nombre traducido de comunas: Santiago Centro, Las Condes, Pudahuel, La Florida.

El uso de la tabla de traducción lleva implícita una validación de existencia y para efectos de implementación, 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 través de tomar directamente desde una ventana el texto correspondiente; por ejemplo: Santiago Centro, Las Condes. Esta natura-lidad y simplicidad es de mucho mayor beneficio que el eventual costo de usar un poco más de espacio en disco.

La base de la tabla de traducción63 lo constituye una tabla de códigos (A) con la siguiente estructura:

A (número de tabla, código de ítem, texto a traducir, otros campos).

Por ejemplo, con el contenido de la siguiente tabla.

El código 99 se usa aquí para los títulos de las mismas tablas.

62 El efecto scrolling permite moverse en una tabla desde una ventana en la pantalla del equi-po. Hacia adelante, atrás, 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 solución es que el software provea también búsqueda por diferen-tes conceptos: índices, palabras claves, fonética, etc… 63 Algunos programadores preguntan: ¿cómo se construye manualmente una tabla de traduc-ción? Respondiendo a su pregunta es que se incluye la técnica. Además, le puede ser útil a otras personas. El autor usó este esquema desde fines de los setenta con bastante éxito.

JUAN BRAVO C. 234

La tabla, más un programa simple de mantención, diversos informes y un formato predefinido para usar la tabla desde múltiples aplicaciones, hacen muy fácil la mantención de los códigos de la instalación.

Cabe destacar que con la introducción de la lista de valores posibles como una característica más del campo y manejada en forma automática con herramien-tas de productividad, la tabla de traducción tiende a desaparecer.

Número de tabla

Código de ítem

Te xto atraducir

1 1 Santiago1 2 Valparaíso1 3 Viña del Mar1 4 Quilpué2 1 azul2 2 rojo2 3 verde… … …99 1 Ciudades99 2 Colores

Número de tabla

Código de ítem

Te xto atraducir

1 1 Santiago1 2 Valparaíso1 3 Viña del Mar1 4 Quilpué2 1 azul2 2 rojo2 3 verde… … …99 1 Ciudades99 2 Colores


4.3. ENFOQUE DE BASES DE DATOS

Se incluye esta sección debido a las referencias que se hacen en el texto a ma-terias propias del enfoque de bases de datos, un tema más especializado y di-rectamente relacionado con el modelamiento de datos.

Veremos: 1. Arquitectura de sistemas de bases de datos 2. Estructura relacional 3. Visión 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.

Figura 4-6. Arquitectura de bases de datos

Hay tres niveles de modelamiento de bases de datos:

• Interno: se refiere a los métodos 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 información. Por ejemplo: los colaboradores con sus car-gas, instituciones previsionales, proyectos en los cuales trabaja, renta o de-partamento donde labora.

• Externo: también llamado vista, son subconjuntos del modelo conceptual que prepara el administrador del sistema para los usuarios que lo soliciten. Es como una “ventana” del modelo conceptual; por ejemplo, tal vez requie-ra preparar al usuario del departamento de personas una “vista” con: nom-bre del empleado, proyectos en que labora y departamento al cual pertene-ce, sin incluir la renta ni el número de cargas.

Métodos de acceso a los

archivos físicos

Modelo de datos completo de labase de datos

Visión deUsuario A

Visión deUsuario B

Nivel interno Nivel conceptual Nivel externo

JUAN BRAVO C. 236

Las estructuras de bases de datos son tres: jerárquica, redes y relacional.

• Estructura jerárquica: esta estructura representa una relación uno a mu-chos. Como un padre con sus hijos o un cliente con sus ventas. A veces, con la estructura jerárquica es posible simular relaciones de muchos a mu-chos a través de crear una nueva relación (por ejemplo: ventas-artículos y artículos-ventas) o siguiendo las instrucciones de la herramienta particular.

• Estructura de red: esta estructura representa una relación de muchos a mu-chos. Por ejemplo, entre facturas y artículos, porque pueden haber varios artículos en una factura y un artículo puede estar presente en muchas factu-ras. Esto es conceptualmente equivalente a tener dos jerarquías: ventas-artículos y artículos-ventas. Para su implementación, 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 artículo en una relación proveedores–artículos.

• Estructura relacional: en 1970, trabajando para IBM , el doctor Edgar F. Codd publicó el artículo “A relational model of data for large shared data banks” (Un modelo de datos relacional para grandes bancos de datos com-partidos ) que dio inicio a esta novedosa forma de describir los datos y sus relaciones. Desde entonces, el Dr. Codd ha sido considerado el “padre” del esquema relacional, el cual consiste en una visión natural de los datos con un estilo tabular de anotación, lo cual facilita la participación del usuario, quien da su descripción de la información que maneja.

Entonces, el nivel interno podría organizarse según una estructura de redes y los niveles conceptual y externo según el esquema relacional. Se aprecia que cada nivel utiliza la estructura más apropiada a sus fines.

En consideración a la importancia de la estructura relacional, en el siguiente punto profundizamos en sus principios.

2. Estructura relacional Las estructuras jerárquicas y redes permiten resolver los problemas más im-portantes de las bases de datos: redundancia, integración de datos e indepen-dencia de los datos versus las aplicaciones; sin embargo, queda un sabor algo amargo cuando se aplican estas estructuras no lineales, porque se extrañan las simples tablas planas, aquellas entidades individuales, aisladas, sin normaliza-ción y en muchos casos redundantes. Tal vez el ideal sería tener las posibili-dades de las bases de datos no relacionales pero con la simplicidad de los ar-chivos lineales. Esto es lo que se trata de lograr con la estructura relacional.


En el enfoque relacional, tal como su nombre lo indica, se “relacionan” algu-nas tablas con otras en base a campos presentes en las mismas tablas. Esto significa, entre otras cosas, que la relación muchos a muchos no se acepta en forma directa, por lo que debe ser resuelta a través de tablas intermedias.

Algunas denominaciones usadas en el enfoque relacional son:

• Relación o tabla : equivalente a entidad o archivo. • Tupla : equivalente a registro. • Atributo : equivalente a campo. • Dominio : conjunto de datos de un atributo.

En el enfoque relacional se aplican las formas normales propuestas por el Dr. Codd, siendo generalmente aceptado que la mayor parte del modelamiento de datos se resuelve con el uso de las tres primeras de ellas.

El esquema relacional predomina actualmente en el ambiente de bases de da-tos porque tiene una sólida base conceptual y teórica, con muchos elementos extraídos de la teoría de conjuntos y del álgebra relacional, especialmente las operaciones destinadas a la consulta de datos: selección, proyección, unión, intersección y otras.

De aquí deriva el conocido esquema Entidad-Relación —ER—. En éste no hay tablas de índices que enlacen las tablas porque siempre los datos que requiere la relación están presentes en las tablas. Por este motivo se usa la entidad aso-ciativa cuando hay relaciones muchos a muchos.

Especial mención merece la extracción de datos desde una relación. La idea es que con los comandos que provee el sistema administrador de la base de datos sea posible extraer datos desde una o varias tablas; en forma horizontal, verti-cal o en una combinación de ambas.

Por ejemplo, en una relación con los atributos: número de factura, fecha y nombre de proveedor se pueden realizar operaciones como estas:

• Extracción horizontal, consiste en seleccionar una tupla; por ejemplo, la factura 1518 del 10/01/95 de LINHOGAR LTDA.

• Extracción vertical, significa obtener, por ejemplo, todos los nombres de los proveedores.

• Una combinación podría ser: extraer las tuplas con número de factura del 1.000 al 2.000 de los proveedores ubicados en la ciudad de Santiago —en este caso, la herramienta debería buscar en dos tablas—.

Actualmente, éstas y muchas otras consultas bastante más refinadas, se efect-úan principalmente con productos tipo SQL (Structured Query Language).

JUAN BRAVO C. 238

3. Visión de bases de datos La visión de bases de datos se origina en la necesidad de administrar los datos de manera uniforme y como un recurso más de la organización. De aquí sur-gen las principales características del enfoque de bases de datos:

• Manejo de la redundancia: significa que cada dato, por ejemplo el nombre y el saldo de crédito del señor Pérez, se incorpora al modelo conceptual y queda almacenado una sola vez en las bases de datos. ¿Le creería usted al sistema si el saldo de crédito del Sr. Pérez aparece en dos lugares a la vez y con diferente contenido? Puede existir la redundancia controlada, es decir, copias de datos para algún uso específico, que son borrados cuando cum-plieron su misión. La eliminación de la redundancia es una de las principa-les razones para realizar el proceso de normalización de datos, presentado en el capítulo tercero.

• Integridad referencial: significa que cada dato de la base está siempre con-sistente. El término se aplica cuando algunos datos son consecuencia, re-sultado o están relacionados con otros, como una sumatoria o la manten-ción de un índice de un dato original. Algunos ejemplos:

◊ Modificar automáticamente el campo “total neto de la factura” cada vez que varíe un ítem de la factura.

◊ Validar la existencia del producto cuando se incluye en una factura. ◊ Readecuar automáticamente el modelo de datos después de agregar

o eliminar campos.

• Protección de la información: se refiere a los conceptos de seguridad, inte-gridad y recuperación, tratados en el capítulo 2. Veamos un resumen:

◊ Seguridad: incluye la privacidad de datos, el análisis de procedi-mientos y errores en el diseño.

◊ Integridad: es asegurar la consistencia de los datos en todo momen-to y protegerlos contra invalidaciones accidentales o deliberadas.

◊ Recuperación: son las precauciones a tomar frente a “caídas” del sistema, básicamente en lo que se refiere a reiniciación, reconstruc-ción y respaldos.

• Auditoría: el software debería permitir efectuar totalizaciones, cuadraturas, referencias cruzadas y otros procesos destinados a apoyar puntos de control y eventuales revisiones, además de proveer los mecanismos para seguir la ruta de auditoría. Ésta consiste en reconstruir la secuencia de transacciones


que afectaron a un determinado dato, generalmente a través de una bitácora de procesos.

• Concurrencia: el sistema administrador de bases de datos debe incluir el manejo de colisiones en una aplicación con múltiples usuarios, situación que se produce cuando dos o más usuarios intentan actualizar simultánea-mente el mismo registro. Son varias las soluciones para este tipo de pro-blemas; por ejemplo, el que toma primero el registro deja al otro esperando hasta que lo actualiza.

• Independencia de datos: es clásica la característica de independencia entre datos y aplicaciones. Significa separar el almacenamiento de los datos de las características de una aplicación particular. Un ejemplo elemental de pérdida de independencia, válido incluso en ambientes sin base de datos, es cuando se incorporan en un programa tablas con datos que sólo 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 código que actúa 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 huésped, tipo COBOL o C. Desde éstos se puede usar el conjunto de instrucciones de manipulación de datos propios del sistema administrador de la base de da-tos o de la norma SQL.

La idea es que los datos pertenecen a toda la organización y no a una apli-cación particular. Bajo este concepto, una aplicación no modifica directa-mente los datos, sino que lo hace un intermediario común a todas las apli-caciones: el sistema administrador de la base de datos a través de los me-canismos que tenga disponibles.

• Normalización del almacenamiento: significa que el almacenamiento y la selección de los datos de la organización siguen las mismas pautas; por ejemplo, para:

◊ Definición: tipo de campo, largo, descripción, etc. ◊ Documentación: en informes o ayudas en línea. ◊ Estructurar los campos de las entidades de manera uniforme: por

ejemplo, aplicando hasta la tercera forma normal del modelo del Dr. Codd o la normalización simplificada de este texto.

Así se obtiene una mínima repetición de definiciones. Además, con la normalización del almacenamiento podemos aplicar funciones genéricas

JUAN BRAVO C. 240

sobre los datos, para consulta, ingreso, modificación, eliminación 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 aplicación se re-quiere ubicar información que está en bases de datos ubicadas en diferentes equipos.

• Manejo de Bases de Datos remotas: significa manejar datos que se encuen-tran en bases muy distantes. Esta característica es cada vez más indispensa-ble y tiene varias consecuencias: implica resolver el problema de la comu-nicación remota y conocer el mundo de los satélites, controladores o líneas 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 inglés 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 definición de datos. DML = Data Manipulation Language. Lenguaje de manipulación de datos. SQL = Structured Query Languaje. Lenguaje de consultas estructuradas.

Figura 4-7. Enfoque de bases de datos

DBA

DBMS

DBDBDB

DD

LenguajesDDLDMLSQL

DBA

DBMS

DBDBDB

DD

LenguajesDDLDMLSQL


A continuación veremos cada uno de lo elementos de este enfoque.

• Administrador de la Base de Datos. Data Base Administrator (DBA), co-rresponde a una función administrativa encargada, entre otras, de las si-guientes actividades:

◊ Diseñar la base de datos ◊ Definir los metadatos (atributos estáticos y funcionales de datos) ◊ Proteger la base de datos

En suma, de todas las actividades tendientes a optimizar el uso del recurso información.

Esta función puede ser desempeñada 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 múltiples funciones, por ejemplo:

◊ Manejar la integridad, privacidad y recuperación ◊ Accesar los datos ◊ Mantener los índices y el diccionario de datos ◊ Proveer funcionalidad básica a los conjuntos de datos

Para cumplir con su función se relaciona con el usuario a través de los dife-rentes lenguajes que provee.

• Diccionario de Datos. Data Dictionary (DD), es un archivo reservado del SABD donde se almacenan las características de los datos, o los metadatos de la organización. Por ejemplo, por cada campo se archiva: nombre, des-cripción, tipo de dato, largo, condiciones de validación, ayudas en línea o documentación. En el DD también se graban las relaciones entre los datos.

El diccionario de datos evoluciona hacia el diccionario de conocimientos, también llamado enciclopedia o repositorio. En éste, además de almacenar-se las características de los datos y sus relaciones, también se agregan ca-racterísticas lógicas, formatos predefinidos, código reutilizable y en espe-cial, reglas de ejecución, las que se activan al momento de producirse un error o al cumplirse alguna condición; por ejemplo, generar una orden de reposición cuando el stock de un producto llegue a su nivel mínimo.

• Bases de Datos. Data Base (DB), es el conjunto de tablas (archivos físicos) donde se almacenan los datos de la organización. Sólo puede ser accesado según los métodos del SABD.

JUAN BRAVO C. 242

• 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 explícitamente estos tres:

◊ Lenguaje de definición de datos: Data Definition Language (DDL), permite mantener las definiciones y estructuras de datos almacena-das en el diccionario de datos.

◊ Lenguaje de manipulación de datos: Data Manipulation Language (DML) , utilizado para actualizar los datos de la base: agregando, mo-dificando o eliminando registros.

◊ Lenguaje de consulta: Query Language, permite realizar consultas sobre la base de datos, por ejemplo, las ventas del cliente Juan Pérez o los artículos más vendidos en el último mes. A través de es-te lenguaje se puede hacer un recorrido o una navegación automá-tica dentro de la base de datos, siguiendo camino de las relaciones predefinidas para dar respuesta al requerimiento. Cuando se trabaja con bases de datos relacionales, se usa el principalmente el lenguaje SQL —Structured Query Languaje— basado en el álgebra y cálculo relacional propuestos por el doctor Codd.

Es importante la armonía entre buenas herramientas —por ejemplo, para ad-ministrar bases de datos, desarrollar sistemas computacionales o consultar datos— y todos los demás factores de productividad: método, incorporación del usuario, excelente preparación del profesional de informática, métodos de trabajo normalizados, hardware adecuado, normalización externa y los facto-res de contexto: colaboración o ambiente físico.

Sólo el desarrollo equilibrado del conjunto de factores —más que el avance espectacular en alguno de ellos— permitirá lograr los objetivos de productivi-dad que las organizaciones requieren.

JUAN BRAVO C. 244

Capítulo 5. Orientación a objetos

En los últimos años, el desarrollo más significativo en ingeniería del software ha sido la aparición de UML como estándar para la

descripción de sistemas orientados a objetos, y el desarrollo de métodos ágiles como la programación extrema.

Sommerville (2005, p. xiv)

La orientación a objetos (OO) provee una forma simple y natural para crear los modelos de la solución de software. Los objetivos que se pretenden lograr son ambiciosos: aumentar la productividad, mejorar la calidad, facilitar la mantención, incorporar al usuario, reducir los riesgos y reutilizar el trabajo previo, entre otros. Cabe destacar dos características: la mayor naturalidad y el aporte a los contenidos a través de una biblioteca de clases que se va perfec-cionando en el tiempo.

Esta es la quinta competencia considerada para apoyar la elaboración de modelos de una solución de software, tal como se aprecia en la siguiente fi-gura (en la introducción se incluyó la visión global de las competencias). Es necesario que el analista sea muy hábil en la orientación a objetos como par-te de su responsabilidad profesional, porque es una competencia central de su labor que tiene un impacto mucho más allá de las etapas de análisis y diseño, tiene que ver con la visión de trabajar con integración y componentes.

Con la orientación a objetos es posible que la solución de un desarrollador sea comprendida más fácilmente por otros, obteniéndose mayor independencia del modelo respecto a su creador; así, la empresa usuaria se beneficia doblemente,






CAPÍTULO 6. UML




porque no se repiten soluciones a los mismos problemas y porque hay una inversión en inteligencia al ser posible que nuevos especialistas aprovechen todo o parte del avance de sus predecesores, más aun cuando el diseño queda registrado en alguna herramienta de apoyo para esta etapa.

En este libro se aborda la orientación a objetos desde el punto de vista del desarrollo de las aplicaciones computacionales que apoyarán el negocio de la organización.

Veremos: • Fundamentos de la orientación a objetos • Definiciones sobre orientación a objetos • Conceptos de la orientación a objetos • Proceso de generalización • Fases de la orientación a objetos • Incorporación de la tecnología de objetos

JUAN BRAVO C. 246

5.1. FUNDAMENTOS DE LA ORIENTACIÓN A OBJETOS

La Orientación a Objetos (OO) es un hito fundamental en el proceso de desa-rrollo de la computación que comenzó en los mismos años de la Segunda Guerra Mundial con el advenimiento de los primeros computadores en Ale-mania y Estados Unidos.

El objetivo de esta evolución histórica ha sido el aumento de productividad. Lo cual se logra en esta técnica mediante tres formas principales:

• Evitando la redundancia en la construcción de código • Reutilizando estructuras y código • Aplicando visión sistémica (visión de conjunto y autonomía)

Al principio de la informática, las aplicaciones prácticamente no tenían diseño y luego surgieron diversas formas más bien locales y artesanales. En los años 60 surgió lo que conocemos como diseño físico o esquema tradicional de di-seño. Hacia fines de esa década ya existían algunas formas de diseño estructu-rado y otras que enfatizan el enfoque de base de datos. La aparición de la orientación a objetos en los años 80 hereda esos avances previos.

En un artículo en Revista Informática de principios de los 90, Reutilización, el sueño de la ingeniería de software, José Piquer, académico del Departamento de Ciencias de la Computación, Escuela de Ingeniería de la Universidad de Chile, ya aconseja a los ingenieros en computación que comiencen a estudiar la orientación a objetos. Señala que la programación orientada a objetos, prin-cipalmente vía SmallTalk, “nos comienza a proveer con algunas herramien-tas buscadas por largo tiempo: las bibliotecas de clases. ¿Cuántas veces uno implementa la misma función de búsqueda, sólo porque el tipo de datos cam-bia?” . Agrega: “cada vez aparecen más bibliotecas comerciales de clases dedicadas a algunos temas como optimización o diseño de interfaces”…

Al margen de formas artesanales de diseño y de las técnicas centradas sola-mente en los datos, el principal método que dominó desde los años 60 es el diseño 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 década de los noventa él promovió… la orientación a objetos, mante-niendo sólo un “diseño estructurado mejorado” para quienes conservaban esa tecnología en sus instalaciones o se incorporaban tardíamente.


La orientación a objetos es muy amplia y permite modelar realidades de dife-rente índole, como textos, imágenes, voces, figuras geométricas y mucho más.

Cabe indicar que la programación orientada al objeto fue la precursora de los conceptos de OO a través de lenguajes tales como C++, SMALLTALK y SIMULA.

Veremos: 1. Mayor eficiencia 2. Visión de los datos 3. Visión histórica funcional 4. La orientación a objetos 5. Incorporación de nuevas tecnologías

1. Mayor eficiencia Una fuerte justificación de la orientación a objetos es su mayor eficiencia. De hecho, la cantidad potencial de funciones es n² en el esquema estructurado y n en la orientación a objetos, tal como vemos en la figura 5-1.

Figura 5-1. Interacciones entre objetos

T1

M1

M2

M3

T2

M1

M2

M3

T3

M1

M2

M3

Operación 10

Operación 11

Operación 12

Operación 10

Operación 11

Operación 12

Operación 10

Operación 11

Operación 12


Operación 10

M1

Objetos3 funciones (n)

Mensaje 10

Operación 11

M2

Mensaje 11

Operación 12

M3

Mensaje 12

Esquema estructurado9 funciones (n2)

T1

M1

M2

M3

T2

M1

M2

M3

T3

M1

M2

M3

Operación 10

Operación 11

Operación 12

Operación 10

Operación 11

Operación 12

Operación 10

Operación 11

Operación 12


Operación 10

M1

Objetos3 funciones (n)

Mensaje 10

Operación 11

M2

Mensaje 11

Operación 12

M3

Mensaje 12

Esquema estructurado9 funciones (n2)

JUAN BRAVO C. 248

La cantidad de interacciones funcionales entre los componentes disminuye notablemente respecto a otros métodos, debido a la estructura de objetos inde-pendientes que se comunican entre sí a través de mensajes, tal como se mues-tra en la figura 5-1. Se puede comparar con la realidad de las empresas, donde a veces se logra mayor productividad eliminando interacciones innecesarias entre los departamentos.

La disminución en el número de funciones se debe a la característica de en-capsulamiento del objeto, donde sólo es posible afectar una variable con una operación que se activa a través de un solo tipo de mensaje. Suponiendo que cada maestro es afectado de la misma forma por cada uno de los repositorios de datos de transacciones, en el esquema estructurado se requieren 9 funcio-nes, producto de las tres tablas de transacciones que actualizan a 3 tablas ma-estras. Frente a la misma situación, en la OO tan sólo se requieren 3 funcio-nes, una por cada objeto. Cada una de ellas sería activada tres veces, una vez por cada objeto de transacción.

Para entender mejor la disminución en la complejidad de las relaciones fun-cionales y el notable aumento de productividad que genera, veremos en el siguiente punto la evolución que han seguido los modelos de soluciones de software.

2. Visión de los datos La visión de los datos que surgió en los años 60 buscaba tener todos los datos puros de la organización de forma centralizada. Así se originó el enfoque de bases de datos que vimos en el capítulo 4.

En este esquema los datos no deben actualizarse, sino que se mantienen los valores originales.

Para satisfacer las necesidades de información de la empresa, no es necesario construir un sistema computacional porque todo se obtiene realizando consul-tas sobre la base de datos, con la ayuda de un sistema administrador de bases de datos.

Por ejemplo, se requiere obtener el saldo de inventario de un producto. En lugar de acceder a un campo “stock”, el cual no está permitido en el enfoque de los datos porque es un resultado, se hace una consulta a la base de datos buscando todo el movimiento del producto, se suman las entradas y se restan las salidas.

Hasta fines de la primera década del 2000, todavía la capacidad de procesa-miento no lo permite en forma eficiente.


3. Visión histórica funcional Durante muchos años y tal vez masivamente hasta la década del 90, la forma tradicional de desarrollar era a través de un diseño físico que culminaba en un diagrama de procesos, mediante el cual se graficaban los programas y reposi-torios de datos del sistema. En gran medida, el objetivo de esta línea de diseño era la optimización de recursos del equipo, en particular, minimizar el alma-cenamiento y el tiempo de uso de procesador.

Típicamente, cada programa incorporaba muchos archivos, tal como se mues-tra en la figura 5-2 para un programa de actualización, uno de los más vitales de todo sistema. En este ejemplo, los archivos64 de transacciones: ventas, compras y mermas del día, actualizan a los maestros de artículos, cuentas con-tables y totales de transacciones; por eso la doble flecha en esos archivos ma-estros.

La construcción 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 algún lenguaje de alto nivel: Co-bol, Clipper, RPG, C u otro.

Figura 5-2. Esquema tradicional de diseño

En esta visión funcional la mantención se veía dificultada por la extensión del programa. Era frecuente observar que una pequeña modificación significaba varios días de trabajo. En este entorno, se calculaba que la mantención con-sumía 5 veces más tiempo y recursos que la construcción. De hecho, era fre-cuente que las instalaciones llegaran a su límite de saturación, manteniendo

64 Se conservó la palabra “archivo” que se usaba en este esquema para referirse a los conjun-tos de datos.

Actualización diaria

Compras

Mermas

Ventas Artículos

Cuentascontables

Totales

JUAN BRAVO C. 250

solamente lo urgente, ni siquiera lo importante. Prácticamente no se constru-ían nuevas aplicaciones.

Ni siquiera ayudaba que el mismo constructor hiciera la mantención, porque al poco tiempo olvidaba las sutilezas del programa. Tampoco ayudaba la pro-gramación estructurada, porque fue utilizada en pocas instalaciones y de modo tan informal, que generalmente se transformaba en una receta de “no usar la instrucción go to” a toda costa65.

Descomposición funcional

Luego, aprendimos a hacer descomposición funcional. En muchos casos, a través del modelamiento de funciones que se investigaba por esos días. En otros, de la mano del diseño estructurado.

La idea de la descomposición funcional es ubicar las funciones computaciona-les atómicas sin mezclarlas dentro de un programa. Por ejemplo, el programa de actualización de la figura 5-2 quedaría como el esquema estructurado de la figura 5-1, convertido en 9 funciones similares entre sí, de tal forma que cons-truyendo la primera, las siguientes se copian y adaptan. Bajo este esquema, el tiempo de construcción de los pequeños programas de la figura 5-2 probable-mente no exceda de dos días y la mantención se simplifique tanto que tal vez quede tiempo para nuevos desarrollos.

Sin embargo, hay algunos inconvenientes. Por ejemplo, cuando se modifica un campo de una entidad, hay que buscar en muchas funciones para corregir todas las rutinas que afectan a ese campo. Otro problema es la serie de incon-sistencias que se generan cuando no se modifican todas las funciones debidas. Además, cuesta manejar un exceso de pequeñas funciones a veces muy pare-cidas entre ellas, tal como vemos en la figura 5-3.

65 El autor trabajó en instalaciones donde la programación estructurada estaba vedada, porque habían tenido muchas malas experiencias de programas innecesariamente extensos y en ex-tremo complejos. El argumento en defensa de la programación estructurada era que no había sido comprendida por el programador y estaba mal aplicada en el programa. La recomendación en esos días (y todavía en ciertos ámbitos) es que era preferible tener mu-chos programas pequeños y si eso no era posible, usar la programación estructurada aplicán-dola correctamente. Lo cual no era tan fácil porque era bastante difícil de aprender. En el libro Desarrollo de sistemas de información, una visión práctica se describen los prin-cipios de la programación estructurada.


Figura 5-3. Ejemplo de relaciones funcionales estructuradas

En el ejemplo de la figura 5-3 se definieron dos procesos de actualización sobre el maestro de artículos: desde ventas y desde mermas. Ambas son fun-ciones atómicas y están bien definidas. Aunque, si observamos detenidamente, apreciaremos que ambas funciones hacen lo mismo: restar el stock. Entonces, ¿por qué repetirlas?…

4. La orientación a objetos Con la orientación a objetos se evita repetir código, porque la función restar stock se define una sola vez y pasa a ser parte del objeto artículos. De esta manera, cuando se requiera ocuparla, ya sea por ventas, mermas, ajustes de salida o devolución de compras, se activa con un mensaje, el cual tiene como parámetros el código del producto y la cantidad que se restará.

Entonces, el ejemplo de la figura anterior quedaría como se muestra en la fi-gura 5-4. En este caso, la función puede ser activada desde los objetos ventas y mermas a través del mensaje 1 (su estructura es: código, cantidad).

Figura 5-4. Ejemplo de orientación a objetos

El gran avance es el encapsulamiento, donde los datos y las funciones están indisolublemente unidos.

Ventas

Artículos

• CódigoDescripciónStockMensaje 1 Mensaje 1

Mermas

1.- Restar stock

Ventas

Artículos

• CódigoDescripciónStockMensaje 1 Mensaje 1

Mermas

1.- Restar stock

Ventas Artículos Mermas1

Actualizar stock

3

Actualizar stock

Ventas Artículos Mermas1

Actualizar stock

3

Actualizar stock

JUAN BRAVO C. 252

Tal como vimos en la introducción del capítulo, la orientación a objetos nos provee de otro concepto vital: la generalización. Es la posibilidad de acercar-nos a la forma natural del aprendizaje: el proceso cognitivo del ser humano.

A través de esta breve síntesis histórica pudimos apreciar la evolución del concepto de diseño durante los últimos 20 años, destacando las ventajas de la orientación a objetos.

5. Incorporación de nuevas tecnologías Es de conocimiento general que la incorporación de nuevas tecnologías sigue la curva que se presenta en la figura 5-5.

Figura 5-5. Gráfico de incorporación de nuevas tecnologías

La incorporación de nuevos entrantes es muy lenta al principio, luego se pro-duce una fuerte aceleración hasta llegar a un alto nivel de entrada de nuevas organizaciones que la adoptan. Finalmente, cuando la tecnología está total-mente consolidada y hay mucha experiencia, se incorpora una menor cantidad de usuarios, los más escépticos, justamente cuando una nueva tecnología está naciendo. El diseño estructurado se encontraría hoy (2008) prácticamente sin nuevos entrantes, más o menos en el punto (DE) señalado en la figura 5-5. A su vez, la orientación a objetos se encontraría en la cúspide de su madurez y UML (que veremos en el capítulo 7) estaría en la fase de incorporación acelerada de nuevos entrantes.

Ciclo de tiempo de incorporación a la tecnología

Tiempo

Cantidad de organizaciones que adoptan la tecnología

UML

OO

DE


Algunos argumentos pueden ser esclarecedores respecto al éxito de la orienta-ción a objetos:

• Business Week catalogó a la tecnología de objetos como la más grande invención después del fuego. Sin duda una apreciación exagerada, pero sintomática respecto a los sentimientos que provoca.

• Más del 75% de las empresas Fortune 100, la está usando o probando. • Estadísticas de 1993 indican que en EE.UU. se estaba utilizando en el

11,9% de los proyectos, en comparación a un 3,8% en 1991. Hacia fines de la primera década del 2000 más del 70% de aplicaciones la usa de una u otra forma.

La orientación a objetos es una tecnología joven que comenzó a mediados de los 80 con un fenómeno muy curioso: nació en cientos de lugares a la vez: Japón, Europa, USA, Chile y otros países. Tenía diferentes nombres y muchas variaciones, aunque con los mismos objetivos66. ¿Por qué se produjo este fenómeno? Porque era una necesidad de mercado. El método tradicional y las técnicas estructuradas habían sido sobrepasadas por la realidad y por el cam-bio en la computación.

Fundación de la OMG

Es tan amplia la OO que unas 200 compañías del área TI formaron en los años 80 el grupo de administración de objetos —más conocido por sus siglas en inglés: OMG (Object Management Group)—. Integran este grupo las princi-pales empresas de computación a nivel mundial: IBM, Unisys, NCR y otras. En forma resumida, el OMG tiene por misión:

• Maximizar la portabilidad y la reutilización del software. • Crear una arquitectura de referencia, con términos y definiciones en los

cuales basar todas las especificaciones. • Ofrecer un foro abierto para el análisis, la educación y la promoción de la

tecnología de orientación a objetos.

En 1994, la OMG encargó el desarrollo de un lenguaje de modelamiento ba-sado en la orientación a objetos, así surgió UML en 1997.

66 Hacia fines de la década de los 80 el autor se encontraba trabajando en el modelamiento de datos y funciones, donde reunía en un solo todo la estructura y la funcionalidad asociada a una entidad, trabajaba en reutilización de código y experimentaba con herramientas CASE como una forma de agilizar el desarrollo de sistemas computacionales. Una vez que supo de la exis-tencia de la tecnología de objetos, adaptó toda su investigación a ella.

JUAN BRAVO C. 254

Hacia el 2008, la OMG tiene varios cientos de miembros y sus productos son estándares “de hecho”, tal como CORBA, MDA, UML, API’s y otros.

Nuevo enfoque, nuevas soluciones

Es posible que muchos problemas tengan soluciones muy simples al observar-los con un nuevo enfoque, distinto a la visión permitida por las estructuras tradicionales de archivos planos y programas asociados, porque sólo se ha apreciado una pequeña porción de la realidad, dejándose de lado la imagen real que percibe el usuario: objetos “vivos”, textos, formas tridimensionales, fotografías o conjuntos de datos con estructuración libre.

Con la tecnología de objetos podemos “ver” a la organización de forma más simple, natural y real.


5.2. DEFINICIONES SOBRE ORIENTACIÓN A OBJETOS

Precisaremos aquí los conceptos básicos de la OO y algunos términos asocia-dos del modelamiento de datos y funciones.

Veremos: 1. Definiciones preliminares 2. Convenciones de diseño 3. Relación de pertenencia 4. Condición 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. También se observa que las ocurrencias de una clase son los objetos y que las ocurren-cias de un objeto son las instancias. Son conceptos recursivos y que dependen del contexto. En cierto contexto un objeto puede ser visto como una clase y en otro como un objeto.

Figura 5-6. Nomenclatura de la orientación a objetos

Nótese en la figura 5-6 que la representación gráfica de los objetos es con una doble línea y la de las clases es con una sola línea, tal como lo propone Ed-ward Yourdon. Veremos que en los diagramas finales de diseño hay solamen-te clases, por lo tanto, se justifica una representación más simple para ellas. El punto (•) señala que el campo es llave principal. El campo Rut es un número identificador de personas y empresas en Chile.

IngresarEliminarImprimir

• Rut NombreDirección

Personas Avales

Clientes

Ingresareliminar

Ventas

Clase

Objeto

Objetos

C/E

Instancias de clientes:Juan Pérez, Alberto Torres

• Nº documentoRut

JUAN BRAVO C. 256

Definiciones de la OO:

• Atributo: es equivalente a “campo”. Por ejemplo: el campo fecha con sus procedimientos de cambio de día, mes y año, traducción del nombre del día y del mes, diferentes formatos (AAAA /MM /DD o DD/MM /AAAA ), etc… Un atributo posee características estáticas y funcionales, tal como vimos en el capítulo 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. También se le llama llave externa o llave foránea. Por ejemplo, el RUT del cliente en el objeto ventas de la figura 5-6.

• Clase: es una abstracción que no tiene una implementación tecnológica. Se aplica a nivel del modelamiento y sirve para identificar y darle sus elemen-tos a los objetos que de ella derivan; por ejemplo, en la figura 5-6 se apre-cia que los objetos clientes y avales se derivan de la clase personas y here-dan de ella sus elementos comunes.

Veremos más sobre clases en el resto del capítulo.

• Función: es un procedimiento que permite cumplir alguna acción, en la forma de un programa de computador. Consta en su mayor parte de lógica generalizada, común a todas las funciones del mismo tipo y en menor me-dida, de las reglas de negocio, o lógica que realmente tiene que ver con las necesidades particulares de la aplicación. Las funciones permiten “dar vi-da” a una estructura estática. Por ejemplo, actualizar el saldo de un inventa-rio o imprimir una cartola.

• Instancia: es una ocurrencia de los datos reales de cada objeto, equivalente al “registro” del diseño tradicional o a la “tupla” del esquema relacional. Por ejemplo, cada cliente individual del objeto CLIENTES de la figura 5-6, los señores Juan Pérez y Alberto Torres.

• Objeto: Es algo concreto del mundo real que tiene una representación física en la construcción del sistema. Cada objeto viene a ser una instancia de su clase. Se define como un conjunto de atributos con funciones indisoluble-mente asociadas, equivalente a la entidad más su funcionalidad. A nivel del diseño, algunos ejemplos de objetos serían: clientes, avales, proveedores, facturas de venta, notas de devolución de compras, artículos, etc…

• Objeto asociativo: generalmente resulta de una relación tipo red entre dos objetos, especialmente cuando se agregan atributos propios de la relación;


por ejemplo, el costo de cada artículo por proveedor en una relación mu-chos a muchos entre artículos y proveedores. El objeto asociativo también puede estar asociado a un solo objeto; por ejemplo, parentescos del objeto personas.

• Variable de resultado: puede ser física, como un atributo del objeto donde se guarda el resultado actualizado de alguna operación, como la valoriza-ción del saldo —según la fórmula saldo x costo— de un producto del in-ventario. También puede ser lógica, como cuando se usa una variable glo-bal y el cálculo se efectúa 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 ningún objeto, permite efectuar operaciones aritméticas, pasar parámetros a través de mensajes, identificar el estado de los objetos, etc… A veces se la identifica con sub-rayado.

• Recursividad: significa que tanto los datos como las funciones son a su vez clases y objetos en otro nivel de profundidad. Asimismo, lo que declaramos como clase en un nivel podría ser objeto en otro, esto porque las observa-ciones se realizan de acuerdo al fin particular de la aplicación.

Los nombres de clases, objetos y funciones son vitales para lograr claridad en modelos complejos. Algunas convenciones recomendables son usar sustanti-vos para clases y objetos, tales como personas, artículos y documentos; y ver-bos en infinitivo para funciones, tales como restar, sumar e ingresar. También se sugiere evitar el uso de prefijos y sufijos, con el fin de obtener nombres fácilmente entendibles y que proporcionen el máximo de información.

2. Convenciones de diseño Algunas convenciones para el diseño pueden ser, por ejemplo:

• Validar el dígito 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 dígito verificador se utiliza en otra enti-dad, por ejemplo, VENTAS, se aplica una condición de existencia respecto a la entidad a la cual ingresó la primera vez (CLIENTES en el ejemplo) y no se vuelve a validar el dígito verificador.

Suponer los siguientes largos de campos, salvo indicación diferente:

JUAN BRAVO C. 258

• Valor : numérico largo 9, con signo • Documentos : numérico largo 6 • Nombres : alfanumérico largo 30 • Dirección : alfanumérico largo 35 • Teléfono : alfanumérico largo 15 • RUT : numérico largo 10, más dígito verificador

Los conceptos relación de pertenencia y condición de existencia, relacionados con las convenciones de diseño, se definen en los siguientes puntos.

3. Relación de pertenencia Una relación de pertenencia surge de una estructura jerárquica como la que se muestra en la figura 5-7, en la cual se aprecia la pertenencia de entidades.

Figura 5-7. Relación de pertenencia

La línea que une los objetos A y B es más gruesa, para reflejar lo fuerte de la relación; es el caso de un encabezado y su detalle en documentos como una factura o una nota de devolución.

La relación de pertenencia es un caso particular de la relación uno a muchos presentada en el capítulo anterior. Se agregan las siguientes características:

• Unicidad: significa que todos los objetos son parte de un solo todo; en consecuencia, los objetos hijo no podrían sobrevivir independientemente.

• Cada hijo tiene un solo padre. Los hijos se relacionan a través del padre. • No se puede eliminar un padre si existen hijos y no se puede crear un hijo

si no existe el padre.

A

B

Entidad A

Entidad B

Donde B pertenece a A, lo cual da origen a la notación:


• Se llega automáticamente al hijo pasando por el padre a través de la rela-ción de pertenencia.

• Para efectos de implementación, generalmente la información del padre se presenta en forma lineal y la del hijo en forma tabular, tal como se aprecia en el siguiente diagrama:

Algunas convenciones sobre esta relación son:

• Suponemos que existe un traspaso automático de información entre padre e hijo. Esto significa que si el objeto de detalle no tiene los datos requeridos para estructurar un mensaje y sí están en el encabezado, se toman automá-ticamente y viceversa.

• Asimismo con las funciones, cualquier función del detalle puede ser acti-vada desde el encabezado y viceversa.

• El primer atributo de un detalle es la misma clave de la entidad encabeza-do, así es que no sería necesario anotarla en el objeto de detalle. Esta dis-tinción es vital, porque a nivel de la implementación significa que no es necesario construir ningún tipo de índice intermedio, pues todo lo necesa-rio está contenido en los objetos y en su estructura.

Considerando lo poderoso de la relación, es conveniente que un mismo dise-ñador sea dueño de todos los objetos sujetos a relaciones de pertenencia.

4. Condición de existencia La condición de existencia (C/E) es una relación funcional entre objetos, la cual permite asegurarse de que uno o más atributos referenciales de un objeto

Forma lineal

Forma tabular

Forma lineal

Forma tabular

JUAN BRAVO C. 260

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 condición de existencia es una validación que sigue, más o menos, la si-guiente lógica:

¿Existe la instancia en el objeto destino? (por ejemplo, un cliente) SI. Acción de desplegar algo y aviso OK. NO. Ofrecer tres alternativas a elección 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 lógica viene provista en forma automática por sis-temas administradores de bases de datos y herramientas de productividad. Es también una posibilidad mantenerla como una clase o rutina reutilizable.


5.3. CONCEPTOS DE LA ORIENTACIÓN A OBJETOS

Los conceptos de la orientación a objetos aplican en las etapas de análisis, diseño e implementación del método GSP.

Veremos: 1. Encapsulamiento 2. Clase 3. Objeto 4. Función 5. Identidad de instancias de objetos 6. Mensaje 7. Independencia 8. Enfoque sistémico

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 artículos con todas las funciones necesarias para extraer y actualizar sus datos. De esta for-ma, si otro objeto requiere algo, por ejemplo, el historial de un artículo, se lo pide al objeto artículos, el cual responderá de acuerdo con sus funciones in-corporadas. Se parece al funcionamiento de una célula, la cual recibe mensa-jes del exterior y reacciona proporcionando los productos correspondientes, ¿cómo lo hace? Eso es parte de sus funciones incorporadas67.

67 Alfred Gilman, ganador —junto con Martin Rodbell— del Premio Nobel de Medicina 1994 nos dice que “la célula es una verdadera maravilla en miniatura: contiene en su núcleo toda la información genética y vive, por así decirlo, su propia vida: recibe sustancias desde el exte-rior, las transforma para conseguir energía, arroja fuera los desechos, fabrica los componentes que el organismo necesita y los exporta al lugar apropiado. Ella necesita “saber” qué tipos de moléculas se encuentran a su alrededor para dejarlas entrar o cerrarles el paso. Necesita “sa-ber” qué hacer con el material que entra. También necesita “conocer” el estado del organismo, para actuar en consecuencia. Se trata de todo un mundo fascinante que funciona a base de “información”. Y ahí desempeñan un papel importante las proteínas G. Con el tiempo, se sabrá cómo se relacionan entre sí las docenas de receptores, proteínas G y electores diversos. Y podrá predecirse cómo reaccionarán las células en respuesta a cualquier combinación de señales”.

JUAN BRAVO C. 262

Otro ejemplo, el objeto clientes, el cual además de una estructura de campos (nombre, dirección, fecha de nacimiento y otras) tiene una cantidad de funcio-nes incorporadas, tales como: enviar mensajes de e-mail para el cumpleaños, obtener saldo de crédito, agregar o eliminar registros.

2. Clase La clase68, es una abstracción de la realidad y vendría a ser la forma común de describir objetos similares. Gracias a ella es posible reconocer rápidamente otros objetos del mismo tipo, asociándolos a ella y dándoles los elementos comunes, los cuales pueden ser alterados en un objeto determinado.

¿Qué diferencia hay entre una clase y un objeto? La clase es una generaliza-ción que no llega a transformarse en tablas, por ejemplo: personas. El objeto representa algo del mundo real que tendrá una representación física, por ejem-plo, las tablas de clientes y proveedores.

A partir de experiencias concretas vamos formando y perfeccionando cada abstracción. Por ejemplo, la idea de mesa la representamos como una cubierta

68 El concepto de clase es tan importante porque tiene una fuerte sustentación natural; de muestra, revisemos esta cita extraída del libro Muéstrame tu rostro, de Ignacio Larrañaga, 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 fábrica de elaboración. Efectivamente, de cada objeto detec-tado por los diferentes sentidos, la mente aparta lo que el objeto tiene de propio o individual y extrae y retiene lo que tiene de común con todos los demás objetos de su especie. Esto es, deduce una idea común a todos los objetos y por consiguiente, universal. Es un trabajo de universalización. Vamos a un ejemplo concreto. Aquí veo una silla. Allá lejos veo otra silla, pero ¡qué diferente a ésta! En ese rincón hay otra silla que no se parece nada a estas dos ni en tamaño ni en diseño. Y así, entraron en mi men-te, supongamos, cincuenta sillas de cincuenta formas diferentes. Ahora comienza el trabajo elaborador de la mente. De todas las sillas, mejor, de las imágenes concretas de cada silla, la mente, dejando aparte aquello que le es propio a cada una, saca y se queda con lo que es común a todas: una idea universal de silla. Una vez terminado este trabajo de elaboración, pueden presentar ante mis ojos mil sillas en medio de diez mil otros objetos. Mi mente toma, como un candil, aquella idea universal y con su luz, voy distinguiendo, reconociendo e identificando las mil sillas entre los diez mil obje-tos, sin equivocarme. Lo mismo sucede en otras áreas. Si me ponen delante otros cinco mil objetos, sabré decir con precisión cuáles son fríos, cuáles calientes o tibios. O, en otro orden, cuáles son duros o blandos; cuáles verdes, rojos o amarillos. Así funciona y ésta es la génesis del pensamiento humano.


con algún tipo de soporte. De la misma forma, tenemos abstracciones de alegría, responsabilidad, padre, madre, pareja y así sucesivamente.

También creamos clases y formamos abstracciones de abstracciones formando conceptos cada vez más complejos.

Las abstracciones son vitales, porque las utilizamos para filtrar la realidad y enfrentar nuevas situaciones69.

Somos capaces de reconocer un lápiz, una experiencia nueva, porque sus ele-mentos distintivos cuadran con nuestra abstracción de lápiz, obtenida como resultado de todas nuestras experiencias anteriores sobre el concepto de lápiz.

No se puede dibujar una abstracción, porque si lo hacemos estamos obligados a particularizarla en un objeto concreto, por ejemplo, en el caso de la mesa, tendríamos que señalar tamaño, forma, textura o color.

Queda de manifiesto la estrecha relación existente entre el concepto de clase de la orientación a objetos y la abstracción del proceso cognitivo en el ser humano.

3. Objeto Es una unidad monolítica de atributos con sus funciones que tiene su propia identificación, tal como se aprecia en la figura 5-8, donde se muestra una for-ma de representación para un ejemplo de clientes. La identificación del objeto contiene un nombre corto, un número y un nemotécnico; en el ejemplo: Clien-tes, 08, CL. Los atributos corresponden a la definición de los datos (RUT, nombre y dirección) y las funciones realizan operaciones sobre los atributos (ingresar, obtener informe y consultar).

El objeto se comunica con el mundo exterior a través de mensajes, de aquí el concepto de encapsulamiento de datos y procesos. Las funciones manipulan los datos y solamente se activan a través de mensajes. Un usuario u otro obje-to no pueden aplicar procedimientos externos para actuar directamente sobre los datos, por esta razón se habla de ocultamiento de datos (data hiding).

69 A propósito, es curioso que algunas abstracciones las tenemos inconscientemente en perfec-cionamiento continuo y otras se nos quedan rígidamente ancladas en alguna parte del pasado, sin verse afectadas por las nuevas experiencias que vivimos, hasta cuando viene una crisis y hacemos una actualización rápida y agotadora.

JUAN BRAVO C. 264

Figura 5-8. Representación de un objeto

Un objeto tiene una identidad, un comportamiento (de acuerdo con la función activada) y un estado que resulta del valor que tomen sus atributos. El objeto así concebido no se daña por errores en otros objetos.

El objeto nace a partir de una abstracción 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 lápiz, una silla o el maestro de clientes en la aplicación de cuentas corrientes.

Aplicando el concepto de recursividad de la orientación a objetos, también puede ser que el maestro de clientes sea una clase y que cada cliente indivi-dual sea un objeto.

Los diferentes tipos de modelos permiten entender mejor la realidad, para así ayudar a resolver problemas concretos. En este sentido, los objetos son mode-los que reflejan de mejor manera la realidad que otros mecanismos actuales, porque lo hacen de manera más natural. Por ejemplo, una fecha no se entiende habitualmente como característica de datos y cálculos por separado, sino que, intuitivamente, uno la entiende como un conjunto donde hay datos (DD/MM /AAAA ) y operaciones (cambio de día, mes, año, situaciones especiales como años bisiestos o meses con diferente cantidad de días).

El objeto también posee características propias; son rasgos que lo definen, independientemente de sus ocurrencias; por ejemplo, nombre, número, ne-motécnico, descripción, fecha de creación, fecha de expiración, propietario o condiciones fijas.

Clientes 08 CL

• RUTNombre Dirección

Identificación

Atributos

Funciones1. Ingresar datos2. Obtener informe3. Consulta


Para efectos del diseño, cada entidad se transforma en un objeto; por lo tanto, el nombre del objeto debería ser el mismo que el de la entidad.

4. Función Por función entendemos función computacional, de la misma forma como fue presentada en el capítulo anterior y con la misma distinción entre parte pública y reglas del negocio.

Orientación a objetos no implica programación orientada al objeto, porque son niveles diferentes. Por lo tanto, la función puede construirse de diferentes ma-neras; por ejemplo:

• Con código reutilizable. • Utilizando facilidades de sistemas administradores de bases de datos. • A través de alguna herramienta de productividad. • Programando en algún lenguaje de alto nivel: Cobol, Clipper, C u otro.

En la orientación a objetos, la función computacional debe poseer la carac-terística de atomicidad (o descomposición funcional) porque:

• Cumple un objetivo preciso y bien acotado; por ejemplo: agregar un clien-te, eliminar un cliente, obtener un informe o verificar el nivel de crédito. Esto trae como consecuencia que en general las rutinas tengan pocas líneas de código.

• Sólo se relaciona con los atributos del objeto y con ningún otro conjunto de datos, porque todo lo que necesita viene dado como parámetro en la es-tructura del mensaje. Es equivalente a que toda función actúe únicamente sobre una entidad; de esta manera, desaparecen las relaciones funcionales entre entidades, las cuales son reemplazadas por el protocolo de un objeto.

5. Identidad de instancias de objetos Significa que cada instancia de un objeto tiene su propia identidad, indepen-dientemente del valor que tomen sus atributos. Un objeto puede cambiar li-bremente cualquier atributo sin dejar de ser él mismo. En consecuencia, no sería necesario definir atributos identificatorios en un objeto, simplificándose notablemente la participación del usuario por este solo concepto.

Con la identidad de instancias de objetos damos un gran paso hacia la natura-lidad, porque en la realidad cada instancia es independiente. Por ejemplo, una persona no pierde su identidad si cambia su nombre, RUT o dirección.

JUAN BRAVO C. 266

Opcionalmente, también debiéramos poder trabajar con una clave única. En otras palabras, el sistema administrador de objetos tendría la capacidad de generar y manejar la identidad de objetos, además de permitir referenciar cada instancia según una clave única, a opción, para responder a la realidad de mu-chos objetos que no tienen problemas con una clave identificatoria (RUT o código de barras) la que en algunos casos es indispensable: artículos de un supermercado o diferenciación de productos a nivel internacional.

6. Mensaje Es una forma lógica de representar la comunicación entre objetos. Los com-ponentes mínimos de un mensaje son: objeto destino, función que activa y parámetros. Los parámetros son los valores y condiciones de entrada que re-quiere la función seleccionada. Por ejemplo, en la figura 5-9 podemos apreciar la estructura del mensaje 1 al objeto artículos, el cual activa la función 1 y lleva los parámetros: código del artículo y cantidad a restar.

Figura 5-9. Ejemplo de estructura de un mensaje

Al conjunto de mensajes válidos de un objeto se le llama protocolo del objeto.

Un mensaje puede generarse de diferentes maneras; por ejemplo:

• Al terminar el ingreso de una transacción • 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 sólo sea para decir “lo escuché”, tal como en la buena comunicación humana.

Mensaje 1: Artículos (código, cantidad)

Artículos

VentasMensaje 1 • Código

DescripciónStock

1.Restar stock


Para efectos de la implementación del diseño con programación tradicional, la generación de un mensaje puede significar la realización de una llamada pa-ramétrica a una rutina. En todo caso, su forma final dependerá de las herra-mientas disponibles para realizar el diseño.

7. Independencia Cada objeto es independiente, está identificado individualmente y no puede ser alterado desde otros objetos o programas. Puede realizar diferentes funcio-nes y tiene conexiones fácilmente reconocibles.

La independencia es una consecuencia del encapsulamiento, porque los datos de un objeto no pueden ser alterados en forma directa. Sólo se puede llegar a ellos a través de mensajes que activan funciones propias del objeto.

Se pueden cambiar libremente las funciones de un objeto sin afectar a otros, siempre que no cambie la estructura del mensaje. No obstante, si fuera necesa-rio afectar los mensajes producto de cambios mayores, el esfuerzo se vería notablemente simplificado, porque las interacciones con otros objetos están definidas y acotadas.

Esto permite una forma simple, práctica y natural de abordar los problemas de procesamiento de datos, porque se espera llegar a tener objetos intercambia-bles. Es decir, se podría cambiar un objeto por otro más poderoso sin afectar al resto del sistema, en la medida que el protocolo se mantenga intacto.

La independencia de los objetos tiene efecto inmediato sobre el grado de co-municación entre ellos. Significa que disminuyen las interacciones innecesa-rias o de dependencia y se incrementan las relaciones importantes, aquéllas que se refieren a “qué es lo que quiero”.

Es un tipo de comunicación estructurada donde se pueden identificar puestos intercambiables de objetos, como éstos:

• Cliente, solicita la acción. • Servidor, da respuesta al pedido.

Esta distinción es dinámica, porque puede variar rápidamente. 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 orientación a objetos, el mismo esquema de definición de objetos permi-te una modularización natural a través de la definición de clases.

JUAN BRAVO C. 268

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 comunicación, pero como ésta es estructurada, pue-de ser automatizada.

8. Enfoque sistémico El enfoque sistémico se caracteriza por proporcionar una visión de conjunto sobre el sistema en estudio, reflejada en identificar los objetos y las interac-ciones entre ellos (los mensajes). En este enfoque, cada interacción tiene el status de un componente más70.

¿Cuál es el número potencial de interacciones entre los objetos? Considere-mos que si hay 2 objetos, la interacción es 1. Si hay 3, las interacciones son 3. Si hay 4, el número 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 relación se traspasará al conjunto.

70 Como analogía, si aplicamos este enfoque a una familia con tres miembros (papá, mamá, hijo), identificaremos inmediatamente tres relaciones principales: papá-mamá, papá-hijo, mamá-hijo. Cada una con su propia identidad y peculiaridades. Somos dependientes de nues-tras relaciones y cada una nos estremece de diferente manera, a veces, hasta hacernos entrar en resonancia. Una “mala” relación afecta a toda la familia, incluso cuando no haya algo es-pecialmente conflictivo en las respectivas personas. Del mismo modo, la “sanación” de una relación enferma repercutirá favorablemente en cada integrante y en el conjunto.


5.4. PROCESO DE GENERALIZACIÓN

Es tan importante el concepto de generalización en la orientación a objetos que le hemos dedicado la presente sección.

Veremos: 1. Obtención de clases 2. Herencia

1. Obtención de clases La generalización 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 instalación y sirven para derivar obje-tos, como si fuera una herencia. Por ejemplo, si las transacciones del inventa-rio son órdenes de entrada y órdenes de salida, dos objetos, podríamos 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 múltiples abstracciones y luego aplicamos la abstracción para reconocer experiencias y tomar decisio-nes. El concepto de generalización de la orientación a objetos permite acer-carnos un poco a la tan buscada inteligencia artificial.

Entonces, en el proceso de generalización 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 características de la clase. Si hay ele-mentos que debe eliminar significa que deberíamos crear una subclase o modificar la clase para que sea representativa.

Profundizando más en la concepción de clases, no es imprescindible la expe-riencia para formar una abstracción. Considerando que la clase es algo abs-tracto, es posible crear clases de objetos que no existen todavía —como es el caso de las clases de partículas subatómicas enunciadas en la teoría de Eins-tein y en la física cuántica que luego se fueron descubriendo—.

JUAN BRAVO C. 270

¿Para qué sirve una clase? Para no multiplicar esfuerzos haciendo lo mismo en cada ocurrencia común y reconocer nuevos objetos de la misma clase, los que heredarán sus elementos y ayudarán a perfeccionarla.

Para aclarar más el concepto, veamos el ejemplo sobre remuneraciones en la secuencia de figuras 5-10, 5-11 y 5-12.

En la figura 5-10 se pueden apreciar los objetos descuentos de anticipos y re-baja de préstamos a las personas; los atributos comunes son: número de do-cumento, RUT del empleado y monto de la transacción; las funciones comu-nes son: verificación de existencia, ingreso, informe y activación del mensaje 19 sobre la clase empleados al terminar el ingreso de datos.

Figura 5-10. Ejemplo de transacciones de sueldos con objetos

En la figura 5-11 se muestra cómo se forma la clase transacciones de sueldos con los elementos comunes de los objetos descuentos de anticipos y rebaja de préstamos a empleados.

Figura 5-11. Ejemplo de definir una clase de transacciones de sueldos

Descuentode anticipos

Empleados Rebaja de Préstamos

• Nº documentoRut Monto

C/E

Mensaje 19

C/E

Mensaje 19

• Rut MontoTotal haberTotal descuento

• Nº documentoRut MontoNº cuota

Ingresar datosObtener informe

18. Sumar haber19. Sumar descto


Descuentode anticipos

Empleados Rebaja de Préstamos


C/E

Mensaje 19

C/E

Mensaje 19


• Nº documentoRut MontoNº cuota




Transacciones de sueldos

Descuento de Anticipos

Rebaja de préstamos

Nº cuota

Empleados

C/E

Mensaje 19






Descuento de Anticipos

Rebaja de préstamos

Nº cuota

Empleados

C/E

Mensaje 19






Sin embargo, justo cuando tenemos listo nuestro modelo, nos damos cuenta que no consideramos las bonificaciones. No hay problema, pues, como es también una transacción de sueldos, la hacemos nacer con los elementos de la clase. Sin embargo, la bonificación se suma al total haber del objeto personal y es necesario activar la función 18 de personal, en lugar de la 19, como en el caso de las otras transacciones.

¿Cómo reflejamos lo particular de cada objeto respecto a su clase? Sería ex-tenso indicar en el diagrama de clases ese nivel de detalle, así es que usamos una tabla de objetos asociada a cada clase. Por lo tanto, el modelo final corre-gido quedaría solamente con las clases y la tabla de objetos, tal como se mues-tra en la figura 5-12.

Figura 5-12. Diagrama final de la generalización

En la figura 5-12 podemos apreciar la estructura de la tabla de objetos: to-mando como base los elementos heredados de la clase, señala qué atributos o funciones se agregan a cada objeto y lo particularizan.

Los mensajes —también llamados solicitudes— pertenecen a cada relación particular entre objetos; así es que se indicaron explícitamente en la tabla de objetos.

En esta secuencia apreciamos la definición, aplicación y perfeccionamiento continuo de una clase, de la misma forma en que opera el proceso cognitivo del ser humano en relación a las abstracciones.


Empleados

C/E

Mensaje 18/19



Ingresar datos Obtener informe



Empleados

C/E

Mensaje 18/19



Ingresar datos Obtener informe


Tabla de objetos de la clase Transacciones de sueldos Objeto Atributos Funciones

Anticipos msg 19 Préstamos Nº cuota msg 19 Bonificaciones msg 18

JUAN BRAVO C. 272

2. Herencia El concepto de herencia es similar a la herencia genética en el ser humano; heredar significa recibir nuestras características a través de los genes y así partimos con lo que nuestros padres nos transmitieron71, sin posibilidad de modificarlo —color de ojos, estatura o ancho de los dedos— aunque incorpo-rando nuestra particular forma de ser obtenida de la experiencia y la reflexión.

En la figura 5-13 se aprecia el nacimiento y aplicación de la clase ventas, la cual fue definida a partir de los elementos comunes de los objetos ventas con-tado y ventas crédito. Si fuera necesario definir un nuevo objeto, por ejemplo “ventas por mayor”, éste nacería con los datos y funciones de la clase ventas, además, puede tener particularidades tales como el atributo descuento y la función emitir factura.

Figura 5-13. Ejemplo de herencia en un sistema de ventas

En otro nivel de abstracción, las funciones también pueden ser clases; por ejemplo, el documento de crédito en la figura 5-13 podría ser “genérico” y representar todos los casos del mismo tipo: letras, pagarés, o cheques a fecha.

En la herencia, los objetos heredan sin discusión los elementos de la clase y pueden agregar otros atributos y funciones.

El concepto de herencia entrega una forma muy clara de apoyar el diseño de aplicaciones administrativas, particularmente en la definición de transaccio-nes, donde existen muchas similitudes entre un tipo de transacción y otra.

Herencia múltiple

71 Y lo que no nos transmitieron por “error” genético y que la naturaleza inventó, pero eso es otro tema.

Ventas contado

Ventas crédito

Emitir pagaré

Ventas

• Nº documentoFecha ClientePrecioCantidad

Ventas por mayor

Emitir factura

Descuento

Emitir boleta


Ventas contado

Ventas crédito

Emitir pagaré

Ventas

• Nº documentoFecha ClientePrecioCantidad

Ventas por mayor

Emitir factura

Descuento

Ventas por mayor

Emitir factura

Descuento

Emitir boleta



Con la herencia múltiple pueden existir subclases o una jerarquía de clases; además, las características heredadas pueden ser incorporadas directamente o provenir desde otras clases u objetos, tal como se aprecia en la figura 5-14.

Figura 5-14. Herencia múltiple

Un ejemplo de herencia múltiple a nivel del diseño es el siguiente: en un sis-tema de ventas necesitamos formar el objeto clientes. Entonces, de la clase personas jurídicas heredamos los datos para formar el objeto. Adicionalmen-te, requerimos agregar los datos de las personas que hacen contacto con nues-tra organización —comprador, gerente y tesorero—, los cuales heredamos desde la clase personas naturales.

En este ejemplo, consideraríamos a clientes como heredero de la clase princi-pal; es decir, de personas jurídicas.

Nuevo atributo o función

Clase Clase

ObjetoObjetoNuevo atributo o función

Clase Clase

ObjetoObjeto

Clase Clase

ObjetoObjeto

JUAN BRAVO C. 274

5.5. FASES DE LA ORIENTACIÓN A OBJETOS

Se presenta en esta sección una técnica para realizar orientación a objetos. Se aplica una visión sintética, holística, yendo de lo general a lo particular.

Todo comienza con el modelamiento de la información.

Veremos: 1. Modelamiento de la información 2. Identificación de clases 3. Visión externa 4. Visión interna 5. Interfaz humana

1. Modelamiento de la información Antes de comenzar con la OO es indispensable contar con el modelamiento de la información.

Repasemos brevemente esta condición de entrada al OO.

• Identificar entidades: consiste en seleccionar los conjuntos de datos que participarán en el modelo. ¿De dónde nacen? De la identificación de los procesos de la organización y más 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 precisión 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 cómo diferentes even-tos (transacciones) van a producir cambios de estado (variación de atribu-tos) de una entidad (maestro) a través de ciertas acciones (funciones).

Además de las funciones propias del modelamiento de la solución, deberán definirse otras orientadas a la infraestructura de apoyo que requiere una apli-cación: protección, en lo que se refiere a privacidad, integridad y recupera-ción; menús, búsqueda de información, bitácora de uso del sistema, creación y reconstrucción de objetos.

Vamos a comenzar suponiendo que existe un modelo de datos normalizado sobre un sistema de inventarios simplificado, como el de la figura 5-15. Este


modelo tiene transacciones de ventas y compras, cada una de ellas posee la estructura encabezado-detalle. También incluye los maestros de proveedores, clientes y artículos de línea blanca.

Figura 5-15. Modelo de datos simplificado de inventarios

Los símbolos corresponden a relaciones unos a muchos:

También 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 artículos en ambos casos.

• Actualizar el maestro de artículos al terminar el ingreso de una transacción, para rebajar el saldo en el caso de ventas y para sumar el saldo y calcular costo promedio en el caso de compras.

Más que presentar recetas, el contenido de las fases es una guía para la acción, ellas deben complementarse con mucho sentido común.

2. Identificación de clases Durante esta fase se realiza el proceso de generalización, con el fin de definir las clases y objetos que formarán parte del sistema.

El resultado esperado es el modelo de datos generalizado, como el de la figura 5-16. En ésta, se aprecian las siguientes relaciones entre las clases: de perte-nencia entre encabezado y detalle de la transacción, de uso (uno a muchos) entre personas y el encabezado de transacción, al igual que entre productos y detalle de transacción.

Encabezado de compras

Proveedores

Detalle decompras

ClientesEncabezado

de ventas

Detalle de ventas

ArtículosLínea blanca

Encabezado de compras

Proveedores

Detalle decompras

ClientesEncabezado

de ventas

Detalle de ventas

ArtículosLínea blanca

Relación de pertenencia

Relación de uso

JUAN BRAVO C. 276

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 generalización de clientes y proveedores. La clase productos es una generalización de artículos de línea blanca.

3. Visión externa Significa definir el protocolo del sistema, es decir, todos los mensajes válidos que activarán las funciones de los objetos. La principal herramienta en esta fase es el modelo funcional generalizado, cuyo objetivo es mostrar las interac-ciones entre las clases. Se presenta en la figura 5-17, siguiendo el mismo ejemplo de los puntos anteriores.

Figura 5-17. Modelo funcional generalizado

Observaciones respecto a la figura 5-17:

• Se agregó una nueva clase: ingreso de transacción. Ésta representa el in-greso de un documento directamente en la pantalla del equipo, tal como si estuviéramos llenando una factura.




C/E

Mensaje 1

C/E

Mensajes 4 y 5




C/E

Mensaje 1

C/E

Mensajes 4 y 5






• Se utilizó este símbolo para graficar la clase de ingreso de datos72:

• Se usó la abreviatura C/E para condición de existencia.

¿Por qué darle tratamiento de una clase al ingreso de datos?

Porque refleja de mejor manera la realidad. En la práctica, el ingreso de dife-rentes tipos de transacciones es bastante similar.

Desde el punto de vista de implementación, siempre el ingreso de datos pasa a través de un almacenamiento transitorio. Explícitamente cuando en el proce-samiento batch-interactivo los datos se guardan en una tabla de transacciones del día, e implícitamente 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 diseño.

Visión 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 aplicación, como un mapa, así se puede lograr la necesaria visión global que tanto ayuda en el perfeccionamiento de la aplicación.

72 Incluir todos los datos en la pantalla simulando el documento original equivale a un proceso de desnormalización del modelo de datos.



JUAN BRAVO C. 278

Figura 5-18. Modelo funcional generalizado y detallado


• Se continúa señalando explícitamente la relación de pertenencia, esto por la característica de funcionalidad intercambiable indicada al comienzo del capítulo.

Por ejemplo, el mensaje 1 —que tiene por misión solicitar agregar un nue-vo documento a la clase transacciones— se envió sólo al encabezado, con lo cual también se agregará automáticamente en el detalle (a través 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 artículo, respectivamente.

• La similitud que existe entre las funciones de las clases nos debería llevar a definir un conjunto de funciones generalizadas que tuvieran siempre la misma identificación. Un mensaje implícito es que cada una de estas fun-ciones generalizadas es también una clase en otro nivel de abstracción.

Encabezado de transacción

• Nº documentoFecha Rut persona


Detalle de transacción

• Nº documento• Código artículoCostoCantidad

1 Cálculo total

Productos

1 Agregar2 Consultar3 Imprimir4 Sumar saldo5 Restar saldo

Personas


C/E

Mensaje 1

C/E

C/E

Mensajes 4 y 5


1 Aceptar datos2 Cuadrar totales

Encabezado, detalle y totales según formato

• Código artículoTipo artículo DescripciónÚltimo costoSaldo

• RutNombreDirecciónTeléfono


Por ejemplo, la lista podría incluir:

a) Condición 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) Estadísticas de uso j) Eliminación de ocurrencias sin movimiento k) Respaldo automático l) Reconstrucción automática m) Inicialización n) Auditoría o) Restricciones de acceso

La funcionalidad generalizada ¿puede ser una norma del medio? Se está tra-bajando en la modularidad y se busca intercambiar y comercializar clases, sin embargo, todavía está en proceso de consolidarse. Mientras tanto, es una exce-lente opción darse normas de reutilización al interior de la organización o en pequeñas agrupaciones de empresas.

4. Visión interna En la visión interna se describen minuciosamente cada uno de los tres compo-nentes de la clase —características propias, atributos y funciones— y la tabla de objetos. En la figura 5-19 se muestra la visión interna de la clase productos, incluida en la figura 5-18. Nótese que la tabla de objetos consta solamente de una ocurrencia, con los mismos elementos que la clase.

JUAN BRAVO C. 280

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 función imprimir. También se normaliza la notación de los atributos, por ejemplo, num – 6,2 puede significar: atributo numérico de 6 enteros y dos decimales, con signo.

Figura 5-19. Visión interna de la clase productos

15 Productos (PR)

Propietario: Juan Pérez, diseñador de sistemasEs el maestro de artículos, todos los productos están en una bodega

Creación: 21/4/2008 Expiración: 21/4/2014Variables globales: costo total y descripción

1. Crear : se agrega un artículo. Parámetros: los 5 atributos.2. Consultar : presentación tabular de los datos, búsqueda por

cualquier atributo.3. Imprimir : sin el costo, con corte de control por tipo de

artículo y orden por descripción en cada tipo.Función normal.

4. Suma saldo : suma unidades al saldo y mueve último costo,parámetros: código, unidades y costo.

5. Resta saldo : resta unidades al saldo, parámetros: código yunidades. Si el saldo queda negativo,procedimiento normal.

Código del artículo : numérico largo 5. Es la llave principalTipo de artículo : numérico largo 2, asociado a la tabla de

traducción 18Descripción : alfanumérico largo 30Último costo : numérico largo 6Saldo : numérico largo 6, con signo. Si queda negativo,

procedimiento normal

15 Productos (PR)

Propietario: Juan Pérez, diseñador de sistemasEs el maestro de artículos, todos los productos están en una bodega

Creación: 21/4/2008 Expiración: 21/4/2014Variables globales: costo total y descripción











Código del artículo : numérico largo 5. Es la llave principalTipo de artículo : numérico largo 2, asociado a la tabla de

traducción 18Descripción : alfanumérico largo 30Último costo : numérico largo 6Saldo : numérico largo 6, con signo. Si queda negativo,

procedimiento normal

Tabla de objetos, clase productos Objeto Atributos Funciones

Artículos de línea blanca


En la siguiente figura, número 5-20, vemos la descripción de la clase Ingreso de transacción, señalada en el punto anterior.

Figura 5-20. Visión interna de la clase ingreso de transacción

Para completar el sistema de inventarios presentado en la figura 5-18, deber-íamos describir las otras clases e incluir la tabla de objetos de cada una:

• Encabezado y Detalle de transacción: van juntas porque hay una relación de pertenencia entre ellas.

• Personas: podría suceder que la descripción de clientes y proveedores sea igual, sin diferencias entre sí, en tal caso, la tabla sería similar a la de pro-ductos de la figura 5-19.

Dos niveles de funcionalidad

En la OO existen dos niveles de definición de funcionalidad. En el primer nivel se asocian procedimientos lógicos a atributos individuales de un objeto, como la verificación de existencia entre las clases transacción y personas de la



















Tabla de objetos, clase Ingreso de transacción Objeto Atributos Funciones

Ingreso de ventas Indicar stock del producto Deben cuadrar totales, stock mayor a unidades por vender. Mensaje 5

Ingreso de compras Crear proveedor y artículo si no existen. Mensaje 4

JUAN BRAVO C. 282

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 artículo u obtener un informe. En ambos casos, la funciona-lidad puede ser generalizada, en otras palabras, serían clases en otro nivel de abstracción.

5. Interfaz humana Especialmente en el orientación a objetos el diseño de la interfaz humana es vital para lograr el objetivo final de tener una buena aplicación en funciona-miento pleno.

En el capítulo 2, acerca de ingeniería de software, dedicamos una sección al diseño de estas interfaces.


5.6. INCORPORACIÓN DE LA TECNOLOGÍA DE

OBJETOS

Para una incorporación exitosa de la tecnología de objetos en la organización, es indispensable considerar su cultura y nivel de madurez, especialmente en cuanto a respetar normas internas y con el medio73.

Veremos: 1. Personalización del objeto 2. Reutilización de código 3. Construcción de un modelo de objetos

1. Personalización del objeto La forma ideal de trabajo en la orientación a objetos es entre pequeños equi-pos (teams) donde participen usuarios y profesionales de la informática.

Como técnica de definición es muy útil “personalizar” el objeto, mejor aún, pensar que “yo soy el objeto” y comenzar a hacernos preguntas; por ejemplo:

¿Quién soy? ¿Para qué sirvo?

¿Qué atributos tengo? ¿Qué funciones cumplo?

¿Cuándo realizo esa función? ¿Cuál es el valor agregado que aporto?

¿Qué información necesito de otros objetos? ¿Qué información necesito para cumplir una función?

A través de las cuales se va aclarando el entorno y luego el contenido del obje-to, tal como en el enfoque sistémico.

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 técnica para refinar la comunicación entre los objetos… y entre las personas.

73 Es lo que vimos en el capítulo 2 sobre el cambio cultural en la organización y en el capítulo 5 acerca de incorporación de nuevas tecnologías.

JUAN BRAVO C. 284

Es también una buena práctica para evitar confundir el contenido con la rela-ción. Separar la esencia del objeto de su comportamiento en un instante del tiempo, igual que entre los seres humanos.

2. Reutilización de código Una idea largamente acariciada es la reutilización de código, lo que en el caso de la orientación a objetos es perfectamente factible, porque cada función in-corporada al objeto puede ser realizada utilizando los servicios de una rutina catalogada a través de una buena parametrización o mediante mensajes. Aun-que también es una alternativa la generación de código ad-hoc con una herra-mienta de productividad.

La reutilización del código tiene en Japón una prioridad tan alta que aproxi-madamente el 75% de cada aplicación se construye con componentes reutili-zables; en comparación con el 25% de reutilización en Estados Unidos.

En el departamento de sistemas de su empresa, ¿qué porcentaje de las aplica-ciones se construye con código reutilizable?…

El principal beneficio de la reutilización, además de la mayor economía en el mediano plazo, es el perfeccionamiento continuo del código de cada función.

Para lograr productividad tenemos que abandonar la artesanía en la programa-ción, donde cada programa es, a veces, una obra de arte irrepetible, desperdi-ciándose lamentablemente todo el tremendo aprendizaje que el programador obtuvo en ese código, ¡cuánta mayor eficiencia podemos lograr al perfeccio-nar muchas veces las mismas rutinas! No es sólo corregir un error, sino que un esfuerzo sistemático de mejoramiento de una clase.

Para incentivar la reutilización, no es suficiente con una arenga del jefe de informática a sus subordinados. Es indispensable crear ambiente y dar señales claras en esa dirección, como en Japón, donde regularmente se proveen, entre otras, las siguientes condiciones:

• Incentivos económicos para quienes completen una aplicación con un alto componente de reutilización.

• Una biblioteca de componentes reutilizables a cargo de personal de presti-gio, que efectúe control de calidad de alto nivel para cada función aceptada. • Incentivos cuando se construye una función que será reutilizable

El medio cultural latinoamericano no es proclive a estas iniciativas, no lo digo para desalentar, sino para tomar en cuenta la realidad y adaptar apropiadamen-te las estrategias, reconociendo de antemano el verdadero esfuerzo de cambio


que será necesario realizar. Al principio puede ser difícil y caro, aún así es una buena inversión, porque los retornos son altos en el mediano y largo plazo.

Como técnica, es muy útil comenzar con equipos piloto que muestren rápida-mente resultados en la línea de reutilización.

Desde la estructura: desarrolladores e integradores

Con la introducción de herramientas de productividad para el ámbito cliente–servidor —las cuales permiten la programación orientada a objetos— está comenzando a ser aplicada una nueva diferenciación: desarrolladores e inte-gradores. Los desarrolladores construyen clases, actividad reservada a los programadores más hábiles de la instalación. Los integradores toman las cla-ses y las adaptan para crear objetos de aplicaciones particulares, eventualmen-te ellos podrían completar una aplicación con muy poca programación. Esto es muy interesante, porque en la práctica significa que en un equipo de integra-dores pueden participar usuarios.

En este esquema, las clases representan código reutilizable.

3. Construcción de un modelo de objetos ¿Cómo se construye un modelo de OO? Se puede implementar con programa-ción tradicional o te tipo OO, bases de datos o cualquier otra forma, porque el diseño es independiente de la implementación tecnológica.

Más concretamente, supongamos que ya tenemos listo nuestro diseño, enton-ces podemos implementarlo con:

• Sistemas Administradores de Bases de Datos orientados al objeto, aunque el apoyo a las aplicaciones administrativas todavía es bajo. Es posible que esta sea en algún momento la mejor opción, en la medida que se desarro-llen y generalicen productos apropiados.

• Herramientas CASE orientadas al objeto, las que pueden ayudar en el mode-lamiento y generar código en ambientes con o sin bases de datos.

• Bases de datos relacionales a través de herramientas especiales, propias o externas.

• Adaptaciones al código generado por otras herramientas de productividad. • Lenguajes de tercera generación tales como Cobol y RPG, buscando

amplia aplicación de código reutilizable. • Otras alternativas…

JUAN BRAVO C. 286

Siempre en la línea de entregar en estas páginas un mínimo indispensable, la simplicidad final del concepto, no se ha querido romper la unicidad incorpo-rando particularizaciones, por ejemplo, transformar las clases en entidades concretas o tomar los atributos desde un diccionario completo de los datos de la organización.

Una reflexión sobre la mayor naturalidad de la tecnología de objetos: hemos llegado hasta un punto donde estamos incorporando al modelamiento una se-rie de características típicamente sociales o humanas, como la personalización de objetos, el enfoque sistémico, la comunicación de mensajes, la identidad personal y el proceso de generalización, ¿qué viene después? Creemos que más estándares y mayor énfasis en trabajar metodológicamente.


CAPÍTULO 6. UNIFIED MODELING

LANGUAGE (UML)

JUAN BRAVO C. 288

Capítulo 6. Unified Modeling Language (UML)

UML es una notación, no un método. 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 aproximación al diseño centrada en el problema con los casos de uso. El Diagrama de Caso de Uso nos da el punto de entrada pa-

ra analizar los requisitos del sistema y el problema que necesi-tamos solucionar.

Popkin Software and Systems http://es.tldp.org

UML significa literalmente Lenguaje Unificado de Modelamiento, aunque la idea queda mejor expresada con: Modelamiento Visual del Software, expre-sión que se está utilizando cada vez más en español. UML está orientado a la especificación, visualización y documentación de los productos de software. Se le considera parte del desarrollo tecnológico de un modelo de negocios, enfocado en la definición de los requerimientos de la aplicación.

Esta es la sexta competencia considerada para apoyar la elaboración de mo-delos de una solución de software, tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). Es indis-pensable que el analista maneje UML porque es el único estándar en esta materia, por lo tanto, también 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).






CAPÍTULO 6. UML




UML surgió de los aportes combinados de tres pioneros en el campo del mo-delamiento orientado a objetos, los doctores Grady Booch, Jim Rumbaugh e Ivar Jacobson, a petición de la OMG (Object Management Group), organiza-ción creada por las empresas líderes mundiales de la industria del software (entre las cuales se encuentran IBM, Unisys, Alcatel, Toshiba y Microsoft) destinada a fijar estándares en la industria con la tecnología de objetos.

La primera versión de UML estuvo disponible en 1997. Ha sido perfeccionado en el tiempo y la versión actual es la 2.0.

Es mucho lo que se puede decir de UML, en este capítulo veremos los mode-los y en el anexo 7 podrá ver un caso completo, el cual puede bajar desde la página www.evolucion.cl.

Veremos: • Modelos de UML • Aplicación de los modelos UML en la etapa de análisis • Aplicación de los modelos UML en la etapa de diseño

JUAN BRAVO C. 290

6.1. MODELOS DE UML

La versión 2.0 de UML tiene 13 tipos de diagramas.

Diagramas de estructura, los cuales se concentran en los elementos que deben existir del sistema:

1. Diagrama de clases 2. Diagrama de componentes 3. Diagrama de objetos 4. Diagrama de estructura compuesta 5. Diagrama de despliegue 6. Diagrama de paquetes

Diagramas de comportamiento, utilizados para reflejar las acciones del siste-ma:

7. Diagrama de actividades 8. Diagrama de casos de uso 9. Diagrama de estados

Diagramas de Interacción, 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 colaboración 12. Diagrama de tiempos 13. Diagrama de vista de interacción

También utiliza un glosario: incluye la definición de todos los términos que se emplean en los modelos de UML, es aplicable en todas las etapas del desarro-llo.

En UML se usa el término artefactos para referirse a diversas agrupaciones de modelos, a modelos individuales o a cualquier elemento que sea identificado individualmente. Cuando en el contexto de UML se usa la palabra sistema, es porque hace referencia al sistema computacional.

Veremos: 1. Casos de uso 2. Uso de herramientas


1. Casos de uso Los casos de uso (use case) son los modelos más conocidos de UML, permi-ten mostrar las interacciones con el usuario. Tal como plantea Ivar Jacobson: “es una narración que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema computacional para completar un proceso”. También es cualquier punto de interacción con el computador, principalmen-te detectados desde las actividades del flujograma de información.

El caso de uso describe lo que importa al usuario, desde su perspectiva, es un ítem específico 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 narración dice: se ingresa la identificación del cliente, no explicamos que sucede si esa identificación es inválida, simplemente se-guimos el curso normal de los sucesos. En algunos casos, las excepciones podrían dar origen a otros casos de uso.

Se aplican a la definición de los requerimientos computacionales del sistema de información. Los casos de uso pueden ser llamados: • De alto nivel, explicados en dos o tres oraciones. • Expandidos, pueden contener cientos de oraciones, se incorpora una des-

cripción minuciosa destinada a la implementación computacional.

Por ejemplo, en la figura 6-1 se aprecia que en una tienda minorista, un vendedor consulta en su terminal por la información de un cliente. El ambiente donde suceden los hechos es el dominio. Incorpora el concepto de actor, es decir, alguien fuera del sistema que interactúa con la aplicación, en este caso el vendedor.

Figura 6-1. Ejemplo de un caso de uso de alto nivel

Consultar situación del cliente

Saldo de crédito y posibilidades de cuotas.

Apoyo en realización de cálculos respecto a financiamiento.

Terminal en la tienda

Vendedor

JUAN BRAVO C. 292

2. Uso de herramientas Existe una amplia gama de herramientas que ayudan en los modelos de UML (Visio, Rational, UML Studio, Enterprise Architect y muchas otras). La reco-mendación es usarlas, realmente facilitan el trabajo y si el sistema es grande, son indispensables. Además, tienen la ventaja de generar el código de la apli-cación en forma automática y son vitales para la comunicación de los modelos (generalmente en XML).

Existe en Internet una amplia variedad de software libre para trabajar con UML, incluso la mayoría de estas herramientas permiten generar código, por ejemplo: ArgoUML, BOUML, Fujaba, gModeler MonoUML y otras.


6.2. APLICACIÓN DE LOS MODELOS UML EN LA

ETAPA DE ANÁLISIS

El siguiente ejemplo muestra en la práctica el uso simplificado de los principa-les modelos de UML en la etapa de análisis74. Planteados en el espíritu del método GSP de trabajar con el mínimo indispensable, para que efectivamente pueda ser aplicado en la mayoría de las organizaciones.

En el anexo 7 se pueden apreciar estos modelos para una aplicación 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. Visión dinámica del sistema 7. Diagrama de estado 8. Contratos

1. Diagrama de casos de uso El diagrama de casos de uso representa una agrupación de casos de uso, por ejemplo, todos los casos de uso que tienen relación con un proceso incluido en el flujograma de información. 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 más de un caso de uso.

En el desarrollo en espiral, se espera que el universo completo de casos de uso esté levantado al menos como diagramas de casos de uso. Entonces, los casos de uso seleccionados para la respectiva vuelta de la espiral se transforman en casos de uso expandidos.

El diagrama de casos de uso incluye uno o varios actores (que pueden ser per-sonas u otros sistemas computacionales identificados con el símbolo tipo di-bujo de niño), un dominio (en este caso terminales del área de adquisiciones) y una acción con un verbo en infinitivo dentro de cada óvalo.

74 Más detalle en libro Gestión de proyectos de procesos y tecnología.

JUAN BRAVO C. 294

Figura 6-2. Ejemplo de un diagrama de casos de uso

En este diagrama se utilizan dos características que provienen de la orienta-ción a objetos:

• Reutilizar casos de uso, en este caso se usa la forma <<include>> sobre una línea punteada que apunta hacia el caso de uso común. Señalan Stevens y Pooley (2002, p. 120): “El caso más vital es cuando se puede sacar factor común del comportamiento de dos o más casos de uso originales o (mejor todavía) cuando se descubre que puede implementar parte de uno de los ca-sos de uso utilizando un componente. Por ejemplo, ambas descripciones de los casos de uso “Tomar prestada copia de libro” y “Ampliar préstamo” mencionan la necesidad de comprobar si existe una reserva sobre el libro”. Entonces deciden incorporar esa necesidad común, “Comprobar reserva” como otro caso de uso referenciado por los dos anteriores.

• Separación del comportamiento variable, en este caso aplica la forma <<extend>> sobre una línea punteada que apunta hacia el caso de uso ori-ginal. Explican Stevens y Pooley (2002, p. 124): “Si un caso de uso incor-pora dos o más escenarios con diferencias significativas, pueden ocurrir va-rias cosas diferentes dependiendo de las circunstancias, se puede decidir que sería más claro mostrarlos como un caso principal y uno o más casos

Cotizar

Jefe deAdquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

IngresarO/C

Terminales del área de Adquisiciones


O/C = Orden de Compra


secundarios. Cuándo hacer esto es un problema de juicio, ya que siempre se pueden mostrar situaciones variables en un caso de uso. Por ejemplo, se podría separar “Tomar prestada copia de libro” en el caso normal en el que al usuario se le permite tomar prestado el libro de la situación inusual en la que al usuario no se le permite tomar prestado el libro porque él o ella ya tiene prestados el máximo número de artículos”. Entonces deciden sacar esa excepción como otro caso de uso llamado “Rechazar préstamo” y la re-lación extend señala 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 narración es breve. Permi-te conocer un poco del requerimiento, algo de la acción, actor(es) y dominio, tal como se aprecia en la figura 6-3.

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 narración en todo detalle e incluye las interfaces visuales. Recuérdese que se usa aquí el concepto de “curso normal de los eventos”, las excepciones se anotan al final para no romper la secuencia de la historia. En la figura 6-4 se aprecia un ejemplo del caso de uso expandi-do Ingresar orden de compra.

Ingresa la Orden de Compra a partir de los documentos decotización a proveedores.

La O/C queda disponible para ser enviada al proveedor luego de la aprobación electrónica por el jefe de adquisiciones

Ingresar O/C

Terminal en bodega


JUAN BRAVO C. 296

Figura 6-4. Caso de uso de expandido Ingresar orden de compra

Tiene dos columnas: acción del actor y respuesta del sistema, las excepciones van aparte. No siempre una acción del actor tiene respuesta, como la acción 1: “Tomar la O/C desde el archivador” (que está en algún 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 mayúsculas entre paréntesis (A, B, …) para identificar la ubicación del respec-tivo campo en la interfaz visual, tal como se aprecia en la figura 6-5 (copiada desde el anexo 7).

1. Si el número de O/C ya existe, vea caso de uso “Corregir Correlativo”. 2…Incluye interfaces detalladas de E/S

Ingresar O/C

Terminal del Administrativo de AdquisicionesAdministrativo

de Adquisiciones

Resumen: (el mismo del caso de uso de alto nivel).Funciones relacionadas:

Curso Normal de los eventos

Excepciones:

Acción del actor Respuesta del sistema

1. Tomar la O/C desde el archivador2. Ingresar Nº O/C en (A) 3. Verifica correlativo y envía 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 línea: Para cada línea:

7. Ingresar el código de 8. Verifica existencia del producto, producto en (H) obtiene y despliega la descripción

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 línea 11….


Figura 6-5. Ejemplo de Interfaz visual detallada

4. Modelo conceptual El modelo conceptual define responsabilidades y el dominio del sistema com-putacional, al comienzo asociado a los casos de uso identificados. Es un mo-delo que se va construyendo en paralelo con los casos de uso.

Identifica los conceptos más relevantes del mundo real en el dominio respec-tivo: roles de personas, tipos de documentos o elementos físicos. También identifica las asociaciones entre conceptos con palabras de enlace: usa, regis-tra en, almacenado en, pagado por, contenida en… Se trazan líneas entre los conceptos para representar este detalle.

En esta etapa, una recomendación es incorporar en el modelo el máximo de conceptos y el mínimo de asociaciones.

Las características del modelo conceptual son muy similares al modelamiento tradicional de datos.

En las asociaciones entre los conceptos se da multiplicidad o cardinalidad.


Fecha Recepción

RUT Proveedor -



AAAAAAAA

CCCCCCCCBBBBBBBB

DDDDDDDD

EEEEEEEE FFFFFFFF

GGGGGGGGDirección Proveedor


HHHHHHHH



GrabarGrabar


Total acumulado



Cerrada

Anulada

SSSSSSSS TTTTTTTT

UUUUUUUU


AnularAnular

WW

SalirSalir

XX



e-Mail

YY ZZ

LLLLLLLLLLLLLLLL

XXXX

Interfaz de Entrada

JUAN BRAVO C. 298

Se expresa de la siguiente forma:

* : cero o más (muchos) 1..* : uno o más 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 tendría la forma que se indica en la figura 6-6:

Figura 6-6. Ejemplo de modelo conceptual sistema de compras


• Una O/C está compuesta por 1 ó más líneas de O/C. A su vez, una línea 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 ó más encabezados de O/C.

• Una línea de O/C contiene un producto. Un producto existe en 0 ó más líneas de O/C.

• Un producto existe en 1 bodega. Una bodega almacena 0 ó más productos.

Obsérvese que aparece, con un rombo negro, una asociación de composición, equivalente a la relación de pertenencia (que se marca con una línea más grue-sa) del modelamiento de datos. En la composición, también llamada unicidad, una línea de la O/C no puede existir sin su encabezado y viceversa.

Encabezado de O/C

Proveedores

Líneas de la O/C

Productos

* 1

* 1

1

1..*

Bodega

*

1

compuesta por

se asocia a

contiene

existe en contiene

existe en

existe en

almacena

Encabezado de O/C

Proveedores

Líneas de la O/C

Productos

* 1

* 1

1

1..*

Bodega

*

1

compuesta por

se asocia a

contiene

existe en contiene

existe en

existe en

almacena


En los conceptos también existen atributos, tal como se aprecia en el modelo de la figura 6-7, siguiendo con nuestro ejemplo de la orden de compra.

Figura 6-7. Ejemplo de modelo conceptual con atributos

5. Diagrama de secuencia del sistema El objetivo del diagrama de secuencia es identificar las operaciones de la aplica-ción, las que luego darán origen a los mensajes y al protocolo del sistema.

Con base en la narración realizada en el caso de uso, se identifican las operaciones de la aplicación, aquellas que obligarán al sistema computacional a hacer algo y que afectarán a uno o más conceptos de aquellos incluidos en el modelo concep-tual. A este nivel de especificación, la aplicación sigue siendo como una caja ne-gra de la cual sólo 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 narración del caso de uso.

Líneas de la O/C

UnidadesPrecio

Bodega...


Proveedores

RutNombre

compuesta por

* 1

existe en contiene

* 1

contiene existe en

*

1

existe en

almacena

Productos...

JUAN BRAVO C. 300

Figura 6-8. Ejemplo de diagrama de secuencia

¿Qué es una operación? Una operación es un mensaje, un mandato para que algo se ejecute, provoca que algo suceda fuera de la frontera del caso de uso. Específicamente, activa una o más funciones en el sistema.

Al principio de la especificación, la aplicación 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, produciéndose una estructura de mensajes.

6. Visión dinámica del sistema Este diagrama es un resumen de las operaciones del sistema, la gráfica sugiere que al unir esta funcionalidad con el modelo conceptual, lograremos algo cen-tral de la orientación a objetos: el encapsulamiento, es decir, un sólo todo (cla-se u objeto) con los atributos y los métodos.

Cuando se trata del primer caso de uso que estamos desarrollando en un sis-tema, el diagrama de secuencia y la visión dinámica son iguales, desde el se-gundo se diferencian porque la visión dinámica es acumula las operaciones de los diferentes casos de uso, tal como se aprecia en la figura 6-9.

Ingresar Nº de O/C

Dar OK a la línea




Ingresar cantidad


Figura 6-9. Ejemplo de diagrama visión dinámica del sistema

Algunos comentarios respecto a los diagramas de secuencia y visión dinámica 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, más bien llamadas a operaciones, porque corresponden a la estructura de mensajes del diagrama de clases (que ya veremos).

• La nomenclatura es la de orientación a objetos. • Los mensajes de la visión dinámica del sistema son mensajes que llegarán

a varias clases, cada una tiene la estructura de atributos y funciones.

7. Diagrama de estado El diagrama de estado de UML representa gráficamente el estado del caso de uso antes y después de cada una de sus operaciones. En la figura 6-10 se ob-serva aplicado a nuestro ejemplo de ingreso de una orden de compra.

Sistema

Ingresar Nº de O/CIngresar código de productoIngresar cantidadDar OK a la línea

Caso de uso Ingresar O/C

Caso de uso Aprobar cotización

Ingresar Nº de cotizaciónDar OK al documento...

JUAN BRAVO C. 302

Figura 6-10. Ejemplo de diagrama de estado

El diagrama de estado aplica principalmente en aplicaciones de ingeniería y se utiliza poco en el ámbito de los sistemas de información administrativos, por lo tanto, no lo incluimos en el curso normal de los eventos de los modelos a utilizar en el método GSP.

8. Contratos Los contratos detallan cada operación y existirán 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.

Ingresar Nº de O/C

Terminar la O/C

Ingresar línea de O/C

En espera de la O/C

Introducción de líneas

En espera del cierre

Imprimir la O/C

Ingresar Nº de O/C

Terminar la O/C

Ingresar línea de O/C

En espera de la O/C

Introducción de líneas

En espera del cierre

Imprimir la O/C

ContratoIdentificación: nombre de operación y parámetrosResponsabilidades: descripción informal de las responsabilidades u objetivos de la operaciónTipos de datos: conceptos que afecta o clasesReferencias cruzadas: enlaces con otras funciones del sistema o casos de uso.Notas: indicaciones para diseño, algoritmos (tal como el cálculo de dígito verificador) y otros datos.Excepciones: ¿qué sucede si...? y otros casos excepcionales.Salida: Mensajes o registros que se envían fuera del sistema.Precondiciones: Supuestos acerca del estado del sistema antes de ejecutar la operación.Poscondiciones: Indicación de como quedó el sistema después de la operación.

• Poscondición 1 ...• Poscondición 2 ...• Poscondición n ...


Figura 6-11. Forma de un contrato por operación

Una clave para entender los contratos son las poscondiciones, es decir, como quedó el sistema después que se ejecutó la operación. Es como la fotografía que se toma después de un suceso. Veamos el ejemplo de la figura 6-12 para nuestro caso de ingreso de orden de compra.

Figura 6-12. Ejemplo de contrato en dar OK ingreso línea

Se identificó, en tiempo verbal pasado, cómo fueron afectados los conceptos tras la operación (poscondiciones). Un contrato sin poscondiciones es una alerta de error, tal vez en la definición de la operación.

ContratoIdentificación: Dar OK al ingreso de la líneaResponsabilidades: con cada ingreso de línea los conceptos deben ser consistentes.Tipos de datos: afecta a los conceptos Encabezado de O/C y Detalle de O/C.Referencias cruzadas: no hayNotas: nada especialExcepciones: la no existencia de la línea en el sistema ya fue validada con el ingreso de O/C.Salida: no hayPrecondiciones: no existe la línea.Poscondiciones:

•Se creó una línea en el concepto detalle.• Se actualizó el contador de líneas en el encabezado.• Se actualizó la asociación entre encabezado y detalle de O/C.

JUAN BRAVO C. 304

6.3. APLICACIÓN DE LOS MODELOS UML EN LA

ETAPA DE DISEÑO

El siguiente ejemplo muestra en la práctica el uso simplificado de los principa-les modelos de UML en la etapa de diseño75.

Veremos: 1. Diagrama de diseño de clases 2. Diagrama de colaboración

1. Diagrama de diseño de clases El modelo de UML que se emplea para representar las relaciones entre las clases es el Diagrama de Diseño de Clases. Corresponde a la visión interna de la aplicación. Nace desde el modelo conceptual e incorpora las funciones ne-cesarias para cumplir con el objetivo de los casos de uso. En la figura 6-13 se observa este diagrama para el ejemplo de la orden de compra.

Figura 6-13. Ejemplo de diagrama de diseño de clases

75 Más detalle en el libro Gestión de proyectos de procesos y tecnología.

Líneas de la O/C

UnidadesPrecio

Agregar línea

Productos...

Bodega...


Crear líneaImprimir

Proveedores

RutNombre

Crear proveed.Modificar Rut

Modificar nombre1

1..*

compuesta por

se asocia a

* 1

existe en contiene

* 1

contiene existe en

*

1

existe en

almacena


2. Diagrama de colaboración Para cada operación del caso de uso seleccionado se presenta un diagrama de colaboración y detalles de implementación76.

• Diagrama de colaboración: cada operación detallada en un contrato se desarrolla en detalle señalando las solicitudes (o pedidos) entre objetos (principalmente del modelo de datos y pantallas).

• Detalles de implementación: se responde a ¿qué clases podemos utilizar? Ya sea de la misma instalación o del medio, es decir, hacer una revisión de la biblioteca de clases77 (que en un esquema de orientación a objetos es un requisito), por ejemplo, la condición de existencia. Corresponde al detalle de cada clase e instancias (objetos) específicas en una tabla de diferencias.

En la figura 6-14 se presenta un ejemplo de diagrama de colaboración para el ejemplo del ingreso de orden de compra.

Figura 6-14. Ejemplo de diagrama de colaboración

76 En este método de desarrollo aplicamos la técnica de espiral, donde se diluye un poco la independencia de la implementación tecnológica, por este motivo se prefiere avanzar en ca-racterísticas de la implementación a nivel del diseño. 77 Se supone la existencia de la biblioteca de clases.

Operación: Dar OK al Ingreso de la línea de O/C

Ingresar producto(cód, cant, pre)

1: Crear línea de O/C(cod, cant, pre)

1.1: Crear (cod, cant, pre)

Terminal del administrativo

Encabezado de O/C

Líneas de la O/C

JUAN BRAVO C. 306

CAPÍTULO 7. HERRAMIENTAS DE LA

TECNOLOGÍA DE

INFORMACIÓN


Capítulo 7. Herramientas de la tecnología de información

La manera ideal de construir un nuevo sistema es tomar algunos componentes existentes y conectarlos unos con otros. Por su-

puesto, la conectividad es la propiedad que permite hacer esto. La metáfora sugiere correctamente que esto es sólo en parte una propiedad de los elementos conectados. Los componentes tienen que ser elementos que completan las necesidades del sistema en su totalidad. más que eso, tienen que ser compatibles unos con otros y esto depende de la presencia de una arquitectura ade-

cuada.

Perdita Stevens y Rob Pooley (2002, p. 15)

Las Herramientas de la Tecnología de Información son todos los productos de software que permiten aumentar la productividad de especialistas y usuarios. Éstas incluyen desde poderosos procesadores de texto hasta sofisticados siste-mas administradores de bases de datos, pasando por múltiples productos de ayuda directa a usuarios y especialistas en desarrollo de aplicaciones.

Esta es la séptima competencia considerada para apoyar la elaboración de modelos de una solución de software, tal como se aprecia en la siguiente fi-gura (en la introducción se incluyó la visión global de las competencias). El analista debe tener una visión global de las herramientas de la tecnología de información y debe conocer en detalle las que apoyan directamente su labor. Es una responsabilidad profesional para aumentar la productividad del mo-delamiento y para compartir en equipos de trabajo.






CAPÍTULO 6. UML



JUAN BRAVO C. 308

En el caso de las herramientas de ayuda en la producción de software convie-ne actuar con prudencia, por ahí aparecen mensajes del siguiente tipo: es posi-ble que las aplicaciones se construyan casi solas o que el mismo usuario pue-da construir su propio software sin depender del programador. Esos y otros mensajes se demuestran con aplicaciones muy pequeñas y estructuradas, ex-trapolándose las conclusiones al resto del software. Sin embargo, siendo váli-do, esa es una parte pequeña de la realidad, lo habitual es que el especialista en informática tenga la responsabilidad de construir aplicaciones de mayor nivel de complejidad, en las cuales la herramienta será sólo un apoyo y siem-pre que se pueda integrar al esquema de desarrollo del departamento de siste-mas en particular.

Para tranquilidad de muchos programadores, hasta hoy no se ha visto el reem-plazo de un especialista por una herramienta de productividad. Sí ocurre que la incorporación de la nueva herramienta acarrea a veces nuevas contratacio-nes, debido a la complejidad de su manejo y al aprovechamiento de las nuevas oportunidades que genera su mayor potencial.

Abordaremos el tema con una introducción general a los lenguajes de cuarta generación, para apreciar la evolución que derivó en las herramientas de la tec-nología de información. Luego estudiaremos las herramientas de uso específico, es decir, aquéllas orientadas a temas precisos, como procesadores de texto, pla-nillas electrónicas o consultas de bases de datos; algunos productos los pueden usar directamente los usuarios finales. Después, revisaremos las soluciones de software generalizadas, para concluir con las herramientas de apoyo para la pro-ducción de software, más conocidas como herramientas CASE.

Veremos: • Evolución de los lenguajes de computador • Herramientas de uso específico • Una pirámide de soluciones • Herramientas de apoyo para la producción de software


7.1. EVOLUCIÓN 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 todavía se trabaja como hace 30 años en máquinas un millón de veces más poderosas que las de esa época. No obstante, la industria de la com-putación ya se percató de este hecho y comenzó a desarrollar una amplia varie-dad de nuevas herramientas, para aumentar la productividad e incorporar al usuario final en el proceso informático.

Estas nuevas herramientas fueron agrupadas inicialmente bajo el nombre len-guajes de cuarta generación y más recientemente, se les comenzó a llamar herramientas de productividad, nombre que a veces compite con el de herra-mientas de desarrollo cliente–servidor. Independientemente de las denomina-ciones, las nuevas herramientas incluyen una amplia variedad de nuevos produc-tos: procesadores de texto, planillas electrónicas, administradores de bases de datos, herramientas CASE, Workflow, Groupware y otras. En las siguientes pági-nas se presenta una clasificación más acabada de estos productos.

El término lenguaje de cuarta generación puede ser confuso, porque da la idea de un simple lenguaje de programación más avanzado. Es decir, resulta insuficiente para reflejar la riqueza y amplitud de los nuevos productos de software orientados tanto a usuarios finales como a profesionales de la in-formática. De aquí que el título del capítulo fuera genérico: herramientas de la tecnología de información.

Para el desarrollo de estos lenguajes ha sido necesario romper con el criterio de eficiencia de una aplicación en cuanto a mínimo uso de tiempo y memoria, lo cual ya no es tan importante y a futuro será una consideración menor, debido al substancial mejoramiento del hardware. Además, la participación 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 especificación de requerimientos o trabajando juntos, directamente en el computador.

Crisis del desarrollo

Existe desde los inicios de la computación una crisis de productividad de las áreas de sistemas, se manifiesta en largas “colas” de aplicaciones pendientes por

JUAN BRAVO C. 310

desarrollar, las que con frecuencia llegan a representar más de 5 años de trabajo. Desde el punto de vista del usuario ejecutivo, la solución significa “hacer traba-jar” al computador, dejando de lado largas esperas, reuniones, especificaciones y cambios de especificaciones por obsolescencia de las anteriores.

Es cierto que los nuevos lenguajes ayudan pero la gran respuesta es incorporar método, tal como vimos en el capítulo 1.

Junto con el aumento de la capacidad del hardware, aunque sin coincidir con la aparición de nuevas generaciones de computadores —caracterizadas por equi-pos construidos con tubos en la primera generación, transistores en la segunda y circuitos integrados en la tercera— han surgido varios niveles de lenguajes: de máquina, simbólicos, de alto nivel, de cuarta generación y lo que hemos llama-do provisoriamente las nuevas herramientas.

También está en experimentación lo que denominan una quinta generación, donde se estudia la inteligencia artificial. Se espera que los sistemas produci-dos en esta quinta generación sean capaces de aprender de sus errores, recono-cer mensajes incompletos, tomar cierto grado de decisiones y crear sus pro-pios procedimientos en la resolución de problemas. La quinta generación de lenguajes no será analizada aquí porque excede los objetivos de este libro; además, aún está lejos de alcanzar resultados prácticos, porque busca copiar capacidades humanas, donde intervienen emociones, sensaciones, motivacio-nes, antecedentes históricos, diversas energías o fenómenos culturales.

En la figura 7-1 están señaladas a la izquierda las primeras cuatro categorías; la última y más reciente, las nuevas herramientas, se indica arriba, con puntos sus-pensivos, porque realmente ignoramos todavía su potencial.


Figura 7-1. Clasificación de lenguajes de computador

Veremos: 1. Lenguajes de máquina 2. Lenguajes simbólicos 3. Lenguajes de alto nivel 4. La cuarta generación de lenguajes 5. Las nuevas herramientas

… …Groupware o workflow Herramientas cliente/servidorImágenes Integración total

Gráficos Generación de aplicacionesBases de datos simples Herramientas CASEPlanillas electrónicas Bases de datos u objetosProcesadores de textos Ciclo completo de desarrollo

Lenguajes de máquina

OFFON

Muchas instruccionesMapa de memoria

Ejecutable

Lenguajes Simbólicos

Códigos de instrucción simbólicosUso de símbolos para variables

CompilaciónMacros

Lenguajes de alto nivel

Código compilado o interpretadoBajo número de instrucciones

COBOL/FORTRAN/C…Muy poderoso

Portable

Lenguajes de cuarta

generación

Amistosos y Productivos

De uso específico Para construcción de aplicaciones

Las nuevas herramientas

JUAN BRAVO C. 312

1. Lenguajes de máquina A este nivel, la programación se realiza trabajando primero en binario y más adelante en hexadecimal, hasta llegar a usar nemotécnicos. Se controla cada variable según su posición en memoria, lo cual obliga a mantener un mapa del uso de memoria.

El lenguaje de máquina se caracteriza por proporcionar un conjunto de muchas instrucciones elementales. Por ejemplo, un programa simple tendrá probable-mente varios miles de instrucciones, producto de la desagregación con que obli-ga a programar el lenguaje; la simple operación C = A + B utiliza entre cinco a diez sentencias.

El programa producido con el lenguaje de máquina viene a ser un objeto que se ejecuta directamente, sin un proceso de compilación. Provee máxima eficiencia, porque el uso de recursos puede minimizarse y porque es extremadamente cer-cano a la máquina, no existiendo portabilidad, excepto para procesar en otro computador con el mismo procesador.

2. Lenguajes simbólicos 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 símbolos, haciendo abstracción de su ubicación en memoria. El programador utiliza códigos de instrucción simbólicos, donde cada uno es un nemotécnico de la propia función de la instrucción (por ejemplo: en ASSEMBLER IBM, AGO es un salto incondicional y AIF es un salto condicional).

Se incorpora también al lenguaje simbólico el concepto de subprograma.

Una extensión de este lenguaje son las macros, las cuales son conjuntos de ins-trucciones que pueden ser llamadas desde cualquier programa. Permiten realizar funciones de entrada de datos, impresión y otras. Por medio de las macros, el lenguaje simbólico se acerca bastante al lenguaje de alto nivel.

Aunque la portabilidad es substancialmente mayor que en los lenguajes de máquina, aún el lenguaje simbólico está muy ligado al hardware particular don-de reside.

Para ser ejecutado, el programa en lenguaje simbólico debe ser compilado, ob-teniéndose un programa objeto en lenguaje de máquina que todavía es bastante eficiente en cuanto al uso de recursos, porque el programa fuente no está dema-siado lejos del programa objeto.


3. Lenguajes de alto nivel Los lenguajes de alto nivel se desarrollaron como respuesta a la excesiva de-pendencia de la máquina que presentaban los lenguajes simbólicos y para evi-tar la intervención de un intermediario entre el usuario y el computador. Los lenguajes de máquina y simbólicos son muy complejos y la programación es lenta, lo que obliga a utilizar los servicios de un especialista. Esto se pretendía evitar con los lenguajes de alto nivel, porque podrían ser aprendidos por el propio usuario para desarrollar sus aplicaciones; en la práctica, esto no suce-dió en las aplicaciones administrativas y fue necesario contar con especialistas en lenguajes de alto nivel.

Los lenguajes de alto nivel están mucho más cerca del usuario que los lenguajes de máquina y simbólicos. Sin embargo, incorporan una lógica extraña y poco natural que dificulta la programación por parte del usuario, quien, si insiste en programar, debería pasar algunos exámenes de aptitud, seguir algunos cursos y luego practicar; período que podría ser muy largo. La dificultad no se produce por el aprendizaje del conjunto de instrucciones del lenguaje, sino que por la estructuración de la lógica de procesamiento.

En general, los lenguajes de alto nivel se orientan a determinados tipos de pro-blemas. Por ejemplo, FORTRAN para aplicaciones científicas y COBOL para apli-caciones comerciales. Normalmente, las instrucciones son bastante poderosas.

Una característica clave de los lenguajes de alto nivel es su portabilidad o la posibilidad de trasladar el programa desde un computador a otro. En la práctica, la portabilidad total se ha dado solamente entre diferentes modelos de un mismo fabricante y cuando se desea trasladar el programa a un computador de otro fa-bricante, la portabilidad se ve afectada por las particularidades introducidas al lenguaje y por su difusión, porque el lenguaje podría no estar disponible en esa línea de equipos. Se han desarrollado más de 100 lenguajes de alto nivel y no más de 10 se han generalizado78; entre ellos se encuentran: COBOL, FORTRAN, RPG, PL/1, BASIC, C, PASCAL Y CLIPPER.

78 En lo que se refiere a las grandes aplicaciones administrativas y pese a muchas predicciones en contra, el lenguaje más común ha sido COBOL. Es posible que siga siéndolo por muchos años, por la gran cantidad de código acumulado, su universalidad y nuevas versiones que incorporan conceptos tales como orientación a objetos e interfaces gráficas. Le siguen de lejos RPG, algunas versiones de BASIC, CLIPPER, C y C++. En general, la estructuración de lógica en los lenguajes de alto nivel ha sido “muy personal” por no decir anárquica, lo cual ha contribuido a reducir aún más la portabilidad y ha dado origen al estudio de técnicas para mejorar la lógica de construcción del programa y dar “pa-

JUAN BRAVO C. 314

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 código construido por el programador (programa fuente) pasa por un compilador (producto de software) que lo transforma en código que “entiende” el compu-tador (programa objeto). Normalmente, el lenguaje de máquina generado es optimizado por el compilador (por ejemplo, se crean tablas en memoria y se eliminan repeticiones) para disminuir el tiempo de ejecución y para utilizar mejor los recursos del sistema operativo.

• Lenguajes Interpretados: esta denominación proviene del término “interpre-tación” como sinónimo de “traducción simultánea” entre diferentes idiomas. Esto significa que el código construido por el programador no está traducido de antemano, sino que al momento de la ejecución del programa se traduce y se procesa cada instrucción. Aquí existe solamente el programa fuente. Es menos eficiente que el programa objeto, porque no se puede optimizar el código y debe traducir-ejecutar cada vez que el programa se llama a ejecu-ción. Tiene como ventaja que el programador ve su programa funcionando inmediatamente, lo que facilita la construcción y la mantención del código.

4. La cuarta generación de lenguajes Con el advenimiento de las herramientas de cuarta generación hubo una aper-tura de la informática hacia los usuarios, quienes pudieron resolver directa y rápidamente variadas necesidades.

Hasta hace un tiempo, el esquema predominante para el desarrollo de software había sido crear un departamento centralizado de informática, en el cual se con-centraban los especialistas encargados del desarrollo de nuevas aplicaciones y de la mantención de las antiguas. Este esquema de trabajo hizo crisis.

¿Qué sucedió? Al principio los usuarios observaron cautamente la introducción del computador en la empresa y sólo se incorporaron los sistemas más importan-tes y tradicionales, como cuentas por cobrar, cuentas por pagar, inventarios, contabilidad y remuneraciones. Al mismo tiempo, en los usuarios existía un gran desconocimiento del computador y de las técnicas empleadas por los espe-cialistas, no exento de un cierto grado de temor y admiración. Sin embargo, cuando el usuario aprendió a sacar provecho del computador y observó que dis-

trones” de programación; como la programación estructurada o la programación práctica (ambas expuestas en el libro Desarrollo de sistemas de información, una visión práctica).


ponía 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 rápida a sus requerimientos. Es más, se fue acumulando cada vez mayor cantidad de aplicaciones sin desarrollar, llegando a producirse una cola de trabajos pendientes que alcanzaba a varios años. 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 pérdida de vigencia de algunas aplicaciones en la cola, porque el entorno actual de la potencial aplicación era diferente al origi-nalmente considerado.

Otro problema fue el atraso invisible que se producía cuando los usuarios pre-ferían no solicitar algunas aplicaciones, porque lo estimaban una pérdida 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 introducción cómo fue creciendo la demanda por nue-vas herramientas destinadas a incorporar al usuario en el proceso de desarrollo y aumentar la productividad en la construcción de sistemas.

La respuesta fueron los Lenguajes de Cuarta Generación, los cuales pueden clasificarse en dos grandes áreas: herramientas de uso específico y lenguajes para construcción de aplicaciones. Ambas tienen las características clave de amistosidad y productividad. Amistosidad, para incorporar a los usuarios en el proceso de desarrollo; y productividad, para aumentar, al menos en 10 veces, el rendimiento en el desarrollo de software.

Por incorporar a los usuarios en el proceso de desarrollo entendemos incre-mentar substancialmente su nivel de participación y que entienda el por qué del desarrollo. No es la idea que programe o arme un sistema, excepto tal vez en las aplicaciones más pequeñas y con apoyo de una buena herramienta.

5. Las nuevas herramientas Al comienzo del uso de los lenguajes de cuarta generación, distinguíamos entre las herramientas de uso específico y aquéllas orientadas a la producción de software en que las primeras no tenían una capacidad procedural y las se-gundas sí. Hoy, tanto las herramientas de uso específico como los productos orientados a la construcción de aplicaciones tienen la característica clave de

JUAN BRAVO C. 316

especificar en forma procedural y no procedural. Procedural se refiere a es-tructurar lógica, como en COBOL o PASCAL. Es decir, cuando la funcionalidad vía menús no alcanza para resolver un requerimiento, entonces se utiliza un lenguaje de alto nivel: huésped, como los indicados, o propio, en este caso con su particular conjunto de instrucciones. Es el caso de la mayoría de las macros que uno puede construir en un administrador de bases de datos, una planilla electrónica e, incluso, en los actuales procesadores de texto. No procedural se refiere a resolver un requerimiento a través de menús o comandos directos, sin programar.

La posibilidad de agregar lógica en cualquier herramienta le permite aumentar notablemente su productividad y da la oportunidad a interesados y especialistas de desarrollar toda su potencialidad.

La característica clave de las nuevas herramientas de la tecnología de informa-ción es la integración total. Esto significa que todos los productos de la instala-ción 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: automatización de oficinas79, bases de datos, workflow, construcción de aplicaciones y administración de proyectos.

Es importante aclarar que la decisión de incorporar una herramienta integrada de la tecnología de información tiene directa relación con el grado de preparación previa de la organización, en cuanto a organización, normalización interna y externa o participación de los usuarios. Además, hay que tomar en cuenta el problema de la conversión de datos desde aplicaciones antiguas, el cual es tan importante que algunos proyectos han fracasado porque sus patrocinadores lo han subestimado.

¿Cuál es el futuro de los nuevas herramientas de la tecnología de información?

En este momento hay una verdadera avalancha de herramientas y se están pro-bando muchas opciones. Por ejemplo:

• Se intensificará la orientación total al usuario, con interfaces cada vez más amistosas, haciendo uso intensivo de ventanas, íconos, colores y mucha sim-plicidad, para hacer no sólo más fácil el trabajo sino también más atractivo.

• Se avanzará mucho más hacia la integración total, especialmente entre las herramientas CASE y los sistemas administradores de bases de datos, los cua-

79 Como ejemplo de esta tendencia, obsérvese la integración del producto MS Office para Windows, el cual incluye Word, Powerpoint, Excel, Access, Outlook y otras aplicaciones.


les tendrán incorporadas o poseerán buenas interfaces a gráficos, planillas electrónicas, procesamiento de imágenes, almacenamiento de voz, procesa-miento de texto, transmisión de datos. En lugar de diccionario de datos, co-menzaremos a escuchar con mayor frecuencia el término enciclopedia, o dic-cionario de conocimiento, el cual incluiría no sólo características de datos, sino también formatos de pantallas e informes; capacidades lógicas para hacer algún tipo de inferencia, buscar recorridos óptimos en consultas o apo-yar la normalización de diseño.

• 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 tecnología de información se estaría logrando lo que no se consiguió a través de los “sis-temas operativos generalizados”, es decir, atravesar horizontalmente las dife-rentes plataformas de hardware y software.

• Disminuirá la necesidad de programación tradicional en el desarrollo de software; se estima que menos del 3 % del código total de una aplicación será incorporado por el desarrollador, la mayor parte será generado automáti-camente o se aplicará código reutilizable. Hoy, sin tener que programar, ya es posible pintar pantallas, generar informes, realizar operaciones de actualiza-ción entre entidades o efectuar múltiples cálculos. Al mismo tiempo, se in-crementará la necesidad del buen diseño de las aplicaciones.

Esto depende en gran medida de la complejidad de la aplicación. Si es muy simple, probablemente no se requiera aportar código, excepto instrucciones muy precisas en puntos bien determinados. Si la aplicación es muy comple-ja, probablemente la herramienta ayudará a definir prototipos con informes, pantallas, consultas y otros módulos básicos que no representan más allá del 50 % de la aplicación, todo el otro 50 % deberá ser programado, aun-que no es problema si se realiza en forma de clases. Resulta evidente que entre esas posibilidades hay muchas situaciones intermedias.

JUAN BRAVO C. 318

7.2. HERRAMIENTAS DE USO ESPECÍFICO

Algunas herramientas de uso específico son:

• Procesadores de texto • Planillas electrónicas • Administradores y evaluadores de proyectos • Lenguajes de apoyo a la toma de decisiones • Generadores de informes • Generadores de gráficos • Diseñadores de pantallas • Lenguajes de consulta, tipo QUERY • Lenguajes de definición y manipulación de datos en Bases de Datos • Automatizadores de análisis y diseño • Paquetes generalizados orientados a algún tipo de problemas

Este es un libro sobre modelos de aplicaciones computacionales, ¿qué relevan-cia pueden tener las herramientas de uso específico sobre el desarrollo de soft-ware? Básicamente en dos aspectos:

• El primero es la disminución en la necesidad de construir software de uso general, lo cual se puede estimar al menos en un 70%, producto de las mayo-res potencialidades de las herramientas. Por ejemplo, hoy, con un simple procesador de palabras puede ordenar textos, efectuar cálculos, imprimir eti-quetas o manejar eficientemente una base de datos simple. Hace algunos años, para satisfacer esos requerimientos, era necesario construir sistemas computacionales pequeños que podían ocupar un mes de programación y lo mismo es válido con el uso de graficadores o planillas electrónicas.

• En segundo lugar, algunas herramientas de uso específico ayudan directa-mente en la producción de software a través de la automatización de las va-riadas y rutinarias labores asociadas a la producción de software, por ejem-plo: “pintar” una pantalla, ordenar una tabla, comunicar información, realizar seguimiento del proyecto, modelar los datos y comunicar el modelo a una ba-se de datos.

Veremos: 1. Herramientas integradas para automatización de oficinas 2. Groupware 3. Workflow


1. Herramientas integradas para automatización de oficinas Todavía no hemos calibrado el impacto de los nuevos productos integrados de automatización de oficinas. Con ellos se reduce la necesidad de construir sis-temas computacionales con personal especializado, quienes pueden ahora des-tinar su tiempo a las aplicaciones más 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 (más

que sólo traducción) • Tiene herramientas de dibujo • Manejo de tablas • Buenos aportes de edición • Impresión automática de sobres y etiquetas

Con las otras herramientas ocurre lo mismo, por ejemplo, ACCESS, de Microsoft, se está transformando en uno de los productos más vendidos81 no sólo para in-teractuar con bases de datos, sino también para desarrollar.

2. Groupware Durante este período también surgieron las herramientas para trabajo de gru-po, tipo Groupware, también llamadas Workgroup. Éstas, además de permitir la comunicación entre los miembros de un grupo, tal como lo haría un correo electrónico, también permiten compartir documentos y hacer una construcción conjunta de proyectos, con una coordinación central e integrando multimedia, son productos tales como NOTES, de Lotus o el mismo Outlook de Windows. Por ejemplo, en evaluación de proyectos, hoy es posible que un equipo se co-ordine para obtener promedios grupales de ponderación de factores de deci-sión, los que antes dependían sólo de la buena fe de algún profesional aislado.

80 Impresiona que antes de este tipo de procesadores debíamos construir algún pequeño siste-ma computacional para dar respuesta a cualquiera de estas facilidades y a otro costo. 81 Un dato: en los primeros 7 meses de venta de la versión 2.0 de Access, en Estados Unidos se vendieron 3 millones de copias, principalmente a usuarios finales.

JUAN BRAVO C. 320

3. Workflow La tecnología de flujos de trabajo, Workflow, permite automatizar un flujo de trabajo y es un buen complemento para la tendencia actual de identificar y rediseñar los procesos del negocio. Ejemplos de este tipo de productos son:

XNEAR, Lotus Notes y Workflow de IBM.

Para cumplir el objetivo de un proceso, generalmente se requieren diversas acti-vidades realizadas por diferentes personas en distintas unidades organizaciona-les. Workflow automatiza ese flujo y administra la ubicación y avance de cada tarea. Naturalmente, exige que todos los participantes tengan el equipamiento apropiado, generalmente algún esquema con redes de computadores.

Desde el punto de vista de la reingeniería de negocios, en particular aplicando el concepto de generalización de procesos, sería conveniente que antes de automa-tizar el proceso, con o sin una herramienta Workflow, se evaluaran otras opcio-nes, por ejemplo82:

• Eliminar o externalizar el proceso completo.

• Agrupar todas las actividades para que las realice una sola persona (con-cepto de integralidad de la gestión de procesos). De esta forma, en lugar de tener una especie de línea de producción con cargos especializados, cada uno de los mismos participantes puede realizar el proceso completo, tal vez orientándose a determinados tipos de procesos.

• Agrupar las actividades del proceso para que un equipo de personas las reali-ce en la misma ubicación.

Con las herramientas tipo Workflow se tiende a eliminar los documentos manua-les y hacer todo el trabajo directamente en el computador. Por ejemplo, opera-ciones crediticias o de ventas. El nivel de amistosidad de estas herramientas debe ser muy alto, porque serán empleadas por la mayoría de los usuarios de la organización.

82 Estas y otras posibilidades se estudian en los libros Reingeniería de negocios y Gestión de procesos.


7.3. UNA PIRÁMIDE DE SOLUCIONES

Es frecuente observar una pirámide como la que se presenta en la figura 7-2. Es cierto que es una pirámide de alto costo, sin embargo, cada día es más ne-cesaria en las organizaciones.

Figura 7-2. Una pirámide de soluciones

Veremos cada una de las capas de esta pirámide, comenzando desde arriba.

1. BI BI (Business Intelligence, en español 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 análisis. Por ejemplo, un tipo de herramienta en que se pueden preparar en los aspectos estadísticos del estudio de datos.

Por supuesto, la información a usar en los análisis 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 minería de datos

Una implementación es instalar la solución BI sobre un Data Warehouse.

Sistema operativo y lenguajes

Motor de base de datos

SRM ERP CRM

BIData Warehouse

Sistema operativo y lenguajes

Motor de base de datos

SRM ERP CRM

BIData Warehouse

JUAN BRAVO C. 322

2. Data Warehouse Data Warehouse se traduce como almacén de datos y se refiere a un conjunto de datos organizado de cierta forma y permanentemente actualizado que ayuda a la toma de decisiones de la empresa.

Lo habitual es instalar el Data Warehouse sobre el procesamiento transaccio-nal, generalmente un ERP que usa algún motor de bases de datos (los veremos en los siguientes puntos).

Un aspecto importante es separar los datos operacionales (que residen en el motor de bases de datos) de los datos en el esquema Data Warehouse, los cua-les tendrán una estructura normalizada de acuerdo con el tipo de análisis que se quiera realizar. Esto significa incorporar un proceso automático de traspaso de información.

3. ERP Los productos ERP (Enterprise Resource Planning, en español, sistemas de planificación de recursos empresariales) administran e integran las transaccio-nes operacionales de la organización, por ejemplo: cotizaciones, pedidos, compras, producción, distribución, facturación, contabilidad, personas y co-branza. De esta forma, cuando, por ejemplo, se produce una venta, el sistema “explota” una serie de transacciones a contabilidad, bodega o producción. Se evita así su ingreso independiente.

Los sistemas ERP derivan desde los antiguos software de Planificación de Recursos de Manufactura (MRP II) y de la Planificación de Requerimientos de Material (MRP).

En variadas implementaciones, los sistemas ERP se relacionan con dos tipos de productos: uno cercano al consumidor (CRM) y otro cercano a los provee-dores (SRM).

4. CRM Los productos CRM (Customer Relationship Management, en español, ges-tión de la relación con los clientes) ayudan en la integración con clientes pro-porcionando un entorno tecnológico para una relación más personalizada (ob-servan historial de contactos, de ventas, hábitos y mucho más). Se puede ver también como un modelo de gestión que se orienta al cliente y que se mani-fiesta en el marketing relacional.


Es una herramienta del tipo B2C (Business to Consumer, o comercio desde las empresas al consumidor).

5. SRM Los productos SRM (Supplier Relationship Management, en español, gestión de la relación con los proveedores) ayudan en la gestión de las relaciones con los proveedores. Buscan integración a través 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 reposición automática.

Es una herramienta del tipo B2B (Business to Business, o comercio electróni-co entre empresas).

6. Motor de base de datos Aquí se puede referenciar el enfoque de bases de datos del capítulo 4, en todo caso, hablamos de sistemas administradores de bases de datos tales como: Oracle, Informix, Sybase, Progress, SQL Server, DMS e Ingres.

JUAN BRAVO C. 324

7.4. HERRAMIENTAS DE APOYO PARA LA

PRODUCCIÓN DE SOFTWARE

Las herramientas de la tecnología de información para la producción de softwa-re, también llamados productos orientados a la construcción de sistemas com-putacionales, son aquéllas que permiten apoyar todo o una parte del método de desarrollo. Se las conoce mejor como herramientas CASE.

Las herramientas C.A.S.E. (Computer Aided Software Engineering, sigla que en español significa más o menos: ingeniería de software con apoyo computacio-nal) son un soporte automático o semiautomático para los métodos de desarrollo de software; una definición más amplia podría ser: las herramientas CASE ayu-dan en todo o parte del diseño, construcción y mantenimiento de un proyecto de software. Por ejemplo, apoyan total o parcialmente en:

• Modelamiento de datos • Modelamiento de funciones • Orientación a objetos • Diseño estructurado • Diagramación de estructuras • Diseño de informes y pantallas • Prototipos • Administración de bases de datos • Generación de código en diferentes lenguajes • Generación de documentación • Generación de datos de prueba • Mantención y regeneración de sistemas

En cierta medida, el concepto CASE nació de la urgencia por solucionar el pro-blema de la productividad en el desarrollo de software.

Tal como vimos en el capítulo segundo, el incremento de productividad no se obtiene automáticamente con la introducción de alguna herramienta. Entre otros aspectos, también influyen la normalización, la aplicación de buenos métodos y la participación del usuario.

Al interior de la empresa un pequeño grupo de ejecutivos, de muy poca disponi-bilidad de tiempo, poseen el conocimiento preciso sobre los objetivos y planes de la organización, así como de la forma de llevarlos a cabo. Este conocimiento es la base para plantear sistemas computacionales que ellos pueden ayudar a


desarrollar. Sin embargo, se han encontrado con las dificultades propias del de-sarrollo tradicional de aplicaciones, tales como atrasos, colas de espera, materias difíciles, programación muy lenta y dificultad de retroalimentación. Esto los ha desalentado y han dejado la iniciativa a especialistas en computación, quienes no poseen la misma visión del negocio, agudizándose 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 través de métodos simples y con apoyo computacio-nal, de tal forma que el modelo producido se pueda seguir perfeccionando a través 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 solución queda registrada automáticamente y es un patrimonio de la organización, porque es independiente de las personas que la desarrollaron y puede ser sucesivamente mejorada. Esta es una inversión en inteligencia.

Algunas características relevantes de las herramientas CASE son las siguientes:

• Tienen la doble orientación de productividad y amistosidad. • Sirven a un método para el ciclo completo de desarrollo o para una o más

etapas específicas. • Proveen la posibilidad de integración entre diferentes etapas. • Permiten uniformar diseños, documentación y construcción al interior de la

empresa. • En la construcción de aplicaciones mayores es posible modularizar y coor-

dinar el trabajo de diferentes desarrolladores. • El usuario y el analista se concentran en lo verdaderamente importante:

definir los requerimientos. • Es posible obtener una visión de conjunto de un proyecto modularizado. • Se provee en forma automática una completa normalización de símbolos.

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 clasificación para los productos en el segmento intermedio, denominada MIDDLE CASE, es menos utilizada.

En la figura 7-3 podemos apreciar las dos clasificaciones principales.

JUAN BRAVO C. 326

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 definición de requerimientos y el diseño. Con la automatización de la obtención de diagra-mas de diseño se pueden hacer revisiones más precisas, reproducciones y es posible ensayar otras opciones de modelamiento.

Ejemplos de herramientas en este nivel serían System Architect y ERWIN. En ambos casos es posible traspasar directamente las definiciones a un sistema ad-ministrador de bases de datos.

De acuerdo con la tendencia de interfaces simples y naturales, se espera que la definición de requerimientos y el diseño de las aplicaciones se efectúe 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 construcción y el mantenimiento del sistema. Estas etapas del desarrollo se ven notablemente simplificadas cuando las co-rrecciones y el perfeccionamiento de la aplicación se realizan a nivel de una especificación y no directamente en el código de los programas.

La herramienta debería entregar como resultado una completa documentación de la aplicación. ¿Qué se documenta? Todo, especialmente:

Herramienta Etapas que apoya

Upper CASE

Lower CASE

Definición de requerimientos de Diseño

Construcción Mantenimiento

Herramienta Etapas que apoya

Upper CASE

Lower CASE

Definición de requerimientos de Diseño

Construcción Mantenimiento


• La especificación completa del sistema; todas las clases y objetos con el detalle de los modelos de datos y funciones.

• El esquema de menús de la aplicación para usuarios finales, incluyendo las ayudas en línea.

Las herramientas LOWER CASE se clasifican en los siguientes tipos:

• Generadores de programas: son productos que permiten generar programas individuales: de impresión o de ingreso de datos. Habitualmente el programa se construye sobre una estructura predefinida, como en el caso de COGEN y GENCOB. Los programas generados pueden ser intervenidos en el mismo len-guaje que se construyeron.

• Generadores de aplicaciones: en los generadores de aplicaciones existe un equilibrio entre procesos y datos, a diferencia del generador de programas. Un generador de aplicaciones puede dar origen a uno o varios programas, según su filosofía, pero siempre va a crear automáticamente un “entorno” pa-ra: manejar tablas, administrar una bitácora de uso de la aplicación, iniciali-zar o reconstruir entidades, seguridad o menús. El generador de aplicaciones puede tener o no un sistema administrador de bases de datos; en caso de no tenerlo, es posible simular algunas de sus facilidades definiendo nuevas fun-ciones. Ejemplos de lenguajes en esta categoría son Synon/2, Genexus, Ge-nial83, Escultor y CASE/AP. Aquí ya es posible completar algunas aplicaciones muy simples sin llegar a programar, aunque es posible agregar funcionalidad a través de un lenguaje de alto nivel, huésped o propio.

• Herramientas de productividad en los sistemas administradores de bases de datos (SABD): también es posible encontrar en los SABD herramientas inte-gradas o módulos opcionales para apoyar la producción de software.

Algunos SABD proveen un buen manejo para la estructuración y consulta de datos en las bases de datos, como DBASE III, TOTAL, INFORMIX U ORACLE

sin SQL-PLUS, pero el apoyo es bajo para construir funciones de las aplica-ciones computacionales: actualizaciones, cálculos o informes con diferen-tes cortes de control. En estos casos, habitualmente es necesario programar esas funciones usando algún lenguaje de alto nivel del SABD, ya sea hués-ped o propio.

Existen poderosos sistemas administradores de bases de datos que integran gran parte de las características de las herramientas de la TI, por ejemplo:

83 El autor construyó esta herramienta a mediados de los 80, originalmente con nombre Bra-vo/2 L4G.

JUAN BRAVO C. 328

pintores de pantallas e informes, generación de gráficos, manipulación de planillas electrónicas, automatización de oficinas (procesador de palabras, correo electrónico, generador de formularios, directorio telefónico, calcula-dora, calendario y borrador), digitalización de imágenes, ayudas en todo el ciclo de desarrollo (evaluación y control del proyecto, análisis, diseño y construcción), ayudas en la toma de decisiones (análisis de sensibilidad), cálculos matemáticos y financieros u operación en tiempo real. Algunos SABD que están o podrían estar en esta categoría son: PACE, ORACLE con SQL PLUS, Sybase, Ingres, Progress y otros.

Las herramientas Lower Case también se distinguen entre las que usan código reutilizable y las que generan código fuente “a la medida”.

Veamos cada una de ellas:

Sistemas de código reutilizable

Los sistemas de código reutilizable son especificados a través de menús 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 parámetros para la ejecución de la aplicación. En el diccionario de referencias se incluyen elementos tales como: nombre del campo, largo del campo, ubicación del campo dentro de la tabla, nombre de la función y menú dónde se encuentra.

Como en el caso de los lenguajes de alto nivel, de tipo intérprete, donde por cada instrucción se realiza un proceso de traducir-ejecutar, aquí también se re-quiere un proceso de “interpretación”, aunque no de instrucciones fuentes, sino de las tablas del software. Ante un requerimiento del usuario, el código reutili-zable hace uso del diccionario de referencias para manipular o seleccionar in-formación de las bases de datos de la aplicación, habitualmente almacenada bajo estructuras de datos propias del producto.

Algunas características de estas herramientas son:

• No son muy rápidas ni eficientes en el manejo de grandes volúmenes de datos.

• No liberan la aplicación, 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 huésped tipo COBOL, CLIPPER o C). • Es difícil y a veces imposible, agregar más funcionalidad a la aplicación adi-

cionando código. La característica procedural es limitada.

Considerando el dinamismo en el desarrollo de productos de cuarta generación y la gran interrelación entre ellos, es difícil encontrar herramientas “puras” en esta


categoría, algunas excepciones podrían 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 aplicación bajo este esquema.

Sistemas de código fuente

Los sistemas de código fuente son generadores de código en lenguajes de alto nivel. A partir de la definición almacenada en los diccionarios de datos y fun-ciones de la herramienta CASE, se construyen automáticamente los programas fuentes de la aplicación, en:

• Lenguaje huésped, tipo COBOL, PASCAL, C o CLIPPER, quedando a disposición del usuario para ser intervenidos.

• Lenguaje propio, también quedan a disposición del usuario para ser inter-venidos.

• Lenguaje propio o huésped, no pueden ser intervenidos directamente por el usuario, sino que se agrega lógica a través de procedimientos especiales. Esta lógica queda almacenada y luego es intercalada automáticamente 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 aplicación manipulan o consultan información directamente en los repositorios de datos de la aplica-ción: clientes, artículos o facturas. Esto permite que la eficiencia de este tipo de sistemas sea mayor que el anterior y sin limitaciones para procesar grandes volúmenes de información. Además, cualquier ineficiencia puede ser rápida-mente resuelta con la posibilidad abierta de aportar código.

Los productos que generan código fuente son los más 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 gráfico y proveen capacidades en programación orientada al objeto. Algunos ejemplos: Gupta (o Centura), PowerBuilder, Delphi, 4D y Visual Basic.

¿Cuál es el aporte de estas herramientas? No debemos olvidar que el esquema cliente servidor nace como una forma de apoyar la construcción descentrali-zada de aplicaciones. El esquema típico son grandes instalaciones con un de-partamento de sistemas centralizado que no alcanza a atender los requerimien-tos de importantes áreas de la empresa; por ejemplo, de la gerencia de ventas

JUAN BRAVO C. 330

donde trabajan 300 personas o del departamento de producción, con 800 em-pleados. Típicamente, ellos cuentan con soluciones locales.

En este contexto resulta razonable que las gerencias de ventas y producción quisieran resolver sus necesidades de aplicaciones a través de la formación de pequeñas unidades de informática, con especialistas en diseño y construcción, los cuales contaran con herramientas que se comunicarán 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, vía la norma SQL, con algún motor de bases de datos en el equipo central.

Un mensaje implícito en esta narración es que, en el esquema cliente servidor, cliente no es lo mismo que usuario final. En este caso, para efectos del desa-rrollo de aplicaciones, el cliente es también un especialista que se encuentra en otra unidad de la empresa.

A excepción de consultas, informes y otros módulos especiales, las herramien-tas de productividad tipo cliente servidor están muy orientadas hacia especia-listas en informática. Un índice adicional es el largo tiempo que toma llegar a obtener un manejo de buen nivel, no inferior a seis meses, incluso para pro-gramadores con experiencia.

El esquema cliente servidor se hace cada vez más parecido al ambiente WEB.

¿Y las herramientas de productividad en ambiente WEB?

Con la explosión de aplicaciones WEB ha surgido una amplia variedad de herramientas en este ambiente, dentro de las más conocidas: .NET y el desa-rrollo en JAVA, destacándose J2EE (Java Enterprise Edition). También PHP integrado con alguna base de datos, como MySQL.

Resulta sorprendente que mucho software en este ambiente es de tipo open source (código abierto para efectos de lograr aportes en su construcción, no necesariamente libre de costo como los productos free).

En todo caso, un objetivo principal de la empresa es el desarrollo de páginas WEB y portales para integrarse con sus proveedores, clientes y demás grupos de interés. Así la empresa se proyecta al medio.


CONCLUSIONES, ANEXOS Y

BIBLIOGRAFÍA

JUAN BRAVO C. 332

CONCLUSIONES

Los que conocen íntimamente un oficio saben perfectamente que lo que menos se encuentra es la uniformidad en los métodos usa-

dos. En lugar de haber una sola manera de trabajar aceptada generalmente como modelo, se usan diariamente, digamos, 50 ó

100 maneras diferentes para hacer cada elemento de trabajo.

Taylor F. W. (1969, p. 26)

Vimos que tradicionalmente el buen modelamiento de soluciones de software permite aumentar la productividad del desarrollo y la calidad del producto. Está bien, aunque debemos agregar la satisfacción total del cliente (no el usua-rio, sino que el cliente de la organización), porque la nueva visión de la totali-dad y los requisitos de competitividad hacen necesario una mirada más allá de lo tradicional.

Vimos que es posible conservar la creatividad y al mismo tiempo obtener mo-delos repetibles y normalizados con métodos y herramientas de uso general. Entonces, el modelamiento de soluciones de software puede ser tecnología y arte a la vez.

El buen modelamiento tiene su base en sólidos pilares:

• La necesidad de trabajar con un método completo, para toda la organiza-ción y para todas las etapas de un proyecto, no sólo el ámbito tecnológico.

• Eficientar el diseño con herramientas de productividad y criterios de mode-lamiento tal como el curso normal de los eventos y otros que provee la vi-sión sistémica.

• Aplicar normas de calidad: CMM, ISO 9000, Tick IT • Alinear el desarrollo de software con las verdaderas necesidades del nego-

cio, esto significa alinear con la estrategia de la organización y verdadera-mente trabajar en conjunto con el usuario.

• Incorporar al diseño los estándares modernos: orientación a objetos y UML, por ejemplo.

Por supuesto, la efectividad se logrará en un ambiente propicio, con el nivel de madurez requerido.

Mucho éxito y gracias por la lectura.

~§~


ANEXO 1. INTRODUCCIÓN A LA PLANIFICACIÓN

ESTRATÉGICA

La idea es tener una visión estratégica, una vista panorámica de la realidad que nos permita tomar los mejores cursos de acción para cumplir con los grandes intereses de la organización84.

Cada área de la organización debería tener su propia misión, objetivos y planes, en armonía con las necesidades estratégicas de la institución, dando respuesta a preguntas del siguiente tipo: ¿Damos énfasis a la calidad o al mínimo costo? ¿Bajo qué paradigma de administración? ¿Potenciamos el conocimiento de la propia organización o utilizamos métodos externos? ¿Se requiere desarrollar más el área comercial o el área productiva?…

Tradicionalmente la planificación se ha preocupado de:

• Definición del propósito de la organización y de las metas departa-mentales

• Creación de nuevos productos • Posicionamiento en determinados segmentos de mercado • Perfil de empleados • Estrategia de marketing • Estrategia de comercialización • Definición de imagen corporativa • Áreas geográficas de la organización y globalización.

Por lo tanto, el desafío es flexibilidad y creatividad.

Hoy, el rol de la planificación estratégica va mucho más allá. Debería “prepa-rar” a su organización para ser receptiva al cambio. Debería permitir que la empresa absorba los “golpes” del medio, se detenga, prepare bien una respues-ta y reaccione con mucha fuerza para lograr sobrevivir85.

84 Este es un resumen acerca de estrategia desde el libro Planificación sistémica. 85 Es equivalente a cuando se critica a alguien y esa persona, en vez de resistir, defenderse o contraatacar, como sería lo habitual, “absorbe” silenciosa y positivamente la crítica. 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 porción de verdad que ella contiene. Quizá por eso Plutarco —escritor romano— dijo: Un buen enemigo es el mejor maestro.

JUAN BRAVO C. 334

El objetivo de la Planificación Estratégica (PE) es ayudar a obtener una vi-sión de los verdaderos intereses y necesidades concretas de la organización con el fin de tomar decisiones hoy, siguiendo una dirección clara y definida. Esto obliga a una reformulación permanente de la planificación estratégica.

Por eso es que hoy hablamos de planificación continua.

¿La PE la hace solamente la alta gerencia? El ideal es que participen todos los miembros de la organización. Aunque la PE comienza por la dirección supe-rior, luego se produce mucha retroalimentación a medida que pasa a través de los diferentes niveles jerárquicos.

En los siguientes pasos, señalados en la figura A1-1, revisaremos los aspectos más importantes de la planificación estratégica.

Figura A1-1. Esquema de planificación estratégica

En la figura A1-1 podemos apreciar una visión de conjunto del esquema pro-puesto. Comienza por una definición clara y precisa del negocio, luego viene la definición del destino de la organización (lo que queremos, en la forma de visión, objetivos y metas). A continuación, vienen los factores críticos del éxito, aquellos aspectos fundamentales para la supervivencia y desarrollo de la organización, que serán ocupación prioritaria del ejecutivo.

Los objetivos, metas y factores críticos del éxito necesitan apoyarse en medi-ciones estables, confiables, oportunas y permanentes. Además, debemos con-siderar que la implementación de las mediciones es la base para la definición de los sistemas de información gerenciales.

Veamos este esquema.

Definición del negocio El primer paso de la técnica es aclarar el giro: ¿Cuál es mi negocio? o ¿Cuál es el valor agregado de mi actividad? Necesariamente significa preguntarse: ¿Existen áreas prescindibles?

Así como el hombre, según Viktor Frankl, fundador de la logoterapia, está en última instancia en búsqueda del sentido de la vida; las personas que integran

Definición del negocio

Destino de la organización

Factores críticosdel éxito

MedicionesSistemas deInformación Gerenciales

Definición del negocio

Destino de la organización

Factores críticosdel éxito

MedicionesSistemas deInformación Gerenciales


la organización también deben preguntarse cuál es el sentido de la existencia de ésta, el rol que le toca jugar en la sociedad.

A este aspecto, Koch y Campbell (Cómo despertar y reanimar la empresa) le asignan una importancia radical. Ellos hablan de éxito cuando la empresa tie-ne verdaderos objetivos.

Para definir el negocio es indispensable efectuar un estudio iterativo y retroa-limentado (en el sentido de construir borradores sucesivos) sobre los siguien-tes temas:

• Introspección: es un escrutinio interno destinado a conocer nuestras forta-lezas y debilidades, compararlas con las de la competencia y así perfeccio-nar nuestras ventajas competitivas. Destaquemos en forma especial que lo que hace la diferencia en una empresa no es lo que hace menos mal, sino lo que hace muy bien. Esto significa destinar a las fortalezas el máximo 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 revés de como lo apren-dimos en el colegio, donde nos gastábamos todo el tiempo en llevar las de-bilidades a un punto de rendimiento medio y las fortalezas quedaban aban-donadas.

• Análisis 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 interacción con el medio.

• Estrategia competitiva: ¿Marketing o innovaciones? ¿En qué nos diferen-ciamos? ¿Nuestra orientación 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, serán elementos diferenciadores: calidad, rapidez en la entrega, servicio óptimo, solidez o lo que sea. El sistema de diferen-ciación y luego la ventaja competitiva es la forma como vamos a competir en el mercado. Se apoya en la orientación al cliente.

• Misión del negocio: es la función específica que nos corresponde desarro-llar en el sistema del que formamos parte, aquella función donde otorga-mos un verdadero valor agregado y además, plenamente reconocido por la sociedad como útil y complementaria para lograr los objetivos de bien común. Por ejemplo: confección de jeans a pedido para clientes mayoris-tas, centro naturista de atención al público o asesorías en planificación es-tratégica dirigidas a la dirección de las organizaciones.

JUAN BRAVO C. 336

Técnicamente, la misión debe incluir los productos que ofrecemos y los mercados que atendemos.

• Valores de la organización: la organización tiene personalidad propia, dis-tinta de las personas que la componen, aunque en el largo plazo se produce cierta similitud. Es decir, tanto la organización como sus integrantes co-mienzan a tener conductas parecidas. Los valores se expresan prioritaria-mente de dos formas:

Destacando el tipo de interacción que queremos tener con cada tipo de asociado: ¿Cómo queremos que sea la relación con los colaboradores, clientes o proveedores? La mecánica es describir las necesidades de cada grupo de asociados y ayudarles a satisfacerlas, en armonía con la satisfac-ción de necesidades de nuestra organización. Por ejemplo, los integrantes de la organización tienen necesidad de una renta digna, un trato respetuoso, un ambiente laboral estable, condiciones de trabajo que protejan su salud física y mental. Los clientes merecen todo nuestro apoyo, pues ellos finan-cian nuestras actividades, es indispensable que tengan la certeza de que trabajamos para entregarles calidad, innovando día a día en su beneficio y que les ofrecemos lo mismo que la competencia y mucho más. Los provee-dores necesitan conocernos para entender nuestras necesidades, requieren pagos puntuales, una relación comercial fluida, niveles de calidad estable-cidos de común acuerdo.

Señalando explícitamente un conjunto de creencias, principios éticos y modalidades de gestión. ¿Cuáles son las condiciones del trato entre las per-sonas? ¿Cómo se manejan temas claves (disciplina, anticipación, comuni-cación interpersonal)? ¿Qué sucede con el fomento a la creatividad e inno-vaciones?

• La emoción del negocio es una fuente para la motivación de todas las per-sonas de la organización y el principal alimento del líder. Surge de nuestros sueños, de identificar la necesidad social concreta que estamos satisfacien-do: abrigo, alimentación o consejería. Es el nexo que nos une con el entor-no, nos ayuda a reflejarnos y compartir experiencias con quienes tienen la misma perspectiva, aun cuando cumplan misiones diferentes86.

86 Tal como lo reflejara muy gráficamente el dueño de una panadería. La emoción del negocio es abrir uno de los panes que estamos produciendo, inspirar profundamente, sentir su aroma y esbozar una sonrisa de satisfacción. Muchos empresarios se nutren de la importancia de su labor en la sociedad para crear riqueza, fabricar bienes, dar empleos, etc…


• La imagen corporativa es la cara que queremos mostrar de la empresa a través de: papelería, banderas o revista interna.

Destino de la organización El asunto es: ¿la organización estará a la deriva o tendrá un rumbo mantenido con mano firme? Indudablemente, identificar el destino de la organización es indispensable. Para ello, tenemos que definir cuatro aspectos, en el mismo orden: ideal, ideal factible, objetivos y metas.

• El ideal es nuestro sueño para la organización. Queremos tener el 90% del mercado, o que cada norteamericano tenga un automóvil, como decía Hen-ry Ford. Que en cada supermercado se venda salmón en la misma forma y cantidad que el pollo o llevar a cero el consumo de drogas, lo que sea su sueño.

• El ideal factible surge de negociar con la realidad y proponer algo posible para el futuro cercano. Aceptamos disminuir un poco nuestra pretensión original, si corresponde, para lograr algo concreto. Entonces diremos que sí es posible obtener el 35% del mercado, construir un automóvil posible de adquirir por los trabajadores, comenzar a vender salmón en los supermer-cados en diferentes presentaciones o reducir el consumo de droga en un 90%. Técnicamente, el ideal factible es una propuesta que sabemos posible, aunque no es tan precisa como un objetivo... es la visión del negocio.

• Los objetivos son los elementos más representativos de la planificación estratégica, porque corresponden al destino concreto de nuestra empresa, aquel punto adonde queremos llegar. La planificación estratégica define los objetivos según el ideal factible, un diseño efectuado sin amarrarnos a la historia del negocio. Cada objetivo asocia mediciones para establecer com-paraciones y apreciar un estado de avance. Así, deja de ser solamente una buena intención. ¿Ha observado las emotivas declaraciones de principios de empresas en quiebra? Tan insubstanciales como las declaraciones de “desarrollo integral del niño” en colegios altamente represivos.

Un antiguo proverbio dice: El camino al infierno está pavimentado de bue-nas intenciones.

Existen previsiones a la cantidad de años que uno desee, aunque general-mente se hace una distinción entre objetivos de corto, mediano y largo pla-zo, unos 2, 5 y 15 años, respectivamente. Los plazos indicados representan solamente un promedio, porque no existe uniformidad al respecto. Largo

JUAN BRAVO C. 338

plazo puede significar 4 años para el ejecutivo de una empresa pequeña o 30 años para el presidente de una corporación japonesa.

• Las metas vendrían a ser las paradas intermedias, cada uno de los diferen-tes escalones que nos permitirán lograr un objetivo. Cada meta requiere un responsable, recursos y plazos.

Factores críticos del éxito Los Factores Críticos del Éxito (FCE) son tan vitales para la empresa, que afectan directamente sus posibilidades de sobrevivencia. Dependen directa-mente de la misión de la empresa y deben ser considerados en la toma de de-cisiones de la alta gerencia; representan un filtro en la cantidad de informa-ción que llega al ejecutivo. Significa que él podría delegar todo lo que no es un FCE. Por ejemplo, en una empresa de confecciones se encontraron los si-guientes FCE:

• Eficiencia en la producción • Estabilidad en la producción • Perfeccionamiento tecnológico • Nueva organización de la empresa

Los factores críticos del éxito se pueden clasificar en:

• Permanentes: se mantienen a través del tiempo y son relativos a la indus-tria, es decir, se pueden encontrar en la mayoría de las empresas del mismo tipo, como el perfeccionamiento tecnológico, la eficiencia y estabilidad de la producción, del ejemplo anterior.

• Temporales: se mantienen por períodos cortos de tiempo; generalmente se originan en:

◊ Particularidades transitorias, como una campaña comercial o el lanzamiento de un nuevo producto.

◊ Hechos circunstanciales, como una nueva ley, un incendio en insta-laciones importantes o la renuncia de un empleado clave.

◊ Situaciones programadas, como el desarrollo de una meta; por ejemplo, la nueva organización de la empresa.


Mediciones La planificación puede carecer de sentido si no está fuertemente anclada a los hechos y la realidad, lo que se consigue a través 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 críticos del éxito.

En alguna parte de la planificación podría decir: aumentar el perfeccionamien-to del personal. Al dejarlo así no pasa de ser una bonita declaración, sin em-bargo, para que se transforme en una realidad, es necesario agregarle un índi-ce; por ejemplo, horas de capacitación anual por empleado. Ahora podemos hablar en concreto: ¿cuántas horas estamos capacitando hoy a nuestro perso-nal y a cuántas queremos llegar?

Otro ejemplo es el de una empresa de confecciones que se plantea por objeti-vo aumentar la producción. En este caso, la medición es número de prendas por día, entonces: ¿Cuál es actualmente el número de prendas por día y a qué nivel queremos llegar?

Sistemas de información gerenciales En el punto anterior, ambos ejemplos terminan con preguntas donde podemos apreciar la necesidad de mediciones actualizadas para definir sistemas de información.

Cada vez que un ejecutivo da pautas sobre cómo hacer algo o se anticipa a una crisis o punto de quiebre, está diseñando sistemas de información gerenciales.

Un sistema de información es un modelo diseñado para cumplir con algún fin práctico, en este caso, apoyar una medición. En el sistema de información gerencial participan personas y se emplean variados recursos: técnicos, finan-cieros, infraestructura, conocimiento o herramientas de software.

Los sistemas de información gerenciales son procesos claramente identifica-bles, cuyo diseño debe estar permanentemente actualizado para conservar su efectividad. Permiten conocer e influir sobre el estado de una variable; por ejemplo, si el número de prendas producidas en el día baja hasta un cierto nivel, se genera automáticamente un alerta a ventas y producción; si el índice llega a un nivel todavía más bajo, podría alertarse a la gerencia general.

¿Quién diseña el sistema de información? Tradicionalmente, ésta ha sido la principal labor del ejecutivo, a veces sin que él lo supiera. Hoy, existe una

JUAN BRAVO C. 340

tendencia a la participación de todos los interesados. De hecho, algunos gru-pos autodirigidos definen y mantienen sus propios sistemas de información.

El diseño de sistemas de información gerenciales tiene relación directa con una antigua habilidad: la anticipación. Como decía El Quijote: “estar preveni-dos es estar armados”.


ANEXO 2. ALINEAR INTERESES

Existe la necesidad de negociar intereses, porque las personas y organizacio-nes tienen propósitos diferentes. Una vez que los intereses están claros, un proceso nada de simple, la gerencia debiera mantener la coherencia a través de un sistema de señales, es decir, establecer indicaciones y acciones concretas y permanentes según el objetivo que se desea obtener. Las personas hacen lo que hacen porque les conviene hacerlo (o creen que les conviene), porque hay estímulos para ello.

Es necesario alinear todas las acciones con la cultura de la organización y bus-car armonía entre los grupos de interés: 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. ¿Cómo lograrlo? Negociando, escuchando, apren-diendo a reconocer los intereses propios y ajenos, poniéndonos en el lugar del otro y practicando la buena comunicación, entre otras acciones.

También hay que lograr armonía entre los costos, lo cual implica negociar con los diferentes grupos de interés, buscando satisfacer sus intereses en armonía con los de la empresa. Este es uno de los aspectos más difíciles para la geren-cia y exige mucha fortaleza y habilidad, porque muchos grupos le exigirán justas demandas (para ellos) y algunos gritarán más que otros: ¡mayores utili-dades!, ¡mejores sueldos!, ¡más tributación…!

De hecho, en las grandes empresas norteamericanas87 comienza a ganar el talento, los trabajadores del conocimiento, como diría Peter Drucker. Las per-sonas más preparadas de la organización estarían obteniendo mayores benefi-cios que los accionistas, lo cual conduce a la rareza de que los trabajadores que no son del conocimiento hagan alianza con los dueños del capital (princi-palmente ellos mismos a través de los fondos de pensiones) para obtener me-jores beneficios. Paradojas de la nueva economía.

Liderar interacciones

Para mantener la armonía, la gerencia debería liderar valores en la relación con cada grupo de interés, 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 Según un artículo de Martin y Moldoveanu (2003) en el Harvard Business Review.

JUAN BRAVO C. 342

Es fácil darnos cuenta de esto con algunos ejemplos:

• Si contratáramos a los mejores futbolistas del mundo y los hiciéramos jugar juntos, lo más probable es que el rendimiento no fuera el óptimo.

• En la empresa manufacturera, es característico otorgar incentivos de pro-ducción por cantidades de productos que en muchos casos se almacenan, en lugar de incentivar a producir sólo lo que se vende.

• En departamentos de mantención, es frecuente pagar horas extras por repa-raciones de maquinarias —y de una u otra forma, siempre hay mucho tra-bajo— en lugar de pagar por su buen funcionamiento.

• Otro caso es nuestra interacción con los médicos en algunos tipos de pro-gramas. Partiendo de la base que el objetivo de la sociedad es el bien común, nuestro negocio es estar sanos. ¿Y el de los médicos?… ¡el negocio de los médicos en esos programas es que haya muchos enfermos! Porque un médico gana más en la medida que hay más enfermos. Este es el resul-tado de una cultura mecanicista que sólo ve partes. La responsabilidad no es solamente de los médicos —y lo mismo es válido en la mayoría de las profesiones—. Es más, muchos de ellos mantienen su profesionalismo y amor al trabajo bien hecho a pesar de los incentivos equívocos que otorga la sociedad. Un esquema sistémico sería aquel donde el negocio del médico es la salud y no la enfermedad, es decir, que el médico gane más en la me-dida que haya más gente sana. Eso es alinear intereses.

Por ejemplo, en la prevención de riesgos ¿a quien o a qué grupo le puede con-venir que hayan más 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 situación típica que se produce cuando el énfasis está en la corrección y no en la prevención. El mensaje es negociar con todos los interesados.

Alinear el interés particular con el interés general

A diferencia de lo que planteaba Henri Fayol de supeditar el interés particular al general, en visión sistémica se propone alinear el interés particular con el interés general. En el primer caso solamente hay mando y control, en el se-gundo, participación y negociación.

88 Como cuando un médico cirujano le pregunta a otro, ¿cómo te va? Y aquel responde: mal, porque he tenido pocas operaciones.


Debemos asegurarnos que la misión del proceso sea consistente con la misión de la empresa y dar señales de que ambos negocios están alineados. Por ejem-plo, si el negocio de la empresa es la fabricación 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 mantención es que las máquinas estén en mal estado, porque sus ingresos provienen de la reparación de maquinarias descompuestas, incluso se les paga horas extra para incrementar el volumen de reparación. Se puede apreciar que ambos negocios se contraponen: a uno le conviene tener los equipos buenos y al otro le con-viene que haya muchos equipos malos. Si el objetivo del equipo de manten-ción fuera “obtener ingresos por tener los equipos en óptimo estado de fun-cionamiento”, tendríamos las misiones alineadas e incentivaríamos la manten-ción preventiva.

Esto es alinear intereses y una forma de implementarlo podría ser: ofrecer un incentivo por tener todas las máquinas en buen estado y descontar de ahí cuando se presenten fallas. Veámoslo más en detalle con el resumen de un caso real. Supongamos que son 5 técnicos, que el sueldo de cada uno es de US$ 1.000 y que el costo para la organización por máquinas que fallan es de US$ 40.000 al mes (horas improductivas). Entonces, se les ofrece a los técni-cos un premio mensual extra de US$ 10.000 a repartirse en el grupo, a condi-ción de que las máquinas estén en buen estado de funcionamiento, pero, si una máquina falla, se descuenta de ese fondo un valor predefinido por cada hora detenida. En este caso tenemos alineadas las misiones: a la organización y al servicio técnico les conviene tener las máquinas buenas.

Epílogo: en el caso real los técnicos aumentaron su remuneración en un 50% y las fallas de las maquinarias disminuyeron en 70%.

Veamos otro ejemplo, si uno toma separadamente el área de producción de una empresa, puede parecer deseable producir cada vez más. Sin embargo, ¿es eso realmente conveniente para la empresa? Tal vez no, porque se podría ver en la necesidad de sacrificar demasiado sus márgenes, absorber gastos dema-siado altos de ventas o de administración ¿Podría ser que el objetivo del área productiva fuera producir según la demanda? Sí, a través de algún esquema que permita disminuir libremente la producción sin incrementar el costo por unidad producida.

Entonces, ¿es posible la armonía en la organización en pro de sus propósitos superiores? Por supuesto, a través de alinear intereses.

JUAN BRAVO C. 344

ANEXO 3. DESARROLLO EN ESPIRAL DEL PROYECTO

El desarrollo en espiral es una técnica donde el proyecto de negocios abarca una porción cada vez mayor de los requerimientos y en cada iteración avanza en calidad, eficacia y eficiencia.

Este método está dirigido a proyectos de cambio mayor. Simplificando, tam-bién se puede aplicar a proyectos de cambio un poco menor, como en el benchmarking o la mejora, aunque resultaría 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 pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejarlos y a continuación, se establece una aproxi-mación a la siguiente iteración… Se avanza un nivel en el rollo de canela, se comprueba que se tiene lo que se desea y después 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 iteración la complejidad se incrementa progresivamente y se reduce el riesgo. Por supuesto y al igual que en un pro-yecto tradicional, un desarrollo de esta naturaleza exige amplio esfuerzo de gestión y operación.

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 técnica llamada “desarrollo en cascada”, en la cual se preten-de avanzar en cada etapa con todos los requerimientos a la vez, en consecuen-cia, recién se ven resultados al término del proyecto, tal vez un año en el caso de proyectos medianos.


En el desarrollo en espiral cada vuelta o ciclo es un pequeño “desarrollo en cascada”, porque pasa por todas las etapas, aunque para un número relativa-mente pequeño del total de requerimientos.

Al término del proyecto (después de todos los ciclos) se recomienda incorpo-rar la mejora continua (ver etapa 7 del método).

JUAN BRAVO C. 346

ANEXO 4. RELACIÓN CAUSAL

Existen varias técnicas asociadas a la detección de causas: árbol de decisión, técnica de los por qué y otras detalladas en el texto. Veremos aquí la técnica causa - efecto de Kaoru Ischikawa junto con la detección de prioridades del italiano Vilfredo Pareto (1848 – 1923).

Es una combinación que hemos venido utilizando con efectividad, en la de-tección de los riesgos de fondo en eventos de pérdida de la administración del riesgo operacional y en la mejora continua.

La técnica causa – efecto se utilizaba principalmente en el ámbito industrial y las “espinas” hacían 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 tecnología. En este caso la aplicamos buscando el problema de fondo de un síntoma o dificultad.

Estrategia TecnologíaEstructura

ProcesosPersonas

Síntoma(s)

Por ejemplo, para un síntoma de descuadraturas de caja, en la línea “personas” se podría anotar, entre otras causas:

— Falta de capacitación — Escasa motivación — Personas no idóneas — 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 síntoma, riesgo o lo que sea que estemos analizando. La fórmula es Y = F(x). En la figura A4-1 se presenta un caso de aplicación de esta técnica para una situación de tiempo de espera excedido de clientes en una empresa de venta al detalle de productos de línea blanca y electrónica.


Figura A4-1. Ejemplo de gráfico de Ishikawa

Se priorizan y grafican de mayor a menor impacto según el porcentaje asigna-do, se lleva un gráfico acumulativo que cuando llega al 80% (o el porcentaje que acuerde el equipo de proyecto) se tiene el conjunto de causas más relevan-tes, los pocos críticos.

El gráfico tiene la siguiente forma, donde la columna más a la derecha tiene el acumulado de las causas ante-riores más la nueva.

El nivel de profundidad al cual se llega tiene que ver con la técnica de desa-rrollo en espiral y con el nivel de error aceptable para la organización en algún nivel de sigma.

Esta forma de trabajo es recursiva, puede ser necesario que una causa tenga su propio análisis causal y así sucesivamente. Es decir, X1 = F(x1), esquema central en la técnica Six Sigma.

A propósito de Six Sigma, en su libro Análisis de la causa raíz, los autores Wilson, Dell y Anderson dicen (1999, p. 6): “En Estados Unidos el 0.1% de fallas significa: 16.000 piezas de correo perdidas por hora, 20.000 prescrip-ciones de medicamentos incorrectas por año, 500 operaciones quirúrgicas in-correctas por semana, 50 bebés recién nacidos se les caen a los médicos por día, 22.000 cheques deducidos de cuentas corrientes equivocadas por hora, su corazón no late 32.000 veces por año”.

TecnologíaEstructura

Procesos Personas

Insatisfacción de clientes debido a excesiva duración del proceso (49 minutos)

Estrategia

Falta TecnologíaObsoleta

EspecializaciónForma obsoleta

RotaciónMotivaciónPreparación

No participaciónFalta área

Falta directrizComunicar

EfectoCausas

JUAN BRAVO C. 348

ANEXO 5. MÉTODO DE ACCIÓN RÁPIDA (MAR)

El objetivo del Método de Acción Rápida (MAR) sobre procesos es capturar oportunidades de mejora o de rediseño de los procesos operativos de cualquier ámbito de la empresa. puede ser un área o un macroproceso. Se trata de pro-poner el (re) diseño en alguna herramienta tal como PowerPoint, Optimus, Visio, System Arquitect u otra, a condición de que este disponible para todos.

Se han logrado importantes cambios en las empresas con esta técnica.

En el MAR es vital la participación de quienes trabajan en los procesos opera-tivos. La idea es la siguiente:

1. Seleccionar un ámbito de trabajo y dibujar un mapa de procesos. 2. Identificar un proceso operativo y describirlo con un Flujograma de Infor-

mación (FI). Aplicar criterio “Curso normal de los eventos”. 3. Identificar cliente, dueño, variable crítica y mediciones estimadas. 4. Establecer objetivos siguiendo el principio de idealización: ideal, ideal fac-

tible. ¿Cuál es el proceso perfecto89? (Puede ser de todo el ámbito). 5. Explicar oportunidades de mejora y señalarlas en un nuevo FI. ¿Cómo que-

dan las mediciones? 6. Realizar un cierre de la propuesta indicando beneficios y costos. Estimar

VAN interno y social (impacto económico en el medio)

Los detalles actualizados de esta técnica los puede bajar desde la página 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. Aceptémoslo de una vez, el futuro no existe, es solamente imaginación nuestra, algo que sucede en nuestra mente y que podemos controlar. El mismísimo Omraam Mikhaël Aïvanhov (1900-1986, sabio francés de origen búlgaro, reco-nocido por su aporte a la espiritualidad) en su libro Poderes del pensamiento nos aporta (páginas 39 y 40): “Hay dos grandes verdades que debéis conocer: primero, que el pensamien-to es un poder real y segundo, que os permite transportaros al futuro y vivirlo con anticipa-ción. Ved, por ejemplo, que si tenéis que afrontar una situación terrible, pasar un examen o comparecer ante un tribunal, ya estáis temblando varios días antes, os inquietáis: ¿qué va a pasar?… Y cuando pensáis que vais a reuniros con aquél o aquélla que amáis y que vais a abrazarla, estáis ya saboreando el gozo de estos minutos próximos o lejanos… El poder del pensamiento es real, tanto para lo negativo como para lo positivo y tenemos, por tanto, que servirnos de él para lo positivo”.


ANEXO 6. AD/CYCLE Y RUP

Se puede apreciar la evolución en el desarrollo de métodos orientados hacia el ciclo de vida genérico 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 más antiguo y el segundo más reciente.

AD/Cycle El ciclo de desarrollo de aplicaciones computacionales de IBM, AD/Cycle, anunciado en 1989, se acerca bastante al ciclo de vida genérico, la principal diferencia es que incorpora explícitamente una etapa de pruebas, la cual es parte de la construcción en el método genérico. Además, en AD/Cycle se habla de Análisis/diseño para referirse a lo que en el método genérico llama-mos diseño.

AD/Cycle provee un ambiente integrado de desarrollo que incluye desde el modelamiento hasta la mantención. Cada una de sus etapas es apoyada por herramientas de automatización propias o de otros proveedores. Las etapas de AD/Cycle son:

• Recolección de requerimientos: incluye planificación de sistemas, objetivos, factores críticos del éxito, prioridades y procesos del negocio.

• Análisis/Diseño: basado en análisis y diseño estructurado. • Codificación: es la construcción de los programas, servicio proporcionado

por los generadores de aplicación. • Pruebas: se incorpora formalmente el uso de prototipos y la idea de lograr

un resultado a través de perfeccionamientos sucesivos. • Mantención: ya sea por errores o cambios en el entorno. Se puede apreciar que ya en 1989 IBM había eliminado la implementación como una etapa más, aunque sus principales tareas: documentación, entrena-miento y poblamiento, se continúan realizando en forma automática o como parte de otras etapas. Se puede apreciar cómo se va delineando poco a poco el concepto de que una aplicación no termina nunca, creándose el ambiente para el desarrollo continuo de la aplicación.

Con AD/Cycle también se eliminan las etapas de diagnóstico y factibilidad aplicados a resolver problemas en forma reactiva, las que fueron reemplazadas por un enfoque global, una visión de conjunto de la organización que se ob-tiene de la recolección de requerimientos.

JUAN BRAVO C. 350

RUP Los autores del UML (capítulo 6) son también creadores de Rational Software Corporation (adquirida por IBM en el año 2005), desde donde han propuesto el RUP (Rational Unified Process), un método completo para el desarrollo de software que rápidamente está siendo incorporado en la industria informática.

RUP considera seis mejores prácticas del desarrollo de software:

1. Desarrollo Iterativo (o en espiral). Se resuelven primero los casos de uso (o requerimientos) más 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 técnica 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 solución de software. Debe cumplir que el software sea fácil de usar, funcional, de buen rendimiento, reusable, factible, entendible, económico, estético y elegante. Haciendo una comparación con el rubro de la construc-ción, esta etapa sería la de arquitectura.

4. Modelamiento visual del software. Se aplican aquí los modelos que provee UML, orientados a la especificación, visualización, construcción y docu-mentación de los productos de software.

5. Verificación de la calidad. Siendo la calidad uno de los más graves pro-blemas de la construcción tradicional de software, se propone incluir indi-cadores de calidad y verificaciones en cada punto del proceso de desarrollo. Se incorpora una labor de Testing en el ciclo de vida, en cada vuelta de la espiral.

6. Control de cambios. En un ambiente de creciente complejidad: múltiples desarrolladores, equipos de trabajo, instalaciones, versiones del software, proyectos y plataformas, se requiere un control explícito de requerimientos, configuración y mediciones.

En este método, cada iteración acerca más el sistema a lo que desea el usuario y a su plena funcionalidad, por otra parte, cada “versión” va quedando en fun-cionamiento real.

Mayor información puede encontrarse en www.omg.org, www.rational.com, www.uml.com y otros sitios relacionados.


ANEXO 7. CASO COMPRAS CON UML

Este caso fue un desarrollo completo de los modelos de UML contemplados en el método GSP (capítulo 1).

En el aspecto metodológico se basa principalmente en el libro “Applying UML and Patterns” de Craig Larman (1998, Prentice Hall).

Reconociendo que es difícil revisar en el papel, usted puede bajar este archivo desde la página www.evolucion.cl

Puede bajar también:

• El caso de uso Ventas • Método de Acción Rápida (MAR) sobre procesos, modelo en Power Point

y detalle en Word. Lo vimos en el anexo 5.

Veremos en las siguientes láminas un caso completo de compras en UML, comienza por los modelos de la etapa de análisis.

Cada lámina tiene notas que explican el respectivo modelo.

JUAN BRAVO C. 352

Etapa de Análisis

Las páginas siguientes corresponden a la etapa de análisis,la cual se extiende hasta la documentación de los contratos

de las operaciones del sistema inclusive.

Modelos de UML de una aplicación de ejemplo: compras

Devoluciones

RECEPCIÓNPOR COMPRAS

Ventas Servicio postventaProyección ventas Adquisiciones

DESPACHOPOR VENTAS

Devoluciones

Primer Flujogramade Información

Macro-procesos

MAPA DE PROCESOS (como parte del Modelo de Negocios)

Procesosoperativos

Bibliografía: Esta presentación se basa principalmente en el libro“ Applying UML and Patterns “ deCraig Larman - 1998 -(Prentice Hall) ISBN 0-13-748880-7

Bibliografía: Esta presentación se basa principalmente en el libro“ Applying UML and Patterns “ deCraig Larman - 1998 -(Prentice Hall) ISBN 0-13-748880-7

Bibliografía: Adicionalmente , esta presentación se basa en la serie de libros de gestión, análisis y sistemas de Juan Bravo C . que incluye, entre otros, a: Gestión de Procesos (2005) y gestión de proyectos de procesos y tecnología (2006).

Bibliografía: Adicionalmente , esta presentación se basa en la serie de libros de gestión, análisis y sistemas de Juan Bravo C . que incluye, entre otros, a: Gestión de Procesos (2005) y gestión de proyectos de procesos y tecnología (2006).


Funciones BásicasCasos de Uso: Crear Guías Internas de Recepción por Compra y de Despacho por Venta (Productos con registro persistente)

R1.1

R1.2

R1.3R1.4

R1.5

R1.6

R1.7

R1.8

R1.9

R1.10

R1.11

R1.12

R1.13

R1.14

Capturar y activar opciones desde un Menú de Opciones, aceptar Opción (Selección Manual).

Desplegar la Interfaz de Creación de Guía de Recepción, Nº de Guía de Recepción (correlativo) y Fecha de la Transacción, - aceptar eventual modificación de Fecha (Ingreso Manual).Capturar el Código del Encargado de Recepción (Ingreso Manual).Desplegar datos del Encargado de Recepción registrados en almacenamiento persistente.

Capturar la información del Proveedor usando el RUT (Ingreso Manual) y desplegar datos pertinentes del Proveedor registrados en almacenamiento persistente.Capturar Nº de Guía de Despacho del Proveedor (Ingreso Manual), verificar validez (No Existencia previa) y desplegarlo.Capturar Fecha (Propia) de Guía de Despacho del Proveedor (Ingreso Manual) y desplegarla.

Capturar/Verificar (C/E) Nº de Orden de Compra (Ingreso Manual) y desplegarlo.

Registrar la transacción en proceso: los Productos a recibir. Capturar la información del Producto a recibir usando el Código (interno) (Ingreso Manual).Desplegar la descripción 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 línea actualizando los totales de la Guía de Recepción en la Interfaz al dar OK a la línea.Grabar en el Detalle de la Guía de Recepción (línea a línea) los datos de cada línea a medida que se completa y calcula cada una de ellas.Actualizar los valores de existenciay recibido de Productos (evitando doble actualización) al dar OK a la Guía de Recepción en su totalidad. Además calcular el nuevo Costo Promedio.

evidente

evidente

evidenteevidente

evidente

evidente

evidente

evidente

evidente

evidente

evidente

evidente

oculta

oculta

Ref. # Función Categoría

Nota: (Craig Larman, 5.6.1.a 5.6.3, págs. 42 a 44) Las funciones básicas se “descubren” durante el desarrollo de las entrevistas con los usuarios, quienes relatan qué es lo que el sistema “debe hacer”, (enforma “evidente” u “oculta”). También el analista agregará algunas que no son evidentes para el usuario.

Nota: (Craig Larman, 5.6.1.a 5.6.3, págs. 42 a 44) Las funciones básicas se “descubren” durante el desarrollo de las entrevistas con los usuarios, quienes relatan qué es lo que el sistema “debe hacer”, (enforma “evidente” u “oculta”). También el analista agregará algunas que no son evidentes para el usuario.

(Base Craig Larman)

Flujograma : Proceso de Recepción de Productos de Proveedores - (Guía Interna de Recepción por Compra)

Proveedor

G/D Proveed.

12

3

Encargado de Recepción

G/D Proveed.

12

3

Depto. deCompras

Depto. deContabilidad

Inventario(Bodega)

Ingresar Guía de Recepción

VerificarCalidad de Productos

G/R Interna

1’2’

3’3’3’

G/D Proveed.

2’’2’’G/RInterna

3’3’

G/R Interna

G/D Proveed.

1’2’

3’

Control deCalidad

Ingresar Productosa Bodega

Ingresar Productosa Bodega

2’’’2’’’G/RInterna

G/R Interna

12

3

G/R Interna

12

3

Nota: Un determinado documento(papel o electrónico) puede ser cambiado(por ejemplo: VºBº, firma, “tick” ) ... para indicar algún tipo de acción que se ha tomado con él - tal como: revisión , aproba -ción , etc -. Con ello, aunque el documento sigue siendo “el mismo ”, ya no es “el mismo ”. Se indica gráficamente esta situa-ción por medio de “cremillas”, que se incrementan , como se muestra en este flujograma para diversos pasos que sigue la copia # 2 de la Guía de Recepción.

JUAN BRAVO C. 354

Funciones Básicas

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

Ofrecer un mecanismo de almacenamiento persistente.

Desplegar la Interfaz de Creación de Guía de Despacho, Nº de Guía de Despacho (correlativo) y Fecha de la Transacción, - aceptar eventual modificación de Fecha - (Ingreso Manual).Capturar el Código del Encargado de Despacho (Ingreso Manual).

Desplegar datos del Encargado de Despacho registrados en almacenamiento persistente.

Capturar la información 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 Condición de Pago de la Venta (Ingreso Manual) y desplegarla.

Registrar la transacción en proceso: los Productos a despachar. Capturar la información del Producto a despachar usando el Código (interno) (Ingreso Manual).Desplegar la descripción 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 línea actualizando los totales de la Guía de Despacho en la Interfaz al dar OK a la línea.Grabar en el Detalle de la Guía de Despacho (línea a línea) los datos de cada línea a medida que se completa y calcula cada una de ellas.Actualizar los valores de existenciay despachadode Productos (evitando doble actualización) al dar OK a la Guía de Despacho en su totalidad.

oculta

evidente

evidente

evidente

evidente

evidente

evidente

evidente

evidente

evidente

evidente

evidente

oculta

oculta

Ref. # Función Categoría

Casos de Uso: Crear Guías Internas de Recepción por Compra y de Despacho por Venta (Productos con registro persistente) (Base Craig Larman)

Funciones Básicas -Atributos y restricciones de las funciones del sistema

Ref. # Función Categoría Atributo Restricción Categoría

Nota: (Craig Larman, 5.7.1, págs. 45 y 46) Los atributos y restricciones de las funciones básicas se “descubren” durante el desarrollo de las entrevistas con los usuarios, quienes relatan qué atributos “debiera tener” el sistema y cuáles eventualmente serían las correspondientes restricciones, - si las hubiera - y si ellas serían “obligatorias” u “opcionales”. (Aquí, por razones de espacio, se dan unos pocos ejemplos).

Nota: (Craig Larman, 5.7.1, págs. 45 y 46) Los atributos y restricciones de las funciones básicas se “descubren” durante el desarrollo de las entrevistas con los usuarios, quienes relatan qué atributos “debiera tener” el sistema y cuáles eventualmente serían las correspondientes restricciones, - si las hubiera - y si ellas serían “obligatorias” u “opcionales”. (Aquí, por razones de espacio, se dan unos pocos ejemplos).

R1.5

R1.12

R1.15

Capturar la información del Proveedor usando el RUT y desplegar sus datos.

Capturar la Cantidad de unidades del Producto respectivo y calcular valor de la línea actualizando los totales de la Guía de Recepción en la Interfazal dar OK a la línea.

Ofrecer un mecanismo de almacena-miento persistente.

evidente

evidente

oculta

obligatoria

obligatoria

opcional

obligatoria

obligatoria

máx. 2 segundos

Estilo Windows

En colores yefectos 3D

máx. 2 segundos

Usar base de da-tos corporativa actualmente ins-talada

Tiempo de res-puesta

Interfaz

Tiempo de res-puesta

Plataforma

(Base Craig Larman)


Crear Guía Interna de Recepción por Compra

Crear Guía Interna de Despacho por Venta

Iniciar Sistema de Bodegas

Administrar Sistema de Bodega de Recepción

y Despacho

Diagrama de Casos de Uso(Casos de Uso Básicos)(Base Craig Larman)

Nota:Administrar Sistema ...Son Casos de Uso Genéricos que en el transcurso del análisis se desagregarían en otros Casos de Uso.

Encargadode Recepción(Empleado)

Encargadode Despacho(Empleado)

Cliente

Proveedor

Administrador(Empleado)

Nota:• Administrador, • Encargado de Recepción, • Encargado de Despacho...son “roles” que juegan las personas de la Organización. (No necesariamente sontrespersonas distintas).

Nota:•Para ejemplificar el método de “Desarrollo en espiral”, se estaría proponiendo estoscasos de uso para ser desarrollados en las primeras vueltas de la espiral. (No se muestran aquí todospor razones de espacio).



Realizar procesos de“Fin de Día”

Caso de Uso: Crear Guía Interna de Recepción por Compra (Productos con registro persistente)(Base Craig Larman)

Comentarios relevantes :

1) Se trata de una transacciónentre dos entidades, (con Provee-dor y Encargado de Recepción).

2) Se trata de una transacciónque implica una entrega /recepción de Productos.

3) Existe un Registro de Provee-dores.

4) Existe un Registro de Encar-gados de Recepción (Empleado).

5) Existe un Registro de Productos. 6) Se lleva un registro persistente

de la transacción.

Encargadode Recepción(Empleado)

Crear Guía Interna de Recepción por CompraCrear Guía Interna de Recepción por Compra

Terminal Recepción

• Caso de Uso: Crear Guía Interna deRecepción por Compra.

• Actores: Proveedor, Encargado de Recepción.

• Tipo: Primario.

• Descripción:Este Caso de Uso co-mienzacuando un Proveedor llega con mercadería acompañando la documen-tación legal de rigor. El Encargado registra el ingreso de la mercadería, emite la Guía Interna de Recepción porCompra, firma toda la documentación, entrega las copias pertinentes al Pro-veedor y envía las restantes copias asus respectivos destinos.El Proveedor se retira, con lo cual termina el Caso de Uso.

Proveedor

Caso de Uso de Alto Nivel

Nota : (Craig Larman, 2.7.2, pág. 26)“Los Casos de Uso de Alto Nivel sonbreves descripciones de un proceso- usualmente dos o tres frases - “.Ver también: (Craig Larman, 6.3.1, pág. 49)

Nota: Descripción - Sigue la narrativa que se desprendedel Flujograma de Informacióncorrespondiente -.

Nota: El inicio y el fin del Caso de Uso deberíanestar inequívocamente indicados en la narrativa. Ello evita las superposicionesy ambigüe-dadesen las especificaciones.

JUAN BRAVO C. 356

Caso de Uso: (Expandido ) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Crear Guía Interna de

Recepción por Compras

Caso de Uso : Crear Guía Interna de Recepción por Compra

Actores : Proveedor (Iniciador) , Encargado de Recepción (Actor Primario).

Propósito: Capturar Datos de Recepción de Productos Comprados.

Resumen: Este Caso de Uso comienzacuando un Proveedor contacta a un Encargado de Re-cepción para solicitarle que reciba los Productos que está entregando, la Trans-acción requerida la documenta con una Guía de Despacho o Factura. El Encargado de Recepción verifica la entrega física (Cantidad y Estado General) contra lo indi-cado por el Documento adjunto y después registra en el Terminal de Recepción los datos consignados en el mismo, al terminar confirma la Transacción. El Proveedor recibe la 3ª copia de la Guía de Recepción y la 3ª copia de su Guía de Despacho o Factura ambas firmadas por el Encargado de Recepción, quien envía a sus respec-tivos destinos las restantes copias también firmadas (según Flujograma de Infor-mación correspondiente). El Caso de Uso termina cuando el Proveedor se retira.

Tipo: Primario y real.

Referencias cruzadas: Funciones: R1.1, R1.2, R1.3, R1.4, R1.5, R1.6, R1.7, R1.8

R1.9, R1.10, R1.11, R1.12, R1.13, R1.14, R1.15


Terminal Recepción

Proveedor


Terminal RecepciónTerminal Recepción

Proveedor

Caso de Uso Expandido

Nota : Este Caso de Uso com-prende desde la Hoja actual hastalas siguientes 4 Hojas (5 en total)

Nota : (Craig Larman, 2.7.2, pág. 26)“Los Casos de Uso Expandidos sonextensas narrativas de descripción de un proceso - pueden contener cientos de frases - “.Ver también: (Craig Larman, 6.3.2, pág. 50).

Caso de Uso Expandido

Curso Normal de los EventosAcción de los actores Respuestas del Sistema

1. Este caso comienza cuando un Proveedor se contacta con un Encargado de Recepción para solicitar que se efectúe una Recepción de Productos. (Petición).

2. El Encargado de Recepción acuerda realizar la Transacción. (Aceptación del compromiso) y para ello ingresa a la opción deCrear Guía de Recepción del Menú de Opciones haciendo (Click)y después oprimiendo la tecla (Tab). 3. El sistema despliega la interfaz de Creación de Guía de Recepción,

asigna y despliega automáticamente en A el Nº de Guía de Recepcióncorrelativo correspondiente y en B la fecha del sistema.4. El Encargado de Recepción verifica visualmente el Nº de Guía de

Recepción y Fecha ofrecidos por el sistema y a continuacióningresa su identificación (Código) en C.

6. El Encargado de Recepción ingresa en E el RUT del Proveedor yverifica los datos del mismo desplegados por el sistema.

5. El sistema obtiene y despliega el nombre del Encargado de Recepciónen D.

7. El sistema despliega los datos básicos del Proveedor (Razón Social,Dirección, e-Mail, Comuna, Ciudad, Teléfono, Fax) en F, G, H, I , J, Ky L respectivamente.

10.El Encargado de Recepción pasa a la sección de detalle, en el cualingresa el Código del Producto en P. 11.El sistema despliega el Nº de Línea en LL , obtiene y despliega la

descripción del Producto en Q.12.El Encargado de Recepción verifica los datos del Producto e

ingresa el costo unitario(Precio) y la cantidad recibida en R yS. Luego oprime (Tab) para grabar la línea actual y crear unanueva línea o terminar el ingreso de datos. 13. El sistema calcula el valor de la línea ingresada y lo acumula, desplegan-

do los valores en T y U, a la vez que graba la línea recién completada.14.Al terminar de ingresar los Productos, el Encargado de Recep-

ción oprime el botón V para indicar al sistema el fin de lacaptura de datos. 15.El sistema calcula los valores subtotales / total y los despliega / re-

despliega en los campos T y U, además actualiza los datos de latransacción en el sistema de almacenamiento persistente. Calcula el costo promedio y lo actualiza Genera un original y 2 copias de latransacción realizada utilizando la interfaz de salida indicada.“Limpia” la interfaz de entrada y posiciona el cursor en A.

16. El Encargado de Recepción cierra la interfaz de Transacción opri-miendo el botón XX para volver al Menú de Opciones y entrega o envía una copia de la Transacción terminada al Proveedor por la vía de comunicación preestablecida. (Notificación de cumpli-miento del compromiso). Opcionalmente vuelve a oprimir (Tab) para ingresar otra recepción, con lo cual el sistema pasa a3.

Caso de Uso: (Expandido ) Crear Guía Interna de Recepción por Compra(Productos con registro persistente) (Base Craig Larman )

8. El Encargado de Recepción ingresa en M , N y O respectivamenteel Nº de Guía de Despacho del Proveedor, la Fecha de la Guía deDespacho y el Nº de la Orden de Compra.

9. El sistema verifica la validez / existencia del Nº de la Orden de Compra.



Fecha Recepción

RUT Proveedor -



AAAAAAAA

CCCCCCCCBBBBBBBB

DDDDDDDD

EEEEEEEE FFFFFFFF

GGGGGGGG

Caso de Uso: (Expandido ) Crear Guía Interna de Recepción por Compra(Productos con registro persistente) (Base Craig Larman)

Interfaz de Entrada

Dirección Proveedor


HHHHHHHH



GrabarGrabar


Total acumulado



Cerrada

Anulada

SSSSSSSS TTTTTTTT

UUUUUUUU


AnularAnular

WW

SalirSalir

XX



e-Mail

YY ZZ

LLLLLLLLLLLLLLLL

XXXX

Notas adicionales a la Interfaz de Entrada:( para desarrollar en vueltas futuras de la espiral)

Curso Normal1) Considerar operacion(es) de Cerrado en Encabezado2) Considerar operacion(es) y “flag” de Cerrada en Líneas

Excepciones3) Considerar operación(es) y “flag” de Reversadoen Encabezado4) Considerar operacion(es) de Anulado de Encabezado5) Considerar operacion(es) y “flag” de Anulada en Líneas6) Considerar operacion(es) y “flag” de Reversada en Líneas7) Considerar operación(es) de Modificar en Encabezado8) Considerar operación(es de Modificar en Encabezado9) Considerar operación(es) de Cancelar en Encabezado

10) Considerar operación(es) de Cancelar en Líneas

Notas adicionales a la Interfaz de Entrada:( para desarrollar en vueltas futuras de la espiral)

Curso Normal1) Considerar operacion(es) de Cerrado en Encabezado2) Considerar operacion(es) y “flag” de Cerrada en Líneas

Excepciones3) Considerar operación(es) y “flag” de Reversadoen Encabezado4) Considerar operacion(es) de Anulado de Encabezado5) Considerar operacion(es) y “flag” de Anulada en Líneas6) Considerar operacion(es) y “flag” de Reversada en Líneas7) Considerar operación(es) de Modificar en Encabezado8) Considerar operación(es de Modificar en Encabezado9) Considerar operación(es) de Cancelar en Encabezado

10) Considerar operación(es) de Cancelar en Líneas

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 (Código no existe). Comunicarse con Administrador.2) Campo M : Nº de Guía 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 Recepción no registrado (Código no existe). Comunicarse con Administrador.5) Campo O : Nº de Orden de Compra no existe. Comunicarse con Departamento de Compras.

Caso de Uso: (Expandido ) Crear Guía Interna de Recepción por Compra(Productos con registro persistente)(Base Craig Larman)

Nota:Se indican algunasde las excepcio-nes posibles únicamente a modo deejemplo.

Nota:Se indican algunasde las excepcio-nes posibles únicamente a modo deejemplo.

JUAN BRAVO C. 358

Guía de Recepción Nª Fecha

RUT Proveedor X-

Comuna Ciudad Teléfono Fax


Total Neto

Firma Autorizaday Timbre

999.999 99/99/9999

999.999.999 XXXXXXX

Razón Social Proveedor XXXXXXXRazón Social Proveedor XXXXXXX

Dirección Proveedor XXXXXXXXXXXXXX

XXXXXXX XXXXXXX XXXXXXX XXXXXXX

XXXXXXX XXXXXXXXXXXX 99999999,99 999999,99

99999999,99

99


Caso de Uso (Expandido ): Crear Guía Interna de Recepción por Compra(Productos con registro persistente)(Base Craig Larman)

Interfaz de Salida

Nº G/D del Proveedor 999.999 Fecha G/D Proveedor 99/99/9999Nº G/D del Proveedor 999.999 Fecha G/D Proveedor 99/99/9999 Nº de O/C. 999.999

e-Mail XXXXXXXXXXXXXX

ProductosProductos

Provee-dores

Provee-dores

Encabezado de Guía Interna de Recepción por

Compra

1

*

*

*

Modelo Conceptual(simplificado)Crear Guía Interna de Recepción por Compra(Productos con registro persistente)(Base Craig Larman)

Detalle de Guía Interna de Recep-ción por Compra

1

1

11..5

Ordenesde CompraOrdenesde Compra1

*Emplea-

dos

CódigoNombre

Emplea-dos

Emplea-dos

CódigoNombre

CódigoDescripciónCosto

Nº de GuíaFechaProveedorNombre

DescripciónCostoCantidad

RUTNombreDirección

Nº OCFecha

Nota:Dentro de losrequerimientos,no necesariamente se encuentrael concepto deOrden de Compra.(Puede ser un ingreso manual).


Nota : En este modelo se consideranlos conceptos mínimos. En un análisisy desarrollo posteriores se podríanin-cluir conceptos tales comoBodega, Terminal, Empresa, etc. Por lo contrario,se podríanexcluir : Empleados, Ordenes de Compra.

Nota:La flecha gruesaentre el Encabe-zadoy el Detalle indica una Relación de Pertenencia. (Base Juan Bravo C.-“La Nueva Visión...” pág 200)

Nota:La flecha gruesaentre el Encabe-zadoy el Detalle indica una Relación de Pertenencia. (Base Juan Bravo C.-“La Nueva Visión...” pág 200)

Nota: Según Craig Larman(9.3 y 9.4 - págs. 87 a 91 -, además de 9.6.1 a 9.6.3 - págs.96 y 97) Se trata de conceptos, asocia-cionesy atributos del mundo real, nose trata de unmodelo de software.

Nota: Según Craig Larman(9.3 y 9.4 - págs. 87 a 91 -, además de 9.6.1 a 9.6.3 - págs.96 y 97) Se trata de conceptos, asocia-cionesy atributos del mundo real, nose trata de unmodelo de software.


Productos

Provee-dores

Provee-dores

Encabezado de Guía Interna de Recep-ción por Compra

1

*

*

*

Diagrama de Diseño de Clases(Borrador inicial)Crear Guía Interna de Recepción por Compra(Productos con registro persistente)(Base Craig Larman)

Detalle de Guía Interna de Recep-ción por Compra

1

111..5

Ordenesde CompraOrdenesde Compra1

*

CódigoNombre

CódigoDescipciónCosto

RUT ProveedorNº de Guía ProveedorNº Guía InternaFecha RecepciónCódigo Enc. RecepciónFecha Guía ProveedorNº de Ord. de Compra

DescripciónCostoCantidad

RUTNombreDirección

Nº OCFecha

Nota: Según Craig Larman(21.3, pág.257):“ Si bien la pre-sentación de losdiagramas declases es posterior a la creación de losdiagramas de interacción, en la prácticausualmente se crean en para-lelo. Muchas clases, métodos y relacio-nes pueden bosquejarsetempranamenteen la etapa de Diseño”

Nota: Según Craig Larman(21.3, pág.257):“ Si bien la pre-sentación de losdiagramas declases es posterior a la creación de losdiagramas de interacción, en la prácticausualmente se crean en para-lelo. Muchas clases, métodos y relacio-nes pueden bosquejarsetempranamenteen la etapa de Diseño”

Emplea-dos

Emplea-dos

Emplea-dos

Nota: Según Craig Larman(21.8.4 a 21.8.8 - págs.262 - 264)Salvocasos específicos, es conve-nienteomitir los métodos :crear(),modificar(), eliminar() y consultar()en los diagramas de clases dado queno agregan valor y aumentan el“ruido” - se consideranimplícitos -

Nota: Según Craig Larman(21.8.4 a 21.8.8 - págs.262 - 264)Salvocasos específicos, es conve-nienteomitir los métodos :crear(),modificar(), eliminar() y consultar()en los diagramas de clases dado queno agregan valor y aumentan el“ruido” - se consideranimplícitos -

costoProm()

total()

subtotal()

validarRut()


Nota: A diferencia del Modelo Conceptual, que muestra atributos“útiles” para entender los concep-tos del contexto, se “descubrió” - obser-vando la interfaz de entrada -, la conve-niencia de agregar otros atributos al enca-bezado. (A su vez se eliminó : Nombre)

Nota: A diferencia del Modelo Conceptual, que muestra atributos“útiles” para entender los concep-tos del contexto, se “descubrió” - obser-vando la interfaz de entrada -, la conve-niencia de agregar otros atributos al enca-bezado. (A su vez se eliminó : Nombre)

Diagrama de Secuencia del SistemaCrear Guía Interna de Recepción por Compra (Productos con registro persistente)(Base Craig Larman)

Encargado de RecepciónEncargado de Recepción:Sistema

Ingresar a la Opción del Menú

Ingresar Código del Empleado en Encabezado

Ingresar Código del Producto en Línea Detalle

Ingresar Precio y Cantidad del Producto

Dar OK a la Línea de Detalle

Dar OK al Final para Terminar la Creación

Caso de Uso:Crear Guía de Recepción( Curso Normal de los Eventos)

Obtener / Ingresar(Tab) Nº de Guía Recepción y Fecha sistema, verificar correlativo y fecha. Ingresar Código 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 Provee-dor ( Nº Guía, Fecha, Nº O/C )Para cada línea:• Ingresar el Código del

Producto• Obtener / Verificar datos del

Producto• Ingresar precio y cantidad del

Producto• Dar OK a la línea (Grabar)Al terminar :•Dar OK a la Transacción(Grabar)• Salir al Menú

Versión en Lenguaje Natural

Reiterar hastaque no haya más Productos que ingresar

Salir al Menú

Ingresar Nº Guía Proveedor, Fecha y Nº O/C en Encabezado

Ingresar RUT del Proveedor en Encabezado

Crear la Guía de Recepción

Desplegar la Interfaz

Calcular la Línea de Detalle

JUAN BRAVO C. 360

Diagrama de Secuencia del SistemaCrear Guía Interna de Recepción por Compra(Productos con registro persistente)(Base Craig Larman)

Encargado de RecepciónEncargado de Recepción:Sistema

crearEncabezado(NumGuiaRecCom, FechaR)

ingresarRutProveedor(RutProveedor)

ingresarCodEmpleado(CodigoEmpleado)

ingresarCodProducto(CodigoProducto)

ingresarPrecioCantidad(Precio,Cantidad)

calcularTotales()

terminarTransacción()

Versión llamando los Eventospor su Nombre

( equivalente a Operaciones del sistema)

salirAMenú()











Reiterar hastaque no haya más Productos que ingresar

ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)

ingresarOpción(CrearGuiaRecepcion)

desplegar(NumGuiaRecCom, FechaR)

Nota: desplegares subordinadode ingresarOpcion y no esinvocado por el actor enforma directa.

Nota: desplegares subordinadode ingresarOpcion y no esinvocado por el actor enforma directa.

grabarLínea()

Nota: calcularTo-taleses subordinadodegrabarLínea y noes invocado por el actoren forma directa.

Nota: calcularTo-taleses subordinadodegrabarLínea y noes invocado por el actoren forma directa.

Operaciones del SistemaCrear Guía Interna de Recepción por Compra (Productos con registro persistente)(Base Craig Larman)

grabarLínea()

terminarTransacción()

Sistema

Visión Dinámica del Sistema

salirAMenu()


ingresarCodEmpleado(CodigoEmpleado)

ingresarRutProveedor(RutProveedor)


ingresarCodProducto(CodigoProducto)

ingresarPrecioCantidad(Precio,Cantidad)


ingresarOpción(CrearGuiaRecepcion)

desplegar(NumGuiaRecCom, FechaR)

calcularTotales()


Contratos: Crear Guía Interna de Recepción por Compra(Productos con registro persistente)(Base Craig Larman)

Postcondiciones:

ContratoNombre: ingresarOpcion(CrearGuiaRecepcion)

Responsabilidades:

Tipo:Referencias cruzadas:

Notas:

Excepciones:Salida:

Precondiciones:

Aceptar (Click ) en la opción del Menú. Obtener el siguiente Nº de Guíacorrelativo (NumGuiaRecCom). Obtener la fecha del sistema (FechaR) . Usar ambos parámetros para invocar el despliegue de la interfaz de CrearGuiaRecepción

SistemaR1.1

Usar Sistema de Menú; Ahora() de MS Access; obtener último Nº de Guía de Recepción válido y sumarle “1” (uno) para obtener el nuevo Nº correlativo de Guía de Recepción.N / A

N / A

El sistema tiene el Menú y la opción Crear Guía de Recepción por Comprarequerida instalados y activos.Además conoce y tiene acceso a EncGuiaRecCompra.NumGuiaRecCom

• Se aceptó (Click ) en el Menú de Opciones. Nota: Obtener Fecha del sistema y obtener Nº de Guía correlativo son opera-

ciones (métodos) que no son evidentespara el usuario en este momen-to, sin embargo, se harán 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 Guía de

Recepción por Compra (NumGuiaRecCom).• Se invocó el despliegue de la interfaz de Creación de la Guía de Recepción

por Compra usando los parámetros NumGuiaRecComy FechaR.

Postcondiciones:

ContratoNombre: ingresarOpcion(CrearGuiaRecepcion)

Responsabilidades:


Notas:

Excepciones:Salida:

Precondiciones:

Aceptar (Click ) en la opción del Menú. Obtener el siguiente Nº de Guíacorrelativo (NumGuiaRecCom). Obtener la fecha del sistema (FechaR) . Usar ambos parámetros para invocar el despliegue de la interfaz de CrearGuiaRecepción

SistemaR1.1

Usar Sistema de Menú; Ahora() de MS Access; obtener último Nº de Guía de Recepción válido y sumarle “1” (uno) para obtener el nuevo Nº correlativo de Guía de Recepción.N / A

N / A

El sistema tiene el Menú y la opción Crear Guía de Recepción por Comprarequerida instalados y activos.Además conoce y tiene acceso a EncGuiaRecCompra.NumGuiaRecCom

• Se aceptó (Click ) en el Menú de Opciones. Nota: Obtener Fecha del sistema y obtener Nº de Guía correlativo son opera-

ciones (métodos) que no son evidentespara el usuario en este momen-to, sin embargo, se harán 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 Guía de

Recepción por Compra (NumGuiaRecCom).• Se invocó el despliegue de la interfaz de Creación de la Guía de Recepción

por Compra usando los parámetros NumGuiaRecComy FechaR.

Nota:

Los nombres de elementos usados

en los contratos hacen referencia

al Diagrama de Secuencia de pág. 18,

al Modelo de Clases de pág. Nº 38

y al Modelo Funcional de pág. Nº 39.

Nota:






Contratos:Crear Guía Interna de Recepciónpor Compra(Productos con registro persistente)(Base Craig Larman)

Postcondiciones:

ContratoNombre: desplegar(NumGuiaRecCom, FechaR)

Responsabilidades:

Tipo:

Referencias cruzadas:

Notas:

Excepciones:

Salida:

Precondiciones:

Desplegar la Interfaz de Creación de Guía de Recepción. Aceptar (Tab) para iniciar el ingreso de la transacción. Desplegar NumGuiaRecCom, desplegar FechaR, opcionalmente aceptar modificación manual de la fecha.

Sistema

R1.2

Esta operación es invocada por ingresarOpcion. El Empleado oprime (Tab) para iniciar el ingreso.N / A

N / A

El sistema tiene el Menú y la opción Crear Guía de Recepción por Comprarequerida instalados y activos. Tiene disponibles a NumGuiaRecComyFechaR.

• Se desplegó la interfaz de Crear Guía de Recepción por Compra (“limpia”).• Se posicionó el cursor en A y se aceptó (Tab) para proseguir.• Se desplegó el Número correlativo de Guía de Recepción: NumGuiaRecCompraen A y la Fecha:FechaRen B.

Postcondiciones:

ContratoNombre: desplegar(NumGuiaRecCom, FechaR)

Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

Desplegar la Interfaz de Creación de Guía de Recepción. Aceptar (Tab) para iniciar el ingreso de la transacción. Desplegar NumGuiaRecCom, desplegar FechaR, opcionalmente aceptar modificación manual de la fecha.

Sistema

R1.2

Esta operación es invocada por ingresarOpcion. El Empleado oprime (Tab) para iniciar el ingreso.N / A

N / A

El sistema tiene el Menú y la opción Crear Guía de Recepción por Comprarequerida instalados y activos. Tiene disponibles a NumGuiaRecComyFechaR.

• Se desplegó la interfaz de Crear Guía de Recepción por Compra (“limpia”).• Se posicionó el cursor en A y se aceptó (Tab) para proseguir.• Se desplegó el Número correlativo de Guía de Recepción: NumGuiaRecCompraen A y la Fecha:FechaRen B.

Nota:






JUAN BRAVO C. 362

Contratos: Crear Guía Interna de Recepciónpor Compra(Productos con registro persistente)(Base Craig Larman)

Postcondiciones:

ContratoNombre: crearGuiaRecCompra(NumGuiaRecCom, FechaR)

Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

Crear instancias deEncGuiaRecCompra y DetGuiaRecCompra y establecer las asociaciones necesarias entreTerminal, EncGuiaRecCompra y DetGuiaRecCompra

Sistema

R1.15

El Empleado oprime (Tab) para cambiar de campo en la interfazpara el ingreso. Opcionalmente usa el “mouse”N / A

N / A

El sistema tiene el Menú, la opción Crear Guía de Recepción por Compray la interfaz correspondiente requerida instalados y activos.

• Se creó una nueva instancia deEncGuiaRecCompra(creación de instancia)• Se asoció EncGuiaRecCompraa Terminal(asociación formada)• Se creó una nueva instancia DetGuiaRecCompra(creación de instancia)• Se asoció DetGuiaRecCompraa EncGuiaRecCompra(asociación formada)• Se asignó el Número correlativo de Guía de Recepción al campo:EncGuiaRecCompra.NumGuiaRecCom(modificación de atributos)

• Se asignó la Fecha del sistema al campo:EncGuíaRecCompra.FechaR( modificación de atributos)

• Se posicionó el cursor en el campo C : Código Enc. Recepción

Postcondiciones:

ContratoNombre: crearGuiaRecCompra(NumGuiaRecCom, FechaR)

Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

Crear instancias deEncGuiaRecCompra y DetGuiaRecCompra y establecer las asociaciones necesarias entreTerminal, EncGuiaRecCompra y DetGuiaRecCompra

Sistema

R1.15

El Empleado oprime (Tab) para cambiar de campo en la interfazpara el ingreso. Opcionalmente usa el “mouse”N / A

N / A

El sistema tiene el Menú, la opción Crear Guía de Recepción por Compray la interfaz correspondiente requerida instalados y activos.

• Se creó una nueva instancia deEncGuiaRecCompra(creación de instancia)• Se asoció EncGuiaRecCompraa Terminal(asociación formada)• Se creó una nueva instancia DetGuiaRecCompra(creación de instancia)• Se asoció DetGuiaRecCompraa EncGuiaRecCompra(asociación formada)• Se asignó el Número correlativo de Guía de Recepción al campo:EncGuiaRecCompra.NumGuiaRecCom(modificación de atributos)

• Se asignó la Fecha del sistema al campo:EncGuíaRecCompra.FechaR( modificación de atributos)

• Se posicionó el cursor en el campo C : Código Enc. Recepción

Nota:






Nota:






Postcondiciones:

Contrato

Nombre: ingresarCodEmpleado(CodigoEmpleado)Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

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 continuación posicionar el cursor en el campo E.

Sistema

R1.3, R1.4, R1.15

Error en ingreso manual del Código o Código no registrado

N / A

El sistema conoce a Empleados.CodigoEmpleado(Registrado opor-tunamente con anterioridad)

Usar Base de Datos MS Access y (Tab) para sucesivos campos

• Se desplegó CodigoEmpleadoen C y NombreenD..• Se asoció EncGuiaRecCompraa una instancia de Empleadosbasado en una igualdad de CodigoEmpleado(asociación formada)

• Se asignó CodigoEmpleadoa EncGuiaRecCompra.CodigoEmpleado(modi-ficación de atributo)Nota : Alternativamente( desde Lista de Valores Posibles ) - Sustituyendo

CodigoEmpleadopor Nombre -- Se asignó NombreaEncGuiaRecCompra.Nombre(modificación de

atributo).• Se posicionó el cursor en el campo E: RUT Proveedor

Postcondiciones:

Contrato


Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.3, R1.4, R1.15


N / A


Contrato


Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.3, R1.4, R1.15


N / A


Usar Base de Datos MS Access y (Tab) para sucesivos campos

• Se desplegó CodigoEmpleadoen C y NombreenD..• Se asoció EncGuiaRecCompraa una instancia de Empleadosbasado en una igualdad de CodigoEmpleado(asociación formada)

• Se asignó CodigoEmpleadoa EncGuiaRecCompra.CodigoEmpleado(modi-ficación de atributo)Nota : Alternativamente( desde Lista de Valores Posibles ) - Sustituyendo

CodigoEmpleadopor Nombre -- Se asignó NombreaEncGuiaRecCompra.Nombre(modificación de

atributo).• Se posicionó el cursor en el campo E: RUT Proveedor

Nota:








Postcondiciones:

Contrato

Nombre: ingresarRutProveedor(RutProveedor)

Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

Aceptar el ingreso de RutProveedor, por su intermedio, obtener y des-plegar los Datos del Proveedor registrados en el sistema de almacena-miento persistente. A continuación posicionar el cursor en el campo M.

Sistema

R1.5, R1.15

Error en ingreso manual del RUT o RUT no registrado

N / A

El sistema conoce a Proveedores.RutProveedor(Registrado oportuna-mente con anterioridad)

• Se desplegó RutProveedoren el campo E• Se asoció EncGuiaRecCompraa una instancia de Proveedoresbasado en una

igualdad de RutProveedor(asociación formada) • Se asignó RutProveedora EncGuiaRecCompra.RutProveedor(modificación deatributo)

• Se desplegaron los datos básicos del Proveedor según 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 : Guía de Despacho de Proveedor Nº

Usar Base de Datos MS Access - el Encargado de Recepción oprime (Tab) para pasar a los sucesivos campos -

Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.5, R1.15


N / A







Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.5, R1.15


N / A






Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.5, R1.15


N / A


Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.5, R1.15


N / A






Usar Base de Datos MS Access - el Encargado de Recepción oprime (Tab) para pasar a los sucesivos campos -Nota:







Postcondiciones:

Contrato

Nombre: ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)

Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

Aceptar el ingreso de NumGDP, FecGD, NumOC,eventualmente verificar existencia del Nº de Orden de Compra registrada en el sistema de almace-namiento persistente. A continuación posicionar el cursor en el campo P.

Sistema

R1.6, R1.7 y R1.8, R1.15

N / A

N / A

El sistema eventualmente conoce a EncOrdCompra.NumOC(Registradooportunamente con anterioridad). Está disponible la Guía de Despachodel Proveedor.

• Se desplegó NumGDP, FecGD, NumOCen los campos M , N y O• Eventualmente, se asoció EncGuiaRecCompraa una instancia de EncOrdCom-

pra basado en una igualdad de NumOC(asociación formada) • Se asignó NumGDP a EncGuiaRecCompra.NumGDP

(modificación de atributo)• Se asignó FecGDa EncGuiaRecCompra.FecGD(modificación de atributo)• Se asignó NumOCa EncGuiaRecCompra.NumOC(modificación de atributo)• Se posicionó el cursor en el campo P:Código.


Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.6, R1.7 y R1.8, R1.15

N / A

N / A






Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.6, R1.7 y R1.8, R1.15

N / A

N / A





Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.6, R1.7 y R1.8, R1.15

N / A

N / A


Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.6, R1.7 y R1.8, R1.15

N / A

N / A






Nota:







JUAN BRAVO C. 364

Usar Base de Datos MS Access y tecla (Tab)

Postcondiciones:

ContratoNombre: ingresarCodProducto(CodigoProducto)

Responsabilidades:


Notas:

Excepciones:

Salida:

Precondiciones:

Aceptar el ingreso de CodigoProducto. Basado en CodigoProducto, ob-tener y desplegar los Datos del Producto registrados en el sistema de almacenamiento persistente. Al oprimir (Tab) - fin de ingreso de Codi-goProducto- asignar Número correlativo a la Instancia de DetGuía-RecCompra.NumLineay pasar al campo Q. Si la Descripciónes la cor-recta pasar (Tab) al campo R: Precio.SistemaR1.9, R1.10, R1.15


N / A

El sistema conoce a Productos.CodigoProducto(Registrado oportuna-mente con anterioridad)

• Se redesplegó CodigoProductoen P• Se desplegó el Número de Línea NumLíneaen LL• Se asocióDetGuíaRecCompraa una instancia de Productosbasado en una

igualdad de CodigoProducto(asociación formada) • Se asignóNumLíneaa DetGuiaRecCompra.NumLínea( modificación de

atributo )• Se asoció la nueva línea de DetGuíaRecCompra a EncGuíaRecCompra(asociación formada)

• Se asignóCodigoProductoaDetGuiaRecCompra.CodigoProducto(modi-ficación de atributo)

• Se desplegó la Descripción del Producto, Descripcionen Q.• Se posicionó el cursor en R: Precio

Postcondiciones:


Responsabilidades:


Notas:

Excepciones:

Salida:

Precondiciones:



N / A



Responsabilidades:


Notas:

Excepciones:

Salida:

Precondiciones:



N / A


• Se redesplegó CodigoProductoen P• Se desplegó el Número de Línea NumLíneaen LL• Se asocióDetGuíaRecCompraa una instancia de Productosbasado en una

igualdad de CodigoProducto(asociación formada) • Se asignóNumLíneaa DetGuiaRecCompra.NumLínea( modificación de

atributo )• Se asoció la nueva línea de DetGuíaRecCompra a EncGuíaRecCompra(asociación formada)

• Se asignóCodigoProductoaDetGuiaRecCompra.CodigoProducto(modi-ficación de atributo)

• Se desplegó la Descripción del Producto, Descripcionen Q.• Se posicionó el cursor en R: Precio

Nota:







Usar Base de Datos MS Access

Postcondiciones:

Contrato

Nombre: ingresarPrecioCantidad(Precio, Cantidad)

Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

Aceptar el Preciodel 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.11y R1.12

N / A

El sistema conoce aProductos.Existencia (Registrado oportuna-mente con anterioridad)

• Se posicionó el cursor en R• Se redesplegóPrecioen R y se posicionó el cursor en S.• Se redesplegóCantidaden S• Se asignó Precioa DetGuiaRecCompra.Precio y Cantidada DetGuiaRecCompra.Cantidad( modificación de atributos)

• Se posicionó el cursor en T: Valor Neto

Usar Base de Datos MS Access

Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.11y R1.12

N / A




Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.11y R1.12

N / A




Postcondiciones:

Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.11y R1.12

N / A


Contrato


Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:


Sistema

R1.11y R1.12

N / A




Nota:







N / A


ContratoNombre: grabarLínea()

Responsabilidades:Aceptar avance con (Tab) hasta la siguiente línea de la interfaz, creandouna nueva Línea de DetGuiaRecCompra. Calcular /ValorLíneay desple-garlo en T de la línea previa. Grabar en almacenamiento persistente un registro de DetGuiaRecCompracon los datos ingresados/calculados en la línea previa (anterior). Calcular /ValorTotaly desplegarlo en U. Posicio-nar el cursor en P de la nueva línea.

Postcondiciones:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones: N / A

Sistema

R1.13, R1.15

N / A

• Se calculó /ValorLíneay se desplegó en T• Se calculó/recalculó /ValorTotal y se desplegó/redesplegó en U.• Se asignó /ValorLíneaa DetGuiaRecCompra./ValorLínea( modificación de atributo)

• Se grabó en almacenamiento persistente el registro de DetGuiaRecComprarecién completado

• Se creó una nueva Línea deDetGuiaRecCompra.(creación de instancia)• Se asoció la nueva Línea de DetGuiaRecCompra.a EncGuiaRecCompra(asociación formada)

• Se posicionó el cursor en P de la nueva Línea de DetGuiaRecCompra.

Usar Base de Datos MS Access. En este punto el sistema queda listo parareiterar el ingreso de un nuevo código CodigoProductoo caso contrario, pasar a terminarTransacción()

N / A

ContratoNombre: grabarLínea()

Responsabilidades:Aceptar avance con (Tab) hasta la siguiente línea de la interfaz, creandouna nueva Línea de DetGuiaRecCompra. Calcular /ValorLíneay desple-garlo en T de la línea previa. Grabar en almacenamiento persistente un registro de DetGuiaRecCompracon los datos ingresados/calculados en la línea previa (anterior). Calcular /ValorTotaly desplegarlo en U. Posicio-nar el cursor en P de la nueva línea.

Postcondiciones:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones: N / A

Sistema

R1.13, R1.15

N / A

• Se calculó /ValorLíneay se desplegó en T• Se calculó/recalculó /ValorTotal y se desplegó/redesplegó en U.• Se asignó /ValorLíneaa DetGuiaRecCompra./ValorLínea( modificación de atributo)

• Se grabó en almacenamiento persistente el registro de DetGuiaRecComprarecién completado

• Se creó una nueva Línea deDetGuiaRecCompra.(creación de instancia)• Se asoció la nueva Línea de DetGuiaRecCompra.a EncGuiaRecCompra(asociación formada)

• Se posicionó el cursor en P de la nueva Línea de DetGuiaRecCompra.

Usar Base de Datos MS Access. En este punto el sistema queda listo parareiterar el ingreso de un nuevo código CodigoProductoo caso contrario, pasar a terminarTransacción()

N / A

Nota:







Postcondiciones:

ContratoNombre: terminarTransacción()

Responsabilidades:

Tipo:


Notas:

Excepciones:

Salida:

Precondiciones:

Aceptar (click) del Botón V (Grabar ). Recalcular /ValorTotal y redesple-garlo en U. Grabar en almacenamiento persistente la instancia actual de EncGuiaRecCompra.”Limpiar” los datos desplegados en la interfaz. Actua-lizar Productos.Existencia, Productos.Recibido, Productos.CostoUnyDetGuiaRecCompra.notAct. Posicionar en A el cursor.

Sistema

R1.2, R1.14, R1.15

N / A

• Se activó onClick_CBGrabarde commandGrabar• Se recalculó /ValorTotal y se grabó/regrabó en almacenamiento persistente la instancia EncGuiaRecCompray las líneas completadas DetGuiaRecCompra.

• Se verificó notAct() de DetGuiaRecCompray se actualizó Productos.Existencia, Productos.Recibido y Productos.CostoUn, regrabando los registros de Productosafectados por la transacción (modificación de atributo), después de ello, se le asignó el valor falseal atributo DetGuiaRecCompra.notAct(modificación de atributo), regrabando los registros correspondientes de DetGuiaRecCompra.

• Se creó una nueva EncGuiaRecCompra(creación de instancia) (en blanco)• La nueva EncGuiaRecComprafue asociada a Terminal(asociación formada)• Se creó una nueva DetGuiaRecCompra( creación de instancia) (en blanco)• Se asoció la nueva instancia de DetGuiaRecCompraa EncGuiaRecCompra (asociación formada)

• Se posicionó el cursor en A, esperando la próxima acción del usuario.

Usar Base de Datos MS Access. Al terminar, el sistema queda listo pa-ra ingresar una nueva transacción o volver al Menú de opciones.

N / A

Productos.Existencia y Productos.Recibido ya fueron actualizados.

Nota:







JUAN BRAVO C. 366

Etapa de Diseño

Las páginas siguientes corresponden a la etapa de diseño,la cual se extiende hasta la documentación de las clasesde diseño y los diagramas correspondientes -.

FechaFecha

:EncGuiaRecCompra:EncGuiaRecComprat1:Terminalt1:Terminal1:NumGuiaRecCom := siguiente() :NumGuia

2:FechaR := ahora() :Fecha

r 1:EncGuiaRecCompra 3 :[NuevaGuiaRecepcion] crearEncabezado( NumGuiaRecCom , FechaR )

t1:Terminal

l1:DetGuiaRecCompra

r 1:EncGuiaRecCompra r 1:EncGuiaRecCompra 3 :[NuevaGuiaRecepcion] crearEncabezado( NumGuiaRecCom , FechaR )

t1:Terminal

l1:DetGuiaRecCompra

3 :[NuevaGuiaRecepcion] crearEncabezado( NumGuiaRecCom , FechaR )t1:Terminalt1:Terminalt1:Terminal

l1:DetGuiaRecCompra

3.1 :[NuevaGuiaRecepcion] crearDetRecCompra( NumGuiaRecCom)

Nota :crearDetRecCompra() esuna de las 4 funciones básicas implícitas. (Podría ser omitida en el Modelo de Datos).

crearEncabezado( NumGuiaRecCom , FechaR )

Omisión del Contenedor de LíneasNota: Según Craig Larman( 21.8.6 - pg.262 ) : “ Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / colec-ciónen sí mismo... estas clases ( tales comojava.util.Vector... ) sonclases predefinidasde la biblioteca de clases...no es útil mos-trarlas explícitamente... agregan “ruido” pero poca información nueva. ”

Omisión del Contenedor de LíneasNota: Según Craig Larman( 21.8.6 - pg.262 ) : “ Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / colec-ciónen sí mismo... estas clases ( tales comojava.util.Vector... ) sonclases predefinidasde la biblioteca de clases...no es útil mos-trarlas explícitamente... agregan “ruido” pero poca información nueva. ”

Diagramas de Colaboración:Creación de EncGuiaRecCompraingresarOpcion(CrearGuiaRecepcion)desplegar(GuiaRecCompra)crearEncabezado(NumGuiaRecCom, FechaR)(Productos con registro persistente)(Base Craig Larman)

ingresarOpcion( CrearGuiaRecepcion )desplegar( GuíaRecCompra )

ingresarOpcion(CrearGuiaRecepcion)es un método del Menú. La clase Fechaes una clase del Sistema en sí- siendo ahora() un método de la misma-, mientras que desplegar(GuiaRecCompra) pertenece a Terminal y siguiente()pertenece a la clase EncRecCompra- aún cuando esta última es una función genérica reutilizable-.

Nota:ingresarOpcion(CrearGuiaRecepcion)es un método del Menú. La clase Fechaes una clase del Sistema en sí- siendo ahora() un método de la misma-, mientras que desplegar(GuiaRecCompra) pertenece a Terminal y siguiente()pertenece a la clase EncRecCompra- aún cuando esta última es una función genérica reutilizable-.

Nota:

Nota: En forma excepcional se representan en este diagrama de colaboración los mensajes correspon-dientes a dos operaciones y sus respec-tivos contratos (desplegar es subordinadode ingresarOpcion).

Nota: En forma excepcional se representan en este diagrama de colaboración los mensajes correspon-dientes a dos operaciones y sus respec-tivos contratos (desplegar es subordinadode ingresarOpcion).

Nota: desplegar()es método propio de Termi-nal, por ello este mensaje nova más allá de este punto.

Nota: desplegar()es método propio de Termi-nal, por ello este mensaje nova más allá de este punto.


Diagramas de Colaboración:Creación de EncGuiaRecCompraingresarCodEmpleado(CodigoEmpleado)ingresarRutProveedor(RutProveedor)(Productos con registro persistente)(Base Craig Larman)

p1:Proveedores

r1:EncGuiaRecComprat1:Terminal 2:ingresarRutProveedor( RutProveedor )

2.1.a:RazonSocial:= consultarDatos (RutProveedor)2.1.b:Direccion := consultarDatos (RutProveedor)2.1.c:eMail := consultarDatos (RutProveedor)2.1.d:Comuna := consultarDatos (RutProveedor)2.1.e:Ciudad:= consultarDatos (RutProveedor) 2.1.f: Fono:= consultarDatos (RutProveedor)2.1.g:Fax := consultarDatos (RutProveedor)

p1:Proveedoresp1:Proveedores

r1:EncGuiaRecComprat1:Terminal 2:ingresarRutProveedor( RutProveedor ) r1:EncGuiaRecComprar1:EncGuiaRecComprat1:Terminal 2:ingresarRutProveedor( RutProveedor )t1:Terminal 2:ingresarRutProveedor( RutProveedor )

2.1.a:RazonSocial:= consultarDatos (RutProveedor)2.1.b:Direccion := consultarDatos (RutProveedor)2.1.c:eMail := consultarDatos (RutProveedor)2.1.d:Comuna := consultarDatos (RutProveedor)2.1.e:Ciudad:= consultarDatos (RutProveedor) 2.1.f: Fono:= consultarDatos (RutProveedor)2.1.g:Fax := consultarDatos (RutProveedor)

t1:Terminal r1:EncGuiaRecCompra1:ingresarCodEmpleado( CodigoEmpleado )

e1:Empleados

1.1:Nombre := consultarDatos( CodigoEmpleado )

t1:Terminal r1:EncGuiaRecCompra1:ingresarCodEmpleado( CodigoEmpleado )

t1:Terminalt1:Terminalt1:Terminal r1:EncGuiaRecComprar1:EncGuiaRecCompra1:ingresarCodEmpleado( CodigoEmpleado )

e1:Empleadose1:Empleados

1.1:Nombre := consultarDatos( CodigoEmpleado )

ingresarCodEmpleado( CodigoEmpleado )

ingresarRutProveedor( RutProveedor )

Asignación de ResponsabilidadesNota: Según Craig Larman( 18.9 a 18.11 - pág.193 a 205 ) La aplicación de los patrones GRASPes la guía para determinar las responsa-bilidades y la estructura del diagrama. La forma y secuencia de los mensajes queactivarán las operaciones respectivas sederivan de la aplicación de estos patrones.

Asignación de ResponsabilidadesNota: Según Craig Larman( 18.9 a 18.11 - pág.193 a 205 ) La aplicación de los patrones GRASPes la guía para determinar las responsa-bilidades y la estructura del diagrama. La forma y secuencia de los mensajes queactivarán las operaciones respectivas sederivan de la aplicación de estos patrones.

Diagramas de Colaboración:Creación de EncGuiaRecCompraingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)(Productos con registro persistente)(Base Craig Larman)

1: ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC)

ll:DetGuiaRecCompra

t1:Terminal r1:EncGuiaRecCompra

ll:DetGuiaRecComprall:DetGuiaRecCompra

t1:Terminalt1:Terminalt1:Terminal r1:EncGuiaRecCompra


es equivalente a repetir tres veces la función aceptarDatos(), enviando cada vez un parámetro correspondiente a un atributodistinto de la misma instancia de1.a: aceptarDatos(NumGuiaRecCom, NumGDP)1.b: aceptarDatos(NumGuiaRecCom, FecGD)1.c: aceptarDatos(NumGuiaRecCom, NumOC)


JUAN BRAVO C. 368

Diagramas de Colaboración:Creación de EncGuiaRecCompraingresarCodProducto(CodigoProducto)(Productos con registro persistente)(Base Craig Larman)

1.2:Descripcion := consultarDatos (CodigoProducto )1.2:Descripcion := consultarDatos (CodigoProducto )

1:ingresarCodProducto( CodigoProducto )

2 *:[i:=1...6] NumLínea:= siguiente () : NumLinea

ll:DetGuiaRecCompra

t1:Terminal

b1:Productos

1.1:aceptarCodigo( CodigoProducto )

r1:EncGuiaRecCompra


t1:Terminalt1:Terminalt1:Terminal

b1:Productosb1:Productos

1.1:aceptarCodigo( CodigoProducto )

r1:EncGuiaRecCompra

2.1 *:[i:=1...6] NumLínea:= siguiente () : NumLinea

2.2:crearLinea( NumLinea )

ingresarCodProducto( CodigoProducto )

siguiente () : NumLinea

Omisión del Contenedor de LíneasNota: Según Craig Larman( 21.8.6 - pg.262 ) : “ Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / colec-ción en sí mismo... estas clases ( tales comojava.util.Vector... ) sonclases predefinidasde la biblioteca de clases...no es útil mos-trarlas explícitamente... agregan “ruido ” pero poca información nueva. ”

Omisión del Contenedor de LíneasNota: Según Craig Larman( 21.8.6 - pg.262 ) : “ Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / colec-ción en sí mismo... estas clases ( tales comojava.util.Vector... ) sonclases predefinidasde la biblioteca de clases...no es útil mos-trarlas explícitamente... agregan “ruido ” pero poca información nueva. ”

Asignación de ResponsabilidadesNota: Según Craig Larman( 18.9 a 18.11 - pág.193 a 205 ) La aplicación de los patrones GRASPes la guía para determinar las responsa-bilidades y la estructura del diagrama. La forma y secuencia de los mensajes queactivarán las operaciones respectivas sederivan de estos patrones.

Asignación de ResponsabilidadesNota: Según Craig Larman( 18.9 a 18.11 - pág.193 a 205 ) La aplicación de los patrones GRASPes la guía para determinar las responsa-bilidades y la estructura del diagrama. La forma y secuencia de los mensajes queactivarán las operaciones respectivas sederivan de estos patrones.

Diagramas de Colaboración:Creación de EncGuiaRecCompraingresarPrecioCantidad(Precio, Cantidad)grabarLínea() y calcularTotales()(Productos con registro persistente)(Base Craig Larman)

ll:DetGuiaRecCompra

t1:Terminal1:ingresarPrecioCantidad( Precio , Cantidad )

1.1:aceptarDatos( Precio , Cantidad )


t1:Terminalt1:Terminalt1:Terminal1:ingresarPrecioCantidad( Precio , Cantidad )

1.1:aceptarDatos( Precio , Cantidad )

r1:EncGuiaRecCompra

2: /ValorTotal := calcularTotales()t1:Terminal r1:EncGuiaRecCompra

2.1*:[i:=1...6]: /ValorLínea := calcularValor()

ll:DetGuiaRecCompra

2: /ValorTotal := calcularTotales()t1:Terminalt1:Terminalt1:Terminal r1:EncGuiaRecCompra


ll:DetGuiaRecCompra

r1:EncGuiaRecCompra


ll:DetGuiaRecCompra


ll:DetGuiaRecComprall:DetGuiaRecCompraNota:No se muestra la secuen-cia de mensajes que correspondería a grabarLinea() . Esta corresponde-ría a la interacción entre la capa del dominio (aplicación) y la capa de servicios de almacenamiento per-sistente. (Otro conjunto de diagra-mas - no abordado aquí -).

ingresarPrecioCantidad( Precio , Cantidad )

grabarLinea()calcularTotales()

Nota: calcularTotaleses subordinado de grabarLíneay no es invocado por el actoren forma directa.

Nota: calcularTotaleses subordinado de grabarLíneay no es invocado por el actoren forma directa.

Nota:Después de grabarLinea() el usuario vuelve a la acción anterior de ingresarCodProducto() hasta queno queden más productos que ingre-sar, en cuyo caso pasa a la siguiente acción :

terminarTransaccion()


Diagramas de Colaboración:Creación de EncGuiaRecCompraterminarTransaccion() (Primera Parte)(Productos con registro persistente)(Base Craig Larman)

t1:Terminalt1:Terminalt1:Terminal1: /ValorTotal := calcularTotales()

r1:EncGuiaRecCompra1: /ValorTotal := calcularTotales()

r1:EncGuiaRecComprar1:EncGuiaRecCompra

1.1*:[i:=1...6] /ValorLínea := calcularValor()

ll:DetGuiaRecCompra

1.1*:[i:=1...6] /ValorLínea := calcularValor()


t1:Terminal r1:EncGuiaRecComprat1:Terminalt1: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 )


ll:DetGuiaRecCompra

b1:Productos

2.3*:[i:=1...6 ][notAct] notAct := notAct (notAct := false)



b1:Productos



b1:Productosb1:Productos




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

2.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 )

calcularTotales()

sumarRecibido( CodigoProducto, Cantidad ) calcularCPP( CodigoProducto, Cantidad, Precio )

sumarExistencia( CodigoProducto, Cantidad )

Nota:terminarTransacción() es realmente un mensaje “compuesto ” , que se desdobla en :calcularTotales() y los mensajes que interactúan con las capas de almacenamiento persistente y presentación. Esto es, por ejemplo, sumarExistencia() se realiza en la capa de dominio, sin embargo se registra en la capa de almacena-miento persistente (Tema no considerado aquí)

Nota: terminarTransaccion() es muy amplio y se presenta dividido en dos partes.

Nota: terminarTransaccion() es muy amplio y se presenta dividido en dos partes.

Diagramas de Colaboración:Creación de EncGuiaRecCompraterminarTransaccion() (Segunda Parte)(Productos con registro persistente)(Base Craig Larman)

r 1:EncGuiaRecCompra 5 :[NuevaGuiaRecepcion] crearEncabezado( NumGuiaRecCom , FechaR )t1:Terminal

l1:DetGuiaRecCompra


r 1:EncGuiaRecCompra r 1:EncGuiaRecCompra 5 :[NuevaGuiaRecepcion] crearEncabezado( NumGuiaRecCom , FechaR )t1:Terminalt1:Terminalt1:Terminal

l1:DetGuiaRecCompra


l1:DetGuiaRecCompral1:DetGuiaRecCompra


FechaFecha

t1:Terminal :EncGuiaRecCompra3:NumGuiaRecCom := siguiente() :NumGuia

:EncGuiaRecCompra:EncGuiaRecCompra3:NumGuiaRecCom := siguiente() :NumGuia

4:FechaR := ahora() :Fecha

siguiente() :NumGuiaahora() :Fecha

crearEncabezado( NumGuiaRecCom , FechaR )

Nota: terminarTransacción() finalmente “termina ”enviando los mensajes para crearEncadezado() y ob-tener los datos de inicialización desplegándolos en la interfaz “limpia”. Por cierto que esto implica una interacción entre la capa de dominio y la capa de presentación. (Tema no abor-dado aquí). Para implementar el mensaje “compuesto ” terminarTransacción() ” (completo), se usarían los patrones aplicables - entre otros, por ejemplo, Indirección, Fachada,Observador -.

JUAN BRAVO C. 370

Encabezado de Guía de Recepción

• RUT Proveedor• Nº Guía ProveedorNº de Guía RecepciónFecha RecepciónCódigo Empleado Fecha Guia ProveedorNº Orden de Compra/ Valor TotalTransacción CerradaTransacción Anulada

crearEncabezado()aceptarDatos()calcularTotales()cerrarTransacción()anularTransacción()copiarTransacción()siguiente()

•Nº LíneaCódigo ProductoPrecioCantidad/ Valor LíneanotActLínea CerradaLínea Anulada

Detalle de Guía de Recepción

crearLínea() aceptarCodigo()aceptarDatos()calcularValor()cerrarLínea()anularLínea()copiarLínea()siguiente()notAct()

Proveedores

•RUT ProveedorRazón SocialDireccióne-Mail ComunaCiudadPaísContactoFonoFax

Proveedores

•RUT ProveedorRazón SocialDireccióne-Mail ComunaCiudadPaísContactoFonoFax

Diagrama de Diseño de ClasesCrear Guía Interna de Recepción por Compra(Productos con Registropersistente)

1

1

*

*

1 1..*1 1..*

Productos

•Código ProductoDescripciónU.MedidaCosto UnitarioExistencia InicialExistenciaRecibidoDespachado

sumarExistencia() restarExistencia()sumarRecibido()sumarDespachado()existenciaNegativa()calcularCPP()



sumarExistencia() restarExistencia()sumarRecibido()sumarDespachado()existenciaNegativa()calcularCPP()

Empleados

• Código EmpleadoNombre

Empleados

• Código EmpleadoNombre

1*

Guía de Despa-cho de Proveedor

• Nº Guía de ProveedorRUT ProveedorFecha Guíaetc...

Guía de Despa-cho de Proveedor


1

1

Ordenesde CompraOrdenesde Compra

• Nº Ordende Compra

Datos

1

*

Nota: Según Craig Larman(21.8.4 a 21.8.8 - pgs.262 - 264)“Salvo casos especificos, es conve-nienteomitir los métodos :crear(),modificar(), eliminar() y consultar()en los diagramas de clases dado queno agregan valor y aumentan el“ruido” - se consideran implícitos -

Nota: Según Craig Larman(21.8.4 a 21.8.8 - pgs.262 - 264)“Salvo casos especificos, es conve-nienteomitir los métodos :crear(),modificar(), eliminar() y consultar()en los diagramas de clases dado queno agregan valor y aumentan el“ruido” - se consideran implícitos -

Nota: Agregado paraclarificar el contex-to, (ingreso manual).


Nota: Al crear la línea de detalle, notAct se incializa a: true




Nota: Agregado paraclarificar el contexto, en principio es una Lista de Valores Posibles.

Nota: Agregado paraclarificar el contexto, en principio es una Lista de Valores Posibles.

Encabezado de Guía de Recepción

•RUT Proveedor •Nº Guia ProveedorNº Guía RecepciónFecha RecepciónCódigo EmpleadoFecha Guía ProveedorNº Orden de Compra/ Valor TotalTransacción CerradaTransacción Anulada

1. crearEncabezado()2. aceptarDatos()6. calcularTotales()7. cerrarTransacción()8. anularTransacción()9. copiarTransacción()

10.siguiente()

•Nº LíneaCódigo ProductoPrecio Cantidad/ Valor líneanotActLínea CerradaLínea Anulada

Detalle de Guía de Recepción

1. crearLínea() 2. aceptarCodigo()3. aceptardatos()6. calcularValor()7. cerrarLínea()8. anularLínea()9. copiarLínea()10. siguiente()11. notAct()

Proveedores

•RUT ProveedorRazón SocialDireccióne_Mail ComunaCiudadPaísContactoFonoFax

Proveedores

•RUT ProveedorRazón SocialDireccióne_Mail ComunaCiudadPaísContactoFonoFax

Modelo Funcional(Detallado y Generalizado)Crear Guía Interna de Recepción por Compra(Productos con Registropersistente)(Base este libro)

Productos


4. consultarDatos()6. sumarExistencia() 7. restarExistencia()8. sumarRecibido()9. sumarDespachado()10. existenciaNegativa()11. calcularCPP()

Empleados

•Código EmpleadoNombre...

Empleados

•Código EmpleadoNombre...

Terminal

1. Desplegar interfaz(Correlativo, Fecha).2. Aceptar datos.3. Enviar mensajes de C/E a registros.4. Enviar mensajes de consulta de datos5. Calcular totales cumulativos6. Enviar mensajes de actualización de

existencias y actualizar línea a línea el registro de la transacción

Encabezado, detalle y totales según formato de pantalla adjunto.

Terminal

1. Desplegar interfaz(Correlativo, Fecha).2. Aceptar datos.3. Enviar mensajes de C/E a registros.4. Enviar mensajes de consulta de datos5. Calcular totales cumulativos6. Enviar mensajes de actualización de

existencias y actualizar línea a línea el registro de la transacción

Encabezado, detalle y totales según formato de pantalla adjunto.

C/E, msg1, msg2,

msg6 y msg10

C/E, msg1, msg2, msg3, msg6, msg10 y msg11

4. consultarDatos()

4. consultarDatos()

C/E y msg4

C/E y msg4

C/E, msg4, msg6, msg8 y msg11

C/E y msg4

Ordenesde Compra

Ordenesde Compra

• Nº Ordende CompraDatos

4. consultarDatos()

Guía de Despacho de Proveedor


Guía de Despacho de Proveedor


C/E y msg4

4. consultarDatos()





BIBLIOGRAFÍA

ACEVEDO, H. (1996): El análisis estructurado de sistemas y el desarrollo de proyectos informáticos, Valparaíso, Ecogestión Editora.

ACKOFF, R. (1972): Un concepto de planeación de empresas, México, Limusa. ACKOFF, R. (1979): Rediseñando el futuro, México, 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 información, Espa-

ña, McGraw-Hill. AT&T Quality Process Center (1992): Reengineering Handbook, USA, AT&T Bell Labora-

tories. BAEZA, R. (1991): “Apuntes del curso orientación a objetos”, Chile, Universidad de Chile. BRAVO, J. artículos:

“¿Se justifica el desarrollo de un sistema computacional?” Revista Informática, volu-men 7, número 2, marzo de 1985. “Modelamiento de datos y funciones”. Revista Ejecución, año 10, número 21, julio de 1990.

BRAVO, J. libros (Santiago de Chile, Editorial Evolución S.A.): • Desarrollo de sistemas de información, una visión práctica (1988) • Reingeniería de Negocios (1995) • Planificación Sistémica (1997) • Análisis de Sistemas (1998) • Gestión de Procesos (2005) • Taylor Revisitado, la productividad es la clave (2005) • Gestión de Proyectos de Procesos y Tecnología (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 ALARCÓN, L. (1999): Administración de Proyectos Civiles, Santiago de

Chile, Pontificia Universidad Católica. CARROL, Daniel T. (1976): How the president satisfies his information systems require-

ments, USA, Society for management information system proceeding. CERDA, G. (2002): “¿Estamos diseñando las interfaces de Software correctas?”, Chile, Re-

vista Akádemeia, Universidad de Ciencias de la Informática, diciembre de 2002, vo-lumen 2, año 2.

CERDA, G. y GUZMÁN, R. (2004): “Algunas recomendaciones a aplicar en el diseño de interfaces de software”, Chile, Revista Akádemeia, Universidad de Ciencias de la In-formática, diciembre de 2004, volumen 4, número 2.

CHIAVENATO, I. (2000): lntroducción a la teoría general de la administración, Quinta edi-ción, México, McGraw-Hill.

COLLADO, M. y GARCÍA, P. (1994): “Programación orientada al objeto en sistemas co-merciales”, Chile, Empresa Binaria S.A.

JUAN BRAVO C. 372

COMISIÓN PRESIDENCIAL (1999): “Tecnologías de información y comunicación. Chile: Hacia la sociedad de la información”. Presidencia de Chile.

COSTA Romero de Tejada, Manuel. (1984): “Introducción a la Ingeniería del Software”. Revista Mundo Electrónico, Nº 143, España.

COVACEVICH, A. (1994): Gerencia versus sistemas de información, Santiago de Chile, Ediciones Asterión Ltda.

DAHL, J., DIJKSTRA, E. y HOARE, C. (1980): Structured Programming. Academic Press Inc. (London) LTD

DAVIDSON, J. (2001): La Gestión de Proyectos, Madrid, Pearson. Diario El Mercurio (12 de febrero de 1995): “Proteínas que piensan”. Santiago de Chile. DRUCKER, P. (1993): Administración y futuro, Buenos Aires, Sudamericana. FAIRLEY, R. (1987): Ingeniería de Software. México, McGraw-Hill. FERNÁNDEZ S., Sergio M. (1995): Fundamentos del diseño y la programación orientada a

objetos. McGraw-Hill, Madrid. FRIEDMANN, R. (2007): Arte y gestión, una poética para el gerente del tercer milenio,

Chile, El periodista. GATTELL, R. (1992): Object data management. Sun Microsystems, Inc. USA, Addison-

Wesley. GETZ, I. y ROBINSON, A. (2005): Tus ideas lo cambian todo, Madrid, Alfaomega. GILLENSON, M. (1987): Introducción a las Bases de Datos. México, McGraw-Hill. GLADWELL, M. (2006): Inteligencia Intuitiva, Buenos Aires, Taurus. GOLDIN, I. y REINERT, K. (2007): Globalización para el desarrollo, Bogotá, Planeta. GOLEMAN, D. (2006): Inteligencia social, México, Planeta. GRAHAM, I. (1992): Object oriented methods. Addison-Wesley Publishing Company,. IBM de Chile S.A. (mayo de 1993): “Humanizando la tecnología”, Revista Providencia 655. INTERNATIONAL Data Corporation (1995): “Latin America Research Prospectus”, Region-

al Information Technology Studies, USA, 1995. ISHIKAWA , K. (1986): ¿Qué es el control total de calidad? La modalidad Japonesa, Co-

lombia, Editorial Norma. JACKSON, M. (1979): Principies of program design. Quinta Edición. Academic Press Inc.

(London) LTD. JACOBSON, I., BOOCH, G. y RUMBAUGH, J. (2000): El proceso unificado de desarrollo

de software, Madrid, Pearson educación, S.A. JALOTE, P. (2000): CMM in practice, Processes for executing software projects at Infosys,

California, Addison Wesley. KENDALL, K. y KENDALL, J. (2005): Análisis y Diseño de Sistemas, México, Pearson. KHOSHAFIAN, S. y ABNOUS, R. (1990): Object orientation. Concepts, Languages, Data-

bases, User Interfases. New York, John Wiley & Sons, Inc. KIM, W. y LOCHOVSKY, F. (1989): Object-oriented concepts, databases, and applications.

USA, Addison-Wesley Publishing Company, ACM PRESS. KOTTER, J. (2004): Liderazgo, Colección HBR, Argentina, Deusto. KOVACEVIC, A. y GONZÁLEZ, A. (1990): Sistemas de Información, conceptos e impli-

cancias para la empresa. Santiago de Chile, Universidad Católica de Chile. LAMB, D. (1988): Software Engineering: planning for change. USA, Prentice-Hall. LARMAN, C. (1999): UML y Patrones, México, Prentice Hall. LARRAÑAGA, I. Muéstrame tu Rostro. Coedición CEFEPAL y Paulinas, Chile, 1979.


LEDGARD, H. y TAUER, J. (1987): Software Engineering Concepts. USA, Addison-Wesley.

LIPSCHUTZ, S. (1987): Teoría de Conjuntos y Temas afines, Serie Schaum, México, McGraw-Hill.

MARTIN, J. (1985): La sociedad telemática, el desafío del mañana. Buenos Aires, Editorial Pairos.

MARTIN, J. y ODELL, J. (1994): Análisis y diseño orientado a objetos. USA, Prentice-Hall. McCONNELL, S. (1997): Desarrollo y gestión de proyectos informáticos, Madrid, McGraw-

Hill. MODELL, M. (1996): Systems Analysis, USA, McGraw-Hill. OECD (2000): Information Technology Outlook 2000, Unión 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): Ingeniería de Software, teoría y práctica, Buenos Airtes, Pearson. PORTER, M. (1992): Ventaja competitiva, creación y sostenimiento de un desempeño supe-

rior , México, Continental. PREECE, J. y otros autores. (1996): Human-Computer Interaction. USA, Addison-Wesley. PRESSMAN, R. (1993): Ingeniería de Software, un enfoque práctico, 3ª edición, España,

McGraw-Hill. REVISTA AMÉRICA ECONOMÍA

Telecomunicaciones, abril/93. Más vale la respuesta rápida, 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 difícil mundo de ERP, marzo de 1996.

REVISTA COMPUTERWORLD, Santiago de Chile. Reingeniería de negocios, el desafío de hoy para la empresa del futuro, marzo de 1993. Archivos con rostros, un gran ejemplo de reingeniería de procesos, abril de 1993. La realidad de la reingeniería, junio de 1993. Reingeniería en las hipotecas, julio de 1995. Objetos: La revolución de los 90, agosto de 1995.

REVISTA INFORMÁTICA, Santiago de Chile. Reutilización: El sueño de la Ingeniería 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 electrónica, mayo de 1993.

REVISTA NEWS 3X/400, España. Doce pasos para diseñar Bases de Datos relacionales, julio de 1994.

ROCKART, J. (1979): “Los altos directivos definen sus necesidades de información”, Argen-tina, Biblioteca Harvard de Administración de Empresas.

ROCKART, J. y Bullen, C. (1981): “A primer on critical sucess factors”. Massachusetts Insti-tute of Technology.

JUAN BRAVO C. 374

SEELY, J. y DUGUID, P. (2001): La vida social de la información, Buenos Aires, Prentice-Hall.

SENGE, P. (1992): La Quinta Disciplina, Buenos Aires, Granica y Vergara. SENN, J. (1987): Análisis y diseño de sistemas de información, México, 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 gestión de costos de proyectos”, Clase ejecutiva de El Mercu-

rio, 13 de octubre, B11, Santiago de Chile. SOMMERVILLE, I. (2005): Ingeniería del software, 7ª ed., México, Pearson (p. 6). STEVENS, Perdita y POOLEY, Rob (2002): Utilización de UML en Ingeniería del software

con Objetos y Componentes, Madrid, Pearson Educación. SYSTEM ARCHITECT. (1992): “Object-oriented Technology” (incluye Métodos de Grady

Booch y Coad/Yourdon), USA, Popkin Software & System Inc. SWENSON, L. (1984): Teorías del aprendizaje, Buenos Aires, Paidós. TAYLOR, F. W. (1969, original de 1911): Principios de la administración científica, Argen-

tina, El Ateneo. TEASLEY, B. (1990): Software engineering with student project guidance, USA, Prentice

Hall. TOLOZA, C. (2005): “¿Cuál es la rentabilidad de la informática 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 análisis y diseño 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): Ingeniería de software orientada a objetos con UML, Java

e Internet, México, Thomson. WILSON, P., Dell, L. y Anderson, G. (1999): Análisis de la causa raíz, una herramienta

para administración de la calidad total, México, Oxford University Press. WIEDERHOLD, G. (1986): Diseño de Bases de Datos, Segunda edición, México, McGraw-

Hill. WIRFS-BROCK, R., WILKERSON, B. y WIENER, L. (1990): Designing Object-Oriented

Software. New Jersey, Prentice Hall.


LIBROS DEL AUTOR PUBLICADOS POR EDITORIAL EVOLUCIÓN

GESTIÓN AVANZADA DE PROCESOS

Precio versión en papel: US$ 15, Chile $10.000 (2009, 190 Págs., 21 x 14 cm.)

El objetivo del libro es aportar métodos concretos para el rediseño y mejora de procesos en la organización, como un medio para lograr la eficiencia y agregar valor para el cliente en una relación de confianza. Surge de una profunda inquietud por el despilfarro de recursos en nuestra socie-dad y, sobre todo, por la subutilización del enorme potencial de las personas. La gestión de procesos es un deseo que se intuye como importante en las orga-nizaciones. Sin embargo, es poco lo que logra realizarse porque no se sabe cómo hacerlo, provocando grandes pérdidas en las mismas organizaciones y en la sociedad por proyectos mal planteados o fuera de costo y plazo, trámites que demoran más de la cuenta, mala atención de clientes, productos defectuosos, entregas con retraso, equivocaciones médicas, errores, pérdidas de clientes y tanto más… En el libro se enseña cómo incorporar a la organización un modelo integral para la gestión de procesos. Este libro complementa, aporta técnicas y muestra aplicaciones de los conceptos desarrollados en el libro Gestión de Procesos, el cual es prerrequisito para éste.

JUAN BRAVO C. 376

GESTIÓN DE PROCESOS

GESTIÓN DE PROCESOS Precio versión en papel: US$ 24, Chile $16.000 (2006, 2ª edición, 400 Págs., 24,5 x 17,2 cm.)

(1ª edición de 2005) Es fácil aceptar la necesidad de cambio en nuestro mundo. Más difícil es cambiar nosotros mismos o que cambie nuestra organización, o la forma cómo hacemos las cosas, a las cuales podríamos llamar… procesos. La gestión de procesos nos insta a detenernos, reflexionar acerca de lo que hacemos y preguntarnos: ¿por qué?, ¿para qué?, ¿cómo?. Porque, si profesionales capaces tienen ideas brillantes que permitirán ganar o ahorrar mucho dinero, al mismo tiempo deberían inventar los nuevos empleos de las personas que serán liberadas de funciones obsoletas. Lo pueden hacer, porque son capaces. Lo deben hacer, por su condición de seres humanos. La gestión de procesos es un medio para lograr grandes metas organizacionales, como la calidad, competitividad, productividad, comunicación y rentabilidad.


GESTIÓN DE PROYECTOS


El objetivo de este libro es ofrecer un método para la gesta-ción, evaluación, planificación, dirección y buena ejecución de los proyectos, principalmente de procesos y tecnología. Es importante hacer bien los proyectos, porque a través de ellos se materializa el cambio propuesto por la estrategia de la organización o por las oportunidades que el medio ofrece. El método tiene como base un amplio estudio de las mejores

prácticas de la gestión de los proyectos y del cambio en las personas. Las em-presas públicas y privadas de Chile pierden anualmente más de 2.000 millones de dólares debido a fallas evitables en proyectos de gestión. De una u otra forma esa ineficiencia la pagamos todos y con creces, porque tampoco disfru-tamos de los beneficios del proyecto si hubiese sido bien hecho.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

Precio versión en papel: US$ 24, Chile $16.000 (2008, 392 Págs., 24,5 x 17 cm.)

El objetivo de este libro es cooperar en aumentar la productividad del desarrollo y la calidad de la solución de software mediante la excelencia de su modelación. Comenzamos por asegurarnos que la serie de modelos (correspondientes a las etapas de análisis y diseño) efectivamente dan solución a una necesidad bien com-prendida y evaluada.

Modelar soluciones de software es una labor bella y creativa que origina verdaderas “obras de arte”. Sin perder la belleza y creatividad, ¿será posible profesio-

nalizar su elaboración? ¡Sí! Definitivamente el diseño de sistemas puede ser arte y tecnología a la vez.

JUAN BRAVO C. 378

EL ENCANTO DE LA COMUNICACIÓN

Precio versión en papel: US$ 15, Chile $10.000 (2007, 2ª edición 230 Págs., 18,5 x 13 cm., 1ª edición de 1998).

Es un libro orientado a todas las personas que quieren co-municarse mejor con quienes les rodean para incrementar la calidad de su vida. El espíritu de este libro es que nos sirva de guía práctica en esta tarea de toda la vida destinada a relacionarnos mejor y a transformarnos. ¿Por qué? Porque la comunicación es cambio que podemos guiar hacia la supe-ración personal.

Estamos vivos y lo más característico de la vida es la transformación. Y por-que el vínculo con nuestros seres queridos es lo único que realmente cuenta, además la mejora en las comunicaciones en las empresas tiene un efecto in-mediato en la vida familiar y social de sus trabajadores.

RESPONSABILIDAD SOCIAL (RS)

Precio versión en papel: US$ 24, Chile $16.000 (2007, 380 Págs., 24,5 x 17,3 cm.)

En los países de Latinoamérica podemos ganar miles de millones de dólares al año con la RS. Surgen de dejar de perder evitando la Irresponsabilidad Social (accidentes, delincuencia, corrupción, mala educación, etc.) y de ga-nar fomentando la Responsabilidad Social (investiga-ción, innovación, emprendimiento, comunicación, etc.). Por eso la RS es la nueva causa de la riqueza de las Naciones. Se puede lograr, tenemos ejemplos de buenos diseños que han disminuido grandes males sociales en

un 80%. Es el caso, en Chile, de la disminución de la tasa de accidentabilidad de los trabajadores desde el 35% de los años 60 al actual 7%. Por supuesto, el énfasis ha estado en la prevención.


HISTORIA DEL IST, 50 AÑOS

Precio versión en papel: US$ 24, Chile $16.000. (2007, 164 Págs., 25 x 25 cm.)

Cumplir 50 años es un gran logro para toda or-ganización y mucho más para una que se dedica a la seguridad social por el gran impacto que tiene en la comunidad. La historia del IST es a la vez parte de la historia de la seguridad del trabajo en Chile, cuyos avances se pueden re-sumir en una sola palabra que bien conocen en

el Instituto: prevención.

Es un avance de Responsabilidad Social que se puede proyectar a otros ámbi-tos para contribuir al Bien Común. Ya sabemos que una historia puede inspi-rar a las personas para lograr fines superiores, al menos para encontrarle senti-do a su quehacer y motivarse. También permite aprender, porque de la lectura se podrá extraer una buena manera de gestionar una empresa, comenzando por una gran dosis de visión.

EMPRESAS DE ÉXITO


Este es un libro acerca de las empresas de éxito, aquellas con una gestión que las lleva a diferenciarse. En un contex-to de buenas prácticas de gestión la tesis es que las empre-sas exitosas se distinguen por algunas pocas prácticas ex-cepcionales. Así como existe la gestión por competencias dirigida a las personas, también existe una gestión por competencias cor-

porativa. Además de hacer las cosas bien, las empresas exitosas se distinguen por un pequeño número de prácticas que hacen muy bien, les hemos llamado “siste-ma de diferenciación”. Se presentan los ejemplos de IST, ENAMI Ventanas, Termosistema e Integramédica.

JUAN BRAVO C. 380

GESTIÓN, EL CASO ENAMI VENTANAS


Es importante destacar lo positivo de la gestión de las empresas, así aprendemos de experiencias concretas. La idea fue desafiante: compartir y aprender de la gestión realizada en una unidad de negocios de una importante organización. Se trata de la Fundición y Refinería Ven-tanas de la Empresa Nacional de Minería, ENAMI. Tiene una cultura distintiva que se aprecia en la inge-niería o innovación permanente, en su contribución al

bienestar del país, en el sentido de honor, en la pasión por aprender, entre otras. Se identificaron varios factores relevantes, por ejemplo: liderazgo, producti-vidad, entorno y personas

TAYLOR REVISITADO


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 países ricos le deban su condición de tales, dice Peter Drucker. Taylor sigue aportando a la creación de riqueza a través de la mayor productividad. Fue precursor

del entrenamiento o capacitación y de la gestión por competencias. Buscó evitar el derroche de materiales y se le reconoce como padre de la ingeniería industrial y de la ergonomía. Buscó que se compartieran los beneficios de la mayor productividad, entre empresarios, trabajadores y la sociedad. ¿Por qué es tan actual su mensaje? Porque su mensaje de fondo está orientado a la su-peración de la pobreza y porque sus propuestas, debidamente actualizadas, podrían generar grandes beneficios en la economía de Latinoamérica.


A LA SALIDA DEL TÚNEL


Es un libro creado con las entrevistas realizadas a los parti-cipantes del programa de televisión del mismo nombre en donde se extrajeron sus mejores ideas, propuestas y mensa-jes. Fue un programa de UCV TV, conducido por el diná-mico y querido periodista Atilio Macchiavello.

Este documento recrea la vida de muchos visionarios y podría ser la salida de su propio túnel. Es un Texto obliga-

do para profesores, estudiantes, profesionales y público en general. Una inspi-ración para pequeños y grandes empresarios y orientación vivencial para nues-tras autoridades.

AMBROSOLI, DESDE LOS ALPES A LOS ANDES


Coautor: Giancarlo Gandolini Ambrosoli.

Este libro es un reconocimiento a la labor de don Cons-tantino Ambrosoli y a todos los emprendedores que ayu-dan a crear un mundo más humano. Es un ejemplo inspi-rador que queremos compartir, porque excedió en mucho nuestras expectativas. ¿Para qué sirve una historia? Para conocer, entender y difundir la cultura de una organización, establecer un

vínculo entre sus integrantes, comunicar una causa común, preservar las tradi-ciones y seguir adelante unidos. Es un gran desarrollo, inseparablemente uni-do a la historia de la familia Ambrosoli, así que para entender la evolución de este negocio, necesitamos conocer la rica tradición acumulada en esta familia.

JUAN BRAVO C. 382

ANÁLISIS DE SISTEMAS

Precio versión en papel: US$ 24, Chile $16.000. (1998, 415 Págs., 26,5 x 18,5 cm.).

Debemos descubrir los sistemas y aprender de ellos para ayudar en el desarrollo de las organizaciones. La vieja cosmovisión 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, educación, comunica-ción, libertad, creatividad y otras respuestas. Si pretende-

mos ignorarla, dar órdenes o sólo poner reglas, la complejidad se abrirá paso igual, como las aguas de un río que se pretenden frenar con un “prohibido el paso”. ¿Cómo hacer análisis de sistemas? Con un enfoque al problema-solución que pasa por comprender la confusión. Algunas herramientas sistémicas son: la teoría del caos, la teoría de la catás-trofe, los círculos virtuosos, la orientación al cliente, etc.

PLANIFICACIÓN SISTÉMICA

Precio versión en papel: US$ 24, Chile $16.000 (1997, 240 Págs., 26,5 x 18,5 cm.).

Tradicionalmente, hemos hecho planificación suponiendo que las condiciones ambientales se mantendrían más o me-nos constantes. ¡Hoy nos damos cuenta que el entorno varía con mucha rapidez! y que la velocidad del cambio sigue y sigue aumentando. Para adaptarnos a esta realidad, la plani-ficación sistémica recurre a herramientas tales como: partici-pación, creatividad y manejo de la incertidumbre del medio.

La planificación sistémica nos ayuda a cumplir los sueños, siguiendo un ca-mino que comienza por determinar qué es lo que queremos, en nuestra empre-sa o… en nuestra vida. Luego, establecemos un sistema de diferenciación y un plan.


LA NUEVA VISIÓN, DISEÑO Y CONSTRUCCIÓN DE SISTEMAS COMPUTACIONALES

Precio versión en papel: US$ 24, Chile $16.000, (contenido actualizado en libro Modelando una solución de software) (2ª edición 2007, 272 Págs., 26,5 x 18,5 cm.) (1ª edición de 1996) Sólo colección.

Este libro trata sobre el desarrollo de sistemas computacio-nales, tales como inventarios, contabilidad, remuneraciones o facturación. Se busca aumentar la productividad en ese ámbito. En espe-

cial se estudia el diseño de sistemas computacionales, una labor bella y emi-nentemente creativa que origina verdaderas “obras de arte”, a veces artesana-les. Siempre conservando la creatividad, ¿Será posible que los métodos de trabajos y las herramientas sean de uso general? ¡Sí! Definitivamente el dise-ño de sistemas dejó de ser arte para transformarse en tecnología. Esta propuesta de la ingeniería de software tiene su base en tres sólidos pila-res: La planificación estratégica en informática, el diseño orientado al objeto y las herramientas de productividad.

REINGENIERÍA DE NEGOCIOS


La finalidad de la reingeniería es lograr grandes desafíos, por ejemplo: aumentar la productividad de las personas, las ven-tas o la producción, no en un 30%, sino en 400% y más. ¿Cómo lograrlo? A través de efectuar grandes cambios en los procesos del negocio, potenciar a las personas, definir una estructura organizacional flexible e incorporar tecnología. Todo en sintonía con la cultura y estrategia de la organiza-

ción. ¿Para qué hacer reingeniería? Para cumplir con la misión de la organización, tarea en la que deben estar empeñadas todas las personas que ahí laboran, sirviendo los intereses de los clientes en armonía con los valores de la empre-sa y de la comunidad.

JUAN BRAVO C. 384

MODELAMIENTO DE SISTEMAS DE INFORMACIÓN

Precio versión en papel: US$ 24, Chile $16.000 (contenido actualizado en libro Modelando una solución de software) (1994, 250 Págs., 24,4 x 18,2 cm.). Sólo colección.

Da una visión de conjunto sobre el desarrollo de sistemas de información, comenzando por la planificación estratégica del negocio. En el texto se incorporan los conceptos de evaluación de

proyectos informáticos, los lenguajes de cuarta generación y la orientación a objetos. Especial relevancia tienen la Ingeniería de Software y las herramien-tas de apoyo en cada etapa del desarrollo del sistema de información. En las últimas décadas la “computación” ha sido un agente de cambio al in-terior de la organización, hoy las áreas de informática o de sistemas también deben cambiar. Se trata de lograr el desarrollo de software de calidad, económico y en plazos convenidos.

DESARROLLO DE SISTEMAS DE INFORMACIÓN

Precio versión en papel: US$ 24, Chile $16.000 (1996, 3ª edición, 204 Págs., 26,5 x 18,5 cm.) (1ª edición de 1987)

El objetivo de este libro es servir de guía práctica en el desarrollo y en la mantención de sistemas de información orientados a empresas. Está especialmente dirigido a todos quienes laboran en el área de informática, y que podrían hacer uso de las materias prácticas, que buscan mejorar el rendimiento, mediante la aplicación de pautas simples y lógicas, donde el criterio predomina sobre la reglamenta-

ción. También se orienta a estudiantes de carreras del área computación e informá-tica, quienes podrán ver facilitado su aprendizaje al enfrentarse con metodo-logías y ejemplos concretos, sobre la base de una visión de conjunto del desa-rrollo de sistemas de información. El libro ha sido de gran ayuda para académicos de las áreas mencionadas.


ACERCA DEL AUTOR:

Juan Bravo Carrasco Doctor por la Universidad de Lleida (España). Master en Dirección de In-formática (Ide Cesem, España) e Ingeniero de Ejecución en Sistemas de In-formación (USM, Chile).

Es Presidente de Evolución, Centro de Estudios Avanzados y editor de la Re-vista Responsabilidad Social.

Con más de 30 años de experiencia como ejecutivo, consultor y relator de seminarios, el Dr. Bravo ha ayudado a clientes tales como: Mutual de Seguri-dad, ENAMI, BancoEstado, Rolec, Transbank, Isapre Colmena, Municipali-dad de Quillota, Banco Itaú, Empresa Portuaria de Valparaíso, Constructora TECSA y Termosistema.

El Dr. Bravo es profesor de programas de postgrado en la Pontificia Universi-dad Católica, Universidad Técnica Federico Santa María (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 están disponibles en papel.

Su disponibilidad en digital y actualización se explica a continuación.

Libros en digital y actualizados

Estos seis textos están disponibles y actualizados en digital. Son los libros más relacionados con el hacer actual de consultoría:

1. Gestión Avanzada de Procesos 2. Gestión de Procesos 3. Gestión de Proyectos 4. Modelando una Solución de Software 5. El Encanto de la Comunicación

JUAN BRAVO C. 386

6. Responsabilidad Social

Los siguientes doce libros no tienen actualización:

Seis son históricos (A la salida del Túnel, Ambrosoli, Enami, Taylor, IST y Empresas de éxito).

Otros seis (Desarrollo, Modelamiento, Reingeniería, Diseño, Planificación y Análisis) perdieron tanta vigencia que no basta con la actualización para su permanencia. En este caso aplica el rediseño, en la forma de nuevos textos que heredan contenidos reciclados posibles de rescatar de los antiguos. Por ejem-plo, el libro Modelando una Solución de Software heredó algunos contenidos de los textos Modelamiento y Diseño.

Libros en digital sin actualización

Estos siete libros están disponibles en digital en su versión original del año que se indica:

1. Reingeniería de Negocios(1995) 2. Diseño de sistemas computacionales (1996) 3. Planificación Sistémica (1997) 4. Análisis de Sistemas (1998) 5. A la Salida del Túnel (2000) 6. Taylor Revisitado (2005) 7. Empresas de Éxito (2005)

Libros sólo en papel sin actualización

Estos cinco libros están disponibles sólo en papel desde las fechas que se in-dican:

1. Desarrollo de sistemas de información, (1996, tercera edición, primera versión de 1987)

2. Modelamiento de sistemas de información (1994) 3. Ambrosoli, desde Los Alpes a Los Andes (1998) 4. Gestión, el caso Enami Ventanas (2005) 5. Instituto de Seguridad del Trabajo, historia (2007)

INFORMACIÓN GENERAL

Cada texto puede ser adquirido en la forma de una versión corporativa en pa-pel o digital.

Editorial Evolución S.A.: Av. Libertador Bernardo O’Higgins Nº171, of 307, Santiago, fono: 6389717 www.evolucion.cl, [email protected].

73926258 Modelando Software

Documents

Transcript of 73926258 Modelando Software